O moat CUDA — por que o ecossistema de software da NVIDIA defende o monopólio de hardware muito depois da AMD alcançar

A tese padrão de short em $NVDA diz: AMD embarca MI300X, depois MI350X, depois MI400 ao longo de 2024-2027, o gap de hardware fecha, as margens brutas de 75% da NVIDIA comprimem, a ação derata. A tese existe desde 2023. A AMD, de fato, embarcou cada uma dessas peças mais ou menos no prazo. As margens brutas da NVIDIA ainda são ~75%. A receita de GPU de data-center da AMD é aproximadamente um décimo da NVIDIA apesar de embarcar silício que faz benchmark competitivo em FLOPs brutos.

A tese bear acertou o hardware e errou tudo o resto. O moat real — aquele que você está long quando está long NVDA — é CUDA: um ecossistema de software de 19 anos que transforma os chips da NVIDIA no substrato default contra o qual cada modelo de IA é escrito contra, não apenas em. Este artigo é como esse moat se parece no nível técnico, por que migrar para fora dele custa mais que os chips, e o que de fato o quebraria.

O que CUDA realmente é

Quando alguém diz "CUDA" em conversa de trader geralmente quer dizer "a API que as GPUs da NVIDIA rodam". Isso está errado por umas três camadas. CUDA é uma stack:

Camada 1 — o driver e runtime. A interface OS de baixo nível que deixa um processo falar com a memória da GPU e submeter kernels de compute. AMD tem um equivalente funcional (runtime ROCm, antes HSA). Essa camada está resolvida.

Camada 2 — a linguagem de kernel e compilador. CUDA C++ é a linguagem; nvcc compila para PTX (representação intermediária da NVIDIA) e depois para SASS (machine code). Triton é uma linguagem de kernel Python-embedded de mais alto nível que a NVIDIA adquiriu indiretamente via o release open-source da OpenAI e integrou. A AMD tem HIP (uma linguagem source-compatible com CUDA) e um compilador HIP→ROCm. A compatibilidade é source-level mas nem sempre behavior-level — regressões de performance de 20-40% em kernels idênticos são rotina ao portar de CUDA para HIP.

Camada 3 — a stack de bibliotecas tunadas à mão. É aqui que o moat realmente mora:

• cuDNN — primitivas de convolução e attention hand-otimizadas da NVIDIA. Todo framework major chama cuDNN para os inner loops de todo transformer, todo modelo de difusão, todo sistema de recomendação.
• NCCL — comunicação coletiva multi-GPU. A biblioteca que faz 8 GPUs num servidor, depois 8 servidores num rack, depois 32 racks num pod parecerem uma única máquina para o PyTorch. NCCL foi otimizada contra o interconnect da NVIDIA (NVLink, NVSwitch, InfiniBand) por uma década. RCCL da AMD é funcional mas materialmente mais lenta na mesma topologia de fabric.
• cuBLAS — álgebra linear densa. As primitivas GEMM (matrix multiply) que dirigem o inner loop de attention, MLPs, e kernels de convolução. cuBLAS foi tunada per-arquitetura (Volta, Turing, Ampere, Hopper, Blackwell) por uma equipe que não faz outra coisa.
• CUTLASS — biblioteca template open-source CUDA para kernels GEMM e conv. A implementação de referência para "como escrevo um kernel custom que bate 95% do peak numa dada arch NVIDIA".
• cuFFT, cuSPARSE, cuRAND, cuSOLVER, Thrust — e mais 15 bibliotecas domain-specific que não têm equivalente do lado AMD nenhum, ou têm equivalentes três anos atrás.

Camada 4 — as integrações de framework. PyTorch, JAX, TensorFlow, vLLM, TensorRT-LLM, DeepSpeed, Megatron-LM, FlashAttention, xFormers, BitsAndBytes — todo framework ou biblioteca de kernel que você já ouviu falar é CUDA-first. O caminho AMD/ROCm é um port mantido por uma equipe menor, frequentemente um release atrás, às vezes quebrado no último release de modelo.

Camada 5 — o tooling. Nsight Systems, Nsight Compute, CUDA-GDB, a suíte de profiler. As ferramentas que um engenheiro ML usa para descobrir por que o kernel está 30% mais lento que o peak e consertar. AMD tem equivalentes (rocprof, ROCm-GDB) que funcionam mas atrasam em capacidade.

Camada 6 — o ecossistema. Dezoito anos de respostas Stack Overflow, issues GitHub, fóruns de developer NVIDIA, cursos CUDA de universidade, tutoriais GTC da própria NVIDIA. Quando um estudante de pós entrando num lab de pesquisa em 2026 aprende programação GPU, ele aprende CUDA. ROCm é uma nota de rodapé no mesmo currículo se aparece.

