لا تُجيب هذه المقالة بـ”نعم إنها فقاعة” أو “لا ليست كذلك”. بدلًا من ذلك، تتناول المنطقَين الهيكليَّين اللذين يُحرِّكان إنفاق عمالقة التقنية، وما يعنيانه لشركات البنية التحتية كشركتنا وللعملاء من قطاع المؤسسات. نقطة الانطلاق كانت تحليلًا دار في منصة 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

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

이 글은 그 의문에 “거품이다 / 아니다”로 답하지 않습니다. 대신 빅테크의 지출을 움직이는 구조적 논리 두 가지를 짚고, 그것이 우리 같은 인프라 사업자와 엔터프라이즈 고객에게 무엇을 의미하는지 정리합니다. 출발점은 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는 그 자리를 위해 만들어진 인프라입니다.

출처

• 원 분석 스레드: @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

이 글은 그 데이터를 검증하고, 헤드라인 한 줄로는 놓치기 쉬운 두 번째 층위를 짚은 뒤, 그것이 ThakiCloud와 Paxis 전략에 무엇을 의미하는지 정리합니다.

무슨 일이 일어났나

숫자부터 정리하겠습니다. 2025년 중반 약 70%였던 미국 모델(OpenAI·Anthropic·Google) 토큰 점유율은 2026년 중반 약 30%로 떨어졌습니다. 같은 기간 중국계 모델(DeepSeek·Qwen·MiniMax·Moonshot·Tencent 등)은 1년 전 2% 미만에서 약 46%까지 올라왔습니다. 변곡점은 2026년 2월 9일부터 15일 사이의 한 주였습니다. 이 주에 중국 모델이 처리한 토큰이 4.12조 개로, 미국 모델의 2.94조 개를 처음으로 앞질렀습니다.

수치는 매체마다 소수점이 갈립니다. 이 흐름을 널리 알린 한 분석가는 미국 72%에서 33%, 중국 47%로 집계했습니다. 반면 미식별 트래픽을 분리한 정밀 집계에서는 중국 약 46%, 미국 약 36%로 나옵니다. 어느 쪽이든 방향은 같고, “미국 33% 대 중국 47%”처럼 둘을 정면으로 빼서 비교하면 미식별 버킷이 가려진다는 점만 유의하면 됩니다.

왜 이렇게 빨랐나

이 변화의 동력은 중국 주요 랩의 급격한 오픈웨이트 전환입니다. DeepSeek은 R1과 V3를 사실상 무료로 공개하며 추론 품질에서 상위 모델에 근접했고, Alibaba의 Qwen 시리즈는 다국어와 코딩 태스크에서 두드러진 성과를 냈습니다. 두 계열 모두 MIT 또는 Apache 라이선스라 상업적 활용이 자유롭다는 점이 개발자 채택을 끌어올렸습니다. Qwen은 Hugging Face 다운로드에서 Llama를 제치고 가장 많이 받는 오픈 모델이 됐습니다.

엔비디아 반도체 수출 규제(H100·H200·B200의 대중국 제한)가 역설적으로 작용했다는 분석도 있습니다. 컴퓨팅이 부족하니 같은 성능을 더 적은 자원으로 뽑아내는 효율화 인센티브가 생겼다는 것입니다. 여기에 OpenRouter 사용자 상당수가 비용에 민감한 스타트업과 개인 개발자라는 점을 더하면, 가격과 라이선스가 유리한 쪽으로 쏠리는 흐름은 구조적입니다.

그런데 토큰은 매출이 아닙니다

헤드라인만 보면 “중국이 미국을 이겼다”가 됩니다. 한 겹 들어가면 다른 그림이 보입니다. 같은 OpenRouter에서 Anthropic은 토큰 점유율이 약 12%인데 매출의 약 46%를 가져간다는 분석이 있습니다. 시장이 둘로 갈라지고 있다는 신호입니다.

한쪽은 가장 싼 모델이 이기는 커머디티 시장입니다. 대량의 토큰이 오가지만 마진은 박합니다. 다른 쪽은 코딩이나 자율 에이전트처럼 실패 비용이 큰 고부가 작업에서 비싸도 잘하는 모델이 매출을 가져가는 시장입니다. 토큰 점유율은 앞의 시장을 비추고, 매출 점유율은 뒤의 시장을 비춥니다. 둘은 같은 지표가 아닙니다.

여기에 하나를 더 보태야 합니다. OpenRouter 사용자층은 비용에 민감한 개발자에 치우쳐 있어 전체 엔터프라이즈 시장을 대표하지 않습니다. 점유율 역전을 곧바로 “미국 패배”로 읽으면, 이 두 가지를 빼놓고 과한 결론으로 건너뛰게 됩니다. 진짜 사건은 승패가 아니라 시장이 토큰과 매출로 분리되고 있다는 재편입니다.

ThakiCloud와 Paxis 관점

이 분리야말로 ThakiCloud와 Paxis 전략에 유리한 지점입니다. 두 가지로 나눠 정리하겠습니다.

첫째, 모델 중립입니다. 시장이 커머디티와 고부가로 갈라지고 모델 순위가 분기마다 뒤집히는 환경에서 가장 탄력적인 구조는 특정 벤더에 묶이지 않는 것입니다. Paxis는 고객이 OpenRouter처럼 비용과 성능의 트레이드오프를 직접 고르게 하는 모델 중립 라우팅을 지향합니다. 중국 오픈모델의 부상은 위협이 아니라 이 전략에 힘을 싣는 흐름입니다. 어느 모델이 위로 올라오든 그것을 1급 시민으로 얹을 수 있으면 시장 변동이 곧 기회가 됩니다.

