شرح KV cache: كيف تسرّع التوليد وتخفّض تكلفة المدخلات؟

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

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

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

ما هي KV cache، وما الذي تحتفظ به من الطلب السابق؟

KV cache هي حالة الانتباه المحفوظة. والانتباه هو الآلية التي يستخدمها نموذج المحوّل لاستحضار المعلومات السابقة ذات الصلة عند حساب التنبؤ الحالي. فالرمز، وهو وحدة من النص أو من مدخلات النموذج الأخرى، ينتج تمثيلات عددية داخل كل طبقة انتباه. وتحتفظ الذاكرة المؤقتة بمفاتيح تلك الطبقة وقيمها لاستخدامها لاحقًا. يشرح دليل Hugging Face للذاكرة المؤقتة هذا التخزين على مستوى كل طبقة.

لتوضيح الأدوار الثلاثة في الانتباه، يمكن تشبيهها بمكتبة بحثية:

• الاستعلام يعبّر عما يبحث عنه الموضع الحالي.
• المفتاح يتيح مطابقة موضع سابق مع الاستعلام.
• القيمة توفر المعلومات التي يمكن أن تسهم بها المطابقة.

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

يُقارَن الاستعلام الحالي بالمفاتيح السابقة، ثم تُستخدم أوزان الانتباه الناتجة لدمج قيمها. وفي المحوّل السببي، لا تستطيع المواضع السابقة الاطلاع على ما يأتي بعدها. لذلك لا تستلزم إضافة رمز لاحق تغيير الحالات التي حُسبت بالفعل للمواضع السابقة، وهذا ما يجعل إعادة استخدامها صحيحة. تصف ورقة PagedAttention الأصلية حسابات الانتباه هذه وعملية التوليد.

ومن هنا أيضًا يتضح لماذا تحتفظ الذاكرة المؤقتة المعتادة بالمفاتيح K والقيم V، بدلًا من حفظ كل استعلام سابق. فالتنبؤ التالي يحتاج إلى الاستعلام الحالي والمفاتيح والقيم المتراكمة؛ أما الاستعلامات السابقة فقد أدت وظيفتها.

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

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

كيف تعمل KV cache في مرحلتي Prefill وDecode؟

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

يمكن وصف مسار العمل في محوّل تقليدي ذاتي الانحدار على النحو التالي:

Prefill: رموز الموجّه → معالجة الموجّه → الاحتفاظ بالمفاتيح والقيم لكل طبقة → التنبؤ بأول رمز في المخرجات.

Decode: أحدث رمز مولّد + المفاتيح والقيم المحفوظة → معالجة ذلك الرمز والانتباه إلى السياق → التنبؤ بالرمز التالي؛ وإلحاق المفاتيح والقيم المحسوبة حديثًا.

تكرار Decode: إعادة استخدام الذاكرة المؤقتة المتنامية حتى ينتهي التوليد.

تستطيع مرحلة Prefill معالجة مواضع الموجّه المعروفة معًا. أما Decode فتتقدم في تتمة لم تُختَر رموزها اللاحقة بعد. يرد هذا التمييز في شرح مسار التوليد والتنفيذ في ورقة PagedAttention.

تقلل KV cache تكلفة الرمز التالي مقارنة بإعادة حساب البادئة كاملة. لكنها لا تجعل تكلفته مستقلة عن طول السياق. ففي الانتباه الكامل التقليدي، يظل استعلامه يتفاعل مع المفاتيح والقيم المحفوظة. وكلما زاد السياق المحتفَظ به، زادت بيانات الانتباه التي ينبغي استخدامها. توثّق Hugging Face عمل الانتباه الذي يبقى مطلوبًا في كل خطوة.

ومن المهم هنا التمييز بين نوعين من إعادة الاستخدام. داخل الاستجابة الواحدة، يمنع تخزين KV مؤقتًا تكرار الحساب أثناء التوليد. أما بين الطلبات، فإن تخزين البادئة مؤقتًا، الذي يُسمّى أيضًا تخزين الموجّهات مؤقتًا أو prompt caching في واجهات API المستضافة، يحتفظ بالحالات المؤهلة كي يتجاوز استدعاء لاحق جزءًا من عمل Prefill. ووجود معرّف للمحادثة وحده لا يثبت أن تلك الحالات متاحة.

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

لمن يبني تطبيقًا يعتمد على API، يعني ذلك ضرورة فحص كل من زمن الانتظار قبل أول رمز والوقت المستغرق في توليد الاستجابة. فتحسّن زمن أول رمز لا يثبت أن Decode أصبحت أسرع. وتفصل وثائق Automatic Prefix Caching في vLLM صراحةً بين التوفير في Prefill وزمن Decode.

كيف ينعكس العمل المعاد استخدامه على فاتورة المدخلات؟

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

في واجهات API التي تميّز بين المدخلات العادية والكتابة إلى الذاكرة المؤقتة والقراءة منها، يمكن حساب جزء المدخلات كما يلي:

تكلفة المدخلات = (U × p_input + W × p_write + R × p_read) / 1,000,000

هنا تمثّل U رموز المدخلات العادية، وتمثّل W الرموز التي تُحتسب ككتابة إلى الذاكرة المؤقتة، وتمثّل R الرموز التي تُحتسب كقراءة منها. وكل p هو سعر الفئة المعنية لكل مليون رمز. ويجب ألا تتداخل الفئات: فلا تُحتسب تكلفة رمز الكتابة مرة أخرى بسعر المدخلات العادية. هذا حساب قائم على وحدات الكمية والسعر باستخدام فئات التسعير لدى OpenAI وAnthropic.

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

Anthropic: حدّد البادئة القابلة لإعادة الاستخدام

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

مثال للأسعار في Claude API القياسية: تبلغ تكلفة مدخلات Claude Sonnet 5.5 $2، والقراءة من الذاكرة المؤقتة $0.10، والكتابة لمدة 5 دقائق $2.50، والكتابة لمدة 1 ساعة $4، وجميعها لكل مليون رمز. أسعار Anthropic.

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

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

OpenAI: راجع قواعد الكتابة الخاصة بالنموذج

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

مثال للأسعار ضمن فئة Standard للسياق القصير: تبلغ تكلفة مدخلات GPT-6.1 Sol $2.00، والمدخلات المخزنة مؤقتًا $0.10، والكتابة إلى الذاكرة المؤقتة $2.50 لكل مليون رمز؛ وتتضاعف أسعار المدخلات والتخزين المؤقت للطلب بأكمله عندما يتجاوز 272K رمز إدخال. أسعار OpenAI، حدّ النموذج.

في GPT-5.6 وما بعده، يبلغ الحد الأدنى 1,024 رمز إدخال ظاهرًا، وتبلغ مدة الاحتفاظ الموثقة 30 دقيقة على الأقل بعد آخر كتابة أو إعادة استخدام. يحلّ سعر الكتابة إلى الذاكرة المؤقتة محلّ سعر المدخلات العادية لتلك الرموز؛ ولا يعني فرض فاتورة ثانية على المدخلات كاملة. وللنماذج الأقدم قواعد مختلفة للكتابة والاحتفاظ. قواعد التخزين المؤقت الحالية.

في Responses API، افحص usage.input_tokens_details.cached_tokens وcache_write_tokens. فالإبقاء على الجلسة لا يضمن الاستفادة من الذاكرة المؤقتة. ارجع إلى دليل تشخيص تخزين الموجّهات مؤقتًا في GPT-6 على الموقع عندما تحتاج إلى فحص ترتيب محتوى الطلب وبيانات الاستخدام المُبلّغ عنها.

Google Gemini: إعادة الاستخدام الضمنية تختلف عن التخزين الصريح

توفّر Google Gemini تخزينًا مؤقتًا ضمنيًا وتلقائيًا، وتنعكس وفوراته على الفاتورة عند نجاح إعادة الاستخدام. وفي مثال Gemini 3.8 Flash، يبلغ الحد الأدنى الموثق 4,096 رمز إدخال. ويزيد احتمال إعادة الاستخدام عندما يأتي المحتوى المشترك في البداية وتتقارب الطلبات زمنيًا. دليل Google لتخزين السياق مؤقتًا.

مثال للأسعار في الفئة المدفوعة Standard من Gemini Developer API: تبلغ تكلفة مدخلات Gemini 3.8 Flash $0.75، والمدخلات المخزنة مؤقتًا $0.075 لكل مليون رمز، مع رسوم تخزين صريح تبلغ $0.50 لكل مليون رمز في الساعة، وذلك حتى 31 ديسمبر 2026. أسعار Google.

يستخدم التخزين المؤقت الصريح موردًا مسمّى للمحتوى المخزن، مع إعداد لانتهاء الصلاحية، وتشير إليه طلبات generateContent اللاحقة. وبسبب رسوم التخزين، قد يظل الاحتفاظ بمستند غير مستخدم يكلّف مالًا. مرجع Google لواجهة التخزين المؤقت.

اختيار واجهة API مهم: تدعم Interactions API التخزين المؤقت الضمني فقط. ويستثني دليل Google الحالي أيضًا Gemini 4 Argon وما بعده من التخزين المؤقت الصريح؛ أما نماذج Gemini 3 و2.5 المدعومة فتستخدم generateContent لهذا النوع من التخزين. وفي Interactions API، افحص usage.total_cached_tokens كما يوضح الدليل. قواعد Google الخاصة بكل واجهة API.

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

حجم KV cache يزداد كلما طال السياق المحتفَظ به

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

