Відеопам’ять під 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 на 8–32 ГБ

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 відсотків майже завжди пояснюється однією з них.

Часті запитання

Скільки відеопам’яті потрібно для моделі на 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-голів. Розбіжність у рази в менший бік — що в моделі ковзне вікно уваги.