Linux no Snapdragon X2: o que muda para IA no código

A Qualcomm confirmou no Snapdragon Summit que o suporte a Linux vai chegar à série Snapdragon X2. Se você já tentou instalar uma distro num notebook com o X Elite da geração passada, sabe por que isso virou notícia. Linux no Snapdragon X2 pode ser a primeira vez em que um notebook ARM com NPU de verdade serve para o dev que vive no terminal, roda Docker o dia inteiro e quer testar modelo de IA local sem pagar API.

O anúncio oficial está no blog da Qualcomm. Ele vem embrulhado no discurso de "PCs com IA agêntica", mas eu quero falar do que interessa para quem escreve código.

O que a Qualcomm anunciou, sem o marketing

Resumindo: a linha X2, aquela com núcleos Oryon de terceira geração e NPU Hexagon na casa dos 80 TOPS, vai ter Linux como alvo suportado. Não é mais "a comunidade que se vire". Pelo menos é isso que a empresa promete.

O contexto pesa. Na geração X1, o Linux chegou atrasado e aos pedaços. Cada modelo de notebook precisava do seu próprio device tree. Algumas máquinas bootavam e outras não. Coisas básicas como áudio, webcam e suspensão funcionavam num modelo e quebravam no outro. Saíram imagens experimentais do Ubuntu, a Linaro empurrou muito código para o kernel, e mesmo assim a recomendação honesta para dev era: compra se quiser brincar, não se quiser trabalhar.

Com o X2, a promessa é começar com o suporte já planejado no lançamento, e não um ano depois. Se isso se cumprir, muda a conta.

Por que Linux no Snapdragon X2 importa para quem usa IA no código

Hoje quem quer IA local no notebook tem basicamente dois caminhos:

• Um Mac com Apple Silicon, que roda modelo bem por causa da memória unificada, mas te prende no macOS.
• Um notebook x86 com GPU dedicada, que roda bem, esquenta, faz barulho e dura três horas na bateria.

Um ARM com NPU rodando Linux nativo é um terceiro caminho que não existia de forma decente. Bateria de ARM, ambiente de servidor e um acelerador dedicado para inferência.

E tem um detalhe que pouca gente comenta. Boa parte da sua stack de produção já roda em ARM. Graviton na AWS, Ampere na Oracle e na Hetzner, imagens arm64 em todo canto. Desenvolver no mesmo conjunto de instruções do servidor elimina uma classe inteira de bug do tipo "na minha máquina funciona".

NPU sem driver aberto é só um número bonito na ficha técnica.

O ponto que decide tudo: a NPU no Linux

Aqui mora minha opinião mais forte. CPU ARM rodando Linux é problema resolvido há anos. O teste real do X2 é outro: dá para usar a NPU no Linux sem gambiarra?

No Windows, a Qualcomm expõe a NPU via ONNX Runtime com o QNN Execution Provider e via a própria Qualcomm AI Stack. No Linux, a história sempre foi mais nebulosa. Existe SDK com build para Linux, mas a integração com o ecossistema que você usa no dia a dia (llama.cpp, Ollama, PyTorch) é outra conversa.

Se a NPU ficar presa num SDK proprietário, com binário fechado e versão de kernel específica, ela vai ser ignorada. O dev vai rodar tudo na CPU e na GPU e seguir a vida. Já vi esse filme com várias placas de "IA" nos últimos anos.

Se o driver entrar no kernel principal (o subsistema accel existe justamente para isso) e os runtimes populares ganharem backend, aí sim. Aí o X2 vira máquina de dev de IA de verdade.

Então meu conselho é simples: não compre pela promessa da NPU. Compre, se for comprar, pelo que já roda na CPU e na GPU. A NPU é bônus até provar o contrário.

O que já dá para fazer hoje, mesmo sem NPU

A boa notícia é que dá para fazer bastante coisa só com os núcleos ARM. O llama.cpp tem otimizações para ARM há tempo, incluindo instruções de produto escalar e matrizes que aceleram bastante os modelos quantizados. Um modelo de 7B ou 8B em Q4 roda com velocidade usável numa CPU ARM moderna.

O fluxo é o mesmo de qualquer Linux:

# confirma a arquitetura
uname -m
# aarch64

# Ollama tem build oficial para linux arm64
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen2.5-coder:7b

Dali você liga no seu editor, no Continue, no agente que preferir, apontando para localhost:11434. Nada muda no seu código. Só a máquina por baixo.

