Залізо для локальних LLM у 2026: VRAM, пропускна здатність пам'яті, квантизація

Щоб запустити open-weight мовну модель локально, пристрою, який виконує обчислення, потрібно достатньо швидкої пам'яті для трьох речей: квантизованих ваг, KV-кешу під вашу довжину контексту й кількість одночасних запитів, а також запасу для середовища виконання. Обсяг пам'яті визначає, які моделі вмістяться, пропускна здатність пам'яті визначає швидкість генерації тексту, а обчислювальна потужність визначає швидкість читання довгих промптів. Спрощено: GPU на 16 ГБ добре впорається з моделями класу 8B, 24–32 ГБ вистачає для моделей класу 32B у 4-бітній квантизації, а моделям класу 70B потрібно приблизно 48 ГБ і більше, тобто карта для робочої станції, два GPU або машина з єдиною пам'яттю.

Формула пам'яті

Будь-який розрахунок починається з однієї суми:

memory ≈ weights + KV cache + runtime overhead

weights  = parameters × bits per weight / 8
KV cache = 2 × layers × kv_heads × head_dim × bytes per element × tokens in flight

Моделі з 70,6 млрд параметрів потрібно близько 141 ГБ під ваги при 16 бітах і близько 42 ГБ при 4,8 біта на вагу.

KV-кеш зберігає ключі й значення уваги для кожного токена, який модель тримає в контексті, тому він зростає з кожним токеном промпту й відповіді. Множник 2 враховує ключі та значення, а решта величин береться з config.json моделі: num_hidden_layers, num_key_value_heads і head_dim. Більшість сучасних моделей використовують grouped-query attention, де KV-голів значно менше, ніж голів запитів.

Накладні витрати середовища виконання охоплюють контекст CUDA, ROCm або Metal та обчислювальні буфери. Закладайте 1–2 ГіБ на пристрій для llama.cpp, чиє автоматичне розміщення за замовчуванням залишає запас 1024 МіБ на пристрій, і більше для серверів, які заздалегідь резервують пам'ять під великі батчі. На машинах з єдиною пам'яттю залиште місце й для операційної системи.

KV-кеш зростає з контекстом і паралельністю

Вартість одного токена прямо випливає з конфігурації:

Llama 3.1 8B:   2 × 32 layers × 8 kv_heads × 128 head_dim × 2 bytes = 128 KiB per token
Qwen3-32B:      2 × 64 layers × 8 kv_heads × 128 head_dim × 2 bytes = 256 KiB per token
Llama 3.3 70B:  2 × 80 layers × 8 kv_heads × 128 head_dim × 2 bytes = 320 KiB per token

При 32 768 токенах це 4, 8 і 10 ГіБ для 16-бітного кешу. При 131 072 токенах кеш моделі 70B сягає 40 ГіБ, тобто стільки ж, скільки її 4-бітні ваги.

Паралельні запити множать кеш: чотирьом користувачам із діалогами по 16K токенів потрібно стільки ж, скільки одному діалогу на 64K. vLLM формує пул KV з пам'яті, що лишилася після завантаження ваг, а llama-server ділить один бюджет контексту (-c) між слотами (--parallel). У посібнику із серверів локального інференсу LLM розібрано, як кожен сервер розподіляє цей пул.

Зменшити кеш можна двома способами. 8-бітний кеш, -ctk q8_0 -ctv q8_0 у llama.cpp або --kv-cache-dtype fp8 у vLLM, скорочує його приблизно вдвічі, а обмеження контексту реально потрібною довжиною нічого не коштує. Sliding-window, гібридна увага та multi-head latent attention зберігають менше даних на токен, тому звіряйтеся з розміром KV-буфера, який llama.cpp виводить під час завантаження моделі.

Розрахунок для моделей 8B, 32B і 70B

