CUDA Rust：AI 翻譯 24 個 GPU Operator，99.5% 效能代表什麼？（2026）

2026 年 9 月 16 日，NVIDIA 在 Technical Blog 發布〈Translating CUDA Tile Operations from Python to Rust Using Agentic AI〉，把 9 月 8 日剛公開的 CUDA Rust 推進到更大膽的一步：讓 AI Agent 轉譯整套 GPU 算子，再以中介表示（IR）、正確性測試與效能門檻逐關驗收。

先講結論：NVIDIA 報告的是一個很有價值的工程方向，但還不是「Rust 已經無痛取代 CUDA Python」的證明。官方在 DGX B200 上量到 24 個 Operator、約 40 個 Kernel 的平均效能達 cuTile Python 的 99.5%；可是這是 NVIDIA 自己的裝置端測量，公開主分支目前只能直接檢視 5 個 cuTile Rust Operator，尚不足以讓外部重建整組結果。真正值得記住的突破，是「共用 IR＋有界 Agent 流程＋機器可判定閘門」這套翻譯系統。

這不是把 Python 語法逐行改成 Rust

這項工作的關鍵，不是 Agent 比人更會改語法，而是 cuTile Python、Triton-TileIR 與 cuTile Rust 最後都進入同一個 cuda_tile dialect，再交給同一套 NVIDIA 編譯器後端。因此，轉譯目標不是重新發明一個更快的演算法，而是讓 Rust 版本保留參考 Kernel 的記憶體操作、Tile 形狀、Reduce 軸與特殊化條件。

“The shared IR makes translation checkable.”

中文：共用 IR 讓轉譯變成可檢查的工作。

NVIDIA Technical Blog

這句話比「AI 自動寫 GPU 程式」重要得多。一般程式測試只能回答幾組輸入有沒有得到正確輸出；IR diff 還能抓出「測試剛好沒撞到」的結構錯誤，例如 Reduce 用錯軸、遮罩遺失，或記憶體操作換成成本不同的版本。只要兩端真的共享同一種 IR，Agent 產生的程式就多了一個比自然語言 Review 更硬的比較基準。

Agent 流程的重點，是限制權力而不是增加角色

NVIDIA 把一次轉譯拆成數個責任邊界：Analyzer 先輸出變體、dtype、容許誤差、Launch grid 與參考 IR；Kernel Writer 只負責 Rust Kernel；Host／FFI Builder 再接上 C ABI、Python Wrapper 與完整測試；Performance Validator 最後用相同 GPU 配對比較。遇到正確性或效能異常時，診斷角色讀 IR 找責任歸屬，但不能直接改程式。

“Subagents communicate only through artifacts with fixed schemas, never through conversation.”

中文：子 Agent 只透過固定 Schema 的產物溝通，不靠彼此對話。

NVIDIA Technical Blog

這裡的設計原則很清楚：把 LLM 當成會犯錯的轉換器，而不是最後裁判。每一階段只能交付約定好的檔案，Validator 以 Exit code 與結構化 Verdict 決定下一步，整個 Loop 又有硬性的重試上限。這和一般「叫第二個 Agent 幫第一個 Agent 看一下」不同；前者可以留下可追蹤、可重跑的證據鏈，後者很容易只是兩個模型互相說服。

同時要注意證據邊界：截至 2026 年 9 月 18 日，原文沒有公布實際執行 24 次轉譯時的模型與版本、Prompt、總工時、人工介入量、首次成功率或逐次 Trace。「Token 成本約減半」也沒有公開絕對數字與 Baseline，所以本文不把它當成已驗證的效率成果。公開 Skill 的 BENCHMARK.md 評的是 4 個路由、啟用與安全任務，也不能替代 24 個 Kernel 的端到端轉譯紀錄。

Rust 的安全性有幫助，但邊界比標題小

cuTile Rust 想解決的是 GPU Kernel 常見的一類錯誤：把可變輸出切成互不重疊的 Partition，讓 Rust Ownership 在 Launch 前就阻止重複可變借用；Tile 模型也把執行緒索引與 Shared memory 等細節交給編譯器。在程式留在安全 API、Launcher 正確維持 Partition 與生命週期的前提下，這能把部分越界、別名與資料競爭，從難重現的執行期 Bug 提前成編譯期錯誤；它不是對整個實作「不可能有 Bug」的保證。

但「用 Rust」不等於整條 GPU 路徑都安全。NVIDIA 在 9 月 16 日原文中明說，為了完全重現參考 IR，有些已轉換 Kernel 仍必須使用 Unchecked API，團隊還在把它們搬到安全介面。C ABI 邊界也要處理 Raw pointer、外部 Stream 與 Tensor descriptor；截至 9 月 18 日，TileGym 公開主分支可見的 5 個 Kernel 目錄，入口目前都包含 unsafe fn。這不代表 Rust 安全模型無效，而是它只保護被安全型別與契約包住的區域。

“Both projects are early-stage and neither is production-ready.”

中文：兩個專案都還在早期階段，尚未達到正式生產可用。

NVIDIA CUDA Rust 發布文

NVIDIA 自己的 9 月 8 日發布文已經把成熟度講得很直白：API 仍會變動，覆蓋率也不完整。因此，現階段最合理的定位是實驗性基礎設施，而不是立刻改寫生產環境中的所有 CUDA Kernel。

