Nvidiaのコンテキスト最適化Rubin CPX GPUは必然だった

Table of Contents

Nvidiaのコンテキスト最適化Rubin CPX GPUは必然だった

分析Nvidia は火曜日、Microsoft の GitHub Copilot などのコード アシスタントで見られるような極めて長いコンテキストの AI ワークフローを高速化し、同時に高価で電力を大量に消費する高帯域幅メモリ (HBM) を削減するように特別に設計された GPU、Rubin CPX を公開しました。

NVIDIAがこの方向へ進んでいる可能性を示唆する最初の兆候は、CEOのジェンスン・フアン氏が春のGTC基調講演でDynamoを発表した時でした。このフレームワークは、分散型推論というアイデアに広く注目を集めました。

すでにご存知かもしれませんが、大規模言語モデル (LLM) の推論は、計算集約型の計算フェーズと、メモリ帯域幅に制限のある 2 番目のデコード フェーズの 2 つのカテゴリに分類できます。

従来、プリフィルとデコードはどちらも同じGPUで実行されていました。分散型サービスでは、パイプラインの各フェーズに異なる数のGPUを割り当てることができるため、コンテキストサイズの増加に伴うコンピューティング能力や帯域幅のボトルネックを回避できます。そして、コンテキストサイズは確かに急速に増加しています。

過去数年間で、モデル コンテキスト ウィンドウは、Llama 2 のわずか 4,096 トークン (単語の断片、数字、句読点など) から、今年初めにリリースされた Meta の Llama 4 Scout では 1,000 万にまで急増しました。

これらの大きなコンテキストウィンドウは、モデルの短期記憶のようなもので、応答を処理および生成する際に保持できるトークンの数を決定します。平均的なチャットボットの場合、これは比較的小さいです。ChatGPT Plusプランは約32,000トークンのコンテキスト長をサポートします。このコンテキスト長を使い切るには、かなり長い会話が必要です。

しかし、コード生成のようなエージェントワークロードの場合、コードベースを理解するには、数十万、場合によっては数百万トークンに相当するコードを処理する必要があるかもしれません。このようなシナリオでは、メモリ帯域幅よりもはるかに多くのコンピューティング能力が必要になります。

HBM搭載GPUを多数プリフィルステージ専用にするのは、コストが高く、消費電力が大きく、非効率的です。NVIDIAはHBM搭載GPUをデコード用に確保し、代わりに低速で安価ながらも消費電力が少ないGDDR7メモリを搭載した新しいGPU、Rubin CPXを導入する予定です。

Nvidia のブログ投稿には、この戦略をわかりやすく示すグラフィックが含まれています。

Nvidiaのブログ記事には、この戦略を分かりやすく説明したグラフィックが掲載されている。

その結果、はるかに安価なハードウェアを使用して同じ量の作業を実行できる構成が実現します。

Vera Rubin NVL144 CPXのプレフィル

Nvidia によれば、各 Rubin CPX アクセラレータは 30 petaFLOPS の NVFP4 コンピューティング能力 (この数値がスパース性を想定しているかどうかは不明) を備え、ハードウェア エンコードおよびデコード機能の両方を備えた 128 GB の GDDR7 メモリを搭載します。

GDDR7はHBMの速度のほんの一部です。例えば、GDDR7ベースのRTX Pro 6000は96GBのメモリを搭載していますが、最大速度は1.6~1.7TB/sです。一方、180GBのHBM3Eを搭載し、2つのBlackwell GPUダイそれぞれに4TB/sの帯域幅を提供できるB300 SXMモジュールと比較してみましょう。

NVIDIAはNVFP4の性能を謳っていますが、キーバリュー(KV)キャッシュは従来、モデルの精度を維持するためにBF16でコンテキストを保存してきたため、実際のプリフィル性能はキーキャッシュとバリューキャッシュがどの精度で保存されているかに依存すると考えられます。また、このチップは、LLM推論の重要なメカニズムであるアテンション(注目度)の高速化を、同社のGB300スーパーチップと比較して3倍実現するとされています。

比較すると、GTC で公開された Rubin のバージョンでは、単一の SXM モジュール上にレチクル サイズの GPU ダイのペアが搭載され、合計 50 ペタフロップスの NVFP4、288 GB の HBM4、13 TB/秒のメモリ帯域幅を実現します。

