รัน Kimi K3 (2.8T) บน AMD MI355X ได้ 952 tok/s ต่อโหนด — Wafer ชี้ประสิทธิภาพต่อดอลลาร์ชนะ B300 ทั้งที่ throughput ต่ำกว่า 1.65 เท่า

วันที่ 31 กรกฎาคม 2026 Ian Ye จาก Wafer (ผู้ให้บริการ inference แบบ serverless) เผยแพร่บทความชื่อ “Is memory the moat?” รายงานผลการเสิร์ฟ Kimi K3 โมเดลโอเพนเวตขนาด 2.8 ล้านล้านพารามิเตอร์ บนการ์ด AMD MI355X เทียบกับ NVIDIA B300 และ B200 — และข้อสรุปคือ AMD ชนะขาดในมิติที่คนจ่ายเงินสนใจที่สุด คือ ประสิทธิภาพต่อดอลลาร์

ที่มาของโจทย์คือขนาดโมเดล K3 กินพื้นที่ เกิน 1.5TB VRAM ก่อนจะจัดสรร KV cache สำหรับคอนเท็กซ์ 1 ล้านโทเคนด้วยซ้ำ ซึ่งแปลว่าโหนด B200 (8 ใบ ใบละ 192GB) ใส่ไม่ลง เหลือทางเลือกแค่โหนด B300 ที่มี VRAM 288GB ต่อใบ หรือจับ B200 สองโหนดมาต่อกันเป็น TP16 — และการ์ดตัวอื่นที่มี 288GB เท่ากับ B300 ก็คือ MI355X นั่นเอง

ตัวเลข

เบนช์มาร์กใช้อินพุต 1,024 โทเคน / เอาต์พุต 400 โทเคน

	8× MI355X (TP8)	2×8 B200 (TP16)	B300 (TP8+DCP8)
decode ต่อสตรีม	118 tok/s	90 tok/s	172 tok/s
aggregate สูงสุด	952 tok/s	498 tok/s	1,568 tok/s
aggregate ต่อ GPU	119 tok/s	31 tok/s	196 tok/s
ต่อ $/GPU-ชม.	48 tok/s/$	7 tok/s/$	33 tok/s/$

ตัวเลขแถวสุดท้ายคิดบนสมมติฐานราคาเช่า $2.50/GPU-ชม. สำหรับ MI355X, $6.00 สำหรับ B300 และ $4.25 สำหรับ B200 — บทความระบุว่า MI355X ถูกกว่า B300 ราว 2.4 เท่าและถูกกว่า B200 ราว 1.7 เท่าต่อใบโดยเฉลี่ย

สรุปเป็นภาษาคน: B300 ยังเร็วกว่าราว 1.65 เท่าในแง่ throughput รวม แต่ราคาแพงกว่า 2.4 เท่า ผลลัพธ์จึงกลับด้านเมื่อหารด้วยเงิน ส่วน B200 แพ้ทั้งสองทาง — แต่บทความก็แก้ต่างให้ตรง ๆ ว่าตัวเลข B200 ถูกกดลงจากการที่มันเป็นคอนฟิกเดียวที่ข้ามสองโหนด จึงต้องจ่ายค่า cross-node all-reduce บนเส้นทางวิกฤตของ decode (RoCE v2 ราว 195 Gb/s) และนั่นคือประเด็นทั้งหมด: K3 คือหนึ่งในโมเดลแรก ๆ ที่การเน้นความจุ HBM ของ MI355X กลายเป็นข้อได้เปรียบที่วัดได้จริง

สองบั๊กที่ต้องแก้เอง — และวิธีแก้ที่สั้นกว่าที่คิด

ส่วนที่มีค่าที่สุดของบทความสำหรับคนที่ต้องลงมือเสิร์ฟเอง คือรายละเอียดว่า “AMD ใช้ได้แล้ว” หมายความว่าอย่างไรในทางปฏิบัติ

