KV Cache للمتوسط: ليه Context طويل في LLM بياكل GPU وازاي تقلله 4x

على Llama 2 70B الأصلي بـ Multi-Head Attention الكامل (64 KV head)، نفس الحساب بيطلع 81.92 GB لـ 32K توكن. ده بيتجاوز سعة A100 80GB لوحده، يعني الموديل أصلًا مش هيتحمّل.

قياس الاستهلاك بكود Python شغّال

الكود ده بيشتغل على Llama 3 8B وبيقيس الـ KV Cache فعليًا لطول contexts مختلفة:

المخرج المتوقع على Llama 3 8B (32 layer، 8 KV heads):

ركز في الرقم الأخير: على موديل 8B، الـ Cache لوحده تجاوز حجم الموديل (16 GB في FP16). على Llama 3 70B هيكون 4x أكتر من ده.

الحلول الأربعة لتقليل الـ KV Cache

1. Multi-Query Attention (MQA)

بدل ما كل attention head يكون له K و V خاصين، كل الـ heads بيشتركوا في زوج K/V واحد بس. التوفير بيوصل 8x لكن الجودة بتفقد محسوسة في موديلات صغيرة، خصوصًا في tasks الـ reasoning الطويل.

الاستخدام: PaLM، Falcon، StarCoder.

2. Grouped Query Attention (GQA)

توازن وسط بين MHA الكاملة و MQA. مجموعة من الـ heads بتشترك في K/V واحد. Llama 3 70B عنده 64 query head لكن 8 KV heads فقط — توفير 8x. الجودة بتفقد 0.3% إلى 0.7% بس على MMLU benchmark، وده مقبول جدًا في 99% من الحالات.

الاستخدام: Llama 3، Mixtral، Qwen 2.5، DeepSeek-V3.

3. PagedAttention (vLLM)

المشكلة الأساسية في الـ Cache التقليدي إنه بيحجز ذاكرة متصلة (contiguous) بطول max_context لكل request، حتى لو الـ request الفعلي 200 توكن بس. PagedAttention بياخد فكرة Virtual Memory من الـ OS: بيقسم الـ Cache لـ blocks صغيرة (16 توكن لكل block)، وبيحجز Block على الطلب. التوفير بيوصل 60% إلى 80% في scenarios متعدد المستخدمين.

على إنتاج فعلي بـ 100 user متوازي على نفس الـ GPU، الفرق بيكون: throughput من 14 req/s لـ 47 req/s — تحسن 3.4x.

4. KV Cache Quantization

تخزين الـ K و V بـ INT8 أو INT4 بدل FP16. بيوفر 2x إلى 4x في الذاكرة بفقد جودة أقل من 1% لو استخدمت per-channel quantization مع HQQ backend.

الـ Trade-offs الحقيقية

• MQA: توفير 8x في الذاكرة، خسارة 1% إلى 2% في accuracy على tasks reasoning. الافتراض إن الموديل أكبر من 13B parameter — على موديلات أصغر الخسارة بتكبر.
• GQA: توفير 4x إلى 8x، خسارة 0.3% إلى 0.7% بس. الأكثر استخدامًا في 2026 وافتراضي في معظم موديلات SOTA.
• PagedAttention: توفير 60% إلى 80% في الـ multi-user serving، لكن في single-user inference بيضيف overhead بدون فايدة. بيحتاج vLLM (مش بيشتغل في raw transformers).
• KV Quantization: توفير 2x إلى 4x، بس latency إضافي 5% إلى 15% بسبب dequantization. ممكن يضرّ بـ long-context retrieval لو نزلت لـ INT4 بدون testing.

متى لا تستخدم هذه التقنيات

لو الـ context بتاعك أقل من 4K توكن وعندك GPU بـ 24GB، الـ KV Cache مش هيتعدى 1GB حتى على Llama 3 70B. المشكلة دي أصلاً غير موجودة عندك. ركّز في تحسينات تانية أهم زي batching، speculative decoding، أو quantization على الموديل نفسه.

كذلك لو بتشتغل على single-user inference (مش API serving)، الـ PagedAttention بيضيف complexity مش لازم. استخدم vanilla generation أو llama.cpp.

لو الموديل بتاعك صغير (أقل من 7B parameter)، KV quantization لـ INT4 ممكن يضرّ الجودة بشكل ملحوظ — اختبر دايمًا قبل ما تنزل لـ INT4.

الخطوة التالية

لو بتشغّل LLM في إنتاج بـ contexts طويلة:

1. قيس الاستهلاك الحالي بالكود في الأعلى — اعرف هل الـ KV Cache فعلاً المشكلة ولا حاجة تانية.
2. لو الـ Cache بيتعدى 30% من ذاكرة GPU، انقل لـ vLLM مع --enable-prefix-caching. ده الحل الأسرع تطبيقًا.
3. لو لسه مش كافي، فعّل KV quantization بـ INT8 أولًا (متجربش INT4 قبل ما تختبر الجودة على dataset حقيقي عندك).
4. لو الموديل عندك بـ MHA كاملة، فكر في الـ migrate لموديل بـ GQA (Llama 3 70B، Qwen 2.5 72B، Mixtral). الانتقال ده غالبًا بيحل المشكلة بدون تعقيد إضافي.

المصادر

• Ainslie et al. "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints" — EMNLP 2023.
• Shazeer "Fast Transformer Decoding: One Write-Head is All You Need" — ورقة MQA الأصلية، 2019.
• Kwon et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention" — SOSP 2023.
• Meta Llama 3 Model Card — التوثيق الرسمي لـ 8 KV heads على 70B.
• HuggingFace Transformers documentation: KV Cache Quantization guide.
• vLLM official documentation — docs.vllm.ai.
• Badri & Shaji "Half-Quadratic Quantization (HQQ)" — Mobius Labs technical report، 2024.