Z.ai تفاصيل استدلال GLM-5.3-Flash مبنية على 100,000 شريحة صينية

نشرت Z.ai في 17 سبتمبر 2026 حساب تقني يصف كيف بنت خدمة استدلال جاهزة للإنتاج بالكامل لنموذج GLM-5.3-Flash من الصفر على مجموعة تضم أكثر من 100,000 مسرّع ذكاء اصطناعي صيني الصنع. ووفقًا للشركة، تم إنجاز معظم العمل بواسطة وكيل بنية تحتية مدعوم من GLM-5.3 بدلاً من مهندسي البنية التحتية فقط، وتعمل جميع عمليات الاستدلال الإنتاجية لـ GLM-5.3-Flash على النظام.

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

GLM-5.3-Flash أُطلقت في 26 أغسطس 2026 كنموذج متعدد الوسائط أصلي أول في سلسلة GLM-5، مع 320 مليار معامل إجمالي و18 مليار معامل نشط تحت بنية هجينة تجمع بين الانتباه المتناثر والخطي. قبل الإصدار، اختبرت Z.ai النموذج بشكل مجهول باسم ox-alpha على OpenCode وOpenRouter، وقالت الشركة إنه أصبح النموذج الأكثر استخدامًا على كلا المنصتين خلال أسبوع من الإطلاق، مع معالجة أكثر من 62 تريليون رمز خلال ستة أيام.

طريقة التغذية الراجعة الكثيفة

في صميم التقرير توجد مشكلة نظامية: يمكن للقياسات من الطرف إلى الطرف أن تخبر الوكيل بأن النتائج تدهورت، لكن لا توضح السبب. اختبار دقة عددية فاشل، أو زيادة بنسبة 30٪ في زمن الحصول على أول رمز، أو انخفاض بنسبة 20٪ في معدل إنتاج المخرجات لا يُظهر أي طبقة مسؤولة أو ما يجب اختباره بعد ذلك. إجابة Z.ai، التي تسميها التغذية الراجعة الكثيفة، تدمج اختبارات الصلاحية، وسجلات وقت التشغيل، وتتبع التنفيذ، وأحداث وقت التشغيل، والاختبارات الدقيقة، والقياسات من الطرف إلى الطرف في سير عمل قابل للتكرار يتيح للوكيل التحقق من كل فرضية محليًا بدلاً من الانتظار لنشر كامل واختبار حمل بعد كل تغيير.

تحدد الشركة ثلاث خصائص ضرورية لمثل هذه التغذية الراجعة. يجب أن تكون محلية، مرتبطة قدر الإمكان بمعلمات الإطلاق المحددة، تغييرات الشيفرة، النوى، ظروف الإدخال، الخيوط، فترات التنفيذ، أو مسارات الشيفرة. يجب أن تكون غير مكلفة وسريعة الحصول عليها. ويجب أن تدعم التحقق الموضوعي من خلال تطبيقات مرجعية وتجارب محكومة، لأن الارتباطات الملحوظة بحد ذاتها لا تُثبت السبب الجذري.

في حلقة الإطلاق التي يصفها التقرير، حدد المهندسون الأهداف وحدود النظام وراجعوا التغييرات الحرجة المتعلقة بالدلالات العددية وسلوك التزامن ومخاطر الإنتاج، بينما تولى الوكيل تحليلًا، وفرضيات، وتغييرات الشيفرة. المجموعة التي قاموا بتحسينها معًا جمعت التوازي النسيجي داخل العقدة للانتباه الخطي ورأس نموذج اللغة (LM Head)، ReplaySSM، تقليل الدقة W8A8، تقليل الدقة المختلط INT8/FP8/BF16 لذاكرة التخزين المؤقت، وتقسيم الطبقة، ضمن بنية منفصلة للترميز‑الملء‑الاستدلال.

ثلاث حالات هندسية

الحالة الأولى تتعلق بالصحة العددية. كشفت عملية التحقق التي تقارن مسارات تنفيذ النواة المقسمة وغير المقسمة عن مشكلة دقة في مسار التوازي السياقي لنواة KDA: عملية tl.dot كانت تستخدم حساب TF32 بشكل افتراضي حتى عندما كانت مدخلاتها FP32، مما أدى إلى تراكم الأخطاء أثناء دمج الحالة وتفاقمها مع زيادة طول السياق. تم إصلاح ذلك بتحديد دقة الإدخال صراحةً إلى tf32x3، التي تستخدم ثلاث عمليات نواة Tensor Core من نوع TF32 لإنتاج نتيجة ذات دقة أعلى.

