في الأسابيع الأخيرة، تحول حديث صناعة الذكاء الاصطناعي من سؤال “من الأذكى” إلى سؤال “من الأرخص”. وجاء المشهد الأكثر دلالة من مايكروسوفت. فالشركة ذاتها التي وضعت 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

Source: RT @KanikaBK: Omg.. this can’t be true… · twitter

What this means for ThakiCloud

Paxis is an enterprise agent platform. Building an agent here is less about reading papers and stacking GPUs, and more about wiring a tool onto a proven skeleton and hitting deploy. With Metis handling training and inference underneath, “someday” collapses into “this afternoon.” The automation running this very blog works the same way. Separate agents pick the news, write the comic, and publish it, and an orchestrator calls them without being asked. The fastest way past the fear is to let one agent loose, which is a thing we prove here every day.

An auto-generated comic riffing on this week’s industry news.

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

지난 몇 주 사이 AI 업계의 화제는 “누가 더 똑똑한가”에서 “누가 더 싼가”로 옮겨갔습니다. 가장 상징적인 장면은 마이크로소프트에서 나왔습니다. 오픈AI를 현대 AI 산업의 궤도에 올려놓은 바로 그 회사가, 엑셀과 아웃룩 안에서 매주 수만 건씩 발생하는 AI 요청을 오픈AI와 앤트로픽 대신 자사 모델로 돌리기 시작했습니다. 마이크로소프트 AI 책임자 무스타파 술레이만은 이를 감추지 않았습니다. “앤트로픽은 극도로 비쌉니다. 우리 목표는 그 비용을 줄이고 궁극적으로는 없애는 것입니다”라고 그는 말했습니다.

이 글은 엔지니어링 리더와 AI 팀, 그리고 자사 서비스의 추론 비용을 책임지는 의사결정자를 위한 것입니다. 지금 벌어지는 비용 전쟁이 왜 일시적 소음이 아니라 구조적 전환인지 짚고, 프론티어 API 지출을 오픈 모델과 자체 호스팅으로 옮기는 이전 플레이북을 정리합니다. 마지막으로 그 이전을 실제로 굴리는 제어 평면으로서 ThakiCloud가 어떤 위치에 있는지 설명합니다.

무엇이 바뀌었나

한 회사의 결정만으로 추세를 말할 수는 없습니다. 그런데 같은 방향의 신호가 몇 주 사이에 겹쳐서 나왔습니다.

첫째, 마이크로소프트의 우회는 정밀했습니다. 가장 어렵고 희귀한 작업은 여전히 프론티어 모델로 보내되, 이메일 답장이나 스레드 요약, 간단한 스프레드시트 수식처럼 지루하고 양이 많은 작업만 자사 모델로 되찾는 방식입니다. 이것이 중요한 이유는 바로 그 지루한 대량 작업이 실제로 돈이 흐르는 곳이기 때문입니다(SiliconANGLE 보도).

둘째, 미국 기업들이 가격을 피해 중국 오픈 모델로 이동하고 있습니다. CNBC 보도에 따르면 한 주요 라우팅 플랫폼에서 중국 모델이 미국 기업 AI 사용량의 30퍼센트 이상을 처리했고 최고 46퍼센트까지 올랐습니다. 1년 전 평균 11퍼센트에서 급등한 수치입니다. 비용은 60에서 90퍼센트 저렴하고, 일부 에이전트 벤치마크에서는 최고 미국 모델과 1점 차이까지 좁혔습니다(CNBC 보도).

셋째, 공급 과잉의 신호가 나왔습니다. 메타는 “잉여” AI 컴퓨트를 판매하는 클라우드 사업을 준비한다고 밝혔습니다. 너무 많이 지었다는 사실을 사업 모델로 인정한 셈입니다(CNBC 보도).

넷째, 시장이 반응했습니다. 6월 말 반도체와 AI 관련 주식에서 1조 달러가 넘는 시가총액이 며칠 만에 사라졌고, 월스트리트는 이 막대한 지출이 정말 회수될 수 있는지 묻기 시작했습니다(로이터 집계 기준 약 1.3조 달러 [추정]).

이 신호들의 공통점은 하나입니다. 프론티어 모델의 성능이 나빠져서가 아닙니다. 오히려 성능은 계속 좋아지고 있습니다. 문제는 가장 큰 고객들조차 “모든 작업에 최고 모델을 쓰고 최고가를 낸다”는 전제를 더는 받아들이지 않는다는 데 있습니다.

가격 자체도 빠르게 내려가고 있습니다. 오픈AI가 최근 공개한 GPT-5.6 Sol은 100만 토큰당 입력 5달러, 출력 30달러 수준으로, 직전 세대보다 토큰당 비용이 큰 폭으로 떨어졌습니다(CNBC 보도). 프론티어 연구소들끼리도 가격 전쟁에 들어갔다는 뜻입니다. 최전선은 더 이상 지능 전쟁이 아니라 가치 전쟁으로 바뀌었습니다.

왜 지금인가

비용 전쟁이 지금 터진 이유는 워크로드의 분포에 있습니다.

