💻 computer science

Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live

تقدم الورقة البحثية CacheTTL، وهو نظام جديد لإدارة ذاكرة التخزين المؤقت لـ KV يستخدم آلية زمن بقاء ديناميكي للاحتفاظ الانتقائي بالذاكرة المخبأة أثناء فترات التوقف الناتجة عن استدعاء الأدوات في سير عمل وكلاء النماذج اللغوية الكبيرة متعدد الخطوات، مما يحقق تحسناً يزيد عن 8 أضعاف في وقت إكمال المهام وتعزيزاً في معدل الإنتاجية مقارنة بسياسات الإخلاء الحالية.

المؤلفون الأصليون: Hanchen Li, Runyuan He, Qiuyang Mang, Qizheng Zhang, Huanzhi Mao, Xiaokun Chen, Hangrui Zhou, Alvin Cheung, Joseph Gonzalez, Ion Stoica

نُشر 2026-05-06

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Hanchen Li, Runyuan He, Qiuyang Mang, Qizheng Zhang, Huanzhi Mao, Xiaokun Chen, Hangrui Zhou, Alvin Cheung, Joseph Gonzalez, Ion Stoica

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

المشكلة: المطبخ الذي "يتوقف ويبدأ"

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

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

إليك الخلل في الأنظمة الحالية:

يبدأ الطاهي في طهي وجبة.
يتوقف الطاهي لاستدعاء أداة (مثلاً: "تحقق من حالة الطقس").
ولأن الطاهي في حالة "توقف"، يفترض نظام المطبخ أن الطلب قد انتهى. فيقوم برمي المكونات التي تم تحضيرها جزئياً (ذاكرة الـ KV Cache) لإفساح المجال لطلبات أخرى.
تنتهي الأداة في ثانيتين. يعود الطاهي ليكون جاهزاً للمواصلة.
الكارثة: المكونات اختفت! يتعين على الطاهي إما إعادة شراء المكونات من مستودع بعيد (إخراج البيانات إلى المعالج CPU offloading) أو إعادة تقطيع كل شيء من الصفر (إعادة الحوسبة).
والأسوأ من ذلك، ولأن المكونات قد رُميت، يتعين على الطاهي الانتظار في الطابور خلف زبائن آخرين لمجرد الحصول على مكان على لوح التقطيع مرة أخرى.

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

الحل: CacheTTL (مؤقت "ابقِهِ جاهزاً")

قام الباحثون ببناء نظام جديد يسمى CacheTTL. تخيل أن هذا النظام يمنح الطاهي "مؤقت ابقِهِ جاهزاً" خاصاً لكل طلب.

بدلاً من رمي المكونات فور توقف الطاهي، يقول النظام: "انتظر! قد يعود هذا الطاهي خلال ثانيتين. دعونا نبقي المكونات على الطاولة لفترة زمنية محددة (وقت البقاء - TTL)."

إليك كيف يعمل الأمر ببساطة:

التنبؤ الذكي: ينظر النظام إلى السجل. "عادةً، عندما يستدعي الطاهي 'التحقق من الطقس'، يستغرق الأمر حوالي ثانيتين. وعندما يستدعي 'البحث في الويب'، يستغرق 5 ثوانٍ".
المؤقت: يضبط النظام مؤقتاً بناءً على هذا التنبؤ. إذا كان من المتوقع أن تستغرق الأداة ثانيتين، فستبقى المكونات على الطاولة لمدة 2.5 ثانية.
العائد:
- إذا عاد الطاهي في الوقت المناسب: ستكون المكونات لا تزال هناك! سيكمل الطاهي من حيث توقف تماماً. لا إعادة تقطيع، ولا انتظار في الطابور.
- إذا تأخر الطاهي: إذا استغرقت الأداة 10 ثوانٍ بدلاً من ثانيتين، سينتهي المؤقت. يقوم النظام بأمان برمي المكونات لإفساح المجال لزبائن آخرين، مما يمنع ازدحام المطبخ.

