NVIDIA vs ASICs custom — o que TPU, Trainium, e MTIA realmente fazem (e por que a maioria deles mira inference, não training)

O bull case em $NVDA é "CUDA defende". O bear case é "ASICs custom comem". Ambos estão certos em camadas diferentes da stack. ASICs custom estão comendo share — em workloads específicos, em padrões de deployment específicos, com perfis econômicos específicos. Eles não estão (ainda) comendo a parte do workload IA que dirige o order book da $NVDA.

Entender qual é qual requer desembrulhar o que cada programa major de ASIC custom realmente faz. A maioria das takes publicadas de trader agrupa os quatro juntos como "silício custom" e trata a categoria como um competidor único. A categoria é heterogênea: TPU e Trainium-the-flagship são training-and-inference dual-purpose, MTIA e Maia e Inferentia e o resto da família Trainium são inference-targeted. A distinção é onde o bear case tem dentes e onde não tem.

Este artigo mapeia cada programa major, contra qual workload está realmente deployed, e como ler as divulgações.

Por que training é diferente de inference

O primeiro passo em qualquer avaliação de silício custom é dividir compute de IA em dois regimes:

Training — runs em larga escala, multi-semana, multi-bilhão de dólares em clusters de milhares de GPUs. O workload é dinâmico (loss landscape muda, hiperparâmetros são tunados, o mix de kernel muda conforme o modelo converge), a arquitetura do modelo está evoluindo (novas variantes de attention, novos otimizadores, novas funções de ativação são tentados semanalmente em labs de fronteira), e os modos de falha são sutis (um único bit-flip num gradient de parâmetro pode corromper o run). A stack de software precisa ser flexível, debugável, e extensível. É onde a stack de bibliotecas CUDA — cuDNN, NCCL, o tooling de kernel — vem compondo há 15 anos. Silício custom para training é difícil porque o substrato tem que acompanhar um target em movimento.

Inference — serving de produção de modelos treinados. O workload é estático (a arquitetura do modelo está congelada, os pesos são carregados uma vez), os kernels são conhecidos antecipadamente (você otimiza uma vez, faz deploy pela vida útil de serving do modelo), e o target de otimização de custo é throughput-per-watt e latência-per-token. É onde silício custom tem o caso econômico mais forte — um modelo de arquitetura fixa rodando 24/7 não precisa da flexibilidade CUDA completa; precisa do silício mais barato possível que rode essa forma específica de computação eficientemente.

A matemática econômica:

• Spend em training num hyperscaler é ~25-30% do capex de compute IA
• Spend em inference é ~70-75%, crescendo conforme a contagem de modelos deployed cresce
• Silício custom em sua maioria mira o pool de inference maior e mais fácil de atacar

É por isso que "silício custom hyperscaler" precisa ser lido no nível de workload, não no nível de programa.

Google TPU — a história de sucesso em training

Google começou desenvolvimento de TPU em 2013, fez deploy de TPU v1 internamente em 2015, e o anunciou publicamente em 2016 com um paper no ISCA. A arquitetura do sistema é um engine matmul de systolic-array com o agora-icônico interconnect chip-mesh, otimizado primeiro para inference (TPU v1, v2) depois para training-and-inference (v3 em diante).

TPU v5e embarcou 2024. Ironwood (TPU v7) embarcou 2025. Cada geração expandiu:

• Paridade de training em escala. Training runs de modelo de fronteira (Gemini, Claude da Anthropic no pool TPU do Google anunciado em 2024) em TPU em throughput near-NVIDIA. A combinação compilador XLA + JAX virou uma alternativa crível ao PyTorch + CUDA para novos projetos de training.
• Dominância em inference para os próprios workloads do Google. Ranking de search, predição de click-through de ads, recomendação YouTube, todos rodam em TPU em escala de produção.
• Disponibilidade externa em cloud. TPU é vendido no Google Cloud em pricing competitivo vs instâncias NVIDIA em workloads equivalentes.

Por que TPU teve sucesso onde outros têm lutado:

1. Tempo. 10+ anos de investimento composto na stack de software (XLA, JAX, orquestração Pathways).
2. Co-design apertado modelo-substrato. As equipes de pesquisa do Google embarcam modelos que funcionam porque são co-designed com as forças do TPU (grandes tiles de matmul, sparsity hardware-supported, o interconnect chip-mesh).
3. Cliente interno captive. A equipe de plataforma ML do próprio Google é o primeiro cliente. Eles não têm razão política para preferir NVIDIA sobre TPU. O pull interno valida o substrato antes de clientes externos verem.

