Xiaomi MiMo baisse de prix de 99 % n'est pas une stratégie marketing ! Luo Fulili répond aux détracteurs sur X

null

Texte | Xiang Xianzhi

Luo Fuli a publié un tweet pour mettre fin à la polémique sur la baisse de prix de Xiaomi MiMo.

Le 26 mai, le compte officiel de Xiaomi MiMo a publié une annonce sur X : la série API MiMo-V2.5 sera en baisse de prix permanente, avec une réduction maximale de 99 %. Tous les prix pour la longueur de contexte seront uniformes, et le forfait Token sera augmenté de 5 à 8 fois.

Cette annonce a fait le buzz dans le cercle de l'IA en Chine pendant toute une semaine. Les réactions dans l'industrie se sont divisées en plusieurs camps. Le plus grand groupe a dit que c'était "encore une guerre des prix" — ces deux dernières années, depuis Zhipu, DeepSeek, ByteDoudou, jusqu'à Alibaba Tongyi, les grands modèles nationaux ont tous réduit leurs prix, chacun se battant pour rester compétitif.

Un autre camp regarde cela de manière plus pessimiste : Xiaomi a annoncé que ses profits cette année avaient été coupés de moitié, et maintenant ils dépensent 600 milliards pour l'IA, tout en réduisant de 90 % leurs API — c'est typique d'une "perte pour gagner le marché". Certains pensent aussi que c'est une continuation de l'effet DeepSeek — ce dernier a tiré la référence de prix de toute l'industrie vers le bas, et ceux qui ne suivent pas seront éliminés.

En tant que responsable de MiMo, Luo Fuli a publié hier soir un blog technique de 5000 mots, rendant publics les comptes d'ingénierie de la baisse de prix.

"Regardez, c'est une véritable capacité technique, pas une simple stratégie marketing."

Pour comprendre ce que Luo Fuli veut dire, il faut d'abord saisir ce que signifie cette baisse de 99 %.

Ce n'est pas une réduction sur l'ensemble du modèle. La réduction de 99 % concerne spécifiquement un tarif appelé Input (Cache Hit), c'est-à-dire la partie où "l'utilisateur répète la lecture de l'historique dans une longue conversation". La nouvelle tarification pour les nouveaux inputs (No Cache Hit) est beaucoup moins importante, et la réduction pour la sortie du modèle (Output) est la plus faible.

Si vous considérez le modèle comme un café, cela devient plus clair.

Vous commandez un latte à moitié sucré, le café a deux méthodes : soit moudre les grains et ajouter du sirop et du lait à chaque fois, ce qui coûte du travail à chaque fois ; soit, si le modèle sait que vous boirez le même latte à moitié sucré tous les jours cette semaine, il prépare une grande quantité à l'avance, la met au congélateur, et la sert à chaque commande en prélevant une portion. MiMo a choisi la seconde méthode — transformer la partie que l'utilisateur lit en "prélevé à la demande" plutôt qu'en "calcul en temps réel", ce qui réduit le coût réel de cette partie à presque zéro, permettant ainsi une réduction de 99 %.

Pour réaliser ce "prélevé à la demande", le blog technique décrit six étapes d'ingénierie, chacune indispensable. Regardons-les une par une.

Étape 1 : réduire la "mémoire" du modèle à 1/7

Lors de la conversation, chaque token doit calculer un "état intermédiaire" qui est stocké pour la prochaine étape. Ce stockage s'appelle KVCache — on peut le voir comme un "carnet de mémoire à court terme" du modèle. Après chaque phrase, le modèle enregistre un résumé dans ce carnet, et la fois suivante, il peut accéder directement à ce résumé sans relire tout ce qui a été dit.

Les modèles traditionnels utilisent une "Attention complète" à chaque couche — chaque token doit regarder tous les autres tokens de la conversation, ce qui fait que le carnet devient de plus en plus gros. La version MiMo-V2.5-Pro modifie cette architecture : sur 70 couches, 60 ne regardent que les 128 tokens les plus récents (SWA, Sliding Window Attention), et seulement 10 couches, appelées "administrateurs de dossiers", regardent tout.

