2026 é diferente: IA no dispositivo é padrão, mas nem tudo acelera do mesmo jeito

Em 2026, os principais sistemas operacionais trazem recursos de IA no próprio dispositivo e muitos apps recorrem à aceleração heterogênea. No Windows 11, funções como Recall e Windows Studio Effects se apoiam na NPU para aliviar CPU e GPU, com patamares mínimos de desempenho bem definidos. No macOS, o Apple Silicon integra CPU, GPU, um Neural Engine e memória unificada que favorecem cargas mistas. No Linux, a maturidade de CUDA/ROCm e dos caminhos via Vulkan continua a pautar o trabalho de criadores e desenvolvedores.

A consequência prática: não existe uma única “especificação de IA”. Um portátil veloz em edição de vídeo com efeitos de câmara em tempo real pode não ser o melhor para inferir um LLM grande ou para gerar imagens em lotes. Este guia decompõe, com critérios verificáveis, o papel de cada acelerador, quanta memória um 7B/13B/70B realmente precisa com diferentes quantizações e como converter isso em decisões de compra realistas para os próximos 3–6 meses. Além disso, esclarece o que significam métricas comuns (TOPS, tokens/s, latências) e como relacioná‑las aos seus fluxos sem cair em comparações pouco úteis entre arquiteturas.

CPU, GPU e NPU: quem faz o quê e com qual API

- CPU: orquestra, cuida do pré/pós‑processamento e, sozinha, atende modelos pequenos ou tooling (tokenização, E/S). Quando a biblioteca não tem backend acelerado, a CPU é o salva‑vidas universal. A métrica útil é o desempenho por fio em ponto flutuante e a presença de instruções vetoriais; além de 8–10 threads, o escalonamento perde eficiência em LLMs por gargalos de memória. Também importam a latência de acesso e a largura de banda sustentada da memória, pois prefill e atualizações do cache KV são sensíveis a esses caminhos mesmo quando parte do cálculo roda em um acelerador.

- GPU: domina com tensores grandes e lotes; é a via principal para LLMs médios e geração de imagens. No Windows, o caminho “agnóstico” passa por Windows ML com ONNX Runtime e sua política de seleção de provedores; na NVIDIA, CUDA segue como rota mais madura; na AMD, ROCm habilita kernels HIP. Vulkan e WebGPU impulsionam a portabilidade do compute, sobretudo em apps e navegadores modernos. Na prática, GPUs entregam melhor throughput quando é possível agrupar solicitações (batching) ou quando o app encadeia várias etapas tensorais com operadores bem suportados no backend escolhido.

- NPU: acelera inferência de baixa latência e baixo consumo em modelos otimizados (visão, efeitos de câmara, assistentes do SO, partes de LLMs compactos). No Windows, certas experiências do sistema exigem um patamar de ~40 TOPS na NPU. No macOS, o Neural Engine convive com GPU/Metal e a conversão para Core ML decide o que roda no ANE e o que fica na GPU. O essencial na NPU é que a rota de execução esteja preparada para aproveitá‑la; sem isso, o trabalho volta para GPU ou CPU mesmo que o dispositivo tenha NPU.

Modelos e memória: 7B/13B/70B em fp16, int8 e 4 bits, e por que RAM/VRAM manda

A memória necessária divide‑se em duas partes: pesos do modelo e cache KV. Regra rápida: pesos ≈ bytes_por_parâmetro×n_parâmetros; fp16/bf16 ≈ 2 B/param, int8 ≈ 1 B/param e 4 bits ≈ 0,5 B/param. Assim, um 7B em fp16 fica em ~14 GB só de pesos; o mesmo 7B quantizado a 4 bits cai para ~3–4 GB, com alguma perda de qualidade. O cache KV pode somar vários GB com contextos longos ou alta concorrência e, muitas vezes, esgota a VRAM/RAM antes dos pesos. O cache KV cresce com o comprimento de contexto efetivo e a profundidade do modelo, então dimensione pensando no seu uso típico (por exemplo, cadeias de ferramentas com contexto estendido vs prompts curtos).

Na prática de portátil, um 7B quantizado cabe e responde de forma fluida com 8–16 GB disponíveis para o processo; um 13B pede 16–24 GB para ficar folgado; um 70B em 4 bits já ocupa 40 GB só em pesos e requer sistemas com muita memória unificada ou transbordo para a RAM. Se sua GPU tem VRAM limitada, mover o cache KV para a RAM do sistema ou dividir o modelo entre GPU e CPU/NPU pode manter a sessão, mas aumenta a latência. Considere também o custo do loader e das bibliotecas do runtime, que somam algumas centenas de MB e podem fazer diferença quando o orçamento de VRAM é apertado.

NPU em 2026: como ler TOPS e quando a GPU ainda lidera

Os TOPS medem operações inteiras por segundo (tipicamente int8/int4) sob suposições específicas do fabricante. Servem para filtrar a compatibilidade mínima do sistema e estimar classes de tarefas em tempo real (p. ex., efeitos de câmara, tradução ao vivo, pequenas redes de visão), mas não substituem métricas de tarefa como tokens/s ou latência P95 no seu modelo alvo. No Windows, recursos do sistema como Recall e a faixa superior de Studio Effects ativam requisitos mínimos em torno de 40 TOPS na NPU, além de condições de memória e segurança do dispositivo. Ao comparar equipamentos, interprete TOPS como um limiar de capacidade, não como escala linear de desempenho entre marcas ou gerações.

