NVIDIA 宣佈推出 CUDA Rust：透過 SIMT 與 Tile 軌道在 Rust 中編寫原生 GPU 核心

TL;DR – NVIDIA 的 CUDA Rust 讓您可以直接使用 Rust 編寫 GPU 核心，並提供兩種不同的程式設計模型（透過 cuda‑oxide 的 SIMT 與透過 cutile‑rs 的 Tile），這些模型可編譯為 PTX 並提供編譯時期的安全性保證。

為何原生 Rust GPU 核心如此重要

Rust 的所有權與型別系統能在編譯時期捕捉各類記憶體安全錯誤，這是傳統 CUDA C++ 核心所缺乏的特性。
NVIDIA 的驅動程式堆疊已逐漸轉向 Rust（Nova Linux 驅動程式、Dynamo 核心、NVTX 綁定）。將 Rust 擴展至核心層完成了該語言的覆蓋範圍。
開發人員現在可以從 Rust 啟動核心，並直接以 Rust 編寫核心程式碼，無需再使用外語封裝器。

兩種軌道對應 CUDA 自身的模型

1. SIMT 軌道 – cuda‑oxide

模型：傳統的單指令多執行緒 (SIMT) 程式設計，與 CUDA C++ 或 numba‑cuda 相同。
工具鏈：自訂的 rustc 程式碼生成後端，將 #[kernel] 函式透過 Rust MIR → Pliron IR → LLVM IR → PTX 進行路由。
需求：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

模型：Tile 層級抽象，其中 tile 是對子張量進行運算的邏輯執行緒；編譯器決定每個 tile 背後有多少實體 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])) 給予每個 tile 獨佔的可變所有權，無需特殊的 DisjointSlice 型別。
- 動態維度在型別簽章中以 -1 表示；實際大小在啟動時解析，允許在不重新編譯的情況下使用靈活的形狀。
- 啟動器 (kernel::add) 會消耗張量，將其作為元組回傳，並僅在呼叫 .sync_on(&stream) 時執行，使整個程式成為一個原子執行的延遲描述。

編譯器自動捕捉的內容

無別名保證 – 兩種軌道都會拒絕在沒有適當獨佔性的情況下讀取與寫入同一個緩衝區的核心，並在編譯時期顯示錯誤，例如「無法借用為可變，因為它同時被借用為不可變」(SIMT) 或「使用了已移動的值」(Tile)。
執行緒索引安全性 – 在 SIMT 中，thread::index_1d() 回傳一個型別化的索引；越界存取會變成明確的 Option 分支，而不是未定義的記憶體讀取。
啟動時期驗證 – #[launch_contract] 強制要求提供的 LaunchConfig 符合核心宣告的幾何結構與裝置限制，將常見的執行時期崩潰來源轉變為編譯時期檢查。

專案成熟度與生態系統定位

cuda‑oxide – 早期 Alpha 版本；需要 nightly 工具鏈且僅限 Linux。提供了一條基於 MIR 的低階路徑，保持與 CUDA 現有 PTX 管線的緊密聯繫。
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，或參加 Melih Elibol 在 RustConf 2026 的演講。

社群反應（精選 HN 評論）

"啟動過程是經過檢查而非信任的。該死，連 Nvidia 都在發佈完全由 Claude 撰寫的文章。" – claiir

"一直在等這樣的東西。CUDA C++ 很痛苦；Rust 的核心程式設計安全性可能會改變遊戲規則。" – Driftbench

"既然 NVIDIA 現在擁有 HuggingFace，而 HuggingFace 有出色的 Candle crate 用於 Rust 推論，這似乎是邁向優秀原生 Rust 核心的好一步。" – dllu

"我非常不喜歡 CUDA……程式設計 GPU 的最佳方式是在單獨的檔案中編寫核心並手動啟動它們，就像在 Metal、OpenCL 和 D3D12 中一樣。" – jacobgorm (指出了一種哲學上的替代方案)。

展望

NVIDIA 的 CUDA Rust 計畫標誌著一項策略性推動，旨在將 Rust 的安全性保證帶入 GPU 堆疊，首先透過兩條互補的軌道，分別滿足低階控制 (SIMT) 與高階抽象 (Tile) 的需求。雖然工具鏈尚處於早期階段，但這些專案已被用於生產級的 Rust 推論引擎，顯示出快速成熟的路徑。隨著 API 的穩定，開發人員可以期待在完全使用 Rust 編寫高效能 GPU 核心時，獲得更順暢、更安全的體驗。