Le résultat est que la taille du KVCache est réduite à 1/7 de celle de l'Attention complète, avec une charge de calcul également divisée par 7.

C'est la première étape pour réduire les coûts. Par analogy, si chaque employé de l'entreprise devait se souvenir de toutes les réunions, la mémoire de chacun serait insuffisante et l'efficacité faible. La nouvelle règle réduit la charge mentale de 60 employés à 1/7, laissant 10 "administrateurs" gérer toute l'historique — la mémoire globale de l'entreprise n'a pas diminué, mais l'efficacité a été multipliée par 7.

Étape 2 : faire en sorte que l'espace économisé par SWA soit réellement utilisable

Réduire le carnet à 1/7 est la première étape, mais pour que cette "théorie" se traduise en "pratique", il faut encore franchir une étape.

Le système traditionnel de KVCache alloue toute la mémoire de manière uniforme à toutes les couches, en fonction de la "capacité maximale". Cela signifie que même si les 60 couches SWA n'ont besoin que d'un petit carnet, le système leur réserve la même grande mémoire que pour les 10 couches d'Attention complète — l'espace économisé par SWA est donc en grande partie réservé mais inutilisé, ce qui ne permet pas de faire de vraies économies.

L'équipe de Luo Fuli a divisé le KVCache en deux pools indépendants : les 10 couches d'Attention complète utilisent un "grand pool" alloué à la longueur totale, tandis que les 60 couches SWA utilisent un "petit pool" alloué uniquement à une fenêtre de 128 tokens.

En analogy, c'est comme si l'entreprise distribuait à chaque employé un grand coffre pour stocker 100 ans de documents, alors qu'en réalité, 60 employés n'ont besoin que d'un petit coffre pour une semaine de documents — la majorité de l'espace dans ces grands coffres est vide. La nouvelle méthode consiste à allouer des coffres en fonction des besoins réels. Résultat : l'entreprise peut accueillir plus de collègues dans le même espace — la capacité de service simultané d'une même GPU a été multipliée par 5.

Cela peut sembler simple, mais sans cette étape, les avantages de l'architecture SWA seraient vains.

Étape 3 : faire en sorte que la "lecture répétée par les anciens utilisateurs" soit réellement mise en cache

Après avoir réduit le carnet à 1/7 et utilisé l'espace efficacement, il faut résoudre un problème ancien : le taux de réussite du cache pour les préfixes.

De nombreux utilisateurs ont des conversations qui commencent de la même façon — même prompt système, même code, même long document. Le système stocke ces résultats calculés pour une réutilisation ultérieure. Ce mécanisme s'appelle le cache de préfixe.

Mais avec SWA, un problème apparaît : deux requêtes avec le même token ne garantissent pas que le KV est toujours valable. Il se peut que le préfixe ait été calculé, mais que la partie hors de la fenêtre SWA ait été éliminée. Si le système continue à supposer que "même token" signifie "cache valide", il risque de lire des données obsolètes ou écrasées, ce qui dégraderait la performance du modèle.

Luo Fuli a amélioré la règle pour qu'elle soit "sûre dans la longueur de la fenêtre" — en ne garantissant que la partie que l'on peut vraiment utiliser.

En analogy, si la bibliothèque possède 1 million de livres, et que vous souhaitez emprunter la trilogie "Three-Body" en trois volumes, l'ancien système vous dirait "le livre est là", mais en réalité, il ne reste que la couverture et le premier volume, les autres ayant été empruntés. Cela vous oblige à revenir pour une nouvelle empruntée. La nouvelle règle garantit que vous pouvez emprunter uniquement la partie complète disponible — d'abord le premier volume, puis les autres seront récupérés plus tard.

Cela semble plus strict, et on pourrait penser que le taux de réussite baisse. En réalité, c'est le contraire : grâce à SWA, la taille du KVCache est réduite à 1/7, ce qui permet de stocker beaucoup plus de contenu dans la même mémoire, augmentant ainsi considérablement le taux de cache.