Para LLMs médios ou difusão por lotes, a GPU segue liderando em throughput e cobertura de operadores. A NPU vence quando o app está adaptado (via Windows ML/ONNX Runtime com política “prefer NPU” ou via Core ML com camadas compatíveis) e quando a autonomia importa: vê‑se com frequência economia energética significativa frente à GPU em tarefas contínuas de baixa potência, embora com limites de operadores e de tamanho de modelo. Em cenários mistos, uma estratégia eficaz é deixar o prefill pesado para a GPU e descarregar na NPU processos de visão ou post‑processing, mantendo o consumo contido sem penalizar demais a latência percebida.

Windows, macOS e Linux: estado real das toolchains e da compatibilidade

- Windows (ARM e x86): Windows ML oferece uma camada uniforme sobre o ONNX Runtime e permite escolher um execution provider (CPU, NPU, GPU via DirectML, CUDA, etc.) ou deixar que uma política selecione “máximo desempenho” ou “máxima eficiência”. DirectML apoia‑se em qualquer GPU compatível com DirectX 12, útil para hardware diverso e deployments sem dependência de um único fornecedor. Para apps que já usam ONNX Runtime, adotar uma política como MAX_EFFICIENCY ou PREFER_NPU é uma forma prática de equilibrar desempenho e autonomia sem reescrever operadores.

- macOS (Apple Silicon): o fluxo recomendado é converter para Core ML (com coremltools) e deixar Metal/ANE executar conforme a compatibilidade. A memória unificada simplifica cargas mistas (modelo na GPU, pré‑processamento em CPU/ANE) e, na geração M5, há configurações de até 128 GB unificados com maior largura de banda, o que ajuda em contextos longos de LLMs e em lotes para criação de conteúdo. Em projetos que misturam visão, áudio e texto, essa unificação reduz cópias entre dispositivos e pode estabilizar as latências sob carga.

- Linux: CUDA continua sendo o caminho mais polido na NVIDIA; ROCm habilita AMDs recentes com uma matriz de compatibilidade que convém revisar antes da compra. Para soluções portáteis e ambientes sem CUDA/ROCm, Vulkan oferece compute geral, e alguns runtimes experimentam rotas via SPIR‑V. No ecossistema open‑source, projetos como o llama.cpp expõem múltiplos backends (CPU/Metal/CUDA/ROCm/Vulkan) com maturidades distintas. Antes de escolher a plataforma, valide que o backend suporte os operadores críticos do seu modelo e que dependências (drivers, kernel, bibliotecas) estejam em versões compatíveis.

Armazenamento, E/S e portas: por que 1–2 TB NVMe não é luxo

Os ficheiros de modelos ocupam espaço real mesmo quantizados: um 7B fica em ~3–4 GB; um 13B, ~7–8 GB; um 70B, ~35–40 GB em 4 bits. Se pretende alternar entre famílias (Llama, Mistral, embeddings, TTS, VAD) e manter várias quantizações/versões, 1–2 TB NVMe evitam limpezas constantes. Leituras sequenciais grandes favorecem a abertura da sessão e a recarga após suspensão; espaço livre também ajuda o paging e as caches do framework. Manter um único volume NVMe rápido simplifica a gestão de checkpoints e reduz a tentação de mover modelos para meios mais lentos que depois penalizam o tempo até o primeiro token.

Em conectividade, Thunderbolt 5 e USB4 v2.0 elevam o teto de largura de banda para SSDs externos ou eGPU (onde suportado) e para monitores 8K/taxas elevadas. Para cargas de IA, o ganho prático é ligar armazenamento externo rápido partilhando o barramento sem estrangular a GPU interna. Se usa chassis externos ou docks, confirme certificação e versão para evitar gargalos. E se o seu fluxo depende de mover modelos entre máquinas, considere um SSD NVMe externo numa caixa TB5/USB4 v2.0: os tempos de cópia e de carga melhoram de forma notável face ao USB legado quando os projetos têm muitos gigabytes.

Como medir desempenho útil e traduzi‑lo em perfis de compra

Métricas que importam: 1) tokens/s no seu modelo e quantização alvo com contexto típico; 2) latência do primeiro token (prefill) e da decodificação; 3) throughput por lote em geração de imagem/áudio. Evite comparar TOPS brutos ou FLOPS teóricos sem relação com o seu pipeline (tokenizador, cache KV, streaming). Sempre que possível, use benchmarks reprodutíveis e abertos do próprio runtime que planeia usar. Complemente com testes de energia quando a autonomia for prioritária: a diferença entre NPU e GPU em cargas contínuas de baixa potência pode ser decisiva mesmo se o tempo total for semelhante.

Perfis mínimos indicativos, se comprar entre Q4 2026–Q1 2027: 1) Chat local 7B (4 bits), multitarefa leve: CPU moderna de 8 núcleos, GPU integrada ou dGPU modesta, 16 GB de RAM e NPU se depender de recursos do SO; 2) Assistente de código e transcrição acelerados: dGPU com ≥ 8–12 GB de VRAM ou Apple Silicon com ≥ 24–32 GB unificada; 3) Geração de imagens em lotes e LLM 13B confortável: dGPU ≥ 16 GB de VRAM ou ≥ 48–64 GB de memória unificada; 4) Laboratório local com 70B em 4 bits: sistemas com ≥ 64–96 GB efetivos (unificada ou soma RAM+transbordo), aceitando compromissos de latência. Regra prática: priorize memória suficiente em vez de pequenas diferenças de TOPS/FLOPS e valide que as APIs que pretende usar (Windows ML/DirectML, Core ML, CUDA/ROCm, Vulkan/WebGPU) funcionam com a sua pilha de software.