لماذا يبدو نموذجك المحلي أغبى مما هو عليه: أين يخسر مسار الاستدلال جودته

تُظهر سلسلة تجارب نُشرت في منتدى Level1Techs أن النموذج الذي يعمل محلياً يبدو غالباً أضعف مما هو في الحقيقة — والسبب في كثير من الأحيان هو مسار الاستدلال نفسه لا النموذج. ويشغّل كاتب الموضوع، وهو مستخدم باسم thr3e، الأوزان ذاتها بإعدادات تشغيل مختلفة ويقيس النقطة التي تبدأ فيها المخرجات بالتباعد.

لا يوجد تنفيذان متطابقان

يستخدم الكاتب عبارة "التنفيذ المرجعي" للدلالة على المختبر الذي ينشر النموذج ويستضيفه بنفسه ويعلن نتائج القياسات الأصلية: عتاده وبرمجياته مختلفان عن عتادك. وكثيراً ما تخلط الإعدادات المنزلية بين أجيال مختلفة من كروت الرسوميات، كما أن مجموعات التعليمات المختلفة تحسب رياضيات الرمز التالي بطريقة مغايرة حتى مع أوزان متطابقة. وقد احتوى حاوي vLLM من إصدار nightly المستخدم في التجارب على 734 حزمة، منها 252 حزمة بايثون — أي 734 قاعدة برمجية لكل منها أخطاؤها الخاصة.

ثلاثة اختبارات: خلفيات الانتباه وذاكرة KV والتكميم

قارن الاختبار الأول ثلاث خلفيات انتباه — FlashAttention 2 وFlash Inference وTriton Attention — على نموذج Qwen3.6-27B بصيغة BF16 على كرت RTX PRO 6000 Blackwell، من دون تغيير أي شيء آخر. وكان عبء العمل سياقاً بنحو 100 ألف رمز مأخوذاً من مسار عمل حقيقي يتضمن استدعاءات أدوات. في آلاف الرموز الأولى اتفقت كل الخلفيات، ثم بدأت تتباعد في أجزاء لاحقة من الطلب. وأعادت إعادة تشغيل الخلفية ذاتها قيماً متطابقة بتّاً ببتّ، أي إن الفرق يأتي من رياضيات مرحلة المعالجة المسبقة لا من العشوائية.

وفي الاختبار الثاني كُوِّمت ذاكرة KV وحدها: نجحت نسخة int8 في النهاية في التعافي من خطأ في استدعاء أداة، أما int4 فلم تتعافَ. وقارن الاختبار الثالث خمسة تنسيقات للأوزان: كان INT8 W8A16 الأفضل، بينما جاء NVFP4 من Nvidia في المرتبة الأخيرة، إذ "انقلب" نحو 50% من الرموز عند سياق يبلغ 88 ألف رمز. ونفّذ كل من NVFP4 وAWQ W4A16 أمراً خاطئاً على جهاز Cisco: أمر 'show run' بدل 'show arp'.

رمز واحد منقلب ومهمة فاشلة

في الجزء الثاني سجّل الكاتب 100% من قيم اللوغيت أثناء استدعاءات الأدوات وفرّع عمليات التوليد ليرى إلى أين ذهب كل إصدار. في إحدى الحالات استهدف تشغيل بخلفية FlashAttention 2 العنوان GigabitEthernet0/1/4 بدل GigabitEthernet0/0/1.201، ثم نفّذ 'show run' بدل 'show mac address table'؛ وفي حالة أخرى فشل في تعيين وصف للواجهة. ومع التوازي التنسوري نجحت المهمة ذاتها عند TP1 وفشلت عند TP2 ونجحت مجدداً عند TP4 — وهو ما يشير عادة، عند التتبع الأعمق، إلى NCCL.

كيف نقيس على نحو صحيح

النصيحة في الموضوع هي تشغيل قياسات قياسية تمثّل عبء العمل الفعلي: ضبط temperature على الصفر ولصق ثلاثة طلبات تجريبية ليس بديلاً جيداً عن العمل الوكيلي، الذي يحتاج استدعاء أدوات بسياق طويل واختبارات معرفية متخصصة. ويُستحسن استخدام إعدادات أخذ العينات وقالب المحادثة الواردة في بطاقة النموذج — فقيمة temperature المنخفضة جداً هي سبب دوران بعض النماذج في حلقة داخل مخرجات THINK. كما أشار المعلّقون إلى أن تباين KL يقيس مقدار انتقال التوزيع عن المرجع لا صحته، وأنه اتجاهي؛ أما اختلاف الرمز الأول فهو مقياس منفصل وأكثر صرامة. وBF16 مرجع للأمانة الرقمية لا "عرّاف": يمكن لنموذج مكمَّم أن يبتعد عنه وينتج مع ذلك جواباً أفضل.