ARM na nuvem: vale trocar de arquitetura?

Processadores ARM deixaram de ser assunto de celular e entraram no catálogo de praticamente todo provedor de nuvem. A proposta é atraente: mais desempenho por real gasto, e consumo de energia menor.

A pergunta prática é se isso se aplica ao que você roda. E a resposta depende menos de arquitetura do que da sua stack — especificamente, do quanto dela tem binário pronto para ARM.

De onde vem a diferença

ARM adota uma abordagem diferente de projeto de processador, com instruções mais simples. Na prática, isso permite colocar mais núcleos no mesmo espaço e com menos consumo.

Para carga de servidor, que costuma ser muitas requisições independentes em vez de uma computação pesada única, esse formato favorece: mais núcleos atendendo em paralelo vale mais que núcleos individualmente mais rápidos.

O resultado varia bastante conforme a carga. Vale desconfiar tanto de "30% mais barato para tudo" quanto de "não vale a pena" — a diferença real depende do que roda.

O que funciona sem esforço

Boa parte da stack moderna já é multiplataforma há anos:

• Linguagens interpretadas — Python, Ruby, PHP, Node.js. O interpretador é compilado para a arquitetura, e o seu código não muda.
• Java e .NET, que rodam sobre máquina virtual.
• Go e Rust, que compilam para o alvo com uma variável de ambiente.
• Bancos de dados — Postgres, MySQL, Redis, MongoDB têm pacotes oficiais.
• Servidores web — nginx, Apache, Caddy.
• Docker, com imagens multiplataforma cada vez mais comuns.

Se a sua aplicação é web com banco relacional, cache e fila, é bem provável que ela rode sem nenhuma alteração de código.

O que costuma quebrar

Os pontos de atrito são previsíveis e vale checar antes:

• Extensão nativa. Pacote de Python, Ruby ou Node que inclui código compilado pode não ter binário pronto para ARM. Ele até compila na instalação, mas isso exige ferramentas de build na máquina e demora bem mais.
• Imagem de container só para x86. Imagem oficial popular costuma ter as duas; imagem de nicho, frequentemente não.
• Software proprietário. Agente de monitoramento, driver de licenciamento, SDK de fornecedor. Aqui não há o que fazer além de perguntar.
• Binário baixado direto, sem gerenciador de pacotes. Ferramenta instalada por script de instalação precisa oferecer a variante correta.

Uma verificação rápida do que existe hoje:

# Extensões nativas em Node
find node_modules -name '*.node' | head -20

# Em Python
python3 -c "import sysconfig; print(sysconfig.get_platform())"
pip list --format=freeze | wc -l

E para as imagens de container, dá para consultar antes de migrar:

docker manifest inspect postgres:16 | grep -A2 architecture

Se aparecer arm64 na lista, a imagem roda. Se só houver amd64, você precisará construir a sua.

Container multiplataforma

Quem usa container tem o caminho mais suave, porque a construção para as duas arquiteturas é um comando:

docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 \
  -t meuregistro/minha-api:1.4 --push .

O resultado é um manifesto único: quem baixa em x86 recebe a variante x86, quem baixa em ARM recebe a ARM. A mesma tag funciona nas duas.

Vale conferir o Dockerfile por hipóteses embutidas de arquitetura — download de binário com nome fixo é o caso mais comum:

# Ruim: assume x86
RUN curl -L https://exemplo/ferramenta-linux-amd64 -o /usr/local/bin/ferramenta

# Bom: usa a variável que o buildx fornece
ARG TARGETARCH
RUN curl -L https://exemplo/ferramenta-linux-${TARGETARCH} \
    -o /usr/local/bin/ferramenta

Um aviso sobre construir em emulação: buildx consegue compilar ARM em máquina x86, e isso é dramaticamente mais lento para qualquer coisa que compile código nativo. Se a construção passar a demorar dez vezes mais, essa é a causa — e a saída é construir em uma máquina da própria arquitetura.

Como testar sem risco

A avaliação honesta exige medir, não estimar. E medir é barato:

• Suba uma VPS ARM com o mesmo dimensionamento da atual.
• Instale a stack. Já aqui você descobre o que não tem pacote pronto — e essa descoberta sozinha responde boa parte da pergunta.
• Rode a sua carga real, não um teste sintético genérico. Índice de referência não representa a sua aplicação.
• Compare a métrica que importa: requisições por segundo com latência aceitável, ou tempo de processar um lote.
• Divida pelo preço. O número que decide é desempenho por real, não desempenho absoluto.

