Chunked Prefill

3 秒看懂

一句话： 把长 prompt 拆成小块逐段处理，让首字更快出、显存更省、GPU 不闲着。

类比： 原来是”整篇课文一口气读完才能回答”，现在是”读一段理解一段，随时可以插入别人的问题”。

3 分钟产业解释

为什么需要 Chunked Prefill？

在 LLM 推理中，处理用户输入（prefill 阶段）和逐字生成回答（decode 阶段）是两个性质完全不同的计算：

核心矛盾： 当输入 prompt 很长（如 10K+ tokens 的文档分析、代码审查），传统 prefill 会：

1. TTFT 恨天高 —— 用户等很久才看到第一个字
2. 显存峰值爆炸 —— 一次性分配所有 KV cache 空间
3. GPU 利用率塌方 —— 其他 decode 请求被阻塞，GPU 空转

Chunked Prefill 就是针对这个矛盾的工程解法：把长 prefill 切成小 chunk，与 decode 请求交错执行。

产业价值

• 用户体验：TTFT 可显著降低（据行业估算，长 prompt 场景下改善幅度可观）
• 集群成本：相同 GPU 数量下支撑更高并发
• 使能应用：让 RAG、长文档分析、多轮对话等场景真正可用

15 分钟专家深入

执行流程图解

传统 Prefill（一次性）：
┌─────────────────────────────────────────────┐
│ ████████████████████████████████████████████ │  ← 整个 prompt 独占 GPU
│             Prefill（长阻塞）                │
└─────────────────────────────────────────────┘
                                          ↑ TTFT
                                    第一个 token 出来

Chunked Prefill（分块 + 交错）：
┌──────────┬──────┬──────────┬──────┬──────────┬──────┐
│ Prefill  │Decode│ Prefill  │Decode│ Prefill  │Decode│
│ Chunk 1  │ Req A│ Chunk 2  │ Req A│ Chunk 3  │ Req A│
│ (512 tok)│      │ (512 tok)│      │ (512 tok)│      │
└──────────┴──────┴──────────┴──────┴──────────┴──────┘
      ↑                                             
  该请求的 decode 需等待全部 prefill chunk 完成后才开始

关键机制

1. 分块与因果一致性

每个 chunk 内部做标准 self-attention，但必须保证因果性：后面的 chunk 不能”看到”它之前的 chunk 中还没计算的部分。

实现方式：

• Chunk 内：标准 causal mask
• Chunk 间：后续 chunk 的 attention 需要能看到前面所有 chunk 的 KV cache
• 这与标准 Transformer 的因果注意力语义完全一致，只是执行时序变了

Chunk 1 tokens: [t0, t1, t2, t3]  → 计算 KV₁
Chunk 2 tokens: [t4, t5, t6, t7]  → 计算时 attend to KV₁ + 新 token 自身
Chunk 3 tokens: [t8, t9, t10, t11] → attend to KV₁ + KV₂ + 自身
...

2. 与 Continuous Batching 的协同

Chunked Prefill 最大的工程价值体现在与 Continuous Batching（连续批处理）的结合：

# 伪代码逻辑
while requests_in_queue:
    batch = []
    
    # 从正在 decode 的请求中取一个 token 的计算
    batch.extend(get_decode_tokens(active_requests))
    
    # 从 prefill 队列中取一个 chunk
    if pending_prefill_chunks:
        batch.extend(get_next_prefill_chunk())
    
    # 一起送进 GPU 执行
    execute_batch(batch)

这就是 vLLM 的 Chunked Prefill + Continuous Batching 调度器的核心思想。

3. Chunk Size 的权衡

典型选择：512、1024、2048 tokens，需要根据模型架构和硬件特性调优。

技术原理

计算图视角

传统 prefill 对长度 N 的序列，计算复杂度为 O(N²)（self-attention）。

Chunked prefill 将其拆分为 C 个 chunk，每个 chunk 大小为 K = N/C：

总计算量不变：仍然是 O(N²)
调度特性改变：
- 单次 kernel 调用：从 O(N²) 降到 O(K²)（chunk 内 attention）
- 加上 attend to 历史 KV：O(K × i×K)，i 为当前 chunk 编号
- 关键是：小 kernel 之间可以插入其他工作

显存模型

传统 Prefill 显存峰值：
┌────────────────────────────────┐
│     激活值（Activation）       │  ← O(N × d) per layer
│     注意力分数矩阵             │  ← O(N²) per head（FlashAttention 可优化）
│     KV Cache（最终）           │  ← O(N × d) per layer
└────────────────────────────────┘

