توجيه ذاكرة التخزين المؤقت KV: لماذا تتسبب موازنات التحميل القياسية في تعطيل التخزين المؤقت للبادئة (Prefix Caching) (وكيفية إصلاح ذلك)

التخزين المؤقت للبادئات (Prefix caching) يسمح لـ vLLM و SGLang بتجاوز إعادة حساب الرموز التي سبق للنموذج رؤيتها — ولكن فقط إذا وصل الطلب التالي إلى نفس نسخة وحدة معالجة الرسوميات (GPU). يمكن للتوجيه الدائري القياسي (round-robin routing) أن يقلل بشكل كبير من موقعية التخزين المؤقت (cache locality) في عمليات النشر متعددة النسخ، مما يحد من فوائد التخزين المؤقت للبادئات ما لم يتم جعل التوجيه مدركًا للتخزين المؤقت. التوجيه الثابت المدرك للبادئات (Prefix-aware sticky routing) يحل هذه المشكلة. تشرح هذه المقالة الآلية، وتكلفة تجاهلها، وكيفية تطبيقها بثلاثة مستويات من التعقيد المتزايد.

يمثل الاستدلال (Inference) حصة متزايدة من الطلب على الحوسبة في مجال الذكاء الاصطناعي. تشير بعض تقديرات الصناعة إلى أن الاستدلال قد يمثل غالبية استهلاك الحوسبة في الذكاء الاصطناعي مع نضوج أعباء عمل الذكاء الاصطناعي التوليدي، وجزء كبير من ذلك هو عمل زائد عن الحاجة — حيث يقوم نموذجك بإعادة حساب حالات الانتباه (attention states) للرموز التي عالجها قبل ثوانٍ. المشكلة ليست في وحدة معالجة الرسوميات (GPU) أو النموذج. إنها موازنة التحميل (load balancer) التي تقف أمام مجموعة الاستدلال الخاصة بك، والتي توجه كل طلب دون أي وعي بما هو مخزن مؤقتًا وأين.

للحصول على نظرة عامة أوسع حول محركات استدلال نماذج اللغة الكبيرة (LLM) ووسائل التحسين، انظر استدلال نماذج اللغة الكبيرة: تحسين السرعة والتكلفة وتوسيع نطاق الذكاء الاصطناعي.

لماذا يعتبر التخزين المؤقت للبادئات مهمًا

يتم تنفيذ كل طلب استدلال لنموذج لغة كبير (LLM) على مرحلتين متميزتين. خلال مرحلة prefill، يقوم النموذج بمعالجة تسلسل الإدخال بالكامل ويبني ذاكرة تخزين مؤقتة للمفاتيح والقيم (KV cache) — وهي مصفوفة من حالات الانتباه (attention states)، إدخال واحد لكل رمز، مخزنة في ذاكرة الوصول العشوائي لبطاقة الرسوميات (GPU VRAM). خلال مرحلة decode، يقوم النموذج بتوليد رموز الإخراج رمزًا تلو الآخر، مع الرجوع إلى تلك الحالة المخزنة مؤقتًا دون إعادة قراءة الإدخال.

مرحلة التعبئة المسبقة (Prefill) مكلفة. تتزايد تكلفتها الحسابية بشكل تربيعي مع طول الإدخال: مضاعفة المطالبة (prompt) تضاعف حساب الانتباه أربع مرات. بالنسبة لمطالبة نظام مكونة من 2000 رمز تتم معالجتها مرة واحدة لكل طلب بمعدل 1000 طلب في الساعة، فإن هذا يعني 2 مليون رمز من عمل التعبئة المسبقة في الساعة — كل ساعة، كل يوم.

يزيل التخزين المؤقت للبادئات الجزء الزائد عن الحاجة من هذا العمل. إذا كان الطلب B يشارك بادئة مع الطلب A الذي تمت معالجته مسبقًا، فإن المحرك يعيد استخدام كتل المفاتيح والقيم (KV blocks) المخزنة مؤقتًا لتلك الرموز المشتركة ويحسب فقط اللاحقة الجديدة. تتراكم هذه الوفورات عبر ثلاثة أنماط عمل شائعة:

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

