{{1}}Muse Spark Open{{/1}} บน AMD: การรองรับตั้งแต่วันแรก เกณฑ์ชั่วคราว และประตูที่ยังไม่มีใครรัน

Meta เปิดตัว Muse Spark Open เมื่อวันที่ 15 ตุลาคม 2026 และในเย็นวันเดียวกันนั้นเอง ก็มี pull request ฉบับร่างไปลงใน SGLang ซึ่งชื่อเรื่องอ่านแล้วไม่ค่อยเหมือนการประกาศฟีเจอร์ใหม่ เท่ากับเป็นการยอมรับว่า [AMD] เพิ่มเกตความแม่นยำ GSM8K + MMMU แบบ nightly สำหรับ Muse Spark Open บน MI35x เหตุผลที่มันมีอยู่ถูกระบุไว้อย่างชัดเจนในเนื้อความของ PR บน HIP โค้ดของโมเดลจะส่งต่อไปยัง implementation บน ROCm แยกต่างหาก — sglang.srt.rocm_muse_spark — และไม่มีงาน continuous integration ใดในโปรเจกต์ที่ครอบคลุมส่วนนี้ ตามคำบอกเล่าของผู้เขียนเอง เกตใหม่นี้ยังไม่เคยถูกรันบนฮาร์ดแวร์จริง หนึ่งในสองเกณฑ์ผ่าน/ไม่ผ่านของมันเป็นเพียงค่าตัวอย่างที่คิดขึ้นมาเพราะไม่มีผลการวัดจาก AMD ให้ใช้ และงาน CI นี้ต่อให้รันวันนี้ก็จะล้มเหลวตั้งแต่ขั้นตอนแรกอยู่ดี นี่ไม่ใช่เรื่องราวการเปิดตัว แต่มันเป็นร่องรอยรูปร่างคล้ายการรั่วไหล ว่าการเอาโมเดล open-weight ขนาด 8.16 แสนล้านพารามิเตอร์ไปรันบนฮาร์ดแวร์ AMD จริง ๆ แล้วมีหน้าตาอย่างไรเมื่อมองจากภายใน serving framework

สิ่งที่ pull request เพิ่มเข้ามาจริง ๆ

เกตคืองาน nightly หนึ่งงานที่ครอบคลุมเช็กพอยต์ FP4 ทั้งสองรายการในสูตร cookbook “Low Latency” ของ MI355X ของโปรเจกต์ ในคำศัพท์ของโปรเจกต์เอง:

• ชุดทดสอบ — nightly-amd-4-gpu-mi35x-muse-spark-open งาน nightly-4-gpu-mi35x-muse-spark-open บนรันเนอร์ linux-mi35x-gpu-8 ที่ TP4 โดยมีขีดจำกัด 21,600 วินาทีต่อไฟล์

• สองเซิร์ฟเวอร์ สองคลาส — หนึ่งตัวต่อหนึ่งเช็กพอยต์ เพราะเซลล์ NVFP4 ใช้เส้นทางการโหลดที่แตกต่างจากของ MXFP4 MXFP4 โหลด amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 โหลดเช็กพอยต์ -NVFP4ของ Meta repo ด้วย --quantization quark_mxfp4 ซึ่งจะทำการ requantize เป็น MXFP4 ในตอนโหลด

• แฟล็กสูตร — TP4/EP4, AITER attention ที่ขนาดเพจ 16, MUSE_MOE_BACKEND=flydsl, DFlash2 พร้อมแบ็กเอนด์ draft-attention ของ Triton

• สิ่งที่วัด — GSM8K แบบ full-split ผ่าน sgl-eval โดยเปิดโหมด thinking, reasoning_effort=xhigh, โทเคนสูงสุด 32,768, อุณหภูมิ 1.0, top_p 0.95 รวมถึงตัวอย่าง MMMU 100 ตัวอย่างสำหรับเส้นทางมัลติโมดัล

• เวลาจริง — ตัวรัน 8-GPU ตัวเดียวให้บริการเช็กพอยต์ทั้งสองตัวตามลำดับ ใช้เวลาประมาณสี่ชั่วโมง

การรวม MMMU เข้าไว้ด้วยคือรายละเอียดที่ทำให้ PR นี้น่าอ่าน ตามที่ผู้เขียนกล่าวไว้ บน HIP โมเดลจะดิสแพตช์เข้าสู่อิมพลีเมนเทชัน ROCm และเส้นทางของภาพผ่านอิมพลีเมนเทชันนั้นไม่ได้ถูกทดสอบในด้านอื่น ดังนั้น ณ ตอนที่เขียนสิ่งนี้ vision tower จึงเป็นส่วนที่ถูกทดสอบน้อยที่สุดของ Muse Spark Open บนซิลิคอน AMD

