باغودا فوكسل، ورموز أقل بنسبة 10%، والجملة الواحدة التي تدعمها OpenBMB فعليًا

الجملة الأكثر اقتباسًا عن MiniCPM-V 4.7 35B-A3B هذا الأسبوع ليست موجودة في بطاقة النموذج الخاصة به. إنها تغريدة نُشرت في 13 أكتوبر 2026، ونصّها: "MiniCPM-V 4.7 35B-A3B لم يستخدم عددًا أقل من التوكنات فحسب، بل أنتج أيضًا معبد باغودا فوكسليًا أفضل من Qwen 3.6 35B-A3." العرض الذي تشير إليه هو فيديو لنموذجين لغويين يكتب كل منهما كود معبد باغودا ياباني ثلاثي الأبعاد بالفوكسل، معروضين جنبًا إلى جنب. إنه ناتج مثير للاهتمام حقًا — فهو يظهر نموذجًا لغويًا بصريًا يعيد إنتاج بنية مشيَّدة ثلاثية الأبعاد انطلاقًا من مُوجّه صورة، وهي مهمة أصعب من كتابة وصف نصي لها. لكن يجدر الفصل بين ما هي عليه تلك التغريدة وما ليست عليه، لأن ثلاث ادعاءات مختلفة دُمجت في سطر واحد، ولها ثلاثة مستويات مختلفة من الدعم. MiniCPM-V 4.7 35B-A3B هو نقطة تحقق حقيقية من OpenBMB وعمره أسبوع تقريبًا؛ أما Qwen3.6-35B-A3B فهو منافس مفتوح الأوزان عمره تسعة أشهر، وأيضًا بترخيص Apache-2.0، وأيضًا مزيج متناثر من الخبراء بالحجم المعلن نفسه. كل ما يلي يتعلق بتحديد أي من ادعاءات الكفاءة المحيطة بهما قابل للتحقق، وأي منها مجرد صورة JPEG لمخطط بياني.

ثلاث دعاوى ترتدي جملة واحدة

التغريدة تجمع ثلاثة أشياء قابلة للفصل، وهي تستحق الفصل لأن واحدًا منها فقط موثّق.

• "استُخدم عدد أقل من الرموز" — هذا بيان قابل للقياس حول استهلاك الرموز لمهمة واحدة. الرقم المتداول إلى جانب العرض التوضيحي هو أقل بنسبة 10% من الرموز مقارنةً بـ Qwen3.6 35B-A3B. هذا الرقم مصدره منشئ طرف ثالث أجرى المقارنة، وليس من تقييم OpenBMB، وهو زوج مطالبات واحد، وليس معيارًا قياسيًا.

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

• «الكفاءة مضافًا إليها الجودة هي ساحة المعركة الحقيقية» — ذلك الجزء أطروحة، ويصادف أنها الأطروحة التي تدافع عنها OpenBMB كتابةً، مع أرقام مرفقة، في بطاقة النموذج. لكنها ليست الجملة التي انتشرت.

هذا مهم لأن الادعاءين الأولين هما الأكثر تذكّرًا، والثالث هو القابل للدفاع عنه. إذا كنت تقرر ما إذا كنت ستنفق 70 جيجابايت من التنزيل على نقطة تحقق، فإنك تريد الثالث.

ما الذي كتبته OpenBMB فعليًا، ومتى

التسلسل الزمني أولًا، لأن إعادة السرد اختصرته. رُفعت الأوزان بهدوء: openbmb/MiniCPM-V-4.7-1Bأُنشئ في 6 أكتوبر 2026 عند 17:40 UTC،openbmb/MiniCPM-V-4.7-35B-A3Bوأُنشئ في 7 أكتوبر عند 07:07 UTC. لم يكن أيّ منهما يحمل بطاقة نموذج، أو وسم ترخيص، أو معيار تقييم آنذاك — وقد جرى تناول هذا هنا في ذلك الوقت، وكان وضعًا غريبًا بالنسبة لرفع نموذج بعدد معاملات يبلغ 35 مليارًا. بعد ستة أيام، في 12 أكتوبر 2026، أودعت OpenBMB الوثائق دفعة واحدة: بطاقة نموذج، وترخيص Apache-2.0، ومخططات تقييم، وملف README للمستودع أُعيد كتابته بحيث يتصدّر السلسلة الجديدة، وإعلان. لم تتغيّر المعاملات ذلك اليوم. أما التفسير فقد تغيّر.