وفقًا للتقرير، تم دمج الإصلاحات في المصدر الرئيسي إلى Flash Linear Attention. الـ طلب سحب، الذي فُتح ودمج في 27 أغسطس 2026، يطبق سلسلة tf32x3 المتحولة في نوى تحديث الحالة ودمج التحويلات كمسار دقة اختياري، ويضيف اختبارات التوازي السياقي، ويعود صراحةً إلى دقة ieee على المنصات التي لا تدعم tf32 (AMD، وحدات المعالجة العصبية، وبطاقات NVIDIA GPU التي تقل قدرة الحوسبة عنها عن 8.0).

الحالة الثانية تتعلق عنق زجاجة تزامن نقل KV. وفقًا للتقرير، وضع المهندسون معيار قبول ينص على أنه، تحت نفس عبء العمل، يجب أن يعمل Prefill مع نقل KV ضمن 5٪ من الخط الأساسي لـ Prefill فقط. وجد الوكيل فجوات تجاوزت 20٪ في بعض السيناريوهات وتبعها إلى DeepEP الإصدار 1.2.1، حيث لم يطلق أي من استدعاء intranodeالإرسال ولا intranodeدمج صراحةً قفل Python GIL. طالما احتفظت تلك الاستدعاءات بالقفل، لم يتمكن خيط نقل Mooncake Python في العملية نفسها من الحصول على القفل في الوقت المناسب، مما أدى إلى تأخر جدولة وتقديم مهام النقل وتقلص التداخل مع الحساب. يشير التقرير إلى أن استدعاء internode_dispatch في نفس الإصدار كان قد أطلق القفل بالفعل، مع تعليق في الشيفرة يوضح أن الهدف كان تجنب حجز نقل KV في خيوط أخرى بينما ينتظر CPU. بعد أن أطلق الإصلاح القفل خلال فترات تنفيذ C++ ذات الصلة، أفاد التقرير أن الفجوة انخفضت إلى أقل من 1٪ تحت نفس ظروف الاختبار.

الحالة الثالثة تتعلق بأداء النواة. قامت Z.ai بجعل الوكيل يستخلص تقنيات من النوى المكتوبة يدوياً في مشاريع تشمل SGLang وFlash Linear Attention وDeepGEMM إلى هياكل تحسين قابلة لإعادة الاستخدام تحمل شروط القابلية للتطبيق، طرق التحويل، قيود الموارد، وأدلة التحقق. على نواة KDA Decode تمثيلية، أفادت الشركة أن تحسين تقسيم الوكيل خفض زمن التنفيذ بنسبة 9.6٪. بعد أن حددت الملاحظات أن الحوسبة هي القيد الأساسي، دمج الوكيل بلاطات البُعد V للنواة، التي كانت تكرر نفس عمليات التطبيع FP32 والبوابات أربع مرات، في كتلة خيط واحدة مع نتائج وسيطة مقيمة في السجلات وتقليل على مستوى الـ warp واحد، مما أنتج ما أفادت الشركة بأنه تسريع بمقدار 1.71× مقارنة بالإصدار السابق.

النتائج المعلنة والتحسين الذاتي المتكرر

تقرير Z.ai أن GLM-5.3-Flash انتقل من تكييف النموذج الأولي إلى جاهزية الإنتاج في أقل من أسبوعين، مع تضاعف الإنتاجية الشاملة نهائيًا ثلاث مرات مقارنة بالخط الأساسي الأولي. كما ذكرت الشركة أن كفاءة استغلال العتاد وتكلفة كل رمز وصلت إلى مستويات مماثلة لبطاقات NVIDIA GPU السائدة.

تصف الشركة الجهد كمثال مبكر على التحسين الذاتي المتكرر، مشيرة إلى أن النموذج شارك في تحسين نظام الاستدلال الذي يعمل عليه. وفي الوقت نفسه، تؤكد Z.ai أنها لم تصل بعد إلى التحسين الذاتي المتكرر، وأن اختيار الأهداف، وتحديد الحدود، وتقييم المخاطر ما زالت مسؤوليات بشرية تعتقد أن البشر يجب أن يواصلوا تحملها.