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

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

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

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

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

هذا ممكن لأن Fugu ليس مجموعة قواعد توجيه، بل نموذج لغوي مُدرَّب على التنسيق ذاته. يتخصص Fugu في فهم متى يُفوِّض، وكيف تتواصل الوكلاء، وكيف يُدمج نواتجها في إجابة واحدة موثوقة. يستند هذا النهج إلى ورقتَي بحث نشرتهما Sakana AI في ICLR 2026: TRINITY (arXiv:2512.04695) التي تُقدم منسقًا تطوريًا لنماذج LLM، وConductor (arXiv:2512.04388) التي تدرس تعلُّم تنسيق الوكلاء باللغة الطبيعية.

تفصيل تصميمي يستحق الإشارة: يمكن لـ Fugu استدعاء نُسَخه الخاصة بصورة تكرارية داخل مجموعة الوكلاء. من الخارج تستدعي نموذجًا واحدًا، ومن الداخل منظومة متخصصة منسقة هي التي تؤدي العمل. صُممت مجموعة الوكلاء لتكون قابلة للاستبدال بهدف معلن هو تقليص الاعتماد على مزود بعينه.

البنية المعمارية: نظام بيئي تعاوني خلف واجهة برمجية واحدة

الادعاء المحوري لـ Fugu هو أن “نموذج التنسيق هو الحدود التالية.” منذ تأسيسها، أكدت Sakana AI أن أقوى أنظمة الذكاء الاصطناعي ستكون أنظمة بيئية تعاونية لا نماذج ضخمة معزولة. Fugu هو التجسيد المنتجي لهذا الاعتقاد.

تقنيًا، يعالج Fugu أربع مراحل داخلية ضمن استدعاء واجهة برمجية واحد:

• الاختيار (Selection): يقرأ طبيعة الطلب ويحدد ما إذا كان سيتولاه مباشرة أم يستعين بنماذج متخصصة.
• التفويض (Delegation): يفصل التخطيط عن التنفيذ ويوزع المهام الفرعية على الوكلاء المناسبين.
• التحقق (Verification): يراجع ناتج كل وكيل داخليًا.
• التوليف (Synthesis): يدمج النتائج في إجابة واحدة متسقة.

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

تمتلك Sakana AI سوابق تؤيد هذا الاتجاه؛ إذ حل ALE-Agent المنسق البرمجي في المرتبة الحادية والعشرين في مسابقة برمجة شارك فيها ألف خبير بشري. Fugu يمتد من تلك التجربة إلى منتج تنسيق للأغراض العامة.

النموذجان: Fugu وFugu Ultra

عند الإطلاق، يتوفر Fugu بنموذجين مُصمَّمَين لأحجام عمل مختلفة، ويُمكن الوصول إليهما عبر واجهة برمجية واحدة متوافقة مع OpenAI.

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

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

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

كيف تقرأ معايير الأداء

أعلنت Sakana AI أن Fugu Ultra يُجاري نماذج رائدة كـ Fable 5 وMythos Preview من Anthropic في معايير الأداء الصعبة لمجالات الهندسة والعلوم والاستدلال. هذا الادعاء يستوجب قراءة متأنية.

أولًا، جميع نتائج خط الأساس باستثناء نتائج Fugu نفسه مصدرها تقارير مزودي النماذج أنفسهم، لا مقارنة مستقلة خاضعة لشروط موحدة. ثانيًا، أهداف المقارنة – Fable 5 وMythos Preview – غير متاحة للعموم وغير مدرجة في مجموعة وكلاء Fugu. أي أن Fugu يدّعي اقتراب أدائه من نموذجين لا يستدعيهما داخليًا. ثالثًا، استُخدم mini-swe-agent scaffolding في تقييم مهام عائلة SWE، ونوع الـ scaffolding يؤثر تأثيرًا ماديًا في النتائج، فلا يمكن اعتبارها مقارنةً في ظروف متكافئة.

في المرحلة الراهنة، تظل قضية “تكافؤ Fugu Ultra مع النماذج الحدية” ادعاءً قائمًا على تقارير ذاتية. الأرقام التفصيلية مُجمَّعة في التقرير التقني لـ Sakana AI (github.com/SakanaAI/fugu)، لكن ريثما تتراكم عمليات التحقق المستقلة، التمييز بين الأرقام التسويقية والأداء المُتحقَّق منه أمر لازم. لا يستشهد هذا المقال بأرقام فردية غير مُتحقَّق منها، بل يُسجِّل طبيعة الادعاءات فحسب.

الانعكاسات على منصة ThakiCloud للذكاء الاصطناعي وتعلم الآلة على K8s

التساؤلات التي يطرحها Fugu تتقاطع مع استراتيجية منصة ThakiCloud بدقة. تُشغِّل ThakiCloud وكلاء متعددي المستأجرين في بيئات عملاء متنوعة، وتدير سحابة عمليات وكلاء تُسمى Praxis فوق K8s وجدولة GPU القائمة على Kueue وخدمة vLLM. الأطروحة التي يسعى Fugu لإثباتها – أن “طبقة التنسيق نفسها تصبح منتجًا” – تتجه في الاتجاه ذاته الذي نسلكه.

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

من منظور ThakiCloud، يتيح تصميم Fugu استخدامين: الأول هو قيمته بوصفه تطبيقًا مرجعيًا لأنماط التنسيق؛ فبنية التوجيه الديناميكي للنماذج المفتوحة المُستضافة ذاتيًا على K8s – بالجمع بين نماذج البرمجة والاستدلال والتخصص الحقلي حسب طبيعة المهمة – فكرة قابلة للتطبيق مباشرة على عمليات وكلاء Praxis. الثاني هو الامتثال القائم على الاستثناء: إمكانية استثناء وكلاء بعينهم من المجموعة ترتبط بشكل طبيعي بسياسات تقييد النماذج المسموح بها لكل مستأجر في البيئة متعددة المستأجرين.

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

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

Fugu منتج جدير بالاهتمام، لكن منطقه التسويقي يحمل نقاطًا تستحق التدقيق.

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

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

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

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

رغم هذه التحفظات، يظل التساؤل الذي يطرحه Fugu – “هل يمكن أن يكون التنسيق قدرة مكتسبة بالتدريب لا شفرة مكتوبة يدويًا؟” – تساؤلًا سيواجهه كل مشغّل منصة وكلاء متعددة. تعتزم ThakiCloud الإجابة عن هذا التساؤل بـ تنسيق قابل للاستضافة الذاتية وللمراقبة بوصفه ميزةً تمايزية.

المصادر

• Sakana AI, “Sakana Fugu: One Model to Command Them All”, 2026-06-22, sakana.ai/fugu-release
• Sakana Fugu Technical Report, Fugu Team, Sakana AI, 2026, github.com/SakanaAI/fugu
• Xu et al., “TRINITY: An Evolved LLM Coordinator”, ICLR 2026, arXiv:2512.04695
• Nielsen et al., “Learning to Orchestrate Agents in Natural Language with the Conductor”, ICLR 2026, arXiv:2512.04388
• THE DECODER, “Sakana AI’s Fugu orchestrates multiple LLMs to match Anthropic’s Fable and Mythos benchmarks”, 2026-06-22, the-decoder.com

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

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

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

ما الذي جرى

يتضمن صميم الشراكة المُعلَنة ثلاثة محاور.

أولًا، عقد توريد متعدد السنوات. ستوفر Micron لـAnthropic ذاكرة النطاق الترددي العالي (HBM)، وذاكرة DRAM، وأقراص الحالة الصلبة (SSD)، وهي المنتجات الرئيسية لمراكز البيانات. يُعدّ هذا عقدًا طويل الأمد لضمان حجوم توريد مستقرة، لا عملية شراء لمرة واحدة.

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

ثالثًا، الاستثمار الاستراتيجي في حقوق الملكية. ضخّت Micron استثمارًا استراتيجيًا في جولة تمويل Series H لشركة Anthropic، دون الإفصاح عن مبلغ الاستثمار. من خلال هذه الجولة، قُيِّمت Anthropic بنحو 965 مليار دولار [تقديري]، لتصبح أعلى شركة ذكاء اصطناعي خاصة قيمةً، مع مشاركة Samsung وSK hynix وAltimeter Capital وSequoia وAmazon وفقًا للتقارير. يتضمن الاتفاق أيضًا نشر Claude عبر عمليات Micron الداخلية.

ارتفع سهم Micron قرابة 5.5% مباشرة عقب الإعلان. غير أن محور هذا المقال ليس سعر السهم، بل الانعكاسات التقنية التي يحملها هذا التحالف لتصميم بنية الذكاء الاصطناعي التحتية.

لماذا تُعدّ الذاكرة عائق البنية التحتية للذكاء الاصطناعي

يُعدّ الاستدلال في نماذج اللغة الكبيرة عملًا مقيَّدًا بالذاكرة في جوهره. في كل مرة يُولَّد فيها رمز (token)، يجب قراءة المجموعة الكاملة لأوزان النموذج من الذاكرة. مهما بلغت سرعة وحدات المعالجة، فإن GPU ستقف مكتوفة تنتظر البيانات إن لم تُسَدَّ بالأوزان بسرعة كافية. لذا تتحدد إنتاجية الاستدلال في الغالب بعرضة النطاق الترددي للذاكرة لا بطاقة المعالجة.

يتضح التسلسل الهرمي لذاكرة خادم استدلال الذكاء الاصطناعي في المخطط أعلاه.

• HBM (ذاكرة النطاق الترددي العالي): الذاكرة فائقة السرعة الأقرب إلى GPU. توفر نطاقًا تردديًا يبلغ تيرابايتات في الثانية، وتحتضن أوزان النموذج النشطة وذاكرة KV cache. تُعدّ HBM عنق الزجاجة المباشر لإنتاجية الاستدلال.
• DRAM (ذاكرة النظام): طاقتها أكبر من HBM لكنها أبطأ. تُستخدم لتبادل الأوزان التي لا تتسع لها HBM أو لحفظ سياقات أطول.
• SSD (التخزين): الأبطأ لكن الأكبر طاقةً. تحتضن نقاط تفتيش النموذج والبيانات الباردة وحصة متنامية من إلغاء تحميل KV cache.

حين توفّر شركة واحدة التسلسل الهرمي بأكمله، يغدو تحسين حركة البيانات عبر كل الطبقات ممكنًا وفق فلسفة تصميم متسقة. كون Micron تغطي HBM وDRAM وSSD هو الأصل الاستراتيجي المحوري في هذه الشراكة.

ما الذي يغيره التصميم المشترك للذاكرة والتخزين

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

أولًا، يمكن أن تنعكس أنماط الوصول إلى البيانات في الاستدلال والتدريب مباشرةً على تصميم الذاكرة. على سبيل المثال، مسارات إلغاء تحميل KV cache بكفاءة من HBM إلى DRAM أو SSD، والبنى التي تُقلص تكلفة العبور بين طبقات التسلسل الهرمي للذاكرة في معالجة السياق الطويل، هي مسائل تحلّ بشكل أفضل حين يصمّمها معًا مزود النموذج ومزود الذاكرة.

