WAKMan يختار سياسة إخلاء KV-cache ويتفوق على LRU بمقدار 5 نقاط مئوية

يوفّر prefix caching في خوادم LLM المال والوقت، لكن فقط ما دام البادئة المطلوبة باقية في الذاكرة. والذاكرة محدودة، وتتوقف النتيجة على سياسة إخلاء KV-cache. اختبر الباحث Suhas Kumar Morisetty وثلاثة مؤلفين آخرين، ممن عملوا ضمن تدريب في Capital One، الاستراتيجيات الشائعة على 20 مزيجاً من الأحمال. والخلاصة بسيطة: لا توجد سياسة واحدة هي الأفضل دائماً. واقترح الفريق WAKMan، وهو مدير يختار سياسة الإخلاء بحسب حركة المرور الفعلية. ويحسّن هذا النظام hit rate في المتوسط بمقدار 5 نقاط مئوية مقارنة بـ LRU.

لماذا يريد الوكلاء وروبوتات الدردشة من الكاش أمرين مختلفين

يتيح prefix caching للخادم إعادة استخدام حالات Key-Value للطلبات التي تشترك في بادئة مع prompts سابقة. وهذا يسرّع مرحلة prefill ويخفض زمن الاستجابة وتكلفة الخدمة. لكن حركة المرور الإنتاجية الواقعية متنوعة: طلبات منفردة، وحوارات متعددة الأدوار، وسلاسل وكيلية (agentic)، أو أي مزيج بينها.

ولهذه الأنواع «زمن عودة» مختلف إلى البادئة. تعود خطوات الوكيل خلال بضع ثوانٍ، وتحتاج إلى كاش يتذكر ما جرى حديثاً. أما الـ prompts الشائعة والحوارات الطويلة فتعود بعد عدد كبير من الطلبات الأخرى، ويكون تكرار الوصول عاملاً أهم بالنسبة لها. تناسب الصورة الأولى LRU، وتناسب الثانية السياسات القائمة على التكرار.

أين يتفوق LRU وأين يخسر

يُستخدم LRU افتراضياً في vLLM. قارنه المؤلفون بسياسة S3FIFO الموجّهة بالتكرار، وخرجوا بنتيجة تنقض عادة اختيار سياسة واحدة إلى الأبد:

• في المزائج التي تغلب عليها الطلبات الوكيلية يحقق LRU إصابات في الكاش أكثر بنسبة 12% من S3FIFO؛
• في بقية المزائج يتأخر LRU عن S3FIFO بما يصل إلى 22%؛
• حتى معامل واحد في الحِمل قد يغيّر الفائز داخل المزيج نفسه.

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

ماذا يفعل WAKMan

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

النتائج النهائية لـ WAKMan:

• زيادة في hit rate مقارنة بـ LRU بمتوسط 5 نقاط مئوية؛
• أقل فجوة متوسطة عن السياسة المثلى بين جميع الأنظمة المقارَنة؛
• أقل فجوة في أسوأ حالة عن الحل الأمثل بين جميع الأنظمة المقارَنة؛
• اختبار على 20 مزيجاً من أحمال single-turn وmulti-turn وagentic.

النقطتان الثانية والثالثة أهم من متوسط الزيادة. فهما تدلان على قابلية التنبؤ: لا يفوز WAKMan بالضرورة في كل مزيج على حدة، لكنه يخطئ الخيار الأفضل بوتيرة أقل وبمقدار أصغر. وبالنسبة لمشغّل الاستدلال (inference) فهذا أثمن من فوز لافت واحد على بنشمارك بعينه.

ماذا تفعل الفرق التي تتزايد فيها حصة الوكلاء

تشغل السيناريوهات الوكيلية بسرعة حصة متنامية من حركة المرور. ومعها يتغير ملف الكاش: تزداد العودات «الساخنة» القصيرة، وتبقى الـ prompts الشائعة والحوارات الطويلة في الخلفية. وإذا كانت سياسة الإخلاء مضمّنة في الخادم ولا تُراجع أبداً، فإن جزءاً من مكسب prefix caching يضيع. ويضيع في صورة prefill مكرر، أي ثوانٍ زائدة من GPU وزمن استجابة زائد.

الخلاصة العملية لمن يشغّل استدلالاً خاصاً به على vLLM:

• قيسوا hit rate بصورة منفصلة لكل نوع من الأحمال، لا بالمتوسط على مستوى الخادم فقط؛
• لا تعتبروا LRU خياراً آمناً دائماً: ففي بعض المزائج يخسر أمام S3FIFO بما يصل إلى 22%؛
• أعيدوا فحص السياسة عند تغيّر حصة حركة المرور الوكيلية؛
• قيّموا الحلول بحسب أسوأ حالة، لا بمتوسط الزيادة فقط.

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