大模型推理优化：vLLM Chunked Prefill 原理与调优实践

做推理服务的老哥应该都有过这种经历：模型明明跑得好好的，突然来个 32K 上下文的 prompt，整个引擎像是被按住了暂停键。后面排队的请求全部卡住，GPU 利用率曲线直接从锯齿状变成一根直线，显存占用却哗哗往上涨。等这个长 prompt 终于 prefill 完，第一批 decode token 出来，服务才算缓过气来。

这个现象的本质，在于传统推理引擎把 prefill 和 decode 当成两个完全隔离的阶段在处理。一个长序列的 prefill 会一次性占用大量计算资源和 KVCache 空间，调度器在这个时间段里几乎做不了任何其他事情。Chunked Prefill 的出现就是要把这个"阻断"打碎，它允许同一个序列的 prefill 计算被拆分成多个 chunk，分批执行，在 chunk 的间隙还能插入其他 decode 请求的计算。这篇文章我会结合 vLLM 的调度器与 attention 后端的实现，把这套机制从原理到代码彻底拆开来看。

1. 为什么需要 Chunked Prefill：从调度器的视角看问题

Chunked Prefill 不是凭空冒出来的优化技巧，它的诞生有非常具体的背景。理解它要解决的问题，才能理解它的设计取舍。

1.1 传统 prefill/decode 两阶段切分的痛点

在大模型推理引擎里，一个请求的处理被分成两个阶段。第一个阶段是 prefill，把用户的 prompt 一次性塞进模型，并行计算所有输入位置的注意力，生成第一个输出 token；第二个阶段是 decode，拿着已有 token 逐个生成后续 token，每一步只算一个位置。这两个阶段的计算特性完全不同：prefill 是计算密集型的矩阵乘，decode 是访存密集型的向量操作。

调度器为了保证推理正确性，通常的做法是"同一批次内要么全是 prefill，要么全是 decode"。这给长 prompt 场景带来了一个致命问题：如果某个时刻所有空闲的 slot 都被一个超长 prompt 的 prefill 占满，那么整个 step 都会被拖住。更麻烦的是，传统实现中序列的 KVCache 是一次性分配的。在 prefill 开始前，调度器就得根据整个 prompt 的长度预留完整的显存。32K 的 prompt，以 7B 模型的 KV 参数计算，单条序列的 KV 可能就要消耗数 GB 的显存。

这种一次性分配带来两个后果。第一，显存池碎片化严重，一个超大 KV 分配请求可能直接导致显存不足；第二，调度器没法做细粒度的显存复用，很多小请求明明可以插进碎片空间，却因为调度策略的限制被拒之门外。

1.2 调度气泡和平均时延的恶化

除了显存，还有调度效率的问题。推理引擎的 batch 是动态的，每个 step 结束都会有请求完成、新请求加入。理想情况下每个 step 都应该塞满 token，但传统两阶段切分做不到这一点。假设当前有一个 16K 的 prompt 在 prefill，剩余显存无法再容纳一个完整的 16K KV 分配，那么其他的计算单元只能空转。这种"计算气泡"在长 prompt 场景下特别明显。

从延迟角度来讲，首 token 时延也被拉长了。用户发了一个长 prompt，想在尽短时间内看到第一个 token，但传统引擎会把这个 prompt 的 prefill 和后续 decode 串行化处理，prefill 内部无法并行处理其他请求，导致整个 batch 的排队延迟累加。做过在线服务的老哥应该都懂，长 prompt 一多，尾延迟就完全压不住。

Chunked Prefill 的思路，就是把 prefill 阶段砍成几段，每段计算的 token 数量变小；调度器不再需要给整个序列预留完整的 KVCache，而是边算边扩，每次只分配一个 chunk 需要的空间。这样 GPU 的算力就能在 prefill chunk 和 decode token 之间穿插使用，显存利用率和请求间的公平性都能得到显著改善。

1.3 适用场景与一个关键认知