إذن، فالصياغة الصادقة ليست «أُطلق MiniCPM-V 4.7 35B-A3B هذا الأسبوع»، بل «أصبح MiniCPM-V 4.7 35B-A3B مقروءًا هذا الأسبوع». وكل ما يمكن الاستشهاد به عنه الآن إما رُفع في السادس والسابع لكنه غير موثّق، أو كُتب في الثاني عشر وهو ادعاء من المورّد.

الادعاء الذي تُقدِمه بطاقة النموذج بالفعل

هذه هي الجملة، منقولة حرفيًا من البطاقة، وهي أضيق نطاقًا من التغريدة: في وضع Instruct، فإن نسخة 35B-A3B «تحقق درجة إجمالية أعلى في وقت استدلال أقل من Qwen3.6 35B-A3B». هذا كل شيء. لا عدد توكنات، ولا هامش، ولا تفصيل لكل معيار في السرد. الدليل وراء ذلك هو مخطط مبعثر — متوسط درجة التقييم على المحور الرأسي، ووقت الاستدلال بالثواني على مقياس لوغاريتمي على المحور الأفقي — حيث يقع MiniCPM-V 4.7 35B-A3B أعلى وإلى يسار Qwen3.6-35B-A3B. تحدد حاشية المخطط نفسها المتوسط باعتباره متوسط خمسة معايير: MMStar وMMMU-Pro وCharXiv reasoning وBLINK وMathVista. تمثل الدوائر وضع Instruct، وتمثل المعينات وضع Thinking.

هذا ادعاء حقيقي ومحدد حول مقايضة ثنائية الأبعاد، وهو أقوى ما في البيان. ومن الجدير بالذكر أيضًا ما لا يستطيع الرسم البياني إخبارك به: لا توجد تسميات رقمية على النقاط المرسومة، لذا لا يمكنك قراءة درجة أو زمن، بل اتجاه فقط. والاتجاه، كما هو مرسوم، يرجّح كفة MiniCPM على كلا المحورين في آنٍ واحد.

وقد جرى قياسه من قِبَل البائع. تحمل أرقام التقييم في البطاقة السطر التالي: "النتائج مستمدة من تقارير عامة ومن تقييمنا المحلي باستخدام نقاط التحقق الرسمية." التقييم المحلي يعني عتاد OpenBMB، وإطار الاختبار الخاص بـ OpenBMB، واختيار الوضع الخاص بـ OpenBMB. هذا أمر طبيعي أن تفعله بطاقة نموذج، وأمر غير طبيعي أن يُغسَل ليصبح حقيقة. لم يُشغِّل أي طرف مستقل نقطتي التحقق هاتين على إطار اختبار مشترك. ولم تُفهرِس أي لوحة صدارة أيًّا من النتيجتين. وحتى كتابة هذه السطور، للادعاء مصدر واحد لا غير، والمصدر يبيع النموذج.

من أين يُفترض أن تأتي كفاءة استخدام الرموز

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

• جدولة الخبراء الاستشرافية (LES) — التقنية الأبرز. يخزّن مزيج الخبراء المتناثر عددًا أكبر بكثير من المعاملات مما يفعّله لكل رمز، وعلى جهاز لا يمكنه الاحتفاظ بكل خبير في الذاكرة، تُجلب الأوزان وتُطرد على شكل صفحات ويتعطل فك الترميز. تستخدم LES التنبؤ بالتوجيه عبر الطبقات لتحميل الخبراء الذين يُحتمل أن تحتاجهم الطبقة التالية مسبقًا، وتعطي الأولوية للحساب للخبراء الذين اختارهم الموجّه الحقيقي فعليًا والمحمّلين بالفعل. وتحرص OpenBMB على التوضيح بأن التنبؤ يوجّه التحميل المسبق والجدولة فقط؛ فتوجيه النموذج على مستوى الرمز لم يتغير، والخبراء الذين فاتهم المتنبئ لا يزالون يُحمّلون ويُقيّمون. تدّعي البطاقة تحقيق تسريع 5× على الأجهزة الحقيقية بفضل هذا، دون فقدان في القدرات.

• التكميم الدقيق على مستوى الطبقات — يقلّص بصمة أوزان الخبراء وحركة البيانات في الذاكرة، وهو النصف الآخر من جعل نمط التحميل على الجهاز ملائمًا.

• أخذ العينات التخمينية DSpark — مسار مُقترن لنموذج المسودة، نُشر بشكل منفصل باسم openbmb/MiniCPM-V-4.7-35B-A3B-DSpark، وأُدمج إلى جانب أعمال الجدولة والتكميم.

