لو بتستضيف LLM في production وبتدفع في فاتورة GPU أكثر من 3000 دولار شهريًا، الخبر ده ممكن يخصم منها 40% قبل آخر السنة. Google Research نزّلت ورقة TurboQuant وهتعرضها في ICLR 2026 يوم 25 أبريل، وبتقول إنك تقدر تضغط الـ KV cache 6 أضعاف بدون ما تخسر دقة النموذج.
TurboQuant: ضغط KV cache 6× لتشغيل LLMs أسرع وأرخص
المشكلة باختصار
لما بتشغّل نموذج زي Llama 3 70B أو Qwen 2.5 72B على GPU، وزن النموذج نفسه مش هو اللي بياكل معظم الذاكرة بعد فترة. اللي بياكلها هو الـ KV cache: Key-Value cache بيخزن كل توكن عدّى على النموذج علشان ميعيدش حسابه في كل خطوة توليد جديدة. مع context طويل (32K أو 128K توكن)، الـ KV cache بيوصل لـ 40–80% من ذاكرة الـ GPU كلها.
ده بيترجم لحاجتين مباشرة: GPUs إضافية لتشغيل نفس عدد الطلبات، وتكلفة أعلى لكل 1000 طلب بسبب batching أقل.
نبدأ بمثال بسيط جدًا
تخيّل إنك بتكتب جملة طويلة على كيبورد، وبعد كل حرف بتعيد قراءة الجملة كلها من أولها علشان تعرف الحرف اللي بعده. ده بطيء فظيع. فتقرر بدل كده تحتفظ في ورقة جنبك بكل حرف كتبته مع معناه، وكل ما تحتاج تكتب حرف جديد تبص بسرعة في الورقة بس. ده بالظبط الـ KV cache.
المشكلة: الورقة دي بتكبر مع كل حرف. في سياق 128K توكن، الورقة بقت كتالوج كامل بياكل مساحة المكتب كلها. TurboQuant بيقولك: "بدل ما تخزن كل حرف بـ 16 بت، خزّنه بـ 3 بت بس، ومش هتفرق في المعنى". الضغط ده هو اللي بيوفّر 6× من الذاكرة.
TurboQuant يشتغل إزاي بالظبط
الورقة (arXiv:2504.19874) بتعتمد على خطوتين متسلسلتين في الـ inference:
- Keys بتتضغط بـ rotation-based vector quantization. كل متجه مفتاح بيتقسم لحجم (scalar) واتجاه (direction) على كرة وحدوية، والاتجاه بيتضغط باستخدام كتالوج نقاط متساوية التوزيع. ده اسمه PolarQuant في الورقة الأصلية.
- Values بتتضغط بـ scalar quantization أبسط، لأن توزيعها أقل تطرفًا من الـ keys فـ quantization عادي بيكفي.
الأهم من كل ده: الطريقة training-free. مش محتاج تدريب إضافي ولا calibration data. بتشتغل على أي LLM قياسي (Llama, Qwen, Mistral, Gemma) من غير ما تلمس الأوزان نفسها. ده بالظبط اللي بيخليها عملية.
الأرقام الحقيقية من الورقة
- 3.5-bit TurboQuant بيتطابق مع الدقة الكاملة (FP16) على MMLU و HellaSwag و GSM8K بفارق أقل من 0.5 نقطة.
- 4-bit TurboQuant بيدي 8× تسريع في حساب attention logits على H100 مقارنة بـ 32-bit keys (حوالي 4× مقارنة بـ FP16 المستخدم فعليًا في الإنتاج).
- سعة KV cache بتقل من 16 بت إلى 3 بت لكل قيمة = 5.3× ضغط نظري، 6× عمليًا بعد padding alignment على الـ GPU.
ترجمة التأثير لـ workload واقعي: GPU واحد H100 80GB شغّال Llama 3 70B على context 32K كان بيخدم 12 طلب متوازي بتكلفة حوالي 2.4 دولار للساعة. مع TurboQuant 4-bit على نفس الكرت، ممكن يوصل لـ 70+ طلب متوازي. التكلفة لكل 1000 طلب بتنزل من حوالي 0.034 دولار لحوالي 0.006 دولار. ده مش كسر في الاقتصاد، ده تغيير شكل الـ deployment بالكامل.