Документація llama.cpp з квантизації наводить кількість біт на вагу, виміряну на Llama 3.1 8B: Q8_0 — 8,50, Q6_K — 6,56, Q5_K_M — 5,70, Q4_K_M — 4,89, IQ4_XS — 4,46 і Q3_K_M — 4,00. У більших моделей значення трохи нижчі: опубліковані файли Q4_K_M для Qwen3-32B і Llama 3.3 70B дають близько 4,8. Цей скрипт застосовує формулу для контексту 32K і накладних витрат 1,5 ГіБ:

GiB = 2**30

def weights_gib(params, bits_per_weight):
    return params * bits_per_weight / 8 / GiB

def kv_gib(layers, kv_heads, head_dim, tokens, bytes_per_elem=2):
    return 2 * layers * kv_heads * head_dim * bytes_per_elem * tokens / GiB

models = {
    "Llama 3.1 8B": (8.03e9, 32),
    "Qwen3-32B": (32.76e9, 64),
    "Llama 3.3 70B": (70.55e9, 80),
}

for name, (params, layers) in models.items():
    kv = kv_gib(layers, 8, 128, 32768)
    for quant, bpw in (("BF16", 16.0), ("Q8_0", 8.5), ("Q4_K_M", 4.85)):
        w = weights_gib(params, bpw)
        print(f"{name:14} {quant:7} weights {w:6.1f} GiB  KV@32K {kv:5.1f} GiB  total {w + kv + 1.5:6.1f} GiB")

Llama 3.1 8B   BF16    weights   15.0 GiB  KV@32K   4.0 GiB  total   20.5 GiB
Llama 3.1 8B   Q8_0    weights    7.9 GiB  KV@32K   4.0 GiB  total   13.4 GiB
Llama 3.1 8B   Q4_K_M  weights    4.5 GiB  KV@32K   4.0 GiB  total   10.0 GiB
Qwen3-32B      BF16    weights   61.0 GiB  KV@32K   8.0 GiB  total   70.5 GiB
Qwen3-32B      Q8_0    weights   32.4 GiB  KV@32K   8.0 GiB  total   41.9 GiB
Qwen3-32B      Q4_K_M  weights   18.5 GiB  KV@32K   8.0 GiB  total   28.0 GiB
Llama 3.3 70B  BF16    weights  131.4 GiB  KV@32K  10.0 GiB  total  142.9 GiB
Llama 3.3 70B  Q8_0    weights   69.8 GiB  KV@32K  10.0 GiB  total   81.3 GiB
Llama 3.3 70B  Q4_K_M  weights   39.8 GiB  KV@32K  10.0 GiB  total   51.3 GiB

Модель 8B у Q4_K_M вміщується на карту 12 ГБ, а в Q8_0 — на карту 16 ГБ, тож на 16 ГБ немає причин через обсяг опускатися нижче Q6_K. Моделі 32B у Q4_K_M з повним кешем на 32K потрібна карта 32 ГБ; на 24 ГБ вона вміщується з контекстом 16K і 8-бітним кешем, займаючи близько 22 ГіБ. Моделі 70B у Q4_K_M потрібно близько 51 ГіБ: два GPU по 32 ГБ, карта для робочої станції на 72 або 96 ГБ чи 64 ГБ єдиної пам'яті й більше. Карта на 48 ГБ запускає її з контекстом близько 8K, а для Q8_0 потрібна карта на 96 ГБ або 128 ГБ єдиної пам'яті.

Формати квантизації та їхня ціна

Квантизація зберігає ваги меншою кількістю біт плюс масштаби для кожного блока. Вона економить пам'ять і прискорює генерацію, але додає похибку.

K-quants та I-quants у GGUF

GGUF — формат файлів llama.cpp, його також використовують Ollama і LM Studio. K-quants, наприклад Q4_K_M і Q6_K, квантизують ваги блоками й залишають чутливі тензори в точнішому типі. I-quants, наприклад IQ4_XS, пакують ваги щільніше. Обидві родини виграють від матриці важливості (imatrix), розрахованої на калібрувальному тексті, а документація llama.cpp вимірює їхні втрати через perplexity і дивергенцію Кульбака — Лейблера. GGUF працює на CUDA, ROCm, Vulkan, Metal і CPU, тому це найпереносніший варіант.

