Сколько VRAM нужно LLM: веса, KV-cache и запас

Оценка видеопамяти состоит из нескольких слагаемых. Размер файла модели полезен, но по нему нельзя узнать, сколько параллельных диалогов выдержит сервер. Практический расчёт должен отдельно учитывать веса, сохранённый контекст и память исполнения.

Сначала посчитайте веса

Для условной модели с P параметрами и B битами на параметр нижняя оценка равна P × B / 8 байт. В обычной десятичной записи 32 млрд параметров требуют 64 GB при 16 битах, 32 GB при 8 битах и 16 GB при 4 битах. В GiB это соответственно около 59,6, 29,8 и 14,9.

GB и GiB обозначают разные единицы: миллиард байт и 2 в степени 30 байт. Сравнивать результаты надо в одной системе. Кроме того, квантованный файл содержит масштабы и другие служебные данные; некоторые тензоры сохраняются в более высокой точности. Поэтому арифметическое значение не равно размеру конкретного артефакта.

Затем посчитайте KV-cache

Для обычного decoder-only Transformer с полным attention и одинаковыми слоями используем оценку:

KV_bytes = 2 × layers × kv_heads × head_dim × tokens × sequences × bytes_per_element.

Двойка означает ключи и значения. tokens включает уже обработанный вход и накопленный ответ. sequences означает одновременно хранящиеся независимые последовательности. Нужны именно KV-heads, а не общее количество attention-heads.

Возьмём параметры Qwen3-32B из официального config: 64 слоя, 8 KV-heads, размер головы 128. 1 Для одного запроса на 8192 токена с двухбайтовым cache получаем 2 GiB. Четыре таких запроса требуют около 8 GiB только под KV-cache. Это собственный расчёт по конфигурации, а не результат запуска.

Элемент условной конфигурации	Оценка
32 млрд весов, идеальные 4 бита	14,9 GiB
Четыре независимых контекста по 8192 токена	8 GiB
Сумма до метаданных и runtime	22,9 GiB

Из этой таблицы нельзя заключить, что карта на 24 GB подходит: пространство для метаданных, графов, промежуточных тензоров и фрагментации ещё не учтено. Даже единицы памяти у производителя и используемой утилиты могут отображаться по-разному.

Добавьте измеряемый резерв

Универсального коэффициента запаса нет. На стадии предварительного выбора можно проверить несколько инженерных сценариев, например 10%, 20% и 30% сверх весов и cache, плюс отдельный фиксированный резерв. Это предположения для чувствительности расчёта. После пилота их заменяют пиковым потреблением конкретного движка.

Если память занята почти полностью, изменение версии kernels, увеличение контекста или дополнительная модель эмбеддингов способно привести к отказу. Резерв нужен также для эксплуатационных действий, но нельзя обещать обновление без остановки на основании одного свободного гигабайта.

Где простая формула перестаёт работать

MLA, sliding-window attention, гибридные архитектуры и разделение cache между устройствами требуют другой модели расчёта. Prefix caching может экономить часть памяти на общих префиксах, но величину экономии нельзя включать в гарантированный бюджет до измерения попаданий. Quantized KV-cache уменьшает размер элементов; его поддержка и влияние на качество зависят от реализации. vLLM отдельно документирует FP8-cache. 2

При распределении по GPU проверьте, какие структуры делятся, а какие дублируются. Суммарные 96 GB на двух картах не означают единый свободный массив на 96 GB. Для MoE учитывайте полный размер размещаемых весов, даже если на токен активируется лишь часть экспертов.

Как превратить оценку в решение

Заполните калькулятор VRAM сначала для обычного запроса, затем для максимального разрешённого. Сохраните все входные параметры вместе с результатом. В пилоте измерьте пик памяти при заданной параллельности и проверьте обработку превышений: очередь, явный отказ или ограничение контекста.

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