PrismML وGoogle تقرّبان تشغيل نماذج 200B محليًا مع Bonsai وTurboQuant

يتوقف تشغيل النماذج اللغوية الكبيرة جداً محلياً عن كونه خيالاً للمتحمسين الذين يمتلكون خادماً. يستهدف نهجان جديدان — أوزان 1 بت من Bonsai من قبل PrismML وضغط KV-cache TurboQuant من Google Research — مباشرة أغلى جزأين في الاستدلال: ذاكرة النموذج وذاكرة السياق الطويل.

كيفية ضغط الأوزان

كشفت PrismML عن Bonsai 8B برخصة Apache 2.0 — نموذج قائم على Qwen3-8B، حيث يتم تخزين جميع الأوزان تقريباً في تمثيل 1 بت. من الناحية العملية، هذا يعني انخفاضاً حاداً في الحجم: حوالي 1.

15 جيجابايت مقابل 16.38 جيجابايت لإصدار FP16، أي أصغر بحوالي 14 مرة. تؤكد الشركة أن هذا ليس مجرد حزم الملفات الأرشيفية.

هذا التنسيق يتطلب kernel خاصة لتجنب فك ضغط الأوزان مرة أخرى إلى FP16 الكامل أثناء الاستدلال. يبدو المخطط خشناً لكن ليس بدائياً: يتم ترميز كل وزن في بت واحد، وتحصل مجموعة من 128 وزناً على مقياس مشترك في FP16. نتيجة لذلك، التكلفة الفعلية تصل إلى حوالي 1.

125 بت لكل وزن. وفقاً لادعاءات PrismML، يُصدر Bonsai 8B حتى 368 رمزاً في الثانية على RTX 4090، حوالي 131 رمزاً في الثانية على M4 Pro، ويبقى قادراً على المنافسة من حيث الجودة بين نماذج 8B، على الرغم من أنه لا يصبح الزعيم المطلق في المعايير.

كيفية تقليل KV-cache

لكن الأوزان الخفيفة وحدها غير كافية. تطور النماذج الكبيرة بسرعة KV-cache — ذاكرة العمل التي تخزن تمثيلات الرموز وتنمو مع طول السياق. هنا حيث يقترح Google Research TurboQuant.

تضغط الطريقة KV-cache بدون إعادة تدريب النموذج وتحافظ، وفقاً لنتائج المؤلفين، على الجودة حتى في نطاق حوالي 3-3.5 بت لكل قناة، حيث تبدأ الكمية العادية بالفعل بمخاطرة ملحوظة بجودة الإجابة. داخل النهج توجد فكرتان أساسيتان: أولاً، يتم تدوير البيانات إلى فضاء أكثر ملاءمة حيث يكون من الأسهل ضغطها بشكل كبير، ثم تعوض خطوة منفصلة خطأ الضغط.

من خلال هذا، يحل TurboQuant ليس فقط قضية الحجم بل أيضاً مشكلة تكاليف الفوائض التي غالباً ما تستهلك فائدة الكمية المتجهة العادية. في اختبارات Google، أظهرت الطريقة تقليلاً بمعامل ستة على الأقل لذاكرة KV-cache وتسريعاً لحساب الانتباه مقارنة بالتمثيل غير المضغوط.

إذا تم دمج النهج

يبدأ الجزء الأكثر إثارة للاهتمام حيث تتراص هاتان الفكرتان معاً. إذا توسعت طريقة 1 بت من PrismML يوماً ما على نماذج من فئة 200B+، واحتفظ TurboQuant بخصائصه على السياق الطويل، سيتوقف التشغيل المحلي لمثل هذه الأنظمة عن كونه مجال الخوادم التي تحتوي على مئات جيجابايت من الذاكرة. باستخدام Qwen3-235B-A22B كمثال، تبدو التقديرات بالفعل ليست خيالية بل قابلة للنقاش تقنياً لكنها واقعية تماماً. هذا ليس حول منتج نهائي بعد، بل حول مسار تطور الأجهزة والاستدلال.

• أوزان النموذج في bfloat16: حوالي 437.7 جيجابايت
• متغير افتراضي بـ 1 بت بالقياس على Bonsai: حوالي 30.8 جيجابايت
• KV-cache لسياق 128k في 16 بت: حوالي 23.5 جيجابايت
• KV-cache مع TurboQuant عند 3.5 بت: حوالي 5.1 جيجابايت
• إجمالي الأوزان والذاكرة: بترتيب 36 جيجابايت بدلاً من أكثر من 460 جيجابايت

هذا ليس وعداً بمساعد 235B محلي جاهز بعد. تبقى أسئلة حول عرض النطاق الترددي للذاكرة، جودة kernel منخفضة البت، الاستقرار على المهام الحقيقية، وكيفية نقل مخطط 1 بت من 8B إلى نماذج أكبر بشكل كبير. لكن المسار يتغير: سابقاً كان الحوار يتعلق بكيفية ضغط 7B أو 14B لجهاز محمول، الآن يتم بالفعل مناقشة ما إذا كانت فئة 200B يمكن إحضارها إلى الأجهزة المحلية.

ماذا يعني هذا

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