Recherche

Présentation de Composer 2.5

8 min de lecture

Composer 2.5 est désormais disponible dans Cursor.

Il représente une amélioration majeure de l'intelligence et du comportement par rapport à Composer 2. Il gère mieux le travail soutenu sur des tâches de longue durée, suit plus fiablement des instructions complexes et est plus agréable à utiliser en collaboration.

Résultats des benchmarks de Composer 2.5Résultats des benchmarks de Composer 2.5

Nous avons amélioré Composer en augmentant l'échelle de l'entraînement, en générant des environnements de 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 comportementaux du modèle, comme le style de communication et le calibrage de l'effort. Ces dimensions sont mal prises en compte par les benchmarks existants, mais nous constatons qu'elles sont importantes dans l'usage réel.

Courbes d'effort de Composer 2.5Courbes d'effort de Composer 2.5

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

Entraînement de Composer 2.5Entraînement de Composer 2.5

Avec SpaceXAI, nous entraînons un modèle nettement plus grand à partir de zéro, en utilisant 10 fois plus de compute au total. 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.

Entraînement de Composer 2.5

Composer 2.5 apporte plusieurs améliorations à notre infrastructure d'entraînement. Ces améliorations portent à la fois sur l'intelligence du modèle et sur la facilité d'utilisation.

RL ciblé avec retours textuels

L’assignation 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. C’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 cela s’est mal passé.

Pour remédier à cela, nous avons entraîné Composer 2.5 avec des retours textuels ciblés.1 L’idée consiste à fournir un retour textuel directement au point 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 et 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 large 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, où le modèle tente d’appeler un outil qui n’est pas disponible. Pendant le rollout, le modèle recevra une erreur « Outil introuvable » et continuera à effectuer d’autres appels d’outil valides. Le fait d’avoir rencontré une erreur au cours de centaines d’appels d’outil aura un impact minimal 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, par exemple « Rappel : outils disponibles… », avec une liste des outils disponibles. Cet indice modifie les probabilités pour l’enseignant, en abaissant celles de l’outil incorrect et en augmentant celles d’un remplacement valide. Pour ce tour uniquement, nous mettons ensuite à jour les poids de l’élève vers ces nouvelles probabilités.

Pendant l’entraînement de Composer 2.5, nous avons appliqué cette méthode à différents comportements du modèle, du style de codage à la communication du modèle.

Feedback textuel de Composer 2.5Feedback textuel de Composer 2.5

Données synthétiques

Pendant l’entraînement RL, les capacités de codage de Composer s’améliorent considérablement, au point qu’il commence à résoudre correctement la plupart des problèmes d’entraînement. Pour continuer à accroître son intelligence, nous sélectionnons et générons dynamiquement des tâches plus difficiles tout au long de l’entraînement. Composer 2.5 est entraîné sur 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 vaste ensemble de tests, et doit supprimer du code et des fichiers de manière à ce que la base de code reste fonctionnelle tout en retirant des fonctionnalités spécifiques et testables. La tâche synthétique consiste ensuite à réimplémenter la fonctionnalité, et les tests servent 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 un récompense hacking inattendu. À mesure que le modèle 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 à retrouver puis à décompiler du bytecode Java pour reconstruire une API tierce. Nous avons pu repérer 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.

Données synthétiques de Composer 2.5Données synthétiques de Composer 2.5

Muon partitionné et double maillage HSDP

Pour le préentraînement continu, nous utilisons Muon avec une orthogonalisation distribuée. Après avoir calculé la mise à jour de 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 par lot les tenseurs de même forme, faisons un all-to-all des partitions pour reconstituer des matrices complètes, exécutons Newton-Schulz, puis renvoyons le résultat vers la disposition partitionnée d’origine avec un autre all-to-all. Ces transferts sont asynchrones : pendant qu’une tâche attend la communication, le runtime de l’optimiseur fait avancer d’autres tâches Muon, ce qui permet de chevaucher réseau et calcul. C’est équivalent à Muon sur matrice complète, mais cela maintient le groupe de partitions occupé ; sur le modèle 1T, le temps d’une étape d’optimisation est de 0,2 s.

Cela est étroitement lié à notre utilisation de HSDP pour les modèles MoE. HSDP crée plusieurs réplicas FSDP et effectue un all-reduce des gradients entre partitions correspondantes. Nous utilisons des dispositions HSDP distinctes pour les poids non experts et les poids des experts : les poids non experts sont relativement petits, donc leurs groupes FSDP peuvent rester compacts, souvent à l’intérieur d’un nœud ou d’un rack, tandis que les poids des experts concentrent la majorité des paramètres et l’essentiel du calcul Muon, et utilisent donc un maillage de partitionnement des experts 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 nécessiter 16 dans un maillage partagé unique. Cela évite une communication étendue pour le petit état non expert tout en répartissant le travail de l’optimiseur des experts sur de nombreux GPU.

Essayez Composer 2.5

Composer 2.5 est facturé 2.50/M tokens en sortie.

Il existe aussi une variante plus rapide avec le même niveau d’intelligence à 15.00/M tokens en sortie, à un coût inférieur à celui des options rapides des autres modèles de pointe. Comme pour Composer 2, l’option rapide est celle par défaut. Consultez notre documentation sur les modèles pour plus de détails.

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