Вимоги LLM до VRAM: Зведена таблиця 2026 (кожна модель, кожен квант)

Вимоги LLM до VRAM: Зведена таблиця 2026 (кожна модель, кожен квант)

Ось число, яке завжди застає зненацька: DeepSeek-V3.2 має 671 мільярд параметрів, але для обробки будь-якого конкретного токена активуються лише 37 мільярдів. Тож скільки відеопам’яті (VRAM) йому дійсно потрібно? Усі 671 мільярд, тобто приблизно 382 ГБ у форматі Q4. Вимоги LLM до VRAM рідко підкоряються інтуїції, і саме розрив між «активними параметрами» та «тим, що потрібно завантажити», стає причиною різкого зростання бюджетів на обладнання. Цей посібник надає вам зведену таблицю (усі основні відкриті моделі, усі рівні квантування, обсяг у ГБ та необхідна GPU), а також формулу, щоб за десять секунд самостійно розрахувати вимоги для будь-якої моделі.

Ключові висновки

• VRAM для ваг ≈ кількість параметрів × байтів на параметр: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Додайте пам’ять для KV-кешу та ~15–20% накладних витрат.
• Моделі зі змішуванням експертів (MoE), такі як DeepSeek, GLM-5.2, Qwen3-235B, повинні завантажувати кожного експерта у VRAM. «Активні параметри» дають швидкість, але не економлять пам’ять.
• KV-кеш — це прихована вартість. Llama 3.3 70B потребує близько 2.6 ГБ кешу при контексті 8K і приблизно 41 ГБ при 128K, поверх ваг моделі.
• Q4_K_M — розумний вибір за замовчуванням: якість майже повна, а розмір становить чверть від FP16.
• Модель на 12B, як-от Gemma 4, поміщається на карту 8 ГБ у форматі Q4. Щільна модель на 70B потребує близько 40 ГБ. Флагманська MoE на 671B вимагає невеликого сервера.

Вимоги LLM до VRAM по моделях: Зведена таблиця

Коротка відповідь: у форматі Q4_K_M малі моделі (до 14B) поміщаються на споживчі карти 8–12 ГБ, середні моделі (24–32B) потребують 16–24 ГБ, щільна модель на 70B потребує близько 40 ГБ, а флагманські MoE-моделі стрибують у сотні гігабайт, оскільки кожен експерт має бути резидентним у пам’яті. Ось повна картина в одному місці. Усі цифри стосуються лише пам’яті для ваг, обчислені на основі кількості параметрів кожної моделі та перехресно перевірені за офіційними картками моделей від Meta AI, Qwen та Hugging Face.

З цієї таблиці можна зробити два важливі висновки. По-перше, квантування — це найпотужніший інструмент: перехід з FP16 на Q4 зменшує розмір приблизно в 4 рази з ледь помітною втратою якості. По-друге, рядки MoE виглядають суворо, бо такими й є. Qwen3-30B-A3B активує лише 3B параметрів на токен, тому працює зі швидкістю крихітної моделі, але вам все одно потрібно тримати всі 30B у пам’яті, щоб мати готовими всіх експертів. Хочете дізнатися деталі по кожній моделі? Наші статті поглиблений огляд Gemma 4 12B та найкращі відкриті LLM 2026 року охоплюють бенчмарки та ліцензії.

Формула VRAM: Розрахуйте будь-яку модель самостійно

Щоб визначити розмір будь-якої моделі, помножте кількість її параметрів на кількість байтів на параметр для вашого рівня квантування, а потім додайте трохи пам’яті для KV-кешу та накладних витрат виконання. Це все. Ваги є домінуючим фактором, а арифметика достатньо проста, щоб її можна було зробити «на серветці».

Основне рівняння для ваг:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Необхідні значення бітів на вагу (це ефективні показники для файлів GGUF k-quant, які мають додаткові метадані блоків поверх номінальної глибини бітів):

