Chips ARM personalizados estão corroendo a hegemonia do x86 nos data centers em nuvem.

Por duas décadas, "servidor" significava x86 — um chip da Intel ou AMD, rodando o mesmo conjunto de instruções seja em um data center de banco ou no rack de uma startup em uma instalação de colocation. Essa premissa está se desfazendo dentro dos três maiores provedores de cloud. AWS, Google Cloud e Microsoft Azure passaram cada um os últimos anos projetando seus próprios CPUs de servidor baseados em Arm, e em meados de 2026 esses chips respondem por uma parcela grande o suficiente da nova capacidade de computação dos hyperscalers que o x86 não é mais o padrão automático que costumava ser.

Os números por trás da mudança

A penetração do Arm nos embarques de CPU para servidores subiu de cerca de 5% em 2020 para algo entre 15% e 23% em 2025, de acordo com analistas de semicondutores que acompanham a categoria. O dado mais impactante veio das sessões do Computex 2026: pesquisas apresentadas lá colocaram os chips baseados em Arm em quase metade da capacidade de computação dos hyperscalers — não em quantidade de embarques, mas em capacidade efetivamente implantada na AWS, Google e Microsoft em conjunto. O próprio mercado de servidores baseados em Arm cresceu de aproximadamente US$ 5,8 bilhões em 2023 para uma estimativa de US$ 8,2 bilhões em 2026.

Esse crescimento não veio às custas da AMD, curiosamente. As estimativas de crescimento de embarques de CPU para servidor da AMD foram revisadas para cima, de 14% para 23% em 2026, e a própria projeção da Intel passou de uma queda de 3% para um crescimento de 3%. O mercado está crescendo rápido o suficiente para que os ganhos do Arm e os ganhos da AMD aconteçam ao mesmo tempo — é a participação legada do x86 da Intel, e não a arquitetura x86 de forma ampla, que está perdendo mais terreno.

Três chips, três apostas diferentes

A AWS foi mais longe primeiro. O Graviton5, disponível para o público geral desde 10 de junho de 2026, empacota 192 cores Arm Neoverse V3 distribuídos em quatro chiplets fabricados no processo de 3nm da TSMC, com 192MB de cache L3, memória DDR5 e PCIe Gen 6 — um aumento de cinco vezes no cache em relação ao Graviton4 e uma melhoria de desempenho declarada de 25%. A AWS o construiu explicitamente para as cargas de trabalho da "era da IA agêntica": serving de inferência, pipelines de recuperação e os padrões de requisição bursty e com alto consumo de memória que agentes de IA geram, em vez da computação clássica em lotes.

O Google Axion adota um ângulo diferente, posicionado como a metade de CPU de um par combinado com os racks de TPU v8 do Google. O Google afirma que o Axion entrega desempenho 30% superior ao de instâncias Arm concorrentes na cloud e 60% mais eficiência energética do que instâncias x86 comparáveis — eficiência sendo a palavra-chave, já que o papel do Axion é em grande medida alimentar dados para dentro e para fora dos TPUs sem se tornar o gargalo de energia ou térmico nesse pipeline.

O Cobalt da Microsoft é o mais discreto dos três, mas sem dúvida o mais testado em produção neste momento: está executando cargas de trabalho reais nas regiões do Azure hoje, com clientes como a Databricks rodando plataformas de dados em produção nele, e não apenas implantações piloto. Ao contrário do Graviton e do Axion, que abraçam um posicionamento voltado à IA, a Microsoft comercializou o Cobalt de forma mais direta como uma opção de custo e eficiência de uso geral para a computação comum do Azure.

Por que os hyperscalers controlam seu próprio silicon agora

Projetar um CPU de servidor do zero não foi uma decisão que os provedores de cloud tomaram de forma leviana — ela exige anos de investimento em engenharia de chips que a maioria das empresas de software jamais toca. O retorno é o controle sobre uma variável que antes ficava inteiramente com os roadmaps de produtos da Intel e da AMD: desempenho por watt na escala de data center. A energia é agora a restrição fundamental sobre a quantidade de capacidade de computação que um hyperscaler pode fisicamente implantar, dados os limites de interconexão com a rede elétrica e o enorme consumo de energia dos clusters de treinamento e inferência de IA. Um CPU projetado internamente pode ser ajustado especificamente para a combinação de cargas de trabalho que aquele provedor efetivamente executa, em vez do perfil de uso geral que um fabricante de chips merchant precisa almejar para atender a todos.

É também por isso que o Grace CPU da Nvidia — um chip baseado em Arm construído para ficar diretamente ao lado das GPUs da Nvidia na mesma placa — importa aqui também, mesmo que a Nvidia não seja um provedor de cloud. É a evidência mais clara de que a vantagem do Arm neste ciclo não tem a ver de verdade com os custos de licenciamento do conjunto de instruções; ela tem a ver com qual arquitetura permite que um designer de chips construa a combinação exata de CPU-memória-interconexão que seu acelerador ou carga de trabalho específico precisa, em vez de comprar o que a Intel ou a AMD entregou naquele ano.

O que isso significa para AMD, Intel e fornecedores independentes de Arm

A aceleração do crescimento em servidores da AMD sugere que ela capturou participação da Intel em vez de perder terreno para o Arm — o EPYC continua sendo a escolha padrão de x86 merchant para cargas de trabalho que não são executadas por um hyperscaler com seu próprio programa de silicon. O retorno ao crescimento positivo da Intel é uma vitória menor, mas real, após anos de erosão de participação em servidores. A empresa deixada de fora da tendência de silicon cativo dos hyperscalers é a Ampere Computing, a designer independente de chips Arm para servidor cujos processadores AmpereOne competem diretamente com o Graviton e o Axion pelos clientes que não querem construir seu próprio chip — provedores de cloud abaixo dos três primeiros e empresas que executam cargas de trabalho Arm em colocation em vez de clouds de hyperscalers.

O que isso significa para quem está escolhendo onde rodar cargas de trabalho

Para equipes de engenharia que avaliam tipos de instância na cloud, a questão prática mudou de "o Arm já é maduro o suficiente" para "quais cargas de trabalho devem migrar primeiro". Serviços sem estado e com escalonamento horizontal — camadas web, API gateways, serving de inferência — tendem a apresentar os ganhos mais claros de custo-desempenho em instâncias Graviton ou Axion, frequentemente com custo 20% a 40% menor para throughput equivalente, desde que seu pipeline de build já produza binários Arm64 ou seu runtime de linguagem abstraia a diferença (Go, Java e a maioria das linguagens interpretadas migram com mudanças mínimas; bases de código C/C++ com intrínsecos específicos de arquitetura exigem trabalho real de portabilidade). Os chips que antes eram uma otimização de custo de nicho para uma parcela das cargas de trabalho são agora o padrão no qual a AWS, o Google e a Microsoft querem que a nova capacidade seja executada — o que significa que fazer benchmark da sua própria carga de trabalho em instâncias Arm não é mais uma diligência opcional, é recuperar o atraso em relação ao ponto onde a infraestrutura já está.