에이전트가 하루에 처리하는 일을 뜯어보면 성격이 뚜렷하게 갈립니다. 한쪽에는 진짜 어려운 추론이 있습니다. 애매한 설계 결정, 미묘한 디버깅, 처음 보는 문제의 분해 같은 것입니다. 다른 한쪽에는 정형화된 대량 작업이 있습니다. 분류, 라우팅, 요약, 규격 검사, 정해진 양식의 답장이 여기 속합니다. 건수로 보면 후자가 압도적으로 많습니다.

프론티어 연구소들의 재무 가정은 단순했습니다. 전 세계 기업이 이 작은 요청 수십억 건을 영원히 비싼 모델로 처리하리라는 것이었습니다. 끝없이 흐르는 그 토큰의 강이 프론티어 기업들의 높은 밸류에이션을 떠받치는 근거였습니다.

그런데 정형화된 작업의 품질은 모델의 지능보다 가드레일이 좌우합니다. 출력 포맷이 흔들리는 이유는 모델이 부족해서가 아니라, 포맷을 산문으로 부탁했기 때문입니다. 길이 상한과 허용값 집합, 렌더링 규격, 통과 기준을 코드가 강제하면, 그 작업은 훨씬 값싼 오픈 모델로도 안정적으로 나옵니다. “충분히 좋은” 수준이 가격의 일부만으로 가능해지는 순간, 대량 작업의 강물을 되찾는 것이 합리적 선택이 됩니다. 마이크로소프트가 정확히 그 판단을 했습니다.

프론티어에서 오픈으로: 이전 플레이북

그렇다면 이 강물을 어떻게 옮길까요. 즉흥적으로 모델을 바꾸는 것은 위험합니다. 신뢰할 수 있는 이전은 다음 다섯 단계를 거칩니다.

먼저 워크로드를 분류합니다. 각 요청을 난이도와 민감도 두 축으로 나눕니다. 어렵거나 민감한 작업은 프론티어에 남기고, 정형화된 대량 작업만 이전 대상으로 표시합니다.

다음으로 대체 후보를 평가합니다. 이전 대상 작업마다 오픈 모델 후보를 실제 데이터로 채점합니다. 여기서 핵심은 사람의 인상이 아니라 코드가 계산한 통과율입니다. 실제 출력을 규격 검사에 통과시키고, 임계에 못 미치면 후보에서 탈락시킵니다.

세 번째로 라우팅을 구성합니다. 작업 유형별로 어떤 모델을 쓸지 규칙을 한곳에 정의합니다. 이 규칙이 단일 진실 공급원이 되어야 나중에 모델을 교체하거나 되돌리기가 쉽습니다.

네 번째로 오픈 모델을 자체 호스팅합니다. 선정된 오픈 모델을 vLLM 같은 서빙 엔진으로 자사 인프라에 올립니다. 이 단계에서 온프레미스와 데이터 주권, 그리고 단위 비용의 이점이 실현됩니다.

마지막으로 검증하고 되돌립니다. 이전 후에도 품질을 계속 측정하고, 통과율이 흔들리면 해당 작업만 다시 프론티어로 올립니다. 되돌림 경로가 없는 이전은 이전이 아니라 도박입니다.

flowchart TB
    A[들어오는 워크로드] --> B{분류 게이트<br/>난이도 · 민감도}
    B -->|어렵거나 민감| C[프론티어 API<br/>Claude · GPT-5.6 Sol]
    B -->|정형화된 대량 작업| D[오픈 모델 후보<br/>eval 통과율로 선정]
    D --> E[자체 호스팅 서빙<br/>vLLM · Metis · Kueue GPU]
    C --> F[정책 게이트 + 감사 로그<br/>Paxis 제어 평면]
    E --> F
    F --> G[결과]
    F -.품질 저하 감지.-> B

X상에서 한 개발자는 이 방식으로 월 6만 달러의 API 지출을 오픈 모델로 옮겨 1만 2천 달러까지, 약 80퍼센트 줄였다고 공유했습니다. 원문 게시물은 접근이 제한되어 독립적으로 검증하지는 못했으므로 수치는 참고용입니다([추정]). 다만 절감의 크기 자체는 검증된 자료와 결이 같습니다. 중국 오픈 모델의 60에서 90퍼센트 저렴한 단가, 그리고 프론티어 연구소들끼리 벌어지는 가격 인하가 같은 방향을 가리킵니다.

ThakiCloud 제품 적용 시사점

이 플레이북은 개념으로는 명료하지만 실제로 굴리려면 두 가지가 필요합니다. 하나는 오픈 모델을 싸게 서빙하는 인프라이고, 다른 하나는 작업마다 모델을 고르고 정책과 감사로 안전을 보장하는 제어 평면입니다. ThakiCloud는 두 제품으로 이 두 축을 함께 제공합니다.

ai-platform: 저비용 서빙 인프라

ai-platform은 쿠버네티스 기반의 AI/ML 서빙 인프라입니다. Kueue로 GPU를 스케줄링하고, vLLM으로 오픈 모델을 서빙하며, 멀티테넌트 격리와 온프레미스 배포를 지원합니다. 이전 플레이북의 네 번째 단계, 즉 선정된 오픈 모델을 자사 인프라에 올려 단위 비용을 낮추는 일이 바로 이 계층에서 일어납니다. 국가 기관이나 규제 산업처럼 데이터를 외부로 내보낼 수 없는 고객에게는 소버린 배포가 결정적입니다. 프론티어 API로는 애초에 만족시킬 수 없는 요구이기 때문입니다.

