Como rodar uma IA local: Guia prático para IA Open Source em 2026

Autor: Pedro Tebaldi PM do KeepGreen

Publicado jun/2026Atualizado set/2026

Rodar uma IA local open source deixou de ser exercício de laboratório. Hoje, virou opção viável para times de TI que querem privacidade, controle de custos e independência de APIs externas. Em 2026, modelos como Llama 3, Qwen e Mistral oferecem qualidade competitiva em hardware acessível. Ferramentas como Ollama transformam o que antes exigia engenharia de ML em um comando de terminal.

Entretanto, a mudança traz responsabilidades novas. É preciso dimensionar hardware, escolher o nível certo de quantização, instrumentar a inferência e medir custo total contra o que você pagaria em APIs comerciais. Este guia mostra como rodar uma IA local open source com mentalidade de operação. O foco não é só instalar o modelo, mas operá-lo como uma carga de trabalho real.

Vamos cobrir os requisitos honestos de hardware, as principais ferramentas em 2026 e os modelos que valem o disco. Sobretudo, vamos mostrar como monitorar a inferência local com métricas que importam para times de TI.

Por que rodar IA local em vez de usar APIs na nuvem

A escolha por uma IA local é técnica e estratégica ao mesmo tempo. Empresas com dados sensíveis, como áreas jurídicas, de saúde e financeira, enfrentam barreiras de compliance ao enviar informação para APIs externas. Rodar localmente elimina esse risco, pois nada sai do perímetro da empresa.

Além disso, o custo de inferência em larga escala muda completamente. Uma API paga por token cobra a cada chamada. Um modelo local, em contrapartida, depende só do investimento inicial em hardware e energia. Para volumes acima de algumas centenas de milhares de requisições por mês, o break-even costuma cair em poucos meses.

Outro ganho importante é a latência. Sem ida e volta para servidores remotos, o tempo de resposta cai de forma significativa. Aplicações que precisam de feedback rápido, como assistentes embarcados ou automações internas, se beneficiam de imediato.

Vale destacar que essa autonomia conversa com práticas modernas de cyber security ao reduzir a exposição de dados sensíveis a fornecedores terceiros. Para times que já operam em computação em nuvem, o modelo híbrido vira opção interessante.

Requisitos de hardware: o que você realmente precisa

Não existe um único patamar de hardware para rodar IA local. Tudo depende do tamanho do modelo escolhido, do nível de quantização e do throughput desejado. Um modelo de 1 bilhão de parâmetros roda em um notebook comum, enquanto um de 70 bilhões exige servidor com GPU dedicada.

A regra geral envolve três recursos. RAM determina se o modelo cabe na memória, VRAM da GPU acelera a inferência e armazenamento SSD reduz o tempo de carregamento. CPU moderna com suporte a instruções AVX2 já é suficiente para começar sem GPU dedicada.

Por isso, o melhor caminho é começar pequeno e escalar conforme o caso de uso. A tabela abaixo mostra a relação entre tamanho do modelo, RAM e GPU recomendada para inferência fluida em 2026.

 
Vale lembrar que tratamos os modelos locais como qualquer outra carga de TI. Eles consomem CPU, memória, disco e energia. Por isso, merecem o mesmo cuidado de capacity planning aplicado ao monitoramento de servidores tradicional.

Para sair da recomendação e chegar ao número, subimos o Llama 3.1 8B em dois servidores Ollama na mesma máquina. Um enxerga a placa de vídeo, o outro não enxerga nenhuma. Assim, valem o mesmo modelo, o mesmo prompt e a mesma semente.

O teste rodou em 3 de setembro de 2026, com Ollama 0.33.2 em Docker. A máquina é um Ryzen 5 5600X de 6 núcleos com uma GeForce RTX 3060 Ti de 8 GB. Cada valor abaixo, vale dizer, é a mediana de cinco respostas de 200 tokens.

 
A placa entregou 12,6 vezes mais tokens por segundo. Além disso, a primeira letra da resposta saiu em 18 milissegundos contra 200 na CPU.

A CPU, ainda assim, não fica inútil. Ela dá conta, por exemplo, de chat interno e de RAG sem pressa, desde que uma pessoa use por vez. O que a CPU não sustenta é concorrência, porque cada requisição simultânea disputa os mesmos núcleos.

Quantização: a chave para rodar modelos grandes em hardware modesto

Quantização é a técnica que reduz a precisão numérica dos pesos do modelo, transformando floats de 16 bits em representações de 4 ou 5 bits. O resultado: o mesmo modelo passa a ocupar 4 a 8 vezes menos memória, com perda de qualidade pequena em tarefas práticas.

