Стратегия Fallback для AI API: матрица отказов провайдеров

Retry AI API, переключение маршрута и замена модели — разные действия. Retry повторяет попытку в рамках того же контракта. Route Fallback отправляет запрошенную модель и протокол по другому допустимому пути. Model Substitution меняет модель, а вместе с ней может изменить качество, цену, задержку, работу Tools, Context Limits и формат вывода.

Надёжная политика определяет допустимые действия до инцидента. Решение зависит от Failure Class, стадии ответа, идемпотентности всей операции и числа попыток, которые ещё помещаются в пользовательский Deadline.

Разделяйте Retry, Fallback и Model Substitution

Используйте разные термины в конфигурации, логах и Runbook.

Действие	Что меняется	Подходящая задача	Главный риск
Same-route Retry	Время и Attempt Number	Восстановление после короткого временного сбоя того же маршрута	Дополнительная нагрузка на неисправную зависимость
Same-contract Fallback	Upstream Channel, Account или упорядоченная Group	Сохранение модели и протокола при отказе одного пути	Скрытая несовместимость формально равных маршрутов
Model Substitution	Model ID или именованная Model Policy	Одобренный продуктом компромисс качества, цены и доступности	Незаметное изменение поведения и Billing

Не называйте все три действия «retry». Операторы должны видеть, был ли Request повторён, перемещён на другой путь или обслужен другой моделью. Для пользователя замена модели должна быть явным Product Contract, а не скрытым способом восстановления.

Некоторые Gateway поддерживают последовательность Provider или Model Steps. Например, документация Cloudflare по Fallback показывает успешный Step. Важно не копировать конкретную Vendor Policy, а сохранять Attempt-level Evidence при каждом изменении маршрута.

Проверяйте четыре Gate перед повтором Request

Одного Status Code недостаточно для Retry Policy.

1. Failure Class: ошибка временная, постоянная, вызвана Caller или имеет неопределённый результат?
2. Response Phase: она произошла до Headers, до эффективного Output или после передачи результата?
3. Idempotency: можно ли повторить всю операцию без дублирования Side Effect?
4. Attempt Budget: остаётся ли достаточно Wall-clock Time и свободная попытка?

Retry Strategy Google Cloud использует те же базовые критерии для обычных API: Response показывает, может ли Retry помочь, а Idempotency — безопасен ли повтор. 408, 429, 5xx, Socket Timeout и Disconnect часто являются временными, но для неидемпотентных операций нужны более строгие условия.

В AI Workflow идемпотентность не заканчивается на HTTP Request к модели. Повтор Prompt может заново предложить письмо, возврат, Deploy или Database Write. Поэтому Tool Execution требует стабильного Idempotency Key и сохранённого результата, даже если Inference сама по себе Read-only.

Начинайте с Failure Matrix

Ниже приведена консервативная Application Policy. Gateway может выполнить внутренний Same-contract Channel Failover до выдачи терминального результата, поэтому слои должны быть согласованы.

Ошибка или стадия	Same-route Retry	Same-contract Fallback	Остановить или исследовать	Причина
Client Validation Error, Unsupported Field, Malformed Request	Нет	Нет	Исправить Request	Повтор того же неверного контракта не поможет
Gateway Authentication, Authorization, Quota, Policy Denial	Нет	Нет	Исправить Account или Policy	Другой Provider Route не должен обходить решение Gateway
Upstream Credential/Account Failure до Output	Не на неисправном пути	Да, при наличии проверенного Channel	Изолировать и исследовать Channel	Можно убрать неисправную Credential, сохранив контракт
Network Failure или 408 до Output	Не более одной ограниченной попытки при Idempotency	Да	Остановиться по Deadline	Сбой может быть временным, но после Disconnect итог неоднозначен
429 до Output	Отложенный Retry с учётом Retry-After	Да, если у равного пути есть Capacity	Остановиться при исчерпании Budget	Немедленные повторы усиливают Rate Limit
500, 502, 503, 504 до Output	Ограниченно с Backoff	Да	Исследовать повторяющиеся сбои	Обычно временно, но не доказывает безопасность всех маршрутов
Schema-invalid Provider Response до Downstream Output	Обычно нет	Только на Route, проверенный с тем же Schema	Изолировать или исследовать Compatibility	Повтор несовместимой реализации редко помогает
Model Refusal или Policy-safe Completion	Нет	Нет	Вернуть результат	Корректный Refusal не является сбоем инфраструктуры
Caller Cancellation или Downstream 499	Нет	Нет	Немедленно остановить	Caller больше не ожидает работу
Partial Stream после видимого текста или Tool Arguments	Без прозрачного Replay	Без прозрачного Fallback	Отметить Partial, решение принимает Application	Второй Stream может повторить или опровергнуть Output
Неизвестен итог Tool Side Effect	Нет до Reconciliation	Нет до Reconciliation	Проверить Idempotency Record или целевую систему	Re-inference может повторить тот же Side Effect

