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

نحن في ThakiCloud نتعامل مع خدمة النماذج عبر منصة AI/ML SaaS المبنية على K8s. لذا نقرأ هذا التحول من زاوية اقتصاديات self-hosting لا من قائمة النماذج. حين يرتقي مفتوح الأوزان إلى مستوى الحدود الأمامية، لا يعود self-hosting مثالية رومانسية، بل يصير مسألة حساب تكلفة. في هذا المقال نستعرض أبرز النماذج مفتوحة الأوزان في منتصف 2026 لتحديد أين تتشكل نقطة التعادل في التكلفة، وكيف تجعل K8s هذا القرار قابلا للتشغيل.

الفجوة لا تتسع: مشهد النماذج مفتوحة الأوزان في منتصف 2026

نبدأ بالحقائق. النماذج الأربعة أدناه مستخلصة من مصادر مستقلة متعددة (Artificial Analysis، بطاقات نماذج Hugging Face، إعلانات المختبرات)، ولم نعتمد على مرجع معياري واحد.

تبرز عدة نقاط. GLM-5.2 حقق 51 نقطة في مؤشر Artificial Analysis الذكائي ليتصدر قائمة النماذج مفتوحة الأوزان، ويحتل موقعا بين المراتب العليا حتى عند إدراج النماذج المغلقة. ما يلفت الانتباه أن النماذج المغلقة الأعلى مرتبة (Fable 5 وOpus 4.8 وGPT-5.5) لا تزال تتصدر القائمة. بمعنى أن القول بأن “مفتوح الأوزان تجاوز الحدود الأمامية” مبالغة لا تصح. العبارة الدقيقة هي أن الحدود الأمامية لم تستطع الفرار، أي أن المُطارِد اقترب كفاية دون أن يكون المُطارَد قد توقف.

DeepSeek V4 Flash يُعدّ أول نموذج مفتوح الأوزان يصلح للتضمين المباشر في أنابيب عوامل البرمجة. SWE-bench Verified 79.0% يقل عن النسخة Pro من نفس العائلة بفارق 1.6 نقطة فحسب، فيما يبلغ سعره نحو 0.14 دولار إدخالا و0.28 دولار إخراجا لكل مليون رمز. MiniMax M3 هو النموذج الوحيد في هذه المجموعة الذي يوفر دعما أصيلا متعدد الوسائط (صورة وفيديو)، مما يمنحه ميزة في أحمال عمل مثل أتمتة واجهة المستخدم وتحويل لقطات الشاشة إلى كود. Nemotron 3 Ultra هو النموذج الأمريكي المفتوح الذي أعلنت عنه NVIDIA في Computex 2026، ويتميز بمعدل أكثر من 300 tok/s ورخصة صديقة للمؤسسات.

ملاحظة ضرورية: تضمّن المصدر الأصلي لـ OpenRouter ادعاءا جيوسياسيا مفاده أن GLM-5.2 برز بسبب تعطّل بعض النماذج المغلقة جراء قيود تصدير أمريكية. غير أن تصنيفات المعايير المستقلة المتاحة للعموم في الفترة ذاتها تُظهر تلك النماذج في المراتب العليا، مما يجعل هذه العلاقة السببية غير مؤكدة. لذا نكتفي في هذا المقال بالحقائق الموثقة المتعلقة بالنماذج والأداء والتسعير، ونتجنب تفسيرات الأسباب والنتائج غير المثبتة.

إعادة حساب التكلفة: ليست سعر الرمز، بل التكلفة الإجمالية للتشغيل

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

ثمة ثلاثة أنماط تكلفة ينبغي التمييز بينها.

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

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

ثالثا، مفتوح الأوزان مع self-hosting. يُنزَّل الأوزان ويُشغَّل على معدات GPU الخاصة بالمؤسسة أو على بنيتها التحتية الداخلية. يتحول هيكل التكلفة من متغير إلى ثابت (إهلاك GPU + تشغيل). الجوهر هنا نقطة التعادل: حين يكفل معدل المعالجة المستمر قسمة التكلفة الثابتة على عدد كافٍ من الرموز، يصبح سعر الرمز الفعلي أدنى من أي خيار API. وعدم خروج البيانات خارج الحدود يُعدّ، في البيئات ذات المتطلبات التنظيمية والسيادية، شرطا أساسيا لا عاملا تكلفة.

