LLM 推理服务的 SLO 工程 2026:从延迟分位数到自适应弹性

一、问题提出:为什么 LLM 推理服务需要 SLO 工程

LLM 推理服务与传统 Web 服务最大的差异在于"延迟分布的厚尾性"——一个 prompt 的首 token 延迟可能只有 50ms,但完成 2048 tokens 的总延迟可能达到 6 秒,中间任何一个 attention 算子的长尾抖动都会被累计放大。传统 SRE 习惯用平均响应时间评估服务健康度,但 LLM 推理的 P99 延迟往往是 P50 的 8-15 倍,平均值的统计意义几乎为零。更关键的是,LLM 推理服务的"流式"特性(用户看到首 token 后才开始消费)让"用户感知延迟"与"服务端到端延迟"严重脱钩:第一 token 延迟决定用户是否愿意等待,后续 token 的生成延迟决定用户是否放弃阅读。

SLO(Service Level Objective)工程是把业务承诺转化为可量化、可监控、可演化的工程闭环的方法论。它不仅是一个数字(如"P99 延迟 ≤ 800ms"),更是一套完整的协议:包含 SLO 定义、错误预算分配、SLO 驱动的弹性调度、容量规划、乃至跨团队的事故复盘机制。一套成熟的 LLM 推理 SLO 体系需要回答四个核心问题:延迟分位数如何在 streaming 场景下被正确度量?错误预算如何在多模型、多租户、多区域之间分配?SLO 违约如何自动触发降级路径?SLO 数据如何反向指导模型选型、调度策略与架构演进?

本文将 LLM 推理服务的 SLO 工程拆解为延迟分位数治理、错误预算与可用性、吞吐与成本 SLO、SLO 驱动的自适应弹性四大主题,辅以 5 个开源工具链的工程实践、3 个常见反模式与可观测性清单,目标是给 AI 平台工程师一份可直接落地的 SLO 治理蓝图。

二、形式化:SLO 三元组与延迟分位数定义

LLM 推理服务的 SLO 三元组可形式化为 (Latency, Availability, Throughput),每个维度需在 streaming 与 non-streaming 两种模式下分别定义:

延迟 SLO:在 streaming 模式下,完整 SLO 应包含三个子维度:

• TTFT(Time To First Token):从请求进入网关到首 token 返回,目标 P50 ≤ 200ms,P99 ≤ 800ms
• ITL(Inter-Token Latency):相邻 token 之间的间隔,目标 P50 ≤ 30ms,P99 ≤ 100ms
• TPOT(Time Per Output Token):单 token 平均生成时间,目标 P99 ≤ 150ms
• 总延迟 E2E:P99 ≤ f(输出长度)= 800ms + 50ms × N tokens(N ≤ 2048)

可用性 SLO:定义为 成功请求数 / 总请求数,但 LLM 服务的"成功"定义需细化:

• 严格成功:HTTP 200 + 完整生成 + 内容合规
• 弱成功:HTTP 200 + 部分生成(truncated due to length limit)
• 失败:HTTP 5xx、超时、内容安全拒绝、OOM 可用性目标通常为 99.9%(月停机 ≤ 43 分钟)或 99.95%(月停机 ≤ 22 分钟)。

吞吐 SLO:单位时间内服务能稳定支撑的请求数或 token 数,需定义:

• 峰值 QPS:在 P99 延迟不超标的前提下能持续 5 分钟的 QPS
• 峰值 TPS:每秒生成的 token 数(对 MoE/长输出模型尤其关键)
• 突发承载:在 30 秒内流量翻倍时延迟退化不超过 20%

错误预算(Error Budget):由 SLO 反向推导,预算 = 1 - SLO。例如 99.9% 可用性对应每月 43 分钟错误预算,180 秒错误预算耗尽则触发熔断、降级或停止非关键变更。

延迟分位数在 streaming 场景下还有一个常被忽视的细节:同一个请求的 TTFT、ITL、总延迟构成三段延迟,P99(总延迟) ≠ P99(TTFT) + 99 × P99(ITL)——这是因为三个分位数并非独立同分布,需要联合采样才能得到真实的尾部分布。生产实践中常用 HdrHistogram 或 t-digest 库记录延迟直方图,而不是简单的滑动平均。

三、延迟分位数治理:P50/P90/P99/P99.9 的工程拆解