Paxis: 이전을 실행하는 Agent-Native Cloud

Paxis는 ai-platform 위에서 도는 에이전트 네이티브 제어 평면입니다. 기존 클라우드가 가상 머신과 데이터베이스를 일급 리소스로 다루듯, Paxis는 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다룹니다. 이전 플레이북의 관점에서 가장 중요한 부분은 모델 라우팅입니다. Paxis는 models.yaml을 단일 진실 공급원으로 삼아 Claude, OpenAI, Ollama, Kimi, MiniMax, 그리고 ai-platform의 vLLM 서빙(Metis)을 한곳에서 교차 라우팅합니다. 앞서 정리한 플레이북의 3단계와 5단계가 여기에 그대로 대응합니다. 작업 유형별로 모델을 지정하고, 품질이 흔들리면 그 작업만 프론티어로 되돌리는 판단이 이 계층에서 이뤄집니다.

여기에 더해 Paxis는 960개가 넘는 스킬을 BM25로 선택하는 스킬 하네스, 격리 샌드박스 실행, 위키 기반 지식 엔진, DAG 멀티에이전트 오케스트레이션, OAuth 자동 재연결을 갖춘 MCP 커넥터를 제공합니다. 그리고 모든 에이전트 행동은 정책 게이트와 감사 로그를 통과합니다. 모델을 싸게 바꾸면서도 무엇이 어떤 모델로 처리됐는지 추적할 수 있다는 뜻입니다.

두 제품의 관계는 한 문장으로 요약됩니다. 저비용 서빙(ai-platform)이 에이전트의 경제성(Paxis)을 만듭니다. 오픈 모델을 싸게 올릴 인프라가 없으면 라우팅 규칙은 종이 위 계획에 그치고, 라우팅과 정책이 없으면 싼 서빙은 통제 불가능한 위험이 됩니다. 이전을 사업으로 만들려면 두 축이 동시에 필요합니다. 참고로 Paxis는 아직 PoC 단계이며 인터페이스와 스키마는 빠르게 바뀔 수 있습니다.

한계 및 반론

이 이야기를 낙관 일변도로 끝내는 것은 정직하지 않습니다. 반대편의 논거도 분명합니다.

첫째, 품질 격차는 여전히 존재합니다. 오픈 모델이 좁힌 것은 정형화된 작업과 일부 에이전트 벤치마크에서입니다. 처음 보는 문제의 분해나 긴 맥락의 미묘한 추론에서는 프론티어가 여전히 앞섭니다. 모든 작업을 오픈 모델로 옮기려는 시도는 대량 작업에서 아낀 돈을 어려운 작업의 실패 비용으로 토해내게 만듭니다. 이전의 핵심은 전면 교체가 아니라 정밀한 분류입니다.

둘째, 자체 호스팅은 공짜가 아닙니다. API 호출은 운영 부담을 연구소에 떠넘기지만, 자체 호스팅은 GPU 확보와 서빙 최적화, 장애 대응을 직접 떠안습니다. 초기 자본 지출과 운영 인력을 고려하면 소규모 트래픽에서는 오히려 API가 쌀 수 있습니다. 손익 분기는 트래픽 규모와 활용률에 달려 있습니다.

셋째, 회자되는 벤치마크 숫자를 그대로 믿어서는 안 됩니다. 이번 글을 준비하면서도 특정 벤치마크 표와 일부 수치는 원출처를 확인할 수 없어 본문에서 제외했습니다. 모델 비교는 자사 워크로드로 직접 측정한 결과로만 판단해야 합니다. 남의 벤치마크는 출발점일 뿐입니다.

넷째, 라우팅 자체가 복잡성을 더합니다. 여러 모델을 오가는 시스템은 단일 모델보다 디버깅과 관측이 어렵습니다. 정책 게이트와 감사 로그가 선택이 아니라 필수인 이유입니다.

그럼에도 방향은 분명합니다. 마이크로소프트조차 모든 작업에 프론티어 가격을 내기를 거부하는 지금, 진짜 질문은 “누가 그 가격을 계속 낼 것인가”입니다. 대량 워크로드를 오픈 모델로 정밀하게 옮기고, 그 이전을 안전하게 통제하는 역량은 앞으로 몇 년간 AI 운영의 핵심 경쟁력이 될 것입니다. 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)

오늘 아침 뉴스에는 정반대 방향으로 움직이는 두 개의 숫자가 나란히 실렸습니다. 하나는 위로 튀어 올랐습니다. 엔비디아 루빈 울트라 랙의 평균 판매가가 2100만 달러로 보도됐습니다. 직전 세대인 블랙웰 울트라의 400만 달러와 견주면 다섯 배가 넘습니다. 다른 하나는 바닥으로 꺼졌습니다. 딥시크가 V4-Pro 요금을 75퍼센트 영구 인하하면서, 출력 토큰 기준으로 오픈AI보다 34배, 앤스로픽보다 29배 싼 가격표를 내걸었습니다.

