NVIDIA เปิด CUDA Rust สองเส้นทาง เขียน GPU kernel เป็น Rust คอมไพล์ลง PTX ตรง — cutile-rs ใช้ได้จริงบน stable แล้ว ส่วน cuda-oxide ยัง early alpha

หมายเหตุเรื่องวันที่: ประกาศนี้ออกวันที่ 8 ก.ย. 2026 เราตามเก็บช้าไปหนึ่งสัปดาห์ เรื่องกลับมาเป็นกระแสอีกครั้งเมื่อขึ้นหน้าแรก Hacker News วันที่ 16 ก.ย. ด้วยคะแนนกว่า 460 จึงขอเขียนเป็นการตามเก็บ ไม่ใช่ข่าวด่วน

NVIDIA ประกาศรองรับการเขียน GPU kernel ด้วยภาษา Rust แบบเนทีฟ ผ่านสองโปรเจกต์ที่แยกกันชัดเจน ประเด็นสำคัญอยู่ที่คำว่าเนทีฟ — ที่ผ่านมาคุณ launch kernel จาก Rust ได้อยู่แล้ว แต่ตัว kernel เองมักต้องไปเขียนด้วยภาษาอื่น สิ่งที่เปลี่ยนคือตอนนี้โค้ด Rust ถูกคอมไพล์ลง PTX ตรง ๆ ไม่ใช่ wrapper ครอบโค้ดที่เขียนที่อื่น

เหตุผลที่ NVIDIA ยกมาเป็นเรื่องที่นักพัฒนาสาย infra น่าจะเห็นด้วย ชั้น systems ของงาน AI ทั้งหมด ตั้งแต่ inference engine, serving infra, ไดรเวอร์ ไปจนถึง agent runtime กำลังย้ายไป Rust มากขึ้นเรื่อย ๆ และ NVIDIA เองก็อยู่ในกระแสนั้น — ไดรเวอร์ Nova เขียนด้วย Rust, NVIDIA Dynamo มี core เป็น Rust, NVTX มี Rust bindings แต่ ตัว kernel คือข้อยกเว้นเดียวที่ยังหลุดออกไป บทความระบุว่า NVIDIA จะพัฒนา CUDA Rust ต่อ “ไปถึงปี 2027 และหลังจากนั้น” ขณะที่ CUDA C++ และ CUDA Python ยังเป็น toolchain ระดับ enterprise ที่โตเต็มที่แล้ว

สองเส้นทาง เลือกตามระดับการควบคุมที่ต้องการ

โครงสร้างสะท้อน CUDA เองที่มีสองโมเดลอยู่แล้ว

เส้นทาง SIMT — cuda-oxide คือการเขียนแบบที่คุ้นเคยจาก CUDA C++ หรือ numba-cuda คือบอกว่าหนึ่ง thread ทำอะไร แล้ว launch เป็นพัน ๆ ตัว ทางเทคนิคมันคือ custom rustc codegen backend ที่ดักการคอมไพล์ ส่งฟังก์ชันที่ติด #[kernel] ผ่าน Rust MIR → เฟรมเวิร์ก Pliron IR ของชุมชน → LLVM IR → PTX ส่วนโค้ดที่เหลือส่งต่อให้ backend มาตรฐาน NVIDIA ระบุว่า GPU dialect ที่วางบน Pliron เป็นของตัวเอง

เส้นทาง Tile — cutile-rs ทำงานสูงขึ้นหนึ่งระดับ คุณคิดเป็น tile ไม่ใช่ scalar โดย kernel body รันครั้งเดียวต่อ sub-tensor เสมือนเป็น logical thread เดียว แล้ว คอมไพเลอร์ตัดสินใจเองว่าจะใช้ GPU thread จริงกี่ตัว มาโคร #[cutile::module] ฝัง AST ของ kernel ไว้ใน host binary แล้ว JIT ผ่าน CUDA Tile IR ตอนถูกเรียกครั้งแรก

คำแนะนำของ NVIDIA ชัดเจน: ให้เริ่มที่ Tile ก่อน เพราะซอร์สจะไม่ผูกกับสถาปัตยกรรมชิปรุ่นใดรุ่นหนึ่ง แล้วค่อยลงมา SIMT เมื่อต้องการคุมหน่วยความจำและ thread เอง

ความต่างที่กระทบการติดตั้งจริง

	cuda-oxide (SIMT)	cutile-rs (Tile)
สถานะ	early alpha	เผยแพร่บน crates.io แล้ว
Rust toolchain	nightly ที่ปักหมุดไว้ (nightly-2026-04-03)	stable 1.89+
CUDA	12.x ขึ้นไป	13.3
LLVM ของตัวเอง	ต้องมี	ไม่ต้อง
ติดตั้ง	cargo +nightly-2026-04-03 install --git ...	cargo add cutile
ระบบปฏิบัติการ	Linux เท่านั้น	Linux เท่านั้น
compute capability	8.0 ขึ้นไป	8.0 ขึ้นไป

