sla
**Service Level Agreements (SLAs) for AI Systems** define the **contractual or internal guarantees on availability, latency, throughput, and error rates for AI-powered services** — which are uniquely challenging to maintain due to the variable execution time, high compute cost, and probabilistic nature of large language models, requiring specialized monitoring, fallback strategies, and infrastructure provisioning that differ significantly from traditional web service SLAs.
**What Are AI System SLAs?**
- **Definition**: Formal commitments specifying the minimum performance levels an AI service will maintain — typically covering availability (uptime percentage), latency (response time percentiles), throughput (requests per second), and error rates, with defined consequences (credits, escalation) for breaches.
- **LLM Challenge**: LLM response times are highly variable — a 10-token response takes 200ms while a 2000-token response takes 20s, making fixed latency SLAs difficult. Output length depends on the query, not the infrastructure.
- **Soft Failures**: Traditional SLAs cover hard failures (downtime, errors) — but LLMs can produce "soft failures" (hallucinations, off-topic responses, safety violations) that degrade user experience without triggering error codes. These are typically not covered by SLAs but matter enormously.
- **GPU Dependency**: AI SLAs depend on GPU availability — GPU shortages, memory fragmentation, and thermal throttling can degrade performance in ways that CPU-based services don't experience.
**Key SLA Metrics for AI Systems**
| Metric | Definition | Typical Target | Measurement |
|--------|-----------|---------------|-------------|
| Availability | Percentage of time service is operational | 99.9% (8.7 hrs downtime/year) | Synthetic monitoring |
| TTFT (Time to First Token) | Latency before first token appears | p95 < 200-500ms | Real-user monitoring |
| Generation Throughput | Tokens generated per second | 30-100 tokens/s | Per-request measurement |
| E2E Latency | Total time from request to complete response | p95 < 2-5s (short responses) | End-to-end timing |
| Error Rate | Percentage of requests returning errors | < 0.1% | Error log analysis |
| Throughput | Requests per second the system handles | Application-dependent | Load testing |
**SLA Management Strategies**
- **Fallback Models**: If the primary model (GPT-4) is slow or unavailable, automatically route to a faster/smaller model (GPT-4o-mini) — degraded quality is better than SLA breach.
- **Caching**: Cache responses for common queries — eliminates latency and cost for repeated requests, improving SLA compliance.
- **Provisioned Throughput**: Reserve dedicated GPU capacity rather than sharing — guarantees consistent performance at higher cost.
- **Synthetic Monitoring**: Send periodic test prompts ("heartbeat") to detect degradation before users are affected — enables proactive alerting.
- **Timeout and Retry**: Set maximum generation time limits — if a response exceeds the timeout, return a cached or fallback response rather than making the user wait.
**SLAs for AI systems require specialized approaches beyond traditional web service guarantees** — accounting for variable execution times, GPU-dependent performance, and probabilistic output quality through fallback models, provisioned capacity, and monitoring strategies that maintain reliable user experiences despite the inherent unpredictability of large language model inference.