LLM-шлюз: маршрутизация, фолбэки и лимиты между провайдерами

Что такое шлюз и зачем он нужен

LLM-шлюз — тонкий сервис между вашими приложениями и провайдерами моделей. Вместо того чтобы каждый сервис напрямую обращался к OpenAI, Anthropic или Google, все вызывают один внутренний эндпоинт с названием задачи. Шлюз решает, какую модель использовать, повторяет запрос или меняет провайдера при ошибке, проверяет лимиты и записывает, что произошло.

Он нужен, как только у вас больше одной ИИ-функции или больше одного провайдера. Без него API-ключи расползаются по репозиториям, каждая команда пишет свои ретраи, и никто не может ответить, сколько стоила функция X на прошлой неделе.

Основные задачи

Маршрутизация по задаче, а не по имени модели

Приложение должно запрашивать профиль задачи, а не конкретную модель. Соответствие задается в конфигурации:

routes:
  classify-ticket:
    primary: small-fast-model
    fallback: [other-provider-small]
    max_output_tokens: 50
  draft-reply:
    primary: large-model
    fallback: [other-provider-large, small-fast-model]
    timeout_ms: 20000
  contract-analysis:
    primary: self-hosted-model
    fallback: []          # чувствительные данные, не покидают наши серверы

Так функцию можно перевести на более дешевую или новую модель без релиза приложения. Полезные сигналы для маршрутизации:

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

Фолбэки, которые не делают хуже

Не каждая ошибка заслуживает повтора. Разделяйте их:

• Повтор у того же провайдера с экспоненциальной задержкой и jitter: таймауты, 429, ошибки 5xx.
• Смена провайдера: повторяющиеся сбои или провайдер помечен как нездоровый.
• Без повтора: ошибки валидации 400, отказы по контент-политике, превышение контекста. Исправляйте запрос.

Добавьте circuit breaker: после нескольких ошибок за короткое время прекратите слать трафик провайдеру на какое-то время и периодически проверяйте его. Так медленная авария не съест все ваши таймауты.

Две оговорки:

• промпты, настроенные под одну модель, могут вести себя иначе на другой, поэтому проверяйте каждый фолбэк на своем eval-наборе;
• при стриминге переключаться безопасно только до того, как первый токен ушел пользователю.

Лимиты и бюджеты

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

• Rate limits: запросы и токены в минуту на пользователя, token bucket в Redis или аналоге.
• Бюджеты: расход за день или месяц на пользователя, команду и функцию. Оценивайте стоимость до вызова по входным токенам и лимиту вывода, после — записывайте фактическую.
• Мягкий и жесткий лимит: на мягком переводите на дешевую модель, на жестком отказывайте с понятным сообщением.
• Ограничение вывода: всегда задавайте максимальную длину ответа для маршрута.

Ключи и логирование

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

Для каждого запроса логируйте: маршрут, модель, провайдера, ID пользователя и функции, входные и выходные токены, стоимость, задержку, статус и путь фолбэков. Тексты промптов и ответов храните только там, где это разрешено политикой, с маскированием персональных данных и коротким сроком хранения.

Писать свой или взять готовый

Open-source и облачные шлюзы уже умеют единый API, фолбэки и учет стоимости. Берите готовый, если он подходит; пишите свой тонкий слой, если нужны особые правила маршрутизации, строгая локализация данных или глубокая интеграция с биллингом. В обоих случаях храните конфигурацию маршрутов в системе контроля версий.

Частые ошибки

• Имена моделей зашиты в коде приложений.
• Повтор неповторяемых ошибок, который умножает расходы.
• Резервные модели ни разу не проверены на ваших промптах.
• Полные промпты с персданными хранятся бессрочно.
• Нет лимитов на пользователя, и один клиент блокирует всех.