Что реально запустить на 32 ГБ RAM и 16 ГБ VRAM: модели для кодинга и общего ассистента

На 16 ГБ VRAM целиком помещаются модели на 7–14 млрд параметров в 4-битном квантовании: это GGUF-файлы уровня Q4_K_M весом примерно 4–9 ГБ плюс запас на KV-кэш и контекст. Такого класса хватает и для кодинга, и для роли общего ассистента, если не ждать от локальной модели уровня топовых облачных сервисов.

Модели на 30–70 млрд параметров в том же квантовании в 16 ГБ не влезают. Их можно поднять, выгрузив часть слоёв в 32 ГБ RAM, но каждый выгруженный слой добавляет задержку на каждом шаге генерации. Для интерактивной работы это обычно неприемлемо, для пакетных задач (прогнать ревью по десятку файлов, сгенерировать тесты к вечеру) вполне терпимо.

Инструменты запуска: Ollama для командной строки и API, LM Studio для графического интерфейса, llama.cpp для ручной настройки выгрузки и контекста. Все три работают с GGUF, поэтому одна и та же модель переносится между ними без конвертации.

Формулировка «что реально запустить на 32 ГБ RAM и 16 ГБ VRAM для кодинга или как общего ассистента» пришла из обсуждения на r/LocalLLaMA: автор вопроса просил краткий обзор после долгой паузы и отмечал, что на фоне владельцев RTX 6000 его сборка выглядит скромно. Ответов в той ветке нет, конкретных моделей и цифр источник не даёт. Поэтому дальше речь пойдёт о механике и ориентирах, которые не устаревают при смене версий моделей каждые пару месяцев.

Почему VRAM, а не RAM, определяет размер модели

При генерации веса модели и KV-кэш лежат в видеопамяти. Видеопамять дискретной карты быстрая: её пропускная способность измеряется сотнями гигабайт в секунду. Двухканальная системная память DDR5 даёт десятки гигабайт в секунду, у DDR4 этот показатель ниже. Генерация идёт токен за токеном, и на каждом шаге активные веса приходится прочитать целиком. Скорость упирается в пропускную способность того уровня памяти, где веса физически находятся.

VRAM задаёт потолок: сколько весов и KV-кэша в неё влезло, столько считается на быстрой памяти. 32 ГБ RAM — это резерв. Туда можно выгрузить часть слоёв, если видеопамяти не хватает, но каждый выгруженный слой замедляет каждый шаг генерации.

Практическая раскладка для 16 ГБ: около 8–10 ГБ под веса, 3–5 ГБ под KV-кэш при длинном контексте, остальное под рабочие буферы и неизбежную фрагментацию. Отсюда и граница в 7–14 млрд параметров при 4 битах. Модель на 7B в Q4 занимает 4–4,5 ГБ, и остаётся место на контекст в десятки тысяч токенов. Модель на 14B в Q4 занимает 8–9 ГБ, контекст придётся держать скромнее.

Важно, что KV-кэш не входит в размер GGUF-файла и при длинном контексте может занимать больше памяти, чем сами веса. Для Llama 3.1 8B при контексте 32K KV-кэш оценивается примерно в 4 ГБ при весах Q4_K_M около 4,9 ГБ: на длинном контексте суммарная потребность в VRAM почти удваивается. Поэтому фраза «модель на 14B влезает в 16 ГБ» верна только вместе с оговоркой про длину контекста.

Квантование: главный рычаг, который решает, влезет модель или нет

Квантование сокращает число бит на один вес. FP16 — это 2 байта на параметр, 4-битный вариант — примерно 0,5–0,6 байта с учётом служебных данных. Разница в четыре раза превращает 28 ГБ FP16-весов в 8–9 ГБ файла.

Класс модели	4 бита, примерно ГБ	6 бит, примерно ГБ	8 бит, примерно ГБ
7B	4–5	6–7	7–8
14B	8–9	11–12	14–16
32B	18–20	26–28	34–36
70B	40–43	56–60	70 и больше

Цифры получены арифметикой квантования (примерно 0,55–0,6 ГБ на 1 млрд параметров при 4 битах), а не замерами. Реальный размер файла зависит от архитектуры и версии квантователя, KV-кэш и буферы в таблицу не входят. Для 32B-моделей Q4_K_M-файлы действительно публикуются: например, для Qwen2.5-32B-Instruct выложен отдельный Qwen2.5-32B-Instruct-Q4_K_M.gguf, а QwQ-32B (32,5 млрд параметров, 31,0 млрд без эмбеддингов) доступна в квантовании q4_K_M с полной длиной контекста 131 072 токена. Точный размер конкретного файла смотрите на странице модели перед скачиванием.

