Привет, Хабр! Меня зовут Антон, и сейчас я активно занимаюсь вопросами инфраструктуры для ML и AI. Когда клиент приходит с запросом в духе «Разверните мне Qwen», невольно задаешься вопросом: «А какая инфраструктура нужна для такой задачи?» Но если запрос становится более конкретным, например, «Разверните Qwen так, чтобы держать 10 RPS с задержкой до пяти секунд», то можно и вовсе растеряться. Как подобрать конфигурацию под такие требования?

В серии статей разберемся, как отвечать на такие вопросы. Рассмотрим, какие инструменты помогают быстро подобрать оптимальную инфраструктуру, как тестировать производительность инференса и автоматизировать процесс. Посмотрим, как пройти путь от ручных запусков примеров моделей до автоматизированного анализа работы фреймворков на GPU с подбором оптимальной конфигурации.

А еще в последнее время мне нравится тематика викингов и драконов (особенно та часть, которая связана с медовухой). Вместе мы напишем книгу по приручению самых разнообразных драконов или, как в простонародье, open source LLM. В ней рассмотрим разные типы драконов, какие «GPU-седла» подходят под каждого и какие инструменты использовать для приручения. Садитесь поудобнее, заваривайте что-нибудь крепкое и айда в уникальное путешествие на дракаре в волшебную долину драконов!

Selectel Tech Day — 8 октября

Разберем реальный опыт IT-команд, технический бэкстейдж и ML без спецэффектов. 15 стендов и интерактивных зон, доклады, мастер-классы, вечерняя программа и нетворкинг. Участие бесплатное: нужна только регистрация.

Зарегистрироваться →

Из System Design в подбор инфраструктуры для инференса

Как происходит подбор инфраструктуры для обычных веб-приложений? Например, сайта с продажей плюшевых тирексов-викингов, агрегатора такси-дракаров или почтово-голубиного мессенджера? Обратимся к стандартным практикам System Design. 

После сбора первичных требований к системе очень важно оценить необходимую инфраструктуру для развертывания и поддержки системы, а также стоимость всего оборудования и процессов. От точности расчетов будет зависеть успех проекта и его жизнеспособность, а самое главное — хватит ли у заказчика материальных ресурсов, чтобы воплотить все сформулированные пожелания и требования к системе. Оценка позволит скорректировать ожидания от продукта.

Рассмотрим основные метрики расчета.

• Пользовательский трафик. Рассчитываем RPS (requests per seconds) относительно заданного MAU (monthly active users). 

• Сетевой трафик и соединения. В облаке уже доступно 1 Гбит/с. Современный сервер может выдержать наплыв в 10 000–100 000 соединений.

• Нагрузка на вычислительную мощность. Исходя из RPS, высчитываем количество станций для обработки трафика.

• Необходимое дисковое пространство для хранения данных и расчет потенциального прироста объема хранилища. Считаем, на сколько пополняется база данных в среднем, и прикидываем на определенное количество лет необходимую емкость. Также учитываем требования по скорости — где подойдет дешевый HDD, а где стоит использовать SSD или даже оперативную память.

Помимо прочего, важно помнить о праве на ошибку. Если платформу разворачивать в облаке, то к уже развернутой инфраструктуре достаточно просто добавить сотни гигабайт дискового пространства, десятки гигабайт оперативной памяти и CPU. Все достаточно гибко и всегда можно увеличить/уменьшить относительно реального трафика. Но можно ли так же сделать с инференсом LLM?

Для приручения наших драконов-инференсов необходимы «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.

1. Модель на HuggingFace (Qwen, Llama, deepseek).

2. Квантизация модели (32 bit, 16 bit, 4 bit).

3. GPU.

4. Инференс-фреймворк.

5. Конфигурация инференса.

6. Автоматизация подбора.

В этой части цикла мы поговорим про GPU и инференс-фреймворки, в следующей — разберем квантизацию моделей, конфигурацию инференс-серверов и автоматизацию подбора инфраструктуры.

