Выбор локальной LLM для ежедневной разработки сводится к одному вопросу: какая модель не подведёт в три часа ночи, когда продакшен упал, а баг зарыт в дебрях легаси-кода. В этом сравнении участвуют три локальные MoE-модели класса ~35B с 3B активных параметров (A3B) - Qwen 3.6, Ornith 1.0 и KAT Coder 2.5 Dev. Их рассматриваем в трёх типичных рабочих сценариях для agentic coding: итеративная отладка, рефакторинг запутанного модуля и восстановление кода после серии неудачных правок. В фокусе - время до первого рабочего решения, расход токенов, точность попадания в корень проблемы, стабильность tool calling и способность удержать длинный контекст.
Сразу к результатам. В этой серии прогонов KAT Coder 2.5 Dev показал наиболее ровный результат по ключевым метрикам: ноль ошибок инструментальных вызовов в 30 прогонах, вдвое меньший расход входных токенов по сравнению с Qwen 3.6 и эффективную работу со всей историей диалога в окне до 1M токенов. Ornith 1.0 чаще сталкивался с механическими ошибками - утечками формата, перезаписью файлов и игнорированием ранних правок. Qwen 3.6 остаётся крепким универсалом, но его склонность к многословности и периодические «галлюцинации уверенности» требуют дополнительной проверки в ответственных задачах. Если нужен один ассистент в IDE, который пишет код, а не поэмы, KAT Coder 2.5 Dev выглядит наиболее практичным кандидатом для такого профиля работы.
Коротко: кому какая модель подходит
- KAT Coder 2.5 Dev - для точной отладки, рефакторинга с сохранением логики, длинного контекста и agentic coding с инструментальными вызовами.
- Qwen 3.6 - для универсальной работы в IDE, черновой генерации, тестов и документации, если допустимы итеративные уточнения и ручная проверка.
- Ornith 1.0 - прежде всего для экспериментов с заявленными возможностями MoE и большим контекстом; для стабильных рабочих задач требуется особенно строгий контроль.
Итог: приоритет точности и дисциплины инструментов - KAT Coder 2.5 Dev; нужен более универсальный помощник - Qwen 3.6; интересен эксперимент с длинным контекстом - Ornith 1.0, но без автоматического доверия к результату.
Методика сравнения: живые задачи вместо одного бенчмарка
Стандартные бенчмарки типа HumanEval измеряют способность модели дописать функцию по сигнатуре. Это полезно для академических сравнений, но ограниченно применимо к разработчику, который в реальности получает баг-репорт в Jira с парой скриншотов, легаси-модуль на 500 строк без тестов и срочную задачу «верни как было» после того, как стажёр три дня коммитил в основную ветку.
Методика построена вокруг трёх сценариев, которые покрывают основные типы описанной работы разработчика.
Сценарий 1 - итеративная отладка. Даётся фрагмент кода с багом из реального open-source проекта и описание симптомов. Модель должна найти причину и предложить исправление. Оценивается точность первого ответа, количество итераций до полного исправления и качество объяснения.
Сценарий 2 - рефакторинг легаси. Запутанная функция на 200 строк с плохим неймингом и дублированием логики. Задача: разбить на модули, переименовать переменные, убрать дублирование, сохранив все сайд-эффекты. Оценивается прохождение существующих unit-тестов после рефакторинга и субъективная чистота кода.
Сценарий 3 - восстановление после сбоев. Лог из 50+ последовательных правок с ошибками, последняя версия нерабочая. Модель должна проанализировать историю, откатить ошибочные изменения и восстановить логику. Оценивается способность удержать релевантные части длинного контекста, точность восстановления и время ответа.
Метрики для всех сценариев едины: время до первого рабочего решения, количество итераций до стабильного результата, расход токенов и субъективная оценка полезности ответа по шкале 1-5. Никаких подсказок в промпте, никакой предварительной разметки кода - только баг-репорт и файлы, как в реальном проекте.
Ограничения методики. Это сравнение отражает поведение моделей в трёх описанных задачах, а не универсальный рейтинг. На результат могут влиять рантайм, квантование, настройки контекста и схема tool calling; субъективная оценка полезности по шкале 1-5 также не заменяет автоматическую проверку. Поэтому выводы ниже - ориентир для выбора под конкретный рабочий процесс, а не свойство любой конфигурации.
Этот подход перекликается с идеей переосмысления оценки MoE-моделей: вместо измерения «знаний» мы фокусируемся на инструментальной точности и способности модели не врать уверенным тоном. Ограничение обычных бенчмарков в том, что они не проверяют главного - умеет ли модель признать, что она не знает ответа, и запросить дополнительный контекст, вместо того чтобы генерировать правдоподобную ерунду.
Архитектурный ликбез: что такое MoE A3B и почему это важно для кодинга
MoE, или Mixture of Experts, - архитектура, в которой полный набор параметров модели разбит на несколько «экспертов», а для каждого входного токена активируется только часть из них. Нотация A3B означает, что из ~35 миллиардов общих параметров в работе одновременно участвуют только 3 миллиарда активных. Это даёт скорость инференса, сравнимую с плотной моделью на 3B, при объёме знаний, характерном для 35B.
Для кодинга этот баланс критичен. Разработчику нужна модель, которая помнит синтаксис редких библиотек, понимает паттерны проектирования и способна рассуждать о побочных эффектах изменений. Плотная модель на 3B просто не вместит достаточно знаний о мире кода. Модель на 35B без MoE будет генерировать ответы слишком медленно для интерактивной работы в IDE. MoE A3B решает это противоречие: знания хранятся в экспертах, а рассуждение ведётся компактным ядром.
У архитектуры есть и врождённые риски. Выбор экспертов для каждого токена - задача нетривиальная. Ошибка маршрутизации может отправить запрос о Python-декораторах эксперту, который специализируется на JavaScript-промисах. Отсюда склонность MoE-моделей к галлюцинациям в узких доменах и нестабильность ответов: один и тот же промпт может привести к разным результатам в зависимости от того, какие эксперты активировались. В кодинге эта нестабильность смертельно опасна: патч, который работает в 90% случаев, в оставшихся 10% молча ломает данные.
Ещё один компромисс - оверсинкинг. MoE-модели склонны генерировать избыточные цепочки рассуждений, потому что каждый эксперт «хочет высказаться». В задачах, где нужна хирургическая точность, это приводит к перерасходу токенов и логическим петлям. Модель начинает переписывать один и тот же блок кода разными способами, не понимая, что первый вариант уже был рабочим. Мы увидим этот паттерн в тестах Ornith 1.0 особенно ярко.
Участники сравнения: Qwen 3.6, Ornith 1.0 и KAT Coder 2.5 Dev
Qwen 3.6 - эволюция линейки Qwen от Alibaba. Модель построена на архитектуре MoE с 35B общих и 3B активных параметров. Лицензия Apache 2.0, поддержка инструментов, vision-входа и рассуждений. Доступна в форматах GGUF и MLX для локального инференса. Позиционируется как универсальная модель, способная закрывать широкий спектр задач - от генерации кода до анализа документов. Контекстное окно - 128K токенов.
Ornith 1.0 - модель от независимой команды, тёмная лошадка в этом сравнении. Архитектура MoE A3B, заявленная специализация на кодинге и agentic-сценариях. Контекстное окно - до 1M токенов. Модель активно обсуждается в сообществе за агрессивный маркетинг, но независимых тестов её реальной производительности мало. Приведённые замеры показывают, что разрыв между заявленными возможностями и практической стабильностью существенный.
KAT Coder 2.5 Dev - модель от команды Kwaipilot, прошедшая этапы SFT и RL-обучения специально для задач agentic coding. Архитектура MoE с 35B общих и 3B активных параметров. Ключевая особенность - RL-тренировка, которая сократила количество ошибок в инструментальных метках с 9.34% до 0.28%, а показатель повторений в одном витке снизила до нуля. Контекстное окно - 1M токенов. Модель заточена на точность и дисциплину использования инструментов, а не на генерацию красивых, но неработающих ответов. Подробный разбор архитектуры и сравнение с Qwen2.5-Coder опубликованы в отдельном обзоре KAT Coder.
Какую локальную модель выбрать для IDE: отладка, рефакторинг и agentic coding
- Отладка: KAT Coder 2.5 Dev лучше подходит для минимального патча с точной локализацией причины; Qwen 3.6 чаще требует уточнений, а Ornith 1.0 может предложить избыточную перестройку.
- Рефакторинг: KAT Coder 2.5 Dev показал наиболее стабильное сохранение логики и тестов; Qwen 3.6 удобен для итеративной работы, Ornith 1.0 требует проверки каждого варианта.
- Длинный контекст: KAT Coder 2.5 Dev эффективно использовал историю до 1M токенов в данном сценарии; Qwen 3.6 при ограничении 128K нуждается в разбиении лога, а у Ornith 1.0 одного заявленного окна недостаточно для гарантии результата.
- Агентные вызовы и tool calling: KAT Coder 2.5 Dev показал наименьшее число ошибок формата; Qwen 3.6 и Ornith 1.0 требуют дополнительного контроля и ручной проверки.
Сценарий 1: Итеративная отладка - какая модель быстрее найдёт и исправит баг
Тестовый кейс - баг из Python-библиотеки для работы с API: при определённой комбинации параметров аутентификации запрос падал с невнятным KeyError, хотя документация утверждала, что конфигурация валидна. Код метода - около 80 строк с вложенными условиями и тремя уровнями словарей конфигурации. Промпт содержал описание симптомов, трейсбек и полный код метода.
Qwen 3.6 выдал развёрнутый ответ на 400 слов с общим описанием проблемы, предложил три возможные причины и патч, который исправлял только одну из них. Модель ушла в рассуждения о лучших практиках обработки словарей, но не заметила, что баг воспроизводится только при пустом значении одного из вложенных ключей. На уточняющий вопрос ответила корректно, но потребовалось две итерации до рабочего патча.
Ornith 1.0 с первой попытки предложил переписать весь метод на 120 строк, изменив сигнатуру функции и добавив три новых класса. Патч проходил тесты, но вносил изменения, которые ломали обратную совместимость с тремя другими модулями. Модель проигнорировала явное указание в промпте «сохранить публичное API неизменным». Расход токенов - 1200 на первый ответ, что втрое выше, чем у конкурентов.
KAT Coder 2.5 Dev: хирургическая точность против «галлюцинаций уверенности»
KAT Coder 2.5 Dev с первой же итерации указал на конкретную строку: доступ к вложенному ключу без проверки его существования при пустом родительском словаре. Ответ занял три абзаца: локализация проблемы, объяснение причины, минимальный патч из четырёх строк. Никаких рассуждений о лучших практиках, никаких предложений переписать архитектуру. Модель вела себя как опытный разработчик на код-ревью: увидел проблему, показал пальцем, предложил исправление.
Показателен контраст с типичным поведением Qwen 3.6. Там, где KAT Coder выдал «строка 47, нет проверки на None», Qwen сгенерировал абзац о том, что «в современной разработке принято использовать паттерн Null Object». Это и есть разница между моделью, заточенной на точность, и универсалом, который стремится показать широту знаний. В отладке широта знаний вредит: разработчику нужен ответ на вопрос «где баг», а не лекция о паттернах проектирования.
На второй итерации в промпт добавили уточнение: «баг воспроизводится только при пустом значении параметра region». Qwen 3.6 скорректировала ответ и выдала рабочий патч. Ornith 1.0 продолжил настаивать на своём варианте с переписыванием метода, проигнорировав новую информацию. KAT Coder подтвердил, что его первоначальный патч уже покрывает этот случай, и показал почему - со ссылкой на код. Три модели показали разные стили работы: универсал, которому нужны уточнения; модель, склонная удерживать исходный вариант; и ассистент, который понял задачу с первого раза.
Сценарий 2: MoE для рефакторинга легаси - сохранить логику и улучшить читаемость
Тестовый кейс - функция обработки заказов из e-commerce проекта: 200 строк, четыре уровня вложенности, переменные с именами a, b, temp, data1, три повторяющихся блока валидации с небольшими отличиями. Задача: разбить на модули, переименовать переменные, вынести повторяющуюся логику в отдельные функции, сохранив все сайд-эффекты, включая запись в лог и обновление кэша. К кейсу прилагался набор из 12 unit-тестов, которые должны проходить после рефакторинга.
KAT Coder 2.5 Dev справился за один проход. Результат: четыре функции вместо одной, осмысленные имена, декоратор для логирования, все 12 тестов зелёные. Модель не просто механически разбила код, но и выявила скрытое дублирование: два блока валидации отличались только названием поля, что позволило вынести общую логику в параметризованную функцию. Расход токенов - 800 на генерацию кода и 200 на объяснение изменений.
Qwen 3.6 выдал структурно похожий результат, но с двумя проблемами. Во-первых, модель добавила избыточные комментарии в стиле «эта функция валидирует заказ» к каждой строке - видимо, сработала привычка к «полезным» объяснениям. Во-вторых, в одном месте был изменён порядок записи в лог, что сломало тест, проверяющий последовательность сайд-эффектов. На исправление потребовалась одна итерация. Общий расход токенов - 1500, почти вдвое выше, чем у KAT Coder.
Оверсинкинг и зацикливание: когда модель «думает» слишком много
Ornith 1.0 продемонстрировал классический паттерн оверсинкинга. Модель сгенерировала пять последовательных версий рефакторинга в одном ответе, каждая со своими пояснениями, и в конце предложила «выбрать наиболее подходящий вариант». Три из пяти версий не проходили тесты. Две рабочие версии отличались только форматированием. Общий расход токенов - 3200, из которых 2000 ушли на рассуждения и сравнение вариантов, которые модель сама же и сгенерировала.
Этот паттерн - прямое следствие архитектуры MoE без качественного RL-выравнивания. Разные эксперты предлагают разные решения, а модель не обучена выбирать одно и отбрасывать остальные. Вместо этого она вываливает на разработчика все варианты, перекладывая ответственность за выбор. В реальной работе рефакторинг должен давать один проверяемый результат, а не список непроверенных вариантов.
Проблема зацикливания проявилась у Ornith 1.0 на уточняющем запросе. При просьбе исправить ошибку в одном из вариантов модель начала генерировать новые варианты, снова с дублированием и снова с ошибками. После трёх итераций тест остановили - модель не сходилась к решению, а блуждала в пространстве возможных рефакторингов, расходуя контекст и время.
Сценарий 3: Восстановление после сбоев - работа с длинным контекстом в 1M токенов
Симуляция: лог из 55 последовательных правок в модуле аутентификации. Правки включают добавление двухфакторной аутентификации, откат из-за бага с сессиями, три попытки починить сессии разными способами, ещё один откат и финальную попытку, которая сломала вход для всех пользователей. Задача - проанализировав всю историю, откатить ошибочные изменения и восстановить рабочую версию. Общий объём контекста - около 800K токенов.
Этот сценарий проверяет не столько знания модели о коде, сколько её способность работать с длинной историей изменений: удерживать в фокусе релевантные части, не терять начало диалога, отличать успешные правки от ошибочных. Заявленное контекстное окно в 1M токенов у KAT Coder и Ornith против 128K у Qwen должно было дать первым двум моделям преимущество. На практике всё оказалось сложнее.
1M токенов: преимущество KAT Coder и слабое место Ornith
KAT Coder 2.5 Dev показал, что 1M контекста работает в данном сценарии. Модель проанализировала всю историю, выделила три ключевые точки: момент, когда двухфакторная аутентификация работала корректно, момент, когда первая попытка починить сессии была близка к успеху, и момент, когда финальная правка всё сломала. Итоговый патч комбинировал рабочие части из разных этапов истории, с явными ссылками на конкретные правки: «берём хэш-функцию из коммита 12, структуру сессии из коммита 8, откатываем изменения в обработчике входа из коммита 55». Время ответа - 45 секунд, расход токенов - 1500.
Qwen 3.6 с окном 128K не смог загрузить всю историю целиком. Историю пришлось разбить на три части и подавать последовательно. Модель корректно работала с каждой частью, но теряла связь между ними: предложенное решение исправляло проблемы из последней части, но возвращало баг из первой. Потребовалось четыре итерации с явным указанием «проверь, не возвращает ли это ошибку из первого лога». Рабочий патч был получен, но процесс напоминал отладку с джуниором, который не видит всей картины.
Ornith 1.0 с заявленным 1M контекста повёл себя хуже всех. Модель загрузила всю историю, но в ответе проигнорировала первые 30 правок, сосредоточившись только на последних десяти. Предложенный патч повторял одну из ранее отвергнутых попыток починить сессии - ту самую, которая уже ломала вход. После явного указания на это модель извинилась и предложила другой патч, который повторял другую отвергнутую попытку. Контекст в 1M токенов формально доступен, но в этом сценарии модель не использовала его эффективно.
Сравнительная таблица: метрики, токены, стабильность
| Метрика | KAT Coder 2.5 Dev | Qwen 3.6 | Ornith 1.0 |
|---|---|---|---|
| Точность первого ответа (отладка) | Прямое попадание | Требует уточнения | Избыточное решение |
| Прохождение тестов (рефакторинг) | 12/12 с первой попытки | 11/12, исправлено за 1 итерацию | Лучший вариант - 9/12 |
| Время восстановления (сценарий 3) | 45 секунд, 1 итерация | 4 итерации, ~3 минуты | Не завершён за 5 итераций |
| Средний расход токенов на задачу | ~800 | ~1500 | ~2500 |
| Стабильность (субъективно, 1-5) | 5 | 3 | 1 |
| Эффективность длинного контекста | Отличная | Ограничена 128K | Заявлена, в этом сценарии использована неэффективно |
| Склонность к оверсинкингу | Минимальная | Умеренная | Критическая |
По этим метрикам KAT Coder 2.5 Dev чаще выдаёт рабочие решения с меньшим расходом токенов. Qwen 3.6 требует больше итераций и генерирует больше текста, но в итоге приходит к корректному результату. Ornith 1.0 в описанных сценариях сталкивается с механическими ошибками и не использует собственный контекст так эффективно, как ожидалось.
Отдельно важна дисциплина инструментальных вызовов. В серии прогонов KAT Coder не допустил ни одной ошибки формата вызова инструментов за все прогоны. Qwen 3.6 периодически генерировал вызовы с неверным синтаксисом. Ornith 1.0 допускал утечки формата, когда часть ответа уходила в неправильный блок, что требовало ручного вмешательства. Для agentic-сценариев, где модель должна самостоятельно вызывать инструменты и обрабатывать результаты, эта разница критична.
Выводы: какую модель выбрать для кодинга и IDE
KAT Coder 2.5 Dev - наиболее убедительный выбор для ежедневной разработки в рамках этой серии задач. Модель демонстрирует точность в отладке, генерирует чистый код при рефакторинге и эффективно использует длинный контекст для анализа истории изменений. RL-выравнивание заметно по рабочему стилю: модель реже уходит в оверсинкинг и не тратит токены на лишние рассуждения. Если нужен ассистент в IDE, который будет писать код, а не прозу, это сильный кандидат. Можно начать с детального бенчмарка KAT Coder, где разобраны настройки инференса и оптимальные конфигурации.
Qwen 3.6 - крепкий универсал для черновой генерации и задач, где допустимы итеративные уточнения. Модель знает много, но склонна это демонстрировать даже когда не просят. Подходит для прототипирования, генерации тестов, написания документации. В ответственных сценариях требует контроля: проверяйте патчи перед применением и не полагайтесь на первое предложение модели без проверки. Лицензия Apache 2.0 и доступность в GGUF делают Qwen 3.6 удобным выбором для быстрого развёртывания.
Ornith 1.0 пока скорее подходит для экспериментов, чем для продакшна. Механические ошибки, утечки формата, нестабильное использование контекста и склонность к оверсинкингу перевешивают заявленные преимущества. Модель интересна для исследований - на ней удобно изучать типичные патологии MoE-архитектур. Для ответственных задач ей нужна дополнительная проверка и стабильное обновление с исправлением ключевых проблем.
Общая рекомендация для всех трёх моделей: контроль обязателен. Даже KAT Coder 2.5 Dev, при всей его точности, не заменит код-ревью и автоматические тесты. Модели этого класса ускоряют разработку, берут на себя рутину и помогают не утонуть в легаси, но финальное решение о применении патча всегда за разработчиком. Сложная бизнес-логика, вопросы безопасности и критические пути должны проходить через человеческую проверку - это не ограничение моделей, а инженерная гигиена.
Для тех, кто присматривается к другим MoE-моделям, полезно изучить наш обзор компактных MoE с ~2B активных параметров - там разобраны модели, которые запускаются на устаревших GPU и при этом решают практические задачи кодинга. Выбор локальной LLM сегодня - это не поиск идеальной модели, а подбор оптимального баланса между точностью, скоростью и стоимостью инференса под конкретный рабочий процесс.
FAQ: выбор локальной MoE-модели для кодинга
Какая модель лучше подходит для отладки?
В рамках описанных прогонов наиболее стабильный первый ответ дал KAT Coder 2.5 Dev: модель локализовала причину и предложила минимальный патч. Qwen 3.6 также может решить задачу, но чаще требует уточнений; Ornith 1.0 нуждается в проверке из-за склонности к избыточным изменениям.
Подходит ли Qwen 3.6 для работы в IDE?
Да, если в задаче допустимы итерации и ручная проверка патчей. Qwen 3.6 остаётся универсальным вариантом для прототипирования, генерации тестов и документации, а формат GGUF упрощает локальное развёртывание.
Когда действительно нужен контекст в 1M токенов?
Он полезен при анализе большой истории правок, нескольких файлов или длинных логов, которые не помещаются в 128K. Но само наличие окна 1M не гарантирует эффективную работу с его содержимым: это показал сценарий с Ornith 1.0.
Можно ли использовать Ornith 1.0 в продакшне?
Для ответственных задач - только после собственной проверки на рабочих данных, инструментальных вызовах и тестах. По описанным сценариям модель разумнее рассматривать как экспериментальный вариант, а не как основной ассистент без дополнительного контроля.