نظرة عامة

مهارة Claude Code ليست سحرًا بل إجراء تشغيل معياري (SOP). هي لا تجعل النموذج أذكى، بل تقيّد بقوة قدراتٍ يمتلكها النموذج أصلًا نحو اتجاه محدد، فترفع متوسط الجودة. في حالة مهارة صفحات الهبوط، هذا القيد هو تحديدًا مبادئ التصميم وقواعد التخطيط وصيغة المخرجات.

يتوافق هذا المنظور تمامًا مع طريقة تشغيل ThakiCloud للوكلاء. جودة الوكيل لا تأتي من فئة النموذج بل من بنية العقد التي تغلّف النموذج. مهارة صفحات الهبوط مثال جيد على تركيز بنية العقد هذه في مجال ضيّق هو تصميم الواجهة الأمامية. وهي أيضًا تصميم مهارة نموذجي: قلّل درجات الحرية لترفع المتوسط.

ما هذه التقنية

مهارة Claude Code هي في جوهرها ملف markdown واحد اسمه SKILL.md. بداخله المبادئ والقواعد التي ينبغي للوكيل اتباعها في مهمة معينة، إضافة إلى تفضيلات المستخدم. عندما يقدّم المستخدم طلبًا بلغة طبيعية، تُحقَن المهارة ذات الصلة في سياق الوكيل، فيتبع الوكيل تلك التعليمات كإجراء تشغيل معياري بينما يولّد HTML وCSS وJavaScript محليًا.

شكل ما تنتجه مهارات صفحات الهبوط يُلاحَظ باتساق عبر عدة مهارات عامة. إنه ملف HTML واحد مكتفٍ بذاته، بكل CSS مضمّن داخل <style> وكل JavaScript مضمّن داخل <script>. تقتصر الاعتماديات الخارجية على Google Fonts ومكتبة الرسوم المتحركة GSAP المحمّلة عبر CDN (Claude Directory). ملف واحد يكفي لاستضافته وتقديمه في أي مكان.

flowchart TB
    U[طلب بلغة طبيعية<br/>إنشاء صفحة هبوط احترافية] --> A[وكيل Claude Code]
    S[SKILL.md<br/>مبادئ التصميم · قواعد التخطيط · التفضيلات] -.حقن.-> A
    A --> G[مخرج HTML واحد<br/>CSS مضمّن · JS مضمّن]
    G --> D1[Google Fonts<br/>CDN]
    G --> D2[رسوم GSAP المتحركة<br/>CDN]
    D1 --> O[صفحة مكتفية بذاتها<br/>تُشحن كملف واحد]
    D2 --> O

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

القرارات التي تتخذها المهارة نيابةً عنك

حين تطلب صفحة هبوط دون مهارة، تكون النتيجة عامة لسبب واضح: على الوكيل أن يقرر التخطيط والمسافات والطباعة وتباين الألوان وتوقيت الحركة من الصفر في كل مرة، وتتجه تلك القرارات نحو متوسط آمن. تثبّت مهارات صفحات الهبوط الاحترافية العامة هذه القرارات مسبقًا بالضبط (تحليل MindStudio).

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

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

أمور ينبغي الانتباه إليها عند بناء مهارتك

إن كتبت مثل هذه المهارة بنفسك، فبعض الأمور مهمة. أولًا، ثبّت صيغة المخرجات صراحةً. تحديد البنية بأنها “HTML واحد، CSS/JS مضمّن، اعتماديات خارجية مقتصرة على الخطوط وGSAP” يُبقي النشر والنقل بسيطين. ثانيًا، اختزل حكم التصميم إلى قواعد. كتابة مقاييس المسافات وتباين الطباعة ولوحة ألوان مسموحة وقاعدة تفضّل transform وopacity الملائمين للمُركِّب في الحركة داخل الإجراء المعياري يعني ألا يعيد الوكيل التداول في كل مرة. ثالثًا، ضمّن حالات الفشل. أكثف معلومة في المهارة هي قائمة “لا تفعل هذا”. بنود مثل منع الحركات التي تُزيح التخطيط ومنع مخالفات أساسيات إمكانية الوصول هي ما يحمي جودة المخرجات فعليًا (دليل Ryan Doser).

ملاحظة أخرى: المهارة ضريبة أيضًا. منذ لحظة تحميلها في السياق تكلّف رموزًا، لذا على كل جملة أن تجتاز اختبار “هل سيخطئ الوكيل بدون هذا؟”. الزخرفة غير الضرورية خسارة صافية.

دلالات لمنتجات ThakiCloud

يتردد صدى هذه الحالة لدى ThakiCloud خصوصًا لأننا نشغّل منصة تعامل المهارات كموارد من الدرجة الأولى.

منظور Paxis (الوكلاء والمهارات). Paxis هي سحابة ThakiCloud الأصلية للوكلاء (Agent-Native Cloud)، التي تعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. قدرة وحدوية مثل مهارة صفحات الهبوط هي بالضبط ما يديره Skill Harness في Paxis. نختار من مئات المهارات عبر BM25، ونحقن ذات الصلة فقط في سياق الوكيل، وننفّذها في صندوق رمل معزول، ونمرّر كل فعل عبر بوابة سياسة وسجل تدقيق. كون مهارة صفحة هبوط واحدة تعمل جيدًا يعني أيضًا أن النمط نفسه يمكن أن يمتد إلى مجالات أخرى مثل توليد الشرائح وعرض المستندات ونشر البنية التحتية. صور ومستندات هذه المدونة نفسها تُولَّد على منصة المهارات ذاتها.

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

منظور ai-platform (البنية التحتية). بعض العملاء يريدون تشغيل أحمال التوليد هذه على بنيتهم التحتية الخاصة بدل الاعتماد كليًا على واجهات برمجة خارجية. تقدّم منصة ai-platform لدى ThakiCloud نماذج التوليد فوق جدولة GPU قائمة على K8s وKueue، فحتى في البيئات المحلية أو السيادية يمكن استضافة مثل هذه المسارات القائمة على المهارات ذاتيًا. كلما كانت المهمة متكررة ومعيارية، مثل توليد صفحات الهبوط، تحوّلت كلفة التقديم المنخفضة مباشرةً إلى اقتصاديات وكيل.

القيود والاعتراضات

بالطبع علينا الحذر من المبالغة. عبارة “صفحة احترافية بضربة واحدة” تصحّ أكثر في ظروف العرض التوضيحي. صفحة هبوط منتج حقيقي تحمل متطلبات متداخلة مثل أصول العلامة ومراجعة النصوص والامتثال لإمكانية الوصول وميزانية أداء واختبار A/B، لذا فمخرج الضربة الواحدة مسودة ممتازة لا نسخة نهائية. وعلى وجه الخصوص، HTML واحد بكل شيء مضمّن مريح للنشر السريع لكنه قد يحتاج إلى تقسيم من جديد للتخزين المؤقت والصيانة في موقع حقيقي تتشارك فيه صفحات متعددة الأصول.

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

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

المصادر

• @the_cyw، “بنيت مهارة تجعل Claude Code يبني صفحات هبوط احترافية”
• Claude Directory: Landing Page Skills
• MindStudio: Claude Code Landing Page Generator Skill
• Ryan Doser: How to Build Landing Pages With Claude Code

في الأسابيع الأخيرة، تحول حديث صناعة الذكاء الاصطناعي من سؤال “من الأذكى” إلى سؤال “من الأرخص”. وجاء المشهد الأكثر دلالة من مايكروسوفت. فالشركة ذاتها التي وضعت OpenAI على المسار الذي تسير عليه اليوم، بدأت بتوجيه عشرات آلاف الطلبات الأسبوعية للذكاء الاصطناعي داخل Excel وOutlook إلى نماذجها الخاصة بدلاً من نماذج OpenAI وAnthropic. ولم يُخفِ مصطفى سليمان، مسؤول الذكاء الاصطناعي في مايكروسوفت، هذا التوجه، إذ قال: “Anthropic باهظة الثمن للغاية. هدفنا هو خفض هذه التكلفة والقضاء عليها في نهاية المطاف.”

هذا المقال موجّه لقادة الهندسة وفرق الذكاء الاصطناعي وصنّاع القرار المسؤولين عن تكلفة الاستدلال في خدماتهم. سنوضح لماذا حرب التكاليف الدائرة اليوم ليست ضجيجاً عابراً بل تحولاً بنيوياً، ونضع دليلاً عملياً لترحيل إنفاق واجهات النماذج المتقدمة نحو النماذج المفتوحة والاستضافة الذاتية، ثم نختم بموقع ThakiCloud كطبقة تحكم تُنفذ هذا الترحيل فعلياً.

ما الذي تغيّر

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

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

ثانياً، تتجه الشركات الأمريكية نحو النماذج الصينية المفتوحة هرباً من الأسعار. وبحسب تقرير CNBC، عالجت النماذج الصينية أكثر من 30 بالمئة من استخدام الذكاء الاصطناعي لدى الشركات الأمريكية على إحدى منصات التوجيه الرئيسية، وبلغت ذروتها عند 46 بالمئة، مقارنة بمتوسط 11 بالمئة قبل عام واحد فقط. وتكاليفها أقل بنسبة تتراوح بين 60 و90 بالمئة، وفي بعض اختبارات الأداء الخاصة بالوكلاء ضاقت الفجوة مع أفضل النماذج الأمريكية إلى نقطة واحدة فقط (تقرير CNBC).

ثالثاً، ظهرت إشارة إلى فائض في العرض. فقد أعلنت Meta عزمها إنشاء عمل سحابي لبيع قدرة الحوسبة “الفائضة” الخاصة بالذكاء الاصطناعي، وهو ما يعني عملياً تحويل الاعتراف بالإفراط في البناء إلى نموذج عمل (تقرير CNBC).

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

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

كما أن الأسعار نفسها تنخفض بسرعة. فنموذج GPT-5.6 Sol الذي أطلقته OpenAI مؤخراً يُسعَّر بنحو 5 دولارات لكل مليون رمز إدخال و30 دولاراً لكل مليون رمز إخراج، وهو انخفاض حاد في تكلفة الرمز مقارنة بالجيل السابق (تقرير CNBC). وهذا يعني أن مختبرات النماذج المتقدمة نفسها دخلت في حرب أسعار فيما بينها. لم تعد الجبهة الأمامية حرب ذكاء، بل تحولت إلى حرب قيمة.

لماذا الآن

اندلعت حرب التكاليف الآن بسبب طبيعة توزّع الأحمال العملية.

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

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

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

من المتقدم إلى المفتوح: دليل الترحيل العملي

فكيف يُنقل هذا النهر عملياً. تغيير النموذج بشكل ارتجالي أمر محفوف بالمخاطر. الترحيل الموثوق يمر بخمس خطوات.

أولاً، تصنيف الحمل. تُقسَّم كل طلبية على محورين: الصعوبة والحساسية. تبقى المهام الصعبة أو الحساسة على النماذج المتقدمة، بينما تُوضَع علامة على المهام النمطية عالية الحجم فقط باعتبارها هدفاً للترحيل.

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

ثالثاً، بناء التوجيه. تُعرَّف في مكان واحد القواعد التي تحدد أي نموذج يعالج أي نوع من المهام. هذه القواعد يجب أن تكون مصدر الحقيقة الوحيد حتى يسهل لاحقاً استبدال النموذج أو التراجع عنه.

رابعاً، الاستضافة الذاتية للنموذج المفتوح. يُنشر النموذج المفتوح المختار على البنية التحتية الخاصة بالشركة باستخدام محرك تقديم مثل vLLM. في هذه الخطوة تتحقق مزايا النشر المحلي والسيادة على البيانات وانخفاض التكلفة لكل وحدة.

أخيراً، التحقق والتراجع. بعد الترحيل، تستمر عملية قياس الجودة، وإذا تراجعت نسبة الاجتياز، تُعاد تلك المهمة تحديداً إلى النماذج المتقدمة. الترحيل بلا مسار للتراجع ليس ترحيلاً بل مقامرة.