Приклад розрахунку для Gemma 4 12B у форматі Q4_K_M: 11.95 × 4.5 ÷ 8 = близько 6.7 ГБ для ваг. Це узгоджується з приблизно 6.6 ГБ, зазначеними в офіційній картці моделі, і пояснює, чому вона поміщається на карту 8 ГБ із запасом для скромного контексту. Застосуйте ту саму математику до моделі 70B у форматі Q4, і ви отримаєте 70 × 4.5 ÷ 8 = 39.4 ГБ, ось чому правило «вам потрібні дві карти по 24 ГБ або одна на 48 ГБ для 70B» є загальноприйнятим.

Повна картина включає ще два доданки: загальна VRAM ≈ ваги + KV-кеш + ~15–20% накладних витрат. Накладні витрати покривають буфери активації, контекст CUDA та фрагментацію пам’яті, а ваша GPU також резервує півгігабайта або близько того для драйвера, тому ніколи не плануйте використовувати 100% заявленої VRAM.

Чому KV-кеш — це число, яке вас вкусить

KV-кеш зберігає ключі та значення уваги для кожного токена, вже наявного в контексті, і зростає лінійно зі збільшенням довжини контексту. При коротких запитах це похибка округлення. Але якщо перейти до довгого контексту, він може зрівнятися з вагою моделі або навіть перевищити її. Це найпоширеніша причина, чому модель, яка «має поміститися», видає помилку нестачі пам’яті (OOM) прямо під час генерації.

Формула на один токен:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Візьмемо Llama 3.3 70B: 80 шарів, 8 голів KV, розмір голови 128, отже kv_dim дорівнює 1024. У форматі FP16 це 80 × 2 × 1024 × 2 = 327 680 байт на токен, близько 0.31 МБ. Помножте на довжину контексту, і картина стане ясною: при 8K токенів кеш займає близько 2.6 ГБ, при 32K — близько 10 ГБ, а при 128K роздувається до приблизно 41 ГБ. Остання цифра додається до 40 ГБ ваг, тож «модель на 40 ГБ» тихо перетворюється на проблему на 80 ГБ, як тільки ви заповните вікно контексту.

Два практичні шляхи вирішення. Групована query-увага (яку використовують усі сучасні моделі) вже значно зменшує kv_dim порівняно зі старою багатоголовою архітектурою, тому сучасні моделі тут набагато економніші, ніж Llama 2. Крім того, більшість рушіїв інференсу можуть квантувати KV-кеш до 8-біт або 4-біт формату, зменшуючи його розмір удвічі або вчетверо за невелику ціну втрати якості. Якщо ви обслуговуєте довгі контексти у продакшені, порівняння vLLM проти SGLang показує, який бекенд найефективніше керує цією пам’яттю завдяки сторінковій увазі.

Моделі MoE: Чому «активні параметри» не економлять VRAM

Це пастка, яка коштує людям найбільше грошей. Модель зі змішуванням експертів (MoE), така як DeepSeek-V3.2 (671B всього, 37B активних, архітектура V3) або GLM-5.2 (744B всього, 40B активних), маршрутизує кожен токен через невелику підмножину своїх експертів. Маркетинг робить акцент на активних параметрах, бо вони описують швидкість: ви платите лише за обчислення 37B параметрів на токен, тому інференс швидкий для такого розміру моделі. Але кожен експерт має сидіти в пам’яті, готовий до вибору, що означає: ваш бюджет VRAM визначається загальною кількістю параметрів, а не активною.

Отже, чесне читання таблиці вище: GLM-5.2 працює зі швидкістю моделі на 40B, але займає пам’ять моделі на 744B. Ось чому цим передовим відкритим моделям потрібен сервер з 8 GPU або машина з великою об’єднаною пам’яттю, хоча один прямий прохід (forward pass) коштує дешево. Qwen3-235B-A22B має таку ж структуру в меншому масштабі: швидка на токен, важка для хостингу.

Перевага MoE проявляється на обладнанні з об’єднаною пам’яттю. Mac Studio з 512 ГБ об’єднаної пам’яті може утримувати модель на 671B у форматі Q4 і все ще запускати її з прийнятною швидкістю саме тому, що активуються лише 37B, тому вимоги до пропускної здатності пам’яті на токен залишаються розумними. Якщо ви новачок у локальному запуску таких моделей, почніть з нашого посібника з налаштування локального LLM, перш ніж витрачати гроші на обладнання.