flowchart TD
    A["워크로드 정의<br/>(처리량·지연·데이터 민감도)"] --> B{"지속적 고처리량인가?"}
    B -->|"아니오 (스파이크·소량)"| C["프로프라이어터리 API<br/>또는 서드파티 호스팅"]
    B -->|"예"| D{"데이터 주권·규제 요구가 있나?"}
    D -->|"예"| E["오픈웨이트 self-hosting<br/>(온프레미스/사설 클러스터)"]
    D -->|"아니오"| F{"실효 토큰 단가 손익분기를 넘기나?"}
    F -->|"넘김"| E
    F -->|"못 넘김"| C
    E --> G["K8s GPU 서빙 운영<br/>(스케줄링·멀티테넌시·관측)"]
    C --> H["가변비용 모니터링"]

أكثر الأخطاء شيوعا في هذا المسار القراري هو الحكم على المرحلتين الثانية والثالثة بسطر واحد من جدول أسعار الرموز. التكلفة الحقيقية لـ self-hosting ليست في الأوزان (متاحة مجانا)، بل في توفير GPU وحزمة الخدمة والجدولة والمراقبة وكوادر التشغيل. لذا فإن عبارة “مفتوح الأوزان مجاني” صحيحة إلى النصف فحسب: النموذج مجاني، أما التشغيل فليس كذلك. مدى كفاءة هذا التشغيل وثباته هو ما تدور حوله اقتصاديات self-hosting في جوهرها.

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

اقتصاديات self-hosting للنماذج مفتوحة الأوزان هي بالضبط المسألة التي تعالجها ThakiCloud بمنتجين اثنين.

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

منظور Paxis (اقتصادية العوامل). الخدمة منخفضة التكلفة لا تنتهي عند ذاتها، بل تُوجد اقتصادية عوامل. حين يتاح الأداء الحدودي في البرمجة كـ DeepSeek V4 Flash بعشرات السنتات لكل مليون رمز، تصبح تكلفة الرموز في سير عمل العوامل متعددة الخطوات قابلة للاحتمال. Paxis من ThakiCloud هو مستوى تحكم Agent-Native Cloud يعمل فوق ai-platform، يختار من أكثر من 960 مهارة عبر BM25 وينفذها في بيئات معزولة، مع تمرير كل إجراء عبر بوابات سياسية وسجلات تدقيق. حين تخفض الخدمة الرخيصة من ai-platform تكلفة استدعاء العوامل، يتسع هامش تصميم تنسيق العوامل متعددة المراحل في نفس الميزانية. بمعنى أن اقتصاديات self-hosting لا تنحصر في توفير البنية التحتية، بل تُوسّع هامش التصميم لطبقة العوامل التي تعمل فوقها مباشرة.

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

دعونا نُفنّد تفاؤل هذا المقال من الداخل.

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

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

ثالثا، الرخصة والمصدر يستحقان التدقيق. “مفتوح الأوزان” ليس مصطلحا متجانسا. MIT (DeepSeek وGLM) والرخصة المجتمعية (MiniMax) وOpenMDW (Nemotron) تختلف في حقوق إعادة التوزيع التجاري والضبط الدقيق. كذلك قد يُحدّد بلد منشأ النموذج وسياسات بياناته مدى إمكانية اعتماده في ظل بيئات تنظيمية بعينها.

رابعا، مشهد النماذج يتقادم بسرعة. الجدول أعلاه لقطة من منتصف 2026 وقابل للتغيير خلال أشهر. لذا فإن الجوهر ليس في أسماء النماذج، بل في المبدأ الثابت: ما إن تبلغ النماذج مفتوحة الأوزان مستوى الحدود الأمامية، كلما كانت متطلبات التكلفة والسيادة لحِمل العمل أكبر، كلما صارت نقطة التعادل في self-hosting أكثر ملاءمة. النماذج تتغير، لكن هذا الاتجاه لن يتغير.

