Composer 2.5 ya está disponible en Cursor.

Supone una mejora sustancial en inteligencia y comportamiento con respecto a Composer 2. Rinde mejor en trabajo sostenido durante tareas de larga duración, sigue instrucciones complejas con mayor fiabilidad y hace que colaborar con él sea más agradable.

Mejoramos Composer aumentando la escala del entrenamiento, generando entornos de RL más complejos e introduciendo nuevos métodos de aprendizaje.

Además de entrenar Composer 2.5 con tareas más difíciles, mejoramos aspectos del comportamiento del modelo, como el estilo de comunicación y la calibración del esfuerzo. Estas dimensiones no quedan bien reflejadas en los benchmarks existentes, pero hemos comprobado que importan para su utilidad en el mundo real.

Composer 2.5 se basa en el mismo checkpoint de código abierto que Composer 2, Kimi K2.5 de Moonshot.

Junto con SpaceXAI, estamos entrenando desde cero un modelo significativamente más grande, usando 10 veces más capacidad de cómputo total. Con el millón de equivalentes H100 de Colossus 2 y nuestras técnicas combinadas de datos y entrenamiento, esperamos que esto suponga un gran salto en la capacidad del modelo.

#Entrenamiento de Composer 2.5

Composer 2.5 incorpora varias mejoras en nuestro stack de entrenamiento. Estos cambios apuntan tanto a la inteligencia del modelo como a la usabilidad.

#RL dirigido con retroalimentación textual

La asignación de crédito durante el RL se está convirtiendo en un desafío cada vez mayor, ya que los rollouts pueden abarcar cientos de miles de tokens. Cuando una recompensa se calcula sobre un rollout completo, al modelo puede resultarle difícil identificar qué decisión concreta ayudó o perjudicó el resultado. Esto resulta especialmente limitante cuando queremos desalentar un comportamiento localizado, como una llamada a herramienta errónea, una explicación confusa o una infracción de estilo. La recompensa final puede indicarnos que algo salió mal, pero es una señal ruidosa de dónde salió mal.

Para abordar esto, entrenamos Composer 2.5 con retroalimentación textual dirigida.¹ La idea es proporcionar retroalimentación directamente en el punto de la trayectoria en el que el modelo podría haber respondido mejor. Para un mensaje objetivo del modelo, construimos una pista breve que describe la mejora deseada, insertamos esa pista en el contexto local y usamos la distribución resultante del modelo como teacher. Usamos la policy con el contexto original como student y añadimos una pérdida KL de destilación on-policy que desplaza las probabilidades de tokens del student hacia las del teacher. Esto nos proporciona una señal de entrenamiento localizada para el comportamiento que queremos cambiar, sin perder el objetivo más amplio del RL sobre la trayectoria completa.

Como ilustración del proceso de retroalimentación textual, consideremos un rollout largo que incluye un error en una llamada a herramienta, donde el modelo intenta llamar a una herramienta que no está disponible. Durante el rollout, el modelo recibirá un error de “Tool not found” y seguirá realizando otras llamadas a herramientas válidas. El hecho de encontrarse con un error en medio de cientos de llamadas a herramientas tendrá un impacto mínimo en su recompensa final.

Con la retroalimentación textual, podemos centrarnos en este error concreto insertando una pista en el contexto del turno problemático, como “Reminder: Available tools…”, junto con una lista de herramientas disponibles. Esta pista cambia las probabilidades del teacher: reduce las de la herramienta incorrecta y aumenta las de una alternativa válida. Solo para ese turno, actualizamos los pesos del student hacia esas nuevas probabilidades.

Durante la ejecución de Composer 2.5, aplicamos este método a una variedad de comportamientos del modelo, desde el estilo de programación hasta la comunicación del modelo.

#Datos sintéticos