503 до любого Output и обрыв после 400 видимых Tokens — принципиально разные ситуации.

Считайте начало Stream границей Commit

До Downstream Output Gateway может отбросить неудачную попытку и выбрать другой путь, не показывая два ответа. После первого содержательного Byte прозрачный Replay становится небезопасным.

Перезапуск Stream может:

• повторить начало ответа;
• создать другое продолжение;
• выдать дублирующий Function Call с новым Call ID;
• изменить Usage и Cost без ясной границы;
• лишить Client возможности сопоставить Events и Attempts.

Если Stream оборвался после начала Output, верните Terminal Partial или Transport Error с исходным Request Identity. Application может предложить явный повтор, продолжение с безопасного Checkpoint или удаление Partial Output. Нельзя незаметно соединять новый Model Stream со старым.

Для Function Calling граница строже: до Retry сохраните принятые Tool Call Identities и Side-effect Results. Сравнение Function Calling объясняет связь Call IDs и Application Idempotency.

Ограничивайте Backoff числом попыток и временем

Exponential Backoff распределяет Attempts по времени, а Jitter не позволяет множеству клиентов повторять синхронно после общего сбоя.

delay_cap = min(max_delay, base_delay * 2^retry_index)
sleep_for = random_between(0, delay_cap)

Соблюдайте корректный Retry-After, если он помещается в Deadline. Backoff не даёт автоматического разрешения на Retry: сначала должны пройти Failure и Idempotency Gates.

Определите Total Budget, а не только Retry Count:

• максимум Attempts на одну User Action;
• максимум Elapsed Time с Queue и Backoff;
• предел Attempts до и после выбора Fallback Group;
• минимальное оставшееся время для полезного ответа;
• распространение Caller Cancellation на все Active Attempts.

Три попытки по 10 секунд не являются реальной политикой для интерактивного Request с Deadline 15 секунд. Batch Workload может иметь больший бюджет, но тоже требует Terminal Deadline и Durable Job Identity.

Не допускайте Retry Amplification между слоями

Если SDK выполняет три попытки, Gateway проверяет три Route на каждую, а Upstream Proxy делает по два Provider Call:

3 client attempts × 3 gateway attempts × 2 upstream attempts = 18 provider calls

Одна User Action превращается в 18 вызовов. Во время сбоя растут Queueing, Rate Limits, стоимость и Recovery Time.

Назначьте Retry Ownership:

• Gateway отвечает за немедленный Same-contract Channel Failover;
• Application решает, можно ли повторить User Action целиком;
• SDK Automatic Retries отключаются или ограничиваются, если повтор уже делает Gateway;
• Async Jobs используют один Durable Job ID и Attempt Ledger;
• после Caller Cancellation ни один слой не начинает новый Attempt.

Записывайте Attempt Number текущего слоя и стабильный End-to-end Request ID. Иначе каждый компонент покажет всего две-три попытки, скрывая суммарное усиление.

Докажите сохранение контракта при Fallback

Одинаковый публичный Model Name не означает одинаковое поведение Route. Перед включением Channel в прозрачный Fallback Set проверьте:

Область контракта	Необходимое доказательство
Model Identity	Requested Model доступна без Silent Mapping
Endpoint	Настроенный Responses или Chat Completions Request принимается
Streaming	Event Types, Termination, Usage и Cancellation работают
Structured Output	Требуемое подмножество JSON Schema и Strict Behavior работают
Function Calling	Tools, Call IDs, Argument Streaming и Results выполняют Round-trip
Limits	Context, Output, Rate и Concurrency соответствуют Workload
Errors	Status и Error Bodies классифицируются без раскрытия Secrets
Usage and Cost	Tokens, Cache Fields, Service Tier и Price Policy понятны
Safety and Region	Policy, Data Path и Residency остаются допустимыми

Если Route не проходит обязательную проверку, она не является прозрачным Fallback для этого Workload. Её можно использовать только в отдельной явной Product Policy.

Смена модели всегда является продуктовым решением. Определите разрешённую Model, Quality Floor, Price Ceiling, Tool Contract и User-visible Disclosure. Ошибка Route не оправдывает тихий переход на более дешёвую или слабую модель.

Понимайте текущую семантику Modelflare

Modelflare ищет допустимые пути для модели, которую запросил API Client. Обычный API Key имеет Primary Group и может иметь упорядоченные Fallback Groups. Smart API Key оценивает доступные Groups согласно Routing Strategy. Оба механизма не должны незаметно менять Requested Model.

Group-level RPM Admission выполняется до Billing и Upstream Request. Если выбранная Group заполнена, проверяется упорядоченная Fallback Group или Smart Routing Candidate; при отсутствии допустимых Groups возвращается 429.

Внутри Group порядок Account Failover задаёт Channel Priority. После Upstream Error неисправный Channel исключается, а выбор продолжается. Текущий Channel Failover не зависит от RetryTimes и AutomaticRetryStatusCodes; он прекращается при успехе, исчерпании Route, Caller Cancellation или после начала Downstream Output.

Это внутренние Same-model Path Decisions, а не разрешение на безграничный Client Retry Loop. Для Group и Channel Design используйте Reliable AI API Routing, а для разделения Gateway Policy Error и Upstream Failure — AI API Error Troubleshooting.

Сохраняйте Evidence каждой попытки

Финальный 200 не доказывает успех первого Route. Финальный Channel ID не описывает неудачные Attempts. Сохраняйте как минимум:

• стабильный Request ID и Caller-visible Correlation ID;
• Attempt Sequence и Group/Channel Reference;
• Model и Endpoint Contract каждой попытки;
• Failure Status, Error Class и Stream Phase;
• факт начала Downstream Output;
• Timing Milestones и Cancellation State;
• доступные Input, Output и Cached-token Usage;
• Cost Attribution для завершённых или Billable Attempts;
• Terminal Reason: Success, Exhausted, Cancelled, Partial или Policy Stop.

Не храните API Keys, Raw Prompts, Raw Responses или Provider Credentials только ради Fallback-диагностики. Обычно достаточно очищенных Error Classes и Timing Metadata; Request Archives должны быть ограниченными, краткосрочными и включаться явно.

Проверьте политику до Production Traffic

Используйте реальную Protocol Boundary и безопасные детерминированные Inputs:

1. отключите Primary Channel до Headers и проверьте следующий Same-model Path;
2. верните Rate Limit и проверьте Attempt Limits и Retry-After;
3. отмените Caller и докажите, что новый Attempt не начинается;
4. оборвите Stream после Output и исключите прозрачный Replay;
5. отправьте Invalid Request и убедитесь, что Fallback её не скрывает;
6. повторите Tool Workflow и подтвердите один Side Effect;
7. исчерпайте все Route и получите один ясный Terminal Error;
8. проверьте Attempt Ledger и согласуйте Usage и Cost.

Сначала включите политику для небольшого Workload. Отдельно наблюдайте Attempt Count, Success-after-fallback и Raw Success Rate и сохраняйте быстрый способ удалить неисправный Route. Цель — не максимальное число Fallback, а безопасное восстановление в ограниченный Deadline при неизменном контракте модели и полной доказательной цепочке.