flowchart TB
    A[الحمل الوارد] --> B{بوابة التصنيف<br/>الصعوبة · الحساسية}
    B -->|صعب أو حساس| C[واجهة نموذج متقدم<br/>Claude · GPT-5.6 Sol]
    B -->|مهام نمطية ضخمة| D[نماذج مفتوحة مرشحة<br/>مختارة عبر نسبة اجتياز التقييم]
    D --> E[تقديم ذاتي الاستضافة<br/>vLLM · Metis · Kueue GPU]
    C --> F[بوابة سياسات + سجل تدقيق<br/>طبقة تحكم Paxis]
    E --> F
    F --> G[النتيجة]
    F -.رصد تراجع الجودة.-> B

شارك أحد المطورين على منصة X أن هذا النهج خفّض إنفاقه الشهري على واجهات البرمجة من 60 ألف دولار إلى 12 ألف دولار عبر النماذج المفتوحة، أي بنسبة تقارب 80 بالمئة. ولم يتسنَّ التحقق من المنشور الأصلي بشكل مستقل لأن الوصول إليه كان مقيداً، لذا يُعامَل الرقم باعتباره غير مؤكد ولغرض المرجعية فقط. غير أن حجم الوفورات نفسه يتسق مع البيانات الموثقة: التكلفة الأقل بنسبة 60 إلى 90 بالمئة للنماذج الصينية المفتوحة، وحرب الأسعار الدائرة بين مختبرات النماذج المتقدمة نفسها، تشير جميعها إلى الاتجاه ذاته.

دلالات الأمر على منتجات ThakiCloud

هذا الدليل واضح من الناحية المفاهيمية، لكن تنفيذه فعلياً يتطلب أمرين: بنية تحتية تقدّم النماذج المفتوحة بتكلفة منخفضة، وطبقة تحكم تختار النموذج المناسب لكل مهمة مع ضمان الأمان عبر السياسات والتدقيق. توفر ThakiCloud هذين المحورين معاً من خلال منتجين.

ai-platform: بنية تحتية منخفضة التكلفة للتقديم

ai-platform هي بنية تحتية لتقديم أنظمة الذكاء الاصطناعي والتعلم الآلي مبنية على Kubernetes. تُجدوِل وحدات معالجة الرسوميات عبر Kueue، وتُقدّم النماذج المفتوحة عبر vLLM، وتدعم العزل متعدد المستأجرين والنشر المحلي. الخطوة الرابعة من دليل الترحيل، أي نشر النموذج المفتوح المختار على البنية التحتية الخاصة لخفض التكلفة لكل وحدة، تحدث في هذه الطبقة تحديداً. وبالنسبة للعملاء الذين لا يمكنهم إرسال بياناتهم خارج نطاقهم، مثل الجهات الحكومية أو الصناعات الخاضعة للتنظيم، يصبح النشر السيادي عاملاً حاسماً، وهو متطلب لا تستطيع واجهات النماذج المتقدمة تلبيته من الأساس.

Paxis: السحابة الأصيلة للوكلاء التي تُنفذ الترحيل

Paxis هي طبقة التحكم الأصيلة للوكلاء التي تعمل فوق ai-platform. فكما تتعامل السحابة التقليدية مع الأجهزة الافتراضية وقواعد البيانات كموارد من الدرجة الأولى، تتعامل Paxis مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. ومن منظور دليل الترحيل، يُعد توجيه النموذج الجزء الأهم. تستخدم Paxis ملف models.yaml كمصدر حقيقة وحيد لتوجيه Claude وOpenAI وOllama وKimi وMiniMax، بالإضافة إلى تقديم vLLM الخاص بـ ai-platform (المسمى Metis)، جميعها من مكان واحد. وهذا يقابل تماماً الخطوتين الثالثة والخامسة من الدليل المذكور أعلاه: تحديد النموذج لكل نوع مهمة، وإعادة مهمة بعينها إلى النموذج المتقدم لحظة تراجع الجودة، وهو قرار يُتخذ في هذه الطبقة.

إضافة إلى ذلك، توفر Paxis طبقة مهارات تختار من بين أكثر من 960 مهارة باستخدام خوارزمية BM25، وتنفيذاً معزولاً داخل صندوق رملي، ومحرك معرفة قائماً على الويكي، وتنسيقاً متعدد الوكلاء عبر رسم بياني موجه (DAG)، وموصلات MCP مع إعادة اتصال تلقائية عبر OAuth. ويمر كل إجراء يقوم به الوكيل عبر بوابة سياسات وسجل تدقيق. بمعنى آخر، يمكن التحول إلى نماذج أرخص مع الاحتفاظ بالقدرة على تتبع ما عولج بأي نموذج بدقة.

يمكن تلخيص العلاقة بين المنتجين في جملة واحدة: التقديم منخفض التكلفة (ai-platform) هو ما يصنع اقتصاديات الوكيل (Paxis). فبدون بنية تحتية قادرة على تشغيل النماذج المفتوحة بتكلفة منخفضة، تبقى قواعد التوجيه مجرد خطة على الورق، وبدون توجيه وسياسات، يتحول التقديم الرخيص إلى مخاطرة لا يمكن التحكم بها. تحويل الترحيل إلى عمل حقيقي يتطلب المحورين معاً في آنٍ واحد. وتجدر الإشارة إلى أن Paxis ما زالت في مرحلة إثبات المفهوم، وقد تتغير واجهاتها ومخططاتها بسرعة.

الحدود والحجج المضادة

إنهاء هذا العرض بتفاؤل مطلق لن يكون أمانة. الحجج المضادة واضحة.

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

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

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

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

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

المصادر

• Microsoft reportedly ditching OpenAI’s, Anthropic’s AI models to cut costs (SiliconANGLE)
• Chinese AI models gain ground with US companies on cost (CNBC)
• Meta plans cloud business to sell AI compute (CNBC)
• OpenAI expands GPT-5.6 Sol access and pricing (CNBC)

تجسيد تجريدي لفكرة نموذج صُمم من الأساس للبرمجة ومهام الوكلاء.

نظرة عامة

Grok 4.5 هو نموذج أعلنت SpaceXAI أنها دربته من الصفر للبرمجة والوكلاء المستقلين. لم يُموضَع كروبوت محادثة استهلاكي، بل كأداة للتطوير والعمل المعرفي، ويستهدف قواعد الأكواد الكبيرة واستخدام الأدوات والمهام طويلة الأمد. وصفه Elon Musk بأنه نموذج “بمستوى Opus لكنه أسرع وأكثر كفاءة من حيث الرموز وأقل تكلفة”. وOpus المشار إليه هنا كان حتى وقت قريب فئة النماذج الأعلى لدى Anthropic.

سبب تجاوز هذا الإعلان مجرد إطلاق نموذج جديد يكمن في السعر وطريقة التدريب. سُعّر Grok 4.5 بـ2 دولار لكل مليون رمز إدخال، و6 دولارات لكل مليون رمز إخراج. طرح أداء بمستوى الطليعة (frontier) بهذا السعر يهز الافتراض السائد بأن “النماذج الذكية باهظة الثمن بحيث يصعب تشغيلها كوكلاء لفترات طويلة”. من منظور Thaki Cloud، هذا التحول ليس شأناً بعيداً عنا. فالذكاء الوكيلي الرخيص يغيّر مباشرة اقتصاديات المنصات التي تشغّل الوكلاء بشكل دائم.

ماذا أُعلن

فيما يلي ملخص الحقائق المُعلنة. Grok 4.5 هو أول نموذج من SpaceXAI مُدرَّب خصيصاً لمهام البرمجة والوكلاء، وتزعم الشركة أنه يتفوق على النماذج المماثلة في الهندسة والعمل المعرفي. جرى التدريب جنباً إلى جنب مع محرر الأكواد Cursor، في سياق استحواذ SpaceXAI على Cursor ثم صقل النموذج داخل بيئة استخدامه. وبالفعل، أصبح Grok 4.5 متاحاً منذ إطلاقه في جميع خطط Cursor، كما يُقدَّم عبر Grok Build وواجهة SpaceXAI. غير أنه، حتى وقت الإعلان، لا يزال غير متاح في الاتحاد الأوروبي.

كُشف أيضاً عن البنية التحتية للتدريب. أوضحت الشركة أنها دربت هذا النموذج على عشرات الآلاف من وحدات معالجة الرسوميات NVIDIA GB300، واستثمرت بشكل كبير في التعلم المعزز (RL) لرفع الذكاء لكل رمز (per-token intelligence). وتشرح SpaceXAI أن هذا الاستثمار بالتحديد هو ما خلق فجوة الكفاءة في الرموز مقارنةً بـOpus 4.8. بمعنى آخر، دُرِّب النموذج على إنجاز المهمة ذاتها بعدد أقل من الرموز، وهو ما يترجم مباشرة إلى خفض تكلفة الاستخدام الفعلي.

ماذا يعني “التدريب المخصص للبرمجة والوكلاء”

عبارة “دُرِّب للبرمجة والوكلاء” يسهل تجاهلها كشعار تسويقي، لكنها تحمل توجهاً تصميمياً محدداً. تُحسَّن النماذج الحوارية العامة للإجابة بشكل طبيعي عن مواضيع واسعة النطاق. أما نماذج الوكلاء فجوهرها القدرة على استدعاء الأدوات عبر خطوات متعددة، ومراقبة النتائج الوسيطة، وتعديل الخطة، وإتمام مهام طويلة. هذه القدرة لا تُكتسب من جودة استجابة واحدة فقط، بل يلعب التعلم المعزز الذي يُعيد تغذية نجاح المسار (trajectory) بأكمله كإشارة مكافأة دوراً كبيراً فيها.

flowchart TB
    A["تعليمات المهمة من المطوّر"] --> B["الوكيل: استكشاف قاعدة الأكواد"]
    B --> C["استدعاء الأدوات: تعديل الملفات واختبارها"]
    C --> D["مراقبة النتائج الوسيطة"]
    D --> E{"هل اكتملت المهمة؟"}
    E -->|"لا"| B
    E -->|"نعم"| F["الناتج النهائي"]
    G["تدريب RL على الذكاء لكل رمز"] -.تأثير.-> C
    G -.تأثير.-> D

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

التحول الذي يصنعه السعر

تقديم أداء بمستوى الطليعة مقابل 2 دولار لكل مليون رمز إدخال و6 دولارات لكل مليون رمز إخراج يغيّر حسابات الربح والخسارة في تشغيل الوكلاء. في مسارات العمل التي يستهلك فيها الوكيل ملايين الرموز وهو يتنقل طوال اليوم عبر قاعدة الأكواد، يحدد سعر الرمز مباشرة هامش ربح الخدمة. وإذا تقارب الأداء، يفوز النموذج الأرخص. وبالفعل تشير عدة تحليلات إلى أن Grok 4.5 أرخص بكثير من Fable 5 وGPT 5.5، بحيث قد يُختار على أساس السعر وحده إذا لم تكن فجوة النتائج القياسية (benchmark) كبيرة.

أهمية هذه النقطة تكمن في أن الذكاء الوكيلي الرخيص يعيد فتح مسارات عمل كانت قد طُويت بسبب التكلفة. فكلما كانت المهمة أكثر استهلاكاً للرموز - كأتمتة مراجعة الأكواد، وإعادة الهيكلة (refactoring) واسعة النطاق، ووكلاء المراقبة الدائمة - كان أثر خفض السعر أكبر. لكن هذا الحساب يأتي مع تحفظ. فانخفاض سعر واجهة برمجة التطبيقات (API) هو أيضاً ثمن للتبعية لمزود سحابي. تخرج البيانات إلى الخارج، وتخضع سياسة التسعير والتوافر لقرارات المزود. وحقيقة أن Grok 4.5 لا يزال غير متاح في الاتحاد الأوروبي تُظهر أن هذه التبعية خطر حقيقي وليس افتراضياً.

من منظور Thaki Cloud

