MiniCPM-V 4.7 1B مقابل UI-Venus 2 9B: أحدهما يتّسع في الجيب، والآخر يحتاج إلى رفّ

إن المقارنة بين MiniCPM-V 4.7 1B وUI-Venus 2 9B ليست متقاربة، وهذا هو الأمر المفيد فيها. MiniCPM-V 4.7 1B هو نموذج رؤية-لغة عام بعدد معلمات يبلغ 1.55 مليار من OpenBMB، رُفع في 6 أكتوبر 2026، ومؤرخ في 12 أكتوبر في ملاحظات إصدار البائع، برخصة Apache 2.0، وصغير بما يكفي ليعمل داخل تطبيق هاتف. UI-Venus 2 9B هو وكيل واجهة رسومية بعدد معلمات يبلغ 9.41 مليار من inclusionAI، صدر في 26 أغسطس 2026، ومُدرَّب تحديدًا للنظر إلى الشاشة وتقرير مكان النقر أو الكتابة أو السحب، ويتوقع وحدة GPU مع خادم vLLM أمامه.إن حالات فشل الذكاء الاصطناعي الموثقة وحوادث الوكلاء الكامنة وراء إصدارات كهذا الإصدار مجموعة في the OrcaRouter AI Incident Archive حيث تحمل كل مدخلة مصادرها الخاصة ودرجة خطورتها ودرجة ثقتها وعلامتها المتنازع عليها.

وضعهما في الجملة نفسها يستدعي السؤال الخاطئ — أيهما أفضل — بينما السؤال الصحيح هو ما الغرض الذي يخدمه كل منهما. إن نموذج رؤية عامًا يتّسع في 1.8 غيغابايت من الذاكرة المكمّمة، ووكيل شاشة يسجّل 73.0 على ScreenSpot-Pro، ليسا بديلين. إنهما طبقتان مختلفتان في مكدّس أتمتة الهواتف المحمولة، والجزء المثير للاهتمام هو أين تقع الحدود بين هاتين الطبقتين فعليًا.

وظيفتان تبدوان متشابهتين من بعيد

يمكن لكلا النموذجين استقبال لقطة شاشة وإرجاع نص عنها. وهنا ينتهي التشابه.

يقرأ MiniCPM-V 4.7 1B الصورة ويصفها أو ينسخها أو يستخرج منها المعلومات أو يجيب عنها. اسأله عن إجمالي إيصال، أو عن محتوى حقل في نموذج، أو عمّا إذا كان مخطط ما يتجه صعودًا، أو عمّا تقوله صفحة من ملف PDF، وسيقدّم إجابة. يتضمن عناصر تحكم في التقطيع للصور عالية الدقة، ونسبة ضغط رموز بصرية قابلة للتبديل بين 4× و16×، ومعلمات لأخذ عينات الإطارات من الفيديو. وتغطي وثائقه المحادثة بصورة واحدة، والمحادثة بصور متعددة، والفيديو، والتعرّف الضوئي على الحروف (OCR)، وتحليل ملفات PDF، والإسناد البصري — أي عبء عمل لقراءة المستندات والشاشات.

يقرأ UI-Venus 2 9B الشاشة ويُصدر إجراءً. وتصف بطاقته حلقة مغلقة: مراقبة الواجهة، والاستدلال على حالة المهمة، وتنفيذ إجراء، ودمج التغذية الراجعة من البيئة في القرار التالي. المخرجات نقاط وتسلسلات إجراءات، لا نثر. وتوفر inclusionAI حوله مطالبات مرجعية ومحللات إجراءات وأمثلة قابلة للتشغيل لمهام الهاتف المحمول والحاسوب والمتصفح والإسناد (grounding) والكابتشا. النموذج سياسة، والإطار المحيط به يشكّل نصف المنتج.

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

الترخيص هو المرشح الأول، وليس المعيار

تحتوي بطاقة UI-Venus 2 9B على قسم لحالة الإصدار أغفلته معظم التغطيات. وتقول تحت "أوزان النموذج" إن الأوزان مضمنة؛ وتقول تحت "الترخيص" إن ترخيص أوزان النموذج بانتظار التأكيد النهائي وسيُضاف قبل الإصدار العام، وإن إعلان Apache-2.0 لم يُنقل عمدًا لأن المواد المصدرية تحتوي على بيانات ترخيص متعارضة.

