Лучший GPU для инференса LLM в 2026 году: подбор по размеру модели

Лучший GPU для инференса LLM (больших языковых моделей) — самый недорогой из тех, что вмещают веса вашей модели в той точности, в которой вы её обслуживаете, оставляют место для KV-кэша, нужного вашему трафику, и дают достаточную пропускную способность памяти, чтобы уложиться в целевую задержку. Вычислительная мощность тоже важна, но в списке приоритетов она стоит ниже, чем можно подумать, глядя на большинство спецификаций. В этом руководстве мы пройдём эти проверки по порядку, а затем сопоставим распространённые размеры моделей с GPU из нашего каталога — от одного RTX 5090 до 8-GPU-серверов.

Как выбрать лучший GPU для инференса LLM

Принимайте решения в таком порядке. Каждый шаг сужает список для следующего.

1. Точность. BF16, FP8 или 4 бита: от неё зависит, сколько байт приходится на параметр.
2. Веса. Они должны поместиться, причём с запасом.
3. KV-кэш. Длина контекста × число одновременных последовательностей; часто именно он решает выбор между двумя GPU-кандидатами.
4. Пропускная способность памяти. Она задаёт скорость декодирования (decode).
5. Вычислительная мощность. Она важна для длинных промптов и больших батчей.
6. Интерконнект. Только если модели нужно больше одного GPU.
7. Цена. В месяц, за гигабайт и за единицу пропускной способности.

Шаг 1: размер модели и точность задают минимальный объём памяти

Веса занимают примерно число параметров × число байт на параметр: 2 байта в BF16 или FP16, 1 байт в FP8 или INT8 и около полубайта в 4-битных форматах (чуть больше с учётом масштабов блоков). Поэтому модели 70B нужно около 140 ГБ в BF16, 70 ГБ в FP8 и 35–40 ГБ в 4-битном формате. Сверху заложите 10–30% на KV-кэш, активации и среду выполнения.

Точность — это решение о качестве в той же мере, что и о памяти. FP8 широко используется для инференса: он вдвое сокращает объём памяти, а потери качества часто невелики; 4-битные форматы экономят ещё больше, но требуют тщательной проверки на ваших собственных задачах. Компромиссы разобраны в нашей статье о сравнении FP8, FP4 и BF16, а калькулятор видеопамяти (VRAM) посчитает всё для конкретной модели.

Шаг 2: KV-кэш и число одновременных запросов

Для каждого токена в каждой активной последовательности модель хранит в каждом слое вектор ключа и вектор значения. Размер на один токен:

KV bytes per token = 2 × layers × KV heads × head dimension × bytes per value

Возьмём модель класса 70B с механизмом grouped-query attention: 80 слоёв, 8 KV-голов размерностью 128, кэш в BF16. Получается 2 × 80 × 8 × 128 × 2 = 327 680 байт, около 0,33 МБ на токен.

Теперь сопоставим это с весами. На одном H200 с весами в FP8 (около 70 ГБ) после накладных расходов среды выполнения на кэш остаётся примерно 50–60 ГБ: это около 20 одновременных последовательностей по 8K токенов с кэшем в BF16 или около 40 — с кэшем в FP8. На одном H100 те же веса оставляют лишь несколько гигабайт — хватит на считанные короткие запросы. Оба GPU «запускают модель», но только один из них комфортно обслуживает реальный трафик. Движки вроде vLLM выделяют кэш страницами по мере поступления токенов, поэтому средняя длина важнее максимальной, а свой объём KV-кэша они сообщают при запуске.

Шаг 3: почему скорость декодирования зависит от пропускной способности памяти

У инференса две фазы. На этапе prefill весь промпт обрабатывается сразу: это крупные матричные умножения, ограниченные в основном вычислительной мощностью. Затем на этапе декодирования модель генерирует по одному токену на последовательность за шаг, и на каждом шаге из памяти нужно считать все активные веса, а также KV-кэш каждой последовательности, чтобы выполнить примерно две операции с плавающей запятой на каждый вес для каждой последовательности. При малых и умеренных размерах батча вычислительные блоки заканчивают работу задолго до того, как придут следующие байты. Поэтому скорость декодирования одной последовательности ограничена байтами в секунду, а не FLOPS.

