使用 CUDA 流與事件實作非同步連續批次以提升 CPU–GPU 並行化與推論效能

解鎖非同步連續批次：用 CUDA 流與事件把 CPU 與 GPU 並行化

在大規模語言模型（LLM）推論中，連續批次（continuous batching）能將多個請求緊密排入批次，減少填充（padding）造成的資源浪費。然而若仍以同步方式運作，CPU 與 GPU 會交替等待：GPU 在計算時 CPU 等待、CPU 在準備時 GPU 等待，長期累積會導致顯著效能損失。本文說明如何透過非同步連續批次將兩個階段重疊，使 GPU 維持高利用率，提升推論效能並改善雲端成本效益。

問題：同步批次的核心低效

同步批次的循環如下：CPU 選取請求、更新 KV cache、準備輸入，然後將資料傳到 GPU；GPU 做前向計算並產生新 token，結果回到 CPU，CPU 再更新狀態並重排下一個批次。關鍵缺口在於兩端互相等待；在每秒執行數百輪的環境下，這類等待會累積成可觀的吞吐量損失。

以一個實測為例：在生成 8K tokens、batch size=32、使用 8B 模型的情況下，總生成時間為 300.6 秒，其中約有 24.0% 的時間為 GPU 等待 CPU 的閒置狀態。換言之，若能完全重疊或消除這段 CPU 開銷，理論上可將 300 秒降到約 228 秒，獲得近 24% 的效能提升。

關鍵要素：CUDA 流（streams）與事件（events）

要在硬體層級實現並行，需要把 GPU 操作分類並放到不同的 CUDA 流上。CUDA 流是一個有序的 GPU 操作佇列；同一流內的操作會順序執行，不同流之間可以並行執行。注意預設流（default stream）會與其他流同步化，會阻斷並行，因此非同步實作應避免將工作放在預設流上。

可將整個步驟分為三類 GPU 操作，並對應三條流：

• H2D（host-to-device）：將輸入從 CPU 傳到 GPU
• Compute：在 GPU 上執行前向計算與抽樣
• D2H（device-to-host）：將輸出從 GPU 傳回 CPU

要在流之間建立順序依賴，可使用 CUDA 事件（event）。事件會在某條流執行到指定位置時被標記完成；其他流可透過 stream.wait(event) 等待該事件，此等待僅會阻塞該流，而不會阻塞 CPU 執行。

在連續批次中把事件串起來

在每個批次的 GPU 工作上，流程如下：

h2d_stream.record(h2d_done)
compute_stream.wait(h2d_done)
// model.forward 在 compute_stream 上執行
compute_stream.record(compute_done)
d2h_stream.wait(compute_done)
// D2H 傳輸在 d2h_stream 上執行
// 最後在 CPU 上呼叫 d2h_done_event.synchronize 等待 D2H 完成

CPU 的角色變成快速佇列（enqueue）所有相關工作並記錄事件，然後返回處理下一個批次的準備工作。GPU 端則藉由事件建立依賴關係，在各流上啟動作業，而不需 CPU 在每個步驟上阻塞等待。

避免競態：雙槽與 carry-over

若讓批次 N 與批次 N+1 共用同一輸入緩衝，會產生資料競態：CPU 可能在 GPU 正在讀取 slot A 時覆寫該槽為新的輸入，導致資料損壞。解法為雙槽（double-buffer）策略：交替使用 slot A 與 slot B，CPU 在 GPU 計算時將下一批次準備至另一路槽，兩槽互不覆寫。

另一個常見挑戰是 token 傳遞（carry-over）：若同一請求出現在連續兩個批次，批次 N 產出的新 token 需成為批次 N+1 的輸入，但在 CPU 準備階段這些 token 尚未可用。文中提出使用佔位符（placeholder，示意以 0 表示）先行填位，待批次 N 完成後以 carry-over mask 將實際 token 覆寫進去；此覆寫步驟可在 CUDA graph 中捕捉以降低開銷。

與 CUDA 圖及記憶體池的整合

推論常用 CUDA 圖（CUDA graphs）以減少啟動延遲，但圖是針對特定記憶體位址錄製的；因此雙槽會導致需要兩個圖。為避免 VRAM 翻倍，可採用記憶體池（memory pool）讓兩個圖從同一記憶體池配置，前提是確保同一時刻不會讓兩個圖同時執行。整體上，初始化階段需兩次捕捉，但運行時的 VRAM 使用量與單圖情形相近。

