มีคนรัน DeepSeek V4 Flash 304B บน MI300X ใบเดียวได้ 168 tok/s แล้วเปิด config ทั้งชุด — แต่ของจริงที่ควรอ่านคือบั๊ก 3 ตัวที่ทำให้โมเดล 'โง่ลงเงียบ ๆ' บน AMD

วันที่ 4 สิงหาคม มี repo ชื่อ deepseek-v4-flash-mi300x ถูกสร้างขึ้นแล้วขึ้นหน้าแรก Hacker News ภายในไม่กี่ชั่วโมง (367 คะแนน) เนื้อหาคือ Docker Compose stack ระดับ production ที่รัน DeepSeek-V4-Flash-0731 โมเดล MoE ขนาด 304 พันล้านพารามิเตอร์ บน AMD MI300X ใบเดียว — ไม่ต้อง tensor parallel, ไม่ต้อง offload น้ำหนักออก GPU, ใบอนุญาต Apache 2.0

ตัวเลขความเร็วน่าสนใจอยู่แล้ว แต่สิ่งที่ทำให้ repo นี้มีค่ากว่า benchmark คือส่วนที่ผู้เขียนเรียกว่า correctness fixes — บั๊กระดับ kernel สามตัวบน ROCm ที่ ไม่ทำให้อะไรพัง ไม่มี error ไม่มี crash แต่ทำให้โมเดลตอบแย่ลงในแบบที่คุณจะโทษว่า “โมเดลมันก็แค่ไม่เก่ง” ทั้งที่จริงคือ stack ของคุณคำนวณผิด

ตัวเลขที่วัดได้จริง

ฮาร์ดแวร์คือ MI300X ใบเดียว (gfx942, 304 CUs, HBM3 192GB, แบนด์วิดท์ 5.3 TB/s) + RAM ระบบ ~235GB สำหรับชั้น KV บน CPU + ดิสก์ ~500GB

• decode แบบ single stream: 168.6 tok/s
• prefill: 7.9–8.5K tok/s (หลัง tune kernel แล้ว)
• 8 streams พร้อมกัน: 542 tok/s รวม (มัธยฐาน 90.3 tok/s ต่อ stream)
• burst 64 streams: 830 tok/s โดยไม่ OOM
• context 256K ผ่านการทดสอบจริง (สถาปัตยกรรมรองรับถึง 1M)

น้ำหนักที่โหลดอยู่ใน HBM คือ 156.67 GB ซึ่งพอดีกับ 192GB เพราะ DeepSeek ส่ง V4 Flash มาที่ความละเอียดต่ำตั้งแต่ต้นทาง ไม่ใช่เพราะคนรัน quantize เพิ่ม — ดูใน config.json ของ Hugging Face จะเห็น expert_dtype: "fp4" โดยพารามิเตอร์ 296.35 พันล้านตัวจาก 304.18 พันล้านตัวถูกเก็บเป็น MXFP4 อัดในคอนเทนเนอร์ int8 ส่วนชั้น dense เป็น FP8 E4M3 ตัวโมเดลเองอัปโหลดขึ้น Hugging Face เมื่อ 31 กรกฎาคม ใบอนุญาต MIT ตอนนี้มี 2,340 likes และดาวน์โหลดไปแล้วกว่า 433,000 ครั้ง

สถาปัตยกรรมเป็น MoE แบบเบาบางมาก: 43 ชั้น, routed experts 256 ตัว + shared 1 ตัว, เปิดใช้แค่ 6 ตัวต่อ token — นี่คือเหตุผลที่โมเดล “304B” วิ่งได้ 168 tok/s บนการ์ดใบเดียว

บั๊กสามตัวที่ไม่ทำให้อะไร crash

ส่วนนี้คือของจริงของ repo และเป็นบทเรียนสำหรับใครก็ตามที่กำลังย้าย inference ไปฝั่ง AMD

1. FP8 คนละมาตรฐาน — ผิดไปเท่าตัวแบบเงียบ ๆ MI300X ใช้ FP8 E4M3 แบบ fnuz ของ AMD/Graphcore ขณะที่การ์ดรุ่นใหม่กว่าอย่าง MI325X และ MI355X ใช้ FP8 มาตรฐาน OCP kernel ที่เขียนโดยสมมติว่าเป็น OCP จะให้ ค่าคลาดเคลื่อนเป็นตัวคูณสอง บน MI300X ทางแก้คือเลือก float8e4b8 และตั้ง FP8_MAX=224.0 พร้อมสลับ write offset ตอนบีบอัด cache

2. routing ของ MoE ถูกทำลายตอนโหลดหนัก kernel ที่เลือก expert pad คอลัมน์ของบล็อกไว้ แต่ไปเทียบ mask กับขอบเขตของ tensor ทั้งก้อนแทนที่จะเทียบกับขนาดบล็อกเชิงตรรกะ ผลคือเมทริกซ์ routing เพี้ยนเมื่อมีโหลดเข้ามาพร้อมกัน อาการที่โผล่ออกมาฝั่งผู้ใช้คือ โมเดลเรียกชื่อ tool ที่ “เกือบถูก” และลืม schema เมื่อ prompt ยาว — อาการที่ทุกคนจะโทษโมเดลก่อนเสมอ ทางแก้คือเปลี่ยน mask เป็น (offs_local < BLOCK_SIZE) & (offs_global < nonzero_indx_size)

