Composer 2.5 ya está disponible en Cursor.

Supone una mejora sustancial en inteligencia y comportamiento frente a Composer 2. Rinde mejor de forma sostenida en tareas de larga duración, sigue instrucciones complejas con más fiabilidad y es más agradable trabajar con él.

Mejoramos Composer escalando el 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 son importantes para su utilidad práctica.

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 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.

#Prueba Composer 2.5

Composer 2.5 tiene un precio de $0.50/Mtokensdeentraday$2.50/M tokens de resultado.

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

Composer 2.5 duplica el uso durante la primera semana.

#Entrenamiento de Composer 2.5

Composer 2.5 incorpora varias mejoras nuevas en nuestra infraestructura de entrenamiento. Estos cambios apuntan tanto a la inteligencia del modelo como a la facilidad de uso.

#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 se calcula una recompensa 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 haberse comportado 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 profesor. Usamos la política con el contexto original como estudiante y añadimos una pérdida KL de destilación on-policy que desplaza las probabilidades de tokens del estudiante hacia las del profesor. Esto nos da una señal de entrenamiento localizada para el comportamiento que queremos cambiar, sin dejar de conservar el objetivo más amplio del RL sobre la trayectoria completa.

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

Con retroalimentación textual, podemos apuntar a este error concreto insertando una pista en el contexto del turno problemático, como “Recordatorio: herramientas disponibles...”, junto con una lista de herramientas disponibles. Esta pista cambia las probabilidades del profesor: reduce las de la herramienta incorrecta y aumenta las de un reemplazo válido. Solo para ese turno, luego actualizamos los pesos del estudiante hacia estas nuevas probabilidades.

Durante la ejecución de Composer 2.5, aplicamos este método a diversos comportamientos del modelo, desde el estilo de codificació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 a lo largo de la ejecución. 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 es la eliminación de funcionalidades. En estas tareas, al agente se le proporciona una base de código con un amplio 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 verificables mediante pruebas. La tarea sintética consiste en volver a implementar 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 comportamientos inesperados de manipulación de la recompensa. 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 descubrir 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 detectar y diagnosticar estos problemas usando herramientas de monitorización con agentes, pero demuestran el nivel de cuidado cada vez mayor que requiere el RL a gran escala.

#Muon fragmentado y HSDP de doble malla

Para el preentrenamiento continuo, usamos Muon con ortogonalización distribuida. Tras formar la actualización del momento, 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 un all-to-all de los shards para reconstruir matrices completas, ejecutamos Newton-Schulz y luego hacemos otro all-to-all para devolver el resultado al diseño fragmentado original. Estas transferencias son asíncronas: mientras una tarea espera la comunicación, el runtime del optimizador avanza otras tareas de Muon, solapando red y cómputo. Esto equivale a Muon con matriz completa, pero mantiene ocupado el grupo de shards; en el modelo de 1T, el tiempo de cada paso del optimizador es de 0,2 s.

Esto está muy relacionado con cómo usamos HSDP para los modelos MoE. HSDP crea varias réplicas de FSDP y hace all-reduce de los gradientes entre shards correspondientes. Usamos diseños de HSDP separados para los pesos de expertos y no expertos: los pesos no expertos son relativamente 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 gran 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 estados pequeños no expertos y, al mismo tiempo, distribuye el trabajo del optimizador de expertos entre muchas GPU.