ظهور نماذج الوكلاء الرخيصة يمسّ منتجَي Thaki Cloud كليهما.

من منظور Paxis، تعزز نماذج الوكلاء منخفضة التكلفة وعالية الأداء مثل Grok 4.5 فرضية Agent-Native Cloud. Paxis هي طبقة تحكم للوكلاء تعمل فوق ai-platform، وتتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. في بنية ينفّذ فيها الوكيل مهمة طويلة عبر عشرات الخطوات، تحتاج - أياً كان النموذج المستخدم - إلى طبقة تُمرِّر سلوكه عبر بوابات السياسات وتُسجّله في سجلات التدقيق. فكلما رخُص النموذج، زاد تشغيل الوكلاء أكثر ولفترات أطول، وكلما زادت قيمة التنسيق (orchestration) والحوكمة. الذكاء الرخيص لا يقلل من الحاجة إلى منصة الوكلاء، بل يزيدها.

من منظور ai-platform، تتضح المفاضلة مع الاستضافة الذاتية. سعر API المنخفض جذاب، لكنه عائق أمام المؤسسات التي لديها متطلبات سيادة البيانات والامتثال التنظيمي والنشر داخل المنشأة (on-premise) بسبب التبعية. تقدّم ai-platform التابعة لـThaki Cloud نماذج مفتوحة الأوزان (open-weight) تُخدَّم في بيئتها الخاصة اعتماداً على K8s وKueue، مما يتيح تشغيل مسارات عمل الوكلاء دون إخراج البيانات إلى الخارج. الجمع بين “الذكاء لكل رمز” والخدمة الفعالة الذي أظهره Grok 4.5 يطرح على معسكر الاستضافة الذاتية تحدياً في الاتجاه نفسه: للمنافسة مع واجهات برمجة التطبيقات السحابية الرخيصة، لا بد من تحقيق كفاءة في الرموز وتكلفة خدمة منخفضة أيضاً على مستوى المنشأة. وهذا يتقاطع تماماً مع توجهنا الذي يجعل من انخفاض تكلفة الخدمة ميزة تنافسية.

القيود وحجج مضادة

عند تقييم هذا الإعلان، ينبغي التحفظ على عدة نقاط. أولاً، يستند جزء كبير من ادعاءات الأداء إلى إعلانات الشركة نفسها. تعبيرات مثل “بمستوى Opus” أو “يتفوق على النماذج المماثلة” من الأسلم التعامل معها كتسويق إلى أن يجري التحقق منها بشكل مستقل عبر نتائج قياسية (benchmarks) مستقلة. والتفوق الفعلي في مهام البرمجة والوكلاء يختلف بشكل كبير باختلاف عبء عمل كل مستخدم.

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

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

المصادر

• Axios, “Scoop: SpaceXAI launches new model, Grok 4.5”
• TechCrunch, “SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’”
• The Decoder, “Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much”

لكن GLM-5.2 الذي كشفت عنه Zhipu يسير عكس هذا التيار تمامًا. تخلى هذا النموذج عن الأسلوب النسبي الجماعي وعاد إلى PPO باستخدام نموذج قيمة مدرَّب من جديد، وعالج بدلاً من ذلك عدم التطابق بين توزيعي التدريب والاستدلال، وهو أحد أكبر مصادر عدم الاستقرار المزمنة في التعلم المعزز، عبر تقنية تُسمى IcePop. والمثير أن هذا الاختيار ليس مجرد رجوع بسيط، بل يحمل طابع الدحض العملي للفكرة الشائعة مؤخرًا بأن «GRPO هو الحل الشامل».

تصوير لتحول الاتجاه في التدريب اللاحق بالتعلم المعزز، من التخلي عن الـ critic إلى استعادته مجددًا.

نظرة عامة

GLM-5.2 نموذج مفتوح الأوزان بنافذة سياق تصل إلى مليون رمز (token)، ويُظهر أداءً قويًا في اختبارات المعايير الطويلة النفَس للبرمجة والوكلاء (agents). ما يتناوله هذا المقال ليس أرقام أداء النموذج نفسه، بل قرارات التصميم في التدريب اللاحق بالتعلم المعزز التي أنتجت هذا الأداء. والجوهر هنا نقطتان. الأولى، العودة إلى PPO باستخدام نموذج قيمة مدرَّب بدلاً من الأسلوب النسبي الجماعي (GRPO). والثانية، تخفيف عدم التطابق بين التدريب والاستدلال الناتج عن ذلك عبر IcePop، مع إزالة حد التنظيم KL الذي كان موجودًا في الصياغة الأصلية لـ IcePop من أجل رفع سرعة تحسّن التعلم المعزز.

هذا الموضوع مهم من منظور ThakiCloud لسبب واضح. خط أنابيب تدريب النماذج اللغوية الكبيرة الذي نشغّله يدعم عدة أساليب للتدريب اللاحق مثل SFT وCPT وDPO وGRPO وGKD. اختيار منهجية التعلم المعزز ليس مجرد تفضيل خوارزمي، بل قرار بنيوي يؤثر مباشرة في ميزانية وحدات معالجة الرسوميات (GPU) واستقرار التدريب وقابلية إعادة الإنتاج. حالة GLM-5.2 تدفعنا إلى إعادة طرح السؤال، ليس «ماذا نستخدم» بل «لماذا نستخدمه».

الجدار الذي اصطدم به GRPO: ثمن التخلي عن الـ critic

لنبدأ أولاً بسبب انتقال هذا العدد الكبير من الفرق إلى GRPO. الـ PPO التقليدي بنية actor-critic. السياسة (actor) تولّد الرموز، ونموذج قيمة منفصل (critic) يقدّر المكافأة المتوقعة لكل حالة. من هذا التقدير تُحسب الأفضلية (advantage، غالبًا عبر GAE)، وتُحدَّث السياسة عبر دالة هدف بديلة (surrogate) مقصوصة (clipped). المشكلة هي تكلفة تدريب هذا الـ critic. يجب إضافة نموذج آخر بحجم يقارب حجم السياسة نفسها، وإذا تقارب الـ critic بشكل خاطئ، يهتز التدريب بأكمله.

يتخلى GRPO عن هذا الـ critic تمامًا. بعد أخذ عينات من عدة استجابات لنفس المُوجِّه (prompt)، يُطبَّع المكافأة داخل تلك المجموعة، فتُبنى الأفضلية اعتمادًا فقط على التفوق النسبي. باختفاء الـ critic، تنخفض الذاكرة المستخدمة، ويختفي معه عدم استقرار تدريب نموذج القيمة. وبفضل أناقته الرياضية أيضًا، انتشر بسرعة.

لكن لا توجد وجبة مجانية. تتلاشى إشارة الأفضلية في الأسلوب النسبي الجماعي عندما يكون التباين داخل المجموعة صغيرًا، أي عندما تكون الاستجابات متقاربة في الجودة سواء كانت جيدة أو سيئة. كذلك يصعب إسناد الفضل (credit assignment) الدقيق على مستوى الرمز في التسلسلات الطويلة. لو وُجد نموذج قيمة، لأمكن تقدير «مدى إسهام هذا الرمز في المكافأة النهائية» لكل حالة، لكن التطبيع الجماعي وحده لا يوفر هذه الدقة. تبرز هذه المحدودية بوضوح في المسائل ذات المسارات الطويلة والمكافآت النادرة، كأعمال البرمجة والوكلاء طويلة النفَس. وهذا بالضبط المجال الذي استهدفه GLM-5.2.

اختيار GLM-5.2: PPO بإحياء نموذج القيمة

هنا يستعيد فريق GLM-5.2 نموذج القيمة المدرَّب. أي أنهم يستعيدون الـ critic الذي تخلى عنه GRPO، لاستعادة دقة تقدير الأفضلية على مستوى الرمز. وعلى عكس التصور السائد بأن «ضجة PPO مبالغ فيها»، راهن الفريق على أن نموذج قيمة مدرَّبًا جيدًا يمنح إشارة أكثر استقرارًا في المسارات الطويلة.

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

flowchart TB
    A["دفعة من المُوجِّهات (prompts)"] --> B["محرك الاستدلال SGLang<br/>توليد التجارب (rollout)"]
    B --> C["الرموز المولَّدة + المكافآت"]
    C --> D["محرك التدريب Megatron<br/>إعادة حساب forward"]
    D --> E{"احتمال الاستدلال ≠ احتمال التدريب<br/>عدم تطابق التوزيع"}
    E -->|"بلا تصحيح"| F["انفجار نسبة الأهمية<br/>انهيار التدريب"]
    E -->|"إخفاء IcePop"| G["كبح الرموز عالية عدم التطابق<br/>تحديث سياسة مستقر"]
    G --> H["تحديث PPO لنموذج القيمة"]
    H --> A

IcePop: كيفية معالجة عدم التطابق بين التدريب والاستدلال

يتنقل التدريب اللاحق الحديث بالتعلم المعزز بين محركين مختلفين. يتولى توليد التجارب (rollout) محرك استدلال عالي الإنتاجية مثل SGLang، بينما يتولى حساب forward الفعلي لتحديث السياسة محرك تدريب مثل Megatron. المشكلة أن هذين المحركين، حتى لو استخدما نفس أوزان النموذج، يختلفان في تنفيذ النواة (kernel) والدقة العددية وترتيب العمليات، فينتجان احتمالات مختلفة قليلاً لنفس الرمز.

يصحّح التعلم المعزز عادةً هذه الفجوة عبر أخذ العينات بالأهمية (importance sampling)، أي ضرب نسبة احتمال السياسة وقت الاستدلال إلى احتمالها وقت التدريب. لكن عند الرموز التي يتباعد فيها التوزيعان، تنفجر هذه النسبة صعودًا أو هبوطًا بشكل حاد. وإذا سيطرت بضعة رموز ذات نسبة متطايرة على التدرّج (gradient)، يهتز التدريب بأكمله، وقد ينهار في الحالات الشديدة. وكلما طال المسار، أي زاد عدد الرموز، ارتفع احتمال تراكم هذا التطاير. وكان هذا تحديًا حاسمًا بالنسبة لـ GLM-5.2 الذي استهدف الأعمال طويلة النفَس.

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

النقطة التي يختلف فيها GLM-5.2 عن IcePop الأصلي هي إزالة حد التنظيم KL. تفرض كثير من وصفات التعلم المعزز عقوبة KL لمنع السياسة من الابتعاد كثيرًا عن السياسة المرجعية. يرفع هذا الحد الاستقرار، لكنه في الوقت نفسه يكبح المدى الذي يمكن أن تتحسن فيه السياسة. رأى فريق GLM-5.2 أن إخفاء IcePop لعدم التطابق في التوزيع يعالج بالفعل جزءًا كبيرًا من عدم الاستقرار، فأزالوا حد KL للسماح للسياسة بالتحسن بجرأة أكبر. وبذلك استغنوا عن أداة استقرار واحدة، وأوكلوا دورها إلى انتقاء الرموز في IcePop.

البنية التحتية: slime وMegatron وSGLang

لكي لا تبقى هذه الخوارزمية مجرد فكرة على الورق وتعمل فعليًا، لا بد من بنية تحتية تتحمل توسّع التعلم المعزز. جرى التدريب اللاحق لـ GLM-5.2 على إطار عمل لتوسيع التعلم المعزز يُسمى slime، ويستخدم Megatron-LM للتدريب الموزَّع وSGLang لتوليد التجارب عالي الإنتاجية. وعدم التطابق بين التدريب والاستدلال الذي شرحناه سابقًا ينبع بالضبط من هذا التكوين. تتباعد الاحتمالات لأن Megatron (التدريب) وSGLang (الاستدلال) يستخدمان كل منهما نواة محسَّنة خاصة به، ويستهدف IcePop تحديدًا هذه الفجوة البنيوية.

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

دلالات التطبيق على منتجات ThakiCloud

