# Qwen3.6 против Gemma4: Тестирование 6 моделей на реальных багах инфраструктуры
Каноническая страница: https://plainews.ru/posts/llm-test-devops-qwen-gemma
Опубликовано: 2026-05-19T19:47:54.842Z

Сравнили 6 топовых моделей (Qwen, Gemma) на реальных багах FastAPI и Nginx. Узнайте, какой AI-агент выбрать для продакшена.
Вы думали, что 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-агент