Обновлено 03.08.2026

Резервная маршрутизация ИИ-запросов: что она решает

Как отличать сбой приложения, API-шлюза и upstream-модели и правильно повторять временные запросы.

Где может возникнуть сбой

Запрос проходит несколько участков: клиент, интернет-соединение, API Router, маршрут поставщика и инфраструктуру самой модели. Ошибка или задержка на любом участке может выглядеть для приложения как 5xx или timeout.

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

Единый маршрут

Для каждой модели действует один маршрут PAYG. Страница статуса показывает результат его последней автоматической проверки.

Правильный retry

  • Повторяйте только временные 429, 502, 503, 504 и сетевые ошибки.
  • Используйте экспоненциальную задержку, jitter и ограничение числа попыток.
  • Не повторяйте автоматически 400, 401 или 402 без исправления причины.
  • Для операций с побочными эффектами используйте собственный idempotency key.
  • Задавайте timeout с запасом для reasoning-моделей и длинных генераций.

Наблюдаемость

Храните request ID, HTTP-статус, время ответа и ID модели, но никогда не записывайте полный API-ключ. Сопоставляйте клиентский request ID с записью в истории кабинета. Это помогает понять, где возникла проблема, не раскрывая содержимое пользовательского запроса.

Готовы попробовать?

Создайте ключ в личном кабинете и отправьте первый запрос.

Создать аккаунт