DeepSeek V4 Flash Trên AMD MI300X: 304B Tham Số, Một GPU

Chuyện gì đã xảy ra?

Ryan Zhou vừa công bố một GitHub repo. Một Docker Compose file. Một LLM 304B tham số chạy trên một GPU AMD MI300X.

Không lượng tử hóa thêm. Không offload weight qua PCIe. Không cụm 8-GPU. Toàn bộ model nằm gọn trong 192 GB HBM3 của một card duy nhất.

Kết quả: 168.6 token/s single-stream decode. Đủ nhanh để chạy production. Đây không phải demo — repo có SHA-256 pin, bản vá FP8, AITER tuning table, và Caddy reverse proxy. Sẵn sàng deploy.

Từ trước đến nay, chạy model tầm này luôn đồng nghĩa với NVIDIA. 2-8 H100. NVLink. NCCL config. AMD MI300X, với 192 GB HBM3 và giá khoảng một nửa H100, đang phá vỡ công thức đó.

Tại sao chuyện này quan trọng

192 GB HBM3 là con bài chiến lược

MI300X có 2.4× HBM của H100 SXM5: 192 GB vs 80 GB. Với DeepSeek V4 Flash dùng FP4/FP8 hỗn hợp, toàn bộ weight (156.67 GiB) + KV cache vừa khít trong một card.

Hệ quả: bài toán khó nhất khi deploy model lớn — multi-GPU interconnect — biến mất. Không NVLink bottleneck. Không NCCL deadlock. Không load balancing. Một GPU, một model, một process.

CUDA không còn là tường thành

Đây là lần đầu một model frontier chạy ổn định trên GPU AMD đơn lẻ ở hiệu năng production-grade. vLLM đã hỗ trợ ROCm đủ tốt. Cộng đồng viết kernel CDNA3 bằng tay. AITER tuning lấp khoảng trống. Ba mảnh ghép này tạo ra thứ mà năm ngoái không ai nghĩ khả thi.

AgntroAI công bố một repo riêng: kernel CDNA3 viết tay, đạt 3.1× speedup (20.7 → ~64 token/s) so với stock vLLM. Lossless — GSM8K vẫn 96.3%.

Con đường không trải hoa hồng

FP8: hai chuẩn, hai thế giới

Đây là cái bẫy nguy hiểm nhất. MI300X (CDNA3) dùng FNUZ E4M3 — một biến thể AMD/Graphcore. MI325X trở lên dùng OCP FP8 tiêu chuẩn.

Kernel tưởng đang đọc OCP nhưng gặp FNUZ? Kết quả sai hệ số 2. Model output rác nhưng không crash — đủ tệ để không phát hiện ngay. Zhou phải viết overlay riêng: float8e4b8 với FP8_MAX=224.0, kèm preshuffle 16×16 tile.

MoE ở batch=1: lãng phí 15/16 phép tính

Stock vLLM dùng Triton tile-GEMM cho MoE routing. Vấn đề: tile cứng là M=16, nhưng batch=1 chỉ cần M=1. 15/16 phép tính bị vứt đi. AgntroAI thay toàn bộ bằng dequant-GEMV kernel riêng — nguồn chính của speedup 3.1×.

Nghịch lý speculative decoding

DeepSeek tích hợp DSpark-7 — speculative decoder dự đoán 7 token cùng lúc để tăng tốc. Nhưng trên MI300X với kernel tối ưu, DSpark-7 chậm hơn single-stream decode thuần. Lý do: speculative verify chạy ở M≥2, rơi đúng vào tile-GEMM chậm. AgntroAI audit kỹ: acceptance rate ~2.4, thấp hơn break-even. Kết luận: tắt speculative decoding mới nhanh nhất.

Một câu hỏi thú vị: nếu chính cơ chế tăng tốc của model lại thành bottleneck trên phần cứng khác, thì "tối ưu cho NVIDIA" có đang trở thành rào cản ngầm cho đa dạng hóa phần cứng?

Developer cần biết gì

1. Kinh tế inference sắp thay đổi

Khi model 304B chạy được trên card giá ~$10-15K thay vì cụm $100K+, bài toán tài chính lật ngược. Các provider inference API sẽ có lựa chọn phần cứng rộng hơn — áp lực cạnh tranh đẩy giá xuống. Developer hưởng lợi đầu tiên.

2. Self-hosting trở nên thực tế

Một MI300X giá bằng nửa H100. Một startup nhỏ mua 1-2 card, chạy model riêng, cắt phụ thuộc OpenAI API. Không rate limit. Không chi phí biến đổi theo token. ROI trong vài tháng nếu volume đủ lớn.

3. AMD không cần thắng ở training

Đây là góc nhìn đáng chú ý nhất. NVIDIA thống trị training nhờ CUDA ecosystem 15 năm tích lũy. Nhưng inference — chiếm 70-80% tổng chi phí vận hành model — là cuộc chơi khác. Bandwidth quan trọng hơn compute. HBM dung lượng quan trọng hơn MFMA throughput. Và ở hai thông số này, MI300X có lợi thế cấu trúc.

AMD không cần đánh bại H100 ở training. Chỉ cần thắng ở inference — nơi 192 GB HBM tự nhiên vượt trội 80 GB. Đó là con đường thực tế để chiếm thị phần.

4. Phần mềm vẫn là rào cản

Clone về chạy ngay? Chưa. Bạn cần hiểu FP8 dialect. Debug kernel. Vá race condition trong vLLM (issue #47282 — CPU→GPU KV restore chưa được upstream merge). Nhưng với team có chuyên môn hệ thống, đây là rào cản vượt qua được — và phần thưởng xứng đáng.

Những con số đáng chú ý

Chỉ số	Stock vLLM	+ Kernel thủ công	+ AITER tuning
Single-stream decode	20.7 tok/s	58.9 tok/s	~64 tok/s
Speedup	—	2.85×	3.1×
Độ chính xác (GSM8K)	96.3%	96.3%	96.3%

Với DSpark-7 + tuned kernel (Zhou):

1 stream: 168.6 tok/s median
8 streams: 542 tok/s aggregate
64 streams burst: 830 tok/s, không OOM
Prefill: 7.9-8.5K tok/s
Context tối đa đã validate: 256K (kiến trúc hỗ trợ 1M)

Điểm cần lưu ý

HBM headroom cực kỳ hẹp. Ngưỡng cao nhất: 204.5/205.8 GB. Tăng KV cache lên 30 GB là crash với HSA_STATUS_ERROR_OUT_OF_RESOURCES. Multi-session throughput (batch>1) vẫn occupancy-bound — các CU rất rảnh vì MoE compute intensity thấp. Đây không phải giải pháp cho high-concurrency serving.

Nhưng cho single-stream — chatbot, coding agent, internal tool — đây là bước tiến thực sự. Từ 20.7 lên 168.6 token/s trên cùng một GPU: cải thiện 8× so với stock vLLM.

Kết luận

Ngày 4/8/2026, một kỹ sư bỏ lên GitHub một Docker Compose file. Trong đó: model 304B tham số, một GPU AMD, 168 token/s.

Đó không phải một bài blog. Không phải một slide deck. Là code chạy được.

Nếu team bạn đang trả hàng nghìn đô mỗi tháng cho inference API — đây là lúc chạy bài toán self-hosting với AMD. Kết quả có thể làm bạn bất ngờ.

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.