Rodando Large Language Models no Seu Hardware

Ano passado gastei US$ 4.200 montando uma máquina local para inferência que conseguia rodar um modelo de 70B parâmetros com velocidade razoável. Um colega olhou meu setup e fez a pergunta óbvia: 'Por que não usar só a API? Isso dá uns oito anos de créditos de API.' Na conta, ele não estava errado. Mas errou na análise geral.

Rodar modelos de linguagem grandes localmente costumava ser domínio de laboratórios de pesquisa com clusters de GPU em rack. Isso mudou rápido. Hardware de consumo, técnicas de quantização e engines de inferência otimizadas colocaram modelos de 70B+ ao alcance de hobbyistas dedicados e pequenas equipes. Dispositivos como o Tinybox vão ainda mais longe — hardware feito sob medida para rodar modelos de 120B parâmetros offline, sem precisar de nuvem.

Mas 'possível' e 'prático' são coisas diferentes. Vamos conversar sobre o que realmente é preciso para rodar modelos grandes localmente, quando isso faz sentido e quando você sai ganhando pagando por uma API.

Por que rodar modelos localmente, afinal?

O modelo de API — enviar seus dados para um provedor de nuvem e receber os resultados de volta — funciona bem para a maioria dos casos. É mais simples, mais barato por consulta em volumes baixos e sempre dá acesso aos modelos mais recentes. Então por que alguém se daria o trabalho de fazer inferência local?

• Privacidade e compliance. Alguns dados não podem sair da sua rede. Prontuários médicos, documentos jurídicos, código proprietário, dados financeiros — setores regulados costumam ter exigências rígidas sobre residência de dados. Enviar prontuários de pacientes para um endpoint de API, mesmo criptografado, pode violar a HIPAA. Inferência local mantém tudo dentro das suas instalações.
• Latência. Chamadas de API envolvem viagens de ida e volta na rede, possíveis filas e rate limits. Inferência local tem latência de rede zero e você nunca fica na fila. Para aplicações interativas — assistentes de código em tempo real, tradução no dispositivo, interfaces de voz — a diferença entre 50ms e 500ms é a diferença entre 'responsivo' e 'arrastado'.
• Custo em escala. O preço de API é por token. Em volumes baixos, é irrelevante. Em volumes altos, cresce brutalmente. Uma equipe que faz muita revisão de código, análise de documentos ou processamento em lote pode queimar milhares de dólares por mês em API. Hardware local tem custo fixo — depois de pago, a inferência é praticamente de graça.
• Disponibilidade. APIs de nuvem caem. Rate limits são impostos. Preços mudam sem aviso. Modelos são descontinuados. Se seu produto depende de uma API de terceiros, você fica refém das decisões de negócio deles. Inferência local significa que sua capacidade não evapora só porque o servidor de outra pessoa teve um dia ruim.
• Liberdade para experimentar. Provedores de API têm políticas de uso. Eles decidem o que você pode ou não fazer com o modelo. Modelos locais não têm essas restrições — você pode fazer fine-tuning, modificá-los, usá-los para qualquer finalidade e rodá-los quantas vezes quiser.

A Realidade do Hardware

A principal restrição para inferência de LLMs é memória, não processamento. Os parâmetros do modelo precisam caber na memória (VRAM da GPU ou RAM do sistema) antes de você fazer qualquer coisa com eles. Um modelo de 70B parâmetros em ponto flutuante de 16 bits exige aproximadamente 140 GB de memória. Isso é mais do que qualquer GPU de consumo oferece.

É aqui que a quantização muda o jogo. Ao reduzir a precisão dos pesos do modelo de 16 bits para 8 bits, 4 bits ou até 2 bits, você diminui drasticamente os requisitos de memória:

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

