In-flight Batching
3 秒看懂
一句話： 不等一個批次全部生成完，誰先”飛完”就立刻讓新請求”插隊”上 GPU，讓算力永遠不閒著。
類比： 傳統批處理像一桌團餐——所有人吃完才能上下一桌；In-flight Batching 像旋轉壽司——空出一個盤子立刻補上一盤新的。
3 分鐘產業解釋
為什麼這項技術重要？
大語言模型（LLM）推論分為兩個階段：
| 階段 | 特徵 | 計算瓶頸 |
|---|---|---|
| Prefill（預填充） | 一次性處理全部輸入 token | 計算密集（Compute-bound），算術強度高 |
| Decode（自迴歸解碼） | 每步只生成 1 個 token | 頻寬密集（Memory-bound），算術強度極低 |
傳統靜態批處理（Static Batching）的做法：湊齊一批請求，全部跑完 decode 才能上下一批。問題在於——不同請求的生成長度差異極大。短請求早早結束，但 GPU 必須為它做無效的 padding 計算，等最長的那個跑完。GPU 利用率被最慢的請求拖死。
In-flight Batching 的核心創新：以每次 decode 迭代為排程粒度（而非以整個請求為粒度），一旦某個請求生成完畢、釋放了算力槽位，立刻從佇列中拉入新請求填補。這使得 GPU 上的”有效工作”幾乎恆定滿載。
產業影響概覽
- 吞吐量提升：相同 GPU 叢集下，推論吞吐量可提升數倍（具體取決於工作負載長度方差，幅度一般在 2–8× 區間，[業界實測經驗值，未統一口徑]）
- 單位推論成本下降：每百萬 token 的 GPU 成本顯著降低
- H100/H200 等高階卡的價值被放大：算力越強，靜態批處理的浪費越大，動態排程的收益也越大
- 已成為行業標配：主流推論架構幾乎全部實現了這一機制或其變體
15 分鐘專家深入
核心機制詳解
In-flight Batching 的排程迴圈可以概括為一個 “檢查-驅逐-填充” 的迭代過程：
每一步 decode 迭代:
1. [檢查] 所有正在 decode 的序列，是否有序列已生成 EOS / 達到最大長度？
2. [驅逐] 將已完成的序列從 GPU 上移除，回收其 KV Cache 槽位
3. [填充] 從等待佇列中選取新請求，執行 prefill（可分塊），
將其 KV Cache 寫入回收的槽位，加入當前 decode 批次
4. [執行] 對當前批次中所有活躍序列執行一次 decode 步這個迴圈的關鍵在於：批次的大小和成員是動態變化的，但 GPU 看到的每一拍都是一個”儘量滿載”的計算任務。
與靜態批處理的精確對比
靜態批處理時間線（請求 A 短，B 中，C 長）:
時間 ──────────────────────────────────────────►
A: [prefill][decode][decode][PAD ][PAD ][PAD ] ← 浪費
B: [prefill][decode][decode][decode][PAD ][PAD ] ← 浪費
C: [prefill][decode][decode][decode][decode][decode]
In-flight Batching 時間線:
時間 ──────────────────────────────────────────►
A: [prefill][decode][decode]→ 完成，釋放槽位
B: [prefill][decode][decode][decode][decode]→ 完成
C: [prefill][decode][decode][decode][decode][decode]
D: ← A 的槽位釋放後立即插入
E: ← B 的槽位釋放後立即插入靜態批處理中，A、B 結束後的 GPU 時間被 padding 佔據；動態批處理中，D、E 被立即拉入，GPU 上的有效 token 處理密度始終接近峰值。
Prefill 的”搶佔”問題與 Chunked Prefill
一個微妙的工程問題：當新請求的 prefill 階段很長（例如輸入 4096 token），它會”霸佔”整個迭代步，導致正在 decode 的請求被卡住，尾延遲（Tail Latency）飆升。
解決方案是 Chunked Prefill（分塊預填充）：
- 將長 prefill 切分為固定大小的 chunk（如每塊 512 token）
- 每個 chunk 與 decode 步交替執行
- 確保 decode 請求的單步延遲不會因新請求插入而產生尖刺
這一思想在 [Sarathi / Sarathi-Serve, Microsoft, 已正式發表於 OSDI 2024] 和 DeepSpeed-FastGen 中被系統化。NVIDIA TensorRT-LLM 的 in-flight batching 實現也支援類似的 chunked prefill 機制。
KV Cache 管理的協同最佳化
動態批排程使 KV Cache 的生命週期變得不可預測——請求隨時插入和退出，傳統的預分配連續記憶體方式會導致嚴重的內部碎片和外部碎片。
這催生了 PagedAttention（[vLLM, Kwon et al., SOSP 2023]）：
- KV Cache 被組織為固定大小的”頁”（如每頁 16 token 的 KV 向量）
- 通過頁表（Block Table）對映到物理記憶體，不要求物理連續
- 請求完成時釋放其頁，立即可被新請求複用
- 記憶體浪費率從傳統方案的 60–80% 降至接近 0（[vLLM 論文資料]）
技術原理
LLM 推論的兩階段計算特徵
┌─────────────────────────────────────────────────────┐
│ Prefill（預填充階段） │
│ │
│ 輸入: [t₁, t₂, ..., tₙ] (N 個 token) │
│ 計算: 所有 token 並行處理，生成完整的 KV Cache │
│ 特徵: Compute-bound, 算術強度 O(N) │
│ GPU 利用: SM 佔用高, Tensor Core 滿載 │
│ │
│ FLOPs ≈ 2 × N × L × d² (簡化, L=層數, d=隱藏維度) │
│ HBM 讀取 ≈ L × (12d²) × W_byte (讀模型引數,∼L·d²) │
│ 算術強度 ∝ N (隨輸入長度線性增長) │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Decode（解碼階段,每步） │
│ │
│ 輸入: 1 個新 token + 已有 KV Cache │
│ 計算: 計算 Attention + FFN, 生成 1 個輸出 token │
│ 特徵: Memory-bound, 算術強度 O(1) │
│ GPU 利用: SM 大量閒置, 頻寬是瓶頸 │
│ │
│ HBM 讀取 ≈ L × (12d²) × W_byte + KV_cache_大小 │
│ (每步都要讀取全部模型引數 + 完整 KV Cache) │
│ FLOPs 僅與單個 token 對應, 算術強度極低 │
└─────────────────────────────────────────────────────┘排程狀態機
┌──────────────┐
│ 等待佇列 │
│ (Waiting) │
└──────┬───────┘
│ 有空餘槽位 且 可排程
▼
┌──────────────┐
┌──────│ Prefill │
│ │ (可分塊執行) │
│ └──────┬───────┘
│ │ prefill 完成
│ ▼
│ ┌──────────────┐◄────────────┐
│ │ Decode │ │
│ │ (逐 token) │── 繼續生成 ──┘
│ └──────┬───────┘
│ │ 生成 EOS 或達 max_length
│ ▼
│ ┌──────────────┐
│ │ Completed │ → 返回結果給使用者
│ └──────────────┘
│
│ chunk 未完成 → 回到 Prefill
└──────────────────────────┘Batch 內的異構執行
一個迭代步中可能同時包含：
- Decode 請求：正在逐 token 生成的序列
- Prefill chunk 請求：新進入的序列在做 prefill 分塊
排程器需要將這兩類請求合理編排到同一個 GPU kernel launch 中。TensorRT-LLM 的做法是通過 padding 和 mask 將異構請求對齊到統一的 tensor shape 上執行；vLLM/SGLang 則通過 PagedAttention kernel 在 kernel 層面直接處理不同長度的序列。
關鍵公式：批次吞吐量
吞吐量 (tokens/sec) ≈ (B_eff × SPS)
其中:
B_eff = 有效批次大小（動態批處理下接近 GPU 最大承載能力）
SPS = 單步解碼速度 (steps/sec)
靜態批處理中:
B_eff = min(B_max, 可用請求數) 但隨請求完成而衰減
有效 GPU 利用率隨時間遞減
In-flight Batching 中:
B_eff ≈ B_max（持續, 只要佇列非空）
有效 GPU 利用率近乎恆定技術演進史
| 時間 | 里程碑 | 關鍵貢獻 |
|---|---|---|
| 2022 | Orca 論文 [OSDI 2022, Yu et al., Seoul National University & Microsoft Research] | 提出”iteration-level scheduling”概念，區分請求級與迭代級排程；引入 selective batching 通過分塊預填充實現 prefill 與 decode 交替執行 |
| 2023 Q1 | vLLM [Kwon et al., UC Berkeley, SOSP 2023] | PagedAttention + 連續批處理；KV Cache 按頁管理，記憶體利用率接近理論極限 |
| 2023 | TensorRT-LLM [NVIDIA] | 將該技術命名為 “In-flight Batching”，整合到 NVIDIA 官方推論引擎；支援 FP8/INT4 量化下的連續批處理 |
| 2023 | DeepSpeed-FastGen [Microsoft] | 系統化提出 SplitFuse（chunked prefill + decode 的統一排程） |
| 2023 | Sarathi-Serve [Microsoft] | 專門最佳化 chunked prefill 的排程策略，減少 prefill 對 decode 延遲的干擾 |
| 2024 | SGLang [UC Berkeley] | RadixAttention + 連續批處理；通過 radix tree 複用字首 KV Cache，進一步提升多輪對話效率 |
| 2024 | 行業收斂 | 主流推論架構（vLLM, TRT-LLM, TGI, SGLang, DeepSpeed-FastGen）全部支援某種形式的連續批處理，成為預設排程策略 |
技術脈絡總結： Orca 定義了問題 → vLLM 證明了 KV Cache 管理的關鍵性 → TensorRT-LLM 將其產品化 → Sarathi/SGLang 解決了 chunked prefill 的細節工程問題 → 2024 年成為行業共識。
技術路線對比
| 維度 | 靜態批處理 (Static Batching) | 連續批處理 (In-flight / Continuous) | 連續批處理 + PagedAttention | 連續批處理 + Chunked Prefill |
|---|---|---|---|---|
| 排程粒度 | 請求級 | 迭代級 | 迭代級 | 迭代級 + 分塊 |
| GPU 利用率 | 隨請求完成遞減，長尾浪費嚴重 | 接近恆定滿載 | 接近恆定滿載 + 記憶體碎片極小 | 最優：decode 不被長 prefill 打斷 |
| 吞吐量（相對） | 1×（基準） | 2–5×（[業界經驗估算，取決於負載方差]） | 3–6× | 3–8× |
| P99 ITL | 高（長尾嚴重） | 較低 | 較低 | 最低 |
| 實現複雜度 | 極低 | 中等 | 高（需自定義 Attention kernel） | 最高（需分塊排程器 + 負載均衡） |
| KV Cache 記憶體浪費 | 60–80%（[vLLM 論文資料]） | 與靜態類似（取決於實現） | 接近 0% | 接近 0% |
| 代表實現 | 早期 HF generate() | 早期 TGI | vLLM, TensorRT-LLM | Sarathi-Serve, DeepSpeed-FastGen, SGLang |
注： 吞吐量倍數為不同工作負載下的經驗區間，非單一標準測試結果。
上下游
上游：In-flight Batching 依賴什麼？
| 環節 | 依賴內容 |
|---|---|
| GPU 硬體 | 高 HBM 頻寬（Decode 階段為 memory-bound，頻寬直接決定單步延遲）；大 HBM 容量（更多併發序列 = 更大 KV Cache） |
| Attention Kernel | 高效的 FlashAttention / PagedAttention kernel，支援變長序列 |
| 模型格式 | 量化模型（FP8/INT4/INT8）降低引數讀取頻寬需求，放大動態排程的收益 |
| 網路通訊 | 多卡張量並行（TP）時，AllReduce/ReduceScatter 通訊不能成為瓶頸 |
下游：In-flight Batching 改變了什麼？
| 下游環節 | 影響 |
|---|---|
| API 服務商 | 單卡可服務更多併發使用者，降低 token 定價下限 |
| 應用層 | 使即時對話、Agent 等高併發場景的經濟可行性提升 |
| GPU 採購策略 | 相同吞吐量目標下，所需 GPU 數量減少；或相同 GPU 下吞吐量倍增 |
| SLA 保障 | 可預測的延遲尾部更穩定，更容易承諾 P99 SLA |
關鍵指標
| 指標 | 定義 | In-flight Batching 的影響 |
|---|---|---|
| Throughput（吞吐量） | 每秒處理的 output token 數（tok/s） | 核心提升目標，通常 2–8× |
| Time-to-First-Token (TTFT) | 從請求到達到第一個輸出 token 的延遲 | 取決於排程策略：激進插入可降低 TTFT，但 chunked prefill 可能略增 |
| Inter-Token Latency (ITL) | 相鄰兩個輸出 token 之間的延遲 | 通常維持或改善；不當的 prefill 排程可能造成 ITL 尖刺 |
| GPU SM Utilization | GPU 流處理器的實際佔用率 | 從靜態批處理的 30–70% 提升至 70–95%（[經驗估算區間]） |
| HBM Bandwidth Utilization | HBM 頻寬的實際使用率 | Decode 階段 memory-bound，動態批處理使頻寬利用率更接近峰值 |
| KV Cache Memory Utilization | KV Cache 記憶體中有效資料佔比 | 配合 PagedAttention 可接近 100%；無 PagedAttention 則仍存在碎片 |
供需與市場資料
需求端：為什麼現在最關鍵？
- LLM 推論成本已超過訓練成本：據公開分析，頭部 AI 公司推論計算量佔比已達 60–80%（[行業共識估算]），推論最佳化的經濟槓桿巨大
- Token 經濟興起：API 按 token 計費，每 token 成本的降低直接轉化為獲利空間或價格競爭力
- 長上下文趨勢：128K–1M token 上下文視窗普及，靜態批處理在長上下文下幾乎不可用，動態排程成為必需
供給端：誰在提供？
| 型別 | 代表 | 定位 |
|---|---|---|
| NVIDIA 官方引擎 | TensorRT-LLM | 命名 “In-flight Batching”，與 NVIDIA 硬體深度繫結 |
| 開源架構 | vLLM (UC Berkeley) | 連續批處理 + PagedAttention，社群最活躍 |
| 開源架構 | SGLang (UC Berkeley) | RadixAttention + 連續批處理，多輪對話最佳化 |
| 開源架構 | HuggingFace TGI | 生產級推論服務，支援連續批處理 |
| 微軟 | DeepSpeed-FastGen | SplitFuse 排程，與 DeepSpeed 訓練棧互補 |
| 雲端服務商 | AWS SageMaker, GCP Vertex AI, Azure ML | 在託管推論服務中內建動態批排程 |
市場規模關聯
- 全球 LLM 推論市場（含自建和 API 服務）2024 年估計在 數百億美元 量級（[多份行業報告交叉估算，口徑不一]）
- 推論最佳化技術（含動態批排程、量化、Speculative Decoding 等）是該市場的效率乘數——不直接產生營收，但決定獲利率
代表公司與資本對映
| 公司/專案 | 關聯方式 | 上市/融資狀態 |
|---|---|---|
| NVIDIA (NVDA) | TensorRT-LLM 是 in-flight batching 的主要商業實現；該技術提升每塊 GPU 的推論吞吐量，理論上”少賣卡”——但實際上因為需求彈性，反而加速了 GPU 採購 | NASDAQ 上市 |
| vLLM → Anyscale | vLLM 最初由 UC Berkeley 開發，Anyscale（Ray 的公司）是主要推動者之一 | 私有，累計融資超 $2.6 億 |
| Hugging Face | TGI 推論伺服器整合連續批處理 | 私有，估值約 $45 億 |
| CoreWeave | 大規模 GPU 雲端基礎設施，推論最佳化棧直接影響其算力出租效率 | 私有，2024 估值約 $190 億 |
| Together AI | 推論 API 服務，深度最佳化連續批處理 + 量化組合 | 私有，融資超 $3 億 |
投資邏輯提醒： In-flight Batching 是通用的軟體排程技術，不構成某一家公司的獨佔護城河。其資本對映更多體現在降低推論成本 → 擴大 AI 推論市場總量這一間接邏輯上。
投資邏輯
利好邏輯
- 推論成本下行 → 需求彈性釋放：動態批排程是推論成本下降的關鍵技術因素之一，低成本使更多應用在經濟上可行（Agent、即時翻譯、程式碼補全等），擴大總可服務市場（TAM）
- GPU 價值最大化：同一塊 H100，靜態批處理 vs 動態批處理的吞吐量差距可達數倍。對於 GPU 雲端服務商，這意味著更高的每卡營收
- 與量化/Speculative Decoding 協同：動態批排程 + FP8 量化 + Speculative Decoding 三者疊加，推論效率可提升一個數量級，使端側/邊緣推論也成為可能
風險與侷限
- 技術擴散快，非護城河：該技術已被所有主流架構開源實現，不存在排他性競爭優勢
- 邊際收益遞減：從靜態到動態的提升是”從 0 到 1”，但進一步最佳化（chunked prefill、更激進的排程）的增量收益在遞減
- 硬體迭代可能顛覆：如果未來硬體的 prefill 和 decode 速度差異被消除（如通過專用硬體），排程最佳化的必要性可能降低
常見誤讀糾偏
❌ 誤讀 1：“In-flight Batching 就是傳統的 micro-batching”
糾偏： 傳統 micro-batching（如 PipeDream 中的流水線 micro-batch）是為了掩蓋通訊延遲，批的大小在編譯時確定，執行時不變。In-flight Batching 的核心是執行時動態插入和驅逐請求，批次成員在每一步迭代都可能變化。兩者解決的問題域完全不同。
❌ 誤讀 2：“連續批處理能降低單個請求的延遲”
糾偏： 連續批處理的核心收益是系統吞吐量（tokens/sec），而非單個請求延遲。事實上，如果為了吞吐量而將批次填得很滿，單個請求的 ITL（inter-token latency）反而可能上升——因為每個 decode 步需要等待更多序列一起完成計算。正確的理解是：在給定延遲 SLA 約束下，連續批處理能最大化吞吐量；或在給定吞吐量目標下，最小化所需 GPU 數量。
❌ 誤讀 3：“動態批處理對 prefill 和 decode 效果相同”
糾偏： 動態批處理的收益主要體現在 decode 階段——因為 decode 是逐 token 的、持續時間長的階段，不同請求的長度差異主要在 decode 階段體現。Prefill 階段是一次性計算，本身不太需要”動態排程”。真正的挑戰在於：如何在不停止 decode 的前提下，將新請求的 prefill 插入——這才是 chunked prefill 要解決的問題。
❌ 誤讀 4：“有了 PagedAttention 就不需要 In-flight Batching”
糾偏： PagedAttention 解決的是 KV Cache 記憶體管理問題（減少碎片、提高記憶體利用率），In-flight Batching 解決的是 GPU 計算排程問題（減少空閒時間、提高算力利用率）。兩者互補而非替代。實際部署中，最優方案是兩者結合。
學習路徑
入門（1–2 小時）
- 閱讀 vLLM 部落格文章中的連續批處理圖解（vllm.ai 部落格）
- 理解 LLM 推論的 prefill / decode 兩階段特徵
進階（4–8 小時）
- 精讀 Orca 論文：“Orca: A Distributed Serving System for Transformer-Based Generative Models” [OSDI 2022]
- 精讀 vLLM 論文：“Efficient Memory Management for Large Language Model Serving with PagedAttention” [SOSP 2023]
- 對比閱讀 TensorRT-LLM 文件中 In-flight Batching 章節
深度（1–2 周）
- 研讀 Sarathi / Sarathi-Serve 論文（OSDI 2024，關於 chunked prefill 的排程最佳化）
- 閱讀 SGLang 論文（RadixAttention 與 prefix caching 的協同）
- 動手實踐：用 vLLM 部署一個模型，對比開啟/關閉 continuous batching 的吞吐量差異（
--disable-continuous-batching引數） - 閱讀 DeepSpeed-FastGen 的 SplitFuse 白皮書
推薦論文清單
| 論文 | 會議 | 核心貢獻 |
|---|---|---|
| Orca (Yu et al.) | OSDI 2022 | Iteration-level scheduling 奠基 |
| vLLM (Kwon et al.) | SOSP 2023 | PagedAttention + 連續批處理 |
| FlashAttention (Dao et al.) | NeurIPS 2022 | IO-aware Attention kernel（底層基礎） |
| SGLang (Zheng et al.) | arXiv 2024 | RadixAttention + 系統級推論最佳化 |
一句話總結
In-flight Batching 是 LLM 推論排程的”旋轉壽司”模式——以迭代為粒度動態插拔請求，使 GPU 算力從”等人齊開飯”變成”即來即服務”，已成為所有主流推論引擎的預設排程策略，是推論成本下行的核心技術因素之一。
延伸閱讀與來源
- Orca 論文：Gyeong-In Yu et al., “Orca: A Distributed Serving System for Transformer-Based Generative Models,” OSDI 2022
- vLLM 論文：Woosuk Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023
- TensorRT-LLM 官方文件：NVIDIA GitHub (github.com/NVIDIA/TensorRT-LLM) — In-flight Batching 章節
- DeepSpeed-FastGen：Microsoft DeepSpeed 部落格, “DeepSpeed-FastGen: High-throughput Text Generation for LLMs via MII and DeepSpeed-Inference”
- Sarathi-Serve：Amey Agrawal et al., “Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve,” OSDI 2024
- SGLang：Lianmin Zheng et al., “SGLang: Efficient Execution of Structured Language Model Programs,” 2024
- FlashAttention：Tri Dao et al., “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness,” NeurIPS 2022
來源標註說明： 本文中具體的效能倍數（2–8×）為業界廣泛引用的經驗區間，非單一標準化基準測試結果。各架構的實際效能取決於模型架構、序列長度分佈、GPU 型號、量化精度等多重因素，建議以自行實測為準。