한쪽에서는 AI를 굴리는 쇳덩어리가 폭등하고, 다른 한쪽에서는 그 쇳덩어리가 뱉어내는 답변의 값이 폭락합니다. 얼핏 모순처럼 보이는 이 장면이 사실은 하나의 사건입니다. 오늘 다이제스트를 관통하는 이야기는 특정 모델이 얼마나 똑똑해졌는가가 아니라, AI 경제의 위층과 아래층이 서로 반대로 벌어지고 있다는 사실입니다. 벌어지는 두 날 사이에 낀 것은 결국 이 기술을 실제로 쓰려는 기업입니다.

위층: 쇳덩어리는 점점 비싸집니다

랙 가격만의 이야기가 아닙니다. 위층 전체가 값을 올리고 있습니다. 번스타인은 HBM4와 LPDDR5X 메모리 단가가 2027년 기가바이트당 53달러까지 오른다고 내다봤습니다. 랙 원가의 절반 이상이 GPU와 HBM에 쏠려 있으니, 메모리가 오르면 서버 한 대의 몸값이 통째로 따라 오릅니다. 그런데도 삼성전자와 SK하이닉스, 마이크론은 증설 속도를 늦추기는커녕 앞당기고 있습니다. 새 공장이 실제 물량을 내놓기까지 최소 3년이 걸려 의미 있는 공급 증가는 2028년 이후에나 가능하다는 계산이 깔려 있기 때문입니다. 마이크론은 2035년까지 미국에 2500억 달러를 붓겠다고 못 박았고, SK하이닉스는 공모가 149달러로 약 40조 원 규모의 미국 주식예탁증서 상장에 나섰습니다. 외국 기업의 미국 증시 상장으로는 최대 규모입니다. 지금의 투자는 가격이 곧 꺾인다는 신호가 아니라, 앞으로 몇 년간 이어질 AI발 수요에 미리 자리를 잡아두는 포석입니다. 다만 같은 날 미국 상무장관이 뉴욕 팹 행사에서 한국 기업들에 미국 내 생산 확대를 공개적으로 압박했다는 소식도 함께 실렸습니다. 국내 대규모 투자와 대미 투자 요구 사이에서 자금과 인력을 어떻게 나눌지가 메모리 3사의 새로운 숙제로 얹혔습니다.

비싸지는 것은 값만이 아니라 복잡도이기도 합니다. 삼성전자는 HBM과 로직, 실리콘포토닉스를 한데 묶는 2.xD 패키징을 개발 중이라고 밝혔습니다. 대역폭 병목을 넘어서려면 서로 다른 칩을 정교하게 붙여야 하고, 그럴수록 파운드리와 첨단 패키징의 캐파에 공급망 전체가 매입니다. 성능을 끌어올릴수록 만드는 난이도와 원가가 함께 오르는 구조입니다. 엔비디아는 성능 향상으로 총소유비용이 개선된다고 말하지만, 랙당 원가의 절반이 GPU와 HBM에 쏠린 이상 실제 투자 회수 속도가 이 사이클의 지속 가능성을 결정하는 진짜 변수로 떠올랐습니다.

여기에 더 무거운 벽이 하나 더 서 있습니다. 전력입니다. 중앙일보와 조세일보가 나란히 짚었듯, AI 경쟁의 축은 반도체 확보에서 데이터센터 운영으로 이미 넘어갔습니다. 정부는 2029년까지 550조 원, 2035년까지 1000조 원이 넘는 AI 데이터센터 투자를 유치하겠다고 목표를 세웠고, 그 가운데 18.4기가와트 목표의 81퍼센트를 SK그룹이 맡는 구조입니다. 문제는 서울과 경기 지역이 관련 전력 계약의 78.7퍼센트를 차지하는데 정작 핵심 부지는 포화에 가깝다는 점입니다. GPU를 사 오는 일보다 계통 연계와 변전소 증설 인허가가 더 긴 리드타임을 요구합니다. 액침냉각 같은 액체 냉각을 도입하면 냉각에 드는 전력을 90퍼센트 넘게 줄일 수 있다지만, 이런 설비를 24시간 무중단으로 돌릴 고숙련 운영 인력을 3년에서 5년 이상 붙잡아 두기가 쉽지 않다는 인력난이 또 다른 병목으로 지목됩니다. 그래서 이미 대규모 송전 권리를 쥔 옛 비트코인 채굴업체들이 AI 인프라 공급자로 다시 값이 매겨지고 있습니다. 코어사이언티픽과 아이렌, 테라울프 같은 기업이 하이퍼스케일러와 장기 전력 계약을 맺으면서, 시장은 이들을 채굴 채산성이 아니라 확보한 전력 용량, 곧 메가와트 단위로 다시 평가하기 시작했습니다. 위층에서 진짜 희소한 자원은 이제 칩이 아니라 전기입니다.

아래층: 답변의 값은 점점 싸집니다