Durante el entrenamiento con RL, la capacidad de programación de Composer mejora sustancialmente, hasta el punto de empezar a resolver correctamente la mayoría de los problemas de entrenamiento. Para seguir aumentando su inteligencia, seleccionamos y creamos dinámicamente tareas más difíciles durante todo el proceso. Composer 2.5 se entrena con 25 veces más tareas sintéticas que Composer 2.

Usamos diversos enfoques para crear tareas sintéticas basadas en bases de código reales. Por ejemplo, uno de estos enfoques sintéticos es la eliminación de funcionalidades. En estas tareas, se proporciona al agente una base de código con un gran conjunto de pruebas y se le pide que elimine código y archivos de forma que la base de código siga siendo funcional mientras se eliminan funcionalidades específicas comprobables. La tarea sintética consiste en reimplementar la funcionalidad, y las pruebas se usan como una recompensa verificable.

Una consecuencia de la creación de tareas sintéticas a gran escala es que puede provocar reward hacking inesperado. A medida que el modelo se volvía más hábil, Composer 2.5 fue capaz de encontrar soluciones alternativas cada vez más sofisticadas para resolver la tarea en cuestión. En un caso, el modelo encontró una caché residual de comprobación de tipos de Python e hizo ingeniería inversa del formato para encontrar la firma de una función eliminada. En otro, fue capaz de encontrar y descompilar bytecode de Java para reconstruir una API de terceros. Pudimos encontrar y diagnosticar estos problemas usando herramientas de monitorización con agentes, pero demuestran el cuidado cada vez mayor que requiere el RL a gran escala.

#Muon fragmentado y malla dual HSDP

Para el preentrenamiento continuo, usamos Muon con ortogonalización distribuida. Después de formar la actualización de momentum, ejecutamos Newton-Schulz con la granularidad natural del modelo: por cabeza de atención para las proyecciones de atención y por experto para los pesos apilados de MoE.

El principal costo está en ortogonalizar los pesos de los expertos. Para los parámetros fragmentados, agrupamos tensores con la misma forma, hacemos all-to-all de los fragmentos para reconstruir matrices completas, ejecutamos Newton-Schulz y luego hacemos all-to-all del resultado de vuelta al diseño fragmentado original. Estas transferencias son asíncronas: mientras una tarea espera la comunicación, la ejecución del optimizador avanza otras tareas de Muon, solapando red y cómputo. Esto equivale a Muon sobre matrices completas, pero mantiene ocupado al grupo de fragmentos; en el modelo 1T, el tiempo del paso del optimizador es de 0,2 s.

Esto está muy ligado a cómo usamos HSDP para los modelos MoE. HSDP forma múltiples réplicas de FSDP y aplica all-reduce a los gradientes entre los fragmentos correspondientes. Usamos diseños de HSDP separados para los pesos de expertos y los de no expertos: los pesos de no expertos son comparativamente pequeños, por lo que sus grupos de FSDP pueden seguir siendo reducidos, a menudo dentro de un nodo o rack, mientras que los pesos de expertos concentran la mayoría de los parámetros y la mayor parte del cómputo de Muon, por lo que usan una malla de fragmentación de expertos más amplia.

Mantener estos diseños separados también permite solapar dimensiones de paralelismo independientes: CP=2 y EP=8 pueden ejecutarse en 8 GPU en lugar de requerir 16 en una única malla compartida. Esto evita una comunicación amplia para el pequeño estado de no expertos, al tiempo que distribuye el trabajo del optimizador de expertos entre muchas GPU.

#Prueba Composer 2.5

Composer 2.5 cuesta $0.50/Mdetokensdeentraday$2.50/M de tokens de resultado.

También hay una variante más rápida con la misma inteligencia por $3.00/Mdetokensdeentraday$15.00/M de tokens de resultado, con un costo inferior al de los niveles rápidos de otros modelos de vanguardia. Al igual que en Composer 2, fast es la opción predeterminada. Consulta nuestra documentación sobre modelos para ver todos los detalles.

Composer 2.5 incluye el doble de uso durante la primera semana.