نظرة عامة

تقديم نموذج MoE بحجم 469B على بنية تحتية خاصة كان يعني، حتى وقت قريب، امتلاك مجموعة GPU موزعة على عقد متعددة. لكن مشروع vLLM ونقطة التفتيش GLM-5.2-NVFP4 التي أصدرتها NVIDIA يغيّران هذه المعادلة تماماً: يكفي الآن تحميل نموذج 469B على ثماني بطاقات Blackwell في عقدة واحدة وتقديمه مباشرةً عبر vLLM.

تحلّل هذه المقالة تلك الوصفة. أما خلفية تنسيق NVFP4 نفسه فقد تناولناها في مقالة سابقة بعنوان تقليص تكاليف تقديم النماذج اللغوية الكبيرة إلى النصف على Blackwell GPU باستخدام NVFP4، لذا نركّز هنا على سؤال محدد: كيف تُشغّل نموذجاً حدودياً بعينه فعلياً؟ نستعرض بنية التكميم والأمر الرسمي لـ vLLM وحسابات حجم الذاكرة المشتقة من الأرقام المعلنة، ثم نستخلص ما يمكن تطبيقه في سياق تشغيل ThakiCloud ai-platform.

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

ما هو GLM-5.2-NVFP4

GLM-5.2-NVFP4 هو نقطة تفتيش لنموذج GLM-5.2 بعد تكميم أوزانه وتنشيطاته بنوع البيانات NVFP4، ليصبح جاهزاً للاستدلال المباشر عبر vLLM وSGLang. النقطة الجوهرية هنا أن البنية تعتمد دقة مختلطة لا “أربعة بتات لكل شيء”.

في منهجية إعادة التكميم الخاصة بـ NVIDIA modelopt، تنزل إلى NVFP4 الطبقات الخطية الخاصة بخبراء MoE فحسب، بينما تبقى الخبراء المشتركون والانتباه والتضمينات والطبقات الكثيفة الأولية على FP8 أو BF16. أما ذاكرة التخزين المؤقت للمفتاح-القيمة (KV cache) فتستخدم FP8. الهدف هو الحفاظ على الدقة في المواضع الحساسة مع ضغط قوي على خبراء MoE الذين يمثّلون الجزء الأكبر من المعاملات.

يمكن تصوّر منظومة التقديم الكاملة على النحو التالي:

flowchart TB
    A["GLM-5.2 469B MoE<br/>(원본 가중치)"] --> B["NVIDIA modelopt 재양자화<br/>MoE 전문가 → NVFP4<br/>어텐션·임베딩·dense → FP8/BF16"]
    B --> C["GLM-5.2-NVFP4 체크포인트<br/>~465 GB · FP8 KV 캐시"]
    C --> D["vLLM 서빙<br/>양자화 자동 감지 (플래그 불요)<br/>TP=8 · expert parallel"]
    D --> E["단일 Blackwell 노드<br/>8× RTX PRO 6000 (96 GB)"]
    E -.긴 컨텍스트·배치.-> D

علاوةً على ذلك، يتداول المجتمع نسخة معدّلة باسم GLM-5.2-NVFP4-REAP-469B، تستهدف سياقات تتجاوز 250K رمز باستخدام DeepSeek Sparse Attention مع فك التشفير التخميني عبر MTP. وقد نُشرت تكوينات متعددة، من بينها نسخة تعمل على 4× RTX PRO 6000 (SM120) وأخرى على 3× DGX Spark بالتوازي الأنبوبي.

التثبيت والتكامل

الأمر الرسمي لتقديم النموذج عبر vLLM كما يظهر في بطاقة نموذج NVIDIA:

vllm serve nvidia/GLM-5.2-NVFP4 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --enable-auto-tool-choice \
  --kv-cache-dtype fp8_e4m3 \
  --served-model-name glm-5.2-nvfp4

ثمة ملاحظات لافتة هنا:

• غياب علم --quantization: يكشف vLLM آلية التكميم تلقائياً من نقطة التفتيش، فلا حاجة للمشغّل إلى تحديد التنسيق يدوياً.
• --enable-expert-parallel: يوزّع خبراء MoE على بطاقات GPU باستخدام التوازي الخبراتي. يعمل جنباً إلى جنب مع TP لنشر نموذج 469B على الثماني بطاقات.
• --kv-cache-dtype fp8_e4m3: يُبقي ذاكرة KV cache بتنسيق FP8 للحفاظ على هامش للسياقات الطويلة والدفعات الكبيرة.
• --reasoning-parser glm45 / --tool-call-parser glm47: يُوزّع رموز الاستدلال وتنسيق استدعاءات الأدوات الخاصة بسلسلة GLM. وضع التفكير مفعّل بصورة افتراضية.

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

نتائج التجربة

كما أشرنا، لم يُنفَّذ تقديم النموذج بشكل مباشر لعدم توفر GPU Blackwell. لذلك أجرينا حسابات حجم الذاكرة بصورة حتمية استناداً إلى الأرقام المعلنة فحسب. المدخلات ثلاثة حقائق موثّقة: 469B معامل، حجم نقطة التفتيش المختلطة المُعلن وهو نحو 465 GB، وتكوين العقدة 8× 96 GB.

نتائج الحسابات:

• بتنسيق BF16، تحتاج 469B معامل إلى نحو 938 GB، وبـ FP8 نحو 469 GB.
• نقطة التفتيش المختلطة NVFP4 المُعلنة تبلغ نحو 465 GB، وهي قريبة جداً من نقطة تفتيش FP8 نقية (469 GB). لو كانت أربعة بتات خالصة لنظرياً انخفضت إلى نحو 234 GB، لكن بما أن التكميم رباعي البت يقتصر على خبراء MoE، فالبصمة لا تنخفض إلى ذلك المستوى.
• تحميل 465 GB من الأوزان على عقدة بإجمالي 768 GB (8× 96 GB) يترك نحو 303 GB للـ KV cache والتنشيطات. نسبة استخدام VRAM تبلغ نحو 60.5%.

نقطة تستحق التوضيح الصريح: الميزة الحقيقية لـ NVFP4 المختلط ليست “تقليص التخزين إلى النصف”. إذا نظرت إلى بصمة الأوزان وحدها ستجدها مشابهة لـ FP8. الفائدة الفعلية تأتي من مصدرين: قدرة معالجة حسابات NVFP4 في نوى Blackwell، وهامش السياق والدفعات الذي يتيحه FP8 KV cache. بعبارة أخرى، قيمة نقطة التفتيش هذه ليست في كونها “أصغر” بل في كونها “أسرع وأقدر على السياقات الطويلة في عقدة واحدة”. تطبيق عبارة “تقليص الذاكرة إلى النصف بأربعة بتات” على هذه الحالة مباشرةً غير دقيق.

الانعكاسات على منتجات ThakiCloud

تحمل هذه الوصفة دلالات مباشرة لـ ai-platform الخاص بـ ThakiCloud - البنية التحتية للذكاء الاصطناعي والتعلم الآلي المبنية على Kubernetes وجدولة GPU عبر Kueue والتي توفر تقديم vLLM وعزل المستأجرين المتعددين.

• التقديم الحدودي على عقدة واحدة يُبسّط الجدولة. حين يتسع نموذج 469B في عقدة واحدة (TP=8)، تختفي تعقيدات التواصل بين العقد وتنظيم الدفعات في التقديم الموزع متعدد العقد. من منظور Kueue، يصبح الأمر وحدة موارد نظيفة “عقدة بثماني GPU”، مما يُيسّر تخصيص GPU واسترداده في بيئة متعددة المستأجرين.
• يناسب سيناريوهات النشر المحلي والسيادي. في بيئات العملاء الخاضعة لمتطلبات أمنية حكومية أو حظر تصدير البيانات، تُعدّ إمكانية الاستضافة الذاتية لنموذج بمستوى حدودي على عقدة محلية واحدة ميزة تمييزية جوهرية. يمكن تشغيل نموذج 469B على بنيتك التحتية الخاصة دون الاعتماد على أي API خارجي.
• هامش VRAM يُعزز إنتاجية المستأجرين المتعددين. الـ 303 GB المحسوبة المتبقية للـ KV cache والتنشيطات تُترجم إلى سياقات أطول أو دفعات أكبر. هذا يعني استيعاب طلبات متزامنة أكثر من نفس العقدة، مما ينعكس مباشرةً على تنافسية التكلفة لكل GPU في خدمة SaaS متعددة المستأجرين.
• الكشف التلقائي عن التكميم يُوحّد العمليات. بما أن vLLM يكشف التنسيق تلقائياً، يمكن نشر نقاط تفتيش مُكمَّمة متنوعة عبر نفس قالب التقديم. لا حاجة إلى تفريع بيان تقديم ai-platform بحسب كل نموذج.

انخفاض تكلفة التقديم ليس فضيلة بنية تحتية فحسب، بل هو قدرة تنافسية للمنتج. تكوين يحمّل نموذجاً حدودياً على عقدة واحدة ويُبقي 40% من VRAM حرة للإنتاجية يُخفّض مباشرةً التكلفة الإجمالية للملكية لكل GPU المقدَّمة للعملاء.

القيود والتحفظات

أكبر القيود ينبع من المقالة نفسها: لا توجد قياسات معيارية فعلية. أرقام إنتاجية الرموز والكمون وانحدار الدقة تستلزم عقدة Blackwell حقيقية للحصول عليها. الأرقام الواردة هنا حسابات حجم مستندة إلى حجم نقطة تفتيش معلنة، لا قياسات زمن تشغيل.

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

