推理优化深入阅读

主故事线

如果把这段优化写成完整排查过程，通常会这样展开：先有人说“首 token 太慢”，于是沿着 2.6 -> 20 -> 21 -> 22 去看请求到底卡在 prefill、attention 还是 cache；接着发现 KV cache 增长快但命中率不高，就顺着 22 -> 36 -> 41 看前缀复用和驱逐策略；再往下，生成阶段吞吐还是不理想，于是回到 21 -> 37 -> 38 检查采样、草稿验证和调度是否真的把 token 产出排顺；最后把这些改动放进 31 / 2.9 里跑一轮，确认提速不是只在单条 benchmark 上成立，而是在真实请求分布里也站得住。

端到端案例

一个更完整的推理优化过程，通常是从“线上首 token 慢、并发一高吞吐就掉”开始的。先沿着 2.6 -> 20 -> 21 -> 22 看基础推理链路，发现问题不是单纯 decode，而是 prefill、attention 和 cache 共同抬高了延迟；然后顺着 22 -> 36 -> 41 看前缀复用和 KV cache 的生命周期，发现 cache 的增长和驱逐没有跟请求形态对齐；再往下看 21 -> 37 -> 38，确认采样、草稿验证和调度有没有把 token 产出排顺；最后把这些改动放回 31 / 2.9 和真实请求分布里，看吞吐、首 token 延迟和稳定性是否同时改善。

阅读建议

• 先看这里，把“推理为什么慢”的链路故事读通。
• 再回到 推理优化正文 看摘要、对照和 FAQ。
• 如果问题更像显存、通信或 backend，也可以继续跳到对应专题。