Q4_K_M — рабочий компромисс для 16 ГБ. Падение качества на 4 битах обычно меньше, чем ожидают: потери заметны на длинных рассуждениях и редком коде, на типовых задачах разница малозаметна. Насколько именно просядет конкретная модель, заранее не скажет никто, это видно только на своих задачах.

5–6 бит имеет смысл, когда модель небольшая и есть запас по VRAM: 7B в Q6_K занимает 6–7 ГБ, всё ещё комфортно. 8 бит для 14B — это 14–16 ГБ только весов, места на контекст почти не остаётся. Для моделей крупнее 14B восьмибитные варианты в 16 ГБ не рассматриваем.

Когда часть модели уходит в RAM и чем это грозит

Частичная выгрузка работает так: несколько слоёв остаются на GPU, остальные живут в системной памяти и подкачиваются по мере надобности. В llama.cpp за это отвечает параметр -ngl (число слоёв на GPU), в LM Studio — ползунок GPU offload, в Ollama — переменная окружения с числом слоёв. Модель запустится и даже ответит. Вопрос в скорости.

Механика замедления описана в разборе частичной загрузки: реальное ограничение — не скорость CPU, а пропускная способность памяти, и загрузка слоя из DDR5 RAM занимает примерно 10–15 мс на слой. При этом частичная выгрузка не меняет веса: при одинаковой точности результат совпадает с полным GPU-инференсом, страдает только темп. Сколько именно токенов в секунду вы получите при выгрузке половины слоёв, зависит от модели, квантования и памяти, поэтому ориентируйтесь на собственный замер, а не на чужие цифры.

32 ГБ RAM хватает, чтобы поднять модель на 30–32 млрд параметров в 4 битах: по арифметике квантования она весит порядка 18–20 ГБ, и остаётся место системе. Windows сама по себе занимает 6–8 ГБ, браузер с аппаратным ускорением ещё несколько. Если свободной памяти не останется, система начнёт свопить на диск, и это уже не медленно, а неработоспособно. Расчёт RAM-футпринта под модели крупнее разобран отдельно: какие open weight модели укладываются в 48, 64 и 96 ГБ RAM.

Практическое правило: для кодинга в реальном времени берите модель, которая целиком влезает в VRAM. Для пакетных задач выгрузка допустима, если вы готовы ждать.

Модели для кодинга: на что смотреть кроме размера

Число параметров — не главный критерий. Для кода важны четыре вещи.

• Обученность на коде и поддержка fill-in-the-middle (FIM): модель должна дописывать код между префиксом и суффиксом, иначе автодополнение в редакторе работает плохо.
• Длина контекста: чем больше файлов вы хотите показать модели, тем крупнее KV-кэш и тем меньше VRAM остаётся под веса.
• Следование инструкциям и формат вывода: агентные сценарии требуют стабильного JSON и вызовов инструментов.
• Поведение в диалоге: способность править код по замечаниям, а не переписывать файл целиком после каждой реплики.

Класс, который влезает в 16 ГБ: кодовые модели на 7–14 млрд параметров в Q4_K_M. Это варианты с пометкой Coder в названии (такие есть у семейств Qwen и DeepSeek) и кодовые файнтюны универсальных моделей. Конкретные версии выходят каждые несколько месяцев, так что проверять надо не номер в названии, а поведение на вашем стеке.

KV-кэш съедает VRAM быстро. Контекст в 32 тыс. токенов на 14B-модели может занять несколько гигабайт, и тогда Q4-веса перестанут помещаться вместе с ним. Выход — либо контекст поменьше, либо квантование самого KV-кэша. В ik_llama.cpp (форке llama.cpp) KV-кэш по умолчанию хранится в f16, и его можно квантовать отдельно для K и V через параметры --cache-type-k и --cache-type-v, например q8_0; аналогичные параметры типа квантования key cache и value cache есть в OpenAI-совместимом сервере llama-cpp-python. Учтите ограничение: квантование KV-кэша может снижать качество, причём K-кэш может требовать более точного кванта, чем V-кэш, а для смягчения потерь при сильном квантовании предлагаются Hadamard-преобразования для K- и V-кэша. Точных цифр экономии VRAM и падения качества для конкретной модели в доступных источниках нет, поэтому проверяйте на своих задачах.

Универсальный ассистент: чем отличается выбор

Общий ассистент предъявляет другие требования: следование инструкциям, нормальный русский язык, устойчивость в длинном диалоге, аккуратность с фактами. Инструкт-версии моделей на 7–14 млрд параметров в Q4 покрывают повседневные задачи: переписать текст, разобрать документ, ответить на вопрос, собрать план.

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

