Muse Spark mở trên AMD: Hỗ trợ ngay từ ngày đầu, một ngưỡng tạm thời, và một cổng chưa ai từng chạy qua

Meta đã phát hành Muse Spark Open vào ngày 15 tháng 10 năm 2026, và ngay tối hôm đó, một pull request dạng nháp đã được đưa vào SGLang với tiêu đề đọc lên không giống một tính năng mới mà giống một lời thú nhận: [AMD] Add a Muse Spark Open MI35x nightly GSM8K + MMMU accuracy gate. Lý do nó tồn tại được ghi rõ trong phần thân của PR. Trên HIP, phần mã của mô hình chuyển hướng sang một triển khai ROCm riêng — sglang.srt.rocm_muse_spark — và không có job tích hợp liên tục nào trong dự án bao phủ nó. Theo chính lời tác giả, cổng kiểm tra mới này chưa từng được chạy trên phần cứng, một trong hai ngưỡng đạt/không đạt của nó chỉ là một giá trị tạm bợ được nghĩ ra vì không có phép đo nào từ AMD để dùng, và job CI này hôm nay cũng sẽ thất bại ngay ở bước đầu tiên. Đây không phải là một câu chuyện ra mắt. Đây là một dấu vết mang hình dáng của một vụ rò rỉ, cho thấy việc đưa một mô hình trọng số mở 816 tỷ tham số lên phần cứng AMD thực sự trông như thế nào từ bên trong một framework phục vụ.

Pull request thực sự bổ sung những gì

Cổng kiểm soát là một tác vụ chạy hằng đêm bao quát cả hai checkpoint FP4 trong công thức cookbook "Low Latency" MI355X của dự án. Theo cách nói của chính dự án:

• Bộ kiểm thử — nightly-amd-4-gpu-mi35x-muse-spark-open, tác vụ nightly-4-gpu-mi35x-muse-spark-open trên linux-mi35x-gpu-8 runner tại TP4, với giới hạn 21.600 giây cho mỗi tệp.

• Hai máy chủ, hai lớp — mỗi checkpoint một lớp, vì cell NVFP4 đi theo đường tải khác với cell MXFP4. MXFP4 tải amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 tải checkpoint -NVFP4 của repo Meta với --quantization quark_mxfp4, được tái lượng tử hóa thành MXFP4 tại thời điểm tải.

• Cờ recipe — TP4/EP4, attention AITER ở kích thước trang 16, MUSE_MOE_BACKEND=flydsl, DFlash2 với backend attention nháp Triton.

• Những gì được đo lường — GSM8K full-split qua sgl-eval với thinking bật, reasoning_effort=xhigh, tối đa 32,768 token, temperature 1.0, top_p 0.95, cùng 100 mẫu MMMU cho luồng multimodal.

• Thời gian thực — một máy chạy 8 GPU phục vụ lần lượt cả hai checkpoint, mất khoảng bốn giờ.

Việc đưa MMMU vào là chi tiết khiến PR này đáng đọc. Như tác giả diễn đạt, trên HIP, mô hình điều phối vào một bản triển khai ROCm và đường đi của hình ảnh xuyên qua bản triển khai đó vốn chưa được kiểm thử — vì vậy, vào thời điểm bài viết này được tạo ra, vision tower là phần ít được vận hành nhất của Muse Spark Open trên silicon AMD.

Hai con số trong PR, và chúng đến từ đâu

Ở đây không có gì là kết quả đo lường Muse Spark Open trên phần cứng AMD, và PR cũng nói như vậy.

• GSM8K 0.93 — lấy nguyên xi từ bài kiểm tra B300 Muse Spark trong PR Day-0. B300 là NVIDIA Blackwell Ultra. Ngưỡng, các thiết lập lấy mẫu và cấu hình tính điểm đều được mang nguyên từ công việc chuyển từ lớp Hopper sang Blackwell để áp lên một ngăn xếp tăng tốc hoàn toàn khác.

