Composer 2.5 est désormais disponible dans Cursor.

Il s’agit d’une amélioration substantielle de l’intelligence et du comportement par rapport à Composer 2. Il est plus performant dans le travail soutenu sur des tâches de longue durée, suit des instructions complexes de manière plus fiable, et est plus agréable à utiliser en collaboration.

Nous avons amélioré Composer en augmentant l’ampleur de l’entraînement, en générant des environnements RL plus complexes et en introduisant de nouvelles méthodes d’apprentissage.

En plus d’entraîner Composer 2.5 sur des tâches plus difficiles, nous avons amélioré certains aspects du comportement du modèle, comme le style de communication et le calibrage de l’effort. Ces dimensions sont mal reflétées par les benchmarks existants, mais nous constatons qu’elles sont importantes dans un usage réel.

Composer 2.5 repose sur le même checkpoint open source que Composer 2, Kimi K2.5 de Moonshot.

Avec SpaceXAI, nous entraînons depuis zéro un modèle nettement plus grand, en utilisant 10x plus de puissance de calcul totale. Avec le million d’équivalents H100 de Colossus 2 ainsi que nos données et techniques d’entraînement combinées, nous nous attendons à une avancée majeure des capacités du modèle.

#Essayez Composer 2.5

Composer 2.5 est facturé 0,50 $/Mdetokensd’entr\acute{e}eet2,50$/M de tokens de sortie.

Il existe également une variante plus rapide avec le même niveau d’intelligence à 3,00 $/Mdetokensd’entr\acute{e}eet15,00$/M de tokens de sortie, soit un coût inférieur à celui des paliers rapides des autres modèles de pointe. Comme pour Composer 2, l’option rapide est sélectionnée par défaut. Voir notre documentation sur les modèles pour tous les détails.

Composer 2.5 offre une utilisation doublée pendant la première semaine.

#Entraînement de Composer 2.5

Composer 2.5 apporte plusieurs améliorations à notre pipeline d’entraînement. Ces changements visent à la fois l’intelligence du modèle et sa facilité d’utilisation.

#RL ciblé avec retour textuel

L’attribution du crédit pendant le RL devient un défi de plus en plus complexe, car les rollouts peuvent s’étendre sur des centaines de milliers de tokens. Lorsqu’une récompense est calculée sur l’ensemble d’un rollout, il peut être difficile pour le modèle de déterminer quelle décision précise a aidé ou nui au résultat. Cela est particulièrement limitant lorsque nous voulons décourager un comportement localisé, comme un mauvais appel d’outil, une explication confuse ou un écart de style. La récompense finale peut nous indiquer que quelque chose s’est mal passé, mais c’est un signal bruité pour savoir où cela s’est produit.

Pour y remédier, nous avons entraîné Composer 2.5 avec un retour textuel ciblé.¹ L’idée consiste à fournir un retour directement à l’étape de la trajectoire où le modèle aurait pu mieux se comporter. Pour un message cible du modèle, nous construisons un court indice décrivant l’amélioration souhaitée, nous insérons cet indice dans le contexte local, puis nous utilisons la distribution du modèle qui en résulte comme enseignant. Nous utilisons la policy avec le contexte d’origine comme élève et ajoutons une perte KL de distillation on-policy qui rapproche les probabilités de token de l’élève de celles de l’enseignant. Cela nous donne un signal d’entraînement localisé pour le comportement que nous voulons changer, tout en conservant l’objectif RL plus global sur l’ensemble de la trajectoire.

Pour illustrer le processus de retour textuel, considérons un long rollout qui inclut une erreur d’appel d’outil dans laquelle le modèle tente d’appeler un outil qui n’est pas disponible. Pendant le rollout, le modèle recevra une erreur « Tool not found » et continuera à effectuer d’autres appels d’outil valides. Le fait qu’il rencontre une erreur parmi des centaines d’appels d’outil n’aura qu’un impact minime sur sa récompense finale.

