Tempo de leitura: 6 minutos
Olá, é um prazer inenarrável estar mais uma vez escrevendo este post. A NVIDIA apresentou uma abordagem para usar IA agêntica na tradução de operações CUDA Tile escritas em Python para cuTile Rust, uma interface voltada à criação de kernels de GPU com as garantias de segurança e propriedade da linguagem Rust.
A proposta não consiste simplesmente em pedir a um modelo de IA que converta um arquivo e torcer para que o resultado funcione. O processo usa vários agentes especializados, validações automáticas e comparação da representação intermediária do código. O objetivo é transformar uma tarefa que poderia produzir um kernel “quase correto” em um fluxo verificável de engenharia.
Segundo a NVIDIA, a abordagem foi aplicada aos 24 operadores públicos do TileGym, com cerca de 40 kernels ao todo. Em testes realizados em uma NVIDIA DGX B200, a implementação em cuTile Rust alcançou, em média, 99,5% do desempenho da versão em cuTile Python. O detalhe mais interessante, porém, está menos no número final e mais na forma como a tradução é controlada.
Como o cuTile Rust se conecta ao CUDA Tile
cuTile Python, Triton-TileIR e cuTile Rust funcionam como diferentes interfaces sobre a mesma representação intermediária: o CUDA Tile IR. Depois dessa etapa, o compilador tileiras aplica otimizações em nível de tiles e gera o binário da GPU.
Essa arquitetura compartilhada muda a natureza da conversão. Em vez de reotimizar um kernel do zero, o processo procura expressar em Rust o mesmo programa de tiles que já existia em Python ou Triton-TileIR. É como traduzir uma receita para outro idioma mantendo os mesmos ingredientes, quantidades e etapas de preparo.
A representação intermediária também permite uma verificação estrutural. A equipe pode comparar o IR do kernel de referência com o IR gerado pelo código Rust antes mesmo de executar os testes funcionais. Assim, é possível identificar diferenças em operações de memória, formatos de tiles, reduções e atributos que talvez passassem despercebidas em um conjunto limitado de testes.
Por que traduzir para cuTile Rust exige mais do que trocar a sintaxe
Uma das principais dificuldades está na maneira como Python e Rust lidam com especialização. No cuTile Python, o compilador JIT pode especializar um kernel no momento da chamada, usando os tipos, formatos e parâmetros recebidos. Em cuTile Rust, essas especializações precisam aparecer explicitamente na assinatura do kernel.
Na prática, informações que ficavam implícitas no código Python precisam ser declaradas para o compilador Rust. Isso inclui formas de tiles, tipos de dados e variantes estruturais. Uma ramificação constante que seria eliminada antes da compilação em Python pode exigir entradas estruturais separadas em Rust, especialmente quando altera a dimensão ou o formato do tile.
Essa explicitação aumenta o trabalho de tradução, mas também torna as restrições mais visíveis. O compilador rustc pode verificar tipos e formas durante a compilação do código-fonte, enquanto o runtime ainda realiza a especialização final do kernel com os valores concretos usados na execução.
Um exemplo com softmax
No exemplo apresentado pela NVIDIA, um kernel de softmax em Python carrega uma linha, converte seus valores para ponto flutuante, calcula o máximo e a soma dos exponenciais e grava o resultado. A versão em cuTile Rust mantém a mesma lógica, mas descreve de forma explícita os tipos e as dimensões dos tiles.
Uma operação de carregamento com preenchimento por infinito negativo, por exemplo, é representada em Rust por uma visão de partição e uma operação de carregamento correspondente. Reduções que mantêm dimensões também precisam ser acompanhadas por operações explícitas de remodelagem e transmissão.
A comparação do IR confirma se as duas versões preservam o mesmo conjunto essencial de operações: carregamento de visão, reduções, armazenamento e operações TMA. Isso ajuda a detectar uma tradução que produz resultados plausíveis nos testes, mas usa uma operação de memória diferente ou perde uma informação importante de desempenho.
Como funciona o fluxo de agentes para gerar cuTile Rust
O skill de conversão disponibilizado no repositório TileGym organiza o trabalho em uma sequência de agentes especializados. O agente principal atua como orquestrador: ele encaminha cada etapa, acompanha os resultados e decide o próximo passo com base em veredictos verificáveis.
O primeiro estágio analisa o kernel de referência. Ele identifica variantes, tipos, formatos, tolerâncias, configurações de lançamento e parâmetros de autotuning. Quando há mais de uma implementação disponível, como uma versão em cuTile Python e outra em Triton-TileIR, o analisador pode compará-las e escolher a referência de desempenho para a conversão.
Em seguida, um agente dedicado escreve o kernel Rust. Ele não cuida da camada de host nem da interface FFI, o que mantém mais claro o responsável por cada erro. O kernel é então testado isoladamente e submetido à comparação de IR.
Outro agente constrói a camada de host e a interface C. Essa etapa conecta os kernels ao TileGym e executa os testes reais do operador em diferentes formatos e dimensões. Só depois de uma validação funcional bem-sucedida o processo avança para os benchmarks.
Quando algo falha, agentes de diagnóstico analisam o problema sem editar diretamente o código. Um deles compara os IRs para descobrir se houve uma tradução incorreta ou um possível problema no compilador. Outro investiga diferenças de desempenho, considerando tanto o código do dispositivo quanto a configuração de lançamento, o autotuning e a lógica do wrapper.
O papel das validações na conversão para cuTile Rust
A NVIDIA descreve o fluxo como uma pequena máquina de estados com tentativas limitadas. Cada etapa termina com um bloco de validação e uma linha de veredicto. O orquestrador não precisa interpretar uma explicação longa do agente para decidir o que fazer: ele segue os códigos e as categorias de falha definidos pelo processo.
Essa separação é importante porque uma conversão completa pode envolver muito contexto técnico. Se um teste falha depois que o kernel isolado já foi aprovado, o problema provavelmente está na camada de host, na interface ou na integração. Sem essa divisão, seria fácil mandar o agente errado investigar o defeito.
O fluxo também usa limites para impedir tentativas infinitas. Há um número máximo de execuções para análise, escrita do kernel, construção do host, diagnóstico e benchmarking. Se a conversão não converge dentro desse orçamento, o processo termina com um registro do diagnóstico em vez de continuar consumindo recursos sem uma conclusão clara.
Desempenho e integração do cuTile Rust com o TileGym
Na integração com o TileGym, os tensores atravessam a interface C como descritores contendo ponteiro, dimensões e strides. De acordo com a NVIDIA, essa camada não copia os dados nem assume a propriedade da memória. O kernel recebe os ponteiros existentes e é lançado na mesma stream CUDA usada pelo chamador.
Essa integração permite que o cuTile Rust funcione como outro backend do TileGym. O projeto também oferece compilação preguiçosa: alterações no código do kernel ou no manifesto podem provocar uma nova compilação na próxima chamada, sem exigir um processo manual separado a cada mudança.
Os benchmarks descritos pela NVIDIA foram feitos com tempo de dispositivo medido via CUPTI em uma DGX B200. Entre 24 operadores e 347 configurações pareadas, a média geométrica do cuTile Rust foi de 0,995 em relação ao cuTile Python. Todos os operadores ultrapassaram o limite de 0,95 usado no processo de aceitação, e aproximadamente um terço apresentou desempenho superior ao da referência.
Esses números não significam que toda aplicação Rust será automaticamente mais rápida. O resultado está relacionado ao fato de as duas interfaces produzirem programas baseados no mesmo IR e compartilharem o compilador e o modelo de otimização. A tradução fiel tende a preservar o comportamento de desempenho, mas a medição continua sendo necessária para cada operador e configuração.
O que a abordagem da NVIDIA revela sobre IA agêntica e código
O aspecto mais relevante do anúncio talvez seja a tentativa de limitar a autonomia dos agentes com contratos verificáveis. Em vez de deixar um único modelo analisar, programar, testar e julgar o próprio trabalho, o processo divide essas funções e exige evidências intermediárias.
Isso não elimina a possibilidade de erros. Um compilador pode ter limitações, uma regra pode estar incompleta e um benchmark pode não representar todos os cenários de uso. Mas a estrutura reduz a dependência de uma resposta convincente e aumenta a chance de localizar o problema.
A abordagem também mostra por que agentes de IA para programação precisam de ferramentas externas, testes e critérios objetivos. Gerar código é apenas uma parte do trabalho. Em sistemas de alto desempenho, a tradução precisa preservar tipos, memória, formas, comportamento numérico, integração com o host e desempenho. Sem essas verificações, um código que compila pode ser apenas uma ilusão bem formatada.
O skill de conversão está disponível no repositório TileGym, junto com instruções por etapa, regras de programação, scripts de validação e exemplos. A NVIDIA informa como requisitos CUDA 13.1 ou superior, Rust 1.89 ou superior, um compilador tileiras e uma GPU Blackwell para a verificação de desempenho descrita no artigo.
Conclusão: cuTile Rust transforma a tradução em um processo auditável
A experiência apresentada pela NVIDIA sugere que traduzir kernels de Python para cuTile Rust pode ser mais confiável quando a IA trabalha dentro de um processo com papéis separados, artefatos intermediários e validações automáticas. O ganho não está apenas em escrever código Rust com rapidez, mas em demonstrar que o resultado preserva a estrutura, a correção e o desempenho esperados.
O uso do mesmo CUDA Tile IR oferece uma base especialmente útil para essa verificação. A comparação estrutural permite encontrar diferenças que testes funcionais isolados poderiam não revelar, enquanto os benchmarks mostram se a implementação continua próxima da referência em condições reais.
Assim, a principal lição não é que um agente consegue substituir sozinho um especialista em kernels. É que agentes podem participar de uma cadeia de engenharia mais controlada, na qual cada etapa precisa deixar evidências antes de liberar a próxima. Para código de GPU, essa diferença pode separar uma automação realmente útil de um simples gerador de exemplos que parecem corretos.
