متحمس يشغّل DeepSeek-V4-Flash على 64 غيغابايت من الذاكرة دون معالج رسومي: حتى 15 رمزًا في الثانية

عادةً ما يتلخص الحديث عن تشغيل النماذج الكبيرة محليًا في سؤال واحد: كم لديك من ذاكرة الفيديو؟ نشر أحد المتحمسين مشروع llama-modchip بترخيص Apache 2.0، ويزعم أن حاسوبًا عاديًا بذاكرة عشوائية 64 غيغابايت يكفي لنموذج بـ284 مليار معامل. لا حاجة إلى بطاقة رسومات، ولا إلى ذاكرة تبديل. لنفهم ما الذي أُنجز فعلًا وهل يمكن تصديقه.

ما الذي تحقق

llama-modchip هو مجموعة تصحيحات لنوى ggml/llama.cpp وأدوات للتكميم (quantization) وسكربتات لتشغيل نماذج MoE المتناثرة مباشرة على المعالج. النموذج المستهدف هو DeepSeek-V4-Flash: 284 مليار معامل في المجموع، منها 13 مليارًا نشطة.

وهذه أرقام المؤلف. ذروة استهلاك الذاكرة نحو 58 غيغابايت مع سياق طوله 256 ألف رمز. تجري المعالجة المسبقة (prefill)، أي «قراءة» الطلب، بسرعة 44 رمزًا في الثانية. ويعطي التوليد من 9 إلى 15 رمزًا في الثانية. أُجريت الاختبارات على معالج Ryzen 9 9955HX بـ16 نواة. وهذه تقريبًا الوتيرة التي لا يزال من المريح فيها قراءة النص أثناء ظهوره على الشاشة. وهي مناسبة للدردشة أو للمهام الخلفية، لكنها ثقيلة نوعًا ما للعمل التفاعلي مع وثائق طويلة: فسرعة 44 رمزًا في الثانية في prefill تعني أن تحميل سياق كبير سيستغرق وقتًا ملحوظًا.

لماذا هذا ممكن أصلًا

اجتمع هنا أسلوبان.

الأول مدمج في النموذج نفسه. تشبه بنية MoE (مزيج الخبراء) مكتبة كبيرة يُفتح فيها عن كل سؤال الكتب-الخبراء اللازمة فقط. كل شيء مخزَّن، لكن جزءًا صغيرًا فقط يُحتسب. لذلك يقترب DeepSeek-V4-Flash من حيث الحوسبة من النماذج المتوسطة: إذ يعمل 13 مليار معامل فقط لكل رمز. وهذا الحمل في متناول المعالج. أما عنق الزجاجة فهو في مكان آخر: يجب الاحتفاظ في الذاكرة بجميع الأوزان البالغة 284 مليارًا.

والأسلوب الثاني هو عمل المؤلف. فهو يكمّم الخبراء الموجَّهين (routed experts) بشكل عدواني، حتى 1.56 بت لكل وزن وفق مخطط IQ1_S، ويستخدم صيغة ملفات خاصة به. وبحساب تقريبي، فإن 284 مليار وزن بواقع بت ونصف وزيادة بسيطة تعطي أكثر قليلًا من 50 غيغابايت. وهذا يتسع في 64 غيغابايت، ويبقى هامش للسياق وللنظام.

الخلاصة بسيطة: MoE يحلّ مشكلة الحوسبة، والتكميم يحلّ مشكلة حجم الذاكرة. أما بطاقة الرسومات فلا حاجة إليها في هذا المخطط.

أين الفخ

ثمة عدة تحفظات ينبغي إبقاؤها في البال.

أولًا، كلمة «lossless» في ملف README. فهي تعني فقط أن اللوجيتات (logits) تتطابق مع النسخة غير المصحّحة على الأوزان المكمَّمة نفسها. أي أن تصحيحات النوى لا تُفسد شيئًا. أما مقارنة النتيجة بالنموذج كامل الدقة فلم يجرِها أحد. وعند 1.56 بت لكل وزن يكاد يكون من المؤكد وجود خسارة في الجودة، والسؤال فقط عن حجمها. وفي البرمجة والاستدلال الطويل واستدعاء الأدوات قد يكون حتى التدهور الطفيف حاسمًا.

ثانيًا، جميع الأرقام حصل عليها المؤلف بنفسه. ولا توجد حتى الآن إعادات مستقلة للتجربة، لذا قد تختلف السرعة واستهلاك الذاكرة على عتاد آخر.

ثالثًا، التوافق. فالملفات المكمَّمة لا تُفتح في llama.cpp العادي ولا في Ollama ولا في LM Studio. المطلوب هو بناء المشروع نفسه، ما يعني القبول بنسخة متفرعة (fork) ومتابعة دعمها.

ماذا نفعل بذلك

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

الخطة العملية: انتظار إعادات مستقلة للتجربة، وإن كان لديك جهاز فارغ بذاكرة 64 غيغابايت فشغّل النموذج بنفسك على مهامك وقارنه بواجهة API أو بنماذج أصغر. فالجودة على بياناتك هي التي ستحدد إن كانت النسخة بدقة 1.56 بت تستحق الاهتمام. وقد تكون سرعة 9–15 رمزًا في الثانية مقبولة للوكلاء العاملين دون اتصال أو للمعالجة الدفعية، لكنها غير مناسبة للمنتجات التفاعلية ذات العشرات من المستخدمين.

أما الاتجاه العام فواضح. فالذاكرة وبطاقات الرسومات تزداد غلاءً، والتحسينات البرمجية من هذا النوع بدأت تنافس العتاد. وحتى الآن هذا أقرب إلى ادعاء جميل منه إلى معيار جديد، لكن الاتجاه يستحق أن يبقى في دائرة المتابعة.