A quantização de 4 bits (Q4_K_M no ecossistema do llama.cpp) é o ponto ideal atual. A degradação de qualidade é mensurável, mas geralmente aceitável para uso prático — a maioria das pessoas não consegue distinguir a saída do Q4 da precisão total em testes cegos. A quantização de 2 bits afeta a qualidade de forma perceptível, especialmente em tarefas que exigem raciocínio, mas ainda funciona para aplicações mais simples como classificação de texto ou sumarização.

Montagens com Hardware de Consumo

Se você está montando sua própria estrutura de inferência local, tem três caminhos básicos, cada um com um perfil diferente de custo-benefício.

O Caminho de GPU Única

Uma RTX 4090 (24 GB de VRAM, ~US$ 1.600) roda com folga modelos quantizados em 4 bits de até cerca de 30B parâmetros, ou modelos de 70B com quantização agressiva de 2 bits. Para a maioria dos modelos de 7B–13B, é exagero — você vai ter mais de 40 tokens por segundo, mais rápido do que a maioria das pessoas consegue ler. É o caminho mais fácil: compre a GPU, instale llama.cpp ou Ollama e pronto.

O Caminho Multi-GPU

Duas ou mais GPUs permitem dividir um modelo entre dispositivos (paralelismo de tensores). Duas RTX 3090s (48 GB de VRAM no total, ~US$ 2.200 usadas) conseguem rodar confortavelmente modelos de 70B em 4 bits. O porém: você precisa de uma placa-mãe com linhas PCIe suficientes e espaço físico para várias GPUs de tamanho completo. A ventilação vira uma preocupação real — duas GPUs de 350W dentro de um gabinete geram calor considerável.

O Caminho de Memória Unificada

Macs com Apple Silicon e grande memória unificada oferecem uma opção surpreendentemente viável. Um M2 Ultra com 192 GB de memória unificada consegue carregar um modelo de 70B em precisão total inteiramente na memória. A velocidade de inferência é menor que a de GPUs dedicadas — talvez 10 a 15 tokens por segundo para um modelo de 70B —, mas a simplicidade é difícil de superar. Sem problemas de driver, sem configuração multi-GPU, sem gerenciamento térmico. Só um Mac Studio na sua mesa rodando um modelo de 70B.

Os chips da série M alcançam isso com a arquitetura de memória unificada: CPU e GPU compartilham o mesmo pool de memória, então não há gargalo na cópia de dados entre a RAM da CPU e a VRAM da GPU. A largura de banda de memória é menor que a de um setup com GPU dedicada, e é por isso que a inferência é mais lenta, mas ter 192 GB de memória endereçável em um dispositivo que consome 60 watts é genuinamente impressionante.

Dispositivos de Inferência Feitos Sob Medida

A categoria mais nova é a de hardware de inferência local feito sob medida — dispositivos dedicados, projetados especificamente para rodar modelos grandes de forma eficiente. Eles visam resolver a dor de cabeça do multi-GPU: em vez de juntar GPUs de consumo com pesadelos de organização de cabos, você recebe um appliance projetado desde o início para inferência.

A atração é óbvia. Você liga na tomada, aponta sua aplicação para ele e ele roda seu modelo. Sem conflitos de driver, sem gerenciar versões de CUDA, sem thermal throttling porque alguém colocou três GPUs muito próximas. O custo é o trade-off — dispositivos feitos sob medida costumam custar mais por FLOP do que GPUs de consumo equivalentes. Você está pagando por integração, confiabilidade e por não precisar depurar a alocação de linhas PCIe.

Para pequenas empresas que precisam de inferência local mas não têm engenheiros de hardware na equipe, esses dispositivos fazem sentido. Para hobbyistas que gostam de construir coisas, os racks multi-GPU feitos em casa continuam mais baratos e mais flexíveis.

A Stack de Software

Hardware é só metade da história. A stack de software para inferência evoluiu rapidamente, e a escolha certa de software pode dobrar sua vazão no mesmo hardware.

