Попытка спланировать бюджет на on-premise инфраструктуру под локальные языковые модели с помощью типовых онлайн-калькуляторов регулярно оборачивается жестким похмельем на этапе продакшена. Анализ популярных инструментов в выдаче по запросу «llm vram calculator» вскрывает фундаментальный изъян: практически все они наивно предполагают, что движок просто загрузит веса в видеопамять, а оставшийся объем станет динамически отдавать под KV-кэш по мере поступления пользовательских запросов.
Предварительное резервирование пула
В реальном проде ни один современный инференс-сервер так не работает. При старте vLLM мгновенно захватывает монолитный кусок памяти под пул через параметр gpu_memory_utilization (по умолчанию 0.92), организуя постраничное размещение KV-кэша. В SGLang эту же механику регулирует mem_fraction_static (базово около 0.9), а в TensorRT-LLM выделение завязано на флаг kv_cache_free_gpu_mem_fraction. Оставшиеся 8% видеопамяти в vLLM под пользовательский кэш не попадут в принципе, из-за чего бумажные формулы систематически искажают доступную емкость.
При расчете модели Llama-3-8B на одном ускорителе A100 с контекстом 8192 токена упрощенный сайзинг обещает около 60 одновременных запросов.
«llama-3-8b, 1× A100, ctx 8192: наивная формула без util обещает ~60 запросов; с поправкой на util — 54, замер vLLM — 55.»
Пул забирает фиксированную долю сразу, поэтому на живом сервере предел составляет 55 запросов, а корректная математика с явным учетом резервирования выдает 54.
Архитектурные расхождения в геометрии кэша
Вторая критическая ошибка — расчет объема данных на один токен. Для стандартных моделей с групповым вниманием (GQA) вычисление опирается на формулу 2·n_kv·head_dim·L·p. Но при переходе к сжатому вниманию в латентное пространство (MLA), как в семействе DeepSeek, используется принципиально другое выражение: (d_c + d_rope)·L·p, учитывающее размерность латента и позиционное кодирование.
Если калькулятор слепо подставляет переменные в стандартную формулу внимания, размер памяти под токен для DeepSeek-V2-Lite оказывается завышен в 7,1–10,7 раза. Корректный расчет дает 31 104 байта на токен, что подтверждают замеры на работающем vLLM: 40.79 ГиБ на 1 408 144 токенов. Ситуацию усугубляет путаница в параметрах: у DeepSeek-V2-Lite их 16 миллиардов в общем объеме, но активными при генерации остаются лишь 2 миллиарда.
Сверка потребления VRAM через логи vLLM и nvidia-smi на четырех моделях трех архитектур на ускорителях A100 и H100 показала расхождение с формулами с поправкой на пул всего в пределах 1–4% при утилизации пропускной способности памяти (MBU) около 0.62. Для ИТ-директоров и CTO вывод здесь сугубо экономический: опора на примитивные онлайн-калькуляторы ведет к фатальным ошибкам сайзинга кластеров. Бизнес либо переплачивает за простаивающие GPU-мощности, либо ловит Out-of-Memory и падение сервиса под реальной нагрузкой. Надежный сайзинг требует использования инструментов вроде локальной утилиты ridgepoint, умеющей читать конфигурации из HuggingFace и учитывать реальные алгоритмы аллокации памяти.