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

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

ماذا حدث

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

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

مسار الهجوم: خط معالجة البيانات كان سطح الهجوم

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

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

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

flowchart TB
    A[المهاجم: يرفع مجموعة بيانات خبيثة] --> B[خط معالجة مجموعات البيانات]
    B --> C1["الثغرة 1<br/>remote-code dataset loader"]
    B --> C2["الثغرة 2<br/>dataset config template injection"]
    C1 --> D[تنفيذ تعليمات برمجية اعتباطية RCE]
    C2 --> D
    D --> E[الحصول على وصول بمستوى العقدة]
    E --> F[جمع بيانات اعتماد السحابة والعناقيد]
    F --> G[تحرك أفقي إلى العناقيد الداخلية]
    G --> H["إطار وكيل ذاتي<br/>آلاف الإجراءات عبر سرب من الصناديق الرملية قصيرة العمر"]

وزن القول إن وكيلًا ذاتيًا قاد الهجوم

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

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

دار هامش مثير للاهتمام في التقارير الثانوية. فمع تطور الاستجابة، عندما حاول الفريق تسليم التحليل الجنائي إلى نماذج تجارية متقدمة (GPT، Claude)، يُقال إن حواجز الأمان اعتبرت حمولات الاستغلال وآثار القيادة والتحكم هجمات ورفضت التعاون، فواصل الفريق الاكتشاف والتحليل بنموذج من فئة GLM 5.2 [تقديري]. تأتي هذه التفصيلة من بعض المنصات لا من الإشعار الرسمي لـ Hugging Face، لذا من الأسلم عدم قراءتها كحقيقة مؤكدة. لكن بصرف النظر عن دقتها، فإن التوتر نفسه، حيث لا يستطيع المدافع استخدام أداة بسبب سياسة أمانها، جدير بالتسجيل بوصفه أمرًا قد يتكرر.

ما الذي كان آمنًا وما لا يزال قيد التحقيق

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

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

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

منظور ThakiCloud: التعامل مع معالجة البيانات بوصفها حدّ ثقة

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

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

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

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

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

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

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

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

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

المصادر

• Security incident disclosure, July 2026 (مدونة Hugging Face الرسمية)
• Hugging Face breached by autonomous AI agent (Help Net Security)
• Hugging Face warns an autonomous AI agent hacked its network (BleepingComputer)
• World’s Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent (The Hacker News)
• تقارير ثانوية (العدد الدقيق للإجراءات وحكاية رفض النموذج تقارير منقولة لا حقائق مؤكدة): Cryptobriefing, Undercode Testing

الإشكالية: القبول ثابت بينما الحمل فعلي في الوقت الحقيقي

أصبحت مشكلة خدمة الاستدلال (inference) لنماذج لغوية كبيرة لعدة مستأجرين على وحدات معالجة رسوميات مشتركة تحدياً تشغيلياً شائعاً الآن. تتقاسم عدة جهات مستأجرة، تختلف فيما بينها من حيث تقطّع حركة المرور (traffic burstiness) وطول التسلسلات (sequence length) ومستويات اتفاقية مستوى الخدمة (SLO)، مسرّعاً واحداً عالي السعة مثل H200 في الوقت ذاته. في المنصات القائمة على Kubernetes، عادة ما يقرر مجدوِل قائم على الحصص والطوابير (quota and queue based scheduler) مثل Kueue أي الأعمال يُسمح لها بالدخول إلى المجمع (pool)، لكن المعاملات الخاصة بزمن الخدمة، مثل حجم الدفعة (batch size) والعدد الأقصى للتسلسلات المتزامنة (max concurrent sequences)، وهي التي تحدد كيفية تقاسم الطلبات التي دخلت بالفعل لسعة المحرك المحدودة، تظل عادة مثبتة بشكل ثابت وقت النشر (deployment).

تطرح هذه الورقة البحثية السؤال الذي يترتب طبيعياً على ذلك. في مجمع H200 متعدد المستأجرين تديره Kueue، حين تتشارك عدة جهات مستأجرة خادم استدلال vLLM واحداً، هل يستطيع عميل نموذج لغوي كبير يراقب قياسات ذاكرة وحدة معالجة الرسوميات وزمن الاستجابة عن بعد (telemetry) في الوقت الفعلي، ويعيد ضبط حجم الدفعة والعدد الأقصى للتسلسلات المتزامنة لكل مستأجر عبر الإنترنت (online)، أن يحسّن فعلياً جبهة باريتو (Pareto frontier) للإنتاجية (throughput) وزمن الاستجابة عند المئين 99 (p99 latency) والتكلفة، مقارنة بالتحكم الثابت في القبول لدى Kueue؟ ولكي يجيب المؤلفون عن هذا السؤال، صمموا بروتوكولاً تجريبياً كاملاً يُفترض تشغيله على وحدة H200 واحدة، لكنهم يوضحون منذ البداية أن التنفيذ نفسه لم يتم لعدم توفر الوصول إلى سياق مجموعة Kubernetes المستهدفة. لذلك، لا يظهر في هذه الورقة أي رقم واحد لمعدل إنتاجية أو زمن استجابة قِيس على عتاد حقيقي. وبدلاً من ذلك، تقدم الورقة ثلاثة أشياء: صياغة رياضية لحلقة التحكم (control loop) الخاصة بمسألة الضبط الديناميكي لحجم الدفعة والتزامن (concurrency) عبر الإنترنت، وبروتوكولاً قابلاً للتكرار (reproducible) يمكن تنفيذه فور استعادة الوصول إلى المجموعة، ومحاكاة قائمة انتظار (queuing simulation) حتمية تختبر بنية ثلاث سياسات تحكم مختلفة تحت الضغط.

صياغة مسألة الضبط كحلقة تحكم

تصوغ الورقة مسألة الضبط الديناميكي عبر الإنترنت لحجم الدفعة والتزامن الخاصين بكل مستأجر باعتبارها مسألة تحكم مغلقة الحلقة (closed loop control) في زمن منفصل (discrete time)، ذات بنية شبيهة بعملية قرار ماركوف (Markov decision process). تتكون الحالة (state) من عمق طابور كل مستأجر، ونسبة استخدام ذاكرة وحدة معالجة الرسوميات، ومئينات زمن الاستجابة الأخيرة (p50/p95/p99)، والحد الأقصى الحالي للتزامن. أما الفعل (action) فهو زيادة أو نقصان محدودة النطاق في تزامن كل مستأجر. وتُصاغ دالة المكافأة (reward function) بطرح عقوبة على تجاوز زمن الاستجابة عند المئين 99 لاتفاقية مستوى الخدمة، وبند التكلفة، من الإنتاجية، بحيث تُحسَّن الإنتاجية وزمن الاستجابة والتكلفة معاً ضمن نطاق آمن. وبناءً على هذه الصياغة، يقترح المؤلفون أيضاً طريقة دمج العميل في عملية النشر الفعلية. فالعميل لا يحل محل قبول المهام (job admission) الخاص بـ Kueue، بل يعمل كعامل جانبي (sidecar) داخله، ويضبط فقط طريقة تقاسم الأعمال التي قُبلت بالفعل لسعة المحرك. والنقطة الجوهرية أن الرافعة التي يتم التحكم بها ليست معامل max_num_seqs الداخلي لمحرك vLLM، بل تزامن القبول (admission concurrency) الخاص بكل مستأجر من جهة العميل. ولأن إصدارات vLLM الإنتاجية لا تُعرِّض معاملات المحرك كمقبض (knob) يمكن تغييره في الوقت الفعلي دون إعادة تشغيل، فإن هذا التصميم يعكس القيد العملي القائل بأن النقطة الوحيدة القابلة فعلياً للضبط هي عدد الطلبات المتزامنة الواردة إلى الخادم.

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

التحذير الذي كشفته المحاكاة: التحكم الديناميكي الساذج كان أسوأ من الثابت

لسد الفراغ الناتج عن عدم تنفيذ البروتوكول التجريبي، بنى المؤلفون محاكاة لقائمة انتظار (queuing simulation) في زمن منفصل، ثابتة البذرة (seed fixed)، مكتوبة بالكامل باستخدام مكتبة Python القياسية فقط. وعلى نموذج مبسّط يتشارك فيه مستأجران مجمعاً محدوداً من الفتحات (slots)، شغّلوا ثلاث سياسات على مدى 20 بذرة عشوائية (seed) و1800 ثانية لكل منها، وأخذوا المتوسط. تُثبّت السياسة الثابتة الحد الأقصى لتزامن كل مستأجر عند 4. أما السياسة الديناميكية الساذجة فتراقب نسبة استخدام ذاكرة وحدة معالجة الرسوميات وزمن الاستجابة عند المئين 99 ضمن نافذة مدتها 6 ثوانٍ كل 3 ثوانٍ، وتضبط المستأجرَين معاً بزيادة أو نقصان مقداره 1. أما سياسة العميل المتمايز (differentiated agent) فهي نموذج بديل (surrogate model) يحاكي استدلالاً أكثر تطوراً للعميل، من خلال مراعاة نسبة التراكم (backlog ratio) لكل مستأجر بشكل مستقل.

جاءت النتائج مخالفة للتوقعات. فقد كانت السياسة الثابتة الأفضل في كل من الإنتاجية (0.686 طلب/ثانية) وعدد الطلبات المُسقَطة (بمتوسط 1.9 طلب)، بينما انخفضت إنتاجية السياسة الديناميكية الساذجة إلى 0.515 طلب/ثانية مع إسقاط 309.5 طلباً في المتوسط. وكان أداء نموذج العميل المتمايز البديل أفضل من السياسة الديناميكية الساذجة (إنتاجية 0.601 طلب/ثانية، وإسقاط 154.7 طلباً)، لكنه ظل غير قادر على مجاراة السياسة الثابتة، كما ارتفع زمن الاستجابة عند المئين 99 في كلا الشكلين الديناميكيين مقارنة بالسياسة الثابتة (11.75 ثانية)، إذ بلغ 12.79 ثانية و13.25 ثانية على التوالي.

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