같은 날, 아래층에서는 정확히 반대되는 힘이 작동했습니다. 딥시크의 인하는 일회성 프로모션이 아니라 영구 정책이었고, 그 파장은 통계로 잡혔습니다. 버셀과 오픈라우터 같은 개발자 플랫폼에서 중국계 모델의 트래픽 점유율이 단기간에 두 자릿수로 뛰었고, 린디 같은 실제 스타트업은 앤스로픽에서 딥시크로 서비스를 통째로 갈아탔습니다. 가격에 민감한 고객층은 이미 움직이고 있습니다.

메타의 행보는 이 흐름을 한층 또렷하게 보여줍니다. 그동안 라마를 오픈소스로 풀며 생태계를 키우던 메타가 뮤즈 스파크 1.1로 처음 유료 API 사업에 뛰어들면서, 경쟁사의 약 4분의 1 수준이라는 파격적인 가격을 들고 나왔습니다. 저커버그는 가격이 매력적일 것이라고 자신했습니다. 여기에 메타는 9월부터 자체 AI 칩을 양산해 엔비디아 의존을 낮추고, 올해 최대 1450억 달러에 이르는 인프라 지출을 회수하려고 유휴 컴퓨팅까지 외부에 팔겠다고 나섰습니다. 구글의 TPU, 아마존의 트레이니엄에 이어 메타의 커스텀 실리콘까지, 빅테크가 직접 칩을 찍고 남는 연산을 되파는 국면입니다. 위층의 비용 압박이 클수록 아래층에서는 그 압박을 남에게 넘기기 위한 가격 전쟁이 격화됩니다.

이 가위질이 실리콘밸리만의 이야기가 아니라는 점이 국내 뉴스에서 드러납니다. 하정우 씨는 울산이 제조 산업 데이터를 많이 축적한 만큼 산업 AI 전환의 가능성이 크다고 말했고, 아이티센코어는 국민은행과 손잡았으며 SK AX는 제조 현장을 겨냥한 풀스택 전환을 내놓았습니다. LG는 물리 법칙을 이해하는 월드모델 개발에 나섰고, 알리페이는 결제와 신뢰, 개방을 앞세워 에이전트 시대의 승부수를 던졌습니다. 제조와 금융과 공공이 저마다 AI를 실제 업무에 밀어 넣기 시작했다는 뜻입니다. 문제는 이들이 AI를 도입하는 그 순간, 방금 살펴본 두 날 사이에 그대로 끼어든다는 데 있습니다. 위로는 인프라 자본비용이, 아래로는 모델 원가와 주권 리스크가 동시에 이들을 누릅니다.

왜 이 둘은 같은 힘일까요

모순처럼 보이던 두 방향은 사실 같은 뿌리에서 갈라집니다. AI 수요가 폭발하면서 상류에 있는 반도체와 전력의 희소성이 값을 밀어 올립니다. 동시에 그 수요를 잡으려는 모델 공급자들의 경쟁이 하류의 마진을 무너뜨립니다. 위로 오르는 자본비용과 아래로 내리는 판매가격이 같은 수요에서 태어난 쌍둥이라는 뜻입니다. 그래서 이 구도는 가위를 닮았습니다. 두 날은 반대로 움직이지만 하나의 축에 묶여 있습니다.

기업이 서 있는 자리는 정확히 그 가위의 한가운데입니다. 인프라를 직접 지으려면 폭등하는 위층 비용을 감당해야 하고, 모델을 외부 API로만 쓰려면 남의 가격 정책과 데이터 주권 리스크에 몸을 맡겨야 합니다. 게다가 딥시크는 중국계 모델이고 메타는 폐쇄형 유료로 돌아섰습니다. 금융과 공공처럼 망분리와 데이터 주권 규제가 엄격한 영역에서는 저 싼 값을 그대로 가져다 쓰기 어렵습니다. 값이 싸다는 사실과 그 값을 안전하게 쓸 수 있다는 사실은 전혀 다른 문제입니다.

가위 한가운데에서 쥐어야 할 손잡이

여기서 흔한 반론 하나를 짚고 넘어가야 합니다. 딥시크가 34배 싸고 메타가 4분의 1 가격을 들고 나왔으니, 그냥 제일 싼 외부 API를 골라 쓰면 되지 않느냐는 것입니다. 값만 보면 맞는 말입니다. 그러나 싼 값에는 조건이 붙어 있습니다. 딥시크는 중국계 모델이고, 메타는 오픈소스에서 폐쇄형 유료로 돌아섰으며, 이 둘의 가격은 언제든 공급자의 사정에 따라 다시 오를 수 있습니다. 남의 가격 정책에 원가 구조를 통째로 맡기는 것은 절감이 아니라 새로운 종속입니다. 진짜 절감은 그 싼 값을 내 통제 안으로 가져올 때 완성됩니다.