منصة ai-platform لدى ThakiCloud بنية تحتية للذكاء الاصطناعي وتعلم الآلة قائمة على K8s، تشغّل خط أنابيب تدريب يدعم جدولة وحدات معالجة الرسوميات عبر Kueue وأساليب متعددة للتدريب اللاحق (SFT وCPT وDPO وGRPO وGKD). حالة GLM-5.2 تحمل دلالات مباشرة لتصميم هذا الخط.

أولاً، منهجية التعلم المعزز ليست خيارًا يُثبَّت مرة واحدة، بل اختيارًا يُحدَّد بحسب طبيعة المسألة. في محاذاة التفضيلات ذات المسارات القصيرة، يظل GRPO بلا critic خيارًا اقتصاديًا. لكن في المسائل التي يهم فيها إسناد الفضل على مستوى الرمز، كمسارات البرمجة والوكلاء الطويلة، قد يمنح PPO بنموذج قيمة إشارة أكثر استقرارًا. في بنية مثل بنيتنا التي تدعم عدة أساليب على منصة واحدة، فإن إتاحة هذا الاختيار للمستخدم بحسب طبيعة مسألته يخلق قيمة عملية حقيقية.

ثانيًا، عدم التطابق بين التدريب والاستدلال ليس أمرًا بعيدًا عنا. عند تشغيل تعلم معزز مُقسَّم (يُستخرج فيه التجريب من محرك استدلال من عائلة vLLM/SGLang بينما يجري التحديث في محرك التدريب) في بيئة متعددة المستأجرين، تنشأ فجوة الاحتمالات نفسها. وإذا جهّزنا تصحيحًا لانتقاء الرموز على غرار IcePop كخيار في بيئة التشغيل التدريبية، يمكن أن نرفع بشكل كبير استقرار التدريب لدى العملاء الذين يريدون صقل نماذجهم الخاصة بالتعلم المعزز في بيئات محلية (on-premise) أو سيادية. تكلفة خدمة منخفضة وخط أنابيب تدريب مستقر ميزتان تنافسيتان حاسمتان لأي فريق يدرس الاستضافة الذاتية.

من منظور الوكلاء (agents)، ترتبط هذه الحالة أيضًا بـ Paxis. Paxis سحابة أصيلة الوكلاء (Agent-Native Cloud) تعمل فوق ai-platform، تتعامل مع المهارات والأدوات والسياسات كموارد من الدرجة الأولى. تدريب مسارات الوكلاء طويلة النفَس الذي شدّد عليه GLM-5.2 هو في جوهره تعزيز لقدرة الوكيل على إنجاز المهام عبر استدعاء الأدوات على مدى خطوات متعددة. والدرس المستفاد من هذه الحالة، وهو أن نموذج قيمة مدرَّبًا جيدًا يمنح إشارة دقيقة في المسارات الطويلة، مرجع يستحق الاعتبار عند التفكير في استراتيجية تدريب ترفع جودة تدفقات عمل الوكلاء متعددة الخطوات التي تتعامل معها Paxis.

القيود والاعتراضات

يجب توخي الحذر عند تعميم هذه الحالة. أولاً، لا ينبغي قراءتها كخلاصة مبسطة مفادها أن «PPO أفضل من GRPO». اختيار GLM-5.2 حكمٌ في سياق مسألة محددة تتسم بالمسارات الطويلة والمكافآت النادرة. في المسائل ذات المكافآت القصيرة وعالية الكثافة، قد تفوق تكلفة الحفاظ على الـ critic فائدتَه، وفي هذه الحالة يبقى GRPO خيارًا معقولاً. كما أن القيد الواقعي المتمثل في عودة ميزانية ذاكرة وحدات معالجة الرسوميات إلى الارتفاع بمجرد إحياء نموذج القيمة يظل قائمًا كما هو.

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

أخيرًا، الشرح التقني في هذا المقال توليف من تحليلات منشورة وورقة بحثية (على arXiv بعنوان “GLM-5: from Vibe Coding to Agentic Engineering”) وشروحات ثانوية. يجب التحقق من المعاملات الفائقة (hyperparameters) الدقيقة والأرقام الفعلية لاختبارات المعايير من المصدر الأصلي مباشرة، وقد تكون تفاصيل تنفيذية لم يتطرق إليها هذا المقال حاسمة في إعادة الإنتاج الفعلية. التدريب اللاحق بالتعلم المعزز مجال يصعب فيه إعادة الإنتاج بشكل خاص، لذا من الأسلم تلقّي هذا المقال باعتباره «اتجاهًا يستحق التفكير فيه» لا «وصفة مضمونة النجاح».

المصادر

• arXiv, “GLM-5: from Vibe Coding to Agentic Engineering” (arXiv:2602.15763)
• “Why is GLM-5.2 So Good: The GRPO to PPO Switch”, Medium (Coding Nexus)
• “Zhipu’s GLM-5.2: A Usability Breakthrough for Chinese Open-Source Models?”, Weijin Research

الحقيقة الأساسية هي التالية: سجّل GPT-5.6 Sol نسبة 7.78% على مجموعة ARC-AGI-3 شبه الخاصة (semi-private)، محققاً رقماً قياسياً جديداً (SOTA)، وأصبح أول نموذج طليعي تم التحقق منه ينهي إحدى ألعاب ARC-AGI-3 بالكامل من البداية للنهاية. لكن اللافت هو تفسير ARC Prize لسبب هذا التفوق: لم ينجح Sol لأنه ينفّذ كل خطوة بدقة أكبر، بل لأنه كان أفضل في orientation، أي القدرة على تحديد اتجاهه بنفسه في موقف لم يره من قبل.

تجسّد اللحظة التي تتقارب فيها الفوضى المتناثرة في بيئة غريبة بلا تعليمات نحو اتجاه واحد، وهي جوهر ما يُعرف بـ orientation.

نظرة عامة

هذا المقال لا يتناول ترتيب GPT-5.6 Sol العام بين النماذج. بل يتناول لماذا حقق هذا النموذج تقدماً ملموساً تحديداً في ARC-AGI-3 دون غيره من الاختبارات، وماذا يعني هذا التقدم لمن يبني عملاء ذكاء اصطناعي ويشغّلها فعلياً في الإنتاج، كما هو حالنا.

تنقسم سلسلة ARC-AGI إلى نوعين مختلفين جوهرياً من المسائل. تقيس ARC-AGI-1 وARC-AGI-2، وهما ألغاز شبكية ثابتة، ما يُسمى fluid intelligence السلبي، أي القدرة على استنتاج قاعدة وإنتاج الشبكة الصحيحة. أما ARC-AGI-3 فهي مسألة من نوع مختلف تماماً: بيئة لعبة تفاعلية تُلعب بالأدوار (turn-based) بلا أي تعليمات، يتوجّب على العميل فيها أن يتصرف بنفسه ليكتشف القواعد ويحقق الهدف. بعبارة أخرى، انتقل المحور من مسألة إصابة الإجابة الصحيحة إلى مسألة التكيّف مع عالم غير مألوف.

هذا الفرق مهم من منظور ThakiCloud. معظم أعباء العمل الخاصة بالعملاء الذكيين التي نتعامل معها أقرب إلى الحالة الثانية. مدى سرعة إدراك العميل للموقف وتحركه بأمان أمام موصل MCP يتصل به لأول مرة، أو واجهة API داخلية لم يرها من قبل، أو مصدر بيانات تغيّر مخططه (schema). هذا هو ما يحدد فعلياً نجاح العميل الذكي في الإنتاج من فشله. وARC-AGI-3 يقيس هذه القدرة بالتحديد ضمن ظروف مخبرية.

ما هو ARC-AGI-3 ولماذا هو بهذه الصعوبة

صُمم ARC-AGI-3 ليكون مقاوماً لنوع التقدم الذي أشبع الجيل السابق. فARC-AGI-1 بات الآن مُشبعاً فعلياً؛ يتقارب Sol وTerra عند نحو 96.5%، بينما يصل حتى النموذج منخفض التكلفة Luna إلى 88%. الاستدلال الثابت بات اليوم قريباً من مسألة محلولة بالنسبة للنماذج الطليعية.

عند الانتقال إلى ARC-AGI-2، تتّسع الفجوة: يسجل Sol نسبة 92% (بتكلفة نحو 1.44 دولار لكل مهمة)، وTerra 83.9% (1.09 دولار)، وLuna 59.5% (0.67 دولار). وحتى هذا المستوى لا يزال يقع ضمن نطاق مدى إتقان حل مسألة معطاة.

المشكلة تكمن في ARC-AGI-3. عند إطلاق هذا المقياس في مارس 2026، لم يتجاوز حتى أفضل نموذج آنذاك نسبة 0.37%. والسبب أن على العميل، داخل لعبة تفاعلية، أن يكتشف بنفسه وبلا أي معلومة مسبقة أي فعل يُحدث أي أثر، وما الهدف، وماذا يعني الفشل. أمر سهل بالنسبة للإنسان، لكنه بالنسبة للنموذج منطقة مجهولة تماماً تقع خارج توزيع بيانات تدريبه.

flowchart TB
    A[سلسلة ARC-AGI] --> B[ARC-AGI-1<br/>ألغاز شبكية ثابتة]
    A --> C[ARC-AGI-2<br/>استدلال ثابت أصعب]
    A --> D[ARC-AGI-3<br/>ألعاب تفاعلية بالأدوار]
    B --> B1[fluid intelligence سلبي<br/>Sol 96.5% مُشبع]
    C --> C1[استدلال قواعد أعمق<br/>Sol 92% / 1.44$]
    D --> D1[بلا تعليمات<br/>اكتشاف القواعد بالفعل]
    D1 --> E[orientation مطلوب<br/>التكيّف مع بيئة غير مألوفة]
    E --> F[الأفضل عند الإطلاق 0.37%<br/>غير محلول فعلياً]

يوضح هذا التركيب أن ARC-AGI-3 يقيس محوراً مختلفاً جذرياً عن باقي الاختبارات. فإذا كان الجيلان الأولان يتعلقان برفع دقة الذكاء (resolution)، فإن الجيل الثالث يتطلب قدرة الذكاء على التكيّف (adaptability). وهذه القدرة لا تُبنى بدقة التنفيذ وحدها.

نتائج GPT-5.6 Sol بالأرقام

سجّل GPT-5.6 Sol، عند أقصى إعداد لجهد الاستدلال (max reasoning effort)، متوسط 13.33% على مجموعة ARC-AGI-3 العامة (public) و7.78% على المجموعة شبه الخاصة. ورقم 7.8% الذي يتصدّر العناوين هو هذا الرقم شبه الخاص تحديداً. وإذا أخذنا بعين الاعتبار أن الرقم القياسي السابق كان لـ Claude Opus 4.8 بنسبة 1.5%، فهذه قفزة تفوق خمسة أضعاف.

الحدث الأكثر دلالة هو أن Sol أصبح أول نموذج طليعي مُتحقق منه ينهي فعلياً إحدى ألعاب ARC-AGI-3 العامة (ft09). وكانت نسبة نجاح Sol في هذه اللعبة 87%. لم ينهِ أي نموذج لعبة واحدة بالكامل منذ إطلاق هذا المقياس مباشرة، لذا فهذا ليس مجرد تحديث لرقم قياسي، بل أول حالة تتجاوز عتبة نوعية.

لكن يجب النظر إلى التكلفة بصراحة. تصل تكلفة تقييم ARC-AGI-3 الكامل عند أقصى جهد استدلال إلى ما يقارب 20,000 دولار إجمالاً. هذه القدرة لا تزال قدرة تنفتح بالكاد عند أغلى إعداد ممكن. رقم 7.78% إشارة اختراق، وليس إعلاناً بأن المسألة قد حُلّت. وبمقارنته بنسبة 92% في ARC-AGI-2، يتضح أن التكيّف التفاعلي لا يزال متأخراً جيلاً كاملاً عن الاستدلال الثابت.

الاختراق جاء من orientation لا من التنفيذ