3. speculative decoding ที่ถูกต้องต้องแยกสาย noise การทำ DSpark บนสถาปัตยกรรม MLA ของ ROCm ต้องใช้การตรวจสอบแบบ causal multi-token และต้องแยกสาย Gumbel noise ของฝั่ง draft ออกจากฝั่ง rejection/recovery ไม่งั้นผลลัพธ์จะไม่ตรงกับ distribution เดิมเมื่อรันพร้อมกันหลาย request

จุดร่วมของทั้งสามคือ ไม่มีตัวไหนโยน exception เลย ระบบยังตอบ ยัง log ปกติ ยัง 200 OK — คุณภาพแค่ตกลงเงียบ ๆ

config ที่ควรลอกไปใช้

Stack คือ vLLM ROCm nightly (pin ที่ digest, เวอร์ชัน 0.26.1rc1.dev229), AITER สำหรับ attention และชั้น dense, Triton สำหรับ grouped MXFP4 experts, GEMM shape ที่ tune ไว้แล้ว 21 แบบสำหรับ gfx942 และ Caddy เป็น HTTPS proxy พร้อม IP allowlist

ค่าที่น่าลอกที่สุดไม่ใช่ค่าที่ทำให้เร็วขึ้น แต่คือค่าที่ทำให้ หน่วงน้อยลงอย่างคาดเดาได้: ตั้งงบ scheduler ไว้ 2,048 token และจำกัด long-prefill ไว้ที่ 1,024 token ผลคือ time-to-first-token ของ request สั้น ๆ ที่ต่อคิวอยู่หลัง prefill ก้อนใหญ่ ลดจาก 8.2 วินาที เหลือ 0.5 วินาที — เป็นการยอมแลก throughput รวมนิดหน่อยเพื่อให้ผู้ใช้ไม่ต้องรอ 8 วินาทีเพราะบังเอิญมีคนส่ง prompt ยาวเข้ามาก่อน

KV cache แบ่งเป็น 20GB บน GPU (fp8_ds_mla, บล็อกละ 256 token) และชั้น offload บน CPU อีก 96GB สำหรับ prefix cache รวมความจุ KV ได้ 1.93 ล้าน token คือรองรับ request ขนาด 256K ได้พร้อมกัน 7 ราย

ผู้เขียนระบุ upstream base revision ของทุกจุดที่แก้ไว้ และเครดิตงานตั้งต้นของ Fergus Finn และ Doubleword — ซึ่งแปลว่าแพตช์เหล่านี้ตามกลับไปหา upstream ได้ ไม่ใช่ fork ที่ลอยอยู่เฉย ๆ

มุมมอง AI Curator

เรื่องที่คนจะแชร์กันคือ “304B บนการ์ดใบเดียว” แต่เรื่องที่ควรจำคือบั๊กตัวที่สอง

ทีมไทยที่กำลังทำ agent อยู่ตอนนี้เจออาการเดียวกันเป็นประจำ: agent เรียก tool ผิดชื่อนิดเดียว, ลืม field ใน schema, พังเฉพาะตอน prompt ยาว แล้วเราก็แก้ด้วยการเขียน prompt ใหม่ เพิ่ม retry เปลี่ยนไปโมเดลอื่น หรือสรุปว่า “โมเดลเปิดมันก็แค่นี้แหละ” repo นี้แสดงให้เห็นว่าอาการชุดนั้น เป็นอาการของ routing kernel ที่คำนวณผิดได้ด้วย และไม่มีทางแยกออกจากกันเลยถ้าดูแค่ฝั่ง application

นี่คือต้นทุนที่ซ่อนอยู่ของการ self-host ที่แทบไม่มีใครพูดถึงเวลาเทียบราคาต่อ token กับ API — คุณไม่ได้แค่รับผิดชอบ uptime คุณรับผิดชอบ ความถูกต้องเชิงตัวเลข ของ stack ทั้งกอง และคุณจะไม่มีวันรู้ว่ามันผิด เพราะมันไม่ crash เมื่อรันโมเดลเปิดเอง สิ่งที่ต้องมีตั้งแต่วันแรกคือชุด eval ที่วัด tool-calling และ long-context โดยเฉพาะ รันหลังอัปเกรด kernel ทุกครั้ง ไม่ใช่แค่ smoke test ว่า endpoint ตอบ 200

อีกประเด็นที่มีนัยเชิงต้นทุนสำหรับภูมิภาคเรา: MI300X หาเช่าได้ในราคาที่ต่ำกว่า H200/B200 อยู่พอสมควร และเป็นการ์ดที่ผู้ให้บริการคลาวด์รายกลาง ๆ ในเอเชียมีของจริง ปัญหาที่ผ่านมาไม่ใช่ราคาแต่คือ “ไม่มีใครรับประกันว่ารันแล้วผลถูก” repo นี้ปิดช่องว่างตรงนั้นไปหนึ่งเปลาะ — แต่สังเกตว่ามันปิดได้เพราะมีคนหนึ่งคนยอมนั่งไล่ kernel ทีละตัวแล้วเปิดโค้ดให้ฟรี ไม่ใช่เพราะ vendor ทำมาให้ ถ้ากลยุทธ์ต้นทุนของคุณคือ “หนีไป AMD” ให้เผื่องบสำหรับคนที่ทำงานแบบนี้ไว้ในทีมด้วย

แหล่งข่าว

• ryanzhou/deepseek-v4-flash-mi300x — GitHub
• deepseek-ai/DeepSeek-V4-Flash-0731 — Hugging Face
• DeepSeek V4 Flash on a Single AMD MI300X — Hacker News