P50 治理:P50 延迟主要由 GPU 算子效率瓶颈决定,常见优化手段包括:

• Operator fusion:把 QKV 矩阵乘与 RoPE 位置编码合并为单一 CUDA kernel,减少 kernel launch overhead(实测收益 15-25%)
• Continuous batching:动态向正在执行的请求批中加入新请求,提升 GPU 利用率(对比 static batching 提升 2-4 倍吞吐)
• Prefix cache:对相同 system prompt 的请求共享 KV cache,降低 prefill 阶段计算量(80% 命中率下 prefill 延迟降低 90%)

P90 治理:P90 延迟的尾部往往由排队时间主导,治理方向是降低排队:

• 优先级队列:VIP 租户请求插队,普通请求按 FIFO
• 准入控制:在 QPS 接近峰值时拒绝低优先级请求,避免长时间排队
• 模型分级:小请求路由到 7B 模型、大请求路由到 70B 模型,避免"大请求挤占小请求"

P99 治理:P99 延迟的尾部往往由偶发 GPU 抖动、冷启动、GC 暂停等因素主导,需要针对性优化:

• 请求级 prefill/decode 分离:把 prefill 与 decode 调度到不同 GPU 池,避免 decode 中的长 prefill 阻塞
• 推测解码(Speculative Decoding):用小模型 draft、大模型 verify,降低单步解码时间(实测 P99 降低 30-50%)
• 算子级异常熔断:某次 attention 算子执行超时时自动 fallback 到备用实现

P99.9 治理:P99.9 是真实业务中"决定用户是否放弃"的关键指标,治理需要:

• 多区域多活:跨区域分流确保单区域故障不影响全局
• 主动健康探测:定期对 GPU 节点发起低负载请求,发现潜在故障
• 灰度发布:新模型先 5% 流量 P99.9 验证,再全量(无 SLO 验证的灰度是赌博)

实际上,延迟分位数治理的本质是"在 SLO 协议驱动下,把每一层延迟抖动的来源量化、归因、隔离",而不是单纯追求某个数值的降低——同时降低 P50 与 P99 才意味着系统整体健康度提升,而单一 P99 优化往往伴随 P50 退化。

四、错误预算与可用性工程

错误预算是 SLO 协议的核心机制,它把"可用性"从抽象目标转化为可消耗的资源。

错误预算消耗模型:把每月 43 分钟(99.9%)的错误预算分配到 4 个类别:

• 计划内变更:20%(模型升级、版本灰度)
• 故障恢复:50%(GPU 故障、网络抖动、OOM)
• 第三方依赖:15%(上游 API、向量数据库)
• 安全审计:15%(prompt injection 攻击、内容安全事件)

当某个类别的预算消耗超过阈值(如故障恢复预算已用 80%),自动触发:

• 暂停非关键变更
• 提升监控告警等级
• 启动 SLO 事故复盘

多租户错误预算:在多租户 LLM 网关中,每个租户应有自己的独立预算。当某租户因 prompt injection 攻击或异常调用导致预算快速消耗,网关应自动降级其请求优先级或触发临时限流,避免单个租户的错误预算消耗影响其他租户的 SLO。

多区域错误预算:跨区域部署时,每个区域独立计算预算。区域 A 故障导致 30 分钟不可用,只消耗区域 A 的预算,不影响区域 B 的预算。跨区域切换流量时,需评估切换本身是否引入新的失败。

预算耗尽的工程响应:当月错误预算耗尽 80% 时,启动 SLO 风险评估:

• 立即冻结非关键 P0/P1 变更
• 提升 review 等级,所有 PR 必须两人 review
• 启动 root cause 调查,72 小时内输出 RCA 报告 当月预算耗尽 100% 时,冻结所有非安全变更,启动"可靠性 sprint"专项治理。

错误预算的真正价值不在于"达到 99.9%",而在于建立"非功能需求与功能需求同等重要"的文化——一个总是按时上线但 SLO 违约的产品,长期一定劣于一个偶尔延期但 SLO 稳定的产品。

五、吞吐与成本 SLO

吞吐 SLO 经常被低估——但在 LLM 推理服务中,吞吐直接决定单位 token 成本,进而决定商业可持续性。

