MiniCPM LES apporte un MoE de 35B sur les téléphones sans restreindre les experts

MiniCPM affirme que sa technologie d’ordonnancement LES aide un modèle de 35 milliards de paramètres à générer 20,51 tokens par seconde sur un iPhone 18 Pro Max. MiniCPM LES répond à un obstacle précis : déplacer les poids du modèle vers la mémoire suffisamment vite sans restreindre les parties du modèle pouvant participer.

Cette distinction compte pour les MoE, ou mélanges d’experts, une architecture qui active des groupes de paramètres sélectionnés plutôt que d’utiliser l’ensemble du modèle pour chaque token. La désignation 35B-A3B de MiniCPM-V 4.7 décrit environ 35 milliards de paramètres au total et 3 milliards de paramètres actifs. Une quantité moindre de calcul actif n’élimine pas la nécessité de stocker et d’accéder aux poids restants.

L’enjeu sous-jacent consiste à préserver la sélection dynamique des experts tout en réduisant les délais de chargement. Les précédentes recherches d’Apple sur l’inférence basée sur le flash ont établi un point de référence utile : le stockage peut étendre une mémoire limitée, mais le mouvement des données exige une gestion rigoureuse. La contribution de MiniCPM cible l’ordonnancement des experts au sein de ce problème plus vaste. Ses résultats publiés exigent également une attribution prudente : la vitesse maximale sur téléphone combine plusieurs optimisations, et le terme « sans perte » doit être interprété plus étroitement que ne le laisse entendre le titre.

MiniCPM LES transforme le chargement des experts en problème d’ordonnancement

Le changement significatif consiste à tenter de préserver les choix d’experts originels du modèle tout en réduisant le temps passé à attendre leurs poids.

La fiche du modèle 35B de l’équipe décrit une approche de déploiement qui conserve le routage au niveau des tokens, le processus qui sélectionne les experts pour chaque token généré. Elle rapporte également un résultat distinct de plus de 13 tokens par seconde sur un iPhone 17 Pro Max, avec environ 3 Go de mémoire.

Ce résultat antérieur sur téléphone doit rester distinct du benchmark plus récent sur iPhone 18 Pro Max. Ils concernent des appareils et des configurations documentées différents. Les traiter comme interchangeables masquerait ce que les éléments publics établissent réellement.

LES signifie Lookahead Expert Scheduling, un système qui anticipe les experts dont la prochaine couche du modèle aura besoin. Son objectif est d’avancer le travail de chargement. La prédiction aide à organiser le calcul ; elle ne remplace pas la sélection finale des experts par le modèle.

Examinons le problème de déploiement du point de vue d’un développeur d’application. Un assistant peut disposer d’une capacité de calcul suffisante pour générer une réponse tout en restant lent parce que sa prochaine opération ne dispose pas des poids nécessaires. Accélérer l’arithmétique apporte peu lorsque celle-ci attend les données.

Garder tous les experts en mémoire de travail évite ce délai particulier, mais exige davantage de mémoire. Garder les poids dans le stockage réduit l’empreinte résidente, mais introduit du travail de chargement. Restreindre les experts disponibles simplifie l’accès tout en pouvant modifier le calcul qui produit la réponse.

L’approche proposée par MiniCPM préserve l’accès à l’ensemble du pool d’experts et gère le moment où les poids arrivent. Cela crée un objectif d’ingénierie différent. La question devient alors de savoir si suffisamment de données nécessaires peuvent arriver pendant un calcul déjà en cours.

C’est pourquoi l’annonce de l’ordonnancement mérite l’attention au-delà d’un titre sur la taille du modèle. Un grand nombre de paramètres sur un téléphone dit peu de chose, à lui seul, sur la réactivité. L’organisation du chargement et de l’exécution détermine si cette capacité peut prendre en charge une application interactive.

Pour les utilisateurs, cette distinction se manifeste par la continuité. Une réponse qui commence à produire du texte puis s’interrompt régulièrement ne procure pas la même expérience qu’une réponse au débit plus régulier. La vitesse moyenne de génération capture une partie de cette expérience, mais la séquence des délais compte aussi.

L’importance pratique repose donc sur le runtime, le logiciel chargé d’exécuter le modèle. Les seuls poids du modèle ne permettent pas d’établir que chaque application compatible reproduira le même comportement. Le déploiement pertinent combine le modèle, l’organisation du stockage, l’implémentation de l’ordonnancement et la configuration numérique.

Ce système combiné est le véritable objet de l’affirmation. Il fournit une base concrète d’investigation sans exiger d’accepter tous les superlatifs associés à la sortie.

