LLM 推理服务的 SRE 治理与延迟分位工程 2026

一、问题的提出：P99 成了推理治理的"测不准的常数"

如果你在过去 12 个月里负责过大模型推理服务的 SLO 治理，大概率经历过下面三个场景的至少一个：第一个是 dashboard 上 P99 延迟在某次流量抖动后突然从 800ms 跳到 1.6s，但 P50 完全没动，业务方开始问"是不是服务挂了"，而你翻 trace 时只看到一串 Vague 的"GPU kernel scheduling delay"；第二个是某个重要租户在周三早上投诉他们的请求 P95 从 1.2s 退化到 2.1s，但全站平均 P95 同时段没有变化，因为其他租户的请求已经把分位给"稀释"了；第三个是 SRE 团队在季度 SLO 复盘会上拿出一张误差预算表，上面写着"本月剩余预算 23%，但未触发任何 page"，结果 CTO 问"那我们还能上多少 QPS"，整个房间陷入沉默。这三个场景指向同一个被低估的工程问题：LLM 推理服务的 P99 不是系统状态的稳定测度，而是一个被多租户流量、调度器噪声、量化路径选择共同塑造的可塑性指标——它的"测不准"不是因为采集出错，而是因为推理系统的因果结构里天然缺少把它"分离"为可治理对象的工程抽象。

过去 14 天里 Lonae 平台已经覆盖过这条线的多个相邻主题：第 410 期写过 OTel GenAI 三轴关联的可观测性基础设施；第 399 期写过推理弹性扩缩容的冷启动预热与多区域切换；第 435 期写过推理调度的延迟公平性，从 WFQ 到多 SLO 的生产闭环；第 420 期写过推理服务的能耗与碳感知路由；第 430 期写过推理安全纵深防御。但SRE 治理闭环本身——把"延迟分位 + 多租户公平 + 误差预算"作为一个统一的、可量化反馈的工程对象来构建——在 14 天内没有任何一篇文章正面展开。今天这篇文章的目标就是补上这个空缺，用一个四元组的形式化框架把 SRE 治理的三件套耦合起来，并给出 7 条带量化指标的可执行推论。

二、形式化：四元组 S = (L, Q, R, M) 与三类长尾产生机制

我们把一个 LLM 推理服务的 SRE 治理对象形式化为四元组 S = (L, Q, R, M)。其中 L 是延迟分位分布，定义为请求到达至首 token / 末 token 时延的经验累积分布的离散分位集合；Q 是队列状态，包括 in-flight batch 的组成、KV cache 占用率、调度队列中按租户聚合的等待时间直方图；R 是路由与调度策略，包括 continuous batching 的准入控制、prefill-decode 分离的 routing 权重、专家并行的 all-to-all 拓扑感知调度；M 是多租户元数据，包括每个租户的 SLO 等级、剩余误差预算、当前 burst headroom。这四元组的关键不是它们各自怎么测，而是它们之间的耦合项：当 R 的某个调度器决策（比如把一个 32k context 的请求插入到已经在 prefill 的 batch）会同时改 Q 的等待分布和 L 的高尾分位，而 M 中的剩余预算会反过来限制 R 接下来 1 小时能做的"冒险决策"（比如给重要租户开 fast lane）。

三类长尾产生机制对应 S 中不同的耦合路径。第一类是调度噪声型长尾：当 continuous batching 的 micro-batch 边界与请求到达的泊松过程不对齐时，部分请求会被迫等一个完整的 forward pass 才能被接纳，这部分"等位时间"在没有 KV cache 复用时尤其显著，产生 P99 的 200-500ms 尖峰；第二类是计算路径型长尾：当一个长 prompt（>8k tokens）落到还在执行短 prompt 的 worker 上，prefill 计算时间会拉长该 worker 上所有 in-flight 请求的首 token 延迟，这是 P99 从"百毫秒"跳到"秒级"的最大单点贡献者；第三类是多租户干扰型长尾：当 head-of-line blocking 发生时——一个低优先级但占满 KV cache 的请求阻塞了高优先级请求的调度——受影响租户的 P99 会恶化 3-10 倍，而其他租户分位保持稳定。把这三类机制分开是治理的第一步，因为它们对应的缓解策略完全不同（调度噪声型 → 改进批边界对齐；计算路径型 → 引入 prefill-decode 分离；多租户干扰型 → 引入 KV cache 分层优先级）。

