IA local para software houses: o guia técnico para rodar LLMs na própria infraestrutura

Rodar LLMs na própria infraestrutura (IA local, ou self-hosted) virou uma decisão de engenharia e de negócio para software houses. A conta fecha em três cenários: volume alto e previsível de tokens, dados que não podem sair do ambiente do cliente e proteção contra mudanças de preço, de limite e de comportamento das APIs de fronteira. Este guia cobre o que é possível rodar hoje, em que hardware, com qual stack de inferência e com quais custos por milhão de tokens, assumindo que o leitor é uma equipe técnica que já opera IA em produção.

O argumento do hedge

A operação de uma software house moderna depende de dois ou três fornecedores de modelo. Essa dependência tem riscos conhecidos: preços e limites de uso mudam sem negociação, modelos são descontinuados ou trocados por versões com comportamento diferente (o que quebra prompt e avaliação calibrados), e os termos de uso de dados variam por contrato. Nada disso é argumento para abandonar as APIs de fronteira, que seguem à frente em raciocínio longo e em tarefas agênticas. É argumento para ter uma alternativa funcionando antes de precisar dela.

Modelos open-weight são esse hedge. Um peso baixado é um ativo que ninguém despublica: a capacidade que você tem hoje continua existindo amanhã, ao custo do seu hardware. Para uma software house, isso se traduz em três garantias: piso de capacidade em qualquer cenário de preço, rota de saída em negociações com fornecedor e resposta pronta para o cliente que pergunta "e se a API sair do ar ou dobrar de preço?". O hedge só vale se estiver operacional, com modelo servido, avaliado e integrado ao roteador de produção, e não como um plano em slide.

O que dá para rodar hoje

A geração atual de modelos open-weight relevantes para código é dominada por arquiteturas MoE (mixture of experts), que separam parâmetros totais de parâmetros ativos por token. As famílias DeepSeek (V3/R1 e sucessoras, 671B totais com 37B ativos, licença MIT), Qwen3 (235B com 22B ativos, Apache 2.0) e GLM (MoE na faixa de 300B com ~32B ativos) entregam qualidade utilizável em geração de código, extração estruturada e agentes simples. Abaixo delas, os densos de 14B a 70B (Qwen, Llama, Gemma 27B, destilados de R1 em 32B) cobrem autocomplete, classificação e RAG com folga.

A régua prática é VRAM. Em quantização de 4 bits, um denso de 32B pede cerca de 20 GB; um MoE grande como DeepSeek ou Qwen3 235B pede 130 GB ou mais, antes do KV cache, que cresce com contexto e concorrência. Quantização Q4/AWQ degrada pouco em geração de código no dia a dia, mas degrada; FP8 em GPUs recentes é o meio-termo com perda quase nula. A regra que usamos: avalie o modelo quantizado no seu benchmark interno, nunca no número de paper.

Hardware: três faixas

Faixa de estação de trabalho: uma GPU de consumo com 24 a 32 GB (RTX 4090/5090) roda densos de até 32B em Q4 e serve uma equipe pequena. É o ponto de entrada para autocomplete interno e experimentação, na casa de R$ 15 a 30 mil por máquina.

Faixa de servidor: GPUs profissionais com 80 a 96 GB (classe H100 ou RTX PRO com 96 GB) rodam densos de 70B com folga e MoEs grandes quantizados quando combinadas em par via tensor parallelism. Uma alternativa fora da curva para MoE grande com pouca concorrência é memória unificada (Mac Studio com 512 GB), que roda DeepSeek quantizado via llama.cpp com throughput modesto, mas custo de aquisição menor que um rack de GPU.

Faixa de nuvem privada: GPU por hora (H100 na casa de US$ 2 a 4/h em provedores de GPU) é o meio-termo para validar a operação antes de comprar ferro, e continua sendo a resposta certa para picos e para treinar ou fazer fine-tuning, que não justificam hardware próprio na escala de uma software house.

A stack de inferência

Para servir em produção, o padrão é vLLM ou SGLang: continuous batching, PagedAttention para o KV cache e API compatível com OpenAI, o que torna a troca transparente para o código cliente. Para desenvolvimento e máquinas individuais, llama.cpp e Ollama com modelos GGUF resolvem com menos operação. Os pesos vêm do Hugging Face, de preferência nas quantizações oficiais do próprio laboratório.

Duas peças completam a stack. Um roteador de modelos (LiteLLM ou equivalente próprio) na frente de tudo, decidindo por tarefa: frontier para raciocínio longo e agentes, modelo local para volume e dado sensível, com fallback automático entre eles. E observabilidade de LLM desde o primeiro dia: tokens por segundo, custo por requisição, taxa de fallback e avaliação contínua em um conjunto de tarefas reais da casa. Sem isso não existe a comparação honesta que sustenta a decisão.

