IBM Research: Claude Sonnet 4.6 дешевле GPT-4.1 в агентных задачах, из-за кэша

Команда IBM Research рассказала, как строила систему маршрутизации между LLM для агентных продуктов, и объяснила, почему задача оказалась намного сложнее, чем выбор «лучшей модели под задачу». Изначально маршрутизация выглядела как классификация: оценить задачу и отправить её подходящей модели. На практике это превратилось в задачу системной оптимизации сразу по трём направлениям, стоимости, сложности и задержке.

Со стоимостью команда столкнулась с парадоксом. На тесте AppWorld Test Challenge (417 задач, один и тот же агент на архитектуре CodeAct) агент на Claude Sonnet 4.6 обошёлся в 79 долларов (0,19 доллара за задачу), а агент на GPT-4.1, в 155 долларов (0,37 доллара за задачу), почти вдвое дороже. По номинальным ценам за токены должно было выйти наоборот: у GPT-4.1 цена ниже и на входные, и на выходные токены, а Sonnet тратит примерно втрое больше шагов рассуждения на ту же задачу. Разгадка, в кэшировании: агентные системы переиспользуют большие куски контекста между шагами, и при высокой доле попаданий в кэш эффективная цена входных токенов резко падает. У Sonnet дешевле именно чтение из кэша, и это с лихвой перекрывает и более высокую базовую цену, и более длинную траекторию рассуждений. Вывод команды: реальная стоимость зависит от связки модель + характер нагрузки + инфраструктура обслуживания, а роутер, ориентирующийся только на прайс-лист, оптимизирует не те цифры.

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

С задержкой тоже не всё сводится к размеру модели (условно «больше, значит медленнее»). Сама маршрутизация добавляет накладные расходы, а на итоговое время ответа часто сильнее влияют факторы инфраструктуры, на каком железе крутится модель, прогрет ли кэш, насколько загружен эндпоинт: теоретически более быстрая модель может на практике давать более медленный отклик, если условия обслуживания не подходят. Важна и гранулярность маршрутизации: если решение принимается один раз на всю задачу, накладные расходы минимальны; если решение принимается на каждом шаге агента (это даёт больше гибкости для адаптации по ходу выполнения), каждая дополнительная точка принятия решения добавляет и задержку, и операционную сложность.

Исходя из этих трёх уроков, команда перестала воспринимать маршрутизацию как классификацию и стала решать её как задачу оптимизации: алгоритм одновременно оптимизирует стоимость, качество и задержку, оставаясь при этом достаточно лёгким, чтобы не превратиться в узкое место. На AppWorld Test Challenge с агентом на CodeAct разные конфигурации роутера образуют границу компромисса «стоимость, точность». Конфигурация 1, оптимизированная под задержку, даёт 84% точности за 93 доллара и 83 секунды, это на 21% дешевле и на 9% быстрее, чем запуск одной только модели Opus, при падении точности всего на 4%. Конфигурация 2 снижает стоимость ещё сильнее. Для сравнения, стандартный роутер, маршрутизирующий по сложности задачи, попадает в похожий диапазон точности, но при более высокой стоимости, он не исследует всё пространство компромиссов так, как это делает оптимизационный подход. При этом сама оптимизация лёгкая, около 6 миллисекунд и 2 килобайт памяти на задачу, так что роутер сам не становится узким местом.

Главный вывод команды: маршрутизация, это не про выбор «лучшей» модели, а про поиск лучшей рабочей точки для всей системы целиком. Модель, лишь одна переменная среди поведения кэша, состояния инфраструктуры, требований комплаенса и характера рабочей нагрузки. IBM Research обещает отдельный пост с техническими деталями своего подхода.

Ключевые факты

