云原生模型服务 SLO：别只承诺平均延迟

一、平均值很会骗人

模型服务上线后，团队常会汇报平均延迟、平均 QPS、平均成功率。问题是，用户感受到的是尾延迟和失败。平均延迟 800ms，P99 可能已经 15 秒；平均成功率 99%，核心租户可能刚好在失败那 1% 里。

云原生模型服务的 SLO 要围绕用户体验和业务风险定义，而不是只看平均值。

二、SLO 要拆到关键阶段

flowchart TD A[请求进入] --> B[网关排队] B --> C[Prefill] C --> D[Decode] D --> E[后处理] E --> F[流式返回]

模型服务延迟由多个阶段组成。只看总耗时，无法判断问题在排队、模型计算、网络还是后处理。

model_service_slo: availability: 99.9 first_token_p95_ms: 1200 total_latency_p99_ms: 15000 error_rate_max: 0.01

流式服务尤其要看首 token 延迟。用户往往能接受总生成时间长一点，但不能接受一直没有反馈。

三、错误要分类统计

type ModelError struct { Code string Retryable bool Stage string }

模型错误不能都算 500。上下文过长、限流、模型超时、网关断流、输出校验失败，处理方式不同。SLO 统计也应该区分。

如果大量错误来自用户输入过长，就应该优化提示和限制；如果来自模型超时，就要看调度和容量；如果来自输出校验失败，可能是 prompt 或 schema 问题。

四、SLO 要连接扩缩容

SLO 不是报表，它要驱动动作。首 token 延迟持续升高，可能要扩容推理副本；排队时间升高，可能要调度更多 GPU；错误率升高，可能要降级模型或熔断某个版本。

slo_actions: first_token_p95_violate: scale_inference_pool queue_wait_violate: reduce_batch_wait error_rate_violate: trigger_canary_rollback

还要为不同租户或任务设不同 SLO。在线对话、批量总结、后台评测不应该共用同一套目标。批任务可以慢，在线请求必须稳。

SLO 也要有错误预算。错误预算耗尽时，新功能发布和模型切换应更谨慎。否则稳定性会一直输给功能速度。

最后，SLO 报表要展示趋势和原因。只显示红绿灯不够，团队需要知道哪个阶段破坏了目标。

还要把 SLO 和发布关联起来。模型版本、镜像版本、路由策略、Batch 参数变化后，如果 SLO 下降，系统要能自动标出变更窗口。否则团队会在容量、代码、模型之间来回猜。

slo_change_correlation: track_model_version: true track_release_id: true track_scheduler_config: true

SLO 也要避免被平均租户掩盖。大客户、免费用户、内部测试流量混在一起，会让指标看起来稳定。至少要按租户等级和任务类型切分视图。

最后，SLO 违反后要有复盘模板。记录违反时间、影响范围、触发指标、根因、临时处置和长期动作。没有复盘，SLO 只是漂亮仪表盘。

五、总结

云原生模型服务 SLO 要关注可用性、首 token、尾延迟、错误分类和阶段拆解，并连接扩缩容和回滚动作。

别只承诺平均延迟。用户不会被平均值安慰，生产系统也不该被平均值误导。