Сколько VRAM нужно для инференса LLM: от 8B до 70B

Таблицы требований к железу обычно заканчиваются на размере весов: 8B в четырёх битах — 5 ГБ, 70B — 40 ГБ, подбирайте карту. По этой логике 70B должна работать на RTX A6000 с её 48 ГБ.

Она и работает — ровно до второго одновременного запроса. Дальше vLLM начинает вытеснять последовательности из кеша и пересчитывать их заново, а под нагрузкой отдаёт CUDA out of memory.

Причина в том, что веса — только нижняя граница. Вторая половина расхода приходится на KV-кеш, и она зависит не от модели, а от того, сколько токенов вы держите в работе одновременно. Ниже — формула, реальные цифры по 8B, 32B и 70B и расчёт того, сколько запросов помещается в карту после загрузки модели.

Веса: нижняя граница

Начнём с константы. Размеры взяты из репозиториев Hugging Face и манифестов реестра Ollama, снятых 19 августа 2026 года:

Формат	Llama 3.1 8B	Llama 3.3 70B	Байт на параметр
bf16	16.06 ГБ	141.11 ГБ	2
FP8	9.08 ГБ	72.67 ГБ	1
INT4 (W4A16)	5.74 ГБ	39.53 ГБ	0.5
AWQ 4-bit	—	39.77 ГБ	0.5
GGUF Q4 (Ollama)	4.92 ГБ	42.52 ГБ	0.5

Источники: unsloth/Meta-Llama-3.1-8B-Instruct и unsloth/Llama-3.3-70B-Instruct для bf16, RedHatAI для квантованных сборок — FP8-dynamic и w4a16 для 70B, FP8-dynamic и w4a16 для 8B, casperhansen/llama-3.3-70b-instruct-awq для AWQ, теги llama3.1:8b и llama3.3:70b из реестра Ollama для GGUF.

Байт на параметр здесь ведёт себя ровно так, как ожидается: 8.03 млрд параметров × 2 байта = 16.06 ГБ, 70.55 млрд × 2 = 141.11 ГБ. Никакого запаса на состояния оптимизатора и градиенты, в отличие от обучения, где на параметр уходит 18 байт — разбор этой арифметики есть в справочнике по VRAM для обучения.

На этом простая часть заканчивается.

KV-кеш: переменная, которой нет в таблицах весов

При генерации каждого следующего токена модель обращается к ключам и значениям всех предыдущих. Пересчитывать их на каждом шаге — квадратичная работа, поэтому они сохраняются. Это и есть KV-кеш.

Его размер считается точно:

KV-кеш = 2 × слои × KV-головы × размер головы × байт на элемент × токены × запросы

Двойка — это отдельно ключи и отдельно значения. Остальное берётся из config.json модели.

Ключевой параметр здесь — num_key_value_heads, а не num_attention_heads. Обе модели Llama используют grouped-query attention: несколько голов внимания делят один набор ключей и значений. Метод описан в статье «GQA: Training Generalized Multi-Query Transformer Models», и его смысл именно в сокращении кеша.

Насколько именно — видно из конфигураций:

Модель	Слои	Головы внимания	KV-головы	Сокращение кеша
Llama 3.1 8B	32	32	8	в 4 раза
Qwen3-32B	64	64	8	в 8 раз
Llama 3.3 70B	80	64	8	в 8 раз

Без GQA кеш 70B был бы в восемь раз больше, и модель на 128k контекста требовала бы под него больше 300 ГБ.

Подставим числа для Llama 3.3 70B в fp16: 2 × 80 × 8 × 128 × 2 = 327 680 байт на токен. Для 8B при 32 слоях — 131 072 байта.

Сколько это в гигабайтах

Расход на одну последовательность, кеш в fp16:

Модель	На токен	4k контекст	8k	32k	128k
Llama 3.1 8B	131 КБ	0.54 ГБ	1.07 ГБ	4.29 ГБ	17.18 ГБ
Qwen3-32B	262 КБ	1.07 ГБ	2.15 ГБ	8.59 ГБ	—
Llama 3.3 70B	328 КБ	1.34 ГБ	2.68 ГБ	10.74 ГБ	42.95 ГБ

Прочерк у Qwen3-32B стоит потому, что max_position_embeddings у неё равен 40960 — 128k контекста модель не поддерживает.