Em termos práticos, isso significa rodar um modelo de 13B em uma máquina de 16 GB que originalmente só comportaria um 7B. O formato mais popular hoje é o GGUF, com variações como Q4_K_M, Q5_K_M e Q8_0. Cada uma equilibra qualidade e consumo de memória de forma diferente.

Por isso, a recomendação prática é começar com Q4_K_M, que oferece o melhor custo-benefício. Em seguida, se o caso de uso exigir mais qualidade, suba para Q5_K_M.

Sobre o Q8_0, medimos os dois extremos na mesma placa de 8 GB. Em disco o Q4_K_M ocupa 4,92 GB e o Q8_0 ocupa 8,54 GB, o que parece apenas uma questão de espaço.

 
O Q8_0 não coube na placa. Com 8,54 GB de pesos para 8 GB de VRAM, o Ollama repartiu as camadas entre placa e processador. Como resultado, a velocidade caiu 8,5 vezes e parou perto dos 5,9 tokens por segundo da CPU pura.

Quem denuncia a repartição é o ollama ps, na coluna PROCESSOR.

# Q4_K_M: cabe inteiro na placa
ollama ps
NAME           ID              SIZE      PROCESSOR    CONTEXT
llama3.1:8b    46e0c10c039e    5.3 GB    100% GPU     4096

# Q8_0: um terco das camadas voltou para o processador
ollama ps
NAME                         ID              SIZE      PROCESSOR          CONTEXT
llama3.1:8b-instruct-q8_0    b158ded76fa0    9.3 GB    33%/67% CPU/GPU    4096

O nvidia-smi, em contrapartida, não ajuda aqui. Ele marcou 6.934 MiB ocupados no caso bom e 7.782 MiB no caso ruim. Ou seja, o pior dos dois parece até melhor aproveitado.

A regra prática, portanto, muda de lado. Escolha a quantização que cabe na sua VRAM em vez da que promete mais qualidade.

Principais ferramentas para rodar IA local em 2026

O ecossistema de IA local amadureceu rápido. Cada ferramenta atende um perfil diferente, do desenvolvedor individual ao servidor de produção. Escolher errado significa fricção desnecessária, então vale entender o que cada uma resolve antes de instalar.

Ollama é o ponto de entrada mais popular. Funciona como um daemon local, expõe API REST em localhost:11434 e gerencia download e troca de modelos com um único comando. Para quem prefere interface gráfica, o LM Studio oferece a mesma facilidade com chat embutido e configuração visual de parâmetros.

Por outro lado, para cenários mais exigentes existem alternativas robustas. O llama.cpp é a biblioteca C++ que serve de base para muitas dessas ferramentas e permite controle fino. Já o vLLM entrega throughput elevado com batching contínuo, ideal para times que querem servir o modelo para múltiplos usuários simultâneos.

Inclusive, esse mesmo princípio de projetos open source orientados a infraestrutura é o que fez o Zabbix e o Grafana virarem padrão de mercado.

 
Em resumo, comece pelo Ollama se você é dev ou está montando um servidor para um time pequeno. Migre para vLLM quando precisar servir dezenas de usuários simultâneos com latência previsível.

Modelos open source recomendados em 2026

Em 2026, a oferta de modelos open source explodiu em qualidade. A escolha não é mais entre “rodar local com qualidade ruim” ou “pagar API com qualidade boa”. Hoje, modelos abertos competem de igual para igual com soluções proprietárias em várias tarefas.

Esta seção tem data. A data importa mais que a lista. Consultamos a biblioteca oficial do Ollama em 3 de setembro de 2026, perguntando ao registro se cada versão existia naquele dia.

# Pergunta ao registro oficial do Ollama se a versao existe HOJE.
# 200 = publicada, 404 = nao existe. E o mesmo endereco que o ollama pull usa.
curl -s -o /dev/null -w "%{http_code}" \
  https://registry.ollama.ai/v2/library/qwen3/manifests/8b

# Saida da varredura em 2026-09-03:
llama3.1:8b                  publicado
llama3.2:3b                  publicado
llama3.3:70b                 publicado
llama4:scout                 publicado
qwen2.5:7b                   publicado
qwen3:8b                     publicado
qwen3.6:27b                  publicado
qwen3.8:27b                  publicado
deepseek-r1:8b               publicado
gemma3:12b                   publicado
phi4:latest                  publicado
mistral:7b                   publicado
gpt-oss:20b                  publicado

A consulta não devolve um ranking, devolve o ritmo. O Llama 3.1 do exemplo anterior continua publicado, mas divide a prateleira com Llama 3.3 e Llama 4. Da mesma forma, o Qwen 2.5 convive com Qwen 3, 3.6 e 3.8.

