Антон Алексеев, Автор в Академия Selectel

Когда клиент приходит с запросом в духе «Разверните мне Qwen», невольно задаешься вопросом: «А какая инфраструктура нужна для такой задачи?» Но если запрос становится более конкретным, например, «Разверните Qwen так, чтобы держать 10 RPS с задержкой до пяти секунд», то можно и вовсе растеряться. Как подобрать конфигурацию под такие требования? В серии статей разберемся, как отвечать на такие вопросы. Рассмотрим, какие инструменты помогают быстро подобрать оптимальную инфраструктуру, как тестировать производительность инференса и автоматизировать процесс. Посмотрим, как пройти путь от ручных запусков примеров моделей до автоматизированного анализа работы фреймворков на GPU с подбором оптимальной конфигурации. А еще в последнее время мне нравится тематика викингов и драконов (особенно та часть, которая связана с медовухой). Вместе мы напишем книгу по приручению самых разнообразных драконов или, как в простонародье, open source LLM. В ней рассмотрим разные типы драконов, какие «GPU-седла» подходят под каждого и какие инструменты использовать для приручения. Из System Design в подбор инфраструктуры для инференса Как происходит подбор инфраструктуры для обычных веб-приложений? Например, сайта с продажей плюшевых тирексов-викингов, агрегатора такси-дракаров или почтово-голубиного мессенджера? Обратимся к стандартным практикам System Design. После сбора первичных требований к системе очень важно оценить необходимую инфраструктуру для развертывания и поддержки системы, а также стоимость всего оборудования и процессов. От точности расчетов будет зависеть успех проекта и его жизнеспособность, а самое главное — хватит ли у заказчика материальных ресурсов, чтобы воплотить все сформулированные пожелания и требования к системе. Оценка позволит скорректировать ожидания от продукта. Рассмотрим основные метрики расчета. Пользовательский трафик. Рассчитываем RPS (requests per seconds) относительно заданного MAU (monthly active users). Сетевой трафик и соединения. В облаке уже доступно 1 Гбит/с. Современный сервер может выдержать наплыв в 10 000–100 000 соединений. Нагрузка на вычислительную мощность. Исходя из RPS, высчитываем количество станций для обработки трафика. Необходимое дисковое пространство для хранения данных и расчет потенциального прироста объема хранилища. Считаем, на сколько пополняется база данных в среднем, и прикидываем на определенное количество лет необходимую емкость. Также учитываем требования по скорости — где подойдет дешевый HDD, а где стоит использовать SSD или даже оперативную память. Помимо прочего, важно помнить о праве на ошибку. Если платформу разворачивать в облаке, то к уже развернутой инфраструктуре достаточно просто добавить сотни гигабайт дискового пространства, десятки гигабайт оперативной памяти и CPU. Все достаточно гибко и всегда можно увеличить/уменьшить относительно реального трафика. Но можно ли так же сделать с инференсом LLM? «Маркетплейс GPU» в мире викингов. Для приручения наших драконов-инференсов необходимы «GPU-седла». GPU, в отличие от CPU, лучше подходят для работы с нейронными сетями, так как обладают огромным количеством ядер, где параллельно происходят матричные операции. В случае с выбором GPU цена ошибки будет велика — при неточном расчете придется переходить на другие модели GPU, что может привести к большим тратам на аренду. Например, переход с RTX™ 4090 c 24 ГБ VRAM на A100 с 40 ГБ VRAM потребует дополнительно около 100 000 ₽/мес. При этом просто добавить VRAM к существующей RTX™ 4090 не получится (можно только добавить еще одну такую GPU, но это все равно увеличит стоимость в два раза). Нельзя просто так взять и добавить 1 ГБ VRAM к системе! Только если вам не доступны тайные знания про способы деления GPU и об интересном проекте Hami-Project, где действительно можно построить системы с гибкой аллокацией видеопамяти. Но в этой статье разберем примеры без шеринга GPU. И внимательный викинг-новичок может задаться вопросом: «Как мне вообще определить нужный объем VRAM для выбранной LLM — например, для Qwen?» Ответы мы разберем дальше — в нашей книге по приручению драконов! Первые шаги в подборе инфраструктуры Тот самый момент первого шага в новый мир! Сейчас мы отправимся в длительное путешествие на нашем викингском дракаре в поисках драконов. Рассмотрим, как выглядит путь подбора инфраструктуры для LLM. Модель на HuggingFace (Qwen, Llama, deepseek). Квантизация модели (32 bit, 16 bit, 4 bit). GPU. Инференс-фреймворк. Конфигурация инференса. Автоматизация подбора. В этой части цикла мы поговорим про GPU и инференс-фреймворки, в следующей — разберем квантизацию моделей, конфигурацию инференс-серверов и автоматизацию подбора инфраструктуры. Начнем с реального кейса, где требовался подбор инфраструктуры для Qwen на 32 млрд параметров. Основная задача — анализ транскрибированных аудиозаписей диалога официанта и клиента, где модель по заданному промту оценивала качество работы сотрудника. Как бы выглядел Qwen в книге приручения драконов. Модель выбрана — Qwen3 32b. Следующий этап — выбор квантизации и GPU, но сперва нужно рассчитать VRAM (требуемую видеопамять GPU). Расчет требуемой VRAM для инференса Почему VRAM критична для LLM Прежде всего, запуск больших языковых моделей упирается в объем видеопамяти GPU. В VRAM должны поместиться не только сами веса модели, но и промежуточные вычисления, а во время генерации — еще и KV-кэш, хранящий историю токенов. Если памяти не хватает, инференс обрывается с ошибкой Out-Of-Memory. Если взять карту с чрезмерным запасом, то часть дорогого ресурса окажется неиспользованной. Именно поэтому VRAM определяет: физическую возможность запуска (модель в нужной разрядности просто может не загрузиться); производительность (batch size и длина контекста напрямую зависят от объема памяти, влияя на задержку и пропускную способность); стабильность (OOM во время тренировки или дообучения может обнулить прогресс и потратить часы GPU впустую). Грамотная оценка VRAM до старта позволяет избежать переплат и простоев, а также подобрать оптимальный баланс между стоимостью аренды GPU и реальной производительностью модели. Почему важен VRAM при инференсе Когда мы запускаем LLM в режиме инференса (без обучения), VRAM расходуется на несколько ключевых частей. Разберем их поэтапно. Параметры модели Веса занимают основной объем памяти и рассчитываются как число параметров × размерность precision. Где: Nparams— число параметров модели; Bytesper_param — размерность precision. FP16 / BF16 → 2 байта на параметр, INT8 → 1 байт, INT4 → 0,5 байта. Выбор размерности задает каркас для выбора квантизации, однако мы пока не принимаем во внимание методы квантизации — о них поговорим в следующей части. Активации Активации — это промежуточные результаты работы слоев. Их объем зависит от batch size, длины последовательности (context length) и архитектуры. Обычно это несколько дополнительных гигабайт. KV-кэш При генерации токенов модель сохраняет ключи и значения attention-механизма, чтобы ускорять следующие шаги. Размер кэша растет линейно с длиной контекста и числом слоев. Для длинных промтов это может быть основной потребитель VRAM. Формула расчета KV-кеша выглядит следующим образом: Где L — число слоев, Nkv — количество KV-голов, Dkv — размерность головы, S — длина контекста, B — batch size. Временные буферы и overhead Фреймворки (PyTorch, TensorRT, vLLM и другие) резервируют память под CUDA-операции, оптимизации и служебные задачи. Обычно стоит закладывать 1–2 ГБ на дополнительные расчеты. Входные данные Токенизированные входные батчи тоже занимают немного VRAM, однако это доли процента по сравнению с параметрами и кэшем. В итоге при инференсе основные «пожиратели» памяти — это веса модели + KV-кэш, а все остальные компоненты обычно добавляют лишь несколько гигабайт сверху. Распишем требуемые VRAM для Qwen32b, используя формулы для количества параметров и KV-кеша. Tensor TypeTF32/FP32 BF16/FP16INT8INT4Размер параметра4 байта2 байта1 байт~0,5 байтаVRAM весов QwQ-32B128 ГБ64 ГБ32 ГБ16 ГБKV-cache QwQ-32B(1 batch)10 ГБ5 ГБ2,5 ГБ1,2 ГБTotal VRAM GB~138 ГБ~70 ГБ~35 ГБ~18 ГБ Возьмем для примера квантизацию INT8 и подберем GPU, в которые может «влезть» наша LLM по текущим требованиям. Как видно на изображении, мы можем взять несколько GPU одной модели, чтобы уместить ~35 ГБ видеопамяти. Соединять GPU можно по степени двойки (1, 2, 4, 16 и т. д.) . Например, у Tesla® T4 16 ГБ видеопамяти, поэтому для покрытия 35 ГБ понадобится четыре карты. У A5000 или RTX™ 4090 24 ГБ VRAM — их понадобится по две штуки. В A100 40 ГБ (но может быть 80) — здесь подойдет и одна GPU, однако по стоимости она будет все равно дороже, например, двух RTX™ 4090. Также я выделил примерные категории таких GPU по цене и скорости. Скорость складывается из нескольких характеристик: TFlOPS, архитектуры, пропускной способности, CUDA-ядер. Рассмотрим основные метрики, которые определяют производительность. TFLOPS (FP16 / BF16 / INT8 / INT4) — показывает теоретическую вычислительную мощность в триллионах операций в секунду. Но «сырые» терафлопсы — не всегда гарантия скорости: многое зависит от поддержки нужных форматов (FP16, INT8, FP8). Архитектура GPU — каждое поколение (Ampere, Ada Lovelace, Hopper) приносит оптимизации для ML/LLM. Например, H100 (Hopper) поддерживает FP8 и более быстрый attention. Пропускная способность памяти (Memory Bandwidth) — определяет, насколько быстро можно читать/писать данные из VRAM. Критично для LLM, так как инференс часто ограничен именно памятью, а не ALU. Количество CUDA-ядер и тензорных ядер — больше ядер означает больше параллелизма. Но реальная эффективность зависит от фреймворка (PyTorch, vLLM, TensorRT) и его умения загружать GPU. Выбор конкретной GPU требует проведения эксперимента — запуска инференса и проверки на нагрузку. Запуск инференса на GPU Запуск инференса напрямую из Hugging Face Самый простой способ запустить модель — использовать API библиотеки Transformers. Достаточно зайти на страницу модели в HF и скопировать несколько строк кода, чтобы загрузить модель и получить ответ: Это достаточно простой способ запуска, однако он подходит только для прототипирования и тестов, а не для продакшен-нагрузки. Чтобы получить производительность и гибкость, используют оптимизированные инференс-движки. Ниже — сравнение популярных решений. OllamaSGLangvLLMУпрощенный запуск LLM локально («как Docker для моделей»)Ориентирован на оптимизацию работы с длинным контекстом и параллельной генерациейОдин из самых популярных инференс-движковУпор на удобство: ollama run qwen и модель готоваПоддерживает техники ускорения (PagedAttention, FlashAttention)Ключевая фишка: PagedAttention позволяет эффективно использовать KV-кэш, снижая VRAM-расход и увеличивая throughputРаботает даже на CPU, поддерживает GPU, но не дает тонкой настройкиДает хорошие результаты при инференсе с большими промтами и батчамиПоддерживает интеграцию с Hugging Face и OpenAI API-совместимый серверХорошо подходит для локальной разработки и простых приложенийПодходит для сценариев с большим количеством одновременных запросовЛучший вариант для продакшен-сервисов с высокой нагрузкой Для ранее описанного кейса мы рассчитали характеристики на двух фреймворках: Ollama и VLLM. Первые тесты были достаточно простыми: Python-скрипт измерял время отправки запроса с промтом до инференс-сервера на разных GPU. Ниже приведена таблица со временем выполнения запросов на GPU при промте в 500 токенов (в среднем). GPUСтоимость ₽/часВремя в vLLM/сек.Время в Ollama/сек.A1002x6,238,23RTX™ 4090 x21,3x6,769,25A5000 x21,3x10,7615,52A30 x2x15,7822,53Tesla® T4 x 41,5x18,2224,31 Исходя из таблицы, наилучший результат показали карты RTX™ 4090 и A100, при этом RTX™ 4090 оказалась выгоднее по стоимости. В итоге клиент арендовал именно эти две GPU. Когда викинг научился подбирать инфраструктуру и оседлал первого дракона. При этом стоит отметить, что у данного способа есть недостатки. Проверка времени выполнения одного конкретного запроса не покроет кейсы продакшен-слоя. Здесь не учитываются RPS, размер батча, изменение контекстного окна и другие параметры. Инференс-фреймворки запускались с дефолтной конфигурацией без дополнительной настройки — это также может повлиять на итоговую производительность инференса. Не учитывалась различная квантизация модели. Уменьшение размерности параметров также могло увеличить производительность при небольшом изменении качества. Заключение В статье мы ознакомились только с базовыми шагами подбора инфраструктуры — сделали первые шаги «викинга-новичка»! Узнали, как правильно рассчитывать требуемую VRAM, подбирать GPU и запускать базовый инференс. В следующей части мы закроем недостатки, описанные выше. Научимся подбирать конфигурацию инференс-сервера с помощью высоконагруженных тестов, познакомимся с видами квантизации модели и автоматизируем наш подбор!