Mini-SGLang 源码阅读（二）：Scheduler、Continuous Batching 与 Chunked Prefill
在线 LLM 调度器要回答的不是“下一个运行哪个进程”，而是：这一轮把哪些请求、哪些 token 放入同一个 GPU batch，并确保显存、KV Cache 和计算预算都不超限。 本文先建立 Continuous Batching、Chunked Prefill 与 Overlap Scheduling 的理论模型，再阅读 Mini-SGLang 的 Scheduler 实现。源码基于提交 9a91cfa。 一、调度器面对三种资源 LLM 请求至少消耗三类资源。 第一是计算量。Prefill 的计算大致随输入 token 数增长，Decode 每个请求每轮只增加一个 token。 第二是 KV Cache。一个请求即使本轮只计算一个 token，也必须继续持有全部历史 K、V。 第三是 batch 槽位和 CUDA Graph 形状。请求数、总 token 数和序列长度都会限制可执行 batch。 因此 Scheduler 需要同时维护两个预算： 本轮计算预算：最多处理多少新 token 长期缓存预算：这些请求最多还会占多少 KV 页 只看当前空闲页是不够的。如果 Prefill 阶段把缓存全部吃完，已经进入 Decode 的请求可能无法继续生成。 二、Continuous Batching 的状态划分 Mini-SGLang 将请求分成两个主要集合： waiting queue：尚未完成 Prefill，等待进入 GPU running batch：已经 Prefill，正在逐 token Decode 传统静态 batch 的生命周期以“整批”为单位；Continuous Batching 的生命周期以“请求”为单位。某个请求完成后立即离开，空出的槽位可以接纳新请求。 ...