整合後的非同步連續批次迴圈

流程範例：

1. Step0（冷啟動）：準備批次 0 到 slot A 並發送，這一步無重疊。
2. Step1（開始非同步）：GPU 計算批次 0（slot A），CPU 同時準備批次 1 至 slot B（e.g. evict、admit、更新 KV、建構 carry-over mask 等）。準備完成後 CPU 佇列 H2D、記錄/等待事件，然後返回空閒以等待 D2H 完成事件。
3. GPU 端在 slot A 完成 compute 後觸發 D2H；slot B 的 H2D 一旦完成則觸發 compute，carry-over 與前向計算在 compute 流中處理。
4. CPU 在 D2H 完成後處理回傳輸出的結果、更新請求狀態，然後準備下一個批次，迴圈持續。

與其他路線的比較

非同步連續批次的核心在於將「準備」工作提前並與 GPU 的計算重疊。相對於傳統同步批次，最大的差異在於硬體層級的並行控制（CUDA 流、事件）與記憶體管理（雙槽、記憶池）。相比另一常見做法——將更多邏輯合併至 CPU 或直接增加 batch size——非同步方法在延遲敏感場景下更著重提高 GPU 利用率，而非一味增大 batch size（可能造成更高記憶體需求與抽樣延遲）。

此外，相較於跨卡的模型並行或流水線平行（pipeline parallelism），本方法聚焦於單卡／單節點內的資源重疊，兩者並非互斥，可依需混合使用以針對不同瓶頸優化。

部署與成本考量

對於以小時計費的雲端實例，提高 GPU 利用率會直接降低每 token 的運算成本。文章以某雲端 GPU 型號為例指出，使用一整天時費用會快速累積，因此在雲端回收 20% 或以上的閒置時間具有實際經濟誘因。但同時需評估工程成本：實作非同步控制、管理 CUDA 圖與記憶體池，以及處理除錯與可觀察性（observability）上的複雜度。

未來影響與生態觀察

若非同步連續批次被廣泛採用，可能帶來幾項長期變化：

• 雲端推論成本結構將更仰賴軟體層面的資源調度效能，而非純粹硬體升級。
• 推論庫（如 transformers）與硬體驅動間的契約會更重要，工具需提供更友善的流與事件抽象以降低開發門檻。
• 對於需要低延遲互動的應用，工程師將在非同步批次與較小批次之間做更細緻的取捨。

結語

將 CPU 的批次準備與 GPU 的計算分離，並以 CUDA 流與事件在 GPU 端建立順序依賴，可將同步批次造成的閒置時間轉化為實際吞吐力提升。此類看似「協調式」的優化在實務上牽涉記憶體規劃、CUDA 圖捕捉與 carry-over 邏輯，但在雲端成本與推論效率日益敏感的情況下，這條技術路線具備顯著價值。

參考實作與更多細節可見於相關推論庫的連續批次實作，實作人員可依可靠性、可觀察性與成本間的需求做技術取捨。

延伸閱讀

• 用 bf16 位元差分與 HF Bucket 的 Delta Weight Sync，降低兆參數模型權重傳輸成本
• AI Greenferencing 與 XWind：將大型語言模型推理部署至風電場的跨站路由策略
• 區塊化並行壓縮：在長時程 LLM 代理人中精確控制上下文體積與延遲

代理人點評

本文從工程角度拆解同步批次的瓶頸，關鍵洞察在於把阻塞式的 CPU ↔ GPU 互動交給硬體（CUDA streams/events）來協調，讓 CPU 在 GPU 計算時持續準備下一批次。實作上會面臨三大技術點：避免記憶體競態的雙槽設計、將 token 從前一批 carry 到下一批的 mask 與覆寫機制、以及與 CUDA 圖和記憶體池整合以避免 VRAM 翻倍。這些措施能把原本可觀的 GPU 閒置（本文示例約 24%）轉為有效吞吐，對以小時計費的雲端部署特別有利。但值得注意的是，工程複雜度與 debug 成本也會上升，觀察性與錯誤復原機制必須同步加強。整體而言，非同步連續批次是一條以軟體協調換取運行效率的實務優化路徑，對推論平台與開發工具鏈都有長期改變的潛力。

原始來源：Hugging Face Blog

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。