Сколько видеопамяти нужно для LLM?

Сколько видеопамяти (VRAM) нужно для LLM (большой языковой модели)? В первом приближении это веса модели плюс KV-кэш, который растёт с длиной контекста и с числом одновременно обслуживаемых запросов, плюс 10–30% на активации и накладные расходы среды выполнения. При обучении к этому добавляются градиенты и состояния оптимизатора. В этом руководстве — формулы, расчёты на реальных цифрах для Llama 3.1 8B и 70B и сопоставление результатов с GPU от 32 до 288 ГБ. Если не хочется считать вручную, калькулятор видеопамяти сделает это за вас.

Сколько видеопамяти нужно для LLM: формула

При инференсе память складывается из трёх частей:

VRAM     ≈ weights + KV cache + overhead
weights  = parameters × bytes per parameter
KV cache = 2 × layers × KV heads × head dim × bytes per value × tokens in flight
overhead = activations, CUDA context, engine buffers (plan 10-30%)

На один параметр приходится 2 байта в BF16 или FP16, 1 байт в FP8 или INT8 и 0,5 байта в 4-битных форматах. Множитель «tokens in flight» (токены в обработке) — это длина контекста, умноженная на число последовательностей, которые обслуживаются одновременно. Все размеры в статье указаны в десятичных гигабайтах (миллиард байт) и намеренно приблизительны: в реальных чекпоинтах часть слоёв хранится в более высокой точности, а движки инференса выделяют память блоками.

Объём весов модели при разной точности

Веса — это нижняя граница. Если они не помещаются, всё остальное уже неважно. Умножьте число параметров на число байт на параметр:

Значения в столбцах FP8 и «4 бита» считайте минимальными. Квантованные форматы хранят рядом с весами коэффициенты масштабирования, а в квантованных чекпоинтах слой эмбеддингов и выходной слой обычно остаются 16-битными. В небольших моделях эти слои весят относительно больше: в Llama 3.1 8B две эти матрицы содержат около 1,05 млрд параметров — примерно 2,1 ГБ в BF16, а это больше половины того, что занимает вся остальная модель в 4 битах. Точность влияет и на качество, причём при 4 битах сильнее, чем при FP8; компромиссы разобраны в нашей статье о точности FP8 и FP4.

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

Во время генерации модель хранит вектор ключа и вектор значения для каждого токена, в каждом слое, для каждой обслуживаемой последовательности. Это и есть KV-кэш. При длинных контекстах или большом числе одновременных пользователей он может превысить объём весов.

KV bytes per token = 2 × layers × KV heads × head dim × bytes per value
KV cache           = KV bytes per token × context length × concurrent sequences

Именно на множителе «KV heads», то есть на числе KV-голов, современные архитектуры экономят память. В Llama 3.1 используется механизм grouped-query attention: у модели 70B — 64 головы запросов, но только 8 KV-голов, поэтому её кэш в восемь раз меньше, чем понадобился бы при полном многоголовом внимании (multi-head attention). Для опубликованных архитектур и 16-битного кэша:

• Llama 3.1 8B (32 слоя, 8 KV-голов размерностью 128): 2 × 32 × 8 × 128 × 2 байта = 131 072 байта, около 0,13 МБ на токен.
• Llama 3.1 70B (80 слоёв, 8 KV-голов размерностью 128): 2 × 80 × 8 × 128 × 2 байта = 327 680 байт, около 0,33 МБ на токен.

Отсюда три вывода. Одному диалогу на 128K токенов с моделью 70B нужно около 43 ГБ кэша — больше половины памяти H100. Шестнадцати пользователям по 8K токенов нужно ровно столько же, сколько этому одному длинному диалогу, потому что значение имеет общее число токенов в обработке. А кэш в FP8 вдвое уменьшает каждое число в таблице — поэтому движки инференса, такие как vLLM, и предлагают его как опцию.