8 біт і FP8

Q8_0 — 8-бітний тип GGUF. На GPU-серверах стандартний 8-бітний формат — FP8. Згідно з документацією vLLM щодо FP8, обчислення FP8 потребують NVIDIA compute capability 8.9 або вище (Ada Lovelace, Hopper, Blackwell), старіші GPU переходять на weight-only ядра W8A16, а FP8 удвічі скорочує пам'ять моделі за зростання пропускної здатності до 1,6 раза й мінімального впливу на точність.

AWQ, GPTQ і 4-бітна рухома кома

AWQ і GPTQ — 4-бітні weight-only методи для GPU-серверів, як-от vLLM і SGLang. Вони калібрують масштаби для груп ваг, залишають активації в 16 бітах, і багато авторів моделей публікують такі версії самі, наприклад Qwen/Qwen3-32B-AWQ. GPU Blackwell додають апаратну математику FP4, а моделі gpt-oss від OpenAI зберігають ваги експертів у MXFP4.

Скільки якості ви втрачаєте

8-бітні формати зазвичай важко відрізнити від BF16. Q6_K і Q5_K_M дають невелике, але вимірюване зростання perplexity і лишаються безпечним вибором, якщо дозволяє пам'ять. 4 біти — звичний компроміс: втрати вимірювані, і найпомітніші вони там, де важать дрібні помилки: у коді, математиці та точному вилученні фактів із довгого контексту. Нижче 4 біт похибка швидко зростає, причому малі моделі страждають сильніше за великі. Більша модель у 4 бітах часто перевершує меншу у 8 бітах за того самого обсягу пам'яті, але перевіряйте це на своїх задачах, як описано в посібнику з оцінювання AI-агентів.

Пропускна здатність задає швидкість генерації, обчислення — швидкість промпту

Генерація одного токена щільною моделлю читає кожну вагу один раз, плюс KV-кеш поточного контексту. За розміру батча 1 переміщення даних домінує, тому стеля рахується просто:

decode tokens/s ≤ memory bandwidth / bytes read per token
bytes read per token ≈ weight bytes (dense) or active-expert bytes (MoE) + KV cache bytes at current depth

Файл Llama 3.3 70B Q4_K_M займає 42,5 ГБ, тож стеля становить близько 42 токенів на секунду при 1792 ГБ/с, 14 при 614 ГБ/с і 6 при 256 ГБ/с. Файл 8B Q4_K_M (4,9 ГБ) отримує близько 91 токена на секунду при 448 ГБ/с. Реальні середовища виконання працюють нижче цих стель і сповільнюються зі зростанням контексту: на 32K кеш моделі 70B додає близько 10,7 ГБ читання на кожен токен.

Таблиця квантизації llama.cpp показує цю закономірність на одній машині з Llama 3.1 8B: генерація зростає приблизно з 29 токенів на секунду у F16 до 51 у Q8_0 і 72 у Q4_K_M, а обробка промпту для всіх типів лишається в діапазоні приблизно від 700 до 920 токенів на секунду.

Обробка промпту йде батчами по сотні токенів, тому кожне читання ваги обслуговує багато токенів, і обмеженням стає матрична продуктивність. Обсяг роботи — приблизно 2 × parameters × prompt tokens операцій, тобто близько 5 × 10^14 для промпту на 8000 токенів у моделі 32B. Від цього залежить час до першого токена в retrieval-augmented generation, де промпт несе знайдені фрагменти, як у схемі гібридного пошуку на pgvector, і в агентів для коду, які надсилають великі файли. Дивіться на обидві характеристики: у NVIDIA DGX Spark скромна стеля генерації при 273 ГБ/с, але NVIDIA оцінює її чип GB10 до 1 PFLOP розріджених обчислень FP4.

