Cline ترفع سرعة نموذج مفتوح المصدر إلى 11840 رمزاً في الثانية على معالج رسومي واحد

انطلاقة قوية من نقطة أساس جيدة

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

أصبحت هذه التجربة ممكنة بفضل شراكة مع NVIDIA — حيث حصل فريق Cline على وصول إلى خادم قوي مزوّد بمعالج رسومي واحد وبذاكرة فيديو سعتها 252 جيجابايت. كانت المهمة بسيطة: استخراج أقصى عدد ممكن من الرموز في الثانية من هذا التكوين تحت حمل متوازٍ مرتفع.

نقطة بداية قوية بالفعل

منذ البداية، مع نسخة محرك vLLM 0.32.0rc1.dev190+g3f1bcfd82 والإعدادات الافتراضية، حقق النموذج 6058 رمزاً في الثانية في اختبار يضم 512 رمزاً كمدخلات و512 رمزاً كمخرجات مع 256 مساراً متزامناً من الطلبات. وكان هذا مفاجئاً لفريق Cline — فقد تبيّن أن التكوين الأساسي للنموذج كان بالفعل مُحسَّناً بشكل جيد للتعامل مع الأحمال المرتفعة، واعتبر الفريق هذا الرقم نقطة انطلاق جديرة بالاحترام، وليس فشلاً يجب تصحيحه ببطولية.

خمس خطوات رفعت السرعة إلى الضعف تقريباً

بعد ذلك، أجرى المهندسون سلسلة من التجارب، مع تغيير معيار واحد في كل مرة:

• التنبؤ بعدة رموز في آنٍ واحد (MTP3). يأتي النموذج مزوداً برأس قادر على التنبؤ بعدة رموز لاحقة دفعة واحدة. وقد أدى تفعيل وضع MTP3 مع تشغيل أحادي المسار (OMP1) — لتجنب تكاليف التنسيق بين المسارات — إلى تحقيق أول مكسب في السرعة.
• المُجدوِل غير المتزامن. في حالة وجود عدد كبير من الطلبات المتوازية، يكون المعالج الرسومي مشغولاً بالعمليات الحسابية في حين يتولى المعالج الرئيسي جدولة المهام. وقد أدى تحويل المُجدوِل إلى الوضع غير المتزامن إلى إزالة فترات الخمول التي كانت تحدث في المعالج الرسومي أثناء انتظاره للمعالج الرئيسي.
• استبدال وحدة Mamba بمحرك FlashInfer. يستخدم النموذج نوعين من الطبقات: طبقات انتباه (attention) عادية مزودة بذاكرة تخزين مؤقت KV، وطبقات Mamba التي تخزن الحالة بطريقة مختلفة — عبر ذاكرة تكرارية وعملية التفاف قصيرة على التاريخ. وأدى تبديل محرك الحساب لطبقات Mamba إلى FlashInfer بشكل غير متوقع إلى تحقيق تحسن ملحوظ في الأداء. ويعترف الفريق بصراحة بأنه ليس متأكداً تماماً لماذا نجح هذا التغيير بالتحديد — فمن المحتمل أن يكون التأثير مرتبطاً بتكوين معالج رسومي محدد ولن يتكرر على عتاد آخر.
• تقليل MTP من 3 إلى 1. يبدو منطقياً أن زيادة عدد الرموز التي يتنبأ بها النموذج مسبقاً تؤدي إلى توليد أسرع. ولكن الواقع هو العكس: فكل تنبؤ يحتاج إلى التحقق منه، وإذا فشل التحقق، يُهدر الوقت دون فائدة. ومع 256 مسار متوازٍ، يكون المعالج الرسومي مشغولاً بالفعل بعمل مفيد، فكانت الرهانات الإضافية على التنبؤات تُعيق العملية فقط. وأدى تقليل عمق التنبؤ إلى MTP1 إلى رفع السرعة مرة أخرى.
• حالة Mamba بصيغة FP16. الخطوة الأخيرة تمثلت في تحويل الحالة الداخلية لطبقات Mamba من دقة 32 بت إلى دقة 16 بت مع تقريب عشوائي (stochastic rounding). ويُقلّل هذا من دقة العمليات الحسابية، وقد يُضعف جودة إجابات النموذج قليلاً، لكن بالنسبة لهدف التجربة — وهو تحقيق أقصى سرعة ممكنة — اعتُبرت هذه المقايضة مبررة.

مجتمعة، رفعت هذه التعديلات الخمسة السرعة الإجمالية من 6058 إلى 11840 رمزاً في الثانية — وهو ما يقارب ضعف السرعة دون تغيير العتاد.

ما تعنيه هذه النتائج للمهندسين

الاستنتاج الرئيسي لفريق Cline لا يبدو كوصفة جاهزة، بل كتحذير: هندسة الاستدلال (inference) تعتمد بشكل كبير جداً على السياق. فالحيل التي نجحت هنا — MTP1 بدلاً من MTP3، FlashInfer بدلاً من نواة Mamba القياسية — قد تؤدي، على شكل مختلف من حركة البيانات (نسبة مختلفة بين رموز الإدخال والإخراج، أو عدد مختلف من الطلبات المتوازية)، إلى تقليل السرعة بدلاً من زيادتها. ولهذا ينصح فريق Cline بعدم نسخ تكوين الآخرين دون تمحيص، بل فهم شكل حركة البيانات الخاصة بك أولاً وضبط عملية الاستدلال وفقاً لها.

كما شارك الفريق ثلاث توقعات للمستقبل. أولاً، سيصبح تشغيل عشرات المسارات العاملة (agentic) المتوازية محلياً أمراً معتاداً — ومن الأمثلة على ذلك عرض توضيحي لـ32 جلسة متزامنة من Cline على نموذج Nemotron 3.5 Super VL على محطة واحدة من نوع NVIDIA DGX، مُسجَّلة دون تسريع للفيديو.

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