من 31 جيجابايت إلى 4 جيجابايت. هذا الرقم هو ما أسقط بضعة بالمئة من سهم شركة Micron في يونيو 2026، وما دفع نصف مطوّري Twitter إلى ذعر حقيقي من انهيار فواتير RAG. الرياضيات في القاع حقيقية: خوارزمية TurboQuant من Google (arXiv 2504.19874، مقبولة في ICLR 2026) تضغط ذاكرة نموذج اللغة الكبير بمعدل ~6x إلى نحو 3 بتات لكل قيمة مع خسارة دقة تكاد تكون صفراً. لكن معظم التقارير أخطأت في نقطة واحدة، وهذا الخطأ يغيّر كل شيء.
قصة ضغط ذاكرة الذكاء الاصطناعي بخوارزمية TurboQuant من Google هي في الحقيقة قصتان تتقاسمان المشهد. دعونا نفصل بينهما.
أبرز النقاط
- TurboQuant هي خوارزمية ضغط من Google لا تحتاج إلى تدريب: ~6x لـ KV cache ينزل إلى ~3 بتات، مع خسارة دقة شبه معدومة (ICLR 2026).
- TurboVec هي مكتبة Rust مستقلة من طرف ثالث تُنفّذ خوارزمية TurboQuant. Google لم تُصدرها.
- عرض "31GB → 4GB، يتفوق على FAISS" الذي انتشر فيروسياً هو إنجاز TurboVec وليس TurboQuant مباشرةً.
- الفائدة الحقيقية للمطوّرين تكمن في تقليل تكلفة الاستنتاج بالسياق الطويل وفهارس RAG الأصغر، لكن ما أصدرته Google رسمياً هو ورقة بحثية وليس منتجاً.
ما هي TurboQuant من Google بلغة مبسّطة؟
TurboQuant هي خوارزمية كمّية متجهية (vector-quantization) من Google Research لا تحتاج إلى تدريب ولا تعتمد على البيانات. تضغط KV cache لنموذج اللغة الكبير بمعدل ~6x، ليصل إلى نحو 3 بتات لكل قيمة مع خسارة دقة شبه معدومة. نُشرت في arXiv 2504.19874 وقُبلت في ICLR 2026. "لا تحتاج إلى تدريب" يعني أنها تعمل على النماذج الموجودة كما هي دون أي ضبط دقيق.
ما الذي يُضغط بالضبط؟ شيئان أساسيان.
الأول هو KV cache. حين يقرأ النموذج محادثتك، يخزّن ملخصاً متراكماً لكل ما سبق يُعرف بمخبأ المفاتيح والقيم. فكّر فيه على أنه الذاكرة قصيرة الأمد للنموذج. كلما اتسعت نافذة السياق، زاد حجم هذه الذاكرة وارتفع استهلاك GPU RAM. يمكن لمحادثة بسياق 128k رمز أن تضخّ KV cache إلى عدة جيجابايتات. هذا سبب ارتفاع تكلفة خدمة السياق الطويل بسرعة، وهو ما دفع إلى تخزين الـ prompt مؤقتاً لخفض تكاليف الـ API في المقام الأول.
الثاني هو فهارس المتجهات. التضمينات التي تشغّل البحث الدلالي وRAG عبارة عن مصفوفات ضخمة من الأعداد العشرية. خزّن ملايين منها بالدقة الكاملة وستجد نفسك أمام عشرات الجيجابايتات في الذاكرة.
TurboQuant تضغط كليهما. الجزء المثير هنا: لا تحتاج أياً من بياناتك للقيام بذلك. معظم خطط الكمّية تدرس عيّنة من متجهاتك أولاً ثم تبني كودبوك مُضبّطاً لها. TurboQuant تتجاوز ذلك كله. فهي لا تعتمد على البيانات، أي أنها تصل إلى نسبة الضغط المستهدفة دون أن تنظر أبداً في توزيعك.
الميزة الحقيقية لـ TurboQuant ليست نسبة الضغط. بل أنها لا تحتاج إلى أي بيانات تدريب للوصول إليها.
هذا هو المكسب الفعلي. يمكنك توجيهها إلى نموذج تشغّله بالفعل والحصول على التوفير فوراً.
TurboQuant مقابل TurboVec: الخلط الذي وقع فيه الجميع
TurboQuant هي خوارزمية ضغط Google (arXiv 2504.19874، ICLR 2026). TurboVec هي مكتبة Rust وPython مستقلة من طرف ثالث (RyanCodrai/turbovec) تُنفّذ خوارزمية TurboQuant للبحث في المتجهات. Google لم تُصدر TurboVec. نتيجة "31GB → 4GB، تتفوق على FAISS" التي انتشرت فيروسياً تعود إلى TurboVec لا إلى TurboQuant المجردة. إن كنت ستتذكر شيئاً واحداً من هذا المقال، فليكن هذا.
إليك مصدر الخلط. حين انتشرت نتيجة 31GB→4GB في مطلع يونيو 2026، نشرت بعض المواقع (منها Tech Startups) عناوين تقول إن Google "أصدرت TurboVec". لم يحدث ذلك. انظر إلى المصدر: TurboVec موجودة على RyanCodrai/turbovec في GitHub وPyPI. إنها مكتبة مفتوحة المصدر بناها مطوّر يدعى Ryan Codrai. صحيفة MarkTechPost وصفتها بشكل صحيح بأنها "فهرس متجهات مبني بـ Rust مع ارتباطات Python، يستند إلى خوارزمية TurboQuant من Google."
العلاقة إذن بسيطة: Google نشرت الرياضيات، والمجتمع بنى أدوات بها. TurboVec هي الأبرز بين هذه الأدوات.
| TurboQuant | TurboVec | |
|---|---|---|
| ما هو | خوارزمية ضغط | مكتبة فهرس متجهات (Rust + Python) |
| من بناه | Google Research + DeepMind | Ryan Codrai (طرف ثالث) |
| أين | arXiv 2504.19874, ICLR 2026 | GitHub RyanCodrai/turbovec, PyPI |
| الرقم الرئيسي | ~6x KV cache ينزل إلى ~3 بتات | من 31GB إلى ~4GB لفهرس 10M وثيقة |
| الحالة | ورقة بحثية + خوارزمية | مكتبة مفتوحة المصدر قابلة للاستخدام |
Google بنت الخوارزمية. Ryan Codrai بنى المكتبة التي يتداول الجميع لقطات شاشتها. الاثنان ليسا شيئاً واحداً.
إن كنت تقيّم مكان فهرس مستند إلى TurboQuant جنباً إلى جنب مع إعدادك الحالي، فمقالتنا عن أفضل قواعد البيانات المتجهة في 2026 تضع FAISS وQdrant والفهارس المضغوطة الأحدث جنباً إلى جنب.
كيف تضغط TurboQuant الذاكرة دون أن تُفسد الدقة؟
تستخدم TurboQuant دوراناً عشوائياً إضافةً إلى مخطط كمّية بالإحداثيات القطبية (PolarQuant) وإسقاطاً على غرار Johnson-Lindenstrauss (QJL، Quantized Johnson-Lindenstrauss) لتوزيع القيم بالتساوي قبل عملية الكمّية. هذا التشويه شبه الأمثل هو ما يُمكّنها من النزول إلى نحو 3 بتات لكل قيمة مع الحفاظ على الدقة شبه سليمة، دون الحاجة إلى أي إعادة تدريب للنموذج.
دعني أفكّ هذه التقنية، لأن المصطلحات تُخفي فكرة بديهية جداً.
حين تُجري عملية الكمّية، أنت تُقرّب الأرقام إلى عدد أقل من البتات. الخطر هنا أن بعض أبعاد المتجه قد تحمل وزناً أكبر بكثير من غيرها، فيُفسد تقريبها نتيجةً كارثية. حل TurboQuant هو تدوير المتجه عشوائياً أولاً. تخيّل خلط ورق اللعب بالتساوي قبل التوزيع، فلا تكون أي يد منحازة. بعد الدوران، تتوزع القيم بشكل متساوٍ وبالتالي لا يهيمن أي بُعد، ويكون التقريب أقل ضرراً.
هذا هو الجزء المعروف بـ QJL: إسقاط عشوائي يخلط كل شيء معاً مع الحفاظ على المسافات. ثم يأتي PolarQuant (المقدَّم في AISTATS 2026) ليُكمّي القيم المدوّرة في إحداثيات قطبية، وهو ما يتناسب مع توزيعها أفضل من التقريب الشبكي الاعتيادي.
النتيجة هي ما تسميه الورقة تشويهاً شبه أمثل، أي أنها تقترب من حد Shannon النظري لأقل قدر من الجودة يمكن خسارته عند ميزانية بتات معينة. بعبارة بسيطة: عند 3 بتات لكل قيمة، لا يمكنك أن تفعل الكثير أفضل من ذلك، وTurboQuant تصل إلى هذا دون دراسة بياناتك.
للاطلاع على الآلية الكاملة، تُعدّ مدونة Google Research وورقة arXiv المصادر الأولية. وقد نشرت InfoQ أيضاً تحليلاً موجهاً للمطوّرين من منظور KV cache إن كنت تريد تأطيراً تطبيقياً.
ماذا يعني 31GB → 4GB فعلاً على فاتورة RAM الخاصة بك؟
فهرس RAG بحجم 10 مليون متجه يحتاج ~31GB من RAM بالدقة الكاملة ينزل إلى ~4GB تقريباً مع ضغط TurboVec المستند إلى TurboQuant، وهو صغير بما يكفي لاستخدام instance عادية بدلاً من المستوى المُحسَّن للذاكرة. بالنسبة لـ KV cache، التخفيض بمعدل ~6x يعني تقريباً 6 أضعاف الجلسات المتزامنة ذات السياق الطويل على نفس الـ GPU. هذا الجزء هو ما يظهر فعلاً على الفاتورة.
أجرينا الحسابات التي لا يجريها المنافسون. ملاحظة أمانة أولاً: كل ما يلي مُقدَّر ومُنمذَج (يونيو 2026) استناداً إلى أسعار السحابة العامة ونسب الورقة البحثية المُعلنة. لم نشغّل TurboVec في بيئة إنتاجية، لذا تعامل مع هذه الأرقام باعتبارها رياضيات لا معياراً قسناه بأنفسنا. مستويات الأسعار تتبع نفس الأساس الذي نستخدمه في دليلنا حول تقليل تكاليف LLM API.
إليك فهرس تضمين بـ 10 مليون وثيقة، بالدقة الكاملة مقارنةً بالمضغوط بـ TurboVec، مع مستوى RAM السحابي المطلوب:
| فهرس RAG بـ 10M متجه | RAM المطلوبة | مستوى الـ instance المعتاد | نطاق التكلفة الشهرية التقريبية للـ RAM |
|---|---|---|---|
| دقة كاملة (float32) | ~31 GB | 32GB+ مُحسَّن للذاكرة | مرتفع (مستوى مُحسَّن للذاكرة) |
| مضغوط بـ TurboVec | ~4 GB | 8GB عام الأغراض | منخفض بكثير (مستوى اقتصادي) |
الانتقال من صندوق مُحسَّن للذاكرة إلى صندوق عام صغير هو القصة بأكملها. بالنسبة لفهرس يستضيفه المستخدم بنفسه، غالباً ما يكون هذا الفرق بين فاتورة تُقلق والأخرى التي تكاد لا تلاحظها. إن كنت تبني الخط الذي يجلس فوق هذا الفهرس، يغطي دليلنا حول بناء تطبيق RAG المكان الذي يقع فيه هذا الفهرس.
الآن جانب KV cache، مُنمذَج على GPU بـ 24GB يخدم جلسات بسياق 128k:
| KV cache، GPU 24GB @ 128k context | الجلسات المتزامنة (مُنمذَجة) |
|---|---|
| دقة كاملة | baseline (لنسمّها ~N) |
| ~3 بتات TurboQuant (~6x) | تقريباً 6x من N |
تخفيض KV cache بمعدل 6x لا يوفر RAM فحسب. يمكنه تحويل GPU واحد إلى ستة لخدمة السياق الطويل.
هذا هو السبب في أن هذا الأمر أكثر أهمية لأعباء العمل ذات السياق الطويل من أي شيء آخر. إن كنت تخدم محادثات قصيرة كثيرة، لم يكن KV cache يوماً هو العائق. لكن إن كنت تشغّل وكلاء بسياق 128k أو تحليل وثائق، يغيّر التخفيض بمعدل 6x اقتصادياتك لكل GPU بين عشية وضحاها. تقارير VentureBeat تضع الحد الأعلى لمكسب الإنتاجية عند 8x على H100 مع توفير يتجاوز 50%، وهو ما يتوافق مع حسابات التزامن المُنمذَجة لدينا.
لماذا هبطت أسهم شرائح الذاكرة، وهل بالغ وول ستريت في رده؟
بعد الكشف عن TurboQuant، هبطت أسهم Micron وWestern Digital وSeagate على خلفية مخاوف من أن رخص ذاكرة الذكاء الاصطناعي بشكل جذري سيُقلص الطلب المستقبلي على DRAM وHBM، في ما وُصف بـ"لحظة DeepSeek". محللون من Wells Fargo جادلوا بالعكس تماماً: رخص الذاكرة يرفع إجمالي الاستخدام لا يخفضه، عبر مفارقة Jevons.
السردية كتبت نفسها. الذكاء الاصطناعي هو أكبر مشترٍ للذاكرة عالية النطاق الترددي الآن، لذا إن كانت خوارزمية Google تخفض احتياجات الذاكرة 6 أضعاف، فالمنطق يقول إن الطلب على الشرائح يهبط وتهبط معه صانعاتها. وصلت TechCrunch إلى مقارنة "Pied Piper"، الشركة الخيالية للضغط من مسلسل Silicon Valley التي وعدت بضغط بيانات العالم. الأسهم هبطت على هذا الخوف.
التأطير الأهدأ، والذي تجاهله معظم التغطيات الإخبارية، يشير إلى مفارقة Jevons: حين يصبح شيء ما أرخص وأكثر كفاءة، عادةً ما نستهلك منه أكثر في المجموع لا أقل. ذاكرة الذكاء الاصطناعي الأرخص تعني أن المزيد من التطبيقات ستشحن ميزات السياق الطويل، والمزيد من الفرق ستستضيف فهارس RAG أكبر بنفسها، ويحدث المزيد من الاستنتاج بشكل عام. لكفاءات الطاقة تاريخ طويل في رفع الطلب الإجمالي لا في قتله.
السوق سعّر TurboQuant كقاتل للطلب. التاريخ يقول عادةً إن رخص الحوسبة يعني فقط أننا نستخدم المزيد منها.
هل كان الهبوط مبالغاً فيه؟ على الأرجح، على المدى القصير على الأقل. ورقة بحثية ليست تحديثاً فورياً على مستوى الصناعة. تفاعل السوق مع عنوان إخباري؛ النشر الفعلي سيستغرق أرباعاً، وقد يُطغي تأثير تحفيز الطلب على التوفير بسهولة.
هل يمكنك استخدام TurboQuant اليوم؟
نعم، جزئياً. الإصدار الرسمي من Google لـ TurboQuant هو الورقة البحثية والخوارزمية، لا منتج جاهز للتحميل. لكن التطبيقات المجتمعية موجودة بالفعل: TurboVec (RyanCodrai/turbovec، على PyPI) لفهارس المتجهات، وAmesianX/TurboQuant لـ llama.cpp (بنحو 5.2x، مع دعم DeepSeek-V2/V3 وGLM-4.7-Flash عبر MLA). المنظومة ناشئة لكنها قابلة للاستخدام.
إن أردت تجربة جانب فهرس المتجهات، TurboVec تبعد pip واحدة:
pip install turbovec
# Rust + Python bindings, implements Google's TurboQuant for vector search
# llama.cpp KV-cache impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python reference impl: github.com/yashkc2025/turboquantلجانب KV cache على النماذج المحلية، تطبيق AmesianX/TurboQuant لـ llama.cpp هو الذي يستحق المتابعة، خاصةً إن كنت تشغّل نماذج DeepSeek أو GLM مع multi-head latent attention. يتكامل بشكل جيد مع إعداد LLM محلي، إذ يعني KV cache الأصغر قدرتك على دفع سياق أكبر على نفس الكرت. وإن كنت تختار النموذج المفتوح الذي ستشغّله معه، فمقالتنا عن أفضل معايير LLMs مفتوحة المصدر تغطي عائلتَي DeepSeek وGLM مباشرةً.
التحفظ الأمين: هذا رياضيات منشورة ونظام بيئي في طور النضج. الإصدار الرسمي من Google هو بحث لا منتج مدعوم بـ SLA.
الإجابة الصادقة: TurboQuant رياضيات قابلة للتطبيق، لا زر تنزيل. في الوقت الحالي.
هل TurboQuant ضجيج أم حقيقة؟ حكم صريح
TurboQuant حقيقية وذكية فعلاً. تصميمها الذي لا يحتاج إلى تدريب هو المكسب الجوهري، وفائدة KV cache أهم ما فيها لأعباء عمل السياق الطويل. لكنها ليست سحراً: هي تقدم واحد في الكمّية ضمن تقدمات كثيرة، الرقم الشهير 31GB→4GB يعود إلى TurboVec لا Google، وذعر الأسهم بالغ في قراءة نتيجة بحثية.
في تجربتنا في ضبط تكاليف الاستنتاج والذاكرة لصالح العملاء، ما يحدد ما إذا كانت تقنية كهذه تستحق التبني هو مستوى الاحتكاك. عدم الحاجة إلى تدريب يكسب هنا بقوة، إذ لا دورة ضبط دقيق، ولا كودبوك للصيانة، ولا جراحة في النموذج. تستطيع ربطها بشيء تشغّله بالفعل.
ما الذي تغيّره:
- استنتاج أرخص بالسياق الطويل، وهو حيث تؤلم تكلفة الذاكرة فعلاً.
- فهارس RAG مستضافة ذاتياً أصغر تناسب أجهزة أرخص.
- خيار ضغط يمكنك تبنّيه دون إعادة تدريب أي شيء.
ما الذي لا تغيّره:
- لن تُفيد كثيراً في أعباء العمل ذات السياق القصير والنماذج الصغيرة، حيث لم يكن KV cache يوماً هو العائق.
- لا تُلغي خطط الكمّية الحالية بين عشية وضحاها؛ هي إضافة لا بديل.
- الإصدار الرسمي من Google لا يزال ورقة بحثية، لذا الأدوات الجاهزة للإنتاج متروكة للمجتمع في الوقت الحالي.
إن كنت تحاول معرفة ما يعنيه هذا بالنسبة لاستنتاجك الخاص أو فاتورة RAM، فهذا بالضبط نوع نمذجة التكلفة الذي نقوم به للعملاء في Techsy. احصل على استشارة مجانية إن أردت نظرة ثانية على الأمر.
عن الكاتب
Mert Batur Gurbuz هو المؤسس المشارك لـ Techsy.io، حيث يشحن الفريق وكلاء ذكاء اصطناعي وأنظمة أتمتة وخطوط صوتية وSDR للعملاء من B2B. يدرس في جامعة Birmingham ويكتب عن مجموعة أدوات LLM التي يستخدمها فريق Techsy فعلياً في الإنتاج. تواصل على LinkedIn.
الأسئلة الشائعة
ما هي TurboQuant من Google؟
TurboQuant هي خوارزمية كمّية متجهية من Google Research لا تحتاج إلى تدريب، منشورة في arXiv 2504.19874 ومقبولة في ICLR 2026. تضغط KV cache لنموذج اللغة الكبير بمعدل ~6x إلى نحو 3 بتات لكل قيمة مع خسارة دقة شبه معدومة. وكونها لا تعتمد على البيانات، فهي تعمل على النماذج الموجودة دون أي ضبط دقيق أو إعادة تدريب.
هل أصدرت Google TurboVec فعلاً؟
لا. TurboQuant هي خوارزمية Google. TurboVec هي مكتبة Rust وPython مستقلة من طرف ثالث (RyanCodrai/turbovec) بناها مطوّر مستقل فوق TurboQuant. بعض المواقع أخطأت في نسب TurboVec إلى Google حين انتشرت نتيجة 31GB→4GB، لكن GitHub يُثبت أنها مشروع مجتمعي.
هل TurboQuant وTurboVec الشيء نفسه؟
لا. TurboQuant هي خوارزمية الضغط التي نشرتها Google. TurboVec هي إحدى المكتبات التي تُنفّذ هذه الخوارزمية للبحث في المتجهات. الأولى هي الرياضيات، والثانية أداة مبنية بتلك الرياضيات. نتيجة "31GB → 4GB، تتفوق على FAISS" الشهيرة هي لـ TurboVec لا شيئاً أصدرته Google مباشرةً.
هل تفقد TurboQuant في الدقة؟
خسارة الدقة شبه معدومة هو ما تؤكده الورقة البحثية، حتى عند نحو 3 بتات لكل قيمة. تحقق الخوارزمية تشويهاً شبه أمثل (قريباً من حد Shannon) عبر تدوير المتجهات عشوائياً قبل الكمّية حتى لا يهيمن أي بُعد. في التطبيق العملي، تكون نسبة التدهور صغيرة بما يكفي لإهمالها في معظم أعباء العمل.
كم تُوفّر TurboQuant من RAM؟
حوالي 6x في KV cache، ينزل إلى نحو 3 بتات لكل قيمة. على جانب فهرس المتجهات، أظهرت TurboVec فهرس 10 مليون وثيقة ينكمش من 31GB إلى نحو 4GB، وهو توفير يصل إلى 92% في الذاكرة. التوفير الفعلي يعتمد على خط الأساس للدقة وما إذا كنت تضغط KV cache أو التضمينات أو كليهما.
هل هذا مجرد ضجيج، ولماذا هبطت أسهم الذاكرة؟
هو تقدم حقيقي، لكن ردة الفعل المذعورة بالغت في قراءة نتيجة بحثية. هبطت Micron وWestern Digital وSeagate على خلفية مخاوف أن رخص ذاكرة الذكاء الاصطناعي سيُقلص الطلب على الشرائح. Wells Fargo تصدّت بمفارقة Jevons: الذاكرة الأرخص والأكثر كفاءة عادةً ترفع الاستخدام الإجمالي. كذلك فإن الورقة البحثية ليست تحديثاً فورياً للصناعة، لذا يبدو رد الفعل على المدى القصير مبالغاً فيه.
هل يمكنني استخدام TurboQuant اليوم؟
جزئياً. الإصدار الرسمي من Google هو الورقة والخوارزمية لا منتج. تطبيقات مجتمعية موجودة الآن: TurboVec على PyPI لفهارس المتجهات، وAmesianX/TurboQuant لـ llama.cpp (DeepSeek-V2/V3 وGLM-4.7-Flash عبر MLA)، وyashkc2025/turboquant كمرجع Python. النظام البيئي ناشئ لكنه صالح للاستخدام بالفعل.
كيف تختلف TurboQuant عن عمليات الكمّية التي أُجريها بالفعل؟
معظم خطط الكمّية تدرس عيّنة من بياناتك لبناء كودبوك مُضبّط. TurboQuant لا تحتاج إلى تدريب ولا تعتمد على البيانات، فتصل إلى نسبتها دون النظر في توزيعك أبداً. كذلك تستهدف KV cache وفهارس المتجهات تحديداً بتشويه شبه أمثل، بدلاً من مجرد ضغط أوزان النموذج.
هل تعمل TurboQuant مع DeepSeek أو llama.cpp؟
نعم، عبر تطبيق AmesianX/TurboQuant لـ llama.cpp، الذي يُرسل ضغطاً بنحو 5.2x ويدعم DeepSeek-V2/V3 وGLM-4.7-Flash عبر multi-head latent attention (MLA). هذا يجعله خياراً عملياً إن كنت تستضيف هذه النماذج بنفسك وتريد KV cache أصغر لسياقات أطول على نفس العتاد.
متى تُفيد TurboQuant أكثر ما يكون؟
تُفيد أكثر ما يكون في الاستنتاج ذي السياق الطويل وفهارس RAG الكبيرة المستضافة ذاتياً، حيث تكون الذاكرة هي العائق الحقيقي. التخفيض بمعدل 6x في KV cache يعني جلسات أكثر بسياق 128k لكل GPU، وفهرس تضمين مضغوط يناسب instances أرخص. تُفيد أقل ما يكون في المحادثات القصيرة والنماذج الصغيرة، حيث لم يكن KV cache أبداً المحرّك الأساسي للتكلفة.