LLM local vs API em 2026: a planilha real de 90 dias rodando os dois lado a lado

Toda semana cai a mesma pergunta no DM: "vale a pena subir LLM local ou continuo na API?"

A resposta honesta é: depende. Mas "depende" é a resposta preguiçosa. A boa é mostrar a planilha.

Nos últimos 90 dias acompanhei de perto um time que rodou os dois lados em paralelo. Mesmo caso de uso, mesmo volume, mesmo SLA. Um chatbot interno de suporte de TI numa empresa de médio porte: 12 mil chamadas por dia, p95 abaixo de 2 segundos, dados sensíveis que não podem vazar pra log de provider qualquer.

Stack A: Ollama + Llama 3.3 70B + duas A100 80GB.

Stack B: Claude Haiku 4.5 via API da Anthropic.

Mesmo prompt, mesma camada de RAG, mesma régua de avaliação. Seis baldes de custo medidos mês a mês. No fim, o veredito muda dependendo de quem você é — e o ponto de break-even está mais longe do que a maioria imagina.

TL;DR

• O que é: comparativo prático de 90 dias rodando LLM local e LLM via API lado a lado, no mesmo caso de uso.
• Stack A: Ollama + Llama 3.3 70B + 2× NVIDIA A100 80GB.
• Stack B: Claude Haiku 4.5 ($1/MTok input, $5/MTok output) via API.
• Volume: 12 mil chamadas/dia, ~3.100 tokens por chamada, p95 < 2s, dados sensíveis.
• Veredito curto: Stack B custou cerca de 1/3 nos 90 dias. Break-even só aparece em volume bem maior ou compliance bem mais duro.

O cenário real (não é benchmark de slide)

Chatbot de suporte de TI interno. Atende funcionários: "esqueci senha do AD", "VPN caiu", "como pedir acesso ao SAP", "o Teams trava quando entro na reunião". A maior parte é triagem, classificação e roteamento. Uma fatia menor exige raciocínio sobre logs ou base de conhecimento interna.

Os números do projeto:

• Volume: 12 mil chamadas/dia. Pico em torno de 4× a média.
• Tokens médios: 2.500 input + 600 output por chamada. Total ~1,1 bilhão de tokens/mês.
• SLA: p95 abaixo de 2 segundos. p99 abaixo de 4.
• Dados sensíveis: trechos de log, e-mails de funcionários, nomes de sistemas internos. Não pode sair sem DPA ou sem opt-out de treinamento.
• Equipe: 1 engenheiro sênior, 1 pleno, 1 SRE meio período.

Duas pessoas no time, duas convicções opostas. Um time achava que LLM local era a única saída por causa do dado sensível. O outro achava que pagar API era barato perto do custo escondido de operar GPU em produção. Em vez de discutir no Slack por mais três semanas, fizeram o que dev sério faz: subiram os dois e mediram.

Stack A — Ollama + Llama 3.3 70B + 2× A100

A escolha do Llama 3.3 70B não foi aleatória. Ele cravou ~86% no MMLU e 88.4% no HumanEval, o que coloca o modelo num patamar muito próximo do GPT-4o em vários benchmarks. Para chatbot de TI, sobra.

A conta de hardware é o problema.

Llama 70B em FP16 pede ~140GB de VRAM. Em INT8, ~70GB. Para garantir throughput decente e cabeça pra failover, foram duas A100 80GB. Em cloud:

• Lambda Labs A100 80GB sob demanda: ~$2,06/h.
• AWS p4d (A100 8-GPU): ~$3,40/GPU/h.
• Decentralizadas (Runpod, Jarvis): ~$1,49/h, sem SLA forte.

Duas A100 a $2,06/h × 730h/mês = ~$6.000/mês só de GPU em cloud. Em hyperscale, quase $10 mil. Em colo on-prem, depois do CAPEX, o custo recorrente cai pra ~$3.500/mês, mas exige hardware comprado, equipe pra cuidar, e redundância de verdade — não dá pra ter uma instância só e dormir.

