NVIDIAは9月8日、RustでGPUカーネルを記述する「CUDA Rust」の開発方針を示し、スレッドを直接扱う「cuda-oxide」と、データのまとまりを扱う「cutile-rs」の2方式を紹介した。Rust製のアプリケーションからGPUを呼び出す段階から、GPU上で動く処理そのものまでRustで書くための取り組みである。両プロジェクトとも開発初期で、本番利用の準備は整っていない。それでも、書き込み先の重複や非同期実行に伴う誤りを型で防ぐ設計は、GPU開発で人間が確認する作業を減らす可能性を持つ。
Rustから呼ぶ段階から、GPUの処理を書く段階へ
cuda-oxideは、Rustコンパイラのコード生成部分を拡張し、GPU向けの関数をPTXというNVIDIA GPU用の中間コードへ変換する。Rustの中間表現からPliron、LLVMを経由する構成で、CPU側の処理とGPUカーネルを同じソースに書ける。公式リポジトリには、ジェネリックなカーネルへホスト側からクロージャを渡す例もある。
プログラミングモデルはCUDA C++で広く使われるSIMTだ。開発者が「各スレッドはどの要素を読み、どこへ書くか」を指定する。実行構成を細かく調整できる反面、スレッドやメモリの扱いを理解して組み立てる必要がある。
cutile-rs、別名cuTile Rustは、より大きな単位で処理を書く。タイルとは、配列や行列から切り出したデータの小領域である。開発者はタイルに対する演算を記述し、物理的なGPUスレッドへの割り当てをコンパイラへ任せる。専用マクロがカーネルの構文木をCPU側の実行ファイルへ埋め込み、初回実行時にCUDA Tile IRを介してコンパイルする仕組みだ。
cutile-rsの加算例では、1,024要素の出力を128要素ずつに分割する。この分割から、1,024÷128＝8タイルという実行構成も決まる。各スレッドの番号から書き込み位置を計算する代わりに、あらかじめ分けた領域ごとに処理を渡すわけだ。ただし、カーネル記述用のDSLであり、任意のRustプログラムがそのままGPU向けになるわけではない。
RustでGPUカーネルを書く試みには先行例がある。NVIDIAのエコシステム解説も、NVVMを介するrust-cudaや、複数のGPU向けバックエンドを持つCubeCLを紹介している。今回のCUDA Rustは、そうした蓄積の上でNVIDIAがCUDA向けの選択肢を育てる取り組みと捉えられる。Rustを選べることと、同じカーネルを他社GPUへ移せることは別の話だ。
所有権をGPUの実行完了までつなぐ
Rustでは、同じ値を複数箇所から読むことはできても、変更できる参照と読み取り用の参照を同時には持てない。この所有権と借用の規則をGPUへ持ち込む際に問題になるのが、多数の処理が同じ配列へ同時に書き込む場面である。
cuda-oxideのDisjointSliceは、各スレッドに重ならない書き込み先を渡すための型だ。配列全体を変更できる参照を全スレッドで共有する代わりに、専用のインデックス型を使って、自分が担当する要素へのアクセスを得る。範囲外なら値を返さないため、呼び出し側でその場合を扱える。
ただし、型を付ければ起動条件まで自動的に正しくなるわけではない。launch_contractで宣言した条件に対して起動構成を事前検証し、確認済みの値を安全な起動APIへ渡す。生の起動構成を使う経路ではunsafeが必要となる。コンパイル時の借用検査と、起動前の構成検証を組み合わせた設計である。cuda-oxideの起動API説明
cuTile Rustは、書き換えるテンソルをホスト側で分割し、タイルごとに排他的な領域を渡す。テンソルとは多次元の配列であり、共有入力と書き換える出力の区別がカーネル内にも引き継がれる。開発者が物理スレッドを直接操作しないことが、安全性を成立させる条件の一つになる。
さらに、CPUがカーネルを起動した後もGPUは処理を続ける。CPU側の関数が戻った時点で配列を自由に変更できてしまうと、GPUによる読み書きと衝突しかねない。cuTile Rustの研究論文「Fearless Concurrency on the GPU」は、処理を遅延実行するDeviceOpを通じて、この時間差も所有権の管理に含めている。
処理列は同期実行、Rustの非同期実行、CUDA Graphとしての再実行へつなげられる。安全なAPIではGPU処理の完了を待ってから所有権を呼び出し側へ戻す。守る対象は、カーネル内部の書き込み先と、GPUが動いている間のデータの寿命である。
保証には境界がある。発表時点のcuda-oxideでは共有メモリの利用にunsafeが必要で、cuTile Rustにも安全なテンソルAPIから外れて低水準の操作を行う経路が残る。Rustを使うことが、あらゆるGPUコードの誤りを取り除くという意味にはならない。
試す前に確認したい、発表と現行READMEの差
cuda-oxideの導入条件は、発表ブログのCUDA 12.x以降に対し、9月13日確認のREADMEではCUDA Toolkit 13.0以降となっている。NVIDIAの9月8日付ブログのSIMT節と、cuda-oxideのREADMEのSetup節を照合すると、固定するRust nightlyの日付にも差がある。
| 項目 | cuda-oxide | cutile-rs |
|---|---|---|
| 記述する処理の単位 | スレッド単位のSIMT | データの小領域であるタイル |
| Rustの条件 | 現行READMEはnightly-2026-08-28を指定 | 安定版Rust 1.89以降 |
| CUDAの条件 | 現行READMEはToolkit 13.0以降、CUDA 13.x対応ドライバのR580以降 | 現行READMEはCUDA 13.3を推奨 |
| OS | Linux | Linux |
| 導入時の注意 | 発表ブログはCUDA 12.x以降、nightly-2026-04-03と記載 | GPUの対応範囲がCUDAの版によって異なる |
| 開発状況 | 初期アルファ版 | 開発初期。本番利用の準備は未完了 |
表は2026年9月13日に両プロジェクトの公開文書を確認した結果である。バージョンの差が生じた日付や理由を確定したものではなく、実機で対応可否を試験した結果でもない。導入時には、取得するコードの版と、その版が指定する環境を合わせる必要がある。
cutile-rsの対応GPUの説明も、単に「新しいCUDAが必要」と読むと条件を取り違える。sm_100以降はCUDA 13.1以降で対応し、sm_8xは13.2で加わった。13.3ではsm_90が加わり、sm_80以降をカバーする。これらはGPUの計算機能を示すアーキテクチャ番号である。
安定版Rustで始められる点ではcutile-rsの負担が小さい。ただし、手元のGPUに対応するCUDA環境があるかは別途確認が要る。一方のcuda-oxideは、Rustのツールチェーンに加えてclangとlibclangの開発用ヘッダーなども必要になる。プログラムの書きやすさと、環境をそろえる手間は分けて評価したい。
性能研究が示したことと、まだ任せられないこと
cuTile Rustの安全な記述は、GPU性能をどこまで保てるのか。Melih Elibol氏らのプレプリント「Fearless Concurrency on the GPU」は、B200上の行列積で、その設計を評価している。CUDA Rust全体の速さを一括して測った研究ではない。
論文の安全性オーバーヘッド評価では、DGX B200の単一GPUを使い、半精度浮動小数点の行列積を測定した。行列の各次元が8,192の条件で、cuTile Rustは2.07 PFLOPSに達し、cuBLASの96.4%となった。同じ処理順序で生ポインタを使うunsafe版との差は0.3%以内だったという。
測定ではSMクロックを固定し、行列サイズごとにタイルを調整している。初回のJITコンパイル費用も定常実行の性能とは別に扱う。著者らの結果が支えるのは、こうした条件で安全性を確保する仕組みの追加負担が小さかったという評価であり、すべての処理でRustが同じ性能を出すという保証ではない。
実用に近い例として挙がるのが、Hugging FaceのGroutだ。Qwen3向けの推論を試す実験用エンジンで、cuTile Rustで書いたカーネルを使う。ただし、線形射影の行列計算にはcuBLASを利用する。Rustからの呼び出しにはcudarcを用いており、GPU計算のすべてを独自のRustカーネルへ置き換えた構成ではない。
また、論文はGroutのAttentionや演算をまとめた正規化処理で、チェックを省いたアクセスや生ポインタを使うと説明する。単純な演算では安全なAPIを使い、まだ表現しきれない処理では開発者が責任を引き受ける。実際の推論エンジンに組み込めたことと、全経路を安全なRustだけで書けることには距離がある。
NVIDIAはCUDA Rustの成熟化を2027年以降も進める方針で、正式版の提供日を示してはいない。採用を考える開発者にとっては、必要な演算を安全なAPIで表現できるか、残るunsafe部分を検証できるか、そして使用するGPUとツールチェーンを固定して試せるかが判断材料になる。その条件がそろえば、CPU側とGPU側をまたぐデータ管理をRustでつなぐ効果を、自分の処理で確かめられる。
