A CPU voltou: quando rodar LLMs em servidores sem GPU em 2026

Você não precisa de uma GPU para cada funcionalidade de IA. Isso era verdade em 2023, e é dolorosamente verdade em 2026. Na semana passada, um desenvolvedor rodou um modelo de 26B em um Xeon de uma década e obteve 5 tokens/s — longe de produção, mas prova o ponto: o piso da inferência em CPU não para de subir. Enquanto isso, uma nova leva de artigos e posts de fornecedores defende flash de alta largura de banda como repositório de pesos. Em outras palavras: capacidade de computação não é mais sua única alavanca; largura de banda e localidade de memória importam tanto quanto.

Se você é um CTO tentando entregar IA confiável e com custo controlado no seu produto neste trimestre, precisa de uma regra simples: GPUs para o que de fato precisa de GPU. Todo o resto vai para as CPUs que você já sabe escalar, proteger e comprar por preços razoáveis.

A versão curta: onde a CPU vence e onde não

• CPU vence quando seus modelos são pequenos (1B–8B), as saídas são curtas (≤150 tokens), a concorrência de pico é irregular ou baixa, e seu SLO tolera de 500–1500 ms até o primeiro token significativo.
• GPU vence quando você exige contextos longos (≥16k), gerações longas (≥300 tokens), RPS sustentado alto, visão/multimodalidade, ou fine-tuning/treinamento.

Todo o resto é zona cinzenta. Aqui vai um framework de decisão para tirar o achismo de cena.

Um framework de decisão pé-no-chão (cinco números decidem)

Antes de escolher hardware ou modelo, responda com logs reais, não com achismos:

1. Comprimento de contexto: qual é o percentil 95 de tokens do prompt + contexto recuperado?
2. Comprimento da saída: qual é o percentil 95 de tokens gerados?
3. Concorrência de pico: quantas gerações concorrentes no pico do negócio?
4. SLO de latência: tempo até o primeiro token e até o último token que você precisa garantir.
5. Patamar de qualidade: qual a taxa mínima de acerto vs. ground truth que você aceita (por tarefa) — e um modelo de 8B ou 4B atende?

Agora aplique os limiares:

• Se contexto ≤8k, saída ≤150 tok e concorrência de pico ≤10 por instância do modelo: CPU é viável, muitas vezes mais barata e simples. Comece com um modelo destilado de 8B ou 3B com quantização de 4 bits.
• Se qualquer item acima for excedido em 2×: assuma GPU, a menos que a qualidade permaneça aceitável com um modelo menor e prompts mais enxutos.
• Se as saídas são “explosivas porém breves” (roteamento, classificação, planejamento de chamadas de ferramentas, moderação, prompts de sistema, reescrita/normalização): CPU quase sempre vence, porque GPUs ociosas queimam dinheiro.

Perceba que isso não é sobre benchmarks de fornecedor. É sobre seus tokens, seus SLOs e sua curva de concorrência.

O que mudou desde 2024 que torna a inferência em CPU real?

• Melhor quantização: esquemas de 4 bits e de precisão mista com escalas por grupo preservam a qualidade enquanto reduzem drasticamente a largura de banda de memória. A confiabilidade de chamadas de ferramentas deixou de ser uma vítima automática se você escolher o esquema certo e testá-lo.
• Decodificação especulativa: modelos rascunho (pequenos, 1B–3B) predizem múltiplos tokens e o modelo alvo verifica. Em CPUs, isso gera aceleração efetiva de 1,2×–2× dependendo do formato do prompt e da taxa de aceitação.
• As bibliotecas ficaram sérias: llama.cpp fechou muitas lacunas de performance em AVX2/AVX-512/NEON/SVE e suporta pesos mapeados em memória; MLC LLM elevou o piso em Arm e ambientes heterogêneos.
• As CPUs ficaram largas e baratas: Sapphire Rapids e peças classe Bergamo trouxeram mais núcleos, L3 maior e canais de memória mais rápidos. Instâncias de CPU na nuvem ainda são precificadas como, bem, CPUs — não como exposições de arte em HBM.

E sim, aquela demo no Hacker News de um modelo de 26B a ~5 tok/s em um Xeon antigo é um truque. Mas o ponto permanece: se uma CPU de museu faz isso, uma CPU moderna carrega muito trabalho real.

Uma conta de TCO que dá para viver

Você não precisa de números perfeitos para escolher a arquitetura; precisa de ordens de grandeza. Eis um jeito de modelar sem acrobacias no Excel:

1. Escolha um tamanho de modelo candidato (3B, 8B). Valide a qualidade em um conjunto de avaliação de 100–200 amostras para suas tarefas reais (chamadas de ferramentas, respostas curtas, roteamento). Se a taxa de acerto ficar dentro de 3–5 pontos da sua linha de base em GPU, mantenha.
2. Meça três coisas em hardware real: throughput de prefill (tokens/s) para seu comprimento médio de prompt, throughput de geração para seu comprimento médio de saída e tempo até o primeiro token. Faça isso em uma máquina de 8–32 vCPUs que corresponda à sua classe de produção (Intel AVX-512 ou AMD Zen 4/4c). Repita em uma A10/A100/L4 se você tiver.
3. Calcule as instâncias necessárias: Instâncias = ceil((geraçōes concorrentes de pico × tokens médios de saída / tps de geração) / SLO). Seja conservador no tps; use seu p50 ou p75, não o p99 de melhor caso.
4. Compare a unit economics: multiplique as instâncias pelo custo horário. Em CPUs, você provavelmente terá autoscaling mais simples e scale-to-zero, enquanto GPUs frequentemente punem com aquecimentos longos e alocações órfãs.

Como referência, instâncias de CPU em nuvem continuam 3–6× mais baratas por hora do que instâncias com uma única GPU. Se sua carga fica ociosa 80% do dia e gera ≤100 tokens por requisição, um pool de CPU com scale-to-zero agressivo quase sempre supera uma GPU parada, mesmo que a GPU seja 2–4× mais rápida em throughput sustentado.

Os pontos ideais para inferência só em CPU em 2026

1) Roteamento, classificação e aplicação de políticas

Moderação, redação de PII, roteamento de ferramentas, classificação de intenção e checagens de permissão preferem saídas curtas e prompts enxutos. Um modelo instruído de 1,5B–3B em 4 bits frequentemente atinge acurácia a poucos pontos do seu baseline de 7B/8B. A latência fica na faixa sub-segundo em um servidor moderno de 16–32 vCPUs. Suas GPUs não deveriam estar queimando ciclos fazendo porteiro.

2) Planejadores de chamadas de ferramentas e controladores de agentes

Etapas de planejamento raramente precisam de gerações longas. Elas precisam de confiabilidade. Um modelo compacto mais um esquema rígido de function-calling roda feliz em CPUs, com suas GPUs caras reservadas para tarefas pesadas como síntese de código ou raciocínio com grande contexto. Se você está indo para agentes, CPUs são seu plano de controle.

3) Chat com picos acentuados e baixo ciclo de utilização

Bots internos de suporte que veem picos de tráfego no horário comercial e depois ficam quase ociosos? Autoscaling em CPU vence. Você pode adicionar decodificação especulativa para reduzir latência e definir um SLO como “primeiro token em até 700 ms, streaming a ≥10 tok/s”. Saída em streaming esconde parte da diferença de throughput bruto vs GPUs.

4) Requisitos in-country e on-prem

Nem todo mundo quer enviar PII para onde há GPUs. Para Brazil (LGPD) e residência de dados na UE, é muito mais fácil comprar capacidade de CPU no país — em bare metal ou em uma região de nuvem mainstream — do que caçar GPUs onde os reguladores querem que suas cargas residam. Sua equipe nearshore consegue operar; seu auditor dorme melhor.

5) Inferência na borda para apps móveis e desktop

Laptops, workstations e servidores compactos (NUCs, EPYCs single-socket) rodam modelos de 1–4B confortavelmente para recursos offline ou com prioridade à privacidade. Se você já investiu em inferência on-device no mobile, a mesma lógica se aplica ao seu parque de desktops corporativos.

Onde a CPU vai te decepcionar

• Geração de longo formato: relatórios, marketing copy, respostas de milhares de tokens. Você vai estourar SLOs ou provisionar um número absurdo de cores.
• Janelas grandes de busca: contextos de 16k–200k tokens exigem largura de banda de memória e batch efetivo que a CPU não acompanha sem compromissos dolorosos.
• Visão/multimodal: alguns casos estreitos funcionam em CPU, mas sua latência e custo explodem rápido. Poupe sua sanidade; use uma GPU.
• Fine-tuning e adapters: treinamento pertence às GPUs. Ponto.

Um stack pragmático de inferência em CPU que não vai te surpreender

Modelos e runtimes

