Серж ФедикБлог

Разбор5 мин чтения

Экономия в агентных моделях начинается с режима работы, а не со смены всего стека

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

Рынок двигается не только за счёт новых способностей

В тестах на наборах агентных траекторий Sol 6.1 показала качество примерно на уровне Sol 6.0 High. При этом она заметно дешевле и немного быстрее. Это не повод объявлять новую модель прорывом. Качественного скачка в результатах нет.

Но для команды, которая делает много агентных прогонов, такая разница важна. Если качество остаётся тем же, снижение цены расширяет границу между качеством, стоимостью и скоростью. На графике это выглядит скромно. В бюджете на регулярные задачи - уже вполне заметно.

Под фронтиром здесь стоит понимать не абстрактный рейтинг моделей. Это область прогресса с июля 2026 года по 2 показателям: качество за деньги и качество при заданной скорости. Модель может быть сильной в общем сравнении, но проигрывать на этой карте из-за цены, задержки или нестабильности ответа.

Лучший способ сэкономить на модели - убрать из запроса то рассуждение, которое системе не нужно.

Режим Low оказался интереснее ожидаемого

Самый практичный результат теста связан не с базовой версией Sol 6.1, а с её режимом Low. В этом прогоне он немного превзошёл сочетание High и Med. Причина не установлена, поэтому превращать наблюдение в универсальное правило нельзя.

Есть рабочая гипотеза: отключение reasoning может благоприятно влиять на Schema-Guided Reasoning. Schema-Guided Reasoning или SGR - это рассуждение по заранее заданной схеме. Модель не ищет форму ответа на ходу, а следует структуре, которую ей передали.

В таком сценарии дополнительный внутренний reasoning способен не помочь, а начать конфликтовать с ограничениями. Похожее поведение уже наблюдалось у моделей вроде GPT-oss-120B, когда их начали сочетать с constrained decoding. При constrained decoding модель ограничена допустимыми вариантами продолжения: например, она должна строго попадать в заданную структуру, а не свободно формулировать ответ.

Важно другое: повторный запуск бенчмарка Sol 6.1 дал в точности те же ответы. Это не объясняет, почему Low оказался впереди, но убирает очевидное подозрение на случайный единичный результат.

SGR даёт понятный повод проверить более дешёвый режим

Рекомендация здесь узкая: если в агентном процессе уже используется SGR, стоит отдельно прогнать Sol 6.1 Low. Цель проста - снизить расходы без заметной потери качества на своей траектории.

Не переносите этот вывод на любые задачи с языковой моделью. Свободный диалог, творческая генерация, открытый поиск и агент с плохо определённой целью могут вести себя иначе. Там reasoning иногда даёт нужную устойчивость. В SGR же часть этой работы уже забрала на себя схема.

Для сравнения достаточно держать одинаковыми входные данные, системные инструкции, инструменты, лимиты и критерий успеха. Меняйте только режим модели. Иначе тест измерит сразу всё: разницу в промпте, случайную смену инструмента, таймауты и особенности маршрута.

так правило записано в файле
Для задач со Schema-Guided Reasoning сначала сравниваем Sol 6.1 Low с текущим режимом на одинаковом наборе траекторий. Считаем стоимость, время выполнения, долю успешных завершений и долю пустых ответов.

Вывод

в структурированных агентных задачах режим Low стоит рассматривать как отдельную конфигурацию, а не как заведомо упрощённый вариант. Его преимущество надо подтвердить на собственных сценариях, но проверка может быстро окупиться.

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

На том же фронтире Sonnet 5.5 и Opus 5.5 оказались глубоко внутри уже освоенной области. Причина не в одном только качестве или скорости. Эти модели чаще других давали fatal refusals - фатальные отказы, когда ответ вообще не выдаётся.

Для агентной системы это тяжёлая поломка. Агент не получает очередной шаг, не вызывает инструмент, не формирует структуру для следующего узла. Красивый средний балл модели перестаёт быть главным, если процесс регулярно останавливается без результата.

Sonnet 5.5 могла бы сдвинуть фронтир по скорости и качеству, если бы не эта особенность. При этом Opus 5 и Sonnet 5 в прежних тестах работали нормально. Ухудшение в наблюдениях началось после выхода Fable. Это временная граница в результатах, а не доказанная причина проблем.

Проверять здесь нужно 4 равных показателя:

01Качество результатапроходит ли ответ ваш критерий успешного шага.
02Стоимостьсколько стоит не отдельный запрос, а завершённая агентная траектория.
03Скоростьсколько времени занимает полезный результат, включая повторные попытки.
04Доля фатальных отказовкак часто система не получает ответ и вынуждена останавливать или перезапускать цепочку.

Ошибаются те, кто смотрит только на цену токена или усреднённый балл бенчмарка. Дешёвый вызов, который иногда не возвращает ответ, становится дорогим из-за повторов, fallback-маршрутов и ручной проверки. Быстрая модель с отказами тоже не обязательно ускоряет процесс целиком.

Бенчмарк полезен как фильтр, а не как решение за вас

Внешний тест помогает сузить список кандидатов. Он показывает направление: Sol 6.1 сохраняет уровень Sol 6.0 High при более выгодной экономике, а Sol 6.1 Low заслуживает проверки в SGR. Но финальное решение принимается на ваших траекториях.

Особенно если агент работает с ограниченным форматом ответа, несколькими инструментами и ценой ошибки выше стоимости одного запроса. В таких системах важны воспроизводимость и отказоустойчивость. Не берите модель в основной маршрут после одного удачного примера. Возьмите 1 повторяемый набор задач, добавьте неуспешные кейсы и замерьте полный путь до результата.

Для фиксации таких тестов и маршрутов команды используют собственные рабочие панели, в том числе ATLAS PANEL. Смысл не в ещё одной витрине метрик. Смысл в том, чтобы видеть: какой режим дал результат, сколько он стоил, где агент остановился и когда fallback стал съедать выгоду.

Вывод

экономия появляется не после чтения рейтинга, а после контролируемого сравнения на одинаковой работе. В сценариях с SGR Sol 6.1 Low - разумный кандидат для такого сравнения.