Devstral Small против GLM 4.7 Flash: какую модель загрузить в ваш coding agent сегодня?

Когда каждый токен стоит денег (или терпения)

Вы запускаете coding agent. Задача простая - написать CRUD API для вашего нового микросервиса. Агент начинает думать. Минута. Две. Пять. Вы смотрите на счетчик токенов и понимате: половина из них ушла не на код, а на внутренний монолог модели о том, как правильно структурировать папку controllers.

Это не гипотетическая ситуация. Это ежедневная реальность разработчиков, которые работают с автономными coding agents в 2026 году. И здесь возникает главный вопрос: какая модель тратит меньше вашего времени и ресурсов на реальную работу?

Сегодня мы сравниваем двух кандидатов: Devstral Small (новая компактная версия от Mistral, вышедшая в январе 2026) и GLM 4.7 Flash (оптимизированная версия от Zhipu AI). Не по абстрактным бенчмаркам, а по единственной метрике, которая имеет значение в продакшене: общее время выполнения задачи от промпта до работающего кода.

Почему эффективность токенов убивает красивые графики

В теории все просто: берете самую умную модель, настраиваете agent framework типа AgentHub, и ждете результат. На практике вы сталкиваетесь с тремя проблемами:

• Контекстная болтовня: модели любят рассуждать. Длинно. Очень длинно. Каждое размышление - токены. Токены - время. Время - деньги.
• Многошаговые тупики: как в этой статье про GLM 4.7, некоторые модели теряются в сложных задачах, начиная переписывать уже работающий код.
• Ресурсный голод: даже на RTX 6000 Pro Blackwell 96GB (о которой мы писали здесь) время инференса имеет значение.

Именно поэтому мы не сравниваем сырую скорость генерации (tokens/second). Мы измеряем end-to-end task completion time - от вашего промпта до готового решения, включая все мысли, ошибки и исправления агента.

Devstral Small: минимализм как философия

Devstral Small - это ответ Mistral на вопрос "а что если сделать coding agent, который не философствует, а просто пишет код?". Модель вышла в январе 2026 с одной четкой целью: быть максимально эффективной в автономных coding workflow.

Что это значит на практике? Devstral обучена распознавать, когда задача достаточно проста для прямого ответа. Вместо:

# Шаг 1: Мне нужно создать функцию для сложения двух чисел
# Шаг 2: Функция должна принимать два аргумента
# Шаг 3: Я назову ее add_numbers
# Шаг 4: Вот код:
def add_numbers(a, b):
    return a + b

Она выдает сразу:

def add_numbers(a, b):
    return a + b

Кажется мелочью? Умножьте на 50 таких решений в одном агентом сеансе. Экономия - сотни токенов.

GLM 4.7 Flash: умный, но болтливый

GLM 4.7 Flash - это оптимизированная для скорости версия GLM 4.7. Zhipu AI позиционирует ее как идеальную для agent workflow, особенно после выхода обновления в декабре 2025, которое улучшило multi-step reasoning.

Проблема GLM 4.7 Flash в ее наследии. Как мы отмечали в разборе бенчмарков, модель отлично справляется с комплексными задачами, но платит за это токенами. Каждый шаг reasoning тщательно документируется. Каждое решение обосновывается.

Тестовый стенд: не синтетика, а реальные задачи

Мы взяли 5 задач, которые типичны для автономных coding agents в 2026:

1. Создать REST API с 3 endpoint (CRUD) для сущности "Task"
2. Написать асинхронного Telegram-бота с 2 командами
3. Создать конфигурацию Docker + docker-compose для Python + PostgreSQL приложения
4. Рефакторинг legacy кода: преобразовать класс из 200 строк в 3 маленьких класса
5. Написать тесты (pytest) для существующего модуля

Каждую задачу агент выполнял полностью автономно, с использованием AgentHub как фреймворка. Мы измеряли:

• Общее время выполнения (секунды)
• Общее количество использованных токенов (вход + выход)
• Количество "шагов reasoning" (отдельные сообщения в цепочке)
• Качество финального кода (работает/не работает после минимальных правок)

Результаты, которые заставят вас пересмотреть выбор модели

Цифры говорят сами за себя. Но есть нюанс.

Когда GLM 4.7 Flash все-таки выигрывает (и это важно)

Не все задачи созданы равными. В наших тестах была одна ситуация, где GLM 4.7 Flash показала свое преимущество:

Это ключевой момент выбора:

• Devstral Small - для стандартных, хорошо понятных задач (CRUD, боты, конфиги, типовые тесты)
• GLM 4.7 Flash - для задач с hidden complexity, где нужно настоящее reasoning

Проблема в том, что заранее редко понятно, к какому типу относится задача. И вот здесь начинается инженерия промптов.

Как заставить обе модели работать на вас

Самый неочевидный лайфхак 2026 года для coding agents: не выбирайте одну модель, используйте обе.

Вот workflow, который мы тестировали и который показал лучшие результаты:

1 Первичный анализ GLM 4.7 Flash

Даете задачу GLM 4.7 Flash с промптом: "Проанализируй сложность этой задачи. Оцени от 1 до 10, где 1 - стандартная шаблонная задача, 10 - требует глубокого анализа legacy кода или нестандартных решений. Объясни свою оценку в одном предложении."

2 Маршрутизация по сложности

Если оценка ≤ 5 - передаем задачу Devstral Small с флагом "direct_generation=true". Если ≥ 6 - оставляем GLM 4.7 Flash с детальным chain-of-thought.

3 Финал: валидация и экономия

Для простых задач экономия достигает 50% токенов. Для сложных - вы получаете качественный анализ, но платите за него. В среднем по проекту - экономия 30-40% токенов без потери качества.

Что будет дальше? Прогноз на 2026-2027

Тренд очевиден: модели для coding agents становятся специализированными. Универсальные LLM типа GPT-5 или Claude 4.5 Sonnet (сравнение с GLM 4.7 было в этой статье) все еще лидируют по raw intelligence, но проигрывают в эффективности для узких задач.

К концу 2026 мы ожидаем:

1. Еще большее разделение: появятся модели специально для рефакторинга, отдельно для тестирования, отдельно для документации
2. Dynamic reasoning switching: одна модель будет сама определять, когда использовать краткий ответ, когда - развернутый reasoning
3. Интеграция с DFlash: технологии типа блочного спекулятивного декодирования сократят время инференса для всех моделей

Но сегодня, в феврале 2026, выбор прост:

Хотите максимальной эффективности для рутинных задач - Devstral Small. Нужен аналитический подход для сложных проблем - GLM 4.7 Flash. А лучше всего - система с маршрутизацией, которая использует сильные стороны каждой.

Последний совет, который сэкономит вам часы: настройте мониторинг не по количеству сгенерированных строк кода, а по соотношению "токены / рабочие строки кода". Если ваша модель тратит 1000 токенов на 10 строк работающего кода - что-то не так. В идеале должно быть 200-300 токенов на 10 строк. Devstral Small дает именно такие цифры. GLM 4.7 Flash - 500-700. Разница в 2-3 раза. Умножьте на количество задач в день.

Арифметика простая. Выбор за вами.