Таблица показывает худший случай. Движки со страничным KV-кэшем (paged KV cache) выделяют блоки по мере генерации токенов, поэтому запрос, который завершился раньше, не занимает память под весь контекст. Рассчитывайте на реалистичный пик числа токенов в обработке, а не на то, что все пользователи одновременно дойдут до максимума, но убедитесь, что хотя бы один запрос максимальной длины помещается.

Накладные расходы и запас

Веса и кэш — это ещё не всё. До загрузки модели контекст CUDA и библиотеки уже занимают память на каждом GPU — обычно от нескольких сотен мегабайт до одного-двух гигабайт. Во время прямого прохода активациям нужно рабочее пространство, и больше всего его требуется при обработке длинных промптов. Движки инференса также резервируют память под графы CUDA и буферы сэмплирования, а задачи на нескольких GPU добавляют буферы для обмена данными.

Практическое правило — закладывать 10–30% запаса сверх весов и KV-кэша: нижнюю границу — для одного GPU с хорошо изученным движком, верхнюю — для конфигураций с несколькими GPU, очень длинных промптов или обучения. В vLLM это правило реализовано явно. Он берёт фиксированную долю памяти каждого GPU (по умолчанию 90%, задаётся параметром --gpu-memory-utilization), загружает веса, измеряет пиковое потребление памяти активациями на тестовом проходе и отдаёт всё оставшееся под KV-кэш. Как это настроить, показано в нашем руководстве по самостоятельному развёртыванию инференса LLM с vLLM.

Пример расчёта: инференс Llama 3.1 70B

Допустим, Llama 3.1 70B должна одновременно обслуживать 16 пользователей, у каждого из которых до 8 192 токенов.

• Веса в FP8: около 70 ГБ, на практике чуть больше.
• KV-кэш в BF16: 16 × 8 192 токена × 0,33 МБ ≈ 43 ГБ.
• Итого с запасом 15%: (70 + 43) × 1,15 ≈ 130 ГБ.

Это помещается на один H200 со 141 ГБ. А на один H100 с 80 ГБ — нет: веса занимают почти всю его память, и на кэш остаётся несколько гигабайт — хватит на один-два запроса по 8K токенов одновременно, а не на шестнадцать. Если вдвое уменьшить кэш с помощью FP8, итог составит около 105 ГБ — для этого всё равно нужно больше одного H100.

В BF16 одни только веса занимают около 140 ГБ. На практике это исключает один H200: на кэш ничего не осталось бы. B200 со 180 ГБ вмещает веса, и после накладных расходов остаётся примерно 20 ГБ — этого хватит примерно на шесть полных запросов по 8K токенов или примерно на двенадцать с кэшем в FP8. B300 с 288 ГБ обслужит всех шестнадцать пользователей с запасом.

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

Обучению нужно гораздо больше памяти на параметр, чем инференсу, потому что GPU хранит ещё и градиенты, и состояния оптимизатора. Цифры ниже приведены без учёта активаций: они зависят от длины последовательности и размера микробатча, и их обычно держат под контролем с помощью чекпоинтинга активаций (gradient checkpointing).

На практике LoRA для модели 8B помещается на RTX 5090 с 32 ГБ или L40S с 48 ГБ, и для активаций ещё остаётся место. Для полного дообучения той же модели нужен B200 со 180 ГБ или B300 с 288 ГБ либо несколько GPU по 80 ГБ с шардированными состояниями оптимизатора. Для модели 70B QLoRA помещается на один H100 или H200, LoRA требует двух GPU по 80 ГБ либо одного B200 или B300, а полное дообучение — 8-GPU-сервера с B300, сервера 8× B200 при экономной настройке или сервера 8× H200 с выгрузкой состояний оптимизатора в память CPU. Каждый из этих вариантов разобран в нашем руководстве по дообучению модели 70B.

MoE-модели (mixture of experts): в памяти нужны все эксперты

MoE-модели направляют каждый токен лишь через нескольких экспертов из множества. Это сокращает объём вычислений на токен, но не память: все эксперты должны постоянно находиться в памяти, потому что следующему токену может понадобиться любой из них. Рассчитывайте память для MoE-моделей по общему числу параметров, а число активных параметров считайте ориентиром только для вычислений.

