Маршрутизация AI-моделей для агентов: как построить routing policy

Коротко

• Маршрутизация AI-моделей — это политика выбора модели для конкретного вызова, этапа или состояния агента. Её задача не в том, чтобы отправить максимум запросов дешёвой модели, а в том, чтобы снизить стоимость успешно выполненной задачи при заданных ограничениях качества и задержки.
• Базовые варианты — classifier routing, жёсткая привязка модели к этапу, каскад с escalation и обучаемый router. Они требуют разных объёмов данных, вычислений и доступа к моделям.
• По заявлению NVIDIA, NeMo Switchyard представляет собой provider-agnostic слой маршрутизации с proxy, совместимым с OpenAI-, Anthropic- и Responses-интерфейсами, а также метриками выбора модели, latency, tokens и outcomes. При этом репозиторий прямо помечает проект как pre-alpha: библиотека libsy имеет статус beta для пробной интеграции, клиенты — alpha, сервер назван demo и не считается production-ready.
• В эксперименте LangChain на 145 задачах routed arm стоил на 74% меньше варианта только с Opus, но уступил ему 6 пунктов accuracy. Frontier-модель получила около 7% вызовов, а judge сформировал 21,2% расходов routed arm.
• Тот же эксперимент не доказывает универсальной выгоды routing: дешёвая модель без router показала 77,7% против 80,0% у routed arm, причём авторы отмечают, что разница меньше межзапусковой вариативности.
• В production нужно измерять не только цену токена, но и cost per successful task, routing regret, escalation rate, p95 latency, fallback success и drift.

Зачем агенту несколько моделей

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

Факт: исследования из пакета рассматривают несколько связанных подходов. FrugalGPT изучает каскады и компромисс между стоимостью и качеством; Hybrid LLM — прогнозирование сложных запросов для cost-quality routing; RouteLLM — обучаемую маршрутизацию между моделями; LLM-Blender — выбор и комбинирование моделей.

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

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

cost per successful task =
(стоимость router + моделей + judge + повторов + переноса контекста + fallback)
/ число принятых успешных задач

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

Что именно маршрутизирует система

До выбора алгоритма нужно определить единицу маршрутизации. Иначе команда сравнит несовместимые политики и получит метрики, которые нельзя объяснить.

Единица решения	Что выбирает router	Преимущество	Основной риск
Отдельный вызов	Модель для текущего prompt	Точная адаптация к локальной операции	Частые переключения и перенос контекста
Этап workflow	Модель для класса шагов: разбор, планирование, проверка	Прозрачная и воспроизводимая политика	Сложность внутри этапа может различаться
Вся задача	Одна модель или один каскад на весь запуск	Проще учитывать сессию и отлаживать трассу	Грубое решение для неоднородного процесса
Состояние после ошибки	Модель восстановления или fallback-путь	Дорогой ресурс используется по необходимости	Ошибка может быть обнаружена слишком поздно

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

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

Какие сигналы видит router

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

Группа сигналов	Примеры	Что помогает решить	Что проверять
Содержание запроса	Длина, тип операции, требуемый формат, наличие нескольких условий	Похож ли вызов на простой или сложный класс	Не маскируется ли сложность короткой формулировкой
Этап агента	Классификация, план, вызов инструмента, проверка, финальный ответ	Какие способности нужны сейчас	Корректно ли размечены переходы между этапами
История выполнения	Неуспешная проверка, повтор, ошибка инструмента	Нужно ли эскалировать или менять стратегию	Не вызвана ли ошибка внешней системой
Сессия	Уже выбранная модель, объём и тип накопленного контекста	Оправдано ли переключение	Полностью ли переносится нужное состояние
Ограничения	Бюджет, deadline, допустимый класс провайдера	Какие варианты вообще разрешены	Не нарушает ли router жёсткое ограничение
Операционное состояние	Ошибки, задержка, доступность endpoint	Нужен ли fallback	Не реагирует ли политика на краткий шум

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

Редакционная рекомендация: храните вместе с трассой входные признаки router, список допустимых моделей, выбранный маршрут, причину выбора, latency, tokens, outcome и последующие fallback-действия. Без этого routing regret и drift останутся предположениями.

Classifier routing

Classifier routing сначала относит запрос к категории, а затем применяет таблицу соответствий «категория — модель». В tuning-free варианте классификатором может быть LLM: NVIDIA перечисляет LLM classifier среди подходов NeMo Switchyard. Классы могут описывать не абстрактную «сложность», а наблюдаемые требования: нужен ли строгий формат, планирование, проверка нескольких условий или восстановление после ошибки.

