Видеопамять под LLM: 10 моделей, 5 квантов и формула для KV-кэша

Коротко (TL;DR)

• Занятая видеопамять — это не «размер модели». Это четыре слагаемых: веса, KV-кэш, служебные буферы движка и то, что уже забрал рабочий стол. Новичков ломает второе: KV-кэш растёт вместе с длиной диалога, поэтому модель спокойно загружается и падает через полчаса работы.
• Правило «Q4 — это 0,5 байта на параметр» занижает результат примерно на 20%. Мы посчитали реальные размеры GGUF-файлов восьми моделей от 3B до 70B: Q4_K_M даёт 4,86 бита на параметр (диапазон 4,78–5,03), Q8_0 — 8,47 бита. На 70B разница с ходовым правилом — 6,8 ГиБ.
• KV-кэш зависит от числа слоёв и KV-голов, а не от числа параметров. Qwen3 32B ест 256 КиБ на токен, Llama 3.1 8B — 128 КиБ, а MoE-модель Qwen3 30B-A3B — всего 96 КиБ, меньше, чем плотная восьмимиллиардная.
• Живой пример провала: Qwen3 32B в Q4_K_M на карте 24 ГБ занимает 21,6 ГиБ при контексте 8k и 27,6 ГиБ при 32k. Модель стартует, работает, а на длинном документе выходит за пределы карты.
• Формула важнее таблицы. Таблица устареет со следующим релизом, формула — нет: чтобы посчитать любую новую модель, нужны четыре числа из её карточки и размер файла.

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

Из чего складывается занятая видеопамять: четыре слагаемых

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

Разберёмся по слагаемым. Опорой будет документация сервера llama.cpp — это движок, на котором работают и Ollama, и LM Studio, и именно его умолчания определяют, сколько памяти уйдёт под кэш. Мейнтейнер проекта отдельно разбирал лог загрузки построчно и назвал ровно четыре буфера, которые аллоцируются на видеокарте; про буфер весов там сказано: «The total size should be very close to the size of the model file on disk». Это первое и главное следствие для расчёта: считать надо от реального файла, а не от арифметики «параметры × полбайта».

Вот все четыре слагаемых.

1. Веса модели. Занимают ровно столько, сколько весит файл GGUF на диске. Не приблизительно — практически байт в байт, потому что движок отображает файл в память как есть.

Квантование локальных LLM: Q8 даёт запас, а обрыв качества начинается ниже Q4

Ollama, LM Studio и llama.cpp на одной модели: от 0,3% разницы до трёх раз

DGX Spark, Mac Studio и Strix Halo: 120B держат все три, 70B буксует у двух

RTX 5090, 4090 и 3090 в локальных LLM: чужие замеры в одной таблице

Локальная генерация видео на видеокарте: Wan 2.2, LTX-2.5 и HunyuanVideo 1.5

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

3. Служебные буферы движка. В разобранном логе это CUDA0 compute buffer size = 507.00 MiB — место под промежуточные результаты вычислений, плюс совсем маленький выходной буфер на 1,95 МиБ. Сверх напечатанного драйвер CUDA забирает ещё несколько сотен мегабайт под собственный контекст, и в логе движка эта часть не видна вовсе. Рабочая оценка на оба буфера вместе — 1–1,5 ГиБ; дальше в таблицах мы берём 1,2 ГиБ. Это оценка, а не замер, и мы её так и помечаем.

4. То, что уже занято. На Windows рабочий стол, браузер и композитор оконного менеджера держат от 0,5 до 1,5 ГиБ видеопамяти ещё до запуска модели. На Linux без графической оболочки — почти ноль. Разница между этими двумя случаями больше, чем весь служебный буфер движка.

Складывается это так:

занятая видеопамять = размер файла GGUF
                    + KV-кэш (растёт с длиной контекста)
                    + 1–1,5 ГиБ буферов движка и драйвера
                    + то, что забрала ОС

Первые два слагаемых считаются точно. Третье оценивается. Четвёртое читатель видит в диспетчере задач сам.

Формула расчёта на примере Llama 3.1 8B: шесть чисел из карточки

Разберём один расчёт полностью — дальше по этому образцу считается любая модель, включая ту, которая выйдет через месяц.

