Cursor's MoK réalise une amélioration des performances de 2,37x sur NVIDIA GB300 NVL72

Cursor open-source MoK intègre le调度 des jetons, la communication inter-GPU et le calcul des experts au sein d'un même noyau GPU. Cette solution permet d'atteindre une amélioration des performances de jusqu'à 2,37 fois pour la propagation avant et 1,78 fois pour la rétropropagation en MXFP8 sur GB300 NVL72, avec une augmentation de 41 % du débit d'entraînement sur 512 GPU GB300, atteignant 1070,2 tokens/s. La latence de signalisation est réduite de 103 μs à 18 μs. L'analyse indique qu'aujourd'hui, où la bande passante NVLink atteint déjà 130 TB/s, le temps d'accès aux données sur le GPU devient le nouveau goulot d'étranglement de performance. Cette avancée marque l'entrée dans la phase « souveraineté complète de la pile », où les entreprises dont le code est le plus proche de la mémoire vidéo et des registres détiennent un pouvoir de tarification plus important.

Auteur et source de l'article : Leifengwang

Le 21 juillet, NVIDIA a publié les derniers résultats de l'entraînement de DeepSeek-V3 avec le GB300 NVL72 : sur 256 GPU, la performance par carte atteint 1 648 TFLOPS.

Moins de deux semaines plus tard, Cursor a open-sourcé Mixture-of-Kittens, abrégé MoK. Au lieu de continuer à optimiser les multiplications matricielles plus rapides, il a réécrit entièrement l’implémentation d’une couche MoE, en intégrant le调度 des tokens, la communication inter-GPU et le calcul des experts dans un seul noyau GPU.

Cela semble un peu contre-intuitif. Puisque le GB300 NVL72 a déjà intégré 72 GPU au sein d’un même domaine NVLink, la bande passante totale NVLink de l’ensemble du rack atteint 130 To/s. Selon cette spécification, le transfert de données entre les GPU devrait déjà être suffisamment rapide.

Dans l'entraînement à grande échelle des MoE, la communication reste un goulot d'étranglement pour le calcul des experts.

Le problème vient du flux de données du MoE. À chaque étape, le routeur décide à nouveau vers quel expert envoyer chaque token, et les experts sont répartis sur différents GPU. Les tokens doivent d’abord être transférés entre cartes, calculés, puis renvoyés ; avant l’envoi, il faut organiser les positions, et après arrivée, il faut attendre que les données soient complètes. Alors que MXFP8 et les Blackwell Tensor Core réduisent de plus en plus le temps de calcul des experts, ces attentes, qui étaient auparavant masquées par le calcul, deviennent de plus en plus visibles.

Cursor fait du MoK en agissant à partir de cet endroit. Il ne se concentre pas uniquement sur la vitesse de transmission d'un seul dispatch, mais réorganise la manière dont les tokens atteignent les experts, quand le calcul commence, et comment la communication et le calcul partagent simultanément le GPU.

Aujourd'hui, où les ressources de calcul sont poussées à leur limite par Blackwell et NVLink, les développeurs constatent : même le matériel le plus rapide ne peut sauver une orchestration logicielle inefficace.

L'open source de MoK n'est pas seulement une victoire pour le noyau ; il marque le début de l'ère où « l'application définit les opérateurs » : pour extraire les 30 % derniers de puissance de calcul, les startups d'IA lancent une guerre pour reprendre la souveraineté fondamentale.

Cependant, pour comprendre pourquoi ce design de Cursor est efficace, il faut d'abord identifier où le MoE paie son « impôt de communication ».

01

La « taxe de communication » de MoE

Dans un FFN dense classique, les poids parcourus par les tokens sont essentiellement fixes. Après l'ajout du Router dans le MoE, chaque token sélectionne temporairement plusieurs experts. Lors de l'utilisation de l'Expert Parallel, les experts sont répartis sur de nombreux GPU, ce qui entraîne au moins deux cycles de communication inter-GPU lors d'une propagation avant.

La première étape s'appelle Dispatch : elle envoie le token vers le GPU où se trouve l'expert ; une fois le calcul effectué, Combine renvoie le résultat à l'emplacement d'origine du token. L'entraînement inclut également la rétropropagation, qui implique deux étapes supplémentaires de communication dans le sens inverse.

