В инструкции AI API SLA объясняется, как поставщик услуг измеряет доступность и какие меры могут быть приняты, если результат окажется ниже согласованного целевого показателя. Само по себе оно не обеспечивает непрерывную работу приложения. Прежде чем выводить ИИ-нагрузку в промышленную эксплуатацию, изучите период измерения, охват услуги, исключения, требования к инцидентам и средства правовой защиты как единый набор условий.
В этом руководстве рассматриваются вопросы, которые стоит задать, и средства контроля, которые по-прежнему необходимы вашему приложению. Оно также связывает эти вопросы с документацией OdiRouter по маршрутизации, обработке ошибок, устранению неполадок и поддержке, не рассматривая публичные формулировки о продукте как договорное обещание.
Что должно определять API SLA для ИИ
Начните с измеряемой услуги. «Доступность API» может означать общий шлюз, отдельный конечный узел, маршрут к модели, регион или всю платформу. Это разные вещи. Шлюз может принять запрос, пока вышестоящая модель недоступна. Исправная модель всё равно может быть недоступна из-за учётных данных, разрешений или баланса аккаунта.
Ищите в применимом соглашении следующие сведения:
период измерения, например календарный месяц;
формулу доступности и систему, предоставляющую измерения;
продолжительность сбоя, после которой он считается простоем;
учитываются ли частичная деградация, высокая задержка или неудачные потоковые запросы;
тарифные планы, регионы, конечные узлы и аккаунты, которые соответствуют условиям;
исключения для технического обслуживания, вышестоящих поставщиков, сетей, конфигурации клиента и форс-мажора;
средство правовой защиты, срок подачи претензии, доказательства и предельный размер компенсации.
Заявленный процент мало говорит о риске, если эти правила отсутствуют.
Рассчитайте допустимое время простоя
Месячная доступность обычно выражается следующей формулой:
Monthly availability =
(total minutes in the measurement period - counted downtime minutes)
/ total minutes in the measurement period x 100Для месяца продолжительностью 30 дней расчёт даёт следующие примеры допустимого времени простоя:
Целевой уровень доступности | Максимальное учитываемое время простоя |
|---|---|
99% | 432 minutes |
99.9% | 43.2 minutes |
99.95% | 21.6 minutes |
99.99% | 4.32 minutes |
Это математические примеры, а не обязательства OdiRouter. Соглашение определяет, какие инциденты учитываются, когда начинается отсчёт и объединяются ли несколько коротких инцидентов. Правило, учитывающее только сбои продолжительностью пять последовательных минут, может дать иной результат, чем правило, основанное на проценте неуспешных запросов.
Доступны отдельные шлюзы, маршруты и приложения.
Запрос к ИИ может проходить через четыре операционных уровня:
Ваше приложение, сеть, учетные данные и состояние учетной записи.
Агрегационный шлюз и его публичная конечная точка.
Выбранный маршрут модели и решение о маршрутизации.
Поставщик модели для анализа исходного сырья и его региональная инфраструктура.
SLA может охватывать только один из этих уровней. Перед тем как предполагать, что обязательство по шлюзу также распространяется на сбой в работе вышестоящей модели, проверьте список исключений.
На общедоступной домашней странице OdiRouter указано, что запросы могут маршрутизироваться в зависимости от цены, задержки и доступности. Это может помочь команде выбирать маршруты и адаптироваться к изменениям условий у поставщика услуг. Команда всё равно должна подтвердить, какие условия договора применяются к её учётной записи, тарифному плану и рабочей нагрузке.
Ознакомьтесь с исключениями, а не только с целевым показателем времени безотказной работы.
Исключения определяют, какие инциденты не входят в расчёт доступности. К распространённым примерам относятся плановое техническое обслуживание, сбои вышестоящих поставщиков, сторонние сети, недействительные запросы, просроченные ключи, недостаточный баланс, неавторизованные модели, меры по пресечению злоупотреблений и события, находящиеся вне разумного контроля поставщика.
Некоторые исключённые сбои можно предотвратить на стороне клиента. В руководстве по устранению неполадок OdiRouter разработчикам рекомендуется проверить Base URL, ключ API, текущий model ID и загруженную конфигурацию. В его документации по ошибкам различаются состояния, допускающие повторную попытку, и ошибки конфигурации:
Ответ
429можно повторить с использованиемRetry-Afterили экспоненциальной задержки.Отдельные ответы
502,503и504могут обосновывать ограниченную повторную попытку и фиксацию инцидента.Ответ
401,403или связанный с маршрутом404обычно требует исправления учетных данных, баланса, разрешений, модели или пути до отправки следующего запроса.
Ограничивайте количество повторных попыток. Бесконечный цикл может увеличить задержку, повторить тарифицируемую работу и скрыть первую ошибку.
Разберитесь в порядке возмещения и подачи претензии
Возмещение часто предоставляется в виде сервисного кредита, а не компенсации упущенной выручки. Проверьте, как рассчитывается кредит, ограничен ли его размер, какие комиссии учитываются и должен ли клиент подавать претензию. Также выясните крайний срок подачи. Подробная запись об инциденте не поможет, если претензия поступит после окончания предусмотренного договором срока.
Храните достаточно доказательств, чтобы восстановить ход события:
временные метки начала и окончания с указанием часового пояса;
метод и URL HTTP;
model ID и конечная точка;
статус и код ошибки HTTP;
X-Request-Idили другой идентификатор запроса поставщика;очищенный от конфиденциальных данных контекст запроса;
количество повторных попыток и результат;
ожидаемое и фактическое поведение приложения.
В документации службы поддержки OdiRouter запрашиваются сведения такого рода. Там также говорится, что клиентам не следует отправлять ключи API, пароли, платежные данные или иную конфиденциальную информацию. Не допускайте попадания секретов в операционные журналы.
Обеспечивайте надежность не только за счет SLA
Сервисный кредит не может восстановить неудавшийся пользовательский запрос. Производственным системам по-прежнему необходимы тайм-ауты, ограниченное количество повторных попыток, наблюдаемость и политика резервного копирования, которая была протестирована до возникновения инцидента.
Для каждой рабочей нагрузки установите свой собственный тайм-аут.
Выберите время ожидания, заданное в пользовательском интерфейсе и в зависимости от крайнего срока выполнения задания, а не из стандартного значения по умолчанию. Интерактивный помощник имеет иной лимит задержки по сравнению с фоновой обработкой мультимедиа. Регистрируйте сбои по тайм-ауту отдельно от ошибок поставщика, чтобы команда знала, где было применено ограничение.
Повторяйте попытку только тогда, когда операция безопасна
Ограничения на количество повторных попыток и временные ошибки сервера с ограниченной задержкой. Соблюдайте Retry-After, если он указан. Для платных операций или операций, изменяющих состояние, используйте стратегию идемпотентности или проверяйте первый результат перед повторным запросом.
Проверяйте резервные маршруты на реальных запросах.
Резервная модель поможет только в том случае, если она поддерживает нужные приложению конечную точку, модальности, контекст, инструменты, структурированный вывод, задержку и качество. Используйте OdiRouter model catalog и текущий список моделей вместо копирования устаревшего model ID. Сравните цены на OdiRouter pricing page, затем выполните типичные запросы перед запуском в продакшен.
Обеспечьте возможность поиска по данным об инцидентах
При необходимости фиксируйте время, маршрут, model ID, статус HTTP и X-Request-Id. Не записывайте в журналы секреты или конфиденциальное содержимое запросов. Единообразные записи помогают при внутренней диагностике и обращениях в службу поддержки.
Оцените OdiRouter для производственной нагрузки
Начните с OdiRouter documentation introduction. Подтвердите текущий маршрут, Base URL, метод аутентификации и поведение конечной точки. Перед реализацией повторных попыток ознакомьтесь с LLM error-handling guide и integration troubleshooting guide.
Публичные страницы OdiRouter, изученные для этого руководства, описывают один API, маршрутизацию по цене, задержке и доступности, интеграцию, ориентированную на продакшен, обработку ошибок и поддержку. Они не публикуют отдельный универсальный целевой показатель доступности, определение простоя, срок подачи претензии или таблицу сервисных кредитов. Свяжитесь с OdiRouter support, чтобы подтвердить условия, применимые к вашей учётной записи или соглашению.
Контрольный список API SLA для ИИ перед запуском в продакшен
Какие сервис, маршрут, конечную точку, регион, тарифный план и учётную запись охватывает соглашение?
Какая система измерения и какой период времени определяют результат?
Когда инцидент начинает и прекращает учитываться?
Учитываются ли задержка, частичная деградация, сбои потоковой передачи и кратковременные простои?
Какие события, связанные с вышестоящими поставщиками, сетью, обслуживанием, учётной записью и форс-мажором, исключаются?
Какой кредит применяется на каждом уровне доступности и каков его максимальный размер?
Каков срок подачи претензии и какие доказательства требуются?
Где поставщик сообщает об инцидентах?
Какие ошибки клиенту следует повторять, а какие требуют изменения конфигурации?
Прошёл ли каждый резервный маршрут реалистичные тесты качества, функций, задержки и стоимости?
API SLA для ИИ — лишь одна из частей решения для продакшена. Дополните его тестами рабочей нагрузки и планом на случай сбоев. Чтобы оценить текущие маршруты, откройте OdiRouter model catalog или создайте учётную запись OdiRouter и протестируйте запросы, которые ваше приложение действительно будет отправлять.