Para quem usa Bun e Node, a vida também é tranquila. Os dois têm binário linux-arm64 oficial. O problema costuma aparecer em dependência nativa antiga, aquele pacote que baixa um .node pré-compilado só para x86. Vale rodar isso antes de migrar:

# lista pacotes com binário nativo no projeto
find node_modules -name "*.node" -type f | head -20

Se aparecer algo exótico, confira se o pacote publica build para arm64 ou se compila no postinstall. Na minha experiência, sharp, bcrypt e esbuild já resolvem sozinhos. O que dá dor de cabeça é lib abandonada.

E o Docker, o PostgreSQL e o resto da stack?

Pergunta que todo mundo faz. A resposta curta: em 2026 isso é o menos preocupante.

O PostgreSQL oficial tem imagem arm64. Redis também. A maioria das imagens populares do Docker Hub é multi-arch. O risco está na imagem interna da sua empresa, aquela que alguém buildou em 2021 só para amd64.

Rodar imagem x86 em ARM funciona via emulação QEMU, mas é lento. Para um serviço que você sobe e esquece, tudo bem. Para o banco que roda os testes de integração 40 vezes por dia, não.

O caminho certo é buildar multi-arch de uma vez:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t minha-api:latest \
  --push .

Isso resolve para você e para quem for fazer deploy em Graviton depois. É o tipo de ajuste que você faz uma vez e esquece.

O que ainda me deixa com o pé atrás

Não quero soar como folder de lançamento, então vamos às ressalvas.

Primeiro, suporte por modelo de notebook. Na geração anterior, "o chip suporta Linux" não queria dizer que o seu notebook suportava. Fabricante de notebook raramente se importa com Linux. Antes de comprar, procure o modelo exato e veja se alguém já bootou, suspendeu e acordou a máquina sem drama.

Segundo, firmware. Muita coisa nesses chips depende de firmware proprietário que a distro precisa extrair do Windows ou baixar de algum lugar. Se a Qualcomm não facilitar a distribuição disso, a instalação continua sendo um tutorial de 14 passos num fórum.

Terceiro, GPU. A Adreno tem driver aberto no Mesa (o Freedreno, com o Turnip para Vulkan), e ele é bom. Mas suporte a geração nova sempre chega com algum atraso. Se o seu plano é usar a GPU via Vulkan no llama.cpp, espere alguns meses de maturação.

E por último, a parte engraçada: a Qualcomm anunciou Linux numa apresentação sobre "IA agêntica". Ou seja, provavelmente o primeiro agente que vai rodar bem nessas máquinas é você, compilando kernel às duas da manhã.

Vale a pena para o dev?

Minha leitura: é a notícia mais interessante sobre notebook ARM desde o M1, mas por um motivo diferente. O M1 provou que ARM serve para trabalhar. O X2 com Linux pode provar que dá para ter isso sem trocar de sistema operacional nem de filosofia.

Se você roda IA local no dia a dia, eu esperaria as primeiras análises com o Linux já instalado, de preferência com alguém testando inferência na NPU e não só benchmark de CPU. Se você só quer uma máquina leve com bateria longa para codar TypeScript e subir uns containers, o risco é menor e a recompensa aparece mais rápido.

De qualquer forma, já vale deixar seus projetos prontos para arm64 hoje. Custa pouco e te deixa livre para escolher a máquina depois. É o que tenho feito nos meus projetos.

A Qualcomm prometeu Linux no Snapdragon X2. Mas pra quem programa, o que decide é se a NPU vai funcionar.

Na geração X1, o Linux chegou atrasado e aos pedaços. Cada notebook com um problema diferente.

Agora a promessa é ter suporte desde o lançamento. Seria um notebook ARM com bateria longa, ambiente igual ao do servidor e IA local sem pagar API.

Só que NPU sem driver aberto é só um número bonito na ficha técnica. Se ficar presa num SDK fechado, todo mundo vai rodar na CPU e esquecer que ela existe.

Meu conselho: não compre pela promessa. Enquanto isso, deixe seus projetos prontos pra arm64. Custa pouco e você fica livre pra escolher a máquina depois.

Escrevi o passo a passo completo no blog, com Ollama, Docker multi-arch e as ressalvas que me deixam com o pé atrás.

#Linux #ARM #InteligenciaArtificial #DesenvolvimentoDeSoftware #Docker