LLM router — слой между приложением и провайдерами моделей, который решает, куда отправить конкретный запрос. В production это не просто удобный alias: router должен учитывать доступность провайдера, latency, цену, ограничения модели, качество ответа, региональные политики и правила fallback.
Два разных решения: модель и провайдер
Полезно разделять model routing и provider routing. Сначала система решает, какая модель подходит задаче: например, дешёвая быстрая модель для классификации или более сильная reasoning-модель для сложного анализа. Затем выбирается конкретный provider/deployment этой модели с учётом health, rate limits, региона и стоимости.
Когда router действительно нужен
У приложения больше одного LLM-провайдера или deployment.
Стоимость frontier-модели слишком высока для всех запросов.
Нужен автоматический fallback при rate limit, timeout или provider outage.
Есть разные SLO: быстрый chat path, качественный research path и дешёвый batch path.
Нужно соблюдать data residency или запрещать отдельные providers для чувствительных данных.
Не начинайте с «умного» auto-router
Самый безопасный первый шаг — статические routing rules и явные model aliases. Сложные classifier-based или semantic routers добавляют скрытый источник ошибок: они могут отправить задачу в более дешёвую модель, которая формально ответит, но ухудшит качество. Сначала нужен измеримый baseline и golden set.
Стратегии маршрутизации
Static rules: маршрут определяется endpoint, tenant, feature или типом задачи.
Weighted routing: нагрузка распределяется между одинаковыми deployments по весам.
Latency-based routing: выбирается healthy endpoint с лучшей текущей задержкой.
Cost-aware routing: учитывается цена input/output и допустимый бюджет запроса.
Classifier/semantic routing: отдельная модель или правило оценивает сложность задачи и выбирает model tier.
Fallback chain: при ошибке запрос переходит к следующей совместимой модели или provider.
Совместимость важнее рейтинга модели
Router не должен выбирать модель только по leaderboard. Проверяйте tool calling, structured output, context window, vision/audio support, JSON schema, streaming и ограничения конкретного endpoint. Для agent workflow несовместимость tool schema важнее нескольких процентов benchmark score.
Fallback не должен менять семантику незаметно
Разделяйте retry того же provider и fallback на другую модель.
Логируйте причину переключения и итоговый serving model.
Не отправляйте чувствительный prompt в provider, который запрещён policy, даже во время outage.
При существенной смене capabilities лучше вернуть controlled error, чем тихо получить некорректный ответ.
Session affinity для диалогов
В длинном чате постоянное переключение моделей между turns может менять стиль, tool behavior и понимание контекста. Если router поддерживает session affinity, закрепляйте related turns за совместимой моделью, но сохраняйте возможность fallback при сбое. Affinity — предпочтение, а не причина игнорировать health и policy.
Quality gates перед экономией
Соберите golden set из реальных production prompts.
Сравнивайте routed answer с текущим baseline по task-specific метрикам.
Отдельно измеряйте tool-call success, structured-output validity и factual/citation quality.
Вводите дешёвую модель постепенно по сегментам, а не сразу на 100% трафика.
Автоматически откатывайте route при деградации quality/SLO.
Observability для router
requested model и фактически обслужившая model/provider;
route reason: rule, cost, latency, fallback, classifier;
TTFT, total latency, tokens и стоимость;
retry/fallback count и причины ошибок;
quality score или downstream success metric;
tenant/user policy, регион и data-handling route.
Budget и cost controls
Стоимость нужно считать до и после маршрутизации. Router может вводить per-request ceiling, tenant budget, model allowlist и max-output limits. Но экономия не должна оцениваться только по цене токена: дешёвая модель, которая вызывает два дополнительных retry или ломает tool workflow, может оказаться дороже end-to-end.
Минимальная production-архитектура
API/agent вызывает логический model alias вместо конкретного provider model ID.
Policy layer проверяет tenant, data class и разрешённые providers.
Router выбирает model tier и deployment/provider.
Gateway применяет timeout, retry, rate limit и fallback policy.
Telemetry пишет route decision, usage, cost и SLO.
Quality monitor сравнивает результат с baseline и сигнализирует о regression.
Что тестировать перед rollout
provider outage и rate-limit storm;
частичный timeout при streaming;
несовместимость tool calling/JSON schema;
резкий рост цены или недоступность нужного региона;
длинную conversation session с affinity;
fallback, который формально 200 OK, но ухудшает качество;
повторный запрос с idempotency для операций, запускающих внешние действия.
Практический rollout
Начните с 2 моделей и 2–3 явных правил.
Добавьте provider fallback без изменения model tier.
Соберите telemetry и golden-set оценки.
После этого вводите cost/latency routing на небольшой доле трафика.
Classifier/auto-routing включайте только там, где можете измерить regression и быстро откатить.
Главный принцип
Хороший LLM router не просто «выбирает самую дешёвую модель». Он делает route decision воспроизводимым и наблюдаемым: понятно, почему выбран конкретный model/provider, какие ограничения действовали, сколько это стоило и не ухудшилось ли качество. Именно эта прозрачность превращает multi-model setup в production-инфраструктуру, а не в набор случайных fallbacks.