CUDA em GPU AMD no Windows: quando compatibilidade vira opcionalidade de negócio

Um projeto open source fez uma carga voltada a CUDA rodar em uma Radeon no Windows. A prova é estreita, mas mostra como pilotos delimitados podem criar alternativas sem transformar um experimento em decisão de plataforma.

Em 13 de setembro de 2026, um repositório público registrou uma combinação pouco comum: uma aplicação Windows preparada para CUDA executando uma etapa real de treinamento em uma GPU AMD Radeon RX 9060 XT.

A carga usou LibTorch, uma rede com 2.216.347 parâmetros e uma pilha formada por ZLUDA e o HIP SDK da AMD. Segundo o mantenedor, uma iteração completou inferência, aprendizado e atualização do otimizador, processando 65.536 *timesteps*.

A manchete tentadora seria simples: “CUDA agora roda em GPU AMD no Windows”.

Não é isso que a evidência permite concluir.

O que o teste mostra é menor e, para quem toma decisões de tecnologia, mais útil: uma carga específica rodou em uma configuração específica. Isso não transforma a pilha em substituta geral do ecossistema NVIDIA. Mas pode transformar uma hipótese de portabilidade em uma alternativa mensurável.

E alternativa mensurável é o começo da opcionalidade.

Como a camada funciona

CUDA não é apenas uma linguagem ou uma biblioteca isolada. É um conjunto de APIs, ferramentas, bibliotecas matemáticas, runtime, drivers e integrações construído para GPUs NVIDIA. Uma aplicação pode depender de algumas dessas peças ou de muitas delas ao mesmo tempo.

Na arquitetura descrita pelo projeto CUDA for AMD on Windows, a aplicação continua “enxergando” uma interface CUDA. No meio do caminho, o ZLUDA recebe essas chamadas e tenta encaminhá-las para componentes compatíveis do ecossistema AMD. Operações de cuBLAS podem chegar ao rocBLAS; cuBLASLt, ao hipBLASLt; cuSPARSE, ao rocSPARSE; e chamadas de cuFFT passam pela implementação correspondente na pilha HIP/ROCm. No fim, o runtime HIP coordena a execução na GPU AMD.

É uma ponte, não uma cópia integral da estrada.

Isso importa porque existe outro caminho possível: converter o código-fonte de CUDA para HIP, recompilar e adaptar as diferenças. A própria documentação de portabilidade da AMD recomenda conversão incremental e testes a cada etapa. O ZLUDA persegue uma proposta distinta: permitir que determinadas aplicações CUDA sejam executadas sem uma migração prévia completa do código.

Quando funciona, essa camada reduz o custo de testar uma alternativa. Quando não cobre uma API, uma biblioteca ou um comportamento de PTX usado pela aplicação, a execução pode falhar ou exigir trabalho adicional.

Compatibilidade, portanto, não é um selo. É uma cadeia.

O que o projeto demonstrou

O documento de validação fixa o ambiente testado: Windows x64, Radeon RX 9060 XT com arquitetura `gfx1200`, ZLUDA `v6-preview.69`, HIP SDK 6.4 e LibTorch `2.3.0+cu118`. O caminho público usa a distribuição oficial do ZLUDA e o HIP SDK instalado, sem depender das DLLs experimentais recuperadas durante o desenvolvimento.

O teste `cuda_check` do próprio ZLUDA reportou sucesso para o driver `nvcuda` e para os grupos cuBLAS, cuBLASLt, cuSPARSE e cuFFT. Depois, o mantenedor executou a carga de Proximal Policy Optimization, ou PPO, que motivou o projeto. A validação foi interrompida após uma iteração completa porque seu objetivo declarado era verificar a execução, não medir desempenho sustentado.

O repositório também publica um A/B com metodologia e dados brutos. Foram dois ensaios de cinco iterações para cada runtime, com descarte da primeira iteração como aquecimento. Nas oito medições restantes por caminho, a configuração pública obteve mediana de 13.278,46 passos por segundo, contra 12.875,80 da sobreposição personalizada recuperada.

Esse número precisa ser lido pelo que ele é.

O A/B não compara a Radeon com uma GPU NVIDIA. Não compara preço, consumo de energia, disponibilidade, suporte ou tempo de engenharia. Ele apenas indica que, naquela carga e naquela máquina, a sobreposição personalizada foi cerca de 3,03% mais lenta do que o caminho público. O resultado ajudou o projeto a escolher seu runtime padrão; não serve para declarar qual fornecedor oferece a melhor plataforma.

Há um mérito concreto aqui: versões estão fixadas, os arquivos baixados têm hashes SHA-256, a arquitetura está documentada e o instalador inclui diagnóstico e teste de runtime. Isso torna a alegação mais auditável do que uma captura de tela solta.

Ainda assim, todos os resultados de execução e desempenho foram publicados pelo próprio projeto. Não encontrei, durante esta apuração, uma reprodução independente dessa carga e dessa configuração.

