Chunked Prefill：大模型推理加速

可视化演示

通过FIFO与LRU两种页面置换策略的步进式演示，直观对比不同算法在缺页处理和命中率上的差异。

1. 背景与痛点：超级大单锁死后厨

餐厅后厨最怕什么？怕一桌 100 道菜的超级大单。按照老规矩，后厨得先停下来，给这桌客人把所有食材一次性备齐。七八个厨师在案板上忙得热火朝天，其他桌客人的菜只能放在灶台边干等。备菜虽然可以并行，但它把厨房占得死死的——等这桌菜备完，别的客人早就等得不耐烦了。

大模型的“后厨”也是这样运作的。收到一次请求，模型先进入 Prefill（预填充）阶段：把用户输入的整段提示词一次性前向计算一遍，算好每个 token 的 Key 和 Value，存进 KV Cache 这份“半成品料包”。这个阶段并行度高、算得快，但要占满整块 GPU。接着进入 Decode（解码）阶段：逐字生成回答，每个 token 依赖前一个 token，只能串行，好在单步开销很小。

问题就出在提示词长度上。用户贴一篇论文、一长串聊天记录，提示词可能有几千甚至上万个 token，Prefill 的计算量随长度线性增长。一个超长请求的 Prefill 会长时间独占 GPU，把正在解码的请求全部堵住，导致所有请求的首字延迟（TTFT）集体飙升，系统吞吐跌入谷底。

回到厨房场景：传统方式就像“来了大单就全员停摆备菜”，等备完菜才开始上菜。其他桌客人等得越久，餐厅差评（延迟超时）就越多。要改变局面，必须从排队规则下手——这正是 Chunked Prefill 登场的理由。

2. 分块处理原理：把备菜切碎，见缝插针

既然“一次备齐”会锁死厨房，聪明的店长改了规矩：把超级大单的备菜切成小份，每备完 10 道菜的量，就停下来先给其他桌炒两道菜，再回来备下一份。备菜和上菜交替进行，谁也不用等太久。

Chunked Prefill 正是这个思路。调度器把长提示词按块长切分（比如每 512 个 token 一块），每次只对一块做 Prefill 计算，算完立刻把结果写进 KV Cache，然后主动让出 GPU，交给调度器安排别的请求。下一次轮到它时，从断点继续算下一块，不必回头重算之前的部分。

块与块之间为什么能平滑衔接？因为注意力计算天然具有“前缀增量”特性：处理第 k 块时，只需要把第 k 块的 query 与已有的 KV Cache（前 k-1 块的结果）做注意力运算，再把本块新产生的 K/V 追加进缓存。也就是说，上下文信息通过 KV Cache 累积，分块只是把一次大计算拆成多次小计算，数学结果与整体 Prefill 完全一致。

分块让“备菜”和“上菜”在同一张灶台上交替进行。对厨师（GPU）来说，几乎没有纯等待的空档；对客人（请求）来说，最长的等待时间从“一整桌宴席的备菜时长”缩短为“一小份备菜的时长”。切得越碎，穿插越灵活，代价则是换手次数变多——这个权衡我们留到第五节细讲。

3. KV缓存管理：半成品料包的冰箱学问

分块备菜之后，半成品料包怎么放？聪明的后厨在冰箱里做了一排排小格子，每份料包按固定份量装盒，做完一盒就放一盒，不用一次性腾出一大块冷藏区。冰箱永远整整齐齐，也不会因为一桌大菜挤占其他客人的空间。

这里的“料包”就是 KV Cache。传统整体 Prefill 要求一次性为整段长提示词分配连续显存，像搬进一个大冰柜；Chunked Prefill 则让 KV Cache 增量写入——每算完一个 chunk，就把这一段的 K/V 追加进缓存，内存按需增长，用多少占多少。

显存管理通常依赖 PagedAttention：显存被切成固定大小的 block（页），每个 block 可容纳固定数量 token 的 K/V。一个序列的 KV Cache 由若干 block 组成的列表管理，物理上可以不连续，逻辑上保持连续，从而几乎消灭显存碎片。更妙的是，当多个请求共享相同前缀（同一段 system prompt、同一篇文档）时，这些 block 可以被直接复用，配合引用计数做写时复制，多请求共享一份预填充结果——好比几桌客人点的都是同一道招牌菜，后厨只备一次，分桌出餐。