ثالثاً، ثمة اعتمادية على الأجهزة. هذه الوصفة تشترط Blackwell. على جيل Hopper (H100) الذي يفتقر إلى نوى NVFP4، لا تتحقق مزايا نقطة التفتيش ذاتها. بالتالي هذا التكوين خيار عملي فقط للمؤسسات التي تبنّت Blackwell أو تعتزم تبنّيه. في البيئات التي تمتلك قاعدة كبيرة من H100، يظل مسار FP8 هو الخط الأساسي الواقعي.

المصادر

• بطاقة نموذج nvidia/GLM-5.2-NVFP4 (Hugging Face)
• وصفة GLM-5.2 على vLLM
• وصفة تقديم GLM-5.2-NVFP4-REAP-469B على SM120 (0xSero/glm-5.2-sm120)
• تقديم GLM-5.2 469B بالتوازي الأنبوبي على DGX Spark (bird/GLM-spark)

لا تُجيب هذه المقالة بـ”نعم إنها فقاعة” أو “لا ليست كذلك”. بدلًا من ذلك، تتناول المنطقَين الهيكليَّين اللذين يُحرِّكان إنفاق عمالقة التقنية، وما يعنيانه لشركات البنية التحتية كشركتنا وللعملاء من قطاع المؤسسات. نقطة الانطلاق كانت تحليلًا دار في منصة X (@Tesla_Teslaway thread)، وقد تحققنا من الأرقام الجوهرية بالعودة إلى مصادرها الأولية.

لماذا يبدو الأمر كاستثمار مفرط

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

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

التأمين غير المتماثل: ما تشتريه الشركات الرائدة فعلًا

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

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

“القفزة” ليست روبوت محادثة أذكى، بل موثوقية × task horizon

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

جهة القياس الفعلي لهذا الأخير هي METR (أشار الخيط الأصلي إلى أنثروبيك، لكن المصدر الدقيق هو بحث METR المعنون “Measuring AI Ability to Complete Long Tasks”). وثّقت METR أن طول المهمة التي يستطيع الذكاء الاصطناعي إتمامها بموثوقية 50% (مقاسةً بالوقت المكافئ لجهد بشري) تضاعف كل سبعة أشهر تقريبًا من 2019 حتى 2025. والأهم أن فترة التضاعف تقلّصت في 2024-2025 إلى نحو أربعة أشهر، وهي علامة واضحة على أن الوتيرة تتسارع.

أما الموثوقية، فالحساب بسيط ويكشف حدًّا فاصلًا. وكيل بموثوقية 95% لكل خطوة يُتمّ مهمة من 20 خطوة بنجاح باحتمالية 0.95^20، أي نحو 36% فحسب. هذا يعني أن الإنسان يظل ضروريًا للمراجعة في كل خطوة، فلا وفر في الكلفة. إذا ارتفعت الموثوقية إلى 99%، يقفز معدل النجاح إلى نحو 82%، ومع 99.9% يبلغ نحو 98%. الموثوقية ترتفع بصورة خطية، لكن القيمة الاقتصادية تقفز قفزة درجية لحظة تجاوز العتبة التي يمكن فيها إزاحة الإنسان من الحلقة. هذه القفزة الدرجية هي ما يراهن عليه عمالقة التقنية.

دوافع الإنفاق تختلف بين الشركات الأربع الكبرى والمختبرات المتخصصة

حتى وإن اشترت الجميع وحدات GPU مماثلة، فإن طبقات الدوافع تختلف. بالنسبة لمايكروسوفت وجوجل وميتا وأمازون، تُمثّل GPU تأمينًا رخيصًا نسبيًا لحماية أعمال جوهرية تُقاس قيمتها بالتريليونات. مقارنةً بمخاطر تفويت القفزة، تبدو النفقات الرأسمالية أقساط تأمين محتملة. أما المختبرات المتخصصة في الذكاء الاصطناعي كـOpenAI وAnthropic، فالذكاء الاصطناعي هو أعمالها الجوهرية بالكامل. ليس بوسعها اللجوء إلى عمل آخر، لذا الإنفاق ليس تأمينًا بل بقاء. الأرقام قد تتشابه، لكن المعنى يختلف.

ملاحظة إضافية: ما يزيد على 60% من هذه النفقات الرأسمالية لا يذهب إلى الرقائق، بل إلى بناء محطات الطاقة ومراكز البيانات. الأرقام التي تبدو وكأنها “تسوق GPU” هي في الحقيقة رهانات على البنية التحتية للطاقة، وهو عامل آخر يُعقّد الحكم على وجود فقاعة.

بوابة رسوم الجيل القادم: موجّه النوايا

بالتوازي مع منطق الإنفاق، يبرز سؤال جوهري: لماذا يجب الاحتفاظ بتلك المكانة بأي ثمن؟ في كل حقبة، ثمة نقطة عبور تُدير حركة المرور وتجمع رسوم العبور. في حقبة الحاسوب الشخصي كانت ويندوز، في حقبة الإنترنت كان بحث جوجل، في حقبة الهاتف المحمول كانت متاجر التطبيقات. في حقبة وكلاء الذكاء الاصطناعي، المرشّح الأقوى لاحتلال تلك المكانة هو الوكيل الذي يستقبل نوايا المستخدم ويوجّهها نحو الخدمات الملائمة، أي موجّه النوايا (intent router).

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

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

منظور ThakiCloud

أهمية هذا المشهد بالنسبة لـThakiCloud لا تنبع من مجرد متابعة توجهات عمالقة التقنية، بل من كوننا نقع في الطبقة الوسطى من منافسة بوابات الرسوم هذه.

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

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

متى يفشل هذا المنطق

في سبيل التوازن، نستعرض السيناريوهات المضادة. ثمة مسارات واضحة لانهيار منطق التأمين غير المتماثل.

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

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

خلاصة

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

المصادر

• خيط التحليل الأصلي: @Tesla_Teslaway (X)
• task horizon: METR, “Measuring AI Ability to Complete Long Tasks” (2025). طول المهمة التي يمكن إتمامها بموثوقية 50% تضاعف كل سبعة أشهر تقريبًا من 2019 حتى 2025، مع تسارع إلى نحو أربعة أشهر في 2024-2025
• النفقات الرأسمالية لشركات هايبر سكيل 2026: نحو $725B (+77% مقارنة بالعام السابق)، مع توجيه أكثر من 60% منها نحو الطاقة ومراكز البيانات: Tom’s Hardware, CNBC

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

ماذا حدث؟

لنبدأ بالأرقام. كانت حصة توكن النماذج الأمريكية (OpenAI وAnthropic وGoogle) تبلغ نحو 70% في منتصف عام 2025، ثم هبطت إلى نحو 30% في منتصف 2026. وفي الفترة ذاتها، ارتفعت حصة النماذج الصينية (DeepSeek وQwen وMiniMax وMoonshot وTencent وغيرها) من أقل من 2% قبل عام إلى نحو 46%. وجاءت نقطة التحول في الأسبوع الواقع بين 9 و15 فبراير 2026، حين تجاوزت التوكنات التي عالجتها النماذج الصينية 4.12T، متخطيةً 2.94T للنماذج الأمريكية للمرة الأولى.

تتباين الأرقام الدقيقة من مصدر لآخر. فالمحلل الذي نشر هذا الاتجاه على نطاق واسع رصد تراجعًا أمريكيًا من 72% إلى 33% في مقابل 47% للنماذج الصينية. أما التجميع الدقيق الذي يفصل حركة المرور غير المحددة المصدر فيُظهر نحو 46% للنماذج الصينية و36% للأمريكية. في كلتا الحالتين الاتجاه واحد، وينبغي فقط الانتباه إلى أن مقارنة الرقمين مباشرةً (كـ”33% أمريكي مقابل 47% صيني”) تُخفي دلو حركة المرور غير المحددة المصدر.

لماذا كان هذا التحول سريعًا؟

المحرك الرئيسي لهذا التحول هو التوجه المتسارع للمختبرات الصينية الكبرى نحو النماذج مفتوحة الأوزان. أصدرت DeepSeek نموذجَي R1 وV3 بصورة مجانية في جوهرها، مُقتربةً من جودة الاستدلال لدى أعلى النماذج. كما حقق Qwen من Alibaba أداءً متميزًا في مهام متعددة اللغات والبرمجة. يتمتع كلا السلسلتين بترخيصَي MIT وApache اللذين يتيحان الاستخدام التجاري بحرية، مما أسهم في رفع معدل تبني المطورين لهما. وأصبح Qwen أكثر النماذج المفتوحة تنزيلًا على Hugging Face متجاوزًا Llama.

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

التوكن ليس إيرادًا

إذا اكتفيت بالعنوان، خرجت بخلاصة “الصين تتفوق على أمريكا”. أما إذا نظرت عمقًا، وجدت صورة مغايرة. في OpenRouter ذاته، تشير تحليلات إلى أن Anthropic تمتلك نحو 12% من حصة التوكن لكنها تستحوذ على نحو 46% من الإيرادات. وهذا مؤشر على انقسام السوق.

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

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

منظور ThakiCloud وPaxis

هذا الانفصال بالذات هو النقطة المواتية لاستراتيجية ThakiCloud وPaxis. نوضح ذلك في محورين.

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

ثانيًا: طبقة الامتثال. حين تبدأ المؤسسات باستخدام DeepSeek أو Qwen لدواعي التكلفة، يأتي السؤال الفوري عن شروط الترخيص التجاري وحوكمة البيانات. البنية التحتية لـThakiCloud المبنية على Keycloak للتعددية المستأجرة وArgoCD لـGitOps تتوافق تقنيًا مع استضافة نماذج متعددة. غير أن الصادق قوله: طبقة التحقق التلقائي من التراخيص التجارية لكل نموذج وامتثال البيانات لكل عميل هي واجب لم يُنجز بعد. هذا فراغ وفي الوقت ذاته الفرصة الأوضح: الجهة التي توفر خط استدلال يدعم النماذج الصينية المفتوحة كمواطنين درجة أولى مع طبقة التحقق من التراخيص والبيانات ستكسب عملاء القطاعات المنظمة.

