Muse Spark Open على AMD: دعم من اليوم الأول، عتبة مؤقتة، وبوابة لم يشغّلها أحد

أصدرت ميتا Muse Spark Open في 15 أكتوبر 2026، وفي المساء نفسه وصلت مسودة طلب سحب إلى SGLang يبدو العنوان أقرب إلى اعتراف منه إلى ميزة: [AMD] إضافة بوابة دقة ليلية GSM8K + MMMU لـ Muse Spark Open MI35x. السبب وراء وجودها موضح في متن طلب السحب. على HIP، يوجّه كود النموذج إلى تنفيذ ROCm منفصل — sglang.srt.rocm_muse_spark — ولا تغطيه أي مهمة تكامل مستمر في المشروع. بحسب ما ذكره المؤلف نفسه، لم تُشغَّل البوابة الجديدة على عتاد بعد، وإحدى عتبتي النجاح/الفشل فيها عنصر نائب اختُرع لعدم وجود قياس من AMD يمكن استخدامه، كما أن مهمة CI ستفشل عند خطوتها الأولى اليوم على أي حال. هذه ليست قصة إطلاق. إنها أثر على شكل تسريب لما يبدو عليه فعلاً إطلاق نموذج مفتوح الأوزان بـ816 مليار معامل إلى عتاد AMD من داخل إطار خدمة.

ما الذي يضيفه طلب السحب فعليًا

البوابة هي مهمة ليلية واحدة تغطي كلا نقطتي التحقق FP4 في وصفة كتاب الطبخ "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 فيقوم بتحميل من مستودع Meta -NVFP4 نقطة التحقق مع --quantization quark_mxfp4، وهي تعيد التكميم إلى MXFP4 عند التحميل.

• أعلام الوصفة — TP4/EP4، انتباه AITER بحجم صفحة 16، MUSE_MOE_BACKEND=flydsl، DFlash2 مع خلفية انتباه مسودة Triton.

• ما الذي يتم قياسه — GSM8K بالتقسيم الكامل عبر sgl-eval مع تفعيل التفكير، reasoning_effort=xhigh، بحد أقصى 32,768 رمزًا، ودرجة الحرارة 1.0، وtop_p 0.95، بالإضافة إلى 100 عينة MMMU للمسار متعدد الوسائط.

• الوقت الفعلي — يخدم مشغّل واحد بثماني وحدات GPU نقطتي التحقق كلتيهما الواحدة تلو الأخرى، نحو أربع ساعات.

إن تضمين MMMU هو التفصيل الذي يجعل الـ PR يستحق القراءة. وكما يقول المؤلف، على HIP يوجّه النموذج إلى تطبيق ROCm، ومسار الصورة عبر ذلك التطبيق غير مختبَر بخلاف ذلك — لذا فإن برج الرؤية، في لحظة كتابة هذا، هو الجزء الأقل استخدامًا من Muse Spark Open على عتاد AMD.

الرقمان في PR، ومن أين جاءا

لا شيء هنا يُعدّ قياسًا لـ Muse Spark Open على عتاد AMD، وهذا ما يصرّح به طلب السحب (PR).

• GSM8K 0.93 — منقول بالكامل من اختبار B300 Muse Spark في البيان الصحفي ليوم الإطلاق. وB300 هو NVIDIA Blackwell Ultra. فقد جرى نقل العتبة وإعدادات أخذ العينات وإعداد التقييم بالكامل من أعمال الانتقال من فئة Hopper إلى Blackwell لتُطبَّق على مجموعة تسريع مختلفة تمامًا.

• MMMU 0.50 — وُصِف في الـ PR بأنه «عنصر نائب لا يقف خلفه أي قياس من AMD». هذا صراحة غير معتادة بالنسبة لملف CI، ويستحق أن نفهم لماذا يهم أكثر مما يبدو. البوابة ذات الحد الأدنى المُختلق ليست فحصًا للصحة؛ بل هي سلك تعثر. ستلتقط انحدارًا كارثيًا وستمرر بصمت انحدارًا طفيفًا. إذا تبين أن نتيجة MMMU الحقيقية لـ MI355X هي 0.68، فإن البوابة تسمح بانخفاض بمقدار ست نقاط قبل أن تنطلق.

• طول القبول في DFlash2 — يُبلَّغ عنه في ملخّص خطوات المهمة، ولا يخضع لبوابة تحقّق عن قصد. لذا فإن مسار فك التشفير التخميني قابل للملاحظة لكنه غير محميّ: نموذج المسوّدة الذي يتوقف بهدوء عن التنبؤ الجيد سيظهر في ملخّص لا يُنبّه عليه أحد.

