Nos últimos meses, temos desenvolvido um sistema multiagente capaz de desenvolver, manter e implementar software complexo de forma autônoma. Como parte desse trabalho, temos testado o sistema em diversos domínios, incluindo fazê-lo criar um navegador do zero e resolver um problema matemático de nível de pesquisa no benchmark First Proof.

Recentemente, começamos a colaborar com a NVIDIA em um novo desafio: aplicar o harness multiagente para otimizar kernels CUDA. Esses são problemas técnicos difíceis, com impactos importantes no mundo real: os kernels CUDA são o software central que dá suporte ao treinamento e à inferência de modelos de IA em GPUs NVIDIA. Kernels mais rápidos significam melhor utilização de GPU, menor consumo de energia, menor latência e menor custo por token — permitindo que provedores ofereçam modelos maiores e mais capazes a mais usuários ao mesmo tempo.

Nosso harness multiagente operou de forma autônoma por três semanas em 235 problemas. O sistema alcançou um ganho médio geométrico de velocidade de 38% ao desenvolver e otimizar kernels para GPUs Blackwell do zero, até o nível de assembly.

Esses níveis de melhoria de performance normalmente só são alcançados após meses ou anos de trabalho de engenheiros de kernel altamente experientes. O sistema multiagente conseguiu isso em semanas, lidando com uma longa cauda de problemas de kernel que eram impraticáveis com as abordagens existentes.

#Otimização de kernel como teste das capacidades de um sistema multiagente

Uma das melhores maneiras de avaliar sistemas multiagentes de longa duração é propor problemas de otimização em aberto nos quais nem nós sabemos qual é a resposta ideal. Problemas de otimização de kernel atendem a esse critério: eles oferecem objetivos mensuráveis que o sistema pode otimizar iterativamente, em vez de buscar um diff simples e conhecido.

Hoje, engenheiros otimizam kernels dividindo modelos em operações matemáticas individuais e ajustando cada uma separadamente. Isso torna o problema administrável, mas deixa performance de lado, porque a otimização fragmentada não captura ganhos potenciais de otimizar todo o sistema ao mesmo tempo. Até hoje, a performance da GPU tem sido limitada pela nossa incapacidade de explorar todo o espaço de soluções além dessas simplificações manuais.

Com este experimento, queríamos ver se nosso sistema multiagente conseguiria operar fora dessas restrições, explorando um espaço de soluções mais amplo para produzir kernels mais rápidos.

#SOL-ExecBench para geração de problemas e benchmarking

A NVIDIA usou o SOL-ExecBench para gerar 235 problemas de otimização a partir de mais de 124 modelos open source em produção, como Deepseek, Qwen, Gemma, Kimi e Stable Diffusion. Em vez de dados sintéticos ou kernels simplificados, cada problema representa uma restrição do mundo real em cargas de trabalho de treinamento ou inferência para uma variedade de arquiteturas de modelos: LLMs, difusão, visão, áudio, vídeo e híbridos multimodais.

Também usamos o SOL-ExecBench para avaliar soluções de kernel multiagente em 27 GPUs NVIDIA Blackwell 200. O SOL-ExecBench é um avaliador eficaz que compara a performance do kernel com linhas de base de software existentes e os limites teóricos de performance do hardware. Se os agentes usarem táticas desleais, como caching, e entregarem performance acima do que uma B200 consegue suportar, o pipeline invalida o resultado.

#Como executamos o experimento

O sistema multiagente resolveu todos os 235 problemas de otimização de kernels de GPU em uma única execução, usando um agente planejador que distribuiu e reequilibrou o trabalho entre workers autônomos com base em métricas de performance.

Todo o protocolo de coordenação ficava em um único arquivo Markdown que especificava o formato de saída, as regras e os testes. O sistema multiagente aprendeu de forma autônoma a chamar o pipeline de benchmarking durante suas execuções, criando um loop em que o sistema testava, depurava e otimizava kernels continuamente, sem nenhuma intervenção de desenvolvedor.

Para avaliar melhor as capacidades do sistema multiagente, pedimos que ele escrevesse suas soluções em duas linguagens, em duas execuções separadas, em extremos opostos do espectro de abstração de GPU:

• CUDA C with inline PTX, que dá aos agentes acesso direto a registradores e instruções em nível de ISA, testando se o sistema consegue raciocinar sobre o hardware no nível mais baixo.
• CuTe DSL, que fornece abstrações composáveis de alto nível com presença mínima em dados públicos de treinamento, testando se o sistema consegue aprender novas APIs apenas com a documentação fornecida.

#Ganho de velocidade de 38%, com 19% das otimizações ultrapassando ganhos de 2x

Apresentamos a performance do sistema multiagente de duas formas:

• Ganho médio geométrico de velocidade em comparação com o código PyTorch otimizado por um único agente como linha de base.
• Pontuações Speed-of-Light (SOL), que representam o quão boa é uma solução em comparação com os limites teóricos do hardware em uma curva logarítmica. Uma pontuação de 0,5 representa a linha de base otimizada do PyTorch, e 1,0 é o limite de performance.

Nosso sistema multiagente superou as linhas de base em 149 dos 235 problemas (63%), com uma razão de média geométrica de 1,38x (ganho médio geométrico de velocidade de 38%).