ทั้งคู่ต้องการ GPU ที่ compute capability 8.0 ขึ้นไป (Ampere ขึ้นไป) และรันได้เฉพาะ Linux ส่วน cuda-oxide ยังต้องมี clang พร้อม libclang headers ด้วย และมีคำสั่ง cargo oxide doctor ไว้ตรวจสภาพแวดล้อมให้ NVIDIA ยอมรับเองว่าการต้องปักหมุด nightly toolchain “คือสิ่งที่เราอยากเลิกขอจากคุณ”

ความปลอดภัยคือข้อขายจริง ไม่ใช่แค่ไวยากรณ์

ส่วนที่น่าสนใจที่สุดคือทั้งสองเส้นทางใช้ระบบ type ของ Rust บังคับเรื่อง aliasing ตั้งแต่ตอนคอมไพล์ ไม่ใช่ตอนรัน

ฝั่ง SIMT มีชนิดข้อมูลชื่อ DisjointSlice<T> ที่สร้างขึ้นมาเพื่อแก้ปัญหาตรง ๆ ว่า &mut [f32] ผิดรูปสำหรับงานนี้ เพราะทุก thread จะต้องถือ &mut ตัวเดียวกัน ซึ่ง Rust ปฏิเสธอย่างถูกต้อง DisjointSlice จึงซอย mutable borrow อันเดียวออกเป็นชิ้นต่อ thread นอกจากนี้ thread::index_1d() คืนค่าเป็นชนิด index ไม่ใช่จำนวนเต็มเปล่า ๆ และ c.get_mut(idx) รับได้แค่ชนิดนั้น โดยคืนค่าเป็น Option ทำให้กรณี out-of-bounds กลายเป็นกิ่งที่คุณต้องจัดการ แทนที่จะเป็น memory error ที่ไปเจอทีหลัง

ยังมี #[launch_contract] ที่ประกาศว่า kernel นี้ index กี่มิติและ block ขนาดเท่าไร ตัว prepare_* จะตรวจ LaunchConfig ของคุณเทียบกับสัญญานั้น และเทียบกับลิมิตจริงของอุปกรณ์ ณ ขณะนั้น แล้วคืน token มาให้ ถ้า kernel ไหนไม่มี contract จะเปิดให้เฉพาะ launch แบบ unsafe เท่านั้น

ตัวอย่างที่บทความยกมาชัดมาก การส่ง output buffer เข้าไปเป็น input ของตัวเองด้วย คอมไพล์ไม่ผ่าน ทั้งสองฝั่ง ฝั่ง SIMT ได้ error[E0502]: cannot borrow c_dev as mutable because it is also borrowed as immutable ส่วนฝั่ง Tile ได้ error[E0382]: use of moved value: z NVIDIA ระบุเองว่าการรับประกันของ cutile-rs แข็งแรงกว่า เพราะ ownership ตามตัว tensor ข้ามขอบเขตของการ launch ไปด้วย ขณะที่ cuda-oxide ตรวจเป็นราย launch call

แต่มีข้อแลกเปลี่ยนที่ควรรู้: ฝั่ง Tile ปลอดภัยเพราะคุณไม่มี shared memory หรือ thread indexing ให้ทำพลาด คอมไพเลอร์เป็นเจ้าของทั้งสองอย่าง ส่วนฝั่ง SIMT ที่ยังคุมได้เอง วันนี้ การใช้ shared memory ยังต้องเขียนใน unsafe ซึ่ง NVIDIA บอกว่ากำลังทำให้ปลอดภัยอยู่ และย้ำว่า shared memory คือรากฐานของ SIMT kernel ที่เร็ว

สถานะจริง ณ 17 ก.ย.

NVIDIA เขียนไว้ตรง ๆ ว่า “ทั้งสองโปรเจกต์ยังอยู่ระยะแรกและยังไม่พร้อม production” coverage ยังไม่ครบและ API จะยังเปลี่ยน

ตรวจสอบสถานะเพิ่มเติมเมื่อ 17 ก.ย. ทั้งสองรีโปอยู่ภายใต้ Apache-2.0 ทั้งคู่:

• NVlabs/cuda-oxide — 3,392 ดาว, 65 issue ที่เปิดอยู่, commit ล่าสุด 16 ก.ย.
• NVlabs/cutile-rs — 928 ดาว, 42 issue ที่เปิดอยู่, commit ล่าสุด 15 ก.ย.
• crate cutile บน crates.io อยู่ที่เวอร์ชัน 0.3.1 (ออก 4 ก.ย. 2026) ยอดดาวน์โหลดสะสมราว 6,900 ครั้ง เผยแพร่ครั้งแรก 13 มี.ค. 2026