كان زمن الاستجابة عند المئين 99 للسياسة الثابتة هو الأدنى، ولم يتمكن أي من المتحكمين الديناميكيين من تقليل زمن الاستجابة في الذيل (tail latency) ضمن نطاق هذه المحاكاة. هذه نتائج محاكاة بمتوسط 20 بذرة عشوائية، وليست قِيماً مقيسة فعلياً على عتاد.

يتحقق المؤلفون من أن هذه النتيجة تعكس الديناميكيات الفعلية للنموذج وليست مجرد خطأ برمجي (bug)، ويتتبعون السبب عبر أربع خطوات. أولاً، بما أن زمن الخدمة (service time) يتبع توزيعاً أسياً (exponential distribution)، فإن الذيل ثقيل بطبيعته أصلاً. فتوزيع أسي بمتوسط 2.5 ثانية يُنتج زمن استجابة عند المئين 99 يقارب 11.5 ثانية حتى دون أي انتظار في الطابور على الإطلاق، وهو رقم لا يختلف كثيراً عن الـ 11.75 ثانية التي سجّلتها السياسة الثابتة. أي أن معظم زمن الاستجابة في الذيل الملاحَظ لا ينبع من الازدحام، بل من تباين زمن الخدمة نفسه. ثانياً، عتبة التقييد (throttle threshold) مضبوطة عند 6 ثوانٍ، أي ضعف نافذة الـ 3 ثوانٍ، وهي أقل بكثير من زمن الاستجابة الجوهري عند المئين 99 البالغ 11.5 ثانية. وزمن الاستجابة عند المئين 99 المقدَّر ضمن نافذة قصيرة، اعتماداً على عدد قليل من الطلبات المكتملة فقط، يحمل ضوضاء (noise) كبيرة وينحاز نحو هذا الذيل الجوهري، لذا يتجاوز العتبة كثيراً حتى في حالات الحمل الخفيف فعلياً. ثالثاً، ولأن هذا التقييد الكاذب (false positive throttle) يخفض المستأجرَين معاً، فإن المستأجر غير المزدحم يُقيَّد أيضاً مع المستأجر المزدحم، وتحت مهلة زمنية صارمة (hard timeout) مدتها 3 ثوانٍ، يتحول كل تقييد غير ضروري مباشرة إلى إسقاط للطلب. رابعاً، ورغم أن قاعدة التوسّع (scaling rule) تسمح بالتعافي، فإن تكلفة التقييد والإسقاط أكبر بشكل غير متناظر من مكسب التوسّع، وبالتالي تنخفض الإنتاجية الصافية.

متطلبات التصميم المستخلصة من الفشل

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

ما تتركه هذه الورقة للشركة والمجتمع والعلم

بالنسبة إلى ThakiCloud، ما تتركه هذه الدراسة الآن ليس توفيراً مؤكداً في التكلفة، بل بروتوكولاً تجريبياً قابلاً للتكرار وقابلاً للتطبيق مباشرة على مجموعتنا من H200 متعددة المستأجرين، وتحذيراً محدداً من أن نهجاً ساذجاً قد يؤدي في الواقع إلى خسارة. وقد اكتمل الهيكل التجريبي (harness) نفسه بالفعل، بحيث يكفي، فور استعادة الوصول إلى المجموعة، استبدال دالة قرار عميل نموذج لغوي كبير فعلية داخل هذا البروتوكول. وعلى نطاق أوسع، كلما تطورت منهجيات تقليل هدر الموارد في مجمعات وحدات معالجة الرسوميات المشتركة، انفتح مسار عملي أمام المؤسسات الصغيرة أيضاً للوفاء باتفاقيات مستوى الخدمة على مجموعات مشتركة، وهو ما يفيد كفاءة الطاقة والتكلفة في بنية الاستدلال التحتية بشكل عام. أما من الناحية العلمية، فإن الإسهام يكمن في الصياغة الصريحة لحلقة تحكم يراقب فيها عميل نموذج لغوي كبير قياسات النظام في الوقت الفعلي ويعيد ضبط معاملات الخدمة الفائقة (serving hyperparameters) عبر الإنترنت، وفي التشخيص الكمي لأنماط فشلها من خلال محاكاة قابلة للتكرار. وتُعد هذه الورقة أيضاً جزءاً من سلسلة الأبحاث التي واصلتها ThakiCloud على نفس الأساس القائم على Kueue ووحدات معالجة الرسوميات. فمقارنة بـ ABJ-Gate، التي تجدول ميزانية أخذ العينات لنموذج الحَكَم (judge model)، وبـ Attested Confidential Sovereign Inference، التي تتناول التصديق عن بعد (remote attestation) لبيئة تنفيذ موثوقة (TEE) عند لحظة القبول، وبورقة “Escalate or Act?” التي تتناول قرارات ثنائية بين التصعيد أو التحرك إزاء حوادث منفصلة نادرة، تتميز هذه الورقة عنها جميعاً بتناولها مسألة مختلفة نوعياً، وهي التحكم المتعدد الأهداف في الوقت الفعلي الذي يُعاد ضبطه باستمرار على مدى ثوانٍ.

القيود

القيود التي تكشفها هذه الورقة عن نفسها واضحة. وأهمها أنه لا يوجد أي تحقق فعلي على عتاد حقيقي بأي شكل من الأشكال، إذ لم يُنفَّذ البروتوكول التجريبي بسبب تعذر الوصول إلى سياق المجموعة المستهدفة، ولم يُقَس أي رقم في الورقة على وحدة معالجة رسوميات فعلية. كما تبسّط المحاكاة الرموز (tokens) وذاكرة التخزين المؤقت KV إلى مجرد عدد فتحات عددي واحد (single scalar slot count)، دون أن تنمذج ديناميكيات مرحلتَي التعبئة المسبقة وفك الترميز (prefill/decode) أو ضغط الذاكرة، بل إن إشارة استخدام الذاكرة نفسها ليست سوى قيمة بديلة (proxy) لإشغال الفتحات، لا قياساً فعلياً لذاكرة الجهاز. كما اقتصر اختبار أنواع المستأجرين على نمطين اصطناعيين فقط لحركة المرور، لذا قد لا تعمم أنماط الفشل المكتشفة على مزيج آخر من حركة المرور. وسياسة العميل داخل المحاكاة أيضاً نموذج بديل مكتوب يدوياً وليس نموذجاً لغوياً كبيراً فعلياً، ولأن درجة الترابط ونوع الإشارة تغيّرا معاً في آن واحد، فلا يوجد حتى الآن دليل مُتحقَّق منه على أن عميلاً فعلياً قائماً على نموذج لغوي كبير سيستوفي متطلبات التصميم المستخلصة في القسم الرابع. ويوضح المؤلفون أيضاً بصراحة أنهم اكتفوا بالإبلاغ عن المتوسط والانحراف المعياري عبر 20 بذرة عشوائية، دون إجراء أي اختبار للدلالة الإحصائية (statistical significance). ولهذه الأسباب، تضع هذه الورقة نفسها لا كنتيجة مُتحقَّق منها، بل كصياغة رياضية وبروتوكول ومحاكاة تحذيرية.

يمكن الاطلاع على صفحة تفاصيل الورقة البحثية من هنا: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-21-agent-dynamic-batch-tuning-vllm

Source: RT @jun_song: Best Local AI models by VRAM size (7/18) · twitter

What this means for ThakiCloud

What the chart is really about is sovereignty: keeping the model, the data, and the infrastructure under your control instead of someone else’s. On-prem is simply the version of that where the whole thing runs inside your own facility rather than a rented datacenter. That is the exact seat ThakiCloud sells. Metis matches a model to the size of the GPU you actually have, and Paxis runs agents on top of it to get real work done. Because the model lives in your rack, the meter does not tick per token. The cloud still has its place. The point is to ask which card is already in your drawer before you rent another.

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

The story that shook timelines over the weekend was not a new model or a new benchmark. It was a notice that Hugging Face, the center of the open AI ecosystem, had been breached. What drew even more attention was who did it. According to the company, no human hacker typed commands through the night. An autonomous AI agent framework drove the attack from start to finish.

A company that sells models getting hit by a model makes for a striking narrative. But the point of this post is not to enjoy the irony. For a company like ThakiCloud that handles models and data on top of customer infrastructure, the real work is to soberly separate exactly where the attack entered and what has been confirmed. And the entry point here was not some flashy zero-day. It was the thing we touch every day: a dataset.

What Happened

Hugging Face disclosed the breach in a blog post on Thursday, July 16, 2026. It came after the company had already confirmed unauthorized access to internal datasets and credentials earlier that week and had contained the intrusion. By the company’s account, the intrusion began in the data-processing pipeline, where the attacker used a single malicious dataset to open two code-execution paths.

That is the confirmed skeleton: an autonomous agent drove it, the entry point was a dataset, and two vulnerabilities led to code execution. The remaining details are emphasized differently across outlets, so confirmed facts and secondary reporting should be read apart.

The Attack Path: The Dataset Pipeline Was the Attack Surface

The essence is the entry method. The attacker uploaded a malicious dataset to the Hugging Face Hub. The moment that dataset passed through the processing pipeline, two vulnerabilities fired in sequence. One was a remote-code dataset loader path; the other was a template injection while parsing the dataset configuration. Both ultimately resolved into arbitrary code execution.

The idea that a dataset can run code may sound unfamiliar, but practitioners know the risk well. Many dataset loaders trust and execute loading scripts from remote repositories and render configuration fields as templates. That flexibility, built for convenience, becomes an execution channel the moment it meets input that crosses a trust boundary.

What followed once code execution was secured was a textbook breach chain. The attacker escalated with node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over the weekend. The entry was a single point, but from the moment that point granted execution privileges, the spread propagated automatically.

flowchart TB
    A[Attacker: uploads malicious dataset] --> B[Dataset processing pipeline]
    B --> C1["Vulnerability 1<br/>remote-code dataset loader"]
    B --> C2["Vulnerability 2<br/>dataset config template injection"]
    C1 --> D[Arbitrary code execution RCE]
    C2 --> D
    D --> E[Node-level access obtained]
    E --> F[Cloud and cluster credentials harvested]
    F --> G[Lateral movement into internal clusters]
    G --> H["Autonomous agent framework<br/>thousands of actions across a swarm of short-lived sandboxes"]

