Планирование видеопамяти для запуска LLM — задача, с которой сталкиваются и инженеры, и исследователи. Казалось бы, достаточно ввести в калькулятор число параметров модели и длину контекста — и получить ответ. Но, как показал эксперимент автора, прогнавшего топ-10 калькуляторов из Google по запросу «llm vram calculator», все они систематически ошибаются в одном и том же: не учитывают, что современные движки резервируют почти всю память под пул заранее, а не раздают её под KV-кэш по мере запросов. Вторая ошибка — неверная формула для архитектур с MLA-вниманием, из-за чего оценка может завышаться на порядок.
Первая ловушка связана с тем, как работают инференс-движки. vLLM при старте выделяет большой кусок VRAM под пул и пейджит KV-кэш внутрь него — за это отвечает флаг gpu_memory_utilization, по умолчанию 0.92. У SGLang аналогичный параметр называется mem_fraction_static (около 0.9), у TensorRT-LLM — kv_cache_free_gpu_mem_fraction. Веса загружаются внутрь этого же куска, а KV-кэш живёт в остатке после весов и overhead. Свободные ~8% VRAM под KV не пойдут никогда. Поэтому ёмкость KV-пула считается как util · VRAM − веса − overhead. Наивные калькуляторы эту формулу игнорируют, и ответ «сколько запросов влезет» оказывается завышенным.
| Модель | Наивно | ridgepoint | Замер vLLM |
|---|---|---|---|
| llama-3-8b (GQA) | ~60 | 54 | 55 |
| DeepSeek-V2-Lite (MLA·MoE) | 16–24 | 17 | 17 |
| llama-3-70b AWQ | ~15 | 12 | 13 |
Вторая ошибка — геометрия KV-кэша. Количество байт на токен зависит от архитектуры внимания. Для обычных GQA-моделей формула выглядит как 2·n_kv·head_dim·L·p, где n_kv — число KV-голов, head_dim — размерность головы, L — число слоёв, p — точность. Но у DeepSeek с MLA-вниманием (Multi-head Latent Attention) KV сжимается в латентное пространство, и формула другая: (d_c + d_rope)·L·p, где d_c — размерность сжатого латента, d_rope — размерность rope-части. Если калькулятор трактует MLA как обычное внимание и подставляет head_dim, он завышает память в 7–11 раз — в зависимости от того, какой head_dim возьмёт. Для DeepSeek-V2-Lite правильный расчёт даёт 31 104 байта на токен, а наивная формула — от 221 184 до 331 776 байт.
Из-за неверной формулы для MLA-архитектур оценка памяти для DeepSeek-V2-Lite завышается в 7–11 раз.
Автор проверил свои расчёты на живом vLLM: замерил потребление памяти на четырёх моделях трёх архитектур (GQA, MLA, MoE) на A100 и H100. Расхождение с предсказанием составило 1–4%, причём предсказание всегда чуть ниже замера. Для llama-3-8b наивная оценка обещала ~60 одновременных запросов при контексте 8192, ridgepoint дал 54, а замер vLLM — 55. Для DeepSeek-V2-Lite наивная GQA-формула давала 16–24 запроса, ridgepoint — 17, замер — 17. Для llama-3-70b AWQ — 15, 12 и 13 соответственно. Разница в 12 против 13 объясняется округлением до целого — по байтам числа совпадают.
Автор создал инструмент ridgepoint, который автоматически определяет архитектуру модели (GQA, MLA, MoE) по конфигу с HuggingFace и применяет корректную формулу. Он доступен как CLI-утилита и позволяет оценить требования к памяти до аренды GPU. Однако инструмент не лишён ограничений: скорость (TTFT, MFU) он не измеряет, а берёт из литературы; throughput под смешанной нагрузкой не считается. Калибровка проведена только на vLLM, хотя SGLang и TensorRT-LLM используют аналогичный механизм пула.
Для практиков вывод прост: при оценке VRAM для LLM нужно учитывать обе ловушки. Иначе можно либо недооценить память и получить OOM, либо переоценить и зря арендовать стойку GPU вместо одной карты. Инструменты вроде ridgepoint помогают избежать этих ошибок, но окончательная проверка — всегда на реальном железе.