Яке квантування обрати?

Для майже всіх Q4_K_M є правильним вибором за замовчуванням: воно зберігає якість, близьку до повної, скорочуючи розмір FP16 приблизно в 4 рази. Переходьте на Q5_K_M або Q8 лише якщо у вас є зайва VRAM і задача, чутлива до якості, а до FP16 звертайтеся лише під час фінального налаштування (fine-tuning) або бенчмаркінгу щодо еталону. Нижче Q4 деградація якості стає помітною швидко, тому Q3 і нижче — це крайній захід, щоб втиснути модель на карту, яка справді занадто мала.

Одне застереження: якість квантування не однакова для всіх моделей. Дуже малі моделі (менше 4B) сильніше відчувають вплив Q4, ніж великі, бо мають менше надлишковості. На моделі 70B різницю між Q4 та Q8 важко помітити на більшості задач. На моделі 1.7B розрив реальний.

Яка GPU вам дійсно потрібна?

Зіставте стовпець Q4 із зведеної таблиці з картою, маючи невеликий запас для KV-кешу. Ось практичне співвідношення від бюджетного споживчого обладнання до дата-центру, із зазначенням рівня моделей, які кожен клас комфортно запускає у форматі Q4.

Apple Silicon заслуговує на окрему згадку, бо об’єднана пам’ять змінює розрахунки. Mac не розділяє VRAM і системну RAM, тому машина M-series на 128 ГБ може завантажувати моделі, для яких знадобилося б кілька дискретних GPU, жертвуючи піковою пропускною здатністю заради можливості вмістити величезні ваги на одному десктопі. Щодо бекендів, які вичавлюють максимум з будь-якої з цих карт, наш огляд найкращих інструментів для локального запуску LLM порівнює реальні швидкості.

Як ми розраховуємо VRAM для клієнтських деплоїв

У Techsy ми досить часто розгортаємо відкриті моделі для клієнтів, тому розрахунок VRAM стає першою темою розмови, ще до вибору моделі, промптів чи будь-чого іншого. Наш метод навмисно нудний, бо режим відмови (OOM у продакшені під реальним навантаженням контексту) коштує дорого. Ось процес, який ми реально використовуємо.

Ми починаємо з математичної таблиці, а потім вимірюємо. Після завантаження моделі ми перевіряємо реальний резидентний слід, а не покладаємося на оцінку:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

Урок, який повторюється знову і знову: команди розраховують пам’ять лише для ваг і забувають про KV-кеш, а потім дивуються, чому модель, яка нормально завантажилася, падає після трьох довгих запитів під час демо. Ми розраховуємо пам’ять для ваг плюс KV-кеш при максимальному контексті, який додаток дійсно використовуватиме, плюс запас, і обмежуємо --ctx-size, щоб неконтрольований запит не викликав OOM на сервері. Для будь-якого клієнтського інтерфейсу ми воліємо запускати квантовану 32B, яка ніколи не падає, ніж FP16 70B, яка отримує OOM під навантаженням.

Якщо ви вагаєтеся між самостійним хостингом відкритої моделі та використанням hosted API, цей компроміс (вартість обладнання та операційне навантаження проти ціни за токен і контролю) — це саме те, що наша команда оцінює під час проєкту з інтеграції ШІ. Якщо вам допоможе, коли хтось прорахує цифри під ваше реальне навантаження, отримайте безкоштовну консультацію, і ми разом усе порахуємо.

Про автора

Мерт Батур Гюрбуз — співзасновник Techsy.io, де команда постачає ШІ-агентів, системи автоматизації та голосові/SDR пайплайни для B2B-клієнтів. Він навчається в Університеті Бірмінгема і пише про стек інструментів LLM, який команда Techsy реально використовує у продакшені.

Кваліфікація: Співзасновник, Techsy.io, Університет Бірмінгема. Слідкуйте на LinkedIn.

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