The Weight of Saying an Autonomous Agent Drove It

The novel part of this incident is not the tooling but the cockpit. Hugging Face described the campaign as “an autonomous agent framework executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services.” Instead of a human intervening at each step, the agent handled reconnaissance, execution, and movement in a continuous chain.

The problem this structure poses for defenders is speed and scale. A human attacker has physical limits of fatigue and typing speed, but an agent swarm throws thousands of attempts in parallel and moves to the next one the instant a step fails. Using and discarding short-lived sandboxes erases the anchors for detection, and command-and-control that migrates across public services defeats blocklists.

One interesting side note circulated in secondary reporting. As the response unfolded, when the team tried to hand forensics to commercial frontier models (GPT, Claude), safety guardrails reportedly recognized the exploit payloads and command-and-control artifacts as attacks and refused to cooperate, so the team continued detection and analysis with a GLM 5.2-class model [estimated]. This detail comes from some outlets rather than Hugging Face’s official notice, so it is safer not to read it as settled fact. Regardless of its accuracy, though, the tension itself, where a defender cannot use a tool because of its safety policy, is worth recording as something that may recur.

What Was Safe and What Is Still Under Investigation

The easier an incident is to exaggerate, the clearer the boundaries must be drawn. Hugging Face said it closed the vulnerable code-execution paths, evicted the attacker, rebuilt the compromised nodes, and revoked and rotated all affected credentials. It added that it found no evidence of tampering with public models, user-facing datasets, or Spaces, and that its software supply chain, including container images and published packages, was verified clean.

The user action was a precautionary recommendation. The company advised users to rotate access tokens and review recent account activity. There is an important distinction here. That recommendation is not a confirmation that user tokens were leaked en masse, but a conservative safety measure given the nature of an incident where internal credentials were harvested. Whether partner or customer data was affected was, as of the disclosure, still under investigation.

In short, what is confirmed is the internal breach and credential theft, the existence of two dataset vulnerabilities, and the swift containment and rotation. What remains open is whether partner and customer data was affected, and the confirmation of some details in secondary reporting (the exact action count, the model-refusal anecdote). Mixing the confirmed with the unconfirmed makes an incident look bigger or smaller than it is.

The ThakiCloud View: Treating Dataset Processing as a Trust Boundary

The lesson this incident offers an infrastructure company is clear. A dataset is not a passive file but an active input that can execute code the moment it is processed. So we look at this through two lenses.

Through the ai-platform lens, ThakiCloud’s ai-platform is a K8s-based multi-tenant AI/ML infrastructure. In such an environment, dataset loading and preprocessing must be treated as input from outside the trust boundary, not inside it. Concretely, this means running dataset-processing jobs in least-privilege isolated containers, blocking network egress by default, and separating node and cloud credentials so workloads cannot touch them directly. That this breach spread from node-level access to credential theft shows again why execution isolation and credential separation must be a default, not an option. This is also why demand for on-prem and sovereign AI is high: the more data and execution stay inside the customer boundary, the smaller the blast radius of such pipeline attacks.

Through the Paxis lens, this incident overlaps exactly with the threat model that an Agent-Native Cloud is designed for in the first place. Paxis is ThakiCloud’s Agent-Native Cloud, and it treats running skills and tools in isolated sandboxes and passing every action through a policy gate and audit log as first-class principles. That the attacker threw thousands of actions with an autonomous agent swarm proves precisely why a structure that screens agent behavior with policy before execution and records it in an audit log after execution is necessary. To counter an attack pattern that uses and discards short-lived sandboxes, the defender too must isolate each execution, explicitly scope its permissions, and leave a reversible audit trail. Isolated execution plus policy-and-audit is not a luxury of the agent era but a minimum requirement.

The two lenses complement each other. ai-platform narrows the blast radius at the infrastructure layer of dataset processing, while Paxis screens each action at the control layer of agent behavior. In an attack like this one, where entry is a data pipeline and the spread is an autonomous agent, defense at both layers is needed to break the chain.

Limits and Counterpoints

To avoid overconfidence in this post’s conclusions, a few things should be made clear. First, the details of the incident are still being settled. Colorful details like the exact action count, the scope of credential theft, and the commercial-model refusal anecdote lean heavily on secondary reporting and must be distinguished from the confirmed facts of the official notice.

Second, our defensive narrative does not mean complete safety. Isolation and policy-and-audit are design principles that shrink the blast radius, not magic that eliminates the vulnerabilities themselves. Vulnerabilities like remote code execution in a dataset loader or injection in config parsing must continue to be found and patched at the code level, and isolation is the second line of defense that contains the damage when such a vulnerability fires.

Third, overrating autonomous-agent attacks is also risky. The root cause of this breach was not sophisticated AI but two familiar vulnerabilities that let input crossing a trust boundary execute code. The agent was merely the automation that exploited those vulnerabilities faster and wider. So the priority for response still lies in the fundamentals: separating untrusted input from execution privileges, detaching credentials from workloads, and making every execution observable.

Hugging Face’s swift containment and transparent disclosure will stand as a good response example. What remains our homework is simple: treat datasets as code rather than files, and make every agent action a subject of screening and audit.

Sources

• Security incident disclosure, July 2026 (Hugging Face official blog)
• Hugging Face breached by autonomous AI agent (Help Net Security)
• Hugging Face warns an autonomous AI agent hacked its network (BleepingComputer)
• World’s Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent (The Hacker News)
• Secondary reporting (the exact action count and model-refusal anecdote are cited reporting, not confirmed fact): Cryptobriefing, Undercode Testing

The Problem: Admission Is Static, but Load Is Real-Time

Serving LLM inference for multiple tenants on shared GPUs has become a common operational challenge. A single high-capacity accelerator such as the H200 hosts several tenants at once, each with different traffic burstiness, sequence lengths, and SLOs. On Kubernetes-based platforms, a quota- and queue-based scheduler such as Kueue typically decides which jobs are admitted into the pool, but the serving-time parameters that determine how already-admitted requests actually share the engine’s finite capacity, such as batch size and the maximum number of concurrent sequences, are usually fixed statically at deployment time.

The paper raises the question that naturally follows from this setup. In a multi-tenant H200 GPU pool managed by Kueue, when multiple tenants share a vLLM inference server, can an LLM agent that observes real-time GPU memory and latency telemetry and re-tunes each tenant’s batch size and maximum concurrent sequence count online empirically improve the throughput, p99 latency, and cost Pareto frontier over static Kueue admission control? To answer this question, the authors designed a complete empirical protocol meant to run on a single H200, but they state up front that execution itself was called off because access to the target Kubernetes cluster context was unavailable. As a result, not a single throughput or latency number measured on real hardware appears anywhere in this paper. Instead, the paper delivers three things: a control-loop formalization of the online batch and concurrency tuning problem, a reproducible protocol that can be executed the moment cluster access is restored, and a deterministic queuing simulation that stress-tests the structure of three control policies.

Formalizing the Tuning Problem as a Control Loop

The paper formalizes online per-tenant batch and concurrency tuning as a discrete-time closed-loop control problem with a structure similar to a Markov decision process. The state consists of per-tenant queue depth, GPU memory utilization, recent latency percentiles (p50/p95/p99), and the current concurrency cap. The action is a bounded-width per-tenant increment or decrement to concurrency. The reward function subtracts a penalty for p99 latency that exceeds the SLO and a cost term from throughput, and is designed to jointly optimize throughput, latency, and cost within a safe range. Building on this formalization, the authors also propose how the agent would integrate into an actual deployment. The agent does not replace Kueue’s job admission; it operates as a sidecar inside it, adjusting only how already-admitted jobs divide the engine’s capacity. The key point is that the lever being pulled is not the vLLM engine’s internal max_num_seqs, but client-side per-tenant admission concurrency. Production vLLM does not expose engine parameters as a knob that can be changed in real time without a restart, so this design reflects the practical constraint that the only point actually adjustable is the number of concurrent requests arriving at the server.

The control-loop structure in which an LLM agent observes GPU telemetry and per-tenant queue depth, produces a bounded-width concurrency adjustment, and thereby re-tunes the batch configuration. This is a conceptual architecture diagram, not a result measured on hardware.

The Warning the Simulation Raised: Naive Dynamic Control Was Worse Than Static

To fill the gap left by the unexecuted empirical protocol, the authors built a seed-fixed, discrete-time queuing simulation written entirely with Python’s standard library. On a simplified model where two tenants share a finite pool of slots, they ran three policies for 20 seeds of 1,800 seconds each and averaged the results. The static policy fixes each tenant’s concurrency cap at 4. The naive dynamic policy observes GPU memory utilization and 6-second-window p99 latency every 3 seconds and adjusts both tenants together by plus or minus 1. The differentiated agent policy is a surrogate model that mimics more sophisticated agent reasoning by independently reflecting each tenant’s backlog ratio.

The results defied expectations. The static policy was best on both throughput (0.686 req/s) and drop count (an average of 1.9 requests), while the naive dynamic policy’s throughput fell to 0.515 req/s and it dropped an average of 309.5 requests. The differentiated agent surrogate model did better than the naive dynamic policy (throughput 0.601 req/s, 154.7 drops) but still could not catch up to the static policy, and p99 latency was also higher for both dynamic variants than for the static policy (11.75 seconds), at 12.79 and 13.25 seconds respectively.

The static policy recorded the highest throughput and fewest drops, while both dynamic variants underperformed in the simulation. These are results from a deterministic queuing simulation averaged over 20 seeds, not values measured on an actual GPU.

The static policy had the lowest p99 latency, and neither dynamic controller reduced tail latency in this simulation regime. These are simulation results averaged over 20 seeds, not figures measured on hardware.