需要先说明一点：Chunked Prefill 不是所有场景的银弹。它对短 prompt 场景的收益非常有限，甚至可能因为 attention mask 的额外开销带来少量性能回退。它主要针对的是以下场景：

• 长上下文的问答、文档摘要、代码补全等场景，prompt 动辄上万 token。
• 高并发在线推理服务，需要控制长请求对其他请求的干扰。
• 显存资源受限、模型 KV 占用较大的部署环境。
• 需要与 Prefix Caching（前缀缓存）配合使用的场景。

一个容易踩坑的误区是：Chunked Prefill 并不会减少模型的数学计算量。它拆分了 KVCache 的分配，但 attention 计算该算多少还是多少。它的收益在于提升调度器灵活性和显存利用率，从而在整体吞吐和尾延迟上做出改善。这个概念后面分析源码时会反复出现。

2. 核心设计原理：分块、复用与动态分配

要深入源码，得先理解 Chunked Prefill 的几个核心设计理念。这些理念落实到代码里，就是调度器的状态机变化和 attention 原语的形状变化。

2.1 从"整段预留"到"按 chunk 动态扩展"

传统 prefill 的 KVCache 分配像去银行取大额现金，一次拿一叠，不管后面用不用得到。Chunked Prefill 则是按需支取，在 prefill 过程中每处理完一个 chunk，就为后续 chunk 追加分配 KVCache。这个追加分配的逻辑，与 decode 阶段为每个新 token 分配 KVCache 的逻辑实际上是统一的。

这就引出了一个非常重要的设计统一性：在 Chunked Prefill 模式下，KVCache 的块管理完全与 decode 一致。所有的块都来自同一个块池，序列的 KV 块是从少到多动态增长的。调度器不再区分"这是 prefill 序列，需要一次性分配完整的块"和"这是 decode 序列，每次只追加一个块"，而是统一走"需要更多空间就申请块"这条路径。

这在源码里表现为序列状态判断的变化。vLLM 中判断一个序列处于 prefill 还是 decode，不再仅仅是看 seq.is_prompt()，还要看当前 step 是否已经把整个 prompt 处理完。调度器关注的其实是 is_pending 和 seq_chunk_start、seq_chunk_end 这类分段标记，后面会具体说。

2.2 chunk 大小的约定与约束

Chunked Prefill 里最核心的参数就是 chunk 的大小。框架把每个 step 允许计算的最大 token 数限定为 max_num_batched_tokens。对 prefill 序列来说，这个数其实就是单个 prefill 请求的最大 chunk 粒度。不同框架对这个参数的叫法不同，vLLM 里是 max_num_batched_tokens，SGLang 在早期版本里也沿用了这个概念。

这里要理解一个约束关系：一个 chunk 内的 token 数，不能超过模型单次 prefill 能接受的最大 batch token 数，否则 attention 计算的形状会超出后端算子的支持范围。但在实现上，由于序列可能在中途被调度器切走，chunk 的实际边界通常还会受到 scheduling policy、抢占策略和剩余 prompt 长度的影响。

举个例子。假设 step 的 token 预算（budget）是 4096，当前有一个待处理的长 prompt，剩余未计算的 token 数是 8000。调度器在这个 step 里最多能给这个序列安排 4096 个 token 的计算量，于是这个序列需要 2 个 step 才能完成 prefill。在第一个 step 结束时，它已经产出了前 4096 个 token 对应的 KVCache，后续 token 的 KV 尚未生成，处于"等待下一轮 prefill"的中间状态。

这个中间状态很关键。它在 Sequence 内部的 timestamp 字段中留下了痕迹：seq.data.status 可能还是 prefill 状态，但 seq.data.num_prefill_tokens 已经被推进到了 4096。下次调度时，调度器要用新的 start_idx 去继续 prefill，而不是从头开始。

2.3 注意力掩码的形状变化：batch 内混合任务的挑战

传统的 prefill 是纯并行，一个 batch 内所有的序列长度都不一样，但没有 decode 参与，attention mask 是一个左下三角的稠密矩阵。decode 则简单得多，每个序列只有一个 query 位置，需要和已有 KV 做 attention，mask 退化成只看可见前缀。

