Hello folks，我是 Luga，今天我們來聊一下人工智能應用場景 - 構建大模型推理關鍵技術 - “ CUDA Graph”。

隨著 LLM 的參數規模與應用場景以前所未有的速度擴張，推理（Inference）階段的性能優化，已從單純追求理論浮點運算（FLOPs）的競賽，轉向一場對系統極致效率的、毫秒必爭的“壓榨”。

在傳統的推理模式中，CPU 作為控制核心，頻繁地向 GPU 下達指令，這種“一問一答”式的交互模式，在面對 LLM 推理任務中海量、細碎的計算核（Kernel）時，其固有的控制開銷（Overhead）形成了一道難以逾越的性能墻。

本文將從“架構”的視角，深入剖析 CUDA Graph 這一關鍵技術，闡述如何通過從“命令式”到“聲明式”的范式轉移，將控制權從 CPU 下放至 GPU，從而繞過傳統架構的瓶頸，為構建下一代高性能、低延遲的大模型推理服務，奠定了堅實的架構基石。

一、傳統推理模式的架構之困：CPU 控制開銷的“死亡之谷”

要理解 CUDA Graph 的革命性，我們必須首先審視其所要顛覆的傳統 GPU 執行模型。在一個典型的、未使用 CUDA Graph 的大模型推理流程中，整個系統的運轉高度依賴于中央處理器（CPU）的精細調度。

1. “廚師與幫廚”的命令式架構

我們可以將這種傳統架構，比喻為一個“急性子的主廚（CPU）與一群技藝精湛但需要指令的幫廚（GPU SMs）”的廚房。2者的職責如下：

• 主廚（CPU）：負責閱讀菜譜（執行推理代碼），并將每一個烹飪步驟（如矩陣乘法、激活函數、層歸一化等）拆解成獨立的指令。
• 幫廚（GPU）：擁有強大的并行處理能力，能夠極快地完成任何單一指令（執行一個 CUDA Kernel）。

整個流程是命令式的：即主廚每喊一個指令，幫廚們就迅速完成，然后集體停下來，等待主廚的下一個指令。對于一個包含數千個獨立操作的復雜菜肴（一次 LLM 推理），主廚需要不間斷地下達數千個指令。問題在于，主廚下達指令本身是需要時間的，這個時間，就是所謂的控制開銷。

2. 控制開銷的“四大元兇”

在 LLM 推理這種對延遲極度敏感的場景下，CPU 的控制開銷主要來源于四個方面，共同構成了性能的“死亡之谷”：

• 內核啟動延遲（Kernel Launch Latency）：CPU 通過 CUDA 驅動程序向 GPU 發起一次 Kernel 啟動請求，本身存在微秒級的固定延遲。對于 LLM 推理中大量的小型 Kernel（例如逐元素的激活函數），這些啟動延遲累加起來，甚至可能超過 Kernel 實際的執行時間。
• CUDA API 調用開銷：除了 Kernel 啟動，每一次內存分配（cudaMalloc）、數據拷貝（cudaMemcpy）、流同步（cudaStreamSynchronize）等 API 調用，都伴隨著 CPU 與 GPU 驅動之間的上下文切換和驗證，累積了顯著的開銷。
• CPU 調度抖動（Jitter）：作為通用處理器，CPU 上的推理線程會受到操作系統調度的影響，任何微小的中斷或上下文切換，都會導致向 GPU 發送指令的節奏被打亂，引入不確定的延遲。
• 動態性帶來的重復開銷：對于每一次新的推理請求，CPU 都需要重復地執行幾乎完全相同的邏輯判斷、參數計算和 Kernel 啟動序列，這在架構上是一種巨大的冗余。

在訓練階段，由于數據批次（Batch Size）較大，計算密集度高，這些微秒級的控制開銷尚可被攤銷。但在推理階段，尤其是要求低延遲的在線服務場景（Batch Size 通常為1），這些開銷便凸顯出來，成為限制系統吞吐量和延遲表現的核心架構瓶頸。CPU 成為了那個最慢的環節，導致 GPU 大量的寶貴計算周期被浪費在空閑等待中。