有了“分格冰箱”和“按需装盒”，Chunked Prefill 才能放心地把料包一盒盒往里放：既不会撑爆显存，也不会因为反复搬运产生碎冰（碎片）。缓存管理理顺了，分块调度的地基才算打牢。

4. 连续批处理配合：智能排单系统

老后厨是“一批菜炒完再排下一批”；新后厨上了套智能排单系统：每做完一道菜就扫一眼全局，谁快出锅谁先来，备菜只在灶台空下来时见缝插针。这套系统就是连续批处理（Continuous Batching）。

传统批处理（Static Batching）要等整批请求全部生成完才腾出 GPU，慢的请求拖累快的请求；Continuous Batching 则在每次迭代（iteration）结束时动态调整批次：生成完成的请求退出，新请求进入，谁 ready 谁上。Chunked Prefill 恰好在这个调度框架里找到了自己的生态位。

每个迭代周期，调度器优先放行需要解码的请求——因为它们每被耽搁一个迭代，词间延迟（ITL）就多抖一下；随后检查 GPU 还剩多少算力，从 prefill 队列里取一个 chunk 塞进去。解码腾出的“算力缝隙”被 chunk 填满，GPU 利用率从“过山车”变成“满负荷平路”。这便是算力重叠（overlap）的威力：显式的等待被隐藏在别人的计算时间里，餐厅的灶台永远不会因为等料而空烧。

排单系统让厨房始终处于“有人在切菜、有人在炒菜”的满负荷状态。每道菜出锅的间隙，备菜师傅就补一份料；每个解码迭代的间隙，调度器就塞一个 chunk。整条流水线严丝合缝，客人的等待时间被悄悄藏进了别人的忙碌里。

5. 延迟吞吐权衡：翻台率与用餐体验的博弈

切菜块头大有块头大的好处：一次切 20 道菜的量，厨师手臂抡得开、效率高，但灶台被占住的时间也长。块头小则灵活，随时能从炒菜切回备菜，但频繁换手同样有损耗。餐厅必须在“单桌体验”和“整体翻台”之间找平衡。

Chunked Prefill 不是免费的午餐。块长 B_c 越大，每次 Prefill 的矩阵乘法并行度越高，计算效率越好；但单个 chunk 占用 GPU 的连续时间变长，其他请求被插队等待的时间也随之变长，P99 延迟上升。块长越小，抢占越频繁、延迟越平稳，但 chunk 过小时内核启动开销占比增大，吞吐反而下滑。

实践中，块长通常设在系统“一个迭代能消化的 token 预算”附近，例如 max_num_batched_tokens 的 1/2 到 1 倍。同时要为不同优先级的请求配置差异化 SLO：在线对话要求 TTFT 低于 500ms，宁可给小块长；离线批量任务不在乎延迟，就给大块长换吞吐。毕竟，餐厅既有赶时间的商务客，也有不着急的聚餐客，一张菜单（一套策略）服务所有人是最低效的。

店长的智慧在于“按客分策”：对赶时间的客人提高优先级、切小块；对不着急的客人用大块换效率。延迟与吞吐从来不是“谁战胜谁”的关系，而是同一块砧板上的两种切法，关键看你要为哪一类客人保体验。

6. 工程落地实践：从菜谱到看板

好方法还得有好管理。成熟的餐厅会把排单逻辑写进 SOP，用看板实时盯着每桌等菜时间与后厨空闲率；大模型服务的落地也一样，把 Chunked Prefill 从论文变成线上能力，离不开框架支持、指标观测和调优经验。

主流推理框架已把 Chunked Prefill 内置为开箱即用的选项：vLLM 通过 --enable-chunked-prefill 开启，配合 max_num_batched_tokens 控制每个迭代最多处理的 token 数；SGLang 在 RadixAttention 之上天然支持分块与前缀复用；TensorRT-LLM 也提供了 in-flight batching 与 chunked context 能力。对部署工程师来说，这不是“要不要造轮子”的问题，而是“怎么把轮子调顺”的问题。