หนึ่ง — speculative decoding พังบน ROCm K3 ไม่ได้แถม draft tensor มาเลย ไม่มี MTP ไม่มี EAGLE เส้นทางเดียวที่เหลือคือใช้ draft model ภายนอกอย่าง Kimi-K3-DSpark ของ RadixArk ซึ่งบน CUDA รันได้เลย แต่บน ROCm รีเควสต์แรกทำ scheduler ล้มด้วย NameError: name 'top_k_renorm_prob' is not defined สาเหตุคือ verifier ของ sglang มีเส้นทางสร้าง target distribution สองแบบ แบบ dense เรียก top_k_renorm_prob จาก sgl_kernel ส่วนบิลด์ ROCm ผูก alias ไว้แค่ Triton kernel ของ top-p — พอรีเควสต์ตกลงเส้นทาง dense ก็ระเบิดทันที

วิธีแก้คือ ฟังก์ชัน PyTorch ธรรมดาตัวเดียว: เรียง, mask, หาร แล้ววางลงในสาขา sampling ของ ROCm ประโยคที่ผมคิดว่าเป็นบทเรียนจริงของบทความนี้คือ “the reflex on ROCm is to assume you need one [a custom kernel], but here it was a missing definition, not a missing kernel” — ผลที่ได้คือ เร็วขึ้นราว 2.2 เท่าต่อสตรีมเดี่ยว, ราว 1.7 เท่าที่โหลดปานกลาง และ aggregate สูงสุดเพิ่ม 18% โดยจุด peak ขยับไปอยู่ที่ concurrency สูงขึ้นมาก (c64 เทียบกับ c24 ตอนไม่มี spec dec)

สอง — prefill ช้าจนใช้งานไม่ได้ อันนี้สำคัญกว่าที่หลายคนคิด เพราะบทความเถียงตรง ๆ ว่า decode tok/s คือ fool’s gold ขณะที่ time-to-first-token คือสิ่งที่ผู้ใช้รู้สึกจริง และ MI355X แพ้ตรงนี้หนัก: prefill เย็น 172,000 โทเคนชุดเดียวกันใช้เวลา ~51 วินาทีบน MI355X เทียบ ~23 วินาทีบน B300

ต้นเหตุคือเคอร์เนลตัวเดียว — K3 บน ROCm ตกไปใช้ Triton attention แบบทั่วไปที่ช้า เพราะเคอร์เนล AITER MLA ตัวเร็วโหลดไม่ขึ้น และเหตุผลไม่ใช่ “ไม่มีเคอร์เนล” แต่เป็น รูปร่างไม่ตรงกัน: K3 ที่ TP8 ให้ 12 attention head ต่อ rank ขณะที่เส้นทาง MLA ของ AITER สร้างมาสำหรับ 4, 8 หรือจำนวนที่หารด้วย 16 ลงตัว วิธีแก้คือ เติมศูนย์ให้ head จาก 12 เป็น 16 รันเคอร์เนลเร็ว แล้วดึง 12 head จริงออกจากผลลัพธ์ ผลคือ prefill วิ่งที่ราว 13k tok/s เทียบกับ 4–7k ของ Triton fallback เร็วขึ้น 2–3 เท่า — บทความย้ำว่านี่ไม่ได้ขยับตัวเลข throughput ในตารางข้างบนเลย เพราะมันเป็นคันโยกของ TTFT ล้วน ๆ

บทสรุปของทีมคือ SOTA บน AMD ใกล้เข้ามาแล้ว งานที่ต้องทำน้อยกว่าตอนเสิร์ฟ GLM5.2 และรอบนี้ ไม่ต้องเขียน custom kernel เลย ปิดท้ายด้วยคำถามว่า “คูเมือง CUDA ตายแล้วหรือยัง?”

มุมมอง AI Curator

ข้อควรระวังก่อน: Wafer ขาย inference และบทความนี้คือการสาธิตว่าทีมเขาเก่งเรื่องรีดประสิทธิภาพบนฮาร์ดแวร์ที่ถูกกว่า นั่นไม่ได้ทำให้ตัวเลขผิด แต่แปลว่าควรอ่านเป็นผลของ ทีมที่ตั้งใจปรับจูน ไม่ใช่ผลของ การกด deploy นอกจากนี้บทความไม่ได้ระบุ quantization/precision ที่ใช้ ไม่ได้ระบุเวอร์ชัน ROCm/sglang และวัดบนรูปทรงโหลดเดียว (1024 เข้า / 400 ออก) ซึ่งเป็นโหลดที่เอื้อต่อ decode มากกว่าโหลด agent จริงที่คอนเท็กซ์บวมเรื่อย ๆ — ตัวเลข TTFT 51 วินาทีนั่นแหละคือสัญญาณเตือนสำหรับ workload แบบหลัง