O que ele não demonstrou

O próprio mantenedor limita a validação à RX 9060 XT. Outras GPUs reconhecidas pelo scanner são candidatas não verificadas. A tabela atual de hardware da AMD lista a RX 9060 XT e a arquitetura `gfx1200` como suportadas pelo runtime e pelo HIP SDK no Windows, mas esse suporte oficial ao hardware não confirma que qualquer aplicação CUDA funcionará por meio do ZLUDA.

Também há lacunas na camada de software. Na configuração validada, cuDNN não ficou disponível. A documentação do HIP SDK 6.4 para Windows explica o motivo estrutural: a distribuição oferecia apenas um subconjunto do ROCm e não incluía as bibliotecas de IA MIOpen e MIGraphX nem bibliotecas de comunicação. O projeto alerta ainda para possíveis falhas em cargas dependentes de NCCL, TensorRT, comportamentos de PTX não cobertos e extensões CUDA personalizadas.

O próprio ZLUDA avisa que está em desenvolvimento intenso e pode não funcionar com a aplicação que o usuário tentar executar. Além disso, a versão `v6-preview.69` usada no teste é uma prévia, embora tenha sido fixada justamente para tornar o ambiente reproduzível.

Rodar uma iteração também não responde às perguntas que aparecem depois: a carga permanece estável por dias? O resultado numérico mantém a precisão esperada? Como a pilha se comporta sob concorrência, pressão de memória e atualizações de driver? Há observabilidade suficiente para diagnosticar uma regressão? Quem assume o incidente se uma dependência comunitária parar de acompanhar o restante do ecossistema?

É nessa distância entre “rodou” e “opera” que muitas decisões ruins de plataforma nascem.

O piloto que cria uma opção real

Uma empresa não precisa escolher entre ignorar a alternativa e migrar toda a infraestrutura. Existe um terceiro caminho: construir uma prova pequena, reversível e comparável.

Para que o piloto produza poder de decisão, ele precisa de sete definições.

1. **Carga delimitada.** Escolha um executável, modelo, conjunto de dados, tamanho de lote e perfil de uso. “Nosso ambiente de IA” é amplo demais para ser testado.

2. **Critério de correção.** Defina tolerância numérica, saídas esperadas, determinismo necessário e quais erros encerram o teste. Velocidade não compensa resultado incorreto.

3. **Ambiente reproduzível.** Registre GPU, driver, versão do Windows, HIP SDK, ZLUDA, bibliotecas, hashes e configuração. Inclua inventário de componentes e análise das licenças; o repositório usa MIT apenas para seus scripts e sua documentação, enquanto as dependências preservam termos próprios.

4. **Desempenho comparável.** Meça aquecimento, latência, vazão, memória, energia e estabilidade prolongada na mesma carga usada pelo ambiente atual. Um pico isolado não representa capacidade operacional.

5. **Custo total.** Some hardware, energia, engenharia de adaptação, testes, observabilidade, suporte, tempo de parada e manutenção de versões. O preço da placa é apenas uma linha da conta.

6. **Operação e reversão.** Determine como atualizar, monitorar, responder a falhas e retornar ao ambiente anterior. A rota de volta precisa ser testada, não apenas escrita em um documento.

7. **Regra de saída.** Antes de começar, estabeleça os limiares para ampliar, manter como contingência ou encerrar o piloto. Sem essa regra, qualquer resultado vira justificativa para a preferência que já existia.

O objetivo não é provar que uma marca substitui outra. É descobrir, com custo controlado, em quais cargas a empresa possui uma segunda rota confiável.

Essa rota muda a conversa com fornecedores. Melhora a qualidade de uma negociação de capacidade. Reduz a dependência de disponibilidade de um único tipo de hardware. E permite separar cargas que exigem o ecossistema completo daquelas que podem operar numa pilha mais aberta ou mais barata.

Mas a opção só existe se puder ser exercida. Um protótipo abandonado, preso a versões antigas e conhecido por uma única pessoa não é opcionalidade. É arqueologia técnica esperando para acontecer.

A decisão de plataforma vem depois

O projeto publicado em setembro não encerra a discussão sobre CUDA em AMD no Windows. Ele faz algo mais honesto: abre uma superfície de teste e documenta seus limites.

Para gestores, esse é o sinal certo. Não aprovar uma migração. Não prometer economia. Não redesenhar a capacidade inteira com base em uma iteração.

Começar fazendo o que não escala.

Escolher uma carga não crítica, reproduzir o ambiente, comparar com a plataforma atual, medir o custo de operação e testar a reversão. Se a prova sobreviver, ampliar um degrau. Se falhar, registrar onde a cadeia rompeu e encerrar com aprendizado barato.

O ganho do primeiro piloto não é provar que AMD substitui NVIDIA.

É descobrir quanto custa manter a escolha aberta.

*Lincoln Ferraz — Arquiteto de Negócios | Estratégia & Inovação | Product Engineer*