預填充階段
3 秒看懂
Prefill 是大型模型推論的第一個階段:把一整段使用者輸入(prompt)一口氣跑完,生成後續生成所需的所有隱藏狀態(KV Cache)。它決定首 token 延遲,計算密度極高,可以並行處理輸入中的所有 token。
3 分鐘產業解釋
當用戶向大語言模型輸入一段提示(prompt)時,推論伺服器並不會逐字逐 token 慢慢處理,而是將整個 prompt 一次性輸入模型。這個一次性處理的過程就是 Prefill(預填充)。 Prefill 階段會計算輸入序列所有層的 Key、Value 向量,並存入 KV Cache,同時輸出最後一個 token 的隱狀態作為解碼起點。此後進入 Decode(解碼) 階段,模型一個 token 一個 token 地自迴歸生成回覆。
Prefill 的計算特點是:
- 計算密集: 對 prompt 的每一層執行矩陣乘法,計算量大但高度並行,能打滿 GPU 算力。
- 延遲主導首 token: 使用者感知的“首個 token 生成時間”(TTFT)主要由 Prefill 耗時決定。
- 與 prompt 長度的關係: 計算量通常與 prompt 長度呈平方或線性關係(取決於注意力實現),prompt 越長,Prefill 時間越長。
工業界圍繞 Prefill 做了大量最佳化,比如 分塊預填充(Chunked Prefill)、與 Decode 的混合排程,以及將長 prompt 拆成多個 Prefill 任務以避免阻塞解碼請求。
15 分鐘專家深入
在 Transformer 自迴歸推論過程中,Prefill 階段本質上是一次非自迴歸的前向傳播。因為輸入序列的所有 token 已經完整給定,不存在 token 間的時序依賴,所以可以像訓練時一樣,用大規模矩陣乘法一次完成所有位置的計算。
Prefill 階段的主要任務:
- 對輸入序列全部 token 計算每一層自注意力的 Query(Q)、Key(K)、Value(V)。
- 執行注意力分數計算和 softmax,得到每個層對所有位置的注意力輸出。
- 將每一層的 K、V 張量存入 KV Cache,供後續 Decode 階段複用,避免重複計算歷史 token。
- 輸出序列最後一個 token 的隱狀態,作為自迴歸生成第一個新 token 的起始條件。
從系統排程角度看,一個推論請求經歷 Prefill 後,會建立一個 KV Cache 塊,並與該請求繫結。這個階段通常會獨佔 GPU 的計算資源,直到 Prefill 完成,才會釋放部分算力給其他請求的 Decode 步驟。
針對超長 prompt,業界發展出 Chunked Prefill:將長 prompt 切分成多個固定長度的塊(chunk),每次只預填充一個 chunk 並儲存部分 KV Cache,中間可以穿插其他請求的 Decode,以減少隊頭阻塞。但這並非讓當前請求在 Prefill 期間就能開始解碼;其解碼仍需所有 chunk 完成後才啟動,整體吞吐提升來自交錯排程其他請求的解碼。
vLLM 等架構更是實現了 Prefill 與 Decode 的統一排程:排程器動態決定將一次迭代分配給某個請求的 Prefill Chunk,還是某個請求的 Decode 步驟,從而在首 token 延遲與吞吐量之間取得更優平衡。
在分散式推論中,Prefill 可能觸發跨卡通訊。張量並行下,注意力計算中的矩陣乘法會被切分,中間結果需要 AllReduce;序列並行下,長 prompt 可能被分割到不同裝置,計算注意力時涉及額外的通訊。這些都會影響 Prefill 的延遲和擴充套件效率。
技術原理(最深層次)
計算過程與關鍵引數
給定輸入序列長度 S,層數 L,隱藏維度 d,注意力頭數 H,每頭的維度 d_h。
在 Prefill 階段,輸入形狀為 [batch\_size, S, d](推論時 batch_size 常為 1)。
- 線性投影:
通過權重矩陣
W_Q, W_K, W_V \in mathbb(R)^{d \times d}一次性映射出 Q, K, V,形狀均為[b, S, H, d_h]。 - 注意力分數與加權: 標準縮放點積注意力:
text(Attention)(Q, K, V) = text(softmax)\!\left(frac(Q K^T){sqrt(d_h)}\right) V
這裡 Q K^T 是一個 [b, H, S, S] 的矩陣,計算量 O(H \cdot S^2 \cdot d_h)。對於長序列,這部分的視訊記憶體和計算開銷急劇增長。FlashAttention 等最佳化演算法通過分塊計算避免完整 S×S 矩陣的物化,在不改變總計算量的情況下,通過減少對全域性記憶體的讀寫將 I/O 開銷的常數因子大幅降低,但計算總量不變。
3. KV 快取更新:
每一層的 K、V 直接儲存到 KV Cache 結構中,形狀 [b, H, S, d_h]。後續解碼階段每生成一個新 token,只需計算該 token 的 Q,並與已快取的完整 K、V 進行注意力運算。
4. 輸出準備:
注意力輸出經輸出投影後,通過前饋網路(FFN),最終得到形狀 [b, S, d]。通常只取最後一個位置的隱狀態 h_S 用於預測下一個 token 的 logits。
計算量估算:
- 多頭注意力的矩陣乘法:
4 \cdot b \cdot S \cdot d \cdot d(投影部分)+O(b \cdot H \cdot S^2 \cdot d_h)(注意力計算)。 - 前饋網路:通常兩個線性層,形如
4 \cdot b \cdot S \cdot d \cdot d_{ff}(其中d_{ff}是 FFN 中間維度,常為 4d 或 8d/3 等)。 綜合來看,Prefill 的 FLOPs 與輸入長度呈近似線性到平方關係,取決於注意力複雜度佔主導時的 S² 項。在 S 較小(如幾百)時,線性部分主導;S 很大(數千或數萬)時,平方項開始顯著影響。
記憶體與視訊記憶體佔用
Prefill 階段視訊記憶體增量以 KV Cache 為主。每層的 KV Cache 大小 = 2 \cdot b \cdot H \cdot S \cdot d_h \cdot 2 位元組(FP16 下)。總 KV Cache 大小 = 2 \cdot 2 \cdot L \cdot b \cdot H \cdot S \cdot d_h 位元組。對於 7B 模型,L=32,H=32,d_h=128,單請求 2048 token 的 KV Cache 約 1 GB;S=2萬時則膨脹至數 GB,直接限制併發請求數。
分段執行示例(ASCII 流程圖)
時間 →
請求到達: [prompt tokens: x1, x2, ..., xn]
↓
[Prefill Start]
| 輸入 Embedding: [b, n, d]
| 層 i=1..L:
| Linear(Q,K,V) [b, n, d] → [b, n, H, d_h]
| Attention(Q, K, V) 計算 [b, H, n, n] 注意力
| └─ 將 K, V 寫入 KV Cache
| FFN: SwiGLU / ReLU 等
| 輸出: [b, n, d]
| (通常僅保留最後一個位置) → 解碼起點
[Prefill End]
↓
[Decode Loop]
| 層 i=1..L:
| 僅輸入新 token x_t,計算其 Q,與 KV Cache 中之前所有 K,V 做注意力
| 更新 KV Cache(新增一個位置)
| 輸出 x_{t+1} 直至 EOS
關鍵最佳化技術:
- 分塊預填充: 將 n 個 token 分成 k 個塊,每次只計算一個塊,可穿插解碼,平衡延遲與吞吐。
- MLA / MQA / GQA: 減少 KV 快取頭數,縮短 KV Cache 長度,間接降低 Prefill 的記憶體和計算壓力。
- Pipeline 並行: 將 Prefill 分佈在多張 GPU 上,通過微批次流水線減少氣泡。
技術演進史
- 原始 Transformer 推論(2017-2019): 沒有明確的 Prefill 概念,早期架構將輸入序列逐 token 送入或一次性前向,但未系統性區分兩個階段,也未充分最佳化 KV Cache 管理。
- KV Cache 成為標準(2019-2020): 以 HuggingFace Transformers 為代表,實現
use_cache=True,自動在第一次 forward 時快取所有層的 K、V,並用於後續自迴歸步驟。Prefill 一詞逐漸被社群用來指代這第一次快取計算的過程。 - 高效推論系統興起(2022-2023): vLLM、TensorRT-LLM 等專門推論引擎出現,顯式地將請求處理分為 Prefill 和 Decode 兩個排程階段。vLLM 提出 PagedAttention,將 KV Cache 以塊管理,Prefill 時動態分配塊,支援更靈活的視訊記憶體共享。
- Chunked Prefill 與混合排程(2023-2024): 為解決長 prompt 阻塞問題,Sarathi-Serve、vLLM 等引入分塊預填充。將 Prefill 切割為多個 step,與 Decode 交替執行,大幅降低長序列請求的平均延遲和隊頭阻塞。
- Disaggregated Prefill 探索(2024-): 學界和業界開始嘗試將 Prefill 和 Decode 分離到不同的硬體池(Prefill 節點計算密集,Decode 節點記憶體頻寬密集),獨立擴縮容,以精細化資源利用率。部分開源專案已實現原型。
技術路線對比
| 維度 | 全量 Prefill (Naive) | Chunked Prefill | Disaggregated Prefill |
|---|---|---|---|
| 排程策略 | 整個 prompt 一次性計算完,期間不響應 Decode | 將 prompt 分成固定長度塊,塊間可插入 Decode 步驟 | Prefill 和 Decode 物理分離,各自獨立排程 |
| 首 token 延遲 | 長 prompt 下很高,且易阻塞其他請求 | 首 token 延遲仍等於全序列 Prefill 完成時間,分塊本身不降低本請求 TTFT | 端到端延遲增加一次跨節點資料傳輸,但可彈性擴縮容 |
| 吞吐量 | 長 prompt 時 GPU 利用率高,但請求排隊嚴重 | 高,通過混合排程最大化硬體利用 | 可針對 Prefill 和 Decode 分別配置算力/記憶體頻寬最佳化的硬體 |
| KV Cache 管理 | 一次性分配所有塊 | 逐塊分配,記憶體碎片更少 | 需要在 Prefill 節點與 Decode 節點間傳輸 KV Cache,增加網路開銷 |
| 系統複雜度 | 低 | 中等,需實現分塊和混合排程 | 高,需解決 KV 傳輸、一致性、負載均衡 |
| 代表實現 | 早期 vLLM ≤0.2.x, HuggingFace generate | vLLM ≥0.3.x, Sarathi-Serve | Splitwise, DistServe 等學術系統 |
上下游
上游:
- 模型架構: 注意力機制(MHA、GQA、MLA)、歸一化層、啟用函式,影響 Prefill 計算量和視訊記憶體佔用。
- 模型訓練: 預訓練得到的權重影響推論效率,訓練時蒸餾/量化可為 Prefill 加速準備。
- 運算元庫: FlashAttention、FlashInfer、cuBLAS 等高度最佳化的核函式直接決定 Prefill 的浮點效率。
- 硬體: GPU(NVIDIA H100/H800/B200)、NPU、ASIC 等,其矩陣乘法吞吐量和視訊記憶體頻寬是 Prefill 效能的天花板。
下游:
- 推論服務架構: vLLM、SGLang、TensorRT-LLM、OpenLLM,直接面向用戶的 API 延遲和吞吐。
- 上層應用: 聊天助手、程式碼補全、文本摘要、多模態互動等,其對 TTFT 的敏感度不同,影響 Prefill 最佳化的側重點。
- 雲端服務與託管平台: 按 token 計價的 MaaS,Prefill 的效率直接影響毛利率和排程策略。
- 硬體採購決策: 對 Prefill 高比重場景,傾向高算力 GPU;對 Decode 高比重,傾向高頻寬 GPU。
關鍵指標
- 首 token 生成時間 (TTFT): 從請求發出到首個生成 token 的延遲,Prefill 耗時佔主導。
- Prefill 吞吐量 (tokens/s): 單位時間處理的 prompt 總 token 數,反映計算效率。
- KV Cache 佔用 (GB): 每個請求的視訊記憶體開銷,影響最大併發數。
- 長序列衰減係數: 當 prompt 長度加倍時,TTFT 增長的比率。標準Transformer自注意力計算複雜度為O(n²),FlashAttention等最佳化僅降低I/O開銷,未改變平方特性,因此實際增長接近平方而非線性;只有採用線性注意力機制才可能實現近似線性增長。
- 排程組合效率: 在混有不同長度請求的場景下,Prefill 策略對整體請求佇列等待時間的影響。
供需與市場資料
- 需求側: 隨著 Agent 工作流、檢索增強生成(RAG)、長文件分析普及,prompt 長度已從幾百 token 激增至數萬甚至數十萬 token。Google Gemini 1.5 Pro 支援 100 萬 token 上下文視窗,推高了對極致 Prefill 效能的需求。
- 供給側: NVIDIA 新一代 GPU 的算力(H200 的 1979 TFLOPS FP8)和視訊記憶體頻寬(H200 的 4.8 TB/s)持續提升,配合 FlashAttention-3 等演算法,Prefill 處理能力每代有 1.5-2 倍提升。[根據輝達產品白皮書估算]
- 定價影響: 部分推論 API 開始區分輸入 token 和輸出 token 的單價(輸入通常低價,因為計算效率高),但輸入 token 價格隱含了 Prefill 成本。若未來長 prompt 成為主流,輸入 token 定價可能上浮以覆蓋視訊記憶體頻寬壓力。
- 產業鏈規模: 暫無專門針對 Prefill 環節的獨立市場規模統計,但它依附於大型模型推論市場。據 Ark Invest 等機構預測,2030 年全球推論市場可達數百億美元,其中 Prefill 相關的軟硬體最佳化將分享可觀份額。
代表公司與資本對映
- NVIDIA: 硬體龍頭,GPU 算力和 TensorRT-LLM 推論庫直接定義 Prefill 效能基線。其 Grace Hopper 架構中 high-bandwidth memory 專門緩解 KV Cache 頻寬瓶頸。
- AI 推論架構公司/專案:
- vLLM(加州大學伯克利分校發起,已成為社群主流):率先引入PagedAttention,並後續集成了Chunked Prefill技術(該技術最早由Sarathi-Serve提出),是Prefill最佳化領域的標杆專案。
- Anthropic: 其內部推論系統可能已採用 Disaggregated 或類似技術,但未公開細節。Claude 長上下文能力背後依賴高效 Prefill。
- OpenAI: 通過分層快取、推測解碼等綜合技術降低 TTFT,間接最佳化 Prefill 感知延遲。
- 雲端運算廠商(AWS、Azure、GCP):自研推論加速晶片(Trainium、Inferentia、TPU)時需專門設計 Prefill 流水線,例如 TPU v5p 的 SparseCore 可能被用於加速注意力計算。
- 創業公司:
- d-Matrix: 針對推論的存內計算晶片,強調 Prefill 和 Decode 的異構計算。
- Groq: LPU 架構擅長低延遲,其 Prefill 處理因確定性排程而表現出極低的首 token 延遲。
投資邏輯
- 長上下文應用爆發帶來的 Prefill 最佳化剛需: RAG、法律合同審查、生物序列分析等場景要求處理超長 prompt,能夠用線性或亞線性複雜度處理 Prefill 的技術(如 Mamba、RWKV、線性注意力)或硬體可能獲得超額收益。
- 推論成本結構分化: 當輸入 token 遠多於輸出 token(如摘要生成),總體推論成本主要由 Prefill 驅動。投資能大幅降低 Prefill 單位成本(例如專用 ASIC)的公司將受益於知識密集型應用的擴充套件。
- 推論基礎設施的分化: 未來可能出現 Prefill 和 Decode 分別最佳化的異構叢集,伺服器、交換器、記憶體廠商將在該趨勢中尋找新機遇。
- 軟體生態壁壘: Chunked Prefill、Disaggregated 等方案需要深度整合到推論架構,已建立生態的架構(如 vLLM 社群)具有先發優勢,相關商業支援公司具備資本價值。
常見誤讀糾偏
-
誤讀:“Prefill 階段就是模型的一次訓練前向”
- 糾偏: 雖然都包含完整前向傳播,但訓練前向需要保留所有中間啟用用於反向傳播,而 Prefill 只保留 KV Cache,且目標是最小化延遲,因此在記憶體分配、計算融合、精度上差異顯著。Prefill 可以採用非確定性演算法(如 FlashAttention 的 recompute 技巧)和更低精度(INT8/FP8/FP4),而訓練通常難以直接套用。
-
誤讀:“Chunked Prefill 把 Prefill 拆小會降低 GPU 利用率”
- 糾偏: 長 prompt 一次 Prefill 的確能讓 GPU 滿載,但這會導致其他短請求排隊等待,整體 GPU 雖然“看起來”利用率高,但系統吞吐量可能因隊頭阻塞反而降低。Chunked Prefill 通過穿插短請求的 decode 步驟,讓 GPU 計算單元和記憶體頻寬更均衡地忙碌,實際整體吞吐提升,尾延遲降低。尤其在批次推論場景下,混合排程比純全量 Prefill 更優。
學習路徑
- 基礎: 閱讀 Transformer 原論文《Attention Is All You Need》,理解自注意力機制,手動推導 Prefill 與 Decode 的差異。
- 動手: 使用 HuggingFace
model.generate()開啟return_dict_in_generate,觀察 KV Cache 狀態;嘗試呼叫 vLLM 的離線推論並設定max_num_batched_tokens感受分塊排程。 - 深入系統: 閱讀 vLLM 論文《Efficient Memory Management for Large Language Model Serving with PagedAttention》及 Chunked Prefill 相關 blog,理解排程器設計。
- 硬核核心: 學習 FlashAttention 和 FlashInfer 的實現,理解如何在 CUDA 核函式中通過 tiling 避免完整注意力矩陣讀寫,並對映到 Prefill 的高吞吐。
- 前沿: 追蹤 Disaggregated Prefill 論文《Splitwise: Efficient Generative LLM Inference Using Phase Splitting》及開源專案 DistServe,思考分離式架構的商業可行性。
一句話總結
Prefill 是 LLM 推論中將 prompt 一次處理並奠定生成基礎的階段,其計算密集特性與最佳化方向直接定義了大型模型應用的首延遲體驗和成本結構。
延伸閱讀與來源
- Vaswani et al., 《Attention Is All You Can》, NeurIPS 2017.
- Kwon et al., 《Efficient Memory Management for Large Language Model Serving with PagedAttention》, SOSP 2023.
- Agrawal et al., 《Sarathi-Serve: A Low-Latency and High-Throughput Scheduling for LLM Inference》, OSDI 2024.
- Patel et al., 《Splitwise: Efficient Generative LLM Inference Using Phase Splitting》, ISCA 2024 (or arXiv 2311.18677).
- NVIDIA TensorRT-LLM 文件, FlashAttention 算法系列 (Dao et al., 2022, 2023).
- vLLM 專案 GitHub: https://github.com/vllm-project/vllm
- 各公司財報/技術部落格中對推論延遲和吞吐的公開揭露(未提供具體數值,但可用於驗證趨勢)。