Батчинг обслуговує багато послідовностей за одне читання ваг, тому пропускна здатність сервера зростає, доки не закінчаться обчислення або кеш. Циклам агентів, навпаки, важлива затримка одного запиту, бо кожен крок чекає на попередній виклик, як описано в посібнику з архітектури production AI-агента.

Моделі mixture-of-experts (MoE) розділяють ці обмеження: пам'ять визначається загальною кількістю параметрів, а швидкість генерації — кількістю активних. У gpt-oss-120b 117 млрд параметрів, з них 5,1 млрд активних, і в її картці моделі сказано, що вона вміщується на один GPU з 80 ГБ; її файл MXFP4 GGUF займає 63,4 ГБ. gpt-oss-20b працює в межах 16 ГБ. Тому машини з великим обсягом і помірною пропускною здатністю лишаються корисними.

Варіанти обладнання за можливостями

GPU NVIDIA за класами VRAM

GPU NVIDIA мають найширшу підтримку з боку середовищ виконання, бо vLLM, SGLang, TensorRT-LLM і llama.cpp вважають CUDA еталонною платформою. Спочатку порівнюйте обсяг, потім пропускну здатність усередині класу: карти GeForce на 16 ГБ запускають ті самі моделі, але в RTX 5080 пропускна здатність більш ніж удвічі вища, ніж у RTX 5060 Ti. RTX PRO 6000 Blackwell вміщує модель 70B у 8 бітах на одній карті. Карти GeForce RTX 50 не підтримують NVLink, тому обмін між кількома GPU йде через PCIe.

Єдина пам'ять: Apple Silicon, Ryzen AI Max, DGX Spark

Системи з єдиною пам'яттю дають CPU і GPU спільний пул LPDDR: значно більше пам'яті під модель, ніж у споживчих GPU, але з меншою пропускною здатністю, ніж у швидкої карти GDDR7, за винятком старшого чипа Apple. Для Mac Studio Apple пропонує M5 Ultra від 96 ГБ, повідомляє, що конфігурація на 512 ГБ з'явиться наприкінці жовтня, і підтримує кластеризацію через Thunderbolt 5 з RDMA; серед середовищ виконання — llama.cpp на Metal і MLX. Ryzen AI Max+ 395 від AMD використовує 256-бітний інтерфейс LPDDR5x-8000, що дає 256 ГБ/с, а Ryzen AI Max+ PRO 495 переходить на LPDDR5x-8533, і системи OEM заявлено на третій квартал 2026 року; llama.cpp працює на обох через ROCm або Vulkan. NVIDIA DGX Spark використовує стек CUDA й має порт ConnectX-7 на 200 Гбіт/с для об'єднання пристроїв.

За формулою стелі такі машини запускають щільні моделі 70B зі швидкістю від одиниць до кількох десятків токенів на секунду, а моделі MoE — значно швидше. Їхні GPU працюють у значно меншому бюджеті потужності, ніж карта на 575 Вт, тому вимірюйте час до першого токена на реальних промптах.

Платформа	Пам'ять для моделі	Пропускна здатність	Потужність	Щільна модель за контексту 32K
GeForce RTX 5060 Ti 16 GB	16 ГБ GDDR7	448 ГБ/с	180 Вт	8B у Q8_0
GeForce RTX 5070 Ti / 5080	16 ГБ GDDR7	896 / 960 ГБ/с	300 / 360 Вт	8B у Q8_0
GeForce RTX 5090	32 ГБ GDDR7	1792 ГБ/с	575 Вт	32B у Q4_K_M
RTX PRO 4000 / 4500 Blackwell	24 / 32 ГБ GDDR7 ECC	672 / 896 ГБ/с	145 / 200 Вт	32B у 4 бітах
RTX PRO 5000 Blackwell	48 або 72 ГБ GDDR7 ECC	1344 ГБ/с	300 Вт	32B у Q8_0, 70B у Q4_K_M на 72 ГБ
RTX PRO 6000 Blackwell	96 ГБ GDDR7 ECC	1792 ГБ/с	600 Вт або 300 Вт (Max-Q)	70B у Q8_0
DGX Spark	128 ГБ LPDDR5x	273 ГБ/с	блок живлення 240 Вт	70B у Q8_0
Ryzen AI Max+ 395	128 ГБ, до 96 ГБ для графіки	256 ГБ/с	45–120 Вт	70B у Q6_K
Ryzen AI Max+ PRO 495	192 ГБ, до 160 ГБ для графіки	близько 273 ГБ/с	45–120 Вт	70B у Q8_0
Mac Studio, M5 Max	до 128 ГБ	до 614 ГБ/с	максимум системи 480 Вт	70B у Q8_0
Mac Studio, M5 Ultra	до 512 ГБ	1,2 ТБ/с	максимум системи 480 Вт	70B у BF16

