
GLM تبني بنيتها التحتية للاستدلال بمساعدة وكيل ذكاء اصطناعي
وصفت شركة Z.ai كيف بنى وكيل البنية التحتية المدعوم بـ GLM-5.3 خدمة الاستدلال التي يعمل عليها GLM-5.3-Flash على أكثر من 100 ألف مسرّع صيني الصنع، في أقل من أسبوعين.
نشرت Z.ai في 17 سبتمبر مقالاً بحثياً يشرح كيف بنى وكيل البنية التحتية (Infra Agent) المدعوم بـ GLM-5.3 خدمة الاستدلال التي يعمل عليها اليوم نموذج GLM-5.3-Flash. عنوان المقال هو «نحو تحسين ذاتي تكراري»، غير أن الشركة تؤكد صراحة أن الهدف لم يتحقق بعد، وأن ما يظهر منه حتى الآن مجرد صور أولى.
100 ألف مسرّع وأسبوعان
يعمل الاستدلال الإنتاجي الكامل لنموذج GLM-5.3-Flash على عنقود يضم أكثر من 100 ألف مسرّع ذكاء اصطناعي صيني الصنع. وبحسب الشركة، لم يسبق لأحد أن نشر عنقوداً بهذا الحجم. واجه الفريق ذاكرة عرض نطاق محدودين في الشرائح، وبنية نموذج جديدة، ونافذة سياق تبلغ مليون رمز، وطلبات متعددة الوسائط، إضافة إلى منظومة غير ناضجة ودعم ناقص للنوى البرمجية.
ونُفّذ جزء كبير من العمل لا بمهندسي البنية التحتية وحدهم، بل بواسطة وكيل البنية التحتية المدعوم بـ GLM-5.3. وقد أدّت التحسينات المكثفة للذاكرة — مثل ReplaySSM وتكميم W8A8 وتكميم الذاكرة المؤقتة بدقة مختلطة INT8/FP8/BF16 وتقنية Layer Split وبنية Encode-Prefill-Decode — إلى تحسين أداء الخدمة من طرف إلى طرف نحو ثلاثة أضعاف، مع اقتراب تكلفة الرمز وكفاءة استخدام العتاد من مستويات وحدات GPU السائدة من NVIDIA. ولم يستغرق الانتقال من التهيئة الأولى للنموذج إلى الجاهزية للإنتاج أكثر من أسبوعين.
«التغذية الراجعة الكثيفة»
الفكرة المحورية في المقال هي أن فعالية الوكيل الهندسية تعتمد على مدى تفصيل التغذية الراجعة التي يتلقاها أكثر من اعتمادها على قدرته على كتابة الشيفرة. فالمقياس الشامل يخبر الوكيل بأن النتائج ساءت، لكنه لا يوضح السبب. لذلك أتاح الفريق للوكيل اختبارات الصحة والمعايير الدقيقة وآثار التنفيذ وأحداث وقت التشغيل بصيغة قابلة للاستخدام المباشر. ولهذه التغذية الراجعة «الكثيفة» ثلاث خصائص: أن تكون محلية، وسريعة ورخيصة الحصول، وقابلة للتحقق الموضوعي عبر تجارب مضبوطة.
حالات محدّدة
على مسار التوازي السياقي (Context Parallelism) في نواة KDA اكتشف الوكيل خطأ في الدقة العددية: فدالة tl.dot كانت تستخدم حساب TF32 افتراضياً حتى مع مدخلات FP32، فتراكم الخطأ في السياقات الطويلة. كان الإصلاح بتعيين input_precision="tf32x3"، وقُبل التعديل أيضاً في مشروع Flash Linear Attention (PR #1180).
وفي عنق الزجاجة الخاص بنقل KV سمح معيار القبول بفارق أداء لا يزيد على 5%، لكن الوكيل قاس أكثر من 20%. وكان السبب أن دالتي intranode_dispatch و intranode_combine في DeepEP v1.2.1 لا تحرّران قفل Python GIL، ما يعيق خيط النقل في Mooncake Transfer. وبعد تحرير القفل انخفض الفارق إلى أقل من 1%.
الحدود والنتيجة
قبل الإطلاق اختُبر GLM-5.3-Flash بشكل مجهول على OpenCode وOpenRouter تحت اسم Ox-Alpha، وصار خلال أسبوع النموذج الأكثر استخداماً على المنصتين، إذ عالج أكثر من 62 تريليون رمز في ستة أيام. ويشدّد المقال على أن اختيار الأهداف ووضع الحدود وتقييم المخاطر تبقى مسؤوليات بشرية.
SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي
نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.