بنية تحتيةتحليل · على الرادارX: @ArtificialAnlys→ المصدر

Vera Rubin NVL72 تنتج رموزًا أكثر بخمس مرات لكل GPU مقارنة بـ GB300 على DeepSeek V4.1 Flash

عرضت NVIDIA نتائج جديدة لـ Vera Rubin NVL72 على DeepSeek V4.1 Flash، ويتوقف الفارق عن GB300 بشدة على نمط التشغيل. فعندما يحتاج كل وكيل إلى 260 رمزًا في الثانية، توفر Rubin إنتاجية أعلى بخمس مرات لكل GPU. وعند 80 رمزًا/ثانية يصبح التفوق 1.7x، ولوكيل واحد تبلغ النتيجة 1٬249 مقابل 848 رمزًا/ثانية، أي 1.47x. وكلما كان مطلوبًا من الوكيل الرد أسرع، زادت الميزة.

معالج بواسطة الذكاء الاصطناعي من X: @ArtificialAnlys؛ بتحرير Hamidun News
Vera Rubin NVL72 تنتج رموزًا أكثر بخمس مرات لكل GPU مقارنة بـ GB300 على DeepSeek V4.1 Flash
المصدر: X: @ArtificialAnlys. كولاج: Hamidun News.
استمع للمقال
بطاقة الحقائق والأرقام
المعيارالتفاصيل
المصدر الأصليX: @ArtificialAnlys ↗
رئيس التحرير
260 رمزًا/ثانية لكل وكيلإنتاجية أعلى بـ 5.0x لكل GPU
80 رمزًا/ثانية لكل وكيليتراجع التفوق إلى 1.7x
وكيل واحد1٬249 رمزًا/ثانية مقابل 848 لـ GB300 (1.47x)

اعتاد الجميع مقارنة المسرّعات برقم واحد: «أسرع بكذا مرة». وتُظهر بيانات Artificial Analysis الجديدة حول Vera Rubin NVL72 بوضوح لماذا لا يكفي رقم واحد. فقد قدّمت NVIDIA إعدادات محدّثة لـ Rubin مع نموذج DeepSeek V4.1 Flash، وتتوقف النتيجة على السرعة التي تَعِد بها كل مستخدم أو وكيل.

ما الذي جرى قياسه

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

تجري المقارنة مع النتائج المحسّنة لـ GB300، أي مع جيل جرى تحسينه برمجيًا بالفعل. وهذا أكثر إنصافًا من مقارنته بأرقام إطلاقه الأولى.

الأرقام

عند 260 رمزًا في الثانية لكل وكيل، تنتج Vera Rubin رموزًا أكثر بـ 5.0 مرات لكل GPU من GB300. وعند 80 رمزًا/ثانية يتقلص الفارق إلى 1.7x. أما في حالة الوكيل الواحد فالنتيجة: 1٬249 رمزًا/ثانية لـ Rubin مقابل 848 لـ GB300، أي 1.47x.

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

لماذا يهم هذا الوكلاء

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

وفي هذا النمط، بحسب الأرقام، تُظهر Rubin قدراتها: فـ 5x لكل GPU تعني أن الحجم نفسه من جلسات الوكلاء السريعة يمكن خدمته بعدد أقل بكثير من البطاقات. وبالنسبة لمزوّد الاستدلال، ينعكس ذلك مباشرة على تكلفة الرمز وعلى الباقات ذات السرعة المضمونة التي يستطيع تقديمها.

القيود

ينبغي تذكّر بضعة أمور. أولًا، هذه نتائج قدّمتها NVIDIA نفسها، والإعدادات مُنتقاة لنموذج محدد هو DeepSeek V4.1 Flash. ومع نموذج آخر أو حجم سياق مختلف قد تختلف النسب. ثانيًا، ينقل المنشور نسبًا لا سعرًا: فلا يمكن أن نعرف من البيانات كم يكلف رف NVL72 على Rubin ومتى سيتوفر في السحابة. ثالثًا، تُظهر نسبة 1.47x للوكيل الواحد أن الترقية تعطي أثرًا أقل بكثير في الأحمال ذات التوازي المنخفض.

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

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

القصة

أسئلة وأجوبة حول الخبر

ما أبرز التفاصيل حول ما الذي جرى قياسه؟

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

ما أبرز التفاصيل حول الأرقام؟

عند 260 رمزًا في الثانية لكل وكيل، تنتج Vera Rubin رموزًا أكثر بـ 5.0 مرات لكل GPU من GB300. وعند 80 رمزًا/ثانية يتقلص الفارق إلى 1.7x. أما في حالة الوكيل الواحد فالنتيجة: 1٬249 رمزًا/ثانية لـ Rubin مقابل 848 لـ GB300، أي 1.47x. الصورة واضحة. كلما ارتفعت السرعة المطلوب ضمانها لكل وكيل، تفوقت البنية الجديدة أكثر. فعند السرعات المنخفضة تكون الميزة أكثر تواضعًا، وعند العالية تكون متعددة الأضعاف. ولا يشرح المنشور السبب، ولا ينبغي التخمين حول الأسباب دون تفاصيل الإعدادات. لكن الخلاصة العملية لا تتغير.

ما أبرز التفاصيل حول لماذا يهم هذا الوكلاء؟

تتأثر سيناريوهات الوكلاء تحديدًا بالسرعة لكل جلسة. فالوكيل يجري عشرات الاستدعاءات المتتالية: يخطط، ويستخدم الأدوات، ويتحقق من النتيجة، ويعيد الكتابة. وإذا كانت كل خطوة تُولَّد ببطء، تتراكم التأخيرات، وينتظر المستخدم دقائق بدل ثوانٍ. لذلك فإن نمط «سريع ولكل واحد» أقرب إلى واقع الوكلاء من نمط «أقصى عدد رموز إجمالًا» المناسب للمعالجة الدفعية. وفي هذا النمط، بحسب الأرقام، تُظهر Rubin قدراتها: فـ 5x لكل GPU تعني أن الحجم نفسه من جلسات الوكلاء السريعة يمكن خدمته بعدد أقل بكثير من البطاقات.

ZK
جمال حميدون — مدير المنتجات في Alpina Digital ومدير منتج AlpinaGPT. يبني منتجات الذكاء الاصطناعي منذ 2019. بدأ Hamidun News كمشروع شخصي ثم أصبح مُجمِّعًا إنتاجيًا بأكثر من 6000 قارئ.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
ما رأيك؟
جارٍ تحميل التعليقات…