둘째, 컴플라이언스 레이어입니다. 엔터프라이즈가 비용 때문에 DeepSeek나 Qwen 계열을 쓰기 시작하면, 곧바로 따라오는 질문이 상업 라이선스 조건과 데이터 거버넌스입니다. ThakiCloud의 Keycloak 기반 멀티테넌시와 ArgoCD GitOps 파이프라인은 다양한 모델을 얹기에 기술적으로 친화적입니다. 다만 솔직히 말하면, 모델별 상업 라이선스와 고객별 데이터 컴플라이언스를 자동으로 검증하는 레이어는 아직 갖춰야 할 숙제입니다. 이것은 공백이자 동시에 가장 분명한 기회입니다. 중국 오픈모델을 1급 시민으로 지원하는 추론 파이프라인과 라이선스·데이터 검증 레이어를 함께 제공하는 쪽이 규제 산업 고객을 잡습니다.

이 논리가 약해지는 경우

균형을 위해 반대 시나리오도 적어 둡니다. 첫째, 엔터프라이즈의 구매 결정은 개발자 실사용과 다르게 움직일 수 있습니다. 토큰 점유율 곡선이 그대로 엔터프라이즈 채택으로 이어진다는 보장은 없습니다. 둘째, 중국 모델의 데이터 리스크가 금융이나 공공처럼 규제가 강한 산업의 채택을 가로막으면, 점유율 곡선은 산업별로 다시 갈릴 수 있습니다. 셋째, 측정의 미식별 버킷이 커서 정밀 수치는 매체마다 흔들립니다.

지켜볼 지표는 셋입니다. 매출 점유율 곡선이 토큰 점유율과 같은 방향으로 가는지, 규제 산업에서 중국 모델 채택률이 실제로 오르는지, OpenRouter 바깥의 엔터프라이즈 게이트웨이에서도 같은 추세가 보이는지입니다.

정리

OpenRouter의 점유율 역전은 진짜입니다. 그러나 그것이 곧 “미국 패배”는 아닙니다. 토큰과 매출이 갈라지는 시장 재편의 한 단면입니다. 어느 모델이 위로 올라오든 거기에 종속되지 않는 쪽, 그리고 그 모델을 합법적이고 안전하게 얹는 검증 레이어를 가진 쪽이 이깁니다. ThakiCloud와 Paxis가 겨냥하는 자리가 바로 거기입니다.

함께 읽기: 빅테크 GPU 과투자의 진짜 논리: 비대칭 보험과 다음 세대 톨게이트

출처

• 원 분석: @FurkanGozukara (X)
• OpenRouter 점유율 데이터: officechai, cryptobriefing, Data Gravity, stockalarm
• 토큰 점유율과 매출 점유율의 분리: Normal Guy (X)
• 중국 모델 데이터 리스크: TechTimes

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

في يونيو 2026، شارك الرئيس التنفيذي لـ Coinbase بريان أرمسترونغ حلّ شركته المختلف. بعبارته، إنه «كيف تبقي الإنفاق على الذكاء الاصطناعي ثابتاً بينما ينمو استخدام الرموز أسياً»، والخلاصة واضحة: حُلّها بإعدادات افتراضية أفضل وتوجيه وتخزين مؤقت، لا بالاحتكاك وتنبيهات الإنفاق. تقول Coinbase إنها خفّضت الإنفاق على الذكاء الاصطناعي إلى النصف تقريباً بينما انفجر استخدام الرموز.

تشغّل ThakiCloud منصة ai-platform التي تخدم النماذج عبر بيئات عملاء متنوعة، لذا فإن كيفية التحكم في كلفة الاستدلال ليست قصة الآخرين. استراتيجية Coinbase سياسة داخلية لشركة واحدة، لكن في داخلها مبادئ LLMOps تنطبق على كل من يشغّل بنية خدمة النماذج. يعرض هذا المقال تلك الاستراتيجية كما هي، ويحلل ما تعنيه من منظور منصة الخدمة.

الجوهر: الإعدادات الافتراضية لا الاحتكاك

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

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

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

flowchart TB
    A[엔지니어 요청<br/>모델 미지정] --> B[LLM 게이트웨이]
    B --> C{기본값 정책}
    C -->|기존| D[비싼 프런티어 모델<br/>높은 토큰 단가]
    C -->|변경 후| E[오픈웨이트 기본값<br/>GLM 5.2 / Kimi 2.7]
    E --> F[작업 난이도 라우팅]
    F -->|단순 반복| G[저렴한 모델]
    F -->|고난도| H[프런티어 모델<br/>명시 선택]
    B --> I[캐시 조회]
    I -->|히트| J[캐시 응답<br/>토큰 0]
    I -->|미스| F
    G --> K[지출 평탄화]
    H --> K
    J --> K

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

ثلاث تقنيات

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

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

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

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

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

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

استراتيجية Coinbase قصة شركة واحدة لها بوابة LLM داخلية، لكن مبادئها تتداخل تماماً مع عرض القيمة لخدمة النماذج متعددة المستأجرين التي تقدّمها منصة ai-platform من ThakiCloud. تخدم ai-platform النماذج بـ vLLM وأمثاله فوق جدولة موارد GPU القائمة على Kubernetes وKueue، وما فعلته Coinbase عند بوابة واحدة يمكننا تقديمه بعمق أكبر على مستوى منصة الخدمة.

أولاً، التوجيه كميزة منصة. وزّعت Coinbase المهام على النماذج عند البوابة. ولأن ai-platform من ThakiCloud تخدم نماذج كثيرة في آن واحد في بيئة متعددة المستأجرين، يمكنها ضبط سياسات التوجيه على مستوى البنية لكل مستأجر: «نموذج صغير للمهام البسيطة، ونموذج كبير للصعبة فقط». ولأننا نستضيف النماذج مباشرة، فإن حرية قرارات التوجيه وشفافية الكلفة أكبر مما هي عليه عند الاعتماد على واجهات برمجة خارجية.

