Chunked Prefill

3 秒看懂

一句話： 把長 prompt 拆成小塊逐段處理，讓首字更快出、視訊記憶體更省、GPU 不閒著。

類比： 原來是”整篇課文一口氣讀完才能回答”，現在是”讀一段理解一段，隨時可以插入別人的問題”。

3 分鐘產業解釋

為什麼需要 Chunked Prefill？

在 LLM 推論中，處理使用者輸入（prefill 階段）和逐字生成回答（decode 階段）是兩個性質完全不同的計算：

維度	Prefill 階段	Decode 階段
計算特性	大量矩陣乘法，計算密集	逐 token 生成，訪存密集
並行度	高（可並行處理所有 input tokens）	低（每步只生成 1 token）
視訊記憶體佔用	高（需快取所有 token 的 KV）	較低

核心矛盾： 當輸入 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 的權衡

Chunk Size	TTFT	GPU 算力利用率	排程複雜度
更小	可能更高（排程開銷）	可能降低（小 kernel 效率低）	更高
更大	更高	更接近峰值	更低

典型選擇：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 不是某篇論文的發明，而是工程社群的湧現式解決方案。多個推論架構在解決同一問題時，獨立收斂到了類似的設計。

---

技術路線對比

維度	傳統 Prefill	Chunked Prefill	Prefill-Decode 分離
架構	單一節點處理全流程	單一節點 + 分塊排程	Prefill 和 Decode 獨立叢集
TTFT	長 prompt 時很高	可觀降低（具體幅度依實現）	可單獨擴充套件 prefill 資源
吞吐量	受長 prefill 阻塞	提升（交錯執行）	高（獨立最佳化）
資源利用率	低（GPU 空閒等待）	較高	需精細排程避免資源碎片
實現複雜度	低	中	高（跨節點通訊、負載均衡）
視訊記憶體效率	峰值高	峰值降低	各叢集獨立規劃
代表系統	基礎推論服務	vLLM、TensorRT-LLM	Splitwise、DistServe [學術]

選擇建議：

• 大多數場景：Chunked Prefill 是價效比最優的工程選擇
• 超大規模部署：可考慮 Prefill-Decode 分離，獲得更大彈性

---

上下游

上游依賴

                     ┌─────────────────┐
                     │  Transformer    │
                     │  模型架構        │
                     └────────┬────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
     ┌────────────┐  ┌────────────┐  ┌────────────┐
     │ FlashAttn  │  │  KV Cache  │  │ Batch      │
     │ 高效運算元    │  │  管理      │  │ 排程器     │
     └────────────┘  └────────────┘  └────────────┘
              │               │               │
              └───────────────┼───────────────┘
                              ▼
                    ┌─────────────────┐
                    │  Chunked        │
                    │  Prefill        │
                    └─────────────────┘

下游應用

• RAG（檢索增強生成）：檢索到的文件 prompt 很長，chunked prefill 大幅改善體驗
• 長文件分析：法律合同審查、財報分析等場景
• 程式碼助手：整個程式碼倉庫作為 context
• 多輪長對話：歷史訊息累積後的推論

---

關鍵指標

指標	含義	最佳化方向
TTFT (Time To First Token)	從傳送請求到收到第一個 token 的延遲	越低越好
TPOT (Time Per Output Token)	生成每個 token 的平均延遲	decode 階段主導
GPU 利用率 (MFU)	模型浮點運算利用率	越高成本效率越好
吞吐量 (tokens/sec)	單位時間處理的總 token 數	吞吐量 vs 延遲的權衡
視訊記憶體峰值	單次推論的最大視訊記憶體佔用	chunk size 可調
Chunk 排程開銷	分塊帶來的額外 CPU/排程成本	應趨近於零

---

供需與市場資料

需求側

據行業觀察與廠商揭露：

• 長 prompt 場景佔比上升：RAG、多模態、Agent 等架構推動輸入長度增長
• 使用者對延遲敏感：聊天機器人場景 TTFT > 2 秒體驗顯著下降
• 推論成本壓力：雲端端 GPU 成本高昂，利用率最佳化直接關聯成本

供給側

主要推論架構支援情況：

架構	Chunked Prefill 支援	備註
vLLM	原生支援	是該特性的主要推廣者
TensorRT-LLM	支援	NVIDIA 官方推論引擎
SGLang	支援	高效能推論架構
DeepSpeed-FastGen	支援	微軟架構

市場影響估算

據供應鏈與行業估算：

• 採用 chunked prefill 的部署，長 prompt 場景吞吐量提升幅度可觀（通常在 1.5x-3x 量級，取決於 workload 特性）
• 成本節省比例與硬體型號、模型大小強相關，[具體數字未有統一公開口徑，需根據實際 benchmark 確認]

---

代表公司與資本對映

推論架構/平台

公司/專案	相關產品	角色
vLLM (UC Berkeley)	vLLM 推論引擎	Chunked Prefill 主要推動者，開源
NVIDIA	TensorRT-LLM	GPU 推論最佳化標準，支援該特性
Anyscale	基於 Ray 的推論平台	vLLM 背後的商業化公司
Together AI	推論 API 服務	大規模部署最佳化
Groq	LPU 推論晶片	硬體層面的推論加速路線
AWS	SageMaker 推論	雲端推論服務

資本關聯

• 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	Ring Attention / Sequence Parallelism
問題	排程和吞吐量	單個序列太長放不進一張卡
層面	推論服務排程	計算圖/模型並行
Chunk 語義	排程單元	分散式計算的分割槽
關係	正交，可結合	正交，可結合

❌ 誤讀四：“有了 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、吞吐量和視訊記憶體峰值的多維改善。

---

延伸閱讀與來源

核心參考

來源	說明	獲取方式
vLLM 官方文件	Chunked Prefill 設計與使用	docs.vllm.ai
vLLM GitHub	實現程式碼與 issue 討論	github.com/vllm-project/vllm
”Efficient Memory Management for Large Language Model Serving with PagedAttention” (2023)	vLLM 核心論文	arXiv
”Orca: A Distributed Serving System for Transformer-Based Generative Models” (2022)	Continuous Batching 奠基	OSDI’22
TensorRT-LLM 文件	NVIDIA 實現參考	NVIDIA 官方文件
SGLang 文件	高效能推論架構	github.com/sgl-project/sglang

進階閱讀

來源	說明
Splitwise: Efficient Generative LLM Inference Using Phase Splitting	Prefill-Decode 分離架構
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving	類似方向
FlashAttention 1 & 2	理解 chunk 內部的高效計算

資料來源宣告

• 本文中的效能資料為行業定性估算或廠商公開基準的描述性引用
• 具體數字因硬體型號、模型大小、workload 特性而異，建議以實際 benchmark 為準
• 融資資訊來源為公開報道，未做獨立核實

---

作者注：本文寫作時，聯網檢索未能獲取到可用的技術文件。內容基於對 LLM 推論最佳化領域的技術理解和公開已知資訊撰寫。核心機制描述力求準確，但具體數字（如效能提升比例、chunk size 最優值等）建議讀者參考各架構官方文件和 benchmark 報告。如文中存在技術錯誤，歡迎指正。