MiMo + TileRT de Xiaomi roule un modèle de 1 trillion de paramètres au-delà de 1000 tokens/sec sur un seul nœud commodity 8-GPU

Xiaomi a publié MiMo-V2.5-Pro-UltraSpeed le 8 juin, un modèle Mixture-of-Experts de 1 trillion de paramètres qui sert au-delà de 1000 tokens par seconde, près de 1200 en démo, sur un seul nœud commodity standard 8-GPU. Le headline c'est pas la taille du modèle ni le throughput pris seuls, c'est la conjonction : scale trillion-paramètres à des vitesses qui requéraient avant du silicon wafer-scale (Cerebras) ou des architectures custom SRAM-heavy (Groq), maintenant qui tourne sur le genre de box 8-GPU qu'un lab de taille moyenne ou une startup bien financée possède vraiment. Le checkpoint est open-sourcé sur Hugging Face comme MiMo-V2.5-Pro-FP4-DFlash, des modules TileRT sélectionnés sont sur GitHub, et un trial API limité roule du 9 au 23 juin à environ 3x le rate standard pour environ 10x la vitesse. La ligne de pricing est le tell honnête d'où ils pensent que la valeur sit : tu paies un premium pour la latence, pas pour l'intelligence.

La vitesse vient de trois techniques empilées, et l'intérêt d'engineering est dans comment elles composent plutôt que n'importe laquelle seule. Premièrement, quantization sélective plutôt qu'uniforme : MXFP4 (4-bit) est appliquée seulement aux MoE experts, qui tiennent la plupart des paramètres et tolèrent le mieux la quantization agressive, pendant que le reste du réseau reste à FP8. Quantization-aware training préserve la capability à travers le squeeze 4-bit au lieu de bolter la quantization après coup. Deuxièmement, DFlash speculative decoding opère au niveau block : au lieu de drafter un token à la fois, le draft model remplit un block entier (capé à 8 tokens) en un seul forward pass via masked parallel prediction, et les acceptance lengths reportées sont task-dependent, 6,30 pour le coding, 5,56 pour le math, 4,29 pour les workloads agentic, ce qui te dit que la méthode paie le plus là où les next several tokens sont les plus prévisibles. Troisièmement, TileRT est le runtime qui fait que le hardware delivre vraiment : un persistent engine kernel qui reste résident sur le GPU et utilise warp specialization pour coordonner compute, data movement et communication inter-GPU à latence microseconde, pour que les experts, les drafts spéculatifs et le trafic cross-GPU overlap au lieu de sérialiser. La quantization shrink les bytes bougés, la spéculation coupe le nombre de forward passes, et le persistent kernel enlève l'overhead de launch et scheduling qui mangerait autrement les gains. Chacune est connue en isolation. Le résultat c'est le co-design.

La lecture écosystème c'est que c'est un argument direct sur où le floor de coût d'inférence vit, visé au thèse du custom-silicon. Cerebras et Groq ont bâti leur case sur la prémisse que les GPUs commodity peuvent pas atteindre la latence et le throughput que le serving frontier-scale a besoin, donc tu as besoin de hardware custom, ce qui veut dire que tu as besoin de leur hardware, ce qui veut dire une relation hosted-API et pas de portabilité. MiMo + TileRT c'est Xiaomi qui dit que le nœud commodity 8-GPU peut atteindre ces numbers si tu co-designes le modèle, l'algorithme de decoding et le runtime kernel ensemble, et ils ont shipé des open weights et du code de runtime partiel pour rendre le claim checkable. Si le claim tient sous reproduction indépendante (le caveat standard, les numbers publiés sont ceux de Xiaomi et les conditions comme batch size et context length étaient pas pleinement spécifiées), la conséquence stratégique c'est que le moat que les vendors custom-silicon bâtissaient devient moins profond, parce que la chose qu'ils vendaient comme only-possible-on-our-hardware devient possible sur du hardware que tu as déjà. C'est la même pression open-substrate qu'on a vue avec Harness-1 en retrieval et Nemotron en speech, maintenant appliquée à la couche inference-serving elle-même.

Lundi matin, si tu serves de gros modèles et la latence est ta contrainte : MiMo-V2.5-Pro-FP4-DFlash plus les modules TileRT open valent une évaluation sérieuse, mais vérifie le throughput sur ton propre nœud avec tes propres settings de batch et context avant de croire le numéro de démo, parce que les conditions étaient pas pleinement publiées. Si tu paies Cerebras ou Groq spécifiquement pour de la vitesse qu'on t'a dit que les GPUs commodity peuvent pas atteindre : cette release est la raison de re-rouler ce calcul buy-versus-build ce quarter, le pricing de trial 3x-cost-pour-10x-speed est un point de référence utile pour ce que le premium de latence vaut vraiment. Si tu designes de l'infrastructure d'inférence : la leçon c'est que les gains viennent maintenant du co-design du modèle, du decoder et du kernel comme un seul système, pas de l'optimisation de n'importe quelle couche seule, et la combinaison MXFP4-sur-experts-seulement plus block-speculation plus persistent-kernel est le pattern concret à étudier. Et si tu tracks le thread open-versus-closed substrate, c'est la version de la couche inference de la même bataille : l'option open ferme le gap à l'option closed spécialisée assez vite pour que la question soit maintenant quand, pas si, le nœud commodity devient assez bon pour le serving frontier-scale.