# CUDAGraph ## 定義 CUDAGraph とは、多数のカーネル起動やメモリ転送といった GPU 操作をあらかじめ「グラフ」として記述し、その後まとめて実行・再利用できる CUDA の機能である。GPU へのカーネル呼び出しやデータコピーはホスト側から API を呼び出すたびにオーバーヘッドが発生するが、一度グラフをキャプチャしておけば全工程をまとめて走らせられるため、カーネル起動・メモリコピーのオーバーヘッドと CPU 側の Python 起因オーバーヘッドを大幅に削減できる。(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]]) ## 横断的知見 - **最適化されていない LLM 推論の最大のボトルネックは演算そのものではなく起動オーバーヘッドである**: Nsight Systems で最適化前の torch 推論を計測すると、GPU カーネル間に約 100 μs のギャップが繰り返し現れ、これは GPU の実行速度に CPU が追いつけていない状態を示す。FlashAttention や量子化のような演算内容そのものの高速化とは異なる層の問題であり、CUDAGraph はこの「CPU 律速」を直接解消する対処である。(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]]) - **CUDA GraphはCPUをキャプチャ時点のグラフから排除するが、実行時分岐の柔軟性を失う**という設計上のトレードオフが、実務書レベルの分析でも裏づけられる。「AI Systems Performance Engineering」第12章は、条件付きグラフノード(IF/IF-ELSE/WHILE/SWITCH)によってこの制約を部分的に緩和できるとし、`cudaGraphSetConditional` で設定した条件ハンドルに基づく分岐をGPU側だけで完結させる手法を示す。ただしPyTorchのPython APIは条件付きノードを直接サポートせず、C++統合が必要という制約もあわせて報告する。デバイス起動グラフローンチ(fire-and-forget/tail/sibling)はホスト起動に対し約2倍低いローンチレイテンシを示し、ノード数・並列分岐数が増えてもレイテンシがほぼ一定に保たれる(ホスト起動はグラフが大きくなるほどCPUスケジューリングコストが増加する)。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 12 Dynamic Scheduling, CUDA Graphs, and Device-Initiated Kernel Orchestration]]) - **CUDA GraphsとDynamic Parallelismは「CPUをクリティカルパスから排除する」という同じ目的を、事前に既知の固定パイプラインか実行時に決まる不規則な分岐かで使い分ける相補的な技術である**。CUDA Graphsは全体の実行フローが既知の場合に固定パイプラインをキャプチャ・リプレイするのに対し、[[Dynamic Parallelism]]は親カーネルが結果を見て子カーネルの数・種類を実行時に決める用途に向く。両者はLLM推論のスケジューリング文脈(vLLM/TensorRT-LLMのバッチサイズ別グラフキャプチャ、あるいはトークンごとに補助アテンションブロックが必要かをDPで判定する例)で共存しうる。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 12 Dynamic Scheduling, CUDA Graphs, and Device-Initiated Kernel Orchestration]]) - **PyTorchはCUDA Graphsをユーザーが手動キャプチャするAPI(`torch.cuda.CUDAGraph`)と、コンパイラが自動キャプチャする仕組み(CUDA Graph Trees、[[torch.compile]]の`mode="reduce-overhead"`)の二層で提供する**。手動キャプチャは静的入力・固定メモリアドレスを前提に全ての中間バッファを最大サイズで事前確保する必要があり、キャプチャ中の新規メモリ確保は「operation not permitted when stream is capturing」エラーで失敗する。CUDA Graph Treesは入力形状ごとに静的グラフをキャッシュし、forward/backwardキャプチャ間でメモリプールを共有する「piecewise capture」でvLLMの可変バッチサイズ推論にも使われる。第12章のデバイス起動グラフローンチ(fire-and-forget/tail/sibling)がC++統合前提の低レベルAPIであるのに対し、第13章のPyTorch統合はPython APIレベルで同じ「CPUをクリティカルパスから排除する」目的を達成する高レベル手段として位置づけられる。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 12 Dynamic Scheduling, CUDA Graphs, and Device-Initiated Kernel Orchestration]], [[@2025__OReilly__AI Systems Performance Engineering - Chapter 13 Profiling, Tuning, and Scaling PyTorch]]) - **MoEのような動的形状ワークロードでは、CUDA Graphsの「固定形状・固定アドレス」制約がDynamic Parallelismだけでなくtorch.compileのモード選択にも同じ緊張関係を生む**。第13章は、トークンルーティングが動的なMoEでは`max-autotune-no-cudagraphs`または`default`を優先し、入力形状が安定してからCUDA Graphを使う`max-autotune`へ切り替えることを推奨する。これは第12章の条件付きグラフノードによる緩和策とは異なるアプローチ(グラフ自体を複数キャプチャし直す vs. グラフ内で分岐する)であり、PyTorchのエコシステムでは前者(形状ごとの再キャプチャ)が主流であることを示唆する。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 13 Profiling, Tuning, and Scaling PyTorch]]) ## 未解決の問い - CUDAGraph によるキャプチャは動的な入力形状(可変長シーケンス、Continual Batching での動的バッチサイズ)とどこまで両立するか。vLLM の ModelExecutor は CUDAGraph キャプチャを担うとされるが、Chunked Prefill や Preemption による動的なリクエスト構成変化にどう対応しているか。 - 条件付きグラフノード(IF/WHILE/SWITCH)は、Continual Batching のような動的なリクエスト構成変化に対して、キャプチャ済みグラフの再利用性をどこまで高められるか。vLLM/TensorRT-LLMは条件付きグラフノードを実運用で採用しているか、それとも複数固定グラフの事前キャプチャ+選択で代替しているか。 - PyTorchのCUDA Graph Trees(形状ごとの再キャプチャ)と第12章の条件付きグラフノード(グラフ内分岐)は、どちらがMoEのような動的ワークロードに対して実運用上優位か。再キャプチャのコストと条件付きノードの実装複雑度(C++統合必須)のどちらがボトルネックになりやすいか、定量的な比較は未確認。 ## 関連 - 隣接 concept: [[GPU最適化]] / [[カーネルフュージョン]] / [[LLM推論]] / [[Dynamic Parallelism]] / [[torch.compile]] - 関連 entity: [[vLLM]] / [[PyTorch]] - ソース: [[@2026__SpeakerDeck__LLM高速化(勉強会)]] / [[@2025__OReilly__AI Systems Performance Engineering - Chapter 12 Dynamic Scheduling, CUDA Graphs, and Device-Initiated Kernel Orchestration]] / [[@2025__OReilly__AI Systems Performance Engineering - Chapter 13 Profiling, Tuning, and Scaling PyTorch]] ## 出典 - [[@2026__SpeakerDeck__LLM高速化(勉強会)]] — CUDAGraph の仕組み、Nsight Systems によるボトルネック観測例 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 12 Dynamic Scheduling, CUDA Graphs, and Device-Initiated Kernel Orchestration]] — CUDA Graphキャプチャ/リプレイの実装詳細、デバイス起動グラフローンチ、条件付きグラフノード、PyTorch統合 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 13 Profiling, Tuning, and Scaling PyTorch]] — `torch.cuda.CUDAGraph` API、CUDA Graph Trees、メモリプール共有、torch.compileモードとの関係