O teste custa algumas horas de máquina, cobradas por hora, e responde de forma definitiva o que nenhum comparativo genérico responde.

Vale medir também o consumo de memória. Algumas cargas usam um pouco mais em ARM, e isso pode empurrar você para o degrau seguinte de plano — o que muda a conta.

Onde o ganho costuma aparecer

Pelos relatos e pela natureza da arquitetura, as cargas que mais se beneficiam:

• Muitas requisições pequenas e independentes — API, servidor web, proxy.
• Processamento paralelizável — transcodificação, compressão, transcrição de áudio como no artigo sobre Whisper em CPU.
• Trabalho contínuo em segundo plano — worker de fila, indexação.

E onde o ganho tende a ser menor: carga de thread única com muita computação, e software que só existe compilado para x86.

Modelos de linguagem, um caso à parte

Para quem roda inferência em CPU, vale um teste específico. As implementações otimizadas costumam ter suporte maduro a ARM, e o desempenho por real pode ser favorável — mas a variação entre bibliotecas é grande, e o suporte a instruções vetoriais específicas muda muito o resultado.

Aqui, mais do que em qualquer outra carga, medir é obrigatório. O artigo sobre rodar LLM na sua VPS traz a metodologia; basta repetir o mesmo teste nas duas arquiteturas e comparar tokens por segundo por real.

O caminho de migração

Se o teste for favorável, migrar não precisa ser evento:

• Comece por um serviço sem estado — worker, API secundária.
• Rode as duas arquiteturas em paralelo por algumas semanas, com o balanceador distribuindo. Isso revela diferença de comportamento que teste não pega.
• Deixe o banco por último. É o componente com mais extensões nativas e o de maior custo se algo der errado.
• Mantenha as imagens multiplataforma mesmo depois de migrar. O custo é a construção um pouco mais longa, e o benefício é poder voltar sem reescrever nada.

Esse último ponto costuma ser o mais valioso. Uma stack que constrói para as duas arquiteturas deixa a escolha em aberto — e permite decidir por preço a cada renovação, em vez de ficar preso à decisão tomada uma vez.

O veredito honesto

Para aplicação web moderna, em stack comum e conteinerizada, ARM merece um teste. O esforço é baixo, o teste custa algumas horas de máquina, e o ganho, quando aparece, é recorrente.

Para stack com dependência proprietária, extensão nativa exótica ou software antigo, a conta muda: o custo de migração pode consumir anos de economia.

E vale dizer o óbvio que às vezes se perde: arquitetura raramente é o maior item da conta de infraestrutura. Antes de investir semanas nisso, vale conferir se não há ganho maior em máquina ociosa, snapshot sem retenção e dado em disco caro — os mesmos itens da faxina descrita no artigo sobre custo real da cloud, que costumam render mais que qualquer troca de arquitetura.

O cenário misto, que costuma ser o mais realista

Não é preciso escolher uma arquitetura para tudo. A configuração que mais aparece em operação madura é mista, com cada carga onde ela rende melhor.

Servidores web e workers, que são fáceis de migrar e se beneficiam de mais núcleos, vão para ARM. Banco de dados, com extensões nativas e maior custo de mudança, permanece em x86 até haver motivo concreto. O balanceador na frente não se importa com a arquitetura de quem está atrás.

Isso funciona porque a fronteira entre os componentes já é a rede, e rede não tem arquitetura. Uma requisição HTTP atendida por uma máquina ARM consultando um banco x86 é indistinguível de qualquer outra.

O único cuidado é manter a construção de imagem para as duas plataformas, para que a mesma tag sirva os dois lados sem exigir decisão a cada implantação. Com isso, a composição da frota vira um ajuste de custo, revisável a qualquer momento, em vez de uma decisão arquitetural irreversível.

Um checklist para decidir

Reduzindo tudo a uma sequência executável em uma tarde:

• Liste as dependências nativas da sua aplicação e verifique se há pacote ARM.
• Consulte o manifesto das imagens de container que você usa.
• Verifique o software proprietário — agente, driver, SDK. Este é o item que mais frequentemente inviabiliza.
• Suba uma VPS ARM e instale a stack. Se travar aqui, você já tem a resposta.
• Rode a sua carga real e compare desempenho por real com a máquina atual.
• Confirme o consumo de memória, que às vezes muda o plano necessário.

Se os seis passarem, a migração é de baixo risco e o ganho é recorrente. Se algum travar, o custo já apareceu — e apareceu antes de você ter investido semanas.

O que não vale é decidir por comparativo publicado. A variação entre cargas é grande demais para que a experiência de outra pessoa sirva de resposta para a sua.