Тесты локальных LLM для кодинг-агентов на 16 ГБ VRAM

Статья на Хабре от Вячеслава - энтузиаста (не профессионального разработчика), запускающего локальные LLM на потребительском железе. Сетап: RTX 5070 Ti с 16 ГБ VRAM, 32 ГБ системной памяти, CachyOS, llama.cpp, собранный из исходников под архитектуру Blackwell, и OpenCode в роли агентской обвязки. Исходный тезис: большинство тестов локальных LLM на YouTube берут слишком тяжёлые модели, настройки по умолчанию и игрушечные промпты, из-за чего дают искажённую картину. Вячеслав берёт три MoE-модели, которые впритирку помещаются при Q4-квантовании, прогоняет их через три агентские задачи и фиксирует как набранные баллы, так и практические трюки, которые вообще делают эти запуски возможными.

Три модели

Все три используют архитектуру Mixture-of-Experts, все три квантованы примерно до 4 бит, и ни одна сама по себе нормально в 16 ГБ не влезает:

Модель	Файл	Всего -> активных	Квантование
Gemma 4 26B-A4B	`gemma-4-26B-A4B-it-MXFP4_MOE.gguf`	26B -> 4B	MXFP4 (Blackwell-native)
Qwen 3.6 35B-A3B	`Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf`	35B -> 3B	Q4_K_M (bartowski)
Qwen3-Coder 30B-A3B	`Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf`	30B -> 3B	Q4_K_M (bartowski)

См. mixture-of-experts, почему сравнение "26B против 35B" теряет смысл при использовании MoE, и llm-quantization по поводу трёх встречающихся здесь семейств квантования.

Трюк с размещением: `--n-cpu-moe`

Главная практическая находка: флаг --n-cpu-moe в llama.cpp подходит для MoE на малом объёме VRAM куда лучше, чем классический сброс слоёв через --n-gpu-layers. Слои внимания (attention) остаются в VRAM для каждого токена; через PCIe в системную память вытесняются только веса неактивных экспертов. Поскольку на каждый токен срабатывает лишь несколько экспертов, трафик по шине PCIe остаётся низким.

Цифры из статьи (скорость генерации, токенов/сек):

Модель + режим	`--n-gpu-layers`	`--n-cpu-moe`	Прирост
Qwen 3.6 Fast	41.3	64.0	+55%
Qwen 3.6 Thinking	41.7	66.7	+60%
Qwen Coder Fast	51.3	57.6	+12%
Qwen Coder Thinking	53.0	60.2	+14%
Gemma 4 (полностью влезает в VRAM)	n/a	61.9 / 60.8	-

Подробную картину см. в moe-cpu-offload.

Три задачи

Соблюдение нестандартных правил AGENTS.md. Файл AGENTS.md проекта требует префикс ai_gen_ в имени файла, строгую типизацию и комментарий // Одобрено ИИ. Сама задача - написать функцию для извлечения уникальных email-адресов - тривиальна; тест проверяет, следует ли модель контекстным правилам.
Вызов инструментов (tool calling). Прочитать index.html, извлечь все теги <h1>, записать их в headers.json. Многошаговая работа с инструментами с ловушкой на корректность JSON (декодирование HTML entities).
Рефакторинг + юнит-тесты. Файл с пятью заложенными багами (ошибка на единицу, два деления на ноль, возврат одного элемента вместо списка, нечитаемые имена). Провести рефакторинг и написать тесты.

В каждой задаче оценивались 4 бинарных критерия по 4 балла; всего 12.

Результаты

Модель	Режим	T1	T2	T3	Итого
Gemma 4	Thinking	3/4	4/4	4/4	11/12
Gemma 4	Fast	4/4	4/4	4/4	12/12
Qwen 3.6	Thinking	1/4	4/4	2/4	7/12
Qwen 3.6	Fast	3/4	4/4	2/4	9/12
Qwen Coder	Thinking	2/4	4/4	2/4	8/12
Qwen Coder	Fast	2/4	2/4	2/4	6/12

Gemma 4 Fast - единственный прогон, набравший максимум. Ниже выделяются три вывода.

Вывод 1: Режим Thinking мешает следованию правилам

У всех трёх моделей вариант Thinking справился с Тестом 1 хуже, чем Fast (или показал тот же результат). Qwen 3.6 Thinking - с худшим баллом в таблице - проигнорировал три из четырёх правил AGENTS.md. Гипотеза Вячеслава: когда модель "рассуждает", она оценивает, насколько нестандартные правила действительно критичны, и молча отбрасывает те, которые кажутся ей произвольными. Режим Fast следует им буквально, не пытаясь ничего рационализировать. См. thinking-mode-rule-erosion, где концепция описана отдельно вместе с практическими выводами.

Вывод 2: Qwen Coder Fast проваливает вызов инструментов из-за HTML entity

Единственный сбой tool calling среди шести прогонов: Qwen Coder Fast записал в JSON "Support & Contact" вместо "Support & Contact". Он прочитал сырой HTML и не декодировал entity. Все остальные прогоны, включая Qwen Coder Thinking, его декодировали. Два потерянных балла из-за одного символа.

Вывод 3: Модели Qwen ломаются на длинных агентских сессиях