متى يضعف هذا المنطق؟

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

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

خلاصة

انقلاب الحصص على OpenRouter حقيقي. لكنه ليس “هزيمةً أمريكية”. إنه وجه واحد من وجوه إعادة هيكلة السوق نحو الانفصال بين التوكن والإيرادات. الرابح هو من لا يُقيّد نفسه بأي نموذج بعينه أيًا كان الصاعد، ومن يمتلك طبقة التحقق اللازمة لاستضافته بصورة قانونية وآمنة. وهذا هو الموضع الذي تستهدفه ThakiCloud وPaxis.

اقرأ أيضًا: المنطق الحقيقي وراء إفراط كبرى شركات التقنية في الاستثمار في وحدات GPU: التأمين غير المتماثل وبوابات العبور للجيل القادم

المصادر

• التحليل الأصلي: @FurkanGozukara (X)
• بيانات حصص OpenRouter: officechai، cryptobriefing، Data Gravity، stockalarm
• انفصال حصة التوكن عن حصة الإيرادات: Normal Guy (X)
• مخاطر بيانات النماذج الصينية: TechTimes

نظرة عامة

يصطدم كل من يدرس الذكاء الاصطناعي الوكيل بحقيقة مبكرة: المادة العلمية مبعثرة. بنية المحول في مكان، ومحاذاة التعلم المعزز في مكان آخر، والتعاون بين الوكلاء وبروتوكول MCP في مدونة ثالثة. كل قطعة متماسكة بذاتها، لكن الموارد التي تُري كيف تتصل هذه القطع في نظام واحد نادرة.

The Hitchhiker’s Guide to Agentic AI: From Foundations to Systems المنشور على arXiv في يونيو 2026 يملأ هذه الفجوة تحديدًا. ليس استعراضًا موجزًا، بل مرجعًا عمليًا يتتبع المسار كاملًا: من طبيعة نموذج اللغة الكبير، عبر المحاذاة والاستدلال، إلى بناء أنظمة وكلاء ونشرها في بيئة الإنتاج. كل فصل يجمع الأسس النظرية مع إرشادات التنفيذ وأمثلة الكود وإحالات المصادر الأولية.

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

ما هذا الدليل

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

نطاق الدليل، مضغوطًا في أربع طبقات:

flowchart TB
    A["1. LLM 기질<br/>트랜스포머 · GPU 시스템<br/>SFT · LoRA · MoE · 압축 · 추론 최적화"] --> B["2. 정렬과 추론<br/>RLHF · PPO · DPO · GRPO<br/>보상 모델링 · CoT · 테스트타임 스케일링"]
    B --> C["3. 에이전트 시스템<br/>궤적 기반 RL · RAG / Agentic RAG<br/>메모리 · MCP · 스킬/도구 · A2A · 멀티에이전트"]
    C --> D["4. 배포와 평가<br/>에이전트 프레임워크 · 에이전트 UI<br/>평가 방법론 · 프로덕션 배포"]
    D -.피드백.-> C
    C -.재학습 신호.-> B

نتناول كل طبقة بالترتيب فيما يلي.

الأساس: طبيعة نموذج اللغة الكبير

ينطلق الدليل من بنية المحول وأنظمة GPU، ثم ينتقل إلى التدريب والضبط الدقيق: الضبط الدقيق الخاضع للإشراف (SFT)، والتقنيات الموفرة للمعاملات مثل LoRA، وبنيات مزج الخبراء (MoE). ويختتم بضغط النماذج وتحسين الاستنتاج.

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

طبقة المحاذاة والاستدلال

تتناول الطبقة الثانية المحاذاة والاستدلال. تبدأ بالتعلم المعزز من ردود الفعل البشرية (RLHF)، وتمر بـ PPO وDPO وتوابعها، وGRPO مع نمذجة المكافآت. ثم تنتقل إلى التعلم المعزز لنماذج الاستدلال الكبيرة، متناولة سلسلة الأفكار والتوسع في وقت الاختبار.

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

أنظمة الوكلاء: MCP والمهارات والذاكرة ومتعدد الوكلاء

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

• التعلم المعزز القائم على المسارات: إشارة التعلم هي مسار العمل الكامل – تسلسل من استدعاءات الأدوات والملاحظات – لا استجابة واحدة.
• RAG وAgentic RAG: الجيل المعزز بالاسترجاع يُرفع من خط أنابيب ثابت إلى شكل يقرر فيه الوكيل بفاعلية استراتيجية استرجاعه.
• أنظمة الذاكرة: هياكل لتراكم المعرفة واسترجاعها عبر الجلسات.
• MCP (بروتوكول سياق النموذج): القناة الموحدة التي يتصل من خلالها الوكيل بالأدوات والبيانات الخارجية.
• مهارات الوكلاء واستخدام الأدوات: قدرات مُعبَّأة كوحدات قابلة لإعادة الاستخدام يمكن اختيارها وتنفيذها.
• بروتوكولات A2A (وكيل إلى وكيل) وبنيات متعدد الوكلاء: الوكلاء يتفويض ويُنسق العمل فيما بينها.

هذه القائمة هي في الواقع مواصفات مكونات منصة أصيلة للوكلاء. كيف تختار المهارات؟ كيف تستدعي الأدوات بأمان؟ كيف تُوجه الذاكرة؟ كيف تُركب عمل وكلاء متعددين في رسم بياني موجه لا دوري؟ يعالج الدليل هذه الأسئلة بوصفها مسألة تصميم نظام موحدة، لا مجموعة تقنيات متفرقة.

النشر والتقييم

تغطي الطبقة الأخيرة العمليات الفعلية: أطر تطوير الوكلاء، وتصميم واجهة مستخدم الوكلاء، ومنهجية التقييم المناسبة للمهام الوكيلية، والنشر في الإنتاج.

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

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

النصف الثاني من هذا الدليل يتداخل كثيرًا مع تصميم Paxis من ThakiCloud. Paxis هي مستوى تحكم السحابة الأصيلة للوكلاء الذي يعمل فوق ai-platform، معاملًا المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. مقابلة مكونات الدليل بطبقاتنا:

• مهارات الوكلاء واستخدام الأدوات – Skill Harness: يختار Paxis من أكثر من 960 مهارة باستخدام BM25 وينفذها في بيئات معزولة. هذا هو مبدأ “عبئ القدرات كوحدات قابلة لإعادة الاستخدام” الذي يؤكد عليه الدليل على نطاق إنتاجي.
• MCP – موصل MCP: يتصل Paxis بالأدوات والبيانات الخارجية عبر موصلات MCP مع إعادة اتصال OAuth تلقائية. القناة الموحدة في الدليل تصبح في المنتج بنية تحتية تتعافى من الأعطال بنفسها.
• أنظمة الذاكرة – محرك معرفة HKE: المعرفة المتراكمة والمسترجعة عبر الجلسات تُعالج من خلال محرك معرفة قائم على الويكي.
• متعدد الوكلاء وA2A – متعدد الوكلاء DAG: تُركب المهام في رسوم بيانية DAG للتفويض والتنسيق، مع NL Cron للجدولة الزمنية.
• النشر والتقييم والسلامة – بوابة السياسات + سجل التدقيق + المهارات المتطورة ذاتيًا: تمر كل إجراءات الوكيل عبر بوابة سياسة وسجل تدقيق. الأنماط المتكررة تُستوعب في مهارات تتطور ذاتيًا. هذا يعالج بالضبط نفس الهاجس الذي دفع الدليل لجعل التقييم طبقة مستقلة.

طبقة الأساس تحمل دلالات أيضًا. تحسين الاستنتاج والضغط المُغطَّيان في الطبقة الأولى من الدليل يقابلان مباشرة عمل ai-platform. توفر منصة ThakiCloud ai-platform البنية التحتية للاستنتاج – Kubernetes مع جدولة GPU المستندة إلى Kueue، وخدمة vLLM، والعزل متعدد المستأجرين – التي تحافظ على الجدوى الاقتصادية حتى حين يُجري وكيل ما استدعاءات أدوات متعددة. انخفاض تكلفة الخدمة (ai-platform) يخلق الجدوى الاقتصادية للوكيل (Paxis). الطبقة الأدنى والطبقة الأعلى في الدليل تتصلان في خط واحد داخل منتجنا.

حدود وتحفظات

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

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

المصادر

• The Hitchhiker’s Guide to Agentic AI: From Foundations to Systems (arXiv:2606.24937)
• صفحة alphaXiv

Overview

Serving a 469B MoE model on your own infrastructure used to be synonymous with a multi-node GPU cluster. The vLLM project and the GLM-5.2-NVFP4 checkpoint published by NVIDIA change that assumption, bringing the requirement down to a single node. A recipe now exists for loading a 469B model on one eight-GPU Blackwell node and serving it directly with vLLM.

This post dissects that recipe. The background on the NVFP4 format itself was covered in an earlier post, Cutting LLM Serving Costs in Half on Blackwell GPUs with NVFP4, so here the focus is narrower: how do you actually bring up one specific frontier model? We walk through the quantization structure, the official vLLM serving command, and a deterministic memory sizing calculation based on public figures, then draw out what this means for ThakiCloud ai-platform operations.

One thing to be clear about upfront: the work in this post did not involve running the model on actual Blackwell hardware. We did not have access to that hardware for this session, so model serving was not performed. Instead, we cite verified figures from the official model card and use those to compute memory sizing deterministically. No benchmark numbers were fabricated.