اقرأ ذلك مرتين. أوزان النموذج قابلة للتنزيل، ومعايير الأداء منشورة، والتقرير التقني على arXiv، والترخيص لم يُحسم بعد. بالنسبة لفريق بحثي، هذا مقبول. أما بالنسبة لشركة تخطط لشحن وكيل شاشة داخل منتج تجاري، فهذا يعني أن المراجعة القانونية لا يمكن أن تُغلق. قد ينتهي الأمر بال模型 إلى Apache 2.0، أو قد لا يحدث ذلك، ولا توجد طريقة لمعرفة ذلك من المواد المتاحة اليوم.

يُطرح MiniCPM-V 4.7 1B بموجب رخصة Apache 2.0 دون أي غموض من هذا القبيل. فهذا السطر وحده يستبعد أحد النموذجين من فئة واسعة من الأعمال التجارية — لا لأنه أسوأ، بل لأن الترخيص المعلّق يمثّل خطرًا على الجدول الزمني لا يضع أحد له ميزانية.

حسابات العتاد، قبل احتساب أي درجة

• الأوزان — 1.55B كثيف، بنحو 3.1 GB بتنسيق BF16، و0.67 GB عند Q4_K_M، إضافة إلى مُسقِط رؤية بحجم 0.90–1.11 GB، مقابل 9.41B، ونحو 18.8 GB BF16 موزعة على أربع شرائح safetensors • أين يعمل — تطبيقات iOS وAndroid وHarmonyOS؛ دعم شرائح من اليوم الأول من Rockchip وHoumo وIntel وAMD وArm، مقابل مسار تقديم عبر GPU، موثّق مع vLLM عند --max-model-len 262144 و--reasoning-parser qwen3 • السياق — 262,144 رمزًا نظريًا، مع ذاكرة KV تكلّف أكثر من الأوزان عند الطول الكامل، مقابل 262,144 رمزًا موروثة من قاعدة Qwen3.5-9B • حزمة الرؤية — مُشفّر من 27 طبقة بحجم مخفي 1152 على مربّعات بحجم 980 بكسل مع ضغط رموز داخل المُشفّر، مقابل برج رؤية Qwen3.5-9B، المنقول من النموذج الأساسي • الترخيص — Apache 2.0 مقابل تأكيد معلّق، مع حجب إعلان Apache-2.0 صراحةً • أسلوب التقييم — خمسة أرقام سردية إضافة إلى مقارنات عبر المخططات فقط، مقابل ملحق رقمي كامل يغطي الجوال والحاسوب والويب والإسناد وCAPTCHA والسلامة • التقييم المستقل — لا يوجد لأي من النموذجين حتى وقت كتابة هذا النص، مقابل لا شيء، رغم أن التقرير الفني على arXiv 2609.00028 يُعد عملاً جوهريًا قابلًا للتحقق من طرف ثالث

الفجوة هنا تبلغ نحو مرتبة مقدار في الذاكرة: 1.8 جيجابايت مكمّمة مقابل 18.8 جيجابايت بصيغة BF16، أو نحو 5 جيجابايت بدقة 4 بت إذا قمت بالتكميم. هذا هو الفرق بين تطبيق وخدمة. وهو أيضًا سبب مناقشة النموذجين عادةً في مقالات مختلفة — أحدهما مسألة نشر على الأطراف والآخر مسألة تكلفة استدلال.

حيث يبرّر 9B حجمه

أرقام UI-Venus 2 9B، وكلها مُبلَّغ عنها من الجهة المورّدة في بطاقته وتقريره الفني، تضعها قرب قمة فئة واجهات المستخدم الرسومية التي تقل عن 10 مليارات معلمة. على ScreenSpot-Pro، الذي يقيس تحديد موضع العناصر في البرمجيات الاحترافية عالية الدقة، يسجّل 73.0. وعلى VenusBench-GD، يسجّل 77.1. وعلى OSWorld-G-R، يسجّل 78.5. وعلى AndroidWorld، يسجّل 80.2. وعلى تقسيم WebVoyager المحدَّث المكوّن من 595 مهمة، يسجّل 90.8. وعلى OSWorld-Verified، يسجّل 70.8. وعلى VenusBench-CAPTCHA الخاص به، يسجّل 78.1 في pass@1 عبر ثمانية أنواع من التفاعل.

