Hello folks，我是 Luga，今天我們來聊一下人工智能應(yīng)用場景 - 構(gòu)建大模型推理關(guān)鍵技術(shù) - “ CUDA Graph”。

隨著 LLM 的參數(shù)規(guī)模與應(yīng)用場景以前所未有的速度擴(kuò)張，推理（Inference）階段的性能優(yōu)化，已從單純追求理論浮點(diǎn)運(yùn)算（FLOPs）的競賽，轉(zhuǎn)向一場對系統(tǒng)極致效率的、毫秒必爭的“壓榨”。

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

本文將從“架構(gòu)”的視角，深入剖析 CUDA Graph 這一關(guān)鍵技術(shù)，闡述如何通過從“命令式”到“聲明式”的范式轉(zhuǎn)移，將控制權(quán)從 CPU 下放至 GPU，從而繞過傳統(tǒng)架構(gòu)的瓶頸，為構(gòu)建下一代高性能、低延遲的大模型推理服務(wù)，奠定了堅(jiān)實(shí)的架構(gòu)基石。

一、傳統(tǒng)推理模式的架構(gòu)之困：CPU 控制開銷的“死亡之谷”

要理解 CUDA Graph 的革命性，我們必須首先審視其所要顛覆的傳統(tǒng) GPU 執(zhí)行模型。在一個典型的、未使用 CUDA Graph 的大模型推理流程中，整個系統(tǒng)的運(yùn)轉(zhuǎn)高度依賴于中央處理器（CPU）的精細(xì)調(diào)度。

1. “廚師與幫廚”的命令式架構(gòu)

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

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

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

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

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

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

在訓(xùn)練階段，由于數(shù)據(jù)批次（Batch Size）較大，計(jì)算密集度高，這些微秒級的控制開銷尚可被攤銷。但在推理階段，尤其是要求低延遲的在線服務(wù)場景（Batch Size 通常為1），這些開銷便凸顯出來，成為限制系統(tǒng)吞吐量和延遲表現(xiàn)的核心架構(gòu)瓶頸。CPU 成為了那個最慢的環(huán)節(jié)，導(dǎo)致 GPU 大量的寶貴計(jì)算周期被浪費(fèi)在空閑等待中。

二、從“命令式”到“聲明式”的范式轉(zhuǎn)移

從本質(zhì)上而言，CUDA Graph 的出現(xiàn)，并非對傳統(tǒng)模式的“小打小鬧”，而是一次徹底的架構(gòu)范式轉(zhuǎn)移：將 GPU 的執(zhí)行模型，從依賴 CPU 實(shí)時指揮的“命令式”，轉(zhuǎn)變?yōu)橐淮涡远x、可重復(fù)執(zhí)行的“聲明式”模型。

基于實(shí)際的業(yè)務(wù)特性，CUDA Graph 的核心思想主要將原本在運(yùn)行時由 CPU 動態(tài)執(zhí)行的指令序列，預(yù)先“錄制”下來，形成一個固定的、可重用的計(jì)算圖。這個過程在架構(gòu)上分為兩個階段：

1. Step 1：捕獲—— 繪制“靜態(tài)藍(lán)圖”

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

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

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

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

GPU 驅(qū)動在接收到這個單一指令后，會接管全部的控制權(quán)。它擁有完整的計(jì)算圖，可以在 GPU 內(nèi)部，以最高效、最低開銷的方式，調(diào)度執(zhí)行圖中定義的所有操作。省去了與 CPU 的反復(fù)通信，繞過了操作系統(tǒng)的調(diào)度抖動，實(shí)現(xiàn)了 Kernel 的背靠背（Back-to-Back）執(zhí)行。

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

通過這種“一次捕獲，多次重放”的架構(gòu)，CUDA Graph 將原本分散在多次 CPU-GPU 交互中的控制開銷，一次性地?cái)備N在了初始的捕獲階段，而在至關(guān)重要的執(zhí)行階段，實(shí)現(xiàn)了近乎“零”的 CPU 開銷，從而將性能的瓶頸重新交還給 GPU 的計(jì)算能力本身。

三、CUDA Graph 在大模型推理中的典型架構(gòu)應(yīng)用模式

在復(fù)雜多變的 LLM 推理場景中，應(yīng)用 CUDA Graph 并非一蹴而就，而是需要根據(jù)具體場景，選擇合適的架構(gòu)模式。

1. 靜態(tài)輸入的完全圖化

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

此模式架構(gòu)優(yōu)勢主要體現(xiàn)在性能提升最大化，CPU 開銷降至最低。適應(yīng)于離線批處理、性能基準(zhǔn)測試，或業(yè)務(wù)場景中輸入形狀高度統(tǒng)一的特定任務(wù)。

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

2. “分段圖化”與“動態(tài)參數(shù)更新”

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

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

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

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

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

(2) 架構(gòu)策略 2：“圖更新”與“動態(tài)參數(shù)”

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

這在架構(gòu)上實(shí)現(xiàn)了“結(jié)構(gòu)靜態(tài)，數(shù)據(jù)動態(tài)”。我們可以捕獲一個通用的計(jì)算圖結(jié)構(gòu)，在每次執(zhí)行前，通過 Graph Update 將其輸入/輸出指針，動態(tài)地指向當(dāng)前請求的實(shí)際數(shù)據(jù)緩沖區(qū)。這避免了為每個請求都重新捕獲的巨大開銷。

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

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

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

這是一種典型的空間換時間的架構(gòu)權(quán)衡：通過增加內(nèi)存占用（緩存多個 Graph），換取了在動態(tài)輸入下的高性能執(zhí)行，避免了運(yùn)行時的編譯和捕獲開銷。

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

CUDA Graph 并非要取代現(xiàn)有的性能優(yōu)化手段，恰恰相反，它是一種更高層次的“調(diào)度與粘合”架構(gòu)。一個設(shè)計(jì)良好的推理系統(tǒng)中，CUDA Graph 應(yīng)該作為頂層的調(diào)度器，其圖中的節(jié)點(diǎn)，調(diào)用的正是那些經(jīng)過極致優(yōu)化的計(jì)算單元。具體：

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

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

因此，從某種角度而言，CUDA Graph 不僅僅是一個 API 或一項(xiàng)孤立的技術(shù)，而是一種全新的、面向未來的 GPU 編程與調(diào)度哲學(xué)。

隨著模型結(jié)構(gòu)日趨復(fù)雜，業(yè)務(wù)對延遲的要求愈發(fā)嚴(yán)苛，CUDA Graph 所代表的“預(yù)編譯、圖執(zhí)行”的架構(gòu)思想，將不再僅僅是一項(xiàng)“可選”的優(yōu)化，而是成為構(gòu)建一切高性能、低延遲 AI 推理服務(wù)的、不可或缺的架構(gòu)基石……

Happy Coding ~

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

Adiós !