What Is GLM-5.2-NVFP4

GLM-5.2-NVFP4 is a checkpoint of GLM-5.2 with weights and activations quantized to the NVFP4 data type, ready for direct inference with vLLM and SGLang. The key detail is that this is mixed precision, not “everything at 4 bits.”

In NVIDIA’s modelopt re-quantization approach, only the MoE expert linear layers drop to NVFP4. Shared experts, attention, embeddings, and the initial dense layers stay in FP8 or BF16. The KV cache uses FP8. The strategy is to preserve precision where it matters most while aggressively compressing the MoE experts, which account for the majority of the parameters.

The full serving stack looks like this:

flowchart TB
    A["GLM-5.2 469B MoE<br/>(원본 가중치)"] --> B["NVIDIA modelopt 재양자화<br/>MoE 전문가 → NVFP4<br/>어텐션·임베딩·dense → FP8/BF16"]
    B --> C["GLM-5.2-NVFP4 체크포인트<br/>~465 GB · FP8 KV 캐시"]
    C --> D["vLLM 서빙<br/>양자화 자동 감지 (플래그 불요)<br/>TP=8 · expert parallel"]
    D --> E["단일 Blackwell 노드<br/>8× RTX PRO 6000 (96 GB)"]
    E -.긴 컨텍스트·배치.-> D

In the community, a variant called GLM-5.2-NVFP4-REAP-469B is also circulating. This applies REAP pruning and targets contexts beyond 250K tokens, combining DeepSeek Sparse Attention with MTP speculative decoding. Variants running on 4x RTX PRO 6000 (SM120) and 3x DGX Spark with pipeline parallelism have both been published.

Installation and Integration

The vLLM serving command given in the official NVIDIA model card is as follows. The validated configuration is a single node with 8x RTX PRO 6000 Blackwell GPUs (96 GB each) and tensor parallelism 8.

vllm serve nvidia/GLM-5.2-NVFP4 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --enable-auto-tool-choice \
  --kv-cache-dtype fp8_e4m3 \
  --served-model-name glm-5.2-nvfp4

Several things stand out.

• No --quantization flag. vLLM auto-detects the quantization scheme from the checkpoint, so operators do not need to specify the format manually.
• --enable-expert-parallel: Distributes MoE experts across GPUs using expert parallelism. Combined with TP, this spreads the 469B model across all 8 cards.
• --kv-cache-dtype fp8_e4m3: Keeps the KV cache in FP8, preserving headroom for longer contexts and larger batches.
• --reasoning-parser glm45 / --tool-call-parser glm47: Parses GLM-series reasoning tokens and tool-call formats. Thinking mode is enabled by default.

The minimum vLLM version required to run this checkpoint is best confirmed in the discussion thread on the model card. NVFP4 auto-detection and the expert parallel path were stabilized in relatively recent versions of vLLM.

Experiment Results

As noted above, model serving was not performed directly (no Blackwell GPU available). Instead, memory sizing was computed deterministically from public figures alone. The inputs are three verified facts: 469B parameters, the publicly stated NVFP4-mixed checkpoint size of approximately 465 GB, and the 8x 96 GB node configuration.

The calculations come out as follows.

• At BF16, 469B weights require approximately 938 GB. At FP8, approximately 469 GB.
• The publicly stated NVFP4-mixed checkpoint is approximately 465 GB, nearly identical to a pure FP8 checkpoint (469 GB). A purely 4-bit approach would theoretically reach around 234 GB, but because only the MoE experts are quantized to 4 bits here, the footprint does not drop that far.
• Loading 465 GB of weights onto a node with 8x 96 GB = 768 GB total leaves roughly 303 GB for KV cache and activations. VRAM utilization is approximately 60.5%.

One point worth being honest about: the real benefit of NVFP4-mixed is not “half the storage.” Looking at the weight footprint alone, it is similar to FP8. The actual gains come from two sources. First, Blackwell tensor cores offer higher NVFP4 compute throughput. Second, the FP8 KV cache creates headroom for longer contexts and larger batches. In other words, the value of this checkpoint is not “smaller” but “faster and longer on a single node.” The common marketing claim of “half the memory at 4 bits” does not apply directly to this case.

Implications for ThakiCloud Products

This recipe has direct implications for the ThakiCloud ai-platform - the AI/ML infrastructure layer built on Kubernetes and Kueue-based GPU scheduling that provides vLLM serving and multi-tenant isolation.

• Single-node frontier serving simplifies scheduling. When a 469B model fits on one node (TP=8), the inter-node communication overhead and batching complexity of multi-node distributed serving disappear. From Kueue’s perspective, this becomes a clean resource unit of “one node with 8 GPUs,” making GPU allocation and reclamation straightforward in a multi-tenant environment.
• Well suited for on-premises and sovereign deployments. In customer environments subject to government security requirements or data export restrictions, being able to self-host a frontier-class model on a single on-premises node is a meaningful differentiator. You can run a 469B model on your own infrastructure without any external API dependency.
• VRAM headroom translates to multi-tenant throughput. The calculated 303 GB of remaining KV and activation budget converts into longer contexts or larger batches. More concurrent requests can be served from the same node, which directly improves the per-GPU cost efficiency of a multi-tenant SaaS offering.
• Auto-detected quantization standardizes operations. Because vLLM detects the format automatically, different quantized checkpoints can be deployed through the same serving template. The ai-platform serving manifest does not need to branch per model.

Low serving cost is not just an infrastructure virtue - it is product competitiveness. A configuration that loads a frontier model on one node and keeps 40% of VRAM free for throughput headroom directly reduces the per-GPU TCO presented to customers.

Limitations and Caveats

The biggest limitation belongs to this post itself. There are no measured benchmarks. Token throughput, latency, and accuracy regression figures require an actual Blackwell node to produce. The numbers here are sizing calculations based on a public checkpoint size, not runtime measurements.

Second, the quality impact of mixed-precision quantization requires separate validation. Dropping MoE experts to 4 bits may introduce accuracy regression on some tasks. Rather than trusting the model card evaluation figures at face value, running regression tests in your actual application domain is the right approach.

Third, there is a hardware dependency. This recipe assumes Blackwell. On the Hopper generation (H100), which lacks NVFP4 tensor cores, the same checkpoint does not deliver the same benefits. This configuration is a practical option only for organizations that have already adopted Blackwell or are planning to do so. In environments with a large existing H100 footprint, FP8 remains the realistic baseline.

References

• nvidia/GLM-5.2-NVFP4 Model Card (Hugging Face)
• GLM-5.2 vLLM Recipe
• GLM-5.2-NVFP4-REAP-469B SM120 Serving Recipe (0xSero/glm-5.2-sm120)
• GLM-5.2 469B DGX Spark Pipeline Parallel Serving (bird/GLM-spark)

This article does not answer that question with “bubble” or “not a bubble.” Instead, it examines two structural logics driving big tech spending and considers what they mean for infrastructure providers and enterprise customers. The starting point was an analysis that circulated widely on X (@Tesla_Teslaway thread), and key figures were verified against primary sources.

Why It Looks Like Overinvestment

Distillation is the technique of collecting outputs from expensive frontier models and using them to train cheaper in-house models. For latecomers, it means replicating capabilities at lower cost that the frontier player already paid to develop. The logic holds: no matter how much money the leader pours in, the gap closes quickly. And it is true that open-source and latecomer models have rapidly narrowed benchmark gaps against top-tier models.

Read this far and overinvestment seems obvious. But if what the leader is buying is not “a few months of model advantage,” the math changes.

Asymmetric Insurance: What the Leaders Are Actually Buying

The real reason big tech buys GPUs is not a three-to-six-month performance lead. It is insurance: the right to be a player with direct leverage when a large capability jump occurs. The loss asymmetry between the two scenarios is extreme.

If a jump happens and you are not there, your trillion-dollar core business (search, cloud, office) can unravel overnight. Think Google becoming Yahoo. If the jump never happens and you turn out to have overinvested, your core business survives intact and the GPUs and data centers you bought do not go to zero. One tail is “the reason your company exists disappears.” The other tail is “depreciation losses.” When the loss magnitudes are that asymmetric, the rational choice for a company operating under uncertainty tilts toward overinvestment. This is not a bubble. It is a rational response to an asymmetric payoff structure.

“The Jump” Is Reliability x Task Horizon, Not a Smarter Chatbot

The key question then is what that jump actually means. It is not a chatbot that scores a few more points on a benchmark. It is the product of reliability and task horizon: the ability to carry multi-step work through to completion without collapsing, even without human intervention.

METR measured this task horizon directly. The original thread cited Anthropic, but the accurate source is METR’s “Measuring AI Ability to Complete Long Tasks” study. METR reported that the length of tasks an AI can complete at 50% reliability, measured in human-equivalent time, has doubled roughly every seven months from 2019 to 2025. More striking, from 2024 to 2025 that doubling period compressed to roughly four months. The trend is accelerating.

On the reliability side, simple arithmetic makes the threshold visible. An agent with 95% per-step reliability completing a 20-step task succeeds with probability 0.95^20, roughly 36%. A human must verify every step, so there is no labor saving. The same task at 99% reliability yields about 82% success; at 99.9% it reaches roughly 98%. Reliability climbs linearly, but the moment it crosses the threshold where you can remove humans from the loop, economic value jumps discontinuously. That jump is what big tech is betting on.

The Big Four and Pure Labs Have Different Spending Motives

