llama-modchip يشغّل DeepSeek بـ284 مليار معلمة ضمن 64 غيغابايت من الذاكرة ومن دون GPU

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

يقول المطوّر إنه يشغّل DeepSeek-V4-Flash، الذي يضم 284 مليار معلمة، على نظام بذاكرة وصول عشوائي سعتها 64 غيغابايت، وبسرعة توليد تبلغ 9.1–14.7 توكنًا في الثانية. هذه نتائج مطوّر المشروع؛ ولم نُعِد إنتاجها بأنفسنا. المصدر الأصلي: مستودع llama-modchip.

كيف يتّسع نموذج كبير في الذاكرة

يعتمد المشروع على ضغط الأوزان وتعديل نوى العمليات الحسابية في llama.cpp. ويستخدم DeepSeek بنية مزيج الخبراء MoE، حيث يعمل جزء من المعلمات عند معالجة كل توكن. لذلك، لا يفسّر العدد الإجمالي للمعلمات وحده حجم العبء الحسابي بصورة كافية. ويقدّر المطوّر حجم النموذج بعد الضغط بـ56.56 غيبيبايت (GiB)، ويعرض قياسات أُجريت على معالج AMD Ryzen 9 9955HX. شروط الاختبار موضّحة في README.

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

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

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

أين تقف وعود السرعة

حُقّق الحدّان الأدنى والأعلى للنطاق المعلن باستخدام أوضاع تسريع مختلفة. وهناك قيد آخر يتعلق بالتوافق: تتطلب ملفات النموذج الخاصة بناء المشروع من المصدر؛ ولن تتمكن الإصدارات القياسية من Ollama وLM Studio من تحميلها. هذه التحفظات واردة في الوثائق.

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

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

لمن تستحق التجربة

المرشّح الأوضح هو فريق لديه خادم يعمل بمعالج مركزي CPU ومهام تسمح ببعض الانتظار. ومن أمثلتها إعداد المسودات، وتحليل النصوص الداخلية، أو معالجة قائمة من المستندات. هذه استخدامات محتملة، وليست نتائج مؤكدة للمشروع.

من المنطقي البدء ببيئة اختبار منفصلة وعينة صغيرة من مواد حقيقية. وينبغي توثيق إصدار البناء ومعلمات التشغيل والنتائج حتى يمكن تكرار التجربة. وبعد ذلك، تُحسب تكلفة الإجابة المفيدة مع مراعاة الإيجار والصيانة والتحقق البشري.

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