لماذا يعد هذا أفضل مما كان لدينا من قبل؟

الأنظمة السابقة حاولت التخمين فيما إذا كان ينبغي لها الاحتفاظ بالمكونات، لكنها كانت تنظر إلى شيء واحد فقط: "هل إعادة شراء المكونات مكلفة؟" لقد تجاهلت المشكلة الأكبر: "كم سيضطر الطاهي للانتظار في الطابور للعودة إلى العمل؟"

نظام CacheTTL ينظر إلى كليهما:

تكلفة إعادة صنع الطعام.
تكلفة الانتظار في الطابور (تأخير الطابور).

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

النتائج

اختبر الباحثون هذا النظام مع وكلاء ذكاء اصطناعي حقيقيين يحلون أخطاء البرمجيات، ويبحثون في الويب، ويكتبون الأكواد. ووجدوا أن:

السرعة: أنهوا مهامهم بسرعة تصل إلى 8 أضعاف في بعض الاختبارات الواقعية.
الكفاءة: استطاع المطبخ (وحدة معالجة الرسوميات GPU) التعامل مع المزيد من الطلبات في وقت واحد دون أن يعلق.
المتانة: حتى لو استغرقت استدعاءات الأدوات وقتاً أطول من المتوقع، لم يتعطل النظام أو يتوقف؛ بل سمح للمؤقت بالانتهاء فقط وتحرك للأمام.

باخت إجراء مختصر

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

ملخص تقني: CacheTTL

بيان المشكلة

تعتمد محركات استدلال النماذج اللغوية الكبيرة (LLM) حاليًا على سياسات إخلاء "نهاية الدور" (end-of-turn) لإدارة ذاكرة التخزين المؤقت للمفاتيح والقيم (KV cache). في هذه الأنظمة، بمجرد انتهاء طلب فك التشفير، يتم إخلاء ذاكرة الـ KV من ذاكرة الوصول العشوائي للوحدة الرسومية (GPU) لتعظيم الاستفادة من الموارد لطلبات جديدة واردة. وبينما تعد هذه السياسة فعالة للدردشة متعددة الأدوار القياسية، إلا أنها تفشل في أعباء العمل الوكيلية (agentic workloads) (مثل وكلاء هندسة البرمجيات، أو الوكلاء مستخدمي الأدوات) التي تتبع نموذج ReAct.

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

إعادة الحساب (prefill)، مما يتسبب في تأخير كبير في زمن الاستجابة.
إعادة تحميل ذاكرة الـ KV من ذاكرة الوصول العشوائي للمعالج (CPU) (إذا كانت خاصية الإزاحة مفعلة)، مما يؤدي إلى تأخيرات انتظار في الطابور لكل دور. وحتى لو كانت عملية إعادة التحميل سريعة، يجب أن ينتظر الطلب في الطابور حتى يتم تحرير ذاكرة الـ GPU بواسطة طلبات أخرى نشطة.

تفشل الحلول الحالية في معالجة هذا الأمر بشكل شامل:

InferCept يأخذ تكاليف إعادة التحميل في الاعتبار ولكنه يتجاهل تأخير الانتظار المتراكم في الطابور لكل دور ويفتقر إلى المتانة ضد مدد استدعاء الأدوات المتغيرة.
Autellix و Pie يركزان على سير العمل الثابت أو يفتقران إلى سياسات احتفاظ محددة لاستدعاءات الأدوات الديناميكية.
استراتيجيات الاحتفاظ الثابتة تخاطر بحدوث حالة جمود (deadlock) لذاكرة الـ GPU إذا استغرقت استدعاءات الأدوات وقتًا أطول من المتوقع.

