MiniCPM-V 4.7 يضع نموذج رؤية بحجم 35B في 3 غيغابايت: تفكيك ادعاء 100 توكن/ثانية

لا يمكن لنموذج بـ35 مليار معلمة أن يتسع في ثلاثة جيجابايت. ومع ذلك، يعمل MiniCPM-V 4.7 35B-A3B في نحو ثلاثة جيجابايت، وكلا العبارتين صحيحتان — وهذه هي الحيلة بأكملها، وهو السبب الذي يجعل الأرقام المتداولة حول هذا الإصدار تستحق التمهل عندها. النموذج هو أول إدخال متفرق لمزيج الخبراء من OpenBMB في سلسلة MiniCPM-V: 35.2 مليار معلمة مخزنة، ونحو 3 مليارات نشطة لكل رمز، وApache-2.0، والأوزان على Hugging Face. يقرأ الصور ومجموعات الصور المتعددة والفيديو، ويجيب بالنص. ومنذ 10 أكتوبر يعمل أيضًا في مشروع llama.cpp الرئيسي، حيث تعرّف عليه معظم الناس. يفصل ما يلي بين الأرقام الثلاثة التي يكررها الجميع — 3 GB و35B ورقم 100 tok/s — ويوضح أيّها نشرته OpenBMB فعلاً. أكثر من 200 نموذج مستضاف، مفتاح واحد، سعر قائمة المزوّد يُمرَّر بهامش ربح 0%. شاهد ما يوجّهه OrcaRouter تبقى نقطة التحقق ذات الأوزان المفتوحة على عتادك؛ أما المخرج المستضاف فهو نقطة نهاية واحدة. تُجمع حالات فشل الذكاء الاصطناعي وحوادث الوكلاء الموثّقة التي تقف خلف إصدارات كهذا الإصدار في أرشيف OrcaRouter لحوادث الذكاء الاصطناعي حيث يحمل كل إدخال مصادره الخاصة ودرجة خطورته ومستوى ثقته وعلامة كونه محل خلاف.

ثلاثة غيغابايت، وخمسة وثلاثون مليار معامل، ولا تناقض

لا تبدو هذه الحسابات مستحيلة إلا إذا افترضت أن «في الذاكرة» تعني «كلها». يُبقي MiniCPM-V 4.7 35B-A3B نحو 3 مليارات معامل مقيمة في الذاكرة، ويبثّ بقية الخبراء عند طلب الموجّه لها — والإطار الذي تعتمده بطاقة النموذج هو Lookahead Expert Scheduling، وهو متنبئ توجيه عبر الطبقات يجلب مسبقًا الخبراءَ التي يُرجَّح أن تحتاجها الطبقة التالية، ويُحمِّل ذلك بالتوازي مع حسابات جارية بالفعل. وتحرص البطاقة على التوضيح أن التنبؤ لا يقود سوى الجلب المسبق والجدولة؛ فلا تزال الرموز تتبع التوجيه الفعلي للنموذج، وأي خبير فاته المتنبئ يُحمَّل ويُقيَّم مثل أي خبير آخر.

لهذا التمييز نتيجة قابلة للقياس. ينشر مستودع GGUF النموذج كاملًا بكل تكميم شائع، ولا يبلغ حجم أي من تلك الملفات ثلاثة غيغابايت:

• Q4_K_M — 21.2 غيغابايت على القرص.

• Q8_0 — 36.9 جيجابايت.

• F16 — 69.4 غيغابايت.

• مُسقِط الرؤية — 0.9 غيغابايت بضغط 4x، و1.1 غيغابايت عند f16.

إذن، "3 GB" رقمٌ للذاكرة المقيمة في ظل البثّ الخبير على الهاتف، وليس حجم تنزيل ولا متطلب VRAM لسطح مكتب. وإذا كنت تخطط لعملية نشر، فالرقم الذي يحكم قرصك وتحميلك الأول هو 21.2 GB عند Q4_K_M، أما الرقم الذي يحكم بصمتك في الحالة المستقرة على الهاتف فهو نحو 3 GB المذكور من المورّد. كلاهما وارد في الإصدار. إنهما يجيبان عن سؤالين مختلفين، وقد دمجت معظم التغطيات بينهما في رقم واحد.

من أين تأتي 100 tok/s، ومن أين لا تأتي

هذا هو الجزء الذي يستحق أن نكون صريحين بشأنه. لا تنشر OpenBMB رقم 100 tok/s خاصًا بـ MiniCPM-V 4.7. الرقم الموجود على بطاقة النموذج هو 13+ tokens/s، على iPhone 17 Pro Max، بذاكرة تبلغ نحو 3 GB. هذا هو ادعاء الإنتاجية الوحيد على الجهاز الذي يقدمه الإصدار، وهو مقيس من قبل المورّد على عتاد لم يكرره أحد خارج المختبر.

