S25：Burst、长上下文、Cache、Batch 与 Worker Loss

内容类型：预习教材（不代表已完成）
日期：2026-12-17
阶段：P2 · AI Systems Engineering 90
总路线：Day 115 / 360
周次 / 节奏：W4 · 周四案例与连接
状态：教材已备；学习未完成
主题：capacity、degradation、worker failure、user experience

一句话定义

Serving 容量不是一个固定 QPS，而是模型、请求长度分布、cache、batch、worker 数与延迟目标共同定义的可持续服务区域；超出后必须排队、降级或拒绝。

学习目标

1. 能分析 burst、长上下文、KV cache 压力和 worker loss 的传播路径。
2. 能区分 capacity、headroom、backlog 和 saturation。
3. 能为容量不足设计 admission、backpressure、load shedding 与降级顺序。
4. 能把技术信号连接到 TTFT、ITL、超时和业务体验。

核心知识

平均到达率低于平均服务率并不足以保证体验，burst 会在短时间积累 backlog。长 prompt 增加 prefill，长输出占用 decode slot 与 KV cache 更久；二者还会拖慢同 batch 的其他请求。Cache 命中可能减少重复 prefill 或模型调用，但 cache key、权限与 freshness 错误会引入质量和隔离风险。

Batch 提高资源利用率，却可能等待凑批、让短请求受长序列影响。Continuous batching 缓解固定 batch 边界，但 scheduler 仍要在 token budget、cache block 与公平性间选择。Worker loss 立即降低服务率，正在执行请求可能重试；若无幂等和退避，重试风暴进一步压垮剩余 worker。

降级应按语义设计：限制最大 context/output、使用较小模型、关闭非必要工具、返回缓存的许可结果、转异步队列或明确拒绝。高风险决策不能为了可用性跳过权限与关键验证。Backpressure 把容量信号传回上游，load shedding 主动丢弃/拒绝低价值工作，二者都优于无限排队。

机制与推导

容量余量可粗写：

[ headroom=1-\frac{offered_work}{service_capacity} ]

工作量应尽量按 prefill/decode token 或估计计算，而非只按请求数。队列动态：Q_(t+1)=max(0,Q_t+arrivals_t-completions_t)。Worker 从 N 降到 N-1 时，service capacity 下降；若到达不变，原本稳定系统可能越过饱和点。

Cache 价值可按 saved_compute - lookup/validation cost - stale/wrong-hit risk 思考。命中率高不必然更好，错误跨租户命中是严重问题。容量情景应同时观察 queue depth、TTFT p95、active tokens、cache occupancy、reject rate 和 retry rate。

最小练习或观察步骤

1. 构造基线、burst、长上下文、worker loss 四个纸面情景。
2. 对每个情景画 arrival→queue→worker→response，并标出容量变化。
3. 用 S23 simulator 改 arrival/service 或仅手算 backlog，记录方向性影响。
4. 为每个情景选择一个最早信号、一个用户指标和一个候选动作。
5. 给出明确降级顺序，并标注不可牺牲的安全/权限边界。

常见误区与边界

• 用平均 QPS 定义容量，忽略长度分布和 tail latency 目标。
• Worker 失败后无限即时重试，制造自激流量。
• 依靠 queue 吸收所有 burst，却没有最大等待和拒绝语义。
• Cache hit rate 高就认为系统健康，忽略错误命中与 freshness。
• 降级时跳过 authorization 或审计记录。

系统场景连接

市场事件或批量对账可能让金融 AI 请求突然上升。若实时欺诈解释与低优先级摘要共享容量，需要保留关键流量、延迟非关键工作，并明确用户可见状态。Web3 网络拥堵或 RPC provider 故障还可能拖慢工具阶段，服务容量需要把外部依赖纳入，而不只计算模型 token。

自检问题

1. 为什么容量要包含请求长度分布与 latency target？
2. Worker loss 怎样通过 retry 形成二次放大？
3. Backpressure 与 load shedding 分别做什么？
4. 哪些降级动作不能跨越安全边界？

专业课程对齐

• 阅读 vLLM 官方文档 的 scheduler、KV cache、distributed serving 与 metrics 内容，把 cache occupancy 和 active sequences 映射到容量情景。
• 阅读 Stanford CS329S 的 deployment、monitoring 与 failure 主题，把模型服务退化连接到用户和业务指标。
• 阅读 MIT 6.5840 的 fault tolerance 课程脉络，关注 worker failure、retry 与恢复为何会改变剩余系统负载。

深入学习提示

按“触发→资源状态→调度行为→用户信号→系统动作”写每个案例。特别画 retry 回路和 cache 错误命中这两个容易被平均指标隐藏的反馈。遇到厂商容量数据时，把模型、硬件、input/output 分布、并发、SLO 与失败假设补全。缺少任一关键条件，都只能作为参考点。

学后填写区

• 四个情景的容量路径：
• 最早系统信号：
• 用户可见影响：
• 我的降级顺序：
• 不可降级的边界：