Qwen-3.5-27B в кодинге: разбор кейса и почему dense-архитектура впечатляет

MoE — это круто, пока не нужно писать код

Все говорят про Mixture of Experts. Сети в 100 миллиардов параметров, где активируется только часть. Экономично. Умно. На бумаге.

А потом ты садишься писать код. И модель размером с небольшую галактику начинает выдавать такой бред, что хочется выключить компьютер и пойти копать огород. Она путает синтаксис. Забывает, что пять строк назад сама же объявила переменную. Предлагает использовать библиотеку, которой не существует с 2024 года.

Проблема не в размере. Проблема в архитектуре. MoE — это когнитивный диссонанс для задач, требующих последовательной, плотной логики. Кодинг — именно такая задача.

Именно в этот момент я решил проверить аутсайдера — Qwen-3.5-27B. Не 70B, не 100B, а скромные 27 миллиардов параметров. И вся архитектура — классическая, плотная (dense). Никаких экспертов. Один большой, хорошо обученный мозг.

Qwen-3.5-27B: плотный и точный

Что такое dense-архитектура в 2026 году? Это анахронизм. Это будто приходить на гонку Формулы-1 на велосипеде. Все смеются.

Но этот «велосипед» имеет одно преимущество — он предсказуем. Каждый нейрон в модели задействован для обработки каждого токена. Нет внезапных переключений между экспертами. Нет шанса, что модель выберет «специалиста по HTML», когда вы пишете на Python.

Qwen-3.5-27B — это последняя на момент 01.03.2026 dense-модель от Alibaba, оптимизированная именно для кода и рассуждений. Не мультимодальная, не для чата, а для работы. И она до сих пор поддерживается и обновляется, в отличие от многих MoE-экспериментов, которые забросили через месяц после релиза.

Реальный кейс: пишем анализатор зависимостей на Python

Теория — это скучно. Я взял реальную задачу из своего бэклога: написать утилиту для анализа Python-проектов. Она должна:

• Рекурсивно сканировать директорию.
• Парсить импорты (import, from ... import) во всех .py файлах.
• Строить граф зависимостей между модулями.
• Находить циклические зависимости (самый больной вопрос для любого проекта).
• Экспортировать отчет в JSON и визуализировать граф.

Задача нетривиальная. Нужно работать с AST (Abstract Syntax Tree), понимать структуру проектов, корректно обрабатывать относительные импорты. Идеальный полигон для теста.

Я не стал разворачивать модель локально. Время — деньги. Использовал OpenRouter API (партнерская ссылка), где Qwen-3.5-27B доступна сразу, без танцев с llama.cpp. Кстати, если хотите свой инстанс, гляньте гайд по локальной настройке Qwen Code.

Шаг за шагом: как я заставил модель думать, а не бредить

1Пишем промпт-скелет

Первая ошибка — дать модели полную свободу. Нельзя просто сказать: «Напиши анализатор зависимостей». Она начнет генерировать код, который выглядит правдоподобно, но сломается на первом же тесте.

Правильный подход — разбить задачу на модули и диктовать архитектуру. Мой промпт начинался так:

"""Требуется написать модуль `dependency_analyzer.py`. Структура:
1. Класс `ProjectScanner` для рекурсивного поиска .py файлов.
2. Класс `ImportParser` для извлечения импортов из AST.
3. Класс `DependencyGraph` для построения и анализа графа.
4. Функция `find_cycles` для обнаружения циклических зависимостей.

Важно: обрабатывать только абсолютные и относительные импорты внутри проекта. Игнорировать стандартные библиотеки и сторонние пакеты (начинающиеся не с '.').
Начни с реализации класса `ProjectScanner`."""

2Итеративная разработка с обратной связью

Сгенерировал код для `ProjectScanner`. Запустил его в голове (читай: проверил логику). Отправил модели следующий промпт:

"""Класс `ProjectScanner` работает. Вот его код:
{вставленный код}

Теперь реализуй `ImportParser`. Он должен принимать путь к файлу, парсить его AST и возвращать список кортежей: (имя_модуля, уровень_относительности). Например, для `from ..utils import helper` вернуть ('utils', 2)."""