1. Система формирует компактное представление текущего вызова.
2. Классификатор возвращает класс или оценку уверенности.
3. Policy отбрасывает модели, нарушающие бюджетные, latency- или иные ограничения.
4. Из разрешённого набора выбирается модель, связанная с классом.
5. Outcome записывается для последующего аудита ошибки классификации.

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

Ограничение: LLM classifier сам создаёт вызов, задержку и расход. Кроме того, классификатор может быть уверен в неверной категории. Если проверка класса по сложности приближается к выполнению исходной задачи, экономическая логика ослабевает.

Редакционная рекомендация: сравнивайте classifier не только с дорогой моделью для всех запросов, но и с сильным простым baseline: одной дешёвой моделью, правилами этапов или фиксированной моделью на весь workflow. Именно такой baseline в кейсе LangChain не позволил принять небольшой прирост accuracy за убедительную победу router.

Stage routing

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

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

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

Ограничение: название этапа — слабая замена реальной сложности. Два шага «планирование» могут радикально различаться по числу условий и последствиям ошибки. Кроме того, жёсткое закрепление модели игнорирует временную недоступность endpoint.

Редакционная рекомендация: используйте stage routing как контрольную архитектуру. Затем добавляйте classifier или escalation только в те этапы, где данные показывают большой разброс результатов или стоимости.

Escalation routing

Escalation routing запускает начальную модель, оценивает результат и при выполнении условия передаёт задачу более сильному или просто более подходящему варианту. Это практическая форма каскада, связанная с направлением, которое рассматривает FrugalGPT. NVIDIA также относит escalation к tuning-free стратегиям Switchyard.

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

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

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

Редакционная рекомендация: считайте escalation rate по классам задач и причинам. Высокая доля эскалаций может означать не только слабую первую модель, но и слишком строгий judge, сломанный prompt, ошибку инструмента или неверно выбранную единицу маршрутизации.

Tunable и prefill routers

Обучаемый router использует накопленные примеры, чтобы предсказывать относительную пригодность моделей для входа. RouteLLM посвящён обучаемой маршрутизации между моделями, а Hybrid LLM — прогнозированию сложных запросов и компромиссу cost-quality.

В материалах NVIDIA отдельно описан tunable prefill router. Он использует внутренние состояния модели, возникающие на prefill-этапе. Это принципиально иной уровень интеграции по сравнению с proxy, который видит только запросы и ответы.

Почему это может быть полезно: внутреннее представление потенциально содержит сигналы, которые сложнее извлечь из поверхностных метаданных. Router можно настраивать по примерам предпочтительного выбора.

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

Редакционная рекомендация: не начинайте с tunable prefill router, если команда ещё не умеет стабильно измерять outcome простого stage routing. Обучение не исправит нечёткое определение успеха; оно лишь точнее воспроизведёт имеющуюся разметку вместе с её ошибками.

Session affinity и перенос контекста

Session affinity — это предпочтение сохранять выбранную модель или маршрут в пределах связанной последовательности шагов. Такая политика снижает число переключений и делает трассу понятнее, но не должна превращаться в запрет на escalation или fallback.

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

Интерпретация: switching cost — это не только оплата дополнительных tokens. В него входят сериализация состояния, возможное повторение инструкций, рост latency и риск потерять скрытые предположения предыдущего шага.

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

Ограничение: source pack не содержит универсального протокола session affinity. Поэтому конкретную схему нужно считать проектным решением и проверять на полноту переноса, повторяемость и стоимость.

Разбор кейса LangChain

LangChain опубликовала эксперимент по маршрутизации вызовов агента на наборе из 145 задач. Это полезный пример структуры расходов, но не независимое доказательство общего превосходства routing.

Наблюдение	Что оно означает	Чего оно не доказывает
Routed arm стоил на 74% меньше Opus-only	В данном запуске стоимость routed-варианта была существенно ниже	Что тот же процент повторится на другом агенте, наборе задач или ценовой конфигурации
Routed arm потерял 6 пунктов accuracy относительно Opus-only	Экономия сопровождалась измеримым снижением качества по выбранной метрике	Что компромисс приемлем для конкретного production-сценария
Frontier-модель получила около 7% вызовов	Дорогой маршрут использовался редко	Что минимальная доля frontier-вызовов является целью сама по себе
Judge занял 21,2% расходов routed arm	Контрольное решение было заметной частью бюджета	Что judge всегда будет иметь такую долю
Дешёвая модель дала 77,7%, router — 80,0%	Прирост к простому дешёвому baseline оказался небольшим	Что router надёжно лучше: авторы указывают, что разница меньше межзапусковой вариативности