그렇다면 벌어지는 두 날 사이에서 기업이 통제할 수 있는 변수는 무엇일까요. 뉴스가 힌트를 흘려두었습니다. AI 데이터센터 기사의 핵심 교훈은 확보한 GPU를 못 돌리면 무의미하다는 것이었습니다. 즉 위층 비용을 흡수하는 첫 번째 손잡이는 유휴를 없애는 스케줄링입니다. 딥시크 사례의 교훈은 저가 모델과 고가 모델을 작업 난이도에 따라 나눠 쓰는 라우팅이었습니다. 두 번째 손잡이는 작업마다 알맞은 모델을 고르는 배분입니다. 메타 유료화와 중국계 모델 확산의 교훈은 싼 값을 데이터 주권 안에서 흡수하려면 오픈 웨이트를 내 인프라에서 직접 서빙해야 한다는 것이었습니다. 세 번째 손잡이는 온프렘과 소버린입니다. 그리고 과기정통부와 KISA가 발간한 AI 보안 레드티밍 가이드가 프롬프트 인젝션과 에이전트 권한 오남용을 표준 위협으로 못 박았듯, 네 번째 손잡이는 실행을 안전하게 가두는 정책과 감사입니다.

ThakiCloud가 Agent-Native Cloud로 만든 Paxis는 바로 이 네 손잡이를 한 손에 쥐도록 설계했습니다. 작업마다 알맞은 모델을 고르는 CostRouter는 딥시크류 저가 모델과 고성능 모델을 워크로드에 따라 갈라 태워 아래층의 가격 붕괴를 비용 절감으로 되받습니다. 격리 샌드박스 실행과 멀티테넌시는 확보한 GPU의 유휴 시간을 줄여 위층의 자본비용을 흡수합니다. 소버린과 온프렘 쿠버네티스 기반은 오픈 웨이트 모델을 국내 규제 안에서 직접 서빙하게 해, 싼 값과 데이터 주권을 동시에 가져갑니다. 그리고 Skills, Tools, Policies, Audit Logs를 일급 리소스로 두고 L0부터 L3까지 자율도를 나눈 거버넌스는, 레드티밍 가이드가 요구하는 정책 게이트와 감사 로그를 처음부터 제품 안에 심어둡니다.

가위는 벌어질수록 손잡이가 중요해집니다

오늘의 두 숫자는 앞으로도 더 멀리 벌어질 가능성이 큽니다. 메모리 공급이 2028년까지 타이트하고 전력 병목은 몇 년의 인허가를 요구하니 위층은 쉽게 내려오지 않습니다. 반대로 자체 칩과 초저가 모델의 물결은 아래층을 계속 끌어내립니다. 이럴수록 승부는 두 날 자체가 아니라 그 사이를 쥐는 손잡이에서 갈립니다. 랙 값과 추론 값이라는 두 개의 숫자를 읽을 때, 그 사이에 놓인 스케줄링과 라우팅과 주권과 안전을 함께 읽어야 하는 이유입니다. 오늘의 뉴스는 어느 모델이 이겼는지를 묻지 않았습니다. 대신 그 모델을 굴리는 비용과 그 비용을 다루는 방식을 물었습니다. 가위의 한가운데에서 흔들리지 않으려면, 먼저 손잡이를 어디에 두었는지부터 확인해야 합니다.

돈의 단위가 바뀌었다

숫자의 규모부터 낯설어졌습니다. SK하이닉스는 나스닥 상장을 위한 미국예탁증서 공모가를 주당 149달러로 확정했습니다. 총 265억 달러, 약 40조 원 규모로, 2014년 알리바바의 250억 달러를 넘어 외국 기업의 미국 상장 가운데 역대 최대입니다. 시가총액이 1조 달러를 돌파한 회사가 달러를 직접 끌어와 용인과 청주 팹의 극자외선 장비, 해외 첨단 패키징에 붓겠다고 합니다. 마이크론은 2035년까지 미국에만 2500억 달러, 약 376조 원을 투입한다고 계획을 또 키웠습니다. 메타는 올해 자본지출 가이던스로만 1150억에서 1350억 달러를 제시했습니다.

이 돈이 어디로 흘러가는지 보면 방향이 뚜렷합니다. 전부 메모리 증설, 데이터센터 건설, 반도체 확보로 향합니다. 뱅크오브아메리카와 모건스탠리 같은 투자은행은 이 단가 급등을 한국 메모리 기업 가치의 근거이자 동시에 빅테크 설비투자를 위축시킬 하방 위험으로 함께 봅니다. 값이 오른다는 건 파는 쪽에는 기회지만, 그 값을 치르고 서비스를 돌려야 하는 쪽에는 부담입니다. 랙 값의 절반이 메모리로 채워지는 구조가 굳어지면, GPU 클라우드 사업자는 차세대 랙 도입 시점을 언제로 잡느냐만으로도 마진의 방향이 갈립니다.

경쟁의 전선이 칩 하나에 머물지 않는다는 점도 눈에 띕니다. 삼성전자는 HBM과 로직, 실리콘포토닉스를 한 패키지로 묶는 2.xD 이종집적을 개발 중이라고 밝혔고, AI PC용 가속기 가이아로 온디바이스 추론 시장에도 발을 들였습니다. 가이아는 프로세싱 인 메모리를 결합해 데이터 이동을 줄이고 전력 효율을 끌어올리는 방향을 잡았습니다. 연산을 빠르게 만드는 싸움이 곧 전력을 아끼는 싸움과 같아졌다는 뜻입니다. 이 흐름은 GPU 클라우드 사업자에게도 앞으로 엔비디아 한 곳이 아니라 NPU와 프로세싱 인 메모리까지 아우르는 멀티벤더 하드웨어를 준비해야 한다는 숙제를 남깁니다.