ثانياً، اقتصاديات خدمة مفتوحة الأوزان. السبب الجوهري لجعل Coinbase نماذج مثل GLM 5.2 وKimi 2.7 افتراضية هو الكلفة المنخفضة. تتخصص ai-platform في خدمة هذه النماذج مفتوحة الأوزان مباشرة في بيئات داخل المؤسسة أو سيادية. عبر الخدمة المُكمّمة على وحدات GPU استهلاكية، والاستدلال عالي الإنتاجية القائم على vLLM، وعزل الموارد متعدد المستأجرين، يكون خفض كلفة الخدمة لكل رمز ميزتنا التنافسية. وبالتحرّر من تسعير الرموز لواجهات النماذج الحدودية الخارجية، كلما شغّلت النماذج مفتوحة الأوزان بكفاءة أكبر على بنيتك، اقتربت فعلاً من منطقة «الأرخص بنسبة 99%» التي وصفتها Coinbase.

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

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

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

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

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

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

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

المصادر

• تغريدة بريان أرمسترونغ: “How to keep AI spend flat while token usage grows exponentially” (2026-06-27)
• Coinbase Says AI Costs Are Staying Flat As Token Usage Explodes (CryptoAdventure)
• Coinbase CEO Halved AI Costs (Yahoo Finance)

نظرة عامة

GLM-5.2، الذي أصدرته Z.ai (المعروفة سابقًا باسم Zhipu AI) في يونيو 2026، نموذج مفتوح الأوزان بسياق يبلغ مليون رمز وبرخصة MIT. لفت الانتباه لمنافسته النماذج التجارية المغلقة في مهام البرمجة ومهام الوكلاء طويلة المدى. لكنّ هذا الإصدار يأتي بشيء يكاد يضاهي أهمية أوزان النموذج نفسها: فقد تم فتح مصدر slime، البنية التحتية للتعلّم المعزّز التي شغّلت مرحلة التدريب اللاحق للنموذج، إلى جانبه.

تطلق معظم النماذج الرائدة أوزانها المدرَّبة مسبقًا، لكنها تُبقي خط أنابيب التعلّم المعزّز الذي يحوّل تلك الأوزان إلى وكيل مفيد فعلًا سرّيًا. فالبنية التحتية التي تربط تصميم المكافأة وتوليد الـ rollout وحلقة التدريب هي بالضبط الخبرة الخاصة التي تحدّد جودة النموذج. يفتح slime هذا المجال بأكمله. تذكر Z.ai أن GLM-5.2، بل أيضًا GLM-5.1 وGLM-5 وGLM-4.7 وGLM-4.6 وGLM-4.5، خضعت جميعها للتدريب اللاحق على الإطار نفسه. ومرور إطار واحد عبر عدة إصدارات من فئة الأحدث عالميًا يعني أن هذه بنية تحتية مُثبَتة في الإنتاج، لا شيفرة مختبرية.

تشغّل ThakiCloud منصة SaaS متعددة المستأجرين للذكاء الاصطناعي والتعلّم الآلي قائمة على K8s، فتخدم النماذج وتشغّل الوكلاء عبر بيئات عملاء متنوعة. لذا فإن السؤال “أي نموذج جيد” يهمّنا بقدر السؤال “أي بنية تحتية بنته وتشغّله”. وبوصفه مرجعًا عامًا للجانب الثاني، يستحق slime التمعّن. في هذه التدوينة نعرض بنية slime وفلسفته التصميمية، ونتأمّل دلالاته لجدولة GPU عبر Kueue ولمنظومة الخدمة SGLang/vLLM في منصتنا.

ما هو slime

slime إطار للتدريب اللاحق لنماذج اللغة الكبيرة من أجل توسيع التعلّم المعزّز، بناه فريق THUDM (من سلالة جامعة تسينغهوا / Z.ai). الفكرة الجوهرية بسيطة: Megatron-LM بارع في التدريب، وSGLang بارع في الاستدلال عالي الإنتاجية (الـ rollout)، فلنربط الاثنين في تدفّق بيانات واحد. يكرّر التدريب اللاحق للتعلّم المعزّز بلا نهاية حلقةً قوامها “يولّد النموذج إجابة (rollout)، ثم تُقيَّم الإجابة، ثم تُحدِّث تلك المكافأة النموذج”، ولذا فإن مدى سلاسة ربط محرّك التوليد بمحرّك التدريب هو ما يحدّد الإنتاجية الإجمالية.

يفكّك slime هذه الحلقة إلى ثلاثة مكوّنات.

flowchart TB
    subgraph ROLLOUT["롤아웃 (SGLang + Router)"]
        SGL["SGLang 추론 엔진<br/>응답 생성"]
        RT["sgl-router<br/>OpenAI 호환 단일 엔드포인트"]
        RW["보상 / verifier<br/>점수 계산"]
    end
    subgraph BUFFER["Data Buffer (브리지)"]
        DB["프롬프트 초기화<br/>커스텀 데이터<br/>롤아웃 생성 전략 관리"]
    end
    subgraph TRAIN["학습 (Megatron-LM)"]
        MG["Megatron 학습 루프<br/>가중치 업데이트"]
    end

    RT --> SGL
    SGL --> RW
    RW -->|"생성 데이터 + 보상 기록"| DB
    DB -->|"학습 배치 공급"| MG
    MG -.->|"파라미터 동기화"| SGL

• التدريب (Megatron-LM): يتولّى عملية التدريب الرئيسية. يقرأ البيانات من Data Buffer لتحديث النموذج، ويزامن المعاملات مع وحدة الـ rollout بعد اكتمال التدريب.
• الـ Rollout (SGLang + Router): يولّد بيانات جديدة، تشمل المكافآت ومخرجات الـ verifier، ويكتبها إلى Data Buffer. وهنا يوفّر sgl-router واجهة برمجية متوافقة مع OpenAI لتتفاعل بيئات الوكلاء المعقّدة مع النموذج عبر نقطة وصول HTTP واحدة.
• Data Buffer: الجسر بين العالمين. يدير تهيئة الموجِّهات (prompts) والبيانات المخصّصة واستراتيجية توليد الـ rollout.