Préserver le choix des experts exerce une pression sur les raccourcis de déploiement mobile

La pression immédiate s’exerce sur les stratégies de déploiement qui gagnent en vitesse en réduisant le pool d’experts disponibles au modèle.

Une restriction des experts peut sembler attrayante lorsque la mémoire et le temps de chargement dominent le budget d’une application. Moins de poids disponibles signifient moins de besoins de chargement possibles. La difficulté est qu’une optimisation qui affecte la disponibilité des experts peut aussi affecter le comportement du modèle.

Cela crée un choix que les développeurs doivent effectuer explicitement. Optimisent-ils l’exécution du modèle original ou déploient-ils un parcours de calcul modifié ? Les deux approches méritent une évaluation, mais leurs affirmations de qualité exigent des preuves différentes.

Un système d’ordonnancement promet une séparation utile. Les développeurs peuvent examiner l’efficacité de l’exécution tout en maintenant intact le mécanisme de sélection du modèle. Il devient ainsi plus simple d’identifier si une modification affecte la vitesse, la qualité des réponses, ou les deux.

Cela modifie également la comparaison avec les modèles plus petits. Un modèle compact qui reste en mémoire peut offrir un chemin de déploiement plus simple. Un modèle plus grand diffusé depuis le stockage doit justifier sa complexité supplémentaire en matière de stockage et de runtime par de meilleurs résultats sur des tâches pertinentes.

Aucune de ces approches ne l’emporte sur le seul critère du nombre de paramètres. Une application qui extrait un court champ d’un document familier pourrait tirer davantage profit d’une latence prévisible que de capacités de raisonnement plus étendues. Un système qui interprète des diagrammes inconnus pourrait accorder davantage de poids à la qualité des réponses.

Il s’agit de scénarios de déploiement, et non de résultats clients vérifiés pour MiniCPM. Ils illustrent pourquoi un même benchmark peut étayer des décisions produit différentes. La valeur dépend de ce que les utilisateurs demandent et des défaillances que l’application peut tolérer.

La comparaison historique est également instructive. Les recherches d’Apple sur l’inférence basée sur le flash ont étudié l’exécution de modèles dépassant la mémoire de travail disponible grâce au chargement sélectif et à un accès au stockage plus efficace. Leurs méthodes diffèrent de LES, mais la contrainte commune est le mouvement des données.

Ce précédent encadre convenablement l’affirmation de nouveauté. L’utilisation du stockage flash pour prendre en charge des modèles plus grands possède un historique de recherche établi. La contribution spécifique examinée concerne l’anticipation des besoins en experts et la coordination de leur exécution.

Pour les équipes de matériel mobile, ce cadre redirige l’attention vers l’ensemble du chemin de la mémoire et du stockage. La capacité de calcul reste pertinente, mais un déploiement peut se bloquer avant d’atteindre ses limites arithmétiques. Évaluer le processeur isolément manque cette possibilité.

Pour les équipes d’application, cela soulève une question d’approvisionnement. Un appareil aux spécifications de calcul attrayantes doit tout de même être testé avec le runtime et la charge de travail visés. Le comportement du stockage, la mémoire disponible et les conditions de fonctionnement deviennent partie intégrante du profil de performance de l’application.

L’implication concurrentielle constitue donc une exigence d’ingénierie plutôt qu’une victoire de marché proclamée. Les alternatives doivent montrer comment elles équilibrent qualité, réactivité et utilisation des ressources dans des conditions comparables. MiniCPM doit satisfaire à la même norme.

Si l’approche d’ordonnancement se reproduit de manière fiable, la restriction des experts devient plus difficile à justifier comme nécessité automatique. Elle reste un choix de conception dont le coût en qualité et le bénéfice en performance devraient être visibles.

Comment MiniCPM LES préserve le routage tout en masquant les délais de chargement

LES utilise la prédiction pour préparer le calcul, tandis que le routeur réel reste responsable de la sélection des experts exécutés.

La documentation officielle sur l’ordonnancement des experts décrit une prédiction inter-couches suivie d’un préchargement, qui charge les poids probablement nécessaires avant que l’exécution ne les atteigne. Les experts correctement anticipés s’exécutent en premier. Les autres experts requis se chargent parallèlement à ce calcul.

Une prédiction manquée crée donc une attente supplémentaire plutôt qu’une autorisation d’ignorer un expert requis. Cette distinction explique l’affirmation de l’équipe concernant un ordonnancement sans perte. Elle concerne la préservation de la participation des experts, plutôt que l’hypothèse selon laquelle les prédictions correspondent toujours à la sélection finale.

