تقود مهارات الوكيل العمل المتكرر في تدريب GPU وتقييمه وضبطه. أما الإنسان فيقدّم الهدف فقط عبر مطالبة.

ما هو Cosmos 3، وما هي مهارات الوكيل (TAO Agent Skills)؟

Cosmos 3 هو نموذج أساسي طورته NVIDIA للتعامل مع العالم الفيزيائي. يستخدم بنية Mixture-of-Transformers التي تجمع النص والصورة والفيديو والصوت المحيط وتتبع الحركة في كيان واحد، ويضم برجاً استدلالياً ذاتي الانحدار (autoregressive) مسؤولاً عن المنطق والتخطيط إلى جانب محول انتشار (diffusion transformer) يتنبأ بالحالات المستقبلية. أعلنت NVIDIA أن هذا النموذج يتصدر عدة معايير قياسية منها VANTAGE-Bench وPAI-Bench وPhysics-IQ وRoboLab وRoboArena. يأتي النموذج بحجمين هما Cosmos 3 Super بسعة 64B وCosmos 3 Nano بسعة 16B، وتستخدم هذه الحالة نسخة Nano.

لكن الجوهر ليس النموذج بل مهارة وكيل TAO (TAO Agent Skill) المرفقة به. مهارة وكيل TAO هي حزمة معرفة تُؤتمت سير عمل التدريب اللاحق لنماذج الرؤية. فهي تغلف معرفة خاصة بالمهمة مثل تفاصيل الإطار البرمجي، وسلوك المُشغِّل (launcher)، وبنية ملفات الإعداد (config)، وطريقة تحميل البيانات، وسير عمل التقييم، بحيث يستطيع وكيل برمجي مثل Codex أو Claude أن ينسق خط أنابيب التدريب بنفسه بأقل قدر ممكن من تدخل الإنسان. بعبارة أخرى، المهارة ليست سطر مطالبة واحداً، بل وحدة قابلة لإعادة الاستخدام تغلف إجراءً قابلاً للتنفيذ إلى جانب آليات التعافي من الفشل.

المطالبتان الاثنتان اللتان تنهيان التدريب اللاحق

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

المطالبة الأولى توجه بإجراء تدريب لاحق بأسلوب LoRA. وهي طلب لتدريب nvidia/Cosmos3-Nano بأسلوب LoRA على مجموعة بيانات Woven Traffic Safety الخاصة بشركة Toyota، مع إجراء تقييم أساسي (baseline) أولاً لأغراض المقارنة.

Perform LoRA post-training of the Cosmos 3 model on the Woven Traffic
Safety dataset. Training data: /home/.../WTS_dataset/wts_data_train
Validation data: /home/.../WTS_dataset/wts_data_val
Base model on Hugging Face: nvidia/Cosmos3-Nano
Also perform a baseline evaluation first, to compare with the post-trained model.

بمطالبة واحدة فقط، عالج الوكيل عدة مهام بالتتابع: اكتشف بنفسه معامل FPS المفقود في خط أنابيب البيانات وأصلح الخطأ، ثم خزّن النموذج مؤقتاً باستخدام رمز Hugging Face، وقاس دقة الأساس بأسلوب zero-shot قبل التدريب فسجّلت 54.41%، ثم شغّل تدريب LoRA. النقطة الجديرة بالملاحظة هنا هي التوجيه القائل “أجرِ تقييم الأساس أولاً”. فبدلاً من الثقة بنتيجة يبلغ عنها النموذج بنفسه بعد التدريب، جرى تثبيت رقم ما قبل التدريب كخط أساس للقياس، وقيس التحسن فعلياً. هذا المبدأ مطابق تماماً للدرس الذي استخلصناه من تجربتنا في الأسبوع الماضي.

المطالبة الثانية هي عملية مسح AutoML. وهي طلب لترك استراتيجية البحث وتحديد المعاملات الفائقة الواجب ضبطها لـ TAO، مع تحسين دقة التحقق (validation accuracy) ثم تلخيص أفضل النماذج.

Run an AutoML sweep to improve the LoRA result. Let TAO choose suitable
search strategies and tune the important training hyperparameters. Optimize
validation accuracy and summarize the best models.

عند رسم سير العمل بأكمله كمخطط، يظهر الإنسان عند الطرفين فقط، بينما تملأ المهارة العمل المتكرر في المنتصف.

flowchart TB
    A["مطالبة بلغة طبيعية<br/>(تدريب LoRA + تقييم الأساس)"] --> B["وكيل برمجي<br/>(Codex / Claude)"]
    B --> C["مهارة وكيل TAO<br/>تغليف معرفة الإطار والمُشغِّل وconfig<br/>وتحميل البيانات والتقييم"]
    C --> D["إصلاح تلقائي للأخطاء<br/>(تصحيح معامل FPS المفقود)"]
    C --> E["تخزين النموذج مؤقتاً<br/>(Cosmos3-Nano عبر رمز HF)"]
    C --> F["تقييم الأساس<br/>(zero-shot بنسبة 54.41%)"]
    F --> G["التدريب اللاحق بأسلوب LoRA<br/>(8×A100، نحو 30 دقيقة لكل حقبة)"]
    G --> H["مسح AutoML<br/>(43 محاولة متوازية، 19.5 ساعة)"]
    H --> I["خدمة أفضل مهايئ (adapter)<br/>عبر Cosmos 3 Reasoner NIM<br/>(نقطة نهاية متوافقة مع OpenAI)"]

تحضير البيئة يتطلب ثلاثة رموز (tokens) وسطراً واحداً من نص التثبيت. تُدخل HUGGINGFACE_TOKEN وNGC_API_KEY وAUTOML_LLM_API_KEY في الطرفية، ثم تُثبَّت مهارة الوكيل بالنص البرمجي أدناه.

export HUGGINGFACE_TOKEN="your_hf_token"
export NGC_API_KEY="your_ngc_key"
export AUTOML_LLM_API_KEY="your_llm_key"

curl -fsSL https://raw.githubusercontent.com/NVIDIA-TAO/tao-skills-bank/main/scripts/install-codex-agents.sh | bash

بيانات التدريب هي مجموعة بيانات Woven Traffic Safety الخاصة بشركة Toyota، وهي مهمة أسئلة وأجوبة على مقاطع فيديو تضم أكثر من 8,000 عينة تدريب وتحقق. تتألف من أسئلة اختيار من متعدد (أربعة خيارات) تتناول بنية الطرق وأنواعها وحالات السلامة المرورية.

الأرقام التي أنتجتها المطالبتان

ارتفع الأداء بوضوح. جميع الأرقام أدناه هي قيم أعلنتها NVIDIA، وليست نتائج أعدنا إنتاجها بأنفسنا.

ارتفعت دقة التحقق من 54.41% إلى 93.35% بمطالبتين فقط. أرقام معلنة من NVIDIA.

بلغ الأساس بأسلوب zero-shot نسبة 54.41%، ورفعته مطالبة LoRA الواحدة إلى 87.14%، أي بزيادة قدرها 32.73 نقطة. وفوق ذلك، ضبط مسح AutoML المعاملات الفائقة عبر التحسين البايزي (Bayesian optimization) ليصل إلى 93.35%، بزيادة قدرها 38.94 نقطة عن الأساس. والنقطة الجوهرية هنا أن هذه الأرقام تحققت دون أن يلمس إنسان المعاملات الفائقة بيده، بل باختيار الوكيل لاستراتيجية البحث وتشغيله التدريب بشكل متكرر.

من الأمانة النظر أيضاً إلى أرقام التكلفة. استغرق تدريب LoRA نحو 30 دقيقة لكل حقبة (epoch) على 8 وحدات A100 80GB، بينما استغرق مسح AutoML، الذي شغّل 43 محاولة متوازية عبر عدة عُقد A100، مدة 19.5 ساعة. أما التدريب الدقيق الكامل المعاملات (full-parameter SFT) الذي شُغِّل كمجموعة مقارنة فقد استغرق 3 ساعات و34 دقيقة على H100، وأعلنت NVIDIA أن LoRA خفّض زمن استخدام GPU إلى نحو سُبع الزمن مقارنة بهذا التدريب الكامل. وبعد انتهاء التدريب، تتولى Cosmos 3 Reasoner NIM خدمة مهايئ LoRA عبر نقطة نهاية متوافقة مع OpenAI، ضمن بنية تُنشر مباشرة كخدمة مصغّرة (microservice) مبنية مسبقاً، دون الحاجة إلى ضبط تبعيات vLLM أو إعدادات CUDA يدوياً.

هل جربنا هذا بأنفسنا؟

بصراحة، لم نتمكن من إعادة إنتاج سير العمل هذا في بيئتنا. أوزان عائلة Cosmos 3 محفوظة في مستودع Hugging Face مُقيَّد بالوصول (gated)، وتحتاج العملية إلى 8 وحدات A100 ومفاتيح NGC وAutoML LLM، كما أن المسح المتوازي المستخدم في هذه الحالة يفترض وجود عدة عُقد GPU. لم نؤمّن مجموعة الموارد هذه لأجل هذا المقال. لذلك فإن جميع الأرقام أعلاه مقتبسة من قيم أعلنتها NVIDIA، ولا نقدمها كما لو كانت نتائج قسناها بأنفسنا. نلتزم بمبدأ عدم إنشاء معايير قياسية دون إعادة إنتاج فعلية. ما يمكننا فعله بدلاً من ذلك هو تشريح بنية هذه الحالة، ومقارنتها بدقة بما يعمل بالفعل على منصتنا، لتحديد أوجه التشابه والاختلاف.

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

هذه الحالة موضوع نادر تتقاطع فيه وجهتا نظر منتجَينا معاً.

