Colibri بلغة C الخالصة يشغّل نماذج MoE بأكثر من 700 مليار معامل دون وحدة GPU

عادةً ما ينتهي الحديث عن تشغيل نماذج open-weight الضخمة بعبارة واحدة: «تحتاج إلى رف من وحدات GPU». أما مستودع Colibri فيقترح طريقًا آخر. بحسب منشور في مجمّع AI Radar، جمع المشروع نحو 47.4 ألف نجمة، منها 802 في يوم واحد. وهذه إشارة قوية على الاهتمام، رغم أن المنشور نفسه لم يُشاهَد سوى 29 مرة ولا يتضمن تفاصيل تُذكر. لنستعرض ما هو معروف وما يستحق أن تتحقق منه بنفسك.

ما الذي يُعلَن عنه

يُوصف Colibri بأنه محرك بلغة C الخالصة لتشغيل نماذج MoE الكبيرة على حواسيب عادية. والفكرة الأساسية: يجري تحميل الخبراء من القرص عند الحاجة. وتشمل قائمة العائلات المدعومة GLM وKimi وDeepSeek وQwen. أما الطرح الرئيسي لكاتب المنشور فهو أن النماذج بحجم 700B فأكثر يمكن تشغيلها دون بطاقة رسومية.

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

كيف يعمل ذلك بمثال بسيط

تُبنى MoE (Mixture of Experts) على النحو التالي: في كل طبقة من النموذج عشرات أو مئات «الخبراء»، أي كتل منفصلة من الأوزان. وبالنسبة إلى كل رمز، يختار موجِّه (router) خاص بضعةً منهم فقط. أما الباقون فيبقون خاملين في تلك اللحظة.

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

وتُظهر حسبة بسيطة حجم الأمر. فـ700 مليار معامل بصيغة 4 بت تشغل نحو 350 غيغابايت. وهذا لا يتسع في ذاكرة حاسوب عادي، لكنه يتسع على قرص NVMe جيد. وفي كل رمز لا يُقرأ فعليًا سوى جزء من هذه الأوزان، وعلى ذلك تقوم الفكرة كلها.

القيود التي يسكت عنها المنشور

أولًا، السرعة. يقرأ قرص NVMe بسرعة أبطأ بمراتب من ذاكرة GPU. وإذا كان كل رمز يتطلب خبراء جددًا، فسيصطدم التوليد بحدود القرص. ولا يتضمن المنشور أي رقم لعدد الرموز في الثانية، وهو المقياس الأهم. وربما تكون النتيجة مقبولة للمعالجة الدفعية أو التجارب، لكن الدردشة التفاعلية أو حلقة الوكيل (agent) ذات عشرات الاستدعاءات قد تصبح مرهقة.

ثانيًا، القرص. فأنت تحتاج إلى مئات الغيغابايتات من المساحة الحرة ووحدة تخزين سريعة. وعلى قرص SATA قديم أو HDD ستكون الصورة أسوأ بوضوح.

ثالثًا، الجودة والتوافق. فلا يُعرف أي صيغ للتكميم (quantization) مدعومة، ولا إلى أي حد تتطابق النتيجة مع التنفيذات المرجعية. وعبارة «يعمل مع DeepSeek وKimi وGLM وQwen» لا تعني بعدُ أن كل إصدار من كل نموذج يعمل.

وأخيرًا، المصدر نفسه. يبدو المنشور ملخصًا آليًا لمستودع رائج. والأفضل التحقق من عدد النجوم وقائمة النماذج مباشرةً على GitHub.

ماذا نفعل عمليًا

إذا كنت مطوّرًا أو مؤسسًا يقيّم نماذج LLM مستضافة ذاتيًا، فإن Colibri يستحق الإضافة إلى قائمة الاختبار السريع. والخطوات بسيطة:

• اقرأ ملف README وقائمة النماذج والصيغ المدعومة.
• خذ نموذج MoE متوسط الحجم وقِس عدد الرموز في الثانية على قرص SSD الخاص بك.
• قارن النتيجة باستئجار GPU أو باستخدام API عادية. فبالنسبة إلى المهام النادرة والبيانات الخاصة وسيناريوهات العمل دون اتصال، قد يكون القرص بدل البطاقة الرسومية أكثر جدوى.
• لا تعتمد المشروع في بيئة الإنتاج قبل أن ترى معايير أداء (benchmarks) مستقرة وسجل إيداعات (commits) نشطًا.

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