ليست هذه أرقامًا يُنتجها نموذج عام بحجم 1B، وليست المقصود منها ذلك. وما يجعلها موثوقة لا تزيينية هو وصف التدريب: مجموعة تطبيقات جوال متعددة اللغات تضم أكثر من 170 تطبيقًا، ومجموعة نطاقات ويب تضم أكثر من 4000 نطاق عبر 19 فئة، وثلاث مراحل تدريب (تدريب أوسط متعدد الوسائط، وتعلم معزز دون اتصال عبر خمس عائلات مهام، وتقطير متعدد المعلمين على السياسة)، ومخطط تحقق مبني على نقاط مفاتيح بصرية ذات صلة بالمهمة مع تصويت متعدد النماذج بدلًا من حكم واحد ينظر إلى الشاشة النهائية. وتُبلغ البطاقة أيضًا عن نتائج السلامة — معدل نجاح الهجوم 11.3% على OSHarm و48.8% على OSBlind، مقابل 25.3% و79.4% للأساس Qwen3.5-9B — وتصوغها على أنها مقارنة بذلك الأساس لا كادعاء متانة مطلق، وهو التأطير الصحيح.

لا شيء من هذا ينتقل إلى نموذج 1B. فالقدرة الوكيلية في واجهات GUI تُدرَّب، ولا تنشأ تلقائيًا من الكفاءة العامة في الرؤية، ولا تغني أي درجة من دقة OCR عن سياسة تعرف ما الذي يفعله زر «التالي».

حيث يفوز 1B على أي حال

ثلاثة مراكز، وهي ليست جوائز ترضية.

زمن الاستجابة والتوافر. النموذج المحلي بحجم 1B لا يتضمن أي رحلة ذهاب وإياب عبر الشبكة، ولا انتظارًا في قائمة، ولا انقطاعًا من مزوّد الخدمة، ولا تكلفة لكل طلب. وبالنسبة لميزة مسح تُستخدم خمسين مرة يوميًا، فهذه هي تجربة المنتج بأكملها. أما نموذج 9B خلف خادم vLLM فهو سريع — لكنه سريع بالطريقة نفسها التي يكون بها أي نموذج مستضاف سريعًا، ويتوقف عن كونه سريعًا عندما ينقطع الاتصال.

الخصوصية بالتصميم. يمكن أن يبقى الإيصال أو وثيقة الهوية أو نموذج طبي أو لقطة شاشة لمحادثة خاصة على الجهاز. هذا ليس عبارة تسويقية؛ إنه الفرق بين ميزة يمكنك إطلاقها في صناعة خاضعة للتنظيم وتلك التي لا يمكنك. تقييم السلامة الخاص بـ UI-Venus 2 9B يتعلق بسوء سلوك النموذج على جانب الخادم. خاصية الخصوصية لدى 1B هي أن الصورة لا تغادر الهاتف أبدًا.

التكلفة على الهامش. قراءة لقطة شاشة باستخدام نموذج مستضاف بحجم 9B تكلّف مالًا مقابل كل طلب، ومع كل طلب، إلى الأبد. أما قراءتها باستخدام نموذج محلي بحجم 1B فتكلّف البطارية. عند الحجم المنخفض يكون الخيار المستضاف أرخص؛ وعند الحجم المرتفع — ماسح ضوئي في تطبيق ميداني، أو أداة إتاحة، أو دفعة من عشرة آلاف إيصال — يكون النموذج المحلي هو الوحيد الذي تقترب تكلفته الحدية من الصفر.

حزمة التقنيات التي ينتهي الأمر بمعظم الفرق إلى بنائها فعليًا

ليس اختيارًا بين هذين، بل تراكبٌ لهما.

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