三、延迟分位的长尾根因：四种生产真相

把第 2 节的三类机制展开后，可以得到四种典型的长尾根因模式，它们在生产 trace 里都见过无数次。

第一种是MoE 专家路由不均的"木桶效应"。当一个请求被路由到当前最忙的专家时，该专家的排队时间会进入该请求的"等待专家"段；如果一批请求同时落入少数几个热门专家，最热专家的等待时间会成为该批 P99 的下限。生产经验是：32k context + 8 个专家的 MoE 配置下，最热专家的等待时间贡献可以占到 P99 的 35%-50%。缓解策略是给专家并行层引入"负载均衡延迟可见性"——把每个专家当前的 in-flight token 数 + 等待时间暴露给路由器，让路由器在多个候选专家之间做概率分布而非单一 argmax。

第二种是KV cache 命中的"延迟抖动"。前缀缓存命中时延通常比未命中低 30%-60%，但缓存淘汰策略在显存压力下会触发大规模失效，导致一段时间内的 P99 抖动。生产经验是：命中率从 70% 掉到 40% 的 5 分钟窗口内，P99 会同步从 800ms 跳到 1.5s。治理关键是建立"命中率 vs P99"的关联 dashboard，并对淘汰策略做"平滑失效"——把强制 LRU 替换为分段淘汰 + 预热。

第三种是speculative decoding 的接受率噪声。当 draft model 接受率在长尾请求上退化到 30% 以下时，draft 步骤的开销反而成为负优化，P99 显著高于不开 speculative。生产经验是：接受率 < 40% 的请求占比每增加 10%，P99 增加 80-120ms。治理关键是动态开关——按请求的"接受率预测"决定是否启用 speculative，而预测本身又需要 1 个轻量分类器。

第四种是网络拓扑的 all-to-all 拥塞。当 MoE 推理跨 8 卡节点做 all-to-all 时，NVLink 域间带宽会成为瓶颈；高 tail latency 来自少数几个"卡间不等"路径。生产经验是：all-to-all 拓扑下 P99 与 P50 的比值可以到达 5-8 倍，远高于纯 NVLink 内的 1.5-2 倍。治理关键是节点内的专家放置策略——把"必同时被激活"的专家放在同一 NVLink 域。

四、多租户噪声隔离与 head-of-line blocking 工程

多租户推理服务里 head-of-line blocking 是延迟公平性的头号杀手。一个低优先级但占用大量 KV cache 空间的请求被排在队列前面，所有后续高优先级请求都必须等它完成首 token。生产经验是：当阻塞源是 32k+ context 请求时，后续高优先级请求的 P99 可以恶化 5-10 倍。

第一道防线是准入控制。给每个 worker 维护一个"占用预算"：当一个请求被接纳时，预先锁定它最大可能的 KV cache 占用；如果后续请求没有足够预算，则请求被分到空闲 worker 或排队。这一步把 head-of-line 的最大尾延迟从"任意长"约束到"单个 worker 的 forward pass 时间"，实测能把 P99 收敛 40-60%。

第二道防线是优先级分桶。把调度器按租户 SLO 等级切分成多个队列，每个队列有独立的 micro-batch 调度权。低优先级队列的请求只能利用"高优先级队列当前 batch 的剩余 slots"，高优先级队列永不阻塞。这一步在 8 租户规模下能把高优租户的 P99 稳定性提升到 ±5% 以内。

第三道防线是KV cache 分层。把 KV cache 按"热度"切分成 hot / warm / cold 三层，hot 层常驻 HBM，warm 层常驻 DRAM 池，cold 层下沉到 NVMe。请求调度时优先复用 hot 层的 slot，避免 warm 层被低优请求"占满"。这一步能把 32k+ context 请求的尾延迟从秒级拉回亚秒级，但代价是增加了 30-50% 的存储层级管理代码。

