5.1 Token 生成循环与执行模型

Mon, 01 Jan 0001 00:00:00 +0000

Token 生成循环与执行模型#

这章解决什么问题#

这一章解决的不是“请求怎样进入系统”，而是“一个 batch 已经准备好之后，模型前向、logits 处理、sampling 和 decode 怎样接起来”。如果没有这层理解，前面的生命周期和架构章节会告诉你请求经过了哪些模块，但你仍然不知道真正生成 token 的那一轮循环是如何推进的。

这里最重要的切分是：调度器决定“这轮应该跑谁”，执行模型决定“这一轮怎样跑”。也正因为这样，本章不再讨论请求排队和 KV 复用策略，而是把注意力放在 ForwardBatch、ModelRunner.forward(...)、LogitsProcessorOutput、sample(...) 和 speculative decoding 的关系上。

为什么执行模型要单独成章#

源码已经明确把调度层和执行层拆开了。python/sglang/srt/model_executor/forward_batch_info.py 文件头直接写出数据流：ScheduleBatch -> ModelWorkerBatch -> ForwardBatch。这说明调度器并不直接操作模型前向所需的低层 tensor，而是先把请求集合组织成更高层的 batch，再逐步降到执行层。

这类设计有很强的工程理由。调度器关心的是 waiting queue、running batch、prefill / decode 切换与 token 预算；执行层关心的是当前轮 forward 需要哪些 tensor、哪些 logits 要被处理、下一步 sample 该如何产生 next token。如果把这两层揉在一起，调度逻辑会污染执行细节，执行细节又会反向拖慢调度路径。

下面这张图专门解决“调度结束后，执行模型内部到底怎样推进”的理解障碍。它比纯文字多解释了两个关键点：一是 ForwardBatch 在循环里的位置，二是 speculative decoding 并不是另一条完全独立的 pipeline，而是嵌在同一执行链里的模式分支。

flowchart LR
 A["ScheduleBatch"] --> B["ModelWorkerBatch"]
 B --> C["ForwardBatch.init_new(...)"]
 C --> D["ModelRunner.forward(...)"]
 D --> E["LogitsProcessorOutput"]
 E --> F["sample(...) / next token"]
 F --> G["decode continuation"]
 G --> C
 C -. TARGET_VERIFY / DRAFT_EXTEND .-> H["speculative decoding path"]
 H -. verify / accept / reject .-> F

读这张图时，最重要的是看清闭环：batch 进入 ForwardBatch，前向产生 logits，sampling 选出 next token，随后又回到下一轮 decode。speculative decoding 并没有打破这个环，而是把 “verify / draft extend” 插进了 ForwardBatch -> sample 之间。

5. 执行模型 on Machine Learning 学习笔记

5.1 Token 生成循环与执行模型

Token 生成循环与执行模型#

这章解决什么问题#

为什么执行模型要单独成章#