- Premier modèle à dépasser une vitesse de décodage de 1 000 tokens/s sur un modèle à 1 billion (1T) de paramètres
- Cette vitesse a été atteinte avec de simples commodity GPU, et non avec du matériel dédié, avec une sortie de plus de 1 000 tps sur un nœud standard unique de 8 GPU
- La technologie clé est un codesign modèle-système combinant la quantification FP4 et le speculative decoding DFlash
- L’API est proposée sur candidature et pour une durée limitée, avec la promesse d’une vitesse de génération d’environ 10x pour un prix 3x plus élevé
- Le franchissement des 1 000 tps n’est pas une simple amélioration de vitesse, mais un point de bascule susceptible de transformer le paradigme même des applications d’IA comme les Coding Agents ou la prise de décision en temps réel
Lancement de Xiaomi MiMo-V2.5-Pro-UltraSpeed
- En collaboration avec TileRT, le modèle est le premier à franchir les 1 000 tokens/s de vitesse de décodage sur un modèle à 1 billion de paramètres, offrant un niveau de rapidité permettant des réponses en temps réel et des itérations immédiates
- Dans les comparaisons de vitesse de génération en temps réel, il atteint jusqu’à environ 1 200 tokens/s
- L’idée avancée est que lorsqu’un modèle devient suffisamment rapide, il cesse d’être un simple outil d’attente pour devenir une extension de la pensée (extension of thinking)
Disponibilité limitée · sur candidature
- L’API est lancée à un tarif promotionnel limité, offrant une vitesse de génération d’environ 10x pour un coût 3x supérieur à MiMo-V2.5-Pro (API uniquement, non compatible avec le Token Plan)
- En raison des contraintes de ressources pour l’inférence à haute vitesse, l’accès fonctionne sur candidature et pour une durée limitée ; seuls les utilisateurs approuvés pourront utiliser l’API du 9 juin 2026 au 23 juin à 23:59 (UTC+8)
-
Comment postuler
- La plateforme API est accessible sur platform.xiaomimimo.com/ultraspeed ; déposer une demande ne garantit pas l’approbation, et la priorité est donnée aux entreprises et développeurs professionnels ayant un besoin métier réel
- L’accès au modèle standard est proposé via la série MiMo-V2.5
-
Essai Chat (gratuit pendant la période de test)
- Les utilisateurs approuvés bénéficient d’un accès Chat gratuit pendant 2 semaines, via ultraspeed.xiaomimimo.com
- Maximum 10 entrées en file d’attente par jour et par compte, 30 minutes maximum par session, avec déconnexion automatique après plus de 5 minutes d’inactivité
1 000 tokens/s — un changement de paradigme au-delà de la vitesse
- Franchir les 1 000 tps à l’échelle 1T ne revient pas simplement à disposer d’une machine à écrire plus rapide, mais à bouleverser en profondeur le paradigme même des applications d’IA
-
Quand la vitesse devient de l’intelligence
- À temps réel constant (wall-clock), il devient possible d’exécuter en parallèle des dizaines de chemins d’inférence (Best-of-N / Tree Search), avec vérification automatique et auto-correction en arrière-plan, ce qui améliore directement la qualité du raisonnement
-
Levée des limites de productivité des Coding Agents
- Jusqu’ici, la latence d’inférence était le goulot d’étranglement et les développeurs devaient attendre devant l’écran ; à 1 000 tps, la vitesse de génération de code et la productivité s’accélèrent à un niveau paradigmatique
-
Entrée dans une boucle de décision en temps réel
- Avec des cycles « think-respond » à l’échelle de la milliseconde, un modèle flagship 1T peut être intégré à des scénarios sensibles au facteur temps comme la génération de signaux de trading quantitatif haute fréquence, le blocage immédiat de transactions anormales, les enchères intelligentes ou les conversations en temps réel
- Le texte avance aussi que, dans des situations vitales comme l’assistance chirurgicale ou l’analyse d’imagerie médicale, chaque seconde gagnée sur l’analyse des lésions et la prédiction des risques donne au chirurgien une marge de manœuvre supplémentaire
Un codesign modèle-système poussé à l’extrême
-
Atteindre 1 000+ tps sur un modèle 1T ne repose pas sur une seule technique, mais sur le résultat d’un codesign extrême entre l’équipe modèle MiMo et l’équipe système TileRT
-
Contrairement aux approches de l’industrie qui s’appuient souvent sur du matériel spécialisé pour obtenir des vitesses comparables — comme le Wafer-Scale de Cerebras ou l’architecture custom à SRAM on-chip de Groq — cette performance a été obtenue sur des commodity GPU grâce au seul codesign modèle-système
-
Côté modèle, la quantification FP4 visant les goulets d’étranglement de bande passante réduit la taille du modèle et la charge des accès mémoire ; en parallèle, DFlash, fondé sur une prédiction parallèle masquée par blocs, augmente la longueur de tokens acceptés à chaque étape de vérification
-
Côté système, TileRT fournit un moteur de compilation et des kernels de calcul adaptés aux caractéristiques de cet algorithme, permettant une sortie de plus de 1 000 tps sur un nœud standard unique de 8 commodity GPU
-
3.1 Quantification FP4
- À l’échelle 1T, l’inférence classique en 8 bits (FP8/INT8) ou 16 bits impose une pression excessive sur la mémoire et la bande passante ; réduire la largeur en bits contribue donc directement à la vitesse de décodage
- Le format FP4 (MXFP4), considéré comme pratiquement sans perte et déjà validé, a été adopté, mais son application simple à l’ensemble du modèle entraîne une dégradation des performances sur les tâches complexes de raisonnement, de logique et de génération de code
- Dans une architecture MoE (Mixture of Experts), seuls les Experts qui représentent la majorité des paramètres et présentent la plus forte tolérance à la quantification ont été quantifiés sélectivement en FP4, tandis que les autres modules conservent leur précision d’origine
- Grâce au FP4 QAT (Quantization-Aware Training), la taille du modèle est réduite et l’utilisation de la bande passante matérielle est maximisée, tout en maintenant des performances globales pratiquement équivalentes à celles du modèle d’origine
-
3.2 DFlash Speculative Decoding
- Le speculative decoding traditionnel repose sur un petit modèle de draft qui anticipe les tokens suivants, ensuite vérifiés par un grand modèle ; la qualité du draft détermine le taux d’acceptation, mais plus le draft est performant, plus son coût de calcul augmente — une tension fondamentale
- DFlash remplit tout un bloc masqué en un seul forward pass du modèle de draft, supprimant ainsi la contrainte sérielle de l’« autoregressive drafting »
- En utilisant l’optimiseur de second ordre Muon et la self-distillation du modèle, l’overhead de l’étape de draft est comprimé à un niveau proche du minimum théorique
- Le modèle de draft utilise uniquement le Sliding Window Attention (SWA), ce qui s’aligne naturellement avec la conception SWA de la série MiMo-V2 et élimine complètement la dépendance au préfixe, réduisant le calcul par prédiction d’une complexité proportionnelle à la longueur du contexte à une constante
- Pendant l’entraînement, l’échantillonnage des signaux de masque est déplacé vers des shards locaux au GPU, ce qui permet à une seule séquence de générer des dizaines de milliers de signaux d’entraînement indépendants en une étape tout en évitant l’overhead de communication inter-device
- La taille des blocs est limitée à 8 afin de réduire l’overhead de vérification et d’augmenter la concurrence, une longueur d’acceptation élevée se traduisant directement par un débit d’inférence élevé
- Longueur moyenne d’acceptation (Acceptance Length) selon les scénarios
- Coding 6.30 (avec certains échantillons jusqu’à 7.14, soit 6 à 7 tokens acceptés sur 8 tokens draftés)
- Math / Reasoning 5.56
- Agent 4.29
- Dans les scénarios de conversation générale, sémantiquement plus dispersés et plus incertains, le taux d’acceptation reste encore relativement faible à ce stade, et l’optimisation se poursuit
-
3.3 Kernels / système d’inférence ultra-faible latence de TileRT
- À une fréquence de fonctionnement de 1 000 tokens/s, la durée de vie de chaque opérateur se comprime à l’échelle de la microseconde, et les « operator boundaries » des systèmes d’inférence traditionnels deviennent un goulot d’étranglement majeur
- Chaque démarrage d’exécution d’opérateur, synchronisation matérielle ou aller-retour vers la mémoire globale interrompt le flux d’exécution et crée des « Execution Gaps » visibles
-
Innovation de niveau paradigmatique dans le modèle d’exécution de TileRT
- Persistent Engine Kernel : abandon du lancement par opérateur ; l’ensemble du pipeline de calcul reste résident et actif en permanence à l’intérieur du GPU, ce qui permet un recouvrement extrême (overlap) des transferts de données et du calcul
- Warp Specialization (collaboration de pipelines hétérogènes) : au niveau du tile, la communication, les transferts de données et les opérations tensorielles sont décomposés plus finement sur le plan physique, rompant avec le modèle homogène en lock-step pour transformer le GPU en système d’exécution hétérogène finement orchestré
-
Fusion profonde matériel-logiciel à l’échelle de la microseconde (Codesign)
- La couche modèle adopte un mélange d’Experts MoE quantifiés en FP4 et un speculative decoding DFlash aligné sur SWA pour une architecture à 1 billion de paramètres ; TileRT fournit un moteur de compilation et des kernels de calcul sur mesure étroitement couplés à ces caractéristiques algorithmiques et à cette méthode de quantification
- Les deux équipes ont fait converger en douceur la pression d’exécution à l’intérieur des limites matérielles grâce à des compromis d’ingénierie communs fondés sur la physique du hardware
- TileRT est une équipe d’architecture système centrée sur l’infrastructure IA de nouvelle génération et l’inférence ultra-faible latence ; grâce à une percée full-stack autour des persistent kernels, du pipeline tile et de la collaboration hétérogène, elle atteint une utilisation extrême du calcul dans des environnements hétérogènes complexes
Démonstrations supplémentaires
- Démo créant un jeu Snake en 10 secondes
- Démo recréant une interface MacOS en 1 minute
Open source et perspectives
- Publication open source sur HuggingFace du checkpoint MiMo-V2.5-Pro-FP4-DFlash, incluant les poids quantifiés en FP4 et les paramètres du modèle DFlash
- Préparation en cours du support UltraSpeed pour MiMo-V2.5
1 commentaires
Avis sur Hacker News
L’IA rapide est vraiment fascinante, mais aussi assez inquiétante. Même aujourd’hui, Claude est plus rapide que moi sur certaines tâches, mais on reste encore dans un ordre de grandeur comparable
J’ai un prompt de synthèse de PR qui tourne depuis une heure et il semble qu’il en ait encore pour plusieurs heures ; s’il se terminait presque instantanément, il est difficile d’imaginer à quel point le workflow changerait. Il m’arrive aussi de commencer à faire du multitâche à cause d’un prompt trop long, puis de le regretter ensuite. À l’inverse, une IA capable de finir en quelques secondes ou quelques minutes un travail qui prenait des heures ou des jours, c’est un vrai changement de paradigme, et je ne sais pas encore où nous nous situerons là-dedans
Je n’ai pas encore testé les 3000 TPS de Cerebras, mais j’ai essayé une démo d’un modèle à 15 000 TPS dont j’ai oublié le nom. Je ne sais pas si cela fait une vraie différence dans le travail réel, mais voir du texte remplir tout l’écran en un clin d’œil est vraiment saisissant. C’est très utile pour de petites vérifications, comme afficher un diff et confirmer que les changements correspondent bien à l’intention, et pouvoir enchaîner rapidement ce type de vérification aide à faire beaucoup de contrôle concentré sans trop casser la concentration
Pour les tâches peu intensives en calcul, les interfaces conversationnelles fonctionnaient déjà comme ça à l’origine. Les programmes passent la plupart de leur temps à attendre que l’utilisateur clique sur un bouton. Nous n’avons pas besoin d’attendre les programmes ni de nous occuper en faisant tourner plusieurs assiettes à la fois. Cela dit, des LLM plus rapides ne suffisent pas ; il faut aussi une compilation et des tests rapides
Plus sérieusement, utiliser Cerebras à environ 2k tokens/s avec une latence très faible donne l’impression d’entrevoir l’avenir. On en vient à repenser son workflow autour de tâches qui peuvent se produire sans revue manuelle lourde, en explicitant par exemple les critères de réussite. Peu de mes problèmes s’y prêtent bien aujourd’hui, mais j’ai l’impression que c’est la direction que prendront les choses. Bien sûr, les modèles rapides ne sont généralement pas les meilleurs en performance brute, mais si on obtient une réflexion de haute qualité quasi instantanée, ce sera un game changer auquel nous ne sommes vraiment pas préparés
Mais sur d’autres tâches, il peut partir complètement dans la mauvaise direction. Avant, on pouvait intervenir en disant « attends, ce n’est pas ça », mais au moment où le texte apparaît à l’écran et où l’on réagit, il a déjà effectué des changements massifs. À moins de lui faire faire un commit à chaque modification, il est difficile d’empêcher qu’il se trompe aussi vite qu’il réussit, et avec beaucoup d’autorisations, il peut aussi faire des erreurs via des API distantes
J’ai du mal à comprendre les discours sur la productivité. Du point de vue d’un employé ordinaire, le fait qu’une tâche qui prenait 2 jours puisse désormais être faite en 2 heures n’a pas tant d’importance. On ne peut pas disposer librement du temps restant ; il faut toujours travailler 8 heures par jour
Avant, il y avait le plaisir de creuser un problème en profondeur pendant 2 jours ; maintenant, cela se transforme en un schéma où l’on tire sur la machine à sous en espérant obtenir la bonne réponse avec le bon prompt. Pour nous, j’ai plutôt l’impression que c’est pire. Évidemment, pour les entreprises et les dirigeants, c’est exactement l’inverse, et ils doivent adorer la situation actuelle autour de l’IA
Je ne le fais pas très souvent, mais c’est le prix à payer pour obtenir plus de vitesse. Si on jette une grosse tâche à l’IA et qu’on revient une heure plus tard, on peut découvrir qu’on a perdu une heure pour n’obtenir absolument rien
En ce moment, j’ai trois tâches en parallèle dans trois onglets, et devoir sans cesse changer de contexte est bien plus pénible. Avec des modèles plus rapides, il n’y aurait plus besoin de lancer une nouvelle tâche pendant qu’on attend
Rien n’empêche d’utiliser cette technologie pour creuser les problèmes plus profondément qu’avant. C’est ça, l’usage intelligent
L’optimisation prix/vitesse des fournisseurs chinois, combinée aux hausses de prix des acteurs américains, risque de rebattre les cartes très bientôt. Beaucoup d’entreprises ont déjà des problèmes avec leur facture IA
J’ai un abonnement annuel à GitHub Copilot, et Microsoft a récemment basculé la facturation sur les tokens. C’est encore facturé en requêtes premium, mais GPT 5.4 est passé de 1x auparavant à 6x maintenant
Je ne comprends vraiment pas quel fossé défensif possèdent les labos de modèles américains. S’ils disent que l’auto-amélioration récursive est imminente, mais que les labos chinois ne sont qu’un peu derrière les meilleurs modèles américains, alors où est le fossé défensif des labos américains ? Est-ce que les modèles américains seraient meilleurs que les modèles open source chinois en auto-amélioration récursive ? Je peux me tromper complètement, mais si j’avais investi dans OpenAI ou Anthropic, j’aurais envie de tout retirer maintenant. À mon avis, il y a une probabilité non négligeable que cela tende presque vers zéro dans les prochaines années
Du coup, on ne peut pas prévoir le coût du travail. Il faut parfois relancer plusieurs fois et payer à chaque tentative. En plus, il faut encore envoyer des prompts pour évaluer si le modèle est authentique ou non, ce qui augmente aussi la consommation de tokens
Si MiMo est aussi bon marché que Deepseek, alors, d’après la discussion précédente https://news.ycombinator.com/item?id=48282814, même en multipliant par 3 pour l’ultra-rapide, cela reste incroyablement peu cher
La version vitesse normale de MiMo V2.5 Pro reste le modèle de code agentique à poids ouverts le plus solide que nous ayons testé. Il est intéressant qu’il reçoive bien moins d’attention que des sorties moins performantes.
Le prix du “fast mode” y est aussi très compétitif. Les données sont ici : https://gertlabs.com/rankings
Ça peut ressembler à du battage promotionnel, mais il existe une croissance exponentielle. Nous allons atteindre un stade où nous produirons presque instantanément plusieurs logiciels à partir d’un prompt, puis choisirons le meilleur.
Les discussions pour savoir quelle bibliothèque a le meilleur nom de méthode avec sucre syntaxique paraîtront aussi étranges que proposer de tout saisir en assembleur
C’est la vraie vieille méthode, et si le produit est bon, il réussira
En pratique, grâce à l’IA, j’ai déjà effectué plusieurs refactorings qui auraient autrement semblé absurdes. Il y a une double friction : pas seulement la charge de travail, mais parfois même l’incertitude sur la réussite. Avec l’IA, on peut lancer un refactoring pendant qu’on prend un café et voir où ça bloque. Globalement, l’IA poussera l’humanité à se manifester elle-même de manière plus extrême. Dans le bon comme dans le mauvais sens. Mais je pense qu’il y aura davantage de mauvais côtés
Dans les petites entreprises, on sautera complètement l’étape du code, et l’UI sera directement rendue à vitesse conversationnelle à partir des données de contexte et des prompts. Un peu comme ce que fait Google Genie dans le jeu vidéo, mais de façon bien plus précise
Ce sera vraiment puissant pour la voix. Grâce aux capacités de raisonnement, les LLM deviennent bien plus intelligents, mais pour la voix, le budget de latence est généralement trop serré pour se permettre ce temps supplémentaire
Cerebras teste Kimi K2.6 à 3000t/s, sur invitation uniquement. J’ai hâte de voir du matériel rapide devenir plus courant pour les modèles de frontière.
Les modèles conçus chez Nvidia pour suivre la vitesse peuvent être un bon complément pour combler cet écart
La nouveauté ici, c’est qu’ils ont dépassé 1000 token/s sur un modèle de plus de 1 trillion de paramètres avec du matériel standard, à savoir un seul serveur de 8 GPU
Intéressant. Les modèles frontier sont devenus assez impressionnants, mais ils restent tous un peu lents pour le codage conversationnel avec humain dans la boucle. Cela pousse donc vers le vibe coding et l’exécution en parallèle de plusieurs agents. Un agent rapide donne davantage l’impression d’un partenaire
J’ai utilisé Cerebras GLM 4.7 pendant un moment pour diverses tâches. Ce n’est pas un modèle très intelligent, mais l’expérience de laisser tourner un prototype live du site et de taper « augmente un peu la police. Non, pas autant » pour voir le changement en temps réel est excellente. Et MiMo 2.5 est bien plus capable que GLM 4.7
GLM 5.1 est la dernière itération de z.ai et l’un des modèles de code open weights les plus populaires. Si vous l’avez essayé, je serais curieux de voir comment GLM 5.1, devenu plus cher que MiMo 2.5 Pro même après une baisse de prix récente de 70 %, se compare
1k TPS est impressionnant aussi, mais ce qui est encore plus intéressant, c’est combien de commentaires générés par IA il y a dans ce fil