The authors verify that this result is the model’s actual dynamics rather than a simple bug, and trace the cause through four steps. First, because service time follows an exponential distribution, the tail is inherently heavy. An exponential distribution with a mean of 2.5 seconds forms a p99 around 11.5 seconds even with zero queuing at all, which is barely different from the 11.75 seconds the static policy recorded. In other words, most of the observed tail latency comes not from congestion but from the variance of the service time itself. Second, the throttle threshold is set at 6 seconds, twice the 3-second window, which is far below this intrinsic p99 of 11.5 seconds. The short-window p99, estimated from only a handful of completed requests, is noisy and biased toward this intrinsic tail, so it frequently crosses the threshold even under genuinely light load. Third, because the resulting false-positive throttles lower both tenants together, even a non-congested tenant gets restricted along with the congested one, and under a 3-second hard timeout, every unnecessary throttle converts directly into a drop. Fourth, while the scaling rule does allow recovery, the throttle-drop cost is asymmetrically larger than the scaling gain, so net throughput falls.

Design Requirements Drawn from the Failure

What this diagnosis tells us is not that dynamic tuning itself is useless. It is that when a noisy, tail-biased signal, throttling that couples tenants together, and a hard timeout combine, naive fixed-threshold control can actually turn out worse than static control. From here, the authors derive four design requirements that an effective agent controller must satisfy. The congestion signal must be robustly estimated from longer telemetry history and confidence estimates rather than raw short-window percentiles. Decisions must be differentiated per tenant rather than driven by a global signal that lumps tenants together. The asymmetric cost between throttling and scaling must be explicitly accounted for, and additional context such as burst-pattern recognition or per-tenant SLA metadata, which cannot be expressed with a fixed numeric threshold, must also be leveraged. The fact that the differentiated agent surrogate model actually recovered roughly half the loss relative to the naive controller suggests this direction may well be valid. However, the authors are clear that because both the coupling and the signal type were changed at the same time, this experiment alone cannot isolate which of the two contributed to the recovery.

What This Leaves for the Company, Society, and Science

For ThakiCloud, what this research leaves us right now is not a verified cost saving. It is a reproducible empirical protocol directly applicable to our multi-tenant H200 cluster, and a concrete warning that a naive approach could actually make things worse. The harness itself is already complete, so that once cluster access is restored, all that needs to be substituted into this protocol is an actual LLM agent decision function. More broadly, as methodologies for reducing resource waste in shared GPU pools are refined, a practical path opens up for smaller organizations to also meet SLAs on shared clusters. This benefits the overall energy and cost efficiency of inference infrastructure. Scientifically, the contribution is that it explicitly formalizes the control loop in which an LLM agent observes real-time system telemetry and re-tunes serving hyperparameters online, and quantitatively diagnoses its failure modes through a reproducible simulation. This paper is also part of the research lineage ThakiCloud has continued on the same Kueue-and-GPU foundation. Compared with ABJ-Gate, which schedules the judge model’s sampling budget, Attested Confidential Sovereign Inference, which handles TEE remote attestation at admission time, and “Escalate or Act?”, which handles binary escalate-or-act decisions for rare discrete accidents, this paper is distinguished from them in that it tackles a qualitatively different problem: real-time, multi-objective control that is continuously re-tuned on a second-by-second cadence.

Limitations

The limitations this paper itself discloses are clear. The most important is that there is no real-hardware validation of any kind: the empirical protocol was never executed because access to the target cluster context was unavailable, and not a single number in the paper was measured on a GPU. The simulation simplifies tokens and the KV cache down to a single scalar slot count and does not model prefill/decode or memory-pressure dynamics, and even the memory-utilization signal is merely a proxy for slot occupancy rather than an actual device-memory measurement. The tenant types tested are also limited to two synthetic traffic patterns, so the failure modes discovered may not generalize to other traffic mixes. The agent policy inside the simulation is likewise a hand-written surrogate model rather than an actual LLM, and because both the coupling and the signal type were changed at once, there is as yet no verified evidence that an actual LLM agent would satisfy the design requirements derived in Section 4. The authors also state plainly that they reported only the mean and standard deviation across 20 seeds and did not run any test of statistical significance. For these reasons, this paper positions itself not as a validated result but as a formalization, a protocol, and a cautionary simulation.

You can find the paper’s detail page here: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-21-agent-dynamic-batch-tuning-vllm

지난 주말 타임라인을 흔든 소식은 새 모델도, 새 벤치마크도 아니었습니다. 오픈 AI 생태계의 중심인 허깅페이스가 뚫렸다는 공지였습니다. 더 눈길을 끈 것은 침해의 주체였습니다. 사람 해커가 밤새 손으로 명령을 친 것이 아니라, 자율 AI 에이전트 프레임워크가 공격을 처음부터 끝까지 몰고 갔다고 회사가 밝혔기 때문입니다.

모델을 파는 회사가 모델에게 당했다는 사건의 구도는 자극적입니다. 그러나 이 글의 목적은 그 아이러니를 소비하는 것이 아닙니다. ThakiCloud처럼 고객 인프라 위에서 모델과 데이터를 다루는 입장에서는, 공격의 진입로가 정확히 어디였고 무엇이 확인됐는지를 냉정하게 구분하는 일이 곧 실무입니다. 이번 사건의 진입로는 화려한 제로데이가 아니라 우리가 매일 만지는 것, 바로 데이터셋이었습니다.

무슨 일이 있었나

허깅페이스는 2026년 7월 16일 목요일 블로그를 통해 침해 사실을 공개했습니다. 그 주 초에 내부 데이터셋과 자격증명에 대한 비인가 접근을 확인한 뒤 대응을 마무리하고 나서 낸 발표였습니다. 회사의 설명에 따르면 침입은 데이터 처리 파이프라인에서 시작됐고, 공격자는 악성 데이터셋 하나를 이용해 두 개의 코드 실행 경로를 열었습니다.

여기까지가 발표 주체가 명시적으로 내놓은 뼈대입니다. 자율 에이전트가 몰았다는 점, 진입로가 데이터셋이었다는 점, 그리고 두 개의 취약점이 코드 실행으로 이어졌다는 점입니다. 나머지 세부는 보도마다 강조점이 조금씩 다르므로, 확인된 사실과 이차 보도를 구분해 읽어야 합니다.

공격 경로: 데이터셋 파이프라인이 공격면이었다

핵심은 진입 방식입니다. 공격자는 허깅페이스 허브에 악성 데이터셋을 올렸습니다. 그 데이터셋이 처리 파이프라인을 통과하는 순간, 두 개의 취약점이 연달아 터졌습니다. 하나는 원격 코드 데이터셋 로더 경로였고, 다른 하나는 데이터셋 설정을 파싱하는 과정의 템플릿 인젝션이었습니다. 둘 다 최종적으로는 임의 코드 실행으로 귀결됐습니다.

데이터셋이 코드를 실행시킬 수 있다는 사실이 낯설게 들릴 수 있습니다. 그러나 실무자라면 익숙한 위험입니다. 많은 데이터셋 로더가 원격 저장소의 로딩 스크립트를 신뢰하고 실행하며, 설정 파일의 필드를 템플릿으로 렌더링합니다. 편의를 위해 만든 이 유연성이, 신뢰 경계를 넘는 입력을 만나면 그대로 실행 통로가 됩니다.

코드 실행을 확보한 다음의 전개는 전형적인 침해 체인이었습니다. 공격자는 노드 레벨 접근으로 권한을 끌어올렸고, 클라우드와 클러스터 자격증명을 수집했으며, 주말 동안 여러 내부 클러스터로 측면 이동했습니다. 진입은 한 지점이었지만, 그 지점이 실행 권한을 주는 순간부터 확산은 자동으로 번졌습니다.

flowchart TB
    A[공격자: 악성 데이터셋 업로드] --> B[데이터셋 처리 파이프라인]
    B --> C1["취약점 1<br/>remote-code dataset loader"]
    B --> C2["취약점 2<br/>dataset config template injection"]
    C1 --> D[임의 코드 실행 RCE]
    C2 --> D
    D --> E[노드 레벨 접근 획득]
    E --> F[클라우드·클러스터 자격증명 탈취]
    F --> G[내부 클러스터로 측면 이동]
    G --> H["자율 에이전트 프레임워크<br/>단기 샌드박스 스웜에서 수천 개 액션 수행"]

자율 에이전트가 몰았다는 말의 무게

이번 사건에서 가장 새로운 대목은 도구가 아니라 조종석입니다. 허깅페이스는 이 캠페인을 “자율 에이전트 프레임워크가 단기 샌드박스 스웜에서 수천 개의 개별 액션을 수행했고, 명령·제어 채널은 공개 서비스 위에 스스로 이전해 가며 자리를 잡았다”고 설명했습니다. 사람이 단계마다 개입하는 대신, 에이전트가 정찰과 실행과 이동을 이어서 처리했다는 뜻입니다.

이 구조가 방어자에게 던지는 문제는 속도와 규모입니다. 사람 공격자라면 피로와 타이핑 속도라는 물리적 한계가 있지만, 에이전트 스웜은 병렬로 수천 개의 시도를 던지고 실패하면 즉시 다음으로 넘어갑니다. 단기 샌드박스를 쓰고 버리는 방식은 탐지의 앵커를 지우며, 공개 서비스 위에서 이전하는 명령·제어는 차단 목록을 무력화합니다.

한 가지 흥미로운 곁가지가 이차 보도에서 돌았습니다. 대응 과정에서 상용 프런티어 모델(GPT, Claude)에 포렌식을 맡기려 하자 안전 가드레일이 익스플로잇 페이로드와 명령·제어 아티팩트를 공격으로 인식해 협조를 거부했고, 결국 GLM 5.2 계열 모델로 탐지와 분석을 이어갔다는 내용입니다 [추정]. 이 대목은 허깅페이스 공식 공지가 아니라 일부 매체 보도에 근거하므로 확정 사실로 읽지 않는 편이 안전합니다. 다만 사실 여부와 별개로, 보안 사고를 방어하는 쪽이 안전 정책 때문에 도구를 못 쓰는 상황 자체가 앞으로 반복될 수 있는 긴장이라는 점은 기록해 둘 만합니다.