L'équipe de Luo Fuli cite des chiffres mesurés en ligne : dans un cadre standard, le taux de cache côté serveur atteint en moyenne 93 %, et pour les utilisateurs réguliers à long cycle, il dépasse 95 %.

En traduction, cela signifie que 95 % des requêtes de "lecture répétée" n'ont pas besoin d'être calculées par le GPU, elles sont directement récupérées du cache. C'est la base physique de la réduction de 99 %.

Étape 4 : stocker le cache dans le SSD intégré au GPU

Avec un taux de cache élevé, la question suivante est : où stocker ces caches ?

La mémoire vidéo (HBM sur GPU) est coûteuse et limitée — une machine H100 à 8 cartes dispose de 640 Go de mémoire, mais le KVCache de MiMo peut atteindre plusieurs dizaines de téraoctets. Il faut donc une hiérarchie : la mémoire la plus récente dans la mémoire vidéo (L1), la mémoire un peu plus ancienne dans la mémoire CPU (L2), et les données froides dans un cache distribué (L3).

C'est comme gérer un portefeuille : l'argent liquide est la mémoire vidéo — accessible rapidement mais limitée ; le solde bancaire est la mémoire CPU — accessible en 30 secondes mais beaucoup plus grand ; le dépôt à terme est le cache distribué L3 — accessible en 2 minutes mais beaucoup moins cher.

La pratique courante dans l'industrie consiste à créer un cluster dédié pour le stockage L3, avec du matériel et des centres de données spécifiques, en payant un loyer mensuel.

L'équipe de stockage de Xiaomi a une approche différente : ils ont développé GCache, un cache distribué déployé directement sur le SSD intégré au GPU — partageant la machine avec la tâche d'entraînement ou d'inférence.

En traduction simple : d'autres louent un entrepôt pour stocker de grandes quantités de données ; Xiaomi a constaté que le garage du GPU est souvent vide, ils y ont stocké directement les données. Cela réduit le coût mensuel.

Le blog technique indique : "Le coût de stockage supplémentaire est nul."

C'est une innovation puissante. Dans le calcul traditionnel de la puissance de calcul IA, le coût de stockage est une dépense fixe — plus votre modèle est grand et plus vous avez d'utilisateurs, plus cette dépense augmente. GCache élimine cette dépense. Avec la petite taille de SWA et un taux de réussite de 93-95 %, la durée de vie du KVCache en L3 (TTL) passe de quelques minutes à plusieurs heures, voire plusieurs jours — plus le TTL est long, plus la fenêtre de réussite du contexte historique est large, et plus le taux de cache est élevé, renforçant la réduction de 99 %.

Étape 5 : faire en sorte que les requêtes qui trouvent le cache empruntent le chemin le plus court

Le cache peut être stocké, consulté et est peu coûteux, mais la dernière étape est : comment router la bonne requête vers la bonne machine.

Xiaomi a développé son propre système de routage appelé LLM-Router, qui réalise trois choses :

1. La cohérence d'affinité. Les requêtes avec le même préfixe sont envoyées à la même machine, pour maximiser la réutilisation du cache.

2. La segmentation par longueur. Les requêtes courtes (0-64K), moyennes (64K-256K) et longues (256K-1M) sont traitées par des canaux différents, pour éviter que les longues ralentissent les courtes.

3. L'optimisation TTFT. Dans la file d'attente d'inférence, les requêtes avec une charge de calcul réelle faible (c'est-à-dire celles qui ont beaucoup de cache) sont prioritaires — pour éviter qu'elles soient bloquées par des requêtes de nouvelle entrée nécessitant beaucoup de calcul.

Par analogy, dans un aéroport, tous les passagers pour la même destination sont regroupés dans la même salle d'embarquement — partageant le processus de récupération des bagages. Ceux avec une valise cabine sont traités séparément de ceux avec de gros bagages, pour accélérer le départ — c'est la cohérence d'affinité. La priorité est donnée à ceux qui embarquent rapidement, pour faire décoller l'avion plus tôt — c'est l'optimisation TTFT.

Selon les tests, cette stratégie augmente de 25 % le taux de cache L2, améliore de 30 % le débit par machine, et réduit de 30 % la latence P90 des longues requêtes.