Chunked Prefill 打破了这个界限。在一个 step 内，调度器可能同时安排了几个 prefill chunk 和几个 decode token。这种情况下，attention 计算的输入形状就是"混合"的：有些序列贡献了 chunk 长度的多个 q token，有些序列只贡献了 1 个 q token。这要求注意力算子能处理这种 irregular 形状，同时 mask 的逻辑也必须按序列来区分。

VLLM 的 PagedAttention 后端为此设计了特殊的数据结构。在 v2 版本的 attention 原语中，每个序列被拆分成不同的 "query 块"，每个块可以对应不同的 context 长度。这背后是一套复杂的 seq_lens、block_tables、prefix_block_len 等元数据的组装逻辑。在源码层面，实现难点集中在 attn_metadata 的构建上，尤其是 prefill 部分与 decode 部分的切分。

2.4 动态 shape 带来的调度复杂度

引入 chunk 拆分之后，调度器要处理的动态性变强了。之前一个 prefill 序列要么在 prefill 队列里，要么结束进入 decode；现在它可能处于"prefill 进行中但尚未完成"的中间态。这个中间态给调度器增加了很多需要额外判断的条件。

具体来说，调度器需要回答这些问题：

• 这个序列的 prefill 已经推进到哪个 token 位置？
• 这个序列当前是否处于可抢占（preemptible）状态？
• 如果它被抢占，回来之后应该怎么恢复它的 start_idx？
• 它占用的 KVCache 块在抢占期间能否被释放或复用？

这一系列问题在 vLLM 的 Scheduler 类里都有对应的字段和处理逻辑。Sequence 里新增加了"prefill 进度"相关的数据，调度策略也要在页面置换逻辑上做适配。可以说，Chunked Prefill 让调度器的代码复杂度上升了一个量级，但换来的就是一张能塞满的 GPU 时间表。

3. 源码剖析：vLLM 调度器与 Attention 后端的协作

接下来进入正题，从源码角度分析 Chunked Prefill 的实现。下面以 vLLM 为参考实现，讲解调度器层面的状态管理、chunk 推进逻辑，以及 Attention 后端如何配合 chunk 粒度进行计算。

3.1 启动入口与开关

在 vLLM 中，Chunked Prefill 由 SchedulerConfig 中的 enable_chunked_prefill 字段控制，命令行参数是 --enable-chunked-prefill。它还有一个依赖条件：只有配置了 max_num_batched_tokens 的限制，即 use_v2_block_manager 被启用后，Chunked Prefill 才能正常工作。早期版本中 use_v2_block_manager 是独立开关，后来的版本中块管理器 v2 已经变成默认实现，所以现在基本上只关注 enable_chunked_prefill 即可。

code复制# 初始化时构建调度配置
scheduler_config = SchedulerConfig(
    max_num_batched_tokens=args.max_num_batched_tokens,
    max_num_seqs=args.max_num_seqs,
    enable_chunked_prefill=args.enable_chunked_prefill,
)

enable_chunked_prefill 为 True 时，调度器会走新的调度逻辑；为 False 时，调度器强制保证每个 prefill 序列一次性计算完整段，不允许中途插入其他任务。

3.2 Scheduler 调度主循环：prefill 状态的推进

Scheduler 的主循环位于 schedule() 方法内，它依次处理 waiting 队列（新到请求）、running 队列（正在执行或等待续跑的请求）。在 Chunked Prefill 模式下，核心逻辑体现在 _schedule_prefills 这个方法里。

算法大致如下：

1. 从 waiting 队列中取出序列，或者从 running 队列中识别出"仍在 prefill 阶段"的序列。
2. 检查 num_prefill_tokens 与 get_len() 的关系，判断这个序列是否需要继续 prefill。
3. 计算当前 step 可以接受的 token 预算，即 remaining_token_budget，并依据这个预算给每个 prefill 序列分配 chunk 区间。
4. 为 chunk 区间内的 token 生成 KVCache 块分配/复用指令。
5. 推进 num_prefill_tokens 到新的起点。
6. 生成 SchedulerOutput，包含本轮要执行的 prefill 序列列表和对应参数。