Avec le retour textuel, nous pouvons cibler cette erreur précise en insérant un indice dans le contexte du tour problématique, tel que « Rappel : outils disponibles… », suivi d’une liste des outils disponibles. Cet indice modifie les probabilités pour l’enseignant, en réduisant celles associées au mauvais outil et en augmentant celles d’un remplacement valide. Pour ce tour uniquement, nous mettons ensuite à jour les poids de l’élève pour les rapprocher de ces nouvelles probabilités.

Pendant l’entraînement de Composer 2.5, nous avons appliqué cette méthode à divers comportements du modèle, du style de codage à la manière dont le modèle communique.

#Données synthétiques

Pendant l’entraînement par RL, les capacités de codage de Composer s’améliorent considérablement, au point qu’il finit par résoudre correctement la plupart des problèmes d’entraînement. Pour continuer à accroître son intelligence, nous sélectionnons et créons dynamiquement des tâches plus difficiles tout au long de l’entraînement. Composer 2.5 est entraîné avec 25 fois plus de tâches synthétiques que Composer 2.

Nous utilisons un éventail d’approches pour créer des tâches synthétiques ancrées dans des bases de code réelles. Par exemple, l’une de ces approches consiste à supprimer des fonctionnalités. Pour ces tâches, l’agent reçoit une base de code accompagnée d’un grand ensemble de tests, et doit supprimer du code et des fichiers de façon à ce que la base de code reste fonctionnelle tout en retirant certaines fonctionnalités testables. La tâche synthétique consiste ensuite à réimplémenter la fonctionnalité, les tests servant de récompense vérifiable.

L’une des conséquences de la création de tâches synthétiques à grande échelle est qu’elle peut entraîner des formes inattendues de détournement de la récompense. À mesure qu’il gagnait en compétence, Composer 2.5 a trouvé des contournements de plus en plus sophistiqués pour résoudre la tâche en cours. Dans un cas, le modèle a trouvé un cache résiduel de vérification de types Python et en a rétroconçu le format pour retrouver la signature d’une fonction supprimée. Dans un autre, il a réussi à trouver puis à décompiler du bytecode Java pour reconstruire une API tierce. Nous avons pu identifier et diagnostiquer ces problèmes à l’aide d’outils de surveillance agentique, mais ils montrent à quel point une vigilance accrue est nécessaire pour le RL à grande échelle.

#Muon partitionné et HSDP à double maillage

Pour le préentraînement continu, nous utilisons Muon avec une orthogonalisation distribuée. Après avoir formé la mise à jour du momentum, nous exécutons Newton-Schulz à la granularité naturelle du modèle : par tête d’attention pour les projections d’attention, et par expert pour les poids MoE empilés.

Le principal coût vient de l’orthogonalisation des poids des experts. Pour les paramètres partitionnés, nous regroupons les tenseurs de même forme, effectuons un all-to-all des partitions pour reconstituer des matrices complètes, exécutons Newton-Schulz, puis réexpédions le résultat par all-to-all vers la disposition partitionnée d’origine. Ces transferts sont asynchrones : pendant qu’une tâche attend la communication, le runtime de l’optimiseur fait avancer d’autres tâches Muon, en chevauchant réseau et puissance de calcul. Cela équivaut à Muon sur matrice complète, tout en gardant le groupe de partitions occupé ; sur le modèle 1T, le temps d’une étape d’optimisation est de 0,2 s.

Cela interagit étroitement avec notre utilisation de HSDP pour les modèles MoE. HSDP forme plusieurs répliques FSDP et effectue un all-reduce des gradients entre les partitions correspondantes. Nous utilisons des dispositions HSDP distinctes pour les poids experts et non experts : les poids non experts sont relativement petits, donc leurs groupes FSDP peuvent rester restreints, souvent au sein d’un nœud ou d’un rack, tandis que les poids experts concentrent la majeure partie des paramètres et de la puissance de calcul Muon, et utilisent donc un maillage de partitionnement expert plus large.

Le fait de garder ces dispositions séparées permet aussi de faire se chevaucher des dimensions de parallélisme indépendantes : CP=2 et EP=8 peuvent s’exécuter sur 8 GPU au lieu d’en exiger 16 dans un maillage partagé unique. Cela évite des communications étendues pour le petit état non expert, tout en répartissant le travail d’optimisation des experts sur de nombreux GPU.