التحدي الجوهي هو الاحتفاظ بذاكرة الـ KV لفترة كافية لتجنب إعادة الحساب وتأخيرات الانتظار في الطابور، دون الاستحواذ على ذاكرة الـ GPU خلال أوقات تنفيذ الأدوات غير المتوقعة.

المنهجية: CacheTTL

يقترح المؤلفون CacheTTL، وهو نظام خدمة يقدم آلية وقت البقاء (Time-to-Live - TTL) للاحتفاظ بذاكرة الـ KV. بدلاً من الإخلاء الفوري، يقوم CacheTTL بتثبيت ذاكرات الـ KV انتقائيًا في ذاكرة الـ GPU لمدة محسوبة.

1. نموذج المنفعة بين التكلفة والفائدة

يحدد CacheTTL زمن الـ TTL الأمثل ( $\tau$ ) من خلال نمذجة المقايضة بين تكلفة الاحتفاظ بالذاكرة وفائدة تجنب الإخلاء.

التكلفة ( $Cost(\tau, r)$ ): هي تكلفة الفرصة البديلة لشغل ذاكرة الـ GPU، وتُحسب كنسبة استخدام ذاكرة الطلب إلى متوسط بصمة الذاكرة للطلبات النشطة، مضروبة في مدة الـ TTL ( $\tau$ ). ويمثل هذا زمن التأخير المضاف للطلبات الأخرى التي تعطلت بسبب الذاكرة المثبتة.
الفائدة ($Benefit(r)$): هي مجموع تكالفيتين تم تجنبهما:
1. تكلفة فقدان الذاكرة المؤقتة (CacheMissCost): الوقت المطلوب لإعادة بناء ذاكرة الـ KV (prefill) أو إعادة تحميلها من الـ CPU.
2. تكلفة الخروج عن الترتيب (OutofOrderCost): تأخير الانتظار في الطابور لكل دور الذي قد يحدث إذا تم إخلاء الذاكرة واضطر الطلب للانتظار في الطابور حتى تصبح ذاكرة الـ GPU متاحة. هذا المصطلح بالغ الأهمية ويميز CacheTTL عن الأعمال السابقة مثل InferCecept. ويتم قياسه بواسطة عامل الذاكرة (memoryfulness factor - $\eta$ )، الذي يقيس مدى ارتباط عدد الخطوات المتبقية بالتقدم الحالي (على سبيل المثال، البرامج ذات الطول الثابت لها عامل ذاكرة عالٍ).

2. حساب الـ TTL

يحسب النظام الـ TTL الأمثل ( $\tau^*$ ) عن طريق تعظيم المنفعة الصافية المتوقعة:
$\tau^* = \arg\max_{\tau} \left( P(\tau, f) \times Benefit(r) - Cost(\tau, r) \right)$
حيث أن $P(\tau, f)$ هي احتمالية اكتمال استدعاء الأداة $f$ خلال الزمن $\tau$ ، والتي تُقدر باستخدام دالة التوزيع التراكمي (CDF) التجريبية من سجلات استدعاء الأدوات التاريخية.

التعامل مع البداية الباردة (Cold Start): عندما تكون البيانات التاريخية شحيحة، يعتمد CacheTTL على TTL ثابت مشتق من افتراض التوزيع الأسي أو المتوسطات العالمية.
المتانة: إذا تجاوز استدعاء الأداة مدة الـ TTL، يتم إخلاء ذاكرة الـ KV تلقائيًا، مما يمنع الاحتلال غير المحدود للذاكرة والجمود المحتمل.

3. الجدولة وتصميم النظام

التعامل بنظام FCFS على مستوى البرنامج: يجمع CacheTTL بين الـ TTL وسياسة "الوصول أولاً يُخدم أولاً" (FCFS) على مستوى البرنامج (وليس فقط مستوى الطلب). وهذا يضمن منح الأولوية للطلبات التي تنتمي إلى نفس برنامج الوكيل للحفاظ على الاستمرارية.
الأولوية الواعية بالـ TTL: يخصص المجدول (scheduler) زوجًا من المفاتيح المتعددة للأولوية:
1. حالة الاستبعاد المسبق (Preempted status).
2. حالة الـ TTL: تُعطى الأولوية للطلبات ذات الـ TTL النشط (المثبتة) على الطلبات غير المثبتة.
3. وقت الوصول على مستوى البرنامج.
التنفيذ: مبني فوق vLLM مع معالج استدعاء الأدوات (Tool-Call Handler) نموذجي. يقوم هذا المعالج بتحليل مخرجات الـ LLM لتحديد استدعاءات الأدوات، وتسجيل الفواصل الزمنية بين الطلبات، وإبلاغ المجدول بقيم الـ TTL. التصميم يضيف عبئًا ضئيلاً (~1k سطر من لغة Python) وهو متوافق مع الإزاحة إلى الـ CPU/SSD.

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

تحديد المشكلة: حددت الورقة أن سياسات إخلاء ذاكرة الـ KV الحالية تضعف أداء الوكلاء لأنها تتجاهل تأخيرات الانتظار في الطابور لكل دور وتنوع مدد استدعاء الأدوات.
نظام CacheTTL: نظام خدمة مبتكر يستخدم آلية TTL للاحتفاظ بذاكرة الـ KV ديناميكيًا، حيث يوازن بين تكاليف الـ prefill/reloading وتكاليف تنازع الذاكرة.
نموذج تكلفة مبتكر: تقديم مصطلح OutofOrderCost، الذي يحدد كمياً عقوبة تأخير الانتظار في الطابور، وعامل الذاكرة للتكيف مع هياكل أعباء العمل المختلفة.
المتانة: يتعامل النظام مع مدد استدعاء الأدوات غير المتوقعة من خلال فرض حد أقصى لوقت الاحتفاظ، مما يمنع حالات الجمود وضغط الذاكرة.

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

قام المؤلفون بتقييم CacheTTL باستخدام Llama-3.1 (8B/70B)، و Gemma-3 (12B)، و GLM-4.5 (355B) عبر أعباء عمل SWE-Bench، و BFCL، و OpenHands على أجهزة متنوعة (A100, H100, B200).

تقليل زمن الاستجابة: يقلل CacheTTL متوسط زمن إكمال المهمة بمقدار 1.12x إلى 3.66x مقارنة بالنماذج المرجعية (vLLM, Autellix, InferCept). وفي اختبارات وكيل SWE الواقعية على بيئة الاختبار الداخلية للشركة (أ)، حقق تحسنًا يصل إلى 8.18x في التأخير.
الإنتاجية (Throughput): تحسنت الإنتاجية بمقدار 1.10x إلى 3.22x.
المتانة: يحافظ النظام على أداء مستقر مع زيادة عدد الأدوار، بينما تتدهور النماذج المرجعية بشكل كبير بسبب تأخيرات الانتظار المتراكمة في الطابور.
التوافق: يتفوق CacheTTL على النماذج المرجعية حتى عند دمجه مع إزاحة الـ CPU والـ SSD، مما يثبت أن فوائد الجدولة الخاصة به مستقلة عن تقنيات إزاحة الذاكرة.
العبء الإضافي: العبء الإضافي للجدولة ضئيل للغاية (بالملي ثانية الواحدة)، وهو ما يتضاءل أمام توفير زمن الاستجابة النهائي.

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

تدعي الورقة أن CacheTTL يوفر أول استراتيجية قوية لإدارة ذاكرة الـ KV واعية بالأدوات ومصممة خصيصًا لأعباء العمل الوكيلية متعددة الأدوار. ومن خلال الانتقال من إخلاء "نهاية الدور" إلى سياسة احتفاظ قائمة على الـ TTL، ينجح النظام في سد الفجوة بين استدلال الـ LLM وتنفيذ الأدوات الخارجية.

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