调度策略、延迟控制与 batch 成形#

这章解决什么问题#

Scheduler 的主循环回答的是“这一轮怎么推进”，但这仍然没有完全解释“为什么某些请求会先进去、某些请求要等等、为什么 batch 长成了现在这个形状”。这部分真正属于调度策略，而不只是 scheduler 的主流程。

这一章要解决的，就是“batch 是怎样被政策性塑形的”。只有把这一层讲出来，读者才会知道 runtime 行为不只是由实现逻辑决定，也受调度策略、timeout、priority 和 prefill 延迟控制影响。

为什么调度策略不等于 scheduler 主函数#

很多人一看到 Scheduler，就会把所有调度问题都压到 get_next_batch_to_run() 上。但从源码组织看，schedule_policy.py、prefill_delayer.py、runtime checker mixin 等路径都在参与塑造最终 batch。换句话说，主函数负责“推进”，策略层负责“如何推进更合适”。

这也是为什么好技术书不会满足于解释一个主流程函数。真正的运行时行为往往来自主流程和策略层共同作用，而不是某个 central function 单独决定。

timeout、priority 与延迟控制的角色#

像 prefill_delayer.py 里 wait_timeout 一类输出理由，说明系统会把“是否延迟某类 prefill”显式变成策略问题。priority scheduling、queue shaping 和超时窗口同样如此。它们都在回答一个更高层的问题：系统应该为谁的延迟负责，又该在什么条件下牺牲一点等待时间来换取更好的 batch 组织。

这类策略没有永远正确的答案，所以尤其适合技术书去讲 tradeoff。因为读者真正需要的不是“默认值是什么”，而是“为什么会有这些策略，它们会把系统推向哪种行为”。

一个更像运行时策略图的图示#

flowchart LR
    A["waiting queue"] --> B["priority / routing / policy filter"]
    B --> C["PrefillDelayer / timeout window"]
    C --> D["PrefillAdder / admission"]
    D --> E["ScheduleBatch shape"]
    E --> F["下一轮运行批次"]

这张图的职责不是重复 scheduler 主流程，而是让读者看到：batch 形成之前，还有一层“策略过滤”。也就是说，batch 不是自然长出来的，它是被 runtime 政策塑形后的结果。

本章对应哪些代码路径#

这一章最重要的锚点包括 python/sglang/srt/managers/schedule_policy.py、python/sglang/srt/managers/prefill_delayer.py、python/sglang/srt/managers/scheduler_runtime_checker_mixin.py、python/sglang/srt/managers/scheduler.py 以及 test/manual/test_schedule_policy.py 这类更接近策略行为的测试。

小结#

理解 batch 形成，不只要看 scheduler 怎么推进，还要看 runtime 为什么允许某些请求更早进入、某些请求暂时等待。把这层策略逻辑补进来后，调度章节就更接近真实运行系统，而不是只有一条“理想推进路径”。