تتولّى Ray إدارة الموارد. ونتيجةً لذلك، يمكن التبديل بعَلَم واحد بين وضع تتشارك فيه عمليتا التدريب والـ rollout وحدات GPU نفسها، ووضع يفصلهما على وحدات GPU منفصلة.

وضعا التشغيل: colocated وdisaggregated

أكثر قرارات slime التصميمية عمليةً هو أن الشيفرة نفسها تدعم وضعَي نشر اثنين.

الوضع المتشارك (colocated) / المتزامن يضع التدريب والـ rollout على مجمّع GPU نفسه. يُفعَّل بعَلَم واحد --colocate. وهو مناسب لاستخلاص أقصى استفادة من بيئات GPU المحدودة، حيث يتقاسم التوليد والتدريب الموارد نفسها زمنيًا.

الوضع المفصول (disaggregated) / غير المتزامن يفصل وحدات GPU الخاصة بالتدريب عن تلك الخاصة بالـ rollout. فيمكن للتوليد أن يستمر دون انتظار التدريب، مما يرفع الإنتاجية. و”التعلّم المعزّز غير المتزامن للوكلاء” الذي أبرزه GLM-5.2 يعمل فوق هذا الوضع تحديدًا. ففصل التوليد عن التدريب يقلّص بشدّة زمن خمول GPU في الأحمال التي تكون فيها كل حلقة طويلة وغير منتظمة، مثل التفاعلات متعددة الأدوار ومتعددة الأدوات.

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

التصميم من أجل التعلّم المعزّز للوكلاء

ثمّة سبب لاستخدام slime في تدريب نماذج الوكلاء مثل GLM-5.x: فهو يتضمّن ميزات موجَّهة مباشرةً لأحمال الوكلاء متعددة الأدوار.

• PD Disaggregation: يفصل مرحلتَي prefill وdecode لأحمال الوكلاء متعددة الأدوار حيث تختلف احتياجات الموارد بين المرحلتين.
• انتماء الجلسة في الـ Router: يوفّر سياسة توجيه تُبقي الوكيل متعدد الأدوار على الجلسة نفسها، فتستمرّ أدوار الوكيل الواحد المتعدّدة في حالة متّسقة.
• Delta Weight Sync: في بيئة مفصولة بين التدريب والاستدلال، يُزامَن فرق الأوزان فقط، مما يخفض كلفة الاتصال.
• نقطة وصول واحدة متوافقة مع OpenAI: بفضل sgl-router، تتفاعل بيئات الوكلاء المعقّدة مع النموذج عبر طلبات HTTP بسيطة. فلا حاجة لحشر شيفرة البيئة داخل إطار التعلّم المعزّز.

البند الأخير عمليّ على نحو خاص. فإذا جرّدت بيئة المهام طويلة المدى مثل تحرير الشيفرة واستخدام الأدوات وحلّ المشكلات متعدد الخطوات إلى استدعاءات لواجهة OpenAI، أمكنك ربط بيئات الوكلاء القائمة بحلقة تدريب التعلّم المعزّز كما هي تقريبًا. وتضيف Z.ai آلية “مكافحة الالتفاف” (anti-hacking) فوق ذلك لكبح اختراق المكافأة، حيث يستغلّ النموذج المكافأة بطرق التفافية في المهام طويلة المدى.

نظرة عامة على التثبيت والاستخدام

slime متاح على GitHub (THUDM/slime)، ولكونه أصيلًا لـ SGLang فهو يفترض منظومة استدلال SGLang ومنظومة تدريب Megatron-LM. كما نُشر دعم اليوم الأول (Day-0) لوحدات AMD Instinct GPU عبر مدوّنة ROCm، مما يؤكد عمله على مسرّعات خارج NVIDIA.

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

من الناحية البنيوية، الأسطح التي يلمسها المشغّل واضحة. فأنت تحدّد أسلوب النشر بعَلَم وضعٍ مثل --colocate، وتركّب استراتيجية الـ rollout الخاصة بمجالك عبر واجهة توليد البيانات المخصّصة في Data Buffer، وتربط بيئات الوكلاء بنقطة وصول sgl-router. ولهذا يؤكّد الإطار على المرونة: فلأن واجهة الـ rollout قابلة للتخصيص بالكامل، يمكن تهيئة كل شيء على الهيكل نفسه، من خوارزميات التعلّم المعزّز العامة إلى تدريب الوكلاء المتخصّص بمجال بعينه.

التحقق عبر GLM-5.x

يُعدّ slime من أكثر أطر التدريب اللاحق المفتوحة للتعلّم المعزّز اختبارًا في الميدان. فقد مرّت عدة إصدارات من فئة الأحدث عالميًا (GLM-5.2 وGLM-5.1 وGLM-5 وGLM-4.7 وGLM-4.6 وGLM-4.5) عبر حلقة تدريبه الكاملة. وذكر GLM-5.2 أنه دُرِّب لاحقًا بخوارزمية جديدة للتعلّم المعزّز غير المتزامن للوكلاء تتعلّم من التفاعلات طويلة المدى متعددة الأدوات، فوق بنية تحتية تفصل التوليد عن التدريب. وقد ذُكر أن التدريب اللاحق الكامل لـ GLM-5.2 اكتمل في نحو يومين، لكننا نُبقي رقم المدّة هذا بوصفه [تقديريًا] لأننا لم نتمكّن من التحقق المتقاطع منه عبر وثائق رسمية أوّلية.

