MiniCPM-V 4.7 : le MoE de 35B qui tourne sur smartphone avec 3 Go de RAM

35 milliards de paramètres qui répondent en temps réel sur un smartphone, en utilisant 3 Go de RAM. On dirait une coquille, mais c'est la fiche technique de MiniCPM-V 4.7, le nouveau modèle open d'OpenBMB et ModelBest, sorti le 12 octobre 2026. Le mécanisme est celui que vous avez déjà croisé avec Qwen3 30B-A3B ou Gemma 4 26B-A4B — les Mixture-of-Experts, MoE — transposé sur téléphone : sur chaque token, seuls environ 3B des 35B totaux travaillent. Voici ce que cela signifie concrètement, quels chiffres tiennent la promesse et ce qu'il faut pour l'essayer.

MiniCPM-V 4.7, en une table

MiniCPM-V 4.7 est un modèle visuel-linguistique — images multiples et vidéo, pas seulement du texte — disponible en deux variantes : 35B-A3B, le premier MoE de la série, et 1B, la version compacte pour un matériel encore plus modeste. Les chiffres de la model card officielle :

Spécification	Valeur
Architecture	MoE : 35B totaux, ~3B actifs par token
Variantes	35B-A3B (MoE) et 1B (dense)
Modalités	texte, images multiples, vidéo, OCR
Vitesse déclarée	13+ tok/s sur iPhone 17 Pro Max avec 3 Go de RAM
Date de sortie	12 octobre 2026
Quantisations officielles	BF16, FP8, INT4, AWQ, GPTQ, GGUF
Moteurs	Ollama, llama.cpp, vLLM, SGLang
Plateformes	iOS, Android, HarmonyOS ; puces Rockchip, Intel, AMD, Arm dès le jour 1

Le backbone linguistique dérive de Qwen 3.5/3.6 et le bloc visuel de SigLIP2. Sources : model card et page GitHub.

MoE : 35B de capacité, 3B de travail

Dans un modèle dense, chaque token fait tourner tous les paramètres : un dense de 35B coûte comme 35B à chaque pas. Dans un Mixture-of-Experts, chaque couche contient de nombreux sous-modèles — les « experts » — et un routeur n'en active qu'une partie par token. Pour le 35B-A3B, il en résulte environ 3B de calcul par token : environ 12 fois moins qu'un dense de la même taille (35/3 ≈ 11,7).

Le problème n'est pas le calcul, c'est la mémoire : tous les poids doivent rester atteignables, et sur un téléphone, 35B totaux n'entrent pas entiers dans la RAM. Les deux voies classiques ont un prix :

• Charger les experts à la volée depuis la mémoire de masse : ça marche, mais chaque chargement fait attendre le token, et le modèle devient lent, à à-coups.
• Bloquer un sous-ensemble d'experts pour tout le prompt : plus rapide, mais vous excluez les experts que le modèle aurait choisis, et vous perdez de la capacité.

MiniCPM-V 4.7 cherche la troisième voie : prédire quels experts seront nécessaires et les charger avant qu'ils ne le soient, sans toucher au routage réel. C'est ce que font les trois techniques ci-dessous, et le résultat déclaré est 13+ tokens/seconde avec 3 Go de RAM sur iPhone 17 Pro Max — le premier MoE open-source qui tourne fluidement on-device sans compromis de qualité.

Les chiffres : où le placer et à quelle vitesse

Scénario	Format	Vitesse	Mémoire
iPhone 17 Pro Max	quant on-device (vendor)	13+ tok/s	~3 Go
Flagship Android	quant on-device (vendor)	17+ tok/s	non déclarée
Desktop, GPU 24 Go	GGUF Q4_K_M	à vérifier	21,8 Go
Desktop, GPU 16 Go	GGUF Q4_K_S	à vérifier	18,7 Go

Trois lectures. La première : les 3 Go ne sont pas un miracle, c'est le poids effectivement chargé en RAM avec les quantisations fines par niveau — le modèle reste de 35B, la RAM tient la partie chaude. La deuxième : un Q4_K_M de 21,8 Go entre sur une 3090 ou 4090 de 24 Go avec de la place pour la KV cache ; sur une carte de 16 Go, on se déplace en Q4_K_S de 18,7 Go, ce qui est serré. La troisième : sur la model card, le vendor affiche un score global plus haut que Qwen3.6 35B-A3B en moins de temps d'inférence — un benchmark fait par eux, à lire avec cette optique. Un repère non officiel : un utilisateur rapporte 37,5 t/s sur une RTX 2060 Super 8 Go avec llama.cpp et CPU-MoE (discussion HF) — indicatif, ce n'est pas un chiffre du vendor.