• Mixtral 8x7B содержит в сумме 46,7 млрд параметров, но на каждый токен задействует лишь около 12,9 млрд. В BF16 её весам всё равно нужно около 93 ГБ — больше, чем вмещает один H100.
• Qwen3-235B-A22B содержит 235B параметров, из которых активны 22B: в BF16 это около 470 ГБ, что помещается на 8× H100 (640 ГБ), а в FP8 — около 235 ГБ.
• DeepSeek-V3 содержит 671B параметров, из которых активны 37B. Даже в FP8 её веса занимают примерно 670 ГБ: больше, чем 640 ГБ сервера 8× H100, но с большим запасом укладываются в 8× H200 (1 128 ГБ) или 8× B200 (1 440 ГБ).

Размер кэша по-прежнему зависит от устройства механизма внимания. Модели DeepSeek используют Multi-head Latent Attention, который хранит сжатый кэш, поэтому для них формула выше даёт завышенную оценку. Об этом семействе — в нашем руководстве по системным требованиям DeepSeek.

Какой GPU подойдёт для вашей модели

Вот как эти цифры ложатся на реальное оборудование для инференса — при умеренной длине контекста и умеренном числе одновременных запросов. «Впритык» означает, что веса помещаются, но для кэша остаётся мало места.

Два замечания о конфигурациях с несколькими GPU. Если разделить модель с помощью тензорного параллелизма, вместе с ней разделится и её KV-кэш, поэтому объём кэша растёт с числом GPU. Кроме того, важен интерконнект: в серверах HGX GPU объединены через NVLink, а карты RTX PRO 6000 и L40S обмениваются данными по PCIe — этого достаточно для запуска отдельных копий модели, но при разделении одной модели между картами такая связь работает медленнее. Рейтинг GPU по типам задач — в нашем руководстве о лучшем GPU для инференса LLM.

Всё сказанное выше предполагает, что вам достаётся вся карта. Каждый GPU, который мы сдаём в аренду, — целый физический GPU, поэтому вся память из таблицы принадлежит вам и ничего не нужно вычитать на профиль vGPU или раздел MIG. Если ваша цель — 70B в FP8 с ощутимым числом одновременных запросов, варианты с одним GPU и с 8 GPU показаны на странице NVIDIA H200.

Часто задаваемые вопросы

Сколько видеопамяти нужно для запуска модели 70B?

Около 140 ГБ под веса в BF16, 70 ГБ в FP8 и 35–40 ГБ в 4-битном формате, плюс KV-кэш и 10–30% на накладные расходы. На практике это B200 или B300 для BF16, H200 для FP8 с ощутимым числом одновременных запросов и GPU с 80 ГБ для 4-битного формата.

Сколько видеопамяти нужно модели 8B?

Около 16 ГБ под веса в BF16, 8 ГБ в FP8 и 4–6 ГБ в 4-битном формате. Добавьте KV-кэш: для Llama 3.1 8B это около 0,13 МБ на токен в BF16, то есть примерно 1 ГБ на 8 000 токенов.

Действительно ли длина контекста влияет на расход видеопамяти?

Да. KV-кэш растёт линейно с длиной контекста и с числом одновременных последовательностей. Одному запросу на 128K токенов к Llama 3.1 70B нужно около 43 ГБ кэша в BF16 — больше половины памяти H100.

Можно ли объединить память нескольких GPU?

Да. Движки инференса и фреймворки для обучения умеют делить модель между несколькими GPU с помощью тензорного или конвейерного параллелизма (pipeline parallelism), и KV-кэш при этом тоже делится. Лучше всего это работает через NVLink, как в 8-GPU-серверах HGX; через PCIe это тоже работает, но обмен данными обходится дороже.

Можно ли использовать всю заявленную память GPU?

Не совсем: контекст CUDA, библиотеки и буферы фреймворков занимают часть памяти на каждом GPU, а серверы инференса резервируют рабочее пространство под активации. На разделяемом или разбитом на разделы GPU вам может достаться лишь его часть, поэтому убедитесь, что арендуете целую карту.