MiniCPM-V 4.7 1B sur un iPhone du quotidien : ce que signifie vraiment « tourner au-delà du Pro Max »

MiniCPM-V 4.7 1B est un modèle vision-langage de 1,55 milliard de paramètres qu’OpenBMB a téléversé sur Hugging Face le 6 octobre 2026 et daté du 12 octobre dans ses propres notes de version. Il dispose d’une fiche de modèle, de onze variantes quantifiées, d’un tag Ollama et d’une application de démonstration embarquée. Ce qui lui manque, c’est une version du récit qui tient la route lorsqu’on chiffre le coût du matériel. L’affirmation qui circule dans les milieux de développeurs — selon laquelle le modèle s’exécute désormais dans une application OnDeviceLLM sur des iPhone ordinaires, et pas seulement sur un Pro Max de 12 Go — est l’élément qui mérite un examen attentif, car « s’exécute sur un téléphone » et « s’exécute sur votre téléphone » sont séparés par environ 3 Go de marge mémoire que la plupart des iPhone n’ont pas. Les défaillances d’IA documentées et les incidents d’agents derrière des versions comme celle-ci sont rassemblés dans l’OrcaRouter AI Incident Archive où chaque entrée porte ses propres sources, sa gravité, sa note de confiance et son indicateur de contestation.

Voici l’état des lieux, avec les coutures apparentes. Tout ce qui suit est soit lu directement dans les fichiers de poids, soit issu de la documentation propre à OpenBMB, soit des spécifications publiées par Apple. Lorsqu’un chiffre provient d’un post de développeur plutôt que d’un artefact reproductible, cet article le précise.

Qu’est-ce qui est réellement connu, et qu’est-ce qui n’est qu’affirmé ?

Le modèle est réel et téléchargeable. Le point de contrôle BF16 compte 1 554 476 272 paramètres, soit environ 3,1 Go sur disque. Le dépôt contient une fiche modèle complète — une rareté dans l’histoire récente de cette famille — qui nomme un socle textuel Qwen3.5, une tour de vision SigLIP2 de 27 couches et 1152 de largeur cachée, des tuiles d’entrée de 980 pixels, une fenêtre de contexte de 262 144 jetons et une licence Apache 2.0. L’entrée README d’OpenBMB elle-même date la sortie au 2026-10-12 ; le dépôt Hugging Face a été créé le 2026-10-06. L’écart de six jours correspond au décalage entre le téléversement et l’annonce pour lequel cette famille est connue, et c’est la raison pour laquelle un article d’octobre peut encore qualifier de sortie discrète un dépôt vieux de six jours.

Ce qui n'est pas établi par quelque artefact que ce soit, c'est l'affirmation précise selon laquelle le 1B tourne dans OnDeviceLLM sur « tous les iPhone du quotidien au-delà du Pro Max de 12 Go ». Un post de développeur est à l'origine de cette formulation. Le dépôt public du projet OnDeviceLLM — un kit de démarrage pour applications de chat et de traduction hors ligne, et non un produit publié sur l'App Store — n'a aucune étoile et sa dernière mise à jour date du 27 juillet 2026. Il précède de dix semaines les poids de MiniCPM-V 4.7, si bien que toute prise en charge de ce modèle y est récente et non documentée. Considérez « déjà en fonctionnement dans OnDeviceLLM » comme le rapport de quelqu'un qui l'a fait, et non comme une voie de déploiement prise en charge par un fournisseur.

Cette distinction est importante, car les chiffres que le fournisseur avance lui-même pour l'appareil ne concernent pas du tout le 1B.

Le chiffre de 3 Go correspond au 35B, pas au 1B

L'affirmation phare d'OpenBMB — « 13+ tokens/s avec seulement 3 Go de mémoire sur l'iPhone 17 Pro Max » — est associée à la 35B-A3B, variante Mixture-of-Experts, exécutée sur le plus grand iPhone vendu par Apple. La technique qui la sous-tend, Lookahead Expert Scheduling, conserve la plupart des poids d'experts sur le SSD et précharge ceux dont la couche suivante est susceptible d'avoir besoin. C'est un remarquable travail d'ingénierie système, et c'est la raison pour laquelle le nom 35B continue d'apparaître dans les articles consacrés aux téléphones.

