Как вы определяете SLO и SLA для LLM сервиса?

Краткий тезис

SLO (Service Level Objective) — это целевые показатели качества сервиса, такие как задержка, доступность и точность ответов. SLA (Agreement) — контрактные обязательства перед клиентом, включающие SLO и условия компенсации при их нарушении. budget|Error budget (бюджет ошибок) — допустимый процент отказов, позволяющий балансировать между стабильностью и скоростью внедрения изменений. Для LLM-сервисов критично добавить метрики качества ответов (faithfulness, hallucination rate), так как традиционные технические метрики не отражают семантическую корректность.

1. Термины: SLO, SLA, SLI, Error Budget

SLI (Service Level Indicator) — измеряемая метрика, отражающая текущее состояние сервиса. Примеры: latency p95, availability (uptime), throughput (RPS), faithfulness score.

SLO (Service Level Objective) — целевое значение SLI, которое команда обязуется поддерживать. Пример: «p95 latency < 500 ms в 99.9% времени за месяц».

SLA (Service Level Agreement) — юридический контракт с клиентом, фиксирующий SLO и последствия их нарушения (компенсации, кредиты). SLA обычно жёстче SLO (например, SLO = 99.9%, SLA = 99.95%).

Error budget — допустимый объём нарушений SLO за период. Если SLO = 99.9%, error budget = 0.1% времени (≈ 43 минуты в месяц). Превышение error budget означает, что команда должна замедлить релизы и сосредоточиться на стабильности.

2. Почему SLO/SLA критичны для LLM-сервиса

LLM-сервисы имеют особенности, отличающие их от традиционных веб-сервисов:

• Стохастичность ответов — одна и та же модель может дать разные ответы на один запрос.
• Семантическое качество — недостаточно, чтобы сервер ответил 200 OK; ответ должен быть полезным и без галлюцинаций.
• Высокая стоимость инференса — ошибки дороги (GPU time).
• Агентные сценарии — в Agentic RAG цепочка вызовов может длиться минуты, и SLO на каждый шаг суммируются.

Без SLO невозможно объективно оценить, работает ли сервис «достаточно хорошо». SLA превращает эти ожидания в измеримые обязательства.

3. Выбор SLI для LLM-сервиса

Традиционные SLI (latency, availability, error rate) дополняются специфическими для LLM:

Технические SLI

• Latency — время от запроса до полного ответа (или первого токена для streaming). Измеряем p50, p95, p99.
• Availability — процент успешных HTTP-ответов (2xx) от общего числа запросов. Исключаем 4xx (ошибки клиента).
• Throughput — количество запросов в секунду (RPS).
• Error rate — доля 5xx ошибок, таймаутов, ошибок модели (например, превышение контекстного окна).

Семантические SLI (качество ответов)

• Faithfulness — насколько ответ соответствует предоставленным документам (для RAG). Измеряется через LLM-as-judge или специальные метрики (RAGAS).
• Hallucination rate — доля ответов, содержащих фактические ошибки.
• Answer relevance — релевантность ответа запросу.
• Task success rate — для агентов: доля успешно завершённых многошаговых задач.

Примеры пороговых значений:

4. Определение SLO: как установить целевые значения

Процесс установки SLO:

1. Сбор исторических данных — если сервис уже работает, анализируем SLI за последние 1–3 месяца.
2. Бизнес-требования — общаемся с заказчиками: какая задержка приемлема? Сколько ошибок допускается?
3. Анализ конкурентов — бенчмарки индустрии (ChatGPT p95 latency ~1–2 с, Gemini ~0.5–1 с).
4. Учёт стоимости — более жёсткие SLO требуют более дорогой инфраструктуры (больше GPU, кэширование, репликация).
5. Итеративное уточнение — SLO не статичны; их пересматривают каждые квартал.

Пример: для чат-бота поддержки клиентов:

• p95 latency < 2 с (пользователь готов ждать)
• Availability 99.95% (простой дорог)
• Faithfulness > 0.85 (допустимы небольшие неточности, но не галлюцинации)

Для аналитического сервиса (генерация отчётов):

• p95 latency < 10 с (допустимо дольше)
• Faithfulness > 0.98 (высокая точность критична)

5. Формализация SLA

SLA — это юридический документ. Для LLM-сервиса типичные пункты:

• Перечень SLO с указанием периода измерения (месяц, квартал).
• Метод измерения — какие инструменты мониторинга, как исключаются плановые работы.
• Компенсации — например, при нарушении SLO по availability на 0.1% — кредит 5% от месячной оплаты; при нарушении faithfulness SLO — возврат 10%.
• Исключения — форс-мажор, DDoS-атаки, planned maintenance с уведомлением.

Важно семантические SLO сложно включать в SLA из-за субъективности оценки. Часто их оставляют как внутренние SLO, а в SLA фиксируют только технические метрики. Однако для enterprise-клиентов возможно включение faithfulness с оговоркой «измеряется по методологии X».

6. Error Budget: управление рисками

Error budget = 100% — SLO (в процентах времени). Например, SLO 99.9% → error budget 0.1% (43 мин/мес).

Как использовать

• Мониторим потребление error budget в реальном времени.
• Если budget израсходован (например, за первую неделю месяца набрали 40 минут downtime), команда переключается на повышение стабильности: замораживает релизы, проводит postmortem, усиливает тестирование.
• Если budget почти не тратится, можно ускорять внедрение новых фич.

