Cline تحصد 11 840 توكن/ث من محطة NVIDIA DGX Station واحدة

رفع فريق Cline السرعة الإجمالية لتوليد التوكنات في نموذج مفتوح المصدر على وحدة GPU واحدة إلى 11 840 توكن إخراج في الثانية. وسُجّل هذا الرقم القياسي في 15 أكتوبر على محطة NVIDIA أتيح للمهندسين الوصول إليها بفضل التعاون مع NVIDIA. وكانت نقطة الانطلاق مرتفعة أصلاً: فنسخة vLLM 0.32.0rc1 الخالصة حققت 6 058 توكن/ث في اختبار بـ512 توكن إدخال و512 توكن إخراج عند 256 مساراً متزامناً. والنتيجة النهائية أعلى بنحو 1,95 مرة.

صُمّم النموذج ليكون أداة محلية سريعة لمهام متنوعة: تحليل المستندات، والبرمجة، والمحاسبة المالية. ولديه على جهاز واحد ميزانية ذاكرة GPU قدرها 252 غيغابايت. وفي العرض التوضيحي الذي قدمته Cline، من دون تسريع للفيديو، تعمل على هذه المحطة 32 نسخة متوازية من Cline فوق Nemotron 3.5 Super VL.

خمس خطوات من 6 058 إلى 11 840

لا تصف Cline اكتشافاً واحداً، بل سلسلة تجارب نجحت منها خمس:

• رأس MTP المدمج. جاء Multi-token prediction مع النموذج. بدأ المهندسون بـ MTP3، أي ثلاثة توكنات مسودة في كل خطوة، وثبّتوا OMP1: فخيط CPU واحد أنسب، لأن تعدد الخيوط يضيف كلفة تنسيق إضافية.
• الجدولة غير المتزامنة. عند التزامن العالي تنشغل GPU بنوى الحوسبة، وتنشغل CPU بالجدولة. ويتيح الوضع غير المتزامن للمجدوِل ألا ينتظر حتى تنتهي GPU من عملها.
• نواة Mamba على FlashInfer. النموذج هجين: طبقات attention تستخدم KV-cache، بينما تحتفظ طبقات Mamba بحالة تكرارية وبسجل قصير للالتفاف (convolution). وقد أحدثت العودة إلى نواة FlashInfer قفزة ملحوظة. أما سبب ذلك تحديداً فلم يفهمه المؤلفون تماماً، وقد لا يتكرر الأثر على عتاد آخر.
• MTP1 بدل MTP3. خطوة تخالف البديهة، رفعت الإنتاجية مرة أخرى.
• حالة Mamba بصيغة FP16 بدل FP32 مع تقريب عشوائي (stochastic rounding). يخفض ذلك الدقة، وقد يخفض نتائج الاختبارات المعيارية، لكن الثمن بدا مقبولاً لهدف «أقصى عدد من التوكنات في الثانية».

لماذا كان عدد أقل من التوكنات المسودة أسرع؟

يبدو فك الترميز التخميني مكافأة مجانية: كلما زاد عدد التوكنات المسودة المتوقعة، زادت فرصة قبول عدة توكنات دفعة واحدة. لكن كل مسودة تحتاج إلى تحقق. وإذا فشل التحقق، يضيع وقت النموذج هباءً. وعند 256 مساراً متوازياً تكون GPU ممتلئة أصلاً بعمل مفيد، فلا يعوّض التحقق الإضافي كلفته. لذلك تفوّق MTP1 على MTP3.

قد يبدو مكسب MTP عند الحمل المنخفض مختلفاً تماماً عنه عند التزامن العالي. وقد تضر الوصفة نفسها في نمط آخر من حركة الطلبات. وتقول Cline صراحةً إن هندسة الاستدلال شديدة الارتباط بالسياق، وإن التوسّع يعتمد على شكل حركة الطلبات.

الاقتصاد: أقل بنسبة 66% من سعر API

تحسب Cline أهم نتيجة عملية بحساب تقريبي سريع. فإذا قارنّا كلفة API بكلفة GPU محمّلة بالكامل، تظهر حسومات بنسبة 66% على الاستدلال. والشرط صارم: يجب أن تكون GPU مشغولة تقريباً طوال الوقت. عندها يكون من الأرخص اعتماد وصفة Cline ودفع كلفة العتاد، بدلاً من المرور عبر موجّه النماذج (router) ودفع ثمن كل استدعاء.

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

ما الذي يجب التحقق منه قبل تكرار الوصفة

لا يمكن نسخ الوصفة بشكل أعمى. أولاً، يجب تثبيت ملفك الخاص: أطوال المدخلات والإجابات، وعدد المسارات المتزامنة، والتأخير المقبول. بعد ذلك يفيد اختبار المفاتيح الخمسة نفسها واحداً تلو الآخر. ففي حالة التزامن العالي تجدر المقارنة بين MTP1 وMTP3، أما مع عدد صغير من المسارات فقد يكون الأثر معاكساً. واستبدال FP32 بـ FP16 في حالة Mamba يتطلب بالضرورة إعادة تشغيل مجموعات التقييم، لأن السرعة هنا اشتُريت بثمن الدقة. وأخيراً، لا يصح حساب التوفير بنسبة 66% إلا عند استخدام مرتفع لـ GPU: فإذا كانت المحطة خاملة، يعود API ليصبح الخيار الأوفر.