Le 1B n’a besoin de rien de tout cela. C’est un modèle dense qui tient entièrement en mémoire. Sur le papier, cela en fait le plus démocratique des deux, et c’est pourquoi l’angle « iPhone du quotidien » tient la route. Mais l’arithmétique est moins favorable que ne le suggère le cadrage :

• Poids BF16 — 3.1 GB sur disque, et à peu près la même empreinte résidente une fois chargés, avant tout cache KV ou activations de vision • Q8_0 GGUF — 1.08 GB de poids, plus un projecteur de vision de 0.90 GB au réglage de compression 4×, ou 1.11 GB à 16× • Q4_K_M GGUF — 0.67 GB de poids, avec le même surcoût de projecteur • Projecteur de vision — c’est la partie que les gens oublient ; il ne diminue pas avec la quantification du modèle de langage, et il est comptabilisé une fois par modèle chargé • Contexte — jusqu’à 262 144 jetons sur le papier ; chaque jeton du cache KV représente de la mémoire supplémentaire que la fiche du modèle ne prévoit pas

Une version Q4 avec le projecteur 16× approche les 1,8 Go de poids. Ajoutez un cache KV fonctionnel pour quelques milliers de tokens de conversation et d’espaces réservés d’image, et vous demandez à une appli quelque chose de l’ordre de 2,2 à 2,8 Go. Sur un Pro Max de 12 Go, c’est confortable. Sur un iPhone de 8 Go, où le système d’exploitation et toutes les autres applis résidentes se disputent déjà la même réserve, une appli qui demande 2,5 Go demande une grande fraction de ce qui reste. iOS l’accordera, ou elle tuera l’appli par jetsam sous pression.

Pourquoi la ligne RAM sur un iPhone est la véritable spécification

Apple ne publie pas la quantité de RAM de l'iPhone dans ses spécifications marketing, et il n'a jamais encouragé les développeurs à considérer le téléphone comme un ordinateur à mémoire adressable. C'est la contrainte à laquelle se heurte l'affirmation « au-delà du Pro Max 12 Go ». La gamme Pro Max embarque, depuis plusieurs générations, plus de mémoire que les modèles standard, et l'écart entre « le téléphone de la vidéo de test » et « le téléphone dans la poche d'un lecteur » est précisément l'écart dont dépend l'argument de ce modèle en matière de traitement sur l'appareil.

La version honnête de cette affirmation est plus étroite et reste intéressante : un modèle de vision de 1B qui nécessitait auparavant un ordinateur portable ou un téléphone haut de gamme tient désormais dans le budget mémoire d'un téléphone de milieu de gamme, si vous utilisez une quantification en 4 bits et acceptez un contexte plus court. C'est un véritable passage à une catégorie de matériel inférieure. Ce n'est pas la même chose que « tourne sur tous les iPhone », et la différence mérite d'être énoncée clairement, car elle détermine si un lecteur peut livrer le produit.

La fiche du modèle ne tranche pas la question. Elle documente la prise en charge d’iOS, d’Android et de HarmonyOS, la prise en charge de puces dès le premier jour par Rockchip, Houmo, Intel, AMD et Arm, et renvoie à un dépôt de déploiement en périphérie avec applications et code source. Nulle part elle n’indique la mémoire minimale de l’appareil, une matrice d’appareils testés, ni un débit de tokens par appareil pour le 1B. Le seul appareil nommé dans les ressources de démonstration du 1B lui-même est un iPhone 17 Pro Max — le même appareil que celui mis en avant pour le 35B.

Ce en quoi le modèle est réellement bon, à 1B

La raison pour laquelle ce calcul de mémoire en vaut la peine, c’est qu’un modèle 1B effectuant de la compréhension de documents et d’écrans sur un téléphone relève d’une catégorie de produit différente de celle d’un chatbot. Cela signifie qu’un ticket de caisse, un formulaire, un menu, une étiquette ou une capture d’écran peuvent être transformés en texte structuré sans aller-retour réseau — aucun téléversement, aucun coût par image, aucun plancher de latence imposé par une antenne-relais.