병목은 GPU에서 전력으로 내려갔다

더 흥미로운 신호는 병목이 이동한 자리입니다. 조세일보가 전한 이야기는 상징적입니다. 코인을 캐던 기업들이 AI 인프라 회사로 변신하고 있는데, 그들이 가진 진짜 자산은 채굴기가 아니라 전력이었습니다. 코인셰어스 보고서에 따르면 상장 채굴 기업 매출에서 AI와 고성능컴퓨팅이 차지하는 비중이 지금 약 30퍼센트에서 연말 최대 70퍼센트까지 오를 전망이고, 지난 1년간 맺은 관련 계약만 700억 달러를 넘습니다. 테라울프는 앤트로픽과 20년 장기 임대를 맺어 2028년 초까지 401메가와트로 확장하고, IREN은 오클라호마 부지를 더해 전력 파이프라인을 4.5기가와트까지 늘렸습니다. 값싼 전력 계약과 변전 설비를 먼저 쥔 쪽이 승자가 된 것입니다.

한국도 다르지 않습니다. 중앙일보는 노무라 전망을 인용해 전 세계 AI 데이터센터 투자가 2025년 723조 원에서 2030년 5241조 원으로 연평균 48퍼센트씩 불어난다고 전했습니다. 정부는 지난달 29일 3대 메가프로젝트를 발표하며 1단계로 8.4기가와트 규모 데이터센터에 550조 원을 넣고, 2035년까지 총 18.4기가와트, 누적 1000조 원을 넘기겠다고 했습니다. SK는 AWS와 손잡고 2029년 5기가와트를 열어 2035년 15기가와트로 키우고, KT는 5년간 5조 원으로 전국 25곳에 실수요 기반 시설을 짓겠다고 선언했습니다. SK텔레콤이 5기가와트급 데이터센터로 승부수를 던진다는 소식도 같은 맥락에 놓입니다. 공통된 병목은 하나로 모입니다. 전력, 냉각, 부지입니다. 한전 계통 연계 지연과 변전소 인허가가 확장의 최대 제약으로 꼽히는 현실에서, 전력을 선점한 사업자가 구조적 우위를 갖는다는 미국의 교훈은 국내에도 그대로 옮겨옵니다.

규모 경쟁이 대기업 컨소시엄으로 재편되는 국면에서, 작은 사업자에게 남는 길이 아예 없는 것은 아닙니다. LG유플러스는 파주에 200메가와트를 공급하는 시설을 짓고, LG씨엔에스는 컨테이너 하나에 GPU 576장을 담는 모듈형 소형 데이터센터를 준비합니다. KT의 에지 전략처럼 산업 현장 가까이 설비를 붙여 지연을 줄이는 접근도 있습니다. 하이퍼스케일 부지를 두고 정면으로 붙기 어려운 사업자라면, 모듈형과 에지, 전력 계약 다변화 같은 틈새에서 밀도를 높이는 편이 현실적인 선택입니다.

그런데 그 돈은 성과로 돌아오고 있는가

여기서 반대 방향의 질문을 던져야 정직한 그림이 나옵니다. 이 사상 최대의 자본은 정말 성과로 회수되고 있을까요. 오늘 뉴스는 오히려 반대 신호를 보냅니다. 네이버는 2분기에 매출 3조 3562억 원, 영업이익 5701억 원으로 역대 2분기 최대를 예고했는데, 주가는 6월 1일 신고가 30만 4000원에서 한 달여 만에 7월 9일 18만 4400원까지 내려앉았습니다. 카카오는 지피티 인 카카오 누적 이용자가 1100만 명에 이르렀지만 수익화 증거가 부족하다는 이유로 증권사들이 일제히 목표주가를 낮췄습니다. 사상 최대 실적을 내고도 웃지 못하는 이유는 단순합니다. 시장은 이제 투자가 아니라 회수를 묻습니다.

빅테크의 반응은 더 직설적입니다. 메타는 오픈소스 노선을 접고 첫 유료 모델 뮤즈 스파크 1.1을 내놓았습니다. 출력 100만 토큰당 4.25달러로, 오픈AI와 앤트로픽 최고급 모델의 약 25퍼센트 수준입니다. 저커버그는 데이터센터와 GPU를 외부에 빌려주는 컴퓨팅 임대 사업까지 저울질하며 사내에 메타 컴퓨트라는 별도 조직을 꾸렸습니다. 4월에 코어위브와 최대 210억 달러 규모 컴퓨팅 임대 계약을 맺은 데 이어, 이번에는 스스로 코어위브 같은 컴퓨팅 공급자가 되겠다는 것입니다. 수천억 달러를 부어놓고 이제 그것으로 돈을 벌겠다는 선언입니다. 한쪽에서는 딥시크가 출력 100만 토큰당 0.87달러로 오픈AI보다 34배 싼 가격을 앞세워 개발자 트래픽의 상당 부분을 흡수하고 있습니다. 오픈라우터 통계에서 중국 오픈소스 모델의 점유율이 한때 46퍼센트까지 치솟았다는 수치는 이 흐름이 취향이 아니라 원가 문제임을 보여줍니다. 승부의 축이 더 좋은 모델을 누가 만드느냐에서 누가 실제로 돈을 버느냐로 넘어갔다는 평가가 나오는 배경입니다.