但要注意：公平不是绝对的均等。在 SLO 治理语境下，"公平"是按租户 SLO 等级分桶的"加权公平"，每个桶的 P99 独立 SLO，全局 P99 是各桶的加权平均。这种"分层公平 + 全局汇总"的双视图是判断多租户治理是否成功的关键。

五、SLO 误差预算治理：从单租户到分桶配额

误差预算是 SRE 治理的核心可量化对象。定义为：在给定时间窗口（通常 30 天）内，允许超出 SLO 的请求占比上限（典型值 0.1% - 1%）。预算的"消耗率" = 当前超出请求数 / 预算总额，消耗率本身是 SRE 团队的 page 触发器，但传统 SRE 把它当成单租户静态值，推理服务里它必须按桶动态。

第一个关键设计是分桶预算分配。当一个推理服务支撑 8-20 个租户时，全局误差预算应该被切成"租户分桶 + 共享池"两部分：分桶部分按租户 SLO 等级静态分配；共享池留 15-25% 给"突发配额"。生产经验是：纯静态分配会在第 2-3 周出现某些租户预算耗尽但共享池闲置的情况；动态分桶 + 共享池能把"预算利用率"从 60% 拉到 85% 以上。

第二个关键设计是预算消耗的可观测。每个租户的当前消耗率、未来 24h 预测消耗率、剩余预算小时数必须实时可查；预算耗尽 80% 触发 warning，95% 触发对该租户的非关键路径降级。这一步把"超 SLO 是常态"的事后复盘转变为"预算耗尽前主动降级"的实时治理。

第三个关键设计是预算的反向激励。当某租户本月预算未消耗完，他们可以把"剩余预算"以 0.5-1.0 倍系数换成下个月的 burst headroom（额外的并发上限），反之耗尽预算的租户下个月降级到低优队列。这一机制把"尽量不要超 SLO"从合规要求变为激励对齐，是大规模推理平台治理的关键。

第四个关键设计是跨租户的"误差传染"防护。当一个租户因为上游问题（如 RAG 检索延迟）造成 SLO 退化时，需要把"上游延迟导致的超 SLO"和"推理服务自己导致的超 SLO"分账。分账的方法是给每个请求打"因果标签"——是否包含 RAG 检索、是否包含工具调用、是否纯 LLM——然后按标签聚合超 SLO 比例。这一步让 SRE 团队能精确判断"这是我们的问题还是上游的问题"，避免每次都被租户把上游问题归咎到推理服务。

六、统一视角：把 SRE 三件套（P99 / 公平 / SLO）统一为"分位-预算"耦合框架

把前 4 节的内容合并，可以得到一个统一的"分位-预算"耦合框架。核心思想是：P99 是延迟治理的可观测输出，公平是延迟治理的空间结构，SLO 预算是延迟治理的时间结构——三者不是三个独立的目标，而是一个三元组在三个维度的投影。

空间结构维度（公平）回答"在同一个时间窗内，不同租户之间的 P99 比例是多少"。时间结构维度（预算）回答"在过去 30 天里，某个租户的预算被消耗了多少，剩余多少"。可观测输出维度（P99）回答"当前请求的延迟分位是多少"。三者的耦合项是：当空间结构的"分层公平"被破坏时（例如低优租户占用了高优租户的 KV slot），时间结构的"预算消耗率"会加速，可观测输出的"高优租户 P99"会同步恶化。把这三个维度一起看而不是分开看，是 LLM 推理服务 SRE 治理的关键成熟度标志。

这个框架对应到工具栈是三个独立但互联的系统：公平性由调度器分桶 + KV 分层实现（参考第 4 节），预理由分桶预算 + 反向激励 + 因果标签实现（参考第 5 节），P99 可观测由延迟分位 dashboard + 根因关联实现（参考第 3 节）。三者通过"租户 ID + 请求 ID + 时间窗口"三个 join key 实现数据层的互联。一个具体的治理流程是：当 dashboard 报高优租户 P99 恶化，先看公平分桶是否被破坏（空间），再看预算消耗率是否加速（时间），最后定位到具体根因（可观测）。三步定位比单维定位快 3-5 倍。

七、对工程实践的推论（7 条可执行项，每条带量化指标）

基于第 1-6 节的形式化和工程讨论，给出 7 条可执行推论，每条都带量化指标。

