Cursor ouvre MoK, un mégakernel qui accélère l’entraînement MoE

Cursor Research a mis en open source Mixture-of-Kittens, ou MoK, un mégakernel de formation pour modèles mixture-of-experts conçu pour les racks NVIDIA GB300 NVL72. Le projet vise un goulot d’étranglement très concret : la couche MoE, qui peut absorber plus de la moitié du temps d’entraînement selon Cursor. Résultat affiché, jusqu’à 2,37x de débit en MXFP8 face au meilleur point de comparaison public, et 1,41x de tokens par seconde en bout en bout sur 512 GPU. L’outil existe en Apache-2.0, mais il ne se pose pas sur n’importe quelle machine du coin.

Quand la communication devient le vrai problème

MoK, pour Mixture-of-Kittens, fusionne communication et calcul MoE dans un seul noyau déterministe. Autrement dit, au lieu de gérer séparément l’envoi des tokens, leur traitement par expert et leur retour, le système traite l’ensemble comme une seule opération GPU. Cursor dit avoir bâti ce choix après plusieurs tentatives sur les kernels MXFP8 et NVFP4, ainsi qu’un chemin de décodage interne pour l’inférence MoE, mais la communication inter-GPU restait le verrou principal.

Le changement de terrain avec les GB300 NVL72 a aussi compté. Un rack NVL72 regroupe 72 GPU dans un même domaine NVLink, ce qui permet un chevauchement fin entre calcul et communication. En face, les CPU Grace intégrés sont décrits comme trop lents par rapport aux GPU. Il fallait donc réduire au minimum les synchronisations CPU-GPU, sinon les GPU se retrouvaient à attendre. Une fâcheuse habitude pour du matériel censé aller vite.

Comment MoK tente de gratter des millisecondes partout

Le cœur technique de MoK repose sur trois décisions. D’abord, Cursor choisit le sens de communication selon l’opération : dispatch en pull pour l’aller, combine en push pour le retour, puis l’inverse en rétropropagation. Selon les microbenchmarks publiés, ce schéma supprime les signaux inter-GPU dans certaines étapes et réduit fortement la latence de synchronisation. Cursor compare notamment 103 µs pour un signal de dispatch en push contre 18 µs en pull, soit environ 5,8x [à vérifier si l’on compare exactement la même configuration].

Ensuite, le projet cherche un compromis sur la granularité du chevauchement. Trop fin, le tensor core n’est jamais pleinement alimenté ; trop large, les GPUs attendent trop longtemps les premiers tokens. MoK utilise donc des minibatchs ajustables, avec une heuristique qui vise au moins deux vagues complètes d’exécution par expert-grouped GEMM. Pour les formes de Kimi 2.5, Cursor situe le plancher à 2 368 tokens. C’est le genre de détail qui ne fait pas la une, mais qui fait souvent la facture de calcul.

Enfin, MoK remplace l’allocation CPU classique par un ring token buffer, ou macrobatch. Le principe consiste à faire tourner un tampon fixe de quelques centaines de mégaoctets, recyclé au fil des minibatchs. Cela évite de jeter des tokens et retire le CPU de la boucle d’allocation. Le backend devient plus prévisible, et la boucle GPU n’attend plus qu’un thread de service termine sa tournée.

Des gains mesurés, mais sur un terrain très spécialisé

Cursor a évalué MoK sur un seul rack NVL72 pour les benchmarks de couche MoE, avec EP degree 64 et 2 048 tokens par GPU avant routage. Les modèles pris comme référence incluent Kimi K2.7 Code, GLM-5.2, Qwen3.5-397B-A17B et DeepSeek-V4-Pro. Face au meilleur baseline public, MoK annonce jusqu’à 2,37x de débit en MXFP8 forward, 1,78x en MXFP8 backward, 1,92x en BF16 forward et 1,58x en BF16 backward.

Sur le stack de production interne de Cursor, les tests menés sur 512 GPU répartis sur plusieurs racks GB300 NVL72 montrent un passage de 760,9 à 1 070,2 tokens par seconde et par GPU, soit 1,41x. Le résultat reste cantonné à un périmètre précis : les organisations qui disposent déjà d’une capacité NVL72, ou qui peuvent la louer. Les équipes sur un seul nœud, ou avec huit GPU, n’y trouveront pas grand-chose d’exploitable. Là aussi, le matériel fait le tri sans beaucoup de délicatesse.

Un outil open source, mais pas grand public

MoK est publié sur GitHub sous licence Apache-2.0. Cursor indique que le code requiert des GPU NVIDIA Blackwell SM100 ou SM103, donc des racks GB200 NVL72 ou GB300 NVL72, ainsi que Python 3.12+, PyTorch 2.10+ et CUDA 13.0+. Les buffers inter-GPU s’appuient sur la mémoire symétrique de PyTorch. En clair, il s’agit moins d’un outil pour bidouilleurs du dimanche que d’une brique pour laboratoires frontaliers, startups très financées, néoclouds GPU ou centres de calcul nationaux.

Le cas d’usage visé est étroit mais stratégique : préentraînement et post-entraînement de modèles MoE de type DeepSeek-V3, RL on-policy, ablations internes et, plus largement, entraînement de grands modèles dans des infrastructures où chaque point de pourcentage de débit finit par compter. Dans ce contexte, l’ouverture du code compte autant que le gain brut. Cursor ne vend pas seulement un kernel plus rapide ; l’entreprise essaie surtout de déplacer un savoir-faire de production vers la communauté.

Liquid AI pousse l’inverse : l’agent local, sans le cloud

Au même moment, Liquid AI a présenté LFM2.5-2.6B, un modèle agentique de 2,6 milliards de paramètres pensé pour tourner entièrement sur l’appareil. Là encore, le choix technique répond à une contrainte d’usage : réduire la latence, préserver la confidentialité et supprimer le coût marginal par token. Le modèle est disponible sur Hugging Face en version base et post-entraînée, avec prise en charge annoncée de llama.cpp, MLX, vLLM, SGLang et ONNX.

La comparaison avec MoK est éclairante. D’un côté, Cursor optimise la chaîne lourde des grands clusters MoE. De l’autre, Liquid AI mise sur des agents qui tiennent dans un téléphone ou un CPU rapide. Les deux annonces racontent la même tendance de fond : l’IA se fragmente selon les contraintes d’infrastructure, entre l’extrême haut de gamme des data centers et les modèles locaux qui veulent tourner partout. Une seule vérité commune subsiste : le goulot d’étranglement n’est plus seulement le modèle, mais l’endroit où il tourne.