عند تجميعها، تنتج الرقم الأبرز في الإصدار: أكثر من 13 رمزًا في الثانية باستهلاك نحو 3 غيغابايت من الذاكرة على iPhone 17 Pro Max. وهذا رقم مورّد، على عتاد المورّد، وببرمجيات المورّد — تطبيق كتبته OpenBMB. إنه نوع الادعاء الذي إما أن يكون المنتج كله أو لا شيء على الإطلاق، ولا توجد حاليًا أي طريقة لأي شخص خارج الشركة للتحقق منه، لأن إعادة إنتاجه تتطلب حزمة التشغيل على الجهاز التي يشغّلها العرض التوضيحي للهاتف.

كفاءة الرموز أمرٌ واقعيّ، لكنها هنا مصفوفة لا كمية قياسية

هناك تفصيل في هذا الإصدار جرى تسطيحه من كل ملخص له، وهو التفصيل الذي يحكم فعليًا اقتصاديات الرمز.

• يدعم MiniCPM-V 4.7 35B-A3B الضغط المختلط للرموز المرئية بنمطي 4x و16x، القابل للاختيار لكل طلب. يدمج إعداد 16x الرموز المرئية من أجل السرعة؛ أما 4x فيحتفظ بأربعة أضعاف هذا العدد، من أجل التفاصيل. الإعداد الافتراضي في بطاقة النموذج هو 16x، ويجب تمرير المعامل إلى كلٍّ من قالب الدردشة واستدعاء التوليد، وإلا فلن يتوافق عدد العناصر النائبة مع مُشفِّر الرؤية.

• يسجّل جدول المقارنة بين الرؤية واللغة الخاص بالمورّد إعداد الضغط المستخدم في صف كل نموذج. في ذلك الجدول، يقع صف MiniCPM-V 4.7 35B-A3B عند 4x — الإعداد الحافظ للتفاصيل، أي المكلف — ويقع صف Qwen3.6 35B-A3B عند 16x. ويُدرج صف Gemma 4 بسعة 31B عند 9x؛ وصفّا Qwen بسعة 27B عند 4x.

• تنصّ حاشية بوضوح على أن MiniCPM-V 4.7 يدعم أيًّا من الإعدادين، بينما لا تدعم النماذج الأخرى في الجدول سوى نسبة ضغط ثابتة.

اقرأ ذلك معًا، فتتغير الصورة. إذا كان صف MiniCPM يستمد درجاته في الرؤية واللغة عند الإعداد الشره للرموز، بينما يستمد صف Qwen درجاته عند الإعداد المقتصد للرموز، فإن العمودين يقارنان عندئذ كميات مختلفة من التفاصيل البصرية، ولم تعد قصة الكفاءة "المدخل نفسه، رموز أقل" — بل "مدخل قابل للتعديل، وهذا هو العمود الذي يفوز في الجودة". هذا ادعاء أكثر إثارة للاهتمام وأكثر صدقًا من ادعاء التغريدة، وقد نشرته OpenBMB في حاشية بدلًا من أن تتصدر به.

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

الجدول، مع التحفظات المرفقة.

تُرفِق البطاقة جدولَي مورّد، أحدهما للغة البصرية والآخر للغة، وكلاهما في وضع Instruct، وكلاهما في مواجهة مجموعة تضم نموذجَي Qwen من فئة 35B-A3B، وGemma بسعة 31B، ونموذجَي Qwen بسعة 27B. قُرِئت الأرقام أدناه من مخطط PNG الخاص بالمورّد نفسه، والتحذير بنيوي: فالأرقام موجودة فقط كوحدات بكسل في ذلك المخطط، وليس كجدول، لذا استُخرج ما يلي عن طريق القراءة الآلية، وقد توجد أخطاء نسخ صغيرة.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91.20 مقابل Qwen3.6 35B-A3B عند 90.40. فارق 0.8 نقطة، وفقاً لاختبار المورّد نفسه.

• OmniDocBench v1.6 — حوالي 98.2 لـ MiniCPM مقابل حوالي 93.3 لطراز Qwen، وهي أكبر فجوة منفردة في الجدول وأكثر ما قد يهم إذا تكررت النتيجة، لأن تحليل المستندات هو المجال الذي تُنفق فيه ميزانيات الرموز عادةً.

• MMMU — نحو 80.2 مقابل 80.0، تعادل تام عند دقة صورة رسم بياني.

• MMMU-Pro — نحو 69.7 مقابل 67.7، في صفٍّ يقع فيه Qwen بحجم 27B أعلى من كليهما.