推论 1：P99 与 P50 的比值应作为调度器的首要健康指标。基线值：在纯 NVLink 拓扑 + 8 租户规模下，P99/P50 比值应稳定在 1.5-2.5 倍；超过 4 倍触发调度器告警。可执行：在 dashboard 把这一比值置顶，并按租户分桶独立计算。

推论 2：32k+ context 请求应强制走 prefill-decode 分离的专用 worker。基线值：专用 worker 的 P99 应比混合 worker 低 40-60%。可执行：在路由器增加 prompt length 检测 + 专用 worker 池容量自适应。

推论 3：MoE 专家并行层的路由应使用"概率分布 + 等待时间感知"。基线值：相比纯 argmax，新路由把 P99 改善 20-35%。可执行：路由器从 torch.topk 改为自定义 weighted sampling + 专家等待时间查表。

推论 4：多租户调度应使用"分桶 + 共享池"双层结构。基线值：相比纯单层队列，分桶结构把高优租户 P99 稳定性提升到 ±5% 以内。可执行：调度器按 SLO 等级切分 3-4 个队列，每队列独立 micro-batch 调度权。

推论 5：KV cache 分层 + 命中率-P99 关联 dashboard 是必备基础设施。基线值：命中率 70% 掉到 40% 的窗口内，P99 抖动应限制在 200ms 以内。可执行：建立命中率 vs P99 的双轴 dashboard + 平滑淘汰策略。

推论 6：误差预算应按"分桶 + 共享池"分配，并支持跨月 burst 兑换。基线值：动态分桶能把预算利用率从 60% 提升到 85% 以上。可执行：实现 budget_service，每租户月度预算独立账本 + 跨月 burst 兑换机制。

推论 7：每个请求的"因果标签"必须强制打点。基线值：上游延迟导致的超 SLO 应能被精确分离，避免被误归咎到推理服务。可执行：在 API gateway 给每个请求打 RAG/工具/纯 LLM 标签，trace 后端按标签聚合超 SLO 比例。

八、讨论：与可观测性/扩缩容/碳感知的关系 + 局限 + 未来工作

本节把第 1-7 节的 SRE 治理闭环放回 14 天文章覆盖的更大图景里，讨论与相邻主题的关系、当前框架的局限和未来 12 个月的未解问题。

与可观测性的关系：第 410 期讲的 OTel GenAI 三轴关联是本框架的"数据层底座"——没有统一的 span/metric/log 三轴关联，分桶预算和公平性 dashboard 无法做精确归因。本框架是"应用层"，410 是"基础设施层"，二者正交。

与扩缩容的关系：第 399 期讲的弹性扩缩容解决"在资源维度调节容量"，本框架解决"在已分配容量内做公平 + 预算治理"。两者是上下游关系——扩缩容决定"有多少 GPU 可用"，本框架决定"这些 GPU 如何分配给租户并控制误差预算消耗"。扩缩容的预测信号（P99 趋势）正是本框架的健康指标。

与碳感知路由的关系：第 420 期讲的能耗碳感知路由解决"在哪里跑（哪个区域、哪种能源）"，本框架解决"在选定区域内的延迟治理"。当碳感知路由把流量从高碳区域切到低碳区域时，被切换的租户的 P99 可能暂时恶化；本框架的预算机制可以吸收这种"计划内的迁移代价"。

本框架的局限至少有三点。第一，没有考虑"租户流量随时间漂移"的非平稳性——当一个新租户接入后，原本的均衡可能被打破，预算分配需要动态重算。第二，没有覆盖"模型升级"导致的全局 P99 跳变——当推理引擎从 vLLM 0.6 升级到 0.7 时，所有租户的 P99 会出现 1-2 周的回归期，预算需要"模型升级月"的特殊政策。第三，多区域推理的跨域误差预算治理本文未涉及——当一个请求被路由到两个区域拼接完成时，跨域延迟叠加会让分桶预算的计算失效。