المصادر

• The Open Weight Models that Matter: June 2026 · OpenRouter Blog
• GLM-5.2 is the new leading open weights model on the Artificial Analysis Intelligence Index
• NVIDIA Nemotron 3 Ultra released · Artificial Analysis
• DeepSeek V4 Flash · OpenRouter
• GLM-5.2 is probably the most powerful text-only open weights LLM · Simon Willison

The mid-2026 open-weight landscape can be summarized in a single sentence: the gap has narrowed, and it is no longer widening. OpenRouter’s June roundup finds that open-weight models maintain roughly a 3-to-6-month capability lag behind frontier labs, yet that interval is not growing. If that assessment holds, the real organizational decision is no longer “which model is the most capable?” It is “where should this workload run, and at what cost?”

At ThakiCloud we operate model serving on top of a Kubernetes-based AI/ML SaaS platform, so we read this shift through the lens of self-hosting economics rather than through a model catalog. Once open-weight quality reaches frontier-grade for a given task, self-hosting stops being an ideological choice and becomes a cost calculation. This post uses the leading open-weight models of mid-2026 to examine where the break-even point forms, and how to make that decision operationally viable on Kubernetes.

The Gap Is No Longer Widening: The Mid-2026 Open-Weight Landscape

The facts first. The four models below are cross-validated across multiple independent sources, including Artificial Analysis, Hugging Face model cards, and each lab’s own announcements. We did not rely on a single benchmark.

Several observations stand out. GLM-5.2 scores 51 on the Artificial Analysis Intelligence Index, placing it first among open-weight models and in the top tier overall including closed models. Notably, the top closed models, Fable 5, Opus 4.8, and GPT-5.5, still occupy the very top positions in the same ranking. This means the claim that “open-weight has surpassed the frontier” is an overstatement. The more precise formulation is that the frontier has stopped pulling away. The gap closed not because the leader stopped, but because the challengers got close enough.

DeepSeek V4 Flash is regarded as the first open-weight model ready to drop directly into coding-agent pipelines. Its SWE-bench Verified score of 79.0% sits just 1.6 points below the Pro variant in the same family, while pricing comes in at approximately $0.14 per million input tokens and $0.28 per million output tokens. MiniMax M3 is the only model in this group with native multimodal capability (images and video), giving it an edge on workloads such as UI automation and screenshot-to-code. Nemotron 3 Ultra is NVIDIA’s US-built open model unveiled at Computex 2026, offering throughput exceeding 300 tok/s alongside an enterprise-friendly license.

One caveat is worth flagging. The OpenRouter source piece includes geopolitical commentary suggesting that US export controls deactivated certain closed models, creating an opening that helped GLM-5.2 rise. However, public benchmark rankings at the same point in time still show those closed models at the top. The causal claim has not been independently verified. This post therefore cites only the verifiable model, performance, and pricing facts, and does not engage with speculative causal interpretations.

Recalculating Cost: Total Operating Cost, Not Cost per Token

When open-weight quality reaches frontier grade, the framing of cost conversations changes. The old question was “how much performance do we sacrifice in exchange for lower spend?” The new question is “where is the cheapest place to obtain the same intelligence?” And that question cannot be answered by reading a per-token pricing table alone.

Three cost modes need to be distinguished.

First, proprietary APIs. These carry no operational burden and provide immediate access to top-tier performance, but the cost is variable and scales linearly with usage, and data leaves your boundary. This model suits low-volume or bursty workloads, or cases where state-of-the-art performance is a hard requirement.

Second, open-weight models with third-party hosting. The weights are public, but inference runs on an external provider’s infrastructure. Per-token prices are substantially lower than closed alternatives, which is the primary point the open-weight roundup emphasizes. However, billing is still usage-based and data governance depends on the provider.