ثانيًا، تُظهر الشراكة أن بنية الذكاء الاصطناعي التحتية تتجه نحو التكامل الرأسي بصورة متزايدة. إنها إشارة إلى أن شركات الذكاء الاصطناعي الرائدة تسعى إلى تأمين ليس GPU فحسب، بل الذاكرة أيضًا على مستوى سلسلة التوريد ومرحلة التصميم. مشاركة شركات ذاكرة كـSamsung وSK hynix في جولة Series H ذاتها تُقرأ في السياق نفسه. قدرة توريد الذاكرة تتحول إلى جزء من القدرة التنافسية في الذكاء الاصطناعي.

منظور منصة ThakiCloud K8s AI/ML SaaS

هذه صفقة بين شركات كبرى، لكنها تحمل دروسًا مباشرة لـThakiCloud بوصفها مشغّلة لمنصة خدمة AI/ML مستندة إلى K8s.

أولًا، يتأكد من جديد أن الذاكرة هي نقطة الانطلاق لتحسين تكاليف الخدمة. تُشغّل ThakiCloud الاستدلال متعدد المستأجرين فوق جدولة GPU المستندة إلى vLLM وKueue. في هذه البيئة، الرافعة الأكثر فاعلية لزيادة الإنتاجية هي في الغالب استخدام الذاكرة لا المعالجة. إدارة KV cache واستراتيجيات الدفعات وتوزيع النماذج المُعيَّر وفق طاقة HBM هي التقنيات المحورية لمعالجة طلبات متزامنة أكثر على GPU ذاتها. سبب استقطاب تقنيات كـPagedAttention في vLLM للاهتمام يعود في نهاية المطاف إلى كفاءة الذاكرة.

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

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

تحفظات وحجج مضادة

لتجنب الإفراط في تأويل هذه الشراكة، تستحق بعض النقاط الإشارة.

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

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

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

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

المصادر

• Micron Technology, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, investors.micron.com
• Yahoo Finance, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, finance.yahoo.com
• Crypto Briefing, “Micron signs supply agreement with Anthropic AI, invests in Series H round”, 2026-06-22, cryptobriefing.com

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

تحليل المستندات، أي تحويلها إلى بنية قابلة للقراءة آلياً، بات أكثر أهمية في عصر RAG والعوامل الذكية. فالصفحة الواحدة من PDF قد تجمع نصاً سردياً وجداول ومعادلات ومخططات وتخطيطاً متعدد الأعمدة، وعلى النموذج أن يفك هذا التشابك بترتيب قراءة دقيق حتى تستطيع النماذج اللغوية الكبيرة الاستفادة منه. حتى وقت قريب، كان هذا الميدان حكراً على النماذج متعددة الوسائط العملاقة كـ GPT-4o وGemini 2.5 Pro، أو على أدوات المعالجة الأنبوبية الثقيلة.

PaddleOCR-VL الصادر عن فريق PaddlePaddle (Baidu) يزعزع هذه المعادلة. فنموذجه الأساسي PaddleOCR-VL-0.9B لا يتجاوز 960 مليون معامل، نموذج رؤية-لغة بالغ الصغر، غير أنه يُفيد بأداء متصدر في تحليل المستندات على مستوى الصفحة كاملاً، وكذلك في التعرف على المكونات الفردية. الرخصة Apache-2.0 تتيح الاستخدام التجاري بحرية، ويشهد النموذج إقبالاً واسعاً على Hugging Face إذ تجاوز عدد التنزيلات 120,000 مرة.

في ThakiCloud نشغّل فعلياً بنية تحتية للاستدلال متعدد المستأجرين ومعالجة المستندات على منصة AI/ML SaaS مبنية على Kubernetes. لهذا لم نكتفِ بمراجعة النموذج نظرياً، بل ثبّتناه وأجرينا عليه استدلالاً فعلياً على مستندات تجمع الكورية والإنجليزية والعربية. نوضح هنا ما إذا كان النموذج الصغير جديراً بالاستخدام الفعلي، وأين يناسب منصتنا.

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

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

البنية ثنائية المراحل التي تفصل تحليل التخطيط عن التعرف على المكونات.

المرحلة الأولى، تحليل التخطيط (PP-DocLayoutV2): نموذج خفيف متخصص يرصد المناطق الدلالية في المستند ويصنّفها ويتنبأ بترتيب القراءة. يستخدم RT-DETR للكشف عن الكائنات، وشبكة مؤشر مكوّنة من ست طبقات محوّلة للتنبؤ بترتيب القراءة. بفصل استدلال التخطيط عن نموذج الرؤية-اللغة الثقيل، تحقق النماذج نتائج مستقرة حتى في التخطيطات متعددة الأعمدة.

المرحلة الثانية، التعرف على المكونات (PaddleOCR-VL-0.9B): تتلقى هذه المرحلة المناطق التي رصدتها المرحلة الأولى وتتعرف بدقة على النص والجداول والمعادلات والمخططات. تتبع البنية نمط LLaVA مع مشفّر بصري ذي دقة ديناميكية على غرار NaViT (مُهيَّأ من نموذج الرؤية Keye-VL) لمعالجة الصور بأي دقة دون تشويه. يربط مُسقِط MLP مزدوج الطبقات مع تفعيل GELU (بحجم دمج 2) السمات البصرية بفضاء تضمينات النموذج اللغوي، فيما يعمل المُفكِّك ERNIE-4.5-0.3B المعزز بـ 3D-RoPE مُفكِّكاً. اختيار نموذج لغوي صغير مقصود: كلما صغر المُفكِّك تسارع فك الترميز رمزاً بعد رمز.

تُكمل وحدة مُعالجة لاحقة خفيفة الدورة بدمج مخرجات المرحلتين في Markdown وJSON منظّمَين. يدعم النموذج 109 لغة تشمل الكورية واليابانية والعربية والسيريلية والديفانغاري (الهندية) إضافة إلى الأبجديات اللاتينية.

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

لنُجرِ التثبيت بأنفسنا. البيئة: MacBook بمعالج Apple Silicon (macOS، معالج مركزي فقط، بلا تسريع GPU)، Python 3.12.8. تعمل PaddleOCR-VL فوق منظومة PaddlePaddle، فنثبّت الحزمتين التاليتين:

# التثبيت في البيئة الافتراضية المشتركة (.venv) وفق قواعد python-runtime
VIRTUAL_ENV="$PWD/.venv" uv pip install paddlepaddle paddleocr
# الإصدارات المثبتة: paddlepaddle==3.3.1, paddleocr==3.7.0

عند المحاولة الأولى للاستدلال ظهر الخطأ التالي:

RuntimeError: A dependency error occurred during pipeline creation.
Please refer to the installation documentation to ensure all required dependencies are installed.

يتطلب خط أنابيب PaddleOCR-VL تبعيات إضافية خاصة بتحليل المستندات. حلّينا الأمر بسطر واحد:

VIRTUAL_ENV="$PWD/.venv" uv pip install "paddleocr[doc-parser]"

شيفرة الاستدلال نفسها مختصرة؛ يقوم خط الأنابيب بتنزيل النماذج اللازمة تلقائياً:

from paddleocr import PaddleOCRVL

pipe = PaddleOCRVL()                 # تنزيل النموذج تلقائياً عند الاستدعاء الأول
out = pipe.predict("sample_doc.png") # صورة المستند ← مخرجات منظمة
for res in out:
    res.save_to_markdown(save_path="paddleocr_out")

ثمة نقطة جديرة بالإشارة: اختارت paddleocr==3.7.0 تلقائياً PP-DocLayoutV3 نموذجاً للتخطيط، وPaddleOCR-VL-1.6-0.9B نموذجاً للتعرف. بمعنى أن الحزمة لا تجلب الإصدار الأوّلي الوارد في الورقة البحثية (2510.14528)، بل نموذج 1.6 المحدَّث ونموذج تخطيط أحدث. رقم “96.33% SOTA على OmniDocBench” الذي انتشر على تويتر ينتمي تحديداً إلى PaddleOCR-VL-1.6 (وفق OmniDocBench v1.6)، وهو مختلف عن الأرقام الأولية التي أوردتها الورقة البحثية. سنوضح هذا التمييز لاحقاً.

نتائج التجربة الفعلية

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

• تهيئة النموذج (الاستدعاء الأول، شاملاً التنزيل): 74.7 ثانية
• الاستدلال (predict): 32.65 ثانية / صفحة واحدة
• الوقت الإجمالي (من الاستيراد حتى الحفظ): 137.4 ثانية
• سجل بنية المُفكِّك: GQA (انتباه مجمّع الاستعلامات)، num_heads 16 / num_key_value_heads 2

كانت مخرجات Markdown للتعرف على النحو التالي:

## ThakiCloud Document Intelligence
Kubernetes AI/ML SaaS Platform - Invoice No. 2026-0623
타키클라우드 멀티테넌트 추론 비용 보고서
GPU hours: 1,284 Total: $9,640.00
E = mc^2 sum_{i=1}^{n} x_i