Em 45 dos 235 problemas (19%), o sistema multiagente alcançou otimizações superiores a 2x em comparação com as linhas de base. Você pode ver as soluções finais desenvolvidas pelo nosso sistema neste repositório público.

#Diferentes estratégias de otimização para diferentes problemas

Para mostrar a adaptabilidade do sistema a diferentes tipos de problemas, destacamos três casos em que ele chegou, de forma orgânica, a estratégias de otimização distintas.

#Atenção de Consultas Agrupadas BF16 com Paged Prefill

A atenção de consultas agrupadas com paged prefill é uma operação comum na fase de prompt em stacks modernas de inferência de LLM. Uma implementação bem otimizada pode suportar contextos mais longos, maior concorrência e melhor taxa de processamento na mesma VRAM de GPU.

O agente usou CUDA C++ para otimizar esse problema de atenção extraído da inferência do SGLang para Llama 3.1 8B. À medida que refinava o kernel, ele empregou com sucesso instruções específicas de hardware para carregamento de memória e operações matemáticas, adicionou um escalonamento aprimorado por meio de kernels persistentes e otimizou agressivamente para o tamanho da entrada.

Comparamos o kernel customizado do sistema multiagente com uma linha de base otimizada manualmente na biblioteca FlashInfer. Constatamos que o sistema produziu uma solução próxima dos limites do hardware, com uma pontuação SOL de 0.9722, representando um ganho médio geométrico de velocidade de 84% em relação à linha de base.

Também substituímos o kernel existente no SGLang e observamos um ganho de velocidade de 3% no tempo até o primeiro token (TTFT) no Llama 3.1 8B. Considerando que esse problema de atenção ocupa de 2% a 5% do processo de prefill, dependendo da configuração de serving, vemos isso como um ganho de velocidade ponta a ponta não trivial.

#Linear NVFP4 de MoE com Gating

Esse problema representa um padrão comum de dois kernels encontrado em modelos Mixture-of-Experts, como o Qwen3, com a ressalva de que o tensor de entrada e o resultado intermediário da multiplicação são quantizados em NVFP4 (ponto flutuante de 4 bits).

O agente identificou corretamente a etapa de quantização como o principal gargalo e, por isso, fundiu o cálculo de escala com o arredondamento. Em vez de escalar e depois arredondar durante a quantização, ele usou faixas de limiar pré-computadas para mapear diretamente valores FP32 em códigos FP4, o que é possível porque existem apenas 16 valores possíveis de NVFP4. Em seguida, aplicou essas otimizações a casos de teste maiores.

No fim, o agente superou a linha de base otimizada do PyTorch, alcançando um ganho médio geométrico de velocidade de 39% e uma pontuação SOL de 0,58.

#Multiplicação de Matrizes BF16

A multiplicação de matrizes é um problema notoriamente difícil de otimizar porque exige um entendimento profundo das várias unidades de hardware e do seu escalonamento. Kernels de multiplicação de matrizes de alto desempenho (GEMMs) exigem PTX inline (semelhante à linguagem assembly), pipelining e staging dentro de um kernel. Como resultado, historicamente, escrever GEMMs rápidos ficou restrito aos especialistas mais experientes em kernels.

O sistema multiagente do Cursor gerou do zero um kernel GEMM especializado em CUDA C++, chegando surpreendentemente perto (86%) de uma linha de base humana meticulosamente ajustada da biblioteca NVIDIA cuBLAS. O sistema alcançou esse resultado aprendendo de forma independente a usar instruções específicas do Blackwell, otimizando leituras e gravações de memória para o hardware e, em seguida, hiperotimizando para as dimensões exatas.

E, em casos de teste com M pequeno, que são especialmente importantes para a fase de decodificação da inferência de LLMs, o kernel do sistema multiagente superou a biblioteca em até 9%. Esse resultado indica que sistemas multiagente em breve superarão especialistas da área até mesmo nos problemas de kernel mais difíceis.

#Um sistema multiagente para desenvolver software

Embora o harness multiagente tenha proporcionado um ganho médio geométrico de velocidade de 38% em relação às linhas de base, a pontuação SOL mediana ainda foi de apenas 0,56, deixando bastante espaço para otimizações adicionais. Acreditamos que soluções multiagente podem melhorar muito com mais capacidade computacional, já que tínhamos centenas de problemas e agentes em execução em apenas 27 GPUs. Isso limitou nossa capacidade de aproveitar plenamente o sistema multiagente. Com mais GPUs, o sistema poderia explorar soluções ainda mais profundas e originais.

As tarefas mais ambiciosas no desenvolvimento de software são abertas, sem uma solução clara. Sistemas com um único agente têm dificuldade nesse cenário porque os modelos têm melhor desempenho em tarefas de escopo restrito que já viram durante o treinamento. Vemos o experimento de otimização de kernel como mais uma validação de que arquiteturas multiagente logo se tornarão a abordagem padrão para desenvolver software, porque conseguem enfrentar problemas inéditos que fogem muito à distribuição dos dados de treinamento.

As técnicas que estamos pesquisando aqui em breve vão informar o produto principal da Cursor. Se você tem interesse em trabalhar em problemas difíceis de coordenação multiagente, a equipe da Cursor adoraria falar com você em hiring@cursor.com.