MiniCPM-V 4.7 1B على iPhone عادي: ما الذي يعنيه فعليًا «العمل بما يتجاوز Pro Max»

MiniCPM-V 4.7 1B هو نموذج رؤية ولغة يضم 1.55 مليار معامل، رفعه OpenBMB إلى Hugging Face في 6 أكتوبر 2026، وحدّد تاريخ 12 أكتوبر في ملاحظات الإصدار الخاصة به. لديه بطاقة نموذج، وأحد عشر إصدارًا شقيقًا مكمَّمًا، ووسم Ollama، وتطبيق عرض تجريبي على الجهاز. ما لا يمتلكه هو نسخة من الرواية تصمد عندما تحسب تكلفة العتاد. إن الادعاء المتداول في أوساط المطورين — بأن النموذج يعمل الآن في تطبيق OnDeviceLLM على هواتف iPhone العادية، وليس فقط على Pro Max بذاكرة 12 غيغابايت — هو الجزء الجدير بالفحص الدقيق، لأن «يعمل على هاتف» و«يعمل على هاتفك» يفصل بينهما نحو 3 غيغابايت من هامش الذاكرة التي لا تمتلكها معظم هواتف iPhone. تُجمع إخفاقات الذكاء الاصطناعي الموثقة وحوادث الوكلاء الكامنة وراء إصدارات مثل هذا الإصدار في OrcaRouter AI Incident Archive، حيث يحمل كل مدخل مصادره الخاصة ودرجة خطورته ودرجة ثقته وعلامة النزاع الخاصة به.

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

ما المعروف فعليًا، وما هو مجرد ادّعاء

النموذج حقيقي وقابل للتنزيل. تبلغ نقطة تحقق BF16 عدد 1,554,476,272 معاملًا، أي ما يعادل نحو 3.1 GB على القرص. ويحتوي المستودع على بطاقة نموذج كاملة — وهو أمر نادر في التاريخ الحديث لهذه العائلة — تحدد عمودًا فقريًا نصيًا Q​wen3.5، وبرج رؤية SigLIP2 بطبقات عددها 27 وعرض مخفي 1152، وبلاطات إدخال بحجم 980 بكسل، ونافذة سياق من 262,144 رمزًا، وترخيص Apache 2.0. ويؤرّخ إدخال README الخاص بـ OpenBMB الإصدار في 2026-10-12؛ وقد أُنشئ مستودع Hugging Face في 2026-10-06. والفجوة البالغة ستة أيام هي تأخر الرفع مقابل الإعلان الذي تُعرف به هذه العائلة، وهي السبب في أن مقالًا من أكتوبر يمكنه أن يصف مستودعًا عمره ستة أيام بأنه إطلاق هادئ.

مالا يثبته أي دليل مادي هو الادعاء المحدد بأن نموذج 1B يعمل في OnDeviceLLM على «أجهزة iPhone اليومية الأحدث من 12GB Pro Max». منشور أحد المطورين هو مصدر ذلك التأطير. المستودع العام لمشروع OnDeviceLLM — وهو حزمة بداية لتطبيقات دردشة وترجمة دون اتصال، وليس منتجًا يُشحن عبر App Store — لا يحمل أي نجمة، وآخر عملية push له كانت في 27 يوليو 2026. وهو يسبق أوزان MiniCPM-V 4.7 بعشرة أسابيع، لذا فإن أي دعم لهذا النموذج فيه حديث وغير موثّق. تعامل مع «يعمل بالفعل في OnDeviceLLM» على أنه تقرير من شخص قام بذلك، وليس كمسار نشر مدعوم من المورّد.

هذا التمييز مهم لأن أرقام المورّد الخاصة على الجهاز لا تتعلق بالطراز 1B على الإطلاق.

الرقم 3 GB يخص 35B وليس 1B

يرتبط الادعاء الرئيسي لـ OpenBMB — "أكثر من 13 رمزًا/ثانية بذاكرة لا تتجاوز 3 غيغابايت على iPhone 17 Pro Max" — بالنسخة 35B-A3B من مزيج الخبراء (Mixture-of-Experts)، التي تعمل على أكبر هاتف iPhone تبيعه Apple. والتقنية الكامنة وراء ذلك، Lookahead Expert Scheduling، تُبقي معظم أوزان الخبراء على SSD وتجلب مسبقًا تلك التي من المرجح أن تحتاجها الطبقة التالية. إنها قطعة هندسة أنظمة مبهرة، وهي السبب في استمرار ظهور اسم 35B في التغطيات المتعلقة بالهواتف.

لا يحتاج 1B إلى أي من ذلك. فهو نموذج كثيف يتّسع له الذاكرة بالكامل. على الورق، يجعل ذلك منه الأكثر ديمقراطية بين الاثنين، وهو السبب في أن زاوية «iPhone اليومي» لها أساس. لكن الحساب أقل ودًّا مما يوحي به التأطير:

• أوزان BF16 — 3.1 GB على القرص، وتشغل تقريبًا الحجم نفسه في الذاكرة بعد تحميلها، قبل أي ذاكرة KV cache أو تنشيطات الرؤية • Q8_0 GGUF — 1.08 GB من الأوزان، بالإضافة إلى مُسقِط رؤية بسعة 0.90 GB عند إعداد الضغط 4×، أو 1.11 GB عند 16× • Q4_K_M GGUF — 0.67 GB من الأوزان، مع الحمل الإضافي نفسه الخاص بمُسقِط الرؤية • مُسقِط الرؤية — هذا هو الجزء الذي ينساه الناس؛ فهو لا يتقلص مع تكميم نموذج اللغة، ويُحتسب مرة واحدة لكل نموذج محمّل • السياق — حتى 262,144 رمزًا نظريًا؛ كل رمز في ذاكرة KV cache هو ذاكرة إضافية لا تخصصها بطاقة النموذج في ميزانيتها

نسخة Q4 مزوّدة بمُسقِط 16× تبلغ أوزانها نحو 1.8 GB. أضف إليها ذاكرة KV مؤقتة عاملة لبضعة آلاف من التوكنات الخاصة بالمحادثة وعناصر نائبة للصور، فستجد نفسك تطلب من التطبيق شيئًا يتراوح بين 2.2 و2.8 GB. على جهاز Pro Max بسعة 12GB يُعد ذلك مريحًا. أما على iPhone بسعة 8GB، حيث يتنافس نظام التشغيل وكل تطبيق آخر مقيم في الذاكرة بالفعل على المجمع نفسه، فإن تطبيقًا يطلب 2.5 GB يطلب جزءًا كبيرًا مما تبقى. سيوفّر له iOS ذلك، أو سيطرد التطبيق (jetsam) تحت الضغط.

لماذا يُعد سطر RAM على iPhone هو المواصفة الحقيقية

لا تنشر Apple حجم ذاكرة الوصول العشوائي (RAM) في iPhone ضمن مواصفاتها التسويقية، ولم تشجّع المطورين قط على التعامل مع الهاتف بوصفه حاسوبًا قابلًا لعنونة الذاكرة. هذا هو القيد الذي يصطدم به ادعاء "ما يتجاوز 12GB Pro Max". فقد حملت فئة Pro Max، لعدة أجيال، ذاكرة أكبر من الطرازات القياسية، والفجوة بين "الهاتف في فيديو المراجعة" و"الهاتف في جيب القارئ" هي بالضبط الفجوة التي تعتمد عليها قصة هذا الطراز بشأن المعالجة على الجهاز.

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

لا تحسم بطاقة الطراز الأمر. فهي توثّق دعم iOS وAndroid وHarmonyOS، ودعم الشرائح من اليوم الأول من Rockchip وHoumo وIntel وAMD وArm، وتُحيل إلى مستودع نشر طرفي يتضمن تطبيقات وشيفرة مصدرية. لكنها لا تذكر في أي مكان الحد الأدنى من ذاكرة الجهاز، ولا مصفوفة أجهزة مختبَرة، ولا معدل الرموز لكل جهاز للطراز 1B. الجهاز الوحيد المذكور في مواد العرض الخاصة بالطراز 1B نفسه هو iPhone 17 Pro Max — وهو الجهاز نفسه الوارد في العنوان الرئيسي للطراز 35B.

ما يجيده النموذج فعليًا، عند 1B

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

أرقام OpenBMB المنشورة لطراز 1B، وكلها مُبلَّغ عنها من الجهة المصنّعة ولم يُعِد أحد إنتاجها بشكل مستقل حتى وقت كتابة هذا النص، تضع OCRBench عند 86.1، وMathVista عند 74.3، وCharXiv Reasoning عند 48.8، وLongVideoBench عند 53.4، وMotionBench عند 54.55. المقارنة الرئيسية التي تتصدر مواد الجهة المصنّعة هي ضد Qwen3.5 0.8B، الذي تقول إنها تتفوق عليه في كل من الدرجة الإجمالية وكفاءة الاستدلال، وضد MiniCPM-V 4.6، الذي تقول إنها تحسّن الأداء عليه عبر القدرات الأساسية. تلك هي معايير الجهة المصنّعة نفسها، شغّلتها الجهة المصنّعة، وتعرض بطاقة النموذج هذه النتائج كرسوم بيانية بدلًا من جدول يتضمن تفاصيل أدوات التقييم.

هناك تفصيلان معماريان يهمان أكثر من الدرجات بالنسبة لأي شخص يقوم بنشر هذا فعليًا:

• ضغط مختلط للرموز البصرية بنسبة 4×/16× — يختار المُستدعي عند كل طلب ما إذا كانت الصورة ستتحول إلى سلسلة رموز مفصّلة أم إلى سلسلة رخيصة، بحيث يمكن لمسح إيصال وصورة مصغّرة أن يتشاركا النشر نفسه • ضغط مبكر داخل ViT، مستعار من LLaVA-UHD v4 — تُقتطع الرموز البصرية داخل مُرمِّز الرؤية بدلاً من اقتطاعها بعده، وهذا ما يجعل مسار 4× ميسور الكلفة من الأساس • التقطيع — تُقسَّم الصور عالية الدقة إلى بلاطات 448×448 إضافة إلى نظرة عامة منخفضة الدقة، مع عدد الشرائح كمعامل وقت تشغيل (توصي البطاقة بـ 36 للصور و1 للفيديو) • أخذ عينات الفيديو — max_num_frames افتراضيًا 128، ويقوم stack_frames بتركيب الإطارات الفرعية في شبكة، وبهذه الطريقة يستطيع الهاتف معالجة تسجيل شاشة دون إبقاء كل إطار في الذاكرة

بالنسبة لحالة استخدام الإيصالات التي يذكرها الموجّه، فإن خط المعالجة هو: الالتقاط، ثم التصغير إلى ما يقارب 980 بكسل على الضلع الأطول، ثم التشغيل بمعدل 4× مع عدد شرائح مرتفع، ثم طلب إخراج منظّم. المسار 4× عند 36 شريحة هو الإعداد المكلف؛ أما المسار 16× فيستهلك نحو ربع الرموز وهو ما يُبقي الهاتف سريع الاستجابة. وما إذا كان 16× كافيًا لقراءة إيصال حراري هو سؤال لا تجيب عنه إلا صورك الخاصة، ولا يُبلّغ أي معيار قياس منشور في البطاقة عن دقة OCR حسب وضع التصغير.

الفجوة بين "العرض التجريبي" و"التطبيق"

ثلاثة أشياء تفصل بين نموذج تجريبي عامل وتطبيق iOS جاهز للإطلاق، ولا شيء منها هو أوزان النموذج.

الأول هو التغليف. يُشحن النموذج بصيغ Transformers وGGUF وAWQ وGPTQ وint4. وصيغة GGUF وحدها تمتلك مشغّلًا ناضجًا يعمل على الجهاز في iOS — llama.cpp ونظائره — كما أن مستودع GGUF وحده هو الذي يحمل ملف مُسقِط الرؤية المنفصل (mmproj) الذي يحتاجه المسار متعدد الوسائط. إذا بدأت من نقطة تحقق BF16 متوقعًا استبدالًا مباشرًا بملف واحد، فستكتشف أن المُسقِط ملف ناتج ثانٍ بحجمه الخاص.

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

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

نمط الإصدار الصامت، ولماذا لا يزال يسبب هذا الالتباس

وصل MiniCPM-V 4.7 دون حدث إطلاق. ظهر مستودع 35B-A3B في 6 أكتوبر 2026 دون أي بطاقة نموذج على الإطلاق — فقد وصلت البطاقة بعد ستة أيام إلى جانب ملاحظة الإصدار المؤرخة. وتبع 1B النمط نفسه: المستودع أولاً، ثم التوثيق، مع اكتشاف المجتمع طوال الوقت. وفي الفجوة، تُستكمل التغطية من أي أثر متاح، ولهذا وصفت الكتابات المبكرة نموذج 35B MoE ثم اضطرت إلى تعديلها عندما ظهر 1B وبطاقته.

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

ماذا نفعل بهذا، بشكل ملموس؟

إذا كان لديك جهاز Pro Max أو iPad. نزّل Q8_0 GGUF والمُسقِّط 16×، وشغّله عبر llama.cpp أو Ollama، واختبر مستنداتك الخاصة عند كلا إعدادي التخفيض. ستحصل على مسار OCR محلي ومسار image-QA يعملان خلال فترة ما بعد الظهر، والطراز 1B صغير بما يكفي ليبقى مقيماً إلى جانب تطبيقات أخرى.

إذا كان لديك iPhone قياسي. ابدأ بـ Q4_K_M وبروجكتور 16×، وحدّد عدد الشرائح عند قيمة متواضعة، وقِس. تقول حسابات الذاكرة إنه ينبغي أن يتّسع؛ أما سلوك الحرارة وjetsam تحت الاستخدام المستمر فهو الجزء الذي لم ينشره أحد. اختبر على أقدم جهاز تنوي دعمه، لا الأحدث.

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

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

الخلاصة: إن MiniCPM-V 4.7 1B نموذج رؤية حقيقي وموثّق بترخيص Apache-2.0، ويشغل نحو 1.8 غيغابايت عند Q4 مع مُسقِط الرؤية الخاص به — صغير بما يكفي ليكون الهواتف المتوسطة هدفًا واقعيًا، وليس فقط هاتف 12GB Pro Max. لم تنشر الشركة المطوّرة مصفوفة أجهزة أو حدًا أدنى للذاكرة، وادعاء «iPhone اليومي» مصدره تقرير مطوّر لا بطاقة النموذج. اختبره على جهازك قبل أن تخطط بناءً عليه.