La documentation décrit également l’organisation contiguë des poids, la réduction des lectures dispersées et l’application d’une précision mixte propre à chaque couche. La quantification, c’est-à-dire la représentation des poids avec une précision numérique réduite, diminue les besoins en stockage et en transfert. Ces modifications ciblent différentes parties du problème de chargement.

Le mécanisme suggère plusieurs implications utiles, bien qu’elles exigent des mesures sur des déploiements réels. La précision des prédictions ne peut à elle seule déterminer le bénéfice total. Une prédiction correcte qui arrive trop tard pourrait réduire très peu le temps d’attente.

De même, charger tôt les bons poids n’aide que si l’appareil peut superposer un travail utile. Si une autre ressource devient le facteur limitant, le même ordonnanceur peut générer un gain différent. La performance appartient à l’environnement d’exécution complet.

Les prédictions incorrectes méritent aussi l’attention. Précharger un élément inutile consomme des ressources, même lorsque la sélection des experts reste inchangée. La question utile est de savoir si les délais évités compensent ce travail supplémentaire sur des requêtes représentatives.

Cela place la sélection des charges de travail au centre de l’évaluation. Un benchmark devrait exposer les situations dans lesquelles l’ordonnancement fonctionne bien et celles dans lesquelles il rencontre des difficultés. Une moyenne sans cette distribution peut dissimuler des tendances importantes pour la fiabilité de l’application.

Par exemple, un assistant documentaire peut rencontrer des mises en page familières au cours d’une session, puis des structures visuelles inhabituelles au cours d’une autre. Les évaluateurs devraient examiner si ces changements modifient la réactivité. Le mécanisme leur donne une raison de poser la question ; il n’établit pas la réponse.

L’approche sépare également deux prédictions que les lecteurs peuvent facilement confondre. Le préchargement des experts anticipe les poids dont un calcul à venir aura besoin. Le décodage spéculatif, qui produit des tokens de sortie candidats pour une vérification ultérieure, concerne le processus de génération lui-même.

MiniCPM intègre DSpark comme composant spéculatif. Cela crée une autre possibilité d’améliorer le débit, mais rend aussi l’attribution plus importante. Une accélération attribuée largement à LES peut inclure des contributions de l’ordonnancement, de l’accès au stockage, de la représentation numérique et de l’ébauche de tokens.

Pour les développeurs, l’avantage conceptuel est suffisamment clair pour être testé. Préserver le travail requis, puis réorganiser la préparation et l’exécution afin de réduire le temps d’inactivité. Le défi pratique consiste à rendre cette réorganisation bénéfique sous les contraintes réelles de l’appareil.

Il s’agit d’une proposition plus solide et plus précise que d’affirmer qu’un grand modèle tient simplement dans une faible allocation mémoire. Elle identifie le temps d’attente que l’implémentation cible et le comportement du modèle qu’elle affirme préserver.

Le résultat à 20,51 tokens combine plusieurs optimisations

Le résultat publié sur téléphone appartient à l’ensemble de la pile d’optimisation, plutôt qu’au seul ordonnancement anticipatif.

Les benchmarks sur appareil d’OpenBMB indiquent que l’iPhone 18 Pro Max dispose de 12 Go de mémoire système. Les résultats détaillés commencent à 3,38 tokens par seconde pour la référence. L’ordonnancement Lookahead atteint 6,57 ; des modifications supplémentaires de planification et de chargement permettent d’atteindre 11,34.

La quantification à précision mixte porte le résultat communiqué à 17,16 tokens par seconde. L’ajout de DSpark l’amène à 20,51, soit 6,07 fois la référence. Le résultat correspondant pour l’iPad Pro M4 entièrement optimisé est de 17,39 tokens par seconde.

Ces chiffres permettent une interprétation concrète : plusieurs étapes contribuent au résultat. Ils ne justifient pas d’attribuer l’ensemble de l’accélération au seul effet de la prédiction d’experts. Les développeurs qui cherchent à reproduire le chiffre mis en avant ont besoin de la configuration pertinente pour chaque étape.

La référence mérite un examen tout aussi attentif. Une comparaison avec une implémentation dépourvue de ces optimisations démontre une amélioration par rapport à cette implémentation. Elle n’établit pas automatiquement une supériorité sur tous les autres runtimes ou modes de déploiement.

C’est un problème d’interprétation fréquent avec les benchmarks de systèmes. Un gain relatif important peut coexister avec un point de départ modeste. Les lecteurs ont besoin à la fois du résultat absolu et d’une description claire de ce qui a changé.

