vLLM يعمل على Vera Rubin NVL72: إنتاجية أعلى بمقدار 7.8 مرة لكل GPU

أعلن مشروع vLLM، أشهر محرك مفتوح المصدر لاستدلال النماذج اللغوية الكبيرة، دعمَه لنظام الرفوف NVIDIA Vera Rubin NVL72. ووفقًا لمدونة المشروع، تبلغ الإنتاجية لكل GPU على حمل AgentX ما يعادل 7.8 مرة قدر ما يحققه الجيل السابق GB200 NVL72. ويتضمن الإصدار دعم النماذج منذ اليوم الأول، ونوى FlashInfer (kernels) المضبوطة لمعمارية Rubin، وتوجيه MoE الذي يراعي المحلية.

الرقم لافت، لكن لا بد أولًا من فهم ما الذي قيس بالضبط.

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

تجري المقارنة على مستوى GPU الواحد، لا على مستوى الرف بأكمله. وتنتمي المنصتان إلى فئة NVL72: أي 72 مسرّعًا مترابطًا في نطاق NVLink واحد. لذلك تبدو المقارنة منصفة من الناحية الشكلية: رف مقابل رف، ومسرّع مقابل مسرّع.

واختير AgentX حملًا للاختبار. ومن الاسم والسياق، يبدو أنه سيناريو استدلال وكيلي (agentic): سياقات طويلة، وعدد كبير من استدعاءات النموذج المتتابعة، واستخدام مكثف للذاكرة المؤقتة. ولا يتضمن الإعلان الأصلي تفاصيل في هذا الشأن، وهذه هي الثغرة الرئيسية. فإعدادات النماذج، ودقة الحساب (FP8 أو FP4 أو مختلطة)، وأحجام الدفعات، وقيود زمن الاستجابة، كلها تحدد بشكل مباشر مدى إمكانية تعميم الرقم على بيئة الإنتاج لديكم.

أبرز معطيات الإصدار:

• المنصة: NVIDIA Vera Rubin NVL72 مقابل GB200 NVL72.
• المحرك: vLLM مع دعم Rubin منذ اليوم الأول.
• النوى: FlashInfer المضبوطة لـ Rubin.
• MoE: توزيع الخبراء مع مراعاة المحلية (locality-aware).
• المقياس: الإنتاجية لكل GPU.
• النتيجة: 7.8x على حمل AgentX.

من أين يأتي التسارع

يذكر المؤلفون ثلاثة عوامل. الأول هو عتاد Rubin نفسه. أما حصة العتاد وحصة البرمجيات من هذا المكسب، فلم يفصل الإعلان بينهما، وهذا أمر مهم. فإذا تحقق جزء كبير من المكسب بفضل تحسينات النوى والتوجيه، فقد يظهر جزء منه لاحقًا على Blackwell أيضًا. وعندئذ سيكون الفارق الفعلي بين الجيلين أقل من 7.8x.

الثاني هو FlashInfer. تنفذ هذه المكتبة عمليات الانتباه (attention) وما يتصل بها، وتتوقف على جودة هذه النوى النسبة التي تتحول من القدرة النظرية للشريحة إلى رموز (tokens) فعلية. وعادةً ما تحقق النوى المكتوبة لمعمارية بعينها أوضح مكسب على العتاد الجديد.

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

أين تكمن التفاصيل الدقيقة

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

ومع ذلك، فإن دعم Day-0 بحد ذاته أمر مهم. ففي السابق كان العتاد الجديد ينتظر أشهرًا حتى تنضج البرمجيات، وكان الأداء الفعلي في تلك الفترة أدنى بكثير من الأداء المعلن. أما هنا، فالمنظومة البرمجية جاهزة مع وصول الرفوف.

ماذا ينبغي أن تفعل الفرق

إذا كنتم تخططون لشراء Rubin أو استئجاره، فلا تدرجوا 7.8x في خطة العمل. اطلبوا من المزوّد إجراء اختبار على نموذجكم وبنمط طلباتكم، وبقيود زمن الاستجابة نفسها المعتمدة في بيئة الإنتاج. وقارنوا تكلفة الرمز، لا عدد الرموز في الثانية لكل بطاقة.

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