الجوهر ليس الرقم بل قابلية إعادة الإنتاج. فبفتح أوزان النموذج (MIT) وإطار التدريب معًا، تستطيع مؤسسة تملك حوسبة كافية أن تعيد تتبّع وصفة التدريب اللاحق لـ GLM-5.2 على بيانات مجالها. وهذه رافعة تنفرد بها المنظومة المفتوحة، يستحيل بلوغها بالنماذج المغلقة.

ما الذي يعنيه هذا لمنتجات ThakiCloud

يمسّ تصميم slime للتعلّم المعزّز غير المتزامن طبقتَي منتج متمايزتين في ThakiCloud.

من منظور ai-platform، يتطلّب تدريب التعلّم المعزّز حملين متزامنين مختلفَي الطبيعة تمامًا: الـ rollout (حمل استدلال) والتدريب (حمل انتشار عكسي). تتوافق الطريقة التي يبدّل بها slime بين colocated وdisaggregated عبر Ray توافقًا جيدًا مع نموذج طابور GPU في Kueue. ففي الوضع المفصول، يتيح تقسيم الـ rollout والتدريب إلى مهامّ منفصلة لـ Kueue جدولة كلٍّ منهما عبر طابوره الخاص، مما يرفع استغلال GPU عبر العنقود متعدد المستأجرين ويُبقي تكاليف الحوسبة في حدودها. وبما أن منظومة الخدمة لدينا تستخدم vLLM أصلًا، فإن الخبرة المكتسبة حول التجميع المستمر وإدارة ذاكرة KV المؤقتة تنتقل مباشرةً إلى جانب الـ rollout في خط أنابيب التعلّم المعزّز. والنتيجة العملية هي خط أنابيب RL داخلي يعمل دون تصدير البيانات خارج العنقود، مما يحوّل التدريب اللاحق الذاتي الاستضافة من هدف مبهم إلى منتج ملموس.

من منظور Paxis، يكون الاتصال أكثر مباشرةً. فـ Paxis هو طائرة تحكّم الوكلاء من ThakiCloud، تعمل فوق ai-platform. يشمل جوهره Skill Harness الذي يختار من أكثر من 960 مهارة عبر BM25، وحلقة مهارات ذاتية التطوّر، وتنفيذًا معزولًا، ومحرّك معرفة HKE. يصبح إطار مثل slime هو المحرّك التعليمي لحلقة التطوّر الذاتي تلك. فبتوليد الـ rollouts من بيانات مجال العميل وتقييمها بإشارة مكافأة وتحديث المهارات عبر التعلّم المعزّز، تتحسّن وكلاء مجال Paxis باستمرار مع الاستخدام. وتعمل نقطة وصول sgl-router المتوافقة مع OpenAI كعنصر ربط يصل موصّلات MCP في Paxis وبيئات الأدوات القائمة بحلقة التعلّم المعزّز بأدنى احتكاك. وهكذا يتكامل المنتجان: تزوّد ai-platform طوابير GPU وخط أنابيب RL الداخلي، بينما تستهلك Paxis ذلك الخط بوصفه محرّكًا لتطوّر المهارات.

هذا أقرب إلى خارطة طريق منه إلى ميزة مُشحونة. غير أن التوافق البنيوي بين منظومة ai-platform (K8s وKueue وvLLM) ومعمارية المهارات ذاتية التطوّر في Paxis من جهة، وما يفترضه slime فعلًا من جهة أخرى، يُظهر أن هذا الاتجاه ليس توفيقًا متكلَّفًا.

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

slime ليس حلًّا سحريًا. لنذكر بضعة قيود واقعية بوضوح.

أكبر عائق للدخول هو الحوسبة والتعقيد التشغيلي. فإقامة Megatron + SGLang + Ray في آنٍ واحد وتنسيق التدريب/الـ rollout عبر وحدات GPU متعددة ليس أمرًا هيّنًا البتّة. وليست هذه أداةً يستطيع GPU واحد أو فريق صغير تشغيلها باستهتار، والتدريب اللاحق للتعلّم المعزّز نفسه يتطلّب استثمارًا في البنية التحتية يضاهي التدريب المسبق. وثمّة فجوة كبيرة بين “الإطار مفتوح” و”نستطيع تشغيل التدريب اللاحق للتعلّم المعزّز”.

ثانيًا، صعوبة التدريب اللاحق للتعلّم المعزّز. فتصميم المكافأة، ومنع اختراق المكافأة، واستقرار التدريب، مصاعب جوهرية لا يحلّها الإطار نيابةً عنك. يوفّر slime البنية التحتية فقط؛ أما دالة المكافأة الجيدة ووصفة التدريب المستقرّة فتبقيان مسؤولية المستخدم. وكون Z.ai أبرزت آلية مكافحة الالتفاف على نحو منفصل هو بذاته دليل على مدى صعوبة هذا المجال.

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

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

المصادر

• THUDM/slime - GitHub
• slime: An SGLang-Native Post-Training Framework for RL Scaling - LMSYS Org
• GLM-5.2: Built for Long-Horizon Tasks - Hugging Face Blog
• Day-0 Support for the SGLang-Native RL Framework slime on AMD Instinct GPUs - ROCm Blogs

نظرة عامة

ما إن تُدخِل منصّة ذكاء اصطناعي إلى مؤسسة حتى تجد نفسك أمام سؤال واحد: «إذًا، كم ساعدت فعلًا؟». حتى الآن، كان الجواب في الغالب مقاييس النظام: كم عدد استدعاءات الـ API، وكم مهمة عولِجت، وكم ملّي ثانية استغرقت الاستجابة. الأرقام نظيفة، لكنها لا تبلغ ما تريد الإدارة معرفته حقًّا: «ما الذي أنتجته منظمتنا فعليًّا بقدر أكبر؟».