• MMMU 0.50 — được mô tả trong PR là “một placeholder không có phép đo AMD nào đằng sau nó”. Điều đó thẳng thắn một cách bất thường đối với một tệp CI, và đáng để hiểu vì sao nó quan trọng hơn vẻ ngoài của nó. Một cổng với ngưỡng sàn bịa ra không phải là kiểm tra tính đúng đắn; nó là một dây bẫy. Nó sẽ bắt được một hồi quy thảm khốc và sẽ âm thầm cho qua một hồi quy nhẹ. Nếu điểm MMMU thực tế của MI355X hóa ra là 0.68, cổng này cho phép trượt sáu điểm trước khi nó kích hoạt.

• Độ dài chấp nhận của DFlash2 — được báo cáo trong phần tóm tắt bước của job, cố ý không được đặt cổng kiểm soát. Vì vậy, đường giải mã suy đoán có thể quan sát được nhưng không được bảo vệ: một mô hình nháp âm thầm ngừng dự đoán tốt sẽ xuất hiện trong một bản tóm tắt mà không ai đặt cảnh báo.

Điểm cuối cùng đó còn khái quát hơn cả PR này. Một cổng kiểm tra độ chính xác chạy hằng đêm đo lường mã mô hình mà framework phát hành, chứ không phải mô hình mà nhà cung cấp phục vụ bạn. Công thức lượng tử hóa khác, kích thước trang khác, backend attention khác, mô hình draft khác — và bạn đã nằm ngoài vùng bao mà cổng kiểm tra đó được viết ra để bao phủ.

Cổng bị chặn, và lý do thì tầm thường.

PR vẫn ở trạng thái bản nháp cho đến khi PR hỗ trợ Day-0 được hợp nhất, đây là một phụ thuộc bình thường. Điểm chặn thú vị hơn là bộ bản vá AMD AITER. Những bản vá đó được xác thực dựa trên một bản sửa đổi của AITER (4ad9983), nhưng Dockerfile ROCm trên main lại ghim một bản khác (2bb5491). Với bản sửa đổi được ghim, 04-aiter-muse-moe-flydsl.patch áp dụng sạch; phần AITER của 03-plan-b-aiter-unified-attention-3d.patch thì không, bởi vì aiter/ops/triton/attention/unified_attention.py đã được tái cấu trúc sau khi các bản vá được tạo. Tác giả chưa kiểm tra bản vá thứ ba, bản vá này nhắm đến mô-đun con composable_kernel. Cho đến khi bản thứ hai áp dụng được, job sẽ thất bại trước khi nó đánh giá bất cứ thứ gì.

Hãy coi đó là dấu hiệu về độ trưởng thành hơn là một lời cáo buộc. Các đường phục vụ của AMD cho những mô hình mixture-of-experts rất lớn đang liên tục được tái xây dựng ở thượng nguồn, và một lockfile của nhà cung cấp chính là thứ phá vỡ bộ bản vá đã giúp mô hình chạy được ngay từ đầu.

Ngày đầu tiên tại AMD thực ra không phải là ngày đầu tiên

Việc cổng chưa được chạy không giống với việc đường hướng AMD là mới. Dòng thời gian xung quanh kể một câu chuyện đầy đủ hơn so với cả bài đăng ra mắt lẫn thông cáo báo chí.

• Các artifact lượng tử hóa của AMD có trước thời điểm ra mắt khoảng bốn tuần — Quark-MXFP4 và Quark-PTPC-FP8, các checkpoint cho Muse Spark Open, đã được công bố lên Hugging Face vào ngày 2026-09-18, khoảng một tháng trước khi Meta công bố trọng số.

• Hỗ trợ framework đã được mở ngay trong ngày ra mắt — PR [Day0] Support Muse Spark Open của SGLang và PR [Model] Add Muse Spark Open support của vLLM đều được mở cách nhau chưa đầy mười hai phút vào ngày 2026-10-15 — đúng là biểu hiện của sự phối hợp thực sự ngay từ ngày đầu tiên.

• Hướng dẫn xây dựng của chính Meta cung cấp các công thức AMD — FP8 (Quark) cho Instinct MI355X được phục vụ qua vLLM, và MXFP4 (Quark) cho MI350X và MI355X, cùng với một đường MXFP4 của Intel được thiết kế cho bốn card 160 GB và một đường INT4 Xeon 6 dùng cho mục đích ngoại tuyến.

