为什么解码阶段要捕获图
解码阶段由大量小算子组成，逐个提交时的内核启动开销会摊薄吞吐。图捕获把这些序列录成一个整体一次提交，减少启动开销。多数引擎默认在解码阶段启用，排查兼容性问题时可以临时切到逐步执行做对照。
基本信息
| 适用平台 | 支持图捕获的推理引擎与对应的加速环境 |
|---|---|
| 默认状态 | 解码阶段通常默认启用 |
| 关闭方式 | 启动参数切到逐步执行模式 |
| 代价 | 捕获需要额外显存与固定的批形状 |
开关对照（示意）
开关对照（示意）
# 默认启用图捕获；排查兼容性问题时：
vllm serve <模型路径> --enforce-eager典型使用场景
- 性能排查：怀疑启动开销占比高时做开关对照
- 兼容性问题：某些算子组合与图捕获冲突，先关掉定位
- 升级验证：引擎升级后复测解码性能是否回归
- 显存紧张：捕获占用额外显存，容量边界上要权衡
两种模式对照
| 模式 | 优点 | 代价 |
|---|---|---|
| 默认捕获 | 启动开销低，解码吞吐更好 | 额外显存占用与固定形状限制 |
| 逐步执行 | 兼容性好，便于定位问题 | 内核启动开销上升 |
图捕获需要额外显存与固定形状的批次：对照实验能快速判断性能差异是否来自图捕获。
版本差异：捕获的批量档位与模式仍在演进，升级后用相同的压测脚本复测，确认解码性能没有回归。
关掉只是排查手段：定位完成后要评估能否恢复启用，长期关闭会让解码吞吐白白下降。
捕获的批量档位决定收益范围：档位覆盖不到的批次会退回逐步执行，压测要覆盖实际流量分布。
改了批参数要重新评估：档位与批大小绑定，参数变化会影响捕获是否还能命中。