Composer 2.5 ist jetzt in Cursor verfügbar.

Gegenüber Composer 2 ist es ein deutlicher Fortschritt bei Intelligenz und Verhalten. Es arbeitet ausdauernder an lang laufenden Aufgaben, befolgt komplexe Anweisungen zuverlässiger und macht die Zusammenarbeit angenehmer.

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

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

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

Gemeinsam mit SpaceXAI trainieren wir ein deutlich größeres Modell von Grund auf neu und setzen dabei insgesamt 10-mal mehr Compute ein. Mit den H100-Äquivalenten im Millionenbereich von Colossus 2 sowie unseren kombinierten Daten- und Trainingstechniken erwarten wir einen großen Sprung bei der Modellleistung.

#Training für Composer 2.5

Composer 2.5 enthält mehrere Verbesserungen an unserem Trainings-Stack. Diese Änderungen verbessern sowohl die Modellleistung als auch die Benutzerfreundlichkeit.

#Gezieltes RL mit textbasiertem Feedback

Die Zuordnung von Credit während des RL wird zunehmend schwieriger, da Rollouts sich über Hunderttausende von Token erstrecken können. Wenn ein Reward über einen gesamten Rollout berechnet wird, kann das Modell nur schwer erkennen, welche konkrete Entscheidung zum Ergebnis beigetragen oder ihm geschadet hat. Das ist besonders einschränkend, wenn wir ein lokales Verhalten unterbinden wollen, etwa einen fehlerhaften Tool-Aufruf, eine verwirrende Erklärung oder einen Verstoß gegen Stilvorgaben. Der finale Reward kann uns zwar sagen, dass etwas schiefgelaufen ist, aber er ist ein verrauschtes Signal dafür, wo es schiefgelaufen ist.

Um dieses Problem anzugehen, haben wir Composer 2.5 mit gezieltem textbasiertem Feedback trainiert.¹ Die Idee ist, Feedback direkt an der Stelle in der Trajektorie bereitzustellen, an der sich das Modell besser hätte verhalten können. Für eine Zielnachricht des Modells erstellen wir einen kurzen Hinweis, der die gewünschte Verbesserung beschreibt, fügen diesen Hinweis in den lokalen Kontext ein und nutzen die daraus resultierende Modellverteilung 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 Students in Richtung derer des Teachers verschiebt. So erhalten wir ein lokales Trainingssignal für das Verhalten, das wir ändern wollen, 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 Fehler bei einem Tool-Aufruf enthält, bei dem das Modell versucht, ein nicht verfügbares Tool aufzurufen. Während des Rollouts erhält das Modell einen „Tool not found“-Fehler und führt anschließend weitere gültige Tool-Aufrufe aus. Dass im Verlauf von Hunderten von Tool-Aufrufen ein einzelner Fehler aufgetreten ist, wirkt sich nur minimal auf den finalen Reward aus.

Mit textbasiertem Feedback können wir diesen konkreten Fehler gezielt adressieren, indem wir im Kontext des problematischen Turns einen Hinweis einfügen, etwa „Reminder: Available 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 einen Turn aktualisieren wir dann die Gewichte des Students 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 Fähigkeit zu coden erheblich, bis zu dem Punkt, an dem es die meisten Trainingsaufgaben korrekt löst. Um die Intelligenz weiter zu steigern, wählen wir während des gesamten Trainingslaufs dynamisch schwierigere Aufgaben aus und erzeugen sie. Composer 2.5 wird mit 25-mal mehr synthetischen Aufgaben trainiert als Composer 2.

Wir nutzen eine Reihe von Ansätzen, 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 Codebasis mit einer großen Anzahl von Tests und wird aufgefordert, Code und Dateien so zu löschen, dass die Codebasis funktionsfähig bleibt, während bestimmte testbare Features entfernt werden. Die synthetische Aufgabe besteht dann darin, das Feature neu zu implementieren, wobei die Tests als verifizierbarer Reward dienen.

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

#Sharded Muon und Dual-Mesh-HSDP

Für das fortlaufende Pretraining nutzen wir Muon mit verteilter Orthogonalisierung. Nach dem Bilden des Momentum-Updates führen wir Newton-Schulz auf 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 derselben Form, setzen die Shards per All-to-All zu vollständigen Matrizen zusammen, führen Newton-Schulz aus und übertragen das Ergebnis dann per All-to-All zurück in das ursprüngliche geshardete Layout. Diese Transfers sind asynchron: Während eine Aufgabe auf Kommunikation wartet, arbeitet die Optimizer-Runtime andere Muon-Aufgaben ab, sodass sich Netzwerk und Compute überlappen. Das entspricht Muon auf vollständigen Matrizen, hält aber die Shard-Gruppe beschäftigt; 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 reduziert Gradienten per All-Reduce über die jeweils entsprechenden Shards. Wir nutzen getrennte 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 den größten Teil des Muon-Compute ausmachen und deshalb ein breiteres Expert-Sharding-Mesh nutzen.

Die getrennten Layouts ermöglichen außerdem, dass sich unabhängige Parallelitätsdimensionen überlappen: CP=2 und EP=8 können auf 8 GPUs laufen, statt in einem einzelnen gemeinsamen Mesh 16 zu benötigen. So vermeiden wir breite Kommunikation für kleinen Nicht-Expert-Zustand und verteilen zugleich die Optimizer-Arbeit für Experts auf viele GPUs.

#Composer 2.5 ausprobieren

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

Es gibt auch eine schnellere Variante mit derselben Intelligenz für $3.00/MEingabe-und$15.00/M Ausgabe-Token – günstiger als die schnellen Tarifstufen anderer führender Modelle. Ähnlich wie bei Composer 2 ist fast die Standardoption. Vollständige Details finden Sie in unserer Modelldokumentation.

Bei Composer 2.5 ist in der ersten Woche die doppelte Nutzung enthalten.