- Kernels CUDA-C gerados por IA mostraram desempenho semelhante ou superior aos kernels otimizados por especialistas do PyTorch
- Um único LLM (modelo de linguagem de grande porte) repetiu a geração de ideias de otimização em linguagem natural e diversos branchings de código, alcançando desempenho superior aos métodos existentes em diversidade de otimização e busca paralela
- Em benchmarks representativos, os resultados foram amplamente superiores ao PyTorch em Matmul (101%), Conv2D (179,9%), Softmax (111,8%), LayerNorm (484,4%), Conv2D+ReLU+MaxPool (290,1%)
- Para superar os limites da tradicional "melhoria sequencial de kernels", foi aplicada uma estrutura de raciocínio em linguagem natural + branching, gerando kernels de alto desempenho em alta velocidade
- Também há progresso em cargas de trabalho modernas de ML, como FP16 e Flash Attention, sugerindo que no futuro o paradigma dominante poderá ser o de IA explorando e aprimorando kernels mais rápidos por conta própria
TL;DR principais resultados
- A equipe de pesquisa do Stanford CRFM encontrou exemplos em que kernels CUDA-C de alto desempenho gerados por IA alcançam velocidades semelhantes ou superiores às de kernels do PyTorch projetados por especialistas
- O objetivo inicial era treinar um modelo de geração automática de kernels melhores por meio de dados sintéticos, mas observaram que apenas o processo de geração desses dados sintéticos já produzia automaticamente kernels rápidos em nível surpreendente
- Por isso, divulgaram antecipadamente o método, os benchmarks de desempenho, as estratégias de otimização e os próximos rumos
- Benchmark: com GPU Nvidia L40S. Desempenho (%): tempo de execução do PyTorch ÷ tempo de execução do kernel gerado
- Matmul (FP32): 101,3% em relação ao PyTorch (matriz 4096x4096)
- Conv2D: 179,9% (entrada: 100, 3, 224, 224; especificação AlexNet Conv1)
- Softmax: 111,8% (tensor 4096x65536)
- LayerNorm: 484,4% (tensor 16, 64, 256, 256)
- Conv2D + ReLU + MaxPool: 290,1% em relação à referência do PyTorch, 189,0% em relação a
torch.compile()
Motivação da pesquisa e método
- O objetivo original era gerar dados sintéticos para treinar um modelo de geração de kernels, mas no processo experimental os próprios kernels gerados atingiram desempenho muito acima do esperado
- Uso do KernelBench (benchmark público da Stanford, lançado em dezembro de 2024)
- Dado um código
torch, o LLM reescreve um novo kernel com velocidade otimizada
- A correção é validada verificando a equivalência numérica entre entrada e saída
- Abordagem anterior: um loop de modificação sequencial que melhora gradualmente o kernel com pequenos ajustes passo a passo
- Desvantagens: pouca diversidade de ideias, repetição das mesmas otimizações e convergência para ótimos locais
- Ideia de melhoria
- Primeiro, conceber e registrar ideias de otimização em linguagem natural; depois gerar simultaneamente vários branchings de implementação em código dessas ideias
- Em cada rodada, executar em paralelo várias tentativas de otimização → usar o kernel de melhor desempenho como semente para a rodada seguinte
- Assim, dentro de um número limitado de iterações de busca, torna-se possível explorar estratégias diversas de otimização e busca paralela
Exemplos de ideias de otimização
- Otimização de acesso à memória: melhorar a eficiência da hierarquia de memória global/shared/register
- Processamento assíncrono e ocultação de latência: sobrepor computação e movimentação de dados
- Otimização de tipo de dado/precisão: uso de FP16/BF16 e operações especializadas de hardware
- Otimização de cálculo e instruções: reduzir volume de cálculo, número de instruções e usar melhor instruções especiais do hardware
- Paralelismo e occupancy: maximizar o uso dos SMs (Streaming Multiprocessors)
- Otimização de loop/branching/indexação: minimizar loops e remover cálculos de índice desnecessários
Processo real de otimização de kernel (exemplo Conv2D)
- Fluxo de ideias de otimização por rodada e melhora de desempenho
- Inicial (rodada 0): porte simples para CUDA (20% da velocidade do PyTorch)
- Rodadas seguintes: → uso de cache de leitura → operação FP16 Tensor Core (conversão para GEMM) → double buffering/pipeline → pré-cálculo de índices/memória compartilhada → vetorização → buffering simultâneo no loop K, entre outros usos avançados da arquitetura de GPU
- Final (rodada 13): 179,9% de desempenho em relação ao PyTorch
- O código real faz amplo uso de técnicas avançadas de programação CUDA
- Em cada rodada, novas ideias são geradas em linguagem natural, várias implementações são testadas em paralelo e o melhor código é selecionado
Takeaways e implicações
- A geração de kernels baseada em IA pode superar especialistas humanos ao combinar um loop de busca poderoso com diversas ideias de otimização baseadas em linguagem natural
- Alguns operadores modernos ainda têm desempenho inferior ao PyTorch no momento, como FP16 matmul e Flash Attention
- Em hardware recente, cálculos FP32 tendem a ser relativamente menos otimizados que FP16/BF16 → isso pode abrir espaço para vantagem de desempenho nessa área
- Melhorias contínuas de desempenho foram confirmadas mesmo com orçamento limitado de tokens de busca (7 milhões de tokens no total entre entrada e saída)
- Pesquisas recentes, como AlphaEvolve e Gemini 2.5 Pro, também sugerem que busca baseada em branching em larga escala + validação pode trazer ganhos revolucionários de desempenho sem retreinamento
- No futuro, essa abordagem poderá gerar em massa dados sintéticos e kernels de alto desempenho, evoluindo para um loop de IA autocorretiva e autoaperfeiçoável
Conclusão
- A geração e otimização automática de kernels por IA já alcançou um nível comparável ao de código manual de especialistas, e no futuro próximo a combinação de modelo + busca com branching + validação pode viabilizar sistemas de IA com autoaperfeiçoamento
- Surge a possibilidade de a IA ultrapassar por conta própria os limites de desempenho de frameworks como PyTorch e TensorFlow
Apêndice: código completo do kernel Conv2D
- Inclui a implementação completa da função e do código-fonte do kernel (código detalhado omitido)
- Principais características no código:
- vetorização em memória compartilhada, double-buffering hierárquico na dimensão K, CUDA WMMA, buffer de saída em nível de warp etc.
- cálculo dinâmico de índices em tempo real, tratamento de bias, carregamento simultâneo de dados com latência escondida dentro do loop K etc.
- O código de exemplo completo e kernels de demonstração podem ser vistos no repositório do GitHub
2 comentários
Seria uma espécie de técnica de ensemble, talvez. Impressionante.
Comentários do Hacker News
Acho bem interessante a forma como os autores deste texto encaram "agentes de IA"
A maioria das pessoas tende a pensar em agentes como se fossem funcionários humanos
Configura poucos agentes em paralelo (muitas vezes só um), e cada um fica em loop lidando com apenas uma tarefa por vez
Ainda estão presas a um mundo com quadro fixo de pessoal, trabalhadores que só conseguem fazer uma coisa por vez e troca de contexto lenta
Mas LLM não é assim
Você pode criar, na prática, uma quantidade infinita de agentes quando quiser
Não há diferença de custo entre processar requisições de LLM em série ou em paralelo
Quando se percebe isso, surge naturalmente o padrão em que cada agente se ramifica em vários subagentes conforme necessário
Foi exatamente isso que os autores tentaram fazer
Parece mais adequado pensar em agentes como "tasks" ou "jobs" e aplicar o que aprendemos com Celery ou Sidekiq
"FP32 está sendo usado bem menos nas cargas modernas de ML, e no hardware recente ele também recebe menos otimização do que FP16 ou BF16. Então isso pode ser um dos motivos pelos quais foi mais fácil superar o PyTorch em kernels FP32"
Os desenvolvedores quase não investiram tempo ao longo dos anos em otimizar versões de kernel em fp32
O realmente interessante, na minha opinião, será quando conseguirem melhorar o desempenho de kernels que de fato recebem desenvolvimento intenso e são os que as pessoas realmente usam
Acho que esses bons resultados podem ser explicados em parte pelo fato de a NVIDIA não fornecer documentação detalhada o suficiente sobre as GPUs
Se fosse um processador com microarquitetura bem documentada, programadores ou compiladores conseguiriam escrever programas comprovadamente ótimos, então não seria fácil obter grandes melhorias com ML/AI para além de encontrar soluções já conhecidas
Já no caso de algo menos documentado, como GPUs da NVIDIA, encontrar o programa ótimo muitas vezes exige busca aleatória com base em exemplos de programas previamente otimizados, ou engenharia reversa para entender como o hardware realmente se comporta em certas situações
Nesse contexto, ML/AI pode mostrar potencial e, ao aprender com bons programas como dados, pode capturar comportamentos undocumented que até programadores humanos teriam dificuldade de encontrar
Fico pensando se melhorias já conhecidas em kernels fp16/bf16 podem ter sido simplesmente transferidas para fp32
"Você está dizendo que ninguém mexeu nesses kernels fp32 por anos?"
Uau, se for isso mesmo, então é muito legal pensar que a IA teria criado novos algoritmos numa área onde não havia soluções prévias
Minha conclusão, vendo este artigo, o AlphaEvolve do Google(aqui) e a notícia recente de que o o3 encontrou um zero day no kernel do Linux(aqui), é que
especialmente o Gemini Pro 2.5 e o o3 parecem ter alcançado um novo nível de capacidade, em que de repente conseguem ter ideias que modelos anteriores não conseguiam
Eu não vejo isso como algo que simplesmente do nada passou a funcionar quando antes não funcionava
Na prática, passamos a conseguir iterar e testar muito mais rápido do que humanos
e a usar instantaneamente grandes volumes de informação
Ou seja, chegamos a um ponto em que uma combinação de enorme quantidade de informação, progresso e brute force aplicado de forma inteligente está dando certo em algumas áreas
Acho que há de fato muita semelhança entre os casos que você citou e este resultado
O texto também diz que "o loop de iteração em tempo de teste se parece menos com um chatbot interativo que verifica, em sequência, o resultado de cada modificação no código, e mais com uma busca estruturada que realiza avaliações paralelas ativamente com base em hipóteses claras de otimização"
Minha conclusão é que agora, com base na capacidade dos LLMs,
aprendemos a reduzir significativamente o espaço de soluções quando a função de avaliação é clara ou quando existem padrões parecidos
Não acho que a questão principal seja comparar modelos, tipo um supera o outro ou só um modelo específico consegue resolver...
O mais significativo é a realidade de que aplicações desse tipo já estão aparecendo de forma clara
O Gemini Pro 2.5 me pareceu a primeira IA que uma pessoa realmente consegue usar, mas, sendo preciso, ele mal passou desse limiar
Ainda há muitos casos em que a taxa de sucesso cai abaixo de 20%
Quando sair a 3.0... acho que isso pode começar a dar um pouco de medo
Espera, o que você quer dizer? Isso não tem nada a ver com kernel de Linux, é "kernel" no sentido de programação para GPU
Será que você não entendeu o texto inteiro errado?
É interessante, mas há alguma evidência mais forte? Um resultado único não é convincente o bastante
"O código de referência usa FP32 por padrão, e a tolerância permitida é 1e-02"
Com esse nível de erro, dá para substituir facilmente um kernel "fp32" por operações em fp16
Pensando só mais um passo, fico imaginando se o núcleo deste trabalho não foi justamente trocar o máximo possível de operações fp32 por fp16 nesse kernel
Seria preciso verificar o quão difícil essa migração realmente é, mas
intuitivamente isso não me parece tão impressionante
Se eu estiver errado, gostaria que os autores tratassem desse ponto com clareza
Nesse caso, o resultado perde o sentido
Não sei se chegaram a verificar erro relativo
Substituir float32 por float16 não significa muita coisa
Precisão parece ser justamente o único motivo para escolher float32
Se essa característica se perde, então também desaparece a diferenciação entre as versões
Mais alguém leu isso achando, pelo título, que a IA tinha criado um kernel de sistema operacional?
Uma melhora de 400% já é impressionante, mas
o que mais me chamou atenção foi a metodologia: em vez de apenas otimizar operações a cada iteração, forçaram uma etapa de raciocínio em linguagem para induzir diversidade na busca
É muito interessante que isso de fato tenha funcionado bem
Acho que é só evolução memética comum
Resultado realmente muito interessante
Parece que esse pessoal ficou empolgado demais e correu para publicar no blog
Talvez também quisessem obter feedback antes da publicação formal
Não sei se esse é o lendário caminho para "self improvement"
mas sinto que um resultado assim é exatamente o tipo de coisa que esperaríamos ver nesse caminho
Esses métodos só funcionam quando existe uma função de avaliação extremamente clara
Compartilhando minha experiência: ao tentar replicar, considerei o kernel de LayerNorm numericamente instável demais para ser validado
Como testaram apenas com média 0 e desvio padrão 1, o fenômeno de cancellation numérica não apareceu de imediato
Além disso, depois confirmei que eles criaram uma nova versão numericamente estável
Acho isso muito positivo
Resultado muito legal
Usei o o3 e o Gemini 2.5 Pro,
mas infelizmente não dizem qual dos dois produziu kernels melhores
Um ponto interessante é observar como código gerado por IA lida com áreas mais amplas, como fused kernels
Por exemplo, algo como gemm + relu + gemm + normalization
Seria um trabalho bem pesado tanto para percorrer tudo com um tuner quanto para uma pessoa escrever manualmente
Só está claro que não é kernel de sistema operacional