La mémoire totale du téléphone répond également à une question différente de l’empreinte mémoire de travail communiquée pour le modèle. La capacité de l’appareil décrit l’environnement matériel. La mémoire de l’application décrit les ressources consommées dans cet environnement, selon la méthode de mesure employée.

Le stockage persistant ajoute une autre dimension. Les fichiers officiels du modèle quantifié indiquent une taille de 21,2 Go pour la variante Q4_K_M. Cette liste illustre pourquoi une faible consommation de mémoire résidente ne doit jamais être interprétée comme un téléchargement tout aussi réduit.

La liste des fichiers n’établit pas que cet artefact précis a produit chaque benchmark publié. Il reste nécessaire d’associer le benchmark à ses fichiers de poids exacts. Sans cela, les développeurs risquent de comparer différentes représentations numériques sous le même nom de modèle.

Cette distinction a des conséquences directes sur le produit. Une application mobile doit prendre en compte l’installation, les mises à jour du modèle, l’espace de stockage disponible et le comportement au lancement. Une configuration qui génère efficacement après préparation doit tout de même offrir une expérience acceptable avant le début de la génération.

La vitesse de décodage mesure la génération de sortie une fois le décodage lancé. Elle ne doit pas être considérée comme l’intervalle complet entre l’envoi d’une image et la réception d’une réponse utile. La gestion et la préparation des entrées nécessitent leurs propres mesures.

De même, les tokens sont des unités utilisées par le modèle, et non un nombre fixe de mots anglais. Un chiffre de débit fournit une comparaison technique dans des conditions données. Il ne se traduit pas directement par une expérience universelle de lecture ou de conversation.

Le résultat communiqué est donc significatif, mais circonscrit. Il montre ce que l’équipe affirme que son implémentation combinée atteint sur le matériel cité. Des tests indépendants devront déterminer dans quelle mesure ce résultat se transpose à des sessions applicatives réalistes.

« Sans perte » exige un point de référence défini

La préservation du routage des experts étaye une affirmation technique limitée ; elle n’établit pas un comportement identique pour tous les réglages de précision, toutes les tâches et tous les appareils.

L’interprétation la plus solide de la description de l’ordonnancement concerne la sélection. Les experts requis restent éligibles, et une erreur de prédiction ne les exclut pas du calcul. Cette propriété traite un risque de qualité spécifique introduit par la restriction du groupe d’experts disponibles.

Le déploiement mobile complet soulève des questions supplémentaires. La quantification modifie la représentation des poids. Une comparaison de qualité appropriée doit donc identifier quel modèle de référence et quelle configuration numérique définissent la base de comparaison.

Une affirmation concernant la préservation du routage ne devrait pas devenir silencieusement une affirmation selon laquelle chaque sortie correspond à celle d’un modèle de précision supérieure. Ces déclarations portent sur des propriétés différentes. Les évaluateurs ont besoin de preuves adaptées à chacune d’elles.

De même, préserver une procédure de génération ne prouve pas que ses réponses sont correctes. Un modèle peut s’exécuter comme prévu tout en interprétant mal un graphique, en comprenant mal une demande ou en inventant un détail. La fidélité d’exécution et l’exactitude des tâches exigent des évaluations distinctes.

Aucune reproduction indépendante du benchmark phare sur téléphone n’a été établie à partir des sources examinées pour cette analyse. Cette limite n’invalide pas le résultat communiqué. Elle détermine le degré de confiance avec lequel les lecteurs devraient le généraliser.

La même prudence s’applique au positionnement de l’entreprise comme « première ». Établir une priorité exige un ensemble de comparaison défini et des définitions cohérentes. Des termes tels que fluide, temps réel et sans perte nécessitent des limites mesurables avant de pouvoir étayer un classement universel.

Le temps réel dépend particulièrement de l’application. Une réponse écrite diffusée progressivement peut tolérer des délais qui interrompraient une interaction en direct. Un seuil de débit technique ne peut pas établir l’adéquation à chaque interface.

Les sessions plus longues introduisent un autre test important. Les évaluateurs devraient mesurer les requêtes répétées, l’évolution des conditions de l’appareil et l’activité concurrente d’autres applications. Il s’agit de questions sur la durabilité opérationnelle, plutôt que de preuves que l’implémentation communiquée se dégrade nécessairement.

Les tests de qualité des réponses devraient inclure des échecs que les utilisateurs peuvent reconnaître. Dans un hypothétique flux de gestion des dépenses, cela signifie vérifier si les entrées extraites correspondent au reçu. Dans l’analyse de documents, cela signifie vérifier si les explications restent ancrées dans la page fournie.

