Как подобрать GPU-сервер для инференса LLM

Большинство вопросов о подборе конфигурации для LLM сводятся к одному: поместятся ли в память GPU сама модель и всё, что ей нужно для обслуживания вашего трафика? В этом руководстве мы покажем, как это посчитать, применим расчёты к двум GPU-серверам FlexDedi — GPU L40S с одним NVIDIA L40S 48 ГБ и GPU RTX PRO с двумя NVIDIA RTX PRO 6000 Blackwell 96 ГБ — и приведём команды vLLM для обоих.

Формула расчёта VRAM

VRAM needed ≈ weights + KV cache + runtime overhead

Накладные расходы среды выполнения включают контекст CUDA, активации, графы CUDA и фрагментацию аллокатора; закладывайте на них несколько гигабайт на каждый GPU. vLLM резервирует долю памяти GPU, заданную параметром --gpu-memory-utilization (0,90 в примерах ниже), загружает веса, профилирует память под активации и отдаёт всё оставшееся под KV-кэш.

Планируйте, исходя из объёма, который показывает nvidia-smi: он может быть на несколько гигабайт меньше номинального, поскольку ECC в памяти GDDR резервирует её часть. В качестве рабочего бюджета при коэффициенте 0,90 в этом руководстве используется около 40 ГБ для одного L40S и около 85 ГБ на каждый RTX PRO 6000 — примерно 170 ГБ на оба.

Веса: параметры × байты на параметр

weights (GB) ≈ parameters (billions) × bytes per parameter

INT4 обходится чуть дороже полубайта на параметр, потому что масштабные коэффициенты квантизации, а часто и эмбеддинги и выходной слой, остаются в более высокой точности. Оба GPU поддерживают FP8 аппаратно. Blackwell добавляет тензорные ядра FP4, но они дают выигрыш, только если в вашем стеке инференса есть программные ядра (kernels) FP4 для этого GPU и этой модели. Пониженная точность может снизить качество модели, поэтому перед переходом проверьте квантизованную модель на собственном оценочном наборе данных.

Для моделей со смесью экспертов (MoE) объём памяти определяется общим числом параметров, поскольку в памяти должны находиться все эксперты, а объём вычислений на токен — гораздо меньшим числом активных параметров.

KV-кэш: часть, которая растёт вместе с трафиком

Каждый токен каждой активной последовательности хранит в каждом слое вектор ключа и вектор значения:

KV bytes per token = 2 × layers × KV heads × head dimension × bytes per element
KV cache ≈ KV bytes per token × tokens per sequence × concurrent sequences

Исходные значения возьмите из файла модели config.json: num_hidden_layers, num_key_value_heads и head_dim (или hidden_size, делённое на num_attention_heads). Удерживать эти числа в разумных пределах позволяет механизм grouped-query attention (GQA), в котором KV-голов гораздо меньше, чем голов внимания.

--kv-cache-dtype fp8 вдвое уменьшает кэш, обычно ценой небольшой потери качества, которую стоит проверить на вашем оценочном наборе. vLLM выделяет кэш блоками по мере поступления токенов, поэтому короткие запросы не резервируют весь контекст. И всё же планируйте под худший случай, который вы готовы обслуживать: когда кэш заполнен, новые запросы ждут в очереди.

Пример 1: модель 14B на одном L40S

Обслуживание Qwen/Qwen3-14B-FP8 на GPU L40S, все значения приблизительные:

• Бюджет: около 40 ГБ
• Веса: около 16 ГБ (14,8 млрд параметров по 1 байту плюс слои, оставленные в более высокой точности)
• Накладные расходы: около 3 ГБ
• KV-кэш: 40 − 16 − 3 ≈ 21 ГБ
• Вместимость при 80 КиБ на токен: 21 ГБ ÷ 80 КиБ ≈ 250 000 токенов

Это примерно 7 одновременных последовательностей при полном контексте модели в 32K или около 60 последовательностей по 4K токенов.

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv --python 3.12 --seed && source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels   # optional: fetch prebuilt kernels instead of compiling at startup

vllm serve Qwen/Qwen3-14B-FP8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --max-num-seqs 64 \
  --host 10.0.0.10 --port 8000 \
  --api-key "$VLLM_API_KEY"

