DeepSeek وGoogle وMeta: 10 تقنيات لضغط KV-cache في نماذج LLM لخفض استهلاك الذاكرة أثناء الاستدلال
أصبح KV-cache منذ وقت طويل القيد الرئيسي على تشغيل نماذج LLM ذات السياق الطويل، ولم يعد الباحثون يقترحون طريقة واحدة لضغطه، بل عشر طرق عملية. ويجمع التقرير أساليب H2O وSnapKV وKIVI وTurboQuant وGQA، إضافة إلى MLA من DeepSeek، وهي تمتد من الاستغناء البسيط عن بعض الرموز (tokens) إلى معماريات تقلّص استهلاك الذاكرة بعشرات النسب المئوية وتسرّع الاستدلال. ويعمل جزء كبير من هذه الطرق مباشرة في مرحلة الاستدلال، فلا تحتاج إلى إعادة تدريب النموذج الأساسي، ويظهر أثرها فورًا في الإنتاجية وتكلفة التشغيل. وتختلف الأساليب في موضعها من خط المعالجة: فبعضها يحذف الرموز الأقل فائدة، وبعضها يخفّض دقة تمثيل الكاش، وبعضها يغيّر بنية attention نفسها. والخلاصة لفرق بناء خدمات الاستدلال أن الكسب لم يعد يأتي من تقنية سحرية واحدة، بل من اختيار مدروس بين الحذف (eviction) والكمّية (quantization) والمعمارية بما يناسب الحمل المحدد واتفاقية مستوى الخدمة (SLA) وميزانية GPU.
معالج بواسطة الذكاء الاصطناعي من MarkTechPost؛ بتحرير Hamidun News
تحوّل KV-cache من عنصر مساعد إلى أحد أبرز القيود على الاستدلال الإنتاجي لنماذج LLM. ويجمع تقرير جديد 10 تقنيات تساعد على خفض استهلاك الذاكرة دون إعادة تدريب النموذج بالكامل، وتسرّع التوليد بشكل ملحوظ في بعض الحالات.
أين تصطدم نماذج LLM بالحدود؟
كلما طال السياق وزاد عدد الطلبات المتزامنة التي يخدمها النموذج، تضخّم KV-cache بسرعة. وهو مخزن وسيط للمفاتيح والقيم في آلية attention. ويورد التقرير مثالًا دالًّا: في نموذج بـ30 مليار معامل، وعند batch size يساوي 128 ومدخل من 1024 رمزًا، قد يشغل KV-cache ما يصل إلى 180 غيغابايت من الذاكرة. وحتى في نموذج 7B تشغل الأوزان نحو 14 غيغابايت من ذاكرة GPU، بينما يشغل الكاش نحو 72 غيغابايت. أي أن آلية التوليد نفسها باتت أغلى من تخزين المعاملات.
ولهذا أصبح تحسين KV-cache اتجاهًا قائمًا بذاته، لا مجرد ضبط ثانوي. فإذا ضُغط الكاش، يمكن رفع batch size وخدمة مستخدمين أكثر على GPU نفسه، وتفادي الاصطدام بحدود الذاكرة مع المطالبات الطويلة. ومن المزايا المهمة أن جزءًا كبيرًا من الطرق يعمل مباشرة في مرحلة الاستدلال: فلا حاجة إلى إعادة تدريب النموذج الأساسي، ويظهر الأثر فورًا في الإنتاجية وتكلفة التشغيل (serving).
كيف يُضغط؟
يستخدم الباحثون حاليًا عدة استراتيجيات، وهي تختلف في الجودة وفي موضعها داخل خط المعالجة (pipeline). فبعض الطرق يحذف الرموز الأقل فائدة، وبعضها يخفّض دقة تمثيل الكاش، وبعضها يغيّر معمارية attention نفسها. وهناك فئة مستقلة توزّع الذاكرة بين الطبقات، لأن الطبقات الأولى تحتاج إلى سياق أغنى، بينما تستطيع الطبقات العميقة العمل بمجموعة أصغر من المفاتيح والقيم. وعمليًا لم يعد الحديث عن نسب توفير فحسب، بل عن إمكانية تشغيل سياق طويل على العتاد نفسه.
- حذف الرموز: تحتفظ H2O وStreamingLLM وSnapKV بجزء فقط من الحالات. تُبقي H2O على الرموز «الثقيلة» ذات المساهمة العالية في attention، وتُبقي StreamingLLM على الرموز الأولى ونافذة حديثة، بينما تختار SnapKV المواضع المهمة بحسب attention في نهاية المطالبة (prompt).
- توزيع الميزانية حسب الطبقات: تنطلق PyramidKV وPyramidInfer من أن الطبقات العميقة لا تحتاج إلى سياق بغنى الطبقات الأولى، ولذلك تُخصَّص الذاكرة بشكل غير متساوٍ.
- الكمّية (Quantization): تخفّض KIVI وKVQuant وTurboQuant دقة تمثيل KV-cache، مع محاولة عدم خسارة جودة التوليد.
- تغييرات معمارية: تقلّص MQA وGQA وMLA حجم الكاش على مستوى مخطط attention نفسه، لا فوق نموذج جاهز.
- الضغط منخفض الرتبة: تقلّص Palu وLoRC والطرق المشابهة البُعد الكامن لموترات KV، لا طول التسلسل.
وأسهل الطرق تشغيلًا هي تلك التي لا تحتاج إلى إعادة تدريب. تحدد H2O الرموز التي تستقطب معظم attention وتحذف المواضع الضعيفة. وتُبقي StreamingLLM على الرموز الأولى بوصفها «مراسي انتباه» مع نافذة حديثة، ولذلك تناسب المحادثات اللامتناهية، لكنها تخاطر بفقدان مقطع مهم من المنتصف. أما SnapKV فتعمل في مرحلة prefill وتنتقي المواضع المهمة لكل رأس attention على حدة، ولذلك تتفوق عادةً على الأساليب الأخشن عند حد الكاش نفسه.
كثيرًا ما يشبه توزيع أوزان attention قانونًا أُسّيًّا، ولذلك فإن حذف
الرموز ذات المساهمة المنخفضة لا يضرّ بالجودة بشدة دائمًا.
من يحقق أفضل مكسب؟
في مجال الكمّية تبرز بوضوح KIVI وKVQuant وTurboQuant. تحوّل KIVI الكاش إلى تمثيل بدقة 2 بت دون fine-tuning، وبحسب بيانات التقرير تخفّض ذروة استهلاك الذاكرة حتى 2,6 مرة في مجموع «الأوزان زائد الكاش»، كما تتيح تشغيل دفعات أكبر بما يصل إلى أربعة أضعاف. وتذهب KVQuant أبعد، إذ تستخدم المعايرة والدقة المختلطة ومعالجة منفصلة للقيم الشاذة للحفاظ على الجودة حتى مع السياقات الطويلة جدًا.
وأجرأ نتيجة في المادة تُنسب إلى TurboQuant من Google Research. تبدأ هذه الطريقة بتسوية توزيع القيم عبر دوران متعامد عشوائي، ثم تصحّح خطأ الكمّية بحيث يبقى تقدير الجداءات القياسية غير متحيز. وعلى H100 تُظهر الطريقة خفضًا للذاكرة بمقدار 6 أضعاف على الأقل، وattention أسرع حتى 8 مرات عند دقة 3 بت. وبالنسبة لفرق البنية التحتية، لم يعد هذا تحسينًا موضعيًا، بل ادعاءً بمعيار جديد للتشغيل (serving).
وثمة مسار مستقل هو تغيير معمارية النموذج نفسها. أصبح GQA عمليًا هو القاعدة في نماذج LLM الحديثة مفتوحة الأوزان: ففي Llama 2 لم يُستخدم إلا في نسخة 70B، أما في Llama 3 فانتشر في نسختَي 8B و70B. وتذهب MLA من DeepSeek أبعد، إذ تخزّن بدل المفتاح والقيمة كاملَي الحجم لكل رمز تمثيلًا كامنًا مضغوطًا. ويذكر التقرير أن DeepSeek-V2 خفّض بفضل MLA حجم KV-cache بنسبة 93,3% قياسًا بنموذجه الكثيف السابق 67B.
ماذا يعني هذا؟
يتراجع اعتماد سوق LLM على حجم الأوزان وحده، ويزداد اعتماده على كلفة الذاكرة في السياق الطويل. والخلاصة بسيطة للفرق التي تبني خدمات الاستدلال: لم يعد الكسب يأتي من تقنية سحرية واحدة، بل من اختيار مدروس بين الحذف (eviction) والكمّية والمعمارية بما يناسب الحمل المحدد واتفاقية مستوى الخدمة (SLA) وميزانية GPU.
- 29 أكتوبر 2026RefactorProof: براهين LLM تنهار بعد إعادة هيكلة الكود
- 29 أكتوبر 2026Cohere ترصد Qwen3.8-Flash-Next وهو يحاول إرسال ملف إلى بكين
- 28 أكتوبر 2026AdaPRA يرفع أداء Qwen 80B بمقدار 24,5 نقطة في لوحات صدارة علم البيانات
- 28 أكتوبر 2026Keystone تُخرج اسم النموذج من الشيفرة: بوابة LLM مفتوحة المصدر تضيف 0.64 مللي ثانية فقط
أسئلة وأجوبة حول الخبر
أين تصطدم نماذج LLM بالحدود؟
كلما طال السياق وزاد عدد الطلبات المتزامنة التي يخدمها النموذج، تضخّم KV-cache بسرعة. وهو مخزن وسيط للمفاتيح والقيم في آلية attention. ويورد التقرير مثالًا دالًّا: في نموذج بـ30 مليار معامل، وعند batch size يساوي 128 ومدخل من 1024 رمزًا، قد يشغل KV-cache ما يصل إلى 180 غيغابايت من الذاكرة. وحتى في نموذج 7B تشغل الأوزان نحو 14 غيغابايت من ذاكرة GPU، بينما يشغل الكاش نحو 72 غيغابايت. أي أن آلية التوليد نفسها باتت أغلى من تخزين المعاملات. ولهذا أصبح تحسين KV-cache اتجاهًا قائمًا بذاته، لا مجرد ضبط ثانوي. فإذا ضُغط الكاش، يمكن رفع batch size وخدمة مستخدمين أكثر على GPU نفسه، وت
كيف يُضغط؟
يستخدم الباحثون حاليًا عدة استراتيجيات، وهي تختلف في الجودة وفي موضعها داخل خط المعالجة (pipeline). فبعض الطرق يحذف الرموز الأقل فائدة، وبعضها يخفّض دقة تمثيل الكاش، وبعضها يغيّر معمارية attention نفسها. وهناك فئة مستقلة توزّع الذاكرة بين الطبقات، لأن الطبقات الأولى تحتاج إلى سياق أغنى، بينما تستطيع الطبقات العميقة العمل بمجموعة أصغر من المفاتيح والقيم. وعمليًا لم يعد الحديث عن نسب توفير فحسب، بل عن إمكانية تشغيل سياق طويل على العتاد نفسه. حذف الرموز: تحتفظ H2O وStreamingLLM وSnapKV بجزء فقط من الحالات. تُبقي H2O على الرموز «الثقيلة» ذات المساهمة العالية في attention، وتُبق
من يحقق أفضل مكسب؟
في مجال الكمّية تبرز بوضوح KIVI وKVQuant وTurboQuant. تحوّل KIVI الكاش إلى تمثيل بدقة 2 بت دون fine-tuning، وبحسب بيانات التقرير تخفّض ذروة استهلاك الذاكرة حتى 2,6 مرة في مجموع «الأوزان زائد الكاش»، كما تتيح تشغيل دفعات أكبر بما يصل إلى أربعة أضعاف. وتذهب KVQuant أبعد، إذ تستخدم المعايرة والدقة المختلطة ومعالجة منفصلة للقيم الشاذة للحفاظ على الجودة حتى مع السياقات الطويلة جدًا. وأجرأ نتيجة في المادة تُنسب إلى TurboQuant من Google Research. تبدأ هذه الطريقة بتسوية توزيع القيم عبر دوران متعامد عشوائي، ثم تصحّح خطأ الكمّية بحيث يبقى تقدير الجداءات القياسية غير متحيز. وعلى H100
ماذا يعني هذا؟
يتراجع اعتماد سوق LLM على حجم الأوزان وحده، ويزداد اعتماده على كلفة الذاكرة في السياق الطويل. والخلاصة بسيطة للفرق التي تبني خدمات الاستدلال: لم يعد الكسب يأتي من تقنية سحرية واحدة، بل من اختيار مدروس بين الحذف (eviction) والكمّية والمعمارية بما يناسب الحمل المحدد واتفاقية مستوى الخدمة (SLA) وميزانية GPU.
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.