ROCm ที่ท้าชน CUDA: ‘ค่อยๆ ก้าวไปทีละขั้น’
(eetimes.com)- AMD กำลังเสริมความแข็งแกร่งให้กลยุทธ์ GPU สำหรับดาต้าเซ็นเตอร์ โดยมี ROCm สแตกซอฟต์แวร์ AI เป็นแกนหลัก เพื่อรับมือกับ ระบบนิเวศ Nvidia CUDA
- ROCm พัฒนาจากชุดเฟิร์มแวร์แบบเรียบง่ายในช่วงแรกไปสู่ แพลตฟอร์มซอฟต์แวร์เต็มรูปแบบ และกำลังนำ รอบการออกรุ่นทุก 6 สัปดาห์ มาใช้เพื่อให้ใช้งานได้อย่างเสถียร
- ผ่าน OneROCm AMD กำลังผลักดัน การรวมสแตก AI และความสามารถในการพกพา ระหว่าง CPU, GPU และ FPGA พร้อมเพิ่มประสิทธิภาพการพัฒนาด้วยการนำโค้ดกลับมาใช้ซ้ำบนพื้นฐาน Triton·MLIR
- ROCm เปิดซอร์ส ทุกองค์ประกอบยกเว้นเฟิร์มแวร์ เพื่อรับเอาความเร็วด้านนวัตกรรมจากคอมมูนิตี้ และยังรองรับเป็นค่าเริ่มต้นบน โน้ตบุ๊ก Strix Halo และเวอร์ชัน Windows
- AMD ให้ความสำคัญกับ การตอบสนองต่อฟีดแบ็กนักพัฒนาและการกู้คืนความเชื่อมั่นของคอมมูนิตี้ โดยมีเป้าหมายพัฒนา ROCm ให้เป็น แพลตฟอร์มที่ยั่งยืนและยึดนักพัฒนาเป็นศูนย์กลางในอีก 10 ปีข้างหน้า
วิวัฒนาการของ AMD ROCm และกลยุทธ์แข่งขันกับ CUDA
- AMD กำลังผลักดัน ROCm สแตกซอฟต์แวร์ AI เป็นกลยุทธ์หลัก เพื่อรับมือกับระบบนิเวศ CUDA ของ Nvidia ใน ตลาด GPU สำหรับดาต้าเซ็นเตอร์
- Anush Elangovan รองประธานฝ่ายซอฟต์แวร์ AI เปรียบการพัฒนา ROCm ว่า “เหมือนการปีนเขาที่ต้องค่อยๆ ก้าวไปทีละขั้น” พร้อมเน้นย้ำเรื่องการปรับปรุงอย่างต่อเนื่องและการบูรณาการ
- เขาเข้าร่วม AMD หลังการเข้าซื้อกิจการสตาร์ตอัป Nod.ai โดยทีมของ Nod มีประสบการณ์ร่วมพัฒนาโปรเจกต์โอเพ่นซอร์สสำคัญอย่าง Shark, Torch.MLIR, IREE
- AMD กำลังผลักดัน การรวมสแตก AI ระหว่าง CPU, GPU และ FPGA (OneROCm) ผ่าน ROCm พร้อมย่นรอบการพัฒนาซอฟต์แวร์ให้เหลือทุก 6 สัปดาห์ โดยตั้งเป้าให้ “ผู้ใช้ใช้งานได้โดยแทบไม่ต้องสนใจเวอร์ชัน”
- ขณะนี้ ROCm กำลังเตรียมเปลี่ยนผ่านสู่ วิศวกรรมที่รองรับ AI และเร่งขยายตัวโดยมีระบบนิเวศโอเพ่นซอร์สและคอมมูนิตี้นักพัฒนาเป็นศูนย์กลาง
ความก้าวหน้าของ ROCm และกลยุทธ์ซอฟต์แวร์
- ROCm ในช่วงแรกเป็นเพียง การรวมชิ้นส่วนเฟิร์มแวร์หลายส่วนเข้าด้วยกัน แต่หลังการลงทุนต่อเนื่อง 2 ปีครึ่ง ก็พัฒนากลายเป็นแพลตฟอร์มซอฟต์แวร์เต็มรูปแบบ
- Elangovan ยกวัฒนธรรมการพัฒนาของทีม Google Chrome เป็นต้นแบบ โดยมุ่งสู่ รอบการออกรุ่นที่สม่ำเสมอและประสบการณ์ใช้งานที่เสถียร
- ROCm กลายเป็นซอฟต์แวร์ที่ “ใช้งานได้เลย” และมีแผนเปลี่ยนสู่ ระบบออกรุ่นทุก 6 สัปดาห์
- AMD กำลัง เปลี่ยนผ่านจากบริษัทที่เน้นฮาร์ดแวร์ไปสู่บริษัทที่เน้นซอฟต์แวร์ และมองว่า วิศวกรรมที่มี AI ช่วย (AI-assisted engineering) เป็นจุดเปลี่ยนสำคัญถัดไป
การรวมสแตก AI และความสามารถในการพกพา
- AMD ทำให้เกิด การรวมสแตก AI ระหว่างฮาร์ดแวร์หลากหลายประเภท เช่น CPU, GPU และ FPGA ผ่าน OneROCm
- แม้องค์ประกอบบางส่วนยังคงผูกกับฮาร์ดแวร์ แต่การเร่งความเร็วทั้งหมดดำเนินการผ่านสแตก ROCm จึงช่วยให้ได้ ความสามารถในการพกพา (portability)
- การแพร่หลายของเฟรมเวิร์ก Triton ช่วยลดปัญหาความเข้ากันได้ระหว่าง GPU
- ในอดีตมีการแปลงเคอร์เนล CUDA เป็นเคอร์เนล HIP แต่ปัจจุบันสามารถ เขียนเคอร์เนล Triton แล้วรันได้ทั้งบน AMD และ Nvidia
- AMD ลงทุนอย่างจริงจังใน Triton และโครงสร้างพื้นฐานคอมไพเลอร์ MLIR พร้อมสนับสนุนการรีทาร์เก็ตโค้ดไปยังฮาร์ดแวร์หลากหลายผ่านการดูแล Torch.MLIR
- ลูกค้าด้าน inference ส่วนใหญ่ใช้เฟรมเวิร์ก LLM อย่าง vLLM, SGLang ทำให้คำขอแปลงโค้ด CUDA ลดลง
- เมื่อมีอัลกอริทึม attention แบบใหม่เกิดขึ้น ก็สามารถ ปรับแต่งเคอร์เนลบน Triton ให้เหมาะสมได้ภายในหนึ่งถึงสองวัน
- HIPify ยังมีให้สำหรับลูกค้า HPC และการเขียนเคอร์เนลใหม่ใช้ Claude AI เพื่อช่วยตรวจสอบและสร้างโค้ด
กลยุทธ์โอเพ่นซอร์ส
- ROCm เปิดเผย ทุกองค์ประกอบเป็นโอเพ่นซอร์ส 100% ยกเว้นเฟิร์มแวร์
- การเปิดซอร์สช่วยให้ได้รับการตรวจสอบจากคอมมูนิตี้นักพัฒนา พร้อมอาศัย ความเร็วของนวัตกรรมจากคอมมูนิตี้ที่อาจเร็วกว่า AMD เอง
- ทุกคนสามารถเข้ามามีส่วนร่วมได้ในจุดที่ต้องการ เช่น คอมไพเลอร์หรือรันไทม์ โดย ไม่ถูกจำกัดด้วยความเร็วการทำงานร่วมกันของ AMD
- AMD กำลังผลักดัน การขยายคอมมูนิตี้นักพัฒนา อย่างจริงจัง และ ROCm รองรับเป็นค่าเริ่มต้นบนโน้ตบุ๊กที่ใช้ Strix Halo
- มีการปล่อยอัปเดต ROCm เวอร์ชัน Windows ในวันเดียวกับฮาร์ดแวร์ดาต้าเซ็นเตอร์ Instinct
คอมมูนิตี้นักพัฒนาและวัฒนธรรมฟีดแบ็ก
- Elangovan ให้ความสำคัญกับการสื่อสารโดยตรงกับนักพัฒนา และติดตามฟีดแบ็กแบบเรียลไทม์ผ่าน X(Twitter)
- เขาติดตามคีย์เวิร์ดอย่าง “ROCm”, “ROCm sucks”, “AMD software not working” และตอบทุกโพสต์ด้วยตนเอง
- ปัญหาส่วนใหญ่เกิดจาก การขาดการให้ความรู้และการสนับสนุน และเขายังให้คำแนะนำโดยตรงแม้กับนักพัฒนาแบบไม่เปิดเผยตัวตน
- AMD ได้ตรวจสอบข้อร้องเรียนเกี่ยวกับ ROCm บน GitHub มากกว่า 1,000 รายการ และแก้ไขได้ทั้งหมดภายใน 1 ปี
- มีคำขอจำนวนมากเกี่ยวกับการรองรับฮาร์ดแวร์รุ่นเก่า ซึ่งขณะนี้ AMD หรือคอมมูนิตี้เป็นผู้ดูแลรักษา
- การตอบสนองเช่นนี้ช่วยฟื้นฟูความเชื่อมั่นของนักพัฒนา และทำให้เกิดการรับรู้ว่า “AMD แก้ปัญหาให้จริง”
- Elangovan แสดงความคาดหวังต่อ GPU MI450 ที่มีกำหนดเปิดตัวในครึ่งหลังของปี 2026 และย้ำว่าจะพัฒนา ROCm ให้เป็น แพลตฟอร์มที่ยั่งยืนในอีก 10 ปีข้างหน้า
- เป้าหมายคือการสร้าง ระบบนิเวศที่เสถียร จนเมื่อต้องมีฮาร์ดแวร์ใหม่ออกมา นักพัฒนาก็ไม่จำเป็นต้องกังวล
ทิศทางในอนาคตและแนวคิด
- Elangovan อ้างอิงประสบการณ์สมัยอยู่ที่ Nod.ai ว่า เทคโนโลยีคอมไพเลอร์ เคยถูกนำไปใช้โดยแทบทุกบริษัทที่ทำ accelerator
- เขากล่าวว่า “ต้องก้าวไปทีละขั้นด้วยความมั่นใจ” และนิยามความก้าวหน้าของ ROCm ว่าเป็น ผลลัพธ์ของการลงมือทำอย่างต่อเนื่อง
- AMD ไม่ได้มุ่งเพียงลอกแบบ CUDA แต่กำลังพัฒนา ความสามารถของ ROCm ที่แตกต่างออกไป และตั้งเป้าให้ในระยะยาว ROCm กลายเป็น แพลตฟอร์มที่ยึดนักพัฒนาเป็นศูนย์กลาง
2 ความคิดเห็น
เริ่มจากไดรเวอร์ก่อนก็แล้วกัน...
ความเห็นจาก Hacker News
ตลอดสัปดาห์ที่ผ่านมา ผมลอง พอร์ต TheRock ไปยัง stagex พร้อมพยายามบิลด์ ROCm ด้วย toolchain ที่อิง musl/mimalloc
เพราะสำหรับเวิร์กโหลดที่ความปลอดภัยและความเป็นส่วนตัวสำคัญ จะเชื่อถือไบนารีที่บิลด์ด้วยคอมไพเลอร์ตัวเดียวอย่างเดียวไม่ได้
ต้องแพ็กเกจ dependency มากกว่า 30 ตัวและ LLVM แบบคัสตอมจนเป็นช่วงเวลาที่เหมือนฝันร้าย แต่เช้าวันนี้ก็สำเร็จในการบิลด์ runtime จนได้
การที่ฮาร์ดแวร์ของ AMD ทำงานได้ในสภาพแวดล้อมแบบเปิดอย่างสมบูรณ์ ทำให้เห็นความหวังสำหรับ เวิร์กโหลดความปลอดภัยสูง
แม้จะผ่าน LLVM fork แบบคัสตอมและแพ็กเกจหลายตัวไปได้ แต่สุดท้ายก็ยอมแพ้เพราะเสียเวลาเกินไป
ตอนนี้ผมใช้ llama.cpp ที่รองรับ Vulkan และก็พอใจมาก
ถ้าคุณพอจะแชร์ build recipe ได้ ก็น่าจะช่วยให้ข้ามขั้นตอนสุดท้ายของการพอร์ต Alpine ได้
ปีที่แล้วผมเชื่อคำสัญญาของ AMD เลยหยุดแคมเปญกับผู้ถือหุ้นไป แต่ตอนนี้รู้สึกว่าจำเป็นต้องลงมือทำจริงแล้ว
unlockgpu.com/action-plan
มันไม่ควรเป็นแบบนี้ งานนี้ควร นำไปใช้งานได้จริง อย่างชัดเจน
Nvidia ก็สัญญาไว้ว่าจะปรับปรุงไดรเวอร์โอเพนซอร์สเหมือนกัน
ส่วนตัวผมกลับมองว่า Intel ที่ให้ 32GB VRAM ได้ในระดับราคา 1000 ดอลลาร์น่าสนใจกว่า
หมายถึงการผสมไฟล์ .o จากคอมไพเลอร์ต่างกันแล้วลิงก์เข้าด้วยกันหรือ?
สงสัยว่าเป็นเวิร์กโหลดที่พยายามหลบปัญหา Reflections on Trusting Trust อย่างจริงจังหรือไม่
ตั้งแต่เดือนกุมภาพันธ์ ผมขอให้ AMD ใส่ Tensile kernel ที่จูนมาสำหรับ gfx1201 เข้าไปใน rcom-libs อยู่ แต่ไม่มีใครรู้ว่าใครเป็นคนรับผิดชอบ
แม้แต่ใน Discord ของนักพัฒนาก็ไม่มีคำตอบ จนรู้สึกอึดอัดใจ เหมือนเป็นตัวอย่างที่สะท้อน คอขวดในระดับองค์กร ของ AMD นอกเหนือจากปัญหาทางเทคนิค
zichguan-amd หรือ harkgill-amd อาจเป็นคนที่เกี่ยวข้อง
AMD ยังต้องไล่ตามช่องว่างของ ROCm อีก หลายปี
แม้แต่ GPU ของตัวเองที่ทำงาน AI ได้ก็ยังรองรับไม่ครบทั้งหมด และต่อให้รองรับก็ยังมีบั๊กเยอะ
ไดรเวอร์ AMDGPU บน Linux ก็ยังไม่เสถียรต่อเนื่องมาตั้งแต่ 6.6
การมองไม่ออกว่า AI จะสำคัญขึ้นเป็นความผิดพลาดที่ชัดเจน
ถ้า AMD แข่งขันได้มากขึ้น ทั้งวงการก็น่าจะดีขึ้น แต่นี่เป็นเรื่องที่บริษัทก่อขึ้นเอง
ตั้งแต่ยุค ATI เดิมก็มีชื่อเสียเรื่อง ไดรเวอร์มีบั๊กเยอะ อยู่แล้ว และหลัง AMD เข้าซื้อก็ดูเหมือนว่าวัฒนธรรมนั้นไม่ได้เปลี่ยนไป
ปีที่แล้ว AMD รวบรวมคำร้องเรียนเกี่ยวกับ ROCm บน GitHub แล้วประกาศว่าแก้ครบทั้ง 1000 รายการแล้ว
แต่ในความเป็นจริง การรองรับฮาร์ดแวร์เก่าแทบไม่ได้เพิ่มขึ้นเลย
ถ้าวันไหน ROCm รองรับการ์ด AMD ทุกใบตั้งแต่วันแรกที่วางขาย เมื่อนั้นผมถึงจะเชื่อคำโฆษณาได้จริง
การทิ้งการ์ดรุ่นใหม่อย่างซีรีส์ 400 ในอดีตถือเป็นความผิดพลาดใหญ่
อยากให้ฝ่ายบริหารลงทุนกับซอฟต์แวร์สแตกมากกว่านี้
ROCm ไม่รองรับ GPU สำหรับผู้ใช้ทั่วไป เช่นการ์ดอย่าง RX 580
แต่ backend แบบ Vulkan ทำงานได้ดี
ผมคิดว่าเป็นเรื่องธรรมดาที่สถาปัตยกรรม GCN จะหมดการรองรับไปแล้ว แต่ในรุ่น RDNA เองปัญหาก็ยังเป็นเรื่อง การรองรับที่ไม่เพียงพอ
ตอนนี้ใช้ได้แค่ RDNA3·RDNA4 ส่วน CUDA ยังรองรับถึง Turing อยู่
ดู เอกสารทางการ
backend แบบ Vulkan ใช้ได้ดี แต่กว่าการรองรับอย่างเป็นทางการจะมาก็ใช้เวลา 1~2 ปี
อยากให้มีการ จัดระเบียบ(clean-up) สแตก ROCm
คืออย่างน้อยควรให้บิลด์ได้ด้วย
git clone --recurse-submodules rocmแล้วตามด้วย configure/make ได้เลย พร้อมแสดง dependency ที่ขาดอย่างชัดเจนตอนนี้มันเหมือนแค่โยนคอมโพเนนต์หลายตัวกองไว้โดยไม่มีโครงสร้าง จนมองไม่เห็น สถาปัตยกรรมที่สอดคล้องกัน
ผมอยู่ฝั่ง OpenVINO และ SYCL ในการสู้กับ CUDA
ช่วงหลัง iGPU·dGPU ของ Intel ราคาสมเหตุสมผลขึ้นและซอฟต์แวร์ซัพพอร์ตก็ดีขึ้น
แม้จะไม่ใช่สำหรับเกม แต่กับเวิร์กโหลดด้าน CV หรือ data science ก็สเกลได้ดีพอสมควร
นี่คือฟีดแบ็กเกี่ยวกับ ROCm ที่ผมอยากส่งถึงผู้บริหาร AMD
(1) การรองรับเฉพาะ GPU ระดับเซิร์ฟเวอร์และ มองข้าม GPU/APU สำหรับผู้ใช้ทั่วไป เป็นความผิดพลาดเชิงกลยุทธ์
นักพัฒนาส่วนใหญ่ทดลองบนโน้ตบุ๊กส่วนตัวก่อน แล้วค่อยขยายไปสู่เซิร์ฟเวอร์ในภายหลัง
ควรทำให้มันรันบน GPU ผู้ใช้ทั่วไปได้เหมือน CUDA แม้ประสิทธิภาพจะต่ำกว่าก็ตาม
(2) นโยบายรองรับแค่สองเจเนอเรชันนั้น ไม่สมเหตุสมผล ในมุมของลูกค้า
ดู เอกสารทางการ
CUDA ยังคงรักษา backward compatibility ได้อย่างแข็งแกร่ง
(3) การโฟกัสแค่ Triton แล้วปฏิบัติกับ HIP เหมือนของชั้นสองเป็นทิศทางที่ผิด
โลกยังมีโค้ด HPC·simulation·scientific จำนวนมากที่อยู่บน C/C++
GPU ของ AMD เด่นเรื่องประสิทธิภาพ FP64 แต่การทำแบบนี้ก็เท่ากับทิ้งจุดแข็งนั้นเอง
(4) สุดท้ายคือควรปรับปรุง คุณภาพการแพ็กเกจ
การร่วมมือกับผู้แพ็กเกจของดิสโทรไม่ได้มีต้นทุนสูงนัก และอาจกลายเป็นข้อได้เปรียบเมื่อเทียบกับ Nvidia
เขียน kernel ได้โดยตรงจากหลายภาษาอย่าง Python, Julia และยังมีการผสานกับ IDE·debugger·library ที่ยอดเยี่ยม
ถ้ามองทั้ง ecosystem ของ GPGPU แล้ว AMD และ Intel ยังตามความ สมบูรณ์ของ ecosystem ของ CUDA ไม่ทัน
บริษัทส่วนใหญ่เลือกใช้ รูปแบบติดตั้งแบบผู้ขาย อย่าง
/opt/foo/ทำแบบนี้แล้วดิสโทรก็ยังนำไปแพ็กเกจเองภายหลังได้ง่ายขึ้น
แต่การจะเข้าใจเรื่องนี้ต้องมีคนที่มีประสบการณ์กับ ecosystem โอเพนซอร์ส
คือชะลอการออก GPU VRAM สูงสำหรับผู้ใช้ทั่วไป แล้วโฟกัสตลาดเซิร์ฟเวอร์แทน
ถ้า AMD ใช้จังหวะนี้ให้ดี ก็อาจกลายเป็นโอกาสได้
อย่างเช่นบน 7900 XT ก็ทำงานได้ดี
เพียงแต่ AMD ไม่ได้ใส่ทรัพยากรในการทดสอบ จึงไม่ระบุว่าเป็น “รองรับอย่างเป็นทางการ” เท่านั้น
จากประสบการณ์ที่เคยยุ่งกับ compute shader มาก่อน ผมรู้สึกว่า CUDA, ROCm, OpenCV ติดตั้งยุ่งยากเกินไปหมด
dependency ก็หนัก และ CUDA ก็กินถึง 11GB
ผมเลยคิดว่าใช้ Vulkan ดีกว่า ไม่ผูกกับแพลตฟอร์มและ “มันก็ทำงานได้เลย”
แค่การคอมไพล์ shader และตั้งค่า resource ก็ต้องใช้หลายร้อยบรรทัดแล้ว และถ้าจะจัดการ GPU address ก็ต้องพึ่ง extension
ไม่น่าใช่งานที่ต้องเสียเวลาเป็นชั่วโมง ๆ
เมื่อก่อนบน NVIDIA ยังเคยมีบั๊ก(?) ที่พอสลับไปโหมดกราฟิกแล้ว ประสิทธิภาพเพิ่มขึ้น 20% ด้วยซ้ำ