Quando usar um LLM local em vez de um modelo por API

O que é um LLM local, na prática

Rodar um modelo localmente significa baixar os pesos de um modelo aberto e servi-lo na sua infraestrutura. Famílias como Llama, Qwen, Mistral, Gemma e gpt-oss publicam os pesos, cada uma com a sua licença, e ferramentas como Ollama, llama.cpp e vLLM transformam esses pesos em um serviço que a aplicação chama.

• No data center (on-premise): Controle total do hardware e da rede, inclusive sem acesso à internet.
• Na sua conta de nuvem: Servidores com GPU dentro da sua rede privada, sem que os dados passem por um provedor de modelo.
• No computador de quem usa: Modelos pequenos para testes, protótipos e uso individual.

O oposto é o modelo por API: Claude, GPT e Gemini rodam na infraestrutura do provedor ou de nuvens parceiras, e a aplicação envia os dados a cada chamada. Entre os dois extremos, algumas nuvens oferecem modelos de provedores em uma região escolhida, o que resolve parte das exigências de residência de dados.

Quando um LLM local faz sentido

A decisão costuma nascer de uma restrição concreta, e não de preferência técnica. Os sinais mais comuns:

• Dados que não podem sair: Contrato, sigilo profissional ou política interna proíbem enviar o conteúdo a terceiros, mesmo com cláusulas de privacidade.
• Residência de dados: Enviar dados pessoais a um provedor no exterior é transferência internacional, que a LGPD só permite nas hipóteses do artigo 33, como as cláusulas-padrão contratuais aprovadas pela ANPD.
• Operação sem internet: Fábricas, embarcações, áreas remotas ou ambientes isolados por segurança (air-gapped).
• Latência previsível: Na mesma rede, o modelo responde sem depender da internet e da fila do provedor, desde que o hardware dê conta da carga.
• Volume alto e constante: Com uso intenso o dia todo, o hardware fica ocupado, e o custo por tarefa pode ficar abaixo do custo por token da API.
• Versão sob controle: O modelo só muda quando você decide, sem depender do calendário de descontinuação do provedor.

LLM local ou API: o que muda em cada critério

Nenhuma das opções vence em todos os critérios. A tabela resume o que muda; o peso de cada linha depende do seu caso.

O que define o custo de cada opção

As duas opções têm custos de natureza diferente, e a comparação só vale com o mesmo volume de trabalho e o mesmo nível de qualidade.

• API: Tokens de entrada e saída multiplicados pelas chamadas; não há custo parado, e a conta cresce junto com o uso.
• Hardware: Compra ou aluguel de servidores com GPU, dimensionados para o pico de uso, e não para a média.
• Operação: Energia e refrigeração, ou o aluguel na nuvem, mais o tempo do time para atualizar, proteger e monitorar o serviço.
• Ocupação: Uma GPU parada custa o mesmo que uma ocupada; o modelo local compensa quando a carga é alta durante boa parte do dia.
• Qualidade: Se o modelo local erra mais, a revisão humana e o retrabalho entram na conta.

Por isso não existe resposta pronta sobre qual opção sai mais barata. A resposta vem de medir: tokens por tarefa e volume de um lado; hardware, ocupação e operação do outro.

Hardware: do que um modelo local precisa

O recurso que mais limita um modelo local é a memória da GPU. Ela guarda os pesos do modelo e, durante o uso, o cache de atenção (KV cache) de cada conversa em andamento.

• Tamanho do modelo: A memória para os pesos cresce com o número de parâmetros e com a precisão de cada um.
• Quantização: Guardar os pesos em 8 ou 4 bits reduz a memória necessária, com alguma perda de qualidade que precisa ser medida.
• Contexto e simultaneidade: Contextos longos e muitos usuários ao mesmo tempo ocupam memória extra no KV cache.
• Servidor de inferência: Em produção, motores como o vLLM atendem vários usuários ao mesmo tempo com batching contínuo; Ollama e llama.cpp facilitam rodar modelos em uma única máquina.

O dimensionamento sai de um teste de carga com o modelo, o tamanho de contexto e o número de usuários reais, e não de uma tabela genérica.

Arquitetura híbrida: modelo local e API no mesmo sistema

A escolha não precisa ser única. Uma camada de roteamento decide, a cada pedido, qual modelo atende, e a aplicação não precisa saber qual foi.

• Por sensibilidade: Dados pessoais ou sigilosos vão para o modelo local, e o restante pode ir para a API.
• Por dificuldade: Tarefas simples, como classificar e extrair, ficam no modelo local, e o raciocínio complexo vai para um modelo de fronteira.
• Por disponibilidade: Se um lado falha ou atinge o limite, o outro assume como fallback.

Como o vLLM e o Ollama expõem APIs compatíveis com a da OpenAI, trocar entre local e nuvem pode ser só configuração, desde que cada rota passe pelas mesmas evals. É o mesmo desenho do Mirador, motor de IA generativa da The Hackett Group: Claude e OpenAI atrás de uma abstração de provider, com escolha do modelo em tempo de execução.