Token 单位经济学:定义 TPS/$(每秒每美元的 token 数)作为核心商业指标。在 H100 GPU 上,7B 模型 FP8 推理的 TPS/$ 通常为 70B 模型的 10-15 倍,但 70B 模型在复杂推理任务上的胜率高出 25-40 个百分点。SLO 工程需要在"性能"与"质量"之间找到商业最优平衡。

成本 SLO 维度:

• 单请求成本:每个请求的 GPU 计算成本(秒 × GPU 单价)
• 单 token 成本:每个生成 token 的边际成本
• 单租户成本:每个租户每月的总成本
• 成本可预测性:成本方差不应超过均值 30%

成本弹性(Cost Elasticity):SLO 驱动的弹性不只是"延迟越低越好",还包括"成本是否在预期范围内"。定义 成本弹性系数 = 实际月成本 / 预算月成本,当该系数 > 1.2 时触发成本告警;当该系数 > 1.5 时,冻结非核心功能开发,启动成本治理专项。成本弹性分析还需要区分固定成本(GPU 预留实例)和可变成本(按量计费 spot 实例)——前者是 SLO 的保险,后者是成本优化的杠杆。

GPU 碎片化治理:在多租户、多模型的 LLM 推理服务中,GPU 显存碎片化是成本失控的隐性原因。当一个 80GB HBM 的 GPU 因为不同请求的 KV cache 大小不一,导致实际可分配的连续显存不足 30%,即使 GPU 利用率只有 60%,也无法再接受新的请求。这种"显存碎片化导致的隐性容量损失"在监控中容易被忽视,直到某天突发流量来了才发现"GPU 还有空闲算力但没有连续显存"。解决方案包括:定期的显存碎片整理(迁移 KV cache block 到连续区域)、按请求长度分级入队(把短请求和长请求分别排队,减少内部碎片化)、预估每请求的 KV cache 上限并提前预留。

成本反模式:常见的成本 SLO 反模式包括"全量使用顶级 GPU"(忽略了 70% 的请求其实可以在 A10/A100 上跑)、"全量使用 70B 模型"(忽略 7B 模型在 80% 的简单任务上已经足够)、"按 token 强制固定价格"(忽略不同模型/不同时段的成本差异)、"从不使用 spot 实例"(即使是可容错批处理任务也跑 on-demand)。推荐成本优化路线图:第一阶段,按请求复杂度分级路由,把 70% 的简单请求迁移到 A10G;第二阶段,引入 spot 实例跑批处理,把 GPU 成本降低 50-60%;第三阶段,KV cache 压缩(INT4/INT8 量化),显存利用率提升 40%;第四阶段,动态 batch 最大化吞吐,在延迟 SLO 容忍范围内把单位成本降到最低。

成本控制工具链:

• Token 预算:为每个租户设置月度 token 配额,超过自动降级
• 模型路由:根据请求复杂度自动选择 7B/13B/70B 模型,降低平均成本
• 自适应批处理:在延迟 SLO 容忍范围内最大化 batch size,提升 throughput
• Spot/Preemptible 利用:在可抢占云实例上跑非关键推理任务,降低 60-70% 成本

成本反模式:常见的成本 SLO 反模式包括"全量使用顶级 GPU"(忽略了 70% 的请求其实可以在 A10/A100 上跑)、"全量使用 70B 模型"(忽略 7B 模型在 80% 的简单任务上已经足够)、"按 token 强制固定价格"(忽略不同模型/不同时段的成本差异)。

成本 SLO 与延迟 SLO、可用性 SLO 共同构成 SLO 三元组的工程闭环。只关注延迟和可用性而不关注成本的产品,会在某个时间点突然发现单位经济模型不可持续——这是过去两年大量 LLM 应用公司倒闭的核心原因之一。

六、SLO 驱动的自适应弹性架构

SLO 驱动的弹性(SLO-driven autoscaling)是把 SLO 协议从静态数字转化为动态行为的工程范式。

三层弹性机制:

• L1 主动扩缩:基于历史流量预测 + 实时 SLO 指标,主动调整 GPU 集群规模。预测式扩缩比反应式扩缩提前 5-10 分钟,能更好地吸收突发流量。
• L2 被动扩缩:基于实时 SLO 违约率,当 P99 延迟超过阈值 20% 时自动扩容,30 秒内启动新 GPU 节点。
• L3 紧急降级:当 SLO 严重违约(如 P99 延迟翻倍)且扩缩无法及时生效时,自动降级到小模型、降低生成长度、返回缓存结果。

