Composer 2.5 ist jetzt in Cursor verfügbar.

Gegenüber Composer 2 bietet es einen deutlichen Fortschritt bei Intelligenz und Verhalten. Es ist besser bei der ausdauernden Arbeit an lang laufenden Aufgaben, befolgt komplexe Anweisungen zuverlässiger und arbeitet sich angenehmer damit zusammen.

Wir haben Composer verbessert, indem wir das Training skaliert, komplexere RL-Umgebungen geschaffen und neue Lernmethoden eingeführt haben.

Neben dem Training von Composer 2.5 auf schwierigeren Aufgaben haben wir auch verhaltensbezogene Aspekte des Modells wie den Kommunikationsstil und die Kalibrierung des Aufwands verbessert. Diese Dimensionen werden von bestehenden Benchmarks nicht gut erfasst, aus unserer Sicht sind sie aber entscheidend für den praktischen Nutzen.

Composer 2.5 basiert auf demselben Open-Source-Checkpoint wie Composer 2, Moonshot's Kimi K2.5.

Gemeinsam mit SpaceXAI trainieren wir von Grund auf ein deutlich größeres Modell und nutzen dabei die 10-Fache gesamte Rechenleistung. Mit den eine Million H100-Äquivalenten von Colossus 2 sowie unseren kombinierten Daten- und Trainingstechniken erwarten wir einen großen Sprung bei den Modellfähigkeiten.

#Composer 2.5 ausprobieren

Composer 2.5 kostet $0.50/MEingabe-Tokenund$2.50/M Ausgabe-Token.

Außerdem gibt es eine schnellere Variante mit derselben Intelligenz für $3.00/MEingabe-Tokenund$15.00/M Ausgabe-Token, die günstiger ist als die schnellen Tarifstufen anderer führender Modelle. Wie schon bei Composer 2 ist Fast die Standardoption. Alle Details finden Sie in unserer Modelldokumentation.

In der ersten Woche ist die doppelte Nutzung von Composer 2.5 enthalten.

#Training von Composer 2.5

Composer 2.5 enthält mehrere neue Verbesserungen für unseren Trainings-Stack. Diese Änderungen zielen sowohl auf die Intelligenz des Modells als auch auf seine Nutzbarkeit ab.

#Gezieltes RL mit textbasiertem Feedback

Die Zuordnung von Ursachen und Wirkungen während des RL wird immer schwieriger, da Rollouts Hunderttausende von Token umfassen können. Wenn eine Belohnung über einen gesamten Rollout hinweg berechnet wird, kann es für das Modell schwer sein zu erkennen, welche konkrete Entscheidung dem Ergebnis geholfen oder geschadet hat. Das ist besonders einschränkend, wenn wir ein lokal begrenztes Verhalten unterbinden wollen, etwa einen fehlerhaften Tool-Aufruf, eine verwirrende Erklärung oder einen Verstoß gegen Stilvorgaben. Die endgültige Belohnung kann uns zwar sagen, dass etwas schiefgelaufen ist, aber sie ist ein verrauschtes Signal dafür, wo es schiefgelaufen ist.

Um das zu lösen, haben wir Composer 2.5 mit gezieltem textbasiertem Feedback trainiert.¹ Die Idee ist, Feedback direkt an der Stelle in der Trajektorie zu geben, an der sich das Modell besser hätte verhalten können. Für eine Zielnachricht des Modells erzeugen wir einen kurzen Hinweis, der die gewünschte Verbesserung beschreibt, fügen diesen Hinweis in den lokalen Kontext ein und nutzen die daraus resultierende Modell-Verteilung als Teacher. Die Policy mit dem ursprünglichen Kontext dient dabei als Student, und wir fügen einen On-Policy-Distillation-KL-Loss hinzu, der die Token-Wahrscheinlichkeiten des Student in Richtung derer des Teacher verschiebt. So erhalten wir ein lokales Trainingssignal für das Verhalten, das wir ändern möchten, und behalten gleichzeitig das übergeordnete RL-Ziel über die gesamte Trajektorie hinweg bei.

Zur Veranschaulichung des Prozesses mit textbasiertem Feedback betrachten wir einen langen Rollout, der einen Tool-Aufruf-Fehler enthält, bei dem das Modell versucht, ein Tool aufzurufen, das nicht verfügbar ist. Während des Rollouts erhält das Modell den Fehler „Tool nicht gefunden“ und führt anschließend weitere gültige Tool-Aufrufe aus. Dass dabei im Verlauf von Hunderten von Tool-Aufrufen ein einzelner Fehler auftritt, hat nur minimale Auswirkungen auf die endgültige Belohnung.