أهم نقطة هنا هي تفسير ARC Prize. فسبب أداء Sol الجيد في ARC-AGI-3، بحسب هذا التفسير، ليس أنه نفّذ كل فعل بدقة أكبر، بل أنه تمكّن أولاً من توجيه نفسه (orient) بشكل صحيح داخل بيئة غير مألوفة.

الـ orientation والتنفيذ قدرتان مختلفتان. التنفيذ هو أداء الفعل بدقة عندما تكون تعرف ما يجب فعله في هذا الموقف. أما orientation فهو إدراك بنية الموقف عبر الملاحظة والمحاولة عندما لا يكون واضحاً أصلاً ماذا يجب فعله. تقيس معظم الاختبارات القياسية التنفيذ، لأن المسألة والهدف يُعطيان بوضوح. أما ARC-AGI-3 فيخفي حتى الهدف نفسه، ويقيس orientation بدلاً من ذلك.

هذا التمييز يمسّ مباشرة تصميم العملاء الذكيين في الواقع العملي. اللحظة التي يفشل فيها عميل ذكي في الإنتاج هي غالباً مرحلة orientation، لا مرحلة التنفيذ. نادراً ما ينهار لأنه استدعى الدالة الخطأ؛ بل ينهار لأنه أخطأ منذ البداية في تحديد أي دالة يجب استدعاؤها ولماذا في هذا الموقف بالذات. تشير نتيجة Sol إلى أن orientation محور يمكن أن يتوسّع (scale) بشكل مستقل، وأن اختباراً يقيس هذا المحور قد يكون أكثر ارتباطاً بجودة العميل الذكي الفعلية.

دلالات التطبيق على منتجات ThakiCloud

هذا الموضوع يمسّ منتجَي ThakiCloud كليهما.

عدسة Paxis (orientation العملاء الذكيين). Paxis هي Agent-Native Cloud الخاصة بـ ThakiCloud، حيث تُعامَل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. هنا لا يكون orientation مفهوماً مجرداً بل مسألة تصميم بحتة. في كل مرة يتصل فيها عميل ذكي بموصل MCP جديد لأول مرة، أو يختار من بين نحو 960 مهارة (skill) عبر BM25، فهو في الواقع يحل مسألة تحديد الاتجاه داخل فضاء قدرات غير مألوف من جديد. والدرس المستفاد من ARC-AGI-3 هو ألا تُترك خطوة orientation هذه للنموذج وحده، بل يجب أن يساعد فيها الـ harness. وحين تُنظّم Paxis فضاء الأفعال عبر أوصاف المهارات وبوابات السياسات وسجلات التدقيق، فإنها تعمل كأداة مساعدة على orientation، تتيح للعميل الذكي أن يجد اتجاهه داخل هيكل مُتحقق منه، بدلاً من أن يتخبّط في بيئة مجهولة. وبدون الاعتماد على استدلال مكلف بأقصى طاقته كما فعل Sol، فإن harness يقلّل عبء orientation يمكن أن يجعل التكيّف المستقر ممكناً حتى مع نماذج أرخص.

عدسة ai-platform (اقتصاديات الاستدلال). في الوقت نفسه، تكلفة التقييم البالغة 20,000 دولار هي أيضاً مسألة بنية تحتية للخدمة (serving). فالاستدلال المرتكز على orientation يتطلب عادة مسارات تفكير طويلة ومحاولات كثيرة، وهو ما يترجم مباشرة إلى استهلاك أكبر للـ tokens. تركّز منصة ai-platform الخاصة بـ ThakiCloud على تشغيل أعباء الاستدلال المكلفة هذه بكفاءة من حيث التكلفة في بيئة متعددة المستأجرين (multi-tenant)، عبر K8s وجدولة Kueue للـ GPU وخدمة vLLM. ولكي يُنقل عميل ذكي يتكيّف مع بيئات غير مألوفة إلى الإنتاج فعلياً، لا بد من طبقة خدمة (serving layer) قادرة على خفض تكلفة أقصى جهد استدلال إلى مستوى يمكن تحمّله. وهذا يؤكد مجدداً أن الخدمة الرخيصة هي ما يصنع اقتصاديات العميل الذكي.

باختصار، لا يتحوّل العميل الذكي المتكيّف إلى شيء يمكن تشغيله فعلياً، بدلاً من أن يبقى عرضاً طليعياً مكلفاً، إلا حين توزّع Paxis عبء orientation على الـ harness، وتخفض ai-platform تكلفة ذلك الاستدلال.

القيود والحجج المضادة

لتجنّب المبالغة في تفسير هذه النتيجة، نضع هنا بعض الحجج المضادة.

أولاً، لا تزال نسبة 7.78% رقماً مطلقاً منخفضاً جداً. فالإنسان يُنهي معظم ألعاب ARC-AGI-3 دون عناء يُذكر، بينما بالكاد أنهى أفضل نموذج لعبة واحدة. القول بأن هذا اختراق وصف عادل، لكنه بعيد عن القول بأن المسألة محلولة. ومدى قوة تعميم قدرة orientation هذه لم يُثبت بعد.

ثانياً، تُقابل مشكلة التكلفة جزءاً كبيراً من ادعاء القدرة. فقدرة لا تنفتح إلا عند أقصى جهد استدلال مسألة منفصلة عن إمكانية النشر الفعلي. والسؤال الحقيقي عن القيمة هو: هل تتكرر نفس قدرة orientation بعُشر هذه التكلفة؟ والبيانات الحالية لا تجيب عن هذا السؤال.

ثالثاً، هذه نتيجة تحقّق منها اختبار قياسي واحد فقط. لم يُختبر Fable 5 بعد على ARC-AGI-3، وما إذا كانت قدرة orientation هذه تنتقل إلى مهام عملاء ذكيين فعلية خارج مجموعة ألعاب ARC-AGI-3 يحتاج إلى تحقق منفصل. ولا تتوفر أدلة كافية بعد لاستبعاد احتمال أن يكون النموذج قد بالغ في التكيّف مع هذا الاختبار تحديداً (overfitting).

مع ذلك، يبقى الاتجاه العام واضحاً. في عصر تتشبّع فيه دقة التنفيذ، تصبح orientation عنق الزجاجة التالي، وسيكون قياسها ومساعدتها عبر harness هو الميزة التنافسية التالية للعملاء الذكيين في الواقع العملي. ورقم 7.78% الذي حققه Sol هو الإحداثية الأولى لتلك النقطة الفاصلة.

المصادر

• نتائج GPT-5.6 Sol على ARC-AGI (ARC Prize)
• إعلان ARC Prize (X/Twitter)
• لوحة صدارة ARC Prize
• GPT 5.6 Sol يتصدر ARC-AGI-3 بنسبة 7.8% (OfficeChai)

خلاصة الورقة البحثية “Measuring the Gap Between Human and LLM Research Ideas” (arXiv 2607.01233) تتعارض مع الحدس السائد. نقطة ضعف أفكار LLM لم تكن ما نسميه عادة “الجودة”. الفجوة الحقيقية كانت في الاتساع (range). فكّر LLM ضمن مساحة أضيق بكثير من الباحثين البشريين، وتركّز هذا الضيق بشكل شبه كامل في نمط واحد، وهو فكرة “ربط الأبحاث القائمة ببعضها”.

تصوير بصري يقابل بين التوزيع الواسع لأفكار البشر والتكتل الضيق لأفكار LLM حول نمط واحد.

نظرة عامة

أهمية هذا البحث تنبع من أن وكلاء البحث المستقل لم تعد فكرة بعيدة المنال. تدير فرق عديدة بالفعل حلقات (loops) تُولّد فيها LLM فرضيات، ويُختار جزء منها لتشغيل تجارب تلقائياً. تشغّل ThakiCloud أيضاً حلقة بحثية خاصة بها تسحب فرضيات تجريبية ليلاً من نشاط الوحدات الفرعية (submodules) والاتجاهات، وتضعها في قائمة انتظار، ثم تنفّذها تلقائياً. جودة حلقة كهذه تعتمد في النهاية على مدى تنوّع وجودة البذور التي ينتجها مولّد الأفكار.

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

ماذا تم قياسه: تجربة أفكار محكومة

أبرز ما يميز هذه الورقة هو الصرامة المنهجية. الحكم على الأفكار بأنها “جيدة” أو “سيئة” أمر ذاتي ويصعب قياسه مباشرة. تجاوز الباحثون هذه المشكلة عبر تجربة محكومة.

اختاروا أولاً 11,683 ورقة بحثية عالية الجودة من ICLR وICML وNeurIPS وNature Communications. ولكل ورقة، أعادوا هندسة مجموعة صغيرة من الأبحاث السابقة الوثيقة الصلة التي يُرجَّح أنها ألهمت فكرتها الأساسية. ثم أعطوا LLM عناوين وملخصات تلك الأبحاث السابقة فقط، وطلبوا منه توليد فكرة جديدة انطلاقاً من هذه النقطة. بمعنى آخر، أُعطي الباحثون البشريون وLLM نقطة انطلاق واحدة تماماً، وهي المجموعة نفسها من الأبحاث السابقة، والمقارنة تسأل إلى أين يتجه كلٌّ منهما من هناك.

flowchart TB
    A[11,683 ورقة بحثية عالية الجودة<br/>ICLR, ICML, NeurIPS, Nature Comm] --> B[الفكرة الأساسية لكل ورقة]
    B --> C[الأبحاث السابقة الملهمة<br/>مستخرجة بالهندسة العكسية]
    C --> D[نقطة انطلاق واحدة]
    D --> E[البشر: الفكرة المنشورة فعلاً]
    D --> F[LLM: فكرة جديدة مولّدة<br/>من العناوين والملخصات]
    E --> G[تصنيف ثنائي المحاور لذائقة البحث<br/>نمط الفرصة x منهج البحث]
    F --> G
    G --> H[مقارنة التوزيع<br/>البشر مقابل LLM]

معيار المقارنة كان تصنيفاً يقسّم “ذائقة البحث” إلى محورين. الأول هو نمط الفرصة، أي نوع الثغرة التي تحفّز العمل البحثي. والثاني هو منهج البحث، أي المنهجية التي تعالج بها تلك الثغرة. رسم الباحثون أفكار البشر وLLM على هذا النظام الإحداثي، وقاسوا كمياً مدى تداخل التوزيعين ونقاط تباعدهما. شملت النماذج التي جرى تقييمها عائلات LLM الرئيسية بما فيها Claude وGemini وGPT وDeepSeek وQwen.

الاكتشاف الجوهري: الفجوة في الاتساع لا في الجودة

يمكن تلخيص النتيجة بجملة واحدة. أفكار LLM المولَّدة شغلت مساحة أضيق بكثير من أفكار البشر ضمن النظام الإحداثي لذائقة البحث.

يظهر هذا الضيق بأوضح صوره في نمط “الربط” (connection). نمط الربط يؤطّر دافعه بأن “أدبيات أو أساليب أو أدلة متفرقة تحتاج إلى ربطها ببعضها”، ويطوّر منهجه عبر دمج مقاربات قائمة أو التوفيق بينها أو توحيدها. بعبارة بسيطة، هي أفكار من نوع “ماذا لو جمعنا بين A وB”.

الأرقام تُظهر الفجوة بوضوح تام. لم تتجاوز نسبة أفكار البشر التي كان دافعها نمط الربط 12.1%، ولم تتجاوز نسبة من استخدم الدمج أو التوحيد كمنهج أساسي 5.1%. في المقابل، تراوحت هذه النسب عبر تسعة نماذج LLM رئيسية بين 47.1% و64.2% وبين 22.5% و38.7% على التوالي، أي بمعدل يفوق 4 إلى 5 أضعاف الاعتماد على هذا النمط.

كانت أفكار الباحثين البشريين موزّعة على اتساع أكبر بكثير. أفكار تسعى لتفسير آلية ما، وأفكار تتعمّق في حالات الفشل، وأفكار تحاول قياس أدلة، وأفكار تبني أنظمة، وأفكار تحسّن الكفاءة، جميعها ظهرت بنسب متقاربة نسبياً. أما LLM، فبدلاً من الانتشار عبر هذا الطيف، استمر في الاستقرار داخل الوادي الضيق نفسه لأفكار “الربط” الآمنة والمقنعة ظاهرياً.