Берём Llama 3.1 8B в кванте Q4_K_M и контекст 8192 токена.

Шаг 1. Размер файла. Идём в репозиторий с готовыми GGUF на Hugging Face и смотрим точный размер блоба: Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf — 4 920 739 232 байта, то есть 4,58 ГиБ. Ollama для того же кванта печатает округлённое «4.9GB» — сходится.

Шаг 2. Четыре числа из config.json. В карточке модели открываем файл config.json и выписываем:

Отдельно нужен пятый параметр — байт на элемент кэша. По умолчанию llama.cpp хранит KV-кэш в f16, то есть 2 байта. Это прямо записано в документации движка: --cache-type-k, -ctk: KV cache data type for K allowed values: f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1 (default: f16). И шестое число — длина контекста, которую вы зададите флагом -c.

Шаг 3. KV-кэш на один токен. Формула:

KV на токен = 2 × слоёв × KV-голов × head_dim × байт_на_элемент

Двойка в начале — потому что кэшируются и ключи (K), и значения (V), причём симметрично: в логе движка это видно как K (f16): 672.00 MiB, V (f16): 672.00 MiB.

Подставляем: 2 × 32 × 8 × 128 × 2 = 131 072 байта = 128 КиБ на токен.

Шаг 4. KV-кэш на весь контекст. 128 КиБ × 8192 токена = 1,00 ГиБ. При 32 768 токенах будет 4,00 ГиБ, при 131 072 — 16,00 ГиБ.

Шаг 5. Складываем.

4,58 ГиБ (веса)
+ 1,00 ГиБ (KV при 8k)
+ 1,20 ГиБ (буферы)
= 6,78 ГиБ

Плюс то, что забрала ОС. На карте 8 ГБ (это 8 ГиБ по факту, видеопамять маркируют в двоичных гигабайтах) остаётся около 1,2 ГиБ — на голом Linux хватит, на Windows с открытым браузером уже впритык. На 12 ГБ конфигурация живёт спокойно и с запасом под контекст побольше.

Почему KV-голов именно 8, а не 32. У Llama 3.1 8B тридцать две головы внимания, но всего восемь KV-голов — это механизм GQA (grouped-query attention, сгруппированное внимание): несколько голов внимания делят один набор ключей и значений. Для расчёта памяти важны именно KV-головы, и разница здесь четырёхкратная. Если взять в формулу num_attention_heads вместо num_key_value_heads, ответ будет завышен вчетверо — это самая частая арифметическая ошибка в этой теме.

Вот те же четыре числа для всех моделей нашей таблицы, чтобы не открывать десять карточек:

Уже по этой таблице видно главное: число параметров и аппетит к KV-кэшу связаны слабо. У Qwen3 32B кэш вдвое толще, чем у Llama 3.1 8B, хотя параметров вчетверо больше — потому что слоёв ровно вдвое больше. А у Gemma 3 27B KV-кэш формально худший в выборке, и виноваты не параметры, а шестнадцать KV-голов вместо восьми. Что с этим делает движок — разберём отдельно, потому что там всё не так страшно.

Сколько весит квант: реальные байты GGUF против правила 0,5

Ходовое правило звучит так: FP16 — 2 байта на параметр, Q8 — 1 байт, Q4 — 0,5 байта. Оно повторяется во всех восьми материалах, которые мы разобрали для этой статьи, и оно неверно.

Мы взяли точные размеры блобов из API Hugging Face (поле siblings[].size — это байты, а не округление карточки) и поделили на точное число параметров из метаданных safetensors. Вот что получилось на восьми моделях от 3B до 70B:

Расхождение с правилом — от 6 до 21 процента, и всегда в одну сторону: реальный файл больше ожидаемого. Причин две. Первая — K-кванты держат часть тензоров в более высокой точности, поэтому «Q4» не означает, что все веса лежат в четырёх битах. Вторая — служебные данные формата и таблицы масштабов внутри блоков.

Проверить это можно, не веря нам на слово. Ollama печатает для Llama 3.3 70B размер q4_K_M — 43GB и fp16 — 141GB. Отношение 43 к 141 даёт 4,88 бита на параметр — то есть независимый реестр приходит к той же цифре, что и наш расчёт по байтам Hugging Face, а не к заявленным четырём битам.