И вот здесь dense-архитектура показала свою силу. Модель помнила контекст всей задачи. Она не спросила: «А что такое ProjectScanner?». Она продолжила с того места, где остановилась, используя согласованные сигнатуры методов.

Для сравнения, MoE-модель того же размера (например, одна из веток Qwen-3.5 с экспертами) в этот момент могла бы «переключить передачу» и начать генерировать код, несовместимый с предыдущим.

3Исправление ошибок — тест на интеллект

Сгенерированный код для `ImportParser` имел баг: он неправильно обрабатывал импорты вида `import os.path`. Модель вернула `('os.path', 0)`, хотя нужно было `('os', 0)`.

Я не стал гуглить. Я скопировал ошибку и отправил модели:

"""В твоем коде есть проблема. Для импорта `import os.path` твой парсер возвращает ('os.path', 0). Но это подмодуль стандартной библиотеки, его нужно игнорировать. Также, для внутренних импортов, если указан точечный путь (например, `package.submodule`), нужно учитывать только первый компонент? Объясни логику и исправь код."""

Ответ Qwen-3.5-27B впечатлил. Она не просто исправила баг. Она предложила два варианта логики (игнорировать все подмодули сторонних пакетов или разделять их) и спросила, какой предпочтителен для моей задачи. Это уровень понимания, который я редко видел даже у моделей в 2 раза больше.

Dense vs MoE: почему 27 миллиардов параметров работают лучше 100

После завершения прототипа (который, кстати, заработал с первого запуска) я сел анализировать. В чем феномен?

Суть в целостности. Кодинг — это не набор независимых подзадач. Это плотная сеть взаимосвязей. Dense-архитектура, где каждый параметр участвует в обучении на всех данных, идеально ловит эти связи.

MoE создавалась для масштаба. Чтобы затолкать в модель больше знаний. Но для программирования важнее не объем знаний, а умение их связывать. Qwen-3.5-27B — специалист по связям.

Ошибки, которые заставили меня вырвать волосы

Не все было идеально. Dense-модель — не панацея.

• Одержимость частными случаями. Иногда модель предлагала излишне обобщенное решение, пытаясь учесть все возможные edge-кейсы, что усложняло код. Приходилось явно говорить: «Пиши для стандартного случая, обработку исключений добавлю позже».
• Слепая зона на свежих библиотеках. Если ваша задача связана с библиотекой, выпущенной после 2025 года, Qwen-3.5-27B может о ней не знать. Это проблема всех моделей с фиксированной датой отсечки обучения. Решение — давать ей документацию в контексте. Но длинный контекст требует аккуратного обращения.
• Иногда слишком буквальна. Если в промпте была малейшая двусмысленность, модель могла интерпретировать ее буквально, а не так, как задумано. MoE-модели здесь иногда гибче за счет «коллективного разума» экспертов.

Главный вывод: с dense-моделью нужно разговаривать как с опытным, но немного занудным разработчиком. Давать четкие, однозначные инструкции. И тогда она выдаст результат, который не стыдно закоммитить.

Что дальше? Dense-архитектура не умерла

К марту 2026 года индустрия AI для кодинга стоит на развилке. С одной стороны — гигантские MoE-агенты, которые пытаются понять всю кодовую базу и автономно ее менять (как Qwen Coder Next). С другой — точные, надежные dense-модели среднего размера, идеальные для итеративной разработки под руководством человека.

Мой прогноз: dense-архитектура останется в нише «рабочей лошадки» для программистов. Там, где нужна не максимальная эрудиция, а максимальная предсказуемость и логическая согласованность.

Пока MoE-модели не решат проблему с целостностью контекста (а это фундаментальная сложность их архитектуры), для реальной, ежедневной работы над кодом я буду выбирать плотные модели. Как Qwen-3.5-27B.

Она не напишет за вас весь проект. Но она станет лучшим pair programmer, который никогда не устает, не просит повышения зарплаты и всегда готов обсудить детали реализации вашего следующего класса.

Попробуйте. Возьмите свою задачу, откройте OpenRouter или локальный инстанс и дайте Qwen-3.5-27B шанс. Только не забудьте — говорите четко. Она этого заслуживает.

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