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

云原生模型服务 SLO别只承诺平均延迟一、平均值很会骗人模型服务上线后团队常会汇报平均延迟、平均 QPS、平均成功率。问题是用户感受到的是尾延迟和失败。平均延迟 800msP99 可能已经 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: trueSLO 也要避免被平均租户掩盖。大客户、免费用户、内部测试流量混在一起会让指标看起来稳定。至少要按租户等级和任务类型切分视图。最后SLO 违反后要有复盘模板。记录违反时间、影响范围、触发指标、根因、临时处置和长期动作。没有复盘SLO 只是漂亮仪表盘。五、总结云原生模型服务 SLO 要关注可用性、首 token、尾延迟、错误分类和阶段拆解并连接扩缩容和回滚动作。别只承诺平均延迟。用户不会被平均值安慰生产系统也不该被平均值误导。