O Composer 2.5 agora está disponível no Cursor.

É uma melhoria substancial em inteligência e comportamento em relação ao Composer 2. Ele lida melhor com trabalho contínuo em tarefas de longa duração, segue instruções complexas com mais confiabilidade e é mais agradável para colaborar.

Melhoramos o Composer aumentando a escala do treinamento, gerando ambientes de RL mais complexos e introduzindo novos métodos de aprendizado.

Além de treinar o Composer 2.5 em tarefas mais difíceis, melhoramos aspectos comportamentais do modelo, como o estilo de comunicação e a calibração de esforço. Essas dimensões não são bem capturadas pelos benchmarks existentes, mas vimos que elas fazem diferença na utilidade prática.

O Composer 2.5 é baseado no mesmo checkpoint de código aberto do Composer 2, Kimi K2.5 da Moonshot.

Junto com a SpaceXAI, estamos treinando do zero um modelo significativamente maior, usando 10x mais capacidade computacional total. Com 1 milhão de H100-equivalentes do Colossus 2 e nossos dados e técnicas de treinamento combinados, esperamos que isso represente um grande salto na capacidade do modelo.

#Treinamento do Composer 2.5

O Composer 2.5 traz várias melhorias para a nossa infraestrutura de treinamento. Essas alterações visam melhorar tanto a inteligência do modelo quanto a usabilidade.

#RL direcionado com feedback textual

A atribuição de crédito durante o RL está se tornando um desafio cada vez maior, já que os rollouts podem abranger centenas de milhares de tokens. Quando uma recompensa é calculada com base em um rollout inteiro, pode ser difícil para o modelo identificar qual decisão específica ajudou ou prejudicou o resultado. Isso é especialmente limitante quando queremos desencorajar um comportamento localizado, como uma chamada de ferramenta incorreta, uma explicação confusa ou uma violação de estilo. A recompensa final pode nos dizer que algo deu errado, mas é um sinal ruidoso de onde isso deu errado.

Para lidar com isso, treinamos o Composer 2.5 com feedback textual direcionado.¹ A ideia é fornecer feedback diretamente no ponto da trajetória em que o modelo poderia ter se saído melhor. Para uma mensagem-alvo do modelo, construímos uma dica curta descrevendo a melhoria desejada, inserimos essa dica no contexto local e usamos a distribuição resultante do modelo como professor. Usamos a policy com o contexto original como aluno e adicionamos uma perda KL de destilação on-policy que move as probabilidades de token do aluno na direção das do professor. Isso nos dá um sinal de treinamento localizado para o comportamento que queremos alterar, ao mesmo tempo em que preserva o objetivo mais amplo do RL ao longo de toda a trajetória.

Como ilustração do processo de feedback textual, considere um rollout longo que inclui um erro de chamada de ferramenta, em que o modelo tenta chamar uma ferramenta que não está disponível. Durante o rollout, o modelo receberá um erro “Tool not found” e continuará fazendo outras chamadas de ferramenta válidas. O fato de ele ter cometido um erro no meio de centenas de chamadas de ferramenta terá impacto mínimo em sua recompensa final.

Com feedback textual, podemos atacar esse erro específico inserindo uma dica no contexto do turno problemático, como “Lembrete: Ferramentas disponíveis...” com uma lista das ferramentas disponíveis. Essa dica altera as probabilidades para o professor, reduzindo as da ferramenta incorreta e aumentando as de uma substituição válida. Só nesse turno, então, atualizamos os pesos do aluno na direção das novas probabilidades.

Durante a execução do Composer 2.5, aplicamos esse método a uma variedade de comportamentos do modelo, do estilo de código à comunicação do modelo.

#Dados sintéticos

Durante o treinamento com RL, a capacidade de programação do Composer melhora substancialmente, a ponto de começar a acertar a maioria dos problemas de treinamento. Para continuar aumentando sua inteligência, selecionamos e também criamos tarefas mais difíceis dinamicamente ao longo do processo. O Composer 2.5 é treinado com 25x mais tarefas sintéticas do que o Composer 2.

Usamos uma variedade de abordagens para criar tarefas sintéticas baseadas em bases de código reais. Por exemplo, uma dessas abordagens é a remoção de recursos. Nessas tarefas, o agente recebe uma base de código com um grande conjunto de testes e é instruído a excluir código e arquivos de forma que a base de código continue funcional, enquanto recursos específicos e testáveis são removidos. A tarefa sintética é reimplementar o recurso, e os testes são usados como uma recompensa verificável.

Uma consequência indireta da criação de tarefas sintéticas em larga escala é que ela pode causar reward hacking inesperado. À medida que o modelo foi ficando mais capaz, o Composer 2.5 conseguiu encontrar soluções alternativas cada vez mais sofisticadas para resolver a tarefa em questão. Em um exemplo, o modelo encontrou um cache residual de verificação de tipos em Python e fez engenharia reversa do formato para descobrir a assinatura de uma função excluída. Em outro, ele conseguiu encontrar e descompilar bytecode Java para reconstruir uma API de terceiros. Conseguimos identificar e diagnosticar esses problemas usando ferramentas agênticas de monitoramento, mas eles demonstram o cuidado cada vez maior necessário em RL em larga escala.

#Muon particionado e HSDP com malha dupla

Para o pré-treinamento contínuo, usamos Muon com ortogonalização distribuída. Depois de formar a atualização de momentum, executamos Newton-Schulz na granularidade natural do modelo: por cabeça de atenção para as projeções de atenção e por expert para os pesos empilhados de MoE.

O principal custo está em ortogonalizar os pesos dos experts. Para parâmetros particionados, agrupamos em lote tensores com o mesmo formato, fazemos all-to-all dos shards para formar matrizes completas, executamos Newton-Schulz e depois fazemos all-to-all do resultado de volta ao layout particionado original. Essas transferências são assíncronas: enquanto uma tarefa aguarda comunicação, o tempo de execução do otimizador avança outras tarefas do Muon, sobrepondo rede e computação. Isso é equivalente ao Muon de matriz completa, mas mantém o grupo de shards ocupado; no modelo 1T, o tempo da etapa do otimizador é de 0,2 s.

Isso interage diretamente com a forma como usamos HSDP para modelos MoE. O HSDP forma várias réplicas de FSDP e faz all-reduce dos gradientes entre shards correspondentes. Usamos layouts de HSDP separados para pesos de experts e não experts: os pesos não expert são relativamente pequenos, então seus grupos de FSDP podem permanecer estreitos, muitas vezes dentro de um nó ou rack, enquanto os pesos dos experts concentram a maior parte dos parâmetros e da computação do Muon, então usam uma malha de particionamento de experts mais ampla.

Manter esses layouts separados também permite sobrepor dimensões de paralelismo independentes: CP=2 e EP=8 podem ser executados em 8 GPUs, em vez de exigir 16 em uma única malha compartilhada. Isso evita comunicação ampla para o pequeno estado não expert, ao mesmo tempo que distribui o trabalho do otimizador dos experts por muitas GPUs.

#Experimente o Composer 2.5

O Composer 2.5 custa $0.50/Memtokensdeentradae$2.50/M em tokens de saída.

Também há uma variante mais rápida com a mesma inteligência por $3.00/Memtokensdeentradae$15.00/M em tokens de saída, com custo mais baixo do que as versões rápidas de outros modelos de ponta. Assim como no Composer 2, a opção rápida é o padrão. Consulte nossa documentação de modelos para todos os detalhes.

O Composer 2.5 inclui uso em dobro na primeira semana.