Even when buying the same GPUs, the motivations differ in kind. For Microsoft, Google, Meta, and Amazon, GPU capex is comparatively cheap insurance protecting trillion-dollar core businesses. Against the risk of missing a capability jump, the capex is a manageable premium. For pure AI labs like OpenAI and Anthropic, GPUs are the core business. There is no separate business to fall back on, so the spending is not insurance but survival. The same numbers carry different meaning.

One more note: more than 60% of this capex goes not to chips but to power and data center construction. Numbers that look like “GPU shopping” are actually closer to bets on power infrastructure, which further complicates a simple bubble verdict.

The Next Tollgate: Intent Router

As important as the spending logic is the question of why that position must be held at any cost. Every era has had a tollgate controlling the critical chokepoint. Windows in the PC era. Google Search in the internet era. App stores in the mobile era. In the AI agent era, the tollgate is likely to be the agent that receives user intent and routes it to the appropriate services: the intent router.

Picture it concretely. A user tells an agent: “Set up dinner plans for tonight and make the reservation.” The agent decides which restaurants to surface as candidates, which booking platform to route through, which delivery service to call. At that moment, restaurants and platforms are no longer exposed directly to the user. If you are not in the agent’s candidate list, you effectively do not exist. The structure shifts from “fall off page one of search results and lose traffic” to “fall out of agent recommendations and lose transactions.” Whoever holds the chokepoint sets the toll.

There is something to be honest about here, though. If agents become tollgates, infrastructure providers are not entirely insulated from that dynamic either. And the premise that “enterprises will resist dependency on external agents” is closer to a trend forming than a settled demand. This article does not claim otherwise. What we observe are signals: data sovereignty, regulatory compliance, and sovereign AI requirements converging to make that trend increasingly legible.

The ThakiCloud Angle

Why this picture matters for ThakiCloud is not because we need to track big tech trends. It is because we sit in the middle layer of that tollgate competition.

The harder big tech competes to control the intent-router layer, the more valuable the alternatives become for enterprises that do not want to hand their data and models to external agents. What those enterprises need is an execution environment for running their own agent infrastructure on-prem or in a private cloud. ThakiCloud’s Kubernetes-based AI/ML workload infrastructure and Kueue-based GPU workload scheduling sit exactly in that space. On the path from GPU cloud MSP to enterprise AI adoption partner, we are targeting this “tollgate internalization” demand.

The task horizon threshold logic also connects directly to product strategy. If an agent’s economic value jumps discontinuously the moment per-step reliability crosses the threshold where humans can leave the loop, then how reliably and stably we carry a customer’s AI workloads is not just an operational quality metric. It is the variable that determines whether the customer crosses the threshold that lets them remove humans from the verification loop. Infrastructure stability is a nonlinear lever on customer ROI. That is why we are obsessive about reliability, isolation, and scheduling quality.

When This Logic Breaks Down

For balance, here are the counter-scenarios. The asymmetric insurance logic can unravel in clear ways.

First, the reliability curve could plateau before it reaches the threshold. If task horizon keeps extending but per-step reliability stalls before 99.9%, the economic value of long autonomous tasks never clears the step. Second, distillation and open-weight models could become good enough that owning the frontier directly stops mattering. The insurance the leaders bought would depreciate. Third, power, land, and grid constraints could prevent capex from translating into actual operational capacity. Spending the money without being able to draw the power keeps the GPUs idle. If any one of these materializes, “rational insurance” becomes “expensive misjudgment.”

The point is not to pick a side. It is to know which indicators separate the outcomes. Does reliability cross the threshold? Do open-weight models substitute for the frontier? Does power keep pace with capex? These three are the metrics to watch over the coming quarters.

Summary

Big tech’s GPU overinvestment may be a bubble or it may be rational insurance. Reading it as “a rational response to an asymmetric payoff structure, combined with a race to capture the next tollgate” reveals something far more structured than mere mania. And on the other side of that race, enterprise demand to avoid tollgate dependency is forming. ThakiCloud is the infrastructure built for that side.

Sources

• Original analysis thread: @Tesla_Teslaway (X)
• Task horizon: METR, “Measuring AI Ability to Complete Long Tasks” (2025). Task length completable at 50% reliability doubled roughly every 7 months from 2019 to 2025; the 2024-2025 interval accelerated to roughly 4 months.
• 2026 hyperscaler capex ~$725B (+77% YoY), with 60%+ of spend going to power and data centers: Tom’s Hardware, CNBC

This post verifies that data, surfaces the second layer the headline tends to obscure, and draws out what it means for ThakiCloud and Paxis strategy.

What Happened

Start with the numbers. US model token share (OpenAI, Anthropic, Google) was around 70% in mid-2025. By mid-2026 it had fallen to about 30%. Over the same period, Chinese models (DeepSeek, Qwen, MiniMax, Moonshot, Tencent, and others) climbed from under 2% a year earlier to roughly 46%. The inflection point was the week of February 9-15, 2026, when Chinese models processed 4.12 trillion tokens against 2.94 trillion for US models – the first time they crossed.

Different analysts land at slightly different digits. The analyst whose work spread this data most widely counted US models at 72% dropping to 33%, with Chinese models at 47%. A more precise count that separates unidentified traffic puts Chinese models at about 46% and US models at about 36%. Either way, the direction is the same. The one thing to watch is that comparisons like “US 33% vs China 47%” obscure the unidentified bucket, so treat the exact numbers as directional rather than definitive.

Why It Happened So Fast

The driver is a sharp shift toward open-weight releases from leading Chinese labs. DeepSeek released R1 and V3 at effectively no cost and achieved near-top reasoning quality. Alibaba’s Qwen series delivered strong results on multilingual and coding tasks. Both families carry MIT or Apache licenses, which made commercial adoption straightforward and pulled developer uptake up fast. Qwen now leads Hugging Face download charts ahead of Llama.

There is also an argument that Nvidia export controls – the restrictions on H100, H200, and B200 sales to China – created a paradoxical incentive. Constrained on compute, Chinese labs had stronger motivation to squeeze more performance from fewer resources. Add the fact that a large portion of OpenRouter’s user base is cost-sensitive startups and individual developers, and a structural tilt toward better price-to-license ratios becomes predictable.

But Tokens Are Not Revenue

The headline reading is “China beat the US.” One layer deeper, a different picture appears. On the same OpenRouter platform, one analysis found that Anthropic holds about 12% of token share but captures roughly 46% of revenue. That is a signal of market bifurcation.

One segment is a commodity market where the cheapest model wins. High token volumes flow through it, but margins are thin. The other is a premium segment – coding, autonomous agents, tasks where failure is expensive – where the model that actually performs commands revenue even at higher prices. Token share reflects the first segment. Revenue share reflects the second. They are not the same metric.

There is one more thing to add. OpenRouter’s user base skews heavily toward cost-sensitive developers, which means it does not represent the full enterprise market. Reading the share reversal directly as “US defeat” means leaving out both of those points and jumping to a conclusion that overstates what the data shows. The real event is not a win or a loss – it is a market splitting into two tracks: tokens and revenue.

The ThakiCloud and Paxis Angle

That split is exactly where ThakiCloud and Paxis have a favorable position. Two points.

First, model neutrality. In a market where commodity and premium tracks diverge and model rankings flip every quarter, the most resilient structure is one that is not locked to any single vendor. Paxis aims at model-neutral routing – letting customers choose their own price-performance tradeoffs the way OpenRouter does, but inside an enterprise-grade layer. The rise of Chinese open-weight models is not a threat to this strategy; it reinforces it. Whatever model rises to the top can be treated as a first-class citizen, which means market volatility becomes opportunity rather than disruption.

Second, the compliance layer. When enterprises start running DeepSeek or Qwen families to control costs, the questions that follow immediately are about commercial license terms and data governance. ThakiCloud’s Keycloak-based multi-tenancy and ArgoCD GitOps pipeline are technically well-suited to support diverse model backends. But to be honest, the layer that automatically validates per-model commercial licenses and per-customer data compliance is still homework we need to build. That is both a gap and the clearest opportunity in front of us. The provider that combines a first-class inference pipeline for Chinese open-weight models with license and data validation tooling will be the one that wins regulated-industry customers.

Where This Logic Weakens

For balance, here are the scenarios where this reasoning breaks down.

First, enterprise purchasing decisions can move differently from developer usage patterns. There is no guarantee the token share curve translates directly into enterprise adoption. Second, if data risk concerns around Chinese models block uptake in heavily regulated industries like finance and government, the share curve may fragment by sector. Third, the unidentified traffic bucket is large enough that precise numbers vary meaningfully across sources.

Three indicators are worth watching: whether the revenue share curve follows the token share curve in the same direction; whether Chinese model adoption actually rises in regulated industries; and whether the same trend appears in enterprise AI gateways outside OpenRouter.

Summary

The share reversal on OpenRouter is real. But it does not mean the US lost. It is one facet of a market restructuring in which tokens and revenue are pulling apart. The winners will be those who are not dependent on whichever model rises next – and who can provide the validation layer that makes running that model legal and safe. That is the position ThakiCloud and Paxis are building toward.

Related reading: The Real Logic Behind Big Tech’s GPU Overinvestment: Asymmetric Insurance and the Next Generation Toll Gates

Sources

• Original analysis: @FurkanGozukara (X)
• OpenRouter share data: officechai, cryptobriefing, Data Gravity, stockalarm
• Token share vs revenue share split: Normal Guy (X)
• Chinese model data risk: TechTimes

Overview

Anyone studying agentic AI quickly notices that the material is scattered. Transformer architecture lives in one place, reinforcement learning alignment in another, MCP and multi-agent collaboration in yet another blog post. Each piece is solid on its own, but resources that show how they connect into a single system are rare.

