推理优化
11.2 优化组合注意事项：技术叠加不等于效果叠加
优化技术叠加的冲突分析（投机解码×量化、连续批×投机、TP×量化）、推荐优化顺序（OOM→TTFT→TPOT→尾延迟）与配套清单
技术叠加冲突分析优化顺序投机解码量化
决策树告诉你”每个症状选什么技术”，11.2 回答更棘手的问题：多个技术叠在一起会怎样。现实是：技术叠加不是加法，有协同、有冲突、有互相抵消。这一节讲清三类关系——协同、冲突、中性——并给出推荐的优化顺序。
📑 目录
1. 技术叠加的三种关系
① 协同（1+1 > 2）：互相放大
例：前缀缓存 + 前缀感知路由 → 命中率更高（10.3）
量化 + 投机解码 → 草稿模型也变小 → 都变快
② 冲突（1+1 < 2 甚至 < 1）：互相抵消或产生新瓶颈
例：投机解码 + 量化 → 草稿精度下降，接受率暴跌
投机解码 + 连续批 → 草稿批次占用调度槽
③ 中性（1+1 ≈ 2）：独立生效，无交互
例：Continuous Batching + 前缀缓存（各自管各自的维度）📌 关键点：叠加技术前先判断关系类型。冲突组合不是”不能用”，而是”要调参/换配置”；协同组合值得优先做。判断依据：两个技术是否争抢同一个资源（KV、调度槽、通信带宽）。
2. 已知冲突案例逐个拆解
2.1 投机解码 × 量化（第 5 章 + 第 4 章）
冲突机制：
投机解码依赖草稿模型与目标模型的分布一致（接受率，5.4 章）
量化降低草稿模型精度 → 草稿与目标分布偏差变大 → 接受率下降
→ 加速比缩水，甚至负收益
数据（5.5 章经验）：EAGLE-3 在 FP16 下接受率 ~0.8+
量化到 INT4 后，接受率可能跌到 0.5 以下 → 加速比从 2.5x → 1.3x
对策：
① 草稿模型保持高精度，只量化目标模型
② 量化后重测接受率（spec_decode_num_accepted_tokens / num_draft_tokens）
③ 接受率 < 0.5 时关掉投机，直接量化更划算2.2 投机解码 × Continuous Batching
冲突机制：
投机解码的草稿验证需要一次前向算多个 token 位置
与连续批的"动态插入新请求"争抢调度槽 → 批次碎片化
对策：
① 确认引擎对投机请求的批处理兼容性（v0.26 支持但需验证）
② 压测对比：纯连续批 vs 连续批+投机 的吞吐曲线
③ 高并发下投机收益天然缩水（批次已满，验证并行度低）——低并发延迟敏感场景才划算2.3 TP × 量化（第 6 章 + 第 4 章）
关系：部分协同、部分冲突
协同面：量化减权重 → TP 通信量减半（第 6 章通信账）→ 扩展性变好
冲突面：INT8/FP8 的量化通信需要反量化与重量化（all-reduce 前）→ 通信里掺了转换开销
且 TP 切分后的每卡小矩阵，量化 kernel 的 tile 效率可能下降
对策：
① 先量化后 TP（权重先变小再切分，通信省）
② 用 FP8（硬件原生支持）而非 INT8 软件模拟，减少转换开销2.4 PD 分离 × 前缀缓存（第 7 章 + 第 3 章）
关系：潜在冲突（KV 传递机制不同）
冲突机制：
传统前缀缓存是"本实例 KV 块复用"
PD 分离时 prefill 与 decode 实例分离 → KV 要跨实例传递
→ 前缀缓存命中数据在 prefill 实例，decode 实例拿不到（除非 KV 连接器共享）
对策：
① 用 vLLM 的 KV 连接器（Mooncake 等，7.5 章）跨实例共享
② 或前缀路由把同前缀请求导到同一对 PD 实例（10.3）3. 协同组合清单
| 组合 | 协同机制 | 出处 |
|---|---|---|
| 量化 + 连续批 | 权重变小 → 显存腾出 → batch 更大 → 吞吐更高 | 4 章 + 2 章 |
| 量化 + TP | 权重变小 → 通信量减半 → 扩展性更好 | 4 章 + 6 章 |
| 前缀缓存 + 前缀路由 | 路由保证同前缀同副本，缓存才有机会命中 | 3 章 + 10.3 |
| 前缀缓存 + 量化 | 缓存命中 → prefill 近零，量化负担最小化 | 3 章 + 4 章 |
| PD 分离 + 量化 | prefill 实例算力型、decode 实例访存型，量化分别适配 | 7 章 + 4 章 |
| 投机解码 + PD 分离 | decode 实例做投机，草稿占用不拖累 prefill | 5 章 + 7 章 |
| 连续批 + 前缀缓存 | 正交：调度管批次，缓存管重复计算 | 2 章 + 3 章 |
💡 提示：协同组合的共通规律：资源类型不同就不冲突。量化省显存（与调度正交）、前缀缓存省计算（与批次正交）、路由管副本选择（与引擎正交）。判断组合是否协同，就问一句：它们争抢同一个资源吗？
4. 推荐的优化顺序
第 0 步：建基线（9.2 压测，没有基线不做优化）
第 1 步：解决 OOM / 稳定性（显存不够一切免谈）
量化（4 章）→ TP（6 章）→ Chunked Prefill（2 章）
第 2 步：解决 TTFT
前缀缓存（3 章）→ 队列/容量核对（10.3）→ Chunked Prefill
第 3 步：解决 TPOT / 吞吐
连续批调参（2 章）→ 量化深度（KV 量化）→ 投机解码（5 章）
第 4 步：解决尾延迟
PD 分离（7 章）→ SLO 调度 → 请求配额（10.3）
第 5 步：容量与成本（10.4），把节省的资源转成成本收益顺序的理由
| 顺序 | 理由 |
|---|---|
| 稳定优先 | OOM 会摧毁一切优化成果（服务不可用 = 0 收益） |
| 免费优先 | 前缀缓存、连续批调参是配置级，先榨干 |
| 结构优先 | PD 分离是架构级改动，放最后（影响面最大） |
| 验证伴随 | 每步压测对比基线，收益可归属（9.4 门禁） |
📌 关键点：优化顺序的本质是”风险从小到大的排序”：配置（改参数）→ 模型（量化，需重测精度）→ 架构（并行/PD，影响面大）。顺序反了，一次架构改动把前面所有收益掩盖，回归定位无从谈起。
5. 优化验证的纪律
每次只动一个变量：
✗ 同一次压测里同时开量化 + 投机 + PD（收益/损失无法归属）
✓ 一次只开一个，压测对比，记录，回滚点保留
收益必须量化：
记录：改动项、基线值、新值、收益百分比、副作用（精度/时延）
例子：
- 开前缀缓存：TTFT p95 2.1s → 1.2s（-43%），命中率 61%
- 权重 INT8：TPOT p95 45ms → 33ms（-27%），MMLU -0.3%
- 加 EAGLE-3：TPOT p95 33ms → 21ms（-36%），接受率 0.71
回归门禁（9.4）收尾：
把关键场景压测固化到 CI，技术叠加后跑一遍，退化即报警💡 提示：优化记录是团队资产：半年后没人记得当初为什么开/关某个 flag，只有记录能回答。格式不重要，字段齐全就行（改动、基线、结果、副作用、日期、负责人）。
📝 总结
- 三种关系：协同（资源正交）、冲突（资源争抢）、中性（独立生效）
- 经典冲突：投机 × 量化（接受率下跌）、投机 × 连续批（调度槽）、PD × 前缀缓存（KV 传递）
- 协同组合：量化×连续批、量化×TP、前缀缓存×前缀路由、投机×PD
- 优化顺序：基线 → OOM → TTFT → TPOT/吞吐 → 尾延迟 → 容量成本
- 验证纪律：一次一个变量、收益量化、回归门禁
🎯 自我检验清单
- 判断两个技术是协同还是冲突的标准是什么？
- 投机解码 × 量化的冲突机制与对策？
- 为什么先量化后 TP？（通信量减半）
- PD 分离下前缀缓存怎么跨实例工作？
- 推荐的优化顺序与每步的理由？
- 优化验证的纪律是什么？为什么一次只动一个变量？
📚 参考资料
- 本模块各章（冲突与协同均出自第 2-10 章原理）
- vLLM 官方文档：Performance Benchmarking（https://docs.vllm.ai/en/latest/performance/benchmarks/benchmarks.html）
- EAGLE-3 论文（接受率与量化敏感性分析）（https://arxiv.org/abs/2503.12014）