O resultado: o spend NVIDIA interno do Google é materialmente menor (como fração de compute interno) que o spend NVIDIA dos outros top-4 hyperscalers. TPU é a prova de existência de que um hyperscaler pode fazer in-house full-stack. É o canário para o risco de concentração de clientes em NVDA.

AWS Trainium e Inferentia — o jogo inference-first

AWS começou com Inferentia em 2019 — um chip pure-inference otimizado para modelos estilo transformer em latência baixa e price/perf competitivo. Inferentia 2 (2023) estendeu a arquitetura. AWS usa Inferentia pesadamente para workloads de inference internos (Alexa, Rekognition, Comprehend, o serviço gerenciado de LLM Bedrock) e oferece instâncias EC2 Inf1/Inf2 para clientes externos.

Trainium lançou 2020 como o counterpart de training. A primeira geração atrasou materialmente a NVIDIA em throughput de training; Trainium2 (2024) fechou muito do gap em workloads específicos. Anthropic anunciou um compromisso major de capacidade Trainium2 em 2024 — o segundo lab de fronteira (depois da parceria Google TPU/Anthropic) a se comprometer com silício de training não-NVIDIA em escala material.

O posicionamento estratégico:

• AWS otimiza Inferentia para workloads internos AWS (alto volume, formas de modelo fixas, latency-sensitive).
• Trainium mira workloads de training de clientes externos onde a vantagem price/perf é grande o suficiente para superar a curva de aprendizado da stack de software. O compromisso da Anthropic é o proof point.
• O Neuron SDK + a integração PyTorch AWS é o esforço de stack de software. Está atrás do CUDA mas à frente de toda alternativa não-Google.

Impacto de concentração em NVDA:

• Spend de inference interno AWS é a linha mais NVDA-vulnerável. Inferentia já está absorvendo.
• Spend de training interno AWS é parcialmente NVDA-vulnerável dependendo do ramp Trainium2 e timing Trainium3.
• Spend NVIDIA de cliente AWS Cloud (instâncias EC2 P-series e G-series) é a parte que cresce com demanda de IA e está estruturalmente protegida — clientes externos escolhem NVIDIA porque já construíram em CUDA.

O efeito líquido na receita NVDA da AWS ao longo de 2026-2028: provavelmente flat-to-down em share interno, up em demanda customer-cloud. O agregado é workload-mix-dependent e apenas parcialmente sob controle da AWS.

Meta MTIA — o programa de catch-up

Meta lançou MTIA (Meta Training and Inference Accelerator) v1 em 2023, originalmente inference-focused. MTIA v2 (2024-2025) mirou inference em larger-scale para os modelos internos de ad-ranking e content-recommendation da Meta — workloads que consomem enorme compute em formas de modelo conhecidas, exatamente o sweet spot de inference.

Meta disse explicitamente em earnings calls que MTIA não vai (inicialmente) substituir NVIDIA para training de modelo de fronteira. A série Llama — a família LLM de fronteira da Meta — treinou em NVIDIA H100s e B200s até 2025. O mandato do MTIA é o workload de recomendação e ad-stack, que é o share maior do spend de compute da Meta mas mais baixo-perfil externamente.

A ameaça competitiva à NVDA do MTIA:

• Curto-prazo (2025-2026): material; Meta está plausivelmente absorvendo 20-30% do seu compute de inference interno em MTIA, o que desloca diretamente spend NVIDIA naquele workload.
• Médio-prazo (2027-2028): desconhecido; depende de se MTIA v3 alcança paridade de training, o que Meta não se comprometeu publicamente. O substrato de training Llama 4 / Llama 5 é o sinal canônico.
• Longo-prazo (2029+): se Meta seguir o caminho do Google, MTIA vira uma redução estrutural no TAM NVDA na Meta. Se eles fazem depende de política interna da Meta e alocação de capex que é difícil de prever.

A análise de concentração de hyperscaler enquadra Meta como o segundo-mais-provável hyperscaler (depois do Google) a alcançar "maioria interno em silício custom" dado o tamanho e perfil econômico do seu workload.

Microsoft Maia — a última entrante

Microsoft anunciou Maia 100 em 2023 e embarcou em 2024-2025. A arquitetura é purpose-built para inference de transformer em larga escala, com posicionamento explícito em torno do workload Azure OpenAI-partner (ChatGPT e serving de modelo downstream).

Maia é o mais jovem dos quatro programas e o menos maduro em stack de software. Microsoft não (em meados de 2026) divulgou publicamente capacidade Maia como percentagem de compute IA Azure. A leitura direcional de fontes da indústria: Maia está absorvendo algum workload de inference interno Azure mas Microsoft permanece pesadamente NVIDIA-dependente tanto para training (a parceria OpenAI roda em NVIDIA Blackwell em escala) quanto para a maioria de inference de cliente.