Остання колонка випливає з розрахунків вище для одного користувача. Таблиця описує можливості, а не співвідношення ціни та якості.

Кілька GPU та вивантаження на CPU

Два GPU подвоюють обсяг, але швидкість залежить від способу поділу. За поділу за шарами, режиму llama.cpp за замовчуванням, кожен GPU зберігає діапазон шарів і їхній KV-кеш, а за батча 1 GPU працюють по черзі: обсяг більший, швидкість генерації та сама. На кожен токен через PCIe проходять лише невеликі активації, тому лінків x8 або x4 достатньо. За тензорного паралелізму (--tensor-parallel-size 2 у vLLM) обидва GPU одночасно читають свою частку кожного шару, що піднімає стелю, але кожен шар синхронізується через PCIe. Тензорний паралелізм vLLM розрахований на однакові GPU, а кількість GPU має ділити кількість голів уваги моделі.

Вивантаження на CPU залишає частину шарів у системній пам'яті, і їх виконує процесор. Час на токен стає сумою: байти на GPU, поділені на пропускну здатність VRAM, плюс байти на CPU, поділені на пропускну здатність RAM. Двоканальна DDR5-6000 теоретично дає 96 ГБ/с (2 канали × 8 байт × 6000 MT/s), а в посібнику з пам'яті DDR5 розібрано, як поєднуються канали й частоти. Модель 70B Q4_K_M, у якої 24 ГБ на GPU і 18,5 ГБ у RAM, не перевищить 5 токенів на секунду. Вивантаження розв'язує проблему обсягу, а не швидкості.

Моделі MoE вивантажуються значно краще. --cpu-moe і --n-cpu-moe N тримають ваги експертів у RAM, а увага й KV-кеш лишаються на GPU, і на кожен токен читаються лише активні експерти. Свіжі збірки llama.cpp самі підбирають кількість шарів, якщо -ngl не задано (--fit увімкнено за замовчуванням); задавайте його явно, коли потрібні відтворювані результати. Команди нижче показують частково вивантажену щільну модель, модель MoE з експертами в RAM і поділ за шарами з перевагою на користь більшого GPU:

llama-server -m Llama-3.3-70B-Instruct-Q4_K_M.gguf -c 16384 -ngl 48 -fa on

llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 32768 -ngl all --n-cpu-moe 24 -fa on

llama-server -m Qwen_Qwen3-32B-Q8_0.gguf -c 32768 -ngl all --split-mode layer --tensor-split 3,2

Живлення, охолодження, лінії PCIe і системна пам'ять

Для GeForce RTX 5090 NVIDIA вказує 575 Вт графічної потужності та 1000 Вт потрібної потужності системи. Версія RTX PRO 6000 Max-Q на 300 Вт зберігає той самий обсяг пам'яті, що й модель на 600 Вт, і це важливо, якщо в одному корпусі буде кілька карт. Оскільки генерація чекає на пам'ять, перевірте знижений ліміт через nvidia-smi -pl і залиште значення, за якого швидкість генерації майже не змінюється.