En traduction, cela signifie qu'une même GPU peut servir plus d'utilisateurs. La moitié de la baisse de prix repose ici — une meilleure efficacité par unité de puissance, et un coût utilisateur plus faible.

Étape 6 : accélérer aussi la "dactylographie" du modèle

Les cinq premières étapes optimisent la lecture — réduire le coût de la lecture répétée de l'historique à presque zéro. La sixième étape concerne l'écriture — le processus par lequel le modèle génère le prochain token.

Traditionnellement, un modèle ne peut générer qu'un seul token à la fois. MiMo supporte nativement le Multi-Token Prediction (MTP) à 3 couches — prédire les 3 prochains tokens en une seule étape, et si la prédiction est correcte, sauter la génération intermédiaire.

En analogy, c'est comme taper un mot à la fois — pour écrire "Aujourd'hui il fait beau", il faut appuyer 4 fois. Avec MTP, c'est comme si un assistant complétait automatiquement les 1-2 prochains caractères — si la prédiction est correcte, vous n'avez pas besoin d'appuyer à nouveau.

Les tests en environnement agentique montrent que, pour les 128 premiers tokens, la décodification accélère de 2,3 fois, et pour 128-256 tokens, de 1,5 fois.

L'importance de cette étape est que la réduction de 99 % concerne principalement Input (Cache Hit), mais en pratique, lors d'une requête, input et output se produisent dans la même demande — si l'output n'est pas réduit, la réduction ne concerne que la moitié du coût. MTP permet aussi de réduire cette moitié, complétant ainsi le modèle de profit de la baisse de prix.

En résumé, les six étapes forment une chaîne de réduction des coûts :

Architecture SWA → KVCache à 1/7 → libération réelle de capacité par double pool → capacité de service 5+ fois plus d'utilisateurs par GPU → taux de cache de 93-95 % → 95 % des requêtes n'ont presque pas besoin de calcul → GCache élimine le coût de stockage → routage prioritaire des requêtes en cache → MTP accélère la génération → réduction du temps GPU par requête d'un ordre de grandeur → baisse du coût unitaire de 95 %+ → réduction de prix de 99 %, tout en maintenant une marge bénéficiaire positive.

Chaque étape manquante brise cette chaîne. La baisse de 99 % n'est pas une simple stratégie marketing, mais le résultat de six piliers d'ingénierie combinés et vérifiés en ligne.

En regardant les premières interprétations de l'industrie, chacune a une part de vérité. La guerre des prix entre entreprises chinoises de grands modèles est réelle ; Xiaomi a vraiment réduit ses profits de moitié tout en investissant dans l'IA ; DeepSeek a vraiment tiré la référence de prix vers le bas.

Mais le blog technique de Luo Fuli, avec ses détails précis, vise sans doute à répondre à ces discours, en séparant "technique" et "marketing".

Elle écrit dans le blog que l'efficacité d'inférence de la série MiMo-V2.5 ne résulte pas d'une seule avancée, mais d'une optimisation multidimensionnelle. Le Hybrid SWA permet de bénéficier à la fois du pré-remplissage et du décodage, mais une implémentation non optimisée du KVCache peut en augmenter le coût. La reconstruction systématique du gestionnaire KVCache, du cache hiérarchisé, de l'arbre de cache de préfixe, la résolution des problèmes clés du KVCache SWA, l'optimisation de la stratégie de routage et des liens Pre-fill / Decode ont été testés en environnement réel, et ont permis de concrétiser cette efficacité théorique dans la production. Grâce à cela, le Hybrid SWA peut exploiter pleinement ses avantages en termes de puissance et d'efficacité pour le raisonnement sur de longs textes. En combinant avec des configurations MoE et diverses optimisations multimodales, la performance du service d'inférence en ligne a été considérablement améliorée.

C'est une approche systématique de l'ingénierie IA, une méthode de réduction des coûts qui mérite d'être partagée dans l'industrie.

La guerre des prix ne nécessite pas de blog, mais la mise en œuvre concrète oui.