في ذلك التسليم تبرر طبقة التوجيه وجودها، ويجدر بنا أن نكون دقيقين بشأن ما تفعله وما لا تفعله. تعرض OrcaRouter أكثر من 200 نموذج مستضاف عبر نقطة نهاية واحدة متوافقة مع OpenAI وبهامش ربح 0%، بتمرير سعر القائمة الخاص بكل مزوّد دون تغيير، مع تجاوز فشل تلقائي ولغة توجيه (DSL) يمكنها الاحتفاظ بمسار أساسي ومسار احتياطي في استدعاء واحد. النمط الذي يتيحه هذا غير مبهر ومفيد: يجرّب الهاتف نموذجه المحلي 1B، ويصعّد التطبيق الحالات الصعبة إلى نموذج رؤية مستضاف عبر المفتاح نفسه الذي يستخدمه لكل شيء آخر، فيصبح مزوّد يمر بفترة سيئة حدث تجاوز فشل بدلًا من انقطاع. لا MiniCPM-V 4.7 1B ولا UI-Venus 2 9B موجودان في ذلك الكتالوج — فكلاهما نقطتا تفتيش تشغّلهما بنفسك — لذا فإن الموجّه هو الطبقة المحيطة بالمكدس، وليس وسيلة لاستدعاء أي من النموذجين.

نمطان من أنماط الفشل يستحقان التخطيط لهما

الأول هو نموذج عام بحجم 1B يُستخدم كوكيل. سيقرأ الشاشة بشكل صحيح ثم لن تكون لديه أي فكرة عما يجب فعله بها. إذا كان منتجك يحتاج إلى إكمال تدفق ما بدلاً من وصفه، فإن 1B هو الأداة الخاطئة، ولا يمكن لأي توجيه أن يصلح ذلك.

الثاني وكيل بحجم 9B أُطلق اعتمادًا على حالة الترخيص المذكورة في بطاقة الطراز. تقول بطاقة UI-Venus 2 9B إن الترخيص قيد الانتظار، وإن إقرار Apache-2.0 قد حُجب عمدًا. وإلى أن يُحسم ذلك، يظل الطراز أثرًا بحثيًا بالنسبة للأغراض التجارية، مهما كان رقم ScreenSpot-Pro جيدًا. أما الفرق التي تخطط على أساس «أنه سيكون على الأرجح Apache 2.0» فإنها تتحمل مخاطرة في الجدول الزمني لم تُقدّر لها ثمنًا.

إلى ماذا يتلخص الاختيار في الواقع

إذا كان السؤال هو "هل يمكنني قراءة لقطة الشاشة هذه على هاتف، دون اتصال، مجانًا، بترخيص يمكنني توزيعه" — فإن MiniCPM-V 4.7 1B يجيب بنعم، بحجم يقارب 1.8 غيغابايت بعد التكميم، بموجب Apache 2.0، والشيء الوحيد الذي عليك التحقق منه هو هامش الذاكرة المتاح في جهازك.

إذا كان السؤال هو «هل يستطيع هذا النموذج تشغيل الواجهة بدلًا من وصفها؟» — فإن UI-Venus 2 9B هو النموذج الذي يمتلك التدريب واختبارات الأداء وأداة الاختبار، وهو يحتاج إلى GPU وقرار ترخيص قبل أن يحتاج إلى أي شيء آخر.

إذا كان الجواب "كلاهما، في منتج واحد" — فأنت إذن تبني نظامًا من طبقتين، طبقة الـ1B تتولى الإدراك على الجهاز، والوكيل يتولى الفعل على خادم، ويصبح العمل الهندسي هو التسليم والتسلّم بينهما بدلًا من الاختيار بينهما.

تبدو المقارنة غير متكافئة لأنها كذلك بالفعل. فالنموذج العام بحجم 1B والمتخصص في واجهات GUI بحجم 9B ليسا في فئة الوزن نفسها، ولا فئة النشر نفسها، ولا وضع الترخيص نفسه. سيكون الخطأ هو قراءة ذلك على أنه "أحدهما أفضل". إنهما يجيبان عن سؤالين مختلفين، وأسرع طريقة للاختيار هي أن تكتب أي سؤال تطرحه فعلاً.