ตัวเลขสองตัวใน PR และที่มาของมัน

ที่นี่ไม่มีการวัดผล Muse Spark Open บนฮาร์ดแวร์ AMD และ PR ก็บอกไว้เช่นนั้น

• GSM8K 0.93 — ยกมาทั้งชุดจากการทดสอบ B300 Muse Spark ใน PR Day-0 B300 คือ NVIDIA Blackwell Ultra ค่าขีดจำกัด การตั้งค่าการสุ่ม และการตั้งค่าการให้คะแนน ล้วนถูกยกมาจากงาน Hopper-class-to-Blackwell ไปยังสแต็กตัวเร่งความเร็วที่แตกต่างกันโดยสิ้นเชิง

• MMMU 0.50 — ระบุใน PR ว่า "เป็นตัวแทนชั่วคราวที่ไม่มีผลการวัดของ AMD รองรับอยู่เบื้องหลัง" นั่นตรงไปตรงมาอย่างผิดปกติสำหรับไฟล์ CI และคุ้มค่าที่จะทำความเข้าใจว่าทำไมมันจึงสำคัญกว่าที่เห็น เกตที่มีพื้นขั้นต่ำซึ่งกุขึ้นมาไม่ใช่การตรวจสอบความถูกต้อง แต่เป็นลวดกับดัก มันจะจับการถดถอยรุนแรง และจะปล่อยผ่านการถดถอยเล็กน้อยไปอย่างเงียบ ๆ หากคะแนน MMMU จริงของ MI355X ออกมาเป็น 0.68 เกตนี้จะยอมให้ร่วงลงได้หกจุดก่อนที่มันจะทำงาน

• DFlash2 ความยาวที่ยอมรับ — รายงานไว้ในสรุปขั้นตอนของงาน โดยจงใจไม่กำหนดเป็นเกต ดังนั้นเส้นทางการถอดรหัสแบบคาดการณ์จึงสังเกตได้แต่ไม่มีการป้องกัน: โมเดลร่างที่เงียบ ๆ หยุดทำนายได้ดีจะไปปรากฏในสรุปที่ไม่มีใครตั้งการแจ้งเตือนไว้

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

ประตูถูกปิดกั้น และเหตุผลก็เป็นเรื่องธรรมดาสามัญ

PR นี้จะคงอยู่ในสถานะฉบับร่างจนกว่า PR สนับสนุน Day-0 จะ merge เข้ามา ซึ่งถือเป็น dependency ปกติ ตัวที่บล็อกอยู่น่าสนใจกว่าคือชุดแพตช์ AMD AITER แพตช์เหล่านั้นผ่านการตรวจสอบกับ AITER รีวิชันหนึ่ง (4ad9983) แต่ ROCm Dockerfile บน main กลับ pin ไว้ที่อีกรีวิชันหนึ่ง (2bb5491) เมื่อเทียบกับรีวิชันที่ pin ไว้ 04-aiter-muse-moe-flydsl.patch apply ได้เรียบร้อย ส่วนครึ่งที่เป็น AITER ของ 03-plan-b-aiter-unified-attention-3d.patch กลับ apply ไม่ผ่าน เพราะ aiter/ops/triton/attention/unified_attention.py ถูก refactor หลังจากที่ตัดแพตช์เหล่านั้นออกมา ผู้เขียนยังไม่ได้ตรวจสอบแพตช์ตัวที่สาม ซึ่งพุ่งเป้าไปที่ submodule composable_kernel จนกว่าแพตช์ตัวที่สองจะ apply ได้ งานก็จะล้มเหลวก่อนที่จะได้ประเมินอะไรเลย

จงอ่านสิ่งนั้นเป็นสัญญาณเกี่ยวกับวุฒิภาวะ มากกว่าจะเป็นข้อกล่าวหา เส้นทางการให้บริการของ AMD สำหรับโมเดล mixture-of-experts ขนาดใหญ่มากกำลังถูกสร้างใหม่ continuously ใน upstream และ vendor lockfile คือสิ่งที่ทำให้ชุดแพตช์ซึ่งทำให้โมเดลรันได้ตั้งแต่แรกนั้นพังพอดี