Держать одну модель на всё удобнее, но специализированная кодовая выигрывает в кодинге. Рабочая схема: кодовая модель на 14B для работы, она же отвечает на общие вопросы. Вторая модель нужна, если хочется держать под рукой что-то полегче и побыстрее: модели на 9 млрд параметров спокойно работают и на 8 ГБ VRAM.

В каком ПО запускать: Ollama, LM Studio, llama.cpp

Все три инструмента работают с GGUF и умеют выгружать слои. Разница в удобстве и контроле.

Ollama: одна команда для запуска, локальный API, удобно для скриптов и интеграций с редакторами. Число слоёв на GPU и другие параметры задаются через переменные окружения и Modelfile. Минус — меньше видимого контроля: не всегда очевидно, что именно попало в видеопамять.

LM Studio: графический интерфейс, поиск моделей, ползунок GPU offload, метрики после ответа. Хороший старт для тех, кто не хочет командной строки. Под капотом тот же llama.cpp, так что поведение сопоставимо.

llama.cpp: максимальный контроль. -ngl, --ctx-size, квантование KV-кэша, flash attention, выбор бэкенда. Здесь видно, сколько слоёв ушло на GPU и с какой скоростью идёт обработка промпта и генерация. Требует понимания параметров, зато позволяет выжать из 16 ГБ максимум.

GGUF — не единственный формат весов. Если вы упёрлись в потолок его квантований, полезно посмотреть на альтернативы: разбор выбора между GGUF и EXL3 по bpw и того, что реально мерить в prefill и decode.

Как проверить скорость и качество на своей конфигурации

Чужие цифры бесполезны: темп зависит от модели, квантования, длины контекста, версии драйвера и движка. Проверять надо у себя. Чек-лист на полчаса.

1. Убедитесь, что модель целиком в VRAM. nvidia-smi покажет занятую память, логи llama.cpp — сколько слоёв ушло на GPU. Если выгружено хоть что-то, скорость уже не та.
2. Замерьте два числа отдельно: скорость обработки промпта (prefill) и скорость генерации (decode). Первая отвечает за время до первого токена при большом контексте, вторая — за темп печати.
3. Проверьте на своём коде. Возьмите файл на 100–200 строк, попросите найти баг или написать тест. Оценивайте не «нравится / не нравится», а долю ответов, которые компилируются и проходят тесты.
4. Проверьте на длинном контексте. Загрузите 20–30 тыс. токенов и посмотрите, не просела ли скорость и не начались ли ошибки памяти.
5. Проверьте русский. Десять типовых вопросов и оценка по шкале «принял бы без правок», «переписал бы», «выбросил».

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

Что делать, если модель не влезает или работает медленно

Порядок действий, от самого дешёвого к самому дорогому по потерям.

1. Уменьшить контекст. С --ctx-size 8192 вместо 32768 освобождаются гигабайты под веса. Часто этого достаточно, чтобы модель перестала выгружать слои.
2. Снизить квантование. С Q5_K_M или Q6_K до Q4_K_M: файл уменьшается почти вдвое, качество проседает умеренно.
3. Взять модель меньшего размера. 14B на 7B, если 14B не влезает вместе с нужным контекстом. Быстрая 7B иногда полезнее медленной 14B.
4. Включить квантование KV-кэша: экономит память на длинном контексте, но качество может просесть, особенно при сильном квантовании K-кэша.
5. Освободить VRAM: закрыть браузер с аппаратным ускорением, отключить лишние мониторы, выгрузить другие модели.
6. Выгрузка в RAM — последний вариант. Модель на 32B в Q4 запустится на 16 ГБ VRAM и 32 ГБ RAM, но темп будет низким: каждый слой, загружаемый из DDR5, добавляет задержку.

Те же компромиссы на ещё более скромном железе разобраны в отдельном материале: запуск локальных моделей на 12 ГБ VRAM с учётом KV-кэша и проверкой нехватки памяти. Приёмы те же, запас меньше.

Итог: как выбрать под свою задачу

• Кодинг: кодовая модель на 7–14 млрд параметров в Q4_K_M, целиком в VRAM, контекст 16–32 тыс. токенов. Начинайте с 14B, если влезает, иначе с 7B.
• Общий ассистент: инструкт-модель того же класса с проверенным русским. Тест — десять своих вопросов, а не строчка в описании модели.
• Инструмент: Ollama для скриптов и интеграций, LM Studio для ручного подбора, llama.cpp для тонкой настройки памяти.
• 32 ГБ RAM: страховка для моделей крупнее 14B и для пакетных прогонов. Заменой VRAM эта память не становится.

Финальную точку ставит собственный замер: скорость генерации на вашей модели, вашем квантовании и вашей длине контекста. Всё остальное, включая эту статью, задаёт только рамки поиска.

Подписаться на канал