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

أصبحت مشكلة خدمة الاستدلال (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

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

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

공유 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

نظرة عامة

في الآونة الأخيرة، تداول مجتمع المطورين خبرا قصيرا بشكل لافت. وهو أن أنثروبيك أزالت نحو 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

نظرة عامة

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

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

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

ما قاله ماسك فعلًا

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

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

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

لماذا نأخذ التوقّع على محمل الجد

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

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

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

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

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

من العمل إلى الأصول: الجزء المتين والجزء الهشّ

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

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

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

أين يعمل هذا الذكاء

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

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

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

من منظور ThakiCloud

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

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

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

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

ما ينبغي مراقبته بحذر

مع الاتّفاق على الاتجاه العام، تبقى بضع نقاط ينبغي التمسّك بها حتى لا ننجرف.

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

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

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

خاتمة

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

المصادر

• الفيديو المصدر: مقطع لإيلون ماسك في حوار مع الرئيس التنفيذي لشركة BlackRock، لاري فينك، في المنتدى الاقتصادي العالمي في دافوس. اقتباسات هذا المقال فُرّغت مباشرة من ذلك الفيديو.
• تحقّق متقاطع من التصريحات: توقّعات ماسك الخمسية (تجاوز الذكاء الرقمي مجموع الذكاء البشري، ومئة مليون إلى مليار روبوت بشري، ومضاعفة الاقتصاد خلال خمس إلى سبع سنوات) نقلتها عدة وسائل إعلام بوصفها تصريحات دافوس. تغطية ذات صلة: Elon Musk predicts robot-majority future in first Davos appearance, Euronews
• عبارة “ثلاث سنوات” المنتشرة هي تأطير صاحب المنشور الذي اقتبس المقطع، لا تصريح ماسك نفسه.
• ملاحظة روي أمارا (المبالغة قصيرة المدى والتقليل بعيد المدى) قاعدة إرشادية شائعة الاستشهاد في توقّعات التقنية. مرجع: Roy Amara, Wikipedia

نظرة عامة

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

مستودع everything-claude-code هو مجموعة إعدادات مفتوحة المصدر تعالج هذا الهيكل تحديدًا. نشر أحد الفائزين بهاكاثون Anthropic كامل إعداداته بمستوى إنتاجي بعد أن صقلها أكثر من ستة أشهر على مشروع خدمة TypeScript مصغّرة حقيقي، وجمع المستودع نجومًا بسرعة بعد الإصدار (نحو 9,700 بحسب التغريدة المصدر، [تقديري]). يستعرض هذا المقال ما يحتويه المستودع، والمبادئ التصميمية التي يقوم عليها، وكيف تتصل تلك المبادئ بمنصة الوكلاء التي تبنيها ThakiCloud. وقد تبنّت ThakiCloud مجموعة قواعد هذا المستودع كمعيار داخلي فعلي، لذا فهذا رأي قائم على التجربة لا مجرد تعريف.

ما هو everything-claude-code

يعرّف everything-claude-code (اختصارًا ECC) نفسه بأنه “نظام تحسين أداء هيكل الوكيل”. وهو يجمّع ستة أنواع من أصول الإعداد: وكلاء فرعيون يعالجون المهام المفوّضة (agents)، وحزم معرفة متخصصة تُستدعى عند الطلب (skills)، وخطّافات تتدخّل تلقائيًا قبل تنفيذ الأدوات وبعده (hooks)، وأوامر مائلة تغلّف الأعمال المتكررة (commands)، وقواعد تُطبَّق دائمًا (rules)، وإعدادات خوادم MCP التي تربط الأدوات الخارجية (MCPs).

والأهم أن هذا ليس إعداد مشروع هواية. فقد فاز المؤلف بهاكاثون Anthropic x Forum Ventures في سبتمبر 2025 ببناء منتج باستخدام Claude Code وحده، ثم صقل هذا الإعداد أكثر من عشرة أشهر وهو يشحن منتجات حقيقية يوميًا. ومؤشرات الجودة التي يذكرها المستودع محدّدة: 1,282 اختبارًا، وتغطية 98٪، و102 قاعدة تحليل ساكن. إن كون مجموعة إعدادات تحمل هذا المستوى من الانضباط هو بذاته دليل على أن المؤلف يفصل بين “قواعد تُسلَّم للذكاء الاصطناعي” و”كود يتحقق من الالتزام بتلك القواعد”.

سمة أخرى هي حياد الهيكل. صُمِّم ECC ليعمل ليس فقط في Claude Code بل أيضًا في وكلاء برمجة آخرين مثل Codex وOpencode وCursor. وفكرة إعادة استخدام القواعد والمهارات نفسها عبر أدوات متعددة هي نتيجة طبيعية لفلسفة التصميم التي نناقشها أدناه.

البنية: هيكل رفيع، مهارات ثقيلة

قلب ECC مبدأ واحد: ابنِ القدرة في المهارات لا في الهيكل. فالهيكل نفسه، أي الهيكل التنفيذي لحلقة النموذج والوصول إلى الملفات والصلاحيات والأمان، يبقى في حدّه الأدنى، بينما تُكدَّس المعرفة المجالية ومعايير الحكم والقوالب وحالات الفشل بكثافة في المهارات والقواعد. هذا ما يتيح للمهارة نفسها أن تعمل عبر أكثر من هيكل، سواء Claude Code أو Cursor.

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

الثاني هو أن القواعد نفسها تُكدَّس في طبقات. يحتوي مجلد common/ على المبادئ العامة المستقلّة عن اللغة (أسلوب البرمجة، سير عمل git، الاختبار، الأمان، وغيرها)، وفوقه تمدّد المجلدات الخاصة باللغة مثل typescript/ وpython/ وgolang/ وweb/ القواعدَ العامة أو تتجاوزها. تعمل الأولوية مثل خصوصية CSS أو قواعد .gitignore: القاعدة الأكثر تحديدًا تتغلب على الأكثر عمومية. مثلًا توصي القواعد العامة بعدم القابلية للتغيير كمبدأ افتراضي، لكن قواعد Go الخاصة باللغة تنصّ على أن تعديل البنية عبر مستقبِلات المؤشرات أمر اصطلاحي، فتتجاوز تلك النقطة وحدها.

تبدو البنية الكاملة على النحو التالي.

flowchart TB
    A[طلب المطوّر] --> B[هيكل رفيع<br/>حلقة النموذج، الصلاحيات، الأمان]
    B --> C{يُحمَّل كل دور}
    C --> D[Rules<br/>معايير دائمة وقوائم تحقّق]
    C --> E[مُشغِّل الطلب]
    E --> F[Skills<br/>خبرة عند الطلب]
    D --> G[قواعد common العامة]
    G --> H[قواعد اللغة<br/>الخاص يتجاوز العام]
    B --> I[Agents<br/>مختصّون مفوَّضون]
    B --> J[Hooks<br/>تحقّق آلي قبل/بعد التنفيذ]
    B --> K[خوادم MCP<br/>ربط الأدوات الخارجية]
    F --> L[مخرجات متسقة]
    H --> L
    I --> L

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

كيف تتبنّاه فعليًا

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

# أنشئ مساحة أسماء قواعد ECC مرة واحدة.
mkdir -p ~/.claude/rules/ecc

# انسخ القواعد العامة (مطلوبة لكل المشاريع).
cp -r rules/common ~/.claude/rules/ecc/

# انسخ القواعد الخاصة باللغة المطابقة لحزمة مشروعك.
cp -r rules/typescript ~/.claude/rules/ecc/
cp -r rules/golang ~/.claude/rules/ecc/
cp -r rules/web ~/.claude/rules/ecc/

هنا يحذّر المستودع صراحةً من خطأ شائع. لا تنسخ بالتسطيح عبر نمط بدل مثل rules/common/*. فالمجلدات العامة والخاصة باللغة تحتوي على ملفات بالأسماء نفسها (coding-style.md وtesting.md وغيرهما)، فالتسطيح يجعل ملف اللغة يكتب فوق الملف العام ويكسر المرجع النسبي (../common/). وللحفاظ على التسلسل الهرمي، يجب نسخ المجلدات كاملة.

تحتاج إعدادات خادم MCP إلى معالجة منفصلة. اسحب فقط إعدادات الخوادم التي تحتاجها من mcp-configs، لكن النقطة الأساسية هي عدم تفعيلها كلها دفعة واحدة. يحذّر المستودع بقوة هنا، لأن كثرة الأدوات المرتبطة قد تقلّص نافذة سياق سعتها 200k إلى 70k فعليًا. فكل خادم MCP مفعَّل يدفع كلفة مخطّط كل دور، لذا تحتاج إلى انضباط تفعيل الخوادم التي تستخدمها فعلًا فقط.

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

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

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

عدسة Paxis (منصة الوكلاء). إن Paxis من ThakiCloud هو مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع Skills وTools وPolicies وAudit Logs بوصفها موارد من الدرجة الأولى. وفلسفة ECC “هيكل رفيع، مهارات ثقيلة” هي بالضبط النموذج الذي يحوّله Paxis إلى منتج. فـ Skill Harness في Paxis يختار من أكثر من 960 مهارة عبر BM25، وينفّذها في صناديق رمل معزولة، ويمرّر كل فعل عبر بوابات السياسات وسجلات التدقيق. بعبارة أخرى، طبقات القواعد والمهارات والخطّافات التي يديرها ECC يدويًا في مجلد ~/.claude لمطوّر فرد، يرفعها Paxis إلى مستوى سحابة متعددة المستأجرين من الاختيار التلقائي والتنفيذ المعزول وفرض السياسات والتدقيق. ويمكن اعتبار Paxis الصورة التشغيلية بحجم المنصّة للمبادئ التي تحقّق منها ECC في سير عمل فردي. ورؤية ECC بأن “القواعد تُحمَّل كل دور وتدفع إيجارًا” تنتقل مباشرة إلى تصميم Paxis القائم على تحميل المهارات عند الطلب فقط وترشيح الضجيج عبر BM25.

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

باختصار، ECC هو خلاصة نظافة الهيكل المصنوعة يدويًا من قِبل فرد، وThakiCloud تبني منتجات تحافظ فيها المنصّة على تلك النظافة تلقائيًا. الخدمة منخفضة الكلفة (ai-platform) تصنع اقتصاديات الوكلاء، وفوقها يصنع تنفيذ المهارات بسياسة وتدقيق (Paxis) الثقة.

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

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

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

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

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

المصادر

• everything-claude-code (affaan-m/everything-claude-code)، GitHub
• ملف المؤلف المتعلق بـ zenith.chat، الفائز بهاكاثون Anthropic x Forum Ventures
• التغريدة الأصلية: ‎@Ryrenz (RT @hjguyhan)، 2026-07-20

نظرة عامة

يمكن تلخيص أخبار الفترة من أواخر يونيو حتى يوليو 2026 في سطر واحد: الاستخدام العشوائي للنماذج المتطورة (frontier models) في كل مهمة يجعل التكلفة يصعب تحملها، بل ويصعب حتى تتبع مصدرها. وقد ظهرت الحادثة بشكل درامي. فقد جرت محاولة تحصيل مبلغ يقارب 2.5 مليار وون من مستخدم محلي واحد، ثم محاولة تحصيل نحو 25 مليار وون لاحقا. ولحسن الحظ لم يُسحب أي مبلغ فعليا بسبب تجاوز حد البطاقة، غير أن تكرار وصول مبلغ غير طبيعي إلى مرحلة طلب موافقة البطاقة، وليس مجرد خطأ عرض، هو ما يمنح الحادثة وزنها المختلف.

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

ماذا حدث في الشهر الأخير

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

المشكلة الثانية كانت في قابلية مراقبة تكلفة الوكلاء. وبحسب تقارير AI Times و The Information، أعلنت شركة ناشئة متخصصة في تدقيق التكاليف تُدعى Vaudit أنها راجعت فواتير 60 شركة بقيمة إجمالية نحو 34 مليون دولار، وخلصت إلى أن نحو 1.7 مليون دولار منها كانت فوترة زائدة. وشكّل استخدام Claude Code جزءا كبيرا من نطاق المراجعة، وذُكرت شركات مثل باناسونيك وHP وهوندا ضمن العملاء. وحسب ادعاء الشركة، فإن الأنماط شملت تسجيل استخدام نموذج رخيص بأسعار نموذج أغلى، وفرض رسوم على مهام لم تُنجز، وتكرار إعادة المحاولة التلقائية بعد الخطأ فيما يُعرف بـعاصفة إعادة المحاولة (retry storm). وهنا ينبغي توضيح نقطتين. أولا، ردت أنثروبيك بأنها لا تفرض رسوما على الطلبات غير المكتملة أو الاستجابات الخاطئة، وأنه لا يوجد دليل واسع على فوترة زائدة. ثانيا، تحصل Vaudit على نسبة من مبالغ الاسترداد الناجحة، أي أنها شركة تدقيق تجارية، لذا يجب قراءة هذه الأرقام كنتيجة تحقيق من طرف واحد لا كتدقيق حسابي مستقل. وبعبارة أخرى، نحن الآن في مرحلة تصادم بين ادعاءات شركة التدقيق ونفي المزود.

المشكلة الثالثة كانت في استجابة السوق. وذكرت The Information أن الشركات بدأت بفصل المهام: النماذج الرخيصة للتصنيف والتلخيص والتحويل البسيط، والنماذج المتطورة للبرمجة المعقدة ومهام الوكلاء، والنماذج مفتوحة الأوزان أو المستضافة ذاتيا للمهام المتكررة عالية الحجم. ونقلت الفايننشال تايمز أن شركات مثل DoorDash وSiemens وAirbnb اعتمدت نماذج DeepSeek أو من عائلة Moonshot لخفض التكلفة. وفي تقرير لـ Business Insider، اعترف حتى مسؤولو المنصة في أنثروبيك بأن ما يُعرف بـالتقنية المعلوماتية الظل (shadow IT)، أي اعتماد كل قسم لأدواته الخاصة بشكل منفصل، أدى إلى تضخم تكاليف الذكاء الاصطناعي في بعض الشركات، لكنهم شددوا على أن الحل ليس إيقاف الاستخدام أو فرض سقف ميزانية موحد، بل اختيار النموذج بحسب المهمة وإدارة مركزية للتكلفة على مستوى المؤسسة. كما تغيرت سياسات التسعير نفسها مرارا: تعدّلت مرات عدة شمولية النماذج عالية الأداء الأحدث ضمن الاشتراك وتوقيت التحول إلى الدفع بحسب الاستخدام، وتكرر تمديد مواعيد انتهاء العروض الترويجية. بل ورد أن إتاحة Claude Fable 5 مجانا امتدت حتى 19 يوليو. وكانت صعوبة توقع تكلفة الشهر القادم أكبر إزعاج لمسؤولي المشتريات، أكثر حتى من مسألة الأداء.

لماذا لا يمكن مراقبة تكلفة الوكلاء

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

flowchart TB
    U["طلب مستخدم واحد"] --> P["وضع خطة الوكيل"]
    P --> L["حلقة التنفيذ"]
    L --> T["استدعاء أدوات · استدعاء نموذج<br/>عشرات إلى مئات المرات"]
    T --> R{"هل نجحت؟"}
    R -->|"فشل"| RS["إعادة محاولة تلقائية<br/>(retry storm)"]
    RS --> T
    R -->|"نجاح"| ACC["توكن · كاش · tool call<br/>تجميع تراكمي"]
    ACC --> INV["الفاتورة: مبلغ نهائي في سطر واحد"]
    INV -.فجوة المراقبة.-> U

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

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

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

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

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

الحدود والرأي المعاكس

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

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

المصادر

• ZDNet Korea، “مستخدم محلي تلقى طلب دفع بقيمة 25 مليار وون… جدل حول خطأ فوترة أنثروبيك” (2026-07-09)
• ZDNet Korea، “أنثروبيك التي طالبت بـ25 مليار وون: تبين أنه خطأ في إعداد الشحن التلقائي” (2026-07-16)
• AI Times، “أنثروبيك في جدل ‘الفوترة الزائدة للذكاء الاصطناعي’: تحصيل رسوم حتى على المهام الفاشلة” (2026-06)
• The Information، تقرير عن سيطرة الشركات على تكلفة الذكاء الاصطناعي وتوزيع النماذج (2026-06-23)
• Financial Times، “Companies turn to Chinese AI models to cut costs” (2026-07)
• Business Insider، “Anthropic Official Warns Against ‘Wrong’ AI Cost Response” (2026-07-15)
• The Wall Street Journal، “Meet the Companies Shelling Out for Top AI Models” (2026-07)

نظرة عامة

كل من شغّل نموذج LLM محلياً يصطدم بالجدار نفسه: إذا كانت أوزان النموذج أكبر من ذاكرة الـ GPU، يفيض الزائد إلى ذاكرة الـ CPU. وراية -ngl في llama.cpp (عدد الطبقات التي توضع على الـ GPU) تفعل هذا بالضبط. المشكلة أنها تقطع فقط على مستوى الطبقة. تخلط الطبقة الواحدة موتّرات مختلفة الطبيعة تماماً (أوزان attention، وأوزان FFN، ومعاملات التطبيع)، ومع ذلك تُعامَل بمبدأ الكل أو لا شيء: إما أن يذهب الكل إلى الـ GPU أو يبقى على الـ CPU.

سبب خسارة هذا الوضع الكتلي بسيط. قد يجعل نفس الـ 1GB في الـ VRAM موتّراً أسرع 10 أضعاف وآخر أسرع ضعفين فقط. الـ VRAM مورد نادر، والقطع الكتلي يمنعك من انتقاء الموتّرات ذات الربح الأعلى لكل GB. يستهدف ATSInfer هذا بالضبط. فهو يحلّل أداء كل موتّر على الـ CPU والـ GPU ويملأ الـ VRAM بدءاً من الموتّرات ذات أعلى ربح سرعة لكل GB. إذا كان ktransformers الأخير حيلةً على “مستوى الخبير” تدفع خبراء MoE إلى الـ CPU (انظر مقالتنا ذات الصلة: إعادة إنتاج الـ 28 ضعفاً لـ ktransformers)، فإن ATSInfer هو التعميم الأدق على “مستوى الموتّر”. واللافت أنه ينطبق على النماذج الكثيفة (dense) وليس MoE فقط.

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

ATSInfer نظام استدلال هجين CPU-GPU مبنيّ كامتداد لـ llama.cpp بنحو 15 ألف سطر من C++. كما يقول الاسم، فإن “الجدولة الآلية للموتّرات (Automated Tensor Scheduling)” هي الجوهر، وتتشابك ثلاث آليات.

flowchart TB
    A["أوزان النموذج<br/>(RAM، تتجاوز سعة VRAM)"] --> B["تحليل لكل موتّر<br/>قياس ربح السرعة لكل GB"]
    B --> C{"التوزيع الثابت<br/>الموتّرات الأعلى ربحاً إلى VRAM أولاً"}
    C -->|"موتّرات عالية الربح"| D["مقيمة في VRAM"]
    C -->|"موتّرات منخفضة الربح"| E["مقيمة في RAM"]
    D --> F["نقل ديناميكي واعٍ بالحمل<br/>ترقية/تنزيل حسب حمل التشغيل"]
    E --> F
    F --> G["تنسيق غير متزامن بين CPU وGPU<br/>تداخل الحساب ونقل PCIe"]
    G --> H["إخراج الرموز<br/>prefill · decode"]

أولاً، التوزيع الثابت للموتّرات (static placement). قبل تحميل النموذج، يقيس مدى تسارع كل موتّر على الـ GPU، ثم يضع الموتّرات على الـ GPU بترتيب “أكبر سرعة مُعادة لكل GB من الـ VRAM مستخدَم”. هذا قريب من مسألة حقيبة الظهر (knapsack) ويستغل مباشرةً التباين على مستوى الموتّر الذي تجاهله التوزيع الكتلي.

ثانياً، النقل الديناميكي الواعي بالحمل (load-aware dynamic transfer). التوزيع الثابت وحده لا يكفي. خلال الاستدلال الفعلي، يتغير الحمل لحظةً بلحظة مع حجم الدفعة وطول السياق وعدد الطلبات المتزامنة. يرقّي ATSInfer موتّراً معيناً من الـ RAM إلى الـ GPU أو ينزّله بناءً على حالة التشغيل. إذا كان التوزيع الثابت هو خط الانطلاق، فالنقل الديناميكي هو تغيير المسار أثناء القيادة.

ثالثاً، التنسيق غير المتزامن بين CPU وGPU (asynchronous coordination). يُداخِل بين حساب الـ CPU وحساب الـ GPU ونقل الـ PCIe الذي يصل بينهما. التنفيذ الساذج يترك الـ GPU خاملاً ينتظر عمل الـ CPU أو حركة البيانات؛ وطبقة التنسيق هذه تملأ ذلك الوقت الخامل. تُبلّغ الورقة أن هذا يرفع متوسط استغلال SM (المعالج المتعدد التدفق) في الـ GPU بنحو 70%.

النتائج التي تبلّغ عنها الورقة

مرة أخرى: الأرقام أدناه قيم أبلغت عنها الورقة، لا شيء أعدنا إنتاجه. شيفرة ATSInfer لم تُنشر بعد (حتى نقاش التغريدات قال “أيها الباحثون، رجاءً شاركوا الشيفرة مع فريق llama.cpp”)، وإعادة إنتاج نموذج بحجم 120B مع RTX 4090 صعبة في البيئة المعزولة وراء هذه المقالة. لذا بدلاً من إعادة الإنتاج، نركّز على التحليل البنيوي والدلالات.

عنوان الورقة العريض: مقابل الأنظمة الهجينة الحالية (بما فيها إنزال llama.cpp على مستوى الطبقة)، يتحسّن الـ prefill (الإنتاجية حتى أول رمز) حتى 1.94 ضعفاً، والـ decode (الرموز المولّدة في الثانية) حتى 3.29 ضعفاً.

الإعداد هو نظام RTX 4090 (24GB) وRTX 3060 مع 64GB من الـ RAM، والنماذج المُتحقَّق منها هي:

• Llama 3.1-70B (INT4)
• Qwen3-Next-80B-A3B (INT4)
• Qwen3.5-122B-A10B (INT4)
• GPT-OSS-120B (MXFP4)

فالادّعاء المركزي هو تشغيل نموذج بـ 122 مليار معامل (وهو MoE بعدد معاملات نشطة أقل بكثير) على بطاقة 24GB واحدة. اقرأ هنا أمرين منفصلين. أولاً، “3.29 ضعفاً” هو حدّ أقصى تحت ظروف محددة، لا متوسط عبر كل نموذج وكل دفعة. ثانياً، الربح يأتي جوهرياً لا من “إدخال ما لم يكن يدخل في الـ GPU” بل من “جعل حركة CPU-GPU الحتمية أذكى”. تبقى الفيزياء نفسها في أن عرض نطاق الـ PCIe هو عنق الزجاجة، لذا فإن مساهمة ATSInfer هي استخدام ذلك العرض دون هدر وتقليل الوقت الخامل للـ GPU.

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

منصة ai-platform من ThakiCloud بنية تحتية للذكاء الاصطناعي/تعلّم الآلة تخدم النماذج عبر بيئات عملاء متنوعة على Kubernetes وKueue. الجدولة على مستوى الموتّر مثل ATSInfer تتوافق مع اتجاه نراقبه عن كثب.

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

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

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

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

أكبر حدّ هو عدم نشر الشيفرة. لا يمكن التحقق مما إذا كانت أرقام الورقة قابلة لإعادة الإنتاج، وما إذا كانت تصمد على أجهزة ونماذج أخرى، إلا بعد ظهور الشيفرة. امتداد بـ 15 ألف سطر من C++ هو أيضاً مهمة صيانة ودمج مع المنبع (upstream) غير هيّنة. الفرع (fork) الذي لا يُدمج أبداً يتخلّف عن تغييرات المنبع مع الوقت ويفقد قيمته.

ثانياً، اعتماد المكاسب على الظروف. يعتمد أثر التوزيع على مستوى الموتّر بشدة على أداء الـ CPU، وعرض نطاق الـ RAM، وجيل الـ PCIe. تفترض تجارب الورقة 64GB من الـ RAM؛ فإن نقص الـ RAM لا يترك مجالاً لإبقاء الموتّرات على الـ CPU أصلاً. على أنظمة PCIe 3.0، يرجّح أن يصبح النقل عنق الزجاجة ويقلّص الربح جوهرياً ([تقدير]، لا تفصّل الورقة مقارنةً جيلاً بجيل).

ثالثاً، السقف المتأصّل لتحسين الـ decode. الـ decode مهمة مقيّدة بالذاكرة (memory-bound). مهما أحسنت الجدولة، يجب الوصول إلى الأوزان خارج الـ VRAM بطريقة ما مع كل رمز، فيكون حتماً أبطأ من الإقامة الكاملة في الـ VRAM. ما يفعله ATSInfer هو “تقليل مقدار التباطؤ”، لا “إزالة التباطؤ”. وبناءً على الحجة المعاكسة: لخدمة إنتاجية تحتاج حقاً كموناً منخفضاً وإنتاجية عالية، يبقى استخدام بطاقة GPU تحمل النموذج كاملاً في الـ VRAM هو القرار الصائب. يتألق ATSInfer في مجال التطوير والتقييم والدفعات الصغيرة حيث لا تقدر على تلك البطاقة أو لا تحتاجها.

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

المصادر

• ورقة ATSInfer: arXiv:2607.10183, Automated Tensor Scheduling for Hybrid CPU-GPU LLM Inference on Consumer Devices
• مقالة ذات صلة: رفّ بـ 400 ألف دولار على 24GB؟ أعدنا إنتاج الـ 28 ضعفاً لـ ktransformers

يستعرض هذا المقال أولاً الحقائق المؤكدة حول ماهية Kimi K3، ثم ينتقل إلى كيفية قراءة لوحة نتائجه المبهرة، وأخيراً إلى ما يحتاج المشغّلون للتحقق منه قبل وضع هذا النموذج في منتج فعلي. بالنسبة لشركة بنية تحتية مثل ThakiCloud، التي تخدم وتشغّل النماذج عبر بيئات عملاء متعددة، هذا السؤال ليس فضولاً أكاديمياً بل هو قرار الاعتماد نفسه. إذا وثقنا بسطر نتيجة واحد ونشرنا نموذجاً بـ 2.8 تريليون معامل داخلياً (on-premises)، لنكتشف لاحقاً أنه لا يفي بالتوقعات في العمل الفعلي، فإن التكلفة تقع بالكامل علينا وعلى عملائنا.

ما هو Kimi K3

Kimi K3 هو نموذج مزيج خبراء (Mixture-of-Experts، أو MoE) واسع النطاق أطلقته Moonshot AI في 16 يوليو 2026. يبلغ إجمالي عدد المعاملات 2.8 تريليون، ما يجعله أول نموذج مفتوح الأوزان يدخل فئة الـ 3 تريليون معامل. غير أن هذه الـ 2.8 تريليون هي الحجم الإجمالي، وفي الاستدلال الفعلي يستخدم النموذج بنية متناثرة (sparse) تُفعّل فقط 16 خبيراً من أصل 896 خبيراً، لذا لا تعمل جميع المعاملات في كل رمز (token). إغفال هذه النقطة يقود بسهولة إلى سوء فهم مفاده أن “كامل الـ 2.8 تريليون يعمل دفعة واحدة”.

تتضمن البنية المعمارية عدة عناصر جديدة. تسمي Moonshot هذا إطار عمل Stable LatentMoE، وتوضح أنه يدعم سياق يصل إلى مليون رمز من خلال Kimi Delta Attention (KDA) و Attention Residuals (AttnRes). أُضيفت إلى ذلك مكونات مثل Quantile Balancing لتوزيع الخبراء، وتحسين Per-Head Muon، وتفعيل SiTU، و Gated MLA. تدّعي الشركة أن هذه التحسينات أدت إلى تحسن في كفاءة التوسّع بنحو 2.5 ضعف مقارنة بالإصدار السابق K2. بما أن هذا الرقم هو ادعاء من الجهة المعلنة، فمن الأسلم قراءته كقيمة مرجعية إلى أن يظهر تكرار مستقل من طرف ثالث.

من منظور التقديم (serving)، أهم جانب عملي هو التكميم (quantization). يتعامل K3 مع الأوزان بصيغة MXFP4 ومع القيم التنشيطية بصيغة MXFP8، وطبّق تدريباً واعياً بالتكميم (QAT) بدءاً من مرحلة الضبط الدقيق الموجّه (SFT). ونتيجة لذلك، انخفضت سعة تخزين أوزان النموذج بأكمله (2.8 تريليون) إلى نحو 1.4 تيرابايت، أي ما يقارب ربع الـ 5.6 تيرابايت التي كانت ستتطلبها أوزان FP16. ومع ذلك، يظل 1.4 تيرابايت رقماً كبيراً. من المقرر إصدار الأوزان الكاملة في 27 يوليو بموجب ترخيص MIT معدّل.

فيما يلي مخطط مبسّط لمسار الاستدلال في K3.

flowchart TB
    A[رموز الإدخال<br/>حتى سياق مليون رمز] --> B[Kimi Delta Attention<br/>+ Attention Residuals]
    B --> C{موجّه Stable LatentMoE}
    C -->|اختيار 16 من أصل 896| D[الخبراء النشطون<br/>أوزان MXFP4]
    C -.الخبراء غير النشطين.-> E[قرص/تفريغ<br/>~1.4 تيرابايت إجمالاً]
    D --> F[قيم تنشيطية MXFP8<br/>مع تطبيق QAT]
    F --> G[رموز الإخراج]

ما تقوله المعايير القياسية

بالنظر إلى النتائج وحدها، فإن Kimi K3 مبهر بالتأكيد. عند الإطلاق، سجّل K3 نسبة 93.5% في GPQA Diamond، وهي أعلى نتيجة بين النماذج مفتوحة الأوزان المتاحة علناً في ذلك الوقت. حصل على 88.3% في Terminal-Bench 2.1، وتصدّر SWE Marathon و Program Bench، اللذين يقيسان جلسات البرمجة المستمرة، بالإضافة إلى BrowseComp و OmniDocBench. هذا يشير إلى أنه قوي بشكل خاص في مهام الوكلاء طويلة الأمد وفي البرمجة.

لكنه ليس في المركز الأول في كل المؤشرات. تخلّف K3 عن Fable 5 من Anthropic في FrontierSWE و HLE-Full، ويُقيَّم في المركز الثالث تقريباً، خلف Fable 5 و GPT-5.6 Sol، في التقييمات المركّبة الصعبة للوكلاء والبرمجة. يلخّص الجدول التالي ذلك.

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

لكن هل يمكننا الوثوق بالمعايير القياسية

هنا تبدأ الحجة الأساسية لهذا المقال. حقيقة أن النتيجة عالية وحقيقة أن هذه النتيجة تتكرر في عملنا الفعلي أمران مختلفان. مباشرة بعد إطلاق K3، تداولت آراء على منصة X مفادها أن “Moonshot ربما أفرطت في التكيّف مع المعايير القياسية”. أشار Guillermo Rauch من Vercel، استناداً إلى تقييم داخلي، إلى أن K3 كان في القمة في مهام الأمن السيبراني وأظهر “ذكاءً خاماً (raw IQ) يتجاوز النتائج الظاهرة”، وهو أمر مثير للاهتمام تحديداً لأنه يعتمد على تقييم خاص وليس معياراً قياسياً علنياً. هذا يشكّل إشارة إلى أن نتائج لوحة الصدارة العلنية ونتائج التقييم الخاص قد تتباعد.

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

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

ما الذي يحتاج المشغّلون للتحقق منه

لذلك، يجب أن يأتي قرار الاعتماد ليس من لوحة الصدارة، بل من تقييم محجوز (held-out) في أيدينا نحن. من الناحية العملية، نوصي بالتسلسل التالي.

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

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

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

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

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

يمسّ هذا النقاش مباشرة كلا منتجَي ThakiCloud.

أولاً، من منظور ai-platform. تقديم (serving) أوزان MXFP4 بحجم 1.4 تيرابايت داخلياً (on-premises) يعني أن ذاكرة GPU والترابط البيني (interconnect) واستراتيجية تفريغ الخبراء يجب أن تُصمَّم معاً. توفر منصة ai-platform من ThakiCloud الأساس لوضع مثل هذه النماذج المفتوحة الضخمة في بيئات العملاء من خلال جدولة GPU المعتمدة على K8s و Kueue، وتقديم من عائلة vLLM، وعزل متعدد المستأجرين (multi-tenant). بالنسبة للعملاء الذين لا يكون فيهم استخدام واجهات برمجة تطبيقات خارجية خياراً أصلاً، سواء بسبب متطلبات جهاز الاستخبارات الوطني أو سيادة البيانات، فإن خيار تشغيل نموذج مفتوح بـ 2.8 تريليون معامل على بنيتهم التحتية الخاصة يحمل قيمة كبيرة في حد ذاته. مع ذلك، وكما شُدّد عليه أعلاه، يجب أن يُحدَّد النموذج المراد تقديمه من خلال تقييم مجال العميل، لا من خلال لوحة الصدارة.

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

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

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

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

المصادر

• Moonshot AI Releases Kimi K3: A 2.8 Trillion Parameter Open MoE Model With Kimi Delta Attention and 1M Context - MarkTechPost
• Kimi K3 Model Overview: 2.8T Parameters, MXFP4 Quantization - Hugging Face
• China’s 2.8-trillion-parameter Kimi K3 - Tom’s Hardware
• Kimi K3 Highlights Limits of AI Benchmark Leaderboards - BankInfoSecurity
• Kimi K3, and what we can still learn from the pelican benchmark - Simon Willison
• Guillermo Rauch on internal evals (X)