在 Scheduler 内有几个关键的私有方法，比如 _get_num_new_tokens 和 _update_seq。_update_seq 中有段代码专门处理 chunked prefill 的推进：

code复制# vLLM Scheduler._update_seq 片段（精简）
if seq.is_prompt() and scheduler_config.enable_chunked_prefill:
    # 只推进当前 chunk 的数量
    seq.num_prefill_tokens += current_chunk_tokens
    seq.step_num += 1
    if seq.num_prefill_tokens < seq.get_prompt_len():
        # 尚未完成整个 prompt 的 prefill，保持 is_prompt 状态
        pass
    else:
        seq.is_prompt = False
else:
    seq.num_prefill_tokens = seq.get_prompt_len()
    seq.is_prompt = False

这段代码揭示了一个容易被忽略的事实：seq.is_prompt() 这个标志并不表示"这个序列在这一轮被调度"，而是表示"这个序列的 prefill 计算还没有全部完成"。Chunked Prefill 让一个序列可以连续多轮保持 is_prompt=True，直到最后一个 chunk 算完。

3.3 Sequence 数据结构中的关键字段

要理解上面这段代码，必须弄清楚 Sequence 对象里存了哪些信息。以下是与 Chunked Prefill 最相关的字段：

这些字段的含义，在 Chunked Prefill 下发生了变化。num_prefill_tokens 不再等于 prompt_len（除非 prefill 完全完成），而是一个动态推进的值。调度器在决定下一轮是否继续 prefill 时，会校验 seq.num_prefill_tokens < seq.get_prompt_len()。

同时，SequenceBlockManager（或叫 BlockManagerV2）需要根据 num_prefill_tokens 来正确地映射"逻辑 token 位置"到 "物理 KV 块"。num_prefill_tokens 的作用相当于一个游标，所有依赖 KVCache 的操作（比如 attention 计算、prefix caching 复用）都会参考这个游标。

3.4 Attention 元数据与 PagedAttention v2 原语

除了调度器，Chunked Prefill 的落地还需要 attention 算子层面的配合。VLLM 的 PagedAttention 后端在支持 Chunked Prefill 之前就已经有 v1 原语，但它对输入形状有严格要求：一个 batch 内所有请求的 query token 数量要么都为 1（decode），要么为一个大于 1 的定值，形状不规则时会直接报错。

Chunked Prefill 打破了这种规整性。同一个 batch 里，有的序列贡献 2048 个 query token，有的只有 1 个 decode token，如果直接拼接，形状就乱套了。为此 vLLM 引入了 PagedAttention v2 原语，它对不规则 query 长度做了专门适配。在 Attention 元数据的构建过程中，每个序列会被拆成多个 "query 块"，每个 query 块内部有独立的 seq_lens、context_lens 和 block_tables。

核心数据结构的组织逻辑大致如下：

• input_tokens：所有序列在 chunk 范围内的 token ID，展开成一维数组。
• query_lens：每个序列本次计算的 query 数量，可能为 chunk_size，也可能为 1。
• context_lens：每个序列已经计算过 KVCache 的 token 数量，等于 num_prefill_tokens + 已生成的 output token 数量。
• block_tables：每个序列的物理块映射表。
• prefix_block_len：如果有 Prefix Caching，记录前缀中可复用的块数。

V2 原语的 attention 计算逻辑可以概括为：

code复制for each sequence:
  for each query block:
    q = query_block
    context = KVCache from [0: context_lens[seq]]
    attn = softmax(q @ context^T)
    out = attn @ context_value

其中 context_lens 会因 Chunked Prefill 的推进而不断变化，attention mask 的"可见范围"也会随之调整。这保证了一个序列在 prefill 中途被打断、下一次续跑时，前面的 token 不会参与当前 chunk 的 attention 计算（因为它已经在之前的 chunk 中算过了）。