لهذا فإن تقرير Economic Index «Cadences» الذي نشرته Anthropic في 26 يونيو 2026 جدير بالاهتمام. فهو ليس تحديثًا روتينيًّا لإحصاءات الاستخدام، بل يُعلن صراحةً أن طريقة قياس الأثر الاقتصادي للذكاء الاصطناعي نفسها قد تغيّرت. انطلاقًا من إدراك أن سجلّات المحادثة وحدها لا تكفي لتفسير أثر الذكاء الاصطناعي في العمل، يوسّع التقرير أساس القياس عبر ثلاثة مسارات.

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

ما هذا التقرير؟

حلّلت Anthropic استخدام Claude عبر Economic Index منذ 2023. واتّكأت كل التقارير السابقة على بيانات عيّنة من سبعة أيام: اقتطاع أسبوع وفحص أنماط الاستخدام داخله. قبل عام، كان معظم استخدام Claude محادثةً بين مستخدم ومساعد، فكانت هذه الطريقة تلتقط صورة معقولة.

لكن مع النمو السريع لـ Claude Code وCowork، تحوّلت حصّة كبيرة من الجلسات إلى مهام وكيلة طويلة الأمد. ولم تعد سجلّات المحادثة تلتقط بالكامل كيف يستخدم الناس الذكاء الاصطناعي. تقول Anthropic إنها أعادت تصميم خط بياناتها في ثلاثة اتجاهات لمواكبة ذلك: رفع معدّل أخذ العيّنات لرؤية الأنماط حتى مستوى الساعة، وإدخال مصنِّف جديد يُعنوِن مخرَج كل محادثة، وتفصيل نتائج المحادثات/Cowork وواجهة 1P API شهريًّا لمزيد من الدقّة.

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

المحور الأول: الإيقاعات بالساعة

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

النتائج بديهية وجديدة في آنٍ معًا. يتتبّع استخدام Claude نمط أيام العمل، بينما ترتفع الطلبات الشخصية في عطلة نهاية الأسبوع. وعند النزول ساعةً بساعة يزداد الوضوح: يطلب الناس نصائح النوم غالبًا قرابة الخامسة فجرًا، ويسألون عن الوصفات قرابة السادسة مساءً، وتتجمّع طلبات الأخبار في الصباح. كما تتفاعل الأنماط مع تواريخ بعينها: ارتفعت الطلبات المتعلقة بالضرائب قبيل الموعد النهائي الأمريكي للإقرار الضريبي في 15 أبريل.

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

المحور الثاني: مصنِّف المخرجات (Artifact)

التحوّل الثاني هو تصنيف مخرجات المحادثات. صنّفت Anthropic ما يُنتجه كل من محادثات الدردشة وCowork من مخرَج (artifact) ضمن أكثر من 30 فئة: مستند، شرح، مقطع شيفرة، ورقة أكاديمية، وهكذا، أي المخرَج الأساسي الذي أنتجه Claude في تلك المحادثة.

حكم المصنِّف بأن 93% من محادثات Claude تُنتج مخرَجًا. وأكثر الأنواع شيوعًا هي الشروحات (17%)، والمستندات والتقارير (15%)، والإرشادات (11%). وتمثّل المخرجات الحوارية كالشروحات أو الإرشادات والمخرجات المكتوبة كالمستندات أو العروض نحو الثلث لكلٍّ منها، بينما تمثّل مخرجات الشيفرة والتقنية كالتطبيقات أو السكربتات نحو السدس.

وتتبع ذلك نتيجة ثانية، هي درجة الاستقلالية (autonomy). تقيس Anthropic مقدار ما يُفوَّض إلى Claude من حُكم على مقياس من 1 إلى 5. فالمهام ذات الإجابات المحدّدة سلفًا، كالترجمة أو الحساب، استقلاليتها منخفضة، أما المهام التي تتطلّب الاختيار من بدائل كثيرة، كبناء التطبيقات أو الألعاب أو العروض، فاستقلاليتها مرتفعة.

ويُقاس المخرَج نفسه باستقلالية أعلى حين يُصنع عبر Claude Code. ففي 26 من أصل 31 مخرَجًا معروضًا كانت الاستقلالية أعلى على Claude Code منها على الدردشة أو Cowork، بفارق متوسّط قدره 0.37 نقطة. وفي السكربتات ومقاطع الشيفرة يتّسع الفارق إلى 0.53 نقطة. ونحو ثلثي هذا الفارق يأتي من تنفيذ المهام نفسها بتفويض أكبر. وتمثّل التدوينات مثالًا جيّدًا: المحادثة الوسيطة على الدردشة/Cowork لإنتاج تدوينة تمرّ بـ 13 جولة من الأخذ والردّ، بينما على Claude Code يفوّض الناس قدرًا أكبر من الحُكم. بعبارة أخرى، يمنح المستخدمون الذكاء الاصطناعي استقلالية أكبر.

المحور الثالث: استبيان الإدراك

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

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

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

ما يعنيه هذا لمنتجات ThakiCloud

التوجّه الذي يكشفه هذا التقرير، قياس مقدار ما يُنجزه الذكاء الاصطناعي فعليًّا في سياق العمل، هو بالضبط المسوّغ السوقي الذي بُنيت من أجله Paxis. Paxis هو سحابة ThakiCloud الأصيلة للوكلاء (Agent-Native Cloud)، وهو مستوى تحكّم في الوكلاء يعمل فوق ai-platform (البنية التحتية للذكاء الاصطناعي/التعلّم الآلي القائمة على Kubernetes). يعامل Paxis المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلّات التدقيق (Audit Logs) موارد من الدرجة الأولى. وتشمل مكوّناته الأساسية: Skill Harness الذي يختار من أكثر من 960 مهارة عبر BM25، والتنفيذ المعزول في صندوق الرمل (Sandbox)، ومحرّك معرفة HKE، وتنسيق الوكلاء المتعددة (DAG)، و NL Cron، وموصّلات MCP، والمهارات ذاتية التطور، وبوّابات السياسة مقترنة بسجلّات التدقيق.

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