• llama.cpp — O canivete suíço da inferência local. Escrito em C/C++, roda em tudo, desde Raspberry Pis até servidores multi-GPU. Suporta dezenas de arquiteturas de modelo e formatos de quantização. Nem sempre é o mais rápido, mas é o mais portável e o mais ativamente mantido.
• vLLM — Otimizado para throughput em GPUs NVIDIA. Usa PagedAttention para gerenciar a memória da GPU de forma eficiente, o que melhora muito a inferência em lote. Se você atende vários usuários a partir de uma única máquina, o vLLM costuma ser a melhor escolha.
• Ollama — A abordagem do 'Docker para LLMs'. Envolve o llama.cpp em uma interface amigável com um registro de modelos. Rode ollama run llama3:70b e ele baixa o modelo, configura a quantização e começa a servir. Excelente para começar, mas menos configurável que o llama.cpp puro.
• MLX — O framework de machine learning da Apple, otimizado para Apple Silicon. Se você usa um Mac com chip da série M, o MLX normalmente oferece desempenho melhor que o llama.cpp por aproveitar a arquitetura de memória unificada de forma mais eficiente.

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

A Comparação de Custos Sem Enfeites

Vamos fazer a conta que realmente importa. Suponha que você rode um modelo de 70B e processe cerca de 1 milhão de tokens por dia (aproximadamente equivalente a analisar 50 a 100 documentos ou atender algumas centenas de conversas de chat).

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

Com 1 milhão de tokens por dia, a API de nuvem é mais barata por anos. Mas esse cálculo muda drasticamente se o volume aumentar. Com 10 milhões de tokens por dia, a API custa US$ 7.200 por ano e o hardware local se paga em cerca de 7 meses. Com 50 milhões de tokens por dia, a inferência local se paga em semanas.

A comparação de custos também ignora os fatores não financeiros: privacidade, latência, disponibilidade e liberdade para experimentar. Se algum deles for requisito (e não apenas um desejo), a comparação financeira passa a ser secundária.

O Que Se Perde na Quantização

A quantização é o que torna a inferência local possível para modelos grandes, mas ela não é de graça. Reduzir a precisão significa perder alguma informação, e a degradação não é uniforme entre as tarefas.

Nos meus testes, modelos quantizados em 4 bits tiveram desempenho quase idêntico à precisão total em: geração de texto, sumarização, Q&A simples, tradução e geração de código para padrões comuns. A degradação aparece em: raciocínio complexo de múltiplos passos, cálculos matemáticos, tarefas que exigem recordação precisa de dados de treinamento e seguimento de instruções com nuances.

Na prática: se você usa um modelo local para completar código, sumarizar documentos ou IA conversacional, a quantização de 4 bits é perfeitamente adequada. Se você o usa para raciocínio analítico complexo ou em tarefas nas quais diferenças sutis de precisão importam, vale testar com cuidado e, possivelmente, usar precisão maior, ao custo de mais memória ou de um modelo menor.

Tomando a Decisão

Depois de um ano rodando modelos localmente, esta é minha estrutura para decidir entre inferência local e na nuvem:

Use APIs de nuvem quando: você precisar da melhor qualidade de modelo possível, seu volume for baixo a moderado, você não tiver expertise em hardware, precisar trocar de modelo com frequência ou latência não for crítica (algumas centenas de milissegundos são aceitáveis).

Rode localmente quando: seus dados não puderem sair da sua rede, você precisar de latência consistente abaixo de 100ms, seu volume de tokens for alto o suficiente para justificar o custo de hardware, você quiser experimentar livremente sem custo por consulta, ou precisar de disponibilidade de inferência independente do uptime de terceiros.

O cenário está mudando rápido. Os modelos estão ficando menores e mais eficientes. As técnicas de quantização estão melhorando. O hardware está ficando mais barato. O limiar de volume em que a inferência local faz sentido financeiro cai a cada ano. Se não faz sentido para você hoje, pode fazer em dezoito meses — e a stack de software só vai ficar mais fácil de usar nesse meio-tempo.