3.5 与 decode 混跑的批处理逻辑

Chunked Prefill 最有价值的一点，是它允许 prefill 和 decode 在同一个 step 里并发执行。也就是说，一个 batch 里既有正在做 prefill 的长 prompt，又有正在做 decode 的短请求。

这在代码层面是怎么实现的？答案是把 prefill 和 decode 的 attention 元数据分开存储，然后统一交给底层算子。在 ModelRunner 中，会先收集 prefill 序列的元数据，再收集 decode 序列的元数据，最后把它们拼接成一个 batch 喂给模型。而因为两次操作混在一个 batch 里，模型前向计算时的 hidden_states 形状必须能容纳两者。

具体到批处理，框架会控制总 token 预算。一个 step 内，如果排了 2048 个 token 的 prefill chunk，那么 decode token 的数量就最多只占 max_num_batched_tokens - 2048，确保总的 token 数不超过算子支持的上限。这也是调度器中 remaining_token_budget 这个变量的用途，它在 _schedule_prefills 和后续的 decode 调度中都会持续被扣减。

3.6 抢占与恢复：Chunked Prefill 下最麻烦的部分

除了混排，抢占（preemption）也是 Chunked Prefill 源码中非常容易出 bug 的地方。传统模式下，一个序列要么在 decode，要么在 prefill，抢占时的处理比较直接。Chunked Prefill 模式下，序列可能正处于 prefill 中途，内存中已经有了前几个 chunk 的 KVCache。这个时候如果发生抢占，需要做的是：

1. 将当前序列的 KV 块释放或迁移。
2. 保存当前的 num_prefill_tokens 进度。
3. 在后续恢复时，从 num_prefill_tokens 继续做 chunked prefill，而不是从头开始。

在 vLLM 的 BlockManagerV2 中，这表现为 fork、swap、free 等接口的调用。而对序列本身，只需保证 num_prefill_tokens 不会被重置。我们可以发现，在所有官方 issues 里，Chunked Prefill 相关的 bug 报告集中在 "错误地将正在 prefill 的序列当做已完成的序列释放了 KVCache"、"恢复后 block_table 错位" 这类问题上。这也提醒我们，阅读源码时重点关注抢占路径里的 num_prefill_tokens 更新逻辑。

4. 工程落地与调优：从源码到线上部署

理解了源码机制，接下来要聊的是工程落地时的调优策略。这部分内容更多来自实际部署中踩坑总结的经验，可以帮助你绕开一些隐蔽的问题。

4.1 chunk 粒度如何设置：一个权衡问题

chunk 大小直接决定了 attention 计算的效率。一般来说，chunk 越大，单次 attention 的矩阵乘规模越大，GPU 利用率越高；但 chunk 越大，KVCache 分配越接近传统模式，调度灵活性越低。反之，chunk 越小，调度越灵活，但过小的 chunk 会让注意力计算退化为类似 decode 的效率，同时增加大量元数据开销。

从线上经验来看，chunk 粒度通常在 256 到 4096 之间。如果 max_num_batched_tokens 是 4096，且大多数请求的 prompt 在几千到几万 token 之间，建议从 1024 或 2048 起步做压测。观察两个指标：GPU 利用率是否持续处于高位，尾延迟是否可接受。如果 GPU 利用率上不去，尝试调大 chunk 上限；如果尾延迟抖动严重，尝试调小。

一个补充知识点：chunk size 并不等于 max_num_batched_tokens。实际 chunk 大小还会受请求剩余长度影响。比如剩余 prompt 只有 500 token，那么这一轮实际 chunk 就是 500，而不是你配置的 2048。因此配置参数控制的是"最大 chunk 上限"，而不是"固定 chunk 大小"。

4.2 显存分配与碎片化的实际收益

Chunked Prefill 的显存收益主要体现在两个方面。第一，分配粒度变小，避免了长 prompt 一次性申请大块 KVCache 导致的分配失败；第二，可复用的空闲块数量增多，调度器可以更精细地填满显存空洞。

