Кажется, что внедрение маршрутизации (model routing) в агентные системы — это легкая победа. Логика интуитивно понятна: отправляйте простые запросы на более дешевые модели, а сложные задачи резервируйте для мощных и дорогих решений. Или же маршрутизируйте по специализации: Claude для кода, Gemini для мультимодальных данных и так далее. Классификатор или эвристическое правило принимает решение, затраты снижаются, производительность остается высокой. Готово.
Но на практике все обстоит не так просто. Большинство систем маршрутизации исходят из предпосылки, что выбор модели — это задача классификации. Однако, основываясь на нашем опыте построения маршрутизации в агентных системах, то, что выглядит как проблема выбора модели, быстро превращается в проблему системной оптимизации. Три ключевых измерения сделали этот процесс для нас неожиданно сложным.
011. Стоимость — это не только прайс-лист модели
Мы ожидали, что GPT-4.1 будет дешевле, чем Claude Sonnet 4.6. Но это оказалось не так. В ходе тестирования 417 задач в рамках AppWorld Test Challenge с использованием одного и того же агента CodeAct, Sonnet обошелся в $79 в общей сложности ($0,19 за задачу), тогда как GPT-4.1 потребовал $155 ($0,37 за задачу) — почти вдвое дороже. На бумаге это не имеет смысла. Токенная цена GPT-4.1 ниже как для входных, так и для выходных данных, а Sonnet выполняет примерно в три раза больше шагов рассуждения для завершения тех же задач. Исходя только из заявленной цены, GPT-4.1 должен был бы легко выиграть.
Объяснение кроется в кэшировании — аспекте, который большинство обсуждений маршрутизации полностью игнорирует. Рабочие нагрузки агентов склонны повторно использовать большие фрагменты контекста на протяжении всех шагов. Когда уровень попадания в кэш (cache hit rate) высок, эффективная стоимость входных данных резко снижается. Более низкая цена чтения кэша у Sonnet означала, что он получил непропорционально большую выгоду от этой модели, что позволило ему преодолеть как более высокую базовую цену, так и более длинные траектории выполнения.
Вывод: фактическая стоимость зависит от взаимодействия модели, рабочей нагрузки и инфраструктуры обслуживания. Маршрутизатор, который смотрит только на прайс-листы, оптимизирует работу против неверных цифр. Это особенно актуально для российских разработчиков, использующих локальные развертывания или облачные провайдеры с различными политиками кэширования.
022. Сложность — это не только трудность задачи
Распространенная стратегия маршрутизации — оценить, насколько сложной является задача, и отправить более сложные задачи более сильным моделям. Это интуитивно понятно, но ломается в двух аспектах.
Во-первых, сложность часто невидима в момент маршрутизации. Запрос вроде «суммируй этот контракт» выглядит простым, но может запустить процесс извлечения данных, проверки соответствия нормативным требованиям, использования инструментов и нескольких раундов уточнения, прежде чем задача будет выполнена. Тем временем, высоко технический запрос может быть эффективно обработан меньшей специализированной моделью. Вы часто не знаете, насколько сложной на самом деле является задача, пока выполнение не начнется.
Во-вторых, даже если вы можете идеально оценить сложность, это лишь один из многих сигналов. В производстве маршрутизаторы должны одновременно балансировать стоимость, задержку, специализацию модели и надежность. Корпоративные развертывания добавляют еще больше ограничений: требования к соответствию нормативным актам, правила резидентности данных, ограничения конфиденциальности, списки одобренных моделей. Задача, которая идеально подошла бы для одной модели, может потребовать отправки в другое место из-за требований управления — и маршрутизатор должен справляться с этим изящно.
Маршрутизаторы не решают одну проблему. Они постоянно балансируют стоимость, качество, задержку, соответствие нормативным требованиям и надежность одновременно. Это требует многомерного подхода, а не простого бинарного выбора.
033. Задержка — это не только скорость модели
Искусственно думать о задержке исключительно в терминах размера модели — большие модели медленнее, маленькие быстрее. Но то, что пользователь фактически испытывает, зависит от гораздо большего.
Сама маршрутизация добавляет накладные расходы. Факторы инфраструктуры — на каком оборудовании работает модель, теплый ли кэш, насколько загружен конечный пункт — часто доминируют над общим временем отклика. Теоретически более быстрая модель все равно может обеспечить более медленный опыт, если условия обслуживания не подходят.
Затем есть гранулярность маршрутизации. Маршрутизация один раз за задачу добавляет минимальные накладные расходы. Но маршрутизация на каждом шаге — что дает больше гибкости для адаптации во время выполнения — означает, что каждая дополнительная точка принятия решения вводит задержку и операционную сложность.
Маршрутизатор, игнорирующий систему обслуживания, оптимизирует работу против неверной реальности. Это особенно критично при работе с моделями, размещенными в разных регионах, где сетевая задержка может нивелировать преимущества более быстрых вычислительных мощностей.
04Как мы решили эту проблему?
Эти уроки сформировали то, как мы построили наш маршрутизатор. Ключевой сдвиг: мы перестали рассматривать маршрутизацию как задачу классификации и начали рассматривать ее как задачу оптимизации. Вместо вопроса «какая модель лучше всего подходит для этой задачи?», наш алгоритм оптимизирует стоимость, качество и задержку одновременно — оставаясь достаточно легким, чтобы не становиться узким местом.
На рисунке ниже показан результат на AppWorld Test Challenge с агентом CodeAct. Каждый синий квадрат — это другая конфигурация нашего маршрутизатора, очерчивающая фронтальную кривую «стоимость-точность». Важна не отдельная точка, а то, что маршрутизатор дает вам диапазон точек работы для выбора в зависимости от того, хотите ли вы приоритизировать стоимость, задержку или точность.
Конфигурация 1 (оптимизированная по задержке) достигает 84% точности за $93 и 83 секунды — снижение стоимости на 21% и снижение задержки на 9% по сравнению с запуском Opus alone, с лишь 4% падением точности. Конфигурация 2 снижает стоимость еще ниже. Обратите внимание, что стандартный маршрутизатор на основе сложности (бирюзовый ромб) попадает в аналогичный диапазон точности, но при более высокой стоимости — он не исследует все пространство компромиссов, как может сделать подход на основе оптимизации. И поскольку сама оптимизация легковесна (примерно 6 мс и 2 КБ памяти на задачу), маршрутизатор не становится узким местом, о котором мы предупреждали ранее.
05Более широкий контекст
Урок, который мы извлек из этой работы, заключается в том, что маршрутизация — это не выбор моделей. Это оптимизация систем. Модели — это одна переменная — важная, но лишь одна среди поведения кэширования, состояния инфраструктуры, ограничений соответствия и шаблонов рабочей нагрузки.
Когда маршрутизация работает хорошо, это редко происходит потому, что она нашла «лучшую» модель для данной задачи. Это происходит потому, что она нашла лучшую точку работы для всей системы. Это более сложная проблема, чем классификация, но именно ее стоит решать.
Мы поделимся более подробной технической информацией о нашем подходе в последующем посте. Тем временем, если вы строите маршрутизацию в своих собственных агентных системах, мы хотели бы услышать, с какими компромиссами вы сталкиваетесь.
06Что это значит на практике
Для разработчиков и архитекторов, внедряющих AI-агенты в производство, этот кейс IBM Research служит важным напоминанием: маршрутизация — это не просто переключатель между моделями. Это сложный механизм, требующий учета множества факторов. Вот ключевые выводы для практического применения:
- Тестируйте в реальных условиях. Не полагайтесь только на прайс-листы. Проведите A/B-тестирование с реальными рабочими нагрузками, чтобы понять, как кэширование и инфраструктура влияют на стоимость.
- Мониторьте задержку на всех этапах. Включите в метрики время маршрутизации, время ожидания в очереди и время выполнения. Часто именно инфраструктурные факторы становятся узкими местами.
- Учитывайте комплаенс. В корпоративной среде выбор модели часто диктуется не эффективностью, а требованиями безопасности и резидентности данных. Маршрутизатор должен учитывать эти ограничения с самого начала.
- Используйте оптимизацию, а не классификацию. Вместо жестких правил «если задача сложная, то модель X», используйте алгоритмы, которые балансируют несколько метрик одновременно, находя оптимальную точку компромисса.
В конечном итоге, успешная маршрутизация — это искусство баланса. Она требует глубокого понимания не только возможностей моделей, но и всей экосистемы, в которой они работают. Только так можно достичь истинной эффективности и снизить затраты, не жертвуя качеством.
Мы надеемся, что этот разбор поможет вам избежать типичных ошибок при внедрении маршрутизации в ваших проектах. Помните: то, что кажется простым решением, часто скрывает за собой сложную систему взаимосвязанных переменных. Исследование этих взаимосвязей — ключ к созданию эффективных и экономичных AI-агентных систем.
Если вы работаете с подобными задачами, делитесь своим опытом в комментариях. Коллективное знание сообщества — лучший инструмент для решения сложных проблем в области AI-инфраструктуры.
Статья основана на материалах IBM Research. Все технические детали и результаты тестов взяты из оригинальной публикации.
Источник: Hugging Face ↗