Os economics, sem romantismo

Preços de referência das APIs em meados de 2026: modelos de fronteira na faixa de US$ 2 a 5 por milhão de tokens de entrada e US$ 10 a 30 na saída; os tiers econômicos dos mesmos laboratórios em US$ 0,15 a 1,20; e modelos abertos servidos por terceiros (DeepSeek e similares) chegando a US$ 0,14 a 0,90. Batch processing costuma dar 50% de desconto e cache de prompt corta até 90% do custo de entrada repetida. Esses números mudam rápido, confira os valores do dia nas páginas oficiais antes de fechar qualquer conta.

Agora o lado local. Exemplo com uma GPU de 96 GB na faixa de R$ 60 mil, amortizada em 36 meses: R$ 1,7 mil/mês de hardware, mais energia (600 a 700 W sob carga, uns R$ 350/mês em operação contínua), mais a fração de um engenheiro para manter a stack. Servindo um denso de 32B com vLLM e batching, o throughput agregado fica na casa de milhares de tokens por segundo, o que dá bilhões de tokens por mês em capacidade teórica. A 10% de utilização real, uns 500 milhões de tokens/mês, o custo sai na ordem de R$ 4 a 6 por milhão de tokens, competitivo com os tiers econômicos das APIs e muito abaixo dos modelos de fronteira.

A palavra que decide tudo é utilização. GPU parada é capital parado: em uso esporádico ou com picos imprevisíveis, a API vence por não ter custo fixo. O local vence quando há carga contínua para encher a GPU: pipelines batch, agentes que rodam de madrugada, features de produto com volume previsível. Por isso a ordem certa é medir o gasto mensal de tokens por categoria de tarefa primeiro e dimensionar o ferro depois, nunca o contrário.

Onde a IA local entra primeiro

Na prática das software houses, os primeiros casos que justificam a infra são: processamento de dados sob LGPD ou contrato restritivo (documentos de clientes de saúde, financeiro e jurídico que não podem ir para API externa); pipelines de alto volume e baixa complexidade (classificação, extração estruturada, geração de embedding, resumo de logs); ambientes air-gapped de clientes como bancos e governo, onde entregar o sistema com modelo embarcado vira diferencial de proposta; e o próprio fallback do roteador, mantendo o produto de pé em indisponibilidade ou mudança abrupta do fornecedor principal. O que ainda não compensa mover: o agente de código do dia a dia da equipe, onde os modelos de fronteira seguem pagando a diferença de preço em qualidade, como já discutimos em software houses na era da IA.

Roteiro de implantação

O caminho que recomendamos: medir 30 dias de consumo de tokens por categoria de tarefa; montar um benchmark interno com 50 a 100 tarefas reais da casa; validar 2 ou 3 modelos open-weight nesse benchmark usando GPU por hora, antes de comprar hardware; escolher o menor modelo que passa no critério de qualidade por categoria; só então dimensionar e comprar o ferro; servir atrás de API compatível com OpenAI e colocar o roteador na frente; e revisar a conta a cada trimestre, porque tanto os preços de API quanto os modelos abertos mudam em ciclos de meses. Para quem presta serviço de IA, essa capacidade vira oferta: consultorias de IA que operam inferência própria têm um argumento que concorrente nenhum copia por slide.

Perguntas frequentes

O que é IA local (self-hosted)?

É rodar modelos de linguagem com pesos abertos na sua própria infraestrutura (GPU no escritório, servidor dedicado ou nuvem privada), em vez de consumir modelos proprietários por API. O controle sobre dados, custos e disponibilidade passa a ser seu, assim como a operação.

Quanto custa rodar um LLM localmente?

O ponto de entrada útil é uma GPU de consumo de 24 a 32 GB (R$ 15 a 30 mil) para modelos de até 32B. Uma operação séria com GPU de 96 GB fica na faixa de R$ 2 a 3 mil/mês amortizados, e o custo por milhão de tokens cai abaixo do das APIs de fronteira quando a utilização é alta. Em uso esporádico, a API continua mais barata.

IA local resolve LGPD?

Ela elimina a transferência de dados a um terceiro no processamento por IA, o que simplifica contratos e DPAs. Não substitui o resto da conformidade (base legal, minimização, segurança do próprio ambiente), mas remove a objeção mais comum de clientes regulados.

Modelo aberto alcança os modelos de fronteira?

Em tarefas delimitadas (classificação, extração, código de escopo curto), a diferença prática é pequena e às vezes nula. Em raciocínio longo e agentes complexos, os modelos de fronteira seguem à frente. A arquitetura sensata usa os dois, com um roteador decidindo por tarefa.