Практический вывод простой: берите размер конкретного файла, а не считайте по правилу. Посчитаем недобор прямо по цифрам выше. У Llama 3.1 8B правило обещает 3,74 ГиБ, файл весит 4,58 — недобор 0,84 ГиБ. У Qwen3 32B: обещано 15,26, реально 18,40 — недобор 3,15 ГиБ. У Llama 3.3 70B: обещано 32,85, реально 39,60 — недобор 6,75 ГиБ.

Почти семь гигабайт на 70B — это ровно та величина, которая решает, поместится модель в две карты по 24 ГБ или нет. Кто считал по правилу, увидит 32,85 ГиБ и решит, что запас огромный; на деле веса займут 39,6, и с KV-кэшем на длинном контексте сборка на двух RTX 3090 ради 48 ГБ окажется не «с запасом», а впритык.

Ближе всех из англоязычного топа подошли те, кто даёт 0,57 байта на параметр для Q4_K_M — это 4,56 бита, уже теплее, но всё ещё ниже измеренного.

Таблица: сколько видеопамяти нужно под модель и квант

Первая таблица — только веса, то есть размер файла GGUF в ГиБ. Это нижняя граница: без контекста и без буферов модель работать не будет, но меньше этого числа она не займёт никогда.

У gpt-oss-120b прочерки не по недосмотру: модель публикуется сразу в формате MXFP4 и весит 59,0 ГиБ, а привычных K-квантов у неё просто нет. Подробнее — в разделе про MoE.

Вторая таблица — полная: веса в Q4_K_M плюс KV-кэш в f16 плюс 1,2 ГиБ буферов. Последняя колонка — реалистичный минимум карты при контексте 8192 токена, с поправкой на то, что часть памяти заберёт система.

Значения для Gemma 3 27B и gpt-oss-120b посчитаны с учётом скользящего окна — если считать их наивной формулой, цифры получатся в разы больше, и именно так делают все чужие таблицы. Почему так — следующие два раздела.

Три вещи, которые в этой таблице легко пропустить.

Первое: у Llama 3.3 70B колонка «при 128k» даёт 80,8 ГиБ — то есть на длинном контексте KV-кэш этой модели весит примерно столько же, сколько её собственные веса. Второе: у Qwen3 32B разброс между 4k и 128k — двадцать восемь гигабайт, больше, чем весит сама модель. Третье: gpt-oss-120b на 117 миллиардов параметров от 4k к 128k прибавляет всего 4,3 ГиБ — меньше, чем восьмимиллиардная Llama.

Обратите внимание и на строку Qwen3 32B: 21,6 ГиБ при 8k делают её пограничной для одной карты на 24 ГБ, а вот на RTX 5090 с её потолком в 32 ГБ та же модель живёт уже с контекстом 32k.

KV-кэш и длина контекста: почему модель падает на длинном диалоге

Самый частый сценарий выглядит так. Модель поставили, она запустилась, отвечает быстро. Через полчаса работы, на длинном документе или после десятка сообщений, движок падает с ошибкой нехватки памяти или начинает выдавать токены в десять раз медленнее.

Причина в том, что веса — константа, а KV-кэш — переменная. Он растёт линейно с числом токенов в контексте и живёт в той же видеопамяти.

Значения в таблице — гибибайты (ГиБ), то есть двоичные гигабайты.

Разберём кейс целиком. Qwen3 32B в Q4_K_M на карте 24 ГБ — популярная конфигурация, её советуют почти все справочники.

Вот откуда берётся ощущение «работало, а потом сломалось»: при запуске с флагом -c 32768 движок аллоцирует весь кэш сразу и честно падает на старте, а вот при автоматическом или растущем контексте проблема выстреливает уже в процессе.

Обратите внимание, что родной контекст у Qwen3 32B — 40 960 токенов, а не 131 072, как у Llama 3.x. Колонка «128k» для этого семейства описывает режим с YaRN, который надо включать отдельно; без него такой контекст просто недоступен. В чужих таблицах эта оговорка обычно отсутствует, и читатель считает память под режим, которого у него нет.

