A Nvidia não ficou gigante só porque fez uma GPU rápida e mandou uma nota fiscal junto. Ela ficou gigante porque transformou um detalhe técnico em hábito cultural: a ideia de que “fazer IA de verdade” é, por definição, fazer IA em CUDA.
Isso é mais poderoso do que um chip. Um chip você troca quando aparece outro melhor. Um hábito você troca quando a dor de mudar fica menor do que a dor de continuar do mesmo jeito.
Durante anos, o mercado contou uma história confortável para explicar o domínio da Nvidia: “as GPUs são as mais avançadas”. Essa frase tem um pedaço de verdade, só que ela serve melhor como marketing do que como explicação. Se desempenho bruto fosse o único juiz, a coroa teria mudado de cabeça várias vezes. Houve gerações em que concorrentes ficaram perto, houve soluções mais baratas, houve momentos em que o custo por desempenho parecia tentador. Mesmo assim, quase ninguém fez a troca em massa.
Porque o trono da Nvidia não fica só no silício. O trono fica na camada onde as equipes gastam anos da vida: ferramentas, bibliotecas, kernels, rotinas de treino distribuído, perfiladores, receitas de otimização, tutoriais, exemplos, bugs conhecidos, jeitos de debugar, jeitos de contratar. Um ecossistema que vira padrão não precisa obrigar ninguém. Ele só precisa fazer o resto parecer trabalhoso.
E aí entra o que mudou, com o peso de um “clique” que desencaixa um império: Google e Meta estão mirando exatamente a peça que sustenta esse aprisionamento invisível, o software. Em dezembro de 2025, a Reuters noticiou que o Google está trabalhando num projeto interno chamado TorchTPU, com o objetivo de tornar as TPUs mais naturais para quem desenvolve em PyTorch, com colaboração próxima da Meta, grande apoiadora do PyTorch, e com possibilidade de abrir partes do software para acelerar adoção.
A ambição é simples de dizer e brutal de executar: permitir que empresas mudem de Nvidia para TPU sem precisar reescrever as partes críticas do código, sem desmontar o stack inteiro, sem abandonar PyTorch. Se essa fricção cair, a conversa deixa de ser “Nvidia ou caos” e vira “Nvidia ou concorrência”. A Nvidia pode continuar excelente e ainda assim perder a coisa que mais importa em mercados maduros: poder de barganha.
O lock-in que ninguém assina, mas todo mundo sente
Quando se fala em lock-in, muitos imaginam contrato, cláusula, exclusividade. No caso da Nvidia, a amarra é mais elegante, e por isso mais perigosa: ela se esconde no custo prático da mudança.
Uma equipe que diz “nosso modelo roda em PyTorch” geralmente quer dizer algo mais específico, mesmo que não verbalize: “nosso modelo foi escrito, treinado, ajustado, validado e colocado em produção num mundo em que CUDA era o chão”.
CUDA, na prática, virou o sistema nervoso periférico do stack de IA. Não é só “um jeito de rodar na GPU”. É um conjunto de escolhas acumuladas:
- bibliotecas de alto desempenho para operações essenciais,
- caminhos de precisão mista e quantização que foram refinados por anos,
- comunicação entre GPUs e entre nós de cluster, com soluções já testadas no inferno do tráfego real,
- profilers, ferramentas de debug, mecanismos de compilação, kernels otimizados e, talvez o mais importante, a “memória muscular” dos times.
Mudar isso não é trocar uma peça. É mexer na base do prédio enquanto tem gente morando dentro.
Por isso o lock-in da Nvidia sempre foi mais psicológico e operacional do que técnico. Em empresas, risco é uma moeda cruel. Risco de regressão, risco de instabilidade, risco de atraso, risco de gastar meses para descobrir que um detalhe do pipeline não tem equivalente. A conclusão prática era automática: ficar na Nvidia parecia racional, mesmo quando era caro.
E aqui tem um ponto curioso, quase irônico: a Nvidia nunca controlou o PyTorch. O PyTorch nasceu dentro da Meta e cresceu como projeto aberto, virando o framework dominante por mérito próprio, do laboratório à produção. O que a Nvidia fez, com genialidade de quem entende o jogo, foi se integrar tão bem que parecia dona.
Integração não é posse. Se o PyTorch ganhar um caminho “sem drama” para rodar bem fora de CUDA, a maior barreira de saída começa a virar poeira.
Por que “existem alternativas” nunca foi suficiente
“Mas já existem alternativas”, alguém sempre diz, e tecnicamente isso é verdade. AMD tem ROCm, Intel tem seus esforços, há aceleradores específicos, há chips especializados em inferência. Só que o mercado de IA em escala não premia apenas a existência de uma alternativa, ele premia uma alternativa que tenha três coisas ao mesmo tempo:
- performance competitiva em cargas relevantes,
- maturidade operacional, aquela sensação de “isso não vai me trair em produção”,
- compatibilidade com o jeito que o mundo já trabalha.
A maioria falha na terceira. Algumas falham na segunda. Várias falham nas duas.
A Nvidia virou o “default” porque fez o caminho parecer inevitável. Não por decreto, por conforto. Quando tudo funciona, quando os tutoriais batem com a realidade, quando a equipe encontra respostas, quando dá para contratar gente que já sabe o stack, a escolha vira hábito. E hábito é um tipo de monopólio emocional.
É por isso que a movimentação do Google assusta: ela não tenta vencer a Nvidia “na pancada” só com hardware. Ela tenta vencer no ponto onde o hábito se forma, a experiência do desenvolvedor.
TPUs: o problema nunca foi músculo, foi idioma
As TPUs do Google sempre carregaram um ar de “poder oculto”, aquele tipo de hardware que a gente ouve falar como se fosse uma arma interna, restrita, feita para as necessidades do próprio Google. A leitura confortável para a Nvidia era: “isso não importa para o mercado, porque ninguém fora do Google usa”.
Só que essa leitura era superficial. O próprio Google Cloud descreve TPUs como aceleradores desenhados para treinamento e inferência de modelos de IA, e elas já sustentam cargas gigantes dentro do ecossistema do Google. O que travava a adoção ampla não era falta de desempenho. Era o idioma de software.
Por muito tempo, o Google apostou com força em JAX e no universo de compilação ligado ao XLA. De novo, tecnicamente faz sentido. Só que o mercado não funciona como seminário de compiladores. Enquanto o Google empurrava um caminho mais “puro”, o resto do planeta consolidava outro caminho: PyTorch.
Para a maioria das empresas, adotar TPU significava adotar um jeito diferente de pensar, adaptar pipelines, revalidar tudo, treinar equipe, e no final ainda ficar com a sensação de estar fora do fluxo principal da indústria. Empresas não migram frameworks por hobby. Elas migram quando são empurradas por dor extrema ou quando a migração é suave.
O que o TorchTPU tenta fazer é inverter a lógica: em vez de pedir que o desenvolvedor se adapte ao hardware, o hardware passa a “se adaptar” ao desenvolvedor.
“Mas já existe PyTorch em TPU”, então qual é o drama?
Aqui entra uma camada importante, que separa “dá para rodar” de “dá para viver”.
O mundo já tem, faz tempo, o PyTorch/XLA, que conecta PyTorch a dispositivos XLA como TPUs. Isso está documentado oficialmente e existe como projeto público. E até em notas antigas do próprio Google Cloud aparece a ideia de suporte via integração PyTorch/XLA.
Então por que ainda existe espaço para um TorchTPU “novo”?
Porque “rodar” não significa “rodar do jeito que o desenvolvedor espera”. Na prática, muitas integrações desse tipo carregam pequenas fricções que, somadas, viram um pedágio enorme: diferenças de cobertura de operadores, comportamentos inesperados, caminhos mais frágeis para debug, diferenças no desempenho por tipo de modelo, desafios de distribuição, tooling menos maduro, e um detalhe que virou central no PyTorch moderno: a experiência eager, aquela sensação de que você escreve o código e ele responde na hora, com o mesmo modelo mental em todo lugar.
Em outubro de 2025, surgiu no próprio repositório do PyTorch/XLA uma proposta explícita para evoluir a experiência e chegar mais perto de algo “nativo”, com a ambição de fazer tensor.to('tpu') parecer tão natural quanto tensor.to('cuda'). Esse é o tipo de frase que parece pequena, até você perceber o que ela realmente significa: transformar TPU de “backend especial” em “cidadão de primeira classe” dentro do PyTorch.
E isso muda o jogo porque reduz a parte mais cara da migração, a parte humana: reaprender o mundo.
O que o TorchTPU realmente ameaça na Nvidia
O mercado gosta de imaginar batalhas de hardware como corrida de cavalos: quem tem mais FLOPS, quem tem mais memória, quem tem mais largura de banda. Só que a Nvidia construiu uma fortaleza onde o hardware é apenas a muralha visível. O fosso está no software, e o fosso é feito de custo de troca.
O TorchTPU, pelo que foi reportado, mira exatamente isso: tornar TPUs amigáveis para o maior framework do planeta, sem exigir que times mudem seu código nem abandonem PyTorch, com colaboração da Meta, e com possibilidade de abrir partes do stack para ganhar tração mais rápido. Essa ameaça não é “as GPUs vão morrer”. Essa ameaça é “as GPUs deixam de ser a única resposta sensata”.
Em mercados de infraestrutura, “única resposta sensata” é como se fabrica margem alta. Quando o cliente não tem alternativa viável, ele aceita preço, prazo, pacote completo, aceitação resignada. Quando aparece uma alternativa boa o suficiente, o cliente não precisa nem migrar para já mudar a conversa. Ele só precisa conseguir dizer, com credibilidade: “eu posso ir embora”.
A Nvidia, por anos, vendeu previsibilidade. “Seu código roda aqui, seu time sabe mexer aqui, seu risco é menor aqui.” Isso sustenta múltiplos altos porque vira uma espécie de seguro embutido. Só que seguro perde valor quando a apólice concorrente fica boa.
Por que a Meta muda o peso específico dessa história
Se esse movimento viesse só do Google, parte do mercado trataria como mais um capítulo do “Google tentando competir com Nvidia”. O Google tem histórico de projetos tecnicamente brilhantes que demoram a virar hábito fora da própria casa.
A Meta muda isso por três motivos. Primeiro, porque a Meta tem interesse econômico brutal em diversificar. O custo de treinamento e inferência em escala de rede social global é um monstro que nunca dorme. Depender de um único fornecedor, num mercado com filas, prazos e preços agressivos, é aceitar fragilidade estratégica. Segundo, porque a Meta é o berço do PyTorch e continua sendo uma força determinante na sua evolução. Quando a empresa que ajudou a criar o framework participa da portabilidade de forma ativa, a chance de isso virar padrão aumenta, porque não é um “plugin lateral”, é o coração do ecossistema se mexendo. Terceiro, porque isso cria efeito cascata. Quando o criador do framework dá sinais de que múltiplos backends importam, ferramentas ao redor se adaptam, bibliotecas seguem, integradores entram, provedores oferecem suporte, e a profecia começa a se autorrealizar.
Esse ponto conversa com outra peça do tabuleiro: não é só software. O Google também tem buscado expandir o negócio de TPUs para fora do seu “jardim murado”, com reportagens indicando oferta de TPUs para uso em data centers de clientes e interesse de grandes compradores. Quando você junta “hardware disponível” com “experiência de PyTorch mais nativa”, o obstáculo deixa de ser filosófico e vira operacional, e isso é o tipo de coisa que compras e infraestrutura entendem muito bem.
O que muda quando “sair” deixa de ser impensável
Aqui é onde o mercado às vezes erra o foco. O preço da ação pode reagir pouco no começo porque o mundo ama narrativas simples, e a narrativa simples é: “Nvidia continua líder, ponto”. Só que a ameaça verdadeira costuma ser lenta, silenciosa e burocrática. Ela nasce em comitê de arquitetura, em prova de conceito, em planilha de custo por inferência.
Quando existe alternativa real, acontecem mudanças bem específicas:
- Negociação: o cliente passa a negociar preço e condições com mais força, mesmo sem trocar nada no curto prazo.
- Planejamento: times começam a desenhar pipelines com portabilidade em mente, para não serem reféns.
- Padronização: ferramentas passam a assumir múltiplos backends como normal, e isso reduz a vantagem do “default histórico”.
- Margem: margens caem antes da participação de mercado cair, porque o poder de precificação é o primeiro a sofrer.
A Nvidia não precisa perder o trono para perder poder. Ela só precisa deixar de ser inevitável.
A parte difícil que quase todo mundo subestima
A história seria fácil se bastasse “rodar PyTorch na TPU” e pronto. Não é assim. Construir paridade prática com CUDA em ambientes corporativos é o tipo de trabalho ingrato que exige anos de engenharia, testes e acertos finos. A própria existência de discussões públicas sobre tornar o backend mais “nativo” mostra que ainda há estrada pela frente.
Alguns desafios que costumam aparecer nesse tipo de migração, mesmo quando o código do modelo não muda:
- cobertura completa de operadores e casos de borda,
- estabilidade e previsibilidade em produção, com observabilidade madura,
- desempenho consistente em modelos variados, não só em benchmarks “favoráveis”,
- suporte a treinamento distribuído e inferência em escala com ergonomia de engenharia,
- ecossistema ao redor, como quantização, kernels customizados, serving, compilação, profiling.
O detalhe é que essa lista não precisa ficar perfeita para ameaçar o lock-in. Ela precisa ficar boa o suficiente em um subconjunto valioso, por exemplo, inferência massiva de modelos populares, ou treinamento de certas famílias de arquitetura. Em infraestrutura, atacar um pedaço muito caro do custo já é suficiente para criar “saídas” na fortaleza.
E a Nvidia, fica parada?
Seria estranho imaginar a Nvidia olhando isso de braços cruzados. Ela tem recursos, talento e uma vantagem real: maturidade de ecossistema, ferramental e rede de parceiros.
O que tende a acontecer, como dinâmica de mercado, é uma corrida em duas frentes:
- A Nvidia reforça o valor do seu ecossistema, com melhores ferramentas, melhor performance, melhores bibliotecas, mais integração com frameworks, mais facilidades que façam o custo de ficar parecer ainda menor.
- O resto do mercado tenta reduzir o custo de sair, criando caminhos compatíveis, “nativos”, que façam a troca parecer só uma decisão de infraestrutura.
O segundo ponto é exatamente o que torna TorchTPU interessante, e por que a participação da Meta é um multiplicador, não um detalhe.
O cenário mais plausível, se essa peça encaixar
Em vez de imaginar um “colapso” da Nvidia, a visão mais realista é um deslocamento gradual do centro de gravidade:
- no começo, TPUs viram alternativa crível para alguns workloads, principalmente onde custo por inferência pesa mais que qualquer outra coisa,
- depois, empresas começam a adotar postura multi fornecedor, mesmo mantendo Nvidia como base,
- com o tempo, a pressão competitiva aparece em preços, prazos e contratos, antes de aparecer em manchetes dramáticas.
Esse é o tipo de mudança que, vista de perto, parece lenta. Vista de longe, parece inevitável.
Uma última observação, que vale ouro para não cair em torcida: nada disso é destino. É uma hipótese de engenharia e mercado. Se o TorchTPU virar uma integração meia boca, se a experiência continuar “especial”, se o desempenho for inconsistente, se o suporte corporativo for frágil, a Nvidia segue com o fosso cheio de crocodilos. Se o TorchTPU entregar uma experiência realmente banal, previsível e eficiente, aquela palavra que sustenta impérios, inevitável, começa a perder o sentido.
Referências
Exclusive: Google works to erode Nvidia's software advantage with Meta's help https://www.reuters.com/business/google-works-erode-nvidias-software-advantage-with-metas-help-2025-12-17/
Cloud Tensor Processing Units (Cloud TPUs) https://cloud.google.com/tpu
PyTorch/XLA https://github.com/pytorch/xla
Evolving PyTorch/XLA for a more native experience on TPU https://github.com/pytorch/xla/issues/9684
Cloud TPU release notes https://docs.cloud.google.com/tpu/docs/release-notes
Meta and Google could be about to sign a mega AI chip deal - and it could change everything in the tech space https://www.techradar.com/pro/meta-and-google-could-be-about-to-sign-a-mega-ai-chip-deal-and-it-could-change-everything-in-the-tech-space
0 comments:
Postar um comentário