Third, open-weight models with self-hosting. You pull the weights and serve them on your own (or on-premises) GPUs. The cost structure shifts from variable to fixed (GPU amortization plus operations). The critical variable is the break-even point. Once sustained throughput is high enough, dividing the fixed cost by the token volume yields an effective per-token cost that undercuts any API price point. For organizations with regulatory or data-sovereignty requirements, keeping data inside the boundary is not a cost trade-off but a precondition.

flowchart TD
    A["워크로드 정의<br/>(처리량·지연·데이터 민감도)"] --> B{"지속적 고처리량인가?"}
    B -->|"아니오 (스파이크·소량)"| C["프로프라이어터리 API<br/>또는 서드파티 호스팅"]
    B -->|"예"| D{"데이터 주권·규제 요구가 있나?"}
    D -->|"예"| E["오픈웨이트 self-hosting<br/>(온프레미스/사설 클러스터)"]
    D -->|"아니오"| F{"실효 토큰 단가 손익분기를 넘기나?"}
    F -->|"넘김"| E
    F -->|"못 넘김"| C
    E --> G["K8s GPU 서빙 운영<br/>(스케줄링·멀티테넌시·관측)"]
    C --> H["가변비용 모니터링"]

The most common mistake in this decision flow is collapsing stages two and three into a single line from a pricing table. The real cost of self-hosting is not the weight download fee (which is zero for open-weight models). It is GPU procurement, the serving stack, scheduling, observability, and operational staff. “Open-weight is free” is therefore only half true. The model is free, but the operations are not. How cheaply and reliably you can run those operations is the actual substance of self-hosting economics.

Product Implications for ThakiCloud

The self-hosting economics of open-weight models are precisely the problem ThakiCloud addresses with two products.

Through the ai-platform lens (infrastructure and serving). ThakiCloud’s ai-platform manages model serving on Kubernetes. What actually lowers the break-even threshold in practice is infrastructure efficiency. Kueue-based GPU job scheduling reduces idle time on expensive accelerators, while high-throughput serving engines such as vLLM combined with quantization techniques (FP8, NVFP4, and similar) extract more tokens per second from the same hardware. When effective per-token cost drops, the break-even in the decision flow above becomes achievable at lower sustained throughput. A multi-tenant architecture lets multiple workloads share a GPU pool, spreading fixed costs across teams. On-premises and sovereign deployment satisfies data-sovereignty requirements without a cost penalty, which matters particularly in environments with strict domestic compliance or security mandates. In short, ai-platform productizes the rightmost stage of the diagram above: Kubernetes GPU serving operations.

Through the Paxis lens (agent economics). Low-cost serving does not stop at infrastructure savings; it unlocks agent economics. When frontier-grade coding performance becomes available for a few cents per million tokens (as with DeepSeek V4 Flash), the token consumption of multi-step agentic workflows finally becomes affordable. ThakiCloud’s Paxis is an Agent-Native Cloud control plane running on top of ai-platform. It selects from over 960 skills using BM25 retrieval, executes them in isolated sandboxes, and routes every action through policy gates and audit logs. Cheaper serving (ai-platform) lowers the per-call cost of agent invocations, which means the same budget can support deeper DAG-style multi-agent orchestration. Self-hosting economics, in other words, do not just reduce infrastructure spend; they directly expand the design space available to the agent layer running on top.

Limitations and Counterarguments

The following pushes back against the optimism in this post.

First, self-hosting is not always cheaper. The break-even analysis assumes sustained, high throughput. For low-volume or irregular traffic, fixed costs cannot be recovered and the API is the cheaper option. Any comparison that omits GPU amortization, power, cooling, and staff makes self-hosting look less expensive than it is.

Second, benchmark figures carry uncertainty intervals. The Artificial Analysis Intelligence Index scores and SWE-bench results cited here are measurements from specific evaluation environments and do not map exactly to real-world workload performance. Independent replication of newly released model benchmarks may be limited in the early weeks after an announcement, so direct evaluation on your own workloads before deployment is necessary.

Third, licenses and provenance must be verified. “Open-weight” is not a uniform category. MIT (DeepSeek, GLM), community license (MiniMax), and OpenMDW (Nemotron) carry different rights for commercial redistribution and fine-tuning. The country of origin of a model and its data policy can also determine whether adoption is permissible under a given regulatory environment.