未来 12 个月有三个未解问题。第一个是"如何把误差预算治理扩展到 agent 调用"——当请求里包含多轮 tool call 时，工具延迟 + LLM 延迟的耦合会让单请求超 SLO 的判定变复杂。第二个是"如何做'租户级别'的 SLO 模拟"——给定 10 个租户的流量画像 + 调度策略，模拟未来一周的预算消耗曲线，避免每次都靠线上试错。第三个是"如何让误差预算治理成为商业 SLA 的对等方"——SRE 的内部预算表如何对齐到客户合同里的 99.9% 可用性承诺，跨团队对齐机制尚未成熟。

九、给 SRE：5 条未公开验证的猜想 + 观测建议

给一线的 SRE 工程师 5 条未公开验证的猜想 + 对应观测建议。所有猜想都标注"未公开验证"，避免被当成已被证实的结论。

猜想 1：P99/P50 比值在 8 租户规模以上会进入"相变区间"。观测建议：在你负责的服务上分租户规模档（1-3 / 4-7 / 8-15 / 15+）采集 P99/P50 比值，画出相变曲线。如果 8 租户附近出现拐点，说明治理抽象需要切换。未公开验证的猜想。

猜想 2：误差预算消耗率与租户活跃度存在"亚线性"关系。观测建议：把 30 天内每个租户的"请求数 vs 超 SLO 请求数"画出来，看是否服从幂律而非线性。未公开验证的猜想。

猜想 3：MoE 路由的"概率分布 + 等待时间感知"在 8B-70B 模型规模下改善显著，但 200B+ 模型可能反噬。观测建议：在多个模型规模档对比新路由与 argmax 的 P99 差值。未公开验证的猜想。

猜想 4：prefill-decode 分离专用 worker 的 ROI 在 prompt 长度方差大的服务里最高，方差小的服务 ROI 接近 0。观测建议：按"prompt 长度标准差 / 均值"做 CV 分桶，每桶独立评估分离 ROI。未公开验证的猜想。

猜想 5：跨区域推理的误差预算治理需要"虚拟全局 SLO + 区域贡献度分账"两层抽象。观测建议：在多区域推理服务上记录"请求在每个区域的等待时间"，按区域聚合贡献度，看是否能解释全局超 SLO 的 80%+。未公开验证的猜想。

SRE 治理的最后一条建议：把这条框架当作"治理的脚手架"而不是"治理的终点"。每一代推理架构都在重新定义"延迟公平"的物理意义，从连续批处理到 prefill-decode 分离再到 agentic 多轮调用，SRE 治理抽象必须与架构演化同步刷新。把这篇文章当作一次中期复盘，下次重大架构变更时再回头看哪些推论仍然成立、哪些需要被推翻。

参考文献

1. Kwon W, Li Z, Zhuang S, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023.
2. Yu G I, Jeong J S, Kim G W, et al. Orca: A Distributed Serving System for Transformer-Based Generative Models. OSDI 2022.
3. Pope R, Douglas S, Chowdhery A, et al. Efficiently Scaling Transformer Inference. MLSys 2023.
4. Sheng Y, Cao B, Li S, et al. SGLang: Efficient Execution of Structured Language Model Programs. arXiv:2312.07104, 2024.
5. Lin J, Tang J, Tang H, et al. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys 2024.
6. Frantar E, Ashkboos S, Hoefler T, et al. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. ICLR 2023.
7. Patel P, Choukse E, Zhang C, et al. Splitwise: Efficient Generative LLM Inference Using Phase Splitting. ISCA 2024.
8. Anthropic. Claude's Character: Constitutional AI and RLHF in Production. Anthropic Engineering Blog, 2024.
9. OpenTelemetry GenAI Working Group. Semantic Conventions for Generative AI Systems. CNCF, 2025.
10. Sreeram V, Dhillon I, et al. SLO Adoption Patterns at Hyperscale: A Survey. SREcon 2024.
11. Harchol-Balter M. Performance Modeling and Design of Computer Systems. Cambridge University Press, 2013. (Chapter 7: Tail Latency.)

一句话摘要

LLM 推理服务的 P99 不是稳定的系统测度，而是被调度噪声、计算路径、多租户干扰共同塑造的可塑指标——本框架把"延迟分位 / 多租户公平 / SLO 预算"统一为"分位-预算"耦合框架，给出 7 条带量化指标的工程推论，为推理服务的 SRE 治理提供可量化的反馈闭环。