以一个 7B 模型为例，假设每个 token 的 KVCache 占用约 1.5KB（取决于 num_heads、head_dim、dtype 等）。一条 32K prompt 的 KV 总量约 48MB。传统模式下，调度器要为这条序列预留完整的 48MB 空间。Chunked Prefill 模式下，如果 chunk 上限是 2048，则本轮只需预留约 3MB 空间，剩余空间可以立即给其他请求用。对于有多条长 prompt 并发的场景，显存峰值可以有明显的下降，具体收益取决于块分配器和序列剩余长度分布。

不过要注意，Chunked Prefill 并不能减少总的 KV 内存使用，它只是把"某个时刻必须同时存在的 KV 量"压低了。如果系统负载很高，显存利用率反而会因为能塞更多请求而接近饱和，这是正常的。

4.3 与 Prefix Caching 的配合

Chunked Prefill 与 Prefix Caching（前缀缓存）天然契合。Prefix Caching 的目的是复用相同前缀的 KVCache，减少重复计算。在 Chunked Prefill 下，序列的 prefill 是分块推进的，那么当它被抢占后、或者另一个相同前缀的请求到来时，调度器可以检查已存在的 KV 块，直接跳过对应 token 的 prefill 计算。

这里有一个重要的实现细节：Prefix Caching 的命中粒度是"块"，一个块通常对应一个固定 token 数（如 block_size=16）。在 Chunked Prefill 模式下，num_prefill_tokens 的推进方向如果是一块一块地推进，那么前缀块天然对齐。但如果 chunk 边界不是 block_size 的整数倍，中间就会产生不能被缓存的部分，导致缓存收益打折。建议在线下压测时观察 BlockManagerV2 的 cache 命中率，如果命中率低，尝试调整 block_size 为 chunk_size 的约数。

这里也解释了一个常见误区：不要在启用 Chunked Prefill 的同时禁用块缓存。虽然 Chunked Prefill 不让单个序列一次性占满显存，但它本身并不处理 KV 块复用的问题，这部分工作仍然由块管理器完成。

4.4 吞吐与延迟的平衡：实测观察

以一个实际场景为例：部署 13B 模型，GPU 为 A100 80G，prompt 平均长度 8000 至 16000 token，QPS 较高。开启 Chunked Prefill（chunk 上限 2048）后，我观察到以下变化：

首 token 时延下降的原因很直观：长 prompt 的 prefill 不再阻塞后续请求的 decode，其他请求可以在 prefill chunk 间隙中插空执行。而吞吐提升则是因为显存碎片减少、KVCache 分配成功率高，调度器能更加密集地安排请求。这个结果非常典型，说明 Chunked Prefill 对长 prompt 场景的优化效果是实打实的。

5. 常见问题与排查技巧实录

Chunked Prefill 在上线过程中有不少坑，以下是我遇到或者见到的频率比较高的几个问题，附上排查思路和解决方案。

5.1 开启后吞吐反而下降

如果开启 Chunked Prefill 后吞吐没有提升，甚至出现下降，大概率是以下两个原因：

• chunk 粒度过小，比如 128 或 256。过小的 chunk 会让 attention 算子退化为低效的循环调用，同时元数据封装耗时占比上升。
• 请求 prompt 大部分都很短，比如平均不到 512 token。此时 Chunked Prefill 的调度灵活性收益远小于 attention 形状不规则带来的开销，建议关掉这个特性。

排查方法很简单：把 max_num_batched_tokens 依次调大，观察请求的平均时延和 GPU 利用率变化。如果 GPU 利用率持续增高而吞吐未改善，就要考虑是否是其他瓶颈（如 CPU 调度开销、模型本身的计算强度）在起作用。

5.2 长 prompt 场景下显存溢出

有一个比较隐蔽的显存问题：Chunked Prefill 开启后，调度器允许更多请求同时进入 running 状态。如果这些请求全是长 prompt，KVCache 的瞬时总量仍然可能很大。而且，由于 prefill 分块执行，一个序列的 KV 块是在预填过程中动态增长的，如果块分配器本身内存不足，还是会出现 OOM。