تلك النقطة الأخيرة تتجاوز نطاق طلب السحب (PR) هذا. فبوابة الدقة الليلية تقيس شيفرة النموذج التي يشحنها الإطار، لا النموذج الذي يقدّمه لك مزوّد. وصفة تكميم مختلفة، أو حجم صفحة مختلف، أو واجهة خلفية انتباه مختلفة، أو نموذج مسودة مختلف، وستكون خارج النطاق الذي كُتبت البوابة من أجله.

البوابة مسدودة، والسبب عادي.

يبقى طلب السحب (PR) في حالة مسودة حتى يُدمج طلب سحب دعم اليوم صفر (Day-0)، وهو تبعية طبيعية. العائق الأكثر إثارة للاهتمام هو مجموعة تصحيحات AMD AITER. تُتحقَّق هذه التصحيحات مقابل مراجعة واحدة من AITER (4ad9983)، لكن ملف ROCm Dockerfile على main يثبّت مراجعة مختلفة (2bb5491). مقابل المراجعة المثبَّتة، يُطبَّق 04-aiter-muse-moe-flydsl.patch بسلاسة؛ أما الجزء الخاص بـ AITER من 03-plan-b-aiter-unified-attention-3d.patch فلا يُطبَّق، لأن aiter/ops/triton/attention/unified_attention.py أُعيدت هيكلته بعد قطع التصحيحات. ولم يفحص المؤلف التصحيح الثالث، الذي يستهدف الوحدة الفرعية composable_kernel. وإلى أن يُطبَّق التصحيح الثاني، تفشل المهمة قبل أن تقيّم أي شيء.

اقرأ ذلك كإشارة على النضج بدلاً من اعتباره لائحة اتهام. يتم إعادة بناء مسارات خدمة AMD لنماذج mixture-of-experts الضخمة جدًا بشكل مستمر في المنبع، وملف قفل المورد هو بالضبط ما يكسر مجموعة التصحيحات التي جعلت النموذج يعمل في المقام الأول.

اليوم الأول في AMD لم يكن في الواقع اليوم الأول.

عدم تشغيل البوابة ليس مماثلاً لكون مسار AMD جديداً. فالجداول الزمنية المحيطة تروي قصة أوفى مما يرويه منشور الإطلاق أو البيان الصحفي.

• آثار التكميم الخاصة بـ AMD تسبق الإطلاق بنحو أربعة أسابيع — Quark-MXFP4 وQuark-PTPC-FP8، وهي نقاط التحقق الخاصة بـ Muse Spark Open، وقد نُشرت على Hugging Face في 2026-09-18، أي قبل نحو شهر من إعلان Meta عن الأوزان.

• بدأ دعم أُطر العمل في يوم الإطلاق — طلب السحب (PR) الخاص بـ SGLang بعنوان [Day0] دعم Muse Spark Open، وطلب السحب (PR) الخاص بـ vLLM بعنوان [Model] إضافة دعم Muse Spark Open، وقد افتُتح كلاهما خلال اثنتي عشرة دقيقة من بعضهما بعضًا في 2026-10-15، وهذا ما يبدو عليه التنسيق الحقيقي في اليوم صفر.

• دليل البناء الخاص بـ 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، ومكسب شامل من طرف إلى طرف بنسبة 3% على MI350.

إذن القصة ليست "دعم AMD يصل متأخرًا"، بل إن دعم AMD وصل مُجهَّزًا ببروفة كاملة وغير مقيس في الوقت نفسه: كانت المخرجات والوصفات وتحسينات السرعة كلها جاهزة، أما رقم الدقة فلم يكن كذلك، وهذه بالتحديد هي الفجوة التي توجد بوابة ليلية لسدّها.

ما تقوله الأرقام المستقلة في هذه الأثناء

بينما لا تزال دقة AMD غير محسومة، فإن الصورة الإجمالية ليست كذلك. يُدرج Artificial Analysis نموذج Muse Spark Open عند مؤشر Intelligence Index بقيمة 39، في المرتبة التاسعة من بين 118 نموذجًا في مجموعة المقارنة الخاصة به، مع وسيط قدره 19 عبر النماذج المماثلة — وهي نتيجة قوية. يكمن الحذر في سعره: 1.25 دولار لكل مليون رمز إدخال و4.25 دولار لكل مليون رمز إخراج، مع خصم ذاكرة تخزين مؤقت بنسبة 88%، وسعر مدمج قدره 0.78 دولار، وإنفاق قدره 0.84 دولار لكل مهمة Intelligence Index، مما يجعله يحتل المرتبة 32 من 40 في مقياس الكفاءة هذا. سرعة الإخراج مُدرجة على أنها غير متاحة، ويُسجّل الإدراج مدخلات النص والصورة مقابل ادعاء البائع الخاص بالنص والصورة والفيديو والصوت — وهو تباين غير محسوم يستحق الإشارة إليه بدلاً من الحكم فيه. هذه الأرقام مستقلة ومحايدة تجاه البائع؛ أما أرقام AMP المذكورة أعلاه فهي خاصة بـ Meta.

