Gemma 4 обыграла Qwen Coder в задачах программирования, а режим мышления заставил модели хуже следовать инструкциям. Рассказываю почему.
Зачем я это затеял
Привет, меня зовут Вячеслав. Я интересуюсь локальными LLM и тем, как они ведут себя в реальных задачах — не на синтетических бенчмарках, а когда нужно написать работающий код, отрефакторить файл с багами или вытащить данные из HTML.
Вокруг локальных моделей сложилась странная ситуация. С одной стороны, их постоянно принижают: если это не последняя версия Opus с максимальным режимом размышления, то и пробовать не стоит. С другой - мало кто действительно разбирается, что стоит за запуском локальной модели. Поднять API через llama.cpp - это полдела. А вот как ты её запускаешь, в какой среде, с какими параметрами - эти вещи порой переворачивают результат с ног на голову. Получить плохой результат с локальной моделью на удивление легко. Получить хороший - надо попотеть.
При этом локальные модели нужны. Особенно когда начинаются истории про чувствительные данные, закрытые контуры и ситуации, когда облачный API просто не вариант.
Я посмотрел множество тестов на YouTube - ни один меня не устроил. Общая канва одинаковая: берут модель побольше, запускают без оглядки на оптимальность и дают задание уровня «напиши сортировку пузырьком». Серьёзно?
Я не разработчик и не кодер по профессии, но решил пойти другим путём. Тесты с подковыркой, реальная агентская среда, подбор параметров. И модели я выбрал не «чем больше, тем лучше», а те, которые реально влезают в 16 ГБ видеопамяти домашней видеокарты. Что из этого вышло - дальше по тексту.
Железо
Цель была простая: что может среднестатистический человек с обычным игровым ПК?
У меня это:
GPU: RTX 5070 Ti, 16 ГБ VRAM
RAM: 32 ГБ
OS: Cachy OS на M.2 SSD
По меркам требований к запуску LLM - это прямо мало, «на тоненького». В этом и был основной вызов: уместить модели, которые формально не влезают в видеопамять, и при этом не потерять в скорости до неюзабельного уровня.
Модели
Три участницы, все с архитектурой Mixture of Experts (MoE):
Модель |
Файл |
Размер |
|---|---|---|
Qwen3-Coder |
|
17,3 ГБ |
Qwen 3.6 |
|
19,9 ГБ |
Gemma 4 |
|
15,5 ГБ |
Почему именно MoE? Потому что эта архитектура даёт два преимущества, критичных для домашнего железа. Во-первых, одновременно активны не все слои - только часть экспертов, что снижает вычислительную нагрузку. Во-вторых, можно выгружать неактивные эксперты в оперативную память, освобождая видеопамять под контекст. Для 16 ГБ VRAM это не просто удобно - это вообще единственная возможность запустить такие модели.
Отдельно хотелось использовать родной для Blackwell формат MXFP4 - и он принёс свои неожиданные результаты, но об этом чуть далее.
Среда запуска
llama.cpp, собранная из исходников под архитектуру Blackwell. Настойчиво рекомендую этот путь вместо LM Studio или Ollama. Те дают удобство одного клика, но вы теряете до 30% скорости просто за это удобство. Когда у вас 16 ГБ VRAM и модель на грани - каждый процент на счету.
MoE - что это и почему 26B не равно 35B в привычном смысле
Все три модели в этом тесте построены на архитектуре Mixture of Experts. Если совсем просто: внутри модели спрятано множество «экспертов» - отдельных нейросетевых блоков, каждый из которых специализируется на чём-то своём. Когда приходит запрос, специальный маршрутизатор решает, каких экспертов задействовать для конкретного токена.
В отличие от обычной «плотной» модели, где каждый запрос проходит через все слои, в MoE одновременно работают только несколько экспертов. Отсюда две важные цифры: общее количество параметров и количество активных параметров.
Модель |
Всего параметров |
Активных |
Формат записи |
|---|---|---|---|
Gemma 4 |
26B |
~4B |
26B-A4B |
Qwen 3.6 |
35B |
~3B |
35B-A3B |
Qwen Coder |
30B |
~3B |
30B-A3B |
Gemma 4 при 26B общих параметров использует 4B активных - больше, чем Qwen-модели с их 3B. Но Qwen при этом имеет 35B и 30B общих весов, которые тоже нужно хранить в памяти, просто не все они участвуют в вычислениях одновременно. Поэтому сравнивать MoE-модели по общему числу параметров - занятие бессмысленное. Важнее смотреть на активные параметры и на то, как модель квантована.
Квантование: сжимаем, но с умом
Квантование - это просто сжатие весов модели. Вместо 16-битных чисел с плавающей запятой храним 4-битные целые. Памяти нужно в разы меньше, а качество… зависит от того, как сжимали.
В моём наборе встретились три разных подхода, и вот тут началось интересное.
Q4_K_M - проверенная классика
Самый распространённый формат в мире GGUF. Тензоры разбиваются на блоки по 256 элементов, каждому блоку - свой масштаб и смещение. Наиболее важные тензоры (например, внимание) сохраняются в 6 битах, остальные - в 4. Не требует калибровочных данных, работает предсказуемо. Формат от автора bartowski, на которого я рекомендую обратить внимание.
UD-Q4_K_XL - Unsloth Dynamic 2.0
Более современный подход. Перед квантованием модель «прогоняют» через 300 тысяч - 1,5 миллионов токенов реальных диалогов, смотрят, какие слои чувствительны к потере точности, и оставляют их в 8 или 16 битах. Остальные сжимают жёстко до 4 бит. Звучит отлично - «новая технология, калибровка на реальных данных». Теоретически это должно быть лучше. Практически… не всегда.
MXFP4_MOE — родной формат для Blackwell
В отличие от целочисленных форматов (INT4), сохраняет структуру числа с плавающей запятой - знак, экспоненту, мантиссу - в рамках тех же четырёх бит. Веса группируются в блоки с общей экспонентой. Главная фишка: нативная поддержка тензорными ядрами Blackwell. Никакой эмуляции, прямой маппинг инструкций на железо. Для Gemma 4 это был естественный выбор.
Сравнение форматов
Q4_K_M |
UD-Q4_K_XL |
MXFP4_MOE |
|
|---|---|---|---|
Тип данных |
INT4/INT6 |
Смешанный 4/8/16 |
FP4 блочный |
Калибровка |
Не нужна |
300K–1.5M токенов |
Не нужна |
Аппаратное ускорение |
Эмуляция CUDA |
Эмуляция CUDA |
Нативные Tensor Cores |
Риск на MoE |
Низкий |
Умеренный |
Низкий |
Почему Qwen без MXFP4
Тут всё коротко и грустно. Команда Unsloth официально вывела MXFP4-слои из форматов Qwen GGUF (Q2_K_XL, Q3_K_XL, Q4_K_XL) из-за аномалий в вычислениях. MXFP4 для Qwen 3.5/3.6 оказался нестабильным - модель может выдавать некорректные ответы или просто падать. Так что выбирать пришлось из оставшихся вариантов.
Новее ≠ лучше: перплексия не врет
Остался выбор между UD-Q4_K_XL и классическим Q4_K_M для Qwen. Документация Unsloth позиционирует Dynamic 2.0 как вершину технологии. Но метрики перплексии (PPL) на WikiText-2 рисуют другую картину:
Формат |
Размер |
Перплексия |
Деградация vs Q8_0 |
|---|---|---|---|
Q8_0 (эталон) |
~36,9 ГБ |
6,5342 |
0% |
Q4_K_M |
~20,0 ГБ |
6,6688 |
+2,1% |
UD-Q4_K_XL |
~19,0 ГБ |
7,1702 |
+9,7% |
Q4_K_M отклоняется от эталона на 2,1%. UD-Q4_K_XL - на 9,7%, причём ещё и экономит всего 1 ГБ на диске. Для архитектуры Qwen динамическое квантование оказалось заметно хуже статического. Похожая картина наблюдается и на Qwen3-Coder.
В профильных обсуждениях отмечают, что Unsloth-кванты исторически проседают именно на MoE-архитектурах со сложной маршрутизацией экспертов. Красивая идея, но не для всех архитектур одинаково полезная.
Итог простой: не гонитесь за «новым» и «продвинутым» форматом. Проверяйте метрики конкретно под свою модель. Иногда старое доброе работает лучше.
Как впихнуть невпихуемое
Все три модели, даже после жёсткого квантования, не влезают целиком в 16 ГБ видеопамяти. Gemma 4 - 15,5 ГБ, но ей тоже нужно оставить гигабайт на KV-кеш, иначе контекст захлебнётся, хотя на тестах этого не произошло. Тут нам нужен offload - выгрузка части модели в системную оперативку.
В llama.cpp есть два способа это сделать, и они работают по-разному.
Подход первый - классический --n-gpu-layers
Ключ в явном виде указывает, сколько слоёв загрузить в видеопамять. Ставишь 999 - просишь загрузить всё, что влезет. Ставишь 45 - 45 слоёв в GPU, остальное в RAM. Подбирается экспериментально: поставил, запустил, посмотрел монитор ресурсов, повторил.
Результаты с классическим offload:
Модель |
Режим |
Prompt (t/s) |
Генерация (t/s) |
|---|---|---|---|
Qwen 3.6 |
Fast |
404 |
41,3 |
Qwen 3.6 |
Thinking |
326 |
41,7 |
Qwen Coder |
Fast |
565 |
51,3 |
Qwen Coder |
Thinking |
587 |
53,0 |
Подход второй - продвинутый --n-cpu-moe
Здесь начинается интереснее. В MoE-архитектуре видеокарта должна держать в памяти все общие параметры - маршрутизатор может выбрать любого эксперта в любой момент. Но вычислительная нагрузка соответствует только активным параметрам (3B или 4B). Поэтому MoE генерирует текст быстро, но требует много памяти для хранения неактивных весов.
llama.cpp позволяет с помощью --n-cpu-moe предписать хранить определённое количество экспертных слоёв в RAM, минимизируя нагрузку на шину PCIe. Ключ, как и --n-gpu-layers, подбирается опытным путём.
Результаты с продвинутым offload:
Модель |
Режим |
Prompt (t/s) |
Генерация (t/s) |
Прирост |
|---|---|---|---|---|
Gemma 4 |
Thinking |
81 |
60,8 |
Полный VRAM |
Gemma 4 |
Fast |
58 |
61,9 |
Полный VRAM |
Qwen 3.6 |
Fast |
391 |
64,0 |
+55% |
Qwen 3.6 |
Thinking |
405 |
66,7 |
+60% |
Qwen Coder |
Fast |
596 |
57,6 |
+12% |
Qwen Coder |
Thinking |
688 |
60,2 |
+14% |
Qwen 3.6 получила прирост 55-60% в скорости генерации. Qwen Coder - 12-14%. Gemma 4 помещается целиком в VRAM, так что ей offload не нужен - она и так работает на максимуме.
Почему это работает
Механизмы внимания (Attention), которые нужны для каждого генерируемого токена, остаются в быстрой видеопамяти для всех слоёв. В медленную шину PCIe отправляются только запросы к неактивным экспертам. Поскольку экспертов задействуется мало, трафик через шину минимальный, и видеокарта не ждёт данные из оперативки.
Результат - прирост скорости более чем на 50% без апгрейда железа. Просто за счёт того, что данные разложены правильно.
Конфигурации запуска
Расписывать назначение каждого параметра не буду - получится справка, а не статья. Приведу итоговые команды, с которыми модели работали в тестах, и отмечу ключевые моменты.
Критичные параметры
Независимо от модели, эти три ключа влияют на производительность сильнее всего:
--flash-attn- включает Flash Attention, ускоряет обработку внимания--cache-type-k q8_0- тип кеша для ключей, q8_0 баланс скорости и памяти--cache-type-v q8_0- тип кеша для значений, аналогично
Без них можно вообще не начинать - потеряете ощутимую часть скорости.
Thinking on/off
Для включения и отключения режима мышления:
--reasoning on/--reasoning off- основной переключатель--reasoning-budget 0- дополнительный параметр для Qwen, полностью блокирует thinking-токены
Для Qwen-моделей одного --reasoning off оказалось недостаточно - об этом подробнее в разделе с наблюдениями.
Gemma 4
--model "gemma-4-26B-A4B-it-MXFP4_MOE.gguf" \ --ctx-size 32768 \ --n-gpu-layers 999 \ --n-cpu-moe 8 \ --flash-attn 1 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --batch-size 512 \ --ubatch-size 512 \ --reasoning off (или on) \ --jinja \ --temp 0.7 \ --top-p 0.8 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 0.0 \ --repeat-penalty 1.0 \ --no-mmap
Gemma помещается целиком в VRAM, поэтому --n-gpu-layers 999. Параметр --presence-penalty 0.0 - в отличие от Qwen, ей не нужно подавлять повторения.
Qwen Coder
--model "Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf" \ --ctx-size 32768 \ --n-gpu-layers 99 \ --n-cpu-moe 17 \ --flash-attn 1 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --batch-size 4096 \ --ubatch-size 1024 \ --reasoning off (или on) \ --reasoning-budget 0 \ --jinja \ --temp 0.7 \ --top-p 0.8 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 1.5 \ --repeat-penalty 1.0 \ --parallel 2 \ --no-mmap
Отличия от Gemma: --batch-size 4096 (больше для эффективного процессинга промпта), --presence-penalty 1.5 (подавляет зацикливание), --parallel 2 (параллельные запросы).
Qwen 3.6
--model "Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf" \ --ctx-size 32768 \ --n-gpu-layers 99 \ --n-cpu-moe 17 \ --flash-attn 1 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --batch-size 4096 \ --ubatch-size 1024 \ --reasoning off (или on) \ --reasoning-budget 0 \ --jinja \ --temp 0.7 \ --top-p 0.8 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 1.5 \ --repeat-penalty 1.0 \ --parallel 2 \ --no-mmap
Идентична конфигурации Qwen Coder - та же архитектура, те же требования к памяти. Обе используют --n-gpu-layers 99 и --n-cpu-moe 17 для оптимального распределения между VRAM и RAM.
Почему среда - это половина дела
Одна из главных ошибок при тестировании локальных моделей - не обращать внимания на то, где и как модель работает. Поднять сервер llama.cpp с API - полдела. А куда вы его подключите и как оболочка будет общаться с моделью, как вызывать инструменты, какой системный промпт зашит - разница может быть катастрофической. От полной неработоспособности до «а что, так можно было?».
Из рабочих вариантов - плагины для VS Code вроде Kilo Kode, Cline, Roo Code, отдельно стоящий OpenCode, ZED и другие IDE. Я выбрал OpenCode как самую стабильную и простую в настройке.
При работе с агентами в терминале критически важна способность модели вызывать инструменты (Tool Calling), понимать структуру проекта и следовать заданным правилам. OpenCode использует файл AGENTS.md (аналог Cursor Rules) для передачи контекста проекта. А для корректного вызова функций через llama.cpp обязательно нужен флаг --jinja - без него модель просто не увидит инструменты.
Тестовые задания были с подковыркой - создавал их не сам, а с помощью Claude, он же помог с ведением протокола.
Модели и режимы
Модель |
Активные параметры |
Режимы |
|---|---|---|
Gemma 4 26B-A4B-it |
~4B |
Thinking / Fast |
Qwen 3.6 35B-A3B |
~3B |
Thinking / Fast |
Qwen3-Coder 30B-A3B |
~3B |
Thinking / Fast |
Все модели запускались на одном железе через llama.cpp. Fast-режим для Qwen-моделей потребовал тройной блокировки: --reasoning off + --reasoning-budget 0 в скрипте запуска и enable_thinking: false в конфиге OpenCode. Просто --reasoning off оказалось недостаточно - модель всё равно думала.
Тесты
Тест 1 - Следование правилам AGENTS.md
В корне проекта лежал AGENTS.md с нестандартными требованиями: использовать префикс ai_gen_ для имён файлов, строгую типизацию и комментарий // Одобрено ИИ. Задача — написать функцию извлечения уникальных email-адресов из текста.
Кажется, простая задача. Но префикс ai_gen_ - это то, чему модель должна научиться из контекста, а не из общего знания.
Тест 2 - Tool Calling
Прочитать файл index.html, извлечь все <h1>-теги, создать headers.json с массивом заголовков.
Здесь проверяется не столько способность писать код, сколько умение модели последовательно использовать инструменты: прочитать файл, распарсить контент, записать результат. Модель, которая застрянет в цикле попыток чтения или запишет неверный JSON, провалит тест.
Тест 3 - Рефакторинг и Unit-тесты
Дан файл с функцией, в которой спрятано 5 багов:
off-by-one ошибка
два деления на ноль
возврат одного элемента вместо списка
нечитаемые имена переменных
Нужно отрефакторить код и написать исчерпывающие unit-тесты. Это самый сложный тест - многошаговый, требующий и понимания кода, и способности писать работающие тесты.
Шкала оценки
Каждый тест оценивался по 4 критериям, по 1 баллу за каждый. Максимум - 4 балла за тест, 12 баллов за всё тестирование. Ничего субъективного: тест либо проходит критерий, либо нет.
Итоговые результаты
Шесть прогонов - три модели, два режима каждая. Сухие цифры:
Модель |
Режим |
Тест 1 |
Тест 2 |
Тест 3 |
Итого |
|---|---|---|---|---|---|
Gemma 4 26B |
Thinking |
3/4 |
4/4 |
4/4 |
11/12 |
Gemma 4 26B |
Fast |
4/4 |
4/4 |
4/4 |
12/12 |
Qwen 3.6 35B |
Thinking |
1/4 |
4/4 |
2/4 |
7/12 |
Qwen 3.6 35B |
Fast |
3/4 |
4/4 |
2/4 |
9/12 |
Qwen Coder 30B |
Thinking |
2/4 |
4/4 |
2/4 |
8/12 |
Qwen Coder 30B |
Fast |
2/4 |
2/4 |
2/4 |
6/12 |
Gemma 4 - единственная модель, набравшая максимум. Qwen Coder - единственный случай, когда Thinking-режим оказался лучше Fast. Но обо всём по порядку.
Тест 1: Следование правилам AGENTS.md
Критерий |
Gemma T |
Gemma F |
Qwen 3.6 T |
Qwen 3.6 F |
Qwen Coder T |
Qwen Coder F |
|---|---|---|---|---|---|---|
Функция без логических ошибок |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
Префикс |
❌ |
✅ |
❌ |
❌ |
❌ |
❌ |
Строгая типизация |
✅ |
✅ |
❌ |
✅ |
❌ |
❌ |
Комментарий |
✅ |
✅ |
❌ |
✅ |
✅ |
✅ |
Итог |
3/4 |
4/4 |
1/4 |
3/4 |
2/4 |
2/4 |
Gemma в Fast-режиме - единственная, кто выполнил все четыре требования. Qwen 3.6 в Thinking-режиме - худший результат: проигнорировала и префикс, и типизацию, и комментарий. При этом функцию написала корректно - все модели справились с базовой задачей.
Тест 2: Tool Calling
Критерий |
Gemma T |
Gemma F |
Qwen 3.6 T |
Qwen 3.6 F |
Qwen Coder T |
Qwen Coder F |
|---|---|---|---|---|---|---|
Вызов инструмента чтения |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
Все 4 тега |
✅ |
✅ |
✅ |
✅ |
✅ |
❌ |
Корректный |
✅ |
✅ |
✅ |
✅ |
✅ |
❌ |
Нет зависания в цикле |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
Итог |
4/4 |
4/4 |
4/4 |
4/4 |
4/4 |
2/4 |
Пять из шести прогонов - идеальный результат. Единственный провал: Qwen Coder в Fast-режиме не извлекла все теги и записала некорректный JSON. Причина - не декодировала HTML-entity & в &, записав в файл "Support & Contact" вместо "Support & Contact". Модель скопировала сырой текст разметки, не интерпретировав его как контент.
Тест 3: Рефакторинг и Unit-тесты
Критерий |
Gemma T |
Gemma F |
Qwen 3.6 T |
Qwen 3.6 F |
Qwen Coder T |
Qwen Coder F |
|---|---|---|---|---|---|---|
Код стал читабельнее |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
Найдено ≥3 из 5 багов |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
Тесты корректны и запускаются |
✅ |
✅ |
❌ |
❌ |
❌ |
❌ |
Нет лишнего boilerplate |
✅ |
✅ |
❌ |
❌ |
❌ |
❌ |
Итог |
4/4 |
4/4 |
2/4 |
2/4 |
2/4 |
2/4 |
Здесь разрыв между Gemma и Qwen-моделями максимальный. Все три модели нашли баги и отрефакторили код. Но написать корректные unit-тесты смогла только Gemma - обе Qwen-модели выдали тесты, которые не запускались или содержали ошибки. Плюс Qwen-модели нагенерировали лишнего boilerplate, который только мешал.
Анализ и неочевидные находки
Gemma 4 - неожиданный лидер
Честно говоря, до тестов я не воспринимал Gemma всерьёз для задач программирования. Казалось, что ей больше подойдут текстовые задачи - суммаризация, перевод, что-то творческое. Но 12/12 в Fast-режиме и 11/12 в Thinking говорят другое.
Особенно впечатляет Тест 3. Gemma - единственная из всех моделей, которая стабильно писала корректные unit-тесты с правильной математикой. При этом у неё больше активных параметров (4B против 3B у Qwen), но меньше общих весов (26B против 30-35B). То есть Google сделали более эффективную архитектуру, а не просто «побольше экспертов».
Единственная слабость: в Thinking-режиме она пропустила префикс ai_gen_ из AGENTS.md. При повторном контрольном прогоне результат воспроизвёлся - это не случайность, а системное поведение.
Парадокс Thinking-режима
Самый интересный результат тестирования: Thinking-режим во всех моделях показал худшее следование правилам, чем Fast.
Модель |
Тест 1 Thinking |
Тест 1 Fast |
Разница |
|---|---|---|---|
Gemma 4 |
3/4 |
4/4 |
+1 в пользу Fast |
Qwen 3.6 |
1/4 |
3/4 |
+2 в пользу Fast |
Qwen Coder |
2/4 |
2/4 |
Без разницы |
Qwen 3.6 в Thinking-режиме - худший результат среди всех прогонов, 1/4. Модель проигнорировала три из четырёх правил AGENTS.md.
Вероятное объяснение: когда модель «думает», она оценивает полученные инструкции и принимает решение, что нестандартные правила вроде искусственного префикса избыточны. Fast-режим следует буквально, без рефлексии. Для практического использования это важно: если нужно точное следование правилам стиля - Fast-режим надёжнее.
Qwen-модели и проблема длинных сессий
Обе Qwen-модели провалили Тест 3 по одной и той же причине. Типичный сценарий:
Модель читает файл, начинает рефакторинг
Попытка записи большого файла вызывает ошибку инструмента
Контекст сжимается, модель «забывает» что делала
Начинает заново или останавливается с вопросом к пользователю
Это системная проблема, не связанная с режимом thinking. Qwen-модели текущих версий плохо справляются с длинными агентскими сессиями в OpenCode при работе с большими файлами.
Ещё один артефакт: обе Qwen-модели создавали новый файл refactored_code.py вместо редактирования существующего buggy_code.py. Qwen 3.6 в Thinking-режиме всё же отредактировала оригинал - видимо, дополнительное «мышление» помогло лучше понять контекст задачи.
Единственный провал Tool Calling
Qwen Coder в Fast-режиме - единственная модель, не справившаяся с Тестом 2. Причина интересная: она не декодировала HTML-entity & в &. В файле index.html был заголовок «Support & Contact», который в разметке записан как Support & Contact. Модель прочитала файл, увидела сырой текст и записала в JSON именно & — технически правильно, но бессмысленно по сути.
Все остальные модели, включая Qwen Coder в Thinking-режиме, корректно интерпретировали HTML и записали &. Разница между режимами в одном символе, но она стоила двух баллов.
Qwen 3.6 vs Qwen Coder - универсальная победила специализированную
Специализированная модель для кода прошлого поколения не превзошла универсальную текущего:
Qwen 3.6 |
Qwen Coder |
|
|---|---|---|
Thinking |
7/12 |
8/12 |
Fast |
9/12 |
6/12 |
Среднее |
8/12 |
7/12 |
Qwen 3.6 выигрывает в Fast-режиме с отрывом в три балла. Qwen Coder немного лучше в Thinking, но разница минимальна и нивелируется тем, что Coder провалил Tool Calling в Fast - это странно для «кодерской» модели, которая должна уметь работать с файлами.
Раньше я использовал Qwen Coder для небольших задач под Windows и она отлично справлялась. Возможно, здесь она пострадала от неоптимального запуска, а возможно - специализированные модели просто не так универсальны, как кажется.
Рекомендации по применению
Если коротко - что брать для каких задач:
Задача |
Рекомендация |
|---|---|
Агентская разработка в IDE (OpenCode, Cursor) |
Gemma 4 Fast - лучший баланс скорости, точности и следования правилам |
Сложный рефакторинг с тестами |
Gemma 4 Thinking - единственная надёжно пишет корректные тесты |
Быстрые правки и короткие скрипты |
Gemma 4 Fast или Qwen 3.6 Fast |
Строгое следование стайлгайду |
Любая модель в Fast-режиме - Thinking обходит правила |
Длинные многошаговые сессии |
Избегайте Qwen-моделей на текущих версиях llama.cpp |
Технические наблюдения, которые стоит запомнить
Тройная блокировка thinking в Qwen 3. Флаг --reasoning off в llama.cpp оказался недостаточным при работе через OpenCode. Надёжное решение — комбинация трёх мер: --reasoning off + --reasoning-budget 0 на уровне сервера и enable_thinking: false через extra_body.chat_template_kwargs в конфиге OpenCode. Если выставить не всё - модель будет думать, даже когда вы этого не хотите.
Индикатор «Thinking…» в интерфейсе OpenCode - это UI-статус обработки запроса, а не признак генерации thinking-токенов. Не пугайтесь, это нормально.
Галлюцинация о собственных действиях. Qwen 3.6 Fast в финальном резюме Теста 3 сообщила, что добавила ai_gen_ префикс - которого в коде не было. Небольшой, но важный сигнал для production: выходной текст модели не является надёжным отчётом о реально выполненных действиях. Проверяйте код, а не слова модели.
Итого
Локальные модели, даже сильно ужатые для запуска на бытовом железе, вполне жизнеспособны. Нет, они не заменят тяжёлые API от лидеров. Но значительную долю бытовых задач решают без проблем: написать скрипт, обработать табличку, перебросить данные из одного API в другое, сделать рефакторинг.
Плата за это - порог входа. Нужно попотеть, чтобы подобрать всё: конкретный квант (не все одинаково хороши), среду запуска, оболочку для работы, параметры. Особенно если нужна приемлемая скорость. Все «лентяйки» вроде LM Studio или Ollama облегчают запуск, но срезают углы - вы жертвуете скоростью. На моём железе это были десятки токенов в секунду.
OpenCode могу рекомендовать отдельно. Помимо возможности запуска локальных моделей, у него есть встроенный набор (ZEN) протестированных моделей по очень гуманной подписке, включая бесплатные. Одна из них, кстати, помогала мне приводить в порядок этот текст.
Отдельное предупреждение: будьте осторожнее с модными скилами вроде Context 7 или Superpowers. Они отлично работают на больших моделях и отлично забивают контекст на маленьких. Не подсовывайте их бездумно в каждый проект. А вот caveman вполне будет в кассу.
Самая слабая сторона маленьких локальных моделей - контекстное окно. Чем больше вы в него поместите, а тут надо не забывать про системный промпт от оболочки, скилы и особенно MCP, тем быстрее модель начнёт не справляться. Нужно всегда помнить об ограниченности ресурсов. Такой подход, кстати, и большие модели убивает - просто у них запас побольше.
Тема запуска LLM локалок, особенно в условиях ограниченности ресурсов, очень широкая, буду рад увидеть в комментариях ваш опыт или мои ошибки в изысканиях.
Дополнение: расширяем контекстное окно до максимума (после прочтения комментариев)
После прочтения комментариев захотелось разобраться с ещё одной практической проблемой: насколько большой контекст реально можно выжать из тех же моделей на тех же 16 ГБ.
По умолчанию во всех скриптах стоял --ctx-size 32768. Это 32К токенов - не так мало, но для агентской работы с большими кодовыми базами или длинными документами хочется больше. Модели в своих метаданных заявляют поддержку 262 144 токенов (256К). Разрыв между «заявлено» и «влезает в 16 ГБ» надо было как-то перекрыть.
Почему контекст съедает много памяти
Каждый токен в контексте требует места под KV-кэш - хранилище промежуточных результатов для механизма внимания. Размер этого кэша зависит от архитектуры модели:
KV на токен = 2 × кол-во_KV-голов × размер_головы × кол-во_слоёв × байт/элемент
У наших моделей цифры получаются очень разные:
Модель |
KV-головы |
Размер головы |
Слоёв |
q4_0 (0,5 байт) |
|---|---|---|---|---|
Qwen3.6-35B |
2 |
128 |
40 |
~10 КБ/токен |
Gemma4-26B |
~7 в среднем* |
176 |
30 |
~36 КБ/токен |
*У Gemma4 нестандартная схема: большинство слоёв имеют 8 KV-голов, каждый шестой - только 2. Итого 210 голов суммарно по 30 слоям.
Gemma4 обходится почти в 4 раза дороже по памяти на каждый токен контекста. Это важно держать в голове.
Что пошло в жертву: уменьшил формат KV-кэша
Исходные скрипты использовали --cache-type-k q8_0 --cache-type-v q8_0 — 1 байт на элемент. Переключение на q4_0 (0,5 байта на элемент) ровно вдвое снижает стоимость кэша без заметной потери качества на практике.
Это сразу даёт эффект: если переключить с q8_0 на q4_0 и одновременно удвоить контекст - потребление VRAM останется примерно таким же. Бесплатный апгрейд с 32К до 65К токенов.
Дальше подключается уже знакомый --n-cpu-moe: чем больше экспертов уходит в оперативку, тем больше VRAM освобождается под KV-кэш для расширенного контекста.
Методология подбора
Алгоритм простой и повторялся для каждого шага:
Запустить сервер с новыми параметрами
Записать потребление VRAM в простое
Отправить тестовый запрос с большим входом (несколько тысяч строк исходников llama.cpp)
Зафиксировать пиковое потребление через nvtop
Если пик > 15,3 ГБ - поднять
--n-cpu-moe, повторитьЕсли пик < 14,0 ГБ - снизить
--n-cpu-moe, повторить
Целевой ориентир: ~1-1,5 ГБ свободно при пиковой нагрузке.
Результаты: Qwen3.6-35B
Стартовал с 14,8 ГБ в простое при 32К контексте (q8_0). Финальные показатели:
Контекст |
n-cpu-moe |
Простой |
Пик при ~238К токенов |
|---|---|---|---|
32К (исходный, q8_0) |
17 |
14,8 ГБ |
— |
128К (q4_0) |
20 |
14,0 ГБ |
14,1 ГБ |
256К (q4_0) |
23 |
14,1 ГБ |
14,7 ГБ |
256К токенов - это максимум по метаданным модели, и он реально влез. Тест с 238К токенов на входе прошёл без проблем, пик VRAM остался в комфортных пределах.
Результаты: Gemma4-26B
Здесь интереснее: из-за более дорогого KV-кэша каждый шаг требует чуть большего n-cpu-moe.
Контекст |
n-cpu-moe |
Простой |
Пик при ~95К токенов |
|---|---|---|---|
32К (исходный, q8_0) |
8 |
14,8 ГБ |
— |
65К (q4_0) |
8 |
14,6 ГБ |
14,8 ГБ |
98К (q4_0) |
9 |
14,3 ГБ |
14,7 ГБ |
131К (q4_0) |
10 |
14,1 ГБ |
14,5 ГБ |
262К (q4_0) |
12 |
14,4 ГБ |
15,3 ГБ |
При 262К тест с 245К токенов на входе прошёл, пик 15,3 ГБ - запас есть, но небольшой. Попытка снизить n-cpu-moe до 11 при этом контексте приводила к OOM.
Про скорость
Расплата за большой контекст — скорость генерации немного падает с ростом n-cpu-moe, потому что больше экспертов обрабатывается через PCIe. Для Gemma4 разница между n-cpu-moe=8 и n-cpu-moe=12 на практике незначительная - модель и так была compute-bound. Для Qwen3.6 снижение заметнее, но в контексте «256К vs 32К» - это разумный обмен.
Итог
Заявленные 262К токенов контекста на 16 ГБ карте оба максимума реально достижимы. Главное - переключиться с q8_0 на q4_0 для KV-кэша и правильно откалибровать n-cpu-moe. Для Qwen3.6 это стоит 6 дополнительных единиц n-cpu-moe по сравнению с базовой конфигурацией, для Gemma4 - 4 единицы.
Конфигурации для всех вариантов контекста которые я использовал:
# Gemma4-26B — быстрые ответы, 262K контекст (максимум модели) # VRAM: idle 14.38 GB, пик при 245K токенов 15.31 GB # Скорость: prompt 1100 t/s, generation 30.94 t/s --ctx-size 262144 \ --n-gpu-layers 999 \ --n-cpu-moe 12 \ --flash-attn 1 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --batch-size 512 \ --ubatch-size 512 \ --reasoning off \ --jinja \ --temp 0.7 \ --top-p 0.8 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 0.0 \ --repeat-penalty 1.0 \ --no-mmap
# Qwen3.6-35B — быстрые ответы, 256K контекст (максимум модели) # VRAM: idle 14.1 GB, пик при 238K токенов 14.7 GB # Скорость: быстрее Gemma4 на коротких задачах --ctx-size 262144 \ --n-gpu-layers 999 \ --n-cpu-moe 12 \ --flash-attn 1 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --batch-size 512 \ --ubatch-size 512 \ --reasoning off \ --jinja \ --temp 0.7 \ --top-p 0.8 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 0.0 \ --repeat-penalty 1.0 \ --no-mmap
Комментарии (176)
nikulin_krd
11.05.2026 14:34Не знаю как у вас так получилось, но у меня Qwen 3.6 существенно лучше пишет код нежели Gemma 4. На простейших задачах Gemma 4 у меня показывала настолько плохие результаты, что использовать ее для кодинга просто не имело смысла.
Запускаю вот так:
docker run -d --ulimit memlock=-1:-1 -p 8080:8080 --name qwen3.6-code-turboquant -v ~/models:/models --gpus all local/llama.cpp:full-cuda \ --server --model /models/Qwen3.6-35B-A3B/Qwen3.6-35B-A3B-UD-Q5_K_XL.gguf --alias 'local/Qwen3.6-35B-A3B' --tools all \ --cache-type-k q8_0 --cache-type-v turbo4 --flash-attn on --no-mmap -c 262144 --host 0.0.0.0 --port 8080 \ --reasoning on --api-key sk_no_need_key -t 16 -tb 16 -tbd 16 --mmproj /models/Qwen3.6-35B-A3B/mmproj-BF16.gguf \ --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0 --presence-penalty 0 --repeat-penalty 1.0 --chat-template-kwargs '{"preserve_thinking": true}' \ --image-min-tokens 1024 --no-mmproj-offload -b 4096 -ub 4096 --mlock -ngl 99 --n-cpu-moe 40 --cache-ram 16384тут сборка с турбоквантом для большего количества токенов. Занимает 11Гб видеопамяти и еще 5 остается на KV. С курсором работает прекрасно.
И помимо perplexity(ppl), хорошо бы еще делать тест на KL Divergence.
Если первая метрика показывает как хорошо угадывается следующий токен, то вторая метрика показывает насколько хорошо работает квантизация
debagger
11.05.2026 14:34Да, я тоже удивился таким результатам. Я уже несколько дней тестирую на кодинге - очень хорошо себя показывает.
nidalee
11.05.2026 14:34Тут надо понимать, что строго говоря, из статьи не следует, что Qwen 3.6 хуже пишет код. Он хуже следует инструкциям. Но если код при этом получается лучше - значит код он пишет лучше. gpt-oss-120b, например, в баш скрипте на 30 строк умудряется пролюбить перенос строки. Зато как следует инструкциям, ух!
vyacheslavteplyakov Автор
11.05.2026 14:34Немаловажный вопрос, пишет в чем? Какая IDE или агент? Я все еще в поиске хорошей рабочей связки.
nikulin_krd
11.05.2026 14:34Cursor
SaturnTeam
11.05.2026 14:34Cursor с локальной моделью? Я пытался настроить, но у меня упорно запросы идут в паблик апи вместо заданного урл
nikulin_krd
11.05.2026 14:34Чуть позже напишу статью об этом. У курсора все улетает на их сервера и просто нахрапом это не победить
GuessWho
11.05.2026 14:34балуюсь с Kilo Code (в виде плагина для VS Code) и Zed, такая же история, после вашей статьи снова попробовал Gemma - забывает как пользоваться инструментами, постоянно останавливается, приходится подталкивать
Qwen-3.6 - сильно тупее клода, но хоть что-то может родить
Scank
11.05.2026 14:34а какой смысл выгружать слои в ЦПУ, если она полностью помещается в VRAM ?
условно IQ3_XSS влезает в VRAM. с 65к контекста удобно работать. Меньше контекста - модель даже проект прочитать не может.
nikulin_krd
11.05.2026 14:34Смысл в том чтобы очистить память для контекста, при этом потеряв где-то 1.5 в скорости, при этом получив и память и лучшую квантовку. IQ3_XSS. - это прям нищенская квантовка
Scank
11.05.2026 14:34я привел пример модели. не суть
разве выгружая слои на цпу вы не теряете в скорости ? при обращении в слой который находится на ЦПУ будет просадка, и это ощутимо, у меня с 50 токенов в таких запросах падает до 20.
kakoka
11.05.2026 14:34Интересно, какие бы модели вы бы выбрали, будь у вас m5max/128gb?
nikulin_krd
11.05.2026 14:34Dense модель Qwen3.6. Пока что она топ среди свободных небольших моделей
jshapen
11.05.2026 14:34Dense модели m5max/128gb как мертвому припарка. 15-20 токенов с секунду
nikulin_krd
11.05.2026 14:34И этого в принципе достаточно. У маков у всех одна проблема - медленная память
jshapen
11.05.2026 14:34Это очень медленно. Невыносимо ждать после флагманских моделей. От 40 уже можно что-то делать, а не ждать 90% времени
nikulin_krd
11.05.2026 14:34Вот подумываю отдать в ремонт свою вышедшую из строя 3090(что-то с памятью, возможно передавил, когда натягивал водоблок) и сделать себе инференс-сервак, потому что сейчас я сижу на 5080 и как сервак использую отдельный здоровый комп, а хотелось бы поменьше решение))
Romatio
11.05.2026 14:34Это нормально для чатика, просто пообщаться с моделью. Если задача - напили тесты на этот класс и найди, от чего они валятся, то можно поставить задачу, сходить в магазин, вернуться, оценить прогресс, и перестать баловаться локальными llm.
LoDo
11.05.2026 14:34Можно попробовать с MTP speculative decoding, там генерация должна получиться 1.5-2x быстрее.
oookkdjjjdjdj
11.05.2026 14:34Для локальной разработки 20 t/s вполне хватает. Ты же код читаешь и вникаешь, а не пытаешься за секунду сгенерить войну и мир
debagger
11.05.2026 14:34А зачем? За такие деньги уже можно нормальный GPU взять. RTX PRO 5000 или, если надо именно много vram - доску nv-link и четыре V100 32Gb. Это 100% будет быстрее чем мак работать. В маке памяти много, но не настолько она быстрая.
rPman
11.05.2026 14:34вы стоимость "доску nv-link и четыре V100 32Gb" осознаете?
VO_Obsidian
11.05.2026 14:34Доска на 4 стоит в районе 70к, 4 V100 32 Gb это около 220к. Плюс таможенный сбор ну 350к. Маки стоят в российских магазинах по 500к. Другой вопрос что под китайскую доску может не быть драйверов...
entze
11.05.2026 14:34К этому еще надо "обвязку". Mac будет медленнее, но помещаться в сумку, потреблять 6W в простое с включенным экраном :)
Проблема Mac конечно не в скорости памяти, а в том что он не CUDA-не годится (пока) для чего-то по настоящему тяжелого типа видео. Но с другой стороны, прогресс идет.
LoDo
11.05.2026 14:34Когда-то сам смотрел на на доску для двух V100. Но Volta уже legacy, драйвера до 580 и CUDA до 12.х. Сейчас на вторичке начали появлятся A100 32Gb в таком же формате, по характеристикам и сроку поддержки намного привлекательней, но ценник х 3.
dkeiz
11.05.2026 14:34если это вопрос не автору, то самые интересные сейчас - qwen 3.6 27b, легенда этой весны. если допилят, то в mtp. Если поместиться, то Qwen 3.5 122B (10B active), особенно когда выйдет обновленная 3.6 версия. Если нет - reap версии, типа Nemotron-3-Super-64B-A12B-Math-REAP или Qwen3.5-REAP-97B-A10B, из вполне может хватить для агентских задач, но кодить с ними может быть опасно, мало ли где произойдет затуп в ответственный момент.
moooV
11.05.2026 14:34если допилят, то в mtp
Буквально вчера появились ггуфы с мтп головами для квена и геммы, а в ламе близок к мержу пиар по мтп. Собрал, погонял, на 3.6-27B производительность х2 почти. Шикарно.
jarkevithwlad
11.05.2026 14:34а можно поподробнее? что собрали? и как настроить?
p.s. нагуглил сам, вроде как должно работать в ik_llama.cpp или собирать самому как описано тут
vyacheslavteplyakov Автор
11.05.2026 14:34А что именно тестироваали? Какую модель? Я на прошлой неделе гонял MTP на той же Gemma4 и не получил прироста вообще, грубо говоря на уровне погрешности, разница была 2-4%.
SabMakc
11.05.2026 14:34Там какая-то деградация была с MTP в ik_llama.cpp (с gemma4), буквально сегодня пробовал - ускорение где-то в 1.5 раза (инференс на CPU).
vitaliy-sn
11.05.2026 14:34Тоже пробовал MTP https://github.com/ggml-org/llama.cpp/pull/22673 На Qwen3.6-27B-Q4_K генерация токенов возросла с ~27 до ~50. Но не все так хорошо, обработка запроса существенно замедлилась с ~1700 до ~700. GGUF сам собирал используя imatrix от bartowski.
debagger
11.05.2026 14:34Контекст сжимается, модель «забывает» что делала
Так может сделать контекст побольше? А то 32К контекст на агентских задачах, это не серьезно.
С полным контекстом на 2080 Ti 22Gb VRAM (65 t/s на пустом контексте):
llama-server.exe -hf unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_NL --host 0.0.0.0 --port 54321 --jinja --parallel 1 --flash-attn on --cache-type-k q8_0 --cache-type-v q8_0 --ubatch-size 256 --batch-size 256 --mmproj-offload --no-mmap --reasoning-budget 8192 --reasoning-budget-message " Thinking token budget is over. Now I must give an answer."С половинным контекстом на 4080 16 VRAM, отключен модуль vision (120 t/s):
llama-server.exe -hf unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_NL --host 0.0.0.0 --port 54321 --jinja --parallel 1 --flash-attn on --cache-type-k q4_0 --cache-type-v q4_0 --ubatch-size 512 --batch-size 512 --mmproj-offload --no-mmap --reasoning-budget 8192 --reasoning-budget-message " Thinking token budget is over. Now I must give an answer."Тут трейдоф - это скорость заполнения - из-за маленького батча она ниже.
зы. Кстати по поводу vision - какой же он днищенский у Gemma и какой божественный у Qwen, тут даже сравнивать нечего.nikulin_krd
11.05.2026 14:34IQ4_NL далеко не лучшая квантизация, лучше UD-Q4_K_XL. А по поводу мультимодальности, чтобы ее не терять и чтобы она не занимала видеопамять, просто сгружать ее в RAM через
--no-mmproj-offloaddebagger
11.05.2026 14:34Вы все правильно написали, в общем случае так и есть, но у меня тут свои причины именно так настроить. Во-первых VRAM не 24Гб а 22. Во вторых мне нужен vision модуль именно в vram потому что при офлоаде он начинает работать на cpu и это очень медленно в моем случае (CPU старый и медленный), а для меня в некоторых задачах нужно чтобы он быстро работал. IQ4_NL выбрал потому что он на 4Гб меньше, чем тот же UD-Q4_K_XL и дает больше места под kv-кэш, так что получается запустить на полном контексте.
Shado_vi
11.05.2026 14:34у UD слишком сильная деградация и она становится "узколобым".
IQ4_NL не имеет таких проблем.nikulin_krd
11.05.2026 14:34Кто вам такое сказал? IQ4_NL имеет более агрессивное сжатие, причем сжатие касается именно весов экспертов в MoE. Оно априори не может быть лучше нормальных квантов.
ЗЫ: UD - это общее название методов квантизация от Unsloth
IQ4_NL
Q4_K_M
Про какую деградацию вы там говорите? На тестах IQ кванты показывают себя хуже обычных квантов.
Shado_vi
11.05.2026 14:34UD может и нормальные для обыденных стандартных популярных распространённых запросах и соответственно тестах.
но если запросы не входят в это(то есть нестандартны) то модели UD глючат жёстко.
а про обычные кванты я не писал.
я про то что IQ4_NL работает стабильней чей UD при непопулярных запросах.
но IQ4_NL менее качественней чем Q4_K_M/nikulin_krd
11.05.2026 14:34Еще раз! UD - это семейство квантов от Unsloth и никакого отношения ни к Q4_K_M, ни к IQ4_NL не имеют. Есть как UD-Q4_K_M, так и UD-IQ4_NL. И UD-Q4_K_M работает существенно лучше UD-IQ4_NL. О каких глюках вы там говорите я не понимаю. Все прекрасно работает - я не думаю что анализ исходников AOSP16 является "распространенной" задачей для локальных моделей, однако UD-Q4_K_M с ней справился прекрасно
vyacheslavteplyakov Автор
11.05.2026 14:34Есть вот такие тесты https://www.reddit.com/r/LocalLLaMA/comments/1rei65v/qwen3535ba3b_quantization_quality_speed/
UD-Q4_K_XL is significantly worse than standard Q4_K_M on this model — both larger file size and nearly 10% higher perplexity. This is consistent with other reports of Unsloth Dynamic quants underperforming on MoE architectures (u/ubergarm's KLD data on Qwen3-30B-A3B showed the same pattern). If you're running Qwen3.5-35B-A3B at Q4, use standard Q4_K_M.
как минимум с этим надо быть осторожным и перепроверить на конкретной задаче и модели, не попадаете ли вы в эту деградацию 10%.
punzik
11.05.2026 14:34Это старые данные. Модель в таком виде была на HF несколько дней после публикации 3.5. Она действительно была глючной. Потом поправили, и размер её стал на 2Г больше.
Shannon
11.05.2026 14:34Есть вот такие тесты
как минимум с этим надо быть осторожным и перепроверить на конкретной задаче и модели, не попадаете ли вы в эту деградацию 10%.
Перепроверять это правильно, но вы не перепроверили в статье, а используете как пруф цифры, которые уже не актуальны и вводят в заблуждение.
Вы ссылаетесь на старый пост со старыми квантами. Там деградация была, но это была аноримальная деградация из-за использования mxfp4 для ffn-тензоров вместо K-квантов, аномалию почти сразу заметили и исправили. Было проведено большое исследование с квантами, в итоге кванты переделали, способ квантования UD изменили.
График от комментатора выше, где видно преимущество UD квантов Qwen3.6 - это как раз тесты после исправления. По комплексной метрике KLD, которая точнее чем PPL, исправленные UD обходят остальные кванты, включая Bartowski.
https://www.reddit.com/r/LocalLLaMA/comments/1rlkptk/final_qwen35_unsloth_gguf_update/
Проблема новых моделей и квантов в том, что их исправляют несколько раз после выхода, и не стоит использовать посты 3 месячной как источник для статьи, не уточнив были ли исправления. Например, для Gemma4 было 5 исправлений, включая исправления в самой llama.cpp, и каждый раз надо было перекачивать кванты. Вначале Gemma4 была не пригодна во многих задачах, включая вызовы инструментов и агентов, сейчас это всё исправили, но если ссылаться на первые посты про Gemma4, то “выяснится”, что она “не пригодна” полностью.
vyacheslavteplyakov Автор
11.05.2026 14:34Дело в том, что это не один день делалось и писалось, а потом еще лежало на модерации. Да, проверять все - это хорошо, но не реально, пока допишешь до конца, можно начинать проверять с начала. Я обязательно посмотрю еще эти кванты, спасибо! Но в последнее время, я что-то прям проникся MXFP4. Unsloth безусловно очень крутые и двигают все вперёд, но как правильно где-то тут заметили, они последнее время очень торопятся и частенько не успевают, выкладывая сырое. Я много раз втыкался, что берешь их квант, их инструкцию буква в букву и оно работает прям плохо. Надо взять за правило ждать хотя бы недели две перед тем как тестировать, а не набрасываться на выходе.
rPman
11.05.2026 14:34Почему отключаете mmap? --no-mmap, эта фича непревзойденная, модель не загружается в память процесса, ее держит в кеше ОС, в результате все работает быстро и при следующем запуске не тратится в принципе время на загрузку. Без mmap веса модели буквально должны удерживаться в оперативной памяти дважды, в кеше файловой системы и в памяти процесса пока модель работает.
nikulin_krd
11.05.2026 14:34Он ее не держит в кэше, он ее отображает на адресное пространство и первый токен медленный, т.к. mmap вернее ядро делает ленивую загрузку. Мало того, у меня модель постоянно загружена, мне не нужно ее останавливать.
Без mmap веса модели буквально должны удерживаться в оперативной памяти дважды, в кеше файловой системы и в памяти процесса пока модель работает.
С каких это пор кэш ФС у нас обязан удерживаться после загрузки данных в оперативную память?
rPman
11.05.2026 14:34я имею в виду что бы получить такой же повторный быстрый запуск.
еще момент, при использовании mmap, так как бОльшая часть модели или вся, загружается в GPU vram, хранить в ram эти части уже не требуется, и вылезает второй бонус mmap, частичное хранение весов ram, память становится доступна для других задач, например я в lmstudio выгружал основную модель в vram а второстепенные маленькие в ram (бенчмарки не проводил), работает,.. т.е. это значимая экономия не дешевой памяти.
p.s. кеш ОС не всегда правильно убирает данные из кеша, по уму должна использоваться статистика т.е. что чаще используется то в памяти останется, но на практике там кажется удаляется то что первое в память попало... т.е. может так получиться что в выше описанном случае основная модель начнет повторно подгружать нужные участки с диска, потому что при загрузке дополнительных моделей, из памяти удалились первые попавшиеся куски... но после повторной загрузки все выравнивается и работает.
nikulin_krd
11.05.2026 14:34Я экспертов оставляю в VRAM, а веса от них выгружаются в RAM. Двойного использования не заметил
Scank
11.05.2026 14:34ваш кейс индивидуален.
Обычно не требуется загружать модели более 1 раза. поработал и выключил.
debagger
11.05.2026 14:34С ключом --no-mmap процесс памяти занимает меньше ОЗУ. В в производительности разницы не заметил. Как я понял llama-cpp пишет модель в vram, если она полностью вмещается, то отображать файл на память уже не надо. По поводу скорости загрузки - это только на этапе экспериментов важно, кроме того - llama-cpp по скорости загрузки несравнимо быстрее той же vLLM, если диск быстрый - никаких проблем.
yellow79
11.05.2026 14:34Спасибо за статью. С недавних пор решил отказаться от LM Studio в пользу llama.cpp, но я запускаю просто с
--fit on, а тут прям такой разбор всех этих флагов, очень познавательно, сам бы ни за что не стал разбираться.Удивительные результаты у вас получились, мне Gemma4 вообще никак не зашла в плане кодинг ассистента, возможно потому что я тестил на стороне Backend и там Gemma не так сильна. Вероятно ваши результаты как-то зависят от mxfp4 и дополнительных урезаний Qwen, чтобы поместиться в VRAM. У меня macbook и всё нативно с запасом влезает в Unified memory.
P.S. Пробовал работать с Qwen3.6 27B, результаты не то чтобы сильно превосходящие MoE модели, но разница ощущается, а вот скорость просто заставляет плакать, 16-20 tok/sec
vyacheslavteplyakov Автор
11.05.2026 14:34Qwen не стала хуже, она не урезана, хотя и выбрана более мелкая по размеру, просто загружена хитрым образом. Я скорее склоняюсь к тому, на сколько просто удачной в пользу той или иной модели оказалась тестовая задача. Надо брать обе и гонять на своих боевых примерах использования. Очень много зависит от того, где модель запущена, в какой оболочке, какая задача, какой систем промпт, как вызываются тулы, тот же скилл суперпауэрс, может творить чудеса, а может выжирать контекст. Вообще самая большая боль на локалках это именно размер контекста который они могут удерживать. Общее правило, что для больших платных моделей, что для локалок, если вы вывалились за 50%, начинаются проблемы, не надо ждать автокомпакции, это работает плохо. И если на условном миллионе 50% это много, то на локалке 50% от заявленного, это прям мало.
breakingtesting
11.05.2026 14:34у меня на Macbook обратные результаты с инфраструктурными задачами - Gemma4 справилась гораздо лучше.
SabMakc
11.05.2026 14:34у gemma4 проблема с окном внимания - оно совсем небольшое (Sliding Window 1024 tokens). Модель быстро “забывает” историю диалога (и это подтверждается тестами). Поэтому для агентских задач плохо подходит - только если контекста надо совсем немного для выполнения задачи.
Но сама модель очень и очень хороша - спору нет.
Bardakan
11.05.2026 14:34Самый интересный результат тестирования: Thinking-режим во всех моделях показал худшее следование правилам, чем Fast.
Вероятное объяснение: когда модель «думает», она оценивает полученные инструкции и принимает решение, что нестандартные правила вроде искусственного префикса избыточны. Fast-режим следует буквально, без рефлексии. Для практического использования это важно: если нужно точное следование правилам стиля - Fast-режим надёжнее.я работаю в Cursor. В последних его версиях 90% моделей thinking. Вы хотите заявить, что они глупее fast? Да и какой тогда смысл в thinking, если он тратит больше токенов и работает хуже?
Предположу, что причина в том, что у вас тесты слишком синтетические, проблемы с квантованием или настройкой моделей и т.п. Т.е. недостоверные результаты тестирования
vyacheslavteplyakov Автор
11.05.2026 14:34Очень просто. Есть дурная на мой взгляд и неэффективная привычка, брать самую жирную модель, выкручивать ей хай эффорт и типа хуже не будет. Будет. Она начинает жрать токены, делать оверинжениринг и тому подобные вещи.
Не зря же моделью по умолчанию в том же клоде стоит сонет.
Общее правило, моё, не навязываю. Для исследования, планирования и проектирования, включаем жирную модель с режимом размышления. Её же можем использовать для контроля и рефакторинга, а для тупого выплёвывыания строчек кода по этому плану, подключаем что-то простое и поменьше думающее. У неё задача писать код, а не фантазировать, чисто механическая.
Так быстрее и эффективнее. не зря сейчас набирает популярность подключать дешевый deepseek, для написания кода. В пару к дорогим моделям.
Вот к примеру что сами антропики советуют https://platform.claude.com/docs/en/about-claude/models/choosing-a-model
ilriv
11.05.2026 14:34Вопрос от чайника: можно ли использовать и дискретную, и встроенную видеопамять?
DamirMur
11.05.2026 14:34Можно, но не нужно потому что встройка берет из озу. Скорость падает из-за перегонов
LoDo
11.05.2026 14:34Если модель немного не влазит в VRAM, то использование unified memory (GGML_CUDA_ENABLE_UNIFIED_MEMORY=1) быстрее обычного offload (у меня так получалось) + защита от OOM.
nikulin_krd
11.05.2026 14:34обязательно нужен флаг
--jinja- без него модель просто не увидит инструментыОн не нужен! jinja включена по-умолчанию. Читайте документацию.
Incognito4pda
11.05.2026 14:34Да тут что автор нагородил в параметрах, почти всё по дефолту включено. По сути, я уже второй месяц юзаю llama.cpp без параметров "тонкой настройки". Порог вхождения в llama.cpp уже давно гораздо проще чем в Ollama. В параметрах запуска достаточно указать хост, порт, папку с моделями - Всё! llama.cpp сам мгновенно подберёт оптимальные параметры для модели и выжмет из вашего железа все соки для достижения максимальной скорости генерации.
Scank
11.05.2026 14:34согласен, причем разницы между llama.ccp и lmstudio в скорости даже не увидел. может быть погрешность 2-4%
Shannon
11.05.2026 14:34Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf
Q4_K_M - проверенная классика
Формат от автора bartowski, на которого я рекомендую обратить внимание.
Q4_K_M отклоняется от эталона на 2,1%. UD-Q4_K_XL - на 9,7%
Q4_K_M - это не формат от Bartowski, у него не классические статические Q4_K_M кванты, хоть он и называет их так.
Bartowski для всех своих квантов применяет кастомные динамические рецепты, например, ffn он квантует как Q3, хотя должен как Q4, и для всех статических квантов, кроме Q8_0, он применяет свой imatrix, который не должен применяться для классического Q4_K_M.
Другая проблема в том, что в imatrix Bartowski нет или мало русского языка в датасете, и она включает в себя wiki text, поэтому показатели PPL завышены, но на практике квант оказывается сломан и не работает как надо, что трудно понять.
Новее ≠ лучше: перплексия не врет
Но метрики перплексии (PPL) на WikiText-2 рисуют другую картину:
Итог простой: не гонитесь за «новым» и «продвинутым» форматом. Проверяйте метрики конкретно под свою модель. Иногда старое доброе работает лучше.
Перплексия постоянно врёт. К PPL нужно относиться с осторожностью, её не стоит сравнивать в лоб, это не мера качества модели, это первичная оценка деградации квантов в рамках одного создающего, чтобы заметить аномальное отклонение. Для оценки качества кванта вместо PPL используют KLD, эта метрика показывает более объективную деградацию кванта.
Недавно показывал как делается KLD замер, и в качестве сравнения как раз брал классику Q4_K_M, которая выступила на уровне UD-Q3_K_XL.
Чем ниже значение, тем лучше Unsloth-кванты исторически проседают именно на MoE-архитектурах со сложной маршрутизацией экспертов
Спорное утверждение. В недавней статье я показывал на что способен квант Qwen3.6-35B-A3B UD-Q2_K_XL, этот квант хуже чем UD-Q4_K_XL, но даже в таком низком значении он не сломан и выполняет работу.
UD-Q2_K_XL сделала реплику Win11 с рабочими окнами, пуском и анимациями:
Qwen3.6-35B-A3B-UD-Q2_K_XL, 4060 16гб, 60 t/s И в агентном режиме создала проект “Minecraft в браузере”, включая правки через Vision:
Qwen3.6-35B-A3B-UD-Q2_K_XL Gemma4 только в размере Dense 31B смогла что-то подобное повторить, MoE 26B-A4B не справилась и в программировании она сильно хуже себя показывала.
rPman
11.05.2026 14:34каким агентом вы правки через vision делали? или скил описали?
Shannon
11.05.2026 14:34Это просто скриншоты агенту, в qwen code в новых версиях можно копи-пастить изображения, либо обычным
@bug7.pngдобавлять в диалог.
Кстати, по поводу качества. Пока видел мало обсуждений свежего Qwopus, это Qwen3.5 и 3.6 дообученные на выдаче больших моделей. Есть в разных размерах, включая Qwopus3.5-4B. Сейчас пробую Qwopus3.6-27B-v1-preview, в целом впечатления положительные, как будто бы лучше чем простой Qwen3.6 27B, но нужно больше экспериментов.
rPman
11.05.2026 14:34хех, я на предыдущей версии (не было поддержки vision хотя модель могла) запилил с ее же помощью mcp сервер, который умеет это делать, но держать изображение нативно в контексте это да (кстати так умеет и opencode)
VO_Obsidian
11.05.2026 14:34Ну да, тема ультраагрессивных квантов не раскрыта, плюсую. gemma-4-26B-A4B-it-UD-Q2_K_XL за несколько запросов в опенкод написало: 1. Клон марио 2. Клон вин 11
Скрытый текст
Примитивно, НО, я тут не парился с системными промптами и вообще впервые увидел опенкод 30 минут назад, плюс используюя турбоквант (AmesianX) модель целиком с контекстом 64к влезает в 15 гигов врамы на 5070ti (1 уходит на 4к монитор). Qwen3.6-35B-A3B-UD-Q2_K_XL.gguf - 128к. У обоих примерно одинаковая картина 90-100 т/с с пустым контекстом 40-60 т/с с заполнением наполовину. Есть проблемы с зацикливанием, но в общем с тулзами могут делать вещи.
vyacheslavteplyakov Автор
11.05.2026 14:34Я бы протестировал на чем-то менее шаблонном. Это буквально как попросить модель для генерации изображений воспроизвести Мону Лизу или Квадрат Малевича. Змейку еще можно попробовать попросить написать или Тетрис. Я к тому, что под эти задачи есть 100% максимальное покрытие в данных на которых модель обучена, ей надо быть ну очень тупой и кривой, чтобы на этом облажаться. Просто ради интереса, попробуйте аналогично попросить её написать что-то типа копии игры Kid Kool для NES, будет интереснее.
vitaliy-sn
11.05.2026 14:34>например, ffn он квантует как Q3, хотя должен как Q4
Это не так, ffn он квантует >= того, что указано в имени модели.
Вот например значения для Qwen_Qwen3.6-27B-Q4_K_L.gguf:
7: 89128960 | 17408, 5120, 1, 1 | Q6_K | blk.0.ffn_down.weight 8: 89128960 | 5120, 17408, 1, 1 | Q4_K | blk.0.ffn_gate.weight 9: 89128960 | 5120, 17408, 1, 1 | Q4_K | blk.0.ffn_up.weightShannon
11.05.2026 14:34Это хорошо, что он откатил свой рецепт, я перестал качать его кванты когда он начал, пытаясь выиграть в размере, часть ffn квантовать в Q3_K, что ударяло по качеству Q4_K_M. Если он ещё увеличит процент русского текста в своем imatrix с 1% хотя бы до 5%, то его кванты будут совсем хороши.
nikulin_krd
11.05.2026 14:34Это системная проблема, не связанная с режимом thinking. Qwen-модели текущих версий плохо справляются с длинными агентскими сессиями в OpenCode при работе с большими файлами.
Сильное утверждение, но проверять мы это конечно не будем. MoE Qwen 3.6 вместе с Cursor прекрасно справилась с полными исходниками AOSP16 и позволили разобраться во флоу работы Zygote
rPman
11.05.2026 14:34я ковыряю qwen и opencode последние две недели, решаю разные задачи, недостатки слабых моделей видны почти сразу, и проблема контекстного окна вылезает прямо видно, чаще всего вылезает в виде циклических повторений блоков последних сообщений.
то что иногда это работает полностью автономно, это просто шикарно, сам в шоке от того как модели читают код и отвечают на вопросы по нему... и не важно что они могут что то опустить, теперь у меня есть буквально возможность, загрузить случайный огромный репозитарий проекта и спросить, а как в такой то хитрой ситуации поведет код, и получить ответ через несколько минут.
nikulin_krd
11.05.2026 14:34У меня максимально возможное количество токенов для модели(если не использовать YaRN) и курсор прекрасно следит за контекстным окном. OpenCode меня выбесил тем, что у него тул коллинг какой-то странный и далеко не всегда работает как надо
nidalee
11.05.2026 14:34Qwen 3.6 из коробки имеет контекст ± как Sonnet, 200к токенов. Если вам память позволяет, конечно.
DzenO
11.05.2026 14:34Встретил упоминание про проблемы с инстументами в OpenCode при использовании локальных моделей. А как с этим бороться? А то спустя несколько вопросов, начинает тупить с записью файлов на диск. Пишет что записал и переубедить не получается
nidalee
11.05.2026 14:34Использовать другие оболочки - например, Qwen Code.
DzenO
11.05.2026 14:34На моделях по АПИ такого нет, исключительно с локальными. И как бороться вообще непонятно. А использовать другого агента ... попробую, может будет лучше
nikulin_krd
11.05.2026 14:34Используйте модели с нормальным чат темплейтом. Например от Unsloth, которая умеет нормально и в preserve_thinking и в роль "developer" и правильно работает с тулами
Weron2
11.05.2026 14:34Хорошая статья. Люблю практические. Запускаю на ртх 3070 8 гб - выдают по 27т/с не уверен что смогу выжать больше, но попробую ваши лайфхаки
Вот вы писали про эти 2 параметра, а в недавней статье говорили что их можно на -cmoe поменять. Это так?
Было бы классно гемма4 с ассистентом потести, но жаль что unsloth не спешит выпустить кванты свои для него. Видимо связано с тем что в llamacpp официально еще не завезли mtp
vyacheslavteplyakov Автор
11.05.2026 14:34можно да, надо тестировать, это же не сложно. в форках llama уже завезли MTP, но он не даёт прироста в Gemma, во всяком случае у меня не получилось. Вот можно потестировать, придётся правда собрать форк и у него чуть другие ключи запуска чем у оригинала, но все работает. https://huggingface.co/AtomicChat/gemma-4-26B-A4B-it-assistant-GGUF
SabMakc
11.05.2026 14:34Возьмите от других assistant-модель - работать будет не хуже.
P.S. я бы рекомендовал уходить от unsloth - они тюнингуют модели под бенчмарки, модели тупеют в других задачах. В частности с русским у них становится заметно хуже. Или без мышления модель начинает откровенно тупить.
nikulin_krd
11.05.2026 14:34Прекрасно работает с русским и отупения не заметил))) У вас там случаем не Cuda 13 стоит?)
SabMakc
11.05.2026 14:34Нет, у меня “честный” инференс на CPU )
С русским отупление более заметно на UD-Q2_K_XL. Но UD-Q4_K_XL тоже подвержен, пускай и гораздо менее заметно.
Что более заметно - при отключении мышления Qwen3.6-35B-A3B-UD-Q4_K_XL не сумел написать достаточно простой алгоритм. Прием с этой же задачей “древний” Qwen3-Coder справился с 1й попытки вообще без нареканий.
К слову, Qwen3-Coder тоже UD-Q4_K_XL, что говорит о том, что раньше менее агрессивно квантовали )
Ну а я вместо unsloth теперь качаю кванты от bartowski - и с “проблемным” алгоритмом он прекрасно справился с 1й попытки и без размышлений.
P.S. пробовал вместо unsloth использовать AesSedai, что по бенчмаркам на уровне unsloth. Но он точно также затупил. Так что я теперь на модели “по бенчмаркам” не смотрю совсем. Это даже анти-рекомендация. Высокий балл в бенчмарке достигается за счет заточки под бенчмарк. А все остальное проседает.
P.P.S. “тупление” более заметно в том, что ответы становятся многословнее. Qwen3 мне нравился именно своей немногословностью. Что в думающем режиме, что в не-думающем. А тут у gemma4 ответы были заметно короче, чем у Qwen3.6 (местами в 2 раза короче). На моделях от bartowski же ответы Qwen3.6 немного короче ответов gemma4.
nikulin_krd
11.05.2026 14:34Я могу объяснить такое поведение. У Unsloth упор идет как раз на thinking у него эти слои практически не сжимаются, у bartowski упор на основу. Вот и вся разница. Но unsloth c preserve_thinking выдает прекрасные результаты
SabMakc
11.05.2026 14:34preserve_thinking- это немного про другое все-таки. И тем более это не заслуга unsloth. У bartowski он тоже работает - это свойство самой модели (Qwen3.6).А вот длина ответа - очень интересный показатель ) Жаль, что очень недооцененный при сравнении квантов.
P.S. там нет thinking-слоев. Unsloth стал все слои квантовать динамически, замеряя метрики. Q4_K_X обычно именно слоям внимания выделялось больше места. А в Unsloth Dynamic 2.0 стали подбирать размер под каждый слой, ориентируясь на метрики. И ключевое - у разных экспертов в МоЕ разное квантование идет, что как раз и портит квантование для “неважных” экспертов. А “неважность” определяется по их собственным тестовым данным.
nikulin_krd
11.05.2026 14:34А я и не писал preserve_thinking это заслуга unsloth. У них он просто работает нормально за счет оптимизированного чат темплейта
SabMakc
11.05.2026 14:34ОК, они оптимизировали чат-темплейт (хотя еще смотреть надо, в чем именно их заслуга и есть ли отличия от bartowski). Но Unsloth все равно портит модели своим UD. В бенчмарках они хороши, но в реальной работе отстают. И я лично ловил кривые ответы неоднократно.
Даже в Thinking-режиме это видно по многословности ответов относительно bartowski. Да, я не ловил явно кривых ответов в Thinking-режиме от Unsloth (потому как обычно в не-думающем режиме гоняю). Но повышенная длина ответов явно говорит о плохой работе (и разница в разы).
P.S. в чат-темплейте от Unsloth нет никаких отличий касательно
preserve_thinkingот темплейта bartowski.
vyacheslavteplyakov Автор
11.05.2026 14:34Чтобы модель меньше трепалась и больше делала, очень рулит Caveman он к стати и качество работы улучшает благодаря этой немногословности https://github.com/JuliusBrussee/caveman/blob/main/README.md
FMW14
11.05.2026 14:34Хотелось бы видеть в подборке моделей еще gpt-oss-20b. Эта со свистом влезает в 16гб врам вместе с контекстом.
Ну и как уже отметили, для тестов стоило поставить контекст больше, возможно результаты были бы другими
slabnoff
11.05.2026 14:34Ну не прям со свистом. Но влезает. Если вам будет полезно субъективное мнение и опыт, то: относительно qwen3.6-35b с включенным cpu-moe по производительности на практике несколько, но не кардинально быстрее, но по качеству работы с кодом очееь заметно хуже. Железо 5060ti 16 gb + xeon e5 2690v4.
test4354545
11.05.2026 14:34тут люди запускают dense qwen 3.6 27b на 16 гб vram с контекстом в 100к юзая турбоквант. Было бы интересно прогнать ее на ваших тестах https://www.reddit.com/r/LocalLLaMA/comments/1svnmgo/quant_qwen3627b_on_16gb_vram_with_100k_context/
nikulin_krd
11.05.2026 14:34В 4-бит квантах она не влазит в 16Гб, а когда она не влазит количество токенов в секунду резко падает
AlexandrUrura
11.05.2026 14:34попробовал штук 20 моделей с той же картой+Ubuntu+llama.cpp+cuda13. Все 14b не понравились, понравилась упомянутая Gemma 4 26B-A4B-it 80т/с стабильно, хорошо рассуждает, для кодинга у google ai попросил написать 7 задач на go с усложнением уровня и туда же кидал ответы,
Qwen3.6-35B-A3B-UD-Q5 завалилась на 3,с тестами справилась только одна модель cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL.gguf,скорость 40 - 12 т/с, комментарии только на английском и китайском. Возможно еще стоит потеститьopenai_gpt-oss-20b-MXFP4.gguf. Для себя сделал вывод что 16Gb мало, минималка 32Gb. Практическое применение пока придумал только одно - аналитика по эксель файлам с персональными данными, в программировании codex лучше локальных моделей на две головы. Параметры запуска:./llama-server -m models/bartowski/cerebras_Qwen3-Coder-REAP-25B-A3B-GGUF/cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL.gguf \
-t 7 \
--alias "cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL" \
--ctx-size 32000 \
--cache-type-k iq4_nl \
--cache-type-v iq4_nl \
--flash-attn on \
--parallel 1 \
--temp 0.4 \
--top-k 20 \
--top-p 0.9 \
--min-p 0.1 \
--batch-size 512
--repeat-penalty 1.1 \
--host 0.0.0.0 \
--port 8080
nidalee
11.05.2026 14:34Для себя сделал вывод что 16Gb мало, минималка 32Gb
24 удовлетворительно, Q4 лезет с квантованием контекста до Q8, около 80-90к токенов истории - как рядовой вызов субагента в Claude Code, там примерно такой же бюджет выходит.
vyacheslavteplyakov Автор
11.05.2026 14:34Полностью согласен. 16г прям мало, современные открытые модели едва помещаются без танцев с бубном. Надо 24, а лучше 32. Это как с 3D принтерами, можно мучать один, пытаясь выжать из него чуть больше скорости, теряя качество, а можно просто купить второй и сразу ускориться в двое, при условии серийной печати конечно.
nikulin_krd
11.05.2026 14:34Если бы вы почитали бы документацию Unsloth, то поняли бы где вы сделали ошибку. Уберите 13-ую Cuda и замените на последнюю 12-ую. cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL.gguf - не советую использовать этого Франкенштейна на каких-нибудь +- нормальных задачах - мало того что порезаны слои, так еще и кванты ужаты через IQ
MaxEkb77
11.05.2026 14:34Вообще у gemma4 обрезанное swa-окно до 1500 токенов, для кодинга лучше запускать с swa-full
SabMakc
11.05.2026 14:34Мышление, что у gemma4, что у qwen3.6 прекрасно выключается через
--chat-template-kwargs '{"enable_thinking": false}'(можно и в запросе передавать - переопределяет значение из аргументов).Для Qwen3-Coder выключать мышление не нужно - это не “думающая” модель. Если результаты в “думающем” режиме другие - значит от прогона зависит.
И gemma4 лучше не использовать с длинным контекстом - у нее окно внимания в 1к токенов (Sliding Window 1024 tokens), на длинных контекстах она просто забывает что было много токенов назад. И с вызовом инструментов у нее не очень - много жалоб на это встречал.
P.S. для gemma4 вышли assistant-модели (
--model-draftдля основной), ускорение в 1.5 раза - очень неплохо )vyacheslavteplyakov Автор
11.05.2026 14:34Нет там ускорения в 1.5 раза, его вообще нет, во всяком случае пока на форке. Ждем официальную поддержку в llama.
vyacheslavteplyakov Автор
11.05.2026 14:34По поводу MTP выше несколько раз упоминали. Я делал небольшой быстрый тест, но до конца не разобрался пока и чудо обещанное не получил.
Что делал
Стандартный llama.cpp не поддерживает MTP — потребовался кастомный форк
atomic-llama-cpp-turboquant. Собрал его рядом со старой сборкой, не трогая рабочую конфигурацию.Модели:
Основная:
gemma-4-26B-A4B-it-MXFP4_MOE.gguf(16.6 ГБ) — та же, что в статьеDraft:
gemma-4-26B-A4B-it-assistant.Q4_K_M.gguf(311 МБ) — новая, специально обученная голова для предсказания токенов
Ключевые параметры запуска:
--spec-type mtp --mtp-head gemma-4-26B-A4B-it-assistant.Q4_K_M.gguf --draft-block-size 3 --draft-max 8Всё остальное оставил как в рабочих конфигах:
--n-cpu-moe 8,--ctx-size 32768,--cache-type-k q8_0и т.д.Результат
MTP технически отработал корректно — 73% acceptance rate (47 из 64 задрафтованных токенов были приняты основной моделью).
Но прироста скорости нет:
Старый llama.cpp (baseline) 61,9 t/s Новый форк + MTP ~61–67 t/s
Я так думаю, что это не сработало потому что брал MXFP4 которая и так лезет в память целиком, надо подождать пока такие вспомогательные модельки появятся для чего-то еще и оно будет большего размера, брать кванты выше для Gemma я смысла не вижу, они не влезут в мои 16 гигов и будет шило на мыло.
SabMakc
11.05.2026 14:34--draft-max 3- рекомендуют от 1 до 4, на 3 оптимум (судя по тестам). И попробуйте на ik_llama.cpp, у меня параметры--spec-type mtp --draft-max 3 --draft-p-min 0.0.У меня
draft acceptance rate = 0.54307 ( 290 accepted / 534 generated), на--draft-max 4немного падает, ускорения меньше (но тут тестовый запрос влияет, тестирую на простом “Что ты умеешь?”). Но судя по всему,atomic-llama-cpp-turboquantнужен хотя бы ради turboquant - чтобы и контекст влезал в VRAM.
oookkdjjjdjdj
11.05.2026 14:34Хороший разбор параметров запуска, мало кто вообще лезет дальше дефолтных настроек, только для реального рефакторинга крупных проектов все эти локалки пока годятся максимум как продвинутый автокомплит
eldog
11.05.2026 14:34Я упёрся в оболочку. Запустить модель не особо сложно, но потом хотелось терминальное приложение типа gemini или copilot, и это как бы тоже можно, ollama позволяет запустить копилот со своей моделью, но потом начинают обламываться вызовы потому что не поддерживает reasoning. И вот что там менять дальше я не разобрался (ну и рогом упираться не стал, честно говоря, бюджет времени на исследование как оно работате был уже потрачене :-) )
nik135
11.05.2026 14:34Товарищи, а кто-нибудь пробовал Intel Arc Pro B70 для целей локального запуска?
https://serverflow.ru/blog/novosti/intel-predstavila-arc-pro-b70-i-b65-peredovye-ii-uskoriteli-s-32-gb-gddr6-na-arkhitekture-big-battle/
tigralen
11.05.2026 14:34У меня Intel A770 16 Gb.
llama.cpp в Vulkan показывает BF16 - нет, тензорных блоков - нет
Хотя по обещаниям Intel все должно быть. В интернет уверяют, что для B-серии драйвера допилили, а про A-серию "когда нибудь". Intel на мейнстрим в виде llama.cpp и прочего пофиг, на нормальные драйвера пофиг, она черти чем занимается.
DenisDenisMIS
11.05.2026 14:34у меня простой мак, 8 Гб. LLM Studio установил. Даже закачался дистиллированный DeepSeek. Работать невозможно(
APKAH9
11.05.2026 14:34Автор, в целом все грамотно настроил, но у тебя reasoning не работал на Квене нормально потому что:
Qwen3-Coder 30B-A3B coder не поддерживает режима Thinking/Reasoning, но у нее огромный контекст (256К-1М) поправь для неё ещё:
--mmap --n-gpu-layers 48Qwen 3.5/3.6 35B-A3B qwen использует chatML для jinja, нужно добавить параметр в llama
--cmlUPD: или просто скачай фикс, вышел недавно:
https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates
--jinja --chat-template-file qwen3.6/chat_template.jinjaПопробуй еще вот эту модельку:
https://huggingface.co/froggeric/Qwen3.6-27B-MTP-GGUF потом расскажешь, как она.
Я пришёл к выводу, что для всех этих локальных инференсов всё же нужно юзать универсальный инструмент VS Code + Continue. Все остальные одеяло на себя тащат со всеми этими спецификациями и ограничениями тупыми ради долларов.
nikulin_krd
11.05.2026 14:34Что самое интересное исправленный чат темплейт, который решает все указанные проблемы, у unsloth появился еще с самого первого выкладывания их тюненной модели))
Scank
11.05.2026 14:34Continue это что ? для меня самый удобный qwen cli
APKAH9
11.05.2026 14:34Continue это oss плагин в VS code, в виде чат-интерфейса как и встроенный copilot, но без привязок и лимитов как copilot, а работающий как отдельный агент (инстанс). Ты сам выбираешь, какой llm/cli/backend использовать. Единственное, нужно немножко попариться, чтобы четко настроить backend (mcp/tools/docs/rag и т.д)
в continue можно много инстансов поднять на разных агентах, то есть это полноценный agentic-workflow инструмент, хотя изначально он создавался как авто-комплитер.
Mayurifag
11.05.2026 14:34Вывод про следование инструкциям, это же вроде температурой регулируется. Не пробовали прям посильней занижать?? до 0, 0.1, 0.2? У меня часто 0.2, если я уверен в промпте и не требуется вот этого галлюциногенного творчества от модели.
APKAH9
11.05.2026 14:34Инструкции из системного промпта берутся, которые всегда сидят в кеше и работают только в stateless (без сохранения состояния модели/без сохранения истории предыдущих запросов). Вы говорите про attention. Снижение температуры как раз на attention влияет, но на моей практике температуру лучше не трогать, а грамотно и кратко составить инструкцию, подбирая каждое слово так, чтобы их векторные представления были далеко друг от друга.
Лучше киньте боевой пример, я наглядно вам покажу
breakingtesting
11.05.2026 14:34Интересно было почитать. Про свой опыт локальных моделей с слабым и помощнее Mac железом написал здесь:
https://habr.com/ru/articles/1033614/
Scank
11.05.2026 14:34Посмотрите на квантование APEX . там еще одна "революция" https://github.com/mudler/apex-quant
AVKinc
11.05.2026 14:34А локальные модели ищут ответы в интернете?
SabMakc
11.05.2026 14:34Ищут не модели в интернете, а обвязка к ней. И если клиент умеет - то и модель может использовать интернет (делается или через MCP, или через обогащение запроса результатами поиска по нему).
tigralen
11.05.2026 14:34Теоретически можно настроить tools (MCP) будут искать. Но tools для поиска или платный, или на забугорных сайтах которые запрещает РосЗапрет.
nikulin_krd
11.05.2026 14:34Или использовать IDE где поиск есть по-умолчанию. Или использовать MCP от Brave и пользоваться бесплатным кредитом, только нужна зарубежная карта
vyacheslavteplyakov Автор
11.05.2026 14:34Brave с тех пор как стал просить деньги, потерял для меня ценность, я переехал на Firecrawl, еще есть альтернативы и не хуже ни разу, но сейчас что-то не могу в закладках найти, пороюсь если надо.
nikulin_krd
11.05.2026 14:34Он сейчас не просит денег. Есть бесплатные 5 баксов в месяц, которых для своих нужд хватит с головой
vitaliy-sn
11.05.2026 14:34Я для поиска в интернете использую MCP https://github.com/pwilkin/mcp-searxng-public и self hosted searxng.
vyacheslavteplyakov Автор
11.05.2026 14:34У MCP есть плохая черта, это тяжелая штука, он сидит в контексте и памяти постоянно внутри сессии. Имеет смысл держать поиск в виде MCP, только если это основная функция рабочего процесса. То есть то, что делает агент конкретный воркфлоу, непосредственно и постоянно его использует.
Использовать MCP для поиска в формате иногда если вдруг понадобится, очень не рациональное занятие. Проще сваять скилл и в скилл положить мелкий заранее написанный скрипт, который будет дёргаться в тот момент, когда он нужен и агент будет делать запрос, получать и отдавать ответ и больше не тратить на него ресурсы.
rPman
11.05.2026 14:34в основном поиск выглядит как - сделать запрос в гугл и получить странички по ссылкам.
полноценно шариться по сайтам, читать форумы и т.п. это кажется нет, или есть но в зачаточном состоянии, и мне кажется причина в том что это опасно, инструкции модель может просто прочитать на сайте, и выполнить их.
p.s. особенно это грустно если вы автономному агенту разрешили скрипты писать и запускать, а вы скорее всего разрешили, даже если в виртуалке.
Mersavets
11.05.2026 14:3435b вышла неудачная, как и прошлая
27b модель плотная, даже в Q2 будет в разы лучше чем 35b moe даже в q8
Она просто сама по себе в разы лучше, а скорость упадёт процентов на 15
TimurZhoraev
11.05.2026 14:34Что по сравнению с арендой облачного сервиса с GPU, насколько это будет дороже токенов по самой модели. Иными словами за сколько часов аренды сервиса он выест стоимость всей видеокарты при заданной конфигурации, вот это было бы интересно
vyacheslavteplyakov Автор
11.05.2026 14:34Проще и дешевле взять подписку на облачные модели, на пример https://opencode.ai/ru/zen за эти 20$ рука отсохнет лимиты выжигать. Локалка имеет смысл когда нет интернета или нельзя в интернет. Аренда сервера, возня с ним для запуска с настройками, по моему лишняя трата времени, но точно не экономия денег.
Scank
11.05.2026 14:3420$ рука отсохнет лимиты выжигать.
Это не правда. Выжигаются достаточно быстро. Смотрите там у чатгпт например вход $0.75 выход $4.50, у Кими 2.6 Выход 3$ - у меня за один запрос агент анализируя проект и добавляя во все места новые импорты сжег 1,5 млн токенов =)
Coprolog
11.05.2026 14:34Интересная статья, многое надо проверить. Только хочется заметить, что для реальных задач 32к контекста - это ни о чем. Даже чтоб проект небольшой прочитать этого может не хватить.
OmManiPadmeHum
11.05.2026 14:34Огромное спасибо за статью! Отдельный лайк комментариям! Сам планирую поэкспериментировать на связке x2 RTX 5060 Ti 16GB. Статья как раз вовремя буду настраивать, тестить.
triller599
11.05.2026 14:34Спасибо за результаты, пойдёт как ориентир. Однако Вы сами не нейросеть? :)
1) у Вас "Gemma 4 - 15,5 ГБ" а в другом абзаце "помещается в VRAM". И потом приводите порог в 15.3.. Если сама сеть 15ГБ+, то в 16ГБ она никак не лезет, Ваши же пороги это подверждают.
Хотя ладно:
2) Не могли бы сказать, кто сжимает Гемму MXFP4 в 15.5 ? Я вижу только 16+ варианты
3) Так понимаю, что llama.cpp ещё не поддерживает NVFP4? Иначе можно было бы взять квант напрямую от Nvidia.
4) И по моим наблюдениям, часто QWEN3.6 –reasoning off работает лучше, чем с размышлениями. Однако уже не раз натыкался, что для qwen надо именно что НЕ ограничивать бюджет на размышления, типа это у них в архитектуре заложено. Однако на железках уровня 5060/5070 выглядит малореально..
vyacheslavteplyakov Автор
11.05.2026 14:34Лезет, но прям на тоненького, не под виндой так точно... Моя весит 15,5, а вот где взял не помню, скорее всего тут, хоть тут она и больше
https://huggingface.co/unsloth/gemma-4-26B-A4B-it-GGUF/tree/main
Для написания кода размышлять не нужно, лишняя трата времени, ресурсов и контекста. Размышлять нужно на этапе планирования. Грубо говоря врубаем super-powers, пишем план полностью, потом переключаемся на режим без думания и пишем быстро быстро код. Потом тесты, дебаг и все такое.
Scank
11.05.2026 14:34качал вчера такую же. После 2-3 запросов модель крашилась. Еще из коробки она не принимала запросы и нужно было template подставлять корректный. Вообщем гемма мне не понравилась, но по бенчу вроде как она лучше умеет кодить, но ей нужны с ходу жесткие инструкции и уточнения каждого чиха.
razex2
11.05.2026 14:34Может быть эта?
https://huggingface.co/noctrex/gemma-4-26B-A4B-it-MXFP4_MOE-GGUF/tree/main
kv_count у неё меньше чем у версии Unsloth. На что это влияет?vyacheslavteplyakov Автор
11.05.2026 14:34Нет, все жё Анслот. она при скачивании по факту на диске 15,5 занимает, а не сколько на сайте написано. Видимо разная оценка занимаемого места. Я не беру всякие совсем уж ноунейм поделки не понятно как и для чего исковерканные.
triller599
11.05.2026 14:34Или обновили, или ещё что.. Сегодня скачал - как написано 16.5, так и на диске занимает 16.5
Впрочем не важно, 15.5 слишком много для реальной работы на GPU, необходимо выносить часть слоёв. Плохо!
Делали бы они все модели 20B, как OpenAI - вот это комфортный размер для 16ГБ. А тут прям как насмешка..
А про паплайн.. спасибо за совет! Я лишь имел в виду, что если уж включать "думание", то его не следует ограничивать, иначе ерунда получается.
vitaliy-sn
11.05.2026 14:34llama.cpp с недавнего времени уже поддеживает NVFP4, но аппаратное ускорение все еще полноценно не реализовано. Я пробовал около месяца назад, когда увидел, что добавили поддержку и скорость оказалась даже хуже чем с Q4_K_M. Модель прямо с hf/nvidia использовать не получится, т.к. они не выпускают NVFP4 GGUF.
triller599
11.05.2026 14:34Да, уже разобрался про Nvidia.
Жаль. Тому же Unsloth возможно имеет смысл "подкрутить" бенчмарки, а вот Nvidia вроде особого смысла нет, могут просто качественно стараться сделать.
APKAH9
11.05.2026 14:34Вопрос знатокам, а ведь можно же расширить model context (который 32k) до условных 128k, задействуя не VRAM видеокарты, а RAM/Nvme?
GPU Direct Storage/HiFC - это тут применимо вообще? Скорость t/s вообще не важна, главное чтобы слабое железо тянуло сложные задачи. Или все-таки порекомендуете лучше думать в сторону выбора другой модели и квантизации? Ну просто 32к это совсем ниочем, функцию написать и задебаждить максимум…
nikulin_krd
11.05.2026 14:34Можно! --no-kv-offload вам в помощь, но скорости инференса не ждите - сразу раза в 3 ниже
Хотите реально сэкономить на KV, тогда вам путь к сборке кастомного Llama.cpp с turboquant
DamirMur
Не нужно для кодирования брать ужатые до Q4, они много теряют, лучше взять поменьше, типа 9B но Q6.
nikulin_krd
Абсолютно бессмысленное занятие. Потеря от Q4 существенно меньше, нежели от потери 10B+ параметров
DamirMur
Только все 10B+ их не использует, иначе бы mmoe было бы бессмысленно. А рассуждать как вы, лучше на бесплатных облачных писать там хоть 120 B+, только секреты не показывать. Код обычно не секретный, данные чувствительны
nikulin_krd
Да! Сразу не использует, но как показывает практика МоЕ с 3B активных явно выигрывает у мелких dense моделей с 8-9B. Я рассуждаю так, потому что в последнее время делаю очень много тестов разных моделей.
DamirMur
Так может у вас мелкие старье типа qwen3 coder, или какая-нибудь gemma4 e4b, которая не для кодирования.
nikulin_krd
Ну какие не старье? llama3.1-8B? Deepseek-R1-8B? Ministral3-8B?
DamirMur
Llama3.1 2024, deepseek r1 январь 2025
nikulin_krd
И они обе даже близко не стояли с MoE Qwen 3.6. Чтобы не быть голословным - https://benchlm.ai/coding
DamirMur
Я тебе честно скажу, я использую,Gemini 3.1 Pro, потому что бесплатно, а для всякой мелочи и подробных логов qwen3.5-9b-Q8.
slabnoff
Подтверждаю. Плотно тестировал. Практически все что смог скачать с хаггинфейс до 14b. В итоге что-то действительно полезное оказалось только qwen3.6 35b и плотный вариант 27b в экстремальном квантовании. После них разве что на gpt-oss-20b можно смотреть без отвращения
DooKoo2
Неверно. Q4 кванты дают деградацию ОЧЕНЬ малую по сравнению с FP16. Для понимания - потеря PPL 0.25 точности, это ужасно мало, в реальной работе незаметно никак.
И еще, чтобы быть правдивым - PPL и NLL показатели по уму надо считать ОТДЕЛЬНО код, простой текст,спец. текст. Часто PPL и NLL меряют на датасете wikitext2, который по своей сути реально текст, и он не гарантирует тоже качество для кода, например.
Я экспериментировал с квантованием, написал свой метод квантования и рантайм, назвал его SVSK - сравнивал с Q4 и на разных моделях.
Мое исследование вот тут: https://github.com/Dookoo2/SVSK
P/S По показателям PPL и NLL мое квантование даже чуть лучше чем QQUF Q4_K_M с imatrix. Пока еще продолжаю работу над проектом.
rPman
тут недавно гугл говорил про turboquant, правда там речь шла о хранении kv-cache но что то мне говорит, оно должно универсально подойти и для хранения весов, или может уже есть реализации, вы сравнивали свою с ними?
DooKoo2
Нет, KV-cache это не то же самое что сжатие весов модели и оно никаки не подойдет для квантизации.Значения ключей (K) и значений (V) имеют огромный динамический диапазон и генерируется оно динамические, outliers (выбросы значений) огромны и его так просто не сжать. Потому просто квантовать кэш не получится, и это решает turbo-quant. Дает дополнительный compute для рассчета KV, но сильно снижает VRAM требования.
На самом деле это выгодно, чипы GPU сейчас мощные, все нейросети это не compute-bound история, а больше memory-bound, то есть частота памяти и ее емкость роляет сильнее. Так что дополнительный compute не важен, а сокращение memory трафика - то что нужно.
SabMakc
.
nikulin_krd
А как обстоят дела с KDL? PPL вот вообще не показателен
DooKoo2
Пока никак, не мерял если честно. Пока ограничился PPL + NLL.