ハクソク

世界を動かす技術を、日本語で。

Nvidia、RustによるネイティブGPUプログラミングを発表

2026年9月16日原文(developer.nvidia.com)

概要

  • 2026年9月、 NVIDIA が RustによるGPUネイティブプログラミング への本格対応を発表
  • CUDA Rust の成熟と普及を2027年以降も推進
  • AIシステム層 でRust採用が加速、NVIDIAもその流れに参加
  • SIMT と Tile の2種類のRust向けGPUプログラミングモデル
  • CUDA Rustにより GPUカーネルをRustで記述・PTXへネイティブ変換 が可能

NVIDIAによるRustネイティブGPUプログラミング推進

  • CUDA C++ や CUDA Python は既に企業レベルで成熟したツールチェーン
  • CUDA Rust は今後さらに成長・成熟予定
  • AIシステム層（推論エンジン、サービング基盤、ドライバ、エージェントランタイムなど）は、モデルや手法の変化に合わせて絶えず進化
  • Rustは コンパイル時にバグを検出 でき、性能も犠牲にしないため採用が拡大
  • NVIDIAも同様の理由でRustを採用
    • Nova Linuxドライバ はRustで記述
    • NVIDIA Dynamo はRustコアを採用
    • NVTX はRustバインディングを提供
  • GPUカーネルのみは例外で、従来は他言語で記述する必要があったが、 CUDA Rust によりRustで直接GPUカーネル記述が可能に

RustによるGPUカーネル開発（SIMTトラック：cuda-oxide）

  • SIMT （Single Instruction, Multiple Threads）は従来のCUDA C++やnumba-cudaと同様のスレッドモデル
    • 1つのスレッドの処理を記述し、数千のスレッドを一斉に実行
  • cuda-oxide はRust専用のコード生成バックエンド
    • #[kernel]属性関数をRust MIR→Pliron IR→LLVM IR→PTXへ変換
    • GPU用の独自ダイアレクトを採用し、Rustで変換処理を完結
  • 利用要件
    • Linux、Compute Capability 8.0以上のGPU、CUDA Toolkit 12.x以上、clang（libclangヘッダ含む）、nightlyツールチェーン
  • プロジェクト作成・実行手順
    • cargo oxide newでテンプレート作成
    • cargo oxide runでビルド・実行（初回はバックエンドビルドに時間がかかる）
  • コード特徴
    • ホスト・デバイスコードが1ファイルに共存
    • kernel関数のシグネチャが安全性を担保
      • a, bは全スレッドで共有読み取り
      • cはDisjointSlice型で、各スレッドが独占的に1要素だけ書き込み可能
    • thread::index_1d()によりインデックス型を返し、c.get_mut(idx)で境界外アクセスをOptionで安全に処理
    • #[launch_contract]でカーネルのインデックス・スレッド数などを宣言し、LaunchConfig1Dと照合
    • 契約未指定カーネルはunsafeなローンチのみ

RustによるGPUカーネル開発（Tileトラック：cutile-rs）

  • Tileモデル はスカラーではなくタイル（サブテンソル）単位で計算
    • 各タイルブロックが1つの論理スレッドとしてサブテンソルを処理
    • 実際のGPUスレッド割り当てはコンパイラが最適化
  • cutile-rs はTileモデル向けRustフレームワーク
    • #[cutile::module]でカーネルASTをホストバイナリに埋め込み、初回実行時にJITコンパイル
  • 利用要件
    • Compute Capability 8.0以上のGPU、CUDA 13.3、Rust 1.89以上、Linux（nightlyやLLVM不要）
  • コード特徴
    • 出力テンソル（z）はpartition([128])で128要素ごとの排他的所有権を各タイルに付与
    • -1は動的次元のセンチネルで、実行時のテンソル形状に対応
    • .partition([128])で排他性・グリッド形状・B（タイル幅）指定を同時に実現
    • カーネルローンチャはマクロ生成で、テンソル所有権を受け渡し、出力のみ抜き出し
    • .sync_on(&stream)まで全て遅延評価で記録され、最後に一括で同期・実行

メモリ安全性とコンパイラによるバグ防止

  • SIMTカーネル も Tileカーネル も、入力は共有・出力は排他所有を保証
  • Rustの型システムにより、同じバッファの同時可変・不変借用がコンパイルエラー
    • 例：出力バッファc_devを入力としても渡すとエラー
  • これにより、並列アクセスによる競合・再現困難なバグを未然に防止

まとめと今後の展望

  • CUDA Rust の登場で、GPUカーネルも含めた エンドツーエンドのRust開発 が可能に
  • SIMT と Tile、2つのプログラミングモデルを用途・既存スタックに応じて選択
  • 今後は 他言語との相互運用 も計画され、柔軟な開発が可能
  • Rustの 安全性・性能・記述性 を活かしたGPUプログラミングの新時代

Hackerたちの意見

これが安定したら試すのが楽しみ！今はWGPUをグラフィックスに使ってて、CUDAにはcudarcを使ってるよ。注意点：Cuda-oxideはCudarcのホストコンポーネントに似てるけど、Rustスタイルのカーネル方言を使ってる。メリットは、ホストとデバイス間で構造体を共有できること。デメリットは、標準のCUDAカーネルを新しいWIP方言に置き換えることになる。まだタイルAPIは試してないけど、楽しみにしてる。最後にチェックしたときは、Cuda OxideはLinux専用で、Asyncが必要だったから、まだ試してないんだ。

└

cudarcは僕にとってすごく良いよ。既存の例やリファレンスを調べるのが簡単だし、見ているものと1対1でマッピングされるからね。CUDA自体で既に苦労してるから、方言があると以前の作業に頼るのがちょっと難しくなる。でも、全体的にはcudarcと比べて、両方のアプローチがよりエルゴノミックに感じるし、ビルドインフラや環境の調整が少なくて済むのは素晴らしい。

NVIDIAがhuggingfaceを買収したから、huggingfaceの優れたCandle [1]クレートがRustでの推論に使えるのは、素晴らしいステップだと思う。 [1] https://github.com/huggingface/candle

└

カーネルがRustで書かれてるかどうかなんて誰も気にしないよ。カーネルはCで書くのが本来の目的だけど、もっと高レベルなものを使いたいなら、Tritonとか、タイルサイズをうまく抽象化してくれるDSLを試してみればいい。

発表は信頼されるのではなく、確認されている。マジで、Nvidiaが完全にClaudeが書いた記事を出してるなんて。

└

心配しなくても大丈夫、彼らには「AI生成の要約」ボックスもあるから。

└

ありがとう、数分節約できたよ。

└

それは本当に素晴らしい観察だね。鋭い目を持ってるだけじゃなくて、訓練された素晴らしい頭脳もあるってことだ。

└

それにNvidiaも なんで「それにNvidiaも」なの？彼らは基本的にすべてにAIを使うことを全面的に支持してるよ。次は何？「マジで、マクドナルドまで不健康な食べ物を出してる」

└

Nvidiaの社員はあまり気にしてない印象があるな。1年以上前から、彼らの小さなプロジェクトの中で完全にAIが書いた「ドキュメント」を見始めたから（つまり、ちょっとでも良いアイデアになる前から）。

└

それが君の正直な負荷評価なの？

└

記事を読んでなかったから、このコメントを読んだとき、NVIDIAがこのライブラリはチェックしたけど、完全にLLM生成だから信頼してないって言ってるのかと思った。

Hacker Newsで議論の続きを見る