Fourth, the model landscape ages quickly. The table above is a snapshot from mid-2026 and will be outdated within months. The underlying principle, however, does not change with the names. Now that open-weight models have reached frontier-grade quality, the self-hosting break-even becomes increasingly favorable for workloads with high cost pressure or strong data-sovereignty requirements. Models change; this direction does not.

Sources

• The Open Weight Models that Matter: June 2026 - OpenRouter Blog
• GLM-5.2 is the new leading open weights model on the Artificial Analysis Intelligence Index
• NVIDIA Nemotron 3 Ultra released - Artificial Analysis
• DeepSeek V4 Flash - OpenRouter
• GLM-5.2 is probably the most powerful text-only open weights LLM - Simon Willison

2026년 중반의 오픈웨이트 모델 지형을 한 문장으로 요약하면 이렇습니다. 격차는 좁혀졌고, 더 벌어지지 않고 있습니다. OpenRouter가 6월에 정리한 라운드업은 오픈웨이트 모델이 프런티어 랩과 3~6개월 정도의 능력 격차를 유지하면서도 그 간격이 확대되지 않는다고 봅니다. 이 명제가 맞다면, 조직이 내려야 할 진짜 결정은 더 이상 “어떤 모델이 가장 똑똑한가”가 아닙니다. “이 워크로드를 어디서, 어떤 비용으로 돌릴 것인가”입니다.

저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 모델 서빙을 다룹니다. 그래서 이 변화를 모델 카탈로그가 아니라 self-hosting 경제학의 관점에서 읽습니다. 오픈웨이트가 프런티어급으로 올라온 순간, self-hosting은 이상주의가 아니라 비용 계산의 문제가 됩니다. 이 글에서는 2026년 중반의 대표 오픈웨이트 모델을 근거로 그 손익분기가 어디쯤 형성되는지, 그리고 그 결정을 K8s 위에서 어떻게 운영 가능하게 만드는지를 짚어보겠습니다.

격차는 더 벌어지지 않는다: 2026년 중반 오픈웨이트 지형

먼저 사실관계입니다. 아래 네 모델은 여러 독립 출처(Artificial Analysis, Hugging Face 모델 카드, 각 랩의 발표)로 교차검증한 수치이며, 단일 벤치 한 곳에만 의존하지 않았습니다.

몇 가지가 눈에 띕니다. GLM-5.2는 Artificial Analysis 지능지수에서 51점으로 오픈웨이트 1위에 올랐고, 폐쇄형까지 포함해도 상위권에 자리합니다. 흥미로운 점은 같은 랭킹에서 상위 폐쇄형 모델(Fable 5, Opus 4.8, GPT-5.5)이 여전히 정상에 있다는 사실입니다. 즉 “오픈웨이트가 프런티어를 추월했다”는 과장은 정확하지 않습니다. 정확한 표현은 “프런티어가 도망가지 못하고 있다”입니다. 따라잡힌 쪽이 멈춘 게 아니라, 추격하는 쪽이 충분히 가까워졌다는 뜻입니다.

DeepSeek V4 Flash는 코딩 에이전트 파이프라인에 곧바로 투입할 만한 첫 오픈웨이트로 평가받습니다. SWE-bench Verified 79.0%는 같은 계열 Pro 변형과 1.6점 차이에 불과하면서, 가격은 백만 토큰당 입력 $0.14 / 출력 $0.28 수준입니다. MiniMax M3는 이 묶음에서 유일하게 네이티브 멀티모달(이미지·비디오)을 제공해 UI 자동화나 스크린샷-투-코드 같은 워크로드에 강점이 있습니다. Nemotron 3 Ultra는 NVIDIA가 Computex 2026에서 공개한 미국産 오픈모델로, 300 tok/s를 넘는 처리량과 엔터프라이즈 친화적 라이선스를 내세웁니다.

