Qwen3.6 против Gemma4: Тестирование 6 моделей на реальных багах инфраструктуры

Вы думали, что LLM легко напишут код и настроят Nginx? Реальность гораздо сложнее: даже самые мощные модели дают сбои при многоступенчатом дебаггинге, а выбор между моделями становится критичным.

Мы провели стресс-тест шести топовых моделей (включая Qwen3.6 и Gemma4) на трех уровнях инфраструктурных задач — от простого API до сложной настройки Nginx и Python-приложений. Вот что выяснилось о том, какой AI-агент действительно готов к продакшену.

Зачем это нужно: Почему «просто написать код» — это не задача для LLM

Когда мы говорим о «просто написать код», мы обычно имеем в виду генерацию функции. Инфраструктурная задача — это совсем другое. Это многоступенчатый процесс, который требует не только знания синтаксиса, но и понимания:

1. Контекста: Что было до и что должно быть после.
2. Зависимостей: Как Python-приложение взаимодействует с сетью, Nginx и операционной системой (OS).
3. Дебаггинга: Умения не просто предложить фикс, а диагностировать, почему фикс не работает (например, из-за опечатки в except или отсутствующего import).

В нашем тесте модели должны были не просто ответить, а действовать в роли локального агента, используя реальный стек (MacBook Pro M4, LMStudio) и исправлять ошибки в работающем коде и конфигурационных файлах.

Как проходил тест: Стек и задачи

Для проведения испытаний мы собрали мини-стенд, который имитирует реальную разработку.

Железо и софт:

• Машина: MacBook Pro M4 (14 CPU, 20 GPU, 48GB Unified RAM).
• Инструменты: LMStudio 0.4.6+1, MLX Runtime 1.6.0.
• Модели: Тестировали как Dense-модели (например, Qwen3.6-27B), так и MoE-архитектуры (Qwen3.6-35B-A3B, Gemma4-26B-A4B).

Инфраструктурные задачи: Мы протестировали три типа проблем, используя Python+FastAPI:

1. Simple (Простая): Ошибка в коде, которую легко обнаружить.
2. Medium (Средняя): Недоступность сервиса по порту, требующая проверки сетевых настроек.
3. Difficult (Сложная): Полная цепочка проблем — от опечатки в исключении (except) до необходимости настройки Nginx и обновления окружения.

Ключевые критерии оценки были не только в конечном результате, но и в процессе:

• Следовал ли системному промпту: Агент не должен «галлюцинировать» или забывать о задаче.
• Проверил ли проблему: Умение агента сначала диагностировать («действительно ли проблема существует?») перед тем, как предлагать фикс.

Что внутри инструмента: Сравнение Qwen и Gemma

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

💡 На простых задачах (Simple)

На базовом уровне MoE-модели Qwen3.6-35B-A3B и Gemma работают на одном уровне. Однако здесь проявился первый важный нюанс: Gemma тратит больше токенов и требовательнее к памяти, даже если результат идентичен.

🛠️ На средних задачах (Medium)

Здесь Qwen3.6 показал себя заметно лучше Gemma. Он справлялся с многошаговой логикой (проверка доступности, анализ ошибки) более эффективно, чем его конкурентка.

💣 На сложных задачах (Difficult) — Где происходит провал

Именно здесь разница между моделями стала максимальной.

• Qwen3.6: Качество решения на тяжелой задаче значительно падает. Модель начинает «застревать» на диагностике, а не переходить к фиксу.
• Gemma4: Проваливается полностью. На сложнейшем уровне агентские циклы часто приводили к сбою системы (WindowServer crash).
• Вывод: Высокая сложность требует не только большой модели, но и идеальной проработки промпта, чтобы не дать агенту потерять нить рассуждения.

Как получить идеальный ответ: Зависимость от промпта

Мы выяснили, что качество решения сложной задачи можно поднять до идеального уровня, если вы точно описываете проблему.

Рекомендации по выбору модели:

• Qwen3.6-35B-A3B: Лучший выбор для проблем, которые сформулированы общими, нечеткими словами. Модель лучше справляется с «сырым» контекстом.
• Gemma4-26B-A4B: Отличный выбор, если проблема четко описана и вам нужен минимальный расход токенов.

Подводные камни: Где локальный AI-агент ломается

Если вы планируете использовать локальных агентов для DevOps, запомните эти три вещи:

1. Память — главный лимит: Даже на MacBook Pro M4 (48GB) ресурсоемкость агентаского цикла (который постоянно перечитывает предыдущие шаги и контекст) быстро истощает память.
2. Агент не равно разработчик: Агент — это просто оркестратор (оркестратор) рассуждений. Он может «убедиться в проблеме» (проверить, есть ли проблема), но не может почувствовать или угадать неявную бизнес-логику.
3. Иллюзия успеха: Некоторые модели умеют имитировать цикл «выполнить команду — получить вывод», но это не значит, что они это сделали. Они могут просто сгенерировать правдоподобный вывод, который расходится с реальностью.

Что попробовать дальше

1. Улучшите промпт, а не модель: Вместо того чтобы пытаться «усилить» модель, инвестируйте время в написание идеального системного промпта, который задает роль, ограничения и пошаговый план действий.
2. Локальный прокси: Если вы строите многоуровневую систему, используйте LLM для генерации конфигураций, а затем вручную (или через CI/CD) внедряйте их, не доверяя агенту финальную настройку.
3. Мониторинг токенов: Всегда следите за расходом токенов. В задачах, где достаточно 500 токенов, использование 2000 токенов из-за лишней болтовни — это прямые потери денег и времени.

Источники

• Habr AI: 6 моделей, 3 инфраструктурных задачи, 1 локальный AI-агент