Маршрутизация между провайдерами ИИ

Зачем шлюз

Помимо устойчивости есть второй мотив, важный не везде одинаково: вы выбираете, где происходит инференс. Через шлюз подключается любой OpenAI-совместимый эндпоинт, включая локальные и self-hosted модели, — значит стек может работать без обязательных внешних SaaS.

Ставить весь конвейер разработки на одного провайдера — стратегический риск:

• Простои блокируют вашу работу. Когда API лежит, ваши агенты стоят.
• Исчезает переговорная позиция по цене. Нет альтернативы — нет рычага.
• Улучшения моделей проходят мимо. Прорывы случаются в разных лабораториях, а не в одной.
• Разным задачам нужны разные модели. PM-агенту, разбирающему абзац, не нужна та же модель, что пишет вашу авторизацию.

AI Gateway в Forge стоит между каждым ходом агента и провайдером под ним. Внутри он говорит на едином формате запроса и ответа, а в сеть переводит под каждого провайдера.

Как работает маршрутизация

У каждой организации есть список провайдеров с двумя ручками:

• Приоритет (задаёте вы) — целое от 1 до 1000. Меньше значит выше. По умолчанию 100.
• Вес (ведёт система) — дробное от 0.1 до 1.0. Единица означает полностью здоров. Падает на ошибках, восстанавливается после паузы.

Когда приходит ход, шлюз вызывает GetOrderedProviders(orgId), который сортирует по (приоритет ASC, вес DESC). Дальше он идёт по списку:

1
2
3
4

1. Пробуем провайдера с наивысшим фактическим рангом
2. При ошибке → RecordError(decayFactor)  // вес *= (1 - decayFactor)
3. Пробуем следующего
4. При успехе → RecordSuccess()           // вносит вклад в восстановление веса

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

Статистика доступности

У каждого провайдера есть скользящее окно статистики:

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

Закрепление

Два вида:

Закрепление на сессию — у сессии есть необязательный providerPin (идентификатор или метка провайдера). Воркер использует его при отправке. Полезно, когда нужно, чтобы все ходы одного прогона конвейера обслуживала одна модель ради согласованности.

Закрепление на воркер — пул воркеров может объявить требования по меткам (например, provider=anthropic-us). Ходы с подходящими метками уходят в этот пул. Полезно для комплаенса («персональные данные должны оставаться на инференсе в регионе США») или для канареечных выкаток.

Управление стоимостью

У разных агентов разные потребности, и Forge позволяет записи агента нести предпочтительного провайдера по умолчанию. Несколько частых схем:

• PM-агент → быстрая дешёвая модель для разбора требований.
• Архитектор → самая сильная доступная модель.
• Разработчик → самая сильная доступная; здесь основная тяжесть.
• QA и ревьюер → сбалансированная модель, хорошо работающая со структурированным выводом.

Это выражается либо закреплением на уровне агента (в записи агента), либо правилами маршрутизации в списке провайдеров организации.

Что вы получаете

Всё перечисленное уже работает в продакшене.

• Метки очереди и провайдеров для канареечной маршрутизации
• Слой перевода под провайдера — метка в сетевой формат
• Закрепление провайдера на уровне агента
• Интерфейс списка провайдеров организации и выбор провайдера на сессию
• JWT на задание с полем provider_id

Полный список провайдеров редактируется в настройках организации в интерфейсе. Закрепление на сессию — выпадающий список на странице сессии. В CLI умолчания задаются через forge config set provider <provider-id>.

Архитектура

CLI

1
2

forge config set provider anthropic-us-east-1   # умолчание для новых сессий
forge cloud-continue <sid> --provider openai-gpt-4o

Интерфейс

• Настройки организации → Провайдеры: добавить, удалить, переупорядочить, отметить запасного.
• Страница сессии → Выбор провайдера: переопределить умолчание организации для одной сессии.
• Список сессий → Фильтр по провайдеру: посмотреть, чем занимался каждый провайдер.
• Вход процесса GitHub Actions: параметр provider_id для разовой отправки.

Попробовать

Если вы уже пользуетесь Forge, зайдите в настройки организации и добавьте второго провайдера. Поставьте ему приоритет 200 (ниже, чем 100 по умолчанию). Forge будет направлять весь трафик основному, пока что-нибудь не сломается; затем плавно переключится на запасного и вернёт вес основному, когда тот стабилизируется. Вы не увидите ни одной ошибки агента.