The Hitchhiker’s Guide to Agentic AI: From Foundations to Systems, published on arXiv in June 2026, targets exactly that gap. This is not a short survey. It is a practitioner reference that follows the full path from the LLM substrate, through alignment and reasoning, to building agent systems and deploying them in production. Each chapter pairs theoretical foundations with implementation guidance, code examples, and primary literature citations.

For a platform like ThakiCloud that treats agents as first-class resources, this guide hits close to home. Skills, tools, memory, and multi-agent orchestration – the topics that fill the second half of the document – are the same things we work with daily inside Paxis (Agent-Native Cloud). This post maps the guide across four layers and draws out what we can take from it for our own products.

What This Guide Is

The guide assumes its reader is a practitioner who wants to build agents. It does not stop at listing concepts; it follows the full stack from first principles to production deployment. The emphasis is on dependencies between layers. Good agents do not emerge from nowhere. A well-trained model must come first, then alignment and reasoning capabilities are added on top, and only then do tool use, memory, and collaboration accumulate into a system.

The guide’s scope, compressed into four layers:

flowchart TB
    A["1. LLM 기질<br/>트랜스포머 · GPU 시스템<br/>SFT · LoRA · MoE · 압축 · 추론 최적화"] --> B["2. 정렬과 추론<br/>RLHF · PPO · DPO · GRPO<br/>보상 모델링 · CoT · 테스트타임 스케일링"]
    B --> C["3. 에이전트 시스템<br/>궤적 기반 RL · RAG / Agentic RAG<br/>메모리 · MCP · 스킬/도구 · A2A · 멀티에이전트"]
    C --> D["4. 배포와 평가<br/>에이전트 프레임워크 · 에이전트 UI<br/>평가 방법론 · 프로덕션 배포"]
    D -.피드백.-> C
    C -.재학습 신호.-> B

We walk through each layer below.

Foundation: The LLM Substrate

The guide starts with transformer architecture and GPU systems, then moves to training and fine-tuning: supervised fine-tuning (SFT), parameter-efficient techniques like LoRA, and mixture-of-experts (MoE) architectures. It closes with model compression and inference optimization.

The ordering is intentional. An agent’s behavioral quality is ultimately bounded by its base model’s capabilities, and the cost of running that model in practice hinges on compression and inference optimization. If inference costs cannot be brought down, the economics collapse the moment an agent starts calling tools multiple times and traversing long trajectories. Efficiency at the lowest layer determines feasibility at the highest.

Alignment and Reasoning Layer

The second layer covers alignment and reasoning. It starts with reinforcement learning from human feedback (RLHF), works through PPO, DPO and its variants, and GRPO with reward modeling. It then moves to reinforcement learning for large reasoning models, covering chain-of-thought and test-time scaling.

An important shift happens here. The center of gravity moves from simply producing answers that people prefer, toward reasoning capability – the ability to think longer and arrive at better answers independently. For an agent that plans across multiple steps and verifies intermediate results, this reasoning layer has to be solid. If alignment handles safety, reasoning handles autonomy.

Agent Systems: MCP, Skills, Memory, Multi-Agent

The second half of the guide is devoted entirely to this layer, which signals where the weight of agentic AI actually sits. The topics covered are names we work with every day.

• Trajectory-based reinforcement learning: The learning signal is the full action trajectory – a sequence of tool calls and observations – not a single response.
• RAG and Agentic RAG: Retrieval-augmented generation is lifted from a static pipeline into a form where the agent actively decides its retrieval strategy.
• Memory systems: Structures for accumulating and retrieving knowledge across sessions.
• MCP (Model Context Protocol): The standardized channel through which an agent connects to external tools and data.
• Agent skills and tool use: Capabilities packaged as reusable units that can be selected and executed.
• A2A (Agent-to-Agent) protocols and multi-agent architectures: Agents delegating and coordinating work with each other.

This list is effectively a parts specification for an Agent-Native platform. How do you select skills? How do you call tools safely? How do you route memory? How do you compose multiple agents’ work into a DAG? The guide treats these questions as a unified system design problem, not a collection of isolated techniques.

Deployment and Evaluation

The final layer covers actual operations: agent development frameworks, agent UI design, evaluation methodology suited to agentic tasks, and production deployment.

The fact that evaluation gets its own dedicated layer is striking. Metrics built for measuring single-response accuracy cannot capture an agent that calls tools repeatedly and traverses multiple steps. You need to look at trajectory success rate, safety at intermediate steps, and cost-effectiveness together. Placing evaluation as an independent topic rather than an appendix to implementation reflects how genuinely difficult it is to answer “how do we know this is working?” for agent systems.

Implications for ThakiCloud Products

The second half of this guide overlaps closely with the design of ThakiCloud’s Paxis. Paxis is an Agent-Native Cloud control plane that runs on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. Mapping the guide’s components onto our layers:

• Agent skills and tool use – Skill Harness: Paxis selects from over 960 skills using BM25 and executes them in isolated sandboxes. This is the guide’s “package capabilities as reusable units” principle operating at production scale.
• MCP – MCP Connector: Paxis connects to external tools and data through MCP connectors with automatic OAuth reconnection. The guide’s standardized connection channel becomes infrastructure that recovers from failures on its own.
• Memory systems – HKE Knowledge Engine: Knowledge accumulated and retrieved across sessions is handled through a wiki-based knowledge engine.
• Multi-agent and A2A – DAG Multi-Agent: Tasks are composed into DAGs for delegation and coordination, with NL Cron for time-based scheduling.
• Deployment, evaluation, safety – Policy Gate + Audit Log + Self-Evolving Skills: Every agent action passes through a policy gate and audit log. Recurring patterns are absorbed into self-evolving skills. This directly addresses the same concern that led the guide to treat evaluation as a separate layer.

The substrate layer carries implications too. The inference optimization and compression covered in the guide’s first layer map directly to the work of ai-platform. ThakiCloud’s ai-platform provides the inference infrastructure – Kubernetes with Kueue-based GPU scheduling, vLLM serving, and multi-tenant isolation – that keeps economics viable even when an agent makes many tool calls. Low serving cost (ai-platform) creates agent economic viability (Paxis). The guide’s lowest layer and highest layer connect in a single line within our product.

Limitations and Counterpoints

Taking this document as the final word on the subject would be a mistake. First, the field moves fast. Agentic AI standards shift on a monthly basis. MCP and A2A implementation details that are accurate today may look different in six months, and the guide’s code examples are tied to specific versions. As a conceptual map it has lasting value; implementation specifics always need to be verified against primary sources.

Second, covering everything necessarily means nothing gets covered to its full depth. Bundling every layer into one document gains breadth but loses depth. Bringing any specific technique to production quality still requires dedicated literature and hands-on experimentation. The guide’s real value is not the answers it gives but the map it draws – showing where each scattered piece sits inside a unified system. Reading a map and actually driving are different things.

Sources

• The Hitchhiker’s Guide to Agentic AI: From Foundations to Systems (arXiv:2606.24937)
• alphaXiv page

개요

469B 규모의 MoE 모델을 자체 인프라에서 서빙한다는 말은, 1년 전만 해도 멀티 노드 GPU 클러스터를 전제로 했습니다. 그런데 vLLM 프로젝트와 NVIDIA가 공개한 GLM-5.2-NVFP4 체크포인트는 이 전제를 단일 노드로 끌어내립니다. 8장짜리 Blackwell 노드 한 대에 469B 모델을 올리고 vLLM으로 바로 서빙하는 레시피가 나온 것입니다.

이 글은 그 레시피를 뜯어봅니다. NVFP4 포맷 자체의 배경은 이전 글 NVFP4로 Blackwell GPU에서 LLM 서빙 비용 절반 줄이기에서 다뤘으니, 여기서는 “특정 프런티어 모델 하나를 실제로 어떻게 올리는가”에 집중합니다. 양자화 구조, 공식 vLLM 서빙 명령, 그리고 공개 수치를 근거로 한 메모리 사이징 계산을 차례로 정리하고, ThakiCloud ai-platform 운용 관점에서 무엇을 가져갈 수 있는지 짚습니다.

먼저 분명히 해두자면, 이 글의 실험은 실제 Blackwell 노드에서 모델을 띄운 것이 아닙니다. 해당 하드웨어를 이 세션에서 보유하지 못했기에, 모델 서빙 자체는 수행하지 않았습니다. 대신 공식 모델카드의 검증된 수치를 인용하고, 그 위에서 메모리 사이징을 결정론적으로 계산했습니다. 벤치마크 수치를 지어내지 않았습니다.

GLM-5.2-NVFP4는 무엇인가

GLM-5.2-NVFP4는 GLM-5.2의 가중치와 활성화를 NVFP4 데이터 타입으로 양자화해, vLLM과 SGLang에서 곧바로 추론할 수 있게 만든 체크포인트입니다. 핵심은 “전부 4비트”가 아니라 혼합 정밀도라는 점입니다.

NVIDIA modelopt 재양자화 방식에서는 MoE 전문가 선형층(expert linears)만 NVFP4로 떨어지고, 공유 전문가(shared experts)·어텐션·임베딩·초기 dense 층은 FP8/BF16으로 남습니다. 여기에 KV 캐시는 FP8을 씁니다. 정밀도에 민감한 부분은 보존하고, 파라미터 대부분을 차지하는 MoE 전문가만 공격적으로 압축하는 전략입니다.

서빙 스택 전체를 그림으로 정리하면 다음과 같습니다.