Цифра в правом нижнем углу — главный вывод раздела. На полном контексте 128k KV-кеш Llama 3.3 70B занимает 42.95 ГБ, то есть больше, чем сама модель в четырёх битах. Требование к карте определяется уже не весами.

Батч: почему кеш решает, сколько запросов вы обслужите

Формула умножается на число одновременных последовательностей. Отсюда практический расчёт: сколько остаётся на кеш после загрузки весов.

vLLM резервирует под свой пул фиксированную долю памяти карты. Параметр --gpu-memory-utilization по умолчанию равен 0.92, то есть на карте 48 ГБ движку доступно 44.16 ГБ. Из них вычитаются веса, остаток уходит под KV-кеш.

Карта и модель	Веса	Остаток под кеш	Токенов в пуле	Запросов по 8k
24 ГБ, 8B в bf16	16.06 ГБ	6.02 ГБ	~45 900	5
48 ГБ, 8B в bf16	16.06 ГБ	28.10 ГБ	~214 000	26
48 ГБ, 70B в INT4	39.53 ГБ	4.63 ГБ	~14 100	1
80 ГБ, 70B в INT4	39.53 ГБ	34.07 ГБ	~104 000	12
80 ГБ, 70B в FP8	72.67 ГБ	0.93 ГБ	~2 800	0
96 ГБ, 70B в FP8	72.67 ГБ	15.65 ГБ	~47 700	5

Расчёт по формуле выше при --gpu-memory-utilization 0.92 и кеше в fp16. Это верхняя граница: часть остатка забирают активации и графы CUDA, поэтому фактический пул меньше на несколько процентов. Проверяется он строкой в логе запуска vLLM, где движок печатает размер выделенного KV-кеша.

Три строки здесь стоит прочитать внимательно.

70B в четырёх битах на карте 48 ГБ оставляет 4.63 ГБ под кеш. Хватает на один запрос с контекстом 8k, второй уже вытесняется. В документации vLLM по оптимизации это состояние описано предупреждением Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space. Модель работает, но каждый вытесненный запрос считается заново.

70B в FP8 на карте 80 ГБ не запускается осмысленно. Веса 72.67 ГБ против доступных 73.6 ГБ — под кеш остаётся меньше гигабайта. Формально влезает, практически нет.

8B в bf16 на карте 48 ГБ обслуживает 26 запросов по 8k. Это тот случай, когда лишняя память конвертируется не в возможность запустить модель, а прямо в пропускную способность. Именно ради этого в vLLM сделан пул страниц: подход описан в статье «Efficient Memory Management for Large Language Model Serving with PagedAttention», где заявлен рост пропускной способности в 2–4 раза при той же задержке за счёт устранения потерь памяти в кеше.

Как ужать KV-кеш

Приёмы от самых дешёвых по последствиям к самым заметным.

Ограничить длину контекста

Самый прямой рычаг. Llama 3.1 и 3.3 объявляют max_position_embeddings равным 131072, и vLLM по умолчанию берёт эту величину из конфига модели. Если реальные запросы укладываются в 8k, длину нужно задать явно:

vllm serve meta-llama/Llama-3.3-70B-Instruct 
  --max-model-len 8192 
  --max-num-seqs 16

--max-num-seqs ограничивает число последовательностей в одной итерации. Оба параметра документация vLLM называет основным способом снизить требования к кешу.

Перевести кеш в FP8

Кеш квантуется отдельно от весов и вдвое сокращает расход на токен: у 70B это 328 КБ против 164 КБ.

vllm serve meta-llama/Llama-3.3-70B-Instruct --kv-cache-dtype fp8

Допустимые значения kv_cache_dtype — auto, fp8, fp8_e4m3 и fp8_e5m2; последние два требуют CUDA 11.8 или новее (документация vLLM по квантованию KV-кеша). Пересчитайте таблицу выше с делением на два: 70B в INT4 на карте 48 ГБ получает уже около трёх запросов по 8k вместо одного.

Квантовать веса, а не докупать память

Разница между FP8 и INT4 для 70B — 72.67 против 39.53 ГБ, то есть 33 ГБ, которые целиком уходят в кеш. На карте 80 ГБ это переход от нуля работающих запросов к двенадцати.

Разнести модель по картам

Тензорный параллелизм делит и веса, и кеш между GPU. Параметр --tensor-parallel-size по умолчанию равен 1:

vllm serve meta-llama/Llama-3.3-70B-Instruct --tensor-parallel-size 2

Для 70B в bf16 это штатный путь. Одиночная карта под неё начинается со 180 ГБ: на H200 со 141 ГБ движку доступно 129.7 ГБ, а веса занимают 141.11 ГБ.

Какая карта под какую модель

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

VRAM	Карты в каталоге	Что обслуживает с рабочим батчем
16 ГБ	RTX A4000, V100 16GB	8B в INT4 с контекстом до 32k
24 ГБ	A30, RTX A5000	8B в bf16, около 5 запросов по 8k
32–40 ГБ	RTX PRO 4500, V100 32GB, A100 40GB	32B в INT4, 8B в bf16 с длинным контекстом
48 ГБ	RTX A6000, RTX 6000 Ada, L40, L40S	8B в bf16 под нагрузкой; 70B в INT4 только с кешом FP8
80–96 ГБ	A100 80GB, H100 80GB, RTX PRO 6000	70B в INT4 с батчем; FP8 начиная с 96 ГБ
141 ГБ	H200 141GB	70B в FP8 с длинным контекстом
180 ГБ и выше	B200, B300, GB300	70B в bf16 на одной карте

Отдельно про 70B в bf16. На H200 со 141 ГБ она не запускается: движку при коэффициенте 0.92 доступно 129.7 ГБ против 141.11 ГБ весов. Одиночная карта начинается с B200 на 180 ГБ — там после весов остаётся 24.5 ГБ под кеш, около девяти запросов по 8k. Дешевле обычно другое: две карты по 80 ГБ с --tensor-parallel-size 2.

Цены зависят от провайдера и двигаются в течение суток, поэтому приводим их отдельно и с датой. Минимальные предложения за один GPU на 19 августа 2026 года: A30 — 52.68 ₽/час, RTX A6000 — 82.79 ₽/час, RTX 6000 Ada — 118.92 ₽/час, L40 — 129.45 ₽/час, L40S — 132.46 ₽/час, RTX PRO 4500 — 138.49 ₽/час, A100 80GB — 197.41 ₽/час, RTX PRO 6000 — 329.66 ₽/час, H100 80GB — 365.57 ₽/час.

Практическая сторона запуска разобрана отдельно: vLLM и Ollama на примере DeepSeek-R1 и Llama 3 через Ollama в Docker. Выбор между покупкой карты и арендой — в расчёте TCO.

Чек-лист при OOM на инференсе

Порядок от самого дешёвого к самому затратному:

1. Задайте --max-model-len под реальные запросы. Модель с окном 131072 резервирует пул под это окно, даже если промпты укладываются в 4k.
2. Снизьте --max-num-seqs. Меньше одновременных последовательностей — меньше страниц в пуле.
3. Включите --kv-cache-dtype fp8. Расход на токен падает вдвое, качество ответов страдает заметно меньше, чем при квантовании весов.
4. Проверьте --gpu-memory-utilization. Значение по умолчанию 0.92; поднимать его выше стоит только на карте, где кроме vLLM ничего не запущено.
5. Перейдите с FP8 на INT4 по весам. Для 70B это освобождает 33 ГБ.
6. Добавьте --tensor-parallel-size, если карт несколько.
7. Проверьте лог запуска. vLLM печатает фактический размер выделенного KV-кеша — это единственная цифра, которая не зависит от прикидок.

Что в итоге

Вопрос «сколько VRAM нужно для инференса» не имеет ответа без второго вопроса — какой контекст и сколько параллельных запросов. Веса 70B в четырёх битах занимают 39.5 ГБ и не меняются. KV-кеш к ним добавляет от 1.34 ГБ на один короткий запрос до 42.95 ГБ на один полный контекст 128k.

Практические ориентиры: для 8B в bf16 под нагрузкой берите 48 ГБ, для 70B в INT4 с реальным батчем — 80 ГБ, для 70B в FP8 — 96 ГБ и выше. Для 70B в bf16 — либо две карты по 80 ГБ, либо одна от 180 ГБ.

Проверять это дешевле на арендованной карте: пул KV-кеша печатается в логе при первом же запуске, и станет видно, укладывается ли ваш профиль нагрузки в выбранный объём. Зеркальный расчёт для обучения — в справочнике по VRAM для дообучения, а для генерации изображений — в разборе Stable Diffusion, SDXL и Flux.