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

A Qualcomm usou o Snapdragon Summit para avisar que o Linux vai chegar à linha Snapdragon X2. Para quem programa, isso pesa mais do que qualquer slide de "PC agêntico". Linux no Snapdragon X2 significa um notebook ARM com bateria de celular e NPU dedicada, rodando o sistema onde mora quase todo o nosso código de servidor. Pelo menos no papel.

O anúncio original está no blog da Qualcomm. Aqui eu explico por que demorou, o que realmente muda no seu fluxo e o que eu ainda quero ver funcionando antes de comprar.

Por que Linux no Snapdragon X2 é notícia

A primeira geração, o Snapdragon X Elite, saiu em 2024 com foco total no Windows. O Linux até rodava, mas do jeito que todo mundo que já instalou distro em hardware novo conhece. Boot ok. Teclado ok. Aí a suspensão falha, o áudio some, a GPU fica sem aceleração e a webcam não existe.

Teve muito trabalho bom de upstream no kernel, com a Linaro e a comunidade ajudando. Mesmo assim, a experiência dependia do modelo exato do notebook e de uma boa dose de paciência. Uma fabricante focada em Linux chegou a engavetar o próprio notebook com X Elite porque o suporte não ficava redondo.

O X2 chega com CPU Oryon de nova geração e uma NPU Hexagon anunciada na casa dos 80 TOPS. Hardware forte não era o problema. O problema era o software em volta dele. Quando a própria Qualcomm passa a tratar Linux como alvo oficial, o recado é outro: os drivers deixam de ser hobby de voluntário e viram compromisso de produto.

Hardware sem driver é só um peso de papel caro.

O que a NPU tem a ver com IA no código

O discurso do evento é "PC agêntico": agentes de IA rodando no seu notebook, sem mandar tudo para a nuvem. Para dev, a tradução prática é mais simples. É rodar modelo de código local, autocomplete local, embeddings locais para buscar no seu repositório.

Hoje, quem faz isso no Linux usa basicamente CPU ou GPU. Ollama e llama.cpp funcionam bem em ARM64 pela CPU. Um teste rápido:

uname -m
# aarch64

ollama run qwen2.5-coder:7b "explique este regex: ^(?=.*\d)[a-z\d]{8,}$"

Funciona. Mas não encosta na NPU. E aí está o ponto que quase ninguém comenta: ter 80 TOPS de NPU não adianta nada se o runtime que você usa não sabe falar com ela. No Windows, a Qualcomm empurra o stack dela com ONNX Runtime e o QNN. No Linux, a pergunta que importa é se esse caminho vai existir de forma estável, empacotado, sem você compilar SDK proprietário numa tarde de domingo.

Se a NPU funcionar bem no Linux, o ganho real é este: um modelo pequeno de autocomplete ou de embeddings rodando o dia inteiro sem esquentar a máquina e sem comer a bateria. Isso muda o jeito de usar IA no editor. Você para de pensar "vou chamar a API" e passa a ter um assistente sempre ligado, de graça, que não manda seu código privado para lugar nenhum.

Se a NPU não funcionar, você tem um ótimo notebook ARM com Linux. O que já é bom, mas é outra conversa.

O que muda no seu fluxo de trabalho com ARM

Aqui é onde a notícia pega o dev full stack de verdade, com ou sem IA. Notebook ARM rodando Linux significa que sua máquina local passa a ter a mesma arquitetura de um Graviton na AWS ou de um Ampere na Oracle Cloud. Isso tem lado bom e lado chato.

O lado bom: build local para ARM sem emulação. Se você faz deploy em instância ARM para economizar, finalmente testa no mesmo alvo.

O lado chato: tudo que assume x86 vai quebrar na sua cara. Algumas coisas que eu checaria no primeiro dia:

• Imagens Docker. Se a imagem base só tem amd64, o Docker vai emular com QEMU. Funciona, mas é lento. Vale publicar multi-arch:

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