Quando AMD ou Google ou Amazon competem em hardware, eles competem com a Camada 1 e (na maioria) Camada 2. O moat são as Camadas 3-6.

Por que o custo de migração importa mais que o preço do chip

Um hyperscaler comprando um H100 de US$30.000 não está pagando US$30.000 por silício. Eles estão pagando US$30.000 porque o resto da stack — o framework de training, o runtime de inference, o formato de checkpoint de modelo, a biblioteca de kernel, o tooling de monitoring, a equipe que sabe como debugar um kernel CUDA — está toda em CUDA. O custo de migração de trocar a NVIDIA fora do data center é:

1. Revalidar o model zoo. Um hyperscaler está rodando centenas de modelos internos — search, ads, recomendações, moderação de conteúdo, generativos — cada um tunado para rodar otimamente em H100/H200/B200. Portar cada um para ROCm ou para um ASIC custom significa revalidar equivalência numérica (o modelo produz o mesmo output bit-equivalent? se não, a divergência importa para a métrica?), rerodar testes A/B, e aceitar algum risco não-zero de regressão num sistema de produção. O custo de engenharia por modelo major é multi-trimestre.

2. Reescrever kernels custom. Todo hyperscaler tem kernels internos-only de fused-attention ou MoE-routing escritos em CUDA. Portar para HIP funciona em teoria; na prática a regressão de performance no port é grande o suficiente que a equipe reescreve do zero contra a arquitetura CDNA da AMD, que tem widths SIMD diferentes, hierarquia de cache diferente, e primitivas de sincronização diferentes. Engenheiros sêniores de kernel CUDA são um talent pool de 4 dígitos globalmente. Equivalentes do lado AMD são menores.

3. Refazer a stack de inference. TensorRT-LLM é o runtime de inference otimizado da NVIDIA — quantization-aware, kernel-fused, batching-aware. O equivalente ROCm (MIGraphX, vLLM-ROCm) é funcional mas atrás. Migrar budgets de latência de inference de produção para AMD significa aceitar (inicialmente) latência de cauda maior ou rodar mais silício para compensar.

4. Treinar a equipe. Engenheiros de plataforma ML sabem CUDA. Mudar para ROCm ou ASIC custom significa uma curva de aprendizado de 6-12 meses por engenheiro mais um mercado de contratação onde talento experiente em AMD comanda um prêmio e é mais difícil de encontrar.

O custo cumulativo está nos mid-9 dígitos para um hyperscaler top-5 migrar completamente para fora de CUDA, com um cronograma de projeto de 2-3 anos. Isso se o destino está totalmente pronto, o que em ROCm tipicamente não está. É por isso que as compras AMD dos hyperscalers se concentram em workloads específicos onde o custo de migração já foi pago (inference para modelos OSS específicos, certas simulações HPC) em vez de em todo o board.

Quando a NVIDIA precifica H100/H200/B200 em 70-80% de margem bruta, eles estão precificando contra o custo de migração do outro lado, não contra o BOM per-chip da AMD. Enquanto o custo de migração ficar ao norte de "compre mais chips NVIDIA com preço premium", o moat se mantém.

O que está realmente estreitando o moat

O moat CUDA é real mas não eterno. Três coisas estão ativamente erodindo:

1. PyTorch 2.x e torch.compile. PyTorch é o framework no qual a maior parte do trabalho ML acontece. Historicamente PyTorch era apertadamente ligado ao CUDA via a camada de extensão C++. PyTorch 2.0 (lançado 2023) introduziu torch.compile, um compilador JIT que tem como target múltiplos backends (Inductor → Triton → CUDA, mas também → ROCm, também → IRs custom). A mudança arquitetural é que o usuário escreve PyTorch puro e o compilador emite código backend-specific. Conforme torch.compile amadurece e o backend Inductor fica battle-tested em ROCm e silício AMD, o lock-in framework-level no CUDA enfraquece. Esse é um processo de 2-4 anos.

2. vLLM e a padronização de inference. vLLM emergiu como o runtime de inference open-source de facto em 2023-2024 para serving de LLM. Ele suporta CUDA, ROCm, e ASICs custom via uma arquitetura de plugin. Conforme mais inference de hyperscaler se move para runtimes estilo vLLM (o que está acontecendo), o lado inference da dependência de framework do CUDA erode. Training ainda está travado em frameworks CUDA-first; inference é incrementalmente portátil.

3. Triton. OpenAI lançou Triton em 2021 como uma linguagem de kernel Python-embedded de mais alto nível. A promessa: escreva um kernel uma vez em Triton, compile para CUDA ou ROCm ou outros backends. Na prática o backend CUDA do Triton é excelente, o backend ROCm é real mas atrasa, e outros backends são experimentais. NVIDIA cooptou o Triton para dentro da stack CUDA (agora é um projeto CUDA-first apesar de ser nominalmente portável). Se Triton ficar multi-backend na prática, lock-in kernel-level enfraquece. Se a NVIDIA o capturar completamente, Triton vira mais uma biblioteca CUDA.

