Сколько видеопамяти нужно открытым LLM: реальные размеры GGUF для 35 моделей

«Параметры × биты ÷ 8» — правило, которое все приводят, когда считают видеопамять под модель. Оно даёт порядок величины и подводит именно там, где это важно: на карте, которой не хватает 2 ГБ, или на чате с контекстом в 32 тысячи токенов, который вдруг перестаёт помещаться.

Поэтому здесь не оценка, а данные из первоисточника для 35 актуальных открытых моделей:

• Веса — реальный размер опубликованного файла: GGUF-сборки unsloth, ggml-org, bartowski и авторов моделей (Q4_K_M, если модель не выпущена сразу в квантованном виде, как GPT-OSS в MXFP4), по данным API Hugging Face.
• Кэш контекста (KV) — по config.json каждой модели: число слоёв, KV-голов и размер головы, с учётом архитектур, где простая формула ошибается.
• Рантайм — контекст CUDA и буферы: около 0,75 ГиБ плюс буфер логитов для пакета из 512 токенов (у словарей на 256 тысяч токенов это заметно).

Все цифры в ГиБ (1024³ байт): в этих единицах продаётся память видеокарт, поэтому их можно прямо сравнивать с «24 ГБ». Hugging Face показывает десятичные гигабайты, поэтому там файлы выглядят примерно на 7% больше.

Таблица

Одна видеокарта, один запрос, кэш в FP16. «Минимальная карта» — самая маленькая распространённая карта, в 97,5% памяти которой помещается объём при 8k (остальное занимают драйвер и CUDA). Название модели ведёт на её страницу со всеми вариантами квантизации.

Что бросается в глаза

Гибридное и скользящее внимание меняют картину. Qwen3 32B и Qwen3.8 27B на диске весят почти одинаково, но переход с контекста 8k на 32k стоит Qwen3 32B ещё 6,0 ГиБ, а Qwen3.8 27B — всего 1,5 ГиБ. Qwen3.8 хранит KV-кэш только на 16 слоях из 64, остальные 48 — слои линейного внимания с постоянным состоянием на последовательность. Gemma 4 делает похожее: окно в 1024 токена на 5 слоях из каждых 6. Для длинного контекста архитектура важна не меньше числа параметров.

MoE-моделям в памяти нужны все веса. Qwen3 30B-A3B на каждый токен использует 3,3 млрд параметров, но загрузить нужно все 30,5 млрд: ей нужна та же карта на 24 ГБ, что и плотной модели на 27B, просто работает она на ней намного быстрее. (llama.cpp умеет держать экспертов в оперативной памяти через --n-cpu-moe ценой скорости.)

GPT-OSS лучше всех вписывается в свой класс. GPT-OSS 20B выходит сразу в MXFP4 и при 8k занимает 12,6 ГиБ — хватает карты на 16 ГБ; GPT-OSS 120B занимает 60,5 ГиБ и помещается на одну карту на 80 ГБ, например H100.

70B — это по-прежнему 48 ГБ. Llama 3.3 70B в Q4_K_M при контексте 8k занимает 43,1 ГиБ: карта на 48 ГБ или две по 24 ГБ с тензорным параллелизмом. При 32k объём растёт до 50,6 ГиБ, и без квантованного KV-кэша в 48 ГБ модель уже не помещается.

MLA-кэш у DeepSeek крошечный. DeepSeek V3.2 и R1 хранят на каждый токен и слой один латентный вектор шириной 576 вместо полных ключей и значений: около 70 КБ на токен для всей модели. Проблема там — веса, а не контекст.

Формула, если хотите проверить модель сами

веса      = размер файла нужной квантизации (или параметры × биты ÷ 8)
kv_кэш    = токены × слои_с_полным_вниманием × 2 × kv_головы × размер_головы × 2 байта
          + min(токены, окно) × слои_с_окном × 2 × kv_головы × размер_головы × 2 байта
рантайм   ≈ 0,75 ГиБ + 512 × словарь × 4 байта
итого     = веса + kv_кэш × параллельные_запросы + рантайм

KV-кэш в q8_0 (-ctk q8_0 -ctv q8_0 в llama.cpp, --kv-cache-dtype fp8 в vLLM) примерно вдвое уменьшает вторую строку. vLLM по умолчанию занимает под кэш 90% карты, поэтому nvidia-smi там всегда показывает полную память; цифры выше — сколько нужно модели, а не сколько забирает vLLM.

Другие настройки

В калькуляторе видеопамяти есть все эти модели, а также FLUX, Qwen-Image, Wan и другие модели картинок и видео: выберите квантизацию, длину контекста и число параллельных запросов — калькулятор покажет, из чего складывается объём и какие видеокарты его вмещают. У каждой модели есть страница с полной таблицей квантизаций в разделе требований моделей к GPU.