• Dependências nativas no Node. sharp, bcrypt, better-sqlite3, driver de banco. A maioria já tem binário para linux-arm64, mas um pacote abandonado no meio da árvore pode cair no node-gyp e pedir compilador.
• Binários baixados em script. Aquele curl | tar no Dockerfile ou no CI que baixa um CLI com x86_64 fixo no nome. Esse é o que mais aparece.
• Bun compilado. Se você distribui binário com Bun, já dá para gerar para ARM direto:

bun build ./src/cli.ts --compile --target=bun-linux-arm64 --outfile cli

Nada disso é novo para quem usa Mac com chip M. A diferença é que agora o ambiente é Linux de verdade, sem a camada de VM que o Docker Desktop coloca no macOS. Seu docker run roda nativo. Para quem vive de container, isso é um ganho de verdade.

O que ainda precisa provar na prática

Anúncio em evento é promessa. Eu separo o que vou olhar quando os primeiros notebooks chegarem às mãos da comunidade:

1. Upstream ou fork? Se o suporte depende de kernel customizado da fabricante, você fica preso à versão que ela mantém. Se está no kernel principal, qualquer distro herda.
2. GPU com aceleração de verdade. Sem driver de GPU decente, o navegador sofre, o VS Code sofre e você desiste em uma semana.
3. Suspender e acordar. Parece detalhe. Não é. Notebook que não volta da suspensão vira desktop com bateria.
4. NPU acessível por runtime aberto. Quero ver ONNX Runtime ou llama.cpp usando a NPU no Linux sem gambiarra. Esse é o item que justifica o tema "IA no código".
5. Distros com imagem oficial. Ubuntu e Fedora dando boot de primeira, sem device tree baixado de fórum.

Se os itens 1, 2 e 3 vierem prontos, já é um bom notebook de dev. O item 4 é o que transforma a máquina em algo diferente de um MacBook com Linux.

Vale trocar seu notebook de dev agora?

Minha resposta honesta: ainda não. Espere os primeiros relatos reais.

Comprar hardware na semana do lançamento por causa de suporte a Linux prometido é um esporte radical. Quem fez isso com o X Elite descobriu que "suporta Linux" pode significar "dá boot e o resto é com você". Eu já fui essa pessoa com outro hardware. Passei mais tempo lendo issue de kernel do que escrevendo código, e meu cliente não pagava por hora de dmesg.

Dito isso, a direção é boa e eu torço por ela. Mais concorrência em ARM no desktop Linux força todo mundo a publicar binário multi-arch. Isso melhora o ecossistema até para quem continua em x86. E se a NPU ficar acessível, IA local deixa de ser coisa de quem tem GPU de 2 mil dólares e passa a ser padrão de fábrica em notebook comum.

Na prática, dá para começar hoje sem comprar nada: garanta que seu projeto builda para arm64. Rode o buildx multi-arch no CI. Troque os downloads com arquitetura fixa no nome. Quando o hardware estiver maduro, você só abre a tampa e trabalha.

Minha aposta: o X2 com Linux vai ser um ótimo notebook de dev bem antes de ser um bom "PC agêntico". E tudo bem. Um notebook que dura o dia inteiro, roda container nativo e não esquenta já resolve mais problema meu do que qualquer agente que eu vi em palco. Se quiser ver como eu organizo build e deploy nos meus projetos, dá uma olhada nos meus projetos.

A Qualcomm prometeu Linux no Snapdragon X2. Eu ainda não vou comprar.

Notebook ARM com bateria de celular, NPU de 80 TOPS e o mesmo sistema dos nossos servidores parece um sonho para quem programa.

O problema é que hardware sem driver é só um peso de papel caro. E 80 TOPS não valem nada se o seu runtime não consegue usar a NPU.

Antes de abrir a carteira eu quero ver quatro coisas funcionando: suporte no kernel principal, GPU acelerada, suspensão sem susto e NPU acessível por ONNX Runtime ou llama.cpp.

Enquanto isso, dá para se preparar sem gastar nada: build multi-arch no CI, imagens arm64 e nenhum download com x86_64 fixo no nome.

Minha aposta é que ele vira um ótimo notebook de dev bem antes de virar um bom "PC agêntico". No artigo completo eu explico o que muda no seu fluxo de trabalho.

#Linux #ARM #Snapdragon #IA #DesenvolvimentoDeSoftware