توجد بالفعل أرقام أعلى، وهي تأتي من منتج مختلف. إن تفرّع llama.cpp-omni التابع لـ OpenBMB — وهو المستودع الذي يحمل تحسينات التشغيل على الجهاز — ينشر جدوله الخاص به لهدف 35B-A3B، مرتبًا وفقًا للتحسينات التي تكون مفعّلة:

• آيفون 18 برو ماكس، 12 غيغابايت — 3.38 tok/s كخط أساس، و11.34 مع Lookahead Expert Scheduling، و17.16 بإضافة الدقة المختلطة، و20.51 مع رأس المسودة DSpark أيضًا.

• iPad Pro 11-inch M4، ذاكرة 16 GB — 2.97 tok/s في خط الأساس، و9.81 مع LES، و14.92 مع الدقة المختلطة، و17.39 مع DSpark.

هذه هي أعلى الأرقام المنشورة على الجهاز لهذا الطراز، وأعلى سلم الأداء هو 20.51 tok/s — أي خُمس 100. الفجوة مهمة لأنها تغيّر الغرض من النموذج. عند 13 tok/s، يجيب تطبيق هاتف عن سؤال حول صورة في ثانيتين أو نحو ذلك. وعند 100 tok/s، قد تفكر فيه كقارئ أولي متدفق للفيديو. الأول منتج حقيقي. أما الثاني فليس ما تم شحنه، وأي شخص يضع ميزانيته بناءً على رقم التغريدة سيُصاب بخيبة أمل بمعامل خمسة.

القراءة الصادقة لادعاء 100 tok/s هي أنه ضغطٌ لثلاث وقائع منفصلة — 3 GB، ويعمل محليًا، وأسرع من الجيل السابق بفارق كبير — في رقم واحد لا يحتويه أي من المصادر. والتحسّن من جيل إلى جيل حقيقي وكبير: فالانتقال من 3.38 إلى 20.51 tok/s يمثل زيادة 6 أضعاف على نفس فئة الجهاز، وقد تحقق عبر تكديس ثلاث تقنيات لا عبر شريحة أكبر.

لم يكن الإصدار يومًا واحدًا، والتواريخ مهمة.

ظهر MiniCPM-V 4.7 بالطريقة التي تظهر بها كثير من الإصدارات مفتوحة الأوزان الآن: الملفات أولًا، والتفسير لاحقًا، ودعم الأُطر في مكانٍ ما بينهما.

• 6 أكتوبر، 17:40 UTC — يظهر نموذج 1B ومتغيراته AWQ وGPTQ وint4 على Hugging Face، بالإضافة إلى إصدارات GGUF عند 18:05.

• 7 أكتوبر، 07:07 بالتوقيت العالمي المنسق — مستودع 35B-A3B يُنشر. لا توجد بطاقة نموذج بعد.

• 8 أكتوبر — رؤوس فك الترميز التخميني DSpark لكلا الحجمين، ونسخة FP8 من 35B.

• 10 أكتوبر، 18:42 UTC — llama.cpp تدمج دعم النماذج.

• 12 أكتوبر — تُودِع OpenBMB بطاقة النموذج، وتُعلن ترخيص Apache-2.0، وتُعلن عن الإصدار كمنتج موثّق.

• 15 أكتوبر — ترتبط رؤوس DSpark من البطاقة الرئيسية، مع مسودات GGUF لكلا الهدفين.

يفسّر هذا الترتيب الكثير من الالتباس في التغطية الثانوية. فمن تعرّف على النموذج عبر llama.cpp في الأسبوع الثاني من أكتوبر كان يشغّل إصدارًا لم يكن موجودًا رسميًا بعد، بلا وسم ترخيص ولا مخطط قياسات أداء، وأرقام الإنتاجية لديه تعكس خيارات التكميم الخاصة بالإطار نفسه لا أي قياس أجراه OpenBMB.

دعم llama.cpp: تم الدمج، ولم يكتمل تمامًا

طلب السحب upstream الذي أضاف MiniCPM-V 4.7 واضح بشكل غير معتاد بشأن ما تغيّر، والجواب هو: لا شيء تقريبًا من الناحية المعمارية. النموذج شبه مطابق لـ MiniCPM-V 4.6؛ والفارق هو 3D RoPE، أي موضع بثلاث قيم لكل رمز — الوقت والصف والعمود — بدلًا من القيمة العددية المفردة التي تستخدمها معظم نماذج الرؤية واللغة. يمدّ الدعم مسار 4.6 الحالي لحمل هذا البُعد الإضافي. كما أشار طلب السحب إلى النموذج بأنه "قادم" عند فتحه في 25 سبتمبر، وهو تلميح معقول إلى مدى مبكرة تداول الأوزان.

