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

Я бы не начинал с router. Сначала полезно доказать, что две модели стабильно выигрывают на разных типах запросов и что эта разница заметна не только в лабораторном тесте.

LLM routing имеет смысл там, где стоимость, latency и качество конфликтуют регулярно. Если все запросы примерно одинаковы, один предсказуемый model contract часто оказывается лучше.

Первый router может быть обычным правилом

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

Такое статическое правило легко объяснить и тестировать. Оно не требует отдельной модели-классификатора, не добавляет скрытой неопределённости и сразу показывает, есть ли экономический смысл в разделении.

Microsoft описывает model router как механизм выбора подходящей модели для конкретного запроса. Я бы пришёл к динамическому выбору только после того, как простая маршрутизация уже доказала полезность.

Проверяемые источники: Microsoft Learn — Model router for Microsoft Foundry concepts

Динамический routing добавляет собственную ошибку

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

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

Microsoft указывает, что router оценивает характеристики запроса и выбирает модель из набора доступных вариантов. Это значит, что список допустимых моделей и политика выбора сами становятся частью production-конфигурации.

Проверяемые источники: Microsoft Learn — How model router works in Microsoft Foundry

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже
LLM routing для бизнеса: когда одной модели уже недостаточно · временная заглушка

Cascade полезнее там, где можно проверить первый ответ

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

Ключевой вопрос — есть ли независимый сигнал качества. Например, schema validation, confidence policy или бизнес-правило, которое обнаруживает неполный результат. Без такого сигнала система не понимает, когда нужно эскалировать.

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

Проверяемые источники: Microsoft Learn — Auto and direct model routing with the Responses API

Экономия может исчезнуть в стоимости управления

Routing добавляет evals, observability, настройки модели, fallback и расследование ошибок выбора. Если экономия на inference мала, команда просто получает больше движущихся частей.

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

Model abstraction и routing особенно полезны, когда компания осознанно работает с несколькими провайдерами. Но сама абстракция не бесплатна.

Проверяемые источники: Google Cloud — Apigee AI solutions: gateway to enterprise-ready AI

Fallback и routing — не одно и то же

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

Если в логах видно только `model=B`, потом сложно понять: B выбрал router, A упала или ответ A не прошёл validation. Для эксплуатации это разные события.

Я бы сохранял причину выбора модели рядом с trace: route policy, fallback event, policy version и конечный outcome. Тогда можно оценить, приносит ли routing измеримую пользу или лишь добавляет разнообразие моделей.

Проверяемые источники: Microsoft Learn — How model router works in Microsoft Foundry · Google Cloud — Apigee AI solutions: gateway to enterprise-ready AI

Я бы начинал с двух классов задач

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

Если граница между классами оказывается устойчивой, её можно автоматизировать. Если половина запросов постоянно перескакивает между моделями, возможно, сам routing criterion плохо сформулирован.

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

Проверяемые источники: Microsoft Learn — Model router for Microsoft Foundry concepts · Microsoft Learn — Auto and direct model routing with the Responses API

Router нужно проверять на дрейфе входных задач

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

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

Routing полезен только пока его критерий описывает текущий процесс. Иначе он превращается в старое предположение, спрятанное внутри инфраструктуры.

Проверяемые источники: Microsoft Learn — How model router works in Microsoft Foundry · Microsoft Learn — Auto and direct model routing with the Responses API

Вопросы, которые я бы уточнил до следующего шага

Что такое LLM routing?

Это выбор модели для конкретного запроса или класса задач по заданной политике. Решение может быть статическим, динамическим или сочетаться с fallback/cascade.

LLM routing всегда снижает стоимость?

Нет. Нужно учитывать стоимость router, дополнительных evals, fallback и эксплуатации нескольких моделей. Экономия имеет смысл только в конечной стоимости корректного результата.

Нужен ли отдельный AI-router?

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

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

Рядом с этой темой я бы держал для «LLM routing»: kak vybrat llm dlya biznesa · Как ограничить стоимость AI-системы · Что происходит с бизнес-процессом, когда AI недоступен.