Маршрутизация моделей: почему простой подход не работает

Большинство систем маршрутизации ошибочно воспринимают выбор модели как задачу классификации. Однако при внедрении этого механизма в агентные системы становится очевидно: перед нами не классификация, а сложная задача системной оптимизации. В ходе наших исследований мы выделили три измерения, которые сделали этот процесс на удивление трудоемким. Мы ожидали, что модель 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 должна была уверенно лидировать. В чем же причина? Ответ кроется в кэшировании — факторе, который многие обсуждения маршрутизации полностью игнорируют. Агентные нагрузки часто повторно используют значительные фрагменты контекста между шагами. При высоких показателях попаданий в кэш эффективная стоимость входных токенов резко падает. Более низкая цена чтения из кэша у Sonnet позволила модели получить преимущество, которое перевесило и ее более высокую базовую стоимость, и большее количество шагов в цепочке рассуждений. Главный вывод: реальные затраты зависят от взаимодействия между моделью, типом рабочей нагрузки и инфраструктурой обслуживания. Маршрутизатор, который ориентируется только на тарифные сетки, оптимизирует параметры по неверным данным.

Трудности оценки сложности задач

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

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

Оптимизация производительности и инфраструктурный фактор

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

Эти уроки определили наш подход к созданию собственного маршрутизатора. Ключевой сдвиг заключался в переходе от модели классификации к модели оптимизации. Вместо вопроса «какая модель лучше для этой задачи?» наш алгоритм оптимизирует показатели стоимости, качества и задержки одновременно, оставаясь при этом достаточно легковесным, чтобы не стать «узким местом». Результаты тестов на AppWorld Test Challenge подтверждают эффективность: мы получили кривую эффективности, где каждая точка — это конфигурация маршрутизатора. Важна не конкретная настройка, а возможность выбора точки на шкале предпочтений: от приоритета стоимости до минимизации задержки или максимизации точности. Маршрутизатор на базе оптимизации позволяет исследовать все пространство компромиссов, в отличие от простых систем, основанных на сложности задачи. Поскольку процесс оптимизации требует всего 6 мс и 2 кБ памяти на задачу, он не создает задержек. Истинная суть маршрутизации — не просто выбор модели, а оптимизация системы в целом. Модели — лишь одна переменная среди поведения кэша, состояния инфраструктуры и ограничений комплаенса.

Источник: huggingface.co