O servidor de inference foi vLLM, não Ollama puro (Ollama é ótimo pra dev local; em produção, vLLM dá throughput melhor). Em A100, vLLM serve Llama 70B em torno de 1.100-1.150 tok/s agregado, com latência por stream entre 100-150 tok/s.

E aqui mora o primeiro vilão silencioso: 600 tokens de output a 120 tok/s dão 5 segundos. O SLA pede 2. A solução foi quantizar pra AWQ INT4, encurtar respostas via prompt e streaming pro frontend, pra que o usuário começasse a ver a resposta antes do completion fechar. Funcionou. Custou três semanas de tuning.

Stack B — Claude Haiku 4.5 + API Anthropic

Haiku 4.5 saiu em outubro de 2025. A própria Anthropic posiciona o modelo como "performance de coding comparável a Sonnet 4 a um terço do custo e mais de duas vezes a velocidade". Pra chatbot de suporte, isso é mais que suficiente.

Os números:

• Input: $1,00 por milhão de tokens.
• Output: $5,00 por milhão.
• Cache hit (5 minutos): $0,10 por milhão de tokens lidos.
• Context window: 200k tokens.
• Latência: na faixa de 600-1.200ms de TTFT, com geração rápida.

Calculando no volume do projeto, sem nenhuma otimização:

• Input mensal: 12.000 × 30 × 2.500 = 900M tokens × $1 = $900.
• Output mensal: 12.000 × 30 × 600 = 216M tokens × $5 = $1.080.
• Total de tokens: ~$1.980/mês.

Com prompt caching ativo num system prompt + RAG context fixo (que cabe perfeitamente nos 200k), boa parte do input vira cache read a $0,10/MTok. No caso real, com ~60% de hit rate, o custo de input despencou para algo perto de $400/mês. Output continuou cheio (é resposta nova). Total ~$1.500/mês com cache.

Sem cluster de GPU. Sem pager pra inference. Sem build de Docker com CUDA. Sem 14 vezes que o vLLM travou porque alguém esqueceu de bumpar o driver.

Os seis baldes de custo (a parte que ninguém mede)

Custo de LLM não é só token nem GPU. Quando a planilha tem só essas duas colunas, ela mente. O time usou seis baldes:

1. Compute — tokens da API ou horas de GPU.
2. Infra — rede, storage, load balancer, gateway, cache externo.
3. Engenharia — horas humanas pra subir, manter, atualizar, debugar.
4. Segurança e compliance — DPA, DLP, isolamento de rede, auditoria, revisão jurídica.
5. Observabilidade e evals — tracing, métricas, dataset de regressão, LLM-as-judge.
6. Custo de oportunidade — quanto tempo até a feature ir no ar, e o que isso significa em valor não capturado.

O quarto, quinto e sexto baldes são onde a discussão local-vs-API geralmente é decidida — e onde a maioria dos slides comparativos passa batido.

A planilha de 90 dias

Tudo em USD, arredondado pra cima. Engenharia calculada a $150/h (sênior + sobretaxa). Custo de oportunidade estimado pelo time como receita/economia adiada por atraso de go-live.

Mês 1 — setup

A diferença mais brutal está aqui. Subir vLLM em produção, com observabilidade, evals, autoscaling e failover, é trabalho de semanas. Subir um SDK de API é trabalho de tarde.

Mês 2 — operação estável

Stack A já está rodando. O custo cai, mas não desaparece — alguém ainda precisa olhar dashboard, ajustar quantização, lidar com OOM ocasional.

Mês 3 — iteração + tuning

Apareceram dois requisitos novos. No Stack A, virou rodada de tuning, requantização e teste de regressão. No Stack B, virou meia hora editando prompt e rodando o eval set.

90 dias somados

Em média, Stack B saiu ~$10.800/mês mais barato. Em 90 dias, a diferença pagou um ano inteiro de operação contínua do Stack B.

Onde o Stack A começa a ganhar?