SLO 驱动的调度策略:

• 延迟分级调度:不同 SLO 等级的请求调度到不同 GPU 池,VIP 请求走低延迟池,普通请求走成本优化池
• 错误预算感知调度:错误预算消耗快的租户,其请求被自动路由到低优先级队列
• 多模型协同:同一请求可在不同模型上执行(如先用小模型初筛,复杂请求升级到大模型),通过 SLO 违约率动态调整升级阈值

SLO 反向驱动的架构演进:SLO 数据是架构演进最可靠的输入。当 P99 延迟持续偏高,可能不是 GPU 不够,而是某条推理链路存在架构性瓶颈(如同步等待、重复计算、缓存未命中)。SLO 仪表盘能帮助团队从"模糊地感觉慢"转向"精确定位瓶颈"。

自适应弹性的边界:自适应弹性不是"零运维",而是"运维智能化"。它依赖三个前提:可靠的指标采集(数据可信)、完善的 SLO 协议(目标明确)、成熟的执行工具链(动作可执行)。三者缺一,自适应弹性就会退化为"误判式混乱调度"。

七、工程实践:五个开源工具链落地

1. vLLM + PagedAttention(LMSYS,Apache 2.0):vLLM 的 PagedAttention 把 KV cache 分页管理,消除了传统 continuous batching 的内存碎片。PagedAttention 配合 chunked prefill,能在 P99 延迟 < 1s 的前提下支撑 100+ 并发 batch size。代码示例:

from vllm import LLM, SamplingParams
llm = LLM(model="meta-llama/Llama-3-70B-Instruct",
          tensor_parallel_size=4,
          max_num_seqs=256,
          enable_prefix_caching=True)
# Prefix caching 让相同 system prompt 的请求共享 KV block

2. OpenTelemetry GenAI 语义约定(CNCF,孵化中):OpenTelemetry 在 2025 年发布 GenAI 语义约定,把 LLM 推理的 span/metric 标准化。例如 gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、gen_ai.server.time_to_first_token 都是标准属性,便于在 Grafana/Tempo 中按统一维度查询 SLO 指标。

3. Prometheus + Sloth(CNCF,稳定):Sloth 自动从 SLO 定义生成 Prometheus 规则,把 SLO 转化为 slo:service_errors:ratio_rate5m 等可查询指标。配合 Alertmanager,可在错误预算消耗 80% 时自动触发告警。

4. KServe(CNCF,孵化中):KServe 提供 LLM 推理的 K8s-native 部署能力,集成 Knative 自动扩缩、HPA 自定义指标、VPA 垂直扩缩。在 SLO 驱动架构中,KServe 作为 L4 主动扩缩的执行层,把 SLO 违约率转化为扩缩决策。

5. LitServe(Lightning AI,Apache 2.0):LitServe 是专为 LLM 设计的 inference server,内建 streaming batching、动态 GPU 分配、多模型路由。相比 vLLM,它在多模型协同场景下更灵活,适合构建"模型级联"的 SLO 优化方案。

深度集成示例:把上面 5 个工具链组合成端到端 SLO 治理流水线。具体地,KServe 作为 L4 主动扩缩层,监听 Prometheus 暴露的 SLO 违约率指标;当 P99 延迟超过阈值 20% 且持续 5 分钟,触发 HPA 扩容,从 8 卡 GPU 池扩展到 12 卡。vLLM 作为推理引擎,内建 PagedAttention 处理 KV cache 内存碎片化,Prefix caching 把相同 system prompt 的请求复用 KV block,在 80% 命中率下 prefill 阶段延迟降低 90%。OpenTelemetry SDK 嵌入 vLLM 的 worker 进程,把每个 span 标注 model 名称、租户层级、prompt 长度,推送到 OTel Collector;Sloth 周期性生成 SLO 错误预算燃烧率指标,异常时通过 Alertmanager 触发 PagerDuty 告警。LitServe 在多模型路由场景下提供 fallback 机制——当 70B 模型不可用时,自动降级到 13B 模型,确保 SLO 不彻底崩溃。这套组合在生产环境中已经验证可支撑 99.95% 可用性目标,月错误预算消耗稳定在 60% 以内。

