【geek-terminalニュース】CUDA RustでGPUカーネル開発はC++職人芸から変わるのか

以前お伝えしたcuda-oxide実験公開の続報です。今回は単なるRust製CUDA周辺ツールではなく、NVIDIAが2026年9月8日に公式ブログで発表した「CUDA Rust」として、GPUカーネルそのものをRustで書く2つの道筋が提示されました。ポイントは、AI高速化の足回りであるGPUカーネル実装に、Rustの所有権、借用、型による制約を持ち込み、C++/CUDA職人芸に依存していた危険な低レイヤ実装をどこまでコンパイル時に制御できるかです。

【事象の全貌と背景】
NVIDIAの公式説明によれば、CUDA C++とCUDA Pythonはすでに成熟したエンタープライズ級ツールチェーンです。一方でRustは、AIシステムの周辺層で存在感を増しています。NVIDIAはNova Linux driverがRustで書かれ、NVIDIA DynamoがRust coreを持ち、NVTXにRust bindingsがあることを挙げ、Rust利用がAIインフラ側へ広がっている流れを示しています。

ただし従来のRustとCUDAの組み合わせには大きな断絶がありました。RustからCUDAカーネルを起動することはできても、肝心のカーネル本体はCUDA C++など別言語で書くことが多い。つまり、ホスト側はRustで安全に書けるのに、最も危険で性能に直結するdevice側に入った瞬間、別ファイル、別コンパイラ、FFI、型のズレ、バッファaliasing、launch設定ミスといった落とし穴が復活する。このギャップを閉じる試みとして出てきたのがCUDA Rustです。

NVIDIAはCUDA Rustを2系統で提示しました。1つ目はSIMT向けのcuda-oxide。CUDA C++と同じく「1スレッドが何をするか」を書き、それを多数起動するモデルです。2つ目はTile向けのcutile-rs。こちらは「1つのデータタイルが何をするか」を書き、実際のスレッド割り当てやメモリレイアウトをコンパイラに任せるモデルです。NVIDIA自身は、まずTileを検討し、より細かいスレッド制御やメモリ制御が必要な場合にSIMTへ下りる考え方を示しています。

【技術的ディープダイブ】
cuda-oxideはカスタムrustc codegenバックエンドです。#[kernel]関数をRust MIRからPliron IR、LLVM IR、PTXへ下げ、それ以外の通常コードは標準バックエンドへ渡す構成だと公式に説明されています。利用要件はLinux、Compute Capability 8.0以上のGPU、CUDA Toolkit 12.x以上、clangとlibclang headers、固定nightly toolchainです。cargo oxide doctorで環境を確認できるものの、現時点ではearly alphaであり、本番投入できる成熟度ではありません。

安全性の肝は、GPUカーネルの危険をRustの型に翻訳する点です。公式例では、入力aとbは共有スライス、出力cはDisjointSliceとして扱われます。これは各スレッドが自分の要素だけへ排他的に書き込むことを型として表す仕組みです。thread::index_1d()はただの整数ではなく専用index型を返し、c.get_mut(idx)はOptionを返します。範囲外アクセスが後から謎のメモリエラーとして爆発するのではなく、Rust側の制御フローとして扱われるわけです。さらに#[launch_contract]で1次元インデックスや256-thread blockなどの契約を宣言し、prepare_vecaddがLaunchConfig1Dを契約と実デバイス制限に照らして検証したうえでsafeな起動に必要な証明を渡します。

cutile-rsは別アプローチです。スカラー単位ではなくタイル単位で計算を書き、各tile blockはsub-tensor上で単一の論理スレッドのようにカーネル本体を1回実行します。実際に何本のGPUスレッドで支えるかはコンパイラが決めます。#[cutile::module] macroはカーネルASTをホストバイナリに埋め込み、初回利用時にCUDA Tile IRを通じてJITコンパイルします。要件はCompute Capability 8.0以上、CUDA 13.3、stable Rust 1.89以上、Linuxで、nightlyや独自LLVMを不要とする点がcuda-oxideより扱いやすい部分です。

Tile側では.partition([128])が128要素chunkごとの排他的所有権を与え、1024要素なら1024/128=8 tilesのgridを構成する例が示されています。形状指定の-1はサイズではなくsentinelで、起動時にtensorから次元を読み取るため、形状変更のたびに再コンパイルしなくてよいと説明されています。公式記事は、SIMT例で出力バッファを入力にも渡すとRustのE0502で失敗し、Tile例で同種のaliasingをするとE0382で失敗することを示しています。ここが今回のギーク刺さりポイントです。GPU並行実行でありがちな「読んでいるものに同時に書いてしまう」事故を、後日のデバッグではなくコンパイル時エラーに変えようとしている。

