ARM Agora Alimenta Metade da Nuvem: Graviton 4, Ampere Altra Max e os Números por Trás do Recuo do x86

A Mudança Não É Mais Teórica

Durante boa parte da última década, ARM no ambiente de servidores era uma promessa — sempre a dois anos de estar pronta para produção. Esse tempo passou. A AWS relata que suas instâncias baseadas em Graviton já alimentam uma parcela substancial e crescente de sua frota de computação. Os chips Altra Max da Ampere rodam workloads de produção na Oracle Cloud, Microsoft Azure e Google Cloud. O Grace CPU da NVIDIA está sendo entregue em Grace Hopper Superchips implantados em clusters de IA ao redor do mundo. A pergunta não é mais se ARM consegue lidar com workloads de servidor. A pergunta é quais workloads ainda justificam pagar o prêmio do x86.

A tese central é simples e respaldada por números: chips ARM para servidores entregam mais throughput por watt e mais throughput por dólar do que seus equivalentes x86 nos workloads que dominam os gastos modernos em nuvem — web serving, microserviços em containers, caching em memória e inferência de Machine Learning. O x86 mantém vantagens reais em software legado single-threaded, workloads do Windows Server e aplicações com dependências rígidas em extensões do ISA x86. Todo o restante é uma conversa sobre migração.

AWS Graviton 4: O Benchmark Que Mudou a Conversa

O AWS Graviton 4, lançado no final de 2023 e que alimenta as famílias de instâncias R8g, C8g e M8g, é construído sobre um core ARM Neoverse V2 customizado em processo TSMC de 3nm. O chip vem com 96 cores, suporte a memória DDR5-5600 e um cache de nível de sistema de 75 MB. A AWS afirma que o Graviton 4 entrega até 30% mais desempenho de computação em relação ao Graviton 3, e até 40% mais desempenho por watt em comparação com instâncias x86 equivalentes em sua própria frota.

No SPECrate2017_int_base, testes independentes de instâncias Graviton 4 pontuam na faixa de 650–700 no agregado de todos os cores, competitivo com o Intel Xeon Sapphire Rapids em faixas de preço similares, consumindo menos energia no nível da instância. Para workloads baseados em Java — uma fatia importante dos gastos corporativos em nuvem — o Graviton 4 marca cerca de 20–25% mais throughput no SPECjbb2015 do que o Graviton 3, que por si só já superava instâncias Intel comparáveis nesse benchmark.

O argumento de preço é direto. Uma AWS m8g.4xlarge (16 vCPU, Graviton 4) custa aproximadamente $0,616/hora sob demanda em us-east-1. Uma m7i.4xlarge comparável (16 vCPU, Intel Sapphire Rapids) custa aproximadamente $0,806/hora. Isso representa uma redução de 24% no custo antes mesmo de considerar que a instância ARM frequentemente lida com maior throughput de requisições por vCPU em workloads stateless.

Ampere Altra Max: 128 Cores, Previsibilidade Single-Threaded

O Altra Max da Ampere Computing é arquiteturalmente diferente do Graviton 4 de forma deliberada. Enquanto a AWS usa um design de core de alto desempenho derivado do Neoverse V2, a Ampere usa seus próprios cores single-threaded — sem simultaneous multithreading (SMT). O Altra Max vem com até 128 cores, cada um rodando a até 3,0 GHz, com 128 MB de cache L3 e memória DDR4-3200 de 8 canais. O TDP fica em 250–270W para a variante de 128 cores.

A ausência de SMT é uma escolha de design com consequências reais. Provedores de nuvem que usam Altra Max podem anunciar vCPUs com mapeamento 1:1 para cores físicos, eliminando a variância de noisy-neighbor que assola instâncias x86 com SMT sob carga mista. A Oracle Cloud Infrastructure usa instâncias Ampere A1 (Altra de geração anterior) a $0,01/OCPU-hora, tornando-a a opção de computação mais barata de qualquer grande provedor de nuvem. Resultados de benchmark do Phoronix em nós Altra Max mostram escalonamento linear até 128 threads em workloads embaraçosamente paralelos — algo que chips x86 com SMT deixam de entregar de forma limpa além da contagem de cores físicos.

A lista de workloads-alvo da Ampere lê como um catálogo de infraestrutura moderna: NGINX, HAProxy, Redis, Memcached, PostgreSQL com workloads de leitura intensiva e microserviços em containers no Kubernetes. Para equipes que rodam essas stacks, instâncias Altra Max reduzem mensuralmente o custo por requisição.

NVIDIA Grace: ARM Encontra HBM3 para Workloads de IA

O Grace CPU da NVIDIA, usado nas configurações Grace Hopper e Grace Blackwell Superchip, é um design ARM Neoverse V2 de 72 cores conectado via NVLink-C2C às GPUs NVIDIA. O Grace CPU em si tem uma figura de 500 GB/s de bandwidth de memória usando LPDDR5X, o que ultrapassa em muito o que canais DDR5 convencionais entregam em plataformas de servidor x86.

No GH200 Grace Hopper Superchip, a CPU e a GPU H100 compartilham um fabric de memória unificado a 900 GB/s entre elas. Isso não é uma afirmação de marketing — elimina o gargalo do PCIe que limita a utilização da GPU em workloads de inferência de LLM onde o modelo precisa mover dados frequentemente entre a memória da CPU e da GPU. Para inferência de Large Language Models e modelos multimodais, o GH200 entrega tokens-por-segundo por dólar mensuralmente maiores do que configurações equivalentes com H100 SXM5 usando CPUs host x86, principalmente por reduzir a latência de transferência de dados.