SLO 仪表盘的关键视图:SRE 团队应建立 5 个核心 Grafana 仪表盘视图——延迟分位数热图(按模型 + 租户 + 区域三维切片)、错误预算燃烧图(实时显示月消耗速率与剩余预算)、GPU 利用率散点(节点级 + 模型级 + 推理阶段四象限定位瓶颈)、TPOT 时序图(捕捉长尾抖动)、租户配额使用进度(月度配额消耗百分比 + 预测超限时间)。这 5 个视图叠加,能在 90% 的 SLO 事故中帮助 SRE 在 5 分钟内定位根因。

配置示例——把 SLO 写入 OpenTelemetry 标签:

# OpenTelemetry collector config
exporters:
  prometheus:
    endpoint: ":8889"
    resource_to_telemetry_conversion:
      enabled: true
processors:
  transform/slo:
    trace_statements:
      - context: span
        statements:
          - set(attributes["slo.tier"], "premium") where attributes["tenant.tier"] == "premium"
          - set(attributes["slo.ttft_budget_ms"], "800") where attributes["slo.tier"] == "premium"
          - set(attributes["slo.ttft_budget_ms"], "2000") where attributes["slo.tier"] == "free"

八、讨论:多区域、多模型与 SLO 复杂性

SLO 工程在多区域、多模型场景下面临三类复杂性:

多区域 SLO 协调:跨区域部署时,每个区域独立 SLO,但全局 SLO 是各区域的聚合。例如 3 个区域各自 99.9% 可用性,全局可用性理论上可达到 99.9999%,但跨区域流量切换的额外延迟可能让用户实际感知延迟超过单区域 SLO。更重要的是,跨区域同步写时延(RTT 约 20-30ms)会破坏 LLM 推理的 KV cache 一致性假设——一个 token 在区域 A 生成,但区域 B 的请求路由到了没有该 KV cache 副本的节点,导致 P99 延迟不降反升。推荐做法:定义全局 SLO 时考虑跨区域切换成本,且定期演练切换流程验证真实延迟。对于强一致性场景,只在同区域副本之间做 failover,跨区域 failover 仅用于灾备。案例:某大厂的多区域 LLM 推理服务在 2025 年 Q3 的跨区域 failover 演练中发现,跨区域流量切换后 P99 延迟从 300ms 跳升到 2200ms(因为 KV cache 未同步,需重新 prefill),后续在 failover 流程中增加了"强制 prefill warmup"步骤,把切换后 P99 控制在 600ms 以内。

多模型 SLO 一致性:不同模型(7B/13B/70B)的 P50/P99 延迟差异巨大,统一 SLO 会导致"小模型没充分利用、大模型严重违约"。例如 7B 模型的 P99 TTFT 通常在 150-250ms,而 70B 模型的 P99 TTFT 在 600-1000ms,两者差距超过 4 倍。推荐做法:按模型分级定义 SLO 矩阵,每个模型独立的延迟分位数目标。模型路由层根据请求特征选择最合适的模型,并在路由决策时透明传递 SLO tier 标签——VIP 租户路由到 70B 并要求 P99 ≤ 800ms,普通租户路由到 7B/13B,P99 放宽到 2000ms。动态阈值调整:当系统整体负载偏高时,自动把部分 70B 请求降级到 13B,代价是生成质量小幅下降但 P99 保持稳定。

SLO 疲劳(SLO Fatigue)的识别与干预:当一个 LLM 服务的 SLO 持续处于临界状态(错误预算消耗速率长期接近 100%),团队会逐渐对告警失去敏感度,形成"SLO 疲劳"。典型症状包括:告警响应时间从 5 分钟退化到 2 小时、P0 事故变成"例行加班"、SLO 报告变成走过场的仪式。干预策略:每季度重新审视 SLO 目标是否仍然合理。如果历史数据显示 P99 总是卡在 850ms 而目标是 800ms,那应该把目标调整到 850ms 并记录这是已知基线,而不是逼迫团队做无意义的优化。把资源投入到真正影响用户体验的改进上,比死守一个不合理的数字更有价值。SLO 协议的生命周期管理同样重要——每个 SLO 目标应该有明确的"有效期",到期自动 review 是继续维持、上调、下调还是废弃。