Отсюда четыре следствия:

• Соотношение пропускных способностей ограничивает выигрыш в декодировании. При одинаковом размере батча декодирование на H200 (4,8 ТБ/с) может быть быстрее, чем на H100 (3,35 ТБ/с), не более чем примерно в 1,4 раза, а на B200, B300 или MI355X (8 ТБ/с) — примерно в 2,4 раза. Больший объём памяти даёт дополнительный выигрыш, позволяя увеличивать батчи.
• Пониженная точность помогает дважды. Веса в FP8 вдвое сокращают не только занимаемую память, но и число байт, считываемых на каждом шаге, поэтому в режиме, ограниченном памятью, декодирование ускоряется.
• Батчинг распределяет затраты на чтение весов. Один проход по весам обслуживает все последовательности в батче, поэтому производительность растёт с размером батча, пока не упрётся в вычислительную мощность или объём KV-кэша. Вот почему свободная память под кэш напрямую превращается в производительность.
• MoE-модели (mixture of experts) читают меньше данных на токен. Для каждого токена считываются только выбранные эксперты, поэтому декодирование обходится дешевле, чем у плотной модели того же общего размера, но все эксперты всё равно должны помещаться в памяти.

Какой GPU для какого размера модели: наши рекомендации

В таблице распространённые размеры моделей сопоставлены с GPU из нашего каталога. Вариант в столбце «Рекомендуем» оставляет место для KV-кэша полезного объёма при умеренной длине контекста; в столбце «Тоже подойдёт» — варианты, где места меньше, скорость ниже или ресурсов больше, чем нужно. Если не указано иное, размеры даны для плотных моделей.

Выделяются две закономерности. RTX PRO 6000 закрывает широкий диапазон: в 96 ГБ помещается всё примерно до 32B в BF16 или до 70B в FP8. А в нашем каталоге шаг от одного GPU к восьми — большой: между одним B300 (288 ГБ) и 8-GPU-сервером ничего нет, поэтому моделям с весами примерно от 250 до 600 ГБ сразу нужен целый сервер. Самый крупный случай подробно разобран в нашем руководстве по системным требованиям DeepSeek R1.

Стоимость гигабайта видеопамяти в месяц

Когда понятно, сколько нужно памяти, сравните цену за гигабайт. Пропускной способности место в той же таблице: самая дешёвая память обычно самая медленная.

Как читать таблицу:

• Цена за гигабайт важнее всего, когда модель едва помещается. Если вы платите за объём, чтобы разместить веса и кэш, выделяются сервер 8× MI355X (8,64 $ за гигабайт, если ваш стек работает на ROCm) и конфигурации с RTX PRO 6000 (около 14 $).
• Пропускная способность важна, когда модель помещается свободно. Модель 32B помещается и на RTX PRO 6000, и на H100; на H100 гигабайт дороже, зато веса считываются примерно вдвое быстрее.
• В пересчёте на гигабайт один B300 дешевле B200. У него на 60% больше памяти, а стоит он в месяц примерно на 13% дороже, при этом пропускная способность того же класса — 8 ТБ/с. B300 мало в наличии.
• Восемь GPU в одном сервере стоят немного меньше, чем восемь тарифов с одним GPU (8× H100 — 16 900 $ против 8 × 2 190 $ = 17 520 $), но вы берёте все восемь сразу.

Когда использовать 8 GPU с тензорным параллелизмом