二、從“命令式”到“聲明式”的范式轉移

從本質上而言，CUDA Graph 的出現，并非對傳統模式的“小打小鬧”，而是一次徹底的架構范式轉移：將 GPU 的執行模型，從依賴 CPU 實時指揮的“命令式”，轉變為一次性定義、可重復執行的“聲明式”模型。

基于實際的業務特性，CUDA Graph 的核心思想主要將原本在運行時由 CPU 動態執行的指令序列，預先“錄制”下來，形成一個固定的、可重用的計算圖。這個過程在架構上分為兩個階段：

1. Step 1：捕獲—— 繪制“靜態藍圖”

在此階段，CPU 仍然像過去一樣，按順序執行一次完整的推理計算流。但此時，CUDA 驅動程序會扮演一個“書記員”的角色。它并不會立即將 Kernel 提交給 GPU 執行，而是將 CPU 發出的所有 CUDA 相關操作（Kernel 啟動、內存拷貝、事件同步等），連同它們的參數、依賴關系、執行順序等記錄下來，并在 GPU 驅動內部構建一個有向無環圖（DAG）的數據結構。

這個過程好比主廚不再直接喊菜，而是花時間將一整套復雜的菜譜（例如法國菜“酥皮包鵝肝鴨肉派”）的全部流程，事無巨細地寫成一張標準化的流程圖（SOP），并交給廚房。這就是所謂的 CUDA Graph。

2. Step 2：實例化與執行—— 賦予 GPU “肌肉記憶”

一旦“藍圖”捕獲完成，CPU 的角色就發生了根本性的轉變，不再需要重復執行成百上千次的 API 調用。在后續的每一次推理請求中，CPU 只需向 GPU 發出一個極其輕量的指令：“執行這張圖（Launch Graph）”。

GPU 驅動在接收到這個單一指令后，會接管全部的控制權。它擁有完整的計算圖，可以在 GPU 內部，以最高效、最低開銷的方式，調度執行圖中定義的所有操作。省去了與 CPU 的反復通信，繞過了操作系統的調度抖動，實現了 Kernel 的背靠背（Back-to-Back）執行。

這相當于廚房拿到了標準化的 SOP 后，幫廚們便形成了“肌肉記憶”。主廚每次只需喊一聲菜名（“來一份酥皮包鵝肝鴨肉派！”），整個廚房便能心領神會，行云流水般地完成所有工序，中間無需主廚再做任何干預。

通過這種“一次捕獲，多次重放”的架構，CUDA Graph 將原本分散在多次 CPU-GPU 交互中的控制開銷，一次性地攤銷在了初始的捕獲階段，而在至關重要的執行階段，實現了近乎“零”的 CPU 開銷，從而將性能的瓶頸重新交還給 GPU 的計算能力本身。

三、CUDA Graph 在大模型推理中的典型架構應用模式

在復雜多變的 LLM 推理場景中，應用 CUDA Graph 并非一蹴而就，而是需要根據具體場景，選擇合適的架構模式。

1. 靜態輸入的完全圖化

這是最理想，也是最簡單的應用模式。當推理請求的輸入形狀（如 Batch Size、Sequence Length）是固定的，整個端到端的推理流程，從數據拷貝到計算再到結果回傳，都可以被完整地捕獲到一個 CUDA Graph 中。

此模式架構優勢主要體現在性能提升最大化，CPU 開銷降至最低。適應于離線批處理、性能基準測試，或業務場景中輸入形狀高度統一的特定任務。

然而，由于其缺乏靈活性。一旦輸入形狀改變，整個圖就需要被廢棄并重新捕獲，這在動態性強的在線服務中是不可接受的。

2. “分段圖化”與“動態參數更新”