flowchart TB
    A["GLM-5.2 469B MoE<br/>(원본 가중치)"] --> B["NVIDIA modelopt 재양자화<br/>MoE 전문가 → NVFP4<br/>어텐션·임베딩·dense → FP8/BF16"]
    B --> C["GLM-5.2-NVFP4 체크포인트<br/>~465 GB · FP8 KV 캐시"]
    C --> D["vLLM 서빙<br/>양자화 자동 감지 (플래그 불요)<br/>TP=8 · expert parallel"]
    D --> E["단일 Blackwell 노드<br/>8× RTX PRO 6000 (96 GB)"]
    E -.긴 컨텍스트·배치.-> D

여기에 더해, 커뮤니티에서는 REAP 가지치기를 적용한 GLM-5.2-NVFP4-REAP-469B 변형도 돌고 있습니다. 250K 이상 컨텍스트를 목표로 DeepSeek Sparse Attention과 MTP 추측 디코딩(speculative decode)을 함께 쓰는 레시피이며, 4× RTX PRO 6000(SM120) 구성이나 3× DGX Spark 파이프라인 병렬 구성 같은 변형이 공개돼 있습니다.

설치 및 통합

NVIDIA가 공식 모델카드에서 제시하는 vLLM 서빙 명령은 다음과 같습니다. 검증된 구성은 단일 노드 8× RTX PRO 6000 Blackwell(각 96 GB), 텐서 병렬 8입니다.

vllm serve nvidia/GLM-5.2-NVFP4 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --enable-auto-tool-choice \
  --kv-cache-dtype fp8_e4m3 \
  --served-model-name glm-5.2-nvfp4

몇 가지가 눈에 띕니다.

• --quantization 플래그가 없습니다. vLLM이 체크포인트에서 양자화 방식을 자동 감지하기 때문입니다. 운영자가 포맷을 손으로 지정할 필요가 없습니다.
• --enable-expert-parallel: MoE 전문가를 GPU에 분산해 expert parallel로 처리합니다. TP와 함께 쓰여 469B 모델을 8장에 펼칩니다.
• --kv-cache-dtype fp8_e4m3: KV 캐시를 FP8로 둬 컨텍스트·배치 여유를 확보합니다.
• --reasoning-parser glm45 / --tool-call-parser glm47: GLM 계열의 추론 토큰과 도구 호출 포맷을 파싱합니다. thinking은 기본 활성화입니다.

체크포인트를 실행할 vLLM 버전 요구는 모델카드의 토론 스레드에서 확인하는 것이 안전합니다. NVFP4 자동 감지와 expert parallel 경로는 비교적 최근 vLLM에서 안정화됐기 때문입니다.

실제 실험 결과

앞서 밝혔듯 모델 서빙은 직접 수행하지 못했습니다(Blackwell GPU 미보유). 그래서 공개 수치만으로 메모리 사이징을 결정론적으로 계산했습니다. 입력은 검증된 사실 세 가지뿐입니다. 469B 파라미터, 공개된 NVFP4-혼합 체크포인트 크기 ~465 GB, 그리고 8× 96 GB 노드 구성입니다.

계산 결과는 다음과 같습니다.

• BF16 기준 469B 가중치는 약 938 GB, FP8은 약 469 GB입니다.
• 공개된 NVFP4-혼합 체크포인트는 약 465 GB로, 순수 FP8(469 GB)과 거의 같습니다. 순수 4비트라면 이론상 234 GB까지 떨어지지만, 이 체크포인트는 MoE 전문가만 4비트라 그 수준까지 내려가지 않습니다.
• 8× 96 GB = 총 768 GB 노드에 465 GB 가중치를 올리면, KV 캐시와 활성화에 약 303 GB가 남습니다. VRAM 사용률은 약 60.5%입니다.

여기서 정직하게 짚어야 할 점이 있습니다. NVFP4-혼합의 진짜 이득은 “저장 용량 반토막”이 아닙니다. 가중치 풋프린트만 보면 FP8과 비슷합니다. 실제 이득은 두 곳에서 나옵니다. 하나는 Blackwell 텐서 코어의 NVFP4 연산 처리량이고, 다른 하나는 FP8 KV 캐시가 만들어 주는 컨텍스트·배치 여유 공간입니다. 즉 이 체크포인트의 가치는 “더 작게”가 아니라 “한 노드에 올린 채로 더 빠르고 더 길게”에 있습니다. 마케팅 수사에 흔히 등장하는 “4비트로 메모리 절반” 같은 표현을 이 케이스에 그대로 적용하면 틀립니다.

ThakiCloud 제품 적용 시사점

이 레시피는 ThakiCloud의 ai-platform 관점에서 직접적인 함의를 가집니다. ai-platform은 쿠버네티스와 Kueue 기반 GPU 스케줄링 위에서 vLLM 서빙과 멀티테넌트 격리를 제공하는 AI/ML 인프라입니다.

• 단일 노드 프런티어 서빙 = 스케줄링이 단순해집니다. 469B 모델이 한 노드(TP=8)에 들어가면, 멀티 노드 분산 서빙에서 발생하는 노드 간 통신·배치 복잡도가 사라집니다. Kueue 입장에서는 “8 GPU를 가진 노드 한 대”라는 깔끔한 자원 단위로 큐잉할 수 있어, 멀티테넌트 환경에서 GPU 할당과 회수가 단순해집니다.
• 온프렘·소버린 시나리오에 잘 맞습니다. 국정원 요구 대응이나 데이터 반출이 금지된 고객 환경에서, 프런티어급 모델을 단일 노드 온프레미스로 self-hosting할 수 있다는 것은 큰 차별점입니다. 외부 API 의존 없이 자체 인프라에서 469B 모델을 돌릴 수 있습니다.
• VRAM 여유 = 멀티테넌트 처리량. 계산된 303 GB의 KV·활성화 여유는 긴 컨텍스트나 큰 배치로 환산됩니다. 같은 노드에서 더 많은 동시 요청을 소화한다는 뜻이고, 이는 멀티테넌트 SaaS의 GPU당 단가 경쟁력으로 이어집니다.
• 양자화 자동 감지 = 운영 표준화. vLLM이 포맷을 자동 감지하므로, 다양한 양자화 체크포인트를 같은 서빙 템플릿으로 배포할 수 있습니다. ai-platform의 서빙 매니페스트를 모델별로 분기하지 않아도 됩니다.

낮은 서빙 비용은 단순한 인프라 미덕이 아니라 제품 경쟁력입니다. 한 노드에 프런티어 모델을 올리고 VRAM의 40%를 처리량 여유로 남기는 구성은, 고객사에 제시하는 GPU당 TCO를 직접 끌어내립니다.

한계 및 반론

먼저 가장 큰 한계는 이 글 자체가 안고 있습니다. 실측 벤치마크가 없습니다. 토큰 처리량, 지연 시간, 정확도 회귀 같은 수치는 실제 Blackwell 노드에서 서빙해 봐야 나옵니다. 이 글의 숫자는 공개 체크포인트 크기에 기반한 사이징 계산이지, 런타임 측정이 아닙니다.

둘째, 혼합 정밀도 양자화의 품질 영향은 별도 검증이 필요합니다. MoE 전문가를 4비트로 떨어뜨리면 일부 태스크에서 정확도 회귀가 있을 수 있습니다. 모델카드의 평가 수치를 그대로 신뢰하기보다, 실제 사용 도메인에서 회귀 테스트를 돌려 확인해야 합니다.

셋째, 하드웨어 종속성입니다. 이 레시피의 전제는 Blackwell입니다. NVFP4 텐서 코어가 없는 Hopper(H100) 세대에서는 같은 체크포인트의 이점을 그대로 누릴 수 없습니다. 즉 이 구성은 “Blackwell을 이미 도입했거나 도입할 조직”에게만 직접적인 선택지입니다. 기존 H100 자산이 많은 환경에서는 FP8 경로가 여전히 현실적인 기준선입니다.

출처

• nvidia/GLM-5.2-NVFP4 모델카드 (Hugging Face)
• GLM-5.2 vLLM 레시피
• GLM-5.2-NVFP4-REAP-469B SM120 서빙 레시피 (0xSero/glm-5.2-sm120)
• GLM-5.2 469B DGX Spark 파이프라인 병렬 서빙 (bird/GLM-spark)

이 글은 그 의문에 “거품이다 / 아니다”로 답하지 않습니다. 대신 빅테크의 지출을 움직이는 구조적 논리 두 가지를 짚고, 그것이 우리 같은 인프라 사업자와 엔터프라이즈 고객에게 무엇을 의미하는지 정리합니다. 출발점은 X에서 활발히 논의된 한 분석(@Tesla_Teslaway 스레드)이었고, 핵심 수치는 직접 1차 출처로 검증했습니다.

과투자처럼 보이는 이유

증류는 비싼 프런티어 모델의 출력을 모아 저렴한 자체 모델 학습에 쓰는 기법입니다. 후발 주자 입장에서는 프런티어가 먼저 비용을 치러 개척한 능력을 더 싸게 복제할 수 있습니다. 그래서 “선두가 아무리 돈을 부어도 격차는 금세 좁혀진다”는 논리가 성립합니다. 실제로 오픈소스·후발 모델이 상위 모델과의 벤치마크 격차를 빠르게 줄여온 것도 사실입니다.

여기까지만 보면 과투자가 맞습니다. 그런데 선두 기업이 사는 것이 “몇 달치 모델 우위”가 아니라면 셈법이 달라집니다.

비대칭 보험: 선두가 실제로 사는 것

빅테크가 GPU를 사는 진짜 이유는 3~6개월치 성능 우위가 아니라, 능력의 큰 도약이 일어났을 때 그 자리에 직접적인 힘을 가진 플레이어로 남아 있기 위한 보험입니다. 두 시나리오의 손실 크기가 압도적으로 비대칭이기 때문입니다.