【コミュニティの生々しい熱量と議論】
Redditのr/rustでは、まず「これはbindingではなく、RustコードをPTXへ直接変換するrustc backendだ」という理解に反応が集まっていました。単なるCUDAラッパーではなく、kernelをRustで書ける点が刺さっています。一方で、あるユーザーは個人テストとして「Blackwellでraw CUDA/cuBLAS比58-60% SoL」と述べつつ、まだ最適化中で新しいため情報は少ないと断っています。これは公式ベンチではないため事実としては扱えませんが、現場感としては重要です。期待はあるが、最速職人芸のCUDAを即置き換えるというより、Triton的に移植性や書きやすさを狙うものではないか、という見方です。

r/linux側では温度が違います。「GPU computeのvendor lock-inは馬鹿げている」「NVIDIAにとっては最高だ」といったCUDA支配への反発が強く出ています。「CUDAが速いのは数学をGPUでやっているだけではないか」という単純化に対し、別ユーザーは「CUDA compiler toolchainの一部はproprietaryで、NVIDIAだけが最適化を知っている」と反論しています。つまりCUDA RustはRust界隈から見ると安全なGPU開発の突破口ですが、Linux界隈から見るとNVIDIAロックインをさらに気持ちよくする装置にも見える。

Hacker Newsではcuda-oxideについて、既存のcudarcとの関係、kernelはCUDAでhostはRustという分離の痛み、byte serializationやFFIの面倒さが論点になっています。短い反応では「writing GPU kernels is inherently unsafe」という冷めた見方もあり、Rustなら全部安全になるという話ではない、shared memory、warp primitive、tensor coreのような領域までどう扱うのかという疑問が残ります。cuTile Rust側では、Tritonとの差分としてRust ownershipによるsafety、Rustエコシステム統合、CUDA graphやasyncまで含むhost-side tensor APIが挙げられています。ただしNVIDIA専用Tile IRである以上、ROCm、Vulkan、Metal、OpenCLには別backendが必要という冷静な指摘もあります。

lobste.rsでは「kernel launchesのunsafeを避けられる」「いずれRust版Thrustのようなものにつながるかもしれない」という期待がある一方、「GPU利用は何でもvibecodingではない」という実務寄りの反応も出ています。全体として、歓迎派はhost/device struct共有、C++/CUDAファイル分離の解消、FFIミス削減に熱を上げ、懐疑派はNVIDIA lock-in、proprietary最適化、安全化できる範囲の限界、公式文書のPR臭を突いている構図です。

【今後の展望とエコシステムへの影響】
ここでオワコン化する可能性があるのは、CUDA C++そのものではありません。少なくともNVIDIAはCUDA C++とCUDA Pythonを成熟ツールチェーンと位置づけ、CUDA Rustを2027年以降にかけて成長させる方針だと述べています。むしろ消えていくかもしれないのは、RustアプリからGPUを使うたびに別言語kernel、薄いbinding、手作業のlaunch整合性、祈りのFFIでつなぐ開発スタイルです。

AI推論エンジン、量子化kernel、attention最適化、KV cache操作、tensor変換のような足回りでは、メモリ安全性と性能チューニングが常に衝突します。cutile-rsがすでにcrates.ioで公開され、Hugging FaceのGrout inference engineやmistral.rsで使われているという公式情報は、この話が単なる研究デモではなく、ローカルLLMや推論基盤の実装者に届く可能性を示しています。ただし公式にも、両プロジェクトはproduction-readyではなく、cuda-oxideはearly alpha、cutile-rsもcoverageは不完全でAPIは変わり得ると明記されています。

短期的には、CUDA Rustは最速kernel職人を置き換える銀の弾丸ではありません。むしろ、危険な低レイヤGPUコードをRustの型システムへ少しずつ持ち上げ、間違ったaliasingやlaunch契約違反をコンパイル時に潰すための土台です。長期的には、AI高速化の主戦場が「C++/CUDAを読める一部の人だけが触れる黒魔術」から、「Rust crate、型、所有権、JIT Tile compilerを組み合わせる普通のソフトウェア工学」へ寄っていくかもしれません。GPUカーネル開発が簡単になるというより、壊れ方がまともになる。そこに今回のCUDA Rustの本当のインパクトがあります。