Как проверить свой расчёт. llama.cpp печатает размер кэша прямо при загрузке, строкой вида size = 6791.50 MiB (69632 cells, 47 layers, 1/1 seqs), K (f16): 3595.50 MiB, V (f16): 3196.00 MiB. Если ваше число и число движка расходятся больше чем на пару процентов — скорее всего, в формулу подставлены головы внимания вместо KV-голов, либо у модели скользящее окно.

Скользящее окно внимания срезает кэш Gemma 3 в пять раз

По таблице архитектур Gemma 3 27B выглядит худшей моделью в подборке: 62 слоя и 16 KV-голов дают 496 КиБ на токен — вдвое больше, чем у Llama 3.3 70B. Наивный расчёт на 32k контекста даёт 15,50 ГиБ только под кэш. Вместе с весами в Q4_K_M это почти 32 ГиБ, и модель, которую Google называет «работающей на одной видеокарте», в 24 ГБ не влезает вовсе.

Так считают все чужие таблицы. И так не работает ни один современный движок.

В config.json у Gemma 3 есть два поля, которые в расчёт обычно не берут: sliding_window: 1024 и sliding_window_pattern: 6. Технический отчёт Gemma 3 расшифровывает их дословно: «a pattern of 5 local layers for every global layer» и «assign a smaller span of only 1024 tokens to the local layers».

По-человечески: из 62 слоёв только каждый шестой видит весь контекст. Таких слоёв десять. Остальные пятьдесят два смотрят назад не дальше чем на 1024 токена — и держать в кэше больше им не нужно.

llama.cpp это учитывает, причём по умолчанию: в документации сервера есть флаг --swa-full: use full-size SWA cache (default: false). Значение по умолчанию false означает ровно то, что кэш локальных слоёв ограничен окном, а не длиной контекста.

Считаем правильно. Десять глобальных слоёв держат полный контекст, пятьдесят два локальных — по 1024 токена каждый:

Авторы модели меряют тот же эффект в долях, и здесь нужна точность в цитировании. Конкретный процент в тексте отчёта приведён для абляционного варианта с соотношением 1:3 и окном 1024: при контексте 32k накладные расходы на кэш падают с 60 процентов до менее чем 15. Для продакшен-схемы 5:1, которая и стоит в Gemma 3 27B, отдельного числа в прозе отчёта нет — только график. Глобальных слоёв у 5:1 меньше, чем у 1:3, то есть экономия должна быть не хуже, но приписывать продакшен-модели ровно эти 15 процентов было бы натяжкой.

Практический итог: Gemma 3 27B в Q4_K_M при 32k контекста занимает 19,5 ГиБ, а не 32 — то есть спокойно живёт на карте 24 ГБ, тогда как «более лёгкая» по параметрам Qwen3 32B на том же контексте не живёт. Из таблицы «модель × квант» этого не видно никак.

Важная оговорка. Скользящее окно — свойство связки модели и движка, а не только модели. Запустите ту же Gemma 3 с флагом --swa-full, или на бекенде, который этот режим не реализует, и вернётся честная наивная цифра в 15,50 ГиБ. Поэтому проверять надо не только карточку модели, но и то, что печатает движок при загрузке.

MoE-модели: почему 117 млрд параметров не значит 117 ГБ памяти

Mixture of Experts — архитектура, в которой модель состоит из множества «экспертов», а на каждый токен работает лишь несколько из них. У Qwen3 30B-A3B это 128 экспертов, из которых активны 8; у gpt-oss-120b — тоже 128 экспертов, активны 4.

Отсюда растёт устойчивое заблуждение в обе стороны, и оба варианта неверны.

Заблуждение первое: «активных параметров 3 миллиарда, значит нужно как под 3B». Нет. Роутер заранее не знает, какие эксперты понадобятся на следующем токене, поэтому все веса обязаны лежать в памяти. Qwen3 30B-A3B в Q4_K_M весит 17,3 ГиБ — ровно как плотная модель на 30 миллиардов параметров. Активные параметры экономят вычисления и скорость, а не память.

Заблуждение второе: «раз память как у плотной, то и требования как у плотной». Тоже нет — и вот здесь начинается интересное. KV-кэш у MoE считается по тем же слоям и KV-головам, а число экспертов на него не влияет вообще.

