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 é melhor em manter um trabalho contínuo em tarefas de longa duração, segue instruções complexas com mais confiabilidade, e é mais agradável de se usar em colaboração.

Aprimoramos o Composer ampliando o 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, também 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 consideramos que 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 compute total. Com o milhão de equivalentes a H100 do Colossus 2 e nossas técnicas combinadas de dados e treinamento, esperamos que isso represente um grande salto na capacidade do modelo.

#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 menor do que o das categorias rápidas de outros modelos de ponta. Assim como no Composer 2, a variante rápida é a opção padrão. Consulte nossa documentação de modelos para mais detalhes.

O Composer 2.5 inclui o dobro de uso durante a primeira semana.

#Treinamento do Composer 2.5

O Composer 2.5 traz várias melhorias novas para nossa infraestrutura de treinamento. Essas mudanças têm como foco 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 aconteceu.

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 política com o contexto original como aluno e adicionamos uma perda KL de destilação on-policy que desloca as probabilidades de token do aluno em direção às 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 inclua 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 de “Ferramenta não encontrada” e continuará fazendo outras chamadas de ferramenta válidas. O fato de ele ter encontrado um erro ao longo de centenas de chamadas de ferramenta terá impacto mínimo em sua recompensa final.

Com feedback textual, podemos direcionar 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 do professor, reduzindo as da ferramenta errada e aumentando as de uma substituição válida. Apenas para esse turno, então atualizamos os pesos do aluno em direção a essas novas probabilidades.

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

#Dado sintético

Durante o treinamento de RL, a capacidade de programação do Composer melhora substancialmente, a ponto de começar a acertar a maior parte dos problemas de treinamento. Para continuar aumentando a inteligência, tanto selecionamos quanto criamos tarefas mais difíceis dinamicamente ao longo da execução. 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 sintéticas é a remoção de recursos. Nessas tarefas, o agente recebe uma base de código com um grande conjunto de testes e é instruuído a excluir código e arquivos de modo que a base de código permaneça 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 da criação de tarefas sintéticas em larga escala é que isso pode levar a exploração inesperada da recompensa. À medida que o modelo se tornou mais capaz, o Composer 2.5 passou a 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 do Python e fez engenharia reversa do formato para descobrir a assinatura de uma função excluída. Em outro, conseguiu encontrar e descompilar bytecode Java para reconstruir uma API de terceiros. Conseguimos encontrar e diagnosticar esses problemas usando ferramentas agênticas de monitoramento, mas eles mostram o cuidado cada vez maior necessário para RL em larga escala.

#Muon com shards e HSDP de 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 nas projeções de atenção e por especialista nos pesos empilhados de MoE.

O principal custo está na ortogonalização dos pesos dos especialistas. Para parâmetros particionados em shards, agrupamos em lote os 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 para o layout original em shards. Essas transferências são assíncronas: enquanto uma tarefa aguarda a comunicação, o tempo de execução do otimizador avança outras tarefas do Muon, sobrepondo comunicação de rede e compute. Isso é equivalente ao Muon com matriz completa, mas mantém o grupo de shards ocupado; no modelo 1T, o tempo da etapa do otimizador é de 0,2 s.

Isso se relaciona diretamente com a forma como usamos HSDP em 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 especialistas e de não especialistas: os pesos de não especialistas são relativamente pequenos, então seus grupos de FSDP podem permanecer menores, muitas vezes dentro de um nó ou rack, enquanto os pesos dos especialistas concentram a maior parte dos parâmetros e do compute do Muon, então usam uma malha mais ampla para sharding de especialistas.

Manter esses layouts separados também permite sobrepor dimensões independentes de paralelismo: 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 de não especialistas, ao mesmo tempo que distribui o trabalho do otimizador dos especialistas por muitas GPUs.