ملخص تقني: طبقة تشغيل مدفوعة بالسياسات لخدمة النماذج اللغوية الكبيرة الوكيلية (Agentic LLM)

1. بيان المشكلة

أصبحت أنظمة النماذج اللغوية الكبيرة (LLM) متعددة الوكلاء (Multi-agent) هي عبء العمل المهيمن في بيئات الإنتاج، ومع ذلك، فإن بنية نظام الخدمة الحالي غير متوافقة هيكلياً مع متطلباتها. تعمل الأنظمة الحالية وفق هيكل مكون من طبقتين:

1. إطار عمل الوكيل (في الأعلى): أنظمة مثل AutoGen أو LangGraph أو MetaGPT التي تدير هويات الوكلاء، ومخططات الأدوار، ومنطق التوزيع. هذه الأنظمة تصدر استدعاءات واجهة برمجة تطبيقات (API) للنماذج اللغوية، لكنها تظل "عمياء" عن أحداث مستوى المحرك (مثل: توليد الرموز (tokens)، وحالة ذاكرة التخزين المؤقت للمفاتيح والقيم (KV cache)).
2. محرك الخدمة (في الأسفل): محركات مثل vLLM أو SGLang التي تتعامل مع عمليات التعبئة المسبقة (prefilling)، والدفعات (batching)، وتوليد الرموز. هذه المحركات تراقب كل حدث، لكنها لا تملك أي معرفة بهويات الوكلاء أو البنية الدلالية لسير عمل الوكلاء المتعددين.

تخلق هذه "الفجوة" (seam) عائقاً حرجاً أمام السياسات العابرة للوظائف (cross-cutting policies). فالعديد من استراتيجيات التحسين — مثل إخلاء ذاكرة KV cache، وتشكيل الدفعات، والتنفيذ الاستباقي، وضمان العدالة، وفرض السلامة — تتطلب وصولاً متزامناً إلى بيانات تعريف هوية الوكيل (من إطار العمل) وأحداث مستوى المحرك (من محرك الخدمة). حالياً، يتم تنفيذ هذه السياسات كـ "رقع مؤقتة" (one-off patches) في إما إطار العمل أو المحرك. هذا النهج يتسم بالهشاشة، ويفتقر إلى الوحدوية (modularity)، ويفشل في الاستفادة من السياق الكامل المطلوب لاتخاذ القرارات المثلى.

2. المنهجية: طبقة تشغيل الوكيل (Agent Runtime Layer)

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

الركائز الأربع

تحدد الطبقة أربع ركائز عامة يمكن من خلالها لأي سياسة مدركة للوكيل أن تتصل بالطبقة. تشكل هذه الركائز حلقة تغذية راجعة من نوع الملاحظة ← التقييم ← التنبؤ ← الفعل (observe → score → predict → act)، موحدة بواسطة هوية الوكيل كإحداثي مشترك:

1. الملاحظة (observe(event)): تستقبل طبقة التشغيل أحداثاً ذات صلة بالسياسة من الجيران (مثل: لمس الكتل (block touches)، وصول الطلبات، أو عودة الأدوات). وتقوم بتحديث الحالة الداخلية المصنفة حسب هوية الوكيل.
2. التقييم (score(item)): تعيد الطبقة أولوية لكل عنصر يستخدمها الجار لتصنيف القرارات (مثل: أي كتلة KV يجب إخلاؤها، أو أي طلب يجب قبوله).
3. التنبؤ (predict(horizon)): تعيد الطبقة توقعاً احتمالياً لنشاط الوكيل المستقبلي (مثل: دور الوكيل التالي، أو استدعاء الأداة التالي).
4. الفعل (act(side_effect)): تصدر الطبقة آثاراً جانبية خارج المسار الحرج إلى الجار (مثل: تسخين ذاكرة تخزين مؤقت، أو تحميل الأوزان مسبقاً، أو التحوط لاستدعاء استباقي). هذه هي الركيزة الوحيدة التي تغير حالة الجار.

دراسة حالة: CacheSage

للتحقق من صحة هذا التجريد، قام المؤلفون بتطبيق الطبقة على ذاكرة التخزين المؤقت KV (KV caching)، وهي السياسة ذات التأثير المباشر الأكبر على تكاليف الخدمة. قدموا CacheSage، الذي يعالج مشكلة سقوط "مرتكزات الوكيل" (البرومبت الخاص بالنظام وتعريفات الأدوات) من الذاكرة المسبقة التفاعلية قبل وصول الجلسة التالية.

ينفذ CacheSage الركائز الأربع عبر ثلاثة مكونات:

• متعلم الانتقال (Transition Learner - observe): يحافظ على نافذة منزلقة لعدّ الانتقالات الزوجية بين الوكلاء ($n(a', a)$) لحساب مصفوفة انتقال ماركوف من الدرجة الأولى عبر الإنترنت. كما يحدد "مرتكز الوكيل" (النظام + الأدوات) عبر تجزئة المحتوى (content hashing).
• مُقيّم احتمالية البقاء (Survival-Probability Scorer - score): يقرب احتمالية اشتعال الوكيل خلال الخطوات $K$ القادمة. بدلاً من الحسابات الدقيقة المكلفة، يستخدم رسماً بيانياً موجهاً غير حلقي (DAG) وبحثاً بالعرض (BFS) لحساب تقريب لعدد "القفزات" (hop count). يتم دمج هذا التقييم مع ساعة الحداثة الموجودة في المحرك لتحديد أولوية الإخلاء.
• التحميل المسبق عبر الجلسات (Cross-Session Prefetch - predict + act): بين خطوات الجدولة، تتنبأ طبقة التشغيل بالوكيل التالي ($a^*$) وتصدر طلباً لـ "التسخين". يحتوي هذا الطلب فقط على برومبت النظام ورسالة مستخدم دنيا لملء ذاكرة KV cache لمرتكز الوكيل المتوقع دون حقن محتوى كامل خاص بالجلسة.

3. المساهمات الرئيسية

1. طبقة تشغيل الوكيل: طبقة ثالثة مقترحة لسلسلة خدمة النماذج، تعرض واجهة مكونة من أربع ركائز (observe, score, predict, act). قام المؤلفون بربط تسع سياسات مختلفة مدركة للوكيل (بما في ذلك تخزين KV caching، وتخزين نتائج الأدوات، وتشكيل الدفعات، والعدالة) بهذه الواجهة، بحجة أنها جميعاً تشترك في نفس الحاجة المعمارية للأحداث المصنفة بهوية الوكيل.
2. CacheSage: تنفيذ ملموس للطبقة من أجل ذاكرة التخزين المؤقت KV. يتعلم مصفوفات انتقال الوكلاء لكل عبء عمل عبر الإنترنت ويستخدمها للإخلاء القائم على البقاء والتحميل المسبق بين الخطوات. يعمل بذاكرة محدودة ($\le$ 20 كيلوبايت لكل عبء عمل) ويتضمن آلية تراجع سلسة إلى خوارزمية LRU القياسية في حال عدم تعلم أي هيكل.
3. التحقق التجريبي: نتائج أولية على خمسة أعباء عمل متعددة الوكلاء من الواقع (MMLU, MT-Bench, GAIA, GSM8K, HumanEval) تظهر فعالية النهج.

4. النتائج

أُجريت التجارب على وحدات معالجة رسومية NVIDIA H100 باستخدام نموذج Llama-3.1-8B-Instruct، مقارنة بـ vLLM وContinuum.

• معدل إصابة الذاكرة (Cache Hit Rate): حقق CacheSage زيادة قدرها +13 إلى +37 نقطة مئوية (pp) في معدلات إصابة الذاكرة مقارنة بـ vLLM عبر جميع أعباء العمل الخمسة. ويُعزى ذلك إلى الاحتفاظ بمرتكزات الوكيل عبر حدود الجلسات التي عادة ما تقوم الذاكرات التفاعلية بإخلائها.
• زمن الاستجابة (Latency): انخفض متوسط زمن الوصول لأول توكن (TTFT) وزمن الاستجటు الشامل لكل دورة بنسبة 12% إلى 29%.
• الإنتاجية (Throughput): زادت إنتاجية النظام بنسبة 6% إلى 14%.
• العبء الإضافي (Overhead): العبء في المسار الساخن ضئيل جداً. تعمل وظيفة observe في حوالي $1 \mu s$ لكل لمسة كتلة، ويعمل المُقيّم في ميكروثانية معدودة. وتظل حالة المنسق أقل من 25 كيلوبايت.

ومن الجدير بالذكر أن نظام Continuum المرجعي، الذي يستخدم تثبيتات TTL، أدى في الواقع إلى خفض معدلات الإصابة بنسبة 9-23 نقطة مئوية في ثلاثة أعباء عمل واقعية، مما يسلط الضوء على المقايضات بين السياسات الثابتة والطبيعة التكيفية لطبقة التشغيل.

5. الأهمية والادعاءات

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

• الوحدوية (Modularity): تسمح الواجهة المكونة من أربع ركائز لسياسات مختلفة بمشاركة نفس تدفق الملاحظات والعمل مقابل نفس الركائز دون الحاجة إلى تعديلات عميقة في المحرك لكل سياسة جديدة.
• العمومية (Generality): الطبقة مستقلة عن إطار العمل (تدعم AutoGen وLangGraph وغيرهما) وقابلة للنقل بين المحركات، حيث تتطلب فقط خطافات (hooks) محددة بدلاً من التعديلات الجذرية العميقة.
• التحقق من الفجوة: من خلال إظهم مكاسب الأداء الكبيرة في ذاكرة KV caching، يجادل المؤلفون بأن الفجوة المعمارية حقيقية وأن طبقة تشغيل الوكيل هي مكون ضروري لخدمة النماذج الوكيلية بكفاءة.

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