Por isso, guarde o comando em vez da lista. Ele responde 200 para versão publicada e 404 para versão que não existe, sem depender de ranking de terceiro nem de artigo parado no tempo.

Trocar de geração pesa na infraestrutura? Medimos o Qwen 3 8B contra o Llama 3.1 8B na mesma placa: 66,6 contra 73,7 tokens por segundo, com 5,6 GB contra 5,3 GB de memória.

A geração nova, portanto, roda no mesmo hardware. Cabe o aviso: isso mede velocidade e espaço, não qualidade de resposta. Comparar qualidade exige benchmark que não rodamos aqui.

Para tarefas específicas, modelos especializados costumam superar generalistas maiores. CodeLlama e StarCoder dominam tarefas de programação, enquanto a família Phi, da Microsoft, entrega qualidade surpreendente em modelos pequenos. Os pesos de cada um estão disponíveis no Hugging Face Hub com licenças permissivas para uso comercial.

Passo a passo: rodando seu primeiro modelo com Ollama

Vamos colocar a mão na massa. O Ollama é a forma mais rápida de sair do zero. Funciona em macOS, Windows e Linux com instalador único. Em menos de cinco minutos você tem um modelo respondendo no terminal.

Após baixar o instalador no site oficial, abra o terminal e rode o comando abaixo para iniciar o Llama 3.1 8B. Na primeira execução, o Ollama baixa o modelo (4,92 GB no formato Q4_K_M, medido no pull) e abre o prompt interativo.

# Inicia o modelo Llama 3.1 8B (download na primeira execução)
ollama run llama3.1:8b

# Lista modelos instalados localmente
ollama list

# Inferência via API REST em localhost:11434
curl http://localhost:11434/api/generate \
  -d '{"model":"llama3.1:8b","prompt":"Explique SLO em uma frase"}'

A primeira chamada demora porque o Ollama carrega o modelo na memória antes de responder. Medimos a mesma pergunta nos dois estados: 4.872 milissegundos com o modelo fora da memória contra 556 com ele residente. A documentação oficial da API cobre streaming, embeddings e ajustes de temperatura.

Existe uma armadilha aí. Ela morde em produção. O Ollama tira o modelo da memória depois de 5 minutos ocioso, que é o padrão de OLLAMA_KEEP_ALIVE. Em seguida, deixamos o laboratório parado exatamente esse tempo e repetimos a pergunta.

# A mesma pergunta, ao mesmo servidor, em tres momentos
momento         carga       total       estado
primeira vez    4.260 ms    4.872 ms    modelo fora da memoria
logo depois     1 ms        556 ms      modelo residente
apos 5 min      3.935 ms    4.564 ms    descarregado pelo keep_alive

Ninguém tocou no servidor entre a segunda e a terceira linha. Só passou o tempo. Quem voltar depois do almoço espera os 4,6 segundos de novo e conclui que a IA local é lenta.

Em servidor compartilhado, portanto, defina OLLAMA_KEEP_ALIVE=-1 e o modelo fica residente. O preço é a memória ocupada o tempo todo, então a escolha é de capacidade e não de conveniência.

Por padrão, o Ollama escuta em localhost:11434, o que permite integrá-lo a aplicações via REST. Para isolar a execução, vale rodar tudo dentro de containers Docker, sobretudo quando você quer reproduzir o ambiente em outras máquinas ou versionar o setup.

Quem prefere não viver no terminal tem o Open WebUI, a interface web que conversa com esse mesmo endereço. Ela sobe em outro container e, em seguida, abre no navegador com os modelos já disponíveis.

A tela abaixo mostra o Llama 3.1 8B do nosso laboratório respondendo em português, com o nome do modelo acima da resposta.

 
A instalação padrão, porém, contraria o motivo de rodar local. Ela já vem com o conector da OpenAI ligado, apontando para api.openai.com.

 
O log do laboratório confirmou a chamada: a interface procurou o endereço e recebeu de volta um erro de autenticação, porque não existe chave configurada. O que sai nessa requisição é o pedido da lista de modelos, nunca o texto das conversas.

Mesmo assim, desligue o conector quando o argumento da sua operação é que nada sai do perímetro. Ou seja, um endpoint externo ativo por padrão merece decisão consciente, não descoberta em auditoria.

Monitorando a inferência local: métricas que times de TI precisam acompanhar

Aqui está o ponto que separa um experimento técnico de uma operação séria. Rodar IA local sem observabilidade é como subir um banco de dados sem monitoração de queries. Funciona no começo, mas falha silenciosamente quando o uso cresce. Cabe ressaltar que LLM local é uma carga de trabalho como qualquer outra. Por isso, merece o mesmo tratamento dado a bancos, filas e serviços críticos.