여기서 한 가지 단서를 답니다. OpenRouter 원문에는 “미국 수출통제로 특정 폐쇄형 모델이 비활성화되어 그 빈자리에서 GLM-5.2가 부상했다”는 지정학적 서술이 포함되어 있습니다. 그러나 같은 시점의 공개 벤치마크 랭킹에는 해당 폐쇄형 모델들이 여전히 정상에 올라 있어, 이 인과 주장은 교차검증되지 않습니다. 따라서 이 글에서는 검증된 모델·성능·가격 사실만 인용하고, 추측성 인과 해석은 다루지 않습니다.

비용의 재계산: 토큰당 단가가 아니라 운영 총비용

오픈웨이트가 프런티어급으로 올라오면 비용 논의의 축이 바뀝니다. 과거에는 “성능을 어디까지 포기하고 비용을 아낄 것인가”였다면, 지금은 “같은 지능을 가장 싸게 어디서 얻을 것인가”입니다. 그리고 이 질문의 답은 토큰당 단가표만으로는 나오지 않습니다.

세 가지 비용 모드를 구분해야 합니다.

첫째, 프로프라이어터리 API입니다. 운영 부담이 없고 즉시 최고 성능에 접근하지만, 사용량에 정비례하는 가변비용이며 데이터가 외부로 나갑니다. 트래픽이 적거나 스파이크성이거나, 최상위 성능이 반드시 필요한 워크로드에 합리적입니다.

둘째, 오픈웨이트 + 서드파티 호스팅입니다. 가중치는 공개되어 있되 실행은 외부 추론 제공자에 맡깁니다. 토큰 단가는 폐쇄형보다 크게 낮지만(오픈웨이트 라운드업이 강조하는 지점), 여전히 사용량 기반 과금이고 데이터 거버넌스는 제공자에 의존합니다.

셋째, 오픈웨이트 + self-hosting입니다. 가중치를 직접 받아 자사(또는 온프레미스) GPU에서 서빙합니다. 비용 구조가 가변에서 고정비(GPU 상각 + 운영)로 바뀝니다. 핵심은 손익분기입니다. 일정 수준 이상의 지속적 처리량이 나오면, 고정비를 토큰 수로 나눈 실효 단가가 어떤 API 단가보다도 낮아지는 구간이 생깁니다. 데이터가 경계 밖으로 나가지 않는다는 점은 규제·주권 요구가 있는 조직에는 비용이 아니라 전제 조건입니다.

flowchart TD
    A["워크로드 정의<br/>(처리량·지연·데이터 민감도)"] --> B{"지속적 고처리량인가?"}
    B -->|"아니오 (스파이크·소량)"| C["프로프라이어터리 API<br/>또는 서드파티 호스팅"]
    B -->|"예"| D{"데이터 주권·규제 요구가 있나?"}
    D -->|"예"| E["오픈웨이트 self-hosting<br/>(온프레미스/사설 클러스터)"]
    D -->|"아니오"| F{"실효 토큰 단가 손익분기를 넘기나?"}
    F -->|"넘김"| E
    F -->|"못 넘김"| C
    E --> G["K8s GPU 서빙 운영<br/>(스케줄링·멀티테넌시·관측)"]
    C --> H["가변비용 모니터링"]

이 결정 흐름에서 가장 자주 빠지는 함정은 2단계와 3단계를 토큰 단가표 한 줄로 판단하는 것입니다. self-hosting의 진짜 비용은 가중치 가격(공개라 0원)이 아니라 GPU 확보·서빙 스택·스케줄링·관측·운영 인력입니다. 그래서 “오픈웨이트는 공짜”라는 문장은 절반만 맞습니다. 모델은 공짜지만 운영은 공짜가 아닙니다. 이 운영을 얼마나 싸고 안정적으로 만드느냐가 self-hosting 경제학의 본체입니다.

ThakiCloud 제품 적용 시사점

오픈웨이트의 self-hosting 경제학은 ThakiCloud가 두 제품으로 정면으로 다루는 문제입니다.

