ACRouter сокращает расходы на маршрутизацию моделей ИИ в 2,6 раза

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

Новый открытый фреймворк под названием Agent-as-a-Router решает эту проблему, рассматривая маршрутизатор как динамического агента, накапливающего память. Он использует цикл «Контекст-Действие-Обратная связь» (C-A-F) для отслеживания успешных и неудачных попыток моделей и обновления поведения маршрутизатора.

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

Для реальных приложений этот фреймворк предоставляет возможность заменить жестко закодированную ИИ-инфраструктуру самооптимизирующимися системами, способными адаптироваться к изменениям в поведении пользователей и базовых моделях, используемых в корпоративном стеке ИИ.

Экономика маршрутизации и дефицит информации

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

В настоящее время разработчики полагаются на два основных механизма для решения этой задачи. Первый — это эвристическая маршрутизация, которая опирается на жестко закодированные ручные правила. Например, разработчик может написать правило, согласно которому, если промпт содержит определенные ключевые слова, он направляется в GPT-5.5. В противном случае он отправляется в размещаемую самостоятельно открытую модель, такую как Kimi K2.7.

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

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

Это приводит к трем отчетливым точкам сбоя. Во-первых, статические маршрутизаторы страдают от замороженного информационного состояния, что означает неспособность накапливать новую обратную связь о выполнении в ходе развертывания. Во-вторых, они терпят неудачу при генерализации вне распределения (OOD). Они дают сбой во время повседневных операций, когда корпоративные данные или поведение пользователей меняются, поскольку их обучающие данные больше не соответствуют реальности. Наконец, они крайне уязвимы к смене моделей (model churn). Статический классификатор, обученный на сегодняшних моделях, может устареть, когда на следующей неделе появится более совершенная модель.

Agent-as-a-Router: Саморазвивающаяся система

Основной тезис Agent-as-a-Router заключается в том, что по-настоящему эффективный маршрутизатор должен приобретать и накапливать информацию на основе результатов выполнения в процессе развертывания, по сути, обучаясь прямо на рабочем месте.

Исследователи достигли этого с помощью цикла C-A-F. Когда поступает новый промпт, маршрутизатор изучает его и метаданные задачи, такие как язык программирования или сложность. Затем он ищет в своей исторической памяти похожие задачи, чтобы узнать, какие модели добивались успеха или терпели неудачу в прошлом. Маршрутизатор использует этот контекст для выбора целевой модели и выполнения задачи. Наконец, система наблюдает за реальным результатом, извлекает сигнал успеха или неудачи и записывает эту обратную связь обратно в свою память для принятия будущих решений о маршрутизации.

Рассмотрим автоматизированный конвейер корпоративной аналитики данных. Маршрутизатор получает задачу генерации SQL и отправляет ее в открытую модель, такую как Kimi. Модель галлюцинирует имя столбца и не может скомпилировать SQL. Цикл C-A-F фиксирует ошибку компиляции, регистрирует ее как обратную связь и записывает в лог. Когда в следующий раз поступает похожий неясный SQL-запрос, маршрутизатор проверяет свой контекст и направляет задачу более продвинутой модели, такой как Claude Opus 4.8.

ACRouter

Исследователи разработали ACRouter как конкретное воплощение этого фреймворка. Он состоит из трех основных компонентов: Оркестратора, Верификатора и Памяти. Эта архитектура поддерживается уровнем инструментов для физического выполнения цикла C-A-F.

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

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

Сам Оркестратор имеет легкий вес. Вместо массивной, сложной с вычислительной точки зрения большой языковой модели исследователи обучили адаптер с числом параметров менее миллиарда на базе Qwen 3.5 (0,8 млрд параметров), что означает возможность его самостоятельного развертывания на любом выбранном вами устройстве.

ACRouter в действии: Превосходство над передовыми базовыми моделями

Чтобы протестировать фреймворк в экстремальных условиях, исследователи представили CodeRouterBench — среду оценки, состоящую примерно из 10 000 задач с проверенными оценками для восьми передовых моделей, включая Claude Opus 4.6, GPT-5.4, Qwen3-Max и GLM-5. Оценка была разделена между тестами в пределах распределения (ID) (охватывающими девять одношаговых измерений программирования, таких как проектирование алгоритмов и генерация тестов) и тестовым стендом агентского программирования вне распределения (OOD). Задачи OOD существенно отличались по качеству и требовали многошагового планирования, навигации по файлам и итеративной отладки, чтобы проверить, сможет ли маршрутизатор адаптироваться к принципиально новым доменам.

Результаты базового тестирования показали, почему стратегия с использованием одной модели несовершенна: ни одна модель не доминирует во всех категориях. Например, хотя Claude Opus 4.6 показал самую высокую среднюю производительность, в проектировании алгоритмов его превзошел GLM-5 (относительное улучшение на 86%), а в генерации тестов — Qwen3-Max (улучшение на 111%), несмотря на то, что Opus стоит примерно в 12 раз дороже меньших моделей, таких как Kimi-K2.5.

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

Согласно бенчмаркингу исследователей, ACRouter прочно обосновался на границе Парето по стоимости и производительности. Как на потоках задач ID, так и на сложных агентских тестах OOD, ACRouter добился наименьшего кумулятивного сожаления (cumulated regret) — метрики, измеряющей субоптимальные решения о маршрутизации с течением времени. На тестовом наборе в пределах распределения затраты на ACRouter составили $13,21 за весь прогон задач по сравнению с $34,02 при постоянном использовании Opus по умолчанию — экономия в 2,6 раза.

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

Предостережения, ограничения и с чего начать

Хотя парадигма Agent-as-a-Router решает проблему информационного дефицита, она не является универсальным решением для всех рабочих процессов ИИ.

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

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

Исследователи выложили в открытый доступ код на GitHub и опубликовали веса модели оркестратора на Hugging Face под лицензией Apache 2.0. Маршрутизатор совместим с Claude Code, Codex и OpenCode.