As métricas essenciais para acompanhar inferência local são quatro. Tokens por segundo mede a velocidade de geração. Time To First Token (TTFT) revela a latência percebida pelo usuário. Uso de VRAM indica saturação da GPU. Por fim, profundidade da fila mostra quando o servidor não dá conta da demanda.

As três primeiras, no entanto, não exigem exporter nenhum. O próprio Ollama devolve os tempos, em nanossegundos, no fim de cada resposta da API.

{
  "model": "llama3.1:8b",
  "done_reason": "length",
  "total_duration": 6406491767,
  "load_duration": 5773643480,
  "prompt_eval_count": 22,
  "prompt_eval_duration": 83133000,
  "eval_count": 40,
  "eval_duration": 547255000
}

Daí saem as contas. Tokens por segundo, por exemplo, é eval_count dividido por eval_duration. O tempo até a primeira letra é load_duration somado a prompt_eval_duration. É ele que o usuário sente como demora.

Repare no load_duration acima: 5,77 segundos numa resposta de 6,4. Esse campo, vale destacar, só fica alto quando o modelo não estava na memória. Em horário de pico, portanto, um load_duration diferente de zero denuncia que o keep_alive expirou entre duas perguntas.

A mesma conta aparece pronta na interface. O Open WebUI exibe esses campos por resposta. A captura abaixo traz 67,07 tokens por segundo com o modelo já residente.

Inclusive, esses sinais conversam diretamente com os pilares da observabilidade tradicionais. Tokens por segundo é uma métrica de throughput. TTFT equivale à latência p50 ou p95. Uso de VRAM é um gauge de recurso e a fila é um indicador de saturação. Nada disso é novo para quem já opera com observabilidade.

Por isso, soluções como o OpMon conseguem instrumentar e correlacionar essas métricas com o resto da infraestrutura. Dessa forma, fica claro se o gargalo está no modelo, na GPU ou em um serviço dependente. Ademais, exporters Prometheus já existem para Ollama e vLLM, prontos para entrar no dashboard ao lado de CPU, memória e disco.

Quando IA local faz sentido (e quando não faz)

Nem todo cenário pede IA local. O ponto de equilíbrio depende de volume, sensibilidade dos dados e tolerância a latência. Vamos a três perfis comuns que aparecem em times de TI brasileiros.

Para times pequenos com dados sensíveis, IA local entrega valor de imediato. Um servidor com GPU dedicada custa na casa dos R$ 20 mil e atende uma equipe inteira para chat, RAG interno e automações.

Quanto tempo esse hardware leva para se pagar? A saída de um modelo comercial de entrada custa US$ 5,00 por milhão de tokens. Na cotação do Banco Central de 2 de setembro de 2026, isso dá R$ 25,64.

 
São 128 dias de placa gerando texto sem parar, 24 horas por dia. Nenhum time usa assim.

A GPU passa a maior parte do tempo ociosa, portanto o prazo real estica na mesma proporção da ociosidade. Uma placa ocupada 10% do dia leva dez vezes mais tempo para empatar.

A energia entra por cima. Medimos 239 W com a placa gerando contra 26 W parada, o que dá 0,94 kWh por milhão de tokens. Até o empate são 735 kWh só de GPU, fora processador, memória e refrigeração.

Ou seja, a pergunta que decide não é o preço por token. É a taxa de ocupação. E quando o motivo é privacidade, a conta muda de natureza: o gasto compra conformidade, não desconto.

Por outro lado, para volumes pequenos e tarefas pontuais, APIs ainda fazem sentido. Pagar por uso evita o trabalho de operar a stack. Inclusive, o custo total raramente justifica o esforço. Da mesma forma, quando você precisa do modelo de fronteira mais recente, APIs comerciais costumam estar à frente em poucos meses.

Em resumo, a regra prática fica assim: se o volume é alto, os dados são sensíveis ou a latência importa, vá de local. Se o volume é baixo e o caso de uso é experimental, comece pela API e migre quando o consumo justificar.

Conclusão

Rodar uma IA local open source em 2026 é mais simples do que parece no primeiro contato. Ferramentas como Ollama eliminam a fricção inicial. Modelos como Llama 3 e Qwen entregam qualidade competitiva. A quantização permite usar hardware acessível. O caminho técnico, em síntese, está pavimentado.

O desafio, por outro lado, não está em ligar o modelo, mas em operá-lo. Falta de monitoração, dimensionamento errado de hardware e ausência de governança transformam uma instalação fácil em um problema operacional silencioso. Por isso, encare o LLM local como qualquer outra carga crítica e instrumente do dia zero.

Se sua equipe quer integrar IA local à operação de TI com observabilidade desde o início, fale com um especialista da OpServices. Vamos desenhar o stack adequado ao seu volume e ao seu perfil de risco.