แต่ข้อสรุปเชิงโครงสร้างยังยืนอยู่ได้ และผมคิดว่ามันสำคัญกว่าตัวเลขใดตัวเลขหนึ่ง: เมื่อโมเดลโอเพนเวตโตจนใส่โหนดเดียวไม่ลง ความจุ HBM กลายเป็นข้อจำกัดที่ผูกปมก่อนความเร็วดิบ ทันทีที่โมเดลไม่พอดีโหนด คุณต้องจ่ายค่าเครือข่ายข้ามโหนดบนเส้นทางวิกฤตของทุกโทเคน ซึ่งตัวเลข B200 ที่ 7 tok/s/$ เทียบกับ 48 ของ MI355X แสดงให้เห็นชัดมากว่าแพงแค่ไหน นี่คือแกนการแข่งขันที่ AMD เลือกไว้ถูกจังหวะพอดี

สำหรับคูเมือง CUDA ผมคิดว่าคำตอบไม่ใช่ “ตายแล้ว” แต่คือ คูเมืองเปลี่ยนหน่วยวัดจาก “ทำไม่ได้” เป็น “กี่วัน-คน” สังเกตว่าปัญหาทั้งสองที่ Wafer เจอไม่ใช่ปัญหาคณิตศาสตร์หรือฮาร์ดแวร์เลย — ตัวหนึ่งคือฟังก์ชันที่ไม่ได้ประกาศไว้ อีกตัวคือ head count ที่ไม่หารลงตัว ทั้งคู่แก้ได้ในไม่กี่บรรทัด แต่ต้องมีคนที่อ่านสแตกลงไปถึงชั้นเคอร์เนลได้ และคนแบบนั้นนี่แหละคือของหายากจริง ไม่ใช่ GPU

สำหรับไทยและ SEA มุมที่ผมอยากให้คิดต่อคือ ตัวเลข tok/s/$ ทั้งตารางขึ้นกับสมมติฐานราคาเช่าล้วน ๆ และราคาเช่า GPU ในภูมิภาคเราไม่ได้เป็นไปตามราคาตลาดสหรัฐฯ ส่วนต่างราคา MI355X กับ B300 ที่ 2.4 เท่าอาจหดเหลือ 1.5 เท่าหรือขยายเป็น 3 เท่าก็ได้ ขึ้นกับว่าผู้ให้บริการรายไหนมีของและมีคิวรอนานแค่ไหน ทีมที่กำลังตัดสินใจซื้อหรือเช่าควร เอาสูตรจากบทความนี้ไปแทนราคาที่ตัวเองได้จริง แทนที่จะจำข้อสรุปว่า “AMD คุ้มกว่า” ไปเฉย ๆ

และประเด็นที่ผมคิดว่าเป็นข่าวดีที่สุดสำหรับภูมิภาคนี้: ตัวเลือกฮาร์ดแวร์สำหรับเสิร์ฟโมเดลโอเพนเวตระดับบนสุดเพิ่งเพิ่มขึ้นเป็นสองราย สำหรับประเทศที่การจัดหา GPU ระดับสูงติดทั้งเรื่องโควตา ราคา และเวลารอ การมีเส้นทางที่สองที่พิสูจน์แล้วว่าใช้งานได้จริง มีค่ามากกว่าส่วนต่าง throughput 1.65 เท่าเสียอีก

แหล่งข่าว

• Is memory the moat? — Wafer, 31 ก.ค. 2026
• Day 0 Kimi-K3 Inference Deployment with Atom on AMD Instinct MI355X GPUs — AMD
• Running Kimi K3 on MI355X at Better Performance per Dollar Than B300 — Hacker News, 2 ส.ค. 2026