执行模型的维护者视角：从 ForwardMode 到 trace 证据#

这章解决什么问题#

前几章已经把 execution model 的主要机制解释清楚了，但从维护者视角看，仍然缺少一个更实用的问题答案：当你怀疑问题落在 execution 层时，究竟应该先看 ForwardMode、graph runner、backend，还是 trace 证据？如果不把这条工作流写出来，execution model 仍然更像一组机制说明，而不是能带去现场的技术章节。

为什么执行层排障特别容易走偏#

execution 层的问题很容易伪装成别的问题。一个 graph runner 或 backend 的限制，可能表现成“性能退化”；一个 ForwardMode 的切换异常，可能表现成“输出不稳定”；一个 speculative path 的 verify / draft 状态不一致，也可能看起来像 scheduler 问题。

这就是为什么 execution model 需要一个维护者视角章节。它的作用不是重复机制，而是帮读者在怀疑 execution 层时更快找到正确观察面。

一条更像维护者的判断顺序#

现象：执行层异常
  -> 先问：当前 ForwardMode 是什么？
  -> 再问：当前走的是 eager、cuda graph 还是 piecewise path？
  -> 再问：attention backend / speculative path 是否改写了执行条件？
  -> 最后问：trace / profile 证据里最晚稳定成立的是哪一段？

这条顺序比“去看 model_runner.py”更重要，因为它先帮你决定“该带着什么问题去看 model_runner.py”。

本章对应哪些代码路径#

这一章最重要的锚点包括 python/sglang/srt/model_executor/forward_batch_info.py、python/sglang/srt/model_executor/model_runner.py、python/sglang/srt/model_executor/cuda_graph_runner.py、python/sglang/srt/model_executor/cpu_graph_runner.py、docs/advanced_features/attention_backend.md、docs/advanced_features/piecewise_cuda_graph.md 与 docs/developer_guide/benchmark_and_profiling.md。

小结#

execution model 讲到这里，不只是“知道它怎么跑”，还应该变成“知道它跑错时怎么想”。这一章补的正是这一步。