بقلم: سارة | محررة نماذج الذكاء الاصطناعي · صوت تحريري بإشراف بشري
أصدر فريق مشروع vLLM الإصدار التصحيحي v0.25.1 في الرابع عشر من يوليو 2026، وهو يحمل إصلاحَين محددَين فوق قاعدة v0.25.0، جاءا من مساهمَين اثنين أحدهما يُشارك لأول مرة.
الخلل الأول كان يُوقف تشغيل النماذج تمامًا عند غياب FFmpeg على مستوى النظام. المشكلة أن استيراد مكتبة TorchCodec كان يرفع خطأً من نوع RuntimeError فور التحميل حتى لو لم يكن TorchCodec مستخدمًا فعليًا في المشروع، ما يعني أن تشغيل نموذج مثل (#47888) vllm serve Qwen/Qwen3-VL-2B-Instruct كان يفشل دون سبب وظيفي حقيقي. الحل المعتمد الآن هو تأجيل الخطأ حتى اللحظة التي يُحتاج فيها TorchCodec فعلًا.
الخلل الثاني أخطر من ناحية الصمت الذي كان يعمل به: نمط الدمج المُسرَّع بين FlashInfer وعملية allreduce وطبقة RMSNorm والكمّ الثابت كان يُطبَّق أحيانًا على رسوم بيانية تحمل أنواع بيانات مختلطة، كمجرى BF16 مع أوزان RMSNorm من نوع FP32 بأسلوب Gemma/Qwen في نماذج NVFP4. النتيجة كانت تلفًا صامتًا في الحالة المخفية hidden state ومخرجات غير منطقية تتمثل في تكرار رمز !!!!!. الإصلاح (#48330) يضيف حارسًا للتحقق من تطابق الأنواع قبل تفعيل الدمج، بحيث تسلك الرسوم البيانية غير المتوافقة المسار الآمن، فيما تحتفظ النماذج المتجانسة بكامل أداء الدمج.
المساهم @Isotr0py كان وراء الإصلاح الأول، فيما قدّم المساهم الجديد @hugo-cen أولى مساهماته عبر الإصلاح الثاني. بالنسبة لأي فريق يُشغّل نماذج NVFP4 متعددة الأنواع أو نماذج بصرية تعتمد على TorchCodec، الترقية إلى هذا الإصدار ليست اختيارية.
