VRAM-калькуляторы LLM занижают память до 11 раз: почему формулы не совпадают с реальностью

Автор открытого инструмента ridgepoint протестировал калькуляторы VRAM для LLM из первой страницы поисковой выдачи и сопоставил их результаты с реальными замерами на живом сервере vLLM. Вывод: все инструменты промахиваются по одной и той же причине. Ни один не моделирует механизм предварительного резервирования памяти, который используют современные движки инференса (исполнения модели на GPU). А для моделей с нестандартной архитектурой внимания, вроде DeepSeek-V2-Lite, ошибка вырастает до порядка.

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

Когда вы запускаете, скажем, vLLM с моделью Llama-3-8B, кажется логичным: движок загрузит веса модели, а остаток VRAM раздаст под KV-кеш (кеш ключей и значений, в котором модель хранит контекст диалога) по мере поступления запросов. Но ни один современный движок так не работает.

vLLM при старте резервирует фиксированную долю всей видеопамяти под единый пул. По умолчанию это 92% VRAM (параметр gpu_memory_utilization). Внутрь этого куска ложатся и веса, и KV-кеш. Оставшиеся 8% VRAM под кеш не попадут никогда.

Механизм называется PagedAttention и описан в открытой статье (arXiv:2309.06180). У SGLang аналогичный параметр называется mem_fraction_static, у TensorRT-LLM он же kv_cache_free_gpu_mem_fraction. Принцип один: память выделяется заранее, одним блоком.

Реальная ёмкость KV-пула считается так: доля утилизации, умноженная на полный объём VRAM, минус веса модели, минус накладные расходы. Ни один из проверенных калькуляторов эту поправку не делает.

Пример на Llama-3-8B: откуда берётся расхождение?

На одной карте A100 с контекстом 8 192 токена наивная формула без поправки на утилизацию обещает около 60 одновременных запросов. С учётом реального резервирования получается 54. Живой замер vLLM показал 55. Разница между «наивным» и реальным значением невелика для одной модели, но масштабируется с размером: на кластере из нескольких карт вы переплатите за целый лишний узел.

Вторая ловушка: геометрия KV-кеша завышает требования в 7-11 раз

Здесь ошибки калькуляторов становятся катастрофическими. У стандартной модели с GQA-вниманием (Grouped Query Attention, способ организации «голов» внимания, при котором несколько голов делят общие ключи) формула расчёта байт на токен хорошо известна: 2 * n_kv * head_dim * L * p.

У моделей семейства DeepSeek с архитектурой MLA (Multi-head Latent Attention, механизм, при котором ключи и значения сжимаются в компактное скрытое представление) формула совсем другая: (d_c + d_rope) * L * p, где d_c это размерность сжатого представления, а d_rope это часть, отвечающая за позиционное кодирование.

Для DeepSeek-V2-Lite разница выглядит так:

• MLA (правильная формула): (512 + 64) * 27 * 2 = 31 104 байт на токен
• Наивная формула с head_dim=128: 221 184 байт на токен, завышение в 7,1 раза
• Наивная формула с head_dim=192: 331 776 байт на токен, завышение в 10,7 раза

Числа сверены с замером на живом vLLM: 40,79 ГиБ на 1 408 144 токена дают те самые 31 104 байта. Калькулятор, который трактует MLA как обычное внимание, ошибётся на порядок, и вы откажетесь от модели, которая реально помещается на одну карту.

Аргументы в пользу существующих калькуляторов

Не все инструменты одинаково слабы. Автор прямо отмечает, что калькулятор apxml «реально силён»: распознаёт MLA, считает накладные расходы движка, умеет учитывать квантизацию KV-кеша. Для быстрой прикидки «поместится ли модель вообще» этого достаточно.

Кроме того, для стандартных GQA-моделей (а это подавляющее большинство открытых LLM) расхождение между калькулятором и реальностью укладывается в единицы процентов. Если вы работаете с Llama, Mistral, Qwen и не упираетесь в потолок памяти, калькулятор даст вполне рабочую оценку.

Наконец, простота имеет ценность: калькуляторы smcleod и NyxKrage считают по формуле «веса + KV = итого» за секунду, без установки чего-либо. Для первичного скрининга «нужна одна карта или две» этого хватает.

Почему калькуляторам нельзя доверять при планировании прода?

Аргумент «для прикидки сойдёт» разбивается о три факта.

Первый: механизм PagedAttention опубликован в 2023 году, а инструменты 2025-2026 годов его по-прежнему не моделируют. Это не новое знание, это игнорируемое знание.

Второй: ошибка в 7-11 раз для MLA-моделей не «погрешность», а качественно неверный ответ. Вы арендуете стойку вместо одной карты.

Третий: ни один калькулятор не отвечает на главный продовый вопрос «сколько одновременных запросов обслужит моя карта», потому что для этого нужно знать реальный размер KV-пула после резервирования, а не теоретический максимум.

Взял то, что видит обычный человек в выдаче, и pre-grab движка не моделирует никто, даже лучший из них. : Автор ridgepoint

Что делать прямо сейчас, по ролям?

Если вы разворачиваете LLM локально или на арендованном GPU: проверяйте реальный размер KV-пула по логам движка. vLLM при старте печатает строку # GPU blocks: N, это и есть фактическая ёмкость. Любой VRAM-калькулятор LLM даёт лишь верхнюю оценку.

Если вы автор на Дзене и используете локальные модели для генерации контента: при выборе модели под свою карту не отбрасывайте DeepSeek-V2-Lite и подобные MLA-модели из-за «страшных» цифр калькулятора. Реальное потребление памяти может быть в разы меньше расчётного.

Если вы предприниматель и считаете экономику инференса: закладывайте в расчёт параметр утилизации (0,90-0,92 для vLLM по умолчанию) и проверяйте архитектуру внимания модели. Для MLA и MoE-моделей (Mixture of Experts, архитектура, где активна только часть параметров) стандартные формулы не работают. У DeepSeek-V2-Lite, например, общий размер весов 16B параметров, а активных только 2B: память платите за 16, скорость считаете по 2.

Главный вывод из этой истории не в том, что появился ещё один инструмент. А в том, что базовая инфраструктурная задача, посчитать, сколько памяти реально нужно, до сих пор решается неправильно на уровне инструментов первой страницы Google. По мере того как MLA и MoE становятся стандартом в новых моделях, разрыв между калькулятором и реальностью будет только расти, и те, кто научится считать руками или хотя бы проверять логами, сэкономят не проценты, а кратные суммы на аренде.