• Meta đã công bố thông lượng dành riêng cho AMD — mô hình draft DFlash V2 mang lại thông lượng gấp 3,7× cho một yêu cầu đơn lẻ trên MI355X và gấp 2,9× ở 16 yêu cầu đồng thời, với 6,4 token được draft chấp nhận mỗi bước; các kernel Helion tùy chỉnh trong SGLang được ghi nhận mang lại mức tăng tốc ở cấp kernel từ 1,03–3,95× trên cả NVIDIA lẫn AMD và mức tăng 3% từ đầu đến cuối trên MI350.

Vậy nên câu chuyện không phải là "hỗ trợ AMD đến muộn". Mà là hỗ trợ AMD đã đến trong trạng thái vừa được tập dượt sẵn vừa chưa được đo lường cùng một lúc: các artifact, các recipe và các mức tăng tốc đều đã sẵn sàng, còn con số độ chính xác thì chưa — và đó chính xác là khoảng trống mà một cổng chạy hằng đêm (nightly gate) tồn tại để lấp đầy.

Trong khi đó, những con số độc lập nói lên điều gì

Trong khi độ chính xác của AMD vẫn chưa ngã ngũ, bức tranh tổng thể thì đã rõ. Artificial Analysis xếp Muse Spark Open ở Intelligence Index 39, đứng thứ chín trong số 118 mô hình trong bộ so sánh của mình, với trung vị là 19 trên các mô hình tương đương — một kết quả mạnh mẽ. Giá mới là điểm đáng thận trọng: 1,25 USD cho mỗi triệu token đầu vào và 4,25 USD cho mỗi triệu token đầu ra, với chiết khấu bộ nhớ đệm 88%, mức giá kết hợp 0,78 USD và 0,84 USD chi phí cho mỗi tác vụ Intelligence Index, xếp thứ 32 trong 40 ở chỉ số hiệu quả đó. Tốc độ đầu ra được ghi là không có sẵn, và danh sách ghi nhận đầu vào văn bản và hình ảnh, trái với tuyên bố của chính nhà cung cấp về văn bản, hình ảnh, video và âm thanh — một điểm khác biệt chưa được giải quyết, đáng để nêu ra hơn là phân xử. Những số liệu đó là độc lập và không phụ thuộc nhà cung cấp; các số liệu AMP ở trên là của Meta.

Phiên bản ngắn gọn nếu bạn đang cân nhắc ngay hôm nay

Nếu hạ tầng của bạn là AMD và bạn đang định tự vận hành Muse Spark Open trên MI355X, thì quan điểm trung thực là chính bạn là phép đo. Có một lộ trình phục vụ day-zero đầy đủ, một công thức lượng tử hóa cho từng tăng tốc, một mức tăng tốc giải mã suy đoán đã được công bố — và, tại thời điểm viết bài này, không có điểm độ chính xác nào được công bố cho cả hai ô FP4 trên silicon AMD. Bất kể thế nào, PR vẫn đưa cho bạn một thứ hữu ích: cấu hình đánh giá của nó là một định nghĩa hoàn chỉnh, sẵn sàng để bê nguyên sang dùng, về việc một phép kiểm tra độ chính xác nghiêm túc trên mô hình này trông như thế nào, cho đến cả reasoning effort và top_p. Hãy chạy nó với checkpoint của riêng bạn trước khi đưa nó cho khách hàng dùng, và để mắt tới các lần chạy đã được tác giả hứa, các bản vá AITER đã rebase, và việc ngưỡng MMMU được thay bằng một điểm đo được.

Ghi chú thực tiễn về việc phục vụ một ngăn xếp lượng tử hóa bốn tuần tuổi