يستحق هذا الأثر المتبقي أن تعرفه قبل أن تبني ميزة grounding عليه. منذ عملية الدمج تلك، تُسنِد نسخة المنبع من llama.cpp إلى رموز علامات الصورة مواضع خاطئة في مطالبات MiniCPM-V 4.7: فرموز الصورة نفسها تُوضَع بشكل صحيح، لكن <slice> و</slice> وعلامات نهاية الصف تُرقَّم كنص عادي بدلًا من إعطائها إحداثيات زوايا البلاطات كما يفعل التنفيذ المرجعي get_rope_index. العَرَض الظاهر هو أن الإحداثيات المُعادة تأتي منخفضة بانتظام عندما تسأل عن موضع شيء ما في صورة. يوجد إصلاح مرفق باختبار وحدة في طلب سحب مفتوح، بتاريخ 14 أكتوبر، واعتبارًا من 20 أكتوبر لا يزال مفتوحًا. إذا كان عبء العمل لديك هو «صِف هذا»، فلن تلاحظ. أما إذا كان «أعطني مربع الإحاطة»، فستلاحظ، وينبغي لك إما انتظار الدمج أو استخدام النسخة المتفرعة التي تحمل المسار المصحح.

ثمة أمر آخر ينجو من رحلة الذهاب والإياب: بالنسبة إلى نموذج 1B، فإن مُسقِط الرؤية هو التنزيل الأكبر. أوزان Q4_K_M حجمها 672 MB؛ أما مُسقِط f16 فحجمه 1.11 GB. لذلك فإن أصغر نشر مفيد لنموذج 1B يبلغ نحو 1.8 GB من الملفات، ومعظمها عيون لا لغة — تفصيل يخطئه أي توقع بأن «1B يعني 1 GB».

ما الذي يجب تشغيله، وعلى ماذا

إذا كان الهدف هو تجربته هذا الأسبوع، فإن المسار الأقل احتكاكًا هو llama.cpp أو Ollama مع مستودعات GGUF، مع توجيه العميل متعدد الوسائط إلى ملف mmproj المطابق. على وحدة معالجة رسومات بسعة 24 GB، يترك Q4_K_M عند 21.2 GB هامشًا ضئيلًا جدًا للسياق — فنافذة 8K توكن بالإضافة إلى بلاطات الصور لن تتسع بشكل مريح، لذا خطط لاستخدام Q4_K_S أو تكميم أصغر إذا كنت تريد أيضًا مطالبة طويلة. على جهاز Mac بسعة 32 GB أو أكثر، يكون Q8_0 خيارًا عمليًا وهو أقرب شيء إلى السلوك المرجعي. على الهاتف، لا تضطلع بعمل جدولة الخبراء إلا تطبيقات المورّد نفسها وفرع llama.cpp-omni؛ أما llama.cpp القياسي فيمنحك الدقة، لا سرعة 20 tok/s.

حيث تكسب طبقة التوجيه مكانها هنا هو على الجانب البعيد من الاستدعاء المحلي. نموذج نشط بحجم 3B على الهاتف ممتاز في الإطار الروتيني — اقرأ هذا الإيصال، هل يبدو هذا الرف ممتلئًا بالمخزون، ماذا تقول هذه اللافتة — وسيصادف أحيانًا صفحة لا يستطيع إكمالها. يضع OrcaRouter أكثر من 200 نموذج مستضاف خلف مفتاح واحد، ويمرر سعر القائمة لكل مزوّد دون أي هامش ربح بحيث يصبح تغيير سعر المورّد ساريًا في اليوم نفسه، ويتحول تلقائيًا عند تدهور أحد المصادر upstream. النمط الذي ينجح هو المحلي أولًا مع مخرج احتياطي مستضاف، وليس المحلي فقط. تبقى نقطة التحقق مفتوحة الأوزان ملكًا لك لتستضيفها؛ ويتولى الموجه كل ما يسلمه الهاتف.

موديل MiniCPM-V 4.7 لا يقدّمه OrcaRouter، ولن نُلمح إلى خلاف ذلك. إنه نقطة تحقّق (checkpoint) تشغّلها بنفسك.

ما الذي سيحسم الأرقام الثلاثة؟

إن قياسًا مستقلًا لنموذج 35B على هاتف محدد بالاسم، مع ذكر التطبيق والتكميم، من شأنه أن يحسم مسألة الإنتاجية — بما في ذلك ما إذا كانت 20.51 tok/s تصمد أمام ساعة توقيت شخص آخر. كما أن تعريفًا منشورًا لرقم 3 GB — هل هو مجموعة الذاكرة المقيمة، أم ذروة التخصيص، أم شيء آخر — من شأنه أن يحسم مسألة الذاكرة. وجدولًا لكل اختبار قياسي بدرجات حقيقية، بدلًا من المخططات الخمسة المرتبطة التي تأتي بها البطاقة حاليًا، من شأنه أن يتيح التحقق من ادعاء «أفضل من Qwen3.6 35B-A3B في وقت أقل» مقابل الترجيح الذي اختارته OpenBMB. لا شيء من ذلك موجود بعد. وإلى أن يوجد، فإن الجملة الدقيقة هي المملة: نموذج متناثر بحجم 35B يعمل على هاتف بمعدل مُبلَّغ عنه يتجاوز 13 رمزًا في الثانية ضمن نحو 3 GB، مع تنزيل بحجم 21 GB ومسار إطار عمل مدموج لا يزال فيه خطأ إحداثيات واحد مفتوح.