Главный вывод: сравнение только с Opus-only создаёт неполную картину. Для решения о внедрении нужны минимум три ветки: дорогая модель, дешёвая модель и router. Если routed arm лишь немного превосходит дешёвую ветку, операционная сложность может не окупиться.

Отдельное ограничение: 145 задач — конкретный экспериментальный набор. Нельзя переносить его распределение сложности на другую систему. Также не следует смешивать такой агентный тест с coding leaderboard. FrontierCode предоставляет coding benchmark и системные сравнения, но рейтинг в отдельном benchmark не заменяет трассовую оценку router внутри вашего workflow.

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

Когда routing не окупается

Router — дополнительная система принятия решений. Иногда правильной архитектурой остаётся одна модель.

• Задачи однородны. Если вызовы мало различаются по сложности и требованиям, выбор почти всегда будет одинаковым.
• Дешёвая модель уже проходит порог качества. Небольшой дополнительный прирост не всегда покрывает classifier, judge и поддержку policy.
• Почти всё эскалирует. Каскад превращается в оплату лишней первой попытки.
• Outcome нельзя проверить. Без устойчивой метки успеха невозможно отличить полезную маршрутизацию от случайных колебаний.
• Перенос контекста дорог или ненадёжен. Смена модели создаёт больше ошибок, чем предотвращает.
• Latency жёстко ограничена. Последовательный classifier или judge может нарушить deadline, даже если снижает стоимость tokens.
• Мало данных по редким критическим задачам. Средняя метрика скроет риск именно там, где ошибка наиболее дорога.
• Команда не может поддерживать наблюдаемость. Без версий policy, трасс и outcome невозможно расследовать регрессию.

Как проверять: сравните полную стоимость routed arm с лучшим простым baseline при одинаковом пороге качества и latency. Если преимущество исчезает после включения judge, повторов, fallback и эксплуатационных затрат, routing не решил экономическую задачу.

Метрики и routing regret

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

Метрика	Что считать	Почему нужна
Task success rate	Доля задач, прошедших заранее заданный критерий	Фиксирует качество на уровне результата, а не стиля ответа
Cost per successful task	Все расходы ветки, делённые на число успешных задач	Не поощряет дешёвые, но бесполезные вызовы
p95 latency	95-й перцентиль времени завершения задачи или критичного этапа	Показывает длинный хвост classifier, retries и fallback
Escalation rate	Доля вызовов или задач, перешедших на следующую ступень	Выявляет каскад, который редко завершается дёшево
Fallback success	Доля отказов основного маршрута, после которых задача всё же успешно завершена	Отделяет наличие fallback от его реальной полезности
Routing regret	Потеря относительно лучшего допустимого выбора для данного случая	Показывает цену неверного маршрута
Drift	Изменение входов, маршрутов, outcomes и ошибок во времени	Предупреждает, что старая policy перестала соответствовать трафику

Редакционная операционализация routing regret: для аудируемой выборки выполните допустимые альтернативные маршруты или используйте проверенные результаты параллельных веток. Затем сравните выбранный маршрут с лучшим вариантом, который удовлетворяет ограничениям качества, бюджета и latency. Regret может выражаться в дополнительной стоимости, потере качества, превышении задержки или составной utility, определённой командой заранее.

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

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

Fallback и отказ провайдера

Routing отвечает на вопрос «какую модель предпочесть», а fallback — «как продолжить, если предпочтительный путь недоступен или не дал приемлемого результата». Эти политики связаны, но причины переключения нужно различать.

Событие	Безопасное направление политики	Что записать
Endpoint недоступен	Выбрать заранее разрешённый альтернативный маршрут	Тип ошибки, число попыток, выбранный fallback
Latency приближается к deadline	Не запускать каскад, который заведомо не укладывается в остаток времени	Остаточный бюджет времени и итоговый outcome
Проверка результата не пройдена	Эскалировать с явной причиной провала	Результат проверки и переданный state
Нарушено ограничение формата	Повторить только при наличии бюджета и безопасной повторяемости	Причина retry и число повторов
Нет допустимой модели	Завершить контролируемой ошибкой, а не снимать ограничение молча	Какое ограничение исключило варианты

Как проверять: fault-тест должен подтверждать не только переключение endpoint, но и сохранение ограничений, корректный перенос state, отсутствие бесконечного цикла и успешный outcome. Метрика fallback success считается только по тем случаям, где основной путь действительно отказал.

Редакционная рекомендация: задайте конечный граф fallback, лимит повторов и общий budget задачи. Не разрешайте router самовольно переходить на модель, которая не соответствует требованиям данных, стоимости или продукта. Приоритет ограничений должен быть определён до инцидента.