لماذا تنجذب LLM إلى “الربط”

هذا التركّز ليس صدفة، بل هو بنيوي. فكرة “ادمج A وB القائمين” هي الخطوة التالية الأكثر أماناً التي يمكن اشتقاقها من مجموعة معطاة من الأبحاث السابقة، حتى على مستوى التنبؤ بالرمز التالي (next token). فهي منخفضة المخاطر، ومقنعة دائماً، وتبدو جديدة على السطح. أما فكرة من نوع “ما هي الآلية الخفية وراء هذه الظاهرة”، فتتطلب قفزة تتجاوز النص المعطى. تميل LLM إحصائياً إلى التقارب نحو الخيار الأول.

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

تداعيات على منتجات ThakiCloud

يمنحنا هذا الاكتشاف توجيهاً تصميمياً مباشراً للوكلاء المستقلين الذين نشغّلهم.

عدسة Paxis: فرض التنوّع عبر الـharness. Paxis هو Agent-Native Cloud الخاص بـThakiCloud، ويتعامل مع تنسيق متعدد الوكلاء قائم على DAG ومهارات ذاتية التطور كموارد من الدرجة الأولى. درس هذه الورقة واضح: ترك توليد الأفكار لنموذج واحد يحصره داخل وادي “الربط”، لذا يجب ألا نترك التنوّع للصدفة، بل يجب فرضه عبر الـharness. عملياً، يعني هذا ثلاثة أمور. أولاً، اعتماد نهج mixture-of-agents يجمع مرشحين من عائلات نماذج مختلفة (Claude وGemini وGPT وDeepSeek وQwen) لتقليل تحيّز النموذج الواحد. ثانياً، تخصيص عدسات مختلفة صراحةً للمشكلة نفسها، كالتفسير الآلي وتحليل الفشل وتحسين الكفاءة، بحيث لا تتقارب الأفكار على نمط الربط وحده. ثالثاً، عدم الوثوق بالأفكار المولَّدة كما هي، بل تصفيتها عبر مرحلة تحقق عدائي (adversarial verify)، بما يمنع الأفكار المقنعة ظاهرياً لكنها ضيقة من عبور خط الأنابيب.

عندما تسحب ThakiCloud فرضياتها من حلقتها البحثية الليلية، يتحوّل هذا المبدأ إلى انضباط تشغيلي فعلي. فبدلاً من الحصول على فرضية واحدة من موجّه (prompt) واحد، يمنع التفرّع عبر عدسات متعددة والتقارب لاحقاً عبر مرحلة التحقق نمط الفشل “الاتساع الضيق” الذي قاسته هذه الورقة مباشرة.

عدسة ai-platform: تكلفة البنية التحتية لتنوّع النماذج. تشغيل عدة عائلات نماذج في آن واحد لضمان تنوّع الأفكار يتطلب طبقة قادرة على خدمة نماذج مفتوحة الأوزان غير متجانسة بكفاءة عبر عدة مستأجرين (tenants). تشغّل منصة ai-platform الخاصة بـThakiCloud مجموعة نماذج غير متجانسة بكفاءة من حيث التكلفة عبر Kubernetes وجدولة GPU بواسطة Kueue وخدمة عبر vLLM. ما يكشفه هذا هو أن تنوّع الأفكار، وهو هدف نوعي، لا يتحقق إلا فوق بنية تحتية للخدمة قادرة على تشغيل نماذج متنوعة بتكلفة منخفضة وبالتوازي.

قيود وحجج مضادة

نقبل هذه النتيجة، لكن مع بعض التحفظات.

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

ثانياً، اتساع الأفكار الأكبر ليس بالضرورة أمراً أفضل. جزء كبير من تنوّع أفكار البشر قد ينتهي في اتجاهات فاشلة في النهاية، وميل LLM نحو أفكار “الربط” قد يكون في الواقع خياراً أكثر أماناً بمعدل نجاح تنفيذي أعلى. قاست هذه الورقة توزيع الأفكار، لا الأفضلية النسبية لنتائج تنفيذها. تبقى العلاقة بين الاتساع والنتائج سؤالاً منفصلاً.

ثالثاً، هناك حساسية تجاه تصميم الموجّه (prompt). لو طُلب من LLM صراحةً “أنتج نوعاً من الأفكار مختلفاً تماماً عمّا هو قائم”، ربما كان التوزيع أوسع. بمعنى آخر، جزء من هذه الفجوة قد يكون نتاج الموجّه الافتراضي وليس قيداً جوهرياً في النموذج، وكون هذا الأمر قابلاً على الأرجح للتصحيح بدرجة كبيرة عبر الـharness هو، من الناحية العملية، الجانب المشجّع في هذه القصة.

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

المصادر

• Measuring the Gap Between Human and LLM Research Ideas (arXiv 2607.01233)
• الورقة الكاملة (HTML)
• مراجعة أدبية (The Moonlight)

Overview

A Claude Code skill is not magic but a standard operating procedure (SOP). It does not make the model smarter; it strongly constrains capabilities the model already has toward a specific direction, raising average quality. For a landing-page skill, that constraint is precisely the design principles, layout rules, and output format.

This view lines up exactly with how ThakiCloud operates agents. Agent quality comes not from the model tier but from the contract structure wrapping the model. A landing-page skill is a good example of concentrating that contract structure into the narrow domain of frontend design. It is also a textbook skill design: reduce degrees of freedom to raise the average.

What This Technique Is

A Claude Code skill is essentially a single markdown file called SKILL.md. Inside it live the principles and rules the agent should follow for a given task, along with the user’s preferences. When the user makes a natural-language request, the relevant skill is injected into the agent’s context, and the agent follows those instructions like an SOP while generating HTML, CSS, and JavaScript locally.

The shape of what landing-page skills produce is consistently observed across several public skills. It is a single self-contained HTML file, with all CSS inlined in <style> and all JavaScript inlined in <script>. External dependencies are limited to Google Fonts and the GSAP animation library loaded via CDN (Claude Directory). One file is all you need to host and serve it anywhere.

flowchart TB
    U[Natural-language request<br/>generate a premium landing page] --> A[Claude Code agent]
    S[SKILL.md<br/>design principles · layout rules · preferences] -.inject.-> A
    A --> G[Single HTML output<br/>inline CSS · inline JS]
    G --> D1[Google Fonts<br/>CDN]
    G --> D2[GSAP animation<br/>CDN]
    D1 --> O[Self-contained page<br/>ships as one file]
    D2 --> O

The key word is “one shot.” When the user describes what they want in plain sentences, the agent produces the whole page in a single pass without many round trips. This works not because the model gets creative, but because the skill has already made most of the decisions about “what makes a good landing page” on the user’s behalf.

The Decisions the Skill Makes for You

When you request a landing page without a skill, the result is generic for a clear reason: the agent has to decide layout, spacing, typography, color contrast, and animation timing from scratch each time, and those decisions converge to a safe average. Public premium landing-page skills fix exactly these decisions up front (MindStudio analysis).

The design philosophy such skills encode is largely consistent. It lays down a base of intentional restraint that strips out the unnecessary, uses asymmetric layouts that break symmetry to steer the eye, and adds psychological triggers on top to lift conversion. It aims at both brand authority and conversion so the result reads as human-crafted rather than template-driven. Some skill authors describe this as “transplanting the expertise of a top-tier design agency into the agent.”

The lesson here is not limited to frontend. A good skill does not give the model freedom; it gives it a validated skeleton and lets it fill in the inside. The more you fix design tokens, layout grids, and output format like code, the smaller the variance per call and the higher the average quality. Conversely, a prose plea like “make it look great” yields a different result every time.

Things to Watch When Building Your Own

If you write such a skill yourself, a few things matter. First, nail down the output format explicitly. Specifying the structure as “single HTML, inline CSS/JS, external dependencies limited to fonts and GSAP” keeps deployment and portability simple. Second, reduce design judgment to rules. Writing spacing scales, typographic contrast, an allowed color palette, and a rule to favor compositor-friendly transform and opacity for animation into the SOP means the agent does not re-deliberate each time. Third, include failure cases. The densest information in a skill is the “do not do this” list. Items like no layout-shifting animations and no violations of accessibility basics are what actually protect output quality (Ryan Doser guide).

One more note: a skill is also a tax. From the moment a skill loads into context it costs tokens, so every sentence must pass the test of “would the agent be wrong without this?” Unnecessary flourish is a net loss.

Implications for ThakiCloud Products

This case resonates with ThakiCloud in particular because we operate a platform that treats skills as first-class resources.

Paxis view (agents and skills). Paxis is ThakiCloud’s Agent-Native Cloud, which treats Skills, Tools, Policies, and Audit Logs as first-class resources. A unit capability like a landing-page skill is exactly what the Paxis Skill Harness manages. We select from hundreds of skills via BM25, inject only the relevant ones into the agent context, run them in an isolated sandbox, and pass every action through a policy gate and audit log. The fact that a single landing-page skill works well also means the same pattern can extend to other domains such as slide generation, document rendering, and infrastructure deployment. The images and documents for this very blog are generated on the same skill harness.

In particular, the principle this case demonstrates, “code owns the format and the model only fills in the content,” maps directly to the Paxis design philosophy. The more you fix the output structure deterministically and narrow the model’s room for judgment, the more consistent the quality across model tiers.

ai-platform view (infrastructure). Some customers want to run these generation workloads on their own infrastructure rather than depending solely on external APIs. ThakiCloud’s ai-platform serves generation models on top of K8s and Kueue-based GPU scheduling, so even in on-premises or sovereign environments you can self-host such skill-based pipelines. The more repetitive and standardized the task, like landing-page generation, the more a low serving cost translates directly into agent economics.

Limitations and Counterpoints

Of course we should be wary of overstatement. The phrase “a premium page in one shot” holds best under demo conditions. A real product landing page carries overlapping requirements such as brand assets, copy review, accessibility compliance, a performance budget, and A/B testing, so a one-shot output is an excellent draft, not a final. In particular, a single HTML with everything inlined is convenient for fast deployment but may need to be split again for caching and maintenance on a real site where multiple pages share assets.

Also, the design taste baked into the skill is the ceiling of the result. If a skill is optimized for a particular aesthetic, it will resist requests that stray from it. This is not a bug but a designed trade-off. It gave up the extremes in exchange for raising the average by reducing freedom, so a team that must handle many brands is better off splitting skills by aesthetic rather than keeping one.

In conclusion, the real value of this case is not “a pretty page comes out in one shot” but that it visibly proved the principle that agent quality comes from skill design, not the model. And Paxis is precisely the productization of that principle into a form operable at the platform level.

Sources

• @the_cyw, “I built a skill to let my Claude Code build premium landing pages”
• Claude Directory: Landing Page Skills
• MindStudio: Claude Code Landing Page Generator Skill
• Ryan Doser: How to Build Landing Pages With Claude Code

Over the past few weeks, the conversation in the AI industry has shifted from “who is smarter” to “who is cheaper.” The most telling scene came from Microsoft. The very company that put OpenAI on the trajectory it now rides has started routing the tens of thousands of weekly AI requests inside Excel and Outlook to its own models instead of OpenAI’s and Anthropic’s. Microsoft’s AI chief Mustafa Suleyman did not hide the reasoning. “Anthropic is extremely expensive. Our goal is to reduce that cost and eventually eliminate it,” he said.

This post is written for engineering leaders, AI teams, and the decision makers who own inference cost for their own services. It explains why the cost war unfolding right now is not transient noise but a structural shift, lays out a migration playbook for moving frontier API spend to open models and self-hosting, and finally explains where ThakiCloud sits as the control plane that actually runs that migration.

What has changed

A single company’s decision does not make a trend. But several signals pointing the same direction have stacked up within a few weeks.

