Hot Chips 2026：Nvidia、CUDA の RISC-V CPU 対応を検討

GPU 演算、特に機械学習アプリケーションの分野において CUDA は巨人のような存在です。これまで CUDA がサポートしてきたのは x86-64 と aarch64 の CPU でしたが、Nvidia はついに RISC-V への対応も視野に入れ始めています。

この動きは、RISC-V CPU から GPU 演算リソースを活用する道を開くものです。今回の発表では、CUDA と連携させるために RISC-V CPU が満たすべき要件が焦点となりました。要するに、Nvidia はサーバーグレードの CPU とプラットフォームを求めています。

Nvidia がまず要求するのは、RVA23 仕様に準拠した CPU です。さらに、RISC-V の サーバー SoC および サーバープラットフォーム 仕様への適合も必須となります。これらの仕様には、RAS（信頼性・可用性・保守性）機能や専用セキュリティプロセッサなど、サーバーグレードに不可欠な基本機能が盛り込まれています。Nvidia が求めるサーバー向けの要件の多くは、こうした規格によってすでに満たされているのです。

Nvidia には、上記の RISC-V プロファイルやプラットフォーム仕様を超えた追加要件がいくつかあります。それは、これらの機能がないと CUDA ソフトウェアを十分に動作させることが難しいと判断したためです。

Nvidia は「最低共通分母」の問題を避けたいと考えています。つまり、拡張機能による性能向上を活用できない状況は望ましくありません。なぜなら、その拡張機能がサポートされたハードウェア上で確実に実行されることを保証できないからです。Nvidia の視点では、そうなれば非効率なコードを配布せざるを得なくなります。

具体例としてベクトル拡張が挙げられました。条件分岐（predication）のサポートがあれば、分岐処理を回避できるためです。

ACPI はより困難な要件です。ACPI を利用すれば、ソフトウェアがハードウェアの能力を自動的に検出でき、電力管理、パフォーマンス制御、熱対策などに活用できます。

Nvidia のソフトウェアチームは当初、CUDA のポート作業を開始した時点で RISC-V ハードウェアに ACPI が存在しないことに不満を持っていました。しかし、この状況はすでに解決されています。2025 年、UEFI フォーラムが RISC-V 向けの ACPI サポートを追加しました。また、昨年承認された「RISC-V BRS（Boot and Runtime Services）仕様」にも ACPI が含まれています。

次に、Nvidia は PCIe のコヒーレンシー（整合性）を要求します。Nvidia が指摘するメモリ順序の問題とは、CPU がデータを書き込んだが、そのデータがキャッシュ内に残っている状態です。この状態で CUDA が DMA リクエストを発行してデータを GPU にコピーしようとすると、DMA エンジンは DRAM からデータを読み込み、CPU 側のキャッシュにある更新済みのデータを見過ごす可能性があります。また、GPU からの結果をコピーする際にも、DMA エンジンが DRAM に書き込んだ後に CPU がキャッシュから古いデータを読み込んでしまうリスクがあります。

システムに PCIe コヒーレンシーがない場合、ソフトウェア側で明示的にキャッシュを無効化（インバリデーション）する必要があります。しかし、このキャッシュ無効化処理を CUDA スタックに組み込むのは困難です。そのため Nvidia は、サーバー CPU において PCIe コヒーレンシーは標準機能として実装されるべきだと考えています。RISC-V のサーバー SoC 仕様ではハードウェアによるキャッシュコヒーレンシーの実装が推奨されていますが、Nvidia はより確実な保証を求めています。

Nvidia はさらに、ハードウェアによるピアツーピア PCIe 通信のサポートも求めています。この機能がなければ、2 つのデバイス間でバッファをコピーする際、CPU メモリを経由する必要があり、パフォーマンスが低下するとともに、追加の同期シグナルが必要になるため複雑性が増します。

Hot Chips 2026: CUDA Targets RISC-V (7 minute read)

Nvidia は要件の詳細まで全てを説明しきれなかったようです。同社は特定の性能レベルの達成を目指しており、提出されたリストは全 2 ページに収まるとのことです。これが「大きなフォントで二重行間が空いた A4 用紙 2 枚」なのか、「オープンノート試験で許可されるメモ用紙 2 枚（学生が可能な限り多くの情報を詰め込む）」のどちらを指すのかは、現時点では不明です。