NVIDIAは、これらのチップがラックスケールNVLシステムにどのように統合されるかについては明らかにしていませんが、GPU大手である同社が、コンピュートトレイ1台あたりVera CPU 2基とGPU 16基(Rubin(HBM)8基とRubin CPX(GDDR7)8基)を搭載したラックのCPXバージョンを提供することは分かっています。NVIDIAのNVL144 CPXラックは、ラック1台あたりCPUソケット36基とGPU 288基を搭載します。

NvidiaのVera Rubin NVL144 CPXコンピュートトレイには、16基のGPUが搭載される。そのうち8基はHBM、残りの8基はGDDR7を使用したコンテキスト最適化されたGPUである。

NvidiaのVera Rubin NVL144 CPXコンピュートトレイには、HBM搭載のGPUが8基、GDDR7搭載のコンテキスト最適化GPUが8基、合計16基のGPUが搭載される。

Nvidia がこれらの CPX GPU を自社のシステムにどう統合するかはすぐには明らかではないが、NVL144 という名前から、Nvidia は 1.8 TB/s の NVLink-C2C 相互接続を使用せず、代わりに PCIe 6.0 を利用することが示唆されている。

  • アリババはAI推論におけるNVIDIAへの依存を終わらせようとしている
  • AI兵器商人NVIDIAは米中貿易戦争で数十億ドルの損失を嘆く
  • NvidiaがローカルAI開発向けの超小型GB10スーパーチップの詳細を発表
  • Nvidia、リアルタイムロボット推論用Jetson Thorキットを宣伝

文脈における問題

過去 1 年間、モデルがより高度になるにつれ、モデル コンテキストはインフラストラクチャ ベンダーとソフトウェア ベンダーにとって新たな戦場のようなものになってきました。

Nvidia Dynamo や llm-d などのフレームワークを使用した分散型サービスに加えて、インスタント キャッシュと KV キャッシュ オフロードの概念も普及しつつあります。

これらの背後にある考え方は、KVキャッシュを毎回再計算するのではなく、事前充填フェーズからの計算出力をシステムメモリにキャッシュするというものです。これにより、まだ処理されていないトークンのみを計算することになります。

vLLM などの一般的なモデル ランナーに KV キャッシュ オフロードとキャッシュ機能を提供する LMCache の開発者は、このアプローチにより最初のトークンまでの時間を最大 10 倍短縮できると主張しています。

このアプローチは、CXLメモリ拡張モジュール、Redisなどのインメモリデータベース、さらにはストレージアレイと階層化できるため、ユーザーがチャットやAIコーディングセッションを終了した場合でも、KVキャッシュを保存して将来使用することができます。GPUとシステムメモリが使い果たされた場合でも、KVキャッシュは低速なCXLメモリまたはストレージから取得するだけで済み、再計算する必要はありません。

モデルコンテキスト問題に対処することを目的とした一種のメモリエリアネットワークを開発したEnfabricaのCEO、Rochan Sankar氏は、この階層を短期、中期、長期のメモリに例えています。

前述の通り、コンテキストが大きくなるとアクセラレータの計算負荷は大きくなりますが、メモリも大量に必要になります。DeepSeekの最新モデルでは、FP8とBF16のどちらで保存するかによって、128,000トークンのシーケンスごとに約104GBまたは208GBのメモリを使用します。つまり、128Kのコンテキスト長でわずか10件の同時リクエストをサポートするだけでも、1~2TBのメモリが必要になります。

これは、Enfabrica が Emfasys CXL メモリ アプライアンスの採用を促進するために期待している課題の 1 つです。各アプライアンスは、GPU システムがアクセスするための RDMA ターゲットとして最大 18 TB のメモリを公開できます。

Pliops XDP LightningAIプラットフォームは、DRAMではなくRDMAを使用してCXLやSSDとの互換性問題を回避している点で、コンセプトは似ています。NANDフラッシュの使用は興味深い選択です。一方で、大幅にコストが抑えられます。一方で、KVキャッシュは本質的に書き込み集中型の操作であるため、大量のOptane SSDを保有していない限り、問題が発生する可能性があります。®

Discover More