第五章调度、批处理与 KV Cache on Machine Learning 学习笔记

5.1 waiting queue 与 batch shaping

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

waiting queue 与 batch shaping#

第二部分已经把请求怎样进入 runtime 讲清楚了。到了这一章，问题不再是“请求能不能进来”，而是“已经进来的请求为什么这一轮能跑、下一轮不能跑，为什么有些请求先 prefill，有些请求继续 decode，最终 batch 又为什么长成了现在这个样子”。

这一节只聚焦 waiting queue 和 batch shaping。更具体地说，它回答三件事：

scheduler 在等待队列里到底看什么；
ScheduleBatch 为什么是调度层和执行层之间的桥；
batch 形状是被哪些运行时约束共同塑造出来的。

一张图先看 batch 成形路径#

flowchart TB
 A["waiting queue"] --> B["Scheduler.get_next_batch_to_run()"]
 B --> C["prefill admission / decode continuation"]
 C --> D["ScheduleBatch"]
 D --> E["ModelWorkerBatch"]
 E --> F["ForwardBatch"]
 F --> G["ModelRunner.forward(...)"]

这张图里最重要的一点是：scheduler 并不是“从队列里取一个请求去跑”。它真正管理的是 batch 生命周期，而不是单个 request 的生命周期。

waiting queue 里的请求并不是平等排队#

如果只从表面看，waiting queue 很像普通队列。但在 SGLang 里，它更像一个等待被塑形的请求集合。Scheduler 真正关心的问题不是“谁先来”，而是：

当前还有多少 token 预算；
running batch 还剩多少可用空间；
现在是更适合接新 prefill，还是继续推进已有 decode；
某个请求带来的 cache、grammar、priority 或 multimodal 约束会不会把整轮 batch 推向更差状态。

这也是为什么第三章之后，第四章还要专门讲 Scheduler 这层边界：它不只是“执行前的最后一站”，而是 batch 政策真正开始发生的地方。

5.2 prefix reuse 与 cache 命中

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

prefix reuse 与 cache 命中#

很多人第一次读推理 runtime，会把前缀复用理解成一句很简单的话：如果两个请求前缀一样，就复用已有 KV。这个理解不算错，但远远不够。因为在真实运行时里，“命中了前缀缓存”并不自动等于“这一轮就更快”，也不自动等于“调度器就能更积极地接新请求”。

这一节只处理三件事：

prefix reuse 在 SGLang 里是怎样被表达的；
cache 命中的收益和调度推进是怎样互相影响的；
为什么前缀命中是 runtime 主能力，而不只是内存优化技巧。

一张图先看 prefix reuse 的位置#

flowchart LR
 A["Req / origin_input_ids"] --> B["tree_cache match"]
 B --> C["reuse committed KV"]
 C --> D["ScheduleBatch"]
 D --> E["ForwardBatch / ModelRunner"]

这张图最值得记住的一点是：prefix reuse 不发生在执行层末端，也不只是 cache 层内部动作。它在 scheduler 组织 batch 时就已经开始影响后续路径。

cache 命中不是一个布尔值，而是一条状态路径#

SGLang 在这一层真正依赖的是 tree_cache。而默认最重要的实现之一，就是 RadixCache 。

从 RadixCache 的初始化可以直接看出它背后的几件事：

它拿到 req_to_token_pool
它拿到 token_to_kv_pool_allocator
它知道 page_size
它有独立的 eviction policy

这说明“命中缓存”并不只是 dictionary lookup。它依赖的不是单个结构，而是一整套：

5.3 KV 生命周期、回收与驱逐

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

KV 生命周期、回收与驱逐#

前两节已经解释了 waiting queue 怎样塑形 batch，也解释了 prefix reuse 为什么不能被看成简单布尔命中。再往下走，就必须回答一个更物理的问题：这些请求背后的 KV 到底怎样被占用、引用、释放和驱逐。

这一节只处理三件事：

request 到 token，再到物理 KV 的映射是怎样建立起来的；
KV 在 extend、decode 和完成之后怎样继续存活或被释放；
cache 驱逐为什么不是简单的“空间满了就删最旧”。

一张图先看 KV 生命周期#

flowchart TB
 A["Req"] --> B["ReqToTokenPool"]
 B --> C["TokenToKVPoolAllocator / KVCache"]
 C --> D["ForwardBatch / ModelRunner"]
 D --> E["reuse / retain / evict"]

这张图最值得记住的一点是：KV 生命周期不是单独存在的一层，它和请求对象、调度对象、执行对象都绑在一起。

`ReqToTokenPool` 解决的是“谁占了哪些位置”#

ReqToTokenPool 的角色，很适合先用一句话固定下来：它负责“某个 request 当前占了哪些 token 位置”。

这件事为什么关键？因为对 runtime 来说：

逻辑上看到的是 request 和 token；
物理上管理的是 KV 槽位。

如果没有这层中间映射，scheduler 很难知道某个 request 释放时应该收回哪一段资源，cache 也很难知道自己命中的到底是哪组真实位置。

5.4 LoRA 热加载与 adapter 路由

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

LoRA 热加载与 adapter 路由#

LoRA（Low-Rank Adaptation）是当前主流的模型微调方法之一，它不修改基础模型权重，而是通过插入小型的低秩矩阵来实现对特定任务的适配。SGLang 支持在运行时动态加载 LoRA adapter、在不同请求间切换 adapter，以及同时维护多个 adapter 的活跃状态。

这一节回答三件事：

LoRA 的权重结构是什么，以及它在推理时如何工作；
SGLang 怎样在单次 forward pass 中同时处理多个使用不同 adapter 的请求；
LoRA adapter 的生命周期（加载、路由、卸载）在代码里落在哪里。

LoRA 的权重结构#

LoRA 不修改原有参数，而是为特定层（通常是 attention 的 Q、K、V、O projection 和 MLP 的 gate/up/down projection）添加两个小矩阵：

W_adapted = W_base + A × B

其中：
- W_base: [d_out, d_in]，冻结不变
- A: [d_out, r]，低秩矩阵，r << d_out
- B: [r, d_in]，低秩矩阵
- A × B: [d_out, d_in]，和 W_base 维度相同

r 是 rank（秩），通常取 8、16 或 32。当 r=16，d_in=d_out=4096 时，每层 Q projection 的参数量从 4096×4096 = 16M 降到 4096×16 + 16×4096 = 131K，压缩了约 122 倍。

第五章 调度、批处理与 KV Cache on Machine Learning 学习笔记

5.1 waiting queue 与 batch shaping

waiting queue 与 batch shaping#

一张图先看 batch 成形路径#

waiting queue 里的请求并不是平等排队#

5.2 prefix reuse 与 cache 命中

prefix reuse 与 cache 命中#

一张图先看 prefix reuse 的位置#

cache 命中不是一个布尔值，而是一条状态路径#

5.3 KV 生命周期、回收与驱逐

KV 生命周期、回收与驱逐#

一张图先看 KV 生命周期#

ReqToTokenPool 解决的是“谁占了哪些位置”#

5.4 LoRA 热加载与 adapter 路由

LoRA 热加载与 adapter 路由#

LoRA 的权重结构#

第五章调度、批处理与 KV Cache on Machine Learning 学习笔记

`ReqToTokenPool` 解决的是“谁占了哪些位置”#