Маршрутизация моделей кажется простой задачей. Но только до продакшна

Маршрутизация языковых моделей кажется достаточно тривиальной задачей: простые запросы уходят дешевым моделям, сложные — дорогим.  Еще можно выбирать модель по специализации: одну для программирования, другую для обработки изображений, третью для анализа документов. Но это легко только на первый взгляд.

Исследователи IBM Research выяснили ^[1]: в агентных системах эта схема быстро перестает быть рабочей. Задача, которая изначально выглядит как выбор подходящей модели, превращается в оптимизацию всей системы. Маршрутизатору нужно одновременно учесть качество, стоимость, время задержки, состояние инфраструктуры и имеющиеся ограничения.

Как проводили эксперимент

AppWorld ^[2] — среда для проверки агентов, которые управляют приложениями через API и решают многошаговые задачи. Полный исходный набор включает девять приложений, 457 API и 750 заданий. В статье IBM использована выборка из 417 заданий AppWorld Test Challenge.

CodeAct ^[3] — подход, при котором агент выполняет действия с помощью генерируемого исполняемого кода. Вместо того чтобы последовательно выдавать отдельные команды в текстовом или JSON-формате, модель может написать фрагмент Python, выполнить его, изучить результат и скорректировать дальнейшие действия.

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

Что показал эксперимент

Стоимость — это не только цена токена

Исследователи запустили один и тот же агент CodeAct на 417 заданиях AppWorld Test Challenge. Claude Sonnet 4.6 обошелся в 79 $, или около 0,19 $ на задачу. GPT-4.1 — в 155 $, или примерно 0,37 $ на задачу. Расходы во втором случае оказались почти вдвое выше.

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

Все дело оказалось в кешировании контекста. В агентном сценарии модель на каждом шаге получает одни и те же системные инструкции, описания инструментов и историю действий. Большая часть этих данных повторяется. Чем больше попаданий в кэш, тем дешевле обходятся входные токены. В эксперименте IBM более низкая цена чтения кеша у Sonnet перекрыла и высокую базовую стоимость, и более длинную траекторию агента. 

Оказалось, что сравнивать модели только по стоимости миллиона токенов недостаточно. Реальные расходы зависят от нагрузки и инфраструктуры, через которую выполняются запросы. Для маршрутизатора важна именно стоимость завершенной задачи. В нее входят число вызовов модели, объем повторяющегося контекста, доля обращений к кэшу и количество сгенерированных токенов.

Сложность нельзя надежно определить заранее

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

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

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

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

Задержка зависит не только от размера модели

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

Даже более быстрая модель может показать худший результат — например, если запрос попадет в длинную очередь или системе придется заново обрабатывать большой контекст. IBM в своем исследовании отмечает, что инфраструктурные факторы порой влияют на задержку сильнее характеристик самой модели.

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

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

Исследования маршрутизации с учетом latency подтверждают: скорость ответа нельзя считать постоянной характеристикой модели. Оно зависит от длины запроса, нагрузки на этапах обработки контекста и генерации, планировщика и того, как запросы объединяются в пакеты. 

В задачах маршрутизации не может быть единственного верного ответа

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

На рисунке ниже — результаты теста AppWorld Test Challenge с агентом CodeAct:

Каждый синий квадрат — одна из конфигураций маршрутизатора, показывающая соотношение стоимости и точности. Важно, что маршрутизатор предлагает выбрать один из вариантов: отдать приоритет стоимости, задержке или точности. Конфигурация 1 ориентирована на задержку, а ее точность достигает 84% при стоимости 93 $ и среднем времени выполнения 83 секунды. Это дает снижение стоимости на 21% и задержки на 9% по сравнению с использованием только Opus, при падении точности всего на 4%.  Конфигурация 2 снижает стоимость еще больше.

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

Сам оптимизатор при этом оставался легким. По оценкам IBM, его накладные расходы — около 6 мс вычислений и 2 Кбайт памяти ^[4] на задачу.

Почему одного универсального способа маршрутизации не существует

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

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

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

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

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

Главный вывод из исследования

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

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