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 صرحت بأنه لم يقم أحد من قبل بتشغيل مجموعة من المسرّعات الصينية الصنع بهذا الحجم. وأشارت الشركة إلى سعة الذاكرة على الشريحة وعرض النطاق الترددي المحدودين نسبيًا، وبنية نموذج جديدة، ونافذة سياق بطول 1 مليون رمز، وطلبات متعددة الوسائط، إلى جانب نظام بيئي غير ناضج حيث كان دعم النواة غير مكتمل واضطر المهندسون إلى التخمين بشأن السلوك الذي كان ينبغي توثيقه.

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

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

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

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

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

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

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

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

الحالة الثانية تتعلق عنق زجاجة تزامن نقل KV. وفقًا للقصة، وضع المهندسون معيار قبول يفيد بأنه، تحت نفس عبء العمل، يجب أن يعمل Prefill مع نقل KV ضمن 5٪ من الخط الأساسي لـ Prefill فقط. وجد الوكيل فجوات تتجاوز 20٪ في بعض السيناريوهات وتتبعها إلى DeepEP v1.2.1، التي لا intranode_dispatch ولا intranode_combine المستدعي أطلق صراحةً قفل GIL الخاص بـ Python. طالما احتفظت هذه الاستدعاءات بالقفل، لم يتمكن خيط Python الخاص بنقل Mooncake في العملية نفسها من الحصول على GIL في الوقت المناسب، لذا انزلق جدولة وتقديم مهام النقل وتقلص التداخل مع الحساب. تشير القصة إلى أن internode_dispatch في نفس الإصدار كان قد أطلق بالفعل GIL، مع تعليق في الشيفرة يوضح أن الهدف كان تجنب حجز نقل KV في خيوط أخرى بينما كان CPU ينتظر. بعد أن أطلق الإصلاح GIL خلال فترات تنفيذ 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 بأنها لم تصل بعد إلى التحسين الذاتي المتكرر، وأن اختيار الأهداف، وتحديد الحدود، وتقييم المخاطر ما زالت مسؤوليات بشرية تعتقد أن البشر يجب أن يواصلوا تحملها.