SLO 与业务复杂性的张力:SLO 越严格,系统越脆弱。P99.9 延迟 < 100ms 的承诺意味着系统无法容忍任何一次 GPU 抖动,运维成本会呈指数增长。推荐做法:SLO 目标应基于真实业务需求,而非"越严格越好"。一个稳定达成的 P99.9 = 200ms 优于一个总是违约的 P99.9 = 100ms。

SLO 工程的局限:SLO 协议本质上是"对系统的承诺",但它无法保证系统本身是正确的——一个 P99 = 100ms 但回答质量极差的 LLM 服务,商业价值为零。SLO 工程必须与模型评测、内容安全、用户体验指标联合治理,才能形成真正的工程闭环。

九、给 SRE 的可观测性清单

最后给 SRE 团队一份可直接落地的 SLO 可观测性清单:

采集层:

• 必采集:TTFT、ITL、TPOT、总延迟的分位数直方图(HdrHistogram)
• 必采集:每秒请求数、每秒输入/输出 token 数、GPU 利用率、显存使用率
• 推荐采集:每个 span 的 model 路由路径、cache 命中率、prefill/decode 阶段时长

存储层:

• 短期(7 天):OpenTelemetry → Prometheus,7 天原始数据
• 中期(30 天):Thanos/Cortex,30 天降采样数据
• 长期(1 年):Parquet + S3,1 年异常样本归档

告警层:

• 必告警:错误预算消耗速率 > 2x 正常 → 紧急
• 推荐告警:P99 延迟突增 20% → 提醒
• 高级告警:SLO 违约率 + 业务指标(用户流失、转化率)联合分析

可视化层:

• 必展示:实时 SLO 仪表盘、错误预算燃烧图、分位数分布热图
• 推荐展示:多模型对比 SLO 仪表盘、多区域 SLO 健康度
• 高级展示:SLO 违约与模型版本更新、流量事件、底层基础设施事件的时间线关联

复盘层:

• 必建立:每月 SLO 复盘会议,review 错误预算消耗与 RCA 报告
• 推荐建立:跨团队 SLO 协议 review,确保 SLO 目标与业务承诺一致
• 高级建立:SLO 数据驱动的容量规划与架构演进路线图

LLM 推理服务的 SLO 工程不是单一团队的责任,而是平台工程、模型工程、应用工程、运维工程四方协作的产物。它的成熟度直接决定 LLM 服务的商业竞争力——一个拥有稳定 SLO 协议的 LLM 服务,能在 99.9% 的时间里交付稳定体验,从而在用户留存、单位经济模型、运营成本三个维度同时建立护城河。

参考文献

1. Kwon, W., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023.
2. OpenTelemetry GenAI Semantic Conventions Working Group. (2025). GenAI Telemetry Specification v1.0.
3. Beyer, B., et al. (2016). Achieving Rapid Response Times in Large Online Services. Google SRE Book Chapter 7.
4. Serrano, N., & Brunn, J. (2021). The Site Reliability Workbook - Practical Ways to Implement SRE. O'Reilly.
5. Mauer, M., et al. (2024). Sloth: Automating SLO Generation from Service Definitions. CNCF TAG Observability Whitepaper.
6. Yu, G., et al. (2024). Speculative Decoding for Production LLM Serving. MLSys 2024.
7. Kouris, A., et al. (2024). KServe: Cloud-Native Model Serving for LLMs. KubeCon EU 2024.
8. Anthropic Engineering. (2025). Production Practices for LLM Inference at Scale. Anthropic Engineering Blog.
9. OpenAI Engineering. (2024). LLM Inference Optimization: From Continuous Batching to KV Cache Compression. OpenAI Engineering Blog.
10. vLLM Project. (2025). vLLM v0.6 Production Deployment Guide. vLLM Documentation.
11. Lightning AI. (2025). LitServe: Multi-Model LLM Serving Architecture. Lightning AI Documentation.
12. Microsoft Azure. (2024). Multi-Region LLM Deployment for High Availability. Azure Architecture Center.

一句话摘要:把 LLM 推理服务的延迟分位数、错误预算、吞吐与成本组合成 SLO 三元组,通过 SLO 驱动的自适应弹性、跨区域多模型协同、可观测性闭环,把可靠性从经验运维升级为可量化、可监控、可演化的工程闭环。