Les chiffres 1B publiés par OpenBMB, tous rapportés par le fournisseur et aucun reproduit de manière indépendante à ce jour, indiquent 86,1 pour OCRBench, 74,3 pour MathVista, 48,8 pour CharXiv Reasoning, 53,4 pour LongVideoBench et 54,55 pour MotionBench. La comparaison phare du fournisseur porte sur Qwen3.5 0.8B, qu’il dit surpasser à la fois sur le score global et sur l’efficacité d’inférence, ainsi que sur MiniCPM-V 4.6, sur lequel il dit s’améliorer sur l’ensemble des capacités clés. Il s’agit des propres benchmarks du fournisseur, exécutés par celui-ci, et la fiche du modèle les présente sous forme de graphiques plutôt que de tableau avec les détails du harnais.

Deux détails architecturaux comptent davantage que les scores pour quiconque déploie réellement ceci :

• Compression mixte 4×/16× des tokens visuels — l’appelant choisit, à chaque requête, si une image devient une séquence de tokens détaillée ou une séquence économique, afin qu’un scan de ticket et une vignette puissent partager un déploiement • Compression précoce intra-ViT, empruntée à LLaVA-UHD v4 — les tokens visuels sont réduits à l’intérieur de l’encodeur visuel plutôt qu’après celui-ci, ce qui rend précisément le chemin 4× abordable • Découpage — les images haute résolution sont divisées en tuiles 448×448 plus une vue d’ensemble basse résolution, le nombre de tranches étant un paramètre d’exécution (la carte recommande 36 pour les images, 1 pour la vidéo) • Échantillonnage vidéo — max_num_frames vaut 128 par défaut, et stack_frames compose les sous-trames en une grille, ce qui permet à un téléphone de traiter un enregistrement d’écran sans conserver chaque image en mémoire

Pour le cas d’usage du reçu mentionné dans le prompt, le pipeline est le suivant : capture, réduction à environ 980 pixels sur le grand côté, exécution en 4× avec un nombre élevé de tranches, et demande de sortie structurée. Le chemin 4× à 36 tranches est le réglage coûteux ; le chemin 16× représente environ un quart des tokens et c’est là que le téléphone reste réactif. Savoir si le 16× suffit pour lire un reçu thermique est une question à laquelle seules vos propres images peuvent répondre, et aucun benchmark publié dans la fiche ne rapporte la précision OCR par mode de sous-échantillonnage.

Le fossé entre « démo » et « app »

Trois choses séparent une démo fonctionnelle d’une app iOS prête à être publiée, et aucune d’elles ne correspond aux poids du modèle.

Le premier point est le packaging. Le modèle est livré dans les formats Transformers, GGUF, AWQ, GPTQ et int4. Seul GGUF dispose d’un exécuteur embarqué mature sur iOS — llama.cpp et ses dérivés — et seul le dépôt GGUF contient le fichier de projecteur visuel séparé (mmproj) dont la voie multimodale a besoin. Si vous partez du checkpoint BF16 en vous attendant à un remplacement direct en un seul fichier, vous découvrirez que le projecteur est un second artefact avec sa propre taille.

Le deuxième point est le budget thermique. Un modèle 1B qui génère quelques centaines de tokens impose une charge de travail en rafale ; un modèle 1B qui effectue de l’OCR sur une page de 36 coupes impose une charge soutenue. Le GIF de démonstration du fournisseur est un enregistrement d’écran, pas un relevé thermique. Aucun chiffre publié dans la fiche ne donne le débit soutenu de tokens par seconde sur un téléphone quelconque, et c’est ce chiffre qui détermine si une application de numérisation semble instantanée au troisième document ou au trentième.