أما التفكير الذي تعتمد عليه هذه الوكلاء فتوفّره ai-platform في بيئة محلّية (on-premise) أو متعددة المستأجرين، مما يُبقي كل القياسات داخل حدود المنظمة. وكما يوضّح إطار Anthropic، فإن القدرة على شرح أثر الذكاء الاصطناعي من خلال مخرجات العمل الفعلية وسجلّات إجراءات الوكلاء، لا من خلال عدد استدعاءات الـ API، ستحدّد ما يتوقّعه عملاء المؤسسات من منصّة الوكلاء.

الحدود والاعتراضات

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

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

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

المصادر

• Anthropic، “Anthropic Economic Index report: Cadences” (2026-06-26)
• Anthropic، “Anthropic Economic Index Survey” (2026-04)

نظرة عامة

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

في يونيو 2026، أثارت مقالة Prakash Bhandari بعنوان “Claude Code Project Structure: The Complete Map” اهتمام مجتمع المطورين. ترسم المقالة خريطة وحيدة لخمسة أنظمة فرعية تتحكم فيها مجلدات .claude: التعليمات (CLAUDE.md وrules)، وتدفقات العمل (skills وcommands)، والخبراء (agents)، والصلاحيات (settings.json)، والذاكرة (memory). إذ تُشغّل ThakiCloud مئات المهارات وعشرات الوكلاء على هذه البنية بالفعل، لم نكتفِ بقراءة المقالة بل قسنا مستودعنا عليها مباشرةً.

هذا المقال هو سجلّ تلك المقارنة الميدانية. نُحدد حدود دور كل مكوّن، ونقيس الأرقام الفعلية لمكوّنات مستودع ai-platform-strategy، ثم نناقش لماذا تتخطى هذه البنية مجرد التنظيم حين يتعلق الأمر بتشغيل منصة SaaS متعددة المستأجرين لـ AI/ML على Kubernetes.

ما هي بنية مشروع Claude Code؟

الفكرة الجوهرية بسيطة. يقرأ Claude Code التكوين من موضعين: مجلد .claude في دليل المشروع، ومجلد ~/.claude في الدليل الرئيسي. يُودَع ملفات المشروع في git لمشاركتها بين أعضاء الفريق، بينما تنطبق ملفات الدليل الرئيسي على جميع المشاريع كإعدادات شخصية. يستقر كل مكوّن في موضعه وفق هذين المسارين.

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

flowchart TB
    ROOT["프로젝트 루트"]
    ROOT --> BRAIN["CLAUDE.md<br/>프로젝트 브레인<br/>(매 세션 자동 로드)"]
    ROOT --> LOCAL["CLAUDE.local.md<br/>개인 오버라이드<br/>(gitignore)"]
    ROOT --> IGNORE[".claudeignore<br/>컨텍스트 경계"]
    ROOT --> MCP[".mcp.json<br/>외부 도구 연결"]
    ROOT --> DOTC[".claude/"]
    DOTC --> SET["settings.json<br/>권한·훅·환경변수"]
    DOTC --> RULES["rules/<br/>상시 규칙<br/>(매 턴 로드)"]
    DOTC --> SKILLS["skills/<br/>온디맨드 전문지식<br/>(요청 시 로드)"]
    DOTC --> AGENTS["agents/<br/>서브에이전트 정의"]
    DOTC --> MEM["agent-memory/<br/>에이전트가 학습한 지식"]
    DOTC --> WT["worktrees/<br/>병렬 격리"]

مخطط بنية مشروع Claude Code مُرتَّب وفق توقيت التحميل في السياق.

حدود دور كل مكوّن

القيمة الحقيقية للخريطة تتجلى في الإجابة عن: ما الذي يذهب إلى أين؟ فيما يلي ملخص مسؤولية كل مكوّن مقروناً بطريقة تطبيقنا الفعلي.

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

CLAUDE.local.md هو تجاوز الإعدادات الشخصية. يشارك CLAUDE.md تنسيقه ذاته لكنه لا يدخل git أبداً. المسارات المحلية للبيئة، ومختصرات تصحيح الأخطاء، والتفضيلات الشخصية، وخصوصيات جهازك: هذه هي ما يذهب هنا. يجوز أن يختلف بين الزملاء، وهو الصمام الأماني الذي يُبقي CLAUDE.md المشترك نظيفاً.

.claudeignore هو حدود السياق. يستخدم صياغة .gitignore ذاتها ليقيّد نطاق قراءة Claude. بدونه، يستنزف node_modules وملفات الترحيل المولّدة وتبعيات البائع والتركيبات الضخمة السياقَ. في مستودعات الأحادي الكبيرة يصبح هذا الملف شرطاً لا خياراً.

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

skills هي المعرفة المتخصصة عند الطلب. لا تُحمَّل إلا حين تُفعّلها طلبٌ ما. وصفات العمل المتخصصة وخطوط أنابيب المجالات والمهام المتكررة: هذا مكانها. السؤال الفاصل بين CLAUDE.md وskills: هل يُحتاج هذا دائماً أم أحياناً؟

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

agent-memory هي المعرفة التي اكتسبها الوكيل بنفسه. هنا يكمن الفرق الجوهري عن CLAUDE.md: الأخير يحتوي ما أخبرته أنت به، أما agent-memory فتحتوي ما تعلّمه الوكيل من التجربة. الوكلاء طويلو المدى يراكمون الأنماط المتكررة والأخطاء والاتفاقيات غير الموثّقة.

أين تضع المعرفة الجديدة؟

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

