La guerre pour l'inférence mobile : moins de I/O et une valeur partagée
La promesse de l'IA sur les téléphones a toujours été freinée par des limites pratiques : le modèle ne tient pas, la mémoire est insuffisante, le stockage est lent et la consommation d'énergie affecte l'expérience utilisateur. Pendant des années, le discours "sur appareil" a été soutenu par des modèles petits et de nombreuses concessions.
Le lancement de PowerInfer-2 modifie cette frontière avec une proposition concrète : exécuter des modèles qui dépassent la capacité de mémoire des appareils, en coordonnant CPU, NPU et stockage afin que le goulet d'étranglement ne domine plus les performances. Selon les évaluations, le système atteint une accélération de 29,2x par rapport à des alternatives comme llama.cpp et MLC-LLM, et atteint 11,68 tokens par seconde pour TurboSparse-Mixtral-47B dans des smartphones, une performance qui, jusqu'à récemment, semblait plus relever du marketing que de l'ingénierie vérifiable. L'histoire publique est liée au lancement open-source du 11 juin 2024 et à l'intégration avec des modèles TurboSparse (versions épargnées de Mistral et Mixtral) diffusée dans un article de HackerNoon.
Cette donnée, bien qu'impressionnante, est une victoire technique, mais l'enjeu économique réside dans la répartition de la valeur qu'elle permet : lorsque le coût marginal de service par token diminue à la périphérie, les prix, la dépendance au cloud, le contrôle sur le produit et le pouvoir de négociation entre fabricants, développeurs de frameworks, propriétaires de modèles et créateurs d’applications sont à renégocier.
L'innovation réelle est logistique : transférer moins de données, facturer plus pour l'expérience
Les chiffres les plus significatifs sont souvent cachés derrière le terme "optimisation". PowerInfer-2 se présente comme un cadre capable de faire fonctionner des LLM dépassant la capacité de mémoire du téléphone par deux idées opérationnelles : adaptation consciente de l'éparpillement et orchestration consciente de l'I/O. En d'autres termes : le système essaie de faire en sorte que le matériel accomplisse un travail utile pendant que le stockage fournit ce qui manque, et réduit la quantité de données à extraire du stockage au départ.
Dans les tests rapportés, PowerInfer-2 montre sur un OnePlus 12 (24 Go de DRAM et XPU de Qualcomm) une accélération moyenne de 24,6x par rapport à llama.cpp, avec des pics à 27,8x, surpassant également un approche d'externalisation comme LLMFlash avec 3,84x en moyenne et jusqu'à 4,63x. Pour les modèles de 7B qui peuvent être contenus en mémoire, le système prétend réduire l'utilisation de mémoire d'environ 40%, tout en maintenant des vitesses comparables à llama.cpp et MLC-LLM. Tout cela s'inscrit dans un objectif produit : inférence en temps réel, locale et privée.
L'intégration avec TurboSparse ajoute une autre couche : il ne suffit pas d'avoir un runtime sophistiqué si le modèle n’a pas une structure d'activation prévisible. Ici, TurboSparse promet une éparpillement plus « amical » pour une exécution efficace et se présente comme un habilitateur de jusqu'à 22x de vitesse supplémentaire pour Mixtral par rapport à llama.cpp sous PowerInfer-2, avec un entraînement d'éparpillement sur 150 milliards de tokens et un coût rapporté de 0,1 millions de dollars. C’est un détail économique pertinent : le coût de "rendre déployable" un grand modèle peut être inférieur au coût annuel de son service dans le cloud à grande échelle, ce qui modifie le calcul d'investissement pour les équipes produit.
En termes de chaîne de valeur, le point est simple. La performance n'augmente pas avec "plus de paramètres", mais avec moins de trafic interne et une meilleure répartition des charges entre unités hétérogènes. Si le produit final est une expérience fluide, l’entreprise qui capte la valeur sera celle qui transforme cette logistique en une intégration stable : temps de réponse constants, moindre consommation, moins de surchauffe, et un comportement prévisible sous différentes charges.
La répartition de la valeur change : cloud, fabricants, frameworks et applications rivalisent pour la marge
Lorsque les smartphones peuvent atteindre des taux de génération à deux chiffres en tokens par seconde avec un modèle de 47B, la discussion passe de "est-ce possible" à "qui facture quoi". Dans un monde dominé par les API d'IA, le prix final pour de nombreuses applications est lié à un coût par token et à une dépendance opérationnelle : latence, disponibilité et risque réglementaire lié aux données sensibles. Si une partie de cette demande migre vers l’appareil, le coût variable par token peut chuter brusquement pour le fournisseur de l'application, mais seulement si la pile est intégrée sans friction.
Ici, quatre positions de capture de valeur se dégagent :
1) Le fabricant de l'appareil et du silicium. Si PowerInfer-2 exploite mieux une XPU hétérogène (CPU+NPU) et démontre que 16-24 Go de DRAM permettent des expériences jusqu'alors réservées au cloud, le fabricant peut justifier une prime sur le matériel ou différencier sa gamme. Cependant, cette prime ne sera durable que si le bénéfice est transféré à l'utilisateur sous la forme d'une meilleure expérience, et non juste d'une liste de spécifications.
2) Le framework d'inférence. Un runtime open-source solide devient un standard de facto et déplace le pouvoir vers ceux qui contrôlent la compatibilité, la chaîne d'outils et la communauté. Ce pouvoir ne se monétise pas nécessairement par des licences ; il se monétise avec une influence sur les intégrations, le support, la distribution des modèles et, surtout, la réduction des coûts d'adoption pour les tiers.
3) Les propriétaires de modèles. TurboSparse propose une voie : prendre des architectures existantes et les rendre plus « exécutables » sur mobile. Si le coût d'éparpillement est faible par rapport à la valeur de distribution massive, le propriétaire du modèle peut élargir sa portée sans avoir à assumer les coûts d'une inférence cloud. Cependant, la valeur capturable par le propriétaire du modèle diminue si le modèle devient une commodité locale, interchangeable et sans lock-in.
4) L'application. C'est celle qui est la plus proche de l'utilisateur et qui peut facturer en fonction des résultats. Si elle parvient à transformer l'inférence locale en un avantage tangible (comme la confidentialité, l'absence de connexion, la latence), elle augmente sa marge en réduisant ses coûts variables. Mais cette marge sera fragile si elle dépend d'optimisations qui ne tiennent pas sur un éventail de dispositifs.
Le risque distributif apparaît lorsqu'un acteur tente de capter l'intégralité du bénéfice. Si le fabricant bloque ou enferme la pile, il augmente les coûts d'innovation des applications. Si le framework optimise pour un sous-ensemble minimal de matériel, cela laisse de côté utilisateurs et réduit le marché. Si le propriétaire du modèle tente de restreindre l'accès ou d'imposer des péages, il incite à se tourner vers des alternatives ouvertes. La stratégie durable est celle qui donne à chaque acteur une raison économique claire de rester : réduction des coûts pour les applications, différenciation pour le matériel et distribution pour les modèles.
De la démo à l'affaire : les contraintes mobiles obligent à des alliances, pas à de l'extractivisme
Le saut de PowerInfer-2 ne se produit pas dans un laboratoire idéal, mais dans un environnement hostile : stockage UFS avec des latences pénalisantes, mémoire limitée et unités de calcul avec des profils variés. La proposition technique citée —diviser le calcul au niveau de "clusters de neurones", en assignant des tâches denses au NPU et des tâches éparpillées au CPU, et en superposant le calcul à l'I/O— est, en essence, une conception d'opération pour une chaîne logistique interne. C'est ce type d'innovation qui, quand elle fonctionne, devient une infrastructure invisible.
Mais cette infrastructure invisible ne crée de la valeur que si le système peut être adopté sans réécriture du produit. Par conséquent, le vecteur stratégique n'est pas seulement "être plus rapide", mais "être intégrable" : stabilité des pilotes, portabilité entre modèles, compatibilité avec les pipelines de quantification et d'emballage, et des performances constantes sur une base installée hétérogène.
À ce stade, la tentation typique de l'industrie est de transférer le coût vers le maillon le plus faible. Dans le secteur mobile, il s'agit souvent du développeur d'application : on lui demande d'optimiser pour chaque appareil, de faire face à la fragmentation et d'accepter que l'expérience finale varie. Ce schéma est une taxe sur l'innovation et finit par réduire la taille du marché.
L'approche suggérée par PowerInfer-2, étant publiée en open-source et accompagnée de modèles dans des dépôts publics (selon les rapportages), vise une répartition plus pragmatique : le coût de l'ingénierie lourde se concentre sur un runtime commun et sur des modèles préparés pour une exécution efficace. Si cela est maintenu, les bénéficiaires ne seront pas uniquement les smartphones haut de gamme, mais aussi la couche de produit qui peut construire des expériences sans être pénalisée par des coûts cloud par défaut.
Cela dit, il y a un angle mort : la durabilité économique de la maintenance. Si la communauté ne couvre pas ce coût, quelqu'un d'autre le fera par une autre forme de captation : support commercial, accords avec des fabricants ou intégration préférentielle. La stabilité de la répartition dépend de la capacité à trouver un financement pour ce « coût fixe » sans transformer la pile en péage.
La valeur se déplace vers qui contrôle l'expérience locale sans rompre les incitatifs
Ce qui est le plus disruptif dans le fait de servir un 47B à 11,68 tokens/s dans un smartphone n'est pas tant le chiffre que le changement d'architecture commerciale : une partie du calcul qui justifiait la dépendance au cloud devient une capacité distribuée sur des millions d'appareils. Cela ne supprime pas le cloud, mais le repositionne : moins d'inférence transactionnelle et plus d'entraînement, de coordination, de mise à jour et de services complémentaires.
Pour les dirigeants, la lecture concrète est une revalorisation de la "marge de conception". Si une application réduit sa facture de tokens en migrant l'inférence vers le périphérique, cette marge peut être réinvestie dans l'acquisition, le contenu, le support ou le prix pour l'utilisateur. Si un fabricant transforme l'inférence locale en un véritable argument d'achat, il capte une partie de la valeur dans l'ASP, mais seulement s'il ne surcharge pas ceux qui créent les expériences. Si un framework devient la voie dominante, il capture de la valeur sous la forme d'un standard et d'un flux d'adoption, mais son pouvoir est maintenu tant qu'il réduit les coûts pour les tiers.
La couverture de TurboSparse Mobile présente une thèse implicite : avec une éparpillement prévisible et une orchestration fine entre NPU, CPU et stockage, la limite des "seuls petits modèles sur mobile" cesse d'être une loi physique. À partir de là, la vraie concurrence se déplace vers la conception produit et la gouvernance de la chaîne technique.
La décision stratégique qui sépare les gagnants des opportunistes est distributive : ceux qui partageront le bénéfice de l'inférence locale —baisse des coûts pour les applications, meilleure expérience pour les utilisateurs, différenciation pour le matériel et une voie de distribution pour les modèles— bâtiront une permanence ; ceux qui tenteront de saisir la totalité de la marge transformeront l'amélioration technique en un nouveau cycle de friction, et ce type d'avantage s'évapore dès qu'un nouveau runtime open-source apparaît.
