現代 AI 系統的「動態調度員」：Continuous Batching（連續批次處理）深度解析

在 LLM（大型語言模型）的生產環境中，推理成本最高的部分之一就是 GPU 的利用率。如果你觀察一個簡單的推理請求，你會發現 GPU 在生成每個 token 時，大部分時間都在等待記憶體傳輸（Memory Bound），而不是在進行計算。而傳統的靜態批次處理（Static Batching）雖然能提高吞吐量，但卻引入了一個致命的問題：木桶效應。

靜態批次處理的痛點：等待最慢的那個

在傳統的靜態批次處理中，系統將多個請求打包成一個 batch 一起輸入模型。然而，不同請求生成的 token 數量截然不同——有的請求只需要回答「是」，有的則需要寫一篇長文。

在這種模式下，整個 batch 必須等到最長的那個序列生成完畢（或觸碰停止符）後才能釋放。這意味著短請求在完成之後，其佔用的顯示記憶體空間依然被鎖定，GPU 必須在後續的迭代中為這些已經完成的請求填充「填充符」（Padding tokens）。這種浪費不僅降低了吞吐量，還增加了不必要的計算開銷。

Continuous Batching：打破同步的枷鎖

為了解決這個問題，vLLM 等現代推理框架引入了 Continuous Batching（連續批次處理）。它的核心邏輯是將批次處理的粒度從「請求級」細化到了「token 級」。

工作原理：動態插入與退出

Continuous Batching 不再等待整個 batch 完成，而是在每一個迭代步（Iteration step）結束後，立即檢查是否有請求已完成。

1. 即時退出：一旦某個序列生成了 <EOS> 或達到了最大長度，它會立即從當前 batch 中被剔除並返回結果給使用者。
2. 即時插入：在同一個迭代步中，系統會檢查等待佇列。如果有新請求進入且顯示記憶體允許，it will be directly inserted into the current running batch.

這意味著 GPU 的計算單元始終在處理有效的 token 生成任務，而不需要為了對齊長度而浪費資源在 padding 上。

核心支撐：PagedAttention 與記憶體管理

Continuous Batching 之所以可行，依賴於對 KV Cache 的精細化管理。如果使用傳統的連續記憶體分配，頻繁地插入和刪除請求會導致嚴重的記憶體碎片化（External Fragmentation）。

PagedAttention 借鑑了作業系統虛擬記憶體的分頁機制：
- 它將 KV Cache 分割成固定大小的「頁」（Pages）。
- 每個請求的 KV Cache 不再要求實體連續，而是透過一個映射表（Block Table）分布在不連續的實體區塊中。
- 當 Continuous Batching 需要插入新請求時，只需分配若干個空閒頁即可，無需移動現有資料。

實際影響：吞吐量的量級提升

從工程實踐來看，Continuous Batching 帶來了顯著的性能飛躍：
- 吞吐量提升：相比靜態批次處理，吞吐量通常能提升 2-4 倍。
- 首字延遲（TTFT）降低：新請求無需等待前一個 batch 全部結束即可進入計算流。
- 資源利用率最大化：GPU 的算力被更均勻地分布在所有活躍請求上。

總結

如果說 KV Cache 是 AI 的「短期記憶」，那麼 Continuous Batching 就是這個記憶系統的「高效調度員」。它透過打破同步等待的僵局，讓 LLM 推理從一種「排隊等候」的模式轉變為一種「流水線作業」的模式。對於任何追求高併發、低延遲的 AI 應用而言，這已成為基礎設施級的標準配置。