MoE-модель на 30 миллиардов параметров держит кэш меньше, чем плотная на восемь. Причина не в экспертах, а в четырёх KV-головах вместо восьми и сорока восьми слоях вместо шестидесяти четырёх. На контексте 32k это разница между 3,00 и 8,00 ГиБ — те самые пять гигабайт, из-за которых одна модель на карте 24 ГБ живёт, а другая нет.

Отдельный случай — gpt-oss-120b. Модель на 117 миллиардов параметров, из которых активны 5,1 миллиарда. Публикуется сразу в MXFP4: карточка OpenAI прямо пишет, что «the models were post-trained with MXFP4 quantization of the MoE weights, making gpt-oss-120b run on a single 80GB GPU». Файл весит 63,4 ГБ, то есть 59,0 ГиБ — 4,34 бита на параметр по нашему расчёту, и 4,25 бита по заявлению Ollama (расхождение объясняется тем, что внимание, роутер и эмбеддинги остаются в BF16).

При этом её KV-кэш — самый скромный во всей подборке: 36 слоёв, 8 KV-голов, размерность головы всего 64, и вдобавок половина слоёв работает со скользящим окном на 128 токенов. При полном контексте 131 072 токена кэш занимает 4,50 ГиБ. Для сравнения, у плотной Llama 3.3 70B столько же кэша набирается уже при 16k.

То есть «120B» пугает цифрой в названии, а по памяти ведёт себя как большая модель с очень дешёвым контекстом. Если веса помещаются — контекст почти ничего не добавит.

Как считать MoE вообще:

1. Веса — по полному числу параметров и реальному размеру файла, как у плотной модели. Никаких скидок на активные параметры.
2. KV-кэш — по слоям и KV-головам из config.json. Экспертов в формуле нет.
3. Если веса не влезают, у MoE есть отдельный рычаг: в llama.cpp флаг --n-cpu-moe держит веса экспертов первых N слоёв в оперативной памяти, оставляя внимание и общие части на видеокарте. Для плотной модели такого рычага не существует — там выгружаются слои целиком.

Модель не влезает: четыре рычага и цена каждого

Расчёт показал перебор. Дальше есть ровно четыре рычага, и у каждого своя цена. Порядок ниже — от самого дешёвого к самому дорогому.

Рычаг 1. Укоротить контекст. Самый недооценённый и часто самый безболезненный. Флаг -c в llama.cpp задаёт длину контекста напрямую; по умолчанию движок берёт её из модели, а модели сейчас заявляют 128 тысяч токенов. Если вы ведёте обычный диалог, а не разбираете стостраничный документ, 8192 токена закрывают почти всё. У Qwen3 32B переход со 32k на 8k освобождает 6 ГиБ — больше, чем даёт понижение кванта на ступень.

Цена: модель просто перестанет помнить начало длинного разговора. Никакой деградации качества внутри окна не происходит.

Рычаг 2. Квантовать KV-кэш. Флаги --cache-type-k q8_0 и --cache-type-v q8_0 переводят кэш с двух байт на элемент на один, то есть режут его ровно вдвое. У Qwen3 32B при 32k это 4,00 ГиБ вместо 8,00, и конфигурация возвращается в 23,6 ГиБ — на карте 24 ГБ снова работает, хоть и впритык.

Цена по качеству — единственный опубликованный замер с методикой, который мы нашли, даёт разницу перплексии на Qwen 2.5 Coder 7B в 0,0043 (8,3891 против 8,3934), и это внутри доверительного интервала обоих измерений. Команда запуска и данные приведены в обсуждении в репозитории llama.cpp. Это замер участника сообщества, не наш и не вендорский, и он один — второго с числами найти не удалось.

Оговорка из того же обсуждения важна: безопасен именно q8_0. Про q4_0 там же пишут, что он «produces weird results» на Qwen2-7B. Половинить кэш можно, четвертовать — на свой риск и с проверкой на своих задачах.

Рычаг 3. Спуститься на квант ниже. Q5_K_M вместо Q6_K, Q4_K_M вместо Q5_K_M. Каждая ступень по нашей измеренной шкале — примерно 0,8–1,4 бита на параметр, то есть на 32B-модели около 3 ГиБ.

Цена — потеря качества ответов, и она нелинейна: разница между Q6 и Q5 почти незаметна, между Q4 и Q3 — заметна хорошо. Подробный разбор того, что именно ломается на каждой ступени, — тема отдельного материала, здесь мы даём только цифры памяти.

