Один ИИ-провайдер — единая точка отказа: как подготовить резервный маршрут

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

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

Соберите минимальный контур

Клиентское приложение не должно знать адреса, ключи и форматы нескольких поставщиков. Оно вызывает один внутренний метод — например, «сгенерировать текст» или «извлечь поля», — а серверный маршрутизатор выбирает адаптер и приводит запрос к формату конкретного API.

Рекомендации Microsoft по архитектуре ИИ-нагрузок предусматривают единый интерфейс для моделей, серверную обработку переключений и собственные тайм-ауты, квоты и ограничения на уровне шлюза вместо расчёта только на встроенные повторы клиентской библиотеки.

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

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

Свяжите классы ошибок с действиями

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

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

Состояние маршрута следует менять не после единичной ошибки, а по серии сбоев или доле неудач в коротком окне. Открытый предохранитель блокирует обычные вызовы к проблемному поставщику, но периодически пропускает пробный запрос. Порог зависит от объёма и характера трафика: единое значение для малонагруженного продукта может вызывать случайные переключения.

Ограничьте повторы общим сроком

У каждой попытки должен быть собственный тайм-аут, а у всей последовательности — общий предельный срок. Если почти всё доступное время потратить на основной маршрут, запасной поставщик не успеет ответить. Для интерактивных запросов оставляйте резерв времени на переключение; для фоновых допускайте более длинную последовательность, которая заканчивается постановкой задачи в очередь ошибок.

Руководство Microsoft по временным сбоям относит ответы HTTP 429 и ошибки серверной группы к возможным кандидатам на повтор, рекомендует учитывать переданный сервером срок ожидания, добавлять случайное отклонение к возрастающей задержке и ограничивать число попыток. Большинство ошибок запроса повтор не исправляет, а каскадные попытки на нескольких уровнях способны умножить нагрузку.

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

Проверьте совместимость запасной модели

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

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

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

Не превратите шлюз в новую точку отказа

Резервирование поставщиков не поможет, если маршрутизатор существует в одном экземпляре. Для контура с требованиями к доступности нужны как минимум два экземпляра за балансировщиком, конфигурация вне памяти процесса и заранее определённое безопасное поведение при недоступности её хранилища.

Эталонная архитектура многостороннего шлюза AWS предоставляет общий интерфейс к собственным сервисам и внешним поставщикам, распределяет запросы между экземплярами шлюза через балансировщик и хранит учётные данные отдельно от приложения. Маленькой команде необязательно воспроизводить весь набор компонентов, но разделение маршрутизации, состояния и секретов остаётся полезным.

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

Испытайте переключение до настоящего сбоя

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

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

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

Читайте также:

• Массовая проверка частотности: почему один CSV даёт несопоставимые цифры
• 40 курсов или один маршрут: как выбрать обучение HTML и CSS
• Историю домена не покажет один WHOIS: бесплатная проверка перед покупкой