# VRAM для LLM: почему размер модели — не весь расчёт

Как оценивать видеопамять для языковой модели: веса, KV-кеш, рабочие буферы, длина контекста и запас для параллельных запросов на GPU.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vram-and-models/
Language: ru

Объём видеопамяти — один из первых параметров, который стоит сообщить оператору пула. Но выражение «модель помещается на карту» может означать разные вещи: загрузку весов, выполнение одного короткого запроса или обслуживание нескольких пользователей с длинным контекстом.

Для коммерческого сервиса важен последний сценарий в пределах согласованных ограничений качества и задержек.

## Из чего складывается расход памяти

Упрощённо бюджет VRAM включает веса, кеш состояния запросов, рабочие буферы движка и резерв. Размеры этих частей зависят от архитектуры модели, реализации и профиля нагрузки. Нельзя корректно назвать всю память свободной только потому, что файлы модели меньше объёма VRAM.

Грубая оценка хранения весов выглядит так: количество параметров умножают на число бит на параметр и делят на восемь. Например, восемь миллиардов параметров при 16 бит дают около 16 миллиардов байт только для весов. Это арифметическая иллюстрация без учёта дополнительных структур и различий GB/GiB.

## Что меняет квантизация

Квантизация использует представление с меньшей точностью, чтобы снизить потребность модели в памяти. Однако выбор формата связан с совместимостью, качеством и эффективностью выполнения. [Документация Hugging Face](https://huggingface.co/docs/transformers/quantization/overview) описывает разные методы и их ограничения.

Меньший размер весов не гарантирует пропорционального ускорения. Сравнивайте поддерживаемый формат на конкретном GPU, а не только объём скачанных файлов. Проверка качества обязательна для задач, где важны структура ответа, язык и выполнение инструкций.

## Почему контекст меняет результат

При работе с длинными запросами и несколькими одновременными пользователями меняется потребность в памяти состояния. Поэтому тест с коротким вопросом не подтверждает способность обслуживать длинные документы.

Зафиксируйте несколько профилей: короткий чат, длинный вход и длинный ответ. Для каждого увеличивайте параллелизм постепенно. Отмечайте границу, после которой появляются ошибки памяти или неприемлемая очередь.

## Как использовать результат

По итогам теста нужно знать рабочие ограничения модели, а не только факт её загрузки. В паспорт сервера добавьте формат весов, версию движка, допустимый контекст и проверенный диапазон нагрузки.

При нескольких GPU не складывайте память без учёта способа распределения модели. Разницу объясняет [материал о multi-GPU](/ru/journal/multi-gpu/).

Связанные материалы: [Пилот GPU-инференса: что проверить до договора о работе](/ru/journal/pilot-checklist/).