Калькулятор видеопамяти для LLM: поместится ли ваша модель на GPU?

Наш калькулятор видеопамяти (VRAM) для LLM (больших языковых моделей) отвечает на первый вопрос, с которого начинается выбор любого GPU: сколько видеопамяти нужно, чтобы запустить модель или дообучить её? Оценка суммирует всё, что занимает память GPU (веса модели, KV-кэш и накладные расходы среды выполнения), а для обучения добавляет к этому градиенты и состояния оптимизатора. На этой странице объясняются формулы, чтобы вы могли проверить результат или самостоятельно пересчитать его для любой модели.

Как работает калькулятор видеопамяти для LLM

Для инференса оценка выглядит так:

GPU memory ≈ weights + KV cache + overhead (10–20%)

Объём весов фиксирован, как только вы выбрали модель и точность. KV-кэш растёт вместе с длиной контекста и числом запросов, которые обслуживаются одновременно. Накладные расходы охватывают всё остальное, что выделяет среда выполнения. При коротких контекстах основную часть памяти занимают веса; при длинных контекстах или большом числе одновременных запросов на первое место может выйти KV-кэш. Дообучение (fine-tuning) добавляет градиенты и состояния оптимизатора, поэтому для обучения модели нужно в несколько раз больше памяти, чем для её инференса.

Веса модели: число параметров × число байт на параметр

Каждый параметр хранится в определённом числовом формате, и от формата зависит его размер:

Квантованные форматы хранят ещё и коэффициенты масштабирования, а некоторые слои часто остаются в более высокой точности, поэтому реальные 4-битные чекпоинты получаются на несколько процентов больше. Более низкая точность экономит память и пропускную способность ценой потери качества, величина которой зависит от модели и метода; этот компромисс разобран в нашем руководстве о точности FP8 и FP4.

KV-кэш: память, которая растёт с каждым токеном

Во время генерации модель хранит ключи и значения механизма внимания для каждого токена в контексте, чтобы не вычислять их заново. В пересчёте на один токен это занимает:

KV cache per token = 2 × layers × KV heads × head dimension × bytes per value

Множитель 2 учитывает ключи и значения. Умножьте результат на число токенов в обработке: длина контекста × число одновременных последовательностей.

Пример расчёта: модель 70B с grouped-query attention

Возьмём модель 70B с 80 слоями и 8 KV-головами размерностью 128, а кэш будем хранить в BF16 (2 байта на значение):

• 2 × 80 × 8 × 128 × 2 = 327 680 байт, то есть около 320 КБ на токен.
• Одна последовательность длиной 32K токенов (32 768): около 10 ГБ.
• Восемь одновременных последовательностей по 32K: около 80 ГБ — больше, чем занимают веса модели в FP8.

Именно grouped-query attention удерживает эти цифры в разумных пределах: 8 KV-голов общие для всех голов запросов. При схеме с одной KV-головой на каждую голову запросов (в типичной модели 70B их 64) памяти понадобилось бы в восемь раз больше. Хранение кэша в FP8 вдвое уменьшает его, а ограничение длины контекста или числа одновременных запросов в настройках сервера инференса задаёт ему верхнюю границу.

Накладные расходы среды выполнения и активации

Помимо весов и кэша, в памяти GPU находятся контекст CUDA, рабочее пространство движка инференса, активации обрабатываемого батча, графы CUDA (если они включены), а часть памяти теряется на фрагментацию. На всё это мы добавляем 10–20%: нижнюю границу — для легковесного сервера с короткими промптами, верхнюю — для больших батчей, длинного prefill или нескольких процессов на одном GPU.

Не удивляйтесь, если инструменты мониторинга покажут почти заполненную память GPU даже в простое. Серверы инференса, такие как vLLM, при запуске резервируют фиксированную долю памяти и заполняют её блоками KV-кэша; от размера этого резерва зависит, сколько запросов выполняется одновременно.

Память для дообучения: полное, LoRA и QLoRA

• Полное дообучение с AdamW в смешанной точности требует примерно 16 байт на параметр без учёта активаций: 2 — на веса в BF16, 2 — на градиенты, 4 — на мастер-копию весов в FP32 и 8 — на два момента оптимизатора. Для модели 70B это около 1,1 ТБ — задача для 8-GPU-сервера с шардированием (FSDP или ZeRO-3), например 8× B200 (1,44 ТБ) или 8× B300 (2,3 ТБ).
• LoRA замораживает базовую модель и обучает небольшие матрицы адаптеров — обычно гораздо меньше 1% параметров. Нужная память — это примерно замороженные веса (около 140 ГБ для модели 70B в BF16) плюс адаптеры, их градиенты и состояния оптимизатора, плюс активации.
• QLoRA загружает замороженные веса в 4-битном формате, около 0,5 байта на параметр, поэтому базовая модель 70B занимает примерно 35–40 ГБ без учёта адаптеров и активаций. С этим справляется один H100 с 80 ГБ или RTX PRO 6000 с 96 ГБ при умеренной длине последовательностей.

Активации растут с размером батча и длиной последовательности и на длинных последовательностях могут превысить объём весов. Чекпоинтинг активаций (gradient checkpointing) за счёт дополнительных вычислений значительно сокращает память под активации.

Распределение модели между несколькими GPU

Когда итог превышает память одного GPU, тензорный параллелизм делит веса каждого слоя и KV-кэш между GPU, так что на каждом оказывается примерно 1/N того и другого плюс его собственные накладные расходы. Оставляйте свободными около 8% памяти каждого GPU — тот же запас, что и в калькуляторе. Модель 70B в BF16 на сервере 8× H100 (всего 640 ГБ) размещает около 17,5 ГБ весов на каждом GPU с 80 ГБ, и большая часть памяти остаётся для KV-кэша и длинных контекстов. При тензорном параллелизме GPU обмениваются данными на каждом слое, поэтому лучше всего он работает на GPU, соединённых через NVLink, как в наших 8-GPU-серверах NVIDIA HGX.

Ограничения любой оценки видеопамяти

• MoE-модели (mixture of experts) задействуют на каждый токен лишь несколько экспертов, но в памяти должны находиться все эксперты. Рассчитывайте их по общему числу параметров, а не по числу активных.
• Накладные расходы фреймворков различаются в зависимости от движка, его версии, ядер (kernels) и настроек. Два сервера с одной и той же моделью могут расходиться на несколько гигабайт.
• Длинные контексты смещают баланс: начиная со 128K токенов KV-кэш может превысить объём весов. Варианты механизма внимания, такие как внимание со скользящим окном (sliding window) или латентное внимание (latent attention), меняют формулу расчёта на токен.
• Мультимодальные модели добавляют энкодеры изображений или звука и их активации.

Считайте результат ориентиром для планирования и подтверждайте его реальным нагрузочным тестом. Разбор по размерам моделей — в нашем руководстве по видеопамяти для LLM.

Какой GPU подойдёт под вашу оценку

Если оставлять свободными около 8% памяти — тот же запас, что и в калькуляторе, — вот максимальные оценки, которые вмещает каждый GPU по отдельности:

Если нужно больше, 8-GPU-сервер вмещает до 2,3 ТБ (8 × 288 ГБ на HGX B300 или AMD Instinct MI355X). На странице каждого GPU, например H100, H200, B200 и B300, показано, что помещается в его память; можно также посмотреть все GPU, которые мы сдаём в аренду.