Chunked Prefill 显存峰值：
┌────────────────────────────────┐
│     激活值（Chunk 大小）       │  ← O(K × d) per layer
│     注意力分数矩阵（Chunk 内） │  ← O(K²) + O(K × accumulated_KV)
│     KV Cache（累计）           │  ← O(N × d) per layer（最终相同）
└────────────────────────────────┘

关键差异：中间激活值的峰值从 O(N) 降到 O(K)。

与 FlashAttention 的关系

• FlashAttention 解决的是”单次 attention 计算的显存效率”（tiling + online softmax）
• Chunked Prefill 解决的是”调度层面的吞吐量和延迟”（将计算拆分可调度单元）
• 两者正交、可叠加：chunk 内部可以用 FlashAttention，chunk 间做调度

与 Prefix Caching 的交互

Chunked Prefill 天然支持 Prefix Caching（前缀缓存）：

• 每个 chunk 的 KV cache 可以独立缓存
• 当多个请求共享相同前缀时（如 RAG 中的文档），可复用已计算的 KV
• 代表性实现：vLLM 的 Automatic Prefix Caching

技术演进史

时间线（近似）：

2022.10  ──  FlashAttention v1 发布
              ↓ 让 attention 计算显存高效，但 prefill 仍是整体执行
              
2023.01  ──  vLLM 项目启动，引入 PagedAttention
              ↓ 主要优化 KV cache 管理，prefill 调度相对简单
              
2023.06  ──  Orca 论文提出 Continuous Batching
              ↓ 打破请求级别粒度，进入 iteration 级别调度
              
2023-24  ──  多篇研究探索 Prefill-Decode 分离架构
              ↓ 如 Splitwise、DistServe 等，将 prefill 和 decode 放在不同节点
              
2023-24  ──  Chunked Prefill 作为工程实践逐步成熟
              ↓ vLLM、TensorRT-LLM 等框架原生支持
              
2024+    ──  更细粒度调度，与 Speculative Decoding、MoE 等结合

关键认知： Chunked Prefill 不是某篇论文的发明，而是工程社区的涌现式解决方案。多个推理框架在解决同一问题时，独立收敛到了类似的设计。

技术路线对比

选择建议：

• 大多数场景：Chunked Prefill 是性价比最优的工程选择
• 超大规模部署：可考虑 Prefill-Decode 分离，获得更大弹性

上下游

上游依赖

                     ┌─────────────────┐
                     │  Transformer    │
                     │  模型架构        │
                     └────────┬────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
     ┌────────────┐  ┌────────────┐  ┌────────────┐
     │ FlashAttn  │  │  KV Cache  │  │ Batch      │
     │ 高效算子    │  │  管理      │  │ 调度器     │
     └────────────┘  └────────────┘  └────────────┘
              │               │               │
              └───────────────┼───────────────┘
                              ▼
                    ┌─────────────────┐
                    │  Chunked        │
                    │  Prefill        │
                    └─────────────────┘

下游应用

• RAG（检索增强生成）：检索到的文档 prompt 很长，chunked prefill 大幅改善体验
• 长文档分析：法律合同审查、财报分析等场景
• 代码助手：整个代码仓库作为 context
• 多轮长对话：历史消息累积后的推理

关键指标

供需与市场数据

需求侧

据行业观察与厂商披露：

• 长 prompt 场景占比上升：RAG、多模态、Agent 等架构推动输入长度增长
• 用户对延迟敏感：聊天机器人场景 TTFT > 2 秒体验显著下降
• 推理成本压力：云端 GPU 成本高昂，利用率优化直接关联成本

供给侧

主要推理框架支持情况：

市场影响估算

据供应链与行业估算：

• 采用 chunked prefill 的部署，长 prompt 场景吞吐量提升幅度可观（通常在 1.5x-3x 量级，取决于 workload 特性）
• 成本节省比例与硬件型号、模型大小强相关，[具体数字未有统一公开口径，需根据实际 benchmark 确认]

代表公司与资本映射

推理框架/平台

资本关联

• Anyscale：已获多轮融资，估值据报达到数十亿美元级别 [来源：公开融资报道]
• Together AI：获 GPU 厂商和 AI 基金投资 [来源：公开报道]
• NVIDIA：通过 TensorRT-LLM 生态绑定推理框架标准

投资视角：推理优化是”卖水人”逻辑，无论谁的模型胜出，都需要高效推理基础设施。