Тензорный параллелизм делит матрицы весов каждого слоя между GPU. На каждом шаге декодирования каждый GPU считывает только свою часть весов, поэтому восемь GPU дают каждому токену в восемь раз больше пропускной способности памяти — а также в восемь раз больше самой памяти. Платить за это приходится обменом данными: две операции all-reduce на каждый слой трансформера на каждом шаге, поэтому тензорному параллелизму место на GPU, соединённых через NVLink. Наши серверы HGX дают 900 ГБ/с на GPU для H100 и H200 (NVLink 4) и 1,8 ТБ/с для B200 и B300 (NVLink 5). В сервере 8× RTX PRO 6000 GPU соединены через PCIe Gen5 без NVLink, поэтому там лучше использовать независимые реплики или конвейерный параллелизм. Этот трафик подробно разобран в нашей статье о сравнении NVLink и PCIe.

Используйте тензорный параллелизм, когда веса вместе с нужным вам KV-кэшем не помещаются на один GPU или когда для большой модели нужна меньшая задержка на запрос, чем способен дать один GPU. В остальных случаях выбирайте минимальную степень тензорного параллелизма, при которой модель помещается, а производительность наращивайте репликами. Модель 70B в FP8 на сервере 8× H200 можно запустить как восемь реплик по одному GPU, как четыре реплики по два GPU, где на каждую реплику приходится больше кэша, или как одну реплику на восемь GPU — обычно она даёт минимальную задержку на запрос. Измерьте все три варианта на своём трафике.

# Two replicas of four GPUs each on one 8-GPU server (vLLM)
CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve <model> \
  --tensor-parallel-size 4 --port 8000
CUDA_VISIBLE_DEVICES=4,5,6,7 vllm serve <model> \
  --tensor-parallel-size 4 --port 8001

Коротко: что выбрать

• Прототипирование, небольшие модели и эмбеддинги: RTX 5090 или L40S.
• Продакшен примерно до 32B или 70B в FP8 при ограниченном бюджете: RTX PRO 6000.
• 70B в FP8 с запасом для длинных контекстов: H200.
• 70B в BF16 или модели класса 120B в FP8: B200 или B300. Из одиночных GPU только B300 вмещает модель 405B с 4-битными весами.
• Плотные модели 405B или MoE-модели 671B: 8× H200, 8× B200, 8× B300 или 8× MI355X.
• Много реплик моделей среднего размера: 8× RTX PRO 6000.

Во всех конфигурациях выше — целые выделенные GPU по фиксированной цене в месяц. Если ваш случай оказался между двумя строками, проверьте свою модель, точность и ожидаемый трафик в калькуляторе видеопамяти, а затем разверните подходящую конфигурацию; цена в месяц показывается до оплаты, а сервер выдаётся менее чем за 10 минут после оплаты. О том, как организовать сам инференс, — в нашем руководстве по самостоятельному развёртыванию инференса LLM с vLLM.

Часто задаваемые вопросы

Какой GPU лучше всего подходит для инференса LLM в 2026 году?

Самый недорогой GPU, на котором помещаются веса вместе с KV-кэшем и пропускной способности которого хватает для целевой задержки. Для ориентира: RTX PRO 6000 подходит для моделей примерно до 32B, H200 с запасом обслуживает 70B в FP8, B200 или B300 справляются с 70B в BF16, а 8-GPU-серверы закрывают модели класса 405B и 671B.

Сколько видеопамяти нужно для запуска модели 70B?

Около 140 ГБ под веса в BF16 или около 70 ГБ в FP8, плюс KV-кэш и запас 10–30%. В FP8 это значит один H100 впритык или один H200 с запасом.

Правда ли, что для инференса пропускная способность памяти важнее вычислительной мощности?

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

Нужен ли NVLink, чтобы обслуживать модель на нескольких GPU?

Строго говоря, нет, но при тензорном параллелизме данные передаются на каждом слое, поэтому лучше всего он работает через NVLink. Без NVLink лучше выбрать конвейерный параллелизм или независимые реплики модели, которая помещается на один GPU.

Что выбрать для инференса: FP8 или BF16?

FP8 вдвое сокращает по сравнению с BF16 память под веса и объём данных, считываемых на каждый токен, а потери качества часто невелики, но проверьте это на собственном наборе данных для оценки. Hopper, Ada Lovelace, Blackwell и MI355X поддерживают FP8 аппаратно.