Короткий ответ: что реально запускать на 12 ГБ VRAM
Рабочий набор для RTX 3080 с 12 ГБ VRAM в 2026 году выглядит так: плотная модель 7B-14B в квантизации Q4_K_M или Q5_K_M, контекст 16K-32K, квантизованный KV-кэш. Этого хватает для агентных задач уровня личного секретаря и менеджера: разобрать входящие, найти контекст в заметках, собрать черновик ответа, поставить встречу, обновить таблицу.
Три класса моделей, которые стоит смотреть в первую очередь:
- Плотные 7B-14B в GGUF Q4_K_M или Q5_K_M. Веса занимают 5-9 ГБ, остальное уходит на KV-кэш, контекст и оверхед рантайма.
- MoE с небольшим общим размером. Вариант работает, когда все веса в квантизации помещаются в VRAM, а активная часть за шаг заметно меньше общей. Если общий размер модели больше лимита, выигрыш от малого числа активных параметров исчезает.
- Модели, заточенные под tool calling и следование инструкциям. Для агента важнее стабильно вызывать функции и не ломать формат ответа, чем выигрывать пару баллов на абстрактных тестах знаний.
Если ориентиром служит Qwen 3.6 35B-A3B, то для 12 ГБ это неудачная цель. MoE-модель такого класса держит в памяти все веса, а не только активные. Агрессивная квантизация не спасает: часть слоёв уезжает на CPU, и каждый шаг агентного цикла начинает упираться в пропускную способность оперативной памяти.
Дальше - разбор по классам моделей, форматам квантизации, агентному workflow и честные границы конфигурации на 12 ГБ.
Почему 12 ГБ, а не 8 ГБ: в чём реальный выигрыш
Разница в 4 ГБ меняет набор сценариев, которые вообще работают, а не добавляет пару процентов скорости. На 8 ГБ обычно укладывается плотная 7B-8B в Q4 с контекстом 4K-8K, и львиную долю остатка съедает KV-кэш. На 12 ГБ та же модель идёт в Q5_K_M или Q6_K, а контекст поднимается до 16K-32K.
RTX 3080 выпускалась в версиях на 10 и 12 ГБ. Это разные платы с разной шириной шины памяти, поэтому планировать запуск моделей нужно под конкретную модификацию, которая стоит в системном блоке.
Что съедает VRAM кроме весов модели
Память на видеокарте делят несколько потребителей, и вес файла модели - только первый из них.
- Веса модели. Размер файла GGUF в выбранной квантизации.
- KV-кэш. Растёт линейно с длиной контекста и зависит от числа слоёв, числа KV-голов и размерности головы. Сюда же попадает история диалога и результаты вызовов инструментов.
- Буферы активаций и оверхед рантайма. llama.cpp, Ollama, LM Studio, vLLM резервируют собственную долю памяти, и она отличается от движка к движку.
- RAG и вспомогательные модели. Эмбеддер можно держать на CPU или в отдельном процессе, но если он живёт на GPU, память придётся делить.
- Графика рабочего стола. Браузер, композитор и мессенджеры в фоне незаметно забирают сотни мегабайт.
Формула KV-кэша: 2 × число слоёв × число KV-голов × head_dim × длина контекста × байт на элемент. Множитель 2 появляется потому, что хранятся и ключи, и значения. Посчитаем для модели с 40 слоями, 8 KV-головами и head_dim 128 в FP16: 2 × 40 × 8 × 128 × 2 байта дают около 160 КБ на токен. На контексте 32 000 токенов это уже примерно 5 ГБ. Подставьте параметры своей модели и получите собственный бюджет вместо догадок.
KV-кэш можно квантизовать. llama.cpp поддерживает типы вроде q8_0 и q4_0 для кэша ключей и значений, и это один из самых дешёвых способов освободить гигабайты. Реальное потребление удобно смотреть через nvidia-smi или встроенные метрики рантайма: они показывают цифру, а не предположение.
Когда 8 ГБ всё ещё достаточно
Для одиночных чатов, коротких промптов, суммаризации небольших текстов и лёгкого RAG на один-два документа 8 ГБ хватает, и менять карту ради этого не нужно. 12 ГБ становятся нужны, когда появляется агентность: длинный системный промпт с описанием инструментов, многошаговые цепочки, несколько источников в контексте, история из десятков сообщений.
Практический признак: если промпт перестаёт помещаться целиком и рантайм начинает резать историю, значит упёрлись в память, а не в модель.
Агентный workflow: как задачи личного секретаря меняют требования к памяти
Типичный запрос к агенту-секретарю звучит так: «разбери входящие, найди в заметках контекст по проекту, подготовь черновик ответа и поставь встречу». Чтобы это сработало, модель на каждом шаге держит в контексте системный промпт с описанием инструментов, историю своих действий, результаты вызовов, а иногда ещё и найденные фрагменты документов. Каждый шаг добавляет токены, а токены превращаются в KV-кэш.
Tool calling и RAG: сколько памяти они добавляют
Описания инструментов и их ответы - это обычный текст в контексте, поэтому они увеличивают KV-кэш наравне с репликами пользователя. Схема из пяти инструментов с параметрами и примерами легко занимает 1-2 тысячи токенов ещё до первого вопроса. Результат вызова календаря или поиска по заметкам добавляет ещё несколько сотен.
RAG работает в два слоя. Эмбеддер нужен, чтобы найти релевантные чанки, и его можно вынести за пределы GPU. Найденные фрагменты попадают в промпт и занимают уже память основной модели. Три чанка по 800 токенов - это почти 2,5 тысячи токенов в каждом запросе.
Реалистичный бюджет на 12 ГБ для агентного сценария: 3-5 инструментов, RAG по двум-трём документам, контекст 16K. Дальше начинается выбор: уменьшать модель, резать контекст или мириться с выгрузкой слоёв на CPU.
Протокол MCP добавляет к этому серверы с внешними инструментами. Сами серверы память видеокарты не занимают, но их схемы и ответы проходят через тот же контекст, поэтому бюджет считать нужно до подключения десятка интеграций, а не после.
Почему личный секретарь - это не тяжёлое программирование
Работа с текстом, почтой, календарём, заметками, суммаризация и черновики требуют модели, которая понимает инструкции и аккуратно вызывает функции. Генерировать сложный код, вести длинные математические выводы или строить рассуждения на десятки тысяч токенов ей не нужно. Штатный 14B с хорошим tool calling закрывает такие задачи на 12 ГБ.
Тяжёлое программирование, длинные цепочки рассуждений и оркестрация нескольких агентов одновременно - другой класс задач, и там 12 ГБ становятся узким местом. Это стоит принять заранее, чтобы не подбирать модель под то, чего она не потянет.
Qwen 3.6 35B 3A на 12 ГБ: почему это плохая идея и что делать вместо
Если речь о MoE-модели класса 35B с примерно 3B активных параметров, то на 12 ГБ VRAM она не помещается в разумной квантизации. Активных параметров мало, но хранить в памяти нужно все веса целиком: маршрутизатор выбирает разные эксперты для каждого токена, и предсказать заранее, какие именно понадобятся, нельзя.
Что происходит на практике при попытке запуска: часть слоёв остаётся на GPU, часть уезжает в оперативную память, и каждый токен начинает ждать шину PCIe. Для одиночного чата с контекстом 4K-8K это ещё терпимо. Для агентного цикла, где между ответами идут вызовы инструментов и нужно держать длинную историю, задержки складываются в минуты ожидания.
Альтернативы по убыванию практичности: плотная 14B в Q5_K_M с полной загрузкой в VRAM, MoE-модель с общим размером, который целиком помещается в 12 ГБ, специализированная модель под tool calling. Отдельно стоит посмотреть на разбор сравнения Qwen3.8 27B в Q2 и Q3 против Qwen3.6 35B-A3B MoE на карте с 12 ГБ: там видно, чем заканчиваются агрессивные квантизации и как ведёт себя MoE-схема при нехватке памяти.
MoE-модели на 12 ГБ: когда они помогают, а когда нет
MoE выигрывает в другом: при том же качестве ответа счёт идёт на меньшее число активных параметров, а значит на меньшее время генерации. Условие простое - все веса в квантизации должны укладываться в VRAM. Если общий размер модели 20B, в Q4 это примерно 11-12 ГБ только под веса, и на контекст места уже не остаётся. Нужен запас.
Рабочая зона для 12 ГБ: MoE, у которого файл весов в Q4 занимает примерно 6-8 ГБ, а активная часть за токен невелика. Тогда остаётся 3-5 ГБ на KV-кэш и оверхед, и агентный сценарий с контекстом 16K становится выполнимым.
Квантизация под 12 ГБ: форматы, которые имеют смысл
Формат квантизации определяет, сколько весов поместится в память и насколько модель потеряет в аккуратности. Основные варианты:
- GGUF - универсальный формат для llama.cpp, Ollama и LM Studio. Основные уровни: Q4_K_M, Q5_K_M, Q6_K.
- AWQ и GPTQ - варианты для vLLM и подобных серверных рантаймов, обычно 4 бита.
- EXL2 - формат для ExLlama с настраиваемым числом бит на слой.
- IQ-квантизации - семейство с более агрессивным сжатием, где качество держится за счёт смешанной разрядности.
Компромисс выглядит предсказуемо. Q4_K_M экономит память, но проседает на задачах, где нужна аккуратность формата и длинные инструкции. Q5_K_M даёт близкое к исходному поведение и остаётся оптимальным выбором для 12 ГБ. Q6_K качественнее, но оставляет меньше места под контекст. Для агента важнее не максимальный балл на тестах знаний, а стабильность вызова функций и точное следование формату ответа.
Стоит сразу проверить две-три квантизации на своих сценариях: разбор выбора между Q4, Q5 и Q6 при жёстком лимите памяти показывает, как квантизация, длина контекста и offload связаны между собой. Там же видно, почему вывод делается по конкретному файлу модели, а не по названию семейства.
Квантизация KV-кэша: как сэкономить гигабайты
Кэш ключей и значений можно хранить в меньшей разрядности, чем веса. В llama.cpp для этого есть отдельные параметры для K и V. Переход с FP16 на q8_0 сокращает память кэша примерно вдвое, переход на q4_0 - ещё сильнее.
Плата за экономию: на длинных диалогах агрессивная квантизация кэша ухудшает связность ответов и точность извлечения деталей из начала контекста. Разумный компромисс для 12 ГБ - q8_0 для ключей и значений и полный отказ от q4_0 на агентных задачах, где важна точность вызова инструментов. Поддержка зависит от рантайма, поэтому проверять нужно на своей сборке.
Крайние квантизации вроде однобитных IQ-вариантов тоже существуют. Сравнение IQ1_S и Q4 на одной и той же архитектуре показывает, что ультранизкая разрядность помогает запустить модель, но даёт менее предсказуемый результат, особенно когда агент должен строго следовать формату.
Компромиссы: размер модели, контекст, скорость
На 12 ГБ действует треугольник ограничений. Больше модель - меньше контекст или медленнее генерация. Длиннее контекст - меньше модель или снова медленнее. Выше скорость - меньше модель и короче контекст. Все три параметра одновременно не вытянуть, поэтому выбирать приходится осознанно.
Для агентных задач уровня секретаря рабочий баланс такой: модель 7B-14B, квантизация Q4_K_M или Q5_K_M, контекст 16K-32K, квантизованный KV-кэш, выгрузка слоёв только как крайняя мера. Если приоритет - скорость реакции в диалоге, разумнее взять 7B-8B и оставить большой запас под контекст и инструменты. Если приоритет - качество черновиков и разбора переписки, 14B с контекстом 16K даст больше пользы.
Скорость генерации: что реалистично на RTX 3080
Скорость зависит от размера модели, квантизации, длины контекста, числа выгруженных слоёв и конкретного рантайма. При полной загрузке в VRAM плотная модель 7B-14B в Q4-Q5 даёт комфортный для агентных задач темп. Как только начинается выгрузка на CPU, цифры падают кратно, и предсказать их заранее по чужому графику нельзя.
Для агентного цикла важнее не пиковый tokens/s, а предсказуемость: одинаковое время ответа на каждом шаге и отсутствие провалов, когда контекст дорастает до предела. Отсюда практический совет: замерять скорость на своём сценарии с инструментами и историей, а не на пустом промпте.
Практические критерии выбора модели под 12 ГБ
Чек-лист, который экономит часы на экспериментах:
- Размер файла в квантизации. Веса плюс запас на KV-кэш и 1-2 ГБ оверхеда должны укладываться в 12 ГБ. Если остаётся меньше гигабайта, контекст придётся резать.
- Поддержка tool calling и следования формату. Без этого агентный сценарий разваливается, каким бы умным ни был сам ответ.
- Качество на русском языке. Если задачи на русском, проверять нужно на русских промптах, а не на английских примерах.
- Реальная длина контекста. Смотреть не на заявленные 128K, а на тот объем, который помещается в память вместе с весами.
- Лицензия. Для рабочих задач и коммерческого применения ограничения важнее пары баллов качества.
- Поддержка в вашем рантайме. GGUF закрывают llama.cpp, Ollama и LM Studio; AWQ и GPTQ нужны для серверных сценариев.
- Активность обновлений. Свежая квантизация от вменяемого автора экономит время на отладке.
Дополнительный критерий, который часто игнорируют: как модель ведёт себя, когда контекст близок к заполнению. Одни начинают терять инструкции из системного промпта, другие обрывают формат вызова. Проверяется просто - забить контекст историей и посмотреть, сохранится ли структура ответа.
Как проверить, влезет ли модель в 12 ГБ
Быстрый расчёт без запуска: размер весов в квантизации плюс KV-кэш по формуле из начала статьи плюс 1-2 ГБ на оверхед рантайма и рабочий стол. Если сумма меньше 12 ГБ с запасом около гигабайта, конфигурация рабочая. Если впритык, любое расширение промпта приведёт к выгрузке слоёв.
После запуска цифры нужно подтвердить: nvidia-smi и логи рантайма покажут фактическое потребление при максимальной длине контекста. Общий подход к выбору моделей и проверке совместимости с рантаймом разобран в материале о выборе модели для vLLM и других рантаймов без перебора всех карточек: там про формат весов, лицензии и совместимость, то есть про тот же набор вопросов, что и для llama.cpp.
Ограничения 12 ГБ VRAM: что не получится без иллюзий
Границы конфигурации стоит знать заранее, чтобы не тратить вечера на заведомо провальные сценарии.
- Тяжёлое программирование и сложные рассуждения. Плотные модели класса 30B+ в рабочей квантизации с нормальным контекстом в 12 ГБ не помещаются. Выгрузка слоёв превращает работу в ожидание.
- Очень длинный контекст. Контекст 128K и больше упирается в KV-кэш даже при 4-битных весах. Даже с квантизацией кэша такой объем требует куда больше памяти.
- Несколько моделей одновременно. Оркестрация из нескольких агентов, где у каждого своя модель, требует держать их в памяти параллельно. На 12 ГБ это невозможно без постоянной перезагрузки.
- Дообучение и тонкая настройка. Локальный файнтюнинг на 12 ГБ нереалистичен даже с LoRA, если только речь не о совсем маленькой модели.
- Одновременные тяжёлые RAG и tool calling. Большая база документов плюс активный агентный цикл быстро упираются в лимит, и приходится выбирать одно.
Что делать на практике: держать тяжёлые задачи на API, оставляя локально те, где важны приватность и постоянная доступность. Второй вариант - частичная выгрузка на CPU для фоновых пакетных заданий, где скорость не критична. Третий - апгрейд до карты с 24 ГБ, если агентные сценарии стали ежедневным инструментом.
12 ГБ на RTX 3080 в 2026 году остаются рабочей конфигурацией для личного секретаря и менеджера: переписка, заметки, календарь, черновики, поиск по документам. Ровно те задачи, где модель 7B-14B с нормальным tool calling закрывает почти все потребности, а лишние гигабайты ничего не добавят.