Não é um "se", é um "quando". Três condições, isoladas ou combinadas:

1. Volume cresce muito. Compute fixo do Stack A não aumenta com tráfego — duas A100 servem 12 mil ou 60 mil chamadas/dia com tuning correto. Stack B escala linearmente com tokens. Em torno de 5-6× o volume atual (algo como 60-70 mil chamadas/dia mantendo o mesmo perfil de tokens), o compute da API começa a equiparar o custo total de operar o cluster. Mas a engenharia continua mais cara no Stack A — o break-even real do total fica em volume ainda maior.

2. Compliance vira veto, não preferência. Não é "preferiria não mandar dado pra fora". É "o regulador proíbe" ou "o contrato com o cliente exige isolamento físico". Aí o cálculo muda de eixo: o custo do Stack A não está sendo comparado com o do Stack B, está sendo comparado com o de não ter o produto. Vale notar que Bedrock e Vertex AI oferecem endpoints regionais com Haiku 4.5 por um adicional de 10%, o que resolve muitos casos de data residency sem precisar subir GPU.

3. Você tem GPU ociosa de outro projeto. Se o time já paga pela infra por outro motivo (treinamento, fine-tuning, vision pipeline), o custo marginal de servir inference cai pra perto de zero. Aqui o Stack A vira óbvio — mas o custo de engenharia continua existindo.

Veredito por persona

Esse é o ponto. A planilha não tem resposta universal. Tem resposta por contexto.

Startup, produto novo, time pequeno. Stack B sem pensar. Cada hora gasta com vLLM, quantização ou autoscaling de GPU é hora que não está gasta no produto. Custo de oportunidade é o balde mais pesado da sua planilha — e você nem sempre vê isso, porque ele não vem em fatura.

Empresa média (10 mil-50 mil chamadas/dia), dado sensível mas não regulado. Stack B com endpoint regional (Bedrock/Vertex em São Paulo) + cache agressivo + DLP no input. Comece aqui. Reavalie em 12 meses.

Enterprise com volume alto e compliance duro (banco, seguro, governo). Stack A ou modelo dedicado em região aprovada. Mas faça a conta inteira: o custo de eng + sec + observabilidade típicamente dobra o número de compute. Não decida só com a linha "GPU/h".

Time de pesquisa ou produto experimental. Os dois. API pra prototipar rápido, local pra controlar custo quando a feature virou tráfego de verdade. Não escolha cedo.

Solo dev / consultor. Stack B com batch API onde der (50% de desconto em workflows assíncronos). O tempo é seu — não venda ele pro Kubernetes.

O que esses 90 dias ensinaram (e que não cabe em benchmark)

O custo da API é fácil de ver: vem na fatura, com decimal e tudo. O custo do local é fácil de esconder: vem fragmentado em hora de engenheiro, em ticket de SRE às 3 da manhã, em feature que não foi entregue porque o vLLM caiu duas vezes na semana.

Quando esses dois custos são colocados na mesma planilha — com os seis baldes, não só os dois óbvios — a discussão muda. Para 80% dos times brasileiros que estão construindo IA aplicada hoje, o break-even simplesmente não chega no horizonte de planejamento. E quando chega, geralmente é compliance que empurra, não compute.

O resto é hype. De um lado, "API é refém de big tech, vamos pra local". Do outro, "local é coisa de quem não sabe usar API". Os dois argumentos perdem na hora que alguém abre a planilha de verdade.

Se você está nessa decisão agora, faça o que esse time fez: rode os dois por 30 dias num subset de tráfego, meça os seis baldes, e deixe os números decidirem. É exatamente esse tipo de discussão prática que rola toda semana na Beer and Code, a melhor comunidade de AI engineering em português, com grupo no WhatsApp aberto pra quem está construindo IA em produção.

A próxima pergunta inteligente não é "local ou API". É "qual dos seis baldes vai dominar minha planilha nos próximos 18 meses?". Quem responde isso primeiro, decide melhor.