Слой маршрутизации LLM API

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

Что обычно даёт слой маршрутизации:

• Абстракция над провайдерами - один и тот же эндпоинт независимо от того, какой провайдер обслуживает запрос
• Цепочки fallback - если основной провайдер падает (5xx, аномалии с задержкой, rate limit) -> вторичный подхватывает запрос без логики на стороне приложения
• Правила маршрутизации - выбор модели на основе характеристик запроса (число токенов, эвристики сложности, уровень пользователя, лимит стоимости)
• Единый биллинг - один общий счёт по всем провайдерам
• Наблюдаемость - единые логи и метрики по всем провайдерам
• Дополнительные возможности - кэширование промптов, семантическая дедупликация, кэширование ответов, повторное использование KV

Компромиссы:

• Дополнительный сетевой узел (накладные расходы по задержке, единая точка отказа)
• Доверие маршрутизатору: ему передаются промпты и ответы (важна политика конфиденциальности)
• Модель ценообразования: большинство берёт наценку; некоторые (например, routing.run) берут плату за запрос, а не за токен, что кардинально меняет расчёты при больших размерах контекста

Заметные примеры:

• OpenRouter - доминирующий агрегатор; наценка за миллион токенов; поддерживает почти любую публичную модель
• Chutes - схожая модель
• routing.run - оплата за запрос, заявляет об отказе от логирования, инфраструктура маршрутизации с открытым исходным кодом
• Pi (lucumr-blog) - встраивает выбор провайдера внутрь агента для написания кода, а не выносит в отдельный шлюз
• Self-hosted (LiteLLM, Helicone, Portkey) - маршрутизация в виде библиотеки или middleware, запускаемых на своих серверах

Смежное: структурно это похоже на alternative-frontend-pattern для потребления сервисов - сторонний интерфейс или прокси, улучшающий базовый API-контракт, но с более сильной привязкой (lock-in), поскольку слой маршрутизации берёт на себя не только маршрутизацию, но и биллинг.

Главный долгосрочный риск этого паттерна в том, что он зависит от нейтральности провайдеров. Если какой-то провайдер начнёт требовать прямую интеграцию для продвинутых возможностей (увеличенный контекст, специфичные форматы tool use, fine-tuning), маршрутизаторы отстанут, если не договорятся об особом доступе.

Связанные страницы: routing-run, lucumr-blog.