排查时需要查看块管理器日志中的物理块数量与内存使用。如果 OOM 集中在 KV 分配阶段，考虑调低 gpu_memory_utilization 或者限制并发请求数。另外注意，如果同时使用了 Prefix Caching，某些块的引用计数可能异常偏高，导致旧块无法释放，这也是OOM罪魁祸首之一，需要留意 BlockManagerV2 的 ref_count 变化。

5.3 首 token 时延没有改善反而不稳定

如果首 token 时延没有改善，反而出现明显抖动，通常和调度策略有关。Chunked Prefill 让 prefill 与 decode 混跑，相当于长请求的 prefill 被"切碎"了，虽然看起来不阻塞其他请求，但长请求自身的首 token 时延可能比传统模式更久，因为每个 chunk 之间可能隔了其他 decode step。

要缓解这个问题，可以启用 vLLM 的 preemption_mode=recompute 或调整调度器的 max_num_seqs，避免同一 step 塞入过多的 prefill chunk。如果服务可以容忍一定的首 token 时延，更推荐的做法是设置 max_num_seqs 相对较小，同时调大 max_num_batched_tokens，保证每个 step 里有更多的 token 预算用于 prefill。

5.4 与某些模型实现不兼容

Chunked Prefill 对 attention 算子有特定要求，因此某些自定义模型可能无法直接开启。例如模型在 forward 中对 q_len 做了固定假设、或使用了自己写的 attention mask，就会在 Chunked Prefill 下报错。排查时重点看 attention 后端的日志，确认模型使用的是 V2 原语，还是自定义 Kernel。

如果模型使用了 HuggingFace 的 LlamaAttention 这类标准实现，一般没问题。如果使用了 Mamba、多模态混合 attention 或者其他非标准结构，就要格外注意。官方仓库中通过 is_pp_supported、is_attention_supported 等接口判定模型兼容性，建议排查时先确认模型对象是否被标记为支持 Chunked Prefill。

6. 个人实操中的几点体会

Chunked Prefill 的源码读起来并不轻松，调度器、序列状态、块管理器、attention 原语四个模块互相影响，任何一个地方理解不到位，调试线上问题时都会很痛苦。不过一旦搞明白了它的设计脉络，再去看调度日志就特别清楚。

我在实际使用中有一个习惯，就是在开启 Chunked Prefill 之后，先在离线压测脚本里构造"30% 长 prompt + 70% 短请求"的混合流量，观察首 token 时延的分布以及显存变化曲线。这个混合比基本能模拟线上多数场景，对比启用前后的数据，很快就能判断这个特性适不适合自己的负载。

另外一个建议是，生产环境升级 vLLM 等推理框架时，不要盲目开启所有新特性。Chunked Prefill 这类功能对调度逻辑影响很大，升级后至少跑一组长尾压测，用 P95/P99 时延对比来验收。我在一次升级中遇到过吞吐正常、但尾部时延明显恶化的情况，后来发现是抢占策略与新版块管理器交互出的问题，这类情况在大版本升级中很常见。

最后再分享一个小技巧：如果你遇到某些日志里出现 "Cannot find a free block for sequence" 之类的问题，优先检查 max_num_seqs 与 block_manager 的搭配，暂时关掉 Chunked Prefill 试试能否解决。很多调度器异常在关闭该特性后自动消失，这时候就说明问题出在块分配与 prefill 推进的交互上，可以从 num_prefill_tokens 的推进逻辑入手排查。

对于正打算在生产环境挑战长上下文负载的团队，我的建议是：先在一台测试机上开启 Chunked Prefill，结合自己的 prompt 长度分布做一遍完整的压测，观察首 token 时延曲线的形态变化；确认收益后再逐步灰度到线上流量。它不是一个保证千篇一律收益的开关，但在长 prompt 密集的场景下，它带来的调度灵活性和显存利用率的提升，是当前架构下极少见的兼得方案。