Питання «яка відеокарта потрібна під локальну модель» майже завжди ставлять навпаки: спочатку дивляться на бюджет, потім прикидають, що туди влізе. Порядок зворотний. Беремо модель, довжину контексту й кількість людей, які працюватимуть одночасно, множимо за формулами NVIDIA й отримуємо число в гігабайтах.
Коротко
- Ваги це одна дія: параметри помножити на байти формату. 70 мільярдів у FP8 це 70 ГБ, у INT4 це 35 ГБ
- Контекст на 128 тисяч токенів для Llama 3 70B забирає ще 40 ГБ, і то на одного користувача
- Llama 2 7B зі старою схемою уваги їсть 512 КБ на токен, Llama 3 70B з GQA лише 320 КБ
- Під кеш іде залишок: 90% пам'яті карти мінус ваги мінус від 1 до 5 ГБ на CUDA-графи
- Профіль FP8 у NIM не завжди економить пам'ять при старті: ваги спершу вантажаться у BF16
З чого складається бюджет пам'яті
NVIDIA описує розподіл пам'яті в NIM так: із повного обсягу карти рушій бере частку gpu_memory_utilization, за замовчуванням 0.9, і всередині цього бюджету розкладає ваги, накладні витрати, пікові активації та KV-кеш. Останній розподіляється жадібно: «it expands to fill all remaining space within the budget after weights, activations, and overhead are accounted for». Тобто кількість одночасних користувачів це не налаштування, а залишок.
Ваги: одна дія множення
Офіційна формула з документації NIM: пам'ять під ваги на одну карту = кількість параметрів × байт на параметр / TP, де TP це кількість карт, між якими ваги розкидані тензорним паралелізмом. Байт на параметр: BF16 і FP16 по два, FP8 один, INT4 і NVFP4 по половині. INT8 у офіційній таблиці NVIDIA відсутній, тому байт для нього ми не називаємо.
| Параметрів | FP16 / BF16 | FP8 | INT4 / NVFP4 |
|---|---|---|---|
| 7 млрд | 14 ГБ | 7 ГБ | 3,5 ГБ |
| 8 млрд | 16 ГБ | 8 ГБ | 4 ГБ |
| 13 млрд | 26 ГБ | 13 ГБ | 6,5 ГБ |
| 70 млрд | 140 ГБ | 70 ГБ | 35 ГБ |
| 120 млрд | 240 ГБ | 120 ГБ | 60 ГБ |
| 405 млрд | 810 ГБ | 405 ГБ | 202,5 ГБ |
Розраховано за формулою з документації NIM. Рядки 7, 8 і 70 млрд збігаються з прикладами NVIDIA, решта це множення
KV-кеш, і чому 7B їсть більше за 70B
Друга половина рахунку це KV-кеш: модель зберігає ключі та значення для кожного прочитаного токена, щоб не рахувати їх заново. Формула NVIDIA: 2 × кількість шарів × (кількість голів × розмірність голови) × байт точності на один токен. Двійка спереду це окремо K і окремо V. Обсяг росте лінійно і за довжиною послідовності, і за кількістю паралельних запитів.
| Модель, схема уваги | На 1 токен | 4 тис. | 32 тис. | 128 тис. |
|---|---|---|---|---|
| Llama 2 7B, FP16, MHA | 512 КБ | 2 ГБ | 16 ГБ | 64 ГБ |
| Llama 3 70B, GQA | 320 КБ | 1,25 ГБ | 10 ГБ | 40 ГБ |
| Llama 3.1 8B, BF16, GQA | 128 КБ | 0,5 ГБ | 4 ГБ | 16 ГБ |
Опорні числа NVIDIA: 2 ГБ на 4096 токенах для Llama 2 7B (Mastering LLM Techniques) і 40 ГБ на 128 тис. токенів для Llama 3 70B (KV Cache Offload). Решта клітинок це лінійне масштабування, задеклароване там само. Рядок 8B зведено з формули й прикладу «512 МБ на запит при 4096 токенах»
Тепер найцікавіше. Сімка зі старою multi-head attention витрачає на токен 512 КБ, а сімдесятка з grouped-query attention лише 320 КБ: модель у десять разів більша, а кеша їй треба на 38% менше. У GQA голови ключів і значень згруповані, тож їх менше, ніж голів запитів. Тому «скільки контексту влізе» не виводиться з кількості параметрів.
Складіть дві таблиці разом: 70B у FP16 із контекстом на 128 тисяч токенів це 140 ГБ ваг плюс 40 ГБ кеша. 180 ГБ на одну людину.
Накладні витрати, які видно тільки в логах
Захоплення CUDA-графів забирає, за оцінкою NVIDIA, «1 to 5 GB depending on GPU architecture and model size». На карті з 24 ГБ дефолтні 10% резерву це 2,4 ГБ, і документація визнає, що на частині архітектур графам цього замало. Тепер про пастку, якої немає в презентаціях. Вона стосується не кожної моделі, але трапляється: у матриці підтримки NIM про профіль Llama 4 Scout сказано прямо: «for the FP8 profile, the same memory as BF16 is required because FP8 quantization happens on the fly, implying that BF16 weights must be loaded into memory first». Там, де квантизація йде на льоту, вісім бітів економлять пам'ять у роботі, але на старті потрібно стільки ж, скільки під BF16. Тому перед закупівлею дивіться на конкретний профіль, а не на колонку FP8 у таблиці.
Карта, модель, контекст, користувачі
Метод відтворюваний до клітинки: обсяг карти множимо на 0.9, віднімаємо ваги й ще 2 ГБ на графи та активації, залишок ділимо на кеш однієї сесії. Числа нижче це верхня межа за пам'яттю. Реальну цифру ще обріже затримка.
| Карта | Вільно під кеш | 8 тис. токенів | 32 тис. | 128 тис. |
|---|---|---|---|---|
| RTX PRO 4500, 32 ГБ | 18,8 ГБ | 18 | 4 | 1 |
| RTX PRO 5000, 48 ГБ | 33,2 ГБ | 33 | 8 | 2 |
| RTX PRO 5000, 72 ГБ | 54,8 ГБ | 54 | 13 | 3 |
| RTX PRO 6000, 96 ГБ | 76,4 ГБ | 76 | 19 | 4 |
| H200 NVL, 141 ГБ | 116,9 ГБ | 116 | 29 | 7 |
Модель класу 8 млрд параметрів у FP8, ваги 8 ГБ, кеш у FP16 по 128 КБ на токен. У колонках кількість одночасних сесій. Наш розрахунок за формулами NIM
Та сама карта під сімдесятимільярдну модель виглядає інакше.
| Карта | Формат ваг | 8 тис. токенів | 32 тис. | 128 тис. |
|---|---|---|---|---|
| RTX PRO 4500, 32 ГБ | INT4 | ваги не влазять | ||
| RTX PRO 5000, 48 ГБ | INT4 | 2 | не влазить | не влазить |
| RTX PRO 5000, 72 ГБ | INT4 | 11 | 2 | не влазить |
| RTX PRO 6000, 96 ГБ | INT4 | 19 | 4 | 1 |
| RTX PRO 6000, 96 ГБ | FP8 | 5 | 1 | не влазить |
| H200 NVL, 141 ГБ | INT4 | 35 | 8 | 2 |
| H200 NVL, 141 ГБ | FP8 | 21 | 5 | 1 |
Модель класу 70 млрд параметрів із GQA, кеш у FP16 по 320 КБ на токен. Ваги: 35 ГБ у INT4, 70 ГБ у FP8. У FP16 така модель займає 140 ГБ і на жодну карту з переліку не поміщається
Дивіться на другий рядок. Сорок вісім гігабайтів формально «тримають» 70B у чотирьох бітах, але після ваг лишається 6,2 ГБ, і це дві сесії по вісім тисяч токенів. Контекст на 32 тисячі не влізе навіть один.
Що показують реальні виміри
Арифметика дає стелю за пам'яттю. Далі вступає затримка. Офіційні заміри NVIDIA для Llama 3.1 8B на одній H100 80 ГБ:
| Точність, вхід / вихід | Користувачів | Час до першого токена | Пропускна |
|---|---|---|---|
| FP8, 200 / 200 | 200 | 0,5 с | 9885 ток/с |
| FP8, 1000 / 1000 | 250 | 6,5 с | 8726 ток/с |
| FP8, 20000 / 2000 | 250 | 281 с | 1214 ток/с |
| FP16, 20000 / 2000 | 250 | 484 с | 585 ток/с |
Джерело: NIM LLMs Benchmarking, Llama 3.1 8B. Максимум протестованої конкурентності в цій серії 250
Пам'яті на 8B вистачило б і на більше сесій, але при вході в 20 тисяч токенів пропускна падає у вісім разів, а перший токен людина чекає близько п'яти хвилин. Сервіс формально живий. Користуватись ним ніхто не буде.
Найпрямший важіль тут це довжина запиту, і логи NIM самі підказують цифру: «Estimated VRAM (45.2 GB) exceeds available GPU memory (39.6 GB). Consider reducing context length with --max-model-len=4096 (estimated 30.1 GB)». Зріз контексту до 4096 звільнив 15,1 ГБ.
Квантизація кеша: обіцянка проти виміру
Логічний наступний хід: стиснути й сам кеш. Вимір NVIDIA порівнює NVFP4 не з FP16, а з FP8: кеш у NVFP4 займає приблизно вдвічі менше, ніж кеш у FP8, а затримка падає до трьох разів. Якість просідає мало: MMLU-PRO 78,2% на BF16, 78,1% на FP8 і 77,4% на NVFP4.
А тепер вимір із протилежним знаком. Nemotron-3-Nano-30B прогнали в llama.cpp на DGX Spark і порівняли кеш у f16 та q4_0. На 64 тис. токенів пам'ять процесу з q4_0 виявилася не меншою, а більшою: 2,06 ГБ проти 1,94 ГБ, тобто на 6% більше, бо метадані масштабування з'їли всю економію на єдиній пам'яті Spark. Обробка запиту при цьому впала з 282,7 до 21,3 токена за секунду. Обидва джерела праві. NVFP4 у TensorRT-LLM апаратно прискорений на Blackwell, а q4_0 у llama.cpp розтискається програмно: формат нічого не гарантує, виграш дає рушій і залізо.
Що з цього є в нас
- RTX PRO 4500 Blackwell, 32 ГБ: моделі до 13 млрд параметрів, ембединги й реранкери
- RTX PRO 5000 Blackwell, 48 ГБ: 8B і 13B із довгим контекстом на команду
- RTX PRO 5000 Blackwell, 72 ГБ: та сама карта з більшою пам'яттю, 70B у чотирьох бітах дихає
- RTX PRO 6000 Blackwell Workstation Edition, 96 ГБ: 70B у FP8 на одній карті
- H200 NVL, 141 ГБ HBM3E: 70B у FP8 із запасом під довгий контекст і десятки сесій
Часті питання
Що дають дві карти замість однієї?
Не єдиний пул. Без NVLink дві карти по 96 ГБ це не 192 ГБ під одну модель, а два пули, між якими ваги ділить тензорний паралелізм через PCIe. Головна користь інша: тримати кілька спеціалізованих моделей одночасно, не вивантажуючи одну заради іншої.
Мені треба більше пам'яті не під більші моделі, а під більше агентів
Тоді дивіться на таблиці по колонці контексту, а не по рядку моделі. Агентні сценарії з'їдають тисячі токенів на ітерацію, і кеш росте швидше за все інше. Часто вигідніша менша модель із довшим контекстом.
Модель формально влазить, але рушій пише OOM. Чому?
Три типові причини: дефолтні 10% пам'яті зарезервовані й недоступні, CUDA-графи забирають від 1 до 5 ГБ понад ваги, а в частині профілів FP8 ваги вантажаться у BF16 і квантуються вже в пам'яті.
Скільки пам'яті займає 70B: 140 чи 131 ГБ?
Майже одне й те саме число в різних одиницях. 140 десяткових гігабайтів це 130,4 гібібайта, а Linux і драйвер рахують саме в гібібайтах. Залишок до 131 дають самі параметри: у Llama 3.1 і 3.3 70B їх трохи більше за круглі 70 мільярдів. Обидві цифри в документах NVIDIA правильні.
Чи можна порахувати кеш для довільної моделі?
Так, але потрібні три числа з її конфігурації: кількість шарів, кількість голів ключа й значення, розмірність голови. Опорні заміри NVIDIA є для 7B і 70B. Для 120B і 405B офіційних чисел по кешу немає, тому таблиць на них ми не наводимо.
Ці моделі є в каталозі
Порахуємо під вашу задачу
Назвіть модель, довжину контексту й кількість людей. Порахуємо обсяг пам'яті й скажемо, де межа однієї карти, а де вже потрібен сервер.
Отримати консультацію