flowchart TB
    START["새 지식·규칙·워크플로 추가"]
    START --> Q1{"항상 적용 +<br/>전체 팀 공유?"}
    Q1 -->|예| CMD["CLAUDE.md (짧게)<br/>또는 .claude/rules/"]
    Q1 -->|아니오| Q2{"가끔만 필요한<br/>전문 워크플로?"}
    Q2 -->|예| SK[".claude/skills/"]
    Q2 -->|아니오| Q3{"독립 역할·<br/>도구 조합?"}
    Q3 -->|예| AG[".claude/agents/"]
    Q3 -->|아니오| Q4{"개인 환경<br/>특이사항?"}
    Q4 -->|예| LO["CLAUDE.local.md<br/>(gitignore)"]
    Q4 -->|아니오| Q5{"에이전트가<br/>경험으로 배운 것?"}
    Q5 -->|예| ME[".claude/agent-memory/"]
    Q5 -->|아니오| PL["plugins/<br/>(여러 프로젝트 배포)"]

شجرة القرار لتحديد موضع أي معرفة جديدة: هل تُحتاج دائماً؟ هل تُحتاج أحياناً؟ من صنعها؟

الأخطاء الشائعة واضحة أيضاً. حشو المعرفة التي “تُحتاج أحياناً” في CLAUDE.md يعني هدر توكن في كل جلسة. مستودع أحادي بلا .claudeignore يستنزف السياق. إيداع CLAUDE.local.md في git يكشف البيانات الشخصية والمسارات. تفعيل أكثر من 10 خوادم MCP دائماً يهدر نحو 10 آلاف توكن بلا استخدام.

قياس مستودع ThakiCloud على هذه الخريطة

بعد قراءة الخريطة، قسنا مستودعنا عليها فعلاً. هذه هي نتائج قياس مجلد .claude في مستودع ai-platform-strategy:

40 قاعدة و94 سطراً من CLAUDE.md هي تكلفة دائمة تدخل السياق مع كل دورة، بينما 1655 مهارة و54 وكيلاً أصول يدخلون السياق عند الطلب فحسب.

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

اللافت أننا حين انتهينا من قراءة مصدر هذا المقال، استخلصناه مباشرةً في ملف قاعدة باسم claude-code-project-anatomy.md وأدرجناه في المستودع. أي أن “خريطة بنية المشروع” ذاتها اجتازت شجرة القرار لتستقر قاعدةً دائمة الحضور. الخريطة وضعت نفسها على الخريطة.

ما يعنيه هذا لمنتجات ThakiCloud

يتمثّل سجل SKILL.md وتعريفات الوكلاء الفرعيين وبنية القواعد في Claude Code في المبادئ التصميمية لـ Paxis، السحابة الأصيلة للوكلاء Agent-Native Cloud التي تطوّرها ThakiCloud حالياً في مرحلة إثبات المفهوم. يُشغّل Paxis منظومة Skill Harness التي تختار من بين أكثر من 960 مهارة عبر استرجاع BM25 وتنفّذها في بيئات عزل sandbox مستقلة، وهو تعميم على مستوى الإنتاج لنمط المهارة عند الطلب ذاته الذي يصفه هذا المقال. مبدأ “إبقاء ما هو دائم التحميل في حدوده الدنيا، ووضع سير العمل المتخصصة في المهارات الجاهزة عند الطلب” هو المبدأ نفسه الذي يعتمده Paxis في تعامله مع المهارات باعتبارها موارد أولى درجة. ومنهج “harness رفيع، مهارات سمينة” هو الأساس المعماري لسجل وكلاء Paxis.

يأخذ Paxis هذه البنية من بيئة المطوّر الفردي ويرفعها إلى وقت التشغيل الإنتاجي. يُدير المنصة مهاراتٍ وأدواتٍ وسياساتٍ وسجلاتِ تدقيق باعتبارها موارد أولى درجة، وينفّذ مستوى التحكم في الوكلاء عبر تنسيق متعدد الوكلاء بـ DAG، وجدولة المهام بالغة عربية طبيعية NL Cron، وموصّلات MCP. أما المهارات ذاتية التطوّر وبوابات السياسة فهي ارتقاء بفكرة agent-memory التي يُعبّر عنها Claude Code إلى مستوى المنتج: الفصل بين القناة التي تراكم فيها الوكلاء معرفتها المكتسبة والقناة التي يُراجعها فيها المسؤولون ويعتمدونها.

تُوفّر ai-platform نقاط نهاية LLM التي تُشغّل هذه المنظومة عند الاستنتاج، إذ تُشغّل ThakiCloud طبقة بنية AI/ML التحتية القائمة على Kubernetes مع خدمة نماذج متعددة المستأجرين عبر vLLM وجدولة GPU عبر Kueue، وهي الركيزة التنفيذية التي تستقبل طلبات استنتاج وكلاء Paxis وتعالجها.

قيود وتحفظات

هذه الخريطة ليست حلاً مطلقاً. إليك تحفظات صريحة.

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

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

ثالثاً، هذه البنية مُخصصة لـ Claude Code. الانتقال إلى بيئة تنفيذ وكلاء أخرى يغيّر اتفاقيات الدليل وآليات التحميل. لذا من الأجدر صياغة المعرفة ذاتها بحيادية تجاه بيئة التنفيذ، مع إبقاء التوصيل بالبيئة رفيعاً قدر الإمكان.

أخيراً، بعض أرقام المصدر، كـ 1000 توكن تقريباً لكل خادم MCP، تقديرات تتفاوت بحسب البيئة والإصدار. الأجدر قراءتها كاتجاه: “كل ما يُحمَّل دائماً يُكلّف”، لا كأرقام مطلقة.

المصادر

• Claude Code Project Structure Explained: The Complete 2026 Guide (Prakash Bhandari)
• Explore the .claude directory (التوثيق الرسمي لـ Claude Code)
• المستودع المقيس: مجلد .claude في مستودع ThakiCloud ai-platform-strategy (القياس بتاريخ 2026-06-27)