도약이 일어났는데 내가 거기 없다면, 검색·클라우드·오피스 같은 조 단위 본업이 순식간에 흔들립니다. 구글이 야후가 되는 시나리오입니다. 반대로 도약이 끝내 안 일어나서 내가 과투자한 것으로 판명되더라도, 본업은 그대로 살아 있고 사들인 GPU와 데이터센터가 0이 되는 것도 아닙니다. 한쪽 꼬리는 “회사의 존재 이유가 사라짐”, 다른 쪽 꼬리는 “감가상각 손실”입니다. 손실의 크기가 이렇게 비대칭이면, 불확실성 속에서 합리적 기업이 택할 수 있는 답은 과투자 쪽으로 기웁니다. 거품이 아니라 비대칭 보상 구조에 대한 합리적 반응이라는 뜻입니다.

“도약”은 똑똑한 챗봇이 아니라 신뢰도 × 태스크 호라이즌입니다

그렇다면 여기서 말하는 도약이 무엇인지가 핵심입니다. 더 똑똑한 챗봇이나 벤치마크 점수 몇 점이 아닙니다. 사람이 개입하지 않아도 여러 단계짜리 작업을 끝까지 무너지지 않고 끌고 가는 능력, 즉 신뢰도와 태스크 호라이즌(task horizon)의 곱입니다.

이 태스크 호라이즌을 실제로 측정한 곳은 METR입니다(원 스레드는 앤트로픽으로 적었으나, 정확한 출처는 METR의 “Measuring AI Ability to Complete Long Tasks” 연구입니다). METR은 AI가 50% 신뢰도로 끝낼 수 있는 작업의 길이(사람 기준 소요 시간)가 2019년부터 2025년까지 약 7개월마다 두 배가 됐다고 보고했습니다. 더 주목할 점은 2024~2025년 구간에서는 그 배가 주기가 약 4개월로 짧아졌다는 것입니다. 추세가 가속하고 있다는 신호입니다.

신뢰도 쪽은 단순한 산수가 임계선을 분명하게 보여줍니다. 단계당 신뢰도가 95%인 에이전트가 20단계짜리 작업을 끝까지 성공할 확률은 0.95의 20제곱, 즉 약 36%에 불과합니다. 사람이 매 단계를 검수해야 하니 인건비 절감이 없습니다. 같은 작업에서 신뢰도가 99%면 성공률은 약 82%, 99.9%면 약 98%로 올라갑니다. 신뢰도는 선형으로 오르는데, 사람을 빼도 되는 임계선을 넘는 순간 경제적 가치는 계단식으로 점프합니다. 이 점프가 빅테크가 베팅하는 “도약”의 정체입니다.

빅4와 순수 랩의 지출 동기는 다릅니다

같은 GPU를 사도 동기의 층위가 다릅니다. 마이크로소프트·구글·메타·아마존에게 GPU는 조 단위 본업을 지키는 상대적으로 싼 보험입니다. 도약을 놓치는 리스크에 비하면 캐펙스는 감당 가능한 보험료입니다. 반면 오픈AI·앤트로픽 같은 순수 AI 랩에게는 GPU가 곧 본업입니다. 도망갈 본업이 따로 없으니 지출은 보험이 아니라 생존입니다. 같은 숫자라도 의미가 다릅니다.

덧붙이면, 이 캐펙스의 60% 이상은 칩이 아니라 전력과 데이터센터 건설에 들어갑니다. “GPU 쇼핑”으로만 보이는 숫자가 실제로는 전력 인프라 베팅에 더 가깝다는 점도 거품 판단을 흐리게 만드는 요소입니다.

다음 세대 톨게이트: 의도 라우터

지출 논리만큼 중요한 것이 “왜 그 자리를 반드시 지켜야 하는가”입니다. 시대마다 길목을 쥔 톨게이트가 있었습니다. PC 시대의 윈도우, 인터넷 시대의 구글 검색, 모바일 시대의 앱스토어입니다. AI 에이전트 시대에는 사용자의 의도를 받아 적절한 서비스로 연결해 주는 에이전트, 즉 의도 라우터(intent router)가 그 자리를 차지할 가능성이 높습니다.

구체적으로 그려보면 이렇습니다. 사용자가 에이전트에게 “오늘 저녁 약속 잡고 예약해 줘”라고 말합니다. 어떤 식당을 후보로 올릴지, 어느 예약 플랫폼을 거칠지, 어느 배달 서비스를 부를지를 에이전트가 정합니다. 이 순간 식당과 플랫폼은 더 이상 사용자에게 직접 노출되지 않습니다. 에이전트의 후보 목록에 들지 못하면 존재하지 않는 것과 같습니다. 검색 결과 1페이지에 못 들면 트래픽이 사라지던 구조가, 에이전트의 추천 후보에 못 들면 거래가 사라지는 구조로 옮겨가는 것입니다. 길목을 쥔 쪽이 통행세를 정합니다.

다만 여기서 정직해야 할 부분이 있습니다. 에이전트가 톨게이트가 된다면, 인프라 사업자 역시 그 역학에서 완전히 자유롭지 않습니다. 그리고 “엔터프라이즈가 외부 에이전트에 종속되기 싫어할 것”이라는 명제는 아직 완결된 수요라기보다 형성 중인 흐름에 가깝습니다. 이 글은 그것을 단정하지 않습니다. 우리가 관찰하는 것은, 데이터 주권·규제 준수·소버린 AI 요구가 겹치면서 그 흐름이 점점 또렷해지고 있다는 신호입니다.

ThakiCloud 관점

이 구도가 ThakiCloud에 중요한 이유는 빅테크 동향 파악 때문이 아닙니다. 톨게이트 경쟁의 중간 레이어에 우리가 있기 때문입니다.

빅테크가 의도 라우터 레이어를 장악하려 경쟁할수록, 자신의 데이터와 모델을 외부 에이전트에 넘기고 싶지 않은 엔터프라이즈의 선택지가 중요해집니다. 그들에게 필요한 것은 온프렘 또는 프라이빗 환경에서 자체 에이전트 인프라를 돌릴 수 있는 실행 환경입니다. ThakiCloud가 제공하는 쿠버네티스 기반 AI/ML 워크로드 인프라, 그리고 Kueue를 통한 GPU 워크로드 스케줄링이 바로 그 자리에 있습니다. GPU 클라우드 레이어에서 MSP로, 다시 엔터프라이즈 AI 도입 파트너로 넘어가는 경로에서, 우리는 이 “톨게이트 내재화” 수요를 겨냥합니다.

태스크 호라이즌의 임계선 논리는 제품 전략에도 직접 닿습니다. 에이전트의 단계당 신뢰도가 임계선을 넘는 순간 경제적 가치가 계단식으로 뛴다면, 고객의 AI 워크로드를 얼마나 높은 신뢰도로 안정적으로 떠받치느냐는 단순한 운영 품질 지표가 아닙니다. 그것은 고객이 사람을 검수 루프에서 빼도 되는 임계선을 넘느냐 마느냐를 가르는 변수입니다. 인프라 안정성이 곧 고객 ROI의 비선형 레버라는 뜻입니다. 우리가 안정성·격리·스케줄링 품질에 집착하는 이유가 여기에 있습니다.

이 논리가 틀리는 경우

균형을 위해 반대 시나리오도 적어 둡니다. 비대칭 보험 논리가 무너지는 길은 분명히 있습니다.

첫째, 신뢰도 곡선이 임계선 앞에서 정체될 수 있습니다. 태스크 호라이즌이 길어져도 단계당 신뢰도가 99.9%대에서 더 오르지 않으면, 긴 자율 작업의 경제적 가치는 끝내 계단을 넘지 못합니다. 둘째, 증류와 오픈웨이트 모델이 충분히 좋아져서 “프런티어를 직접 소유할 필요”가 약해질 수 있습니다. 그러면 선두가 산 보험의 값어치가 떨어집니다. 셋째, 전력·부지·전력망 제약이 캐펙스를 실제 가동 능력으로 바꾸지 못하게 막을 수 있습니다. 돈을 써도 전기를 못 끌어오면 GPU는 멈춰 있습니다. 이 세 가지 중 하나라도 현실이 되면 “합리적 보험”은 “값비싼 오판”으로 바뀝니다.

요점은 어느 쪽이 맞다고 단정하는 게 아니라, 무엇을 지켜보면 답이 갈리는지를 아는 것입니다. 신뢰도가 임계선을 넘느냐, 오픈웨이트가 프런티어를 대체하느냐, 전력이 캐펙스를 따라오느냐. 이 세 지표가 향후 몇 분기의 관전 포인트입니다.

정리

빅테크의 GPU 과투자는 거품일 수도, 합리적 보험일 수도 있습니다. 그러나 이를 “비대칭 보상 구조에 대한 합리적 반응 + 다음 세대 톨게이트 선점 경쟁”으로 읽으면, 단순한 광기보다 훨씬 정교한 구조적 강제가 보입니다. 그리고 그 경쟁의 반대편에는, 톨게이트에 종속되기를 원치 않는 엔터프라이즈 수요가 형성되고 있습니다. ThakiCloud는 그 자리를 위해 만들어진 인프라입니다.

관련 슬라이드

본문 내용을 NotebookLM(blue_collage 스타일)으로 요약한 슬라이드입니다.

출처

• 원 분석 스레드: @Tesla_Teslaway (X)
• 태스크 호라이즌: METR, “Measuring AI Ability to Complete Long Tasks” (2025). 50% 신뢰도 작업 길이가 2019년부터 2025년까지 약 7개월마다 두 배, 2024~2025년 구간은 약 4개월로 가속
• 2026 하이퍼스케일러 캐펙스 약 7,250억 달러(+77% YoY), 지출의 60% 이상이 전력·데이터센터: Tom’s Hardware, CNBC