Un flux de travail de connaissance plus large ajoute la récupération, c’est-à-dire le processus de sélection du contenu stocké pertinent pour une réponse. Les lecteurs qui comparent les bases de connaissances personnelles devraient évaluer cette couche séparément de la vitesse de génération du modèle. Une sortie plus rapide ne peut pas compenser la sélection du mauvais document source.

L’exécution locale requiert également une interprétation attentive. Elle offre une option de déploiement pour traiter les entrées sur l’appareil, mais ne décrit pas chaque flux de données d’une application terminée. L’architecture de l’application détermine ce qui reste local.

Ces distinctions renforcent l’analyse en rendant les affirmations vérifiables. La question n’est plus de savoir si une « IA mobile sans perte » paraît plausible. Elle est de savoir quel comportement demeure inchangé, quelles ressources le système consomme et quelles mesures démontrent le résultat.

MiniCPM LES offre aux développeurs une proposition d’ordonnancement précise à examiner. Son adoption devrait suivre des résultats reproductibles et des contrôles de qualité au niveau de l’application, chaque conclusion étant liée à la propriété effectivement mesurée.

Trois signaux montreront si l’approche se transpose aux produits

Les prochaines preuves devraient relier la reproductibilité, l’usage soutenu et la disponibilité de l’implémentation, dans cet ordre.

Le premier signal est une reproduction indépendante avec des artefacts et des paramètres identifiables. Au cours des prochains mois, un résultat utile inclurait les fichiers exacts du modèle, la révision du runtime, les prompts et les limites de mesure. Ces détails permettraient à d’autres développeurs d’examiner la même affirmation.

Une reproduction devrait rapporter plus que son meilleur essai. La variation entre les requêtes importe lorsque les équipes planifient un service interactif. Des résultats cohérents renforceraient la confiance que la vitesse publiée représente une configuration utilisable.

Un résultat inférieur nécessiterait une interprétation plutôt qu’un rejet immédiat. Des fichiers de poids ou des paramètres différents pourraient expliquer un écart. Une divergence reproductible dans des conditions identiques affaiblirait plus directement l’affirmation initiale de performance.

Le deuxième signal est un test soutenu sur des charges de travail représentatives. Les évaluateurs devraient suivre les requêtes complètes, de l’envoi de l’entrée jusqu’à la réponse finale. Ils devraient aussi vérifier la qualité en parallèle de la réactivité, car une sortie incorrecte mais plus rapide apporte peu de valeur au produit.

C’est à ce stade que l’inférence MoE mobile passe d’une démonstration technique à une décision applicative. Une évaluation utile montrerait si les bénéfices persistent lors de requêtes répétées sur des documents ou des images. Elle identifierait aussi les conditions dans lesquelles un modèle résident plus petit reste préférable.

Les résultats entre appareils préciseraient la portée. Un comportement similaire sur du matériel supplémentaire étayerait une applicabilité plus large. Des résultats concentrés sur une configuration étroite indiqueraient une opportunité de déploiement plus spécialisée.

Le troisième signal est une intégration accessible de la pile d’optimisation requise. Les développeurs ont besoin d’un chemin clair entre les poids publiés et l’implémentation à l’origine du benchmark. La documentation devrait rendre sans ambiguïté les choix nécessaires de runtime et d’artefacts.

Cette disponibilité est importante, car la compatibilité et des performances équivalentes sont deux réussites distinctes. Charger un modèle pris en charge ne garantit pas qu’une application active chaque optimisation d’ordonnancement et de stockage. Reproduire la configuration complète constitue l’étape pertinente.

Une intégration claire renforcerait l’idée qu’il s’agit d’une infrastructure réutilisable pour les applications mobiles. Des instructions fragmentées ou des résultats dépendants de la configuration rendraient l’adoption plus difficile, même si la technique sous-jacente demeure solide.

Pour les équipes envisageant un projet pilote, l’étape suivante appropriée consiste en une évaluation limitée utilisant des contenus qui ressemblent à des demandes réelles d’utilisateurs. Incluez les documents difficiles et les images délicates qui révèlent si une capacité de modèle accrue améliore la réponse. Mesurez le temps d’attente ressenti par les utilisateurs, en parallèle de l’utilisation des ressources et de l’exactitude. Gardez la configuration de référence fixe lors de l’évaluation de chaque optimisation, afin que les améliorations restent attribuables. MiniCPM LES mérite de l’attention, car il propose une manière concrète de préserver le choix des experts tout en réduisant les délais de chargement. Avant de construire autour de la vitesse mise en avant, demandez-vous si cette même configuration fournit des réponses fiables tout au long du flux de travail mobile prévu.