SLA для LLM-шлюза в критичных банковских системах

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

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

Начинайте с критичности банковской операции

SLA следует привязывать к последствию отказа, а не к абстрактному классу «production». Помощник сотрудника, который предлагает черновик ответа, терпит минутную паузу: человек продолжит работу вручную. Модель, которая проверяет документы внутри синхронного пути выдачи решения, может удержать очередь, сорвать срок обслуживания и оставить оператора без понятного статуса. Одинаковые 99,9% для этих сценариев означают разный риск.

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

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

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

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

Доступность равна доле годных операций

Доступность LLM-шлюза надо считать по успешным операциям с точки зрения клиента. Правильный SLI выглядит как отношение числа годных запросов к числу всех запросов, допущенных политикой, а не как доля минут, когда health-check получил 200. Минутный метод скрывает короткие массовые отказы, а проверка служебного endpoint не касается маршрута, авторизации, квот и модели.

В знаменатель входят запросы с корректной авторизацией, допустимым размером, поддерживаемой моделью и согласованной квотой. Ошибки клиента, например неверная схема или отозванный ключ, можно исключить. Ответы 429 из-за нехватки мощности поставщика, 5xx, тайм-ауты, обрывы потока и ответы с нарушенной заявленной схемой должны расходовать бюджет. Если поставщик исключает любой сбой нижестоящей модели как «ошибку третьей стороны», он продаёт SLA только на прокси, хотя банк покупает маршрутизацию до модели.

Я закрепляю формулу и классификацию прямо в приложении к договору. Такой фрагмент можно перенести в машиночитаемую спецификацию мониторинга:

sli: successful_llm_operations / eligible_llm_operations
window: calendar_month_utc
objective: 99.95%
eligible:
  auth: valid
  request_schema: valid
bad_events:
  - gateway_5xx
  - provider_429_or_5xx
  - client_deadline_exceeded
  - stream_terminated_before_finish
  - response_schema_invalid
maintenance: consumes_error_budget
minimum_sample: report_count_and_ratio

Цифра 99,95% здесь служит примером структуры, а не готовой рекомендацией. При равномерном трафике она допускает 0,05% неуспешных операций. Банк выбирает цель после оценки ущерба и архитектуры собственного обходного пути. Если ручной режим выдерживает только пять минут, договор с часовым пределом одного инцидента не спасёт процесс, даже когда месячный процент выглядит высоким.

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

p95 без p99 скрывает опасный хвост

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

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

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

Один порог для всех запросов также бесполезен. Задержка зависит от модели, длины входа, максимума выходных токенов, режима streaming, tool calling и требуемой схемы. В SLA задают несколько профилей, например короткую классификацию с фиксированным лимитом и генерацию объяснения в отдельном диапазоне токенов. Запросы сверх профиля не смешивают с основной выборкой, но поставщик всё равно должен сообщать их статистику.

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

Я не принимаю формулировку «p99 при нормальной нагрузке» без чисел. В приложении должны стоять допустимая частота запросов, параллелизм, токены в минуту, распределение размеров и поведение при превышении. Поставщик обязан либо принять нагрузку в этом конверте, либо быстро вернуть явный 429 с Retry-After. Молчаливое удержание запроса до клиентского тайм-аута лишает банк времени на запасной маршрут.

RTO и RPO защищают от разных потерь

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

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

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

Есть ещё одно различие, которое регулярно теряют в переговорах: RTO платформы не равен RTO бизнес-процесса. После восстановления endpoint приложение должно открыть circuit breaker, прогреть соединения, проверить модель, разобрать очередь и снять ручное ограничение. Банк измеряет полный путь на учениях и оставляет поставщику только часть общего времени. Если процесс допускает десять минут простоя, обещание поставщика восстановиться за те же десять минут уже не помещается в бюджет.

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

Переключение провайдера не гарантирует тот же результат

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

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

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

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

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

RU LLM можно рассматривать в такой архитектуре как единый OpenAI-совместимый endpoint с маршрутизацией к 500+ моделям от 68+ провайдеров и собственным хостингом 20+ open-weight моделей в российских ЦОДах, но конкретные SLO, резервные маршруты и результаты учений всё равно должны попасть в договор и протокол приёмки.

Ретраи требуют идемпотентности и общего лимита

Автоматический повтор без идентификатора операции способен превратить краткий сетевой сбой в двойную обработку и двойную оплату. RFC 9110 прямо запрещает прокси автоматически повторять неидемпотентный запрос, если он не знает, что семантика безопасна, либо не может установить, что первый запрос не был применён. Большинство LLM API используют POST, а поверх генерации приложение может запускать инструмент с реальным побочным эффектом.

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

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

Заголовок Retry-After из RFC 9110 позволяет серверу сообщить, когда повторить запрос после 503 или ограничения. В SLA закрепляют, какие коды содержат этот заголовок, максимальную задержку и поведение шлюза при отсутствии подсказки. Ответ 429 из-за собственной квоты клиента можно не считать недоступностью поставщика, а 429 при трафике внутри договорного конверта нужно считать. Разница определяется причиной и метрикой, а не одним HTTP-кодом.

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

Метрики банка и поставщика должны сходиться

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

Разница часов ломает расследование быстрее, чем кажется. Все отметки хранятся с часовым поясом и достаточной точностью, узлы синхронизируют время, а отчёт показывает начало влияния, обнаружение, переключение и полное восстановление. Для streaming полезно иметь отдельные отметки первого байта, первого содержательного токена и завершения. Один server duration не включает сеть и очередь на стороне клиента.

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

Google SRE Workbook предлагает оповещать по скорости расходования бюджета ошибок, burn rate, а не ждать конца отчётного окна. Это полезнее статического сигнала «доступность ниже цели»: быстрый расход требует немедленного вызова дежурного, медленный позволяет открыть задачу без ночного пейджинга. Я применяю два окна, короткое для резкого массового отказа и длинное для устойчивой деградации, но пороги рассчитываю из согласованного бюджета, а не беру из чужого примера.

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

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

Компенсация должна менять операционное поведение

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

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

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

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

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

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

Чек-лист договора и приёмки

Готовый SLA должен позволить независимой смене воспроизвести расчёт и провести переключение без устных пояснений поставщика. Если строку нельзя проверить метрикой, журналом или учением, это пожелание, а не обязательство.

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

Объём услуги: в договоре перечислены endpoint, модели, регионы, режимы и лимиты. Приёмка: запросы по каждому профилю.

Успешная операция: договор задаёт HTTP-статус, схему, завершение потока и срок. Приёмка: клиентский счётчик good events.

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

Задержка: договор задаёт TTFT, полное время, p95 и p99 по профилям. Приёмка: гистограммы банка и поставщика.

Один инцидент: договор ограничивает непрерывную деградацию. Приёмка: контрольная остановка маршрута.

Восстановление: договор задаёт MTTD, подтверждение, failover и RTO. Приёмка: протокол учения с отметками времени.

Сохранность: договор задаёт RPO отдельно для конфигурации, очередей и аудита. Приёмка: восстановление и сверка записей.

Переключение: договор перечисляет допустимые модели, условия запуска и возврата. Приёмка: тест качества резервного маршрута.

Повторы: договор задаёт deadline, idempotency key, Retry-After и дедупликацию. Приёмка: обрыв соединения до и после первого токена.

Отчётность: договор задаёт поля событий, сроки отчёта и порядок спора. Приёмка: сопоставление одной выборки трассировок.

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

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

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

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