vLLM تتيح لعقد decode إعادة KV-cache إلى عقد prefill وتُسرّع TTFT حتى 3.3 مرة

أضاف فريق vLLM نقل KV-cache في الاتجاهين إلى الاستدلال المفصول (disaggregated inference). صار بإمكان عقد prefill أن تأخذ من عقد decode الـ cache المحسوب مسبقاً للدورات السابقة من الحوار، دون إعادة حساب السياق كاملاً في كل دورة. وفي الـ prompts الطويلة متعددة الدورات ينخفض زمن أول توكن (TTFT) حتى 3.3 مرة.

أين كان الوقت يضيع

في نمط disaggregated serving تعمل مرحلتا prefill وdecode على مجمّعات GPU منفصلة. تعالج prefill الـ prompt وتبني KV-cache، ثم تسلّمه إلى عقدة decode التي تولّد الرد توكناً تلو الآخر. المنطق وراء هذا الفصل واضح: prefill محكومة بالحوسبة، بينما decode محكومة بالذاكرة وعرض النطاق الترددي، ويمكن ضبط كل مجمّع وفق حمله الخاص.

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

في الدردشة العادية يمكن تحمّل ذلك. أما مع الوكلاء فلا. فالحلقة الوكيلية (agentic loop) تتألف من عشرات الخطوات: استدعاء أداة، ثم رد، ثم استدلال، ثم استدعاء تالٍ. يتسع السياق إلى عشرات الآلاف من التوكنات، بينما يبقى الجزء الجديد منه في كل خطوة صغيراً. وهكذا ندفع ثمن prefill كاملاً مقابل ما حسبناه قبل دقيقة.

كيف تعمل القناة العكسية

الفكرة بسيطة. بعد توليد الرد تحتفظ عقدة decode بـ KV-cache الخاص بالـ prompt والتوكنات المولَّدة معاً. وحين تصل الدورة التالية، يمكن لعقدة prefill أن تطلب منها البادئة (prefix) المطابقة، وتستلمها، ثم تحسب الذيل الجديد فقط. بعد ذلك يجري كل شيء كما كان: يُرسل الـ cache الكامل إلى decode.

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

أبرز الأرقام من الإعلان:

• تسريع TTFT: حتى 3.3x؛
• السيناريو: الـ prompts الطويلة متعددة الدورات؛
• ما يجري توفيره: حوسبة prefill المتكررة على السجل المعالَج مسبقاً؛
• اتجاه النقل: decode → prefill بالإضافة إلى prefill → decode؛
• المنصة: vLLM في تهيئة تفصل بين عقد prefill وعقد decode.

حُدِّدت القيمة 3.3x بوصفها حداً أقصى. فهي أفضل حالة في الحوارات الطويلة، وليست متوسطاً مضموناً للنتائج. أما في المراسلات القصيرة ذات البادئة الصغيرة فسيكون الفارق أقل بكثير.

ما لم يُكشف عنه

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

وثمة سؤال معماري أيضاً. كي تتمكن عقدة decode من إعادة الـ cache، يجب أن تحتفظ به، بينما ذاكرة HBM على الـ GPU محدودة. وكلما طالت الجلسات زاد الضغط على الذاكرة، وازدادت أهمية سياسة الإخلاء (eviction). وإذا كان الـ cache قد أُخلي فعلاً، فلن يتحقق أي مكسب، وتعود prefill إلى إعادة الحساب الكاملة.

لمن يفيد هذا عملياً

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

قبل التطبيق يُستحسن التحقق على حركة البيانات الخاصة بكم من النقاط التالية:

• ما نسبة البادئة المتكررة بين الدورات، وكيف تنمو خلال الجلسة؛
• هل يكفي عرض النطاق الترددي للـ interconnect بين عقد prefill وعقد decode؛
• كم من الوقت تحتفظ عقد decode بالـ cache، وكم مرة يُخلى قبل الدورة التالية؛
• كيف يتغير p95/p99 TTFT، وليس أفضل نتيجة فقط.

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