Comment il y parvient : trois techniques, dont une de vision

1. Lookahead Expert Scheduling (LES). Un prédicteur estime le routage de la couche suivante et pré-charge les experts probables pendant que la GPU ou la NPU calcule la couche courante. La prédiction ne guide que le pré-chargement : le calcul suit toujours le routage d'origine du modèle, et un expert manqué arrive quand même, chargé au moment.

2. Quantisation fine par niveau. Chaque niveau des poids des experts a sa propre résolution de quantisation, selon son importance. Le résultat : moins de mémoire et moins de trafic de bande — qui sur téléphone est souvent le goulot, plus que les FLOP.

3. Échantillonnage spéculatif DSpark. Un petit modèle draft (publié en BF16 et GGUF) propose plusieurs tokens à la fois et le grand modèle les vérifie en un seul pas : la même idée de la décodification spéculative que vous avez déjà vue pour les modèles desktop.

Et la partie visuelle : compression mixte 4x/16x des tokens visuels dans l'encodeur, avant d'entrer dans le modèle linguistique. Avec 16x, le modèle est plus rapide — bon pour la vidéo et les longs documents ; avec 4x, il conserve quatre fois plus de tokens pour les détails fins — OCR, petits objets. On choisit à l'exécution, selon la tâche.

Et les limites ?

• Les 3 Go sont sur un iPhone 17 Pro Max, un flagship récent avec beaucoup de RAM. Sur des téléphones plus anciens ou avec moins de mémoire, le modèle ralentit ou n'entre pas : le vendor ne déclare pas de minima pour le reste de la gamme.
• C'est un modèle visuel-linguistique, pas omnimodal complet : images, vidéo et OCR oui, voix non — c'est la ligne MiniCPM-o.
• Le benchmark d'efficacité est celui du vendor, publié sur la model card : il compare des modèles d'autres familles avec leurs conditions de test. À prendre comme repère, pas comme mesure neutre.
• Le Q4_K_S de 18,7 Go sur une GPU de 16 Go est serré : poids, KV cache et contexte, la marge est mince.

L'essayer

1. Avec Ollama, le chemin le plus rapide. Il est dans la librairie officielle :

ollama run openbmb/minicpm-v4.7

Vous pouvez alors discuter depuis le terminal. Pour les images, connectez-le à Open WebUI et joignez une photo au prompt : le modèle la voit. S'il ne démarre pas, mettez Ollama à jour — les modèles multimodaux exigent le support mmproj.

2. Avec Transformers, plus de contrôle. Sur une machine avec GPU :

pip install "transformers[torch]>=5.18.0" torchvision torchcodec

Puis vous chargez openbmb/MiniCPM-V-4.7-35B-A3B avec torch_dtype="auto", passez downsample_mode="16x" aussi bien à apply_chat_template qu'à generate, et utilisez les paramètres de sampling recommandés par le vendor (temperature 0.7, top_p 0.95, top_k 100). Si torchcodec ne se charge pas avec votre version CUDA, le contournement documenté est d'installer av à la place, ou de pinner CUDA 12.8 dans l'installation de torch.

3. En production locale. vLLM et SGLang sont supportés si vous avez besoin d'un serveur avec une API compatible OpenAI ; pour l'usage consumer, la voie GGUF reste la plus simple sur un matériel courant.

Si vous voulez le tableau complet de ce que changent les MoE sur un matériel desktop, la comparaison de Kolibri et l'analyse sur les modèles de décision JEV-35B partent des mêmes concepts à des tailles plus grandes. Et pour comprendre ce qui arrive aux poids quand on les comprime, le guide sur la quantisation reste la référence.

Sources

• Model card MiniCPM-V 4.7 35B-A3B — Hugging Face
• Poids GGUF officiels
• Annonce ModelBest et OpenBMB — PR Newswire, 15 octobre 2026
• GitHub OpenBMB/MiniCPM-V — sortie 12 octobre 2026

En résumé

MiniCPM-V 4.7 35B-A3B est le premier MoE open-source qui tourne fluidement sur un smartphone sans compromis : 13+ tokens/seconde avec 3 Go de RAM sur iPhone 17 Pro Max, avec environ 3B de calcul actif par token. Le secret est de prédire quels experts seront nécessaires (LES), de quantiser fin par niveau et d'ajouter l'échantillonnage spéculatif DSpark. En desktop, le GGUF Q4_K_M de 21,8 Go entre sur une GPU de 24 Go. Les chiffres on-device sont ceux du vendor, à lire comme tels : la base est solide, mais les minima sur le reste de la gamme sont à vérifier sur votre matériel.

Article généré par IA