Le troisième est le reste de votre pile. L'inférence sur l'appareil traite l'image. Elle ne traite pas la partie où vous rapprochez le reçu extrait d'un grand livre, escaladez une ligne ambiguë vers un modèle plus grand, ou basculez lorsque le téléphone est assez ancien pour que l'application refuse de charger les poids. C'est la frontière où un routeur mérite sa place plutôt que de remplacer quoi que ce soit : OrcaRouter met plus de 200 modèles hébergés derrière un point de terminaison unique compatible OpenAI avec 0 % de marge, en répercutant directement le prix catalogue de chaque fournisseur, avec basculement automatique et un DSL de routage pour les configurations primaire-et-secours. Un extracteur côté téléphone peut confier ses cas incertains à un modèle de vision hébergé, et la même clé porte les deux chemins. MiniCPM-V 4.7 1B lui-même ne figure pas dans ce catalogue — c'est un checkpoint que vous exécutez vous-même — donc le routeur est le chemin d'escalade, pas le moyen d'appeler ce modèle.

Le schéma de la libération silencieuse, et pourquoi il continue d'engendrer cette confusion

MiniCPM-V 4.7 est arrivé sans événement de lancement. Le dépôt 35B-A3B est apparu le 6 octobre 2026 sans aucune fiche de modèle — celle-ci est arrivée six jours plus tard, en même temps que la note de version datée. Le 1B a suivi le même schéma : d'abord le dépôt, ensuite la documentation, et la découverte par la communauté tout au long. Dans l'intervalle, la couverture se comble à partir de l'artefact disponible, ce qui explique pourquoi les premiers articles décrivaient un modèle MoE de 35B et ont ensuite dû être révisés lorsque le 1B et sa fiche sont apparus.

Il ne s'agit pas d'une critique de l'ingénierie d'OpenBMB. C'est une description de la manière dont les informations sur ce modèle se propagent, et c'est la raison pour laquelle une affirmation comme « fonctionne sur des iPhone du quotidien » peut circuler plus vite que les chiffres de mémoire qui la relativisent. Le dépôt est la source principale. La fiche modèle est la source principale. La capture d'écran d'un développeur montrant une application qui fonctionne sur son téléphone est un point de données, pas une spécification.

Que faire de cela, concrètement ?

Si vous disposez d'un Pro Max ou d'un iPad. Téléchargez le GGUF Q8_0 et le projecteur 16×, exécutez-le via llama.cpp ou Ollama, puis testez vos propres documents avec les deux réglages de sous-échantillonnage. Vous obtiendrez en un après-midi un pipeline local fonctionnel d'OCR et de questions-réponses sur images, et le modèle 1B est assez petit pour rester résident aux côtés d'autres applications.

Si vous avez un iPhone standard. Commencez avec Q4_K_M et le projecteur 16×, plafonnez le nombre de tranches à une valeur modeste, et mesurez. Les calculs de mémoire indiquent que cela devrait tenir ; le comportement thermique et vis-à-vis du jetsam en utilisation soutenue est la partie que personne n'a publiée. Testez sur l'appareil le plus ancien que vous comptez prendre en charge, pas sur le plus récent.

Si vous construisez un produit. Considérez le modèle embarqué comme la voie rapide et un modèle hébergé comme la voie de l’exactitude. L’escalade est une décision de routage, et l’intégrer dès le premier jour coûte moins cher que de l’ajouter après le premier ticket d’assistance concernant un reçu que le téléphone a mal lu.

L'affirmation à l'origine de cet article — selon laquelle un modèle multimodal de 1 milliard de paramètres tourne désormais sur des téléphones en dessous du niveau Pro Max — est plausible sur le plan du calcul de mémoire et non prouvée au regard des données publiées. C'est un état normal pour un modèle aussi jeune, et c'est une raison de tester plutôt que d'attendre. Les poids sont sous Apache 2.0, les quantifications existent, et la seule chose qui vous sépare d'une réponse est un après-midi avec votre propre matériel.

L'essentiel : MiniCPM-V 4.7 1B est un modèle de vision réel, documenté et sous licence Apache-2.0, qui tient en environ 1,8 Go en Q4 avec son projecteur visuel — assez petit pour que les téléphones de milieu de gamme soient une cible crédible, et pas seulement les Pro Max de 12 Go. Le fournisseur n'a publié ni matrice d'appareils ni chiffre de mémoire minimale, et l'affirmation concernant « l'iPhone du quotidien » provient d'un rapport de développeur plutôt que de la fiche du modèle. Testez sur votre propre appareil avant de planifier quoi que ce soit en fonction de cela.