Một chi tiết cơ chế trong PR đáng được lưu tâm. Ô NVFP4 được nạp với --quantization quark_mxfp4, nghĩa là checkpoint nguồn là NVFP4 và runtime lượng tử hóa lại nó thành MXFP4 khi nạp. Hai pipeline khác nhau về mặt số học đang được so sánh trong cùng một bộ kiểm thử, và đó chính xác là lý do mỗi bên có server riêng, class riêng và dòng đạt/không đạt riêng. Hướng dẫn của chính Meta là bản dựng AMD FP8 (Quark) đạt độ chính xác tương đương BF16 trên GSM8K, nhưng tuyên bố đó là về FP8, không phải về ô FP4 nào, và đó là phép đo do nhà cung cấp thực hiện. Nếu bạn đang chọn một phương pháp lượng tử hóa cho môi trường production, hãy coi các ô FP4 là chưa được kiểm chứng cho đến khi có ai đó công bố con số cụ thể.

Đây chính là lúc lớp định tuyến chứng minh được giá trị của mình. Với người đọc chỉ gọi một endpoint được host sẵn, mọi bất định đó đều không tồn tại — nhưng nếu bạn là người đưa ra quyết định tự host, cách để giảm thiểu rủi ro cho một mô hình chưa được kiểm chứng là đưa một phần nhỏ lưu lượng vào nó, đặt sau một thứ có thể chuyển lưu lượng trở lại. OrcaRouter hiện định tuyến Muse Spark 1.2 và Muse Spark 1.1 và không định tuyến Muse Spark Open, nên ở đây không có gì là tuyên bố về việc host mô hình mới; nó chính là một API duy nhất cho hơn 200 mô hình, với tự động chuyển đổi dự phòng khi nhà cung cấp bị suy giảm và một DSL định tuyến để tách lưu lượng giữa các mô hình và nhà cung cấp bằng cấu hình thay vì thay đổi code. Chúng tôi chuyển nguyên mức giá niêm yết của nhà cung cấp với 0% chênh lệch, và đó chính là điều khiến một lần chạy song song thận trọng trở nên đủ rẻ để thực sự làm.

Đối với bản thân Muse Spark Open, tình trạng sẵn có hiện nay diễn ra thông qua API riêng của Meta và một loạt nền tảng suy luận bên thứ ba, cùng với các lượt tải trọng số trên Hugging Face và hai danh mục mô hình trên đám mây mà Meta đã nêu tên. Trên AMD, cách nhanh nhất để có một con số đáng tin cậy là cổng kiểm tra trong PR này — một khi có ai đó chạy nó.

Xem gì

• Việc hợp nhất PR Day-0 — cổng kiểm soát độ chính xác không thể hợp nhất trước khi điều đó xảy ra, và thời điểm nó đến là lúc mã của chính mô hình trở thành đường cơ sở thay vì một bản chụp nhanh.

• Việc rebase bản vá AITER — cụ thể là phần AITER của bản vá unified-attention so với bản revision được ghim. Cho đến khi bản vá đó được áp dụng, bộ kiểm thử AMD sẽ báo đỏ vì những lý do không liên quan gì đến mô hình.

• Ngưỡng MMMU không còn ở mức 0,50 — thời điểm một điểm số MI355X thực sự thay thế giá trị tạm thời, cổng đa phương thức bắt đầu phát huy tác dụng.

• Báo cáo chạy đầu tiên được công bố — tác giả đã cam kết đăng các lần chạy trên cả ba ảnh trước khi đánh dấu PR là sẵn sàng. Đó là kết quả đo độ chính xác AMD đầu tiên cho Muse Spark Open, và nó sẽ đến từ một harness kiểm thử chứ không phải từ slide của nhà cung cấp.

• Liệu số liệu của NVIDIA và AMD có khác biệt hay không — nếu GSM8K giữ ở mức gần 0,93 trên MI355X trong khi MMMU thấp hơn đáng kể so với bất kỳ nền tảng nào khác, thì đường xử lý thị giác trên ROCm chính là câu chuyện, và PR của framework đã thêm cổng đó sẽ là nơi đầu tiên điều này lộ diện.

Với bất kỳ ai đang theo dõi cách các flagship trọng số mở thực sự tiếp cận phần cứng thứ cấp, đây là tệp bạn nên để mở. Bài đăng ra mắt cho bạn biết mô hình có sẵn trên AMD. Pull request cho bạn biết rằng tính đến ngày 15 tháng 10 năm 2026, chưa có ai kiểm tra liệu nó có còn tốt ở đó hay không.