工程调优讲究“先观测、后动手”。核心指标包括：TTFT（首字延迟）、ITL（词间延迟）、吞吐（token/s）和 GPU 利用率。如果 GPU 利用率低而队列里总有长 prompt，优先调大 batch 预算；如果 P99 延迟超标，再考虑调小块长。同时要认清适用边界：长上下文场景（文档问答、代码库分析、多轮对话）收益最明显；对几十 token 的短请求，分块反而引入额外调度开销，有时直接关闭更省心。

SOP 定好了、看板挂起来了，后厨才能稳定出菜。Chunked Prefill 的落地也是如此：框架负责执行，监控负责反馈，调参负责收尾——三者闭环，长文本推理这台“大胃王”才算真正被驯服。

AI 应用场景

Python 演示

"""对比传统整体 Prefill 与 Chunked Prefill 的推理调度效果"""import mathimport randomimport statistics  class Req:    def __init__(self, rid, arrive, prompt_len, out_len):        self.rid = rid        self.arrive = arrive        self.prompt = prompt_len        self.out = out_len        self.ttft = -1        self.finish = -1  def gen_requests(n, seed):    random.seed(seed)    reqs, t = [], 0    for i in range(n):        t += random.randint(1, 4)        prompt = random.choice([64, 128, 256, 512, 1024, 2048])        reqs.append(Req(i, t, prompt, random.randint(16, 64)))    return reqs  def simulate(reqs, budget=8, chunk=None, wp=0.5):    """chunk=None 走传统整体 Prefill, 否则走 Chunked Prefill"""    reqs = sorted(reqs, key=lambda r: r.arrive)    pref_left = {r.rid: r.prompt for r in reqs}    done = 0    t = idx = 0    while done < len(reqs):        while idx < len(reqs) and reqs[idx].arrive <= t:            idx += 1        active = reqs[:idx]        pend = [r for r in active if r.ttft < 0]        if chunk is None and pend:            r = min(pend, key=lambda x: x.arrive)            steps = max(1, math.ceil(pref_left[r.rid] * wp / budget))            r.ttft = t + steps            t += steps            continue        work = float(budget)        for r in active:            if r.ttft >= 0 and r.out > 0 and work >= 1:                r.out -= 1                work -= 1                if r.out == 0:                    r.finish = t                    done += 1        if chunk is not None and pend and work >= chunk * wp:            r = min(pend, key=lambda x: x.arrive)            pref_left[r.rid] -= chunk            if pref_left[r.rid] <= 0:                r.ttft = t        t += 1    return t  def main():    reqs = gen_requests(30, seed=7)    for name, chunk in [("传统整体 Prefill", None), ("Chunked Prefill", 8)]:        copy = [Req(r.rid, r.arrive, r.prompt, r.out) for r in reqs]        total = simulate(copy, chunk=chunk)        ttfts = sorted(r.ttft for r in copy if r.ttft >= 0)        print("=== %s ===" % name)        print("总耗时(越小吞吐越高): %d 时间步" % total)        print("平均 TTFT: %.1f | P95 TTFT: %.1f"              % (statistics.mean(ttfts), ttfts[int(len(ttfts) * 0.95) - 1]))  if __name__ == "__main__":    main()

1. def simulate(reqs, budget=8, chunk=None, wp=0.5):统一模拟入口，chunk=None 表示传统整体 Prefill，传入块长则走 Chunked 路径。
2. pref_left = {r.rid: r.prompt for r in reqs}记录每个请求还剩多少提示词 token 没算完。
3. while done < len(reqs):一直模拟到所有请求都生成完毕为止。
4. pend = [r for r in active if r.ttft < 0]筛出还没完成预填充的“待备菜”请求。
5. steps = max(1, math.ceil(pref_left[r.rid] * wp / budget))传统模式一次性算完需占用的时间步。
6. for r in active:每个时间步先给已进入解码的请求让路。
7. work -= 1每个解码 token 消耗 1 单位算力预算。
8. if r.out == 0:输出 token 耗尽即标记该请求完成。
9. if chunk is not None and pend and work >= chunk * wp:解码之后还有剩余算力，就切一个 chunk 填充。
10. pref_left[r.rid] -= chunk一个 chunk 处理完，扣减剩余量，接近零时记录 TTFT。

常见误区

面试题