CUDA Graphs、推論モデル、分離型サービング

現代の AI インフラは、CPU オーバーヘッドの排除、推論時の思考ループ、処理段階ごとに特化した GPU クラスタのルーティングによって、性能をシリコンとクラスタの物理的限界まで押し上げています。この 3 つの技術が、今日の最も高速で賢い本番 AI システムを支えています。

1. CUDA Graphs とカーネル融合：CPU とメモリのオーバーヘッドを排除

H100 や B200 などの最新 GPU が指数関数的に高速化したことで、軽量な GPU カーネル 1 つの実行はわずか 2 から 5 マイクロ秒で済むことがあります。しかし CPU は、PCIe ドライバを通じてカーネルを準備・検証・起動するだけで 10 から 20 マイクロ秒かかることが多く、数百万ドルの GPU が CPU の命令を待って完全に遊んでしまいます。

• カーネル融合（演算をまとめてメモリと起動回数を節約）。

• 融合しない場合のボトルネック。標準的な Transformer 層は、数十の小さな演算を順に実行します（例：LayerNorm → Linear → Add Residual → GeLU）。融合しない場合、GPU は各段階に別々のカーネルを起動し、中間テンソルを低速な HBM (VRAM) に書き出して、次の段階ですぐに読み戻します。
• 融合実行。torch.compile (TorchInductor) や TensorRT-LLM などのコンパイラは、複数の要素単位演算やリダクション演算を 1 つのカスタム CUDA/Triton カーネルに融合します。値は HBM から 1 度だけ読み込まれ、超高速のオンチップレジスタ/SRAM 内で変換され、最後にだけ HBM へ書き戻されるため、メモリ帯域のトラフィックとカーネル起動回数を大幅に減らせます。

• CUDA Graphs（実行パイプライン全体を一度に再生）。

• 記録と再生。カーネル融合後でも、LLM の順伝播は、生成トークンごとに数百回のカーネル起動を必要とします。CUDA Graphs は、ウォームアップ実行中に GPU の演算列全体（カーネル、メモリコピー、依存関係）を取得し、GPU メモリに直接保存する静的な実行グラフへコンパイルすることで、この問題を解決します。
• CPU の介入をゼロに。リアルタイム推論では、CPU が 300 個のカーネルを 1 つずつ起動する代わりに、1 回の API 呼び出し (cudaGraphLaunch) を発行し、GPU が自律的に順伝播全体を実行するようにします。
• 動的な形状への対応。CUDA Graphs には静的なメモリアドレスとテンソル形状が必要なので、推論エンジンは入力バッチを固定バケットサイズ（例：バッチサイズ 1、2、4、8、16）までパディングし、事前取得したグラフを再生する前に入力ポインタをその場で更新します。

2. テスト時計算と推論モデル（o1/o3 と DeepSeek-R1）

従来、AI 研究機関は事前学習により多くの計算資源を投入することだけで知能を拡大していました（より多くのインターネットの文章で、より大きなモデルを学習）。OpenAI の o1/o3 や DeepSeek-R1 などの推論モデルは、第 2 の拡大軸であるテスト時計算（推論時スケーリング）を切り開き、モデルが回答前に長く「考える」ことを可能にしました。

• Chain-of-Thought (CoT) のための強化学習。

• これらのモデルは、人間が書いた段階的推論の例だけに頼るのではなく、数学、コーディング、形式論理などの検証可能な領域で、大規模強化学習 (RL) によって学習されます（DeepSeek-R1 の GRPO、Group Relative Policy Optimization など）。
• モデルは複数の候補推論経路を生成し、最終回答がユニットテストや数学的検証に合格した場合にのみ客観的な報酬を受け取ります。そして自己検証、行き詰まったときの後戻り、複雑な問題の下位目標への分解といった、創発的な認知行動を自律的に発見します。

• 推論の計算量はどう拡大するか。

• 難しいプロンプトが与えられると、モデルは最終回答を出す前に、隠された作業領域で数千もの内部「思考トークン」を生成します。仮説の探索により多くの推論トークンを使うにつれて、精度は対数的に向上します。
• 計算資源のトレードオフの変化。従来の LLM では、推論は低コストで高速です（出力は約 50 トークン）。推論モデルでは、1 回の問い合わせで 10,000 から 50,000 の思考トークンを生成することがあり、推論は KV キャッシュの増大と長いコンテキストのアテンション効率に支配される、大規模で持続的なバッチ生成処理になります。

3. Prefill と Decode の分離

LLM のサービングは、計算特性が根本的に相反する 2 つの段階からなります。両方をまったく同じ GPU で実行すると、深刻なスケジューリングの競合とハードウェアの低稼働を招きます。

• 同居による干渉の問題。

• 従来の統合サービングでは、50 人のユーザーに Decode トークンをストリーミングしている最中に、別のユーザーが 32,000 トークンの巨大な文書を Prefill に投入すると、大規模な Prefill の行列演算が GPU の Tensor Cores を占有します。その結果、ストリーミング中の 50 人全員に、目立つ停止やレイテンシの急上昇（「引っ掛かり」）が生じます。
• また、Prefill は高い演算 FLOPs を必要としますが、Decode は大きなバッチの KV キャッシュを保持するための膨大な HBM メモリ帯域幅と容量を必要とします。

• クラスタの分割（分離型アーキテクチャ）。

• Mooncake、DistServe、NVIDIA Dynamo など、現代の超大規模推論システムは、GPU クラスタを 2 つの専用プールに分けます。
• 1. Prefill プール：素の演算スループット（高い Tensor Core 稼働率、より小さなテンソル並列度）を最適化し、長いプロンプトを素早く処理して、厳しい TTFT（最初のトークンまでの時間）目標を達成します。
• 2. Decode プール：高いメモリ帯域幅と大容量の KV キャッシュ（より広いテンソル/エキスパート並列度、大きなバッチサイズ）を最適化し、最大限の毎秒トークン数で滑らかにトークンをストリーミングします。
• KV キャッシュの高速転送。Prefill GPU がプロンプト処理を終えて初期 KV キャッシュを構築すると、超高速な NVLink または InfiniBand RDMA 接続を通じて、その KV キャッシュを Decode GPU の VRAM へ直接ストリーミング転送します。Decode GPU は干渉を受けず、即座にトークン生成を引き継ぎます。