اللافت أن النموذج التقط العنوان الإنجليزي بوصفه ترويساً في Markdown (##)، وتعرّف بدقة على الجملة الكورية “타키클라우드 멀티테넌트 추론 비용 보고서”، وقرأ الأرقام والرموز النقدية ($9,640.00، GPU hours 1,284) دون أخطاء. جودة التعرف على الكورية مستقرة بشكل لافت لنموذج بهذا الحجم.

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

فيما يلي الأرقام التي أوردتها الورقة البحثية من المعايير العامة. المخطط أدناه يعرض مسافات التحرير لعدد من اللغات من مجموع 109 لغة (الأقل كلما كان أفضل):

إبراز الكورية والعربية، وهما السوقان الرئيسيتان لـ ThakiCloud. المصدر: arXiv:2510.14528.

الكورية عند 0.052 والعربية عند 0.122، كلتا اللغتين المستهدفتين تُظهران مسافات تحرير جيدة. على صعيد الأداء الشامل على مستوى الصفحة، تُشير الورقة البحثية إلى أن النموذج حقق 92.86 في المجموع على OmniDocBench v1.5، متفوقاً على MinerU2.5-1.2B (90.67) الذي يليه مباشرة.

نموذج 0.9B يتفوق على نموذج 1.2B في الدرجة الإجمالية. المصدر: arXiv:2510.14528 Table 2.

عند الاستشهاد بالأرقام لا بد من توضيح الإصدار. الورقة البحثية (2510.14528) أفادت بـ 92.86 على OmniDocBench v1.5؛ والإصدار اللاحق PaddleOCR-VL-1.5 أفاد بـ 94.5% على v1.5، فيما أفاد PaddleOCR-VL-1.6 بـ 96.33% على v1.6 كرقم [تقديري] (أرقام الإصدارات اللاحقة مستندة إلى تقارير منفصلة). الرقم 96.33% الذي ظهر على تويتر ينتمي إلى أحدث إصدار 1.6. كذلك تجدر الإشارة إلى أن سرعة الاستدلال المقاسة في الورقة تمت على NVIDIA A100 واحد بمعالجة دُفعية لـ 512 مستنداً باستخدام محركات خدمة عالية الأداء كـ vLLM وSGLang وFastDeploy. قياسنا لـ 32.65 ثانية/صفحة على المعالج المركزي هو رقم مرجعي لبيئة بلا تسريع، ولا يعكس الإنتاجية في بيئة الإنتاج.

دلالات التطبيق على منصة ThakiCloud K8s AI/ML SaaS

جاذبية هذا النموذج لا تكمن فقط في ارتفاع درجاته، بل في سهولة تشغيله لصغر حجمه. من منظور منظومة ThakiCloud:

• خدمة متعددة المستأجرين بتكلفة منخفضة: نموذج 0.9B يعمل على بطاقة GPU واحدة من الفئة الاستهلاكية أو الاقتصادية. نشره فوق جدولة GPU المستندة إلى Kueue ومحركات الخدمة vLLM وSGLang يتيح تشغيل نقاط نهاية منفصلة لتحليل مستندات كل مستأجر بتكلفة معقولة، مع التحكم الكامل في التكلفة عبر الاستدلال ذاتي الاستضافة بدلاً من دفع رسوم رمزية لنموذج ضخم.
• سيادة البيانات والتشغيل المحلي: المستندات كثيراً ما تحوي معلومات حساسة كفواتير وعقود وسجلات طبية ومالية يصعب إرسالها خارجياً. الاستضافة الذاتية لنموذج Apache-2.0 تتيح تقديم استخبارات المستندات دون إرسال البيانات إلى واجهات برمجية خارجية، بما يتوافق مع اشتراطات عزل الشبكة وقيود تصدير البيانات في القطاعات الحكومية والمالية.
• تعدد اللغات يعني ملاءمة السوق: يصدر مدونة ThakiCloud بالكورية والإنجليزية والعربية. من موقعنا المُطِل على السوقين الكوري والشرق أوسطي، معالجة الكورية (0.052) والعربية (0.122) بنموذج واحد بشكل موثوق يترجم مباشرة إلى ميزة تنافسية ويُقلل الحاجة إلى محركات OCR مختلفة لكل سوق.
• طرف المدخلات في خط أنابيب RAG: مخرجات Markdown وJSON المنظّمة تتغذى مباشرة في فهرسة RAG واستدعاءات أدوات الوكلاء. النص المحافظ على تخطيطه وترتيب قراءته يرفع جودة القطع ويُسهم مباشرة في دقة الاسترجاع.

في مرحلة أكثر نضجاً، يمكن فصل نموذج التخطيط من المرحلة الأولى عن نموذج التعرف من المرحلة الثانية كخدمتين مستقلتين: التخطيط على عقد المعالج المركزي، والتعرف بنموذج الرؤية-اللغة على عقد GPU. البنية المنفصلة على مرحلتين تُيسّر جدولة الموارد غير المتجانسة في بيئة Kubernetes.

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

لا يصح الاكتفاء بالإيجابيات. إليك نقاط الضعف بناءً على القياس الفعلي والأدبيات:

• بطء على المعالج المركزي: 32.65 ثانية/صفحة التي قسناها غير مناسبة لمعالجة المستندات بكميات كبيرة. الاستخدام الفعلي يستلزم GPU ومحركات خدمة كـ vLLM وSGLang، وإنتاجيات الورقة المُبهرة تستند إلى بيئة دُفعية على A100.
• تبعيات البنية الثنائية: تحتاج إلى إدارة نموذجَي التخطيط والتعرف معاً، مما يزيد تكلفة النشر وإدارة توافق الإصدارات مقارنة بنموذج واحد. في الواقع تجلب الحزمة بشكل افتراضي PP-DocLayoutV3 + PaddleOCR-VL-1.6، وهذا التوليف قد يتغير بمرور الوقت.
• أرقام SOTA مرتبطة بإصدار محدد: 96.33% هو رقم الإصدار 1.6 على OmniDocBench v1.6، وليس العنوان الرئيسي للورقة الأساسية التي اقترحت 0.9B. الاستشهاد دون توضيح الإصدار والمعيار يُفضي إلى التضليل.
• الاعتماد على جودة المعالجة الأولية: كما أظهر اختبارنا العربي، جودة رسم الصورة ودقتها وتشكيل حروفها تحدد النتيجة. في خطوط الأنابيب الإنتاجية، مرحلة توحيد المدخلات لا تقل أهمية عن اختيار النموذج.
• ضعف التعرف على الجداول: أشارت الورقة البحثية نفسها إلى أن TEDS الخاصة بالجداول الإنجليزية على OmniDocBench v1.0 (88.0) منخفضة نسبياً (مع تفسير بتأثير أخطاء التعليق). المستندات الغنية بالجداول تستلزم تحققاً منفصلاً.

خلاصة القول، PaddleOCR-VL خيار مُغرٍ جداً بوصفه نموذج تحليل مستندات “صغيراً لكن قوياً” لاستخبارات المستندات ذاتية الاستضافة. غير أن استخراج قيمته الحقيقية في الإنتاج يتطلب معالجة ثلاثة تحديات تشغيلية معاً: خدمة GPU، وتثبيت الإصدارات، ومعالجة المدخلات الأولية.

المصادر

• ورقة PaddleOCR-VL البحثية (arXiv:2510.14528): Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model
• بطاقة النموذج على Hugging Face: PaddlePaddle/PaddleOCR-VL
• الكود المصدري: github.com/PaddlePaddle/PaddleOCR
• أُجريت التجارب الواردة في هذا المقال على بيئة ThakiCloud (macOS، معالج مركزي) مباشرة، وأرقام المعايير المُستشهد بها مستقاة من الورقة البحثية المذكورة أعلاه.

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

مع جعل المحاكاة توليد الخبرة شبه مجاني، يزداد سؤال واحد حدّة: كم من بيانات البشر، وبأي شكل، يستحق الاستخدام فعلًا؟ في تعلّم سياسات القيادة يرتبط هذا السؤال مباشرة بالتكلفة. فجمع عروض القيادة البشرية على نطاق واسع مكلف وبطيء، بينما الـ self-play داخل محاكٍ رخيص وغير محدود تقريبًا.

ورقة من جامعة نيويورك وبرينستون ومتعاونين بعنوان “Human-like autonomy emerges from self-play and a pinch of human data” (arXiv:2606.19370، يونيو 2026) تقدّم إجابة واضحة. كما يقول العنوان، حفنة تكفي. وعمليًا، فإن 30 دقيقة فقط من بيانات القيادة البشرية، أي أقل بـ 2500 مرة من التعلّم بالتقليد، تُنتج سياسة أكثر توافقًا مع البشر. ويكتمل التدريب بأكمله في 15 ساعة على GPU استهلاكي واحد.

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

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

ما هذا البحث

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

كانت المعالجات السابقة تعني هندسة المكافآت بعناية أو نشر التعشية النطاقية. وكلاهما كثيف العمل وهشّ. تقلب هذه الورقة الفكرة. فبدل استخدام بيانات البشر كإشارة تعلّم رئيسية، تحوّل سياسة مرساة بالاستنساخ السلوكي (BC) إلى حدّ تنظيم. تبقى المكافأة بسيطة ومتفرّقة (+1 لبلوغ الهدف، -1 للاصطدام أو الخروج عن الطريق، و0 فيما عدا ذلك)، ويُضاف حدّ KL نحو سياسة المرساة إلى خسارة PPO. وتتحكّم λ في القوة؛ وحين تكون λ صفرًا يُختزل الأمر إلى self-play صرف دون تنظيم.

البنية الكاملة موضّحة أدناه. محرّك self-play رخيص هو القوة الدافعة الرئيسية، ومرساة بشرية مدتها 30 دقيقة تسحب السياسة بلطف نحو البشر عبر خيط رفيع من تنظيم KL.

يستحق قرار تصميمي واحد التأكيد. فحدّ KL هذا يسحب السياسة نحو المرساة لا على توزيع البيانات المسجّلة دون اتصال (offline) بل على الحالات التي تزورها السياسة فعلًا، وهو تنظيم على المسار (on-policy). فإن نظّمت فقط على توزيع BC غير المتصل، لا تستطيع منع السياسة من الانحراف عن توزيع الحالة في الحلقة المغلقة الذي تراه عمليًا. أما KL على المسار فيستدعي المرساة عند نقطة انزياح التوزيع تلك بالضبط. يبدو الأمر طفيفًا لكنه يحكم استقرار الحلقة المغلقة.

تُدرَّب سياسة المرساة نفسها بالـ BC على مسارات سيارة القيادة الذاتية فقط. فمسارات المركبات المحيطة مُعاد بناؤها بواسطة طبقة إدراك، لذا فهي مشوّشة وجودة قيادتها غير مضمونة؛ ولذا تُستخدم أنظف إشارة فقط، أي مسار المركبة الذاتية. يُنتج كل سيناريو نحو 9 ثوانٍ من البيانات، فتبلغ 200 سيناريو نحو 30 دقيقة. ولادعاء “أقل بـ 2500 مرة” اشتقاق صريح: 200 سيناريو في 9 ثوانٍ تساوي 30 دقيقة، بينما مجموعة Waymo الكاملة بنحو 500,000 سيناريو في 9 ثوانٍ تساوي نحو 75,000 دقيقة، أي نسبة حوالي 0.0004.

المنهجية الأساسية: من إشارة رئيسية إلى مرساة

هيكل المنهجية نظيف. الخسارة هي حدّ تدرّج السياسة المقصوص (clipped surrogate) في PPO مضافًا إليه خسارة القيمة ومكافأة الإنتروبيا، مع حدّ تنظيم KL فوقها. وهو أقرب إلى تركيب دقيق لمكوّنات معروفة جيدًا منه إلى خوارزمية جديدة.

تكمن المساهمة الحقيقية لا في الجدّة الخوارزمية بل في نظافة القياس التي أتاحتها البنية التحتية. وسّع الباحثون خبرة الـ self-play إلى 20 مليار انتقال على المحاكي عالي الإنتاجية GPUDrive، وهو ما يعادل نحو 63 عامًا من القيادة البشرية. كانت الأعمال السابقة مقيّدة بسرعة المحاكي (نحو 2000 خطوة في الثانية) عند 140 مليون انتقال ونحو 5 أيام تدريب، فلم يتبقَّ مجال لدراسة توسيع كمية بيانات البشر كمحور مستقل. وبإزالة عنق زجاجة الإنتاجية عبر GPUDrive، أصبحت تجربة التوسيع المنفصل لـ”كمية الـ self-play” و”كمية بيانات البشر” ممكنة لأول مرة.

يكشف هذا الفصل عدم تماثل مثير للاهتمام. فانتقالات الـ self-play تُوسَّع حتى 20 مليارًا، بينما بيانات البشر قريبة من التشبّع عند 30 دقيقة. واستخدام مرساة مدتها 30 ساعة لا يغيّر إلا قليلًا. تتسطّح المنفعة الحدّية للبيانات البشرية الإضافية بسرعة، وهذا هو الأساس التجريبي لرسالة أن حفنة تكفي.

النتائج التجريبية الفعلية

مجموعة البيانات هي Waymo Open Motion Dataset (WOMD). ولأجل تقييم human-replay الذي يقيس التوافق البشري، تُرشَّح السيناريوهات لرفع إشارة التفاعل. فمن بين 10,000 سيناريو تحقّق محجوزة، يُسجَّل مسار المركبة الذاتية بحسب مقدار تقاطعه مع مسارات الوكلاء الآخرين، مع الإبقاء على أعلى 200 مشهد تفاعلي فقط مثل الاندماج والإفساح والتقاطعات المزدحمة التي تتطلب تنسيقًا حقيقيًا.

تُلخَّص النتائج الأساسية في المخطط أدناه. كل رقم مُبلَّغ عنه في الورقة؛ ولا شيء مُختلَق.

النقاط الأساسية كما يلي.

• يحقّق spiced self-play معدل اصطدام بخطأ ذاتي بين 0.6% و0.7% ببيانات بين 30 دقيقة و3 ساعات. ومقارنة بخط الأساس للتعلّم بالتقليد SMART-tiny-CLSFT (1.6%، مُدرَّب على مجموعة Waymo الكاملة، نحو 52 يومًا من البيانات)، يمثّل ذلك تحسّنًا بنحو 2.5 مرة.
• بلغ معدل الاصطدام بخطأ ذاتي لـ self-play النقي دون تنظيم 2.1%. وإضافة حفنة من المرساة فقط جعلته أكثر أمانًا بنحو 3.5 مرة.
• يتجنّب التقييم التباهي بمقياس واحد. فهو ينظر إلى النتيجة ومعدل الإكمال ومعدل الاصطدام ومعدل الاصطدام بخطأ ذاتي وشدّة الاصطدام Δv عبر ثلاث بيئات: self-play (يتشارك جميع الوكلاء السياسة)، وhuman-replay (المركبة الذاتية فقط هي السياسة، والبقية تعيد تشغيل السجلات)، وIDM (الآخرون قائمون على قواعد وتفاعليون).

يختلف الاتساق الداخلي أيضًا. فيُبقي spiced self-play معدل الاصطدام دون 1.5% في بيئة الـ self-play وفي cross-play مع سجلات البشر، بينما يرتفع خط أساس التعلّم بالتقليد إلى نحو 6% في بيئة الـ self-play، مُظهرًا اتساقًا أضعف. ويوضّح الباحثون أن عدم استقرارية بيئة الـ self-play، أي توزيع شريك متغيّر يتحوّل فيه خصم شبه عشوائي ابتداءً إلى كفء تدريجيًا، تساعد فعلًا على التقارب نحو أعراف متبادلة متّسقة.

لكن ليست كل الصورة وردية. فمقياس Waymo Open Sim Agent Challenge (WOSAC) الميتا للواقعية التوزيعية يرتفع من 0.68 لـ self-play النقي إلى 0.725 للنسخة المُنظَّمة، لكن المكسب صغير نسبةً إلى التحسّن الدرامي في الأمان وغير حسّاس تقريبًا للبيانات المضافة. فقد تكون السياسة آمنة وأقل شبهًا بالبشر توزيعيًا في الوقت ذاته، وهي نقطة نعود إليها أدناه.

التطبيق على منصّة ThakiCloud للـ AI/ML SaaS على K8s

القيادة بحد ذاتها ليست مجال ThakiCloud المباشر. ومع ذلك تنتقل الدروس المنهجية لهذه الورقة بشكل شبه مباشر إلى بنيتنا متعددة الوكلاء والتعلّم المعزّز والمحاذاة.

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

ثانيًا، فكرة تنظيم KL على المسار لها إمكان قوي للدمج مع بوّابة التحقّق fan-out لدينا. فيمكننا إطلاق عمّال كثيرين بحرية كالـ self-play، ثم تثبيتهم بمجموعة صغيرة من المسارات الذهبية المعتمدة بشريًا تحت تنظيم KL لكبح الانحراف نحو أعراف غريبة مثل الهلوسة أو انحراف التنسيق. والمفتاح هو تطبيق التنظيم لا على مجموعة ذهبية ثابتة غير متصلة بل على الحالات التي يزورها العمّال فعلًا، وهي بنية تستحق إثبات مفهوم على منصّتنا.

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

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

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

إنه عمل علمي تجريبي رصين، لكن بقراءة نقدية تبقى ثلاثة توتّرات.

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

ثانيًا، عدم التماثل بين مكاسب الواقعية التوزيعية ومكاسب الأمان غير مُفسَّر بالكامل. فانتقال مقياس WOSAC الميتا من 0.68 إلى 0.725 متواضع بجانب التحسّن الكبير في معدل الاصطدام، وهو غير حسّاس لمزيد من البيانات. فقد تكون السياسة آمنة وأقل شبهًا بالبشر توزيعيًا، وهو ما يتوتّر مع العنوان القوي “human-like autonomy emerges”. وعدم مواجهة المتن لهذه الفجوة مباشرة يترك مجالًا للمبالغة في الادعاء.

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

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

المصادر

• الورقة: Human-like autonomy emerges from self-play and a pinch of human data (arXiv:2606.19370)، https://arxiv.org/abs/2606.19370
• Hugging Face Papers: https://hf.co/papers/2606.19370
• صفحة المشروع (مقاطع فيديو والمصدر الكامل): https://spiced-self-play.com/

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

طالما تطلّب إنتاج الفيديو محرّرات مخصّصة ولمسة بشرية. لكن مؤخرًا ترسّخ نمط حيث يُوصَف الفيديو بالشيفرة ويُعرَض، تمامًا كما تكتب وكلاء البرمجة الشيفرة. يضع digitalsamba/claude-code-video-toolkit هذا النمط فوق Claude Code. عند إصداره يُظهر نحو 1.6 ألف نجمة على GitHub و268 تفريعة و182 إيداعًا، برخصة MIT.

الفكرة الأساسية بسيطة. تصف مشروع فيديو باستخدام Remotion، وهو إطار قائم على React؛ وتفوّض توليد الأصول مثل الصوت والصور والموسيقى ولقطات الـ b-roll إلى نماذج ذكاء اصطناعي مفتوحة المصدر؛ وتربط العملية كلها بأوامر الشرطة المائلة ومهارات Claude Code. ينشئ المستخدم مشروعًا من قالب بأمر /video واحد، ويهيّئ وحدة GPU السحابية والتخزين والصوت بأمر /setup، ثم ينتقل إلى العرض.

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

ما هذه الأداة

تحوّل claude-code-video-toolkit بيئة Claude Code إلى محطة عمل لإنتاج الفيديو. من المفيد فهمها في ثلاث طبقات.

الأولى هي طبقة أوامر الشرطة المائلة. يرشدك /setup تفاعليًا عبر التهيئة الأولى مثل GPU السحابية ونقل الملفات والصوت. ينشئ /video المشاريع ويفتحها، ويساعد /scene-review في المراجعة مشهدًا مشهدًا داخل Remotion Studio. وإلى جانب ذلك توجد أوامر لكل مرحلة من مراحل الإنتاج: /brand و/template و/generate-voiceover و/voice-clone و/redub و/record-demo و/publish وغيرها. يرفع /publish الفيديو المكتمل إلى YouTube ويملأ البيانات الوصفية تلقائيًا من project.json.

الثانية هي طبقة المهارات. تجمّع هذه المعرفة المجالية كي يتعامل معها Claude Code بعمق: remotion (إطار فيديو قائم على React)، وelevenlabs (الصوت)، وffmpeg (معالجة الوسائط)، وplaywright-recording (تسجيل العروض في المتصفح)، وfrontend-design (التصميم البصري)، وqwen-edit (تحرير الصور)، وideogram4 (توليد صور بنص داخلي قوي)، وacestep (الموسيقى)، وltx2 (مقاطع فيديو مدفوعة بالنص والصورة)، وmoviepy (تركيب فيديو بلغة بايثون)، وrunpod (وحدة GPU سحابية)، بإجمالي إحدى عشرة مهارة.

الثالثة هي طبقة القوالب والعلامة التجارية. يتضمّن templates/ قوالب sprint-review وsprint-review-v2 وproduct-demo وconcept-explainer-short للمقاطع العمودية بنسبة 9:16. ويعرّف brands/ ملفات علامة تجارية تحمل الألوان والخطوط وإعدادات الصوت، وتُطبَّق تلقائيًا عند إنشاء مشروع بأمر /video. يوضّح المخطط أدناه كيف تتصل هذه الطبقات الثلاث في خط إنتاج واحد.

flowchart LR
  A["موجّه / سكربت"] --> B["أمر /video"]
  B --> C["ملف العلامة التجارية<br/>brand.json · voice.json"]
  C --> D["تركيبة Remotion<br/>فيديو React"]
  D --> E["طبقة مهارات الذكاء الاصطناعي"]
  E --> E1["Qwen3-TTS<br/>صوت · استنساخ"]
  E --> E2["FLUX.2 · Ideogram4<br/>صور · بطاقات عناوين"]
  E --> E3["ACE-Step<br/>موسيقى"]
  E --> E4["LTX-2<br/>b-roll"]
  D --> F["remotion render<br/>h264 · 1080p · 6x"]
  F --> G["out/video.mp4"]
  G --> H["/publish → YouTube"]

تبرز بنية التكلفة على نحو خاص. صُمّمت الأداة كي تعتمد الأصول التوليدية مثل الصوت (Qwen3-TTS) والصور (FLUX.2) والموسيقى (ACE-Step) على نماذج مفتوحة المصدر بدلًا من واجهات API تجارية. تنشر النماذج على حساب GPU السحابي الخاص بك وتشغّلها بسعر التكلفة. للتخزين تشير إلى الطبقة المجانية من Cloudflare R2 (10 غيغابايت، دون رسوم خروج)، وللحوسبة إلى خطة Modal Starter برصيد مجاني 30 دولارًا شهريًا. هذا الخيار القائم على الاستضافة الذاتية يتطابق تمامًا مع منظور المنصة الذي سنناقشه لاحقًا.

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

البدء السريع الموثّق كالتالي: استنساخ المستودع، وتثبيت اعتماديات بايثون اختياريًا، وفتح Claude Code.

git clone https://github.com/digitalsamba/claude-code-video-toolkit.git
cd claude-code-video-toolkit
python3 -m pip install -r tools/requirements.txt   # اختياري: التعليق الصوتي وتوليد الصور والموسيقى وأمثلة moviepy
claude                                              # تشغيل Claude Code داخل الأداة

ثم داخل Claude Code، تهيّئ GPU السحابية والتخزين والصوت تفاعليًا لنحو خمس دقائق بأمر /setup، وتنشئ مشروعك الأول بأمر /video. المتطلبات هي Node.js 18+ وClaude Code؛ ويُنصح ببايثون 3.9+ لأدوات الذكاء الاصطناعي. أما FFmpeg فاختياري.

الأهم هنا أن ثمة مسارًا منفصلًا للتحقق من العرض فورًا دون أي تهيئة. examples/hello-world مثال مصغّر لا يحتاج أي مفاتيح API. اتّبعت هذا المسار بالضبط وشغّلته فعليًا.

cd examples/hello-world
npm install
npm run render

بالنظر إلى package.json الخاص بـ hello-world، يكون سكربت العرض npx remotion render src/index.ts SprintReview out/video.mp4، والاعتماديات هي إصدار Remotion 4.0.425 وReact 18. أي إنه يحوّل تركيبة React مباشرة إلى فيديو دون أي استدعاءات نماذج خارجية.

نتائج التجربة الفعلية

أجريت التحقق داخل شجرة عمل git معزولة، وكل رقم مأخوذ مباشرة من سجل التشغيل. كانت البيئة Apple Silicon (arm64) وNode.js 24.1.0 وnpm 11.3.0.

أولًا، تثبيت الاعتماديات. أضاف npm install نحو 230 حزمة واستغرق قرابة 3.5 ثانية. لكن التدقيق أبلغ عن 10 ثغرات (7 متوسطة و3 عالية)، وهو ما أعود إليه في قسم القيود.

في خطوة العرض، ينزّل Remotion مرة واحدة عند التشغيل الأول Chrome Headless Shell. في هذا التشغيل نزّل نحو 90.2 ميجابايت، وهي تكلفة لمرة واحدة. ثم تلت ذلك عملية التجميع والتركيب. كانت التركيبة SprintReview، والترميز h264، والتزامن 6x، وعرض كامل الإطارات البالغة 750 إطارًا. ترك السجل الملاحظة “Cached bundle. Subsequent renders will be faster”، موضحًا أن عمليات العرض اللاحقة أسرع بفضل ذاكرة التجميع المؤقتة.

من حالة باردة، بلغ الزمن الفعلي لأمر npm run render، شاملًا التنزيل والتجميع والعرض والترميز، 18.4 ثانية. كان الناتج النهائي فيديو h264 بدقة 1920x1080 و30 إطارًا في الثانية وطول 25.0 ثانية وحجم 2.15 ميجابايت (2,152,829 بايت)، متضمنًا مسار صوت AAC. لم يُستخدم أي مفتاح API على الإطلاق.

الزمن الفعلي لكل مرحلة في خط عرض hello-world بدقة 1080p، مقاسًا دون أي مفاتيح API.

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

التطبيق على منصة ThakiCloud السحابية للذكاء الاصطناعي على Kubernetes

تكمن جاذبية هذه الأداة في أنها تشبه بنيويًا الأحمال التي تتعامل معها منصتنا. عرض الفيديو وتركيب الأصول التوليدية كلاهما مهام دفعية مرتبطة بوحدة GPU، بنمط استخدام الموارد في دفعات قصيرة وكثيفة قبل العودة إلى الخمول. تصفّ ThakiCloud مهام GPU وتمنحها الأولوية باستخدام Kueue فوق Kubernetes وتخدم النماذج عبر vLLM وغيره. إن الاستمرارية اللاخادمية بأسلوب Modal/Daytona التي توصي بها الأداة، حيث تدخل البيئة في سبات عند الخمول وتستيقظ عند الطلب، تحل المشكلة نفسها لكفاءة الموارد التي نسعى إليها عبر Kueue، لكن في طبقة مختلفة.

النقاط الجديرة بالإبراز هي التكلفة والاستضافة الذاتية. صُمّمت الأداة لتشغيل نماذج مفتوحة الأوزان مثل Qwen3-TTS وFLUX.2 وACE-Step على وحدة GPU الخاصة بك بسعر التكلفة بدلًا من واجهات API تجارية. يتوافق هذا تمامًا مع توجّه ThakiCloud في اعتبار التشغيل المحلي والاستضافة الذاتية نقاط قوة. حين يرغب عميل في تشغيل أحمال توليدية متعددة المستأجرين في بيئة عالية الأمان دون إرسال بيانات أو نماذج إلى الخارج، يمكن لمنصتنا أن تستوعب بطبيعتها خط إنتاج الفيديو والوسائط هذا أيضًا.

زاوية الاستخدام الداخلي واضحة كذلك. قالبا sprint-review وproduct-demo من المخرجات التي تنتجها فرق الهندسة بشكل متكرر. وإذا غلّفت هذا التوليد للفيديو كمهام Kubernetes ووضعتها في طابور Kueue، أمكنك نقل العرض الثقيل من حواسيب المطورين المحمولة إلى مجمّع GPU مشترك يُعالج بحسب الأولوية. كون الأداة نفسها مرتبطة بـ Claude Code قيدٌ، لكن فصل مرحلة عرض Remotion وحدها وتحويلها إلى حاوية يجعل وضعها على بنيتنا الدفعية أمرًا مباشرًا.

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

ثمة نقاط ضعف واضحة إلى جانب نقاط القوة. أولًا، أمان الاعتماديات. حتى npm install للمثال المصغّر أبلغ عن 10 ثغرات (منها 3 عالية). لطرحها في الإنتاج تحتاج أولًا إلى تدقيق الاعتماديات وتثبيتها، والأأمن فرض ذلك كبوابة في خط الأتمتة لديك.

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

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

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

خلاصة القول، يُعدّ claude-code-video-toolkit نقطة انطلاق جيدة لأتمتة الفيديو الصديقة للشيفرة. تجربة إنتاج فيديو 1080p خلال 30 ثانية دون مفاتيح API نقطة قوة واضحة، وفلسفته القائمة على النماذج مفتوحة المصدر والاستضافة الذاتية تتوافق جيدًا مع توجّه منصتنا. ومع ذلك، تحتاج إلى موازنة التكلفة الحقيقية لمرحلة الأصول التوليدية وأمان الاعتماديات والارتباط بالأداة معًا للوصول إلى حكم متوازن.

المصادر

• GitHub: digitalsamba/claude-code-video-toolkit
• Remotion: remotion.dev
• بيئة الاختبار: Apple Silicon (arm64)، Node.js 24.1.0، npm 11.3.0 / جميع الأرقام مستخرجة مباشرة من سجلات التشغيل.

انتشر مؤخرًا اقتباس بسرعة في مجتمعات المطورين: يُقال إن مبتكر Claude Code صرّح بأن “Fable 5 صار يكتب 100% من شيفرتي، وهو أقوى من Opus بثلاثة أضعاف على الأقل.” بمفردها، جملة كهذه أقرب إلى ادعاء تسويقي يصعب التحقق منه. لذلك يفصل هذا المقال أمرين عن قصد: ما هو مؤكَّد رسميًا، وتحليل كيف تُغيِّر هذه الحقائق المؤكَّدة طريقة عمل فرق الهندسة فعليًا.

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

نفصل الحقائق المؤكَّدة عن الاقتباس

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

أما ما تؤكده الوثائق العامة فهو الآتي. إن Claude Fable 5 هو أقدر نموذج متقدم متاح للعموم تطرحه Anthropic، وقد أُعلن في يونيو 2026 إلى جانب نموذج Claude Mythos 5 محدود الإصدار. معرّف النموذج هو claude-fable-5. التسعير 10 دولارات لكل مليون رمز إدخال و50 دولارًا لكل مليون رمز إخراج، أي نحو ضعف سعر Opus 4.8. المعالجة الدُّفعية بنصف ذلك عند 5 دولارات للإدخال و25 دولارًا للإخراج، ويهبط الإدخال عند إصابة ذاكرة التخزين المؤقت للموجِّهات إلى دولار واحد لكل مليون رمز. نافذة السياق مليون رمز افتراضيًا، مع إخراج يصل إلى 128 ألف رمز لكل طلب.

أما من حيث الأداء، فادعاء الشركة المعلن هو أنه في معيار تحليلي أساسي يقيس المهام التحليلية المعقدة طويلة الأمد، صار أول من يتجاوز 90%، بتحسُّن نحو 10 نقاط على Opus [تقدير: وفق إعلان الشركة]. كما أوضح فريق Claude Code أنه لأن Fable 5 يعمل لفترة أطول ويتحقق من نفسه وينتج شيفرة أعلى جودة، فإن دور الإنسان ينتقل من “مراقبة ما إذا كان يؤدي العمل بشكل صحيح” إلى “توجيه ما إذا كان يؤدي العمل الصحيح”. هذه الجملة الأخيرة هي في الواقع أهم نقطة في هذا المقال.

ما الذي يختلف في البرمجة الوكيلية

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

[ الإنسان: يحدد النية/الهدف ]
        |
        v
[ الوكيل: يضع خطة ] ---> [ يكتب الشيفرة ] ---> [ اختبار/تشغيل ]
        ^                                            |
        |                                            v
[ الإنسان: مراجعة الاتجاه (توجيه) ] <--- [ حلقة تحقق/إصلاح ذاتي ]
                                              |
                                              v
                                   [ تقديم التغيير عند النجاح ]

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

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

ماذا يعني “كتابة الذكاء الاصطناعي 100% من الشيفرة” لفريق

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

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

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

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

تطبيقه على منصة ThakiCloud السحابية على Kubernetes

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

أولًا، بنية التكلفة. سعر رمز الإخراج في Fable 5 هو 50 دولارًا لكل مليون رمز، وهو ليس رخيصًا بأي حال. حين يشغّل الوكيل حلقة ذاتية طويلة، يصبح استهلاك الرموز غير قابل للمقارنة بتبادل سؤال وجواب واحد. حتى الحالة المذكورة سابقًا ببناء لعبة صغيرة واحدة في تمريرة واحدة استهلكت نحو 910 آلاف رمز. لذا فلاستخدام البرمجة الوكيلية على مستوى المؤسسة، تحتاج إلى انضباط في تتبُّع ميزانية الرموز لكل وحدة عمل، وتوجيه النماذج وفق صعوبة المهمة. نماذج رخيصة للاستكشاف البسيط وقراءة الملفات، ونماذج متقدمة فقط للاستدلال المعقد متعدد الخطوات. كما أن تصميمًا يخفض تكلفة الإدخال بنسبة 90% عبر التخزين المؤقت للموجِّهات هو أيضًا رافعة أساسية لضبط التكلفة. تتعامل ThakiCloud مع هذا النوع من التوجيه ونظافة التخزين المؤقت بوصفه إعدادًا افتراضيًا على مستوى المنصة.

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

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

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

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

لتجنّب قبول هذا الاتجاه دون نقد، نذكر الحجج المضادة بوضوح.

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

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

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

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

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

المصادر

• Anthropic، صفحة “Claude Fable” الرسمية: https://www.anthropic.com/claude/fable
• Anthropic، “Introducing Claude Fable 5 and Claude Mythos 5” (وثائق Claude API): https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• Anthropic، تسعير Claude API: https://platform.claude.com/docs/en/about-claude/pricing
• ClaudeDevs، “Claude Fable 5 is here … get started in Claude Code”: https://x.com/ClaudeDevs/status/2064394919549210774

نظرة عامة

كلما ازداد إطار الوكيل قوة، ازدادت وثائقه عرقلةً على نحو متناقض. فمع نمو الميزات بسرعة تنتفخ صفحات الوثائق إلى المئات، ويصبح العثور على السطر الذي تحتاجه فعلًا أصعب فأصعب. وHermes Agent الذي أطلقته Nous Research في فبراير 2026 ليس استثناءً. فالوثائق الرسمية منظّمة جيدًا لكنها ضخمة، وفوق ذلك تتناثر المعرفة العملية التي يتشاركها المجتمع على X (تويتر) وغيره.

Hermes Bible (hermesbible.com) موقع مجتمعي غير رسمي يواجه هذه المشكلة مباشرة. يفهرس كل صفحة من وثائق Hermes Agent الرسمية إلى جانب سير عمل واقعية بناها المجتمع في مكان واحد، ويوفّر بحثًا نصيًا كاملًا بضغطة مفتاح واحدة. ويذكر الموقع نفسه بوضوح أنه “غير رسمي، من بناء المجتمع، وغير تابع لـ Nous Research”.

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

ما هذا الموقع

الوظيفة الأساسية لـ Hermes Bible هي الفهرسة والبحث. يحتوي الموقع على 169 صفحة من وثائق Hermes Agent مقسّمة إلى 10 أقسام: Getting Started (6 صفحات تشمل التثبيت والبدء السريع ومسار التعلّم)، وCore Features (45 صفحة تشمل نظرة عامة على الميزات والأدوات ونظام المهارات والمنسّق)، وMessaging Platforms (30 صفحة تشمل بوابة المراسلة وتيليجرام وديسكورد وسلاك)، وSecrets (صفحتان)، وSkills، وUsing Hermes (15 صفحة تشمل CLI وTUI والإعداد وتهيئة النماذج)، وغيرها.

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

flowchart LR
  A["وثائق Hermes Agent الرسمية<br/>169 صفحة · 10 أقسام"] --> C["Hermes Bible<br/>فهرس نصي كامل (غير رسمي)"]
  B["سير عمل المجتمع<br/>28 سير عمل واقعي"] --> C
  C --> D["بحث نصي كامل غامض ⌘K<br/>عناوين · أقسام · ترويسات"]
  D --> E["نتائج فورية فور الكتابة<br/>دون تحميل"]
  C --> F["تصفّح /docs<br/>10 أقسام"]
  C --> G["/flows<br/>البنى · اقتصاد الرموز"]

عامل التمييز هو مكتبة Flows. فإلى جانب الوثائق الرسمية، تجمع 28 سير عمل واقعيًا لأتمتة متعددة الوكلاء بناها المجتمع فعلًا. ويُنظَّم كل سير عمل بحيث يمكنك البحث فيه ودراسته وتكييفه، شاملًا البنية الكاملة واقتصاد الرموز وأنماط التنسيق. فمثلًا تقدّم إحدى المقالات لوحة Hermes (localhost:9119) التي “لا يتحدث عنها أحد لكنني أفتحها كل يوم” بوصفها سطح تشغيل للحفاظ على صحة وكيل يعمل على مدار الساعة، وتغطي Sessions وMCP وSkills وCron وAnalytics وLogs وSystem. وأخرى بعنوان “المستويات الخمسة عشر لاستخدام Hermes Agent” تعرض كل شيء من أول موجّه بضربة واحدة إلى أتمتة عمل تجاري عبر ملفات متعددة، مع اقتصاد الرموز، وتذكر أنها جرى التحقق منها مقابل Hermes Agent v0.17.0.

للمرجع، Hermes Agent نفسه مشروع برخصة MIT من Nous Research، يُظهر نحو 200 ألف نجمة على GitHub و35.7 ألف تفريعة وأكثر من 12 ألف إيداع حتى كتابة هذه السطور. ويعلن عن “حلقة تعلّم مغلقة” يصنع فيها الوكيل مهارات من التجربة ويحسّنها أثناء الاستخدام ويبني نموذجًا للمستخدم عبر الجلسات. ويمكن النظر إلى Hermes Bible بوصفه استجابة المجتمع لمواكبة هذا المشروع السريع التطوّر.

انعكاسات من منظور منصة ThakiCloud

النظر إلى Hermes Bible لا كموقع بحث فحسب بل كنمط يجعله درسًا مباشرًا لنا. تشغّل ThakiCloud داخليًا أكثر من 1000 مهارة وقاعدة تشغيل، وهي بالضبط المشكلة نفسها لـ “قابلية بحث المعرفة الهائلة” التي تواجهها وثائق Hermes Agent. وفي الواقع تمتلك منصتنا بالفعل بوابة بحث مهارات قائمة على BM25 تُبرز المرشحين في كل دورة عمل. ويوضّح بحث ⌘K النصي الفوري في Hermes Bible جيدًا، من جانب تجربة المستخدم، الطرح نفسه القائل إنه “كلما نمت المعرفة، صار البحث إنتاجية”.

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

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

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

أوضح القيود أنه غير رسمي. فـ Hermes Bible مشروع مجتمعي غير تابع لـ Nous Research، لذا لا ضمان بأن المحتوى المفهرس يطابق دائمًا أحدث الوثائق الرسمية. وHermes Agent مشروع سريع الحركة بأكثر من 12 ألف إيداع. والفهرس غير الرسمي يتأخّر بطبيعته، وخاصة في مجالات مثل الإعداد الحسّاس أمنيًا أو إدارة الأسرار يجب أن تعامل الوثائق الرسمية بوصفها المرجع النهائي.

ثانيًا، عليك مراعاة أن الوثائق الرسمية توفّر بالفعل نقاط دخول صديقة للآلة. إذ تقدّم وثائق Hermes Agent الرسمية ملف /llms.txt (نحو 17 كيلوبايت) الذي يفهرس كل صفحة بوصف قصير، وملف /llms-full.txt (نحو 1.8 ميجابايت) الذي يدمج كل شيء في ملف واحد. ولتحميل الوثائق دفعةً واحدة في نموذج لغوي كبير، يكون هذا المسار الرسمي أكثر موثوقية واستقرارًا. أي إن قوة Hermes Bible تكمن خالصةً في تجربة بحث الإنسان بسرعة وتصفّح سير عمل المجتمع.

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

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

المصادر

• Hermes Bible: hermesbible.com
• Hermes Agent (Nous Research): github.com/NousResearch/hermes-agent
• الوثائق الرسمية: hermes-agent.nousresearch.com/docs

For much of the past several years, AI progress has been driven by scale: train bigger models on more data, and compete on monolith benchmarks. But the hard problems of the real world demand a breadth of knowledge and skill that far exceeds any single benchmark score. The ability to judge which model fits which task, to divide planning from execution, and to combine the strengths of different models – collective intelligence – is emerging as the next axis of competition.

On June 22, 2026, Tokyo-based Sakana AI launched Sakana Fugu, a product aimed squarely at this shift. Fugu is a multi-agent system that dynamically coordinates multiple LLMs while presenting a single model API to the caller. What makes it notable is that Fugu itself is “a language model trained to call other models.” A model commands models.

This post analyzes Fugu’s architecture from the perspective of ThakiCloud, an operator of multi-tenant agent platforms. We examine why packaging orchestration inside a single model is a meaningful design choice, how to read the self-reported benchmarks, and what contradictions lurk in the product’s marketing claim that it reduces vendor lock-in.

What This Technology Is

Sakana Fugu is a multi-agent system that behaves like a single model. When a user sends a request to a single endpoint, Fugu decides how to handle it. Simple requests it handles directly; more complex tasks it routes to a coordinated team of specialist models. Model selection, delegation, verification, and synthesis all happen internally, so the complexity of a multi-agent system never surfaces in user code.

This is possible because Fugu is not a set of routing rules but a language model trained on orchestration itself. Fugu is specialized to understand when to delegate, how agents should communicate, and how to synthesize their outputs into a single trustworthy answer. The approach draws on two Sakana AI papers accepted at ICLR 2026: TRINITY (arXiv:2512.04695), which introduces an evolved LLM coordinator, and Conductor (arXiv:2512.04388), which studies learning to orchestrate agents in natural language.

One design detail worth noting: Fugu can recursively call its own instances within the agent pool. From the outside, you are calling one model; from the inside, a coordinated system of specialists is doing the work. The agent pool is designed to be swappable, with the stated goal of reducing dependence on any single provider.

Architecture: A Collaborative Ecosystem Behind a Single API

Fugu’s central claim is that “the orchestration model is the next frontier.” Since its founding, Sakana AI has argued that the most capable AI systems will be collaborative ecosystems, not isolated giant models. Fugu is the product manifestation of that belief.

Technically, Fugu handles four internal stages within a single API call:

• Selection: It reads the nature of the request and decides whether to handle it directly or which specialist models to engage.
• Delegation: It separates planning from execution and distributes sub-tasks to the appropriate agents.
• Verification: It checks each agent’s output internally.
• Synthesis: It combines the results into a single coherent answer.

All of this happens behind one line of OpenAI-compatible API. This contrasts with conventional multi-agent frameworks, which push complexity – graph definitions, message routing, state management – onto the developer. Fugu is an attempt to absorb that complexity into the model weights themselves. Compared to the multi-persona agent team structure ThakiCloud already operates, Fugu takes one step further: it makes the orchestrator a trained model rather than hand-written code.

Sakana AI has prior evidence for this direction. ALE-Agent, a coding orchestrator, placed 21st in a coding competition among 1,000 human experts. Fugu extends that experience into a general-purpose orchestration product.

Two Variants: Fugu and Fugu Ultra

At launch, Fugu is available in two variants sized for different workloads. Both are accessed through a single OpenAI-compatible API.

Fugu (standard) balances performance with low latency. It is a sensible default for interactive services such as coding assistance, code review, and chatbots. Teams with data, privacy, or compliance requirements can exclude specific agents from the pool. This opt-out capability is meaningful for regulated industries and customers with data-sovereignty requirements.

Fugu Ultra is tuned to maximize answer quality on difficult, multi-step problems. It draws on a deeper pool of specialist agents when accuracy and depth matter most. Early users have reportedly put Fugu Ultra to work on high-demand tasks such as AI research, paper reproduction, cybersecurity analysis, and literature and patent search.

The separation of these two variants is essentially a mechanism for exposing the cost-quality trade-off to the user. Orchestration inherently involves multiple model calls, so engaging a deeper pool drives up both latency and cost. Fugu surfaces that trade-off as two product lines.

How to Read the Benchmarks

Sakana AI announced that Fugu Ultra performs “shoulder-to-shoulder” with leading models such as Anthropic’s Fable 5 and Mythos Preview on challenging engineering, science, and reasoning benchmarks. That claim requires careful reading.

First, every baseline score other than Fugu’s own numbers comes from the respective model provider’s self-reports. This is not an independently controlled apples-to-apples comparison; it is a collection of self-announced figures. Second, the comparison targets – Fable 5 and Mythos Preview – are not publicly available and are not included in Fugu’s agent pool. Fugu is claiming near-parity with models it does not internally call. Third, the SWE-family tasks were scored using mini-swe-agent scaffolding. The choice of scaffolding materially affects results, so these cannot be treated as equivalent conditions.

At this point, the proposition that “Fugu Ultra is on par with frontier models” should be treated as a self-reported claim. The specific figures are compiled in Sakana AI’s technical report (github.com/SakanaAI/fugu), but until independent third-party verification accumulates, distinguishing marketing numbers from validated performance is prudent. This post does not cite individual unverified scores; it records only the nature of the claims.

Implications for ThakiCloud’s K8s AI/ML SaaS Platform

The questions Fugu raises map precisely onto ThakiCloud’s platform strategy. ThakiCloud operates multi-tenant agents across diverse customer environments, running an agent operations cloud called Praxis on top of K8s, Kueue-based GPU scheduling, and vLLM serving. The thesis Fugu is trying to prove – that “the orchestration layer itself becomes the product” – is the same direction we are already pursuing.

The core is hedging vendor lock-in. Sakana AI cited the risk of dependence on a single provider as the justification for launching Fugu. As the export-control episode around Anthropic’s Fable and Mythos models illustrated, regulatory boundaries or diplomatic policy shifts can change access to a specific API overnight. In critical sectors such as government, finance, and infrastructure, depending on a single company’s API is a real vulnerability. This logic is the same reason ThakiCloud has emphasized on-premises and self-hosting.

From ThakiCloud’s perspective, Fugu’s design offers two uses. First, it is valuable as a reference implementation of orchestration patterns. The structure of dynamically routing self-hosted open models on K8s – combining coding, reasoning, and domain-specialized models by task type – is an idea that maps directly onto Praxis agent operations. Second, opt-out-based compliance: the ability to exclude specific agents from the pool connects naturally to policies that restrict the set of permitted models per tenant in a multi-tenant environment.

Where ThakiCloud can differentiate from Fugu is clear, however. Fugu is a closed API; ThakiCloud offers a path to self-hosting the orchestration layer inside the customer’s own environment. For domestic customers that must address sovereignty, cost efficiency, and national-security requirements, the option to “put the orchestration inside our own cluster” is a decisive difference. Fine-tuning an open model at the level of Qwen3 for a specific domain, then self-hosting the orchestration layer on top of it, can deliver strong competitiveness at lower serving cost.

Limits and Counterarguments

Fugu is an interesting product, but its marketing logic has several points worth scrutinizing.

The biggest contradiction is that it creates a new dependency while claiming to reduce vendor lock-in. Fugu is a closed commercial API; it is not open-weight. A product launched on the logic that single-provider dependence is dangerous in turn requires dependence on a new single provider: Sakana AI. The fact that Fugu is not available in the EU/EEA at launch also demonstrates that this product, too, is subject to regulation and regional policy. Genuine vendor-lock-in hedging is only possible with self-hostable orchestration.

Second, cost and latency are unpredictable. A structure in which a model calls other models – and sometimes itself recursively – makes it hard to forecast how many model calls a single request will trigger internally. Modes like Fugu Ultra that engage deeper pools can deliver higher quality, but cost and latency may spike accordingly. For production teams managing SLAs and budgets, controlling this unpredictability is the key challenge.

Third, verification and debugging are harder. The fact that the internal delegation path is embedded in model weights is an advantage for ease of use, but it means that when a wrong answer appears, tracing which agent’s judgment caused the problem is difficult. In operational environments where observability matters, this opacity is a liability.

Fourth, as noted earlier, the performance claims are still at the self-reported stage. The comparison targets are non-public models not included in the pool, and the baselines are provider self-reports. Reserving judgment until independent reproduction and verification accumulate is the rational response.

Despite these reservations, the question Fugu raises – “Can orchestration be a learned capability rather than hand-written code?” – is one every multi-agent platform operator will have to face. ThakiCloud intends to answer that question with self-hostable, observable orchestration as its differentiator.

Sources

• Sakana AI, “Sakana Fugu: One Model to Command Them All”, 2026-06-22, sakana.ai/fugu-release
• Sakana Fugu Technical Report, Fugu Team, Sakana AI, 2026, github.com/SakanaAI/fugu
• Xu et al., “TRINITY: An Evolved LLM Coordinator”, ICLR 2026, arXiv:2512.04695
• Nielsen et al., “Learning to Orchestrate Agents in Natural Language with the Conductor”, ICLR 2026, arXiv:2512.04388
• THE DECODER, “Sakana AI’s Fugu orchestrates multiple LLMs to match Anthropic’s Fable and Mythos benchmarks”, 2026-06-22, the-decoder.com

The center of gravity in the AI race has been shifting from models to infrastructure, and within infrastructure, from compute to memory. GPU compute capacity has grown rapidly, but the real practical bottleneck for large language model inference has become how quickly data can be fed to that compute, which is to say, memory bandwidth.

On June 22, 2026, memory semiconductor company Micron and AI company Anthropic announced a strategic partnership. This goes well beyond a simple component supply contract: it bundles a multi-year supply agreement, co-design of memory and storage architecture for AI workloads, and an equity investment into a single comprehensive alliance. The partnership signals that memory is no longer a passive component but an active variable in AI system design.

This post reads the partnership through the lens of infrastructure technology rather than stock market reaction. It covers why memory has become the battleground of AI infrastructure, what co-designing memory and storage changes, and the implications for ThakiCloud as an operator of a K8s-based AI/ML serving platform.

What Happened

The core of the announced partnership has three components.

First, a multi-year supply agreement. Micron will supply Anthropic with high-bandwidth memory (HBM), DRAM, and solid-state drives (SSD), the key products for data center use. This is a long-term contract to secure stable supply volumes, not a one-off purchase.

Second, co-design of memory and storage architecture. The two companies agreed to jointly design memory and storage architectures optimized for AI workloads. In other words, this is a collaboration to align memory configuration and data paths with Anthropic’s model training and inference patterns. This is the aspect that most clearly distinguishes the deal from a plain supply contract.

Third, strategic equity investment. Micron made a strategic investment in Anthropic’s Series H funding round. The investment amount was not disclosed. Through this round, Anthropic was valued at approximately $965 billion [estimated], becoming the most valuable private AI company, with Samsung, SK hynix, Altimeter Capital, Sequoia, and Amazon among the reported participants. The agreement also includes deploying Claude across Micron’s internal operations.

Micron’s stock rose roughly 5.5% immediately after the announcement. The focus of this post, however, is not the share price but the technical implications this alliance carries for AI infrastructure design.

Why Memory Is the Bottleneck in AI Infrastructure

Inference for large language models is fundamentally a memory-bound workload. Every time a token is generated, the model’s full set of weights must be read from memory. No matter how fast the compute units are, if weights cannot be supplied quickly enough, the GPU sits idle waiting for data. As a result, inference throughput is often determined by memory bandwidth rather than compute capacity.

The memory hierarchy of an AI inference server is structured as shown in the diagram above.

• HBM (High-Bandwidth Memory): The ultra-fast memory closest to the GPU. It delivers bandwidth on the order of terabytes per second and holds active model weights and the KV cache. HBM is the direct bottleneck for inference throughput.
• DRAM (System Memory): Larger capacity than HBM but slower. Used to swap weights that do not fit in HBM or to hold larger contexts.
• SSD (Storage): Slowest but largest in capacity. Hosts model checkpoints, cold data, and an ever-growing share of KV cache offloading.

When a single company supplies the entire hierarchy, it becomes possible to optimize data movement across all layers under a coherent design philosophy. The fact that Micron covers HBM, DRAM, and SSD is the key strategic asset in this partnership.

What Co-Designing Memory and Storage Changes

Until now, memory has largely been purchased as a commodity to a standard specification. The noteworthy aspect of this partnership is that Micron and Anthropic will co-design memory and storage architectures tailored to AI workloads. This implies several shifts.

First, the data access patterns of inference and training can be directly reflected in memory design. For example, efficient paths for offloading the KV cache from HBM to DRAM or SSD, and structures that reduce the cost of crossing memory hierarchy boundaries during long-context processing, are problems that are better solved when the model provider and the memory provider design together.

Second, the partnership shows that AI infrastructure is becoming increasingly vertically integrated. It is a signal that frontier AI companies are trying to secure not just GPUs but also memory at the supply chain and design stage. The participation of memory companies like Samsung and SK hynix in the same Series H round can be read in the same light. Memory supply capability is being incorporated as part of AI competitiveness.

ThakiCloud K8s AI/ML SaaS Platform Perspective

This is a deal between large companies, but it carries direct lessons for ThakiCloud as an operator of a K8s-based AI/ML serving platform.

First, it reconfirms that memory is the starting point for serving cost optimization. ThakiCloud runs multi-tenant inference on top of vLLM and Kueue-based GPU scheduling. In this environment, the most effective lever for increasing throughput is often memory utilization, not compute. KV cache management, batching strategies, and model placement calibrated to HBM capacity are the key techniques for handling more concurrent requests on the same GPU. The reason technologies like vLLM’s PagedAttention receive attention ultimately comes down to memory efficiency.

Second, there is the economics of on-premises AI infrastructure. The trend of frontier companies securing memory as a strategic asset paradoxically highlights the value of on-premises self-hosting. When customers serve models on their own GPU and memory, the ability to tune the memory hierarchy to the workload determines total cost of ownership (TCO). ThakiCloud can provide more predictable and efficient inference costs than cloud API dependency by optimizing model placement and memory configuration within customer clusters.

Third, there is the sovereignty and supply chain perspective. The fact that memory has become the battleground of AI competition prompts a rethinking of the vulnerabilities in structures where domestic customers simultaneously depend on external clouds and external supply chains. Demand for keeping data and infrastructure in-house through on-premises and self-hosting, especially in domains subject to national security or regulatory requirements, strengthens in this context.

Caveats and Counter-Arguments

To avoid over-interpreting this partnership, several points deserve attention.

First, a substantial portion of the public information remains at the press release level. What specific technical outputs the co-design of memory and storage architecture will produce, and the amounts of investment and supply volumes involved, have not been disclosed. The practical impact of the partnership therefore needs to be confirmed through future products and data; assessment at this point is closer to an interpretation of direction.

Second, it is important to distinguish between commercial and financial motivations and technical significance. The equity investment and internal Claude deployment are mechanisms to strengthen business ties; they do not in themselves guarantee advances in memory technology. Figures like the $965 billion [estimated] valuation or the stock price gain reflect market expectations and do not connect directly to infrastructure performance.

Third, while the premise that memory bandwidth is the bottleneck holds broadly across inference workloads, it does not apply equally in all cases. With smaller models, high batch throughput, or compute-intensive stages, compute can be the bottleneck. The simplification that “more memory solves everything” should be resisted; measuring the bottleneck empirically for each workload and responding accordingly is the correct approach.

In conclusion, the Micron-Anthropic partnership is a meaningful signal that competition in AI infrastructure is expanding beyond compute to the entire memory hierarchy. ThakiCloud intends to use this trend as a foundation for strengthening our strengths in memory-efficient serving and on-premises economics.

Sources

• Micron Technology, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, investors.micron.com
• Yahoo Finance, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, finance.yahoo.com
• Crypto Briefing, “Micron signs supply agreement with Anthropic AI, invests in Series H round”, 2026-06-22, cryptobriefing.com

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

Overview

Document parsing – converting documents into machine-readable structure – has regained importance in the era of RAG and AI agents. A single PDF page can mix body text, tables, formulas, charts, and multi-column layouts, and untangling all of that in the correct reading order is a prerequisite for LLMs to reason over it effectively. Until now, this space has been dominated by large multimodal models like GPT-4o or Gemini 2.5 Pro, or by heavy pipeline-based tools.

PaddleOCR-VL, released by the PaddlePaddle team at Baidu, challenges that picture. Its core model, PaddleOCR-VL-0.9B, has roughly 960 million parameters – an ultra-compact vision-language model – yet it reports top-tier performance on both page-level document parsing and element-level recognition. The license is Apache-2.0, meaning unrestricted commercial use, and the model has already accumulated over 120,000 downloads on Hugging Face.

At ThakiCloud, we operate multi-tenant inference and document processing workloads directly on our Kubernetes-based AI/ML SaaS platform. So instead of just summarizing the paper, we installed the model ourselves and ran inference on documents mixing Korean, English, and Arabic. The goal: find out whether a small model is genuinely usable in practice and where it fits in our platform.

What This Technology Is

The core design philosophy of PaddleOCR-VL is: do not handle everything with a single large end-to-end VLM. End-to-end approaches rely on long autoregressive decoding, which is costly in latency and memory, and they are prone to hallucinations and instability on multi-column or mixed layouts. PaddleOCR-VL separates the work into two stages instead.

Two-stage structure separating layout analysis from element recognition.

Stage 1, Layout Analysis (PP-DocLayoutV2): A lightweight dedicated model locates and classifies semantic regions in the document, then predicts reading order. It uses RT-DETR for object detection and a pointer network with 6 transformer layers for reading order prediction. By offloading layout reasoning from the heavy VLM into a separate module, the pipeline achieves stable results even on complex multi-column layouts.

Stage 2, Element Recognition (PaddleOCR-VL-0.9B): This stage receives the regions identified in Stage 1 and performs fine-grained recognition of body text, tables, formulas, and charts. The architecture follows the LLaVA family, but uses a NaViT-style dynamic-resolution encoder (initialized from the Keye-VL vision model) as its visual backbone, enabling lossless processing of arbitrary-resolution images. A 2-layer MLP projector with GELU activation (merge size 2) bridges visual features into the language model’s embedding space, and the decoder is ERNIE-4.5-0.3B with 3D-RoPE. Choosing a small language model as the decoder is a deliberate speed tradeoff – smaller decoders decode faster per token.

A lightweight post-processing module then merges the outputs of both stages into structured Markdown and JSON. The model supports 109 languages, covering not only Latin scripts but also Korean, Japanese, Arabic, Cyrillic, Devanagari (Hindi), and other writing systems.

Installation and Integration

Let’s walk through the installation. Our environment is an Apple Silicon MacBook (macOS, CPU-only, no GPU acceleration) running Python 3.12.8. PaddleOCR-VL runs on top of the PaddlePaddle ecosystem, so we install two packages:

# Install into the shared virtual environment (.venv) per python-runtime rules
VIRTUAL_ENV="$PWD/.venv" uv pip install paddlepaddle paddleocr
# Installed versions: paddlepaddle==3.3.1, paddleocr==3.7.0

The first inference attempt raised this error:

RuntimeError: A dependency error occurred during pipeline creation.
Please refer to the installation documentation to ensure all required dependencies are installed.

The PaddleOCR-VL pipeline requires additional document-parsing-specific dependencies. One extra command resolved it:

VIRTUAL_ENV="$PWD/.venv" uv pip install "paddleocr[doc-parser]"

The inference code itself is short. The pipeline downloads the required models automatically on first use:

from paddleocr import PaddleOCRVL

pipe = PaddleOCRVL()                 # Downloads models automatically on first call
out = pipe.predict("sample_doc.png") # Document image -> structured output
for res in out:
    res.save_to_markdown(save_path="paddleocr_out")

One important note: paddleocr==3.7.0 automatically selects PP-DocLayoutV3 as the layout model and PaddleOCR-VL-1.6-0.9B as the recognition model when building the pipeline. In other words, the package pulls in the post-publication 1.6 model and a newer layout model as its defaults – not the original version from the base paper (2510.14528). The widely shared “OmniDocBench 96.33% SOTA” figure comes from PaddleOCR-VL-1.6 (on OmniDocBench v1.6), and the version is different from the numbers reported in the original paper. We will clarify this distinction in a later section.

Actual Experiment Results

For our test document, we created a synthetic image mixing Korean, English, Arabic, numbers, and simple formulas – a single-page document modeled after a ThakiCloud invoice and cost report. The actual timings measured in a CPU-only environment:

• Model initialization (first call, including download): 74.7s
• Inference (predict): 32.65s / page
• Total elapsed (import to save): 137.4s
• Decoder architecture log: GQA (grouped-query attention), num_heads 16 / num_key_value_heads 2

The recognized Markdown output was as follows:

## ThakiCloud Document Intelligence
Kubernetes AI/ML SaaS Platform - Invoice No. 2026-0623
타키클라우드 멀티테넌트 추론 비용 보고서
GPU hours: 1,284 Total: $9,640.00
E = mc^2 sum_{i=1}^{n} x_i

Notable observations: the model captured the English heading as a Markdown heading (##), correctly recognized the Korean sentence “타키클라우드 멀티테넌트 추론 비용 보고서” verbatim, and read the numeric and currency values ($9,640.00, GPU hours 1,284) without error. Korean recognition quality was surprisingly stable for a 0.9B model.

One finding worth reporting honestly: the Arabic line in our synthetic image was classified as an image region rather than transcribed as text. This appears to be an issue with our test image rather than a model defect. When rendering Arabic with PIL, character joining (shaping) and bidirectional (bidi) text handling were not applied correctly, causing the characters to render in an unconnected form. The layout stage likely interpreted this as a graphic. The Arabic line-level edit distance reported in the paper is 0.122, which is low enough to suggest that real Arabic documents would yield very different results. The experience itself is an operational lesson: preprocessing and rendering quality drive outcomes.

Let us also look at the benchmark numbers the paper reports on public datasets. The chart below shows per-language line-level text recognition edit distances reported in the base paper (arXiv:2510.14528) for a subset of the 109 supported languages (lower is better).

Korean and Arabic highlighted as ThakiCloud’s core market languages. Source: arXiv:2510.14528.

Korean achieves 0.052 and Arabic achieves 0.122 – solid edit distances for both languages ThakiCloud targets. At the page level, the base paper reports an OmniDocBench v1.5 aggregate score of 92.86, ahead of the next-best MinerU2.5-1.2B (90.67).

A 0.9B model beating a 1.2B model on aggregate score. Source: arXiv:2510.14528 Table 2.

When citing these numbers, version clarity matters. The base paper (2510.14528) reports 92.86 on OmniDocBench v1.5. The subsequent release PaddleOCR-VL-1.5 reports 94.5% on v1.5, and PaddleOCR-VL-1.6 reports 96.33% on v1.6 as an [estimated] figure (based on a separate report for the later version). The 96.33% seen on social media is the score from the latest 1.6 release. It is also worth keeping in mind that the inference throughput figures in the paper were measured on a single NVIDIA A100 with batch sizes of 512 PDFs and high-performance serving engines like vLLM, SGLang, and FastDeploy. Our CPU-measured 32.65s per page is a reference point for an unaccelerated environment – not a production throughput figure.

Implications for ThakiCloud K8s AI/ML SaaS Platform

What makes this model interesting is not just the high benchmark scores – it is the fact that it is small enough to operate easily. From ThakiCloud’s stack perspective:

• Low-cost multi-tenant serving: A 0.9B model fits on a single consumer-grade or entry-level GPU. Deployed on top of our Kueue-based GPU scheduling and vLLM/SGLang serving infrastructure, we can run per-tenant document parsing endpoints at a reasonable cost – controlling unit economics through self-hosted inference instead of paying per-token fees to a large VLM API every time.
• Data sovereignty and on-premise deployment: Documents often contain information that cannot be sent outside – invoices, contracts, medical records, financial data. With an Apache-2.0 model hosted on-premise, we can deliver document intelligence without routing sensitive data through external APIs. This also aligns with network isolation and data-export restrictions common in Korean public-sector and financial environments.
• Multilingual coverage as market fit: Our blog publishes in Korean, English, and Arabic simultaneously. With our eyes on both the Korean and Middle Eastern markets, having a single model that reliably handles Korean (0.052) and Arabic (0.122) is directly a product advantage – it reduces the need to bolt on different OCR engines per market.
• Document parsing as the input layer for RAG: Structured Markdown and JSON output feeds directly into RAG indexing and agent tool calls. Text that preserves layout and reading order produces higher-quality chunks, which directly improves retrieval accuracy.

At a more mature deployment stage, the two-stage design also opens the door to heterogeneous scheduling: run the layout stage on CPU nodes and the VLM recognition stage on GPU nodes as separate services. The explicit separation of the two stages is actually an advantage for resource allocation in a Kubernetes environment.

Limitations and Counter-Arguments

The strengths are real, but so are the weaknesses. Based on our measurements and the literature:

• CPU inference is slow: Our measured 32.65s per page is not suitable for bulk document processing. In production, a GPU and a serving engine like vLLM or SGLang are effectively mandatory – the impressive throughput numbers in the paper come from an A100 batch environment.
• Two-stage dependency management: You now have two models to manage together – the layout model and the recognition model. Deployment and version compatibility overhead is higher than with a single model. In practice, the package already defaults to PP-DocLayoutV3 + PaddleOCR-VL-1.6, and the default combination may change over time.
• SOTA numbers are version-specific: 96.33% is the score of version 1.6 on OmniDocBench v1.6, not the headline of the original 0.9B paper. Citing this figure without specifying the version and benchmark edition will cause confusion.
• Input quality dependency: As our Arabic test showed, the rendering quality, resolution, and character shaping of the input image drive results. In a real data pipeline, the input normalization stage matters as much as model selection.
• Reported weakness in table recognition: The base paper itself notes that English table TEDS on OmniDocBench v1.0 (88.0) is relatively low (with an explanation about annotation errors), so documents heavy in tables warrant additional validation.

On balance, PaddleOCR-VL is a compelling choice for self-hosted document intelligence as a compact but capable document parsing model. To realize its full value in production, however, three operational challenges must be addressed together: GPU serving, version pinning, and input preprocessing.

Sources

• PaddleOCR-VL paper (arXiv:2510.14528): Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model
• Hugging Face model card: PaddlePaddle/PaddleOCR-VL
• Source code: github.com/PaddlePaddle/PaddleOCR
• The experiments in this post were conducted directly in the ThakiCloud environment (macOS, CPU). Benchmark figures cited are as reported in the paper above.

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.