Рычаг 4. Выгрузить слои в оперативную память. Флаг -ngl задаёт, сколько слоёв держать в видеопамяти; всё, что не поместилось, считает процессор. Формально это позволяет запустить что угодно на чём угодно. Практически это самый дорогой рычаг из четырёх.

Два независимых сторонних замера дают представление о масштабе. На одной 14B-модели в одном и том же кванте полная работа на GPU даёт 43,18 токена в секунду, полностью на CPU — 2,89, разрыв примерно пятнадцатикратный. На RTX 4060 с 8 ГБ переход от полной загрузки к частичной выгрузке роняет скорость с 40,58 до 8,62 токена в секунду — в 4,7 раза.

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

Где выгрузка приемлема:

• Приемлема: пакетная обработка, где вы отдали задание и ушли; выгрузка одного-двух последних слоёв; MoE-модели через --n-cpu-moe, где в оперативную память едут эксперты, а не слои целиком, и потери заметно меньше.
• Неприемлема: интерактивный чат, работа ассистента в редакторе кода, любой сценарий, где вы ждёте ответ на экране. Здесь лучше взять модель на ступень меньше и получить её целиком в видеопамяти.

Общее правило по всем четырём рычагам: сначала контекст и KV-кэш, потом квант, выгрузка — последней. Первые два ничего не отнимают у качества модели, третий отнимает предсказуемо и понемногу, четвёртый убивает скорость.

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

Сверка расчёта с чужими замерами: где формула сходится и где нет

Своих карт у редакции нет, поэтому проверить формулу мы можем только сопоставлением с чужими опубликованными цифрами. Вот все точки сверки, которые удалось найти, включая расхождения.

Первые восемь строк сходятся, и это главный аргумент в пользу того, что формула рабочая. Расхождение по строке «4,5 ГБ против 4,29» объясняется просто: у источника другая восьмимиллиардная модель и в цифру, судя по формулировке, включён служебный буфер.

Две последние строки — это ошибки в топе выдачи, а не в нашем расчёте. Надбавка «+20 ГБ на 8k для 70B» завышена в восемь раз, и читатель по ней купит лишнюю карту. Утверждение «KV-кэш добавляет 5-10 процентов» верно только для очень короткого контекста: у Qwen3 32B при 32k кэш даёт 8,00 ГиБ против 18,4 ГиБ весов, то есть 43 процента.

Чего мы не проверяли и о чём поэтому не пишем: реальную скорость генерации на конкретных картах, поведение при нескольких одновременных пользователях (там KV-кэш умножается на число сессий) и точный расход на бекендах вне llama.cpp и Ollama.

Риски расчёта: движок, репозиторий кванта и платформа

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

Репозиторий кванта. Один и тот же «Q4_K_M» у разных сборщиков отличается. Пример из нашей же таблицы: Qwen3 14B в Q4_K_M — 9,0 ГБ у одного репозитория и 9,3 ГБ по данным Ollama. Три процента разницы. У динамических квантов, где точность подбирается по слоям, расхождение бывает больше. Всегда смотрите размер того файла, который скачиваете.

Версия движка. Флаги и умолчания меняются. Значения, которые мы приводим, сверены с веткой master 16 августа 2026 года: KV-кэш по умолчанию в f16, --swa-full по умолчанию false, -ngl по умолчанию auto. Через полгода что-то из этого может быть другим, и первым делом стоит перечитать документацию сервера, а не чужую статью.

Бекенд. Всё в этом материале посчитано для llama.cpp и надстроек над ним (Ollama, LM Studio). У vLLM своя модель памяти с преаллокацией под пул KV-кэша, там расчёт другой. У бекендов без поддержки скользящего окна Gemma 3 будет требовать наивные 15,50 ГиБ при 32k, а не 2,91.

Платформа. На Apple Silicon память единая, и «сколько осталось видеопамяти» — вопрос настроек, а не спецификации карты. Наши цифры по весам и кэшу там применимы, а вот колонка «карта» — нет.

Число одновременных сессий. Все расчёты сделаны на одного пользователя. KV-кэш умножается на число параллельных запросов почти линейно: четыре сессии по 32k у Qwen3 32B дают уже 32 ГиБ кэша.

