执行模型#

执行模型部分会处理 token generation loop 本身，包括 sampling、speculative decoding、前后处理与 decode 阶段的衔接。它与请求生命周期相关，但不相同：生命周期关心请求怎样穿过系统，执行模型关心模型在一次生成过程中怎样推进状态。

这一节的核心不是重复“请求怎么进来”，而是解释：当 request 已经被 scheduler 组织成 batch 之后，ForwardBatch 怎样驱动一次 prefill / decode，SamplingParams 怎样影响 next-token 选择，以及 speculative decoding 怎样把“先草拟、再验证”的路径插入同一循环。

本节包含什么#

本节第一章是 5.1 Token 生成循环与执行模型。这一章会把 ScheduleBatch -> ModelWorkerBatch -> ForwardBatch 的数据结构转换、ModelRunner.forward(...) / sample(...) 的职责边界，以及 speculative decoding 的插入点放到同一张图里看，避免把“调度”和“执行”写成同一个问题。

这一节与前后章节的关系#

这部分紧跟在 4. 调度与内存 之后，是因为 batch 已经形成以后，才有必要谈 token loop 内部怎样推进；又必须放在 6. 结构化生成与 API 之前，因为后者依赖这一节解释“约束”究竟插在执行链的哪个环节。把顺序固定下来，能避免不同章节反复重复同一个 decode 过程。

本节对应哪些代码路径#

这一节的主锚点包括 python/sglang/srt/model_executor/forward_batch_info.py、python/sglang/srt/model_executor/model_runner.py、python/sglang/srt/sampling/sampling_params.py、python/sglang/bench_one_batch.py 与 docs/advanced_features/speculative_decoding.md。它们共同回答的是“token 怎样被生成”；这样设计的原因，是为了把 execution loop 与前面的 scheduler 逻辑明确分层。