ai-platform 렌즈 (인프라·서빙). ThakiCloud의 ai-platform은 K8s 기반에서 모델 서빙을 운영합니다. self-hosting의 손익분기를 실제로 당기는 것은 결국 인프라 효율입니다. Kueue 기반 GPU 잡 스케줄링으로 값비싼 가속기의 유휴를 줄이고, vLLM 같은 고처리량 서빙 엔진과 양자화(예: FP8, NVFP4)로 같은 하드웨어에서 더 많은 토큰을 뽑아내면, 위 결정 흐름의 “실효 토큰 단가 손익분기”가 더 낮은 처리량에서도 충족됩니다. 멀티테넌트 구조는 여러 워크로드가 GPU 풀을 공유하게 해 고정비를 분산시킵니다. 온프레미스·소버린 배포는 데이터 주권 요구를 비용 페널티 없이 충족하는 경로이며, 이는 국내 규제·보안 요건이 강한 환경에서 특히 중요합니다. 요컨대 ai-platform은 위 다이어그램의 가장 오른쪽 단계, K8s GPU 서빙 운영을 상품화한 것입니다.

Paxis 렌즈 (에이전트 경제성). 저비용 서빙은 그 자체로 끝나지 않고 에이전트 경제성을 만듭니다. DeepSeek V4 Flash처럼 프런티어급 코딩 성능을 백만 토큰당 수십 센트에 얻을 수 있게 되면, 다단계 에이전트 워크플로의 토큰 소비가 비로소 감당 가능해집니다. ThakiCloud의 Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 960개 이상의 스킬을 BM25로 선택해 격리된 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시킵니다. 싼 서빙(ai-platform)이 에이전트 호출의 단가를 낮추면, 같은 예산으로 더 깊은 DAG 멀티에이전트 오케스트레이션이 가능해집니다. 즉 self-hosting 경제학은 인프라 절감에 그치지 않고, 그 위에서 도는 에이전트 계층의 설계 자유도를 직접 넓힙니다.

한계 및 반론

이 글의 낙관을 스스로 반박해 보겠습니다.

첫째, self-hosting이 항상 더 싸지는 않습니다. 손익분기는 지속적 고처리량을 전제로 합니다. 트래픽이 적거나 불규칙하면 고정비를 회수하지 못해 API가 더 쌉니다. GPU 상각·전력·냉각·운영 인력을 빠뜨린 비교는 self-hosting을 실제보다 싸게 보이게 합니다.

둘째, 벤치마크 수치는 신뢰 구간을 가집니다. 여기 인용한 AA 지능지수나 SWE-bench 점수는 특정 평가 환경의 측정값이며, 실제 워크로드 성능과 정확히 일치하지 않습니다. 일부 신규 모델의 벤치는 발표 초기에 독립 재현이 충분치 않을 수 있어, 도입 전 자사 워크로드로 직접 평가하는 절차가 필요합니다.

셋째, 라이선스와 출처를 확인해야 합니다. “오픈웨이트”는 동질적이지 않습니다. MIT(DeepSeek, GLM)와 커뮤니티 라이선스(MiniMax), OpenMDW(Nemotron)는 상업적 재배포·파인튜닝 권리가 다릅니다. 모델 출처 국가와 데이터 정책도 규제 환경에 따라 도입 가능 여부를 가릅니다.

넷째, 모델 지형은 빠르게 늙습니다. 위 표는 2026년 중반의 스냅샷이며 몇 달이면 갱신됩니다. 그래서 핵심은 특정 모델 이름이 아니라 변하지 않는 원리입니다. 오픈웨이트가 프런티어급에 도달한 이상, 비용·주권 요구가 큰 워크로드일수록 self-hosting의 손익분기는 계속 유리해집니다. 모델은 바뀌어도 이 방향은 바뀌지 않습니다.

출처

• The Open Weight Models that Matter: June 2026 · OpenRouter Blog
• GLM-5.2 is the new leading open weights model on the Artificial Analysis Intelligence Index
• NVIDIA Nemotron 3 Ultra released · Artificial Analysis
• DeepSeek V4 Flash · OpenRouter
• GLM-5.2 is probably the most powerful text-only open weights LLM · Simon Willison

نظرة عامة

تقديم نموذج 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