Mit textbasiertem Feedback können wir genau diesen Fehler gezielt adressieren, indem wir im Kontext des problematischen Turns einen Hinweis einfügen, zum Beispiel „Erinnerung: Verfügbare Tools…“ zusammen mit einer Liste verfügbarer Tools. Dieser Hinweis verändert die Wahrscheinlichkeiten für den Teacher, senkt die für das falsche Tool und erhöht die für eine gültige Alternative. Nur für diesen Turn aktualisieren wir dann die Gewichte des Student in Richtung der neuen Wahrscheinlichkeiten.

Während des Composer-2.5-Laufs haben wir diese Methode auf eine Vielzahl von Modellverhalten angewendet, von Coding-Stil bis hin zur Modellkommunikation.

#Synthetische Daten

Während des RL-Trainings verbessert sich Composers Programmierfähigkeit deutlich, bis es die meisten Trainingsaufgaben korrekt löst. Um die Intelligenz weiter zu steigern, wählen wir während des gesamten Ausführens dynamisch schwierigere Aufgaben aus und erzeugen sie. Composer 2.5 wird mit 25-mal mehr synthetischen Aufgaben trainiert als Composer 2.

Wir nutzen verschiedene Ansätze, um synthetische Aufgaben zu erstellen, die auf realen Codebasen basieren. Ein Beispiel für einen solchen synthetischen Ansatz ist das Entfernen von Features. Für diese Aufgaben erhält der Agent eine Codebase mit einer großen Anzahl von Tests und soll Code und Dateien so löschen, dass die Codebase funktionsfähig bleibt, während bestimmte testbare Features entfernt werden. Die synthetische Aufgabe besteht dann darin, das Feature neu zu implementieren; die Tests dienen dabei als verifizierbare Belohnung.

Eine Folge der groß angelegten Erstellung synthetischer Aufgaben ist, dass sie zu unerwartetem Reward Hacking führen kann. Je leistungsfähiger das Modell wurde, desto ausgefeiltere Workarounds fand Composer 2.5, um die jeweilige Aufgabe zu lösen. In einem Fall fand das Modell einen verbliebenen Python-Cache für die Typprüfung und entschlüsselte dessen Format, um die Signatur einer gelöschten Funktion zu rekonstruieren. In einem anderen Fall konnte es Java-Bytecode finden und dekompilieren, um eine Drittanbieter-API zu rekonstruieren. Wir konnten diese Probleme mit agentenbasierten Monitoring-Tools erkennen und diagnostizieren, aber sie zeigen, wie viel mehr Sorgfalt bei RL im großen Maßstab nötig ist.

#Sharded Muon and dual mesh HSDP

Für das fortlaufende Pretraining nutzen wir Muon mit verteilter Orthogonalisierung. Nach der Bildung des Momentum-Updates führen wir Newton-Schulz in der natürlichen Granularität des Modells aus: pro Attention-Head für Attention-Projektionen und pro Expert für gestapelte MoE-Gewichte.

Der Hauptaufwand entsteht bei der Orthogonalisierung der Expert-Gewichte. Bei geshardeten Parametern bündeln wir Tensoren mit gleicher Form, setzen die Shards per All-to-all zu vollständigen Matrizen zusammen, führen Newton-Schulz aus und verteilen das Ergebnis anschließend per All-to-all zurück in das ursprüngliche Sharding-Layout. Diese Transfers sind asynchron: Während eine Aufgabe auf Kommunikation wartet, arbeitet die Optimizer-Laufzeit andere Muon-Aufgaben weiter ab, sodass Netzwerk und Rechenleistung überlappen. Das entspricht Full-Matrix-Muon, hält aber die Shard-Gruppe ausgelastet; beim 1T-Modell beträgt die Zeit pro Optimizer-Schritt 0,2 s.

Das hängt eng damit zusammen, wie wir HSDP für MoE-Modelle nutzen. HSDP bildet mehrere FSDP-Replikate und all-reduziert Gradienten über entsprechende Shards hinweg. Wir nutzen separate HSDP-Layouts für Nicht-Expert- und Expert-Gewichte: Nicht-Expert-Gewichte sind vergleichsweise klein, daher können ihre FSDP-Gruppen schmal bleiben, oft innerhalb eines Knotens oder Racks, während Expert-Gewichte den Großteil der Parameter und der Muon-Rechenleistung ausmachen und deshalb ein breiteres Expert-Sharding-Mesh nutzen.

Getrennte Layouts erlauben außerdem, dass sich unabhängige Parallelismus-Dimensionen überlappen: CP=2 und EP=8 können auf 8 GPUs laufen, statt in einem einzelnen gemeinsamen Mesh 16 zu erfordern. So vermeiden wir breite Kommunikation für kleine Nicht-Expert-Zustände und verteilen zugleich die Optimizer-Arbeit für Experts auf viele GPUs.