NVIDIAがCUDA Rustを発表：SIMTおよびTileトラックによるRustでのネイティブGPUカーネル開発

TL;DR – NVIDIAのCUDA Rustにより、Rustで直接GPUカーネルを記述可能になりました。2つの異なるプログラミングモデル（cuda‑oxideによるSIMTとcutile‑rsによるTile）が提供され、PTXへのコンパイルとコンパイル時の安全性保証を実現します。

なぜネイティブRust GPUカーネルが重要なのか

Rustの所有権と型システムは、従来のCUDA C++カーネルでは欠けていたメモリ安全性のバグをコンパイル時に一掃します。
NVIDIAのドライバスタックはすでにRustへの移行を進めています（Nova Linuxドライバ、Dynamoコア、NVTXバインディング）。Rustをカーネル層まで拡張することで、言語のカバー範囲が完成します。
開発者はRustからカーネルを起動するだけでなく、カーネルコード自体をRustで記述できるようになり、外部言語のラッパーが不要になります。

CUDAのモデルを反映した2つのトラック

1. SIMTトラック – cuda‑oxide

モデル: CUDA C++やnumba‑cudaと同一の、従来の単一命令複数スレッド（SIMT）プログラミング。
ツールチェーン: Rust MIR → Pliron IR → LLVM IR → PTXという経路で #[kernel] 関数を処理するカスタム rustc コード生成バックエンド。
要件: Linux、計算能力 ≥ 8.0のGPU、CUDA 12.x+、clang、および固定されたnightly Rustツールチェーン（cargo +nightly‑2026‑04‑03）。

はじめ方:

cargo +nightly-2026-04-03 install --git https://github.com/NVlabs/cuda-oxide.git cargo-oxide
cargo oxide new vecadd_demo
cd vecadd_demo
cargo oxide doctor   # 環境の検証
cargo oxide run      # ベクトル加算の例をビルドして実行

安全性のハイライト:
- カーネル引数には DisjointSlice を使用し、各スレッドに排他的な可変アクセス権を与えることで、不正な &mut [T] パターンを回避します。
- #[launch_contract] はスレッドブロックのジオメトリを宣言します。prepare_vecadd は起動構成をコントラクトおよびデバイスの制限に対して検証し、安全な vecadd 呼び出しに必要な証明オブジェクトを生成します。
- コンパイル時のエラーにより、同じバッファを入力と可変出力の両方として渡そうとするような古典的なエイリアシングバグを E0502 として防ぎます。

2. Tileトラック – cutile‑rs

モデル: タイルレベルの抽象化。タイルはサブテンソル上で動作する論理スレッドであり、コンパイラが各タイルを支える物理GPUスレッド数を決定します。
ツールチェーン: 純粋な安定版Rust（≥ 1.89）。nightlyやカスタムLLVMは不要。CUDA 13.3と計算能力 ≥ 8.0のGPUが必要です。

はじめ方:

cargo new vecadd_demo
cd vecadd_demo
cargo add cutile
cargo run   # src/main.rsに例を貼り付けた後

安全性のハイライト:
- テンソルのパーティショニング（api::zeros(...).partition([128])）により、各タイルに排他的な可変所有権が与えられ、特別な DisjointSlice 型が不要になります。
- 動的な次元は型シグネチャ内で -1 として表現され、実際のサイズは起動時に解決されるため、再コンパイルなしで柔軟な形状に対応可能です。
- ランチャー（kernel::add）はテンソルを消費してタプルとして返し、.sync_on(&stream) が呼び出されたときにのみ実行されるため、プログラム全体が遅延評価される記述としてアトミックに動作します。

コンパイラが自動的に検知するもの

エイリアスフリーの保証 – 両トラックとも、適切な排他性なしに同じバッファを読み書きするカーネルを拒否します。SIMTでは「不変として借用されているため可変として借用できない」、Tileでは「ムーブされた値の使用」といったエラーをコンパイル時に発生させます。
スレッドインデックスの安全性 – SIMTでは thread::index_1d() が型付きインデックスを返し、範囲外アクセスは未定義のメモリ読み取りではなく、明示的な Option 分岐となります。
起動時の検証 – #[launch_contract] は、提供された LaunchConfig がカーネルの宣言されたジオメトリおよびデバイスの制限と一致することを強制し、ランタイムクラッシュの一般的な原因をコンパイル時のチェックに変換します。

プロジェクトの成熟度とエコシステムにおける位置付け

cuda‑oxide – アーリーアルファ版。nightlyツールチェーンが必要でLinux専用です。CUDAの既存のPTXパイプラインに近い、低レベルなMIRベースのパスを提供します。
cutile‑rs – crates.ioで公開されており、HuggingFaceの Grout 推論エンジンや mistral.rs プロジェクトですでに使用されています。より安定していると見なされていますが、まだ1.0未満でありAPI変更の可能性があります。
両プロジェクトは他のRust‑GPUの取り組み（rust‑cuda、rust‑gpu、CubeCL）と共存しています。NVIDIAのブログには、これらの関係性をまとめたエコシステムの付録へのリンクがあります。

今すぐ試すには

SIMTの例 – cargo oxide new vecadd_demo && cargo oxide run
Tileの例 – Tileベースのベクトル加算コードをコピーした後、cargo add cutile && cargo run
ドキュメント – cuda‑oxide book および cutile‑rs docs
論文 – Fearless Concurrency on the GPU (arXiv 2606.15991)
コミュニティ – 各GitHubリポジトリでIssueを報告するか、Discordに参加するか、RustConf 2026でのMelih Elibol氏の講演に参加してください。

コミュニティの反応（HNコメントより抜粋）

「起動が信頼されるのではなく検証される。くそっ、NVIDIAでさえ完全にClaudeが書いた記事を出しているのか。」 – claiir

「こういうのをずっと待っていた。CUDA C++は苦痛だ。カーネルプログラミングにおけるRustの安全性はゲームチェンジャーになる可能性がある。」 – Driftbench

「NVIDIAがHuggingFaceを所有し、HuggingFaceがRustでの推論用に優れたCandleクレートを持っている今、これは優れたネイティブRustカーネルへの良い一歩に見える。」 – dllu

「私はCUDAが嫌いだ…GPUをプログラミングする最良の方法は、Metal、OpenCL、D3D12のように、カーネルを別のファイルに書いて手動で起動することだ。」 – jacobgorm （哲学的な代替案を指摘）

今後の展望

NVIDIAのCUDA Rustイニシアチブは、Rustの安全性保証をGPUスタックにもたらすという戦略的な推進を示しています。低レベルな制御（SIMT）と高レベルな抽象化（Tile）の両方に対応する2つの補完的なトラックから始まっています。ツールはまだ初期段階ですが、すでに本番グレードのRust推論エンジンで採用されており、急速な成熟の道筋が見えています。APIが安定するにつれ、開発者は完全にRustで高性能なGPUカーネルを記述するための、よりスムーズで安全な体験を期待できるでしょう。