06 Serving 与性能：让整条链路满足服务目标
单个 kernel 更快、网络更快或缓存命中率更高，都不自动等于服务更好。本主题把调度、缓存、存储、传输和部署放回同一条请求时间线，以正确性、延迟、吞吐和成本评价组合。
配套设计：PD 与共享缓存关系图、专家系统设计题、存储容量和网络算例。
1. 先定义目标和负载
至少说明输入/输出长度、共享前缀比例、到达方式、并发、模型和精度，以及 TTFT/ITL 的 SLO。goodput 的单位和判定口径也要固定，例如每秒完成且满足约定延迟的请求数。
如果一组实验用固定并发，另一组用固定到达率，排队行为可能不同。若失败和超时请求被排除，尾延迟与吞吐也可能显得过于乐观。
2. 从时间线找瓶颈
进入服务 → 排队 → 查询/加载可复用状态 → Prefill → 首 token
→ 多轮 Decode → 完成
在每个阶段标出 CPU、GPU、网络和等待。实际阶段可以交错，分析时看关键路径与资源争用。先找到占比和限制，再决定改调度、kernel、缓存还是通信。GPU 侧的带宽、异步拷贝和分析工具见GPU 与 kernel 基础；按现象选优化手段见推理优化方法；框架怎样选见框架对比；上万张卡时的额外问题见万卡集群的挑战。
3. 常见优化的适用条件
| 优化 | 解决什么问题 | 必须检查的代价 |
|---|---|---|
| Attention kernel、融合、CUDA Graph | 访存、launch 或中间张量开销 | shape、后端支持、数值正确性和静态化约束 |
| 量化 | 权重/KV 容量、带宽或计算成本 | 质量、精度、转换开销及算子支持 |
| TP/PP/EP 等并行 | 单机装不下或单设备计算能力不足 | 通信、同步、拓扑、负载均衡与状态布局 |
| Prefill/Decode 分离 | 两阶段资源需求和延迟目标不同 | KV 交接、独立排队、容量比例和故障恢复 |
| 共享缓存 | 跨请求或副本复用计算 | 加载代价、热点、命名空间、容量和写入成本 |
| 缓存感知路由 | 把请求送到更可能命中的位置 | 热节点排队可能超过省下的计算 |
| 限流与背压 | 避免过载失控 | 拒绝/等待策略、公平性和重试放大 |
PD 交接解决“本次请求的计算状态交给谁”，共享缓存解决“以后哪些请求还能复用”。可以组合，但需要分别说明收益来源和数据协议。
4. 同层比较，再组合
比较引擎时固定模型、硬件、精度、工作负载和延迟约束；比较缓存方案时固定复用语义、布局、冷热状态和容量；比较传输时固定对象大小、并发和测量边界。
具体对照见组件选型。每次选型只回答一个有前提的问题，例如“这种长共享前缀负载下，host 缓存还是远端共享更合算”，不作无条件的框架排名。
5. 实现深读与验证
| 资料 | 用途 |
|---|---|
| vLLM 性能、并行与 Serving | 用具体引擎串起 profiling、GPU 优化、并行和部署 |
| LMCache 观测与运维 | 观察缓存链路、配置、资源和失败 |
| 运行时实现 | 回到调度和执行状态解释瓶颈 |
| 实验与报告 | 统一对照、正确性、原始数据和证据 |
验收时提交一张时间线、一张资源预算表、一个有收益的条件和一个不收益的条件。所有数字都应标明是推导、模拟还是实测。