네이버의 사례는 이 시차를 숫자로 드러냅니다. 엔비디아와 손잡은 AI 팩토리는 55메가와트에서 2028년 200메가와트를 거쳐 최종 1기가와트까지 키우고 장기적으로 연매출 20조 원을 노리는 사업이지만, 정작 GPU 투자에 따른 감가상각비가 단기 영업이익률을 눌렀습니다. 인프라를 먼저 짓고 회수는 나중이라는 구조가 대형 플랫폼에서도 예외가 아니라는 뜻입니다. 투자자가 사용량이 아니라 계약과 매출이라는 증거를 요구하는 이유가 여기에 있습니다.

비싼 컴퓨트를 증명 가능한 일로 바꾸는 층

정리하면 이렇습니다. 자본은 반도체와 전력으로 쏟아지고, 그 위에서 서비스를 돌리는 기업은 회수를 증명하라는 압박을 받습니다. 그렇다면 진짜 가치가 만들어지는 자리는 하드웨어 아래가 아니라 그 위, 비싼 컴퓨트 한 사이클을 낭비 없이 성과로 바꾸는 소프트웨어 층입니다. ThakiCloud가 Paxis를 에이전트 네이티브 클라우드로 설계한 이유가 여기에 맞닿아 있습니다.

작업마다 모델을 골라 쓰는 CostRouter는 딥시크와 메타의 저가 API가 열어놓은 선택지를 그대로 무기로 씁니다. 이메일 분류나 문서 요약처럼 토큰에 민감한 워크로드는 값싼 모델로 흘리고, 정교한 추론이 필요한 구간에만 비싼 모델을 배치하면 같은 결과를 더 낮은 원가로 냅니다. 랙 한 대의 값이 폭발하는 시대에 원가를 지키는 길은 더 싼 하드웨어가 아니라, 매 호출을 적정 모델로 라우팅하는 소프트웨어 규율입니다.

정책 게이트와 감사 로그는 네이버와 카카오가 겪는 증명의 압박에 대한 답이기도 합니다. Paxis는 스킬과 툴, 정책, 감사 로그를 일급 리소스로 다루고, 에이전트의 자율도를 L0에서 L3까지 단계로 관리합니다. 에이전트가 무슨 권한으로 어떤 일을 했는지 기록으로 남으면, 사용량이 아니라 실제로 처리한 일을 근거로 성과를 말할 수 있습니다. 어떤 작업은 사람이 승인하고 어떤 작업은 완전히 위임할지를 정책으로 나누면, 회수를 묻는 질문 앞에서 숫자 대신 근거를 내밀 수 있습니다. 알리페이가 위임 인증과 거래 추적으로 3억 건의 에이전트 결제를 쌓아 신뢰 계층을 만든 것도 같은 문법입니다.

주권의 문제도 그대로 겹칩니다. 한 기자수첩은 소버린 AI를 외치는 자리에서 정작 가장 선명하게 남은 단어가 엔비디아였다고 꼬집었습니다. 정부는 초과세수 5조 원으로 엔비디아 베라루빈 GPU 1만 개를 확보하고 2030년까지 국산 반도체 비중을 절반으로 늘리겠다고 하지만, 데이터와 모델까지가 주권인지 컴퓨팅과 반도체까지 포함하는지 기준은 아직 흐릿합니다. 이 공백은 온프렘 쿠버네티스 위에서 데이터가 나가지 않는 소버린 스택을 실제로 굴려 보인 사업자에게 포지셔닝의 창이 됩니다. 대형 사업자가 소버린을 표방하면서도 엔비디아 생태계에 깊이 편입되는 사이, 컴퓨팅 국산화와 데이터 주권을 실제 레퍼런스로 쌓는 쪽이 기준이 확정되기 전에 앞서갈 수 있습니다.

보안은 이 신뢰의 마지막 고리입니다. 과기정통부와 KISA가 이번 주 펴낸 AI 보안 레드티밍 가이드는 프롬프트 인젝션과 에이전트 하이재킹을 포함한 8대 위협을 규정하고 위험을 5단계로 나눴습니다. 에이전트가 외부 문서나 웹페이지에 숨은 악성 지시에 휘둘리는 하이재킹은, 모든 실행을 격리 샌드박스 안에 가두는 구조로 정면 대응할 수 있습니다. 금융과 공공 조달에서 레드티밍 이력이 요건으로 굳어질 국면에서, 격리 수준을 정량으로 입증하는 아키텍처는 규제 대응인 동시에 그 자체가 조달 경쟁력이 됩니다.

청구서 이야기로 돌아가 보겠습니다. 랙 한 대에 2100만 달러가 찍히는 시대에, 가장 비싼 낭비는 그 랙 위에서 엉뚱한 모델에 엉뚱한 일을 시키고도 무엇을 했는지 설명하지 못하는 것입니다. 자본과 전력은 이미 격전지가 되었습니다. 다음 격전지는 그 위에서 매 사이클을 증명 가능한 일로 바꾸는 층이고, ThakiCloud는 바로 그 자리를 겨냥하고 있습니다.