O efeito combinado: o custo de migração para um hyperscaler trocar a NVIDIA fora está caindo ~10-20% por ano numa base de mid-9 dígitos. O moat está corroendo do topo (camada de framework) para o fundo (camada de kernel). Lock-in da camada de biblioteca (cuDNN, NCCL) é o mais difícil de erodir — isso ainda está 5+ anos de paridade genuína.

O que isso significa para o bear case NVDA

O bear case tem três pernas tradicionais:

1. Competição de hardware — AMD e ASICs embarcam silício melhor, margens comprimem.
2. Concentração de clientes — top 5 clientes são ~50% da receita; um deles faz in-house e o múltiplo comprime.
3. Supply de HBM — oligopólio de memória coreano limita o ramp independente do order book da NVDA.

O moat CUDA defende diretamente contra a perna 1 e indiretamente atrasa o impacto da perna 2 (porque um ASIC in-house ainda precisa limpar o custo de migração CUDA, que é um projeto de 2-3 anos antes de poder substituir completamente o spend NVIDIA). Não faz nada quanto à perna 3 — veja a análise do bottleneck HBM e o dashboard da bolha memory para a dependência do lado supply que nenhum moat de software pode consertar.

Então o bear case acionável em NVDA não é "AMD vai alcançar" — essa tese esteve errada por três anos e o moat CUDA explica por quê. Os bear cases acionáveis são:

• Supply de HBM limita o ramp num nível menor do que o order book implica (real mas já parcialmente precificado)
• ASIC custom num único hyperscaler derruba o spend NVIDIA deles em 30%+ em 18 meses (Google fez isso com TPU para workloads internos; a questão é se Microsoft/AWS/Meta replicam em escala)
• Uma abstração real PyTorch-level vence e o custo de migração comprime abaixo do prêmio de chip que a NVIDIA cobra (timeline 2027-2029 se acontecer)

Três coisas para observar

O moat CUDA é a variável única mais importante na tese NVDA. Três sinais que significariam que está erodindo mais rápido do que precificado:

1. Dados de share de backend PyTorch. Telemetria anonimizada de PyTorch (que a Meta publica irregularmente) mostrando que fração de training de modelo está acontecendo em backends ROCm vs CUDA vs ASIC-custom. Se ROCm cruzar 10% do compute de training PyTorch, o moat está corroendo. Atualmente estimado abaixo de 3%.

2. Linguagem dos 10-Ks dos hyperscalers. Microsoft, Meta, Google, Amazon divulgam capex de IA mas raramente quebram share NVIDIA vs custom. Observe mudanças de linguagem em 10-Ks e earnings calls — "diversificando nosso substrato de compute IA" é o indicador líder. Quando dois dos top 4 dizem isso no mesmo trimestre, o moat está visivelmente erodindo.

3. Benchmarks AMD MI400 ou Instinct sucessor em modelos reais. Os benchmarks MI300X da AMD são ótimos em workloads sintéticos, menos ótimos no model zoo que hyperscalers realmente rodam. Se MI400 (esperado final de 2026) embarcar com uma história real de PyTorch — significando Meta, Microsoft, ou Anthropic publicarem papers training de modelos grandes nele em throughput near-NVIDIA — a tese bear em hardware finalmente tem dentes. Até hoje, nenhum tal paper existe.

Bottom line

CUDA não é uma biblioteca. São dezoito anos de investimento composto em compiladores, bibliotecas, frameworks, tooling, e as carreiras de cada engenheiro de plataforma ML no campo. AMD embarcou silício competitivo desde 2023 e capturou aproximadamente 10% do pool de receita de GPU de data-center — não porque os chips são ruins, mas porque o custo de migração CUDA → ROCm excede o diferencial de preço de chip em cada hyperscaler que de fato fez a conta.

O short certo em NVDA é supply-constrained (HBM, veja a bolha memory) ou customer-concentration-driven (ASIC custom num dos compradores top-5). O short errado — o que esteve errado por três anos — é "AMD vai alcançar em hardware". Em hardware eles alcançaram. No moat eles não alcançaram.

---

Dashboard NVDA ao vivo no QuantAbundancia — o painel de tese com technicals, fundamentals, e o mapeamento de bolha atuais.

As 12 bolhas de IA ranqueadas pela realidade empírica — a taxonomia que divide compute, memory, custom-silicon, e networking em blocos separados.

CXMT e a bolha DRAM — o lado supply de memory da restrição NVDA que o moat CUDA não pode consertar.