Три локальные языковые модели — Gemma 4 (26B-A4B), Qwen 3.6 (35B-A3B) и Qwen Coder (30B-A3B) — прошли сравнительное тестирование на домашнем ПК с RTX 5070 Ti и 16 ГБ видеопамяти. Автор теста, Вячеслав, поставил задачу не воспроизвести синтетические benchmark-результаты, а проверить модели в реальных сценариях: написание работающего кода, рефакторинг файлов с багами, извлечение данных из HTML. Победителем в задачах программирования вышла Gemma 4 — несмотря на меньшее суммарное число параметров.
Все три модели построены на архитектуре Mixture of Experts (MoE). В отличие от «плотных» сетей, где каждый запрос проходит через все слои, MoE активирует лишь часть специализированных блоков-«экспертов» для каждого токена. Это даёт два практических преимущества для домашнего железа: снижение вычислительной нагрузки и возможность выгружать неактивные эксперты в оперативную память, освобождая видеопамять под контекст. Из-за этого сравнивать MoE-модели по общему числу параметров бессмысленно — важнее смотреть на активные параметры. У Gemma 4 их 4B при 26B общих, у Qwen 3.6 и Qwen Coder — по 3B при 35B и 30B соответственно.
| Модель | Файл | Размер на диске | Всего параметров | Активных параметров | Формат квантования |
|---|---|---|---|---|---|
| Qwen Coder | Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf | 17,3 ГБ | 30B | ~3B | Q4_K_M |
| Qwen 3.6 | Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf | 19,9 ГБ | 35B | ~3B | Q4_K_M |
| Gemma 4 | gemma-4-26B-A4B-it-MXFP4_MOE.gguf | 15,5 ГБ | 26B | ~4B | MXFP4_MOE |
Отдельный сюжет — выбор формата квантования. Квантование сжимает веса модели: вместо 16-битных чисел с плавающей запятой хранятся 4-битные целые, что кратно снижает потребление памяти. Для Gemma 4 был выбран формат MXFP4_MOE — нативный для архитектуры Blackwell, с прямым маппингом на тензорные ядра GPU без эмуляции. Для Qwen-моделей этот формат недоступен: команда Unsloth официально исключила MXFP4-слои из сборок Qwen 3.5/3.6 из-за аномалий в вычислениях — модели выдавали некорректные ответы или падали.
Формат MXFP4 для Qwen 3.5/3.6 признан нестабильным командой Unsloth и исключён из официальных сборок.
Для Qwen автор сравнил два оставшихся варианта: классический Q4_K_M и «продвинутый» UD-Q4_K_XL от Unsloth Dynamic 2.0. Последний перед сжатием прогоняет модель через 300 тысяч — 1,5 миллиона токенов реальных диалогов, определяет чувствительные слои и оставляет их в 8 или 16 битах. Звучит убедительно, но метрики перплексии на WikiText-2 дают обратную картину: Q4_K_M отклоняется от эталона Q8_0 на 2,1%, тогда как UD-Q4_K_XL — на 9,7%, экономя при этом лишь 1 ГБ на диске. В профильных обсуждениях отмечают, что Unsloth-кванты исторически проседают именно на MoE-архитектурах со сложной маршрутизацией экспертов.
Ни одна из трёх моделей не помещается целиком в 16 ГБ видеопамяти даже после квантования: Gemma 4 занимает 15,5 ГБ, Qwen 3.6 — 19,9 ГБ, Qwen Coder — 17,3 ГБ. Решение — offload через llama.cpp: часть слоёв выгружается в системную оперативную память. Автор настойчиво рекомендует собирать llama.cpp из исходников под конкретную архитектуру GPU вместо использования LM Studio или Ollama — по его оценке, удобство «одного клика» обходится потерей до 30% скорости генерации. При 16 ГБ VRAM и моделях «на грани» это принципиально.
Ещё один вывод касается режима мышления (thinking mode) у Qwen-моделей: его включение ухудшает точность следования инструкциям. При этом скорость генерации у Qwen Coder в режиме thinking даже немного выросла — с 51,3 до 53,0 токена в секунду, — но качество выполнения конкретных задач снизилось. Это расходится с распространённым представлением о том, что «больше размышлений — лучше результат».