من زاوية Paxis، هذه الحالة تحقق خارجي لأطروحتنا القائلة بأن المهارات يجب أن تُعامل كموارد من الدرجة الأولى. Paxis هو مستوى التحكم الخاص بـ ThakiCloud للسحابة الأصيلة الوكيلة (Agent-Native Cloud)، ويعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. يختار Skill Harness من بين أكثر من 960 مهارة باستخدام BM25 وينفذها في صندوق رملي معزول، ويمرر كل سلوك عبر بوابات السياسات (policy gates) وسجلات التدقيق. ما أثبتته مهارة وكيل TAO التابعة لـ NVIDIA هو أن وجود مهارة تغلف تفاصيل الإطار البرمجي وحتى آليات التعافي من الفشل يجعل الوكيل البرمجي يكرر سير عمل معقداً بثبات. وهذا يطابق تماماً التوجه الذي اعتمدناه في تعريف المهارة بوصفها وحدة تنفيذ لا مجرد مطالبة. غير أن الفرق واضح أيضاً: مهارات TAO مرتبطة بشدة بمنظومة NVIDIA، بحيث يصعب استخدامها كما هي خارج مُشغِّل TAO ونماذج Cosmos وNGC وNIM. أما حاضنة مهارات Paxis فتستهدف عدم الارتباط بمزود أو نموذج بعينه، وهذه النقطة هي جوهر القيمة التي نريد تقديمها في البيئات المحلية (on-premises) والبيئات السيادية.

ومن زاوية ai-platform، هذه الحالة هي بعينها تدريب وخدمة GPU الذي نجدوله يومياً. إرسال 43 محاولة AutoML متوازية عبر عدة عُقد يتطابق مباشرة مع طريقة إدارة Kueue لطوابير GPU في منصتنا. وخدمة مهايئ LoRA عبر نقطة نهاية متوافقة مع OpenAI بواسطة NIM تحل المشكلة ذاتها التي نحلها عبر مسار الخدمة القائم على vLLM. كما أن كون LoRA يقلل زمن استخدام GPU بشكل كبير مقارنة بالتدريب الكامل SFT يدعم أطروحتنا القائلة بأن الخدمة منخفضة التكلفة والتدريب منخفض التكلفة يصنعان في النهاية جدوى اقتصادية للوكيل. عندما يريد عميل إجراء تدريب لاحق لنموذج أساسي على بياناته الخاصة، فإننا نوفر له مساراً يقسّم GPU عبر Kueue ويخدم المهايئ عبر vLLM فوق عنقوده (cluster) الخاص، بدلاً من سحابة خارجية مقيدة الوصول.

بجمع الزاويتين معاً تكتمل الصورة. تسند ai-platform التدريب والخدمة منخفضي التكلفة، وفوقهما يقود Paxis الوكيل بالمهارات والسياسات والتدقيق. وحالة NVIDIA أظهرت، عبر معيار قياس لجهة أخرى، أن هذا التركيب يؤدي فعلاً إلى تحسن حقيقي في الأداء.

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

لتجنب المبالغة في تقدير هذه الحالة، ينبغي النظر في أربع نقاط معاً. أولاً، عبارة “في يوم واحد” مقياسها الزمن الفعلي (wall clock) لا زمن GPU. فمسح استغرق 19.5 ساعة عبر 8 وحدات A100 وعدة عُقد ليس رخيصاً بأي حال، والنسبة “سُبع الزمن” قيمة نسبية مقارنة بالتدريب الكامل SFT، لا تعني رخصاً مطلقاً. ثانياً، نسبة 93.35% رقم يخص مهمة ضيقة هي أسئلة وأجوبة فيديو للسلامة المرورية من نوع الاختيار من أربعة بدائل، ولا ينبغي تعميمها على أنها ارتفاع مماثل في القدرة العامة على الاستدلال الفيزيائي. ثالثاً، الأتمتة تُخفي التبعية للمزود. السبب في قدرة الوكيل على إصلاح الخطأ “بنفسه” هو أن بنك المهارات كان يعرف مسبقاً نمط الخطأ الخاص بذلك الإطار البرمجي بالضبط، وهذه السلاسة تختفي بمجرد الخروج من تلك المنظومة. رابعاً، “الحد الأدنى من التدخل” لا يعني تدخلاً معدوماً. فلا تبدأ العملية إلا بعد أن يُدخل الإنسان مفاتيح API، ويحدد مسارات مجموعة البيانات، ويثبت أصلاً بنك المهارات المناسب لتلك المهمة. ما ألغاه الوكيل هو العمل المتكرر، لا الحكم البشري نفسه.

ومع ذلك فإن الاتجاه واضح. إن تجميد معرفة سير العمل في هيئة مهارة، وتكرار الوكيل تنفيذها، والتحقق من التحسن عبر بوابة قياس فعلية لا عبر تقرير ذاتي من النموذج، ليست استراتيجية خاصة بمزود واحد، بل تصميم مشترك لعصر الوكلاء. وهذا بالضبط ما نسعى إلى بنائه عبر Paxis وai-platform.

المصادر