วันแรกที่ AMD ไม่ใช่วันแรกจริง ๆ

การที่เกตไม่ถูกรันไม่เหมือนกับเส้นทาง AMD เป็นของใหม่ ไทม์ไลน์โดยรอบเล่าเรื่องได้ครบถ้วนกว่าทั้งโพสต์เปิดตัวหรือ PR

• อาร์ติแฟกต์การควอนไทซ์ของ AMD เกิดขึ้นก่อนการเปิดตัวราวสี่สัปดาห์ — โดย Quark-MXFP4 และ Quark-PTPC-FP8 เช็กพอยต์สำหรับ Muse Spark Open ถูกเผยแพร่ไปยัง Hugging Face เมื่อวันที่ 18 กันยายน 2026 ซึ่งราวหนึ่งเดือนก่อนที่ Meta จะประกาศน้ำหนัก

• การรองรับของเฟรมเวิร์กเปิดให้ใช้งานตั้งแต่วันเปิดตัว — ของ SGLang [Day0] รองรับ Muse Spark Open PR และของ vLLM [Model] เพิ่มการรองรับ Muse Spark Open PR ถูกเปิดทั้งคู่ภายในเวลาห่างกันสิบสองนาทีในวันที่ 2026-10-15 ซึ่งนี่คือหน้าตาของการประสานงานแบบ day-zero ที่แท้จริง

• คู่มือการบิลด์ของ Meta เองให้สูตรสำหรับ AMD มา — FP8 (Quark) สำหรับ Instinct MI355X ที่ให้บริการผ่าน vLLM และ MXFP4 (Quark) สำหรับ MI350X และ MI355X พร้อมเส้นทาง Intel MXFP4 ที่ออกแบบสำหรับการ์ดขนาด 160 GB จำนวนสี่ใบ และเส้นทาง INT4 Xeon 6 สำหรับการใช้งานแบบออฟไลน์

• Meta เผยแพร่ตัวเลขปริมาณงานสำหรับ AMD โดยเฉพาะ — โมเดลร่าง DFlash V2 ให้ปริมาณงาน 3.7 เท่าสำหรับคำขอเดียวบน MI355X และ 2.9 เท่าเมื่อมีคำขอพร้อมกัน 16 รายการ โดยมีโทเคนที่ร่างขึ้นและได้รับการยอมรับ 6.4 โทเคนต่อขั้นตอน; เคอร์เนล Helion ที่กำหนดเองใน SGLang ได้รับการยกเครดิตว่าช่วยเพิ่มความเร็วระดับเคอร์เนล 1.03–3.95 เท่าทั้งบน NVIDIA และ AMD และเพิ่มประสิทธิภาพแบบ end-to-end 3% บน MI350

ดังนั้น เรื่องนี้ไม่ใช่ "การรองรับ AMD มาช้า" แต่เป็นการที่การรองรับ AMD มาถึงพร้อมกับทั้งความพร้อมที่ซ้อมมาแล้วและยังไม่ได้วัดผลในเวลาเดียวกัน: อาร์ติแฟกต์ สูตร และการเร่งความเร็วพร้อมหมดแล้ว แต่ตัวเลขความแม่นยำยังไม่พร้อม ซึ่งเป็นช่องว่างที่ด่าน nightly มีไว้เพื่อปิดพอดี

ในขณะเดียวกัน ตัวเลขอิสระบอกอะไร

แม้ว่าความแม่นยำของ AMD จะยังไม่ได้รับการคลี่คลาย ภาพรวมโดยรวมกลับชัดเจน Artificial Analysis จัดให้ Muse Spark Open อยู่ที่ Intelligence Index 39 เป็นอันดับ 9 จาก 118 โมเดลในชุดเปรียบเทียบของตน โดยมีค่ามัธยฐานที่ 19 ในบรรดาโมเดลที่เทียบเคียงได้ — ซึ่งเป็นผลลัพธ์ที่แข็งแกร่ง จุดที่ต้องระวังอยู่ที่ราคา: 1.25 ดอลลาร์ต่อ 1 ล้านโทเคนอินพุต และ 4.25 ดอลลาร์ต่อ 1 ล้านโทเคนเอาต์พุต พร้อมส่วนลดแคช 88% อัตราผสม 0.78 ดอลลาร์ และค่าใช้จ่าย 0.84 ดอลลาร์ต่องาน Intelligence Index ซึ่งอยู่อันดับ 32 จาก 40 ในมาตรวัดประสิทธิภาพด้านนั้น ความเร็วเอาต์พุตถูกระบุว่าไม่มีข้อมูล และรายการนี้บันทึกอินพุตที่เป็นข้อความและรูปภาพ ขณะที่คำกล่าวอ้างของผู้ขายเองระบุว่ามีข้อความ รูปภาพ วิดีโอ และเสียง — เป็นความไม่สอดคล้องที่ยังไม่ได้รับการคลี่คลาย ซึ่งควรค่าแก่การตั้งข้อสังเกตมากกว่าการชี้ขาด ตัวเลขเหล่านั้นเป็นอิสระและไม่ผูกกับผู้ขายรายใด; ส่วนตัวเลข AMP ข้างต้นเป็นของ Meta

