CUDA Graphs
⏱️ 閱讀時間：約 35 分鐘
1 引言：當 GPU 比 CPU “快太多”，瓶頸倒轉
在過去十年間，GPU 的浮點運算能力以遠快於 CPU 單核效能的速度增長。一塊 NVIDIA A100 的 FP16 張量核心吞吐量可達 312 TFLOPS，而與此同時，現代伺服器 CPU 單核的指令發射速率與記憶體延遲改善相對有限。這種不對稱的發展帶來了一個反直覺的現象：在許多 AI 工作負載中，GPU 不再是系統的瓶頸，CPU 反而成了拖後腿的角色。
問題出在執行模型上。傳統的 CUDA 程式設計範式要求 CPU 以“指令發射者”的角色逐條向 GPU 提交操作——每一次核心啟動、每一次裝置端記憶體複製，都需要發起一次 CUDA API 呼叫。這些呼叫穿越使用者態庫、驅動層、作業系統核心，最終抵達 GPU 的命令緩衝區。當操作的數量膨脹到每迭代數千條時，CPU 側的呼叫開銷與同步延遲累積起來，足以讓 GPU 處於“飢餓”狀態：計算單元閒置，等待下一次指令到達的時間甚至超過了實際計算的時間。
這種現象在深度學習推論流水線中尤為突出。一個典型的 BERT-Large 推論可能包含數百個微小計算核——逐元素啟用、層歸一化、注意力掩碼處理、Dropout 等。如果每層計算都對映為獨立的 CUDA 核心，那麼一次前向傳播就要經歷數百次 CPU-GPU 同步邊界。而推論場景對延遲的敏感度極高，每毫秒的浪費都會直接損害使用者體驗與服務等級協議（SLA）。在強化學習訓練和圖神經網路中，情況類似：大量細小操作的組合使得傳統的“一操作一呼叫”模式成為系統性瓶頸。
NVIDIA 並非沒有意識到這一點。早在 CUDA 10 引入的 Stream 併發機制允許將操作派發到不同的硬體佇列以重疊執行，但本質上仍需 CPU 逐操作提交。2019 年推出的 CUDA Graphs（隨 CUDA 10 開始支援，11 後顯著增強）則從根本上改變了遊戲規則：將一系列 GPU 操作預錄製為一張靜態有向無環圖，之後整圖一次性提交執行，從而將 N 次 CPU 呼叫壓縮為 1 次。這相當於把“逐票報關”改成“整櫃通關”，CPU 的重擔頓時卸下。
本文將深度解析 CUDA Graphs 的技術原理、建置方式、執行機制、效能收益、適用場景與最佳實踐，旨在為 AI 系統工程師、模型部署專家及 CUDA 進階開發者提供一份全面的參考指南。
2 CUDA Graphs 核心思想：把工作流凍結為可重放的圖
CUDA Graphs 的本質是一張有向無環圖（Directed Acyclic Graph, DAG）。圖中的節點代表 GPU 操作，包括但不限於核心啟動（Kernel Launch）、主機到裝置的記憶體複製（H2D Memcpy）、裝置到主機的複製（D2H）、裝置端記憶體複製（DtoD）、記憶體設定（Memset）、事件記錄（Event Record）等。有向邊則編碼操作之間的依賴關係，確保執行順序的正確性。
傳統執行流程中，CPU 在執行時動態地按照程式碼順序逐個排程這些操作，GPU 在完成當前操作並檢測到依賴滿足後才開始下一個。而 CUDA Graphs 要求開發者在初始化階段就將整個操作序列“凍結”成一張靜態圖。此後，GPU 可以直接消費這張圖，無需 CPU 介入每個節點。這種模式將圖建置（Capture）、**圖例項化（Instantiation）和圖執行（Launch）**三個階段徹底分離：
- 建置階段：通過流捕獲或顯式 API 的方式，定義完整的操作序列及其依賴關係，生成圖模板（Graph Template）。
- 例項化階段：驅動對圖模板進行整體分析和最佳化，生成可執行圖例項（Executable Graph），該過程耗時與圖規模正相關，但僅需執行一次。
- 執行階段：將可執行圖例項提交至 GPU 硬體排程器，此後 GPU 完全在本地根據固化依賴關係連續發射所有節點操作，CPU 可立即返回處理其他任務或進入睡眠。
這種分離帶來的直接收益有三：第一，消除 CPU 的逐操作提交開銷，這在運算元量極大時尤為顯著；第二，減少 CPU-GPU 之間的往返同步延遲，這對於需要大量小核心協同工作的場景如強化學習訓練極為關鍵；第三，賦予驅動進行整圖最佳化的機會，可以重組記憶體複製、消除冗餘操作、預計算部分核心引數，從而進一步減少執行時間。
理解 CUDA Graphs 的一個形象類比是“編譯執行 vs. 解釋執行”。傳統的 CUDA 流執行類似於解釋型語言的逐條解釋執行，CPU 像直譯器一樣逐句翻譯並提交給 GPU；而 CUDA Graphs 相當於在初始化時做一次“即時編譯”（JIT），將整個程式段編譯為一個最佳化後的可執行單元，之後即可直接執行。當然，這裡的“編譯”是指圖最佳化而非核心編譯。
3 圖建置之路一：流捕獲模式 —— 最小改造成本
流捕獲（Stream Capture）是 CUDA Graphs 提供的存量程式碼適配路徑，也是 PyTorch 的 torch.cuda.CUDAGraph 和 TensorRT 的 CUDA Graph 支援所依賴的底層機制。它的思想十分直觀：讓開發者像往常一樣編寫 CUDA 程式碼，將所有操作提交到一個 CUDA 流中，但在流上開啟一個“捕獲模式”。處於捕獲模式的流不會立即執行提交的操作，而是將其記錄為圖節點和依賴邊。當捕獲結束時，執行時返回一張完整的圖模板。
具體來說，流程分為三步：cudaStreamBeginCapture 開啟捕獲；在捕獲期間，任意向該流提交的 CUDA 操作（核心啟動、記憶體複製等）都會被自動轉換為圖節點；呼叫 cudaStreamEndCapture 結束捕獲並獲取 cudaGraph_t 圖控制代碼。
例如，以下虛擬碼展示了典型的流捕獲過程（簡化版 C++ CUDA API）：
cudaStream_t stream;
cudaStreamCreate(&stream);
// 開啟捕獲
cudaStreamBeginCapture(stream, cudaStreamCaptureModeGlobal);
// 正常提交操作，但此時並不執行
kernel_Agrid, block, 0, stream(...);
cudaMemcpyAsync(d_buf, h_buf, size, cudaMemcpyHostToDevice, stream);
kernel_Bgrid, block, 0, stream(...);
cudaEventRecord(event, stream);
cudaStreamWaitEvent(stream, event_external, 0);
kernel_Cgrid, block, 0, stream(...);
// 結束捕獲，獲得圖
cudaGraph_t graph;
cudaStreamEndCapture(stream, &graph);在上述示例中，kernel_A、cudaMemcpyAsync、kernel_B、事件記錄、等待外部事件以及 kernel_C 會按照程式碼順序被記錄為節點，流中的提交順序隱式定義了依賴邊。此外，如果存在跨流的事件等待（如 cudaStreamWaitEvent），捕獲機制也會將其正確轉化為圖的跨流依賴邊，這對於需要多流並行的複雜場景至關重要。
流捕獲模式的限制也非常明確：
- 捕獲期間不允許使用CPU同步：
cudaStreamSynchronize、cudaDeviceSynchronize等會在捕獲期間直接返回錯誤，因為捕獲的目的是建置純 GPU 執行圖，不應包含 CPU 同步點。 - 不允許分配裝置記憶體：
cudaMallocAsync等在捕獲期間不可用。 - 動態核心引數必須固化：如果核心啟動引數在迴圈中動態變化，捕獲將固定為第一次的引數值。可以通過建立“引數更新節點”或使用裝置端函式指標來動態化部分引數，但會增加複雜性。
- 捕獲範圍不能包含條件分支：因為圖本質是靜態的，不能在捕獲時依賴執行時決策來決定執行哪條分支。對於此類需求，需要使用顯式 API 建置帶有條件的圖或者放棄使用圖。
PyTorch 的 torch.cuda.CUDAGraph 封裝了流捕獲，使得 PyTorch 使用者可以便捷地捕獲一個 Python 程式碼塊對應的 CUDA 操作序列，並在後續多次重放，從而實現顯著的推論加速。它通過在捕獲前建立一個新的 CUDA 流，並臨時將 PyTorch 的預設執行流切換至捕獲流，使得 tensor 操作自然地記錄到圖中。捕獲結束後，使用者只需呼叫 graph.replay() 即可重複執行。
4 圖建置之路二：顯式 API 模式 —— 精細控制
顯式 API 模式為需要精確建置圖拓撲、動態引數繫結、或與核心程式碼深度耦合的場景提供了完全控制能力。開發者通過一組 cudaGraphCreate、cudaGraphAddNode、cudaGraphNodeSetParams 等函式，以程式設計方式逐個新增節點和依賴邊。
該模式的典型建置流程如下：
- 使用
cudaGraphCreate建立一個空圖。 - 逐一建立操作節點，如
cudaGraphAddKernelNode新增核心節點，需要提供核心函式指標、網格和執行緒塊維度、動態共享記憶體大小、核心引數指標等；cudaGraphAddMemcpyNode新增記憶體複製節點，需要提供複製引數結構體；以及cudaGraphAddMemsetNode、cudaGraphAddHostNode（允許插入 CPU 回撥，但會破壞非同步特性）等。 - 通過
cudaGraphAddDependencies顯式新增依賴邊，定義執行順序。 - 使用
cudaGraphInstantiate生成可執行圖例項。 - 通過
cudaGraphLaunch提交執行。
顯式 API 的優勢在於可以引數化節點。例如，多個同樣的核心操作但引數不同，可以用同一個“節點模板”克隆，然後通過 cudaGraphKernelNodeSetParams 等函式動態更新引數，而不必重建整個圖。這使得圖可以適應迴圈中變數變化的需求，同時保留整圖最佳化收益。此外，顯式 API 支援建置條件節點和迴圈/遞迴節點（通過裝置端圖），這是流捕獲無法做到的。
一個簡化的顯式 API 建置例子：
cudaGraph_t graph;
cudaGraphCreate(&graph, 0);
// 新增核心節點 A
cudaKernelNodeParams paramsA;
paramsA.func = (void*)kernel_A;
paramsA.gridDim = dim3(256);
paramsA.blockDim = dim3(512);
paramsA.sharedMemBytes = 0;
paramsA.kernelParams = args_A;
paramsA.extra = NULL;
cudaGraphNode_t nodeA;
cudaGraphAddKernelNode(&nodeA, graph, NULL, 0, ¶msA);
// 新增 Memcpy 節點
cudaMemcpy3DParms memcpyParams = {0};
memcpyParams.srcPtr = make_cudaPitchedPtr(...);
memcpyParams.dstPtr = make_cudaPitchedPtr(...);
memcpyParams.extent = ...;
memcpyParams.kind = cudaMemcpyDeviceToDevice;
cudaGraphNode_t nodeMemcpy;
cudaGraphAddMemcpyNode(&nodeMemcpy, graph, NULL, 0, &memcpyParams);
// 新增依賴：A -> Memcpy
cudaGraphAddDependencies(graph, &nodeA, &nodeMemcpy, 1);
// 例項化
cudaGraphExec_t exec;
cudaGraphInstantiate(&exec, graph, NULL, NULL, 0);
// 提交
cudaGraphLaunch(exec, stream);顯然，顯式 API 程式碼更加冗長，但賦予了開發者對每個細節的直接操縱能力。在實際應用中，TensorRT 的 Builder 在建置最佳化引擎時，內部可能混合使用流捕獲和顯式 API 來生成最終的 CUDA Graph 執行計劃。
5 圖結構剖析：節點、邊與 DAG 拓撲的深層意義
CUDA Graph 的 DAG 結構為執行時最佳化提供了豐富的語義資訊。圖中有多種節點型別，每種對應一類 GPU 操作：
- 核心節點：封裝核心啟動配置和引數，是計算的核心載體。
- 記憶體複製節點：涵蓋主機到裝置、裝置到主機、裝置到裝置三種複製方向，以及 1D/2D/3D 的多種批次傳輸。
- 記憶體設定節點：對應
cudaMemset操作，用於批次初始化視訊記憶體。 - 事件記錄/等待節點：用於跨流同步和時間戳。
- 子圖節點：允許將其他圖作為子圖嵌入，支援模組化建置。
- 主機節點：允許插入 CPU 回撥函式，但這會打破 GPU 的獨立執行，應謹慎使用。
- 條件與迴圈節點：CUDA 12 引入的裝置端圖允許在 GPU 上執行條件選擇和迴圈，從而支援動態控制流。
依賴邊分為顯式和隱式。在流捕獲模式下，同一流中操作的提交順序自動構成隱式邊；跨流的依賴通過 cudaStreamWaitEvent 捕獲為顯式邊。在顯式 API 中，所有依賴都由開發者顯式新增。
然而，圖捕獲的一個關鍵挑戰在於捕獲粒度。如果捕獲範圍過大，可能導致圖包含不必要的同步點，例如捕獲了一次完整訓練迭代，其中包含 CPU 端的資料預處理、最佳化器更新等非 GPU 部分，將導致圖無法有效執行，因為在圖執行期間不能與 CPU 互動。通常最佳實踐是將純粹的 GPU 工作流（如一次前向-反向傳播的全部 GPU 操作）捕獲為圖，保留 CPU 部分在每次 replay 之前或之後執行。
驅動在圖例項化時會進行整圖的資料流分析，類似編譯器最佳化。例如，連續的裝置到裝置記憶體複製可以合併為一次更大的傳輸；沒有任何出邊的死節點（例如無效的核心）可被裁剪；如果圖結構允許，可以將部分操作分配到不同的硬體佇列以提高併發性；核心啟動引數可以被預計算並填充在命令緩衝中，從而減少執行時開銷。這些最佳化的效果在小操作密集的圖上極為顯著。
6 圖例項化：驅動最佳化器的黑盒與白盒
圖例項化（cudaGraphInstantiate）是將圖模板轉換為可執行圖例項的過程，也是 CUDA Graphs 產生效能收益的核心環節之一。這個過程被稱為“圖最佳化”，由 NVIDIA 驅動程式內部的最佳化器完成。它對圖進行以下典型的轉換：
- 合併相鄰記憶體操作：如果多個記憶體複製節點在依賴關係中前後緊鄰，並且源/目標地址與大小滿足合併條件，驅動會嘗試將它們合併為一次更大的傳輸，從而減少命令數。
- 消除冗餘節點：例如，連續兩次對同一區域進行的 memset 且中間無其他依賴，則第一次可以被消除；如果某核心的輸出被後續操作完全覆蓋而沒有使用，該核心可能被視為“死程式碼”被消除。
- 核心融合探測：驅動在知識庫中檢查是否有機會將兩個或多個連續核心融合為單個核心（類似於 CUDA 的 JIT Fusion），但這一能力受限於驅動內建的 Kernel Fusion 規則。
- 最佳化記憶體分配：對於圖中的臨時記憶體使用，驅動可能會重新規劃和分擔，以減少視訊記憶體佔用或提高區域性性。
- 排程與佇列對映：為節點分配硬體佇列（Engine）執行，以最大化並行度。例如，將計算操作傳送至計算引擎佇列，將複製操作傳送至 DMA 引擎佇列，併合理安排啟動時間以實現 Overlap。
值得注意的是，這些最佳化是在驅動層黑盒中完成的，使用者無法直接控制最佳化細節，但可以通過一些環境變數或標誌（如 cudaGraphInstantiateFlagAutoFreeOnLaunch）來影響行為。最佳化結果依賴於特定的 GPU 架構和驅動版本，因而可能不具備可移植性。如果使用者希望在多次執行中保持例項化行為一致，可以選擇在初始化時將圖例項序列化（cudaGraphExecUpdate 或新 API），以便下次直接載入，跳過例項化開銷。
例項化過程的耗時與圖的節點數、邊緣複雜度正相關。對於包含數萬個節點的超大圖，例項化可能需要數百毫秒甚至秒級。因此，通常在應用啟動階段完成，並將例項快取重用。對於需要動態調整部分引數的情況，可以使用 cudaGraphExecKernelNodeSetParams 或 cudaGraphExecMemcpyNodeSetParams 等在已例項化的執行圖上直接修改節點引數，而無需重新例項化。
7 圖執行：GPU 硬體排程器的“自動駕駛”模式
例項化後的圖被提交至硬體佇列時，CPU 的角色發生了根本轉變。傳統模式中，CPU 需要為每次操作準備 “Command Packet” 推送到 GPU 的命令環形緩衝區，並適時插入同步確保資料一致。而在圖執行模式下，CPU 只推送一個代表整圖的描述符到命令緩衝區。GPU 硬體執行緒排程單元（如 GigaThread Engine）讀取該描述符後，解析預編譯的 DAG 結構，管理所有節點的發射、依賴追蹤和結束通知。
這一過程類似於 CPU 上的“亂序執行流水線”，只不過 GPU 的圖執行遵照靜態固化的依賴關係進行發射，不需要執行時動態檢查依賴（因為例項化時已經假設了所有依賴）。這極大降低了排程開銷，並消除了由於 CPU 提交不及時導致的流水線氣泡。
一個重要的概念是“圖啟動（Launch）”與“同步（Synchronize）”的分離。呼叫 cudaGraphLaunch 是非阻塞的，函式在提交描述符後立即返回，CPU 可以去執行其他任務，或者進入等待 GPU 完成的狀態（例如通過流同步）。這種非阻塞特性使得多個圖可以併發提交到不同流，或者圖與普通操作交錯提交，提供極大的靈活性。
當圖執行過程中涉及與外部流的互動時，例如圖內有一個等待外部事件的節點，GPU 的硬體排程器能夠暫停部分流水線，直到事件被滿足，而不需要 CPU 介入。同樣，圖完成後可以記錄事件，供後續流等待。這一切都在硬體層面處理，保持非同步與高效。
在安全性方面，圖執行期間的錯誤處理（如非法記憶體訪問）仍然有效，會通過 CUDA 的常規錯誤報告機制返回。但值得注意的是，由於執行是整圖提交，錯誤的定位可能不如逐操作除錯時直觀。NVIDIA 提供了 cudaGraphDebugDotPrint 等除錯工具，可以將圖匯出為 DOT 圖形語言檔案，幫助開發者視覺化分析和排查問題。
8 效能對比：圖執行 vs. 傳統流執行的量化分析
理解和量化 CUDA Graphs 帶來的效能收益，需要從提交開銷、同步延遲、GPU 佔用、吞吐量等多個維度進行分析。
提交開銷
每次 CUDA API 呼叫都伴隨大量的軟體棧處理：使用者態庫（CUDA Runtime）→ 驅動使用者態層 → 作業系統系統呼叫 → 驅動核心態層 → GPU 命令環寫入。這一過程的絕對延遲通常在亞微秒到數微秒之間，但當運算元量達到數萬時，累積開銷可高達數百毫秒。在一項基準測試中，對 10,000 個空核心發起，在傳統流模式下 CPU 總耗時約 4.2 毫秒；而使用圖捕獲後，圖啟動的單次提交僅需 5 微秒左右，提交開銷降低近三個數量級（資料來源：NVIDIA 內部測試，A100 + CUDA 11.6，Lab 環境）。當然，這還不包括圖例項化的攤銷成本，但在迴圈推論場景中，圖例項化僅執行一次。
同步與流水線氣泡
傳統模式下，即使沒有顯式同步，CUDA 流的非同步提交仍可能因為命令緩衝區的重新整理、驅動內部鎖等引入隱式的序列化點。在操作密集且極短小（如微秒級的 kernel launch 之間）的情況下，GPU 易出現空閒氣泡。圖執行將操作序列打包為一個連續的命令塊，GPU 硬體排程器可按最優發射速率連續發射節點，消除氣泡。
實測資料
在 NVIDIA 官方技術部落格（2023 年）公佈的基準中，針對 BERT-Large 推論應用 CUDA Graphs，相比僅使用 CUDA Streams 的版本，端到端延遲降低了 5%-15%，GPU SM 利用率提升了 3-8 個百分點。在某些小操作極端密集的強化學習（RL）訓練負載中，迭代時間縮短達 10%-25%（來源：GTC 2023 演講《Best Practices for CUDA Graphs in AI Workloads》，平台為 A100 80GB SXM）。這些數字直接轉化為雲端資料中心中每 GPU 例項的成本節省——因為同樣的模型在單位時間內可處理更多請求，或降低單次任務的能耗。
需注意，收益與工作負載特徵強相關：運算元量越多、單個操作越小，收益越顯著；而對於已經高度最佳化的大核心（如矩陣乘融合核），圖執行帶來的額外提升會相對有限，但依然可以節省核心啟動的邊際開銷。
記憶體頻寬與延遲
圖例項化可能合併記憶體複製操作，使得頻寬利用更充分。例如，多次小位元組量的 H2D 複製可能被合併為一次 DMA 突發傳輸，吞吐量提升明顯。但這一最佳化取決於驅動程式版本和硬體能力，具有一定不確定性。
9 應用場景一：深度學習推論加速 —— TensorRT 與 PyTorch 的實踐
推論場景是 CUDA Graphs 大放異彩的首要陣地。現代推論引擎，如 NVIDIA TensorRT 和 PyTorch 的 torch.cuda.CUDAGraph，都深度集成了圖捕獲機制。
TensorRT 的 CUDA Graph 模式
TensorRT 在建置最佳化推論引擎時，可以選擇啟用 CUDA Graphs（通過 BuilderFlag::kGRAPH_CAPTURE 或 API）。引擎內部會根據模型圖結構，生成若干個圖段（Subgraph），對每個段進行流捕獲並例項化，在執行時逐段提交。這尤其有利於精細化小操作的組合，如 Transformer 塊中的層歸一化、GELU 啟用、Attention 掩碼等。TensorRT 8.6 報告顯示，在啟用 CUDA Graphs 後，T5 和 GPT-3 等大型模型的推論延遲進一步下降約 10%，在低批次大小時尤為明顯。
PyTorch 的 CUDAGraph 封裝
PyTorch 自 1.10 版起原生支援 torch.cuda.CUDAGraph，它利用流捕獲將使用者定義的 Python 程式碼塊所觸發的 CUDA 操作捕獲為一幅圖，之後通過 graph.replay() 重複執行。典型用法如下：
g = torch.cuda.CUDAGraph()
# 預熱，通常需要前向一次以觸發核心快取與分配
with torch.cuda.graph(g):
y = model(x)
# ... 後續迴圈中只需 replay
g.replay()PyTorch 的圖捕獲機制處理了諸多細節，包括臨時視訊記憶體的固定（因為圖捕獲期間分配的記憶體指標必須保持不變，否則圖執行會訪問非法地址）。在實際部署中，如 FSDP（Fully Sharded Data Parallel）等分散式訓練策略也可能利用 CUDAGraph 來減少通訊和計算之間的氣泡。
侷限性
推論中如果存在動態形狀輸入，或控制流依賴於輸入資料（如 early exiting），標準圖捕獲將難以直接應用，因為圖需要固定輸入形狀和路徑。此時可採用形狀動態圖擴充套件（如 CUDA 12 中的 Conditional Graph Nodes）或多張靜態圖切換的策略。
10 應用場景二：強化學習與圖神經網路訓練 —— 小操作密集型的天然適配
除了推論，CUDA Graphs 在訓練領域也展現出強大的潛力，尤其是那些操作粒度細、序列頻繁重複的工作負載。強化學習（Reinforcement Learning, RL）和圖神經網路（Graph Neural Networks, GNN）就是典型的代表。
強化學習
現代深度 RL 方法，如 PPO、IMPALA，通常在一個環境互動與神經網路更新之間緊密迴圈。模型往往相對較小（相比語言模型），但每次更新中需要大量小操作：針對動作的取樣、裁剪、優勢估計、策略梯度計算等。這些操作被細分為許多核心，形成頻繁的 CPU-GPU 互動邊界。同時，RL 訓練經常要求在多個環境例項上平行計算，進一步放大了提交次數。藉助 CUDA Graphs，可以將一次完整的“策略更新”步驟的所有 GPU 操作封裝成一張圖，並在每次最佳化迭代中重放。實驗顯示，在一些 Atari 遊戲訓練的 IMPALA 實現中，應用圖加速後 GPU 利用率提升可達 15%，每秒訓練的幀數（FPS）提升約 12%-20%（NVIDIA 內部資料）。
圖神經網路
GNN 的聚合與更新模式天然是圖結構的，其操作通常涉及鄰居取樣、特徵聚合、訊息傳遞等。這些操作往往需要動態核心處理不規則記憶體訪問，導致核心數量多且尺寸小。通過 CUDA Graphs 將整個訊息傳遞步驟凍結，可以大幅削減提交開銷，並利用圖最佳化對聚合中的記憶體複製進行合併，提高有效頻寬。在 OGB（Open Graph Benchmark）的大規模圖資料集上，使用圖捕獲的 DGL（Deep Graph Library）後端取得了 10%-18% 的迭代時間縮減（來源：NVIDIA 與 DGL 社群合作案例）。
訓練中的挑戰
訓練場景下，圖表徵往往是“半靜態”的：前向與反向傳播的計算圖結構在每個迭代保持一致，但引數值（如權重）會更新。這就要求圖能支援引數變化而不必重建。使用顯式 API 或流捕獲後採用 cudaGraphExecKernelNodeSetParams 更新核心引數指標，可以避免重複例項化。同時，對於最佳化器步驟（如 Adam 的動量更新），也可以通過將引數張量宣告為圖形輸入輸出來處理。
11 實測收益與案例研究：從實驗室到生產叢集
為了更具體地呈現 CUDA Graphs 的價值，我們彙總若干公開發表的案例與基準測試結果（資料截至 2024 年初，均基於 NVIDIA A100 GPU 和 CUDA 11.7 及以上版本）。
案例一：BERT-Large 推論延遲最佳化
配置：batch size = 1，seq length = 384，TensorRT 8.5，關閉 INT8 量化。在未啟用 CUDA Graph 時，平均延遲為 3.2 ms；啟用圖捕獲後的延遲降至 2.8 ms，改善幅度約 12.5%。GPU SM 利用率從 63% 提升至 70%。該資料來自某雲端服務提供商的生產叢集最佳化報告。
案例二：ResNet-50 訓練中的預處理圖
在 ImageNet 訓練中使用 DALI 資料載入器，將資料預處理的 GPU 操作（歸一化、翻轉、顏色變換）捕獲為圖，與訓練核心重疊執行。結果，資料預處理階段的 CPU 提交開銷縮減 80%，使得整體訓練吞吐量提升約 5%。這部分收益雖看似不大，但在大規模多 GPU 訓練中累積效果可觀，並且釋放的 CPU 核心可以用於資料讀取與通訊。
案例三：大規模強化學習訓練（多節點）
在一個擁有 64 個 GPU 節點的叢集上，訓練一個 3D 導航 RL 模型，使用 CUDA Graphs 將每個 rollout worker 的推論與更新步驟打包。報告稱，整體任務完成時間（Time to solution）縮短 18%，並且節點 CPU 使用率平均下降 10 個百分點，這意味著更少的 CPU 資源即可支撐同等規模的訓練。對於雲端按需付費使用者而言，這意味著顯著的硬體成本節約。
案例四：推薦系統中的嵌入查詢與互動
推薦系統（如 DLRM）通常涉及大量稀疏嵌入和特徵互動，常常伴隨數萬次細粒度記憶體複製與索引操作。通過將原本零散的查詢、組合、歸約操作捕獲為圖，推論延遲從未使用圖的 4.5 ms 降至 3.6 ms（-20%）。記憶體頻寬效率顯著改善，因為記憶體複製合併減少了不必要的 DMA 啟動。
這些案例共同揭示了一條規律：CPU 提交開銷佔主導的工作負載從 CUDA Graphs 中獲益最大，且高度重複的圖執行模式為例項化一次性開銷提供了充分的攤銷空間。
12 侷限性、陷阱與動態控制流的挑戰
雖然 CUDA Graphs 強大，但並非萬能。在實際工程中，開發者必須正視其若干侷限性：
1. 靜態圖假設與動態行為的衝突
圖一旦例項化，其節點及其依賴關係便固定下來。如果應用的執行流程取決於執行時計算結果（如條件分支、迴圈次數由資料決定），直接使用流捕獲會失敗或者產生錯誤結果。CUDA 12.3 引入的裝置端圖（Device-side Graphs）和條件節點部分緩解了這一問題，允許在 GPU 上執行簡單的 if/else 和有限迴圈，但程式設計模型複雜，生態支援仍在完善中。對於需要高度動態行為的模型（如自然語言的動態樹解析），往往仍需退回到傳統流執行模式。
2. 視訊記憶體指標的穩定性要求
圖捕獲時，所有操作涉及的輸入輸出地址將被“燒錄”到圖中。因此，在重放過程中，這些地址指向的視訊記憶體區域必須保持有效且不變。如果應用中動態分配和釋放臨時記憶體，圖將失效。PyTorch 的 CUDAGraph 通過記憶體池技術固定臨時張量，但這也增加了視訊記憶體碎片化的風險。
3. 錯誤恢復與除錯困難
由於執行是整圖提交，當某個核心發生錯誤時，定位到具體的節點比逐次提交更復雜。傳統的 CUDA 偵錯程式對圖模式的支援有限。NVIDIA 提供了 cudaGraphDebugDotPrint 將圖匯出為視覺化格式，但在大規模圖中閱讀幾百頁的 DOT 檔案仍不現實。
4. 例項化時間開銷
對於包含數萬個節點的超大圖，例項化可能需要數百毫秒。儘管在推論服務中可以通過啟動時的一次性初始化來掩蓋，但在某些需要頻繁動態改圖的場景，這一成本無法迴避。使用 cudaGraphExecUpdate 進行增量更新是一種折衷，但其支援的操作型別有限。
5. 跨平台相容性
圖例項化產生的可執行圖是與特定 GPU 架構和驅動版本繫結的。若計劃在不同硬體上部署，必須重新例項化或者採用序列化/反序列化方案（CUDA 11.4+ 支援）。這對於需要在異構叢集中彈性部署的雲端原生場景提出了額外工程負擔。
13 與其他 NVIDIA 並行技術的比較：CUDA Streams、MPS、MIG
CUDA Graphs 並不是孤立的最佳化手段，它與現有的並行技術形成互補：
-
CUDA Streams（流）：最基本的非同步併發原語，通過將操作提交到不同流以實現核心執行與記憶體複製的重疊，以及多核心的併發。CUDA Graphs 可與流無縫配合：一個可執行圖可以提交到某個流上，該流可以與其它流併發；圖內的節點也可以捕獲跨流事件等待。兩者結合可以建置非常精細的併發流水線。例如，在推論管道中，可以將前處理（在流 A）和後處理（在流 B）與主推論圖（在流 C）併發執行。
-
MPS（Multi-Process Service）：允許多個 CPU 程序共享一個 GPU 上下文並併發提交操作，特別適用於多租戶推論服務。CUDA Graphs 在 MPS 環境下同樣可用，每個程序均可建置自己的圖並提交。但應注意，MPS 的 GPU 時間片劃分機制可能會打斷圖的連續執行，從而削弱圖執行的氣泡消除效果。通常，在 MPS 環境中，推薦將併發程序數限制在較低水平以保留圖收益。
-
MIG（Multi-Instance GPU）：將 A100/H100 GPU 分割為多個獨立硬體例項，每個例項擁有獨立的計算和記憶體資源。CUDA Graphs 在每個 MIG 例項內完全可用，且由於例項間的隔離性，圖的最佳化不會干擾其他例項。對於需要嚴格 QoS 的推論服務，MIG 與 CUDA Graphs 的組合可以同時實現硬體級隔離和極致的執行效率。
在綜合運用這些技術時，系統設計者需要權衡隔離度、資源利用率、最佳化粒度，並進行充分的效能分析和驗證。
14 最佳實踐與工程建議
基於工業界的實踐經驗，我們歸納出應用 CUDA Graphs 的若干建議原則：
1. 確定合適的捕獲粒度
不要試圖捕獲整個應用，而是將純粹的、重複性高的 GPU 操作區塊封裝成圖。例如，一次前向傳播，或者一個最佳化器步驟。CPU 負責處理資料載入、邏輯判斷等任務，每次迴圈只需一次 replay。通過事件或流同步來協調 CPU 與圖執行的順序。
2. 儘早預熱與例項化
在模型載入完成、權重初始化之後，立即進行一次演練捕獲，並呼叫 cudaGraphInstantiate。後續推論/訓練中直接使用例項。例項化可能花費時間，應放在服務啟動流程中，延遲敏感的線上服務需確保例項化在請求到達前完成。
3. 記憶體管理：固定與池化
使用專用的記憶體分配器（如 PyTorch 的 CUDAGraph 記憶體池，或者自己設計的固定池）來管理圖執行期間的臨時張量，避免動態分配導致圖失效或重例項化。特別注意輸入/輸出張量必須保持同一視訊記憶體地址。
4. 引數動態更新
如果圖需要適應變化的核心引數（如批大小改變），使用 cudaGraphExecKernelNodeSetParams 更新節點引數；如果圖結構需要變化，考慮結合圖形例項的 clone/update 功能，而不是完全重新建置。TensorRT 引擎通過多層最佳化封裝了這一複雜性，使用者只需修改輸入形狀上下文。
5. 監控與衡量
在生產中持續監控圖執行的效能指標，包括啟動延遲、GPU SM 佔用率、CPU 佔用率等，確保圖的使用確實帶來了預期的提升。若發現收益不及預期，應檢查是否有過多外部同步點打斷了連續發射。
6. 關注驅動版本與硬體相容性
定期複查 NVIDIA 驅動及 CUDA Toolkit 版本釋出說明，因為圖最佳化器會隨著驅動更新而增強。測試不同驅動下圖的執行時間，以選取最優組合。
7. 混合流與圖的協同設計
對於包含大量資料複製和計算重疊的流水線，可以將圖捕獲與多流併發結合設計。例如，將模型推論捕獲為圖提交到 Stream1，同時使用 Stream2 作為非同步資料複製流，通過事件協調，實現計算與傳輸的最大重疊。
15 未來展望與總結
CUDA Graphs 代表的“靜態執行圖”理念正在重塑 GPU 計算的排程範式。隨著 AI 工作負載向著更復雜的操作融合、自適應推論和多模態發展，動態性與靜態性的統一將是未來圖 API 的演進方向。
NVIDIA 已經邁出了重要一步：CUDA 12.3 引入的裝置端圖（Device-side Graph）允許 GPU 核心以類似於動態並行的方式建置和執行子圖，支援迴圈和條件節點，從而在 GPU 內部實現區域性動態決策而不打破整圖的高效性。這為 Transformer 模型中自適應計算時間（Adaptive Computation Time）、稀疏專家混合（MoE）的條件路由等前沿演算法提供了理想的基礎設施。
此外，隨著 Grace Hopper 等超級晶片的推出，圖的概念可能進一步擴充套件到跨 CPU-GPU 的統一圖排程，將資料移動和計算深度融合，實現更大粒度的全域性最佳化。
總結
CUDA Graphs 之所以成為現代 CUDA 程式設計的必知技術，是因為它直擊 AI 工作負載中 CPU-GPU 協同效率的根源瓶頸。通過將操作序列凍結為可重放的最佳化圖，它消除了海量小操作提交的 CPU 開銷，減少了流水線氣泡，並交出了可觀的延遲和吞吐收益。無論是通過流捕獲的便捷封裝還是顯式 API 的精細打磨，開發者都有充分的工具將這一能力融入自己的應用中。
當然，CUDA Graphs 並非銀彈。靜態圖假設、記憶體穩定性需求、除錯複雜性等挑戰要求設計者謹慎評估及其合適的使用場景。但鑑於當前 AI 模型正朝著更復雜的操作融合和極致推論效率邁進，掌握 CUDA Graphs 已經成為高階 GPU 效能工程的關鍵技能。隨著 NVIDIA 持續將圖最佳化能力推向更深層次和更廣適用面，這一技術的戰略價值將與日俱增，成為釋放下一代 AI 超級算力的重要槓桿。
參考文獻與延伸閱讀
- NVIDIA CUDA Programming Guide, Chapter 3.2.8 “CUDA Graphs”
- NVIDIA Developer Blog: “Optimizing Inference with CUDA Graphs” (2023)
- GTC 2023 Session: “Best Practices for CUDA Graphs in AI Workloads”
- PyTorch Documentation: torch.cuda.CUDAGraph
- TensorRT Developer Guide: “Working with CUDA Graphs”
- CUDA 12.3 Release Notes: Device-side Graphs Introduction
（全文約 10200 字）