4.1 Scheduler、批次与 KV Cache

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

Scheduler、批次与 KV Cache#

这章解决什么问题#

这一章解决的不是“请求从哪进来”，而是“请求已经进来之后，系统怎样决定谁先跑、谁继续跑，以及这些请求占用的 KV cache 怎样被映射、复用和回收”。如果没有这层理解，你读 scheduler.py 时会只看到大量条件分支；读 memory_pool.py 时会只看到张量分配；两边都看了，仍然不知道它们为什么必须一起工作。

这里最值得先抓住的事实，是 python/sglang/srt/managers/schedule_batch.py 文件头写出的那条数据流：ScheduleBatch -> ModelWorkerBatch -> ForwardBatch。这条注释说明调度阶段并不是直接操作 GPU forward 所需的最低层张量，而是先构造一个更高层的 batch 表示，再逐步降到执行层。调度与内存的配合，也正是围绕这条转换链组织的。

`Scheduler` 看的不是单个请求，而是“当前批次状态”#

python/sglang/srt/managers/scheduler.py 里的 Scheduler 初始化时会建立等待队列、running_batch、last_batch、tree_cache、req_to_token_pool 等状态。它不是简单地从队列里拿一个请求就调用模型，而是持续维护“现在已经在跑什么、下一轮还能塞什么、哪些请求应该进入 prefill、哪些请求应该继续 decode”。

get_next_batch_to_run() 很适合当作阅读入口。这个方法先处理 timeout、过滤完成请求、把上一轮 prefill batch 合并进 running_batch，然后决定本轮是取新的 prefill batch，还是推进已有 decode batch。也就是说，调度器真正管理的是 batch 生命周期，而不是单个 request 生命周期。

继续往下看 get_new_batch_prefill() 和 _get_new_batch_prefill_raw()，你会看到 PrefillAdder 被用来在 token 预算、batch 大小、LoRA 约束、priority scheduling 与 chunked prefill 之间做折中。这里的重点不是把每个条件背下来，而是理解：SGLang 把“能不能接新请求”建模成一次 batch 构造问题，而不是某个全局开关。

这部分如果只靠文字，很容易把 Scheduler、ScheduleBatch 和 cache 看成三块并列知识。下面这张图专门用来解释它们之间的状态流转关系：请求怎样从 waiting queue 进入 batch，batch 怎样触发前向，cache 怎样在这个过程中决定复用和回收。

4. 调度与内存 on Machine Learning 学习笔记

4.1 Scheduler、批次与 KV Cache

Scheduler、批次与 KV Cache#

这章解决什么问题#

Scheduler 看的不是单个请求，而是“当前批次状态”#

`Scheduler` 看的不是单个请求，而是“当前批次状态”#