Служебные буферы. Наши 1,2 ГиБ — оценка, собранная из напечатанного движком буфера вычислений (507 МиБ в разобранном логе) и неотображаемого контекста драйвера. У другой модели, другого размера батча и другой версии CUDA это число будет иным. Оставляйте запас.

Что устареет первым. Именами моделей в таблице — они меняются каждые несколько месяцев. Реальными размерами файлов — при перевыпуске квантов. Дольше всех проживёт формула: она не зависит ни от имени модели, ни от года, и требует только четырёх чисел из config.json плюс размер файла.

Где перепроверять. Материала на английском по теме на порядок больше, чем на русском, и он делится на два класса. Сводные справочники требований к видеопамяти (в англоязычной выдаче это llm vram requirements) дают готовые таблицы по моделям; интерактивные страницы вида vram llm calculator считают по вашим параметрам. Пользоваться ими стоит именно как перекрёстной проверкой, а не как ответом: почти все они берут веса по правилу «0,5 байта на параметр» и скользящее окно не учитывают — то есть воспроизводят ровно те две ошибки, ради которых написан этот материал. Расхождение с нашей таблицей больше чем на 15 процентов почти всегда объясняется одной из них.

FAQ

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

В кванте Q4_K_M такая модель весит около 4,6 ГиБ. С контекстом 8192 токена и служебными буферами получается 6,8 ГиБ. На карте 8 ГБ это работает, но впритык: свободного места останется около гигабайта, и на Windows с открытым браузером его может не хватить. На 12 ГБ конфигурация живёт спокойно и позволяет поднять контекст до 32k.

Влезет ли модель на 32 миллиарда параметров в видеокарту на 24 ГБ?

Смотря какой контекст. Qwen3 32B в Q4_K_M занимает 21,6 ГиБ при 8192 токенах и помещается. При 32 768 токенах требуется уже 27,6 ГиБ, и карта не справляется. Промежуточный вариант — оставить 32k, но перевести KV-кэш в q8_0 флагами --cache-type-k q8_0 --cache-type-v q8_0: это даёт 23,6 ГиБ, то есть работает, но без запаса на рабочий стол.

Почему модель загрузилась, а через полчаса диалога вылетела с ошибкой памяти?

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

Можно ли считать MoE-модель по активным параметрам, а не по всем?

Нет. Роутер не знает заранее, какие эксперты понадобятся на следующем токене, поэтому все веса обязаны находиться в памяти. Qwen3 30B-A3B с тремя миллиардами активных параметров весит столько же, сколько плотная тридцатимиллиардная. Активные параметры экономят вычисления и дают скорость маленькой модели, но не память. А вот KV-кэш у MoE считается по слоям и KV-головам и часто оказывается меньше, чем у плотной модели втрое меньшего размера.

Насколько безопасно квантовать KV-кэш до q8_0?

Единственный найденный замер с опубликованной методикой даёт разницу перплексии 0,0043 на Qwen 2.5 Coder 7B — величину, которая укладывается в доверительный интервал самого измерения. Экономия при этом ровно двукратная. Это замер одного участника сообщества, а не редакции, поэтому на своих задачах результат стоит проверить. Про q4_0 в том же обсуждении отзываются заметно хуже: половинить кэш безопасно, четвертовать — нет.

Считается ли оперативная память вместо видеопамяти, если модель не влезает?

Технически да: флаг -ngl в llama.cpp оставляет часть слоёв на процессоре, и запустить можно почти что угодно. Практически цена высокая и нелинейная. Сторонние замеры дают падение с 43,18 до 2,89 токена в секунду при полном переносе на процессор и с 40,58 до 8,62 при частичной выгрузке. Для пакетных задач это терпимо, для интерактивного чата — нет.

Как проверить, что мой расчёт совпал с реальностью?

llama.cpp печатает размер KV-кэша при загрузке строкой вида size = 6791.50 MiB (69632 cells, 47 layers, 1/1 seqs), K (f16): ..., V (f16): .... Сравните её со своим числом. Расхождение вдвое-вчетверо почти всегда означает, что в формулу подставлены головы внимания вместо KV-голов. Расхождение в разы в меньшую сторону — что у модели скользящее окно внимания.