Si vous déplacez simplement un grand bloc de données continues de A à B, NVLink est déjà suffisamment rapide. La complexité du MoE réside dans le fait que la distribution des données fournie par le Router varie à chaque étape.

Un expert peut recevoir beaucoup de tokens à cette étape, puis très peu à l'étape suivante. Le système doit d'abord compter le nombre de tokens de chaque expert, puis déterminer où placer ces tokens sur le GPU cible, tout en regroupant autant que possible les données du même expert. Seule une GEMM groupée permet d'obtenir des entrées structurées et d'alimenter efficacement les Tensor Cores.

Après la fin de la communication, le calcul ne peut pas commencer immédiatement. Le GPU cible doit confirmer que toutes les écritures distantes ont été terminées et que les données sont effectivement visibles. Les charges des experts ne sont pas entièrement uniformes ; certaines GPU peuvent terminer plus tôt, mais elles doivent quand même attendre que l'expert le plus chargé termine.

Ainsi, dans une phase de « communication », plusieurs actions sont mélangées : transfert de données, génération de disposition, synchronisation et déséquilibre de charge. Les 130 To/s décrivent la bande passante maximale que peut fournir l’ensemble du rack, mais ne signifient pas que chaque communication dynamique et fragmentée de MoE peut saturer simultanément tous ces liens.

DeepEP a optimisé le transfert de données avec une grande efficacité. C'est une bibliothèque de communication haute performance conçue pour Expert Parallel, offrant des noyaux dédiés de Dispatch et Combine, prenant en charge FP8 et permettant de contrôler le nombre de SM utilisés pour la communication. La dernière version permet même de maintenir un débit de communication élevé avec un nombre de SM nettement réduit.

Un seul couche MoE doit encore constamment transmettre entre Dispatch, Grouped GEMM et Combine.

On rencontre alors une contradiction pratique : attendre qu’un nombre suffisant de tokens soient réunis pour effectuer le calcul permet d’obtenir une matrice volumineuse, ce qui permet aux Tensor Cores de fonctionner efficacement, mais retarde le démarrage du calcul ; en revanche, traiter les tokens dès leur arrivée permet de mieux superposer communication et calcul, mais la matrice devient trop petite, laissant de nombreux SM GPU sans suffisamment de travail.

Plusieurs flux CUDA permettent de rendre la communication et le calcul concurrents, mais il est difficile de garantir en permanence que les deux côtés obtiennent les ressources GPU idéales.

La conception derrière MoK traite essentiellement cette question de « rythme ».

02

L'une des modifications les plus intéressantes de MoK consiste à passer le dispatch avant de Push à Pull.

Le Push traditionnel est intuitif : lorsque le GPU source possède un token, il l'écrit activement dans le GPU cible. Le problème survient avec l'adresse cible. Un GPU reçoit simultanément de nombreux tokens provenant d'autres GPUs.

Chaque expéditeur doit savoir à l'avance dans quelle section il doit écrire, sans se chevaucher ; les jetons du même expert devraient également être disposés de manière continue, sinon la GEMM suivante devra être réorganisée.

Au fur et à mesure que le nombre de GPU impliqués augmente, ce processus d'ordonnancement devient de plus en plus lourd. Pull a adopté une nouvelle approche : enregistrer la GPU cible des experts, qui récupère elle-même les tokens nécessaires. Elle n'a besoin que de connaître sur quelle GPU source se trouvent les tokens et à quel emplacement dans les données sources ; l'endroit où ils sont stockés localement est déterminé par elle-même.

Cela élimine la nécessité de coordonner plusieurs expéditeurs vers l'adresse cible. Les données reçues peuvent également être directement organisées selon les experts locaux.

Il est intéressant de noter que Pull n'envoie pas moins de données. Dans les micro-benchmarks du curseur, pour le même bloc de données BF16 de 256×256, Push déplace environ 159,6 Ko sur NVLink, tandis que Pull atteint 172,0 Ko, car la lecture nécessite l'envoi supplémentaire de requêtes.

La force de Pull réside dans un autre aspect : la communication MoE est fragmentée et la charge est déséquilibrée. Les deux directions de NVLink possèdent des canaux indépendants, permettant à Pull d'utiliser simultanément les deux directions pour les requêtes et le retour des données. Dans les tests avec une charge déséquilibrée parmi les experts, Cursor a observé une augmentation jusqu'à 29 % de l'utilisation de NVLink.