• جدول اللغات — بالهيئة نفسها، مع الخلايا الأكثر بروزًا في اتباع التعليمات والبرمجة. يُدرَج IFBench عند نحو 47.7 مقابل 35.3، وLiveCodeBench-v6 عند نحو 97.0 مقابل 54.3. وهذان الفارقان كبيران بما يكفي لأن يُعاملا بوصفهما الخليتين الأقل مصداقية في الإصدار إلى أن يشغّلهما شخص آخر: فارق قدره 43 نقطة على معيار برمجي بين نموذجين مفتوحين من نوع MoE متقاربين في الحجم، قياسًا من أحد الطرفين، ادّعاء يحتاج إلى أداة ثانية.

مُبلَّغ عنها من المورّد، ومُختبَرة على منصة اختبار المورّد، وغير مُعاد إنتاجها. هذا كل ما في الأمر. إذا صمدت هذه الأرقام أمام اختبار مستقل، فإن الادعاء بحدود باريتو صحيح، ويصبح فيديو الباغودا مجرّد حاشية. وإذا لم تصمد، فليس هناك سوى فيديو الباغودا.

ما تقوله أرقام التبني، وهو لا يقول شيئًا عن الجودة

في هذه المقارنة، ثمة رقم واحد لا يجادل فيه أحد، وهو ليس معيارًا مرجعيًا. يُظهر عدّاد التنزيلات في Hugging Face، عند قراءته في 13 أكتوبر 2026، الرقم 630 لـopenbmb/MiniCPM-V-4.7-35B-A3Bمقابل نحو 3.6 مليون لـQwen/Qwen3.6-35B-A3B— وهو مستودع أُنشئ في 15 أبريل 2026، وبالتالي فهو متقدم بنحو تسعة أشهر على منحنى التبني. تقيس هذه الفجوة الزمن لا الجدارة، وهي السبب في أن مسألة الكفاءة تُطرح في هذا الاتجاه أصلًا: على الوافد الجديد أن يحاجّ على أساس كل رمز تحديدًا لأنه لم يحظ بتسعة أشهر ليكون الخيار الافتراضي.

هناك أيضًا تناقض داخلي صغير في القائمة يستحق الإشارة إليه. يحمل المستودع وسم «On-Device Model» الموروث من بقية العائلة، ونموذج MoE متناثر بـ35.2 مليار معلمة ضمن 70.4 غيغابايت من أوزان BF16 ليس «على الجهاز» بأي معنى يعرفه مَن يقوم بالتنزيل. قصة العمل على الجهاز حقيقية، لكنها تمر عبر التكميم وبث الخبراء فوق نقطة التحقق، لا عبر نقطة التحقق نفسها. احسب الميزانية على أساس النسخة المكمّمة والتطبيق، لا على أساس الوسم.

ما العمل بشأن ذلك هذا الأسبوع

الموقف العملي ضيق وواضح. إذا كنت تريد التحقق من ادعاء الكفاءة، فلا يوجد شيء يمكن التحقق منه بعد — فهو مجرد مخطط مورّد واحد، والرقم الوحيد المصحوب برقم لكل مهمة (رموز أقل بنسبة 10%، pagoda واحدة) يأتي من عرض توضيحي واحد لطرف ثالث. وإذا كنت تريد تشغيل النموذج، فإن الأوزان بموجب Apache-2.0، والبنية موثَّقة، وإعداد تقليل العينات (downsampling) لك أن تختاره، وهو رافعة حقيقية لا تحظى بالتقدير الكافي: 16x عندما تكون الإنتاجية مهمة، و4x عندما يعرض لك المخطط مستندًا.

نصف هذه المقارنة يمكن الوصول إليه اليوم عبر واجهة برمجية مستضافة، والنصف الآخر لا، ويستحق الأمر أن نكون دقيقين في تحديد أيّهما أيّ.qwen/qwen3.6-35b-a3bهو نموذج مستضاف على OrcaRouter — وهو مُدرج في الكتالوج خلف مفتاح واحد، بسعر Qwen المعلن نفسه دون أي إضافة عليه، ويوزّع الطلبات إلى أي مزوّد يكون سليمًا لا إلى مزوّد حدّدته أنت. أما MiniCPM-V 4.7 فليس مستضافًا لدينا؛ بل هو نقطة تحقق بأوزان مفتوحة تخدمها بنفسك. هذا التفاوت هو الشيء المفيد هنا. يمكنك إدراج جانب Qwen من هذه المقارنة ضمن خط أساس بعد ظهر اليوم، وتشغيل منصة الاختبار الخاصة بـ OpenBMB على بياناتك في مواجهته، وتترك مخطط المورّد يكون الفرضية لا الجواب.

وهو، بالنظر إلى أن الجدال كله يدور حول الكفاءة على عتادك، القياس الوحيد الذي كان سيحسم الأمر.