投资逻辑

核心论点

1. 推理成本是 AI 商业化的关键卡点

   • 训练是一次性的，推理是持续的
   • Token 经济学：每降低一分推理成本，就扩大一分可盈利应用场景

2. 长上下文是大趋势

   • 128K、1M+ 上下文窗口成为竞争焦点
   • 长 prompt 场景下，chunked prefill 从”锦上添花”变成”必需品”

3. 软件优化的复利效应

   • 硬件迭代周期长（制程、封装）
   • 软件优化可以持续叠加：Chunked Prefill + FlashAttention + Quantization + Speculative Decoding + …
   • 推理效率的摩尔定律（软+硬）

风险因素

• 硬件厂商自研推理栈：NVIDIA TensorRT、AMD ROCm 可能吃掉独立框架的空间
• 模型架构突变：如果 Transformer 被新架构替代，现有优化可能失效
• 开源竞争：vLLM 等开源项目可能压低商业化空间

标的思考框架

问三个问题：
1. 这家公司是否在"推理效率"上建立了技术壁垒？
2. 壁垒是否可被硬件代际升级或模型架构变革抹平？
3. 商业模式是否能随推理量线性增长？

常见误读纠偏

❌ 误读一：“Chunked Prefill 减少了总计算量”

纠偏： 没有减少。总计算量由模型架构和序列长度决定，Chunked Prefill 改变的是计算的时序调度，不是计算量本身。

• 如果所有请求都是纯 prefill（无 decode 并发），chunked prefill 可能反而因调度开销略慢
• 真正的价值在于：prefill 与 decode 的交错执行，让 GPU 不闲着

❌ 误读二：“Chunk Size 越小越好”

纠偏： 存在 sweet spot。

• 太小：kernel launch 开销占比高，GPU 算力利用率低，调度复杂度上升
• 太大：失去交错执行的灵活性，接近传统 prefill
• 实践：通常在 512-2048 tokens 范围，需针对具体硬件和 workload 调优

❌ 误读三：“Chunked Prefill 是 Chunked Attention（Ring Attention）”

纠偏： 两者解决不同问题。

❌ 误读四：“有了 Chunked Prefill 就不需要 PagedAttention 了”

纠偏： 两者互补，不是替代关系。

• PagedAttention：解决 KV cache 的显存碎片化问题（按需分配页，而非连续分配）
• Chunked Prefill：解决调度粒度问题（让 prefill 可中断、可交错）
• 一个管”怎么放”，一个管”什么时候算”

学习路径

入门（30 分钟）

1. 理解 Prefill vs Decode：看任意 LLM 推理入门文章
2. 了解 Continuous Batching：Orca 论文或 vLLM 博客
3. 看 vLLM 官方文档 中关于 Chunked Prefill 的说明

进阶（2-3 小时）

4. 读 vLLM 设计文档：理解 PagedAttention + Chunked Prefill + Continuous Batching 的完整调度逻辑
5. 跑个实验：用 vLLM 启动服务，对比开启/关闭 chunked prefill 的 TTFT 差异
6. 看 SGLang / TensorRT-LLM 的相关文档：不同实现的对比

专家（持续跟进）

7. Prefill-Decode 分离架构论文：Splitwise、DistServe 等
8. 看推理框架源码：重点是 scheduler 和 KV cache manager
9. 关注调度算法：如 FCFS、最短作业优先、公平调度等在推理场景的变种
10. 跟踪硬件演进：HBM 带宽、NVLink 拓扑变化对调度策略的影响

一句话总结

Chunked Prefill 通过将长 prompt 的计算拆分为可调度的小块，实现与 decode 请求的交错执行，在不改变模型、不减少计算量的前提下，用调度层面的巧思换取 TTFT、吞吐量和显存峰值的多维改善。

延伸阅读与来源

核心参考

进阶阅读

数据来源声明

• 本文中的性能数据为行业定性估算或厂商公开基准的描述性引用
• 具体数字因硬件型号、模型大小、workload 特性而异，建议以实际 benchmark 为准
• 融资信息来源为公开报道，未做独立核实

作者注：本文写作时，联网检索未能获取到可用的技术文档。内容基于对 LLM 推理优化领域的技术理解和公开已知信息撰写。核心机制描述力求准确，但具体数字（如性能提升比例、chunk size 最优值等）建议读者参考各框架官方文档和 benchmark 报告。如文中存在技术错误，欢迎指正。