Nemotron 3.5 Super VL في SageMaker: نموذج بحجم 120B للمستندات ووكلاء واجهات المستخدم خلال 10 دقائق

إذا كنت تبني وكيلًا لا يكتفي بالدردشة، بل ينظر إلى لقطة شاشة، أو يقرأ فاتورة، أو يحلل رسمًا بيانيًا، فعادةً ما تضطر إلى تجميع مجموعة متنافرة: نظام OCR منفصل، ونموذج لغوي منفصل، وكود لاصق بينهما. تقدّم NVIDIA وAWS طريقًا مختلفًا. أصبح Nemotron 3.5 Super VL متاحًا الآن في SageMaker JumpStart، ويمكن نشره بنقرات قليلة في Studio أو بعدة أسطر بلغة Python.

ما بداخل النموذج

هذا نموذج متعدد الوسائط: يستقبل الصور والفيديو والنص، ويُخرج نصًا. يبلغ إجمالي معاملاته 120 مليار معامل، لكن بفضل بنية Mixture-of-Experts لا يعمل لكل رمز سوى 12 مليارًا. الجزء اللغوي هجين: تتناوب طبقات Mamba-2 مع طبقات MoE، إضافةً إلى ثماني طبقات انتباه. أما الرؤية فيتولاها المشفّر C-RADIO. السياق المعلن يصل إلى مليون رمز، لكننا سنعود إلى هذا الرقم لاحقًا.

يستطيع النموذج استدعاء الأدوات، وإخراج JSON وفق مخطط محدد، ويمكن تشغيل الاستدلال أو إيقافه لكل طلب عبر المعامل enable_thinking. عند استخراج الحقول من فاتورة، الأفضل إيقاف الاستدلال: فهو أسرع وأرخص. أما للأسئلة المعقدة حول الرسوم البيانية فالأفضل إبقاؤه.

يتوفر في JumpStart خياران. تزن نسخة NVFP4 نحو 75 غيغابايت وهي مصممة للاستدلال السريع، بينما تشغل نسخة BF16 نحو 249 غيغابايت وهي لمن يريد إعادة التدريب الدقيق أو التقطير أو إجراء تكميمه الخاص.

العتاد والسرعة والجودة

تعمل نسخة NVFP4 افتراضيًا على ml.g7.24xlarge: أربع وحدات GPU من طراز RTX PRO 4500 Blackwell وذاكرة 128 غيغابايت. أما BF16 فتتطلب ml.p5en.48xlarge بثماني وحدات H200. وفق قياسات AWS (250 رمزًا في الإدخال، و1500 في الإخراج، وخمسة تدفقات متوازية) تبدو الصورة كالتالي:

• g7.24xlarge، NVFP4: نحو 63 رمزًا/ثانية لكل طلب، و0.45 ثانية حتى الرمز الأول؛
• g7.48xlarge، NVFP4: نحو 64 رمزًا/ثانية، و0.51 ثانية؛
• p5en.48xlarge، BF16: نحو 141 رمزًا/ثانية، و0.53 ثانية.

لا يصح مقارنة NVFP4 وBF16 بهذه الأرقام: فالعتاد مختلف. أما من حيث الجودة فالنسخة المكمّمة لا تخسر تقريبًا. في MMLongBench-Doc تحصل النسختان على 62.82، وفي CharXiv تتراجع NVFP4 قليلًا (79.88 مقابل 80.82)، وفي OSWorld-Verified، اختبار التحكم بالحاسوب، تتفوق قليلًا (52.30 مقابل 51.14). هذه المقاييس مأخوذة من بطاقات NVIDIA، فتعامل معها على أنها معلنة وليست مُتحقَّقًا منها بشكل مستقل.

عقبات يجدر معرفتها قبل النشر

أولًا: لن تحصل في JumpStart على مليون رمز من السياق. فإعدادات الخدمة مصممة لما بين 520 و15600 رمز. وصفحة بدقة 1536×1024 تستهلك نحو 1536 رمزًا، لذا لن يتسع مستند طويل متعدد الصفحات في طلب واحد.

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

ثالثًا: المطالبات الطويلة تُبطئ النموذج. فمع إدخال بحجم 10000 رمز يبلغ الزمن حتى الرمز الأول على g7.24xlarge نحو 12.6 ثانية. هذا كثير للدردشة التفاعلية، لكنه مقبول لمعالجة المستندات على دفعات.

رابعًا: رأس MTP الخاص بـ speculative decoding موجود في نقطة التحقق (checkpoint)، لكنه غير مفعّل في إعدادات JumpStart. ولا تحمّل نقطة النهاية محوّلات LoRA، إذ تُخدَّم الأوزان الأساسية فقط. كما أن حصص نسخ g7 في الحسابات الجديدة تبدأ من الصفر، لذا يجب إرسال طلب زيادة مسبقًا. ويتطلب الـ SDK حزمة SageMaker Python SDK v3 بالإصدار 3.25 أو أحدث، ويجب تحديد نوع النسخة صراحةً في Compute، وإلا فسيفشل البناء على ml.m5.large الافتراضية.

ماذا نفعل بهذا

إذا كان لديك تدفق من الفواتير أو العقود أو التقارير ولا تريد إخراج البيانات من AWS، فهذه طريقة سريعة لاختبار فرضيتك: انشر NVFP4 على g7.24xlarge، وحوّل الصفحات إلى PNG، واطلب JSON. أما بالنسبة لوكلاء GUI، فنتيجة OSWorld البالغة نحو 52% تشير إلى أن النموذج صالح للتجارب لا للأتمتة دون إشراف. الترخيص هو OpenMDW 1.1، فاقرأه بعناية على بطاقة النموذج قبل النشر. ومن المفيد لمدير المنتج أن يحسب مسبقًا ميزانية وقت خمول نقطة النهاية: فنموذج بحجم 120B على أربع وحدات GPU يكلّف مالًا حتى عندما لا يرسل أحد أي طلبات.