Stell dir vor, du leitest eine große Küche mit hunderten Spezialisten – jeder für ein bestimmtes Gericht zuständig. Die Bestellungen strömen rein, und du musst die Zutaten an die richtigen Köche verteilen, ihre Gerichte einsammeln und wieder zusammenführen. Genau das passiert in einem neuronalen Netz mit Mixture-of-Experts (MoE). Doch je größer die Küche, desto mehr Zeit geht für die Verteilung selbst drauf. Genau diesen Engpass hat das Team hinter Composer, dem agentischen Codier-Modell, erkannt und eine Lösung gefunden: den Open-Source-MoE-Megakernel Mixture-of-Kittens (MoK).
Bei MoE-Schichten werden die Eingaben (Tokens) von einer Router-Instanz auf eine Auswahl spezialisierter Experten-Netzwerke verteilt. Jeder Experte ist ein kleines Feedforward-Netz mit Up-, Gate- und Down-Projektion. Gerade bei Modellen wie DeepSeek-V3, die hunderte Experten nutzen, ist die Kommunikation zwischen den GPUs oft teurer als die eigentliche Berechnung. Cursor hat festgestellt, dass in ihren Produktions-Workloads bis zu 50% der Trainingszeit allein in der MoE-Schicht verbraucht wird – insbesondere wegen der Datenübertragung. Traditionelle Ansätze trennen Kommunikation und Rechnung, aber das führt zu Wartezeiten.
Die Lösung: ein einziger Kernel, der alle Kommunikations- und Rechenoperationen der MoE-Schicht verschmilzt. MoK ist vollständig deterministisch, d.h. die Reihenfolge der Operationen ist immer gleich, was für reproduzierbare Ergebnisse wichtig ist. Der Kernel wurde speziell für die NVL72-Architektur entwickelt, bei der 72 GPUs in einem Gehäuse über NVLink verbunden sind. Diese Umgebung ermöglicht eine fein granulare Überlappung von Kommunikation und Berechnung, die mit klassischen Multi-Node-Systemen nicht erreichbar wäre.
Das Kernproblem: Kommunikation als Flaschenhals
Bei verteiltem MoE werden die Experten auf verschiedene GPUs verteilt. Jeder GPU besitzt einen Teil der Experten. Wenn ein Token einem Experten auf einer anderen GPU zugeordnet wird, muss es zuerst dorthin geschickt werden – das nennt man Dispatch. Danach wird das Ergebnis zurückgeschickt – Combine. Die einfachste Methode ist, erst alle Tokens zu verschicken, dann die Berechnung durchzuführen und danach die Ergebnisse zurückzugeben. Das ist ineffizient, weil während der Übertragung die GPU-Pipeline leer läuft.
Eine bessere Methode ist das Pipelining: Man teilt die Tokens in Chunks auf, schickt den ersten Chunk, berechnet ihn, während der zweite Chunk übertragen wird, und so weiter. Das macht man seit Jahren. Doch Cursor hat erkannt, dass bei der NVL72-Architektur noch mehr möglich ist: Man kann die Kommunikation so gestalten, dass sie fast vollständig hinter der Rechenarbeit verschwindet. Dafür mussten sie zwei entscheidende Design-Fragen beantworten: In welche Richtung fließen die Daten am besten? Und wie synchronisiert man die GPUs, ohne die langsamen CPUs einzubinden?
Push oder Pull? Die richtige Kommunikationsrichtung
Bei der Datenübertragung zwischen GPUs gibt es zwei grundlegende Mechanismen: Push und Pull. Beim Push sendet die Quelle die Daten aktiv zum Ziel. Beim Pull fordert das Ziel die Daten von der Quelle an. Bisherige Frameworks wie DeepEP bevorzugen Push, weil es weniger Protokoll-Overhead gibt. Aber Cursor hat durch Mikrobenchmarks herausgefunden, dass Push nicht immer besser ist – es kommt auf die Situation an. Für den Dispatch, also das Verteilen der Tokens an die Experten, ist Pull effizienter, weil es das Scheduling vereinfacht und die NVLink-Lanes besser auslastet. Beim Combine, also dem Zurückschicken der Ergebnisse, ist Push vorteilhaft, da es die Token-Reihenfolge beibehält und weniger Bytes insgesamt bewegt.
Das Entscheidende ist, dass MoK für jede der vier Kommunikationsoperationen (Forward-Dispatch, Forward-Combine, Backward-Reverse-Dispatch, Backward-Reverse-Combine) die optimale Richtung wählt. Zudem: Der Scheduling-Plan, der für den Dispatch erstellt wird, kann auch für alle anderen Operationen wiederverwendet werden. Das spart Zeit und vermeidet Redundanz.
Das Scheduling: Ein Plan, der alle NVLink-Lanes sättigt
Um die gesamte NVLink-Bandbreite auszunutzen, muss man sicherstellen, dass alle 72 GPUs gleichzeitig Daten senden und empfangen. Dafür muss der Schedule so gestaltet sein, dass zu jedem Zeitpunkt jedes Quell-Ziel-Paar aktiv ist. Bei Push-basierten Systemen muss man eine komplexe Tabelle mit Quell- und Ziel-Indizes erstellen, die alle Bedingungen erfüllt: gleichmäßige Verteilung über alle Ziele, sortierte Ankunft bei den Experten, keine lokalen Kopien. Das erfordert aufwendige Sortierungen. Bei Pull-basiertem Dispatch ist der Schedule deutlich einfacher – man braucht nur eine Liste von Quell-GPU und -Index, und die Reihenfolge ergibt sich automatisch aus dem Routing. Cursor hat gezeigt, dass der Pull-basierte Dispatch weniger als 3% der Laufzeit benötigt und vollständig auf der GPU läuft, ohne CPU-Beteiligung.
Warum ist das so wichtig? Weil die CPUs in der NVL72, die Grace-Prozessoren, im Vergleich zu den GPUs sehr langsam sind. Wenn die GPU auf die CPU warten muss, um einen Schedule zu erstellen oder zu synchronisieren, entstehen untätige Zeiten. MoK minimiert CPU-Arbeit und CPU-GPU-Synchronisation, indem es alles auf der GPU erledigt. Ein cleverer Trick ist der Einsatz von Ring-Token-Puffern, die es erlauben, Tokens direkt in den Speicher der Ziel-GPU zu schreiben, ohne dass die CPU eingreifen muss.
Determinismus und MXFP8-Unterstützung
Ein weiterer wichtiger Aspekt ist der Determinismus. Viele KI-Trainingsprozesse sind nicht reproduzierbar, weil die Reihenfolge der Operationen variiert. MoK stellt sicher, dass die Reihenfolge der Kommunikation und Berechnung immer exakt gleich ist, unabhängig von der Anzahl der GPUs oder der Batch-Größe. Das erleichtert das Debugging und die Fehlersuche. Zudem unterstützt MoK MXFP8, ein 8-Bit-Float-Format, das die Speicher- und Rechenlast reduziert, ohne die Genauigkeit wesentlich zu beeinträchtigen. Diese Format-Unterstützung ist in den Kernel integriert, sodass kein separater Kernel für die Konvertierung nötig ist.
Die Vorteile zeigen sich in der Praxis: In mehreren Racks mit NVL72-Systemen steigerte MoK den End-to-End-Durchsatz um 41% (Faktor 1,41). Das bedeutet, dass bei gleicher Hardware und gleicher Energie deutlich mehr Trainingsdaten verarbeitet werden können. Für ein Unternehmen wie Cursor, das Composer mit hunderttausenden von GPUs trainiert, summiert sich das zu erheblichen Kosteneinsparungen und kürzeren Trainingszeiten.
Warum hat das Auswirkungen auf die gesamte KI-Community?
Die Open-Source-Veröffentlichung von MoK ist ein wichtiger Schritt, denn bisher waren solche Optimierungen oft proprietär. Andere Forschungslabore und Unternehmen können den Kernel nutzen, anpassen und verbessern. Das könnte die Entwicklung von effizienteren MoE-Modellen beschleunigen. Gerade bei den aktuellen Trends zu größeren Modellen und längeren Kontexten wird die MoE-Schicht immer mehr zum Flaschenhals. MoK zeigt, wie man durch eine durchdachte Neugestaltung der Kommunikation enorme Leistungsgewinne erzielen kann.
Natürlich ist MoK auf die NVL72-Architektur zugeschnitten, aber die Prinzipien – die Wahl zwischen Push und Pull, das Scheduling, die Überlappung von Kommunikation und Rechnung – lassen sich auf andere Systeme übertragen. Auch die Idee, die CPU aus dem kritischen Pfad zu nehmen, ist universell gültig. Der Kernel ist auf GitHub verfügbar, und das Team von Cursor lädt zur Zusammenarbeit ein.
Für dich als Entwickler oder KI-Enthusiast bedeutet das: Du kannst jetzt die internen Optimierungen eines kommerziellen Trainingssystems nachvollziehen und für deine eigenen Projekte nutzen. Mixture-of-Kittens ist mehr als nur ein netter Name – es ist ein Beispiel dafür, wie man ein vermeintlich gelöstes Problem (die MoE-Schicht) mit frischem Blick und neuen Hardware-Möglichkeiten noch einmal grundlegend verbessern kann. Die Küche kann also weiter wachsen, ohne an der Verteilung zu ersticken.
Quelle: cursor.com