L'écart de synchronisation est plus marqué. Après l'écriture Push, le GPU cible doit attendre le signal de terminaison des autres GPU ; lorsqu'on utilise Expert Parallel avec une grande échelle, un rang peut impliquer jusqu'à 71 pairs. Pull est initié localement par le GPU, et les données peuvent être utilisées directement dès leur réception.

Dans les micro-benchmarks à nœuds multiples de Cursor, cette latence de signalisation est passée de environ 103 microsecondes avec Push à 18 microsecondes avec Pull.

MoK n'utilise pas non plus Pull partout. En avant, on utilise Pull Dispatch et Push Combine ; en arrière, on utilise Pull Reverse-Combine et Push Reverse-Dispatch. Pendant la phase Dispatch, il faut réorganiser de nombreux tokens sources en entrées pour les experts ; Pull nécessite moins de coordination. Lors de la Combine, il est clair de savoir à quel token chaque résultat doit revenir ; il est donc plus simple de le pousser directement avec Push.

Après avoir modifié la direction de la communication, MoK a toujours intégré la communication et le calcul expert dans un seul Megakernel.

Il divise les SM du GPU en deux parties. Une partie gère le dispatch, le combine et la gestion d'état, tandis que l'autre est dédiée à l'exécution des Expert FFN. Une fois qu'une série complète de tokens est récupérée par la partie communication, elle notifie la partie calcul via un compteur local GPU ; une fois le calcul terminé, elle notifie à nouveau la partie communication pour transmettre les résultats.

Cela permet de déterminer directement combien de SM utiliser pour la communication et combien pour le calcul, sans laisser entièrement la décision à plusieurs flux CUDA en concurrence. Le paramètre le plus crucial ici est le minibatch, c’est-à-dire le nombre de tokens traités à la fois par les experts.

Il ne peut pas être trop grand. Un trop grand nombre signifie que les premiers calculs prendront beaucoup de temps à s'effectuer. Il ne peut pas non plus être trop petit. Les GEMM d'experts doivent finalement être divisés en un grand nombre de tâches de calcul réparties sur les SM ; si le nombre de tokens est trop faible, il n'y aura pas assez de tâches, et de nombreux SM resteront inactifs.

Cursor utilise une onde pour déterminer cette limite. Une onde complète peut être comprise simplement comme le fait que tous les SM ont reçu du travail. MoK souhaite qu'un minibatch forme au moins deux ondes complètes, afin que les Tensor Core disposent de suffisamment de tâches pour s'exécuter en continu.

Les résultats réels parlent d'eux-mêmes. Sur une architecture Kimi 2.5 avec une taille cachée de 7168 et une dimension intermédiaire d'expert de 2048, Cursor estime qu'un minibatch nécessite au moins environ 2368 tokens. À 512 tokens, le temps d'inférence avant de MoK est de 5,981 ms ; il diminue à 3,425 ms lorsque le nombre de tokens augmente à 2560. Au-delà, l'accélération n'est plus significative.

Autrement dit, fragmenter la communication ne rend pas toujours plus rapide. Une superposition véritablement efficace nécessite de transmettre les données le plus tôt possible, tout en ne coupant pas GEMM trop finement.

Mais le MoE présente un autre problème : avant que le routeur n'ait terminé, on ne sait pas exactement combien de tokens chaque GPU recevra finalement.

Préparer un buffer selon le pire scénario gaspillerait beaucoup de mémoire vidéo. Si on laisse d'abord le GPU compter les tokens, puis qu'on notifie le CPU pour allouer l'espace correspondant, le GPU devrait s'arrêter et attendre le CPU.

MoK utilise un tampon de jetons Ring de taille fixe. Un espace est d'abord rempli avec les jetons envoyés par Dispatch ; une fois que les experts ont terminé le calcul et que Combine a transmis les résultats, cet espace est immédiatement réutilisé pour la prochaine série de jetons. Le Combine du macro-batch précédent peut se dérouler simultanément avec le Dispatch du macro-batch suivant.

Le Ring Buffer agit ici comme une couche tampon : lorsque la communication est plus rapide, les données s'accumulent à l'intérieur ; lorsque le calcul consomme plus vite, il attend le prochain lot de tokens. L'ensemble du processus est piloté par l'état sur le GPU, sans nécessiter que le CPU intervienne à chaque itération pour décider de la prochaine étape.