Скільки VRAM потрібно для запуску моделі 70B?

Щільна модель 70B, така як Llama 3.3 70B, потребує близько 40 ГБ VRAM для ваг у форматі Q4_K_M, тому плануйте карту на 48 ГБ (RTX 6000 Ada) або дві карти по 24 ГБ. Додайте ще кілька гігабайт для KV-кешу, якщо використовуєте довгий контекст, що підвищує практичні вимоги до 48 ГБ і більше.

Скільки VRAM потрібно Llama, Qwen або DeepSeek?

Це повністю залежить від варіанту. Llama 4 Scout потребує близько 62 ГБ у форматі Q4, Qwen3-32B — близько 18 ГБ, а Qwen3-8B — менше 5 ГБ. DeepSeek-V3.2, MoE на 671B, потребує приблизно 382 ГБ, оскільки кожен експерт має завантажитися. Для MoE-моделей завжди перевіряйте загальну кількість параметрів, а не активну.

Чи можу я запустити LLM на GPU з 8 ГБ?

Так, комфортно. Карта на 8 ГБ, така як RTX 4060, запускає моделі до приблизно 12B параметрів у форматі Q4_K_M. Gemma 4 12B займає близько 6.8 ГБ, залишаючи місце для скромного контексту. Для всього більшого доведеться або сильніше квантувати, або скорочувати контекст, або переходити на більшу карту.

Що може запустити GPU на 24 ГБ, як-от RTX 4090?

Карта на 24 ГБ обробляє щільні моделі до приблизно 32B у форматі Q4_K_M із запасом для розумного контексту, тож Qwen3-32B та Mistral Small 3.2 24B працюють комфортно. Вона також запускає MoE Qwen3-30B-A3B, яка завантажує 30B ваг, але генерує зі швидкістю моделі 3B завдяки розрідженій активації.

Чи погіршує квантування якість моделі?

У форматі Q4_K_M і вище втрата якості мала і часто непомітна на реальних задачах, особливо для моделей понад 13B. Розрив збільшується, коли ви опускаєтеся нижче, і коли моделі стають меншими, тому Q4 на 70B майже безкоштовний, тоді як Q4 на 1.7B помітний. Q8 практично без втрат, якщо у вас є пам’ять.

Чи потребують MoE-моделі менше VRAM, ніж щільні?

Ні, і це найпоширеніша помилка. Модель зі змішуванням експертів повинна тримати кожного експерта у VRAM, тому її пам’ять визначається загальною кількістю параметрів. Показник активних параметрів описує лише швидкість інференсу. GLM-5.2 працює зі швидкістю моделі 40B, але потребує пам’яті моделі 744B.

Чи є об’єднана пам’ять тим самим, що й VRAM?

Функціонально, для завантаження моделей, так. Apple Silicon та деякі інші системи використовують один пул пам’яті для CPU та GPU, тому Mac на 128 ГБ може завантажувати моделі, для яких інакше знадобилося б кілька дискретних GPU. Компроміс — пропускна здатність: об’єднана пам’ять зазвичай забезпечує нижчу пікову продуктивність, ніж висококласна GPU дата-центру, тому кількість токенів за секунду буде нижчою.

Чи можу я розвантажити частину моделі в системну RAM або на CPU?

Так. Рушії, такі як llama.cpp та Ollama, дозволяють тримати деякі шари на GPU, а решту — в системній RAM, використовуючи прапорець на кшталт --n-gpu-layers. Це дозволяє запускати модель, занадто велику для вашої VRAM, але кожен шар на CPU різко уповільнює генерацію, тому використовуйте це, щоб зробити модель можливою, а не швидкою.

Як розрахувати VRAM для моделі, якої немає в таблиці?

Помножте кількість параметрів у мільярдах на кількість бітів на вагу для вашого квантування, а потім поділіть на 8. Для Q4_K_M використовуйте приблизно 4.5 біта, тож модель 40B потребує 40 × 4.5 ÷ 8 = близько 22.5 ГБ для ваг. Додайте приблизно 15–20% накладних витрат плюс ваш KV-кеш для реального розрахунку.