تم تقليص Google Gemma 4 31B إلى 18.3 غيغابايت وتشغيله على Kaggle المجاني

تم ضغط نموذج Gemma 4 الذي يضم 31 مليار معامل من Google بنجاح من 62 غيغابايت إلى 18.3 غيغابايت وتشغيله عبر Kaggle المجاني، على الرغم من أن حد القرص أصغر من حجم النموذج الأصلي. لتحقيق ذلك، قام المؤلف ببناء خط أنابيب صارم وفعال إلى حد ما: كمية فورية، حذف الذاكرة المؤقتة أثناء التنفيذ، والتحميل المباشر للنموذج إلى Hugging Face Hub.

الوصول إلى الحدود

يحتل Gemma 4 31B الأصلي بتنسيق float16 حوالي 62 غيغابايت، والقرص المتاح على Kaggle المجاني محدود بـ 57.6 غيغابايت. المشكلة ليست فقط تنزيل النموذج.

لا تزال بحاجة إلى إعادة تكميته إلى 4 بتات، والحصول على مجموعة أوزان جديدة حول 18 غيغابايت، ثم تحميله. إذا حسبنا بكل بساطة، في مرحلة واحدة تحتاج إلى الاحتفاظ بكل من الأصل والنتيجة، وهذا بالفعل حوالي 80 غيغابايت. بعبارة أخرى، السيناريو القياسي ينهار حتى قبل أول تحميل ناجح.

هذه هي نقطة هذه الحالة: لا يتعلق الأمر بـ MLOps جميل على أجهزة مكلفة، بل عن محاولة تشغيل نموذج ثقيل مفتوح المصدر في ظروف حيث يجب كسب كل غيغابايت. بدلاً من A100، تم استخدام اثنين من T4 المجانيين، لذا اختزلت المهمة إلى حدين في نفس الوقت — القرص والذاكرة المرئية. نتيجة لذلك، كان يجب بناء خط الأنابيب بالكامل ليس حول الراحة، بل حول البقاء: ما يتم تخزينه، ومتى يتم الحذف، وفي أي لحظة يتم إرسال القطعة للخارج.

كيفية بناء خط الأنابيب

التقنية الأساسية الأولى هي الكمية ليس بعد التحضير الكامل، بل مباشرة أثناء عملية التحميل. لهذا، تم استخدام bitsandbytes وتنسيق NF4، وسمح المعامل device_map="auto" بالتوزيع التلقائي للنموذج عبر اثنين من T4 بسعة 15 غيغابايت لكل منهما. الفكرة هي عدم الانتظار حتى تستقر جميع الأوزان بشكل مريح على القرص ثم البدء في المعالجة. كلما بدأت الضغط مبكراً، قل احتمال أن تستهلك الملفات المؤقتة والحالات الوسيطة المساحة المتاحة بالكامل.

• يتم تحميل النموذج وكميته في نفس الوقت تقريباً، بدون فاصل طويل بين المراحل
• المعامل device_map="auto" يوزع الأوزان المجزأة بين اثنين من T4
• بعد التحميل في VRAM، يتم حذف ذاكرة Hugging Face المؤقتة لتحرير مساحة للقطعة الجديدة
• بدلاً من الحفظ على القرص، يتم إرسال النموذج مباشرة إلى Hugging Face Hub

الخطوة الأكثر جذرية كانت حذف مجلد ذاكرة Hugging Face المؤقتة بعد أن كان النموذج محمللاً بالفعل في الذاكرة المرئية. من الناحية التقنية، تعتمد الحيلة على سلوك Linux: حتى لو تم حذف ملف من نظام الملفات، يمكن للعملية أن تستمر في الاحتفاظ به مفتوحاً، وتصبح المساحة متاحة لكتابات جديدة. بفضل هذا، يتوقف الـ 62 غيغابايت الأصلي عن التدخل في إنشاء أجزاء مكممة. تجنبت المرحلة النهائية أيضاً النسخ غير الضرورية: بدلاً من الحفظ العادي والتحميل المنفصل، تم إرسال النتيجة مباشرة إلى Hugging Face Hub عبر push_to_hub.

"لم ننتظر انتهاء التحميل، بدأنا بضغط الأوزان على الفور."

ما حصل في النهاية

كانت النتيجة قطعة بحجم 18.3 غيغابايت — لم تعد وحشاً مرتبطاً بأجهزة الخادم، بل نموذجاً يمكنك العمل معه على تكوينات عادية بكثير. يؤكد المؤلف بشكل خاص أن هذا هو Gemma 4 بـ 31 مليار معامل، الموجه من بين أمور أخرى نحو المهام التي تتضمن أكواداً معقدة. تم نشر النتيجة نفسها على Hugging Face، لذا فهذه ليست مجرد وصفة نظرية، بل تجربة قابلة للتكرار مع نتيجة ملموسة وبناء جاهز.

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

ما يعنيه ذلك

يمكن تكييف النماذج الكبيرة مفتوحة المصدر مثل Google Gemma 4 حتى مع البنى الأساسية المتواضعة جداً، إذا أعدت بناء العملية برمتها حول القيود بدلاً من حول خط أنابيب مريح. بالنسبة للمطورين، هذه إشارة جيدة: يتم خفض حاجز الدخول للتجارب مع LLM الكبيرة، لكن ثمن هذه الإمكانية هو سيناريوهات MLOps أكثر هشاشة وتدويناً.