SLA для LLM-шлюза должен измерять весь путь запроса

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

Поэтому процент доступности сам по себе почти бесполезен. Закупочная команда должна сравнивать формулу доступности, порог задержки, качество ответа, RTO, время реакции поддержки, правила внешних зависимостей и последствия нарушения. Я видел договоры с красивыми 99,95%, по которым поставщик мог исключить почти любой реальный сбой. Такой процент ничего не обещает.

Доступность считают за календарный месяц и по успешным запросам

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

Базовая формула должна стоять прямо в приложении к договору:

Availability = (Eligible Requests - Failed Requests) / Eligible Requests * 100%

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

RFC 9110 разделяет классы HTTP-статусов и относит 5xx к ошибкам сервера. Это полезная отправная точка, но для LLM ее недостаточно: транспортный успех не гарантирует пригодный результат. В договоре нужно отдельно описать потоковые ответы, потому что первый токен и полное завершение имеют разные моменты успеха. Для обычного ответа успех фиксируют после получения всего корректного тела. Для потока можно считать доступность по успешному началу, но обрыв до завершающего события должен попадать в отдельную метрику завершения потока.

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

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

Для ориентира, 99,9% за 30-дневный месяц допускает около 43 минут 12 секунд недоступности, 99,95% - около 21 минуты 36 секунд, 99,99% - около 4 минут 19 секунд. Эти числа имеют смысл только при поминутном измерении. При расчете по запросам фактический допустимый ущерб зависит от трафика, поэтому договор должен показывать и долю отказов, и эквивалентную длительность непрерывных инцидентов.

p95 задают для первого токена и полного ответа отдельно

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

Для потоковой генерации банк обычно должен видеть как минимум две метрики:

• time to first token, от приема полного запроса шлюзом до первого содержательного фрагмента;
• time to last token, от приема запроса до корректного завершения потока;
• долю запросов, превысивших жесткий тайм-аут;
• p99 для обнаружения тяжелого хвоста, даже если обязательство привязано к p95.

Для непотоковых вызовов измеряют полную длительность. Метрики группируют по согласованным корзинам, например до 2 000 входных токенов и до 500 выходных, а не смешивают все запросы. Иначе большое число коротких запросов скроет задержки длинных операций. Не стоит требовать одинаковый порог от каждой модели: быстрому классификатору и крупной reasoning-модели нужны разные профили.

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

Пример проверяемого условия выглядит так:

Для запросов класса Interactive с входом <= 2 000 токенов и лимитом
выхода <= 500 токенов не менее 95% подходящих потоковых запросов
за каждые 15 минут получают первый содержательный токен за <= 1,8 с.
Запросы, завершившиеся 5xx или тайм-аутом, включаются в выборку
с длительностью, равной порогу тайм-аута.

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

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

Качество маршрутизации входит в успех запроса

LLM-шлюз может вернуть ответ быстро и технически корректно, но нарушить обязательство по маршруту: выбрать запрещенного поставщика, выйти за пределы страны, подставить несовместимую модель или потерять параметры запроса. Для банка это не «деградация функции», а неуспешная операция.

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

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

Проверка на приемке может выглядеть как воспроизводимая последовательность:

1. Банк создает профиль, разрешающий две модели в одной допустимой географии.
2. Команда выводит основной маршрут из тестового пула согласованным способом.
3. Шлюз переводит запросы на разрешенный резерв и записывает причину переключения.
4. Команда блокирует оба маршрута и получает явный отказ, а не скрытый выход к третьему поставщику.
5. Банк сопоставляет идентификаторы запросов с журналом маршрутизации и клиентскими замерами.

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

RTO начинается с подтвержденного инцидента, а RPO нужен не всегда

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

Точку старта фиксируют однозначно: первый из моментов, когда мониторинг поставщика обнаружил нарушение или банк передал достаточные доказательства через аварийный канал. Требование ждать, пока поставщик сам «признает» инцидент, дает ему возможность двигать начало отсчета. Точка окончания - устойчивое восстановление метрики на протяжении контрольного окна, например 15 минут, а не одиночный успешный запрос.

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

RPO отвечает на другой вопрос: какой объем состояния допустимо потерять после восстановления. Для безсостоящего проксирования RPO может быть неприменим. Но у шлюза могут быть конфигурации маршрутов, ключевые политики, лимиты, журналы аудита и данные о потреблении. Для каждого вида состояния нужно написать либо конкретный RPO, либо «неприменимо» с причиной. Общее обещание RPO=0 без описания состояния выглядит сильно, но его невозможно проверить.

План восстановления должен пройти испытание до подписания и затем проверяться с согласованной периодичностью. Банку нужны дата, сценарий, фактические времена обнаружения и восстановления, отклонения и закрытые действия. Отчет «тест пройден» без временной шкалы не доказывает соблюдение RTO.

Поддержка обязуется реагировать, обновлять и привлекать инженеров

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

Уровни критичности описывают через наблюдаемый эффект, а не через мнение поставщика. P1 может означать полную недоступность продуктивного API, массовые ошибки, подтвержденное нарушение маршрутизации или невозможность выполнить срочное защитное действие. P2 - заметную деградацию без полного отказа, когда существует приемлемый обходной путь. Если поставщик вправе единолично понизить приоритет, он может формально выполнить SLA, сменив ярлык. Понижение допускают только с письменным обоснованием и доказательством работающего обхода.

Для каждого уровня таблица должна содержать:

• режим покрытия, например 24x7 для P1 и рабочие часы для P3;
• канал обращения и резервный канал при недоступности портала;
• время подтверждения и время подключения технического специалиста;
• интервал содержательных обновлений;
• срок предварительного и окончательного разбора причины.

«Содержательное обновление» означает новые факты: текущий эффект, принятые меры, результат проверки, следующий контрольный момент и изменившийся прогноз. Автоматическое письмо «мы работаем» не останавливает таймер. Для P1 банк должен иметь телефонный или иной синхронный аварийный канал, потому что заявка внутри упавшей панели поддержки бесполезна.

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

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

Внешний поставщик не должен превращаться в универсальное исключение

Шлюз продает управление несколькими маршрутами, поэтому отказ внешней модели нельзя автоматически вычитать из SLA. Именно при таком отказе проявляется смысл шлюза: обнаружить проблему, выбрать разрешенную альтернативу или честно вернуть контролируемый отказ. Полное исключение внешних поставщиков оставляет банку SLA только на тонкий слой прокси, хотя он покупает результат всей цепочки.

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

Исключение можно принять лишь при одновременном выполнении условий:

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

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

Отдельно согласуют режим pinning, когда банк сам требует только одну модель или одного провайдера. В этом случае внешнюю недоступность допустимо вынести в отдельный показатель, если шлюз доказал исправность своего слоя. Закупке полезно сравнивать две цифры: end-to-end доступность управляемого пула и доступность самого шлюза при принудительно закрепленном маршруте. Первая показывает полученный сервис, вторая помогает установить причину.

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

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

Доказательство внешней причины не сводится к снимку публичной страницы статуса. Такая страница подтверждает лишь заявление третьей стороны и часто округляет время. Нужны собственные отметки обнаружения, категории ответов, перечень затронутых разрешенных маршрутов и действия автоматики. Банк может принять агрегированные данные, но интервал и причинная связь должны проверяться.

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

Сервисные кредиты должны расти быстрее тяжести нарушения

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

Лестницу считают от месячной платы за затронутый сервис, а не от маленькой строки «плата за поддержку». Например, нарушение ниже договорного порога, но не ниже 99,90%, может давать кредит 5% от платы за затронутый сервис. Уровень от 99,50% до 99,90% может давать 10%, от 99,00% до 99,50% - 20%, а результат ниже 99,00% - 30%. Границы должны исключать пересечения, чтобы значение ровно на пороге не вызывало спор.

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

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

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

Валютная и расчетная часть тоже влияет на исполнимость. Договор указывает, в каком счете появится кредит, можно ли зачесть его против следующего платежа и что произойдет при расторжении до такого счета. Формулировка «кредит предоставляется по усмотрению поставщика» отменяет автоматическое последствие, поэтому ее следует убрать.

Нарушения p95, RTO и поддержки нельзя растворять в доступности. Для них нужны отдельные кредиты или баллы нарушения с понятной конвертацией. Если API был доступен 99,99% времени, но каждый вечер отвечал слишком медленно для клиентского процесса, поставщик не выполнил обещание качества. Совокупный предел кредитов можно установить, но он не должен обнулять последствия нескольких независимых нарушений.

Автоматическое начисление лучше процедуры «подайте требование за пять рабочих дней». У поставщика уже есть телеметрия, и он должен приложить расчет к месячному отчету. Банк сохраняет право оспорить цифры по своим измерениям. Если договор все же требует заявку, срок должен быть разумным и начинаться после получения полного отчета, а не после скрытого момента сбоя.

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

Отчет должен позволять пересчитать каждую цифру

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

Минимальная строка агрегата может иметь такой вид:

{"period":"2026-06","route_profile":"retail-assistant-prod","eligible":1842231,"failed":1320,"ttft_p95_ms":1420,"timeout_count":284,"excluded":91,"exclusion_reason":"bank-approved-maintenance"}

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

Часы обеих сторон синхронизируют, формат времени и допустимое расхождение фиксируют. Банк хранит собственные синтетические проверки и метрики приложения. Синтетика ловит полный отказ при низком реальном трафике, а реальные запросы показывают эффект на типичной нагрузке. Ни один источник не следует объявлять единственно истинным.

При споре стороны сначала сверяют определение подходящего запроса, временные окна и идентификаторы, затем сравнивают сырые события. Формулировка «данные поставщика окончательны» делает независимый контроль декоративным. Лучше назначить срок сверки, формат выгрузки и порядок привлечения независимого эксперта для редких неразрешимых споров.

Хранить нужно не бесконечно, а достаточно для банковского контроля, расследований и договорного срока предъявления требований. Конкретный срок выбирают вместе специалисты по риску, безопасности и записям. В SLA важно закрепить доступность отчета и неизменность уже опубликованной версии.

AI Router дает единый OpenAI-совместимый эндпоинт, маршрутизацию между внешними провайдерами и собственными моделями, а также аудит-логи и лимиты на уровне ключа. При закупке банка эти возможности все равно надо превратить в конкретные SLI, пороги и доказательства, потому что перечень функций не заменяет обязательство.

Приемка должна сломать договор на тестовом стенде

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

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

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

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

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

Подписывать следует не самый высокий процент, а самое узкое пространство для спора. Банк выиграет от договора, где медленный, неправильно маршрутизированный или оборванный ответ назван отказом, RTO отделен от реакции, а исключение требует доказательств. Именно эти строки будут читать в три часа ночи, когда сервисный статус и клиентский опыт перестанут совпадать.