[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-cuda-oxide-rust-ptx-kernels-zh":3,"article-related-cuda-oxide-rust-ptx-kernels-zh":30,"series-tools-dd0deb29-30f9-47af-91a1-dc966fff3fa2":83},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"dd0deb29-30f9-47af-91a1-dc966fff3fa2","cuda-oxide-rust-ptx-kernels-zh","cuda-oxide 把 Rust 變成 PTX 核心","\u003Cp data-speakable=\"summary\">我拆 \u003Ca href=\"\u002Ftag\u002Fcuda\">cuda\u003C\u002Fa>-oxide 的 \u003Ca href=\"\u002Ftag\u002Frust\">Rust\u003C\u002Fa> 轉 PTX 做法，最後給你一份可直接改的 \u003Ca href=\"\u002Ftag\u002Fgpu\">GPU\u003C\u002Fa> Rust 模板。\u003C\u002Fp>\u003Cp>我用 GPU 工具鏈很久了，真的很少看到哪個方案會讓我一開始就放心。通常都是這樣：主程式是 Rust，device 端又跑去另一套語言，launch 還要再包一層，最後你花半天只是在追一個「CPU 上能編、進 kernel 就壞掉」的型別問題。最煩的是，程式明明是你寫的，到了 GPU 那一段卻像借來的。\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\">cuda-oxide\u003C\u002Fa> 讓我停下來看，不是因為它很華麗，而是因為它想把這條討厭的縫補起來。我先懷疑，反而覺得它比較像真的東西。\u003C\u002Fp>\u003Cp>我會注意到它，主要是因為它不是再丟一個「Rust 包裝 CUDA」的小把戲。它想做的是把標準 Rust 直接編到 PTX，host 跟 device 還放在同一個 workspace 裡，整條路徑都走 Rust-native。這種東西我通常第一反應是：你先別急著吹，先把邊界講清楚。好消息是，這個專案自己也沒裝成熟，README 直接說它還在 alpha，\u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> 會變。老實講，我比較喜歡這種誠實。\u003C\u002Fp>\u003Cp>觸發我整理這份拆解的來源，就是 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\">NVlabs\u002Fcuda-oxide 的 GitHub 倉庫\u003C\u002Fa>，還有它正在寫的 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\u002Ftree\u002Fmain\u002Fcuda-oxide-book\">cuda-oxide book\u003C\u002Fa>。我下面拆的不是新聞，是我把它的 README、目錄結構、工具鏈說明，整理成開發者真的能拿去試的版本。\u003C\u002Fp>\u003Ch2>我先在意的不是語法，是那條討厭的分裂線\u003C\u002Fh2>\u003Cblockquote>single-source compilation：host 和 device code 放在同一個檔案，透過一次 cargo oxide build 一起處理\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：它不想讓你一邊寫主程式、一邊再養一個 GPU 子世界。你不用把 host crate、device crate、wrapper crate 三個東西拆開來互相餵資料。cuda-oxide 想把這些東西收回同一個 Rust workspace，然後把 device 端編成 PTX。這件事看起來很小，但其實很狠，因為它直接砍掉我最常踩到的那條線。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781110154542-ttd2.png\" alt=\"cuda-oxide 把 Rust 變成 PTX 核心\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前做 GPU 專案最常卡住的地方，不是 kernel 算法，而是「語言邊界」本身。型別在 CPU 端很漂亮，一跨過去就變另一種生物；錯誤訊息還會假裝自己很有幫助，結果只是把你丟回 FFI、build script、macro 地獄。那種感覺很像你明明在寫同一個功能，卻得同時維護兩個思考\u003Ca href=\"\u002Fnews\u002Fnvidia-nemotron-3-ultra-open-models-compete-zh\">模型\u003C\u002Fa>。cuda-oxide 這個方向對我來說有吸引力，因為它不是在包裝那條分裂線，它是想把線直接拔掉。\u003C\u002Fp>\u003Cp>實操上我會怎麼看？我不會先問「能不能取代 CUDA」。那太大了，也太容易自我感動。我會先問三件事：第一，host 跟 kernel 能不能在同一個模組裡協作；第二，資料型別跨過去會不會還是你熟悉的 Rust；第三，專案裡是不是有一堆膠水在偷偷吃掉時間。如果答案是後兩個都不漂亮，那再快的 kernel 也救不了整個 repo。\u003C\u002Fp>\u003Cul>\u003Cli>先找「一個 workspace、兩個世界」能不能真的成立。\u003C\u002Fli>\u003Cli>先看型別邊界，不要先看效能數字。\u003C\u002Fli>\u003Cli>如果你團隊最痛的是維護成本，這種整合型工具才有意義。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>#[kernel] 不是噱頭，重點是編譯器真的看得懂\u003C\u002Fh2>\u003Cblockquote>rustc codegen backend：把 \u003Ccode>#[kernel]\u003C\u002Fcode> 函式編成 CUDA PTX\u003C\u002Fblockquote>\u003Cp>也就是說，kernel 不是某種外掛 DSL，也不是「看起來像 Rust 的假語法」。它還是 Rust 函式，只是最後會被編譯器往下轉成 GPU 能跑的 PTX。這差很多。因為只要你真的碰過 GPU 工具鏈，就知道最討厭的不是寫 kernel，而是你得同時記住一堆特殊簽名、特殊 launcher、特殊限制，最後整段程式像在跟編譯器談條件交換。\u003C\u002Fp>\u003Cp>我喜歡 cuda-oxide 的地方，是它把「語法好看」跟「編譯器理解」分開處理。很多工具都很愛做表面功夫：macro 寫得很順、API 看起來很親切，結果一碰到泛型、closure capture、第二個 kernel 變體，整個外殼就裂掉。cuda-oxide 不是那種路線。它的重點是編譯器後端要真的知道怎麼把 Rust 降到 PTX，而不是只靠一些魔術字串撐場面。\u003C\u002Fp>\u003Cp>我之前踩過一個很典型的坑：demo 階段很美，因為只有單一 kernel、固定參數、固定資料流。等你開始加泛型、加 closure、加不同輸入型別，原本說得很漂亮的 macro API 就開始露出破綻。最後你還是得回頭手寫 launch plumbing。這也是為什麼我會把 cuda-oxide 的重點放在「編譯器契約」而不是「macro 手感」。如果你搞不清楚 lowering 規則，後面只會更痛。\u003C\u002Fp>\u003Cp>實操寫法很簡單：先讀它的 kernel 模型，不要先研究花俏功能。你要先知道一個 Rust 函式怎麼變成 PTX、參數怎麼傳、哪些普通 Rust 能保留、哪些不行。能用一句話講清楚這條路徑，再談要不要押專案。講不清楚，就先別碰大規模遷移。\u003C\u002Fp>\u003Cul>\u003Cli>把 kernel 當成「會被編譯器理解的 Rust」，不是外來語法。\u003C\u002Fli>\u003Cli>先測泛型、closure、捕獲變數，再談導入。\u003C\u002Fli>\u003Cli>真正的契約在 compiler backend，不在表層 macro。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>host runtime 才是大多數 GPU 專案真正卡住的地方\u003C\u002Fh2>\u003Cblockquote>host-side runtime：處理記憶體管理、pinned host transfer、kernel launching\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：cuda-oxide 不只想編 kernel，它也想把 host 端那些煩到不行的事一起接走。像是配置 device memory、搬資料、pin host buffer、啟動 kernel，這些東西平常都不會出現在宣傳頁，但真正把專案磨爛的，常常就是這些地方。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781110149083-m8bw.png\" alt=\"cuda-oxide 把 Rust 變成 PTX 核心\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我看它的 crate 切法，像是 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\u002Ftree\u002Fmain\u002Fcrates\u002Fcuda-core\">cuda-core\u003C\u002Fa> 跟 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\u002Ftree\u002Fmain\u002Fcrates\u002Fcuda-async\">cuda-async\u003C\u002Fa>，我會把它理解成：前者偏向\u003Ca href=\"\u002Fnews\u002Fgpu-programming-core-software-skill-zh\">核心\u003C\u002Fa> runtime primitive，後者偏向非同步裝置操作。這個分法有價值，因為它把「我能不能 launch 一個 kernel」跟「我能不能把整條 pipeline 接起來」分開了。很多 GPU 工具卡死就是卡在這裡，demo 可以跑，但只要資料流一多，host orchestration 就變成一坨 callback 和同步點。\u003C\u002Fp>\u003Cp>我以前做過一條 GPU 資料管線，kernel 本身其實沒什麼問題，真的讓人想翻桌的是 host 端。每次傳輸、每次同步、每次 stream 管理都要手工接線，結果整個專案像在拼樂高，但每塊都是自訂規格。這種時候，如果 runtime 層能用 Rust 型別把流程講清楚，價值其實比 kernel 語法還高。因為你不是在追求「能跑」，你是在追求「能維護」。\u003C\u002Fp>\u003Cp>實操上，我會直接拿 host API 當審核重點：能不能不碰 raw FFI 就完成配置、搬運、啟動、取回結果？能不能讓你看得出資料何時在 host，何時在 device？如果答案是否定的，那它只是把複雜性包得比較好看，不是真的少。README 裡提到的 \u003Ccode>CudaContext\u003C\u002Fcode>、\u003Ccode>DeviceBuffer\u003C\u002Fcode>、\u003Ccode>LaunchConfig\u003C\u002Fcode>、typed module loader，我覺得方向是對的，因為 host 端應該像控制平面，不是第二套語言。\u003C\u002Fp>\u003Cul>\u003Cli>先檢查 host API 是否還要你理解太多 CUDA 細節。\u003C\u002Fli>\u003Cli>先看資料搬運流程，再看 kernel launch。\u003C\u002Fli>\u003Cli>runtime 要像控制平面，不要像另一個 FFI 黑盒。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>非同步 GPU 工作如果不順，整個抽象就只是換皮\u003C\u002Fh2>\u003Cblockquote>stream 消失，\u003Ccode>{kernel}_async\u003C\u002Fcode> 回傳 lazy \u003Ccode>DeviceOperation\u003C\u002Fcode>，最後靠 \u003Ccode>.sync()\u003C\u002Fcode> 或 \u003Ccode>.await\u003C\u002Fcode> 觸發\u003C\u002Fblockquote>\u003Cp>也就是說，它不是只想把 PTX 編出來而已，它想讓 GPU 工作變成可以在 Rust 裡組合的延遲運算。這點我很在意。因為同步 demo 很容易寫得漂亮，真正麻煩的是你要同時處理傳輸、launch、後處理，還要把吞吐量撐起來。這時候如果 API 設計不好，你的 stream 會慢慢變成隱性架構，最後每個模組都知道 stream，大家都知道要 sync，但沒人知道為什麼。\u003C\u002Fp>\u003Cp>cuda-oxide 在 async 路線上，明講 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\u002Ftree\u002Fmain\u002Fcrates\u002Fcuda-async\">cuda-async\u003C\u002Fa> 是核心。這種設計我會給過，因為它至少知道複雜性應該被集中處理，而不是散落到每個 kernel 呼叫點。\u003Ccode>DeviceOperation\u003C\u002Fcode> 這種 lazy 物件也很有意思，因為它把 GPU 工作描述成「可組合的待執行步驟」，不是一串硬塞進 stream 的命令。\u003C\u002Fp>\u003Cp>我以前看過太多 GPU 專案，最後最貴的不是算力，是同步點管理。你本來只是想把兩個 kernel 串起來，結果一個 sync 不小心插在中間，整個 pipeline 直接失去重疊效果。更慘的是，程式看起來還是對的，只是慢得很誠實。這也是為什麼我會先測 async，而不是等到最後才碰。因為如果 async 抽象不順，後面所有高階功能都只是更漂亮的包裝紙。\u003C\u002Fp>\u003Cp>實操寫法：先做最小 pipeline，upload、launch、download、驗證，一次跑完。然後看 \u003Ccode>{kernel}_async\u003C\u002Fcode> 能不能自然串接，不要把你逼成 state machine。若它能讓你把多步驟工作寫成可讀的鏈式流程，那才算真的有用。若不行，那就只是 stream 管理換了名字。\u003C\u002Fp>\u003Cul>\u003Cli>先測 async 串接，不要等到專案後期。\u003C\u002Fli>\u003Cli>確認同步邊界清楚，不要藏在抽象裡。\u003C\u002Fli>\u003Cli>看的是可組合性，不只是吞吐量。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>編譯管線才是這專案真正的本體\u003C\u002Fh2>\u003Cblockquote>Rust → Rust MIR → Pliron IR → LLVM IR → PTX\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：這不是一個只賣語法糖的專案，它是在賣編譯器架構。這件事很重要，因為長期能不能維護，通常不是看你今天能不能跑，而是看你中間層怎麼設計。架構亂，後面每個 bug 都會變成尋寶遊戲。\u003C\u002Fp>\u003Cp>README 還提到可以用 \u003Ccode>cargo oxide pipeline vecadd\u003C\u002Fcode> 看完整流程，這種透明度我很買單。因為如果你真的要把它放進專案，你一定會想知道 lowering 在哪裡發生、最佳化在哪裡做、device-specific lowering 又從哪裡開始。沒有這些資訊，出了問題只會一路往下猜，猜到最後人都沒了。\u003C\u002Fp>\u003Cp>我也會特別注意工具鏈限制。專案把 pinned nightly Rust、CUDA Toolkit 12.x+、Clang、LLVM 21 以上這些要求直接講出來，這不算輕鬆，但算務實。GPU 編譯本來就很吃環境，裝得起來不代表能穩定重現。與其假裝你的系統預設都沒問題，不如老實說版本就是要對。這點我反而尊重。\u003C\u002Fp>\u003Cp>實操上，如果你要試，先問團隊能不能接受 pinned nightly、CUDA 安裝、LLVM 版本對齊。如果你們連容器或 Nix shell 都不想碰，那你會很痛苦。相反地，如果你們本來就有固定 GPU build 環境，那這套可能比你現在東拼西湊的流程更乾淨。它還有 \u003Ca href=\"https:\u002F\u002Fnixos.org\u002F\">Nix\u003C\u002Fa> 的 dev shell 方向，這對編譯器專案來說很實際，因為可重現性常常比速度更重要。\u003C\u002Fp>\u003Ch2>它講「安全」，但我會把那個詞前面加一個問號\u003C\u002Fh2>\u003Cblockquote>safe(ish), idiomatic Rust\u003C\u002Fblockquote>\u003Cp>也就是說，它不是在保證 GPU 上一切都絕對安全。它比較像是在說：我盡量保留 Rust 的紀律，但 GPU 上還是有 shared memory、atomic、barrier、warp op 這些硬骨頭。那個 \u003Ccode>ish\u003C\u002Fcode> 很誠實，我反而喜歡。因為只要你真的寫過 GPU，就知道「完全安全」通常只是把鋒利的地方藏起來，不是把問題消掉。\u003C\u002Fp>\u003Cp>README 提到的 device-side 抽象很多，像是 type-safe indexing、shared memory、scoped atomics、barriers、TMA、warp\u002Fcluster ops。這些東西每一個都能讓抽象翻車，所以它敢把硬體層的東西直接列出來，我覺得是好事。像 \u003Ca href=\"https:\u002F\u002Fdocs.nvidia.com\u002Fcuda\u002Farchive\u002F12.0.1\u002Fcuda-c-programming-guide\u002Findex.html\">NVIDIA CUDA Programming Guide\u003C\u002Fa> 裡那些 atomics 和 barriers，本來就不是可以假裝不存在的東西。\u003C\u002Fp>\u003Cp>我待過的 GPU 抽象層很多都犯同一個毛病：把尖角包起來，然後假裝尖角不見了。結果只是把風險搬到別的地方。cuda-oxide 如果能做到的是「減少你出錯的方式」，而不是「讓你完全不可能出錯」，那就\u003Ca href=\"\u002Fnews\u002Fopen-source-llms-beat-gpt4-class-2026-zh\">已經\u003C\u002Fa>很有價值了。GPU 程式的安全感，本來就不是零風險，而是你能不能清楚知道哪裡會炸。\u003C\u002Fp>\u003Cp>實操上，我會把它的安全敘事當成部分保護，不是絕對保證。先讀 SIMT、barrier、atomic 的章節，再拿同步相關的 kernel 做測試。凡是依賴同步的地方，都要補測試。這不是悲觀，這是 GPU 開發的基本禮貌。你要做的不是相信它永遠不錯，而是把錯的空間壓小。\u003C\u002Fp>\u003Cp>它列出的例子像 vector add、generic kernels、device-side \u003Ccode>Ord::cmp\u003C\u002Fcode> lowering、GEMM、Blackwell tensor cores、async pipeline，這些都不是裝飾品。這些例子代表編譯器已經得在真實 GPU 模式上活下來，不然根本撐不起這些範圍。\u003C\u002Fp>\u003Ch2>我會怎麼把它放進自己的 repo\u003C\u002Fh2>\u003Cp>如果是我明天就要試 cuda-oxide，我會照這個順序：先做一個很無聊的 vector add 或 map kernel。先確認 host\u002Fdevice 共用 workspace 是真的順。再測一個帶 closure capture 的泛型 kernel。接著如果我的工作負載需要，再看 async 組合。最後才碰 tensor core、cluster、device FFI 這些比較兇的功能。\u003C\u002Fp>\u003Cp>我不會一開始就挑 repo 裡最炫的例子。那種做法很容易騙自己，以為工具成熟了，其實只是某個 demo 剛好跑過。先從 boring 的東西開始，boring 能跑，後面才有資格談進階功能。這是我看編譯器專案的老習慣，沒這個習慣很容易被展示稿帶走。\u003C\u002Fp>\u003Cp>我也會盯著平台支援。README 明講目前以 Linux 為主，還提到 Ubuntu 24.04。這很正常，但也代表我不會把 macOS 或 Windows 當起點。專案如果老實說它先支援哪裡，我反而比較安心。比起「到處都能跑」這種空話，我更想知道哪裡是它真的測過的地方。\u003C\u002Fp>\u003Cp>另外一個我會查的是，自己的程式到底會不會太依賴現在這套 macro 和 backend 形狀。專案還在 active development，API 變動是可預期的。這沒什麼好裝，實驗期就該這樣。你要分清楚哪些層會 churn：macro、runtime API、還是 lowering internals。這決定你要不要把它放進正式路徑。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># cuda-oxide 導入模板（可直接改成你自己的 repo 筆記）\n\n## 1) 我想解的問題\n我想用 Rust 寫 GPU kernel，並且把 host 與 device code 放在同一個 workspace。\n\n## 2) 第一個驗證目標\n先做一個最無聊的 kernel：\n- vector add\n- map over slice\n- reduction\n\n## 3) 導入前先回答的問題\n- 我能不能把 kernel 寫成一般 Rust 函式，然後用 #[kernel] 標記？\n- host 端能不能不用 raw CUDA FFI 就 launch？\n- 泛型與 closure capture 能不能正常工作？\n- DeviceBuffer 搬資料需不需要額外膠水？\n- async GPU 工作能不能自然串起來，不用手工管 stream？\n\n## 4) 最小 kernel 範本\nuse cuda_device::{cuda_module, kernel, thread, DisjointSlice};\nuse cuda_core::{CudaContext, DeviceBuffer, LaunchConfig};\n\n#[cuda_module]\nmod kernels {\n    use super::*;\n\n    #[kernel]\n    pub fn map\u003CT: Copy, F: Fn(T) -> T>(f: F, input: &[T], mut out: DisjointSlice\u003CT>) {\n        let idx = thread::index_1d();\n        let i = idx.get();\n\n        if let Some(out_elem) = out.get_mut(idx) {\n            *out_elem = f(input[i]);\n        }\n    }\n}\n\nfn main() {\n    let ctx = CudaContext::new(0).unwrap();\n    let stream = ctx.default_stream();\n\n    let data: Vec\u003Cf32> = (0..1024).map(|i| i as f32).collect();\n    let input = DeviceBuffer::from_host(&stream, &data).unwrap();\n    let mut output = DeviceBuffer::zeroed(&stream, 1024).unwrap();\n\n    let module = kernels::load(&ctx).unwrap();\n    let factor = 2.5f32;\n\n    module.map(\n        &stream,\n        LaunchConfig::for_num_elems(1024),\n        move |x: f32| x * factor,\n        &input,\n        &mut output,\n    ).unwrap();\n\n    let result = output.to_host_vec(&stream).unwrap();\n    assert!((result[1] - 2.5).abs() \u003C 1e-5);\n}\n\n## 5) 導入檢查清單\n- [ ] Rust nightly 已固定版本\n- [ ] CUDA toolkit 已安裝\n- [ ] LLVM \u002F llc 版本已確認\n- [ ] clang \u002F libclang 可用\n- [ ] cargo oxide doctor 可通過\n- [ ] 一個 kernel 可編成 PTX\n- [ ] 一次 host launch 可成功\n- [ ] 一條 async pipeline 可跑通\n\n## 6) 上線規則\n如果 compiler 變動太快，先把 cuda-oxide 放在 feature flag 後面，等 API 穩一點再擴大使用。\n\n## 7) 需要寫進你 repo 的文件\n- 支援的 toolchain 版本\n- 一個可跑的 kernel 範例\n- 一個 async 範例\n- 已知限制\n- 必要時回退到原生 CUDA 的路徑\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我最想從 cuda-oxide 抄走的，不是「Rust 可以跑 GPU」這句口號，而是它把 compiler、runtime、kernel model 都攤在開發者面前。這種工具才不容易變成 folklore。我要的是能檢查、能測、能慢慢信任的工具鏈，不是只有一份好看的 README。\u003C\u002Fp>\u003Cp>如果你現在卡在 GPU 專案的語言分裂、host orchestration、或 async 流程管理，這套值得你花時間看。原始來源是 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\">NVlabs\u002Fcuda-oxide\u003C\u002Fa> 與它的 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide\u002Ftree\u002Fmain\u002Fcuda-oxide-book\">book\u003C\u002Fa>；上面那份模板是我根據它的結構整理出的可抄版本，不是原文照搬。\u003C\u002Fp>","我拆 cuda-oxide 的 Rust 轉 PTX 做法，最後給你一份可直接改的 GPU Rust 模板。","github.com","https:\u002F\u002Fgithub.com\u002FNVlabs\u002Fcuda-oxide",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781110154542-ttd2.png","tools","zh","908bd6d7-ba5a-40f0-8000-e785fd1372f5",[17,18,19,20,21],"Rust","PTX","CUDA","GPU 編譯器","async runtime",[23,24,25],"cuda-oxide 想把 Rust 直接編成 PTX，並讓 host 與 device 放在同一個 workspace。","它的價值不只在 kernel 語法，而是 compiler backend、host runtime、async pipeline 一起處理。","導入前先從最小 kernel、泛型 closure、async 串接與工具鏈版本固定四件事驗證。",1,"2026-06-10T16:48:43.64696+00:00","2026-06-10T16:48:43.634+00:00","af224289-42f1-4b8a-806f-e8117fafad69",{"tags":31,"relatedLang":42,"relatedPosts":46},[32,34,36,38,40],{"name":17,"slug":33},"rust",{"name":21,"slug":35},"async-runtime",{"name":18,"slug":37},"ptx",{"name":19,"slug":39},"cuda",{"name":20,"slug":41},"gpu-編譯器",{"id":15,"slug":43,"title":44,"language":45},"cuda-oxide-rust-ptx-kernels-en","cuda-oxide turns Rust into PTX kernels","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"c16aef24-e638-468b-b959-03b3dd311ba2","last30days-skill-best-reason-stop-trusting-search-alone-zh","last30days-skill 是停止只靠搜尋的最佳理由","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781122670213-wroe.png","2026-06-10T20:17:22.229493+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"396b3184-2feb-400c-a7f2-bc133bec889d","15-ai-coding-assistant-tools-2026-zh","2026 AI 程式助理工具選配指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781114581485-154k.png","2026-06-10T18:02:27.477751+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"279c8306-f41d-4bcc-a87a-2d3c0a905d39","gpu-programming-core-software-skill-zh","GPU 編程正在成為核心軟體技能","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781109180204-axgz.png","2026-06-10T16:32:18.403171+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"1a577d27-7d0b-428a-a3df-ee0ae39c5d5f","devin-pricing-turns-agents-into-seats-zh","Devin 定價把 agents 變 seats","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781096620398-19a8.png","2026-06-10T13:03:10.4842+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"2fe98ea1-b9ab-4462-97ce-a1746483d51d","update-cursor-in-1-minute-zh","1 分鐘更新 Cursor","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781092963184-c3rr.png","2026-06-10T12:02:16.930353+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"f69efc2b-0c9c-4888-a8b7-bb0328d7df1f","cloudflare-bots-beat-human-web-traffic-zh","Cloudflare 機器人流量超越人類：實作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781089384566-ldx3.png","2026-06-10T11:02:25.914435+00:00",[84,89,94,99,104,109,114,119,124,129],{"id":85,"slug":86,"title":87,"created_at":88},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":125,"slug":126,"title":127,"created_at":128},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":130,"slug":131,"title":132,"created_at":133},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]