Інференс — тривале навантаження, а дві карти з відкритим охолодженням у сусідніх слотах ганяють одна одній гаряче повітря. Перевіряйте частоти, температуру й потужність під час 30-хвилинного прогону.

Карти GeForce RTX 50 і RTX PRO Blackwell використовують PCIe 5.0 x16. Споживчі настільні платформи зазвичай дають один графічний лінк x16, який деякі плати ділять на x8/x8, а слот від чипсета часто працює в режимі x4. Поділ за шарами це витримує; тензорному паралелізму й завантаженню моделей краще x8 і ширше, що дають платформи робочих станцій. Показане покоління лінку може знижуватися, поки GPU простоює, тому перевіряйте його під навантаженням.

Системної пам'яті має бути не менше, ніж найбільший файл моделі, який ви завантажуєте, плюс місце для ОС, і значно більше, якщо ви вивантажуєте шари. Файли моделей займають від 5 ГБ до понад 100 ГБ, тому швидкий накопичувач скорочує час завантаження; про цей сценарій розповідає посібник з вибору NVMe SSD.

nvidia-smi --query-gpu=name,pcie.link.gen.current,pcie.link.width.current,power.draw,memory.used --format=csv -l 1

nvidia-smi dmon -s pucvmt -d 1

sudo nvidia-smi -pl 450

Виміряйте власну швидкість

Опубліковані цифри рідко збігаються з вашим файлом моделі, контекстом, драйвером і версією середовища виконання, тому вимірюйте самі й порівнюйте з формулою стелі. У llama-bench параметр -p задає довжину промпту, -n — кількість згенерованих токенів, а -d заздалегідь заповнює KV-кеш до заданої глибини й показує, як падає швидкість зі зростанням діалогу. Друга команда порівнює 16-бітний і 8-бітний кеш:

llama-bench -m Qwen_Qwen3-32B-Q4_K_M.gguf -p 512,4096 -n 128 -d 0,16384 -fa on -r 3 -o md

llama-bench -m Qwen_Qwen3-32B-Q4_K_M.gguf -p 4096 -n 128 -d 16384 -ctk f16,q8_0 -ctv f16,q8_0 -fa on

Потім перевірте паралельне навантаження. vllm bench serve працює з OpenAI-сумісними endpoint і показує час до першого токена, час на вихідний токен, затримку між токенами та загальну пропускну здатність:

vllm serve Qwen/Qwen3-32B-AWQ --max-model-len 32768

vllm bench serve --backend openai --base-url http://127.0.0.1:8000 --model Qwen/Qwen3-32B-AWQ --dataset-name random --random-input-len 4096 --random-output-len 256 --num-prompts 200 --max-concurrency 8

Поділіть виміряну швидкість одного потоку на стелю. Якщо співвідношення незвично низьке, шукайте шари, непомітно вивантажені на CPU, лінк PCIe зі зменшеною шириною, тротлінг або повільний backend.

Чеклист підбору

• Випишіть із config.json кількість параметрів, шарів, KV-голів і розмірність голови.
• Оберіть квантизацію: 8 біт, якщо вміщується, потім Q6_K або Q5_K_M, потім 4 біти, а нижче лише після перевірки.
• Задайте контекст і кількість паралельних запитів, порахуйте KV-кеш і вирішіть, чи прийнятний 8-бітний кеш.
• Додайте 1–2 ГіБ на пристрій і запас для ОС на єдиній пам'яті.
• Відкиньте платформи, у яких стеля генерації нижча за потрібну вам швидкість.
• Для довгих промптів із RAG або агентів для коду враховуйте обчислення й вимірюйте час до першого токена.
• Для MoE рахуйте пам'ять за загальною кількістю параметрів, а швидкість за активними.
• Перевірте живлення, охолодження, лінії PCIe, RAM і накопичувач до купівлі другого GPU.
• Проведіть заміри й скоротіть розрив зі стелею, перш ніж додавати обладнання.