เวอร์ชันสั้น ๆ ถ้าคุณกำลังตัดสินใจวันนี้

หากความจุของคุณคือ AMD และคุณกำลังวางแผนจะโฮสต์ Muse Spark Open ด้วยตนเองบน MI355X จุดยืนที่ซื่อตรงก็คือคุณคือผู้วัดเอง มีเส้นทางการให้บริการแบบ day-zero ที่ครบถ้วน มีสูตรการทำ quantization ต่อ accelerator มีความเร็วจาก speculative-decoding ที่เผยแพร่แล้ว และ ณ เวลาที่เขียนนี้ ยังไม่มีคะแนนความแม่นยำที่เผยแพร่สำหรับ FP4 cell ใด ๆ บนซิลิคอนของ AMD PR ให้สิ่งที่มีประโยชน์กับคุณไม่ว่าจะอย่างไร: การตั้งค่าการประเมินของมันคือคำจำกัดความที่สมบูรณ์ พร้อมยกไปใช้ได้ทันที ว่าการตรวจสอบความแม่นยำอย่างจริงจังบนโมเดลนี้เป็นอย่างไร ไปจนถึง reasoning effort และ top_p รันมันกับ checkpoint ของคุณเองก่อนที่คุณจะให้ลูกค้าใช้งานมัน และจับตาดูการรันที่ผู้เขียนสัญญาไว้ แพตช์ AITER ที่ rebase แล้ว และเกณฑ์ MMMU ที่จะถูกแทนที่ด้วยคะแนนที่วัดได้

บันทึกเชิงปฏิบัติเกี่ยวกับการให้บริการสแต็กควอนไทเซชันอายุสี่สัปดาห์

กลไกหนึ่งใน PR ที่ควรค่าแก่การใส่ใจ เซลล์ NVFP4 ถูกโหลดด้วย --quantization quark_mxfp4 ซึ่งหมายความว่าเช็กพอยต์ต้นทางเป็น NVFP4 และรันไทม์จะควอนไทซ์ใหม่เป็น MXFP4 ตอนโหลด มีการเปรียบเทียบไปป์ไลน์ที่ต่างกันเชิงตัวเลขสองชุดภายใต้ชุดทดสอบเดียวกัน ซึ่งเป็นเหตุผลว่าทำไมแต่ละชุดจึงได้เซิร์ฟเวอร์ของตัวเอง คลาสของตัวเอง และบรรทัดผ่าน/ไม่ผ่านของตัวเอง แนวทางของ Meta เองระบุว่าบิลด์ AMD FP8 (Quark) ให้ความแม่นยำเทียบเท่า BF16 บน GSM8K แต่ข้อกล่าวอ้างนั้นเป็นเรื่องของ FP8 ไม่ใช่เกี่ยวกับเซลล์ FP4 ใด ๆ และเป็นการวัดจากผู้ขาย หากคุณกำลังเลือกการควอนไทซ์สำหรับโปรดักชัน ให้ถือว่าเซลล์ FP4 ยังไม่ได้รับการยืนยันจนกว่าจะมีใครเผยแพร่ตัวเลขนั้น