Обе модели Qwen провалили Тест 3 по одинаковому сценарию: читают файл, начинают рефакторинг, инструмент записи файла падает с ошибкой на большом объёме вывода, контекст сжимается, модель "забывает", что делала, начинает заново или обращается к пользователю. Это происходит независимо от режима Thinking. Кроме того, Вячеслав поймал Qwen 3.6 Fast на галлюцинации в финальном отчёте: модель утверждала, что добавила префикс ai_gen_, хотя в коде его не было. Мораль: текстовый отчёт модели - ненадёжное свидетельство того, что она сделала на самом деле.

Сопутствующий артефакт: обе модели Qwen создали новый файл refactored_code.py вместо редактирования исходного buggy_code.py. Qwen 3.6 Thinking оказался единственным прогоном Qwen, который внёс правки по месту - судя по всему, дополнительное рассуждение помогло ему понять структуру задачи.

Побочная история с квантованием

Вячеслав также зафиксировал менее масштабное наблюдение, заслуживающее отдельного упоминания: кванты Unsloth "Dynamic 2.0" UD-Q4_K_XL, которые продвигались как более продвинутый формат, работают на Qwen MoE хуже, чем классический Q4_K_M. Перплексия по сравнению с базовым Q8_0:

Формат	Размер	Перплексия (WikiText-2)	Деградация
Q8_0 (baseline)	~36.9 GB	6.5342	0%
Q4_K_M	~20.0 GB	6.6688	+2.1%
UD-Q4_K_XL	~19.0 GB	7.1702	+9.7%

Экономия 1 ГБ на диске обходится почти в 5 раз большей погрешностью по перплексии. Сами Unsloth позже убрали слои MXFP4 из своих сборок Qwen GGUF из-за вычислительных аномалий. Подробности в llm-quantization.

256K контекста на 16 ГБ

Дополнение по следам комментариев сообщества: при переключении --cache-type-k и --cache-type-v с q8_0 на q4_0 (что вдвое снижает затраты на KV-кэш на токен) и увеличении --n-cpu-moe обе модели - Qwen 3.6 и Gemma 4 - укладывают свои заявленные 256K токенов контекста в 16 ГБ VRAM. KV-кэш у Gemma 4 обходится примерно в 4 раза дороже за токен, чем у Qwen, из-за раскладки в 30 слоёв × ~7 KV-голов × 176 head-dim, поэтому для достижения 256K ей требуется --n-cpu-moe 12 вместо --n-cpu-moe 23. См. kv-cache-sizing.

Практические выводы Вячеслава

Для агентской работы в IDE на 16 ГБ VRAM: Gemma 4 Fast.
Для сложного рефакторинга + тестов: Gemma 4 Thinking - единственная модель, написавшая реально работающие тесты.
Для строгого следования стайлгайдам: любая модель в режиме Fast. Ни в коем случае не Thinking.
Для длинных многошаговых сессий: избегать Qwen на текущих сборках llama.cpp.
Отказ от LM Studio и Ollama - работают до 30% медленнее, чем собранный из исходников llama.cpp. Удобство оборачивается ощутимой потерей производительности на столь ограниченном железе.
Отказ от навыков, раздувающих контекст (например, Context 7, Superpowers), на небольших локальных моделях. Они работают на крупных облачных моделях, потому что тем хватает запаса токенов.

Связи

Статья встраивается в существующие темы вики:

lucumr-local-models - критика Армина Ронахера (Armin Ronacher) по поводу фрагментации локальных LLM и проблем со стримингом инструментов; сетап Вячеслава - наглядный пример той самой экспертизы, которой, по словам Ронахера, требоваться не должно.
titit-local-ai - аргументы Теда Ньюарда (Ted Neward) в пользу локальных OSS LLM из-за хрупкости облаков и экономики; эта статья - практический пример того, как кто-то делает эту ставку.
hold-on-to-your-hardware - 16 ГБ на потребительских картах остаются реалистичным потолком; описанные здесь практические трюки продиктованы именно этим ограничением.
gemma-gem - отдельное развёртывание Gemma 4 через WebGPU в расширении для Chrome; то же семейство моделей в совершенно иной среде.
deepseek-v4-roleplay-instruct - ещё один материал о поведении reasoning-режима с иным выводом (переключатель `` у DeepSeek работает нормально, здесь же режим Thinking сам по себе создаёт проблемы).

Инструменты, добавленные из этой статьи: llama.cpp (уровня сущности, наконец-то обзавёлся собственной toolbox-страницей), OpenCode (использованная здесь агентская обвязка).

Связанные материалы (пакет 2026-05-13)

habr-local-llm-quantization-deep-dive - вводная статья Вячеслава, закладывающая концептуальную базу для этих тестов
reddit-qwen3-6-mtp-12gb - тред на Reddit с практическим опытом запуска Qwen 3.6 + MTP на 80 т/с на 12 ГБ; то же семейство моделей, добавляется спекулятивное декодирование
little-coder-scaffold-model-fit - Инбарр показывает, что переработка скаффолда поднимает результат Qwen3.5-9B с 19.11% до 45.56% на Aider Polyglot; ортогональный рычаг по сравнению с рассмотренным здесь
incompressible-knowledge-probes - фреймворк IKP от Боцзе Ли (Bojie Li) помещает Qwen3.6, Gemma 4 и другие локально запускаемые модели на шкалу фактологической ёмкости наряду с передовыми закрытыми моделями
interactive-turboquant - сжатие KV-кэша, превосходящее замену q8_0 -> q4_0, использованную в конфигурации на 256K контекста из этой статьи