План внедрения

Ниже — практический чек-лист. Он начинается не с установки router, а с определения задачи и baseline.

1. Опишите outcome. Зафиксируйте машинный, экспертный или продуктовый критерий успешной задачи.
2. Разбейте workflow на этапы. Отметьте места, где требования к модели действительно различаются.
3. Соберите трассы baseline. Запишите вход, этап, модель, latency, tokens, проверки, ошибки и итог.
4. Выберите простые контрольные ветки. Минимум одна дешёвая модель, одна более сильная и текущая production-policy.
5. Определите жёсткие ограничения. Бюджет, deadline и допустимые маршруты должны применяться раньше оптимизации.
6. Запустите stage routing. Используйте его как объяснимую контрольную policy.
7. Добавьте classifier только в неоднородные этапы. Измерьте его собственную цену, latency и ошибки.
8. Спроектируйте escalation. Укажите проверяемый trigger, передаваемый state и максимальное число ступеней.
9. Определите session affinity. Решите, когда сохранять модель, а когда переключение обязательно.
10. Постройте конечный fallback-граф. Для каждого отказа задайте разрешённый следующий шаг и условие остановки.
11. Считайте полную стоимость. Включите router, judge, retries, перенос контекста и fallback.
12. Оцените routing regret. На аудируемой выборке сравните выбор policy с допустимыми альтернативами.
13. Проверьте p95 latency. Среднее время не должно скрывать длинные каскады.
14. Повторите эксперимент. Не принимайте малую разницу за эффект, если она укладывается в межзапусковую вариативность.
15. Версионируйте policy и prompts. Каждая трасса должна указывать конфигурацию, принявшую решение.
16. Настройте контроль drift. Следите за изменением входов, долей маршрутов, ошибок и outcomes.
17. Вводите постепенно. Сначала ограниченная доля подходящего трафика, затем расширение только при сохранении quality- и latency-порогов.

Инструментальная оговорка: NeMo Switchyard можно рассматривать как исследуемый слой для такой архитектуры. Однако репозиторий проекта называет его pre-alpha, libsy — beta для trial integration, клиенты — alpha, а server — demo и не production-ready. Это не формальность: production-внедрение потребует самостоятельной оценки надёжности, безопасности, совместимости и операционной поддержки.

Как проверять routing policy

Оценка должна отвечать не на вопрос «угадал ли router метку сложности», а на вопрос «улучшил ли он систему при наших ограничениях».

1. Сформируйте набор задач, отражающий реальные этапы и редкие критические случаи.
2. Зафиксируйте версии моделей, prompts, tools, policy и критериев outcome.
3. Прогоните одинаковые задачи через простые baselines и routed arm.
4. Повторите запуски там, где результат недетерминирован или заметно меняется.
5. Сравните task success, полную стоимость, p95 latency и типы ошибок.
6. Отдельно посчитайте цену classifier и judge.
7. Проанализируйте false escalation и пропущенную escalation.
8. Проверьте перенос контекста при каждой смене модели.
9. Смоделируйте недоступность основного маршрута и измерьте fallback success.
10. Проведите ручной аудит случаев с высоким routing regret.

Факт: NVIDIA описывает для Switchyard наблюдение за выбором модели, latency, tokens и outcomes через routing layer. Ограничение: наличие метрик в слое не гарантирует правильного определения outcome и не заменяет дизайн эксперимента.

Редакционная рекомендация: задайте критерии остановки заранее. Если routed arm не выполняет quality-порог, не компенсируйте это красивой цифрой экономии. Если он выполняет качество, но нарушает p95 latency, также нельзя считать внедрение успешным.

Что нас ждёт

Фактологическая база на 27 августа 2026 года: в source pack одновременно представлены tuning-free стратегии, обучаемая маршрутизация, каскады, предсказание сложности, выбор и комбинирование моделей. NVIDIA заявляет provider-agnostic routing layer с совместимым proxy и outcome-метриками, но текущая маркировка репозитория Switchyard подчёркивает раннюю зрелость реализации.

Редакционный прогноз: routing policy будет всё меньше походить на правило «дешёвая или дорогая модель» и всё больше — на диспетчер ограниченного workflow. Решение будет учитывать этап, остаточный бюджет, историю проверок, доступность маршрутов, session affinity и вероятность успешного завершения.

Второе направление — переход от token economics к outcome economics. Judge, retries и fallback уже способны занимать заметную долю бюджета: в эксперименте LangChain judge составил 21,2% routed-расходов. Поэтому команды будут оптимизировать весь граф задачи, а не цену одного inference-вызова.