На тесте AppWorld (417 задач, один и тот же агент на CodeAct) агент на Claude Sonnet 4.6 обошёлся в 79 долларов (0,19 доллара за задачу), а на GPT-4.1, в 155 долларов (0,37 доллара за задачу), почти вдвое дороже, хотя токены GPT-4.1 номинально дешевле.
Разница объясняется кэшированием: агентные системы переиспользуют контекст между шагами, а у Sonnet дешевле чтение из кэша, это перекрывает и более высокую базовую цену, и втрое больше шагов рассуждения.
Оценить сложность задачи заранее ненадёжно: простой на вид запрос может потянуть за собой поиск, проверки на соответствие, вызовы инструментов и несколько итераций уточнения.
Задержка зависит не только от размера модели, а от состояния инфраструктуры (прогрет ли кэш, загружен ли эндпоинт) и от того, маршрутизируется ли задача целиком или каждый шаг агента отдельно.
IBM Research построила роутер как задачу оптимизации по стоимости, качеству и задержке одновременно: конфигурация под задержку даёт 84% точности за 93 доллара и 83 секунды, на 21% дешевле и на 9% быстрее чистого Opus при падении точности на 4%, а накладные расходы самого роутера, около 6 мс и 2 КБ памяти на задачу.

Почему это важно

Материал ломает интуитивное представление о маршрутизации между LLM как о простом выборе «лучшей модели под задачу». IBM Research показывает на реальных цифрах, что решения, основанные только на прайс-листах моделей или на оценке сложности задачи, систематически ошибаются: стоимость зависит от кэширования и характера нагрузки, а не только от цены за токен, а сложность задачи часто невозможно оценить заранее. Это важно для всех, кто строит продукты поверх нескольких LLM ради экономии: наивный роутер может незаметно оптимизировать не те показатели.

Кому это важно

Прежде всего, командам, которые разрабатывают агентные ИИ-продукты и маршрутизируют запросы между несколькими провайдерами моделей (OpenAI, Anthropic и другими) ради баланса цены и качества. Также полезно инженерам MLOps и платформенным командам, проектирующим слой выбора модели, и всем, кто считает и оптимизирует расходы на LLM в масштабе продакшн-нагрузки.

Как это применить

Ключевые практические выводы: считать реальную стоимость запроса на всём пути выполнения задачи, а не по прайс-листу за токен, эффект кэширования может полностью перевернуть картину; не строить роутер только на оценке сложности задачи, закладывать требования комплаенса, резидентности данных и списков разрешённых моделей; заранее решить вопрос гранулярности маршрутизации, маршрутизация всей задачи целиком дешевле по накладным расходам, чем маршрутизация каждого шага агента отдельно; при сравнении моделей использовать одинаковый агентный каркас (как CodeAct в AppWorld), чтобы сравнивать реальную, а не номинальную стоимость.

Можно ли доверять

Это инженерный блог-пост самой команды IBM Research, опубликованный на площадке Hugging Face, независимой проверки цифр нет. Конкретные результаты (417 задач, AppWorld Test Challenge, стоимость и точность конфигураций роутера) получены на собственном тестовом стенде компании и представлены как её собственная разработка, а не как сторонний бенчмарк. Рассуждения о природе проблемы (кэширование, скрытая сложность, инфраструктурные факторы задержки) выглядят методологически обоснованными и совпадают с общеизвестной практикой работы с LLM API, но конкретные проценты и доллары стоит воспринимать как заявленные вендором, а не как независимо подтверждённые.

Риски и подводные камни

Конкретное соотношение цен Claude Sonnet 4.6 и GPT-4.1 привязано к конкретному моменту, конкретному бенчмарку (AppWorld) и конкретному агентному каркасу (CodeAct), цены на API и поведение кэша у обоих провайдеров меняются со временем, поэтому вывод «Sonnet дешевле GPT-4.1» нельзя автоматически переносить на другие задачи и другие пары моделей. Пост не раскрывает точную архитектуру роутера и детали алгоритма оптимизации, авторы обещают это в отдельном материале, но пока проверить методику независимо нельзя. Результаты получены на одном бенчмарке и одной конфигурации агента, поэтому обобщать их на произвольные агентные системы стоит с осторожностью.

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

— IBM Research, блог на Hugging Face