Вопрос «какая видеокарта нужна под локальную модель» почти всегда задают наоборот: сначала смотрят на бюджет, потом прикидывают, что туда влезет. Порядок обратный. Берём модель, длину контекста и количество людей, которые будут работать одновременно, умножаем по формулам 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 официальных чисел по кешу нет, поэтому таблиц на них мы не приводим.
Эти модели есть в каталоге
Посчитаем под вашу задачу
Назовите модель, длину контекста и количество людей. Посчитаем объём памяти и скажем, где граница одной карты, а где уже нужен сервер.
Получить консультацию