Третье направление — ужесточение требований к доказательствам. Небольшой прирост относительно дешёвого baseline нельзя будет считать победой без повторных запусков, анализа вариативности и routing regret. Публичный leaderboard останется источником гипотез, но не заменит тест на собственном распределении задач.

Ограничение прогноза: source pack не позволяет утверждать сроки стабилизации конкретных проектов, будущие версии API или будущие показатели моделей. Эти параметры не следует достраивать предположениями.

Ограничения

• Материал отражает факты и источники, доступные в исследовательском пакете на 27 августа 2026 года.
• Заявления об архитектуре NeMo Switchyard переданы как заявления NVIDIA и документации проекта, а не как результат независимого production-аудита.
• Результаты LangChain относятся к конкретному набору из 145 задач и конфигурации эксперимента. Они не являются универсальным коэффициентом экономии.
• Разница 80,0% против 77,7% в опубликованном кейсе меньше указанной авторами межзапусковой вариативности, поэтому её нельзя представлять как надёжно доказанный выигрыш routing.
• Source pack не содержит единого стандарта расчёта routing regret. В статье дана редакционная операционализация, которую нужно адаптировать к utility и ограничениям системы.
• Source pack не задаёт универсальный session state contract, production-SLA или безопасный fallback-граф.
• Исследования RouteLLM, FrugalGPT, Hybrid LLM и LLM-Blender подтверждают существование соответствующих направлений, но не доказывают превосходство конкретной policy на произвольном агенте.
• FrontierCode полезен как coding benchmark и источник системных сравнений, но не измеряет автоматически качество маршрутизации внутри конкретного workflow.
• Цены, доступность, версии и сравнительные характеристики моделей могут меняться; в пакете нет оснований фиксировать неуказанные значения.

FAQ

Что такое маршрутизация AI-моделей?

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

Какая метрика для router главная?

Практический приоритет — cost per successful task при обязательных ограничениях качества и latency. Доля дешёвых вызовов сама по себе не показывает, сколько задач завершилось успешно.

Доказывает ли экономия 74% в кейсе LangChain пользу routing?

Нет. Это результат конкретного эксперимента на 145 задачах. Routed arm был на 74% дешевле Opus-only, но потерял 6 пунктов accuracy, а преимущество над дешёвой моделью — 80,0% против 77,7% — оказалось меньше межзапусковой вариативности.

Чем classifier routing отличается от stage routing?

Classifier сначала определяет класс текущего запроса и выбирает маршрут по этому классу. Stage routing использует уже известное состояние workflow и закрепляет модель за этапом, поэтому обычно проще и прозрачнее.

Когда нужна escalation?

Когда ранняя дешёвая попытка часто проходит проверку, а для оставшихся случаев существует надёжный trigger перехода. Если эскалирует почти всё, каскад обычно теряет экономический смысл.

Зачем нужна session affinity?

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

Можно ли считать NeMo Switchyard готовым production-router?

Нет без самостоятельной проверки. Репозиторий маркирует проект как pre-alpha, libsy — как beta для trial integration, клиенты — alpha, а server — demo и не production-ready.

Как проверить fallback?

Нужно смоделировать отказ основного маршрута и проверить конечность графа, соблюдение ограничений, перенос state, итоговый outcome и fallback success. Сам факт переключения endpoint недостаточен.

Источники

1. Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard — подтверждает заявленную NVIDIA архитектуру provider-agnostic routing layer, совместимый proxy, наблюдаемые метрики и типы routers, включая classifier, stage, escalation и tunable prefill.
2. NVIDIA NeMo Switchyard — подтверждает реальную маркировку зрелости проекта: pre-alpha, beta-статус libsy для trial integration, alpha-клиенты, demo-server и предупреждение о неготовности к production.
3. How many of your agent’s calls actually need a frontier model? — подтверждает параметры эксперимента на 145 задачах, снижение стоимости routed arm на 74% относительно Opus-only, потерю 6 пунктов accuracy, около 7% frontier-вызовов, долю judge 21,2%, результаты 77,7% и 80,0% и оговорку о межзапусковой вариативности.
4. FrontierCode Leaderboard — подтверждает наличие coding benchmark и системных сравнений; используется для объяснения, почему leaderboard не заменяет тест router на собственном workflow.
5. RouteLLM — подтверждает исследовательское направление обучаемой маршрутизации между моделями.
6. FrugalGPT — подтверждает исследование каскадов моделей и компромисса между стоимостью и качеством.
7. Hybrid LLM — подтверждает направление предсказания сложных запросов и cost-quality routing.
8. LLM-Blender — подтверждает исследовательское направление выбора и комбинирования моделей.