First, Microsoft’s detour was precise. The hardest, rarest tasks still go to frontier models, while only the tedious, high-volume work, things like email replies, thread summaries, and simple spreadsheet formulas, is being reclaimed for its own models. This matters because that tedious bulk work is exactly where the money actually flows (SiliconANGLE report).

Second, US companies are moving toward Chinese open models to escape pricing. According to CNBC, Chinese models handled more than 30 percent of US enterprise AI usage on one major routing platform, peaking at 46 percent, a sharp jump from an average of 11 percent a year earlier. Costs are 60 to 90 percent lower, and on some agentic benchmarks the gap to the top US models has narrowed to within a single point (CNBC report).

Third, a signal of oversupply has surfaced. Meta announced it is preparing a cloud business to sell “surplus” AI compute, effectively turning the admission that it built too much into a business model (CNBC report).

Fourth, the market reacted. In late June, more than a trillion dollars in market capitalization vanished from semiconductor and AI-related stocks within days, and Wall Street began asking whether this enormous spending could actually be recouped (roughly $1.3 trillion by Reuters’ tally, unverified, for reference only).

What these signals share is not that frontier models got worse. If anything, their performance keeps improving. The problem is that even the biggest customers no longer accept the premise of using the best model for every task and paying the top price for it.

Pricing itself is also falling fast. OpenAI’s recently released GPT-5.6 Sol prices at roughly $5 per million input tokens and $30 per million output tokens, a sharp drop in per-token cost from the previous generation (CNBC report). That means the frontier labs are now in a price war with each other too. The front line has shifted from an intelligence war to a value war.

Why now

The cost war is breaking out now because of how workloads are distributed.

Break down what agents handle in a given day and the character splits clearly. On one side sits genuinely hard reasoning: ambiguous design decisions, subtle debugging, breaking down a problem nobody has seen before. On the other side sits standardized, high-volume work: classification, routing, summarization, spec checking, replies in a fixed format. By count, the latter overwhelmingly dominates.

The financial assumption of the frontier labs was simple: that enterprises worldwide would process billions of these small requests forever on expensive models. That endless river of tokens was the basis propping up the frontier companies’ lofty valuations.

But the quality of standardized work is governed more by guardrails than by model intelligence. Output formats drift not because the model lacks capability, but because the format was requested in prose instead of being enforced. When length caps, allowed value sets, rendering specs, and pass criteria are enforced by code, that work comes out reliably even from far cheaper open models. The moment “good enough” becomes achievable for a fraction of the price, reclaiming that river of bulk work becomes the rational move. That is exactly the call Microsoft made.

From frontier to open: the migration playbook

So how do you actually move this river. Switching models on impulse is risky. A reliable migration goes through five steps.

First, classify the workload. Split each request along two axes: difficulty and sensitivity. Keep hard or sensitive tasks on frontier, and mark only the standardized, high-volume work as a migration target.

Second, evaluate substitution candidates. For each task marked for migration, score open-model candidates against real data. The key here is a pass rate computed by code, not a human impression. Run actual outputs through the spec checks, and drop any candidate that falls short of the threshold.

Third, configure routing. Define, in one place, the rules for which model handles which task type. That single source of truth is what makes it easy to swap or roll back models later.

Fourth, self-host the open model. Deploy the selected open model on your own infrastructure using a serving engine like vLLM. This is the step where on-premises deployment, data sovereignty, and unit-cost advantages are actually realized.

Finally, verify and roll back. After migration, keep measuring quality, and if the pass rate slips, move that specific task back to frontier. A migration without a rollback path is not a migration, it is a gamble.

flowchart TB
    A[Incoming workload] --> B{Classification gate<br/>difficulty · sensitivity}
    B -->|Hard or sensitive| C[Frontier API<br/>Claude · GPT-5.6 Sol]
    B -->|Standardized bulk work| D[Open model candidates<br/>selected by eval pass rate]
    D --> E[Self-hosted serving<br/>vLLM · Metis · Kueue GPU]
    C --> F[Policy gate + audit log<br/>Paxis control plane]
    E --> F
    F --> G[Result]
    F -.Quality degradation detected.-> B

On X, one developer shared that this approach took their monthly API spend from $60,000 down to $12,000 on open models, roughly an 80 percent cut. The original post was access-restricted and could not be independently verified, so the figure should be treated as unverified, for reference only. That said, the scale of the savings is consistent with the verified data: the 60 to 90 percent lower per-token cost of Chinese open models, and the price cuts happening between the frontier labs themselves, point in the same direction.

Implications for ThakiCloud’s products

The playbook is conceptually clear, but running it in practice requires two things: infrastructure to serve open models cheaply, and a control plane to choose the model per task while guaranteeing safety through policy and audit. ThakiCloud provides both pillars together through two products.

ai-platform: low-cost serving infrastructure

ai-platform is Kubernetes-based AI/ML serving infrastructure. It schedules GPUs with Kueue, serves open models with vLLM, and supports multi-tenant isolation and on-premises deployment. Step four of the migration playbook, deploying a selected open model on your own infrastructure to bring down unit cost, happens at this layer. For customers who cannot send data outside their own boundary, such as government agencies or regulated industries, sovereign deployment is decisive, a requirement that frontier APIs cannot satisfy to begin with.

Paxis: the Agent-Native Cloud that executes the migration

Paxis is the agent-native control plane running on top of ai-platform. Just as a conventional cloud treats virtual machines and databases as first-class resources, Paxis treats skills, tools, policies, and audit logs as first-class resources. From the migration playbook’s perspective, the most important part is model routing. Paxis uses models.yaml as a single source of truth to cross-route Claude, OpenAI, Ollama, Kimi, MiniMax, and ai-platform’s own vLLM serving (Metis) from one place. This maps directly onto steps three and five of the playbook described above: assigning a model per task type, and rolling a task back to frontier the moment quality slips is a judgment call made at this layer.

Beyond that, Paxis provides a skill harness that selects among more than 960 skills using BM25, isolated sandbox execution, a wiki-based knowledge engine, DAG multi-agent orchestration, and MCP connectors with automatic OAuth reconnection. Every agent action passes through a policy gate and an audit log. In other words, you can switch to cheaper models while still tracking exactly what was processed by which model.

The relationship between the two products can be summarized in one sentence. Low-cost serving (ai-platform) is what makes an agent’s economics (Paxis) work. Without infrastructure that can run open models cheaply, routing rules remain a plan on paper; without routing and policy, cheap serving becomes an uncontrollable risk. Turning migration into a real business requires both pillars at once. Note that Paxis is still at the proof-of-concept stage, and its interfaces and schemas may change quickly.

Limitations and counterarguments

Ending this story on pure optimism would not be honest. The counterarguments are clear.

First, quality gaps still exist. Where open models have closed the distance is standardized tasks and some agentic benchmarks. On breaking down never-seen problems or subtle reasoning over long context, frontier still leads. Trying to move everything to open models means paying back, in failure costs on hard tasks, everything you saved on bulk work. The core of migration is not wholesale replacement but precise classification.

Second, self-hosting is not free. API calls hand the operational burden to the lab, while self-hosting means taking on GPU procurement, serving optimization, and incident response yourself. Once you factor in upfront capital expenditure and operations headcount, API calls can actually be cheaper at small traffic volumes. The break-even point depends on traffic scale and utilization.

Third, widely circulated benchmark numbers should not be taken at face value. While preparing this post, certain benchmark tables and figures could not be traced to a verifiable original source and were left out of the body. Model comparisons should be judged only by results measured directly against your own workload. Someone else’s benchmark is a starting point, nothing more.

Fourth, routing itself adds complexity. A system that moves between multiple models is harder to debug and observe than a single-model system. That is exactly why policy gates and audit logs are not optional, they are required.

Even so, the direction is clear. Now that even Microsoft refuses to pay frontier prices for every task, the real question is who will keep paying that price. The ability to precisely migrate bulk workloads to open models, and to control that migration safely, will be a core competency of AI operations for years to come. ThakiCloud is positioned to provide that migration on both fronts, infrastructure and control plane, together.

Sources

• Microsoft reportedly ditching OpenAI’s, Anthropic’s AI models to cut costs (SiliconANGLE)
• Chinese AI models gain ground with US companies on cost (CNBC)
• Meta plans cloud business to sell AI compute (CNBC)
• OpenAI expands GPT-5.6 Sol access and pricing (CNBC)

An abstract depiction of a model designed from the ground up for coding and agentic work.

Overview

Grok 4.5 is a model that SpaceXAI says it trained from scratch for coding and autonomous agents. Rather than positioning it as a consumer chatbot, the company frames it as a tool for development and knowledge work, aimed at large codebases, tool use, and long-running tasks. Elon Musk introduced the model as “Opus-class, but faster, more token-efficient, and cheaper.” The Opus referenced here is Anthropic’s top model tier until recently.

What makes this announcement more than just another model launch is its pricing and training approach. Grok 4.5 is priced at $2 per million input tokens and $6 per million output tokens. Offering frontier-level performance at this price point shakes the long-standing assumption that “smart models are too expensive to run as agents for long stretches.” From ThakiCloud’s perspective, this shift is not someone else’s problem. Cheap agentic intelligence directly changes the economics of any platform that runs agents around the clock.

What Was Announced

Here is a summary of the disclosed facts. Grok 4.5 is SpaceXAI’s first model trained specifically for coding and agentic work, and the company claims it outperforms peer models on engineering and knowledge-work tasks. Training took place alongside the code editor Cursor, in the context of SpaceXAI having acquired Cursor and then refining the model within that usage environment. In fact, Grok 4.5 is available across all Cursor plans from launch, and it is also offered through Grok Build and the SpaceXAI console. As of the announcement, however, it is not yet available in the EU.

The training infrastructure was also disclosed. The company trained this model across tens of thousands of NVIDIA GB300 GPUs, and stated that it invested heavily in reinforcement learning (RL) for per-token intelligence. SpaceXAI explains that this investment is precisely what created the token-efficiency gap versus Opus 4.8. In other words, the model was trained to handle the same task using fewer tokens, which directly translates into lower real-world costs.

What “Training Specifically for Coding and Agents” Means

The phrase “trained for coding and agents” is easy to dismiss as marketing copy, but it carries a concrete design direction. General-purpose conversational models are optimized to answer naturally across a broad range of topics. Agentic models, by contrast, live or die on their ability to call tools across many steps, observe intermediate results, revise plans, and carry a long task through to completion. That ability cannot be learned from single-response quality alone; reinforcement learning that feeds the success or failure of an entire trajectory back as a reward signal plays a major role.

flowchart TB
    A["Developer task instruction"] --> B["Agent: explore codebase"]
    B --> C["Tool call: edit files, run tests"]
    C --> D["Observe intermediate results"]
    D --> E{"Task complete?"}
    E -->|"No"| B
    E -->|"Yes"| F["Final output"]
    G["Per-token intelligence RL training"] -.influences.-> C
    G -.influences.-> D

The “per-token intelligence” SpaceXAI emphasizes should be read in this context. The structural reason token consumption explodes when an agent works on a long task is that the model tends to think more verbosely than necessary before reaching the same conclusion, or repeats unnecessary tool calls. Training the model to pack more judgment into each token lets it complete the same task in a shorter trajectory. Training inside Cursor, a real coding environment, ties into this as well. Using real-world tool-call patterns as a training signal can push an agent toward handling tools more efficiently.

What the Pricing Changes

Offering frontier-level performance at $2 per million input tokens and $6 per million output tokens changes the profit-and-loss math of running agents. In workflows where an agent burns through millions of tokens all day moving across a codebase, the per-token price directly determines the service’s margin. If performance is comparable, the cheaper model wins. Several analyses point out that Grok 4.5 is dramatically cheaper than Fable 5 or GPT 5.5, and that if the benchmark gap is not large, price alone could decide which model gets chosen.

