Как построить AI model router API для стоимости, скорости и отказоустойчивости

AI model router API принимает запрос, определяет его класс и выбирает модель по заранее заданным ограничениям: качеству, цене, latency, доступности и политике данных. Хороший router не угадывает «лучшую модель» магически. Он принимает объяснимое решение, записывает причину выбора и умеет безопасно остановиться.

Первая версия AI-продукта обычно подключена к одной модели. Это разумно: меньше кода, проще отладка. Затем появляются противоречивые требования. Маркетингу нужен хороший русский, поддержке — низкая задержка, финансам — строгий JSON, разработчикам — сильный coding Agent, CFO — меньший счёт.

Добавить пять Model ID несложно. Сложно не превратить систему в набор случайных if, который никто не решается менять.

Router начинается не с модели, а с класса задачи

Если запрос нельзя отнести к классу с приемлемой уверенностью, router должен выбрать безопасный default, а не самый дешёвый route.

Минимальная архитектура

application
  -> policy layer
  -> task classifier
  -> model registry
  -> router
  -> gateway/provider
  -> validator
  -> telemetry

model registry stores:
capabilities, price tiers, context limits,
data policy, timeout, eval score, health

Model registry важнее красивого алгоритма. Без актуальных данных router будет принимать точные решения на основе устаревшей реальности. Цены, лимиты и capabilities должны версионироваться, а изменения — проходить review.

Почему «дешёвая модель для простых запросов» — слабое правило

Сложность запроса нельзя надёжно определить по длине. «Верни сумму НДС» выглядит просто, но ошибка может стоить дорого. Длинная просьба переписать рекламный текст может быть безопасной и дешёвой.

Вместо одного score используйте ограничения:

· risk: есть ли деньги, персональные данные или внешнее действие;

· contract: нужен ли JSON Schema, Vision или Tools;

· latency budget: сколько времени осталось до SLA;

· quality floor: минимальный Eval score для класса;

· cost ceiling: максимально допустимая ожидаемая стоимость;

· data policy: разрешённые provider и регионы.

Пример объяснимого решения

{
  "task_class": "support_refund_complex",
  "risk": "medium",
  "required": ["ru", "json_schema"],
  "latency_budget_ms": 8000,
  "selected_model": "strong-model-a",
  "reason": "cheap-model-b below quality floor",
  "fallback": "strong-model-c",
  "policy_version": "2026-08-11.3"
}

Такой лог помогает разбирать счёт, инциденты и жалобы. Запись полного Prompt не всегда нужна и может нарушать требования к данным; для аналитики часто достаточно хеша, класса и обезличенных метрик.

Три стратегии маршрутизации

В production часто работает гибрид: правила отсекают запрещённые routes, классификатор выбирает класс, каскад повышает модель при низкой уверенности.

Каскад без самообмана

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

Надёжнее использовать проверяемые сигналы: прошёл ли JSON Schema, найдена ли цитата в RAG-контексте, выполнились ли тесты, совпала ли сумма с детерминированным расчётом. LLM-as-a-judge полезен как один сигнал, но не как единственный судья.

Стоимость маршрута

Ожидаемая стоимость включает больше, чем Token:
expected_cost = model_cost
              + retry_probability  retry_cost
              + escalation_probability  strong_model_cost
              + validation_cost
              + failure_probability * business_loss

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

Fallback — это часть бизнес-логики

Fallback запускается не только после 5xx. Причиной может стать Rate Limit, превышение latency budget, невалидный JSON или низкая уверенность. Но повтор нельзя выполнять после необратимого Tool Call без idempotency.

Gateway и router — не одно и то же

Gateway унифицирует транспорт, ключи и наблюдаемость. Router решает, куда отправить конкретный запрос. OpenRouter и OdiRouter могут дать готовый каталог моделей; LiteLLM или Portkey — слой управления над вашими provider accounts. Но правила задачи всё равно принадлежат продуктовой команде.

OdiRouter можно использовать как OpenAI-compatible gateway под собственным router: приложение выбирает Model ID, а единый endpoint сокращает число интеграций. Это удобная граница ответственности — если не переносить в gateway бизнес-логику, которую потом невозможно объяснить.

Как внедрять без риска

1. Соберите статистику текущей одной модели: качество, Token, latency, ошибки.

2. Выделите два самых массовых класса запросов.

3. Добавьте одну альтернативную модель и shadow traffic.

4. Сформулируйте quality floor и cost ceiling.

5. Включите route для 5% безопасного трафика.

6. Добавьте fallback только после тестов ошибок и идемпотентности.

7. Пересматривайте registry и Eval после обновления моделей.

Частые вопросы

Что такое AI model router API?

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

Чем LLM router отличается от API aggregator?

Агрегатор предоставляет доступ к моделям и единый биллинг. Router принимает решение о выборе модели. Они могут использоваться вместе.

Нужна ли отдельная модель-классификатор?

Не всегда. Небольшой набор правил надёжнее на старте. Классификатор полезен, когда классов и формулировок становится много.

Как измерить пользу router?

Сравните cost per successful task, p95 latency, completion rate, долю escalations и число инцидентов с базовой системой на одной модели.

Вывод

Зрелый AI model router не ищет одну идеальную модель. Он превращает выбор в управляемое решение: фиксирует ограничения, объясняет route, проверяет результат и безопасно обрабатывает сбой. Именно это снижает стоимость без скрытого ухудшения качества.