- AMD đang tăng cường chiến lược GPU trung tâm dữ liệu xoay quanh ngăn xếp phần mềm AI ROCm để đối phó với hệ sinh thái Nvidia CUDA
- ROCm đã phát triển từ một tập hợp firmware đơn giản ban đầu thành một nền tảng phần mềm hoàn chỉnh, đồng thời áp dụng chu kỳ phát hành 6 tuần để bảo đảm khả năng sử dụng ổn định
- Thông qua OneROCm, AMD thúc đẩy hợp nhất ngăn xếp AI và bảo đảm tính di động giữa CPU, GPU và FPGA, đồng thời nâng cao hiệu quả phát triển nhờ tái sử dụng mã dựa trên Triton·MLIR
- ROCm mã nguồn mở toàn bộ các thành phần trừ firmware, qua đó hấp thụ tốc độ đổi mới của cộng đồng, và cũng được hỗ trợ mặc định trên laptop Strix Halo và phiên bản Windows
- AMD coi trọng việc phản hồi ý kiến nhà phát triển và khôi phục niềm tin của cộng đồng, với mục tiêu phát triển ROCm thành một nền tảng bền vững lấy nhà phát triển làm trung tâm trong 10 năm tới
Sự tiến hóa của AMD ROCm và chiến lược cạnh tranh với CUDA
- AMD đang thúc đẩy ROCm, ngăn xếp phần mềm AI, như một chiến lược cốt lõi để đối phó với hệ sinh thái CUDA của Nvidia trong thị trường GPU trung tâm dữ liệu
- Phó chủ tịch mảng phần mềm AI Anush Elangovan mô tả quá trình phát triển ROCm là “giống như leo núi, tiến lên từng bước một”, nhấn mạnh vào cải tiến và tích hợp liên tục
- Ông gia nhập AMD thông qua thương vụ mua lại startup Nod.ai, và đội ngũ Nod có kinh nghiệm đóng góp cho các dự án mã nguồn mở lớn như Shark, Torch.MLIR, IREE
- Thông qua ROCm, AMD thúc đẩy hợp nhất ngăn xếp AI giữa CPU, GPU và FPGA (OneROCm), đồng thời rút ngắn chu kỳ phát triển phần mềm xuống còn 6 tuần, hướng tới mức độ mà “người dùng không cần phải để ý đến phiên bản”
- ROCm hiện đang chuẩn bị cho chuyển đổi sang kỹ thuật được AI hỗ trợ, đồng thời tăng tốc mở rộng dựa trên hệ sinh thái mã nguồn mở và cộng đồng nhà phát triển
Sự phát triển của ROCm và chiến lược phần mềm
- Ban đầu ROCm là một gói gồm nhiều mảnh firmware ghép lại, nhưng sau 2 năm rưỡi đầu tư đã phát triển thành một nền tảng phần mềm hoàn chỉnh
- Elangovan tham chiếu văn hóa phát triển của đội Google Chrome, hướng tới chu kỳ phát hành định kỳ và trải nghiệm người dùng ổn định
- ROCm đã trở thành phần mềm “cứ thế là chạy”, và sắp chuyển sang mô hình phát hành 6 tuần một lần
- AMD đang chuyển đổi từ một công ty trọng phần cứng sang một công ty trọng phần mềm, và xem kỹ thuật được AI hỗ trợ (AI-assisted engineering) là bước ngoặt trọng yếu tiếp theo
Hợp nhất ngăn xếp AI và tính di động
- Thông qua OneROCm, AMD hiện thực hóa việc hợp nhất ngăn xếp AI giữa nhiều loại phần cứng như CPU, GPU và FPGA
- Một số thành phần vẫn còn phụ thuộc phần cứng, nhưng mọi tăng tốc đều được thực hiện qua ngăn xếp ROCm để bảo đảm tính di động (portability)
- Sự phổ biến của framework Triton đã giúp giảm bớt vấn đề tương thích giữa các GPU
- Trước đây phải chuyển đổi kernel CUDA sang kernel HIP, nhưng hiện nay có thể viết kernel Triton để chạy trên cả AMD và Nvidia
- AMD đang đầu tư tích cực vào Triton và hạ tầng trình biên dịch MLIR, đồng thời hỗ trợ retarget mã sang nhiều loại phần cứng thông qua việc duy trì Torch.MLIR
- Phần lớn khách hàng suy luận sử dụng các framework LLM như vLLM, SGLang, nên nhu cầu chuyển đổi mã CUDA đang giảm dần
- Khi xuất hiện thuật toán attention mới, có thể tối ưu kernel dựa trên Triton chỉ trong một đến hai ngày
- HIPify vẫn được cung cấp cho khách hàng HPC, còn với việc viết kernel mới, AMD sử dụng Claude AI để kiểm chứng và sinh mã
Chiến lược mã nguồn mở
- ROCm công khai 100% mã nguồn mở cho mọi thành phần trừ firmware
- Việc mã nguồn mở vừa cho phép nhận được kiểm chứng từ cộng đồng nhà phát triển, vừa tận dụng tốc độ đổi mới của cộng đồng nhanh hơn AMD
- Bất kỳ ai cũng có thể tham gia ở điểm mình muốn như trình biên dịch hay runtime, và không bị giới hạn bởi tốc độ cộng tác của AMD
- AMD đang tích cực thúc đẩy mở rộng cộng đồng nhà phát triển, và ROCm được hỗ trợ mặc định trên laptop dùng Strix Halo
- Bản cập nhật ROCm cho Windows cũng được phát hành cùng ngày với phần cứng trung tâm dữ liệu Instinct
Cộng đồng nhà phát triển và văn hóa phản hồi
- Elangovan coi trọng việc giao tiếp trực tiếp với nhà phát triển và thu thập phản hồi theo thời gian thực qua X(Twitter)
- Ông theo dõi các từ khóa như “ROCm”, “ROCm sucks”, “AMD software not working” và trực tiếp phản hồi mọi bài đăng
- Phần lớn vấn đề xuất phát từ thiếu đào tạo và hỗ trợ, và ông cũng trực tiếp đưa ra lời khuyên cho cả các nhà phát triển ẩn danh
- AMD đã điều tra hơn 1.000 khiếu nại liên quan đến ROCm trên GitHub và giải quyết toàn bộ trong vòng 1 năm
- Có nhiều yêu cầu hỗ trợ phần cứng đời cũ, hiện nay đang được AMD hoặc cộng đồng bảo trì
- Nhờ những phản hồi này, niềm tin của nhà phát triển đã được khôi phục, và nhận thức rằng “AMD giải quyết vấn đề” đang lan rộng
- Elangovan bày tỏ kỳ vọng vào GPU MI450 (dự kiến ra mắt nửa cuối năm 2026) và nhấn mạnh sẽ phát triển ROCm thành một nền tảng bền vững trong 10 năm tới
- Mục tiêu là xây dựng một hệ sinh thái ổn định để nhà phát triển không phải lo lắng ngay cả khi phần cứng mới xuất hiện
Định hướng tương lai và triết lý
- Dựa trên kinh nghiệm từ thời còn ở Nod.ai, Elangovan nhắc đến trường hợp công nghệ trình biên dịch được gần như mọi công ty làm bộ tăng tốc áp dụng
- Ông nhấn mạnh rằng “phải tiến lên từng bước với niềm tin”, và định nghĩa sự phát triển của ROCm là kết quả của việc thực thi liên tục
- AMD không chỉ dừng ở việc sao chép CUDA, mà còn đang phát triển các tính năng ROCm khác biệt, với mục tiêu dài hạn là trở thành một nền tảng lấy nhà phát triển làm trung tâm
2 bình luận
Bắt đầu từ driver trước đã...
Ý kiến trên Hacker News
Trong tuần qua, tôi đã port TheRock sang stagex đồng thời cố build ROCm bằng toolchain dựa trên musl/mimalloc
Vì với các workload coi trọng bảo mật và quyền riêng tư, không thể tin tưởng các binary chỉ được build bằng một compiler duy nhất
Việc đóng gói hơn 30 dependency cùng một bản LLVM tùy biến là một cơn ác mộng, nhưng sáng nay cuối cùng tôi đã build runtime thành công
Việc phần cứng AMD có thể hoạt động trong một môi trường hoàn toàn mở khiến tôi thấy có hy vọng cho các workload bảo mật cao
Tôi đã vượt qua được LLVM fork tùy biến và nhiều gói khác, nhưng cuối cùng bỏ cuộc vì quá tốn thời gian
Giờ tôi dùng llama.cpp có hỗ trợ Vulkan và thấy hoàn toàn đủ dùng
Nếu bạn có thể chia sẻ build recipe thì có lẽ sẽ giúp tôi vượt qua bước cuối cùng của việc port sang Alpine
Năm ngoái tôi đã dừng chiến dịch vận động cổ đông vì tin vào lời hứa của AMD, nhưng giờ tôi cảm thấy thực sự cần hành động
unlockgpu.com/action-plan
Không thể tiếp tục thế này được, rõ ràng công việc này phải có thể sử dụng được
Nvidia cũng đã hứa sẽ cải thiện driver mã nguồn mở
Cá nhân tôi thấy việc Intel cung cấp 32GB VRAM ở mức khoảng 1000 USD còn hấp dẫn hơn
Ý bạn là link các file .o được tạo từ những compiler khác nhau với nhau sao?
Tôi tò mò không biết đây có phải là workload thực sự đang cố né vấn đề Reflections on Trusting Trust hay không
Từ tháng 2 tôi đã đề nghị AMD thêm kernel Tensile được tinh chỉnh cho gfx1201 vào rcom-libs, nhưng không ai biết ai phụ trách việc đó
Ngay cả trên Discord của dev cũng không có câu trả lời, nên rất bức bối. Đây có vẻ là một ví dụ cho thấy điểm nghẽn tổ chức của AMD bên cạnh các vấn đề kỹ thuật
zichguan-amd hoặc harkgill-amd có thể là người phụ trách liên quan
AMD vẫn còn phải bắt kịp khoảng cách nhiều năm về ROCm
Họ thậm chí còn không hỗ trợ toàn bộ các GPU của chính mình có khả năng tính toán AI, và ngay cả khi có hỗ trợ thì cũng đầy lỗi
Driver AMDGPU cho Linux liên tục bất ổn từ sau 6.6
Không nhìn ra AI sẽ trở nên quan trọng là một sai lầm rõ ràng
Nếu AMD có năng lực cạnh tranh thì cả ngành đều được lợi, nhưng đây là điều họ tự chuốc lấy
Từ thời ATI họ đã nổi tiếng vì driver nhiều lỗi, và có vẻ sau khi AMD mua lại thì văn hóa đó cũng không thay đổi
Năm ngoái AMD đã thu thập các lời phàn nàn liên quan đến ROCm trên GitHub và tuyên bố đã giải quyết cả 1000 trường hợp
Nhưng trên thực tế, hỗ trợ cho phần cứng cũ hầu như không tăng lên
Chỉ khi nào ROCm hỗ trợ ngay từ ngày phát hành cho mọi card AMD thì tôi mới thực sự tin vào quảng bá của họ
Trước đây việc bỏ rơi cả những card mới như dòng 400 là một sai lầm lớn
Tôi mong ban lãnh đạo sẽ đầu tư nhiều hơn vào software stack
ROCm không hỗ trợ GPU tiêu dùng phổ thông, ví dụ như RX 580
Thay vào đó, backend Vulkan hoạt động tốt
Tôi nghĩ việc kiến trúc GCN giờ bị ngừng hỗ trợ là điều có thể hiểu được, nhưng ở thế hệ RDNA thì thiếu hỗ trợ vẫn là vấn đề
Hiện tại chỉ dùng được với RDNA3·RDNA4, còn CUDA vẫn hỗ trợ cả Turing
Xem tài liệu chính thức
Backend Vulkan thì chạy tốt, nhưng phải mất 1–2 năm mới có hỗ trợ chính thức
Tôi muốn ROCm stack được dọn dẹp (clean-up)
Chỉ cần có thể
git clone --recurse-submodules rocmrồi build bằng configure/make, đồng thời in rõ các dependency còn thiếuHiện tại nó giống như ném nhiều thành phần vào một chỗ mà không có cấu trúc, không thấy được một kiến trúc nhất quán
Tôi thuộc phe OpenVINO và SYCL trong cuộc đối đầu với CUDA
iGPU·dGPU của Intel gần đây có giá khá hợp lý và hỗ trợ phần mềm cũng đã tốt hơn
Với workload CV hay data science chứ không phải gaming, nó scale khá ổn
Đây là phản hồi về ROCm mà tôi muốn gửi tới ban lãnh đạo AMD
(1) Việc chỉ hỗ trợ GPU server và phớt lờ GPU/APU tiêu dùng là một sai lầm chiến lược
Phần lớn developer đều thử nghiệm trên laptop cá nhân trước rồi mới mở rộng lên server
Cũng như CUDA, dù hiệu năng thấp hơn thì ít nhất vẫn phải chạy được trên GPU tiêu dùng
(2) Chính sách chỉ hỗ trợ hai thế hệ là phi lý từ góc nhìn khách hàng
Xem tài liệu chính thức
CUDA duy trì khả năng tương thích ngược rất mạnh
(3) Chỉ tập trung vào Triton và coi HIP là hạng hai là một hướng đi sai lầm
Vẫn còn rất nhiều mã HPC·mô phỏng·khoa học dựa trên C/C++
GPU của AMD có thế mạnh về hiệu năng FP64, mà làm vậy chẳng khác nào tự vứt bỏ lợi thế đó
(4) Cuối cùng, cần cải thiện chất lượng đóng gói
Hợp tác với những người đóng gói cho distro không phải chi phí lớn, mà còn có thể tạo lợi thế cạnh tranh trước Nvidia
Bạn có thể viết kernel trực tiếp từ nhiều ngôn ngữ như Python, Julia, và tích hợp với IDE·debugger·thư viện cũng rất tốt
Nếu nhìn toàn bộ hệ sinh thái GPGPU thì AMD và Intel vẫn chưa theo kịp độ hoàn thiện hệ sinh thái của CUDA
Hầu hết công ty chọn kiểu cài đặt do vendor quản lý như
/opt/foo/Làm vậy cũng giúp distro dễ tự đóng gói lại về sau
Nhưng để hiểu được điều này thì cần những người có kinh nghiệm với hệ sinh thái mã nguồn mở
Họ trì hoãn ra mắt GPU VRAM cao cho người dùng phổ thông và tập trung vào thị trường server
Nếu AMD tận dụng tốt khoảng trống này thì có thể là cơ hội
Ví dụ trên 7900 XT nó vẫn chạy tốt
Chỉ là AMD không đầu tư tài nguyên test nên không ghi là “hỗ trợ chính thức” mà thôi
Với kinh nghiệm từng làm việc với compute shader, tôi thấy CUDA, ROCm, OpenCV đều quá phiền phức trong khâu cài đặt
Dependency cũng nặng, riêng CUDA đã 11GB
Tôi nghĩ cứ dùng Vulkan thì hơn. Không bị phụ thuộc nền tảng và “cứ thế là chạy”
Chỉ riêng việc compile shader và thiết lập resource cũng đã cần tới hàng trăm dòng, còn nếu muốn xử lý địa chỉ GPU thì phải cần extension
Tôi không nghĩ đó là việc phải tốn đến hàng giờ
Trước đây trên NVIDIA còn từng có lỗi(?) là chuyển sang chế độ đồ họa thì hiệu năng tăng 20%