苏黎世贝勒爷我先把结论放在前面：Chunked Prefill 不是某个框架独有的黑魔法，也不是一篇论文里突然冒出来的理论名词。在 vLLM、SGLang、TensorRT-LLM 这些主流推理引擎里，它已经是处理长输入、混合负载、高吞吐场景下的默认方案之一。如果你正在做 LLM 服务化部署，或者准备优化自家推理系统的首 Token 延迟和吞吐，这篇源码级别的拆解值得你花二十分钟读完。
我这次不会只停留在“Chunked Prefill 就是把 Prefill 切块”这个层面。我会从它到底解决了什么问题开始，把 vLLM 里的调度器实现、Continuous Batching 的交互逻辑、显存管理策略、Prefix Caching 的碰撞关系、以及和 PD 分离这种架构方案的对比，全部串起来讲清楚。看完之后你不仅知道它怎么用，还能直接打开源码找到对应的实现位置。
1. Chunked Prefill 到底解决了什么：一个被排队拖垮的 GPU 场景
先说一个所有做过 LLM 推理服务的人都会遇到的场景：你的 GPU 显存 80GB，模型 70B，线上并发请求一多，为什么 GPU 利用率上不去，但首 Token 延迟却高得离谱？
如果你打开 NVIDIA SMI 看，会发现 GPU 计算单元大量空闲，显存带宽也没有跑满。问题的根源往往不是模型算不动，而是调度策略把 GPU 饿死了。这时候 Chunked Prefill 就是用来解决“GPU 饿死”问题的。
1.1 Prefill 和 Decode 的计算特性差异：一个吃算力，一个吃带宽
LLM 推理过程分两个阶段。Prefill 阶段处理整段输入 prompt，一次性并行计算所有 token 的注意力，这个阶段计算密集，GPU 的 Tensor Core 能跑得很满。Decode 阶段逐 token 生成输出，每一步只计算一个 token，注意力部分还需要读取之前所有 token 的 KV Cache，这个阶段是典型的访存密集，GPU 计算单元大多数时候在等显存数据。
问题来了：如果你把 Prefill 和 Decode 用同一个 batch 混跑，Prefill 一个长请求可能占用几十毫秒甚至几百毫秒，Decode 请求在 batch 里只能干等。等 Prefill 算完了，Decode 才能继续。这就像一个单人流水线上突然插入一个大件，后面所有小件都被堵住了。
对于在线服务来说，这个等待直接转化为首 Token 延迟和每个 Decode 步的间隔拉长。体验上就是“问了问题之后半天才开始蹦字”，而且生成过程中还一顿一顿的。
1.2 经典的“等长批处理”和它的问题
早期推理框架都是等一个 batch 里所有请求都完成 Prefill，才开始 Decode。这个方案实现简单，但问题很明显：
- 长 prompt 请求会拖垮整个 batch 的 Decode 节奏
- 短 prompt 请求无法及时插队
- GPU 利用率呈现出剧烈的锯齿状波动：Prefill 阶段算力拉满，Decode 阶段算力闲置
如果把 Prefill 和 Decode 直接混在一个 batch 里，虽然能缓解一部分等待问题，但 GPU 的实际执行效率会下降。因为 Prefill 的矩阵乘形状和 Decode 完全不同，两者混在一个 kernel 里往往需要 padding，或者用低效的 shape 去跑。
Chunked Prefill 的思路就是：不把 Prefill 当一个整体，而是把它按 chunk 粒度拆开。每个 chunk 大小合适，既能填充 Decode batch 的剩余算力，又不至于让 Decode 等太久。这就像往流水线里塞小件，而不是一个大件。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. vLLM 里 Chunked Prefill 的调度核心：从 LLMEngine 到 Scheduler 的链路
vLLM 是目前实现 Chunked Prefill 最典型的开源参考。很多人以为 Chunked Prefill 是模型层或者 kernel 层的改进，其实它首先是调度层的设计。
2.1 入口：LLMEngine 的调度循环
vLLM 的 LLMEngine.step() 是整个推理循环的心脏。每次 step 调 Scheduler.schedule()，拿到一个 SchedulingOutput。里面有 scheduled_seq_groups、blocks_to_swap_in、blocks_to_swap_out、blocks_to_copy 这些关键数据。Chunked Prefill 的核心决策就发生在 Scheduler 内部。
在 vLLM 配置里，有一个参数叫 max_num_batched_tokens，还有一个叫 max_num_seqs。这两个参数直接控制 Chunked Prefill 的行为。max_num_batched_tokens 代表一个 step 里最多处理多少 token，如果模型支持，这个值可以设成大于 1 的值；max_num_seqs 代表一个 step 里最多有多少个序列。
默认情况下，如果你不显式开启 Chunked Prefill，vLLM 会把 Prefill 当作一个不可分割的整体。只有当 max_num_batched_tokens 小于当前 batch 里的 prompt token 总数时，调度器才会把一个 prompt 切分成多个 chunk。
code复制# 伪代码逻辑
def _schedule_prefills(self, budget):
for seq_group in waiting_queue:
if not budget.can_schedule(seq_group):
break
remaining_tokens = seq_group.get_seqs()[0].get_len()
if remaining_tokens <= self.scheduler_config.max_num_batched_tokens:
# 整个 prefill 可以放进一个 step
self._schedule_prefill(seq_group)
else:
# 需要 chunk 成多步
self._schedule_chunked_prefill(seq_group)
这段逻辑看着简单，真正的复杂度在 budget 的计算上。vLLM 用 SchedulingBudget 来追踪当前 step 已经占用的 token 数量和序列数量。每调度一个 seq_group，都要检查是否会超过 max_num_batched_tokens 和 max_num_seqs。
2.2 Scheduler 的预算计算：Chunk 大小是怎么定的
vLLM 的 Chunked Prefill 对 chunk 大小的计算很直接：seq_group 的 token 数超过剩余预算，就把超出部分切到下一个 step。每个 scheduler step 开始时，budget 会先处理 Decode 阶段的 token 占用，再考虑 Prefill 的可用空间。
code复制# vLLM 中 scheduler.py 的关键字段
self.max_num_batched_tokens = scheduler_config.max_num_batched_tokens
self.max_num_seqs = scheduler_config.max_num_seqs
在 _schedule_prefills 里，vLLM 会算一个 num_new_tokens。如果剩余 token 数大于可用的 max_num_batched_tokens，只调度一个 chunk 的 token 数。这样 Prefill 请求就会被切成多个 chunk，每个 chunk 都被当作一次独立的 Prefill 调度。
这里有三个容易忽略的细节：
- 第一个 chunk 的处理仍然遵循 normal priority，和普通 Prefill 没有区别
- 后续 chunk 的优先级路径不同，vLLM 会给这些“续跑”的 prefill 标注 priority，防止被新请求抢占
- Chunked Prefill 不影响 sequence 的 num_computed_tokens 统计，chunk 之间不会重复计算
2.3 为什么 max_num_batched_tokens 默认值值得你重新审视
vLLM 默认的 max_num_batched_tokens 在不同版本里是动态调的。以前很多版本默认 2048，后来逐步变成 4096、8192 甚至更高。很多人不理解这个值为什么这么重要。
这个值直接决定了 GPU 每个 step 的工作粒度。太大，调度器把很多 token 一次性塞进去，Decode 被阻塞的时间变长；太小，每个 step 的矩阵乘形状太小，GPU 算力发挥不出来。
实际操作中，你需要根据模型 size 和显存带宽来调。我的经验是：对于 7B 模型，max_num_batched_tokens 设 4096 到 8192 之间比较合理；对于 70B 模型，设 2048 到 4096 之间的收益比较明显。但这只是一个起点，真正的调优需要看 Nsight 和训练日志里的 per-step 时间。
3. 调度器实现细节：为什么说 Chunked Prefill 是调度层的艺术
很多讲 Chunked Prefill 的文章都忽略了调度器内部的两个核心问题：不同优先级的 Prefill 怎么排？Chunk 之后的 Decode 状态怎么同步？这两个问题不搞清楚，你自己去改 vLLM 源码的时候一定会踩坑。
3.1 显存管理：Chunked Prefill 如何和 PagedAttention 协作
vLLM 的显存管理核心是 PagedAttention。它把 KV Cache 分成固定大小的 block，每个 block 默认 16 个 token。Chunked Prefill 切分 prompt 之后，每个 chunk 的 KV Cache 依然按 block 分配，这样显存碎片化的问题就被 PagedAttention 的 block 表解决了。
关键实现点在 block_manager_v1.py 或 block_manager_v2.py 的 append_slot 方法里。当一个 chunk 处理完，新 chunk 到来时，调度器会根据 sequence 的当前长度决定是否分配新的 block。如果 sequence 恰好在一个 block 边界上，新 chunk 直接复用下一个空闲 block；如果不在边界，就先部分填满已有 block 的空间部分。
有个细节值得注意：Chunked Prefill 的 chunk 边界并不和 block 边界对齐。一个 chunk 可能跨两个 block。PagedAttention 的 kernel 在处理这种 kv cache 分布时是支持的，因为它通过 block table 按 token 索引查找物理位置。这也是为什么 Chunked Prefill 本质上是依赖 PagedAttention 的灵活显存管理才成立的。
3.2 Running 队列和 Waiting 队列的优先级博弈
vLLM 的 scheduler 维护两个队列：Waiting queue 放等待调度的新请求，Running queue 放当前正在生成的 seq_group。Decode 阶段的 seq_group 一定在 Running queue 里。Preffill 阶段的新请求从 Waiting queue 进入 Running queue。
如果是非 Chunked Prefill，一个 seq_group 被调度时一次性完成 Prefill，然后进入 Running。Chunked Prefill 则不同，一个 seq_group 可能在 Running queue 里也处于 Prefill 中间态。所以 vLLM 里对 seq_group 的 state 判断不能只看是不是 running，还要看 remaining_tokens 是否为零。
优先级调度这里，vLLM 的 policy 默认是 FCFS（先来先服务）。但有 chunked prefill 时，为了让已经在生成的请求不被打断，running 里的 decode 请求优先级更高。新到达的 waiting 请求只能使用“剩余预算”，这就是 Chunked Prefill 能天然控制排队延迟的原因。
3.3 为什么 Chunked Prefill 不适用于所有场景
Chunked Prefill 看起来很好，但并非银弹。我在实际部署中发现它有三个明显的代价：
- 长 prompt 会被切块多次，总 Prefill 时间变长（因为每个 chunk 都要单独调度，中间有 kernel launch 和同步开销）
- 对短的、延迟敏感的请求，切块会引入额外的 token 等待，因为第一个 chunk 可能不会在一整个 step 里跑完
- 如果 max_num_batched_tokens 设置不当，反而会降低总体吞吐
所以如果你做的是离线批量推理，或者所有请求都是长 prompt 且不需要流式输出，那么 Chunked Prefill 带来的收益不明显，甚至负优化。它最适合的是在线服务、混合负载、长 prompt 短输出这类场景。
4. 源码走读：从 Scheduler 到 attention backend 的完整 Chunk 路径
我每次读 vLLM 的源码都会从 scheduler.py 的 schedule() 方法入手。Chunked Prefill 在这一层的体现，不在一个单独的模块里，而是散落在几个判断逻辑里。为了避免你像我第一次一样找半天，我把关键的代码路径直接标记出来。
4.1 schedule_running 和 schedule_prefills 的顺序关系
在 Scheduler.schedule() 里，顺序是：
- 先调用 _schedule_running，处理 Running 队列里的 decode 请求
- 再调用 _schedule_prefills，处理 Waiting 队列里的 Prefill 请求
- 最后是 _schedule_swaps 和 _schedule_copies
这个顺序很关键。因为 budget 是先被 running decode 消耗完的，剩下的 token 预算才给 prefill。如果你把 max_num_batched_tokens 和 max_num_seqs 调得和 decode 请求量差不多，prefill 的 chunk 会被切得非常小，完全失去 Chunked Prefill 的意义。
所以调优的时候，max_num_seqs 要明显大于并发 decode 数量，才能腾出空间给 prefill chunk。max_num_batched_tokens 要大于 decode 总 token 数，prefill 才有机会一起跑。
4.2 Attention backend 如何处理 chunk 边界
vLLM 的 attention 有多个 backend，比如 XFormersBackend、FlashAttentionBackend、FlashInferBackend。Chunked Prefill 不影响 backend 的选择。它影响的是传给 backend 的 query token 数量。
在 model_runner.py 里，input_tokens 是当前 step 所有序列的 token 拼接。Chunked Prefill 对模型来说只是输入形状变化，不改变 attention 的计算逻辑。关键是 attn_metadata 里的 slot_mapping 和 block_table 要能正确索引，让 kernel 找到每个 token 对应的 KV Cache 位置。
对于 FlashAttention 系列，有一个重要参数叫 num_splits。它控制 kernel 在长序列维度上是否切分。Chunked Prefill 的 chunk 本身就是切分，所以 num_splits 可以设得保守一些。这俩要分清楚：num_splits 是 kernel 内部并行策略，Chunked Prefill 是调度层切分。
4.3 从 sequence 角度看 Chunk 对状态的修改
跟踪一个 seq_group 在 chunk 之间的状态迁移，是最好的理解方式：
- 初始状态：Waiting，remaining_tokens = len(prompt)
- 第一次调度：调度一个 chunk 的 token，seq 状态标记为 RUNNING（但仍在 prefill 阶段）
- 执行 attention 和 MLP，更新 num_computed_tokens += chunk_size
- 再次调用 schedule()：重新计算 remaining_tokens，如果还有剩余，继续调度下一个 chunk
- 直到 remaining_tokens = 0，prefill 完成，进入 decode 循环
在 model_runner 里，input_positions 会记录每个 token 在序列中的位置，这样可以避免重复计算 attention 的 position encoding。这个变量在 Chunked Prefill 的实现里非常关键，很多新手看代码时会疑惑为什么 input_positions 不从头开始。因为它要从 num_computed_tokens 开始。
5. 实战调优：让 Chunked Prefill 真正提升吞吐的配置组合
光知道原理不够，你大概率是拿来部署的。这一节我直接给出几种我实测过的配置组合和调参建议。
5.1 基础参数配置建议
以下是我在 A100/H100 上部署 7B/13B/70B 模型时的推荐起点：
| 模型规模 | max_num_batched_tokens | max_num_seqs | 备注 |
|---|---|---|---|
| 7B | 8192 | 128-256 | 显存 40GB 以上 |
| 13B | 4096-8192 | 64-128 | 显存 40GB 以上 |
| 70B | 2048-4096 | 32-64 | 显存 80GB 或量化 |
| MoE 模型 | 4096 | 64-128 | 根据 expert 数调整 |
注意，这些数字不是一个固定最优解。你需要结合 Nsight 看 step 耗时。如果一个 step 的 GPU kernel 时间有明显空闲，说明 batch 太小，可以调大 max_num_batched_tokens；如果 decode 延迟飙升，说明 prefill chunk 太大，调小。
5.2 和 Continuous Batching 的协同效果
Chunked Prefill 和 Continuous Batching 是互补关系。Continuous Batching 负责让 decode 阶段的序列可以动态进出 batch，Chunked Prefill 负责让 prefill 阶段可以细粒度地和其他请求共享 GPU。两者组合之后，GPU 的 mini-batch 形状更稳定，计算效率更高，显存利用率也更均匀。
我做过一个对比实验：在相同请求混合下，只开 Continuous Batching 不开 Chunked Prefill，GPU 利用率波动在 30% 到 85% 之间；同时开启后，波动压缩到 50% 到 80% 左右。虽然利用率峰值没有显著提高，但低谷期变少了，这对在线服务的尾延迟非常重要。
5.3 和 Prefix Caching 一起吃时要注意什么
vLLM 的 Prefix Caching 会缓存 KV Cache block。Chunked Prefill 切分 prompt 之后，每个 chunk 有自己的 block。如果 chunk 边界和 prefix cache 的 block 不一致，缓存命中率会下降。
实测下来的策略是：尽量让 prompt 的长度是 block 大小（默认 16）的整数倍。这个不现实。更实际的方案是，在 Prefix Cache 开启时把 chunk 大小设成 block 大小的整数倍。但 vLLM 的 chunk 大小由剩余预算决定，不一定对齐。所以遇到 cache 命中率下降时，关注一下 chunk 切分位置，必要时可以调 block_size。
我自己在线上服务里，如果用户的 prompt 高度重复，我会优先用 Prefix Caching，把 max_num_batched_tokens 调小一点，让 chunk 更细粒度，提高 cache 命中。
6. 主流推理引擎的 Chunked Prefill 实现差异对比
很多人问，读 vLLM 的源码能不能直接套到 TensorRT-LLM 或者其他框架上？答案是不能，但思想是相通的。我把几个主流引擎的差异写出来。
6.1 vLLM：调度层切分，最灵活
vLLM 的 Chunked Prefill 是纯调度层的实现。它不改变模型结构，不改变 kernel 策略，只是在 Scheduler 里把 seq_group 的 token 预算逐 chunk 下发。好处是代码侵入小，方便自定义；坏处是调度器仍然是一个单线程瓶颈，极端并发下 scheduler 的 CPU 开销会显现。
6.2 SGLang：RadixAttention 下的 Chunked Prefill
SGLang 的 RadixAttention 天然支持 chunk 级别的 prefix 复用。它的调度器结合了 radix tree，可以直接在 chunk 边界做 KV Cache 复用。Kernel 层面也有更多优化。如果你对 prefix 复用有强需求，SGLang 的 Chunked Prefill 会比 vLLM 更聪明。
6.3 TensorRT-LLM：更底层的 Inflight Batching
TensorRT-LLM 的 Inflight Batching 也支持 chunk 化的 prefill 和 decode 混跑。它的实现更偏底层，需要把模型编译成 TensorRT engine 时指定 max_num_tokens 和 max_batch_size。这意味着它没有 vLLM 那么动态，但一旦编译好，kernel 执行效率通常更高。
我在实际对比中，TensorRT-LLM 的静态场景（固定形状，高并发）表现更好；vLLM 在动态场景（变长 prompt、流式输出）更灵活。适合哪个，取决于你对延迟和吞吐的优先级。
7. 比 Chunked Prefill 更进一步：PD 分离和 Disaggregated Prefill
Chunked Prefill 并不是终点。业界现在越来越关注 PD 分离（Prefill 和 Decode 分离部署）。我简单说一下两者关系，方便你做架构选型。
7.1 为什么要 PD 分离
Chunked Prefill 解决的是同一个 GPU 上 Prefill 和 Decode 的混跑冲突。但混跑本身还有隐性代价：Prefill 和 Decode 的 kernel 形状不同，即使 chunk 化，混在一个 stream 里还是有切换开销。PD 分离则把 Prefill 和 Decode 放到不同的 GPU 甚至不同的节点上，彻底隔离干扰。
PD 分离的实现复杂度更高：需要把 KV Cache 从 Prefill 节点传输到 Decode 节点。这个传输开销在长上下文中会非常大。所以 PD 分离通常和 Prefix Caching 一起用，把中间状态缓存起来，减少重复传输。
7.2 Chunked Prefill 仍然是 PD 分离的一个重要基础
即使在 PD 分离架构里，Prefill 节点也不会把一个超长 prompt 一次性全算完。它依然会把 prompt 切 chunk，分批计算，并逐步把 KV Cache 发送给 Decode 节点。所以理解 Chunked Prefill 的源码实现，对未来深入 PD 分离架构也很有帮助。
如果你正在设计自己的推理系统，我的建议是：先完整跑通 vLLM 的 Chunked Prefill，把调度、显存、kernel 的配合理解清楚，再去拆 PD 分离。直接上 PD 分离的复杂度，在没有基础的情况下很容易失控。
8. 代码变体与自定义尝试：从改 max_num_batched_tokens 开始
最后这部分，我分享一些我改 vLLM 源码做实验的经验。Chunked Prefill 的代码路径并不复杂，适合作为学习推理框架的第一个切入口。
8.1 最简单的自定义：动态调整 chunk 大小
默认的 chunk 大小是剩余预算决定的。你可以改成按照请求的 prompt 长度均匀切分。在 schedule_prefills 里，把 num_new_tokens 改成 ceil(remaining_tokens / num_chunks)。这样对于一个固定长度 prompt，它的 chunk 大小均匀，调度更可控。
code复制# scheduler.py 中修改逻辑
num_chunks = 4 # 自定义 chunk 数
num_new_tokens = max(1, (remaining_tokens + num_chunks - 1) // num_chunks)
这样改的代价是，当剩余预算小于 num_new_tokens 时，需要分多次调度，且单 chunk 大小小于理想值。实验下来，均匀切分在某些负载下能提升吞吐，但大多数时候收益不明显。因为默认的“用满预算”逻辑已经足够好。
8.2 需要注意的坑：序列 ID 和 chunk 追踪
当你修改 chunk 大小或者自己加逻辑时，最容易踩的坑是 sequence 的状态追踪。Chunked Prefill 实现里，一个 sequence 在 prefill 未完成前不能被释放，也不能被抢占。如果你错误地把 seq_group 先调度了完整 prefill，后面再切 chunk，会导致 KV Cache 重复分配。
解决思路是，维护一个 helper dict，记录每个 seq_id 的 computed_tokens。每次调度前查一下，确保调度逻辑从 computed_tokens 之后开始。
8.3 从源码到论文：Chunked Prefill 的学术背景
Chunked Prefill 这个 idea 并不是 vLLM 原创，也并非某一篇论文提出。它是工程实践中自然演化而来的调度优化。类似思想在 SARATHI、FastServe、NanoFlow 等系统里都有体现。SARATHI 的核心贡献之一就是 chunked prefill（它叫 equitable preemption 相关的概念），通过均匀 chunk 避免长 prompt 抢占。
读这些论文的意义，不在于记住某个算法名，而是理解它们之间互相影响的设计选择。这也是我读 vLLM 源码时最喜欢做的事：把工程实现和论文设计一一对应。
最后再分享一个小技巧
如果你刚接触 Chunked Prefill，我建议你做一个非常简单的实验：用 vLLM 起一个服务，只发一个 10000 token 的 prompt，然后把 max_num_batched_tokens 从 2048 调到 8192，用 Nsight 记录每步的 kernel 时间。你会发现，当 chunk 大小增大时，单个 step 的 FFN 和 attention kernel 时间占比在变化，调度空隙在缩小。
这个实验做完，你对 Chunked Prefill 的理解会超过绝大多数只是看过文档的开发者。因为你会真正感受到调度层的决策如何落到 kernel 执行上。之后再调参、改源码、设计新策略，你都会有方向感。