Google تكشف عن TurboQuant: ضغط ذاكرة KV-cache في نماذج LLM بمقدار 6 أضعاف دون فقدان الدقة

قدّم Google Research خوارزمية TurboQuant لضغط KV-cache في النماذج اللغوية الكبيرة، وهي خوارزمية يُفترض أن تزيل أحد أبرز القيود التي تواجه السياق الطويل. وبحسب الشركة، يقلّص الأسلوب استهلاك الذاكرة 6 أضعاف على الأقل، ويسرّع حساب attention في بعض الإعدادات حتى 8 أضعاف دون فقدان في الجودة على المهام الاختبارية.

لماذا يُبطئ KV-cache النماذج؟

عندما يعمل نموذج LLM مع سياق طويل، يخزّن المفاتيح والقيم الوسيطة في KV-cache حتى لا يعيد حسابها من جديد مع كل token. يوفّر ذلك عمليات حسابية، لكنه يصطدم سريعًا بحدود الذاكرة: فكلما كبر النموذج وطال الحوار أو المستند، ازداد حجم الكاش بشكل أكبر. ونتيجة لذلك لا تقتصر الاختناقات على وحدة GPU نفسها، بل تشمل أيضًا تبادل البيانات بين ذاكرة SRAM السريعة وذاكرة HBM. وهذا مؤلم بوجه خاص في مرحلة inference، لأن الطلبات الطويلة تصبح أغلى بوضوح من حيث زمن الاستجابة (latency) والعتاد معًا.

تشبّه

Google الـ KV-cache بـ«ورقة غش رقمية فائقة السرعة» يستخدمها النموذج بدلًا من إعادة الحساب.

تحلّ الكمّنة (quantization) التقليدية جزءًا من المشكلة، لكن لها أثرًا جانبيًا: فإلى جانب البيانات المضغوطة، يجب تخزين ثوابت إضافية خاصة بالكمّنة. وتلتهم هذه البتات الزائدة جزءًا من المكسب، خصوصًا حين يتعلق الأمر بمليارات القيم داخل سياق طويل. وعلى هذه النقطة تحديدًا تبني Google خوارزمية TurboQuant: فالفكرة ليست ضغط المتجهات بقوة أكبر فحسب، بل التخلص من الحمل الإضافي (overhead) الذي يمنع تحقيق توفير فعلي في الذاكرة.

كيف تعمل TurboQuant؟

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

ثم تأتي الطبقة الثانية: Quantized Johnson-Lindenstrauss أو QJL. تأخذ هذه الطبقة الخطأ المتبقي بعد المرحلة الأولى وترمّزه ببت إضافي واحد، بحيث يزول الانحياز المنهجي عند حساب inner product ودرجة attention (attention score).

ولهذا أهمية عملية لسببين. أولًا، تبقى TurboQuant غير معتمدة على البيانات (data-oblivious): فهي لا تحتاج إلى مجموعات بيانات للمعايرة، ولا إلى تدريب إضافي أو fine-tuning لنموذج بعينه. ثانيًا، يناسب الأسلوب السيناريوهات الفورية (online) التي يجب فيها ضغط الكاش أثناء الاستدلال مباشرة، بدلًا من إعداد مسار معالجة منفصل في وضع offline.

وتؤكد Google أن هذه المنظومة مفيدة ليس لنماذج LLM فحسب، بل أيضًا للبحث المتجهي، حيث يلزم كذلك تخزين مصفوفات ضخمة من embeddings ومقارنتها بسرعة وبكلفة منخفضة. وتعدّ الشركة TurboQuant للعرض في مؤتمر ICLR 2026.

ما النتائج التي حققتها Google؟

اختبرت Google خوارزمية TurboQuant على LongBench وNeedle In A Haystack وZeroSCROLLS وRULER وL-Eval، باستخدام نماذج Gemma وMistral المفتوحة. وبحسب الشركة، تحافظ TurboQuant على الجودة في مهام السياق الطويل، وتقلّص KV-cache بشكل ملحوظ في الوقت نفسه. يركّز مدوّن Google على الكمّنة بدقة 3 بتات دون فقدان في الجودة على المعايير التي جرى اختبارها، بينما يشير ملخص (abstract) الورقة البحثية على arXiv بشكل منفصل إلى الحفاظ الكامل على الجودة عند 3,5 بت لكل قناة، وإلى تدهور طفيف فقط عند 2,5 بت.

• تقليص ذاكرة KV-cache 6 أضعاف على الأقل
• تسريع حساب attention logits حتى 8 أضعاف على H100 في إعداد 4 بتات، مقارنةً بالمفاتيح غير المكمّنة بدقة 32 بت
• لا حاجة إلى إعادة تدريب أو fine-tuning أو مجموعات بيانات للمعايرة
• نتائج قوية في البحث المتجهي (vector search) أيضًا: تفوقت TurboQuant على الطريقتين الأساسيتين PQ وRabbiQ في معيار recall على مجموعة بيانات GloVe

وتراهن Google بشكل خاص على استخدام الأسلوب في البحث. فـTurboQuant وPolarQuant وQJL لا تقلل استهلاك الذاكرة فحسب، بل تقلل أيضًا الوقت اللازم لبناء الفهرس، مع الحفاظ على دقة البحث عن أقرب الجيران. وهذا يجعل التقنية مثيرة للاهتمام ليس لنماذج الذكاء الاصطناعي التوليدي وحدها، بل لأي بنية تحتية تتعامل مع مجموعات ضخمة من المتجهات: من البحث الدلالي إلى أنظمة التوصية وطبقة retrieval في منتجات الذكاء الاصطناعي.

ماذا يعني ذلك؟

تُظهر TurboQuant أن المكسب الكبير التالي في نماذج LLM قد لا يأتي من معاملات جديدة للنموذج، بل من تعامل أذكى مع الذاكرة. وإذا تأكد نهج Google في بيئات الإنتاج وظهر في حزم inference الشائعة، فسيصبح السياق الطويل أرخص وأسرع وأكثر إتاحة، حتى دون ترقية العتاد. وبالنسبة إلى المطورين، تتيح هذه التقنية فرصة لإدخال جلسات أطول وسيناريوهات RAG ضمن ميزانية GPU نفسها، أما بالنسبة إلى المستخدمين فهي تعني إجابات أكثر استقرارًا على المستندات الكبيرة والحوارات الطويلة.