นี่คือจุดที่เลเยอร์การกำหนดเส้นทางพิสูจน์คุณค่าของตัวเอง ความไม่แน่นอนเหล่านี้ไม่มีอยู่เลยสำหรับผู้อ่านที่เรียกใช้ปลายทางแบบโฮสต์ — แต่ถ้าคุณเป็นคนที่ต้องตัดสินใจเรื่องการโฮสต์เอง วิธีลดความเสี่ยงของโมเดลที่ยังไม่ผ่านการพิสูจน์ก็คือการส่งปริมาณทราฟฟิกส่วนเล็ก ๆ ไปที่มัน ผ่านสิ่งที่สามารถย้ายทราฟฟิกกลับได้ ปัจจุบัน OrcaRouter กำหนดเส้นทางให้ Muse Spark 1.2 และ Muse Spark 1.1 และไม่ได้กำหนดเส้นทางให้ Muse Spark Open ดังนั้นสิ่งที่กล่าวถึงในที่นี้จึงไม่ใช่ข้ออ้างเรื่องการโฮสต์โมเดลใหม่ แต่เป็น API เดียวที่ครอบคลุมกว่า 200 โมเดล โดยมี การสลับสำรองอัตโนมัติเมื่อผู้ให้บริการมีประสิทธิภาพลดลง และ DSL สำหรับกำหนดเส้นทางเพื่อแบ่งทราฟฟิกระหว่างโมเดลและผู้ให้บริการผ่านการตั้งค่าแทนการแก้ไขโค้ด เราส่งต่อราคาตามรายการของผู้ให้บริการโดยไม่บวกกำไร 0% ซึ่งเป็นสิ่งที่ทำให้การรันแบบขนานอย่างระมัดระวังมีต้นทุนต่ำพอที่จะทำได้จริง

สำหรับตัว Muse Spark Open เอง ความพร้อมใช้งานในวันนี้ต้องผ่าน API ของ Meta เองและแพลตฟอร์มอินเฟอเรนซ์ของบุคคลที่สามหลายแห่ง รวมถึงการดาวน์โหลดเวตบน Hugging Face และแค็ตตาล็อกโมเดลบนคลาวด์สองแห่งที่ Meta ระบุชื่อ สำหรับ AMD วิธีที่เร็วที่สุดที่จะได้ตัวเลขที่เชื่อถือได้คือเกตใน PR นี้ — เมื่อมีใครสักคนรันมัน

ดูอะไรดี

• การ merge PR ใน Day-0 — ด่านตรวจสอบความแม่นยำไม่สามารถ merge ได้ก่อนหน้านั้น และเมื่อมันมาถึง นั่นคือช่วงเวลาที่โค้ดของโมเดลเองกลายเป็น baseline แทนที่จะเป็น snapshot

• การ rebase แพตช์ AITER — โดยเฉพาะส่วน AITER ของแพตช์ unified-attention เทียบกับ pinned revision จนกว่าจะ apply ได้ ชุดทดสอบ AMD จะเป็นสีแดงด้วยเหตุผลที่ไม่เกี่ยวข้องกับโมเดลเลย

• เกณฑ์ MMMU ที่ขยับออกจาก 0.50 — ในจังหวะที่คะแนน MI355X ของจริงเข้ามาแทนที่ค่าชั่วคราว ด่านมัลติโมดัลก็เริ่มทำงาน

• รายงานการรันที่เผยแพร่ต่อสาธารณะครั้งแรก — ผู้เขียนได้ให้คำมั่นว่าจะโพสต์ผลการรันบนอิมเมจทั้งสามก่อนจะทำเครื่องหมายว่า PR พร้อมใช้งาน นั่นคือค่าความแม่นยำของ AMD ครั้งแรกสำหรับ Muse Spark Open และค่านั้นจะมาจากชุดทดสอบ ไม่ใช่สไลด์นำเสนอของผู้จำหน่าย

• ว่าตัวเลขของ NVIDIA และ AMD จะแตกต่างกันหรือไม่ — หาก GSM8K ยังคงอยู่ที่ราว 0.93 บน MI355X ขณะที่ MMMU อยู่ในระดับต่ำกว่าอย่างมีนัยสำคัญเมื่อเทียบกับแพลตฟอร์มอื่นใด เส้นทางด้านวิชันบน ROCm ก็คือประเด็นสำคัญ และ PR ของเฟรมเวิร์กที่เพิ่มเกตเข้ามาก็จะเป็นที่แรกที่สิ่งนี้ปรากฏให้เห็น

สำหรับใครก็ตามที่ติดตามว่าโมเดลเรือธงแบบเปิดน้ำหนักไปถึงฮาร์ดแวร์ระดับรองได้จริงอย่างไร นี่คือไฟล์ที่ควรเปิดค้างไว้ โพสต์เปิดตัวบอกคุณว่าโมเดลนี้พร้อมใช้งานบน AMD พูลรีเควสต์บอกคุณว่า ณ วันที่ 15 ตุลาคม 2026 ยังไม่มีใครตรวจสอบว่ามันยังใช้งานได้ดีอยู่ที่นั่นหรือไม่