也別把這次發布寫成「Rust 第一次能寫 GPU」。NVIDIA 自己列出 rust-cuda、rust-gpu 與 CubeCL 等先行專案；多個 Front end 匯入共同 IR 也早有 MLIR 等工程脈絡。這次真正的新意，是 NVIDIA 把 Rust Ownership、CUDA Tile IR 與一條有界的 Agent 驗證流水線組合起來，並給出一組供應商規模測試。

99.5% 到底量了什麼？

官方方法是在 NVIDIA DGX B200 上，對 24 個 Operator 的 347 組設定逐一配對 cuTile Python 與 cuTile Rust，使用 CUPTI 記錄 Device time，每組取 4 次 CI Run 中的最佳值，再算幾何平均。結果是 0.995，且 NVIDIA 表示全部 Operator 都高於 0.95 的驗收線。

三位作者 Yinuo Liu、Melih Elibol 與 Dheemanth Manur 都是 NVIDIA 技術人員。這讓文章成為架構與產品狀態的一手資料，也意味著成功率、效能與「無人值守」應視為供應商自評，而不是獨立 Benchmark。

這個數字能支持一個窄而有用的結論：在相同 IR 與編譯器後端下，忠實翻譯的 Rust Kernel 可以接近 Python Front end 產生的 Kernel 效能。它不能直接證明整個應用程式快 99.5%、移植成本已回本，或安全性問題已消失。Device time 排除了 Host、首次 JIT、Wrapper 與排程成本；而「4 次取最佳」描述的是理想 Kernel 執行，不是使用者感受到的 P50 或 P99 延遲。

公開證據檢查：亮點成立，但證據鏈還沒閉合

以下稽核以 2026 年 9 月 18 日的 NVIDIA 原文與 TileGym 公開主分支為準；「還缺什麼」只描述這批公開材料，不推論 NVIDIA 內部沒有相關紀錄。

主張	目前能確認什麼	還缺什麼
24 個 Operator、約 40 個 Kernel 已轉譯	NVIDIA 原文與圖表明確如此報告	公開主分支目前只有 5 個 cuTile Rust Operator 目錄，未見完整 24 項產物與逐項 CI Log
平均效能是 cuTile Python 的 99.5%	官方交代 B200、347 組配對、CUPTI Device time 與 4 次取最佳	缺少可下載原始資料、完整 Run Log 與第三方重跑；也不是端到端 Wall-clock 結果
Agent 流程可重複執行	Skill、角色說明、Validator 與範例已公開	公開的 Skill Benchmark 是 4 個路由／啟用任務，不是 24 個 Kernel 轉譯的完整重現紀錄
Rust 帶來記憶體安全	Ownership 與 Partition API 能在安全介面內擋下一類別名錯誤	Unchecked API、Unsafe entry、FFI 與編譯器正確性仍在信任邊界內

這也是為什麼社群熱度不能拿來替結果背書。9 月中在 Hacker News 爆量討論的連結指向 9 月 8 日的 CUDA Rust 發布文，不是 9 月 16 日這篇 Agent 轉譯實驗。它證明大家很在意「Rust 能不能進入 CUDA」，不等於大家已經獨立驗證 24 個 Operator 的成績。

AlphaLab 的判斷：真正的護城河是可驗證的翻譯

我同意 NVIDIA 的部分：當來源與目標 Front end 共享 IR 時，Agent 不必憑感覺重寫演算法；把 IR diff、數值測試、效能閘門與有限重試串起來，確實能把大型移植從一次性手工藝，變成較可管理的工程流程。這個想法甚至比 CUDA Rust 本身更能外溢到編譯器遷移、API 升級與跨語言 Porting。

我保留的部分：99.5% 目前仍是供應商在單一 Blackwell 系統上、以 Device time 計算的結果；「24 個全數完成」也尚未在目前公開主分支形成可從頭重跑的證據鏈。Rust 可以縮小一部分錯誤面，但 Unchecked API、FFI、驅動與編譯器仍可能出錯。把這些限制寫清楚，不會削弱成果，反而能讓團隊知道哪一段已經被機器驗證、哪一段仍靠信任。

如果你負責 AI 基礎設施，現在可以怎麼做？

1. 只挑一個邊界清楚的 Operator 試點：先選輸入形狀、dtype 與正確性基準完整的 Kernel，不要一次搬整個模型。
2. 固定版本與硬體：鎖定 TileGym、cutile-rs、CUDA、Driver 與 GPU 型號，保留每次 Run 的 Commit SHA。
3. 把 IR 當成合約：除了數值輸出，也比較 Memory op、Tile shape、Reduce 軸、Mask 與 Specialization；任何例外都要有可讀理由。
4. 同時量 Device 與 Wall-clock：前者看 Kernel 忠實度，後者才看 JIT、Host、FFI 與 Wrapper 是否真的值得。
5. 建立 Unsafe 清單與回退路徑：逐項標出 Raw pointer、Unchecked API、FFI 與所有權假設；驗收不過就保留 Python Backend。

最適合現在投入的，是已經有大量自訂 CUDA／Triton Kernel、又有能力維護 Compiler 與效能測試的團隊。只是想讓一般 Python 推論更快的產品團隊，短期內更值得先用成熟框架、Profiler 與既有 Kernel Library，而不是為了 Rust 重新建立整套 GPU Toolchain。