This matters because cheap agentic intelligence reopens workflows that had previously been shelved due to cost. Tasks that consume large amounts of tokens, such as automated code review, large-scale refactoring, or always-on monitoring agents, benefit the most from a lower per-token price. That said, this math comes with a caveat. A low API price is also the cost of depending on a cloud vendor. Data leaves your environment, and pricing policy and availability are dictated by the vendor’s decisions. The fact that Grok 4.5 is not yet available in the EU shows that this dependency risk is real, not theoretical.

ThakiCloud’s Perspective

The arrival of cheap agentic models touches both of ThakiCloud’s products.

From Paxis’s perspective, a low-cost, high-performance agentic model like Grok 4.5 reinforces the premise of the Agent-Native Cloud. Paxis is the agent control plane that runs on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. In a structure where agents carry out long tasks across dozens of steps, you need a layer that routes that behavior through policy gates and records it in audit logs, regardless of which model is doing the work. As models get cheaper, agents get run more often and for longer, and the value of orchestration and governance grows accordingly. Cheap intelligence does not reduce the need for an agent platform; it increases it.

From the ai-platform perspective, the trade-off with self-hosting becomes sharper. A low API price is attractive, but for organizations with data sovereignty requirements, regulatory obligations, or on-premise needs, that dependency becomes an obstacle. ThakiCloud’s ai-platform serves open-weight models on its own K8s and Kueue-based infrastructure, allowing agentic workflows to run without data ever leaving the environment. The combination Grok 4.5 demonstrates, per-token intelligence paired with efficient serving, poses the same challenge to the self-hosting camp. In other words, to compete with cheap cloud APIs, on-premise deployments must also achieve token efficiency and low serving costs at the same time. This is precisely the direction we are pursuing: making low serving cost our competitive edge.

Limitations and Counterpoints

A few things need to be held in reserve when evaluating this announcement. First, much of the performance claim rests on the company’s own statements. Phrases like “Opus-class” or “outperforms peers” are safer treated as marketing until independently benchmarked. How the model actually stacks up in real coding and agentic work will vary widely depending on each user’s workload.

Second, price competitiveness does not automatically mean it is the best choice. A cheap rate comes bundled with vendor lock-in, data movement, and availability risk. Regional and regulatory constraints, like unavailability in the EU, are real, and such constraints can become decisive obstacles in domains like domestic public sector or finance where data sovereignty matters. Deciding on adoption based on performance and price alone risks running into regulatory and governance requirements later and having to walk it back.

Finally, the facts in this piece are drawn from a synthesis of public reporting and company statements. Detailed benchmark figures and precise training specifics should be verified directly from primary sources, and the picture may change as independent evaluations accumulate over time.

Sources

• Axios, “Scoop: SpaceXAI launches new model, Grok 4.5”
• TechCrunch, “SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’”
• The Decoder, “Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much”

Zhipu’s GLM-5.2, however, runs directly against this trend. The model abandons the group-relative approach and goes back to PPO with a trained value model, while addressing RL’s chronic instability problem, the train-inference distribution mismatch, with a technique called IcePop. What makes this interesting is that the choice is not a simple regression. It amounts to an empirical rebuttal of the recent conventional wisdom that “GRPO is universally superior.”

Depicting the directional shift in RL post-training: dropping the critic, then bringing it back.

Overview

GLM-5.2 is an open-weight model with a one-million-token context window that shows strong performance on long-horizon coding and agentic benchmarks. This post is not about the model’s raw performance numbers, but about the RL post-training design decisions behind that performance. There are two key points. First, the model went back to PPO with a trained value model instead of the group-relative approach (GRPO). Second, it mitigated the resulting train-inference mismatch with IcePop, while removing the KL regularization term that was part of the original IcePop formulation, in order to speed up RL improvement.

This topic matters from ThakiCloud’s perspective for a concrete reason. The LLM training pipeline we operate supports several post-training methods, including SFT, CPT, DPO, GRPO, and GKD. The choice of RL methodology is not merely a matter of algorithmic taste. It is an infrastructure decision that directly affects GPU budget, training stability, and reproducibility. GLM-5.2’s case pushes us to ask not just “what should we use” but “why should we use it.”

The Wall GRPO Hit: The Cost of Dropping the Critic

Let’s first look at why so many teams moved to GRPO. Traditional PPO uses an actor-critic structure. A policy (the actor) generates tokens, while a separate value model (the critic) estimates the expected reward of each state. This value estimate is used to compute advantage (typically via GAE), and the policy is updated with a clipped surrogate objective. The problem is the cost of training this critic. You need to run an additional model that is roughly the same size as the policy, and if the critic converges poorly, the entire training run can become unstable.

GRPO removes the critic entirely. It samples multiple responses for the same prompt, normalizes the reward within that group, and derives advantage purely from relative standing. With no critic, memory usage drops, and the instability that comes from training a value model disappears along with it. The approach is also mathematically clean, which helped it spread quickly.

But there is no free lunch. The group-relative approach loses signal when the variance within a group is small, that is, when the responses are all similarly good or similarly bad. It also struggles with fine-grained, token-level credit assignment over long sequences. A value model can estimate, state by state, “how much did this token contribute to the final reward.” Group normalization alone cannot deliver that resolution. This limitation is most pronounced in problems with long trajectories and sparse rewards, such as long-horizon coding and agentic tasks. That is precisely the territory GLM-5.2 was targeting.

GLM-5.2’s Choice: PPO with a Revived Value Model

The GLM-5.2 team brought the trained value model back. In other words, they restored the critic that GRPO had discarded, in order to regain token-level advantage estimation resolution. Contrary to the prevailing sentiment that “the PPO hype is overblown,” they bet instead that a well-trained value model gives a more stable signal over long trajectories.

The problem is that the moment you revive the critic, the training instability mentioned earlier comes back with it. And on top of that, a newer headache specific to modern RL stacks compounds the issue: train-inference distribution mismatch.

flowchart TB
    A["Prompt batch"] --> B["Inference engine SGLang<br/>generates rollouts"]
    B --> C["Generated tokens + reward"]
    C --> D["Training engine Megatron<br/>recomputes forward pass"]
    D --> E{"Inference probability differs<br/>from training probability<br/>distribution mismatch"}
    E -->|"No correction"| F["Importance ratio explodes<br/>training collapses"]
    E -->|"IcePop masking"| G["Suppress high-mismatch tokens<br/>stable policy update"]
    G --> H["Value model PPO update"]
    H --> A

IcePop: Fixing the Train-Inference Mismatch

Modern RL post-training moves back and forth between two different engines. Rollouts, that is response generation, are handled by a high-throughput inference engine such as SGLang, while the forward computation for the actual policy update is handled by a training engine such as Megatron. The problem is that even when these two engines use the same model weights, differences in kernel implementation, numerical precision, and computation order cause them to produce subtly different probabilities for the same token.

RL typically corrects for this gap using importance sampling, which multiplies by the ratio between the inference-time policy probability and the training-time policy probability. But for tokens where the two distributions diverge, this ratio can explode or collapse. When a handful of tokens with runaway ratios come to dominate the gradient, the entire training run becomes unstable, and in severe cases it collapses. The longer the trajectory, that is, the more tokens involved, the higher the probability that these spikes accumulate. For GLM-5.2, which targets long-horizon tasks, this was an especially critical problem.

IcePop tackles this mismatch head on. It identifies tokens where the inference distribution and the training distribution diverge significantly, and suppresses or masks that token’s contribution, so the gradient is not dragged around by a small number of unstable tokens. The result is that only the signal from stable tokens is retained and used in the policy update. This lets the training keep the benefits of PPO with a revived value model while avoiding the collapse caused by train-inference mismatch.

Where GLM-5.2 diverges from the original IcePop is that it removes the KL regularization term. Many RL recipes apply a KL penalty to keep the policy from drifting too far from the reference policy. This term improves stability, but it also caps how much the policy is allowed to improve. The GLM-5.2 team judged that IcePop’s distribution-mismatch masking already handled most of the instability, so they dropped the KL term and allowed the policy to improve more aggressively. In effect, they removed one stability mechanism and handed that role over to IcePop’s token selection.

Infrastructure: slime, Megatron, SGLang

For this algorithm to work in practice rather than remain an idea on paper, it needs infrastructure that can withstand RL at scale. GLM-5.2’s post-training was carried out on top of an RL scaling framework called slime, using Megatron-LM for distributed training and SGLang for high-throughput rollout generation. The train-inference mismatch described above arises directly from this configuration. Because Megatron (training) and SGLang (inference) each use their own optimized kernels, probabilities diverge between the two, and IcePop is designed precisely to target this structural gap.

In other words, IcePop is less a pure algorithmic improvement and more a joint system-and-algorithm design response to a system-level problem that inevitably arises in modern RL stacks that separate the training engine from the inference engine. The lesson for practitioners is clear. When choosing an RL methodology, you cannot look at the algorithm alone. You have to consider the combination of training and inference engines that algorithm runs on.

Implications for ThakiCloud’s Product

ThakiCloud’s ai-platform is a K8s-based AI/ML infrastructure that operates a training pipeline supporting GPU scheduling through Kueue and multiple post-training methods (SFT, CPT, DPO, GRPO, GKD). GLM-5.2’s case has direct implications for how this pipeline should be designed.

First, RL methodology is not something to fix in place. It is a choice to be made based on the problem at hand. For short-trajectory preference alignment, critic-free GRPO remains economical, but for problems where token-level credit assignment matters, such as long coding or agentic trajectories, PPO with a value model can provide a more stable signal. In a platform like ours that supports multiple methods, exposing this choice so users can switch based on the characteristics of their problem creates real, practical value.

Second, train-inference mismatch is not someone else’s problem for us either. If you run a decoupled RL setup, drawing rollouts from an inference engine (the vLLM/SGLang family) while running the update on a training engine, in a multitenant environment, the same kind of probability mismatch can occur. Preparing a token-selection correction like IcePop as an option in the training runtime can significantly improve training stability for customers who want to fine-tune their own models with RL in an on-premises or sovereign environment. Low serving cost combined with a stable training pipeline is a decisive advantage for teams considering self-hosting.

From an agent perspective, this connects to Paxis as well. Paxis is the Agent-Native Cloud that runs on top of ai-platform, treating skills, tools, and policies as first-class resources. GLM-5.2’s emphasis on long-horizon agent trajectory training is, at its core, about strengthening an agent’s ability to complete tasks by calling tools across multiple steps. The lesson from this case, that a well-trained value model provides finer-grained signal over long trajectories, is worth keeping in mind when thinking through training strategies to improve the quality of the multi-step agent workflows Paxis handles.

Limitations and Counterarguments

This case should be generalized with caution. First, it should not be read as a simple conclusion that “PPO is better than GRPO.” GLM-5.2’s choice is a judgment made within a specific problem setting characterized by long horizons and sparse rewards. For problems with short, dense reward signals, the cost of maintaining a critic can outweigh the benefit, in which case GRPO remains a reasonable choice. The practical constraint that reviving the value model increases the GPU memory budget again also still applies.

Removing IcePop’s KL term is not a universal solution either. KL regularization is a safeguard against the policy running away from the reference policy. Removing it and relying entirely on distribution-mismatch masking for stability only holds up under the assumption that the masking works well. That assumption could break down under a different data distribution or a different combination of inference engines, so rather than porting this decision over directly, teams need a process to verify stability in their own environment.

Finally, the technical explanation in this post is a synthesis of publicly available analyses and papers (arXiv’s “GLM-5: from Vibe Coding to Agentic Engineering”) as well as secondary commentary. Specific hyperparameters and exact benchmark numbers should be confirmed directly against the original source, and implementation details not covered here may prove decisive for actual reproduction. RL post-training is a particularly difficult area to reproduce, so it is safer to treat this as “a direction worth considering” rather than “a recipe that just works.”

Sources

• arXiv, “GLM-5: from Vibe Coding to Agentic Engineering” (arXiv:2602.15763)
• “Why is GLM-5.2 So Good: The GRPO to PPO Switch”, Medium (Coding Nexus)
• “Zhipu’s GLM-5.2: A Usability Breakthrough for Chinese Open-Source Models?”, Weijin Research