Article | Xiang Xian Zhi
Luofuli a publié un message sur X pour clore le scandale de la baisse de prix de MiMo de Xiaomi.
Le 26 mai, le compte officiel MiMo de Xiaomi a publié une annonce sur X : les API de la série MiMo-V2.5 connaissent une réduction permanente allant jusqu'à 99 %. Toutes les longueurs de contexte sont désormais tarifées de manière uniforme, et les forfaits Token sont améliorés de 5 à 8 fois.
Cette annonce a dominé le cercle de l'IA en Chine pendant une semaine entière. Les réactions initiales du secteur se sont divisées en plusieurs camps. Le plus grand camp a déclaré que c'était « une autre guerre des prix » — ces deux dernières années, des modèles de grande taille chinois comme Zhipu, DeepSeek, ByteDance DouBao et Alibaba Tongyi ont alterné les baisses de prix, et personne n'échappe à la concurrence.
Un autre point de vue plus pessimiste : Xiaomi vient d’annoncer que son bénéfice cette année a été divisé par deux, et pourtant, elle continue de dépenser 60 milliards de yuans dans l’IA et de réduire ses API de 90 % — un classique « perte pour conquérir le marché ». Certains pensent que c’est encore l’effet DeepSeek — cette dernière ayant fait chuter la base de tarification de toute l’industrie au sol ; qui ne suit est éliminé.
En tant que responsable de MiMo, Luo Fuli a directement publié une note technique de 5000 mots hier soir, rendant publics les détails techniques de la réduction de prix.
Regardez, c'est une véritable capacité technique, pas une stratégie de marketing.
Pour comprendre ce que Luo Fuli dit, il faut d'abord savoir ce que ce 99 % a réduit.
Ce n'est pas une réduction générale sur le modèle. La réduction de 99 % s'applique uniquement à la catégorie de tarification appelée Input (Cache Hit) — c'est-à-dire la partie où les utilisateurs lisent à nouveau le contexte historique dans des conversations longues. Les nouvelles entrées ordinaires (No Cache Hit) bénéficient d'une réduction beaucoup plus faible, et la sortie du modèle (Output) connaît la réduction la plus faible.
Si vous considérez le modèle comme un café, cela devient plus facile à comprendre.
Vous commandez un latte à moitié sucré, et le café a deux façons de le préparer : soit chaque fois, moudre les grains, verser le sirop et le lait depuis le début, en payant les matières premières et la main-d'œuvre à chaque fois ; soit le modèle sait que vous allez boire le même latte à moitié sucré tous les jours cette semaine, alors il en prépare une grande casserole qu'il garde au réfrigérateur, et sert simplement une portion à chaque fois. MiMo a opté pour la deuxième méthode — il a transformé la lecture répétée des utilisateurs de « calculée à la demande » en « récupérée à la demande », ce qui fait que le coût réel de cette partie est proche de zéro, permettant naturellement une réduction de 99 %.
Pour réaliser « la prise en direct », six projets techniques sont décrits dans le blog technique, aucun ne peut être omis. Examinons-les un par un.
Projet 1 : Réduire la mémoire du modèle à 1/7
Lorsqu'un modèle dialogue avec vous, chaque token génère un « état intermédiaire » qui est stocké pour être utilisé à l'étape suivante. Cet élément s'appelle KVCache — on peut le comparer à un « carnet de mémoire à court terme » du modèle. À chaque phrase prononcée, le modèle note un résumé de cette phrase dans son carnet ; à la prochaine interaction, il consulte simplement ses notes au lieu de réécouter tout ce que vous avez dit depuis le début.
Le modèle traditionnel applique une « pleine attention » à chaque couche — c’est-à-dire que chaque token examine l’ensemble des tokens de la conversation, ce qui revient à accumuler de plus en plus de pages dans un cahier. MiMo-V2.5-Pro modifie cette architecture : sur les 70 couches, 60 ne regardent que les 128 derniers tokens (SWA, Sliding Window Attention), tandis que seulement 10 couches, les « gestionnaires d’archives », examinent l’intégralité du texte.
Le résultat est que le volume du KVCache est réduit directement à 1/7 de celui de l'attention complète, et la quantité de calcul est également de 1/7.
C'est la première fondation pour réduire les coûts. Par exemple, auparavant, chaque employé de l'entreprise devait se souvenir de toutes les minutes de réunion, ce qui surchargeait tout le monde et réduisait l'efficacité. La nouvelle règle réduit la charge mentale des 60 employés à 1/7, en confiant la gestion de l'ensemble de l'historique à seulement 10 administrateurs d'archives — la capacité mémoire globale de l'entreprise n'a pas diminué, mais son efficacité a été multipliée par 7.
Projet 2 : Rendre l'espace économisé par SWA réellement utilisable
Réduire le notebook à 1/7 sur le plan architecturale est la première étape, mais passer de « 1/7 théorique » à « 1/7 réel » représente encore un obstacle.
Les systèmes traditionnels de KVCache allouent la mémoire GPU à toutes les couches selon le « usage maximal possible ». Cela signifie que même si les 60 couches SWA n'ont besoin que d'un petit cahier, le système leur attribue tout de même la taille d'un grand registre d'archiviste — l'espace économisé par SWA est simplement réservé inutilement, ce qui revient à ne pas avoir économisé d'espace.
L'équipe de Luo Fuli a séparé le KVCache en deux pools indépendants. Les 10 couches de Full Attention utilisent le « grand pool », avec une allocation sur la longueur complète ; les 60 couches de SWA utilisent le « petit pool », avec une allocation limitée à une fenêtre de 128 tokens.
Par exemple, l'entreprise fournissait à chaque employé un classeur capable de contenir 100 ans de documents — mais 60 employés n'avaient en réalité besoin que de petits classeurs pour une semaine de documents, laissant 99 % de l'espace des grands classeurs inutilisé. La nouvelle approche consiste à distribuer des classeurs selon les besoins réels. Résultat : le bureau peut désormais accueillir plus de cinq fois plus d'employés — le nombre d'utilisateurs simultanés qu'une seule GPU peut servir a été multiplié par cinq.
Cette étape semble simple, mais sans elle, les avantages de l'architecture SWA précédente sont vains.
Projet 3 : Faire en sorte que « la lecture répétée par les anciens utilisateurs » cible réellement le cache
Laptop pressé à 1/7 + l'espace est vraiment utilisable, l'étape suivante consiste à résoudre un vieux problème : le taux de命中 du cache de préfixe.
De nombreux échanges d'utilisateurs commencent de la même manière — même prompt système, même bibliothèque de code, même document long. Le système stocke les résultats déjà calculés et les réutilise directement lorsqu'une correspondance est trouvée. Ce mécanisme s'appelle le cache de préfixe.
Mais dans le mode SWA, il y a un piège : deux requêtes ayant le même jeton ne signifient pas que les données KV sont encore valides. Il est possible que le préfixe ait été calculé, mais les parties hors de la fenêtre SWA ont déjà été éliminées. Si le système réutilise les données selon l'ancienne règle « même jeton = hit », il pourra lire des données invalides ou écrasées, ce qui entraînera une dégradation immédiate des performances du modèle.
L'équipe de Luo Fuli a mis à jour les règles pour appliquer la « longueur de sécurité de la fenêtre » — ne garantissant que la partie que vous pouvez emprunter intégralement.
Par exemple, une bibliothèque possède un million de livres, et vous souhaitez emprunter la série complète de trois volumes de "The Three-Body Problem". L'ancienne architecture vous indiquerait « Ce livre est disponible », mais en vous rendant sur place, vous découvrez que l'étagère ne contient que la couverture et le premier volume ; les deux volumes suivants ont déjà été empruntés. Ce « faux positif » vous oblige à faire un déplacement inutile et à recommencer la demande. Le nouveau système ne promet plus que les parties que vous pouvez emprunter intégralement — il vous fournit d'abord le premier volume, puis récupère les deux volumes suivants pour vous.
Cela semble plus strict et entraîner une baisse du taux de réussite, mais en réalité, c’est l’inverse : puisque SWA réduit la taille du KVCache à 1/7, le même espace de stockage peut contenir plusieurs fois plus de données, ce qui augmente considérablement le taux de réussite réel.
Dans son blog, Luo Fuli a fourni des chiffres réels en ligne : sous les principaux cadres harness, le taux de命中 du cache serveur est en moyenne de 93 %, et peut dépasser 95 % pour les utilisateurs à forte fréquence et à long cycle.
La signification de ce chiffre : 95 % des demandes de « lecture répétée » n'utilisent pas du tout le GPU, mais récupèrent directement les données depuis le cache. C'est la base physique du rabais de 99 %.
Projet 4 : Intégrer le « cache » dans le SSD intégré au GPU
Le taux de réussite a augmenté, la prochaine question est : où ces caches sont-ils stockés ?
La mémoire vidéo (mémoire HBM sur GPU) est chère et limitée — une machine H100 à huit GPU ne dispose que de 640 Go de mémoire vidéo, tandis que le KVCache à stocker pour MiMo peut atteindre plusieurs dizaines de To. Il est donc nécessaire d’implémenter une architecture en couches : les données les plus récemment utilisées sont conservées en mémoire vidéo (L1), les données légèrement plus anciennes en mémoire CPU (L2), et les données froides dans un cache distribué (L3).
C'est pareil que de gérer votre argent. L'argent liquide dans votre portefeuille est la mémoire vidéo — disponible à tout moment mais avec une capacité limitée. Le solde de votre carte bancaire est la mémoire CPU — il faut 30 secondes pour le retirer, mais vous pouvez y stocker beaucoup. Le dépôt à terme est un cache distribué L3 — il faut 2 minutes pour le retirer, mais c'est beaucoup moins cher.
La pratique courante de l'industrie consiste à déployer un cluster de stockage dédié pour L3, avec des serveurs spécifiques et un data center exclusif, avec paiement mensuel du loyer.
L'équipe de stockage de Xiaomi adopte une approche différente. Elle a développé en interne un cache distribué appelé GCache, déployé directement sur les SSD intégrés aux machines GPU — partageant la même machine que les tâches d'entraînement et d'inférence.
Quelqu'un a loué un entrepôt spécialement pour stocker de grandes quantités de données ; Xiaomi a constaté que le garage contenant les machines GPU était inutilisé et a directement stocké les données dedans, économisant ainsi le loyer mensuel.
Le coût de stockage supplémentaire est de 0.
L'impact de cela est plus fort qu'il n'y paraît. Dans le compte traditionnel des coûts de calcul des entreprises d'IA, le coût de stockage est une dépense fixe — plus votre modèle est volumineux et plus vous avez d'utilisateurs, plus votre facture de stockage s'allonge. La méthode de GCache élimine complètement cette dépense. Associée à la petite taille de SWA et à un taux de réussite de 93 à 95 %, la durée de vie (TTL) du KVCache en L3 passe de quelques minutes à plusieurs heures, voire plusieurs jours — plus la TTL est longue, plus la fenêtre de correspondance pour le contexte historique s'élargit, plus le taux de réussite du cache augmente, et plus la réduction de 99 % devient crédible.
Projet 5 : Faire emprunter le chemin le plus court aux requêtes qui atteignent le cache
Le cache peut stocker, rechercher et coûte peu cher ; la dernière étape consiste à acheminer les bonnes requêtes vers les bonnes machines.
Xiaomi a développé son propre système d'ordonnancement appelé LLM-Router, qui effectue trois tâches :
Premièrement, le调度 d'affinité. Les requêtes ayant le même préfixe sont acheminées vers la même machine afin de maximiser la réutilisation du cache.
Deuxièmement, le regroupement par taille. Répartissez les courtes requêtes (0-64 Ko), les requêtes moyennes (64 Ko-256 Ko) et les longues requêtes (256 Ko-1 Mo) sur des canaux de traitement distincts pour éviter que les courtes requêtes ne soient ralenties par les longues.
Troisièmement, optimisation de TTFT. Dans la file d'attente pour l'inférence, prioriser l'ordonnancement des requêtes nécessitant peu de calculs réels (c'est-à-dire celles qui hit fortement le cache) — afin d'éviter qu'elles soient bloquées par des requêtes nécessitant un calcul lourd avec une entrée entièrement nouvelle.
Par exemple, dans un plan d'exploitation aéroportuaire classique, tous les passagers à destination du même endroit sont regroupés dans le même salon d'embarquement et partagent le même processus de retrait des bagages — c'est le scheduling par affinité. Les passagers avec un bagage à main et ceux avec trois grandes valises vérifiées empruntent deux voies de sécurité différentes, afin que les rapides ne soient pas ralentis par les lents — c'est le bucketing par longueur. Lors de l'embarquement, les passagers n'ayant qu'un bagage à main sont priorisés, car ils embarquent plus vite, permettant ainsi un décollage plus précoce de l'avion — c'est l'optimisation TTFT.
Cette stratégie d'ordonnancement a réellement augmenté le taux de命中 du cache L2 de 25 %, le débit d'entrée par machine de 30 % et réduit la latence P90 des requêtes longues de 30 %.
La même GPU peut servir plus d'utilisateurs. L'autre moitié de la logique de la réduction de prix réside ici : la production effective par unité de puissance de calcul est plus élevée, et le coût par utilisateur est plus faible.
Projet 6 : Accélérer la vitesse de frappe du modèle
Les cinq premières actions optimisent le côté « lecture » — en réduisant le coût pour l'utilisateur de relire le contexte historique à presque zéro. La sixième action optimise le côté « écriture » — c'est-à-dire le processus de génération du prochain token par le modèle.
Les modèles traditionnels génèrent un seul token à la fois. MiMo prend en charge nativement 3 niveaux de MTP (Multi-Token Prediction) — prédire les 3 prochains tokens en une seule fois, et sauter directement les calculs intermédiaires si les prédictions intermédiaires sont correctes.
Par exemple, taper traditionnellement consiste à saisir un caractère à la fois — si vous voulez écrire « aujourd'hui, il fait beau », vous devez appuyer 4 fois sur les touches. MTP fonctionne comme une complétion automatique qui devine vos 1 à 2 prochains caractères — si elle a raison, vous n'avez pas besoin d'appuyer sur ces touches supplémentaires.
MTP de MiMo testé en scénarios agentic : accélération de 2,3 fois pour les 128 premiers tokens, 1,5 fois pour les tokens 128 à 256.
L'importance de cela réside dans le fait que la réduction de 99 % s'applique spécifiquement à l'entrée (cache hit), mais lorsque le modèle sert réellement les utilisateurs, l'entrée et la sortie se produisent au sein d'une même requête — si la sortie n'est pas optimisée, le coût total de la requête n'est réduit que de moitié. MTP permet également de réduire cette moitié liée à la sortie, bouclant ainsi le modèle économique de réduction globale.
Chaîne de réduction des coûts reliant six éléments :
Architecture SWA → KVCache 1/7 → Deux piscines libèrent réellement la capacité → Un seul GPU peut héberger 5 fois plus de concurrence → Taux de réussite du cache de préfixe : 93-95 % → 95 % des requêtes nécessitent presque aucun calcul → GCache réduit les coûts de stockage à zéro → L'ordonnancement priorise les requêtes avec hit → MTP réduit également la génération → Le temps GPU par requête diminue d'un ordre de grandeur → Le coût unitaire baisse de plus de 95 % → Les prix baissent de 99 %, tout en restant rentables.
Si un seul maillon manque, la chaîne se rompt à ce niveau. La réduction de 99 % n'est pas un chiffre marketing, mais l'effet cumulé de six piliers techniques combinés à une validation en ligne réelle.
En regardant les différentes interprétations initiales du secteur, chacune contient une part de vérité. La guerre des prix entre les entreprises chinoises de grands modèles ces deux dernières années est réelle ; le fait que Xiaomi ait vu ses bénéfices divisés par deux tout en continuant d’investir massivement dans l’IA est réel ; et le fait que DeepSeek ait poussé les prix du secteur au plus bas est également réel.
Mais en publiant cette fois-ci un blog technique et en détaillant les aspects techniques, Luo Fuli vise sans doute à contester les allégations concernant la guerre des prix, afin de faire en sorte que « les problèmes techniques restent techniques, et les problèmes de marketing restent du domaine du marketing. »
Elle a écrit dans son blog que l'efficacité d'inférence de la série de modèles MiMo-V2.5 ne provient pas d'une percée unique sur un seul point, mais du résultat d'une optimisation coordonnée sur plusieurs dimensions. Hybrid SWA permet à la fois au prefill et au decode de bénéficier de gains, mais une implémentation non suffisamment optimisée du KVCache peut au contraire augmenter les coûts à chaque étape. Dans ce cadre, l'équipe MiMo a systématiquement重构é la gestion du KVCache, le cache hiérarchique et l'arbre de cache de préfixes, résolu les problèmes centraux du KVCache SWA, optimisé les stratégies d'ordonnancement ainsi que les chaînes prefill/decode, et validé ces améliorations dans des scénarios réels en production, concrétisant ainsi les avantages théoriques d'efficacité dans un environnement réel. À ce stade, Hybrid SWA a pleinement démontré ses avantages architecturaux en termes de puissance et d'efficacité pour l'inférence de textes longs. Associée aux optimisations diverses liées à la configuration MoE et à l'inférence multimodale, cette approche a considérablement amélioré les performances des services d'inférence en production.
Il s'agit d'une approche systématique en ingénierie IA, également une méthode de réduction des coûts值得行业共同参考借鉴的降本手段。
La guerre des prix n'exige pas d'écrire un blog, c'est la concrétisation technique qui en a besoin.