CUDA を RISC-V CPU で動かすことに加え、Nvidia は NVLink Fusion の要件についても簡単に触れました。NVLink Fusion を利用すれば、他社も自社のチップに Nvidia の NVLink IP を実装できるようになり、任意の CPU と組み合わせて Nvidia 製の C2C（Chip-to-Chip）リンクを利用できます。例えば、MediaTek の CPU デイスクと Nvidia GPU を NVLink C2C で接続した GB10 のような製品が想定されます。もちろん Nvidia は顧客に自社の CPU も使ってほしいと考えていますが、カスタム CPU や他のアクセラレータを接続したい場合でも、Nvidia 製の NVLink IP を利用することを望んでいます。そのカスタム CPU が RISC-V である可能性も十分にあります。

NVLink Fusion の要件には、CUDA が求めるすべての条件に加え、DOCA や NCCL といったソフトウェアフレームワークをサポートするために必要な要素も含まれます。さらに、Nvidia との緊密なパートナーシップが必須となります。

IP（知的財産）の統合は複雑を極める作業であり、GB10 を巡る MediaTek と Nvidia の協力関係のような、極めて密接な連携が必要になるでしょう。

RISC-V のソフトウェアエコシステムが、x86-64 や aarch64 に追いつくにはまだ道のりが遠いのが現状です。Nvidia が CUDA を RISC-V 世界へ持ち込もうとする試みは有望な発展ですが、残念ながら、これだけで「RISC-V システムに Nvidia GPU を接続して、すぐに CUDA で開発を始める」ということが可能になるわけではありません。

既存の RISC-V ハードウェアの绝大多数が、Nvidia が求める要件を満たしていないからです。実際、近い将来にこれらの要件を満たす RISC-V 向けコンシューマーハードウェアが存在するとは、私はあまり期待していません。

ACPI（Advanced Configuration and Power Interface）は明白な障壁となっており、ベンダーにとって導入が難しい課題です。aarch64 の世界でも ACPI サポートは長年標準化されながら、その実装状況は不安定で不十分でした。2025 年に策定される RISC-V の新規格が広くサポートされるようになるには、数年どころかそれ以上の時間を要する可能性が高いでしょう。

もし CUDA サポートを搭載した RISC-V システムが登場するなら、それはまずサーバーシステムとして現れる可能性が高いでしょう。 hobbyist が手に入れられるシングルボードコンピュータではないはずです。

Nvidia は SiFive と提携していることを明言しており、SiFive は Hot Chips 2026 で CUDA を実行するシステムのデモを予定しています。Nvidia のスライドに示された例の CPU スペックは、まさにそのシステムに対応するものであり、コア数が非常に多いサーバー用チップであることを示唆しています。

私もそのデモを見るのが楽しみです。ただし、CUDA が未対応のシステム上で動作することを Nvidia 側が妨げないことを願っています。RISC-V システムから NVIDIA GPU を駆動させることに挑戦する愛好家の姿を見てみたいものです。

今後、NVIDIA には既存の RISC-V システムが要件を満たす機会をより多く与えるよう、要求条件を緩和してほしいと願っています。ベクトル拡張機能や PCIe コヒーレンスの欠如が、必ずしも解決不能な性能問題に直結するわけではありません。予測可能な分岐であれば、条件分岐（predication）の代わりに分岐を使用することで十分なパフォーマンスを発揮できます。ただし、PCIe コヒーレンスがない場合のキャッシュ無効化には性能コストがかかります。しかし、データ転送よりも計算処理が主となるワークロードにおいては、そのコストは許容範囲内と言えるでしょう。同様に PCIe ピアツーピア転送についても言えます。高速な動作を実現できるのは素晴らしいことですが、頻繁に発生しない処理については、慎重に設計すれば低速パスに割り当てることも可能です。

NVIDIA の現在の要件が、迅速かつリスクの低い RISC-V ポートを可能にするための妥協点から生まれたものであることを願っています。そして CUDA が、特殊なエンタープライズ向け設計だけでなく、幅広い RISC-V システムでも利用できるよう進化していくことを期待しています。