عندما تكون التسلسلات متساوية الطول، وأبعاد طبقات الانتباه موحّدة:

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2: مصفوفة للمفاتيح وأخرى للقيم.
• B: عدد التسلسلات المتزامنة، بافتراض أنها لا تشترك في بيانات الذاكرة المؤقتة.
• T: عدد الرموز المعالجة والمحتفَظ بها لكل تسلسل، بما فيها رموز الموجّه والرموز المولّدة.
• L: عدد طبقات الانتباه التي تحتفظ بهذا النوع من الذاكرة المؤقتة.
• H_kv: عدد رؤوس المفاتيح والقيم في كل طبقة.
• D: عدد القيم العددية في كل رأس.
• S: عدد البايتات المستخدمة لتخزين كل قيمة عددية.

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

عدد الرؤوس عامل مهم. ففي انتباه الاستعلامات المجمّعة، حيث تشترك عدة رؤوس استعلام في رؤوس المفاتيح والقيم، يجب استخدام عدد رؤوس KV في المعادلة. وإحلال عدد رؤوس الاستعلام الأكبر محلّه سيؤدي إلى المبالغة في تقدير حجم الذاكرة المؤقتة.

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

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

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

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

تحسين KV cache في vLLM

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

PagedAttention: خصّص الكتل مع نمو المحادثة

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

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

لا يقلل تقسيم الذاكرة إلى صفحات، بحد ذاته، المعلومات المخزنة لكل رمز. بل يحسّن طريقة استيعابها داخل الذاكرة المتاحة. كذلك تصف vLLM صفحة نواة Paged Attention بأنها توثيق تاريخي؛ استفد من الفكرة من دون اعتبار وصف النواة القديم تمثيلًا للتنفيذ الحالي.

تخزين البادئة مؤقتًا: تجاوز العمل المشترك مع طلب سابق

تعيد ميزة Automatic Prefix Caching استخدام حالة KV لبادئة مطابقة. وتوثّق vLLM الإعداد enable_prefix_caching=True؛ وهذه هي الميزة المناسبة عندما تبدأ الأسئلة المتكررة عن مستند، أو جولات الوكيل، بالمحتوى نفسه. Automatic Prefix Caching.

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

لكن حدود الاستفادة يحددها حمل العمل: فالموجّهات غير المترابطة لا تشترك في كثير من العمل، وقد تظل مرحلة Decode تستحوذ على معظم وقت الإجابات الطويلة. وإذا كنت تختار محرك التشغيل نفسه، فتتناول مقارنة vLLM وSGLang هذا القرار الأوسع.

تكميم KV cache: بايتات أقل لكل قيمة مخزنة

يقلل تكميم KV cache الدقة المستخدمة في القيم العددية المخزنة مؤقتًا. تدعم vLLM التخزين بدقة FP8 عبر kv_cache_dtype="fp8"، وتوصي بمعايرة عوامل القياس باستخدام مجموعة بيانات للحفاظ على الجودة. وتعتمد الخيارات المتاحة على مكوّن تنفيذ الانتباه المستخدم. وثائق الذاكرة المؤقتة المكمّمة في vLLM.

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

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

ضغط KV cache: فرّق بين دقة القيم والمحتوى المحتفَظ به

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

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

ترحيل KV cache: الاحتفاظ بحالة أكبر مقابل نقل البيانات

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

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

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

أين تكمن المبالغة في الاحتفاء بنجاح إعادة الاستخدام؟

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

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

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

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

أسئلة شائعة عن KV cache في النماذج اللغوية الكبيرة

هل يستخدم ChatGPT ذاكرة KV cache؟

توثّق OpenAI تخزين الموجّهات مؤقتًا اعتمادًا على KV في واجهات API الخاصة بها. يوضح ذلك طريقة عمل الميزة في API العامة، لكنه لا يكشف كل تفاصيل البنية الداخلية لتشغيل ChatGPT. عند بناء تطبيق، اعتمد على قواعد التخزين المؤقت المنشورة وحقول الاستخدام الخاصة بالنموذج الذي اخترته عبر API. وثائق OpenAI.

هل ينبغي ترحيل KV cache إلى ذاكرة وحدة معالجة الرسومات؟

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

ماذا يحدث عندما تمتلئ KV cache؟

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

كيف أقلّل حجم KV cache؟

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

ثلاث عادات ترفع استفادة الوكيل من الذاكرة المؤقتة

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

1. 1

   ضع موجّه النظام الثابت في البداية

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

2. 2

   أضف إلى السجل بدلًا من إعادة كتابته

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

3. 3

   أبعد الطوابع الزمنية عن البداية

   ضع الوقت الحالي ومعرّف الطلب وغيرهما من البيانات الوصفية المتغيرة بعد المواد القابلة لإعادة الاستخدام. فقد يُبطل طابع زمني في البداية إعادة استخدام السياق الذي يليه. وعند استخدام نقاط فصل صريحة، حدّد نهاية البادئة الثابتة قبل الجزء المتغير في آخر الطلب. إرشادات نقاط الفصل لدى Anthropic.

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

اشترك في النشرة البريدية لتصلك شروحات عملية للأنظمة التي يعتمد عليها وكلاء الذكاء الاصطناعي.