Сначала установите актуальный драйвер NVIDIA для дата-центров и убедитесь, что nvidia-smi видит GPU; картам Blackwell, таким как RTX PRO 6000, нужны открытые модули ядра NVIDIA. При запуске vLLM записывает в журнал размер KV-кэша и максимальное число одновременно обслуживаемых запросов для вашего --max-model-len — сравните их со своей оценкой. Привязка --host к частному адресу и параметр --api-key закрывают эндпоинт от публичного интернета и требуют bearer-токен в каждом запросе.

Пример 2: модель 70B на двух RTX PRO 6000

Модели 70B в BF16 нужно около 141 ГБ под веса (70,6 млрд параметров × 2 байта) — больше, чем вмещает один GPU. При тензорном параллелизме каждый GPU хранит половину весов и половину KV-голов:

• Бюджет на GPU: около 85 ГБ
• Веса на GPU: около 70,5 ГБ
• Накладные расходы на GPU: около 3 ГБ
• KV-кэш на GPU: около 11,5 ГБ
• На токен на GPU в FP8: 160 КиБ ÷ 2 = 80 КиБ
• Вместимость: 11,5 ГБ ÷ 80 КиБ ≈ 140 000 токенов — примерно 4 последовательности по 32K или 34 по 4K

Если же взять веса в FP8 (около 70 ГБ, или 35 ГБ на GPU), бюджет KV-кэша вырастает примерно до 47 ГБ на GPU: около 570 000 токенов, или 17 последовательностей по 32K. Именно поэтому для моделей класса 70B на этом сервере стоит рассмотреть чекпойнты в FP8.

export HF_TOKEN=hf_your_token   # Llama weights are gated: accept the license on Hugging Face first
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --host 10.0.0.10 --port 8000 \
  --api-key "$VLLM_API_KEY"

Тензорный параллелизм по PCIe

NVLink у этих GPU нет, поэтому обмен данными между двумя картами RTX PRO 6000 идёт по PCIe 5.0; путь показывает nvidia-smi topo -m. Тензорный параллелизм синхронизирует GPU внутри каждого слоя, поэтому он оправдан, когда модель не помещается на один GPU или когда для большой модели нужна меньшая задержка на запрос.

Если модель помещается на один GPU, лучше запустите по одной реплике на каждый GPU. Тогда между картами нет обмена данными, а vLLM распределяет запросы между обеими:

vllm serve Qwen/Qwen3-14B-FP8 --data-parallel-size 2 --max-model-len 32768 --kv-cache-dtype fp8

Третий вариант для больших моделей — --pipeline-parallel-size 2. Он распределяет между GPU слои, а не тензоры, и передаёт меньше данных, но ценой простоев конвейера (pipeline bubbles), поэтому сравните его с тензорным параллелизмом на собственном трафике.

Что куда помещается

Приблизительная оценка при коэффициенте использования памяти 0,90 и KV-кэше в FP8:

CPU, RAM и NVMe тоже важны

Системная оперативная память. При загрузке веса проходят через память хоста, а страничный кэш Linux хранит недавно загруженные файлы моделей, чтобы при перезапуске не читать их с диска повторно. Распространённое практическое правило — системной RAM должно быть не меньше, чем суммарной VRAM: у GPU L40S 256 ГБ на 48 ГБ VRAM, у GPU RTX PRO — 576 ГБ на 192 ГБ. Остальное используют API-сервер, токенизация, компоненты поиска (retrieval), такие как векторные базы данных и модели эмбеддингов, а также выгрузка KV-кэша в память CPU с помощью инструментов вроде LMCache.

CPU. EPYC 9355P (32 ядра) в GPU L40S и EPYC 9455P (48 ядер) в GPU RTX PRO отвечают за планирование, токенизацию, а также предварительную и последующую обработку. Перегруженный CPU хоста проявляется в виде простоев GPU между шагами, которые можно увидеть с помощью nvidia-smi dmon.