• Tamanho de modelo: comece com variantes instruídas de 3B–8B. Se 8B falhar nos testes por >5 pontos, não force CPU; gradue essa carga para uma GPU.
• Runtime: llama.cpp pela portabilidade e otimizações agressivas de CPU; MLC LLM para Arm e empacotamento unificado entre dispositivos; Ollama para integração rápida (teste e depois endureça para produção).
• Quantização: use 4 bits somente nos pesos com escalas agrupadas (ex.: q4_k_m). Reexecute sua suíte de avaliação após quantizar; chamadas de ferramenta e saídas JSON são mais sensíveis.
• Decodificação especulativa: combine um modelo rascunho de 1–3B com seu alvo de 3–8B. Valide a taxa de aceitação nos seus prompts; 40–70% de aceitação pode cortar 20–40% da latência sem desvio de qualidade.

Hardware e SO

• Famílias de CPU: prefira Intel AVX-512 (Sapphire Rapids) ou AMD Zen 4/4c (Genoa/Bergamo) com L3 grande e 8+ canais de memória. Arm (Graviton3/4) é atraente em custo/watt se o caminho NEON/SVE do seu runtime estiver maduro.
• Memória: capacidade primeiro. Um modelo 8B em 4 bits fica na faixa de 4–6 GB para pesos, mas planeje 3× de folga para cache KV e batching. Se rodar múltiplos workers, mapeie em memória o mesmo arquivo de pesos para compartilhar páginas entre processos.
• NUMA e pinning: fixe threads por socket. Use numactl e cpusets. Desative oversubscription; ajuste as threads do runtime para núcleos físicos, não vCPUs. Teste com e sem SMT (hyper-threading); resultados variam por microarquitetura.
• Huge pages e mmap: suporte os pesos com páginas grandes onde houver suporte. Faça pre-fault na inicialização para evitar surpresas de page-fault na primeira requisição. Mapeie em memória pesos somente leitura para permitir que múltiplos workers os compartilhem.

Serviço e autoscaling

• Pools por modelo: não multiplique modelos dentro de um único processo. Rode um modelo por worker, um worker por conjunto de pinos de CPU. Escalonamento horizontal é seu amigo.
• Autoscaling ciente de fila: escale por requisições em voo e tokens em progresso, não apenas por CPU%. HPA/KEDA com métricas customizadas funcionam; mantenha o cool-down de scale-up abaixo de 30 s para lidar com picos.
• Warm starts: o carregamento de pesos via mmap é rápido, mas a residência de páginas não é grátis. Mantenha uma pequena reserva de workers aquecidos por modelo para proteger seus p95 de SLO.
• Streaming: sempre faça streaming de tokens para o cliente. Isso esconde lacunas de throughput bruto e cumpre confortavelmente SLOs de “tempo até o primeiro token”.

Observabilidade que realmente te diz algo

• Medição de tokens: emita tokens de prompt, tokens de saída, tempo até o primeiro token e tokens/s. Distinga taxas de prefill e de geração.
• Deriva de qualidade: avaliações noturnas em um conjunto fixo de teste. Acompanhe deltas de taxa de acerto quando mudar quantização, flags de runtime ou opções de compilador.
• Controle de admissão: se a profundidade da fila ultrapassar N, rejeite requisições ou encaminhe para um pool de GPU. Ser honesto é melhor do que violar SLOs.

Segurança e compliance: CPUs tornam in-country fácil

A escassez de GPU criou um padrão ruim: envio de dados para onde quer que existam GPUs. Se você tem restrições de LGPD, HIPAA ou SOC2 — e muitos têm — regiões de CPU e bare metal são triviais de adquirir no país (Brazil, UE ou estados específicos dos EUA). Você ganha:

• Procurement mais curto: capacidade de CPU está em todo lugar; seus ciclos de compra e revisão de segurança são de semanas, não trimestres.
• Atestação mais simples: menos dispersão de fornecedores e menos aceleradores “caixa preta” para explicar aos auditores.
• Ops nearshore: um pod baseado no Brazil pode operar e endurecer seu cluster de inferência em CPU com 6–8 horas de sobreposição diária e custo operacional materialmente menor do que uma equipe nos EUA.

Como pilotar em 30 dias sem descarrilar seu roadmap

