Qwen Code models — это модели, которые вы сами прописываете в настройках агента и переключаете командой /model, поэтому выбирать приходится по результатам на ваших задачах: общий рейтинг мало говорит о вашем репозитории. Сравнение честное, когда каждая модель получает один репозиторий, одну формулировку задачи и один режим подтверждений. Метод подходит командам, у которых уже есть тесты, иначе качество правки оценивать нечем.
Что сравниваем
В Qwen Code у моделей несколько ролей: основная для правок, быстрая для подсказок, модель сжатия контекста и другие. Сравнивайте основную роль, а остальные назначайте после.
По справочнику настроек основная модель задаётся параметром model.name. Рядом лежат отдельные роли: fastModel для подсказок, compactionModel для сжатия длинной сессии, visionModel для чтения картинок и advisorModel для второго мнения. Пустое значение у быстрой модели и модели сжатия означает, что работает основная.
Начинайте с основной роли, потому что именно она пишет правки. Быстрая модель влияет на удобство, а модель сжатия на длинные сессии; добавляйте их в замер по одной. За один прогон меняйте один параметр, иначе причина сдвига в результате останется загадкой.
| Роль | Параметр | Что проверять |
|---|---|---|
| Основная | model.name | Проходят ли тесты после правки и насколько мал diff |
| Быстрая | fastModel | Полезны ли подсказки и как растёт расход |
| Сжатие контекста | compactionModel | Сохраняется ли суть длинной сессии после сжатия |
| Работа с картинками | visionModel | Читается ли скриншот ошибки |
Список доступных моделей определяют ваши записи в modelProviders; команда /model показывает настроенные модели и переключает между ними. Документация для подписочного плана Alibaba Cloud называет, среди прочих, qwen3-coder-plus и qwen3-coder-next (вторая помечена как экспериментальная), но перечень меняется, поэтому актуальные идентификаторы берите в консоли поставщика. Как завести провайдера и ключ, описано отдельно, а общий обзор агента даёт статья о Qwen Code для разработки в компании.
Набор задач
Три задачи покрывают типовую работу агента. Они разные по природе, поэтому модель, сильная в одной, может провалиться в другой.
- Исправление ошибки: сервис падает, когда в файле конфигурации пустое поле. Ожидание: сервис берёт значение по умолчанию, падающий тест проходит.
- Тест к готовой функции: функция округления суммы уже работает, а проверки к ней нет. Ожидание: тесты на границы и отрицательные значения, сама функция осталась прежней.
- Переименование: параметр в трёх файлах получает новое имя. Ожидание: все вызовы обновлены, поведение прежнее, лишних файлов в diff нет.
У каждой задачи своя проверочная функция. Исправление ошибки показывает, умеет ли модель идти по трассе падения до причины. Тест к готовой функции показывает понимание контракта. Переименование проверяет дисциплину правок в нескольких файлах сразу.
Заморозьте условия. Для каждого прогона создайте ветку от одного и того же коммита, чтобы начальное состояние совпадало. Формулировку задачи сохраните текстом в файле и копируйте дословно. Режим подтверждений оставьте default: правки файлов потребуют вашего согласия, и вы увидите, сколько раз модель просила разрешения. Модель переключайте флагом --model при запуске, чтобы настройки между прогонами совпадали.
Подготовьте образец репозитория заранее: небольшой, с запускаемыми тестами и без секретов. Боевой проект для сравнения брать рискованно, ведь агент читает файлы, и всё прочитанное уходит поставщику модели вместе с запросом.
Ответы моделей варьируются от запуска к запуску. Чтобы отделить случайность от свойства модели, повторите каждую пару «задача — модель» минимум дважды. Если в записи провайдера есть блок generationConfig, параметры выборки в samplingParams можно зафиксировать одинаковыми для всех кандидатов.
Замеры
- Запустите тесты скриптом сразу после правки и запишите итог: прошли, упали, сколько проверок добавлено.
- Выполните
git diff --statи отметьте число затронутых файлов. Лишние файлы в списке считаются отклонением. - Откройте
/stats model: команда показывает расход по каждой модели. Сверяйте цифры с консолью поставщика. - Засеките задержку внешним таймером скрипта: от отправки задачи до готового diff. Время ожидания подтверждений человеком вычитайте.
- Запишите, сколько раз пришлось уточнять задачу и что именно приходилось исправлять руками.
Итоговую картину собирают в таблицу «задача — модель — тесты — файлы — уточнения — задержка». Одна строка читается сразу, а пять строк с одной и той же моделью показывают разброс. Если у модели два зелёных прогона из двух на исправлении ошибки и один провал из двух на переименовании, это вывод о её слабом месте, и выводу можно доверять больше, чем впечатлению от одной удачной попытки.
Качество текста объяснений агента оценивайте отдельно от качества правки. Модель способна уверенно описать изменение, которого в diff нет. Поэтому читайте сам diff и сверяйте каждую заявленную правку с реальным файлом.
Отдельной строкой фиксируйте выходы за рамки задачи: новые файлы, переформатирование всего модуля, отключённый падающий тест. Отключение теста считается провалом даже при зелёном отчёте, а лишний файл в diff снижает оценку, потому что ревьюеру придётся читать больше.
Границы модели
Длинная сессия упирается в контекст. Параметр contextWindowSize в generationConfig переопределяет размер окна, а context.autoCompactThreshold задаёт долю окна, при которой запускается автоматическое сжатие; значение по умолчанию по документации равно 0.85. После сжатия детали ранней части сессии могут пропасть, поэтому на больших задачах проверяйте, помнит ли агент требования из начала.
Окно и лимит задают границы по ресурсам. Есть и граница по смыслу: внутренние соглашения вашей команды модели неизвестны, пока они остаются устной договорённостью. Поэтому одна и та же модель в разных репозиториях даёт разный результат, и сравнение на чужом проекте мало что подтверждает.
Ограничитель размера запроса — параметр model.sessionTokenLimit: он задаёт предельный размер накопленного запроса, и при превышении следующая отправка отбрасывается, а сессия продолжается; значения -1 и 0 означают отсутствие лимита. Расход в деньгах он оставляет без учёта, его сверяйте по /stats model и консоли поставщика. Для пилота задайте предел, чтобы раздутый контекст перестал уходить поставщику без вашего решения. Открытые веса на своём сервере дают другой профиль: данные остаются внутри, зато скорость и качество зависят от железа и размера модели, и этот вариант разобран в статье про Qwen Code с локальной моделью.
На каких задачах вашей команды важна скорость ответа?
Решение и пересмотр
Запишите выбор рядом с кодом: идентификатор основной модели, назначенные роли, версия набора из трёх задач, дата замера. Через такую запись коллега поймёт, почему стоит именно эта модель, и сможет повторить сравнение. Пересматривайте решение, когда поставщик объявил новую модель, когда задачи команды заметно сменились или когда прогоны начали давать другие результаты на том же наборе.
При пересмотре оставляйте прежний набор задач нетронутым: тогда новая строка таблицы сравнима со старой. Новые типы задач добавляйте отдельными строками с датой, а результаты для старых строк храните рядом. История замеров показывает, растёт ли качество выбранной модели вместе с обновлениями поставщика или уходит в сторону.
Разные задачи допускают разные модели. Исправления и тесты могут идти на более лёгкой модели, переименования в нескольких файлах и разбор незнакомого модуля требуют более сильной. Назначение по типам задач описывайте правилом в README: память разработчиков подводит. Подключение вспомогательных инструментов через MCP-серверы оценивайте отдельным набором: оно тоже меняет поведение агента.
Возьмите один репозиторий с рабочими тестами и две модели из своего списка. Прогоните три задачи по два раза, заполните таблицу и покажите владельцу репозитория. Нужен аудит выбора модели с учётом данных и рисков? Напишите нам, состав работ определим после разбора вашего процесса.