NVMe. Время загрузки ≈ размер модели ÷ устойчивая скорость чтения. Для оценки: 141 ГБ при условных 5 ГБ/с загружаются примерно за 30 секунд. На накопителях Gen5 — 2 × 3,84 ТБ в GPU L40S и 2 × 7,68 ТБ в GPU RTX PRO — можно держать рядом несколько версий моделей; направьте на них кэш Hugging Face командой export HF_HOME=/srv/models.

Пропускная способность: чего ожидать и как измерять

Инференс состоит из двух фаз. Prefill (предзаполнение) обрабатывает промпт параллельно и упирается в вычисления; длинные промпты увеличивают время до первого токена (TTFT). Decode (декодирование) выдаёт по одному токену за шаг для каждой последовательности и при малом размере батча ограничено пропускной способностью памяти, потому что на каждом шаге считываются веса. Это даёт верхнюю границу для одного потока, а не результат измерения:

decode tokens/s per sequence ≤ memory bandwidth ÷ bytes read per token (≈ weight bytes)

Например, модель 14B в FP8 (около 16 ГБ) на L40S с пропускной способностью памяти 864 ГБ/с не может превысить примерно 54 токена/с для одного потока, а на практике цифры ниже. Для RTX PRO 6000 Blackwell Server Edition NVIDIA указывает около 1,6 ТБ/с.

Батчинг меняет картину. На каждом шаге декодирования веса считываются один раз сразу для всех последовательностей в батче, поэтому суммарная пропускная способность растёт с числом одновременных запросов, пока не закончатся вычислительные ресурсы или KV-кэш, а скорость в токенах в секунду для каждого пользователя при этом падает. Непрерывный батчинг (continuous batching) в vLLM делает это автоматически; ваша задача — выбрать компромисс между общей пропускной способностью и временем на выходной токен (TPOT), приемлемый для вашего продукта. Измерьте его на собственных длинах промптов:

export OPENAI_API_KEY="$VLLM_API_KEY"   # sent as the bearer token
vllm bench serve --backend vllm --model Qwen/Qwen3-14B-FP8 \
  --base-url http://10.0.0.10:8000 \
  --dataset-name random --random-input-len 1024 --random-output-len 256 \
  --num-prompts 200 --max-concurrency 16 \
  --percentile-metrics ttft,tpot --metric-percentiles 95,99

Повторите тест для нескольких значений --max-concurrency и выберите наибольшее, при котором ещё выполняются ваши целевые показатели задержки p95 и p99.

GPU L40S или GPU RTX PRO

Выбирайте GPU L40S ($979/мес.), если:

• ваши модели — примерно до 14B параметров в BF16 или FP8 либо около 30B в INT4;
• вы запускаете эмбеддинги, реранкеры, распознавание речи или генерацию изображений рядом с чат-моделью среднего размера;
• вы предпочитаете горизонтально масштабироваться на несколько серверов поменьше или вам нужна локация в Далласе, а не только в Ашберне, Амстердаме или Франкфурте.

Выбирайте GPU RTX PRO ($2 199/мес.), если:

• вы обслуживаете плотные модели класса 70B, крупные MoE-модели или длинные контексты для множества одновременных пользователей;
• вам нужны две модели рядом, по одной на GPU;
• помимо инференса вы дообучаете модели с LoRA или QLoRA — здесь пригодятся 192 ГБ VRAM;
• вы хотите, чтобы аппаратная поддержка FP4 уже была в наличии, когда её освоит ваш стек инференса.

В пересчёте на гигабайт VRAM сервер RTX PRO дешевле: около $11,45 за гигабайт в месяц против примерно $20,40 у сервера L40S.

Запуск на FlexDedi

Для моделей примерно до 14B параметров начните с GPU L40S ($979/мес.), а для моделей класса 70B, крупных MoE-моделей или трафика с длинным контекстом — с GPU RTX PRO ($2 199/мес.). У обоих — порты 25 Гбит/с с безлимитным трафиком и NVMe Gen5, оба собираются под заказ и обычно выдаются в тот же день. Разместите серверы приложений рядом, в бесплатной частной сети, чтобы API инференса никогда не был доступен из интернета, и примените ко всем хостам базовую конфигурацию безопасности Linux. Подробнее — на странице «AI-инференс и ML».