在線推理服務的核心挑戰是處理動態的輸入序列長度。一個完全靜態的 CUDA Graph 在此會失效。為此，我們需要采用更靈活的架構策略。這里，我們主要分為如下 3 種架構策略：

(1) 架構策略 1：“分段圖化”

LLM 的推理過程，可以被清晰地劃分為兩個階段：Prefill（對輸入 Prompt 的并行處理）和Decoding（逐 Token 的自回歸生成）。

作為動態性的主要來源，Prefill 階段的計算圖結構與輸入序列長度直接相關。而在 Decoding 階段，由于每次只生成一個 Token，其計算模式是固定且高度重復的。這個階段非常適合被捕獲成一個可重用的 CUDA Graph，我們稱之為“Decoding Graph”或“Step Graph”。

通過將固定的 Decoding 階段圖化，我們已經能夠優化掉推理過程中絕大部分（通常是95%以上）的 CPU 控制開銷。

(2) 架構策略 2：“圖更新”與“動態參數”

CUDA 提供了 Graph Update 機制，允許在不重新捕獲整個圖的情況下，修改圖中某些節點（如 memcpy 或 Kernel）的參數，例如指向輸入/輸出數據的內存地址指針。

這在架構上實現了“結構靜態，數據動態”。我們可以捕獲一個通用的計算圖結構，在每次執行前，通過 Graph Update 將其輸入/輸出指針，動態地指向當前請求的實際數據緩沖區。這避免了為每個請求都重新捕獲的巨大開銷。

(3) 架構策略 3：“裝桶與填充”

這是處理動態序列長度的經典工程實踐。我們可以預先為一系列離散的、有代表性的序列長度（例如 64, 128, 256, 512...）分別捕獲并緩存對應的 CUDA Graph。

在運行時，當接收到一個請求時，我們將其輸入序列填充（Pad）到最接近的、更大的那個桶（Bucket）的長度，然后直接調用該桶預先編譯好的 Graph。

這是一種典型的空間換時間的架構權衡：通過增加內存占用（緩存多個 Graph），換取了在動態輸入下的高性能執行，避免了運行時的編譯和捕獲開銷。

3. 與高性能庫和自定義核的集成

CUDA Graph 并非要取代現有的性能優化手段，恰恰相反，它是一種更高層次的“調度與粘合”架構。一個設計良好的推理系統中，CUDA Graph 應該作為頂層的調度器，其圖中的節點，調用的正是那些經過極致優化的計算單元。具體：

• 封裝高性能庫： 對 NVIDIA cuBLAS（矩陣運算）、cuDNN（卷積運算）等官方庫的調用。
• 集成自定義核：封裝像 FlashAttention 這樣的 state-of-the-art 的自定義 CUDA Kernel，或是 vLLM 中 PagedAttention 的一系列 Kernel 調用。通過將這些高度優化的、但仍需 CPU 調度的 Kernel 序列捕獲到 Graph 中，實現了優化的“強強聯合”。

綜上所述，大模型推理的性能優化，是一場與物理定律賽跑的系統工程。在這場工程體系中，CUDA Graph 提供了一種跳出傳統思維框架的、釜底抽薪式的架構解決方案：通過將控制權從 CPU 徹底下放到 GPU，實現了從“命令式”到“聲明式”的深刻轉變，從根本上消除了長久以來制約 GPU 推理性能的 CPU 控制開銷。

因此，從某種角度而言，CUDA Graph 不僅僅是一個 API 或一項孤立的技術，而是一種全新的、面向未來的 GPU 編程與調度哲學。

隨著模型結構日趨復雜，業務對延遲的要求愈發嚴苛，CUDA Graph 所代表的“預編譯、圖執行”的架構思想，將不再僅僅是一項“可選”的優化，而是成為構建一切高性能、低延遲 AI 推理服務的、不可或缺的架構基石……

Happy Coding ~

Reference ：[1]    https://developer.nvidia.com/blog/enabling-dynamic-control-flow-in-cuda-graphs-with-device-graph-launch/

Adiós !