35B MoE для реального кодинга: сравниваем Qwen 3.6, Ornith 1.0 и KAT Coder 2.5 Dev в бою

Выбор локальной LLM для ежедневной разработки сводится к одному вопросу: какая модель не подведёт в три часа ночи, когда продакшен упал, а баг зарыт в дебрях легаси-кода. Мы взяли три MoE-модели класса ~35B с 3B активных параметров (A3B) - Qwen 3.6, Ornith 1.0 и KAT Coder 2.5 Dev - и прогнали их через три типичных рабочих сценария: итеративная отладка, рефакторинг запутанного модуля и восстановление кода после серии неудачных правок. Без синтетических бенчмарков, без подсказок, с жёсткими метриками: время до первого рабочего решения, расход токенов, точность попадания в корень проблемы и способность удержать контекст на дистанции.

Сразу к результатам. KAT Coder 2.5 Dev обходит конкурентов по всем ключевым метрикам: ноль ошибок инструментальных вызовов в 30 прогонах, вдвое меньший расход входных токенов по сравнению с Qwen 3.6 и способность эффективно использовать всю историю диалога в окне до 1M токенов. Ornith 1.0, напротив, систематически проваливается на механических ошибках - утечки формата, перезапись файлов, игнорирование ранних правок. Qwen 3.6 остаётся крепким универсалом, но его склонность к многословности и периодические «галлюцинации уверенности» делают модель рискованным выбором для ответственных задач. Если вам нужен один ассистент в IDE, который пишет код, а не поэмы, - KAT Coder 2.5 Dev сейчас лучший кандидат.

Почему бенчмарки врут, а мы - нет: методика тестирования на живых задачах

Стандартные бенчмарки типа HumanEval измеряют способность модели дописать функцию по сигнатуре. Это полезно для академических сравнений, но бесполезно для разработчика, который в реальности никогда не получает задачу в виде изолированной чистой функции. Реальный мир - это баг-репорт в Jira с парой скриншотов, легаси-модуль на 500 строк без тестов и срочная задача «верни как было» после того, как стажёр три дня коммитил в основную ветку.

Мы построили методологию вокруг трёх сценариев, которые покрывают 80% рабочего времени разработчика.

Сценарий 1 - итеративная отладка. Даётся фрагмент кода с багом из реального open-source проекта и описание симптомов. Модель должна найти причину и предложить исправление. Оценивается точность первого ответа, количество итераций до полного исправления и качество объяснения.

Сценарий 2 - рефакторинг легаси. Запутанная функция на 200 строк с плохим неймингом и дублированием логики. Задача: разбить на модули, переименовать переменные, убрать дублирование, сохранив все сайд-эффекты. Оценивается прохождение существующих unit-тестов после рефакторинга и субъективная чистота кода.

Сценарий 3 - восстановление после сбоев. Лог из 50+ последовательных правок с ошибками, последняя версия нерабочая. Модель должна проанализировать историю, откатить ошибочные изменения и восстановить логику. Оценивается способность удержать релевантные части длинного контекста, точность восстановления и время ответа.

Метрики для всех сценариев едины: время до первого рабочего решения, количество итераций до стабильного результата, расход токенов и субъективная оценка полезности ответа по шкале 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.

Сценарий 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: Рефакторинг легаси - сохранить логику, улучшить читаемость

Тестовый кейс - функция обработки заказов из 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 проваливает ключевые сценарии из-за механических ошибок и неспособности эффективно использовать собственный контекст.

Отдельно отметим дисциплину инструментальных вызовов. В наших тестах KAT Coder не допустил ни одной ошибки формата вызова инструментов за все прогоны. Qwen 3.6 периодически генерировал вызовы с неверным синтаксисом. Ornith 1.0 допускал утечки формата, когда часть ответа уходила в неправильный блок, что требовало ручного вмешательства. Для agentic-сценариев, где модель должна самостоятельно вызывать инструменты и обрабатывать результаты, эта разница критична.

Выводы: какую модель выбрать для продакшн-задач и почему KAT Coder 2.5 Dev сейчас впереди

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 сегодня - это не поиск идеальной модели, а подбор оптимального баланса между точностью, скоростью и стоимостью инференса под конкретный рабочий процесс.

Подписаться на канал