무엇이 안전했고 무엇이 아직 조사 중인가

과장하기 쉬운 사건일수록 경계선을 분명히 그어야 합니다. 허깅페이스는 취약한 코드 실행 경로를 닫고, 공격자를 축출하고, 침해된 노드를 재구축했으며, 영향을 받은 자격증명을 전부 무효화하고 교체했다고 밝혔습니다. 또한 공개된 모델과 사용자용 데이터셋, Spaces에 변조 흔적은 발견되지 않았고, 컨테이너 이미지와 배포 패키지를 포함한 소프트웨어 공급망은 깨끗한 것으로 검증됐다고 덧붙였습니다.

사용자 조치는 예방 차원의 권고였습니다. 회사는 사용자에게 접근 토큰을 교체하고 최근 계정 활동을 검토하라고 안내했습니다. 여기서 중요한 구분이 있습니다. 이 권고는 사용자 토큰이 대량으로 유출됐다는 확인이 아니라, 내부 자격증명이 탈취된 사고의 성격상 취하는 보수적 안전 조치라는 점입니다. 파트너나 고객 데이터가 영향을 받았는지는 발표 시점 기준으로 여전히 조사 중이라고 회사는 밝혔습니다.

정리하면 확인된 것은 내부 침해와 자격증명 탈취, 두 데이터셋 취약점의 존재, 그리고 신속한 봉쇄와 교체입니다. 아직 열려 있는 것은 파트너·고객 데이터 영향 여부와, 이차 보도에 담긴 일부 세부(정확한 액션 수, 모델 협조 거부 일화)의 확정입니다. 확정과 미확정을 섞으면 사건이 실제보다 더 커지거나 더 작아 보입니다.

ThakiCloud 관점: 데이터셋 처리를 신뢰 경계로 다루기

이번 사건이 인프라 회사에 주는 교훈은 분명합니다. 데이터셋은 수동적인 파일이 아니라, 처리되는 순간 코드를 실행할 수 있는 능동적 입력이라는 사실입니다. 그래서 우리는 이 문제를 두 개의 렌즈로 봅니다.

ai-platform 렌즈에서, ThakiCloud의 ai-platform은 K8s 기반의 멀티테넌트 AI/ML 인프라입니다. 이런 환경에서 데이터셋 로딩과 전처리는 신뢰 경계 안쪽이 아니라 바깥쪽 입력으로 취급돼야 합니다. 구체적으로는 데이터셋 처리 작업을 권한이 최소화된 격리 컨테이너에서 실행하고, 네트워크 이그레스를 기본 차단하며, 노드 자격증명과 클라우드 크리덴셜을 워크로드가 직접 만질 수 없도록 분리하는 설계입니다. 이번 침해가 노드 레벨 접근에서 자격증명 탈취로 번졌다는 점은, 실행 격리와 크리덴셜 분리가 왜 옵션이 아니라 기본값이어야 하는지를 다시 보여줍니다. 온프렘과 주권 AI 수요가 높은 이유도 여기에 있습니다. 데이터와 실행이 고객 경계 안에 머무를수록 이런 파이프라인 공격의 폭발 반경을 줄일 수 있습니다.

Paxis 렌즈에서, 이번 사건은 에이전트 네이티브 클라우드가 애초에 겨냥하는 위협 모델과 정확히 겹칩니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 스킬과 도구를 격리된 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시키는 것을 일급 원칙으로 삼습니다. 공격자가 자율 에이전트 스웜으로 수천 개의 액션을 던졌다는 점은, 에이전트의 행동을 실행 전에 정책으로 심사하고 실행 후에 감사 로그로 남기는 구조가 왜 필요한지를 그대로 증명합니다. 단기 샌드박스를 쓰고 버리는 공격 패턴에 맞서려면, 방어 측도 각 실행을 격리하고 그 실행의 권한 범위를 명시적으로 스코프하며 되돌릴 수 있는 감사 흔적을 남겨야 합니다. 격리 실행과 정책·감사는 에이전트 시대의 사치가 아니라 최소 요건입니다.

두 렌즈는 서로를 보완합니다. ai-platform이 데이터셋 처리라는 인프라 층에서 폭발 반경을 좁히고, Paxis가 에이전트 행동이라는 제어 층에서 각 액션을 심사합니다. 이번처럼 진입은 데이터 파이프라인이고 확산은 자율 에이전트인 공격에서는, 두 층의 방어가 함께 있어야 체인을 끊을 수 있습니다.

한계 및 반론

이 글의 결론을 과신하지 않도록 몇 가지를 분명히 해 둡니다. 첫째, 사건의 세부는 여전히 확정 중입니다. 정확한 액션 수, 자격증명 탈취의 범위, 상용 모델 협조 거부 일화 같은 색깔 있는 디테일은 이차 보도에 크게 의존하며, 공식 공지의 확정 사실과 구분해야 합니다.

둘째, 우리의 방어 서술이 곧 완결된 안전을 뜻하지는 않습니다. 격리와 정책·감사는 폭발 반경을 줄이는 설계 원칙이지, 취약점 자체를 없애는 마법이 아닙니다. 데이터셋 로더의 원격 코드 실행이나 설정 파싱의 인젝션 같은 취약점은 코드 수준에서 계속 발견되고 패치되어야 하며, 격리는 그 취약점이 터졌을 때 피해를 가두는 두 번째 방어선입니다.

셋째, 자율 에이전트 공격을 과대평가하는 것도 위험합니다. 이번 침해의 근본 원인은 정교한 AI가 아니라, 신뢰 경계를 넘는 입력이 코드를 실행할 수 있었던 익숙한 취약점 두 개였습니다. 에이전트는 그 취약점을 더 빠르고 넓게 악용하는 자동화였을 뿐입니다. 따라서 대응의 우선순위는 여전히 기본기에 있습니다. 신뢰할 수 없는 입력을 실행 권한과 분리하고, 자격증명을 워크로드에서 떼어 내며, 모든 실행을 관측 가능하게 만드는 일입니다.

허깅페이스의 신속한 봉쇄와 투명한 공개는 좋은 대응 사례로 남을 것입니다. 우리에게 남는 숙제는 단순합니다. 데이터셋을 파일이 아니라 코드로 대하는 것, 그리고 에이전트의 모든 행동을 심사와 감사의 대상으로 두는 것입니다.

출처

• Security incident disclosure, July 2026 (Hugging Face 공식 블로그)
• Hugging Face breached by autonomous AI agent (Help Net Security)
• Hugging Face warns an autonomous AI agent hacked its network (BleepingComputer)
• World’s Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent (The Hacker News)
• 이차 보도(정확한 액션 수·모델 협조 거부 일화 등은 확정 사실이 아닌 보도 인용): Cryptobriefing, Undercode Testing

문제의식: 어드미션은 정적인데 부하는 실시간이다

공유 GPU 위에서 여러 테넌트의 LLM 추론을 서빙하는 문제는 이제 흔한 운영 과제가 됩니다. H200 같은 대용량 가속기 한 장에 트래픽의 버스트성, 시퀀스 길이, SLO가 서로 다른 여러 테넌트가 동시에 올라탑니다. Kubernetes 기반 플랫폼에서는 보통 Kueue 같은 쿼터·큐 기반 스케줄러가 어떤 작업을 풀에 들여보낼지 결정하지만, 일단 들어온 요청들이 엔진의 유한한 용량을 실제로 어떻게 나눠 쓰는지를 좌우하는 배치 크기와 최대 동시 시퀀스 수 같은 서빙 시점 파라미터는 대개 배포 시점에 정적으로 고정됩니다.

이 논문은 여기서 자연스럽게 따라오는 질문을 던집니다. Kueue가 관리하는 멀티테넌트 H200 GPU 풀에서 여러 테넌트가 vLLM 추론 서버를 공유할 때, 실시간 GPU 메모리·지연 텔레메트리를 관측하는 LLM 에이전트가 테넌트별 배치 크기와 최대 동시 시퀀스 수를 온라인으로 재조정하면 정적 Kueue 어드미션 제어 대비 처리량, p99 지연, 비용의 파레토 프론티어를 실측으로 개선할 수 있을까요. 저자들은 이 질문에 답하기 위해 단일 H200에서 돌아가는 완전한 실측 프로토콜을 설계했지만, 목표 Kubernetes 클러스터 컨텍스트에 접근할 수 없어 실행 자체가 무산됐다는 사실을 서두에서부터 분명히 밝힙니다. 그래서 이 논문에는 실제 하드웨어에서 측정한 처리량이나 지연 수치가 단 하나도 등장하지 않습니다. 대신 논문은 세 가지를 내놓습니다. 온라인 배치·동시성 튜닝 문제의 제어루프 정식화, 클러스터 접근이 복구되는 즉시 실행 가능한 재현 가능 프로토콜, 그리고 세 가지 제어 법칙의 구조를 스트레스 테스트하는 결정론적 큐잉 시뮬레이션입니다.

제어루프로 정식화한 튜닝 문제

논문은 온라인 테넌트별 배치·동시성 튜닝을 마르코프 결정 과정과 유사한 구조를 가진 이산 시간 폐루프 제어 문제로 정식화합니다. 상태는 테넌트별 큐 깊이, GPU 메모리 사용률, 최근 지연 백분위수(p50/p95/p99), 현재 동시성 상한으로 구성되고, 액션은 제한된 폭의 테넌트별 동시성 증감분입니다. 보상 함수는 처리량에서 SLO를 넘긴 p99 지연에 대한 페널티와 비용 항을 뺀 형태로, 안전 범위 안에서 처리량-지연-비용을 함께 최적화하도록 설계됩니다. 이 정식화 위에서 저자들은 에이전트가 실제 배포에 통합되는 방식도 함께 제안합니다. 에이전트는 Kueue의 잡 어드미션을 대체하지 않고 그 안쪽에서 사이드카처럼 동작하며, 이미 어드미션된 작업들이 엔진 용량을 나누는 방식만 조정합니다. 핵심은 손대는 레버가 vLLM 엔진 내부의 max_num_seqs가 아니라 클라이언트 측 테넌트별 어드미션 동시성이라는 점입니다. 프로덕션 vLLM은 엔진 파라미터를 재시작 없이 실시간으로 바꿀 수 있는 노브로 노출하지 않기 때문에, 실제로 조정 가능한 지점은 서버에 들어오는 동시 요청 수뿐이라는 실무적 제약을 그대로 반영한 설계입니다.

LLM 에이전트가 GPU 텔레메트리와 테넌트별 큐 깊이를 관측해 제한된 폭의 동시성 조정값을 산출하고, 이를 통해 배치 구성을 재조정하는 제어루프 구조입니다. 개념적 아키텍처 다이어그램이며 하드웨어에서 실측된 결과가 아닙니다.

시뮬레이션이 던진 경고: 순진한 동적 제어는 정적보다 나빴다

실측 프로토콜이 실행되지 못한 자리를 메우기 위해 저자들은 Python 표준 라이브러리만으로 작성한 시드 고정 이산 시간 큐잉 시뮬레이션을 만듭니다. 두 테넌트가 유한한 슬롯 풀을 공유하는 단순화된 모델 위에서, 세 가지 정책을 20개 시드·1800초씩 돌려 평균을 냅니다. 정적 정책은 테넌트별 동시성 상한을 4로 고정하고, 순진한 동적 정책은 GPU 메모리 사용률과 6초 윈도우 p99 지연을 3초마다 관측해 두 테넌트를 한꺼번에 ±1씩 조절하며, 차별화 에이전트 정책은 테넌트별 백로그 비율을 각자 독립적으로 반영하는 방식으로 더 정교한 에이전트 추론을 흉내 낸 대리 모델입니다.

결과는 예상을 벗어납니다. 정적 정책이 처리량(0.686 req/s)과 드롭 수(평균 1.9건) 모두에서 가장 우수했고, 순진한 동적 정책은 처리량이 0.515 req/s로 떨어지면서 평균 309.5건이나 요청을 드롭했습니다. 차별화 에이전트 대리 모델은 순진한 동적 정책보다는 나았지만(처리량 0.601 req/s, 드롭 154.7건) 여전히 정적 정책을 따라잡지 못했고, p99 지연 역시 두 동적 변형 모두 정적 정책(11.75초)보다 높게 나타났습니다(각각 12.79초, 13.25초).

정적 정책이 가장 높은 처리량과 가장 적은 드롭을 기록했고, 두 동적 변형 모두 시뮬레이션에서 성능이 낮았습니다. 20개 시드 평균을 낸 결정론적 큐잉 시뮬레이션 결과이며 실제 GPU에서 측정한 값이 아닙니다.

정적 정책의 p99 지연이 가장 낮았고, 두 동적 컨트롤러 모두 이 시뮬레이션 영역에서 꼬리 지연을 줄이지 못했습니다. 20개 시드 평균의 시뮬레이션 결과이며 하드웨어 실측치가 아닙니다.

저자들은 이 결과를 단순 버그가 아니라 모델의 실제 동역학이라고 검증하며 네 단계로 원인을 추적합니다. 첫째, 서비스 시간이 지수분포를 따르기 때문에 원래부터 꼬리가 두껍습니다. 평균 2.5초짜리 지수분포는 큐잉이 전혀 없어도 p99가 11.5초 근처에 형성되는데, 이는 정적 정책이 기록한 11.75초와 거의 차이가 없습니다. 즉 관측되는 꼬리 지연 대부분은 혼잡이 아니라 서비스 시간 자체의 분산에서 나옵니다. 둘째, 스로틀 임계값이 3초 기준의 두 배인 6초로 설정되어 있는데, 이는 이 내재적 p99인 11.5초보다 훨씬 낮습니다. 몇 건 안 되는 완료 요청으로 추정하는 짧은 윈도우 p99는 노이즈가 크고 이 내재적 꼬리 쪽으로 편향되어, 실제로는 가볍게 부하가 걸린 상황에서도 임계값을 자주 넘깁니다. 셋째, 이렇게 발생한 오탐 스로틀이 두 테넌트를 함께 묶어 낮추기 때문에 혼잡하지 않은 테넌트까지 함께 제한받고, 3초짜리 하드 타임아웃 아래서 불필요한 스로틀 하나하나가 곧바로 드롭으로 전환됩니다. 넷째, 확장 규칙으로 회복은 되지만 스로틀-드롭 비용이 확장 이득보다 비대칭적으로 크기 때문에 순 처리량이 떨어집니다.

실패에서 뽑아낸 설계 요구사항

이 진단이 말해주는 바는 동적 튜닝 자체가 쓸모없다는 것이 아닙니다. 노이즈가 크고 꼬리 쪽으로 편향된 신호, 테넌트를 함께 묶는 스로틀링, 하드 타임아웃이 결합하면 순진한 고정 임계값 제어가 정적 제어보다 실제로 더 나빠질 수 있다는 사실입니다. 여기서 저자들은 효과적인 에이전트 컨트롤러가 갖춰야 할 네 가지 설계 요구사항을 도출합니다. 혼잡 신호는 짧은 윈도우의 원시 백분위수 대신 더 긴 텔레메트리 이력과 신뢰도 추정을 바탕으로 견고하게 추정해야 합니다. 결정은 테넌트를 하나로 묶은 전역 신호가 아니라 테넌트별로 차별화되어야 합니다. 스로틀링과 확장 사이의 비대칭적 비용을 명시적으로 고려해야 하고, 고정된 숫자 임계값으로는 표현할 수 없는 버스트 패턴 인식이나 테넌트별 SLA 메타데이터 같은 추가 맥락도 활용해야 합니다. 실제로 차별화 에이전트 대리 모델이 순진한 컨트롤러 대비 손실의 절반가량을 회복한 것은 이 방향이 유효할 가능성을 시사합니다. 다만 결합도와 신호 종류를 동시에 바꿨기 때문에 어느 쪽이 회복에 기여했는지는 이 실험만으로 분리해낼 수 없다고 저자들은 선을 긋습니다.

회사·사회·과학에 남기는 것

ThakiCloud 입장에서 이 연구가 당장 남기는 것은 검증된 비용 절감이 아닙니다. 우리 멀티테넌트 H200 클러스터에 곧바로 적용 가능한 재현 가능 실측 프로토콜, 그리고 순진하게 접근하면 오히려 손해를 볼 수 있다는 구체적 경고입니다. 클러스터 접근이 복구되면 이 프로토콜에 실제 LLM 에이전트 결정 함수만 대체해 넣으면 되도록 하네스 자체는 이미 완성돼 있습니다. 더 넓게 보면 공유 GPU 풀의 자원 낭비를 줄이는 방법론이 다듬어질수록 소규모 조직도 공유 클러스터에서 SLA를 지킬 수 있는 실용적 경로가 열립니다. 이는 추론 인프라의 에너지·비용 효율 전반에 도움이 됩니다. 과학적으로는 LLM 에이전트가 실시간 시스템 텔레메트리를 관측해 서빙 하이퍼파라미터를 온라인으로 재조정하는 제어루프를 명시적으로 정식화하고, 그 실패 모드를 재현 가능한 시뮬레이션으로 정량 진단했다는 점이 기여입니다. 이 논문은 ThakiCloud가 같은 Kueue·GPU 기반 위에서 이어온 연구 계보의 일부이기도 합니다. 저지 모델 샘플링 예산을 스케줄링하는 ABJ-Gate, 어드미션 시점의 TEE 원격 증명을 다루는 Attested Confidential Sovereign Inference, 드문 이산 사고에 대한 이진 원격·조치 결정을 다루는 “Escalate or Act?”와 비교하면 이 논문은 초 단위로 연속 재조정되는 실시간 다목적 제어라는 질적으로 다른 문제를 다룬다는 점에서 이들과 구별됩니다.

한계

이 논문이 스스로 밝히는 한계는 명확합니다. 가장 중요한 것은 어떤 형태로든 실제 하드웨어 검증이 없다는 점으로, 목표 클러스터 컨텍스트에 접근할 수 없어 실측 프로토콜이 실행되지 못했고 논문에 실린 어떤 수치도 GPU에서 측정된 것이 아닙니다. 시뮬레이션은 토큰과 KV 캐시를 단일 스칼라 슬롯 수로 단순화했을 뿐 프리필/디코드나 메모리 압력 동역학을 모델링하지 않으며, 메모리 사용률 신호조차 슬롯 점유율의 대리값일 뿐 실제 디바이스 메모리 측정치가 아닙니다. 테스트한 테넌트 유형도 두 가지 합성 트래픽 패턴에 그쳐 다른 트래픽 혼합에서는 발견된 실패 모드가 일반화되지 않을 수 있습니다. 시뮬레이션 속 에이전트 정책 역시 실제 LLM이 아닌 손으로 작성한 대리 모델이며 결합도와 신호 종류를 동시에 바꿨기 때문에, 4장에서 도출한 설계 요구사항을 실제 LLM 에이전트가 충족한다는 검증된 근거는 아직 없습니다. 20개 시드에 대한 평균과 표준편차만 보고했을 뿐 통계적 유의성 검정은 수행하지 않았다는 점도 저자들은 분명히 밝힙니다. 이런 이유로 이 논문은 검증된 결과가 아니라 정식화와 프로토콜, 그리고 경고성 시뮬레이션으로서 스스로를 자리매김합니다.

논문 상세 페이지는 다음에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-21-agent-dynamic-batch-tuning-vllm

원 뉴스: RT @jun_song: Best Local AI models by VRAM size (7/18) · twitter

ThakiCloud 제품 적용 시사점

이 순위표가 말하는 건 결국 ‘주권’입니다. 주권이란 모델과 데이터, 인프라를 남이 아니라 내 통제 아래 두는 걸 뜻하고, 온프렘은 그걸 남의 데이터센터가 아닌 우리 시설 안에서 돌리는 방식입니다. 타키클라우드가 파는 자리가 정확히 여기입니다. 메티스는 내가 가진 GPU 크기에 맞춰 어떤 모델을 얹을지 골라 주고, 파시스는 그 위에서 에이전트를 굴려 실제 일을 시킵니다. 모델이 우리 랙 안에 사니까, 요금은 토큰마다 새로 찍히지 않습니다. 물론 클라우드가 필요할 땐 씁니다. 다만 ‘얼마짜리 카드를 내가 이미 쥐고 있나’를 먼저 묻자는 겁니다.

이 만화는 업계 뉴스를 바탕으로 자동 생성된 초안입니다.

نظرة عامة

في الآونة الأخيرة، تداول مجتمع المطورين خبرا قصيرا بشكل لافت. وهو أن أنثروبيك أزالت نحو 80 بالمئة من التعليمات النظامية في Claude Code. والجزء المثير للاهتمام لم يكن التقليص بحد ذاته، بل السبب وراءه. فقد قال طارق شيهيبار (@trq212) من أنثروبيك إن سلسلة النماذج الجديدة Fable 5 “تريد تعليمات نظامية أصغر”، وأوضح أن إدراج الكثير من التعليمات والأمثلة قد يعيق النموذج فعليا. والسبب، بحسب قوله، أن النموذج أكثر خيالا من القواعد التي نكتبها له.

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

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

ما الذي تغيّر

يتلخص جوهر الخبر المنشور في نقطتين. الأولى أن حجم التعليمات النظامية في Claude Code انخفض بشكل كبير. والثانية أن السبب ليس “النموذج ضعيف فنملؤه أكثر” بل على العكس “النموذج أصبح قويا فنملؤه أقل”.

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

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

flowchart TB
    subgraph OLD["سابقا: تعليمات نظامية ثقيلة"]
        A1["تحديد كل القواعد والاستثناءات<br/>والصيغ في التعليمات النظامية"] --> A2["توقع أن يتبع النموذج<br/>التعليمات كما هي"]
        A2 --> A3["قد تحد التعليمات<br/>من القدرة الفعلية"]
    end
    subgraph NEW["حاليا: إطار رقيق مع سياق"]
        B1["التعليمات النظامية تحدد<br/>سياقا خفيفا فقط"] --> B2["استثمار الحكم<br/>الذي استوعبه النموذج داخليا"]
        B2 --> B3["تُحقن القواعد كسياق<br/>عند الحاجة فقط"]
    end
    OLD -.الانتقال مع تعاظم قوة النموذج.-> NEW

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

لماذا تريد النماذج الأذكى تعليمات أرق

هذه الظاهرة ليست حديثا يدور بالحدس وحده. فهناك أبحاث تشير إلى أن زيادة سقالات الوكيل (الإطار) لا تُحسّن الأداء بالضرورة، بل قد تسبب تداخلا بينها. على سبيل المثال، تتناول ورقة “More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding” (arXiv 2605.05716) النقطة التي يبدأ عندها إضافة المزيد من مكونات الإطار في خلق تداخل بين هذه المكونات، مما يؤدي إلى تراجع الأداء الإجمالي. وهذه ملاحظة تفيد بأن إضافة المزيد من التعليمات ليست منفعة متزايدة باطراد.

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

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

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

من القواعد إلى السياق

أكثر ما يفيد عمليا في هذا الخبر هو جزء “التوجيه بالسياق بدلا من صيغ المنع الجافة”. فهناك طريقتان لنقل النية نفسها.

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

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

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

دلالات على مستوى منتجات Thaki Cloud

يتقاطع هذا التيار بدقة مع فلسفة تصميم منصة الوكلاء Paxis الخاصة بـ Thaki Cloud. فـ Paxis طبقة تحكم للسحابة الأصيلة للوكلاء (Agent-Native Cloud) تعمل فوق ai-platform، وتتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. ومن أبرز مبادئ التصميم فيها “إطار رقيق، ومهارات ثقيلة”. فحلقة النموذج والصلاحيات والأمان، أي الإطار، تُبقى عند الحد الأدنى، بينما تُكدَّس المعرفة المجالية والأحكام وحالات الفشل بكثافة في المهارات.

لا يضع إطار المهارات في Paxis أكثر من 960 مهارة كلها في التعليمات النظامية الدائمة. بل يختار عند وصول الطلب، عبر بحث BM25، المهارات ذات الصلة فقط ويستدعيها كسياق في تلك اللحظة تحديدا. وهذا بالضبط تجسيد لما يعنيه هذا الخبر بـ”مُعِدّ السياق الخفيف”. إذ يظل الإطار الدائم الذي يُدفع ثمنه في كل حالة رقيقا، بينما تُقدَّم المعرفة الكثيفة فقط عند مهمة محددة. ومنذ لحظة إدراج أي مهارة في الفهرس، يبدأ اسمها ووصفها بتحمل تكلفة رمزية (توكن) في كل جلسة، لذلك نحكم على إدراج كل جملة في الإطار الدائم بمعيار: هل يخطئ الوكيل من دونها؟

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

وهناك دلالة أيضا من منظور البنية التحتية. فحين تصبح التعليمات النظامية أرق، تقل رموز الإدخال (input tokens)، وهذا يؤثر مباشرة على تكلفة الخدمة والتأخير. وفي بيئة تخدم فيها ai-platform النماذج عبر vLLM بتشغيل متعدد المستأجرين، فإن تقليص الإطار الدائم ليس مسألة جودة فحسب بل مسألة اقتصادية أيضا. فانخفاض تكلفة الخدمة يُتيح تشغيل الوكلاء بشكل أكثر تواترا وعلى نطاق أوسع، وهذه القدرة بدورها تصنع جدوى اقتصادية للوكلاء.

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

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

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

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

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

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

المصادر

• تصريح علني منسوب لطارق شيهيبار (@trq212) من أنثروبيك، نقلا عن موقع the-decoder.com
• “Anthropic Slashes Claude Code System Prompt by 80%”, ClaudeAINews
• “More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding”, arXiv 2605.05716

يستعرض هذا المقال ماهية Kimi Code CLI، وما تقدمه فعلياً، ولماذا تستحق المتابعة من منظورنا كمشغّلين لمنصة ذكاء اصطناعي قائمة على K8s. وقد خصصنا مساحة واسعة لشرح لماذا يُعد معيار Agent Client Protocol المفتوح قطعة قد تغير قواعد اللعبة في منظومة الوكلاء.

ما هو Kimi Code CLI

Kimi Code CLI أداة برمجة عاملة بأسلوب الوكيل تعمل من الطرفية، وتنتمي إلى نفس فئة Claude Code وGemini CLI وCodex CLI. المستودع الرسمي هو MoonshotAI/kimi-code، وقد تطور من المشروع السابق MoonshotAI/kimi-cli مع الحفاظ على استمرارية الجلسات والإعدادات القديمة. كلا المستودعين رسميان من Moonshot، وينبغي الحذر من الخلط بينهما وبين مشاريع طرف ثالث تحمل أسماء مشابهة.

وهنا يجب توضيح تصحيح أول. الاسم الرسمي لهذه الأداة ليس “CLI مخصصة لـ Kimi K3” بل Kimi Code CLI. فهي أداة غير مقيدة بنموذج واحد، وتستخدم افتراضياً نموذج Moonshot المتخصص في البرمجة Kimi K2.7 Code، لكن يمكن عبر الإعدادات التحول إلى نماذج أخرى بما فيها K3. أي أن K3 هو أحد النماذج المتعددة التي يمكن ربطها بهذه الأداة، وليست الأداة مصممة حصراً له. أما K3 نفسه فهو نموذج MoE مفتوح بحجم 2.8 تريليون معلمة أطلقته Moonshot في 16 يوليو 2026، ويعتمد على Kimi Delta Attention مع نافذة سياق تصل إلى مليون رمز. وقد غطت هذا الإطلاق وسائل إعلام رئيسية مثل CNBC وBloomberg وForbes.

من المفيد رسم الصورة الكاملة أولاً لتترابط التفاصيل لاحقاً بسهولة أكبر. جوهر الأمر هو الدور المزدوج الذي تلعبه Kimi Code CLI: فمن جهة تتصل بالأدوات والبيانات كعميل MCP، ومن جهة أخرى تتصل بالمحررات كخادم ACP.

flowchart TB
    subgraph EDITOR["محرر المطور (عميل ACP)"]
        ZED["Zed"]
        JB["عائلة JetBrains"]
        VSC["VS Code / Neovim"]
    end
    ACP["Agent Client Protocol<br/>JSON-RPC over stdio"]
    subgraph CLI["Kimi Code CLI (نواة الوكيل)"]
        MAIN["الوكيل الرئيسي<br/>يحافظ على سجل المحادثة"]
        SUB["الوكلاء الفرعيون<br/>coder · explore · plan<br/>لكل منهم سياق معزول"]
    end
    MODEL["طبقة النموذج<br/>Kimi K2.7 Code / K3<br/>أو نقطة نهاية متوافقة مع OpenAI"]
    subgraph MCP["خوادم MCP (الأدوات والبيانات)"]
        T1["Context7"]
        T2["Chrome DevTools"]
        T3["موصلات داخلية"]
    end

    EDITOR --> ACP
    ACP -->|kimi acp| MAIN
    MAIN --> SUB
    MAIN -->|طلب استدلال| MODEL
    SUB -->|طلب استدلال| MODEL
    MAIN -->|استدعاء أداة| MCP

الوكلاء الفرعيون: تقسيم السياق للحفاظ على نظافة الوكيل الرئيسي

توفر Kimi Code CLI ثلاثة أنواع من الوكلاء الفرعيين المدمجين. الوكيل coder هو المسؤول الهندسي العام الذي يقرأ الملفات ويكتبها وينفذ الأوامر لتطبيق التغييرات الفعلية. الوكيل explore مخصص للاستكشاف، إذ يتصفح قاعدة الشيفرة للقراءة فقط. أما الوكيل plan فيقتصر عمله على تقديم خطط التنفيذ وتصاميم البنية دون تنفيذ أي أوامر في الصدفة. هذا التقسيم موثق في الصفحة الرسمية Agents and Sub-Agents.

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

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

MCP: تجربة إعداد دون تعديل JSON يدوياً

تُدار عمليات ربط Model Context Protocol عبر مسارين. الأول هو الأوامر الفرعية لسطر الأوامر، حيث تُدار الخوادم عبر kimi mcp add وkimi mcp list وkimi mcp remove وkimi mcp authorize. على سبيل المثال يمكن ربط خادم بحث في الوثائق عبر نقل HTTP، أو ربط خادم أتمتة متصفح عبر نقل stdio.

# نقل HTTP (يدعم خيار OAuth)
kimi mcp add --transport http context7 https://mcp.context7.com/mcp

# ربط عملية محلية عبر نقل stdio
kimi mcp add --transport stdio chrome-devtools -- npx chrome-devtools-mcp@latest

أما المسار الثاني فهو الأمر التفاعلي بشرطة مائلة /mcp-config الذي يُستخدم داخل واجهة TUI، ويتيح إضافة الخوادم وتعديلها والمصادقة عليها دون تحرير ملف إعدادات JSON مباشرة. ويعرض الأمر /mcp قائمة الخوادم المتصلة حالياً والأدوات المحمّلة. والجزء الذي أبرزه تعريف LinkedIn، وهو أنه لا حاجة لتعديل JSON مباشرة، صحيح فعلاً. لكن هذه الميزة بحد ذاتها ليست غائبة عن Claude Code، وسنعود إلى هذه النقطة لاحقاً. الوثائق ذات الصلة موجودة في إعداد MCP.

Agent Client Protocol: أهم قطعة في هذه الأداة

هذا هو الجزء الأكثر إثارة للاهتمام في هذا المقال. Agent Client Protocol، ويُختصر بـ ACP، هو معيار مفتوح صممه فريق محرر Zed. يعمل برخصة Apache، ويتبادل الرسائل عبر JSON-RPC 2.0 فوق stdio. تُشغّل المحررات الوكيل كعملية فرعية وتتواصل معه عبر المدخلات والمخرجات القياسية، وآلية النقل نفسها مطابقة لبروتوكول خادم اللغة.

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

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

تدعم Kimi Code CLI هذا البروتوكول بشكل أصلي عبر الأمر الفرعي kimi acp دون الحاجة إلى أي تثبيت إضافي. يتصل بها Zed بشكل أصلي، بينما تتصل به JetBrains عبر إضافة، وقد ظهرت بالفعل عدة تكاملات مع محررات أخرى وفق سجل ACP الخاص بـ Zed. بذلك يستطيع المطور تشغيل جلسة Kimi دون مغادرة المحرر الذي اعتاد عليه.

إدخال الصور والفيديو، إلى أي حد فعلياً

ذكر تعريف LinkedIn أنه يمكن تمرير لقطة الشاشة كما هي كمدخل. وهذا يحتاج إلى تصحيح. فالميزة التي تبرزها Moonshot فعلياً ليست لقطة شاشة ثابتة بل إدخال مقطع فيديو مسجّل للشاشة. يذكر وصف المستودع أنه عند إسقاط تسجيل شاشة أو مقطع عرض توضيحي في المحادثة، يستطيع الوكيل مشاهدة وفهم السلوك الذي يصعب شرحه بالكلام مباشرة. وبالطبع تدعم نافذة الإدخال في سطر الأوامر لصق الصور أيضاً، إذ إن النموذج الافتراضي Kimi K2.7 Code هو نموذج متعدد الوسائط أصلي مزوّد بمُرمّز رؤية MoonViT بحجم 400 مليون معلمة، يستقبل النص والصور والفيديو معاً. غير أنه عند ربط نموذج مخصص، يجب تحديد دعم الصور صراحة ضمن modalities الخاصة بذلك النموذج ليعمل بشكل صحيح. وخلاصة القول إن إدخال الصور متاح فعلاً، لكن ما يُروَّج له كفارق حقيقي هو إدخال الفيديو، وتعبير لقطة شاشة غير دقيق تماماً.

التثبيت فعلياً في ثلاث خطوات

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

# 1) تشغيل سكربت التثبيت (يثبّت uv في الوقت نفسه)
curl -LsSf https://code.kimi.com/install.sh | bash

# 2) التشغيل داخل دليل المشروع
kimi

# 3) إعداد المصادقة
/login

بالنسبة لنظام macOS تتوفر brew install kimi-code، وبالنسبة لويندوز يتوفر أيضاً سكربت PowerShell. للتطوير من الشيفرة المصدرية يلزم Node بإصدار 24.15 أو أحدث مع pnpm. ولأن الرخصة MIT، فإن القيود قليلة على قراءة الشيفرة وعمل fork لها وتوزيعها داخل المؤسسة.

انفتاح النماذج ومزودي الخدمة

يبلغ أقصى طول للسياق في عائلة K2.6 نحو 256 ألف رمز، بينما يصل في K3 وفق مواد تسويق Moonshot إلى مليون رمز. لكن الأهم من ذلك هو انفتاح مزودي الخدمة. ففي ملف ~/.kimi-code/config.toml يمكن تسجيل عدة مزودين في آن واحد، من نقاط نهاية متوافقة مع OpenAI، إلى مفاتيح Anthropic API، وصولاً إلى Google GenAI أو Vertex AI. وهذا يعني أن الأداة غير مقيدة بنموذج واحد بعينه. كما تعالج تلقائياً حقل reasoning_content الخاص بنماذج الاستدلال من أطراف ثالثة. الوثائق ذات الصلة في Providers and models.

هل هي ميزات غير موجودة في Claude Code: مقارنة صريحة

أكثر العبارات انتشاراً في التعريف كانت أنها تقدم ميزات غير موجودة في Claude Code. وبعد التحقق تبين أن هذا الإطار في معظمه مبالغ فيه.

فالوكلاء الفرعيون وعزل السياق يقدمهما Claude Code أيضاً بالطريقة نفسها عبر ميزة الوكلاء الفرعيين. وMCP مدعوم أصلاً بنضج في Claude Code عبر نقل stdio وSSE وHTTP. كما أن لصق الصور موجود فيه أيضاً. هذه العناصر الثلاثة إذن ليست فوارق حقيقية.

الفارق الحقيقي يكمن في نقطتين. الأولى هي طريقة دعم ACP. فـ Kimi Code CLI تدمج ACP كميزة أساسية من الدرجة الأولى داخل الأداة نفسها عبر الأمر الفرعي kimi acp. أما Claude Code فيتصل بها عبر حزمة محول منفصلة صنعها Zed، وما تزال في مرحلة تجريبية. من منظور المستخدم، الأولى تعمل فور تفعيل الأداة، بينما الثانية تتطلب إضافة جسر إضافي. النقطة الثانية هي انفتاح النماذج. فـ Kimi مفتوح على سلسلة K مفتوحة الأوزان مع إمكانية التحول بين عدة مزودين، بينما يقتصر Claude Code على نماذج Anthropic حصرياً. ومن هذه النقطة يتفرع فارق ثالث يتعلق بإمكانية الاستضافة الذاتية. فبما أن Kimi أداة مفتوحة المصدر مع نموذج مفتوح الأوزان، يمكن تشغيله داخل المؤسسة، بينما تظل Claude Code أداة مفتوحة لكن نموذجها متاح عبر واجهة API فقط. يمكن الاطلاع على الدليل ذي الصلة في مقال Zed حول Claude Code عبر ACP التجريبي.

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

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

من عدسة Paxis، تتداخل بنية Kimi Code CLI إلى حد كبير مع اتجاه تصميم منتجنا. فPaxis هو مستوى التحكم الخاص بـ ThakiCloud لسحابة أصيلة الوكلاء (Agent-Native Cloud)، ويتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. والطريقة التي يعمل بها الوكلاء الفرعيون coder وexplore وplan لدى Kimi بالتوازي وفي سياقات معزولة، تشترك في الفلسفة نفسها مع طريقة عمل حاضنة المهارات في Paxis، التي تختار من بين أكثر من 960 مهارة باستخدام BM25 وتنفذها في صناديق اختبار معزولة. وACP بشكل خاص، بوصفه معياراً محايداً تجاه المزودين، يمثل فرصة مباشرة لـ Paxis. فأي وكيل ننشره، بما في ذلك الوكلاء المزودة بنماذج خضعت لضبط دقيق خاص بنا، يمكنه إذا نفذ ACP أن يتصل بمحررات المطورين لدى العملاء مثل Zed أو JetBrains بطريقة موحدة. وهذا المزيج من معيارين، MCP للاتصال بالبيانات وACP للاتصال بالمحررات، يمثل بالضبط الصورة التكاملية التي نتجه إليها.

ومن عدسة ai-platform، الانفتاح يعني حرية النشر مباشرة. فبوضع سلسلة K مفتوحة الأوزان فوق جدولة GPU عبر Kueue وخدمة vLLM في عنقودنا، وتوجيه الأداة نحو نقطة نهاية داخلية، يمكن بناء وكيل برمجة داخلي دون الاعتماد على API خارجي أو إخراج البيانات إلى الخارج. وهذا ينسجم مع متطلبات الأمن الخاصة بالاستضافة داخل المؤسسة في قطاعي المال والقطاع العام حيث لا يجوز خروج الشيفرة إلى الخارج، وكذلك مع متطلبات جهات مثل NIS. وقد سبق أن تناولنا في مقالات سابقة فكرة أنه كلما أصبحت القدرات شائعة ورخيصة، فإن ما تدفعه الشركات فعلياً هو بيئة تنفيذ محكومة. وأهمية Kimi Code CLI تكمن في أنها فتحت طبقة التنفيذ هذه كمصدر مفتوح.

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

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

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

المصادر

• MoonshotAI/kimi-code (المستودع الرسمي)
• MoonshotAI/kimi-cli (المستودع السابق)
• دليل بدء Kimi Code CLI
• وثائق Agents and Sub-Agents
• وثائق إعداد MCP
• Zed - Agent Client Protocol
• ACP: The LSP for AI Coding Agents
• Zed - Claude Code via ACP (تجريبي)
• MarkTechPost - إطلاق Kimi K3