Начнем с реального кейса, где требовался подбор инфраструктуры для Qwen на 32 млрд параметров. Основная задача — анализ транскрибированных аудиозаписей диалога официанта и клиента, где модель по заданному промту оценивала качество работы сотрудника. 

Модель выбрана — 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.

Где:

• N_params— число параметров модели;

• Bytes_{per_param} — размерность precision.

FP16 / BF16 → 2 байта на параметр, INT8 → 1 байт, INT4 → 0,5 байта.

Пример: Qwen-7B в FP16 ≈ 14 ГБ VRAM только под веса.

Выбор размерности задает каркас для выбора квантизации, однако мы пока не принимаем во внимание методы квантизации — о них поговорим в следующей части.

Активации

Активации — это промежуточные результаты работы слоев. Их объем зависит от 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 можно в материалах «How To Calculate GPU VRAM Requirements for an Large-Language Model» и «​​Mastering LLM Techniques: Inference Optimization». Еще один полезный ресурс —  онлайн-калькулятор подсчета VRAM для LLM.

Распишем требуемые VRAM для Qwen32b, используя формулы для количества параметров и KV-кеша.

Возьмем для примера квантизацию 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.

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 и скопировать несколько строк кода, чтобы загрузить модель и получить ответ:

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Qwen/Qwen3-32B"

# load the tokenizer and the model
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto"
)

# prepare the model input
prompt = "Give me a short introduction to large language model."
messages = [
    {"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=True # Switches between thinking and non-thinking modes. Default is True.
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

# conduct text completion
generated_ids = model.generate(
    **model_inputs,
    max_new_tokens=32768
)
output_ids = generated_ids[0][len(model_inputs.input_ids[0]):].tolist() 

# parsing thinking content
try:
    # rindex finding 151668 (</think>)
    index = len(output_ids) - output_ids[::-1].index(151668)
except ValueError:
    index = 0

thinking_content = tokenizer.decode(output_ids[:index], skip_special_tokens=True).strip("\n")
content = tokenizer.decode(output_ids[index:], skip_special_tokens=True).strip("\n")

print("thinking content:", thinking_content)
print("content:", content)

Это достаточно простой способ запуска, однако он подходит только для прототипирования и тестов, а не для продакшен-нагрузки. Чтобы получить производительность и гибкость, используют оптимизированные инференс-движки. Ниже — сравнение популярных решений.

Для ранее описанного кейса мы рассчитали характеристики на двух фреймворках: Ollama и VLLM. Первые тесты были достаточно простыми: Python-скрипт измерял время отправки запроса с промтом до инференс-сервера на разных GPU. Ниже приведена таблица со временем выполнения запросов на GPU при промте в 500 токенов (в среднем).

Исходя из таблицы, наилучший результат показали карты RTX™ 4090 и A100, при этом RTX™ 4090 оказалась выгоднее по стоимости. В итоге клиент арендовал именно эти две GPU.

При этом стоит отметить, что у данного способа есть недостатки.

• Проверка времени выполнения одного конкретного запроса не покроет кейсы продакшен-слоя. Здесь не учитываются RPS, размер батча, изменение контекстного окна и другие параметры.

• Инференс-фреймворки запускались с дефолтной конфигурацией без дополнительной настройки — это также может повлиять на итоговую производительность инференса.

• Не учитывалась различная квантизация модели. Уменьшение размерности параметров также могло увеличить производительность при небольшом изменении качества.

Заключение

В статье мы ознакомились только с базовыми шагами подбора инфраструктуры — сделали первые шаги «викинга-новичка»! Узнали, как правильно рассчитывать требуемую VRAM, подбирать GPU и запускать базовый инференс.

В следующей части мы закроем недостатки, описанные выше. Научимся подбирать конфигурацию инференс-сервера с помощью высоконагруженных тестов, познакомимся с видами квантизации модели и автоматизируем наш подбор!

Облачные серверы с GPU

Используйте облачные серверы Selectel с  видеокартами для машинного обучения, аналитики и работы с графикой.

Подробнее →