A posição da Microsoft é estruturalmente diferente da Meta ou da Amazon:

• A parceria OpenAI é um compromisso de capacidade multi-ano para workloads específicos de training e inference de modelo de fronteira, principalmente em NVIDIA.
• O workload de IA de cliente do Azure está pesadamente NVIDIA-defaulted porque a proposta de venda do Azure inclui "você pode treinar no mesmo substrato que já construiu" (NVIDIA + CUDA).
• O caminho do Maia para share material é o workload Microsoft-interno apenas — inference Office Copilot, Bing AI, features Microsoft 365 AI. Esse é um substancial mas não majoritário do spend de compute IA da Microsoft.

Leitura líquida: Microsoft é a mais lenta-movimentando dos quatro hyperscalers em silício custom, o que faz Microsoft estruturalmente NVDA-bullish para o médio prazo. O cenário bear para NVDA na Microsoft requer Maia v2 ou v3 rampar significativamente em 2027-2028, e Microsoft não sinalizou publicamente esse timeline.

Onde isso deixa a tese NVDA

Os quatro programas hyperscaler de silício custom, ordenados por ameaça competitiva à NVDA:

| Rank | Programa | Status | Impacto NVDA 2026-2028 | |------|---------|--------|----------------------| | 1 | Google TPU | Maduro, training + inference | Material; spend NVDA interno do Google já estruturalmente reduzido | | 2 | AWS Trainium/Inferentia | Inference maduro, training rampando | Material em inference, parcial em training (ramp Trainium2) | | 3 | Meta MTIA | Inference escalando, training TBD | Share de inference ativo; training neutro até 2027 | | 4 | Microsoft Maia | Inference, estágio inicial | Limitado; parceria OpenAI mantém spend NVDA alto |

Oracle não tem programa de silício custom e permanece estruturalmente long NVDA tanto em training quanto inference.

Uma forma limpa de ler a paisagem: o TAM NVDA nos top-4 hyperscalers está bifurcando. O share de training — protegido pelo moat CUDA — fica em sua maioria NVDA. O share de inference é mais furado e está sendo ativamente absorvido por silício custom, especialmente no Google e AWS. Meta está mid-cycle. Microsoft está atrasada.

Três sinais que forçariam uma revisão de tese

1. Um segundo hyperscaler embarca um paper de training de modelo de fronteira em silício custom. Anthropic no TPU foi o primeiro (2024). Se um segundo lab publicar equivalente em Trainium, MTIA, ou Maia até 2027, a tese "CUDA defende training" enfraquece. Observe papers acadêmicos da Anthropic-em-Trainium2, Llama-X-em-MTIA, ou qualquer lab de fronteira em Microsoft Maia.

2. Telemetria de backend PyTorch muda. Dados de share de backend PyTorch publicados pela Meta (raramente divulgados) mostrando acima de 5% do compute de training PyTorch em backends não-CUDA. Atualmente estimado abaixo de 3%.

3. Mix de receita "compute" vs "networking" da NVDA. NVDA divulga o split a cada trimestre. Se o share de compute começar a comprimir enquanto networking cresce (porque clientes continuam comprando fabric Mellanox/InfiniBand para os próprios clusters ASIC), esse é o sinal cedo de que o substrato do cliente está mudando para longe de GPUs NVDA enquanto networking NVDA permanece o fabric default.

Bottom line

ASICs custom são competidores reais para NVDA, mas a superfície competitiva é inference-first para três dos quatro programas. Training — o workload mais CUDA-dependent — permanece estruturalmente NVDA. TPU é a exceção que prova a regra: Google demonstrou que a migração é possível dado uma década de investimento composto em software, e o playbook implícito está sendo seguido em profundidades variadas pela AWS, Meta, e Microsoft.

A leitura da tese: long NVDA em receita de training e o moat CUDA; bearish em trajetória de margem conforme inference muda para silício custom nos top-4 hyperscalers. Líquido: uma compressão de múltiplo multi-ano em vez de um declínio step-function. A restrição do lado supply limita o ramp independente. A concentração de clientes é a variável que determina onde naquela banda a ação imprime.

---

Dashboard NVDA no QuantAbundancia — painel de tese com marcas atuais.

O moat CUDA — o ecossistema de software que defende training mas vaza em inference.

O bottleneck HBM da NVIDIA — o teto do lado supply que gateia o ramp independente da composição de clientes.

Concentração de clientes hyperscaler — o risco de concentração do lado demanda que ASICs custom são designed para explorar.