• NVIDIA Developer Blog, “Post-Train NVIDIA Cosmos 3 in One Day Using Agent Skills” (https://developer.nvidia.com/blog/post-train-nvidia-cosmos-3-in-one-day-using-agent-skills/)
• GitHub: NVIDIA/cosmos, NVIDIA-TAO/tao-skill-bank
• Hugging Face: nvidia/Cosmos3-Nano, nvidia/Cosmos3-Super
• مجموعة البيانات: Woven Traffic Safety (WTS)، Toyota

نظرة عامة

عنوان الورقة البحثية هو “Harness Updating Is Not Harness Benefit”، أي أن تحديث الأداة والاستفادة منها أمران مختلفان. معظم الأنظمة التي تتعامل مع الوكلاء ذاتية التطور قاست هذين الأمرين ككتلة واحدة. يحل الوكيل مهمة، ثم يستخرج من سجل التنفيذ تعديلات على الموجّهات أو المهارات، ثم يُعاد تشغيل المهمة التالية بالأداة المعدَّلة، وإذا ارتفعت الدرجة النهائية، يُعلَن أن “التطور نجح”.

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

ما الذي تسأله هذه الدراسة

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

تقسّم الدراسة عملية التطور هذه إلى قدرتين.

الأولى هي قدرة تحديث الأداة (harness-updating): القدرة على النظر إلى أدلة مهمة منجَزة وإنتاج تحديث دائم وقابل لإعادة الاستخدام. استخلاص درس من حالة فاشلة وتدوينه في وثيقة مهارة، أو ملاحظة نمط متكرر وترسيخه كقاعدة في الموجّه، كلاهما يندرج تحت هذه الفئة.

الثانية هي قدرة الاستفادة من الأداة (harness-benefit): القدرة، عند توفّر أداة محدَّثة، على استدعائها فعليًا واتباعها لرفع أداء المهمة. مهارة جيدة تجلس دون استخدام في المكتبة، أو مهارة يتم استدعاؤها لكن لا تُتَّبع تعليماتها حتى النهاية، كلتاهما تنتج استفادة تساوي صفرًا.

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

flowchart TB
    A[تنفيذ المهمة] --> B[جمع أدلة التنفيذ]
    B --> C{قدرة تحديث الأداة<br/>إنتاج تحديثات دائمة من الأدلة}
    C --> D[أداة محدَّثة<br/>موجّهات، مهارات، ذاكرة، أدوات]
    D --> E{قدرة الاستفادة من الأداة<br/>استدعاء التحديثات واتباعها بأمانة}
    E --> F[أداء حل المهمة]
    F -.تُقاس معًا في الحلقة نفسها.-> G[المكسب المقاس<br/>القدرتان متشابكتان]
    C -.نتيجة القياس المنفصل.-> H[ثابتة<br/>متشابهة بصرف النظر عن فئة النموذج]
    E -.نتيجة القياس المنفصل.-> I[غير رتيبة<br/>النماذج متوسطة الفئة تستفيد أكثر]

ما الذي يكشفه فصل القدرتين

تتلخّص نتيجة التجربة المنفصلة في جملتين، وكلتاهما تخالف الحدس العملي.

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

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

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

لماذا لا تستفيد النماذج الضعيفة

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

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

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

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

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

خلاصة هذه الدراسة تتطابق تمامًا مع الانضباط الذي بنيناه في تشغيل Paxis. Paxis هو Agent-Native Cloud من ThakiCloud، ويعامل المهارات والأدوات والسياسات كموارد من الدرجة الأولى. نختار من أكثر من 960 مهارة باستخدام BM25 وننفّذها في بيئات معزولة (sandboxes)، وحلقة التطور الذاتي للمهارات لدينا تستخلص الدروس من الإخفاقات وتعدّل وثائق المهارات. بعبارة أخرى، نحن نُشغّل بالفعل حلقة “تحديث الأداة” كل يوم.

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

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

هناك أيضًا دلالة على مستوى البنية التحتية. تُشغّل ai-platform عدة فئات من النماذج فوق K8s وKueue. تشير هذه الدراسة إلى أنه من المنطقي، عند نشر خط أنابيب ذاتي التطور، وضع فئات نماذج مختلفة في أدوار مختلفة للمطوِّر وحلّ المهمة. النشر المختلط، نموذج رخيص كمطوِّر ونموذج متوسط الفئة كحلّال للمهمة، تصميم يمكنه توفير تكلفة كبيرة في جدولة GPU متعددة المستأجرين مع الحفاظ على الجودة.

حدود الدراسة وحجج مضادة

قبل نقل هذه الدراسة مباشرة إلى الممارسة، تستحق بضع تحفّظات الذكر.

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

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

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

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

المصادر

• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents، arXiv 2605.30621: arxiv.org/abs/2605.30621
• صفحة Hugging Face Papers: huggingface.co/papers/2605.30621
• خلفية ذات صلة: Agentic Harness Engineering، arXiv 2604.25850: arxiv.org/html/2604.25850v3

كتب أحد المطورين هذا: “عمري 33 عامًا وأظن أن Claude Code يُذيب دماغي. طوال ستة أشهر متواصلة كنت أفتح خمس أو ست نوافذ طرفية في آن واحد، أنتظر الردود لأضغط Enter في 90% من الوقت. هذا هو العمل كله الآن. وهو يفعل بي شيئًا ما.” ثم أقرّ بأن هذه قد تكون مشكلة في طريقة اعتماده على الأداة لا في الأداة نفسها، لكنه أصرّ على أن الأثر حقيقي على أي حال.

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

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

العمل الجديد المسمى Multi-Clauding

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

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

ما هو حقًا إحساس ذوبان الدماغ

“ذوبان الدماغ” يبدو استعارة مبالَغًا فيها، لكن بداخله تتراكب عدة ظواهر ملموسة رصدها علم الإدراك منذ زمن.

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

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

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

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

من مراقب إلى منسّق

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

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

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

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

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

تلتقي هذه الرؤية بفلسفة تصميم Paxis التي نبنيها بدقة. Paxis هو مستوى تحكم Agent-Native Cloud يعمل فوق ai-platform الخاصة بـ ThakiCloud، ويعامل المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. هنا لا تكون الوكلاء المتوازية شيئًا يجلس الإنسان بجانبه ويراقبه عند كل نافذة، بل وحدات تنفيذ ذاتية يفوّضها منسّق وترشّحها بوابة.

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

يُضاف إلى هذا منظور البنية التحتية لـ ai-platform. الوكلاء المفوَّضون بهذه الطريقة يُجدوَلون على موارد GPU التي يديرها K8s و Kueue، ويُعزَلون بنظام متعدد المستأجرين. البنية التحتية تحمل إنتاجية التنفيذ الذاتي، وبوابات التحقق تحمي الجودة، والإنسان يجمع انتباهه على أكثر الأعمال إنسانية: التصميم والحكم. التنفيذ الذاتي منخفض التكلفة يخلق اقتصاديات الوكلاء، وتلك الاقتصاديات بدورها تحرر الناس من المراقبة المتكررة. مشكلة التكلفة الإدراكية للبرمجة الموازية بالذكاء الاصطناعي هي في النهاية مشكلة تحلّها بنية منصة تسحب الإنسان من عبء المعالجة الموازية.

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

لهذه القصة اعتراضات يجب ذكرها بأمانة.

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

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

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

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

المصادر

• Braeden (@BraedendotTECH)، منشور على X: Claude Code is melting my brain
• Eva Keiffenheim، The Cognitive Costs of Multi-Clauding
• CodeAgentSwarm، How to Set Up Multiple Claude Code Terminals in Parallel (2026)
• ShareUHack، A One-Person Engineering Team: The Complete Claude Code Parallel Workflow Guide
• Anthropic، Claude Code power user tips

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

في 14 يوليو 2026، أصدرت PrismML نموذج Bonsai 27B الذي يواجه هذا الجدار مباشرة. Bonsai 27B ليس نموذجا مدربا من جديد، بل يُبقي Qwen3.6-27B كما هو ويكتفي بتمثيل الأوزان فقط بصيغة منخفضة البت. البنية المعمارية لم تتغير. صدرت نسختان بترخيص Apache 2.0، وأفادت التقارير بأن نسخة ternary تحافظ على 94.6% من جودة النموذج الأصلي بحجم 5.9GB، بينما تحافظ نسخة 1-bit على 89.5% بحجم 3.9GB.

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

ما هو Bonsai 27B

Bonsai 27B هو تمثيل منخفض البت لنموذج Qwen3.6-27B. وبالتطبيق على نموذج متعدد الوسائط يتكون من نحو 24.8B من أوزان اللغة، و0.46B لبرج الرؤية، و2.5B للتضمينات ورأس LM، يُحوَّل النموذج بالكامل، بكل مكوناته كثيفة عمليات المصفوفات، إلى صيغة منخفضة البت. ويشمل ذلك التضمينات، وإسقاطات الانتباه، وإسقاطات MLP، ورأس LM، بينما يبقى جزء ضئيل جدا فقط، مثل معاملات التطبيع والمقياس، بدقة عالية. أما برج الرؤية فيُحفظ بشكل منفصل بصيغة 4-bit HQQ ولا يُحمَّل إلا عند وجود مدخل صورة.

تختلف طبيعة النسختين. تُمثل نسخة Ternary Bonsai 27B الأوزان بثلاث قيم {-1, 0, +1} لتصل إلى فعالية 1.71 بت وسعة مثالية قدرها 5.9GB. أما نسخة 1-bit Bonsai 27B فتستخدم قيمتين فقط {-1, +1} لتصل إلى فعالية 1.125 بت بحجم 3.9GB. ويُدعم السياق حتى 262K رمز (token)، ويظل هذا عمليا لأن نحو 75% من آلية انتباه Qwen3.6-27B خطية.

flowchart TB
    A[Qwen3.6-27B<br/>FP16 54GB] --> B[تقسيم على مستوى المجموعات<br/>مجموعة واحدة لكل 128 وزنا]
    B --> C{دفتر الشيفرة منخفض البت}
    C -->|Ternary| D[-1, 0, +1<br/>حوالي 1.585 بت]
    C -->|Binary| E[-1, +1<br/>1.0 بت]
    D --> F[مقياس FP16 واحد لكل مجموعة<br/>+16/128 بت]
    E --> F
    F --> G[Ternary 1.71 bpw 5.9GB<br/>Binary 1.125 bpw 3.9GB]
    G --> H[برج الرؤية<br/>يُخزَّن بشكل منفصل بصيغة HQQ رباعية البت]
    H --> I[llama.cpp / MLX<br/>استدلال محلي على الحواسيب المحمولة والهواتف]

كيف يعمل الضغط

الفكرة الأساسية بسيطة. يُخزَّن كل وزن كرمز واحد، وتشترك كل مجموعة من 128 وزنا في مقياس FP16 واحد. ويُعاد بناء الوزن الفعلي كحاصل ضرب مقياس المجموعة في الرمز، بالصيغة w_i = s_g · t_i.

بتتبع حساب البتات تتضح تكلفة التخزين. تحمل قيمة ternary واحدة log2(3) ≈ 1.585 بت. وبإضافة مقياس FP16 واحد لكل 128 قيمة، تُضاف 16/128 بت ليصل المجموع إلى نحو 1.71 بت، أي تقليص بمقدار نحو 9.4 مرة مقارنة بـ FP16. أما binary فالقيمة نفسها بت واحد، وبإضافة عبء المقياس نفسه يصبح 1 + 16/128 = 1.125 بت، أي تقليص بمقدار نحو 14.2 مرة.

يظهر هنا تباين لافت. فنسخة Q4_K_XL من Qwen3.6-27B، التي تُسمى عادة 4-bit، يبلغ متوسطها الفعلي 5.2 بت، ونسخة IQ2_XXS التي تُسمى 2-bit يبلغ متوسطها الفعلي 2.8 بت. أي أن الاسم يختلف عن متوسط البت الفعلي. كما يختلف Bonsai عن BitNet. فـ BitNet يُدرَّب من الصفر بدقة منخفضة البت تجنبا للانهيار، بينما يضغط Bonsai نموذجا مدربا مسبقا بعد تدريبه. وتدعي PrismML أنها تجنبت الانهيار دون إعادة تدريب، لكن تفاصيل هذا الادعاء تعتمد على الوثائق التقنية المنشورة.

نتائج المعايير المُبلَّغ عنها

أفادت PrismML بأنها قيّمت 15 معيارا في وضع thinking باستخدام EvalScope وvLLM على H100. يعرض الجدول أدناه هذه القيم المُبلَّغ عنها. ونؤكد مجددا أن هذه الأرقام هي قيم نشرها المزوّد، وليست قيما أعادت ThakiCloud إنتاجها، وأن إعادة الإنتاج المستقلة تتطلب تحققا منفصلا.

وعند التقسيم حسب الفئة، يتضح أن الضغط لا يُحدث خسارة موحدة. فالرياضيات تصمد نسبيا جيدا، من 95.33 عند FP16 إلى 93.40 لـ ternary و91.66 لـ 1-bit. في المقابل، تنخفض مهام الوكيل (agent) واستدعاء الأدوات بشكل حاد من 80.00 إلى 74.01 لـ ternary و66.03 لـ 1-bit، وتنخفض الرؤية من 72.61 إلى 59.57 لـ 1-bit. كما تنخفض القدرة على اتباع التعليمات بشكل كبير من 78.47 إلى 65.74 لـ 1-bit.

التباين الذي تُبرزه PrismML هو الانهيار الانتقائي في نسخ sub-4-bit السابقة. فنسخة IQ2_XXS تحافظ على 88.93 في مهام الإجابات القصيرة مثل MMLU-Redux، لكنها تنهار إلى 57.5 في AIME26 و56.4 في LiveCodeBench. والملاحظة هي أن المعايير القصيرة تُخفي هذا الانهيار. وهذه الملاحظة بحد ذاتها بصيرة عملية يتفهمها كل من تعامل مع الضغط منخفض البت من قبل.

الذاكرة هي القيد الحقيقي

قراءة إصدار Bonsai 27B بالاعتماد فقط على أرقام الحجم تُفوّت الجوهر. فشروط تشغيل النموذج على هاتف أكثر صرامة بكثير من سعة التخزين وحدها. يقيّد iOS التطبيق الواحد باستخدام نحو نصف الذاكرة الفعلية فقط، لذا فإن هاتف iPhone بذاكرة 12GB لا يُتيح فعليا سوى نحو 6GB. وهنا تكمن أهمية نسخة 3.9GB.

الميزانية الثانية هي ذاكرة التخزين المؤقت KV cache. وبما أن 16 فقط من أصل 64 طبقة تمتلك ذاكرة تخزين مؤقت كاملة الانتباه ومتنامية، فإن التكلفة تبلغ نحو 64KiB لكل رمز عند FP16. وملء نافذة 262K بالكامل يكلف نحو 17.2GB، ويؤدي استخدام ذاكرة تخزين مؤقت KV بدقة 4-bit إلى خفض ذلك إلى نحو 4.3GB. ومهما قلّصنا أوزان النموذج، فإن السياق الأطول سيستهلك الذاكرة عبر ذاكرة التخزين المؤقت KV، لذا يجب أن تسير الأوزان منخفضة البت وذاكرة التخزين المؤقت منخفضة البت معا.

وأفادت PrismML أيضا بأنها قاست الأثر على الجودة الناتج عن ضغط الذاكرة المؤقتة. فمقارنة بخط الأساس FP16-KV الخاص بها، أظهرت نسخة Ternary Bonsai قيمة forward-KL للمخرجات بلغت 0.0011 nats على MATH-500، بينما أظهرت Q4_K_XL قيمة 0.0146. وعند 100K رمز باستخدام ذاكرة مؤقتة FP16، تبلغ الذروة نحو 11.6GB لنسخة 1-bit ونحو 14.7GB لنسخة ternary. أي أنه حتى بعد تقليص الأوزان، يتطلب السياق الطويل خفض دقة الذاكرة المؤقتة أيضا حتى يتسع النموذج فعليا على الجهاز.

الإنتاجية وفك الترميز التخميني

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

أصدرت PrismML أيضا مُسوِّدا (drafter) باسم DSpark مدربا خصيصا لاستهداف Bonsai 27B. وعلى H100، وبعمق مُسوَّدة (draft depth) k=4، أفادت بطول قبول tau=3.6 للنسخة binary المستهدفة، أي 143.8 tok/s، بتسريع قدره 1.37 مرة. والتحقق بلا فقدان (lossless)، لذا يبقى توزيع المخرجات مطابقا. بيد أن المُسوِّد معطّل افتراضيا على شرائح Apple silicon عند حجم دفعة (batch size) يساوي 1.

التشغيل نفسه معياري تماما. يمكن تشغيل خادم llama.cpp أو التوليد مباشرة عبر llama-cli، كما يُوفَّر مسار MLX أيضا. ويستخدم استدعاء الأدوات مصفوفة tools بأسلوب OpenAI كما هي، وتعود الاستجابة عبر choices[0].message.tool_calls. ووضع thinking مفعّل افتراضيا ويمكن تبديله لكل طلب.

ماذا يعني هذا لـ ThakiCloud

تتقاطع الخدمة منخفضة البت مع منتجَي ThakiCloud كليهما.

منظور ai-platform (البنية التحتية والخدمة). تخدم منصة ai-platform التابعة لـ ThakiCloud نماذج مفتوحة الأوزان عبر بيئات عملاء متنوعة. وما يُظهره Bonsai هو إمكانية وضع جودة بمستوى 27B على GPU واحدة بسعة 24GB مع ذاكرة تخزين مؤقت KV بدقة 4-bit. وهذا يؤثر مباشرة على كثافة تعدد المستأجرين. فإذا أمكن تشغيل عدد أكبر من المستأجرين على GPU نفسها، أو تحقيق نفس اتفاقية مستوى الخدمة SLA ببطاقة أصغر، تنخفض تكلفة الخدمة. ولهذا أهمية خاصة في عمليات النشر المحلية (on-premises) والسيادية. فالقطاع العام المحلي والصناعات الخاضعة للتنظيم تتطلب استضافة ذاتية self-hosting تمنع خروج البيانات، بينما تظل ميزانيات الأجهزة محدودة. وخفض أوزان النموذج وذاكرة التخزين المؤقت KV معا إلى صيغة منخفضة البت يتيح تجميعا أكثف في تجمع GPU تُجدوله Kueue، وهذا يصب مباشرة في كفاءة التكلفة وكثافة الموارد التي نُشدد عليها دائما. غير أن منخفض البت ليس الحل دائما. فإذا كان عبء العمل متمركزا حول الوكلاء (agent) أو استدعاء الأدوات، تكون خسارة الجودة كبيرة كما يُبيّن قسم القيود أدناه، وهو ما يستدعي توجيها (routing) يُغيّر الدقة بحسب عبء العمل.

منظور Paxis (الوكلاء والحافة). Paxis هو مستوى تحكم Agent-Native Cloud الذي يعمل فوق ai-platform، ويتعامل مع Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. والنموذج الذي يعمل على هاتف بحجم 3.9GB يفتح الباب أمام وكلاء on-device في السياقات الحساسة للخصوصية. فإعداد لا يغادر فيه الطلب (prompt) الجهاز مفيد للامتثال التنظيمي ولسير العمل دون اتصال (offline). ومن منظور Paxis، يبدو طبيعيا التعامل مع هذه النماذج المحلية داخل تنفيذ معزول في صندوق رملي (sandbox)، مع تمرير كل إجراء عبر بوابات السياسات وسجلات التدقيق. فالاستدلال المحلي منخفض البت يخلق اقتصاديات وكلاء الحافة، وPaxis هو الطبقة التي تحكم ذلك التنفيذ.

يُكمّل المنظوران أحدهما الآخر. فالخدمة منخفضة التكلفة (ai-platform) هي ما يخلق اقتصاديات الوكلاء (Paxis).

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

أكبر تحفظ يتعلق بمصدر المعايير. فكل الأرقام أعلاه هي تقييمات ذاتية من PrismML، ولا توجد إعادة إنتاج مستقلة حتى الآن. والحجة التي تُشير إلى الانهيار الانتقائي لـ IQ2_XXS مقنعة، لكن المعايير التي تُظهر تفوق Bonsai هي أيضا قياسات ذاتية من المزوّد نفسه. والحكم العادل يتطلب إعادة إنتاج من طرف ثالث.

وعدم انتظام خسارة الجودة مهم عمليا أيضا. فدرجة الوكيل واستدعاء الأدوات لنسخة 1-bit لا تتجاوز 66.03. ودقة استدعاء الأدوات عند هذا المستوى تنطوي على مخاطر لخطوط أنابيب الوكلاء في الإنتاج. كما أن الرؤية عند 59.57 واتباع التعليمات عند 65.74 يشهدان انخفاضا كبيرا بالمثل، مما يعني أن نسخة 1-bit تقتصر عمليا على الاستدلال النصي البسيط والاستخدام على الجهاز ذي الأولوية للخصوصية. أما المسارات التي تحتاج جودة، فيجب أن ترتقي إلى ternary أو دقة أعلى.

كما يجب قراءة أرقام أداء الهاتف بحذر. فأرقام tok/s على iPhone كافية للتفاعلات القصيرة لكنها بطيئة للتوليد الطويل. والحرارة والبطارية والإنتاجية المستدامة لا تظهر في جدول المعايير. وتذكر الورقة البيضاء أنها قاست 672 رمزا لكل 1% من بطارية iPhone، لكن زمن الاستجابة الفعلي والاستمرارية في الاستخدام الحقيقي مسألتان منفصلتان.

وأخيرا، يعتمد الادعاء الأساسي بتجنب الانهيار دون إعادة تدريب على تفاصيل المنهجية الواردة في الوثائق المنشورة. والترخيص هو Apache 2.0، لكن علاقة وراثة الترخيص من نموذج Qwen3.6 الأساسي تتطلب تحققا قبل النشر التجاري. وخلاصة القول إن Bonsai 27B يمثل تقدما عمليا حقيقيا في الضغط منخفض البت، لكن قرارات التبني ينبغي أن تُتخذ بالتوازي مع متطلبات الجودة الخاصة بكل عبء عمل وإعادة الإنتاج المستقلة.

نتائج إعادة الإنتاج المستقلة من ThakiCloud

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

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

ثم حمّلنا إصدارهم Bonsai-1.7B-unpacked (أوزان البِتّة الواحدة معادة إلى FP16) بأدوات قياسية. استخدمت كل مجموعة من 128 وزناً مقياساً واحداً فقط، وكانت الحيرة على مقطع ثابت 3.492، أي مطابقة عملياً لنفس أساس Qwen3-1.7B عند FP16 (3.507). النموذج المُصدَر حقيقي وشبه خالٍ من الفقد.

في المقابل، إعادة الإنتاج الساذجة من الصيغة العامة وحدها (تثنية BWN المعيارية) تنهار تماماً عند نفس 1.125 بِتّة. يؤكد شاهد الـ4 بِتّات سلامة أداة القياس.

الطريقة المغلقة يمكن التنبؤ بها. لأننا نملك أوزانهم الفعلية، قارنّاها مع أوزان الأساس واستخرجنا بصمة الطريقة. توافقت إشاراتهم مع الأساس بنسبة 71.6% فقط، أي أن نحو 28% من الإشارات قُلبت، بينما تحافظ التثنية الساذجة على كل إشارة. كما كانت مقاييس مجموعاتهم أكبر بمقدار 2.26 مرة من المتوسط الساذج. هذه بصمة تعويض الخطأ الذي يقلّل خطأ خرج الطبقة لا خطأ الوزن المفرد، أي عائلة GPTQ. وبما أن التوافق أعلى بكثير من 50% العشوائية، فالأساس هو Qwen غير معدّل، بما يتسق مع ادعائهم “دون إعادة تدريب”.

نفّذنا هذا التنبؤ لاختباره. مكمِّم ثنائي بتعويض الخطأ كتبناه يدوياً (عائلة GPTQ) استرجع نحو 10 أضعاف من الانهيار الساذج. الاتجاه كان صحيحاً. لكن بقيت فجوة كبيرة مع FP16 حتى بعد الاسترجاع، وتكبير المقياس 2.26 مرة وحده زاد الأمر سوءاً، ما يعني أن المقياس الأكبر لا يفيد إلا مقترناً بتحسين الإشارة. تعويض الخطأ المعياري ضروري لكنه غير كافٍ. الوصول إلى بِتّتهم الواحدة بلا فقد يحتاج معالجة الأوزان البارزة أو مخططات المتبقي، وهو بالضبط الجزء الذي حجبوه.

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

المصادر

• prism-ml/Bonsai-27B-gguf (Hugging Face)
• PrismML Releases Bonsai 27B (MarkTechPost)
• PrismML Bonsai 27B docs

نظرة عامة

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

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

ما هي أعمال Claude Code وموصلات MCP

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

الموصلات هي طبقة التكامل المبنية فوق خوادم MCP. تُضاف موصلات المكتبة بنقرة واحدة وتسجيل دخول عبر OAuth من قسم Connectors تحت Customize. من بينها Notion وGmail وSlack وHubSpot وLinear وCanva وAtlassian وMicrosoft 365. يضم دليل الموصلات أكثر من 375 تكاملًا يغطي الملفات والبريد الإلكتروني وإدارة المشاريع والتحليلات والتصميم والمبيعات وأدوات المطورين.

يوضّح المخطط أدناه الفرق في تدفق البيانات بين عمل ثابت وعمل حي.

flowchart TB
    U[المستخدم يفتح العمل] --> Q{هل هو عمل حي}
    Q -- لا --> S[عرض اللقطة<br/>المأخوذة عند الإنشاء]
    Q -- نعم --> M[إعادة استعلام موصلات MCP]
    M --> C1[المصادر المتصلة:<br/>Notion وSlack وHubSpot وغيرها]
    C1 --> R[العرض بالحالة الراهنة]
    R --> W{هل هو إجراء كتابة أو حذف}
    W -- نعم --> A[طلب موافقة المستخدم]
    W -- لا --> D[اكتمال تحديث الشاشة]
    A --> D

كيف يعمل

تتلخص الآلية في ثلاث قواعد.

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

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

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

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

مثال إعداد عملي

إضافة خادم MCP في Claude Code تتطلب أمرًا واحدًا وملف إعدادات واحدًا. إليك الأمر الفعلي لإضافة خادم MCP محلي.

# تسجيل خادم MCP في Claude Code
claude mcp add my-metrics --command "python3" --args "servers/metrics_mcp.py"

# التحقق من الخوادم المسجَّلة
claude mcp list

يمكن الإعلان عن خوادم MCP المرتبطة بمشروع في .mcp.json في جذر المستودع ومشاركتها مع الفريق. البنية كالتالي.

{
  "mcpServers": {
    "my-metrics": {
      "command": "python3",
      "args": ["servers/metrics_mcp.py"],
      "env": { "METRICS_DB_URL": "postgres://..." }
    }
  }
}

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

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

هذه الميزة هي النسخة الموجّهة للمستهلك من مشكلة نعمل عليها منذ فترة طويلة في Paxis. Paxis هو Agent-Native Cloud الخاص بـ ThakiCloud، ويتعامل مع المهارات والأدوات والسياسات كموارد من الدرجة الأولى. من أهم أجزاء طبقة الأدوات تلك خط الأنابيب الذي يدير موصلات MCP مع إعادة اتصال OAuth تلقائية. خطوة Anthropic في السماح للأعمال باستدعاء الموصلات تشير بالضبط إلى النقطة ذاتها التي يستهدفها تصميمنا: الوكلاء الذين يتحدثون مع أنظمة خارجية يحتاجون إلى ترقية الموصلات لتصبح موارد من الدرجة الأولى.

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

من الناحية التحتية، تمثّل ai-platform الطبقة التي تخدم خوادم MCP التي يستعلم عنها عمل حي، بشكل موثوق فوق K8s. حين يعرض فريق ما البيانات التي يراجعها كثيرًا كخوادم MCP، مثل MCP للمؤشرات الداخلية أو MCP لحالة النشر أو MCP للتكلفة، يستطيع المطورون تجميع لوحات تشغيل خاصة بهم عبر أعمال حية دون كتابة سطر واحد من الواجهة الأمامية. كون خلفية MCP موثوقة ومنخفضة التكلفة هو ما يجعل اقتصاديات الوكلاء ممكنة، ولهذا تتحرك طبقة الخدمة في ai-platform وطبقة الموصلات في Paxis ككيان واحد.

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

هناك بضع نقاط يجب توضيحها قبل التبني.

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

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

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

المصادر

• Claude Code now supports artifacts, Anthropic: claude.com/blog/artifacts-in-claude-code
• Connect Claude Code to tools via MCP, Claude Code Docs: code.claude.com/docs/en/mcp
• Get started with custom connectors using remote MCP, Claude Help Center: support.claude.com/en/articles/11175166
• Anthropic Claude Code Artifacts update, VentureBeat: venturebeat.com/data/anthropics-claude-code-artifacts-update-brings-live-shared-dashboards-and-interactive-workspaces-to-enterprises

Agent skills conduct the repetitive labor of GPU training, evaluation, and tuning. The human only supplies the goal through a prompt.

What Cosmos 3 and Agent Skills Are

Cosmos 3 is a foundation model NVIDIA built to handle the physical world. It uses a Mixture-of-Transformers architecture that unifies text, images, video, ambient sound, and motion tracking, combining an autoregressive reasoning tower responsible for logic and planning with a diffusion transformer that predicts future states. NVIDIA states that this model ranks first on multiple benchmarks including VANTAGE-Bench, PAI-Bench, Physics-IQ, RoboLab, and RoboArena. It comes in two sizes, the 64B Cosmos 3 Super and the 16B Cosmos 3 Nano, and this case study uses Nano.

The key here is not the model but the TAO agent skill attached alongside it. A TAO agent skill is a bundle of knowledge that automates the post-training workflow for vision models. It encapsulates task-specific knowledge such as framework details, launcher behavior, config structure, data loading conventions, and evaluation workflows, so that a coding agent like Codex or Claude can orchestrate a training pipeline on its own with minimal human intervention. In other words, a skill is not a single-line prompt but a reusable unit that packages an executable procedure together with failure recovery.

Post-Training That Finishes with Two Prompts

What makes this case study striking is that the only human input was two natural-language prompts.

The first prompt instructs LoRA post-training. It asks the agent to train nvidia/Cosmos3-Nano with LoRA on Toyota’s Woven Traffic Safety dataset, but to run a baseline evaluation first for comparison.

Perform LoRA post-training of the Cosmos 3 model on the Woven Traffic
Safety dataset. Training data: /home/.../WTS_dataset/wts_data_train
Validation data: /home/.../WTS_dataset/wts_data_val
Base model on Hugging Face: nvidia/Cosmos3-Nano
Also perform a baseline evaluation first, to compare with the post-trained model.

With this single prompt, the agent handled several tasks in sequence. It found and patched a missing FPS parameter in the data pipeline on its own, cached the model using a Hugging Face token, measured a pre-training zero-shot baseline of 54.41%, and then ran LoRA training. What stands out here is the instruction to “run a baseline evaluation first.” Instead of trusting a self-reported result after training, the agent pinned down a pre-training number as a measured baseline and actually measured the improvement. This is exactly the same principle we learned from our experiment last week.

The second prompt is an AutoML sweep. It leaves the search strategy and which hyperparameters to tune up to TAO, and asks the agent to optimize validation accuracy and summarize the best models.

Run an AutoML sweep to improve the LoRA result. Let TAO choose suitable
search strategies and tune the important training hyperparameters. Optimize
validation accuracy and summarize the best models.

Looking at the overall flow as a diagram, the human appears only at both ends, while the skill fills in the repetitive work in between.

flowchart TB
    A["Natural-language prompt<br/>(LoRA training + baseline eval)"] --> B["Coding agent<br/>(Codex / Claude)"]
    B --> C["TAO agent skill<br/>encapsulates framework, launcher, config,<br/>data loading, and evaluation knowledge"]
    C --> D["Automatic error patching<br/>(fixing missing FPS parameter)"]
    C --> E["Model caching<br/>(Cosmos3-Nano via HF token)"]
    C --> F["Baseline evaluation<br/>(zero-shot 54.41%)"]
    F --> G["LoRA post-training<br/>(8x A100, ~30 min/epoch)"]
    G --> H["AutoML sweep<br/>(43 parallel trials, 19.5 hours)"]
    H --> I["Serving the best adapter<br/>Cosmos 3 Reasoner NIM<br/>(OpenAI-compatible endpoint)"]

Environment setup is three tokens and one install script line. Set HUGGINGFACE_TOKEN, NGC_API_KEY, and AUTOML_LLM_API_KEY in the terminal, then install the agent skill with the script below.

export HUGGINGFACE_TOKEN="your_hf_token"
export NGC_API_KEY="your_ngc_key"
export AUTOML_LLM_API_KEY="your_llm_key"

curl -fsSL https://raw.githubusercontent.com/NVIDIA-TAO/tao-skills-bank/main/scripts/install-codex-agents.sh | bash

The training data is Toyota’s Woven Traffic Safety dataset, a video question-answering task with over 8,000 training and validation samples. It consists of four-choice questions about road structure, road type, and traffic safety situations.

The Numbers Two Prompts Produced

Performance improved clearly. All the figures below are values NVIDIA published, not results we reproduced.

Two prompts raised validation accuracy from 54.41% to 93.35%. NVIDIA published figures.

The zero-shot baseline was 54.41%, and the single-prompt LoRA run raised it by 32.73 points to 87.14%. On top of that, the AutoML sweep tuned hyperparameters with Bayesian optimization and pushed it to 93.35%, a gain of 38.94 points over the baseline. The key point is that these numbers came without a human touching a single hyperparameter by hand; the agent chose the search strategy and ran the repeated training itself.

To be honest about it, we also need to look at the cost numbers. LoRA training took about 30 minutes per epoch on 8x A100 80GB GPUs, and the AutoML sweep ran 43 trials in parallel across multiple A100 nodes, taking 19.5 hours. A full-parameter SFT run used as a comparison took 3h34m on H100, and NVIDIA states that LoRA cut GPU time to roughly one-seventh of that full SFT run. Once training finishes, Cosmos 3 Reasoner NIM serves the LoRA adapter through an OpenAI-compatible endpoint, a structure that deploys directly as a prebuilt microservice without requiring manual setup of vLLM dependencies or CUDA configuration.

Did We Run This Ourselves

To be honest, we did not reproduce this workflow in our own environment. The Cosmos 3 family of weights sits behind a gated Hugging Face repository, it requires 8 A100 GPUs plus NGC and AutoML LLM keys, and the parallel sweep used in the case study assumes multiple GPU nodes. We did not secure this combination of resources for this post. So every number above is a quote of a value NVIDIA published, and we do not present it as something we measured ourselves. We hold to the principle of never fabricating a benchmark without reproducing it. What we can do instead is dissect the structure of this case study and precisely contrast it with what is already running on our own platform, noting what matches and what differs.

Implications for ThakiCloud Products

This case study is a rare topic where the perspectives of both our products interlock.

From the Paxis lens, this is external validation of our thesis that skills should be treated as first-class resources. Paxis is ThakiCloud’s Agent-Native Cloud control plane, and it treats Skills, Tools, Policies, and Audit Logs as first-class resources. The Skill Harness selects from over 960 skills using BM25, runs them in an isolated sandbox, and routes every action through policy gates and audit logs. What NVIDIA’s TAO agent skill proves is that when a skill encapsulates framework details all the way down to failure recovery, a coding agent can reliably repeat a complex workflow. This is exactly the direction we have been defining skills in: not as prompts, but as units of execution. The difference is just as clear, though. TAO skills are tightly bound to the NVIDIA stack, so they are hard to use as-is outside the TAO launcher, Cosmos models, NGC, and NIM. The Paxis skill harness is designed to avoid dependency on any specific vendor or model, and that is exactly the core of the value we aim to deliver in on-premises and sovereign environments.

From the ai-platform lens, this is exactly the GPU training and serving we schedule every day. Throwing 43 AutoML trials in parallel across multiple nodes directly overlaps with how Kueue manages the GPU queue on our platform. NIM serving a LoRA adapter through an OpenAI-compatible endpoint solves the same problem our vLLM serving path solves. And the fact that LoRA cuts GPU time substantially compared to full SFT supports our thesis that low-cost serving and low-cost training are ultimately what make agent economics work. When a customer wants to post-train a foundation model on their own data, we offer a path where they slice GPUs with Kueue and serve adapters with vLLM on their own cluster, rather than going through a gated external cloud.

Put the two lenses together and the picture is complete. ai-platform underpins low-cost training and serving, and on top of that Paxis drives the agent with skills, policies, and audit. NVIDIA’s case study, using someone else’s benchmark, shows that this combination actually leads to real performance gains.

Limits and Counterarguments

To avoid overstating this case study, four things need to be kept in view together. First, “in one day” is a wall-clock measure, not a GPU-time measure. A 19.5-hour sweep across 8 A100 GPUs and multiple nodes is by no means cheap, and one-seventh is a relative figure against full SFT, not a claim of absolute cheapness. Second, 93.35% is a number from a narrow task: four-choice traffic-safety video QA. It should not be inflated into a claim that general physical reasoning ability improved by that much. Third, automation hides vendor lock-in. The reason the agent could patch errors “on its own” is that the skill bank already knew that exact framework’s error patterns in advance. That smoothness disappears once you step outside the stack. Fourth, “minimal intervention” is not zero intervention. A human still has to enter API keys, specify dataset paths, and install a skill bank suited to that task in the first place before the flow can begin. What the agent removed is repetitive labor, not judgment itself.

Even so, the direction is clear. Hardening workflow knowledge into a skill, having an agent execute that skill repeatedly, and confirming improvement through a measured gate rather than a self-report is not one vendor’s strategy but a common design pattern of the agent era. That structure is exactly what we are building with Paxis and ai-platform.

Sources

• NVIDIA Developer Blog, “Post-Train NVIDIA Cosmos 3 in One Day Using Agent Skills” (https://developer.nvidia.com/blog/post-train-nvidia-cosmos-3-in-one-day-using-agent-skills/)
• GitHub: NVIDIA/cosmos, NVIDIA-TAO/tao-skill-bank
• Hugging Face: nvidia/Cosmos3-Nano, nvidia/Cosmos3-Super
• Dataset: Woven Traffic Safety (WTS), Toyota

Overview

The paper is titled “Harness Updating Is Not Harness Benefit.” Read literally, updating a harness and benefiting from a harness are two different things. Most systems that work with self-evolving agents have measured these two as a single blob. An agent solves a task, extracts prompt or skill edits from the execution trace, runs the next task with the revised harness, and if the final score goes up, the system declares that “evolution worked.”

The problem is that this verdict conflates two distinct abilities: the ability to produce a useful, durable update from execution evidence, and the ability to actually put that updated harness to work when solving a task. Both abilities live inside the same model, but they are fundamentally different in character. And because prior evaluations measured both inside the same execution loop at once, looking at the final score alone could not tell you where the improvement came from. The authors propose an experimental design that untangles this conflation, and the result runs directly against conventional wisdom in the field.

What This Research Asks

First, some terminology. Here, a harness refers to the entire set of editable, external components that shape an agent’s behavior without touching the model’s parameters. Prompts, skills, memory, and tool definitions are all part of the harness. Self-evolution is the process by which an agent reviews its own execution outcomes and revises this harness on its own. The model stays fixed; only the surrounding knowledge and tooling change.

The study splits this evolution process into two abilities.

The first is harness-updating: the ability to look at evidence from a completed task and produce a useful, reusable, persistent update. Extracting a lesson from a failed case and writing it into a skill document, or noticing a recurring pattern and hardening it into a prompt rule, both fall under this category.

The second is harness-benefit: the ability, given an updated harness, to actually retrieve it and follow it to raise task performance. A good skill sitting unused in the library, or a skill that gets invoked but whose instructions are not followed through to the end, both produce zero benefit.

The key insight is that these two abilities must be measured separately. If you pair the model that produced the update with a different model that uses the update, you can tell whether an improvement came from the quality of the update or the quality of how it was used. The diagram below shows the structure of the conflation and where the separation happens.

flowchart TB
    A[Task Execution] --> B[Collect Execution Evidence]
    B --> C{Harness-Updating Capability<br/>Generate persistent updates from evidence}
    C --> D[Updated Harness<br/>Prompts, Skills, Memory, Tools]
    D --> E{Harness-Benefit Capability<br/>Invoke and faithfully follow updates}
    E --> F[Task-Solving Performance]
    F -.Measured together in the same loop.-> G[Measured Gain<br/>Two capabilities entangled]
    C -.Separated measurement.-> H[Flat<br/>Similar regardless of model tier]
    E -.Separated measurement.-> I[Non-monotonic<br/>Mid-tier models benefit most]

What Separating the Two Abilities Reveals

The result of the separated experiment comes down to two sentences. Both run against practical intuition.

First, harness-updating capability is flat across model tiers. Harness updates produced by models of very different capability tiers delivered surprisingly similar gains. In the authors’ own words, updates produced by a small 9B-scale model matched the gains delivered by updates from a top-tier frontier model. In other words, “who wrote the skill” barely moved the quality of the update. Extracting a rule and hardening it into documentation turns out to be a cheaper cognitive task than expected.

Second, harness-benefit capability is non-monotonic across tiers. Given the same updated harness, weak-tier models saw almost no gain, mid-tier models gained the most, and top-tier models gained less than the mid-tier models did. Rather than a curve that keeps climbing as you move up, it is a curve that bulges in the middle.

Overlay these two results and the picture flips. Assigning an expensive frontier model to the evolver role, the one that produces updates, in a self-evolving system is close to wasted budget, since update quality is flat regardless. Assigning an expensive model to the agent that actually solves tasks is not necessarily optimal either, since benefit is non-monotonic. A strong model already has its own habits set, and tends to follow an external harness’s instructions less closely.

Why Weaker Models Don’t Benefit

The most practically useful part of the paper analyzes why weak-tier models fail to benefit. The authors point to two failure modes.

The first is activation failure. Even when a skill in the library is a perfect match, the model fails to retrieve it. The judgment required to connect a relevant harness artifact to the current situation simply does not fire. The skill exists, but gets dropped at the retrieval and selection stage, so no amount of accumulated updates helps.

The second is unfaithful execution. The model successfully retrieves the skill, but fails to follow its multi-step instructions through to the end. When the ability to hold a long chain of instructions is weak, a good harness gets derailed into a partial, drifted execution partway through.

This diagnosis points to a clear prescription. To raise self-evolution performance, don’t raise the evolver’s intelligence, target harness invocation (activation) and faithful execution of long instructions. Your capability budget buys more when spent on the side that uses updates, specifically on these two bottlenecks, rather than on the side that produces them.

Implications for ThakiCloud Products

This study’s conclusion lines up closely with the discipline we’ve built running Paxis. Paxis is ThakiCloud’s Agent-Native Cloud, and it treats skills, tools, and policies as first-class resources. We select from more than 960 skills using BM25 and execute them in isolated sandboxes, and our self-evolving skill loop extracts lessons from failures and revises skill documentation. In other words, we already run a “harness-updating” loop every day.

The first lesson this study offers is: don’t attach an expensive model to the evolver. A nightly evolution loop that improves skills and logs retrospectives can run on a low-cost tier under the premise that update quality is flat. In fact, our skill model policy already starts evolution and orchestration stages on sonnet by default, pinning a higher-tier model only for the small set of skills where content quality is itself the deliverable. This study gives that choice an evidentiary basis: it was optimization with no quality loss, not just cost savings.

The second lesson is the diagnosis that the bottleneck is “activation and execution.” In our environment, this is precisely the problem of skill routing and gate compliance. No matter how many skills exist, if the right one is not retrieved at request time, that is activation failure, and if a skill is invoked but its deterministic gates are not honored, that is unfaithful execution. Paxis’s decision to strengthen skill retrieval with a BM25 router, and to have format and validation owned by code gates rather than the model’s own prose judgment, targets exactly these two bottlenecks. Performance is decided less by piling on more good skills and more by the plumbing that retrieves the right skill precisely and enforces its instructions to the end.

There is an infrastructure implication too. ai-platform serves multiple model tiers on top of K8s and Kueue. This study suggests that when deploying a self-evolving pipeline, it is reasonable to place different model tiers in different roles for the evolver and the task solver. A mixed deployment, a cheap model as evolver and a mid-tier model as the task solver, is a design that can save substantial cost in multi-tenant GPU scheduling while holding quality steady.

Limitations and Counterarguments

Before carrying this study straight into practice, a few caveats are worth naming.

First, the conclusions of “flat” and “non-monotonic” are tied to the task distribution and harness types the experiments covered. Rule-extraction work like revising skill documentation may show flat updating capability, but updates that involve implementing complex tools or generating long orchestration code may well reopen the gap between model tiers. Whether our own updates lean toward the former or the latter is something each team has to measure for itself.

Second, the finding that top-tier models benefit less from an external harness can also be read as a ceiling effect: a strong model is already good, so there is less room left to improve. This does not mean the harness is useless. Absolute performance can still be higher for a strong model; the harness is simply a marginal gain layered on top.

Third, for an organization like ours that already practices “evolve cheap, gate expensive,” this study reads less like a new direction and more like quantitative backing for an existing discipline. For a team that has been reflexively raising the evolver model’s tier whenever self-evolution performance stalls, on the other hand, this data is a clear signal to reallocate budget.

In the end, this study leaves us with one practical rule. Don’t look at a self-evolving harness’s performance as a single score. Decompose it into two axes, updating and benefit, and measure each separately. Only once you separate them does it become clear where your capability budget should actually go.

Sources

• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents, arXiv 2605.30621: arxiv.org/abs/2605.30621
• Hugging Face Papers page: huggingface.co/papers/2605.30621
• Related background: Agentic Harness Engineering, arXiv 2604.25850: arxiv.org/html/2604.25850v3

Source: RT @kimmonismus: NVIDIA says Codex post-trained Cosmos 3 Nano from 54.41% to 93.35% accuracy in one day - with two prompts · twitter

What this means for ThakiCloud

The catch with a self-improving loop isn’t the accuracy, it’s the meter. Every round of getting smarter is another stretch of GPUs running flat out, and on a rented cloud that stretch shows up as a line item. Run the loop on someone else’s hardware and the model improves while the invoice does too. ThakiCloud’s Metis keeps training and inference inside your own walls (on-prem), so both the smarter model and the compute that made it stay under your control. Let Paxis’s agents refine the model and Metis absorb the training, on your racks, not a landlord’s counter.

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

One developer wrote this: “I’m 33 and I think Claude Code is melting my brain. For six months straight I’ve had five or six terminals open at once, waiting on responses just to smash enter 90% of the time. That’s the whole job now. And it’s doing something to me.” He went on to admit this might be a problem with how he leans on the tool rather than the tool itself, but insisted the effect is real regardless.

The reason this short confession spread so widely across the developer community is simple: many people are standing in the same spot. Running several AI coding agents in parallel is no longer an experiment but an everyday shape of work. Guides on how one person can match the throughput of a small engineering team through parallel workflows have appeared in several places, and tools for managing many Claude Code terminals on a single screen have emerged. Anthropic itself documents power-user tips for leveraging subagents and parallel sessions. The tools are ready, and throughput has clearly risen. What has not yet been discussed enough is what happens inside a person’s head behind that throughput.

This essay is about that inner side. Why parallel AI coding feels like it melts the brain, what that sensation actually is, and what exit appears once we reframe the problem as one of work structure rather than individual willpower. At the end, I will connect this view to the design of the agent platform ThakiCloud is building.

The New Labor Called Multi-Clauding

Let me first draw the actual shape of this labor precisely. Parallel AI coding, often called multi-Clauding, tends to flow like this. You split the screen and open five or six terminals. Each terminal gets a different task. One fixes a bug, one writes tests, one refactors, one tidies up documentation. While one produces an answer, your gaze shifts to another terminal to enter the next instruction. When a response arrives, you usually approve it if it looks plausible rather than reading it carefully, and move on. The physical form of that approval is the enter key.

On the surface this looks enormously productive. One person drives four or five threads of work at once, so by simple arithmetic it goes that much faster. Throughput really does rise. The problem is that the unit of this throughput is not code but a person’s attention. The burden of parallelism has quietly moved from the machine to the human. For a computer, parallelism means sharing resources; for a person, parallelism means continually splitting a single attention. And human attention is not a resource that grows as you divide it, but one that wears down as you divide it.

What the Sensation of a Melting Brain Really Is

“Melting brain” sounds like an exaggerated metaphor, but inside it several concrete phenomena that cognitive science has long observed overlap.

The first is attention residue. When you shift your gaze from one task to another, the attention in your head does not follow instantly. The afterimage of the previous task lingers for a while and eats into your focus on the next one. Cycling through six terminals makes this switch happen hundreds of times a day. Each switch’s loss is small, but accumulated, what remains at the end of the day is the fatigue of having skimmed the surface of everything and gripped nothing deeply.

The second is the collapse of flow. The state in which a developer writes the best code is a state of flow, deeply immersed in a single problem with the whole context loaded into the head. Parallel watching collides head-on with this state. Flow grows by feeding on uninterrupted, continuous time, and six terminals endlessly shatter that time into small pieces. In the end no task reaches the depth of flow, and only shallow management repeats.

The third is the trap of passive supervision. The confession of approving 90% of responses without reading them stabs exactly at this point. When automation works well most of the time, a person gradually trusts it and stops reviewing. It is the same structure as the automation-induced complacency that aviation safety research has long warned about. The problem is when a genuinely dangerous decision hides inside that unguarded 10%. The watcher does nothing most of the time, and by the moment judgment is actually needed, the judgment muscle has already gone dull.

The fourth is the risk of deskilling. The understanding you gain from grappling with a problem yourself and the understanding you pass through while approving an agent’s answer are different. The former builds muscle; the latter does not use it. When a day of just hitting enter repeats, that developer’s self-observation of no longer being as sharp as before may be not a complaint but an honest observation.

From Watcher to Orchestrator

The common prescription here appeals to individual willpower. Reduce the number of terminals, focus on one thing at a time, read the responses carefully. All correct, but against the powerful lure of throughput, a strategy of enduring on willpower alone usually does not last. I believe this problem should be reframed as one of work structure rather than one of will.

The core question is this: why must a person be directly watching six terminals? The reason, usually, is that only a person’s own eyes can confirm whether an agent’s output is right or wrong. Since the responsibility for verification hangs entirely on human eyes, the person has no choice but to sit beside every terminal. The finger that hits enter is in fact standing in for a verifier. And that verification is bound to be careless.

The exit is to move the responsibility for verification from human eyes to code. Instead of a person approving the agent’s output, let a deterministic gate render the verdict. Did it pass the tests? Does the type check hold? Are there any policy violations? These are not judgments confirmed by a person reading, but objective signals where a single command decides pass or fail. You can also make the results of several fanned-out agents get audited, refutation-style, by a verification stage with a different perspective before they are merged. Now the person moves from a watcher supervising six terminals to an orchestrator who designs what to build and judges only the results the gate has filtered.

The difference looks subtle but is decisive. In the watcher model, a person’s attention is spread thinly across every parallel branch. In the orchestrator model, a person’s attention gathers at only two points: the front end that decides what to delegate, and the back end that judges the few results that passed the gate. The tedious waiting and careless approval in between are owned by code, not by a person. Throughput is maintained or even rises, but the person’s cognitive load drops dramatically.

Implications for ThakiCloud Products

This view meets the design philosophy of Paxis, which we build, precisely. Paxis is an Agent-Native Cloud control plane that runs on top of ThakiCloud’s ai-platform, treating skills, tools, policies, and audit logs as first-class resources. Here parallel agents are not something a person sits beside and watches at each terminal, but autonomous execution units that an orchestrator delegates and a gate filters.

Concretely, several things implement the exit described above. Each agent runs in an isolated sandbox, so it does not contaminate another’s half-finished work; the need for a person to hold six task states in their head at once is reduced. Fanned-out results must pass policy gates and audit logs, and in operations we have pinned down the discipline that fanned-out work must always be closed with a verification stage. Code outputs are filtered by test-run results; outputs requiring judgment are filtered by adversarial verification from different perspectives. Since the responsibility for verification lies in code rather than in human eyes, the developer can remain a person who sets direction rather than a watcher who hits enter.

To this is added the infrastructure view of ai-platform. Agents delegated this way are scheduled on GPU resources managed by K8s and Kueue, and isolated as multi-tenant. Infrastructure carries the throughput of autonomous execution, verification gates protect quality, and the person gathers attention on the most human work of all: design and judgment. Low-cost autonomous execution creates agent economics, and that economics in turn frees people from repetitive watching. The cognitive-cost problem of parallel AI coding is, in the end, a problem solved by a platform design that pulls the person off the burden of parallel processing.

Limits and Counterarguments

This story has counterarguments that must be honestly stated.

First, as that developer admitted at the outset, this may genuinely be a problem of the person rather than the tool. Some people handle parallel watching skillfully and feel little cognitive fatigue. Cognitive load varies greatly between individuals, and generalizing a single anecdote into everyone’s diagnosis is dangerous. That said, the fact that the same confession drew broad sympathy suggests this may be not a rare exception but a common experience produced by structure.

Second, orchestration itself creates a new cognitive load. To delegate well you must design what to split and how, and which gates to verify with, and this design is by no means free. One could criticize that it merely moves the burden of watching to the burden of designing. But the two burdens differ in nature. Watching is a reactive burden that lasts thinly all day; designing is an active burden concentrated at the front end. The latter is far closer to a person’s growth and mastery.

Third, gates are not omnipotent. There are clearly kinds of defects a verification gate cannot catch. If a gate filters out nothing, that is not a sign of perfection but a sign that the gate is powerless. Moving verification to code does not make human judgment disappear; rather, pouring human judgment fully into the few results the gate has filtered is the heart of this structure. Automation should be a tool that gathers thinking where it is most needed, not one that replaces thinking.

The sensation of your brain melting from hitting enter is not a reason to blame the tool, but a signal to redesign the structure in which we work with it. Whether you remain a watcher or become an orchestrator depends, in the end, not on individual will but on a design decision: where you place the responsibility for verification.

Sources

• Braeden (@BraedendotTECH), X post: Claude Code is melting my brain
• Eva Keiffenheim, The Cognitive Costs of Multi-Clauding
• CodeAgentSwarm, How to Set Up Multiple Claude Code Terminals in Parallel (2026)
• ShareUHack, A One-Person Engineering Team: The Complete Claude Code Parallel Workflow Guide
• Anthropic, Claude Code power user tips

Attempts to run large models on small devices mostly go one of two ways. One is to train a small model from scratch, and the other is to compress a large model’s weights after the fact. The latter has always hit the same wall. Below 4-bit, short benchmarks look fine, but quality collapses on longer reasoning tasks like math or coding.

On July 14, 2026, PrismML released Bonsai 27B, which addresses this wall head-on. Bonsai 27B is not a newly trained model. It leaves Qwen3.6-27B as is and represents only the weights in low-bit form. The architecture is unchanged. Two variants were released under Apache 2.0, and the ternary build reportedly keeps 94.6% of the original quality at 5.9GB, while the 1-bit build keeps 89.5% at 3.9GB.

This post reads Bonsai 27B from ThakiCloud’s perspective of serving low-bit models in a multi-tenant setting. We go in order through how the compression works, why memory rather than storage capacity is the real constraint, and what practical implications this trend carries for our inference infrastructure. Up front: all benchmark figures below are numbers PrismML has published, not values ThakiCloud has reproduced independently.

What Bonsai 27B Is

Bonsai 27B is a low-bit representation of Qwen3.6-27B. Applied to a multimodal model composed of about 24.8B language weights, 0.46B in the vision tower, and 2.5B in embeddings and the LM head, it converts the entire set of matrix-heavy components to low-bit. This includes embeddings, attention projections, MLP projections, and the LM head, while only a tiny tail of parameters such as normalization and scale stay at high precision. The vision tower is kept separately at 4-bit HQQ and is only loaded when there is image input.

The two variants differ in character. Ternary Bonsai 27B represents weights with three values, {-1, 0, +1}, giving an effective 1.71 bit and an ideal size of 5.9GB. 1-bit Bonsai 27B uses only two values, {-1, +1}, giving an effective 1.125 bit at 3.9GB. Context is supported up to 262K tokens, and this stays practical because about 75% of Qwen3.6-27B’s attention is linear.

flowchart TB
    A[Qwen3.6-27B<br/>FP16 54GB] --> B[Group-wise split<br/>1 group per 128 weights]
    B --> C{Low-bit codebook}
    C -->|Ternary| D[-1, 0, +1<br/>about 1.585 bit]
    C -->|Binary| E[-1, +1<br/>1.0 bit]
    D --> F[One FP16 scale per group<br/>+16/128 bit]
    E --> F
    F --> G[Ternary 1.71 bpw 5.9GB<br/>Binary 1.125 bpw 3.9GB]
    G --> H[Vision tower<br/>4-bit HQQ stored separately]
    H --> I[llama.cpp / MLX<br/>on-device inference on laptops and phones]

How the Compression Works

The core idea is simple. Each weight is stored as a single code, and every group of 128 weights shares one FP16 scale. The actual weight is reconstructed as the product of the group scale and the code, in the form w_i = s_g · t_i.

Tracing the bit accounting makes the storage cost clear. One ternary value carries log2(3) ≈ 1.585 bits. Adding one FP16 scale per 128 values adds 16/128 bits, bringing the total to about 1.71 bits, roughly a 9.4x reduction versus FP16. Binary is 1 bit per value itself, and with the same scale overhead it comes to 1 + 16/128 = 1.125 bits, roughly a 14.2x reduction.

An interesting contrast appears here. The commonly named “4-bit” Qwen3.6-27B Q4_K_XL build actually averages 5.2 bits, and the “2-bit” IQ2_XXS actually averages 2.8 bits. The name and the real average bit count differ. Bonsai is also different from BitNet. BitNet trains from scratch at low bit to avoid collapse, but Bonsai compresses an already-trained model after the fact. PrismML claims it avoided collapse without retraining, but the details of this claim rely on the published technical documentation.

Reported Benchmark Results

PrismML stated it evaluated 15 benchmarks in thinking mode on H100 using EvalScope and vLLM. The table below shows those reported figures. To emphasize again, these numbers are values the provider has published, not values ThakiCloud has reproduced, and independent reproduction requires separate verification.

Breaking it down by category shows the compression does not create uniform loss. Math holds up relatively well, from 95.33 at FP16 to 93.40 for ternary and 91.66 for 1-bit. Agent tasks and tool calling, in contrast, drop sharply from 80.00 to 74.01 for ternary and 66.03 for 1-bit, and vision falls from 72.61 to as low as 59.57 for 1-bit. Instruction following also loses significantly, from 78.47 to 65.74 for 1-bit.

The contrast PrismML emphasizes is the selective collapse of existing sub-4-bit builds. IQ2_XXS keeps 88.93 on short-answer tasks like MMLU-Redux but collapses to 57.5 on AIME26 and 56.4 on LiveCodeBench. The point is that short benchmarks mask this collapse. This observation itself is a practical insight that anyone who has worked with low-bit quantization would recognize.

Memory Is the Binding Constraint

Reading the Bonsai 27B release purely by its size numbers misses the point. The conditions for fitting a model on a phone are much stricter than storage capacity alone. iOS limits a single app to roughly half of physical memory, so a 12GB iPhone actually exposes only about 6GB. This is why the 3.9GB build matters.

The second budget is the KV cache. Because only 16 of 64 layers have a growing full-attention cache, it costs about 64KiB per token at FP16. Filling the full 262K window costs about 17.2GB, and using a 4-bit KV cache brings this down to about 4.3GB. No matter how much the model weights are reduced, a longer context will consume memory through the KV cache, so low-bit weights and a low-bit KV cache need to go together.

PrismML also says it measured the quality impact of cache compression. Against its own FP16-KV baseline, Ternary Bonsai showed an output forward-KL of 0.0011 nats on MATH-500, while Q4_K_XL showed 0.0146. At 100K tokens, using an FP16 cache, 1-bit peaks at about 11.6GB and ternary at about 14.7GB. In other words, even after shrinking the weights, long contexts require lowering cache precision as well for the model to actually fit on a device.

Throughput and Speculative Decoding

Generation is bound by memory bandwidth. The fewer bytes read per step, the more tokens per second. Prefill, on the other hand, is compute-bound, so the compression effect is relatively smaller there. The throughput PrismML released shows exactly this property.

PrismML also shipped a DSpark drafter trained specifically for the Bonsai 27B target. On H100 with a draft depth of k=4, it reports an accepted length of tau=3.6 for the binary target, that is 143.8 tok/s, a 1.37x speedup. Verification is lossless, so the output distribution stays identical. However, on Apple silicon the drafter is disabled by default at batch size 1.

Execution itself is standard. You can run a llama.cpp server or generate directly with llama-cli, and an MLX path is also provided. Tool calling uses the OpenAI-style tools array as is, and the response comes back as choices[0].message.tool_calls. Thinking mode is enabled by default and can be toggled per request.

What This Means for ThakiCloud

Low-bit serving touches both of ThakiCloud’s products.

ai-platform lens (infrastructure and serving). ThakiCloud’s ai-platform serves open-weight models across a variety of customer environments. What Bonsai shows is the possibility of putting 27B-class quality on a single 24GB GPU along with a 4-bit KV cache. This directly affects multi-tenant density. If more tenants can run on the same GPU, or the same SLA can be met with a smaller card, serving cost goes down. This matters especially for on-premises and sovereign deployments. Domestic public sector and regulated industries require self-hosting that keeps data from leaving the premises, but hardware budgets are limited. Lowering both model weights and the KV cache to low-bit together enables denser packing in a GPU pool scheduled with Kueue, which feeds directly into the cost efficiency and resource density we have emphasized. That said, low-bit is not always the answer. If a workload is agent- or tool-calling-centric, quality loss is significant as shown in the limitations section below, which calls for routing that varies precision by workload.

Paxis lens (agents and edge). Paxis is the Agent-Native Cloud control plane that runs on top of ai-platform, treating Skills, Tools, Policies, and Audit Logs as first-class resources. A model that runs on a phone at 3.9GB opens the door to on-device agents where privacy is sensitive. A setup where the prompt never leaves the device is useful for regulatory compliance and offline workflows. From Paxis’s point of view, it is a natural fit to run such local models inside sandboxed, isolated execution while passing every action through policy gates and audit logs. Low-bit on-device inference creates the economics for edge agents, and Paxis is the layer that governs that execution.

The two lenses complement each other. Low-cost serving (ai-platform) creates the economics for agents (Paxis).

Limitations and Counterpoints

The biggest caveat is the source of the benchmarks. All the figures above are PrismML’s own evaluations, and there is no independent reproduction yet. The argument pointing out IQ2_XXS’s selective collapse is persuasive, but the benchmarks that show Bonsai’s advantage are also self-measured by the same provider. A fair judgment needs third-party reproduction.

The unevenness of the quality loss also matters in practice. The 1-bit build’s agent and tool-calling score is only 66.03. Tool-calling accuracy at this level is risky for production agent pipelines. Vision at 59.57 and instruction following at 65.74 are similarly large drops, which means 1-bit is effectively limited to simple text reasoning and privacy-first on-device use. Paths that need quality should move up to ternary or higher precision.

Phone performance numbers also need careful reading. The iPhone tok/s figures are enough for short interactions but slow for long generations. Heat, battery, and sustained throughput are not visible in the benchmark table. The white paper reportedly measured 672 tokens per 1% of iPhone battery, but real-world latency and sustained performance are separate concerns.

Finally, the core claim of avoiding collapse without retraining relies on method details in the published documentation. The license is Apache 2.0, but the license inheritance relationship with the Qwen3.6 base needs verification before commercial deployment. In summary, Bonsai 27B is a genuine practical advance in low-bit quantization, but adoption decisions should be made together with workload-specific quality requirements and independent reproduction.

ThakiCloud Independent Reproduction

In the limitations above we noted that no independent reproduction existed yet. We ran one. The intended reader is an infrastructure engineer weighing a self-hosted low-bit pipeline. The short version is that PrismML’s released 1-bit model genuinely works, but the compression method itself cannot be reproduced, because it was never disclosed.

We first extracted and read all three whitepapers in full. What is public is the storage format, the inference kernels, and the benchmarks. The algorithm for assigning 1-bit weights without retraining while avoiding collapse appears nowhere. The 8B whitepaper explicitly calls it “proprietary Caltech intellectual property.” The method is sealed.

We then loaded their released Bonsai-1.7B-unpacked (their 1-bit weights materialized back to FP16) with stock tooling. Every 128-weight group used exactly one scale, and perplexity on a fixed passage was 3.492, essentially identical to the same base Qwen3-1.7B at FP16 (3.507). The released model is real and near lossless.

By contrast, reproducing naively from the public format alone (textbook BWN binarization) collapses completely at the same 1.125 bits. A 4-bit control confirms the harness is sound.

A sealed method can still be predicted. Because we hold their actual 1-bit weights, we paired them with the base weights and reverse-engineered a fingerprint. Their signs agreed with the base only 71.6% of the time, meaning about 28% of signs were flipped, whereas naive binarization preserves every sign. Their group scales were also 2.26x larger than the naive mean. That is the fingerprint of error compensation that minimizes layer output error rather than per-weight error, the GPTQ family. Since sign agreement is far above the 50% of chance, the base is unmodified Qwen, consistent with their “no retraining” claim.

We implemented that prediction to test it. A hand-written error-compensated binary quantizer (GPTQ family) recovered about 10x of the naive collapse. The direction was right. Yet even after recovery a large gap to FP16 remained, and simply enlarging the scale by 2.26x made things worse, which tells us the larger scale only helps when coupled with sign optimization. Textbook error compensation is necessary but not sufficient. Reaching their lossless 1-bit needs salient-weight handling or residual schemes beyond it, and that is exactly the part they withheld.

One caveat: this perplexity is a coarse signal on a short passage, measured on small models. Full category retention (tool use, vision) would require building their custom kernels, serving the 27B, and running the whole benchmark suite, which we leave as separate work. Still, to “does 1-bit actually work” the answer is yes, and to “can public materials reproduce that quality” the answer is no. That gap is the value of the technology.

Sources

• prism-ml/Bonsai-27B-gguf (Hugging Face)
• PrismML Releases Bonsai 27B (MarkTechPost)
• PrismML Bonsai 27B docs