Локальные LLM, GGUF, VRAM, RAM и контекст

Калькулятор памяти для локальной LLM

Проверьте, поместятся ли веса модели и KV-cache в видеопамять или общую память компьютера. Калькулятор учитывает размер GGUF или число параметров, квантование, длину контекста, GQA/MQA, sliding-window attention, параллельные последовательности и резерв backend.

Что вводить и почему точный размер GGUF лучше одной цифры «8B»

Если файл GGUF уже скачан, укажите его фактический размер. Это надёжнее оценки по количеству параметров и типу квантования.
Если файла ещё нет, калькулятор оценит размер весов по параметрам и типичному effective bits/weight для llama.cpp. Реальный GGUF может отличаться из-за архитектуры и смешанного квантования тензоров.
KV-cache зависит не от размера файла модели, а от архитектуры внимания, числа слоёв, KV-heads, head dimension, контекста и точности кеша.
Для гибридных моделей можно отдельно задать число full-attention слоёв и окно остальных sliding-window слоёв. Для MLA и других специальных архитектур используйте результат только как предварительную оценку.
Скорость tokens/s здесь не прогнозируется. Она зависит от GPU/CPU, пропускной способности памяти, backend, offload, batch и конкретной модели.

1. Модель и квантование

Пресеты задают только типовой набор параметров для проверки интерфейса. Архитектуру конкретной модели сверяйте по config.json, карточке модели или метаданным GGUF.

Параметров модели млрд Для MoE используйте общее число хранимых параметров, а не только active parameters. Квантование весов Оценка веса использует типичный effective bits/weight. Фактический GGUF предпочтительнее. Фактический размер GGUF ГиБ Необязательно. Если заполнено, именно это значение используется для основного расчёта весов.

Дополнительный mmproj / vision-файл ГиБ Для мультимодальной модели укажите размер отдельного projector-файла, если он загружается вместе с LLM. Шаблон архитектуры KV-cache Это шаблоны, а не привязка к конкретному названию модели.

2. Контекст и KV-cache

Контекст на последовательность ток. Это выделяемый context size, а не только длина текущего prompt. Параллельных последовательностей KV-cache растёт с числом одновременно обслуживаемых последовательностей. Точность K/V cache Квантованный KV экономит память, но поддержка и влияние на скорость зависят от backend. Резерв backend и буферов ГиБ Compute buffers, graph, служебные allocations и практический запас. При OOM увеличьте.

Архитектура внимания

Всего transformer-слоёв Full-attention слоёв Оставшиеся слои считаются sliding-window. KV-heads Head dimension

Sliding-window, если такие слои есть ток. Игнорируется, если full-attention слоёв столько же, сколько всего слоёв.

Базовая формула KV-cache 2 × layers × KV-heads × head dimension × tokens × bytes/value. Для sliding-window слоёв вместо полного контекста используется выбранное окно.

3. Ваш компьютер

Тип памяти для inference Доступная VRAM ГиБ Указывайте реальный объём видеопамяти. Если GPU обслуживает монитор, часть VRAM уже может быть занята. Системная RAM ГиБ

Резерв RAM для ОС и остальных программ ГиБ Для unified memory этот запас вычитается из общей памяти перед проверкой модели.

Что проверяется Для дискретной GPU отдельно оценивается полное размещение в VRAM и возможность RAM/CPU-offload. Для unified memory и CPU сравнение идёт с доступной общей памятью.

Из чего складывается память

Как меняется результат при другом квантовании

Квантование	Оценка весов	Всего с KV и резервом	На этом железе

Таблица оценивает веса по parameters × effective bits/weight. Если вы ввели точный размер GGUF, он используется только в основном результате.

Что проверить перед скачиванием модели

Это предварительный расчёт памяти, а не гарантия запуска. Реальные allocations зависят от версии llama.cpp/Ollama, backend, драйвера, Flash Attention, mmap, GPU-offload, batch, архитектуры модели и других параметров. Если приложение уже показывает OOM, ориентируйтесь на фактический лог выделения памяти.

Как читать расчёт VRAM и RAM

Веса модели занимают основную часть памяти. Для GGUF точный размер файла обычно является лучшей отправной точкой, чем грубый пересчёт «параметры × биты».

KV-cache хранит ключи и значения внимания для уже обработанных токенов. Поэтому длинный контекст и параллельные запросы могут добавить гигабайты даже тогда, когда сама модель небольшая.

Sliding-window attention меняет зависимость от контекста: локальные слои хранят только окно, а глобальные продолжают расти с полной длиной контекста. Поэтому одна универсальная формула без знания архитектуры может сильно ошибаться.

Методика. Типичные effective bits/weight для GGUF-квантований сверены с актуальной документацией llama.cpp. Сам принцип роста KV-cache и варианты его квантования описаны также в документации Hugging Face. Для точного расчёта конкретной модели приоритет имеют её config.json, GGUF-метаданные и фактический лог backend.

Если вы только начинаете работать с локальными моделями, смотрите также раздел «Локальный ИИ» и материал о локальной LLM в Home Assistant.

Частые вопросы

Почему 8B Q4 не означает ровно 4 ГБ?

Квантование хранит не только сами низкобитные значения. Есть масштабы, метаданные, тензоры иной точности и смешанные схемы. Поэтому фактический GGUF обычно отличается от простой формулы parameters × 4 бит.

Почему увеличение context size увеличивает VRAM?

При обычном autoregressive inference KV-cache хранит состояние внимания для предыдущих токенов. Для full-attention слоёв его объём растёт примерно линейно с выделенным контекстом и числом параллельных последовательностей.

Если модель не помещается в VRAM, она не запустится?

Не обязательно. llama.cpp и некоторые другие backend умеют держать часть весов в системной RAM и выполнять CPU/GPU offload. Это может позволить запустить модель, но производительность обычно ниже, а требования к RAM остаются значительными.

Можно ли по памяти точно предсказать tokens/s?

Нет. Факт размещения модели и скорость inference — разные задачи. Скорость зависит от вычислительной мощности, bandwidth памяти, backend, batch, offload, prompt processing, длины контекста и конкретной архитектуры.