SLO и error budget для LLM API клиента

Короткий ответ: SLO измеряет путь пользователя, а не один запрос

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

Разделите обычные ответы, streaming, асинхронные задачи и внутренние batch-процессы. У них разные ожидания, таймауты и последствия ошибки. Для каждого маршрута фиксируйте версию приложения, разрешённый model ID и тип операции, но не пишите в телеметрию prompt, ответ, API-ключ или полный заголовок Authorization. Сигнал SLO должен помогать диагностике без превращения мониторинга в хранилище секретов.

Выберите индикаторы: latency, ошибки и полезный результат

Хороший service level indicator сочетает технический статус и прикладную проверку. HTTP 200 не всегда означает успех: JSON может не соответствовать схеме, поток может оборваться, а ответ может быть непригоден для следующего шага. Для структурированного сценария считайте успешным только ответ, который прошёл серверную валидацию. Для генеративного текста добавьте проверяемые свойства: язык, максимальную длину, наличие обязательного поля или корректный безопасный отказ.

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

Error budget превращает спор в заранее согласованное решение

Error budget — допустимая доля неуспешных или слишком долгих операций за выбранное окно. Сначала согласуйте, что именно считается ошибкой: локальный deadline, ошибка схемы, безопасный отказ, отмена пользователем или ответ 429 могут иметь разные статусы для продукта. Затем назначьте владельца и действие при расходе бюджета. Например, команда может остановить эксперимент, уменьшить concurrency, отключить необязательную функцию или вернуть подтверждённый маршрут.

Не выбирайте порог по памяти и не маскируйте его бесконечными повторными вызовами. Проведите короткий staging-прогон на synthetic или согласованно обезличенных данных, посмотрите распределение и зафиксируйте начальную гипотезу. Через неделю сравните её с фактическим трафиком. Если нагрузка, модель, prompt, base URL или политика данных меняются, пересмотрите SLO: старый бюджет не доказывает будущую надёжность.

Fallback должен быть ограниченным и проверяемым

Fallback полезен только для заранее разрешённого сценария и не должен обходить ограничения, правила доступа или договорные условия. Укажите порядок маршрутов, допустимый класс задач, локальный budget cap и явные стоп-условия. Если запасной маршрут меняет формат, язык, риск данных или стоимость, потребуйте повторной валидации и, при сомнении, покажите пользователю контролируемый отказ. Нельзя считать любой второй ответ эквивалентой заменой первого.

Разделяйте ошибки, которые можно повторить, и ошибки, которые нужно остановить. 401, 403 и неверная схема не исправляются повтором. Для временного сбоя применяйте небольшое число попыток с deadline и backoff только к безопасной операции. Записывайте безопасный correlation ID, класс ошибки и решение маршрутизатора. Этого достаточно, чтобы связать инцидент с логами, не раскрывая содержание запроса или секреты.

Запуск через canary и ежедневный разбор

Начните с feature flag и малого внутреннего или низкорискового трафика. До запуска подготовьте dashboard с долей успешных прикладных результатов, перцентилями latency, классами ошибок, отменами и расходом error budget. Назначьте человека, который имеет право остановить rollout. Если метрика ухудшается, сначала стабилизируйте систему и соберите безопасные агрегаты; не меняйте одновременно prompt, модель, таймаут и код, иначе причина останется неясной.

Ежедневный разбор не обязан быть длинным. Сверяйте окно наблюдения, версию релиза, объём выборки, самые частые классы ошибок и принятое действие. Храните агрегаты и ссылки на воспроизводимые synthetic-кейсы. Так SLO становится практикой управления риском, а не маркетинговым числом. Цель — дать пользователю предсказуемый путь и честно остановиться, когда система не выполняет собственный договор команды.

Server-side пример

Пример показывает локальную проверку на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут, model ID и параметры в текущем каталоге RussiaAPI.

export function classifyOutcome({ status, elapsedMs, schemaOk, deadlineMs }) {
  if (elapsedMs > deadlineMs) return 'deadline_exceeded';
  if (status >= 500) return 'upstream_error';
  if (status >= 400) return 'request_error';
  return schemaOk ? 'good' : 'invalid_output';
}

export function burnRate(outcomes) {
  if (!outcomes.length) throw new Error('empty_window');
  return outcomes.filter((value) => value !== 'good').length / outcomes.length;
}

// Store only aggregates and a correlation ID; never record prompts or secrets.

Проверьте синтаксис через node --check, добавьте аутентификацию своего маршрута и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.

Границы и безопасный запуск

Это инженерное руководство, а не юридическое заключение и не инструкция по обходу законов, санкций, региональных, платёжных или платформенных ограничений. Не передавайте в тесты персональные данные, коммерческие секреты, upstream-ключи, cookie, пароли или полный заголовок Authorization. Для чувствительных данных подтвердите цель, минимизацию, срок хранения и договорные условия с ответственными специалистами.

Ключ RussiaAPI хранится только в server-side secret store. Разделяйте development, staging и production, ограничивайте доступ и журналируйте лишь безопасные метаданные. Неизвестную функцию, модель, квоту или поле ответа считайте неподтверждёнными, пока не проверите их в текущем разрешённом тестовом контуре.