Cursor a également intégré la quantification de l'activation MXFP8 dans les chemins de données de Dispatch, Grouped GEMM et SwiGLU, éliminant ainsi le kernel de quantification indépendant ainsi qu'une lecture/écriture intermédiaire supplémentaire dans la HBM.

Une fois que Pull, minibatch, SM partition et Ring Buffer sont combinés, MoK devient véritablement une chaîne de traitement MoE continue.

03

Le benchmark de Cursor évalue la couche MoE complète, incluant le planificateur, le routage, les FFN experts, la combinaison et la fusion pondérée finale, avec pour comparaisons NCCL + PyTorch, DeepEP, TransformerEngine et HybridEP + Megatron.

Sur GB300 NVL72, MoK atteint une amélioration maximale de 2,37 fois pour la passe avant et de 1,78 fois pour la passe arrière par rapport aux meilleures lignes de base publiques pour chaque scénario ; pour BF16, les améliorations maximales sont respectivement de 1,92 fois pour la passe avant et de 1,58 fois pour la passe arrière.

Plus important, l'entraînement end-to-end. La solution de production originale de Cursor utilisait déjà DeepEP. En passant à MoK sur 512 GPU GB300, le débit par carte est passé de 760,9 tokens par seconde à 1070,2, soit une amélioration d'environ 41 %.

Il faut également bien comprendre les limites de ces résultats. Cursor n’ayant pas publié d’ablation détaillée complète, il est impossible de déterminer avec précision quelle partie des 2,37 fois provient de Pull, quelle partie de Megakernel et quelle partie de Ring Buffer.

Il est possible de confirmer séparément l'amélioration de l'utilisation de NVLink et de la latence de signalisation par Pull ; les autres gains proviennent principalement de la combinaison de l'ensemble des méthodes d'exécution.

MoK dépend également fortement du matériel. Il est conçu pour des domaines NVLink rapides tels que Blackwell et NVL72. Les lectures distantes, la communication et l'interleaving fin de calcul sont tous basés sur la capacité des GPU à accéder à la mémoire vidéo des autres avec une faible latence. Lorsque la taille cachée du modèle, le Top-k ou la taille des experts changent, la taille appropriée du minibatch et le nombre de SM de communication changent également.

C’est aussi le point le plus intéressant de MoK. Dans le passé, lorsqu’on discutait de l’optimisation MoE, on se concentrait facilement sur deux chiffres : combien de TFLOPS pour les GEMM, et combien de GB/s pour l’All-to-All. Avec la génération GB300, il n’est plus possible d’expliquer toute la performance en poussant simplement ces deux chiffres plus haut.

Quand le token arrive, comment le disposer selon la disposition requise par les experts, à partir de combien on commence à calculer, combien de SM sont pris pour la communication, quand le buffer est libéré — ces détails d'exécution déterminent directement la vitesse d'entraînement.

Un rack avec une bande passante NVLink de 130 To/s nécessite toujours une réécriture des noyaux GPU pour MoE, car les liens sont déjà rapides ; il s'agit désormais de gagner du temps sur le GPU et l'attente des données.

Le comportement de réécriture des noyaux GPU par Cursor marque l'entrée dans une nouvelle phase de concurrence de l'IA 2.0 : la « souveraineté full-stack ».

Autrefois, nous croyions fermement à la spécialisation : faire des applications, c’était faire des applications (Cursor) ; faire de la couche sous-jacente, c’était faire de la couche sous-jacente (NVIDIA). Mais la concurrence actuelle dans l’IA est entrée dans une nouvelle phase de « déintermédiation » : Cursor ne développe pas son noyau parce qu’il « veut » le faire, mais parce qu’il « doit » le faire.

DeepSeek a ouvert une nouvelle ère de l'extraction technique, tandis que Cursor a étendu ce feu jusqu'au niveau des applications. Cette tendance vers la « déintermédiation » est en train de redéfinir le pouvoir de tarification de l'IA : à l'avenir, la valorisation des entreprises d'IA ne sera plus déterminée par le nombre de tokens qu'elles possèdent, mais par la proximité de leur code avec la mémoire vidéo et les registres.

Les entreprises d'IA incapables de percer le black box sous-jacent resteront coincées dans le marécage de la « taxe de la médiocrité ».