Apple M4 Ultra no Mac Pro: ARM no Nível das Workstations Profissionais

O M4 Ultra da Apple, anunciado para o Mac Pro 2025, combina dois dies M4 Max via interconexão UltraFusion, produzindo um chip com até 80 cores de CPU (60 de desempenho, 20 de eficiência), até 80 cores de GPU e uma arquitetura de memória unificada com suporte a até 192 GB a mais de 800 GB/s de bandwidth agregado. O TDP do sistema M4 Ultra fica em torno de 300W de potência total do sistema, comparável ao consumo de um único die Intel Xeon W de alto desempenho.

O Mac Pro não é um servidor em nuvem, mas seus benchmarks informam diretamente o debate sobre servidores. No Cinebench R24 nT, o M4 Ultra pontua aproximadamente 9.000–9.500 pontos no multi-core — comparável a um Threadripper 7970X com aproximadamente o dobro do consumo de energia. Desenvolvedores que constroem e testam aplicações em containers nativas para ARM em Mac Pros com M4 Ultra já rodam workloads equivalentes aos de produção localmente antes de implantar no Graviton 4 ou Altra Max em produção. O alinhamento do ecossistema de software está fechando rapidamente.

As Vantagens Arquiteturais do ARM para Workloads de Servidor

As razões pelas quais o ARM vence em eficiência são estruturais, não temporárias. O ISA ARM gera footprints de instrução menores que o x86, reduzindo a pressão no instruction cache. A ausência do legado x87 e da lógica complexa de decodificação de comprimento variável significa que mais área de cada die vai para unidades de execução e cache. Cores modernos de servidor ARM como Neoverse V2 e Neoverse N2 implementam execução out-of-order com pipelines largos que igualam ou superam o Golden Cove da Intel e o Zen 4 da AMD em throughput por clock para workloads de inteiro e com uso intensivo de memória.

Os números de eficiência energética são consistentes em testes independentes. Resultados do SPECpower_ssj2008 — que medem desempenho por watt em diferentes níveis de carga — mostram plataformas de servidor ARM da AWS, Ampere e NVIDIA rodando 15–40% mais eficientes do que equivalentes x86, dependendo do workload e do nível de carga. Na escala de um data center, essa diferença é medida em megawatts e milhões de dólares anualmente.

Onde o x86 Ainda Vence

A honestidade exige reconhecer onde o x86 mantém vantagem:

• Workloads do Windows Server — a AWS não oferece instâncias Graviton com Windows; as instâncias Azure Cobalt 100 ARM rodam apenas Linux até 2024. SQL Server e .NET Framework (não .NET Core) permanecem dependentes do x86 na prática.
• Aplicações legadas single-threaded — AMD EPYC Genoa e Intel Sapphire Rapids atingem clocks de boost single-core mais altos (até 4,5 GHz) do que os atuais chips ARM para servidor, o que importa para workloads serializados.
• Workloads dependentes de AVX-512 — códigos HPC e alguns Pipelines de transcodificação de vídeo são otimizados manualmente para as extensões SIMD AVX-512 da Intel. O SVE2 do ARM é competitivo, mas exige recompilação e reajuste.
• Software ISV com licenciamento exclusivo para x86 — Oracle Database, SAP HANA e várias ferramentas comerciais de EDA ou não suportam ARM ou têm termos de licença separados que eliminam o benefício de custo.

Conclusões Práticas para Engenheiros Escolhendo Instâncias em Nuvem

• Comece sua migração para ARM com workloads HTTP stateless primeiro. NGINX, Node.js, Go e APIs Python em containers compilam de forma limpa para ARM64 e mostram o retorno mais rápido. Use instâncias AWS C8g ou OCI Ampere A1 e realize um teste de carga A/B em relação ao seu baseline x86 atual antes de confirmar.
• Para serviços Java, adote o Graviton 4 agressivamente. A JVM suporta ARM64 há anos. Os próprios benchmarks da AWS mostram ganhos de 20–30% de throughput em workloads Spring Boot e Quarkus no Graviton 4 versus instâncias Intel equivalentes a custo menor.
• Para inferência de IA em escala, avalie o GH200 antes de recorrer ao padrão H100 + x86. A arquitetura de memória unificada elimina um gargalo real para modelos acima de 70B parâmetros. Solicite acesso via AWS, CoreWeave ou NVIDIA DGX Cloud para fazer benchmark do seu modelo específico.
• Não migre workloads Windows Server ou HPC dependentes de AVX-512 ainda, a menos que você tenha builds nativos para ARM confirmados e testados. A economia de custos não se concretiza se o workload apresentar desempenho inferior ou exigir bibliotecas específicas de ISA que ainda não foram portadas.
• Use instâncias Ampere Altra Max para Redis, Memcached e NGINX. O mapeamento 1:1 de vCPU para core e o escalonamento linear de threads tornam a previsibilidade de latência mensuralmente melhor do que instâncias x86 com SMT sob carga variável.

O momento do ARM em servidores não está chegando — ele já chegou. O trabalho restante é a migração sistemática dos workloads que ainda rodam em x86 por inércia, e não por necessidade.