1. Semana 1: escolha duas cargas que se encaixem nos pontos ideais (por exemplo, moderação e roteamento de ferramentas). Congele um conjunto de avaliação de 100–200 amostras com ground truth.
2. Semana 2: levante um pool de CPU (16–32 vCPUs, 64–128 GB de RAM). Implemente llama.cpp ou MLC com um candidato de 8B e um de 3B, ambos em 4 bits. Adicione streaming + métricas de tokens e latência.
3. Semana 3: rode A/B/C vs seu caminho atual apoiado em GPU. Se o caminho em CPU ficar a 3–5 pontos de qualidade e dentro do seu SLO, prossiga. Se não, reduza o modelo ou aperte os prompts; se ainda falhar, declare como “requer GPU” e siga em frente.
4. Semana 4: leve a produção com autoscaling baseado em fila, controle de admissão e uma rota de overflow para GPU em picos. Crie alertas para regressões de tokens/s e erros de esquema induzidos por quantização.

Armadilhas comuns (e como evitá-las)

• Assumir que CPU == má qualidade: sua bancada de avaliação decide. Muitos modelos de 3B–8B passam bem em tarefas estreitas com os prompts e a quantização certos.
• Ignorar largura de banda de memória: inferência em CPU é frequentemente limitada por banda. Prefira peças com mais canais de memória e L3 maior; mantenha tamanhos de batch realistas.
• Superotimizar threads: mais threads não garantem mais tokens/s. Encontre o joelho da curva para sua CPU; fixe e pare.
• Não testar function-calling sob quantização: esquemas JSON e chamadas de ferramentas são frágeis quando você espreme precisão. Valide e, se necessário, use maior precisão no head de saída ou decodificação restrita.
• Esquecer scale-to-zero: o ganho econômico das CPUs desaba se você mantiver pools aquecidos o dia todo para cargas que têm picos 10 minutos por hora. Ajuste isso.

E o tal do “flash de alta largura de banda” para pesos?

Você verá propostas de camadas NVRAM/NVMe posicionadas como quase-HBM para pesos de modelos. É útil, com ressalvas:

• Ajuda no cold start: repositórios de pesos apoiados em flash reduzem tempos de carga fria para modelos multi-GB em vários workers. Combine com mmap para compartilhar páginas.
• Não é almoço grátis: a geração ainda é limitada por SRAM/DRAM. Uma vez aquecidos, os pesos precisam estar na RAM. Não espere que flash aumente tokens/s em steady-state.
• Resistência importa: já vimos equipes queimarem a vida útil de SSD ao chacoalhar pesos para dentro e fora. Pese modelos populares; rode a cauda longa com parcimônia.

Use flash para melhorar a suavidade operacional, não para fingir que sua CPU é uma GPU.

Sim, misture arquiteturas

O padrão vencedor de 2026 se parece com isto:

• Pool de CPU para roteamento, filtros, planejadores, gerações curtas e tráfego on-prem/in-country.
• Pool de GPU para contexto longo, saídas longas, multimodal e qualquer tarefa que falhe no seu funil de avaliação em CPU.
• Roteamento de overflow para que filas de CPU possam transbordar para GPU durante picos, com tetos rígidos de orçamento para evitar sustos na fatura.

Isso não é dogma. É margem. Você mantém qualidade onde precisa e recompra custo e simplicidade em todo o resto.

Se você quiser ajuda

DHD Tech constrói e opera pools de inferência em CPU para startups dos EUA com pods baseados no Brazil. Montamos sua bancada de avaliação, dimensionamos os modelos corretamente, endurecemos o stack de serving e conectamos autoscaling com handoffs limpos para overflow em GPU — para você parar de pagar por aceleradores que ficam ociosos 18 horas por dia.

Principais pontos

• Não padronize GPUs. Se contexto ≤8k, saída ≤150 tok e a concorrência de pico é modesta, CPUs provavelmente vencem.
• Quantização e decodificação especulativa tornaram prática a inferência em CPU para modelos de 1B–8B sem destruir a qualidade.
• Meça tokens/s de prefill/geração e tempo até o primeiro token nos seus prompts; deixe sua bancada de avaliação decidir.
• Use CPU para roteamento, políticas, planejadores, chat com picos e cargas in-country; mantenha GPUs para tarefas longas, pesadas ou multimodais.
• Arquiteture com pesos via mmap, pinagem de threads, autoscaling baseado em fila e saída em streaming. Adicione overflow em GPU para picos.
• Flash ajuda no cold start, não no throughput sustentado. Não queime a resistência de SSD “chacoalhando” pesos.
• Ops nearshore em CPU são fáceis de compor e auditar. Você entrega mais rápido e gasta menos.