النسخة المختصرة إذا كنت تقرر اليوم

إذا كانت سعتك الحوسبية من AMD وكنت تخطط لاستضافة Muse Spark Open ذاتيًا على MI355X، فالموقف الصادق هو أنك أنت القياس. يوجد مسار خدمة كامل من اليوم صفر، ووصفة تكميم لكل مُسرّع، وتسريع منشور لفك التشفير التخميني — ومع ذلك، واعتبارًا من كتابة هذه السطور، لا توجد درجة دقة منشورة لأي من خليتي FP4 على سيليكون AMD. يمنحك الـ PR شيئًا مفيدًا على أي حال: إعداد التقييم الخاص به تعريف كامل وجاهز للاقتباس لما يبدو عليه فحص دقة جدي لهذا النموذج، وصولًا إلى جهد الاستدلال و top_p. شغّله على نقطة التحقق الخاصة بك قبل أن تضع أي عميل أمامه، وترقّب عمليات التشغيل التي وعد بها المؤلف، وتصحيحات AITER المُعاد تأسيسها، واستبدال عتبة 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 للتوجيه لتقسيم حركة المرور بين النماذج والمزوّدين عبر الإعدادات بدلاً من تغيير الشيفرة. نحن نمرر سعر القائمة الخاص بالمزوّد كما هو دون أي هامش ربح، وهذا ما يجعل التشغيل المتوازي الحذر رخيصًا بما يكفي لتنفيذه فعلاً.

بالنسبة إلى Muse Spark Open نفسه، يتاح اليوم عبر واجهة برمجة تطبيقات Meta الخاصة ومجموعة من منصات الاستدلال التابعة لجهات خارجية، بالإضافة إلى تنزيلات الأوزان على Hugging Face وفهرسي نماذج السحابة اللذين ذكرتهما Meta. على AMD، أسرع طريقة للحصول على رقم موثوق هي البوابة في طلب السحب هذا — بمجرد أن يشغّلها أحدهم.

ماذا تشاهد

• وصول طلب السحب في اليوم صفر — لا يمكن لبوابة الدقة أن تُدمج قبل ذلك، ووصوله هو اللحظة التي يصبح فيها كود النموذج نفسه هو الأساس بدلًا من لقطة.

• إعادة تمركز ترقيع AITER — تحديدًا النصف الخاص بـ AITER من ترقيع الانتباه الموحّد مقابل المراجعة المثبّتة. وإلى أن يُطبَّق ذلك، تظل مجموعة اختبارات AMD حمراء لأسباب لا علاقة لها بالنموذج.

• انتقال عتبة MMMU بعيدًا عن 0.50 — في اللحظة التي تحل فيها درجة MI355X حقيقية محل العنصر النائب، تبدأ البوابة متعددة الوسائط في العمل.

• أول تقارير تشغيل منشورة — وقد التزم المؤلف بنشر نتائج التشغيل على الصور الثلاث جميعها قبل وضع علامة الجاهزية على الـ PR. وهذا هو أول قياس لدقة AMD لـ Muse Spark Open، وسيأتي من بيئة اختبار لا من عرض تقديمي لمورّد.

• هل تتباين أرقام NVIDIA وAMD — إذا بقي GSM8K قريبًا من 0.93 على MI355X بينما يستقر MMMU عند مستوى أدنى بدرجة جوهرية من أي منصة أخرى، فإن مسار الرؤية على ROCm هو القصة، وسيكون طلب السحب (PR) الخاص بإطار العمل الذي أضاف البوابة أول مكان ظهر فيه ذلك.

لكل من يتابع كيف تصل الطرازات الرائدة مفتوحة الأوزان فعليًا إلى الأجهزة الثانوية، هذا هو الملف الذي ينبغي إبقاؤه مفتوحًا. يخبرك منشور الإطلاق بأن النموذج متاح على AMD. أما طلب السحب فيخبرك أنه حتى 15 أكتوبر 2026، لم يتحقق أحد بعد مما إذا كان لا يزال جيدًا هناك.