Для LLM-сервиса error budget можно расширить на семантические метрики: например, если faithfulness упал ниже порога в течение часа, это считается «ошибкой» и списывает часть budget.

7. Мониторинг и алертинг

Необходимые компоненты:

• Сбор SLI — Prometheus + экспортёры (для latency, availability, error rate). Для семантических метрик — отдельный пайплайн: логирование ответов, асинхронная оценка через LLM-as-judge (например, GPT-4), запись результатов в Prometheus.
• Дашборды — Grafana: графики p50/p95/p99 latency, availability, faithfulness, error budget consumption.
• Алерты — при превышении SLO (например, latency p95 > 500 ms в течение 5 минут) или при исчерпании error budget на 50%/80%/100%.

Пример кода для экспорта метрик в Prometheus (Python + FastAPI):

from prometheus_client import Histogram, Counter, Gauge
import time

LATENCY = Histogram('llm_request_duration_seconds', 'Request latency', buckets=[0.1, 0.5, 1, 2, 5])
ERRORS = Counter('llm_errors_total', 'Total errors', ['error_type'])
FAITHFULNESS = Gauge('llm_faithfulness_score', 'Current faithfulness score')

@app.post("/generate")
async def generate(prompt: str):
    start = time.time()
    try:
        response = await model.generate(prompt)
        LATENCY.observe(time.time() - start)
        # асинхронно оцениваем faithfulness
        score = await evaluate_faithfulness(response)
        FAITHFULNESS.set(score)
        return response
    except Exception as e:
        ERRORS.labels(error_type=type(e).__name__).inc()
        raise

8. Балансировка SLO: trade-off latency vs. качество

Часто приходится выбирать между скоростью и точностью. Примеры:

• Быстрая модель (LLaMA 3 8B) — низкая latency, но ниже faithfulness.
• Тяжёлая модель (GPT-4) — высокая faithfulness, но latency больше.

Стратегии

• Каскад моделей — сначала быстрая модель, если её уверенность низкая — переключаемся на тяжёлую.
• Кэширование — для частых запросов (например, FAQ) отдаём предварительно сгенерированные ответы, latency ~0.
• Streaming — пользователь видит первый токен через 200 ms, хотя полный ответ может генерироваться 2 с. SLO на TTFB (time to first token) отдельно.

Пример SLO для streaming TTFB p95 < 300 ms, полный ответ p95 < 3 s.

9. Примеры SLO для разных типов LLM-сервисов

10. Процесс пересмотра SLO

SLO не должны быть статичными. Рекомендуется:

• Ежеквартальный review — анализируем фактические SLI, отзывы клиентов, изменения в модели.
• Ужесточение — если сервис стабильно выполняет SLO с запасом, можно повысить планку (например, latency p95 с 500 ms до 300 ms).
• Ослабление — если нарушения часты, возможно SLO слишком агрессивны; корректируем их в соответствии с возможностями.
• Добавление новых SLI — с появлением новых фич (например, мультимодальность) добавляем соответствующие метрики.

11. Связь с reliability engineering для ML-систем

SLO/SLA — часть практик SRE (Site Reliability Engineering), адаптированных для ML. Ключевые принципы:

• Toil reduction — автоматизация мониторинга и алертинга.
• Postmortem culture — при нарушении SLO проводим разбор без обвинений, улучшаем систему.
• Gradual rollouts — новые версии моделей раскатываем на 1% трафика, следим за SLI.
• Canary deployments — сравниваем SLI новой и старой версии.

Для LLM-сервисов особенно важно A/B-тестирование faithfulness, так как latency и availability могут оставаться в норме, а качество ответов упасть.

Пет-проект для закрепления

Задача Развернуть минимальный LLM-сервис (FastAPI + OpenAI API), добавить мониторинг latency, availability и faithfulness, определить SLO и настроить алерты.

Инструменты

• Python, FastAPI, uvicorn
• Prometheus client (prometheus_client)
• Grafana (локально или через Docker)
• OpenAI API (или локальная модель через Ollama)
• LangChain / RAGAS для оценки faithfulness

Шаги:

1. Создать FastAPI-приложение с эндпоинтом /generate, который вызывает OpenAI API.
2. Добавить метрики: latency (Histogram), errors (Counter), faithfulness (Gauge) — faithfulness оценивать через LLM-as-judge (например, gpt-4o-mini) асинхронно.
3. Настроить Prometheus для сбора метрик с /metrics.
4. В Grafana создать дашборд: графики p95 latency, availability (100% - error rate), faithfulness score, error budget consumption.
5. Определить SLO: p95 latency < 2 s, availability > 99.5%, faithfulness > 0.85.
6. Настроить алерты в Grafana (или Alertmanager) при превышении SLO в течение 5 минут.
7. Провести нагрузочное тестирование (например, locust) и проверить, как часто нарушаются SLO.

Ожидаемый результат Работающий дашборд с SLI и статусом SLO (OK/WARNING/CRITICAL). Вы сможете увидеть, как изменение модели (например, замена gpt-3.5-turbo на gpt-4o) влияет на метрики.

Связь с другими вопросами

Навигация

• Предыдущий: 380
• Следующий: 382
• Индекс: 00. Индекс разборов