ضغط نموذج DeepSeek-V4-Pro بمعامل 50 وتشغيله على معالج T4 مجاني واحد في Kaggle

تُظهر تجربة DeepSeek-V4-Pro أن نموذجًا من فئة 1.6 تريليون معامل يمكن إيصاله إلى حالة التشغيل دون عنقود من معالجات H100، شرط التخلي عن فكرة تشغيله بصورته الأصلية. فبدلًا من استدلال (inference) كامل، بنى صاحب المشروع تقريبًا شديد العدوانية: ضغط الأوزان عبر التحليل منخفض الرتبة، ومرّر شظايا ضخمة عبر معالجة متدفقة، وكيّف البنية يدويًا لتلائم الأدوات القائمة.

النتيجة بعيدة عن مستوى الإنتاج، لكن مجرد التشغيل على معالج NVIDIA T4 مجاني في Kaggle يمثل عرضًا قويًا لمدى ما تحسمه اليوم الرياضيات والبراعة الهندسية. ويتحدث الوصف الأصلي عن DeepSeek-V4-Pro، التي يصفها صاحب المشروع بأنها نموذج MoE بحجم 1.6 تريليون معامل وأوزان يتجاوز حجمها 800 غيغابايت.

وتحتاج أنظمة من هذه الفئة عادةً إلى بنية تحتية مختلفة تمامًا: عدة معالجات H100، وهامش كبير من ذاكرة الفيديو، وقنوات سريعة بين العقد، وسعة معقولة من القرص المحلي. وفي هذا السياق، لا يبدو اختيار نسخة Kaggle المجانية بمعالج T4 وذاكرة 16 غيغابايت VRAM ونحو 50 غيغابايت من القرص محاولة لتكرار تشغيل قياسي، بل تجربة على حافة الممكن. وصياغة المسألة نفسها مهمة أيضًا: فالهدف ليس الحفاظ على النموذج بصورته الأصلية، بل اختبار مقدار البنية المفيدة التي يمكن الإبقاء عليها بعد ضغط جذري.

الخطوة المحورية في المشروع هي التخلي عن التكميم المعتاد إلى 4 بت لصالح «تحويل SVD»، أي التحليل منخفض الرتبة لمصفوفات الأوزان. وبحسب المؤلف، أعطت الرتبة 64 ضغطًا بنحو 50 ضعفًا. يُبقي هذا النهج على الاعتماديات الرئيسية بين المعاملات، لكنه يتخلص من كمّ كبير من التفاصيل، ومعها جزء من الجودة. وبالنسبة لنموذج عملاق، فهذه مقايضة قاسية: تنخفض الدقة، لكن تظهر فرصة لإدخال النظام في عتاد متاح. وهو في جوهره لم يعد النموذج الأصلي بالمعنى الكامل، بل هيكله الرياضي الذي ما زال قادرًا على الاحتفاظ بجزء من السياق والروابط الترابطية.

العنصر الثاني المهم هو التعامل مع الأوزان بأسلوب MLOps شبه اضطراري. فبدلًا من تخزين مجموعة المعاملات كاملة محليًا، عالج المؤلف الشظايا بالتتابع عبر safe_open: يحمّل ملفًا واحدًا، ويستخرج التنسور المطلوب، ويضغطه في الذاكرة العشوائية، ويرسل النتيجة إلى المستودع، ثم يفرغ الذاكرة المؤقتة (cache) بالكامل قبل الخطوة التالية. وبهذه الطريقة أمكن تمرير مجموعة أوزان لم تكن لتتسع في السيناريو المعتاد على جهاز مجاني، متجاوزًا قيد مساحة القرص. ويؤكد المؤلف بشكل خاص أن استهلاك الذاكرة العشوائية لم يتجاوز 4 غيغابايت. وهذه تفصيلة مهمة، لأن مثل هذه المهام لا تصطدم بذاكرة VRAM وحدها، بل بلوجستيات الملفات أيضًا، حين يستحيل فعليًا حتى فك ضغط النموذج دون حيل وسيطة.

الطبقة الثالثة من البناء هي «سرقة هوية» معمارية (architectural identity theft). فمكتبة transformers، كما يؤكد المؤلف، لم تكن تدعم DeepSeek-V4 بعد، ولذلك اضطر إلى تمويه الإعدادات على أنها DeepSeek-V2 وتعديل توجيه MoE بشكل منفصل عبر monkey patching. من الناحية الهندسية، هذا أسلوب هش: فهو يعتمد على إصدار المكتبات وصيغة ملفات الإعدادات وبنية موجّه الخبراء (router). لكن هذه الخطوة تحديدًا تُظهر أن جزءًا من القيود المحيطة بالنماذج الكبيرة لا يرتبط بالعتاد وحده، بل بتوافق الأدوات أيضًا. فإذا كانت المنظومة لا تعرف البنية الجديدة بعد، يضطر الباحثون غالبًا إلى تكييف الإطار مع النموذج أولًا، ثم الانشغال بجودة المخرجات.

والناتج نسخة من النموذج تتسع، بحسب المؤلف، في ذاكرة معالج T4 واحد وتستطيع دعم السياق، لكن جودتها تتراجع بشكل ملحوظ. ومن الآثار الجانبية المذكورة الهلوسات وخلط الروسية والإنجليزية والصينية في إجابة واحدة. وهذا يجعل النظام مرشحًا سيئًا للسيناريوهات التطبيقية الموثوقة التي تهم فيها الدقة والاستقرار وقابلية التنبؤ. لكن المشروع ينجح كإثبات جدوى (proof of concept): فهو يبين أن النماذج مفتوحة الأوزان الضخمة جدًا لا تُناقَش بمصطلحات مراكز البيانات وحدها، بل يمكن أيضًا تفكيكها إلى تهيئات أكثر إتاحة، وإن كانت مخفّضة بشدة.

والخلاصة الرئيسية هنا ليست أن T4 أصبح فجأة بديلًا عن عنقود معالجات رسومية حديث. بل العكس تمامًا: فالتجربة تُظهر بوضوح ثمن هذه التسويات، والحدّ الذي يصبح التشغيل بعده إعادة بناء بحثية لا استدلالًا كاملًا. غير أن مثل هذه المشاريع تحديدًا تدفع إلى الأمام ممارسات الضغط والاستدلال التقريبي (approximate inference) وMLOps الميسّر. وكلما ظهرت حلول التفافية من هذا النوع، انخفض حاجز الدخول أمام من يريدون التجريب مع النماذج الكبيرة دون ميزانية مؤسسية.