หลักฐานการใช้งานจริงที่ NVIDIA อ้างคือ cutile-rs ถูกใช้นอกบริษัทแล้วใน Grout ซึ่งเป็น inference engine ของ Hugging Face และใน mistral.rs ส่วนแผนระยะถัดไปคือ interop ข้ามภาษา ระหว่าง CUDA Rust, CUDA C++ และ CUDA Python เพื่อไม่ให้การเลือก frontend ปิดทางไปยัง ecosystem อื่น

มุมมอง AI Curator

ข่าวนี้อ่านง่ายที่สุดถ้ามองว่าเป็น การยอมรับ ไม่ใช่การเปิดตัว งาน Rust บน GPU มีมาก่อนหน้านี้หลายโครงการ ทั้ง Rust-GPU, rust-cuda และ CubeCL ซึ่ง NVIDIA ก็อ้างถึงในภาคผนวกของ cuda-oxide book เอง สิ่งที่เปลี่ยนไม่ใช่ว่าเขียน Rust ลง GPU ได้แล้ว แต่คือ เจ้าของ PTX ลงมาทำเองและประกาศ roadmap ถึงปี 2027 สำหรับทีมที่ต้องขออนุมัติเลือกเทคโนโลยี ความต่างระหว่าง “โครงการชุมชน” กับ “NVIDIA ดูแล” คือความต่างระหว่างข้อเสนอที่ผ่านกับไม่ผ่าน

แต่ผมจะไม่แนะนำให้ย้ายงานจริงตอนนี้ และ NVIDIA ก็ไม่ได้แนะนำเช่นกัน ถ้าจะลองวันนี้ ลองแค่ cutile-rs เพราะมันอยู่บน stable Rust ติดตั้งด้วย cargo add บรรทัดเดียว และมีคนใช้จริงนอก NVIDIA แล้ว ส่วน cuda-oxide ที่ต้องปักหมุด nightly ไว้ที่วันที่ 3 เม.ย. 2026 พร้อม LLVM ของตัวเอง นั่นคือสัญญาณว่ายังเป็นของสำหรับอ่านและทดลอง ไม่ใช่ของสำหรับส่งขึ้น production — และข้อจำกัดที่ shared memory ยังต้อง unsafe ก็แปลว่า kernel SIMT ที่เร็วจริงยังเขียนแบบปลอดภัยเต็มที่ไม่ได้ ซึ่งเป็นการตัดข้อได้เปรียบหลักของ Rust ออกไปพอดีในจุดที่ต้องการมันที่สุด

สำหรับนักพัฒนาไทย ผมคิดว่านัยที่แท้จริงอยู่ที่เพดานความรู้ที่ต่ำลง ไม่ใช่ประสิทธิภาพ อุปสรรคของการเขียน CUDA ไม่เคยเป็นเรื่องไวยากรณ์ แต่เป็นคลาสของบั๊กที่ “รันผ่านบนเครื่องผมแต่พังบนของลูกค้า” — race condition ที่ทำซ้ำไม่ได้ตามสั่ง ผ่านเทสต์แล้วค่อยพังบน production ตามที่บทความอธิบายไว้เอง การที่ compiler ดักเคส aliasing ให้ตั้งแต่ตอนคอมไพล์ ทำให้วิศวกรที่ไม่ได้เชี่ยวชาญ GPU มาสิบปีเริ่มแตะงานนี้ได้อย่างมีความมั่นใจมากขึ้น ในตลาดที่คนเขียน CUDA เก่ง ๆ หายากและแพงมาก นี่มีค่ากว่าตัวเลข benchmark

ข้อสังเกตสุดท้ายที่อยากฝากไว้ — ข้อจำกัด Linux เท่านั้น และ compute capability 8.0 ขึ้นไป ตัดผู้อ่านจำนวนไม่น้อยออกไปเงียบ ๆ การ์ดรุ่นก่อน Ampere ใช้ไม่ได้เลย ใครที่เรียนหรือทำวิจัยด้วยการ์ดมือสองรุ่นเก่าอย่าง GTX 10 ซีรีส์ หรือ Turing ยังต้องอยู่กับ CUDA C++ ต่อไป และเรื่องนี้ก็เป็นภาพสะท้อนที่คุ้นเคยของการพัฒนาเครื่องมือ AI ยุคนี้ที่เพดานล่างของฮาร์ดแวร์ขยับสูงขึ้นทุกปี

แหล่งข่าว

• NVIDIA Technical Blog — Introducing CUDA Rust: Two Tracks for Writing GPU Kernels (8 ก.ย. 2026)
• GitHub — NVlabs/cuda-oxide (เส้นทาง SIMT, Apache-2.0)
• GitHub — NVlabs/cutile-rs (เส้นทาง Tile, Apache-2.0)
• lib.rs — cutile 0.3.1 (แพ็กเกจบน crates.io)