يطبق vLLM التخزين المؤقت للبادئات عبر مطابقة الكتل القائمة على التجزئة (hash-based block matching) — حيث يتم تحديد كل كتلة KV بواسطة تجزئة (hash) الرموز التي أنتجتها. يستخدم SGLang تقنية RadixAttention، وهي شجرة جذرية (radix tree) تجد أطول بادئة مطابقة عبر جميع الطلبات النشطة وتعيد استخدام تلك الكتل مباشرة. في أعباء العمل التي تعتمد بشكل كبير على البادئات، أفادت التقارير أن RadixAttention من SGLang يحقق تحسينات متعددة الأضعاف في الإنتاجية مقارنة بالخدمة غير المدركة للتخزين المؤقت (cache-blind serving)، مع إبلاغ LMSYS عن مكاسب تصل إلى حوالي 5 أضعاف في المعايير التمثيلية. يزيل vLLM، مع تمكين التخزين المؤقت التلقائي للبادئات، غالبية التعبئة المسبقة الزائدة عن الحاجة في أعباء عمل الدردشة متعددة الأدوار.

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

كيف يدمر توجيه التناوب الدوري معدل إصابة ذاكرة التخزين المؤقت

لننظر في نشر بثماني نسخ vLLM خلف خدمة Kubernetes قياسية. تقوم النسخة 1 بمعالجة طلب يحتوي على موجه نظام مكون من 2000 رمز، وتحسب ذاكرة التخزين المؤقت KV، وتخزنها في ذاكرة الفيديو (VRAM) الخاصة بها. يصل الطلب التالي بنفس الموجه. يرسله توجيه التناوب الدوري إلى النسخة 2 — التي لا تحتوي على ذاكرة تخزين مؤقت لتلك البادئة، لذا تعيد حساب التعبئة المسبقة بالكامل من الصفر. يذهب الطلب الثالث إلى النسخة 3. نفس الفشل.

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

في أعباء العمل التي تعتمد بشكل كبير على البادئات، يمكن أن يقلل التوسع الساذج من محلية ذاكرة التخزين المؤقت ويزيد من التعبئة المسبقة الزائدة ما لم يكن التوجيه مدركًا لذاكرة التخزين المؤقت.

الأرقام الإنتاجية صارخة. أجرى مشروع llm-d، وهو إطار عمل الاستدلال الموزع الأصلي لـ Kubernetes من Red Hat، اختبارات أداء للتوجيه المدرك لذاكرة التخزين المؤقت للبادئات مقابل التناوب الدوري على 8 وحدات Pods / 16 وحدة معالجة رسوميات H100 وقاس زمن وصول الرمز الأول أسرع 57 مرة وإنتاجية مضاعفة على نفس الأجهزة. أظهر اختبار أداء منفصل على Llama 3.1 70B عبر 4 وحدات معالجة رسوميات AMD MI300X 3 أضعاف رموز الإخراج/ثانية وتقليل TTFT بمقدار مرتين بعد تبديل استراتيجيات التوجيه. سجلت بوابة الاستدلال الخاصة بـ DigitalOcean، المبنية على نفس المبادئ الأساسية، ما يصل إلى تحسن في الإنتاجية بنسبة 108% للتوجيه المدرك لذاكرة التخزين المؤقت مقابل التوجيه العشوائي في نفس تكوينات الأجهزة.

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

التحدي هو أن محلية ذاكرة التخزين المؤقت النقية وموازنة التحميل النقية تتجهان في اتجاهين متعاكسين. يصبح السؤال حينئذٍ: كيف تحافظ على محلية ذاكرة التخزين المؤقت دون التضحية بموازنة التحميل؟

ثلاثة مستويات للتوجيه المدرك للبادئات

هذه الأساليب مرتبة من الأبسط إلى الأكثر دقة.

المستوى 1 — تقارب الجلسة

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

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

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

المستوى الثاني — توجيه تجزئة البادئة

بدلاً من التجزئة بناءً على مرسل الطلب، قم بالتجزئة بناءً على محتوى الطلب. على وجه التحديد، قم بتجزئة أول N رمز مميز من الموجه — البادئة الثابتة المتطابقة عبر المستخدمين — ووجّه جميع الطلبات ذات تجزئة البادئة نفسها إلى النسخة المتماثلة نفسها.

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

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

المستوى الثالث — التوجيه المدرك لأحداث KV

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

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

هذا هو بشكل عام الهيكل المستخدم بواسطة مكون Endpoint Picker الخاص بـ llm-d، والذي يستخدم معلومات حالة ذاكرة التخزين المؤقت والحمل لتحديد نسخة متماثلة مستهدفة قبل إعادة توجيه الطلب. تكلفة التوجيه نفسها لا تذكر مقارنة بالتوفير في التعبئة المسبقة الذي يتيحه.

متى تتخطى التوجيه المدرك للبادئة

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

التشخيص العملي: قم بقياس معدل نجاح ذاكرة التخزين المؤقت لديك مباشرةً من مقاييس أحداث ذاكرة التخزين المؤقت لـ vLLM أو إحصائيات RadixAttention الخاصة بـ SGLang. إذا ظل معدل النجاح منخفضًا حتى بعد التوجيه المدرك لذاكرة التخزين المؤقت، فافحص بنية الموجه أولاً.

كيف تطبق TrueFoundry التوجيه الثابت لذاكرة التخزين المؤقت KV

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

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

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

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

أفضل الممارسات

• أصلح بنية الموجه قبل تعديل التوجيه. ضع كل المحتوى الثابت — موجه النظام، أمثلة اللقطات القليلة، الأجزاء المسترجعة — في بداية كل موجه. يجب أن يتبع المحتوى المتغير (رسالة المستخدم، معرف الطلب، الطابع الزمني) البادئة الثابتة. حقل ديناميكي واحد في غير مكانه قبل موجه النظام يلغي إمكانية التخزين المؤقت بالكامل، بغض النظر عن استراتيجية التوجيه.
• حدد حدود البادئة الخاصة بك بناءً على عدد الرموز المميزة الفعلي، وليس التخمينات. قسّم موجه النظام النموذجي وكتلة الأمثلة إلى رموز، وعدّ الرموز، واستخدم هذا الحد لتجزئة البادئة. غالبًا ما يقطع الطول الثابت العشوائي في منتصف الجملة داخل المحتوى المتغير أو يفوت المنطقة المستقرة بالكامل.
• ابدأ بالمستوى 2، قم بالقياس، ثم قرر ما إذا كان المستوى 3 يستحق العناء. الانتقال من التوجيه الدوري (round-robin) إلى التوجيه بتجزئة البادئة (prefix-hash routing) يحقق غالبية المكاسب المتاحة بدون بنية تحتية توجيه مخصصة. يستحق المستوى 3 التقييم عندما تقوم بتشغيل نسخ متعددة بتزامن مستمر وتكون أخطاء ذاكرة التخزين المؤقت للبادئة (prefix-cache misses) عنق زجاجة تم قياسه.
• راقب معدل نجاح ذاكرة التخزين المؤقت كتنبيه إنتاجي، وليس مجرد مقياس في لوحة المعلومات. قيام مطور بإضافة حقل ديناميكي بهدوء إلى موجه النظام سيؤدي إلى انخفاض معدل النجاح فورًا. يظهر تراجع زمن الاستجابة قبل أن يتحقق أي شخص من السجلات. قم بتنبيه عند انخفاض معدل النجاح دون خط الأساس المحدد لديك.
• اضبط وزن المحلية (locality weight) لكل نوع حمل عمل، وليس بشكل عام. تستفيد محادثات متعددة الأدوار (Multi-turn chat) وخطوط أنابيب RAG من تفضيل قوي لمحلية ذاكرة التخزين المؤقت (cache-locality). يستفيد الاستدلال الدفعي (Batch inference) على مدخلات متنوعة من موازنة التحميل النقية. إذا كانت بوابتك تخدم حركة مرور مختلطة، قم بتشغيل تكوينات توجيه منفصلة لكل فئة حمل عمل بدلاً من المساومة على كليهما.
• راقب استخدام ذاكرة الفيديو (VRAM) جنبًا إلى جنب مع معدل النجاح. تقوم ذاكرة التخزين المؤقت للبادئة (Prefix caching) بمقايضة ذاكرة وحدة معالجة الرسوميات (GPU) بتوفير التعبئة المسبقة (prefill savings). عند التزامن العالي، تتنافس الكتل المخزنة مؤقتًا مع الطلبات النشطة على ذاكرة الفيديو (VRAM)، مما يؤدي إلى تشغيل إخلاء LRU وانهيار معدلات النجاح. إذا تدهور معدل النجاح تحت الحمل على الرغم من التوجيه الصحيح، فإن ضغط الذاكرة هو السبب المحتمل — اضبط سقف استخدام الذاكرة على محرك الاستدلال قبل افتراض وجود مشكلة في التوجيه.

الخلاصة

بالنسبة لمعظم الفرق، فإن الانتقال من التوجيه الدوري (round-robin) إلى التوجيه بتجزئة البادئة (prefix-hash routing) هو التحسين الأكثر فعالية. يصبح التوجيه الأكثر تعقيدًا المدرك لذاكرة التخزين المؤقت (cache-aware routing) ذا قيمة متزايدة مع نمو حجم الأسطول والتزامن وإعادة استخدام ذاكرة التخزين المؤقت.

تعرف على كيفية تعامل بوابة الذكاء الاصطناعي من TrueFoundry مع التوجيه المدرك للبادئة (prefix-aware routing) جنبًا إلى جنب مع نشر النموذج في لوحة تحكم واحدة → truefoundry.com/ai-gateway