ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System

إليك ملخص تقني مفصل لورقة البحث بعنوان "ThunderAgent: نظام استدلال وكيل (Agentic) بسيط، سريع، ومدرك للبرامج."

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

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

1. تخبط ذاكرة التخزين المؤقت لـ KV (KV Cache Thrashing): تتناوب سير عمل الوكلاء بين "التفكير" (توليد LLM) و"التنفيذ" (تشغيل الأدوات). تتعامل الأنظمة الحالية التي تدرك الطلبات كأن كل خطوة هي طلب مستقل وغير مرتبط بحالة (stateless). عندما يتم استدعاء أداة، يقوم النظام غالباً بإخلاء ذاكرة التخزين المؤقت لـ KV لاستيعاب طلبات جديدة. وعند عودة الأداة، يجب على النظام إعادة حساب تاريخ التفاعل بالكامل (إعادة التعبئة المسبقة - re-prefill)، مما يزيد زمن الاستجابة الإجمالي بمقدار يصل إلى 7.14 ضعفاً ويدمر معدل الإنتاجية (throughput).
2. عدم توازن الذاكرة عبر العقد (Cross-Node Memory Imbalance): في البيئات الموزعة، تقوم المجدولات الحالية غالباً بتثبيت جميع الطلبات من سير عمل واحد على عقدة GPU محددة لتعظيم محلية التخزين المؤقت (cache locality). ومع ذلك، نظرًا لأن سير عمل الوكلاء يتسم بأطوال سياق وفترات تنفيذ غير متوقعة، يؤدي ذلك إلى عدم توازن شديد في الذاكرة: حيث تنفد الذاكرة من بعض العقد بينما تظل أخرى غير مستغلة، مما يسبب عمليات إقصاء (preemption) غير ضرورية.
3. الجهل بدورة حياة الأداة (Tool Lifecycle Obliviousness): تفتقر المنسقات إلى الرؤية الشاملة لحالة الوكيل. فهي تفشل في تحرير الموارد (مثل حاويات Docker، أو منافذ الشبكة) فور اكتمال سير العمل، مما يؤدي إلى استنزاف الموارد. وعلى العكس من ذلك، فإنها غالباً ما تنتظر حتى يتم تجهيز البيئات بالكامل قبل السماح لـ LLM بالتفكير، مما يضيف تأخراً كبيًراً في زمن الاستجابة.

2. المنهجية: ThunderAgent

يقدم ThunderAgent تجريداً مدركاً للبرامج (program-aware) يوحد جدولة استدلال LLM وتنفيذ الأدوات. بدلاً من إدارة الطلبات الفردية، فإنه يدير البرامج الوكيلية (Agentic Programs) كوحدات جدولة أساسية.

أ. تجريد البرنامج (Program Abstraction)

يصنف النظام سير عمل الوكيل كـ "توبل" (tuple) $P = \langle ID, c, T, L, \tau, s \rangle$ حيث:

• $ID$: معرف عالمي فريد.
• $c$: عدد توكنات السياق (بصمة ذاكرة KV cache).
• $T$: مجموعة بيئات الأدوات المطلوبة.
• $L$: وضع العقدة (للمحلية المكانية).
• $\tau$: مرحلة التنفيذ (التفكير أو التنفيذ).
• $s$: حالة الجدولة (نشط، متوقف مؤقتاً، منتهي).

يسمح هذا التجريد للمجدول بالتمييز بين الانتظار المؤقت للأداة وبين الجلسة المنتهية، مما يتيح إدارة ذكية للموارد.

ب. المجدول المدرك للبرنامج (Program-Aware Scheduler)

يحسن المجدول نموذج تكلفة يقلل من الأعباء غير المنتجة: إعادة الحساب ($Cost_{recompute}$)، السعة غير المستخدمة ($Cost_{unused}$)، والتخزين المؤقت الخامل ($Cost_{caching}$).

1. الإيقاف المؤقت الواعي بالحالة والإقصاء بناءً على الأقصر أولاً:
   • يراقب النظام ضغط الذاكرة بشكل دوري. إذا كان النظام الخلفي يعاني من التخبط، فإنه يوقف البرامج مؤقتاً.
   • الاستراتيجية: يعطي الأولوية لإيقاف البرامج في مرحلة التنفيذ (تشغيل الأداة) لتوفير الذاكرة لبرامج التفكير.
   • سياسة الإقصاء: من بين البرامج المراد إقصاؤها، يختار تلك ذات أطوال السياق الأقصر أولاً. يثبت التحليل النظري أن تكلفة إعادة الحساب تتناسب طردياً مع مربع طول السياق ($c^2$)؛ وبالتالي، فإن إقصاء السياقات الأقصر يقلل من إجمالي عقوبة إعادة الحساب.
2. الهجرة الديناميكية عبر طابور الانتظار العالمي:
   • بدلاً من تثبيت سير العمل في عقدة معينة، يستخدم ThunderAgent طابور انتظار عالمي مدرك للبرنامج مشترك عبر جميع عقد التوازي البياناتي (DP).
   • عند إيقاف برنامج مؤقتاً، يتم إخلاء ذاكرة KV cache الخاصة به (مما يجعله غير مرتبط بعقدة محددة). يمكن بعد ذلك استعادته إلى أي عقدة ذات سعة متاحة، مما يوازن حمل الذاكرة عبر المجموعة دون التضحية بمحلية التخزين المؤقت.

ج. إدارة موارد الأدوات المدركة للبرنامج

1. جمع المهملات المدرك لدورة الحياة: ترتبط الموارد (حاويات Docker، المنافذ) ارتباطاً وثيقاً بحالة البرنامج. عندما يصل البرنامج إلى حالة Terminated (منتهي)، يتم استرداد الموارد فوراً، مما يمنع تسرب القرص/الذاكرة.
2. التحضير غير المتزامن للبيئة: يقوم النظام بدمج إعداد البيئة كثيف الإدخال/الإخراج (مثل سحب صور Docker) مع تفكير LLM. يراقب النظام الطابور العالمي ويجهز البيئات للبرامج ذات الأولوية العالية قبل استعادتها إلى وحدة معالجة الرسومات (GPU)، مما يخفي زمن انتقال التهيئة.

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

• التجريد الموحد: قدم مفهوم "البرنامج الوكيلي"، الذي يفصل منطق الجدولة عن محركات الاستدلال المحددة (vLLM/SGLang) ويتيح رؤية موحدة للموارد غير المتجانسة (KV cache، القرص، الشبكة).
• خوارزمية جدولة محسنة: طور نهج تحسين مقيد يقلل تكاليف إعادة الحساب عبر استراتيجية "الأقصر أولاً للإقصاء" ويوازن الذاكرة عبر الهجرة العالمية، محققاً معدلات إصابة (hit rates) مثالية تقريباً لـ KV cache.
• إدارة فعالة للموارد: نفذ جامع مهملات مدرك لدورة الحياة وتحضيراً غير متزامن للبيئة، مما حل مشكلات تسرب الموارد وتأخر الإعداد المتأصلة في الأنظمة الوكيلية الحالية.
• نظام مفتوح المصدر: تم طرح التنفيذ الكامل كمصدر مفتوح، مما يسهد عملية إعادة الإنتاج والتطوير المستقبلي.

4. النتائج التجريبية

تم تقييم ThunderAgent عبر أعباء عمل متنوعة (البرمجة، التوجيه، الاكتشاف العلمي) ونماذج مختلفة (GLM-4.6, Qwen-3) على مجموعات GPU مكونة من 8×H100.

• إنتاجية الخدمة (Serving Throughput): حقق تحسينات في الإنتاجية تترا-وح 1.5× إلى 3.6× مقارنة بالأنظمة الرائدة (vLLM, Continuum).
  • مثال: في مهمة SWE-Agent مع GLM-4.6، زادت الإنتاجية بمقدار 2.65× مقارنة بـ vLLM و 1.52× مقارنة بـ Continuum عند مستويات التزامن العالية.
• كفاءة تدفق RL (RL Rollout Efficiency): أظهر تحسينات تتراوح بين 1.8× إلى 3.9× في سرعات تدفق التعلم التعزيزي (Reinforcement Learning)، وهو أمر حاسم لتقليل تأخر السياسة (policy lag) في التدريب غير المتزامن.
• توفير الموارد: قلل استخدام ذاكرة القرص بنسبة تصل إلى 4.2× من خلال الاسترداد الفعال لبيئات الأدوات.
• معدل إصابة KV Cache: حافظ على معدلات إصابة قريبة من 100% لتدفقات العمل ذات أوقات الأدوات المتوقعة، بينما انخفضت المعدلات في الأنظمة المرجعية إلى ~60% بسبب التخبط.
• زمن الاستجابة (Latency): قلل زمن الاستجلة الإجمالي بشكل كبير من خلال القضاء على عمليات إعادة التعبئة المسبقة ودمج إعداد البيئة.

5. الأهمية

يمثل ThunderAgent تحولاً جذرياً من الجدولة على مستوى الطلب إلى الجدولة على مستوى البرنامج في الذكاء الاصطناعي الوكيلي.

• القابلية للتوسع: يحل مشكلة "انهيار الإنتاجية" التي تظهر في الأنظمة الحالية مع زيادة أحجام الدفعات (batch sizes)، مما يجعل استدلال الوكلاء واسع النطاق مجدياً اقتصادياً.
• كفاءة التكلفة: من خلال تعظيم الاستفادة من الأجهزة وتقليل إعادة الحساب الضائعة، فإنه يخفض تكلفة خدمة الوكلاء المعقدين بشكل كبير.
• أساس لوكلاء المستقبل: مع زيادة استقلالية وتعقيد الوكلاء، تصبح القدرة على إدارة تدفقات العمل المعتمدة على الحالة عبر موارد غير متجانسة (GPU، CPU، شبكة) أمراً ضرورياً. يوفر ThunderAgent البنية التحتية اللازمة لدعم الجيل القادم من التطبيقات الوكيلية.

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