推理优化正文
页面目标
这页不是再重复目录，而是把推理优化专题里最常见的三类问题展开成可操作的判断路径：
- 长 prompt 为什么慢
- 生成阶段为什么吞吐不高
- cache 为什么一边跑一边涨
适用人群
- 想理解推理框架、推理引擎和优化点关系的人。
- 正在看长上下文、生成速度、KV cache 或吞吐问题的人。
- 想把推理优化和 benchmark 结果对齐的人。
不适用人群
- 只关心训练，不关心推理链路的人。
- 只想抄一个优化名词，但不想看请求和缓存代价的人。
- 还没有 decode、cache、batch 基本概念的人。
你应该如何开始读
- 先读
2.6 -> 20 -> 21 -> 22，把推理优化的基础主线串起来。 - 如果你关心长上下文和 cache，再看
22 -> 36 -> 41。 - 如果你关心生成阶段吞吐，再看
21 -> 37 -> 38。 - 最后用
31 / 2.9验证优化是不是在真实场景里成立。
故事线
一个典型的推理优化故事，通常从用户抱怨“长 prompt 一进来就很慢”开始。第一次排查时，大家常会盯着 decode，觉得是采样或生成策略出了问题；但一上 profiling，真正的瓶颈往往分成三层：attention 太重、KV cache 在涨、调度没有把 prefill 和 decode 排顺。
第一步先看 2.6 -> 20 -> 21 -> 22，确认基础推理链路到底是哪里慢。 第二步再看 22 -> 36 -> 41，确认 cache 能不能复用、分页和驱逐是否合理。 第三步再看 21 -> 37 -> 38，确认生成路径和调度是否在浪费吞吐。 最后把这些策略回到 31 / 2.9，看看优化是不是在真实请求分布里成立。
这个故事的关键不是“有多少推理技巧”，而是把技巧放回一个真实请求链路里看：谁在训练，谁在组织请求，谁在真正吃掉算力和缓存。
具体案例
案例 1：长 prompt 进来后首 token 延迟高
现象是：prompt 长度一上去，首 token 延迟明显升高，但 decode 阶段的单 token 速度看起来还行。
判断链路是：先看 20 -> 22，确认 attention 和 KV cache 是否已经在长上下文下被放大；再看 36 -> 41，确认前缀复用和 cache 驱逐有没有跟上。
结果通常有两种：
- 如果
prefill占比特别高，问题多半在 attention 计算和前缀组织。 - 如果 cache 增长快但复用低，问题多半在请求组织和驱逐策略。
这个案例的重点是：首 token 慢不等于 decode 慢，必须先把 prefill 和 cache 分开看。
案例 2：生成阶段吞吐不高
现象是：单个请求看起来没问题，但并发一高，整体吞吐就上不去。
判断链路是：先看 21 -> 37 -> 38，确认采样、草稿验证和调度有没有把 token 产出节奏排顺。
常见结论是：
- 如果草稿模型质量不够， speculative decoding 反而会吃掉收益。
- 如果调度没把 prefill / decode 分开排， token 产出会被请求顺序拖住。
这个案例的重点是：吞吐问题往往不是“模型不够快”，而是“请求组织不够顺”。
案例 3：优化看起来有效，但线上不稳定
现象是：benchmark 上看起来提速了，但线上请求一换，收益就掉下去。
判断链路是：先回到 31 / 2.9，确认 benchmark 口径和线上请求分布是不是一致；再看 22 -> 36 -> 41，确认 cache 命中条件是否被请求形态放大或削弱。
这个案例的重点是：推理优化不是只看单条曲线，而是看请求分布、缓存命中和调度策略能不能一起成立。
栈位关系
推理优化不是单独的一层，它通常嵌在训练框架、推理框架和推理引擎之间。
| 栈位 | 主要职责 | 和本专题的关系 |
|---|---|---|
| 训练框架 | 训练、微调、导出模型权重 | 提供上游模型和结构约束 |
| 推理框架 | 加载模型、组织请求、处理解码流程 | 负责把模型接入推理场景 |
| 推理引擎 | 调度、KV cache、kernel 路径和执行效率 | 是优化最直接的落点 |
专题主线
这页不是按单页罗列，而是按“问题 -> 机制 -> 调度 -> 验证”的链路来读。
| 主线 | 关注的问题 | 适合先看 |
|---|---|---|
| 计算主线 | attention 怎么算得更省、更稳 | 20 -> 22 -> 31 |
| 解码主线 | 生成时怎么选 token、怎么减少重复计算 | 21 -> 37 |
| 缓存主线 | KV cache 怎么复用、怎么分页、怎么调度 | 22 -> 36 -> 41 |
| 吞吐主线 | 怎么把 prefill / decode / batch 排布得更高效 | 36 -> 38 -> 31 |
| 高级生成主线 | speculative / multi-token / scheduling 怎么串起来 | 2.7A -> 37 -> 38 |
一页速记
| 层级 | 你主要关心什么 | 在本专题里怎么看 |
|---|---|---|
| 训练框架 | 模型是怎么训练出来、怎么导出权重的 | 只看它作为上游来源，不在这里展开训练细节 |
| 推理框架 | 模型怎么被加载、请求怎么被组织、解码怎么走 | 先看 2.6 / 2.7A，再看请求和解码策略 |
| 推理引擎 | 调度、KV cache、kernel 路径和执行效率 | 重点看 22 / 36 / 38 / 41 这条线 |
建议阅读顺序
- 先看
2.6 -> 20 -> 21 -> 22，把 attention、decode 和 cache 的基础行为对上。 - 再看
2.7A -> 36 -> 37 -> 38 -> 41，把前缀复用、高级生成和调度串起来。 - 最后回到
31 / 2.9，确认方法层判断能不能在 benchmark 里兑现。
典型案例
长 prompt
长 prompt 的核心不是“token 多”，而是 attention 成本和 KV cache 一起上来。优先检查 20 -> 22，看 attention 是否已经做了分块/在线 softmax 级别的优化，再看 36 -> 41，判断前缀复用和 cache 驱逐有没有跟上请求结构。
生成慢
如果是生成慢，通常要看 21 -> 37 -> 38。采样策略决定生成路径，草稿-验证决定 token 产出节奏，调度决定 prefill 和 decode 是否能排顺。很多场景不是模型本身慢，而是请求组织没有把吞吐挤出来。
显存持续涨
如果 cache 持续涨，重点看 22 -> 36 -> 41。要先分清是 KV cache 的自然增长，还是前缀复用不足、驱逐策略太保守、batch 组织不合理造成的额外占用。
框架与引擎
推理优化不是孤立发生的，它通常发生在一条链路里：
- 训练框架先把模型训练出来，或者把微调后的权重导出。
- 推理框架负责把模型加载进来，并把请求、解码和基础 serving 逻辑组织起来。
- 推理引擎再往下接管调度、KV cache、kernel 路径和执行效率。
所以，当你在看 FlashAttention / PagedAttention / Prefix Caching / Decode Scheduling 时，不要只问“算法怎么写”，还要问“它落在推理框架层还是引擎层”。
前者更偏接口、请求和流程组织，后者更偏执行、缓存和吞吐。
典型阅读链
- 如果你想先理解推理慢在哪里，先读
20 -> 22 -> 31，把 attention、cache 和收益验证先串起来。 - 如果你想先理解生成阶段怎么做决策，先读
21 -> 37，把采样策略和多 token 生成连起来。 - 如果你想重点看 cache 生命周期和调度，先读
22 -> 36 -> 41，把分页、前缀复用和驱逐策略连起来。 - 如果你想看吞吐和延迟怎么一起优化，先读
36 -> 38 -> 31，把 prefill、decode 和 benchmark 连起来。 - 如果你想看更强的生成加速，先读
2.7A -> 37 -> 38，再回到31看收益是否成立。
对照表
| 场景 | 先看什么 | 重点差异 |
|---|---|---|
| 长 prompt | 20 -> 22 -> 31 | 看 attention 成本和 cache 增长 |
| 生成慢 | 21 -> 37 -> 38 | 看采样、草稿验证和调度 |
| cache 变大 | 22 -> 36 -> 41 | 看复用、分页和驱逐 |
| 想提吞吐 | 36 -> 38 -> 31 | 看 prefill / decode 排布 |
| 想接更强生成 | 2.7A -> 37 -> 38 | 看策略复杂度和接受率 |
进一步展开
1. 先看请求阶段
prefill占比高时，先关注 attention 和前缀复用。decode占比高时，先关注采样、草稿验证和调度。
2. 再看 cache 生命周期
- cache 的增长是否和 prompt 长度同步。
- 前缀是否真的被命中复用。
- 驱逐是否会误伤高复用请求。
3. 最后看工程化收益
- 是否真的提升了吞吐。
- 是否把延迟控制在可接受范围。
- 是否引入了过高的实现复杂度。
简单规则
- 先区分目标是降延迟还是提吞吐。
- 再区分瓶颈是在 attention、decode 还是 cache。
- 再看优化是否改变了请求组织方式。
- 最后用
31和2.9证明收益。
常见错误
- 只优化单个 kernel，不管请求调度。
- 只看理论提速，不看线上请求分布。
- 只谈 cache 省了多少，不谈调度复杂度增加了多少。
深入阅读
- 想看完整请求链路故事，去 推理优化深入阅读。
- 想快速回顾摘要、对照和 FAQ，继续留在本页即可。
相关专题
- Profiling 专题：当你先要证明慢点在哪里时看这里。
- 显存优化与性能调优专题：当推理优化和 KV cache、显存账本绑在一起时看这里。
- 编译与图优化专题：当优化更像 backend、fusion 或调度问题时看这里。
小结
推理优化的核心不是“有多少技巧”，而是“哪类请求适合哪条链路”。这页的作用是把技巧放回问题里看，而不是单独看概念。