IA local: como executar modelos de IA no teu próprio computador (guia 2026)

Cada prompt que escreves no ChatGPT viaja para um servidor que não controlas, custa-te dinheiro (direta ou indiretamente) e deixa de funcionar assim que ficas sem internet. Durante anos essa foi a única forma de usar IA decente. Já não é.

Em 2026, descarregar um modelo de linguagem e corrê-lo no teu próprio computador é questão de minutos e de uns poucos gigas de RAM. Não é uma experiência para fanáticos do terminal: há apps com interface que o tornam tão simples como instalar o Spotify. Este guia leva-te do "não faço ideia" ao "tenho um modelo a responder-me offline", entendendo cada decisão pelo caminho.

Porquê executar IA em local

Há três razões que se sustentam sozinhas, e o resto são nuances.

Privacidade real. Os teus prompts e as respostas nunca saem do computador. Nada de logs num servidor alheio, nada de "podemos rever as tuas conversas", nada de fugas por uma brecha na nuvem. Se trabalhas com dados de clientes, minutas legais, informação médica ou qualquer coisa que não queiras carregar para um terceiro, isto muda as regras do jogo.

Custo zero por utilização. Pagas uma vez —o hardware que já tens— e depois geras tudo o que quiseres sem um contador de tokens a correr. Se fazes volume (classificar milhares de textos, resumir em ciclo, prototipar à base de tentativa e erro), a diferença face a uma API paga é brutal.

Funciona offline. Sem internet, sem quedas de serviço, sem "o modelo está sobrecarregado, tenta mais tarde". Num avião, numa zona sem cobertura ou no dia em que o fornecedor tem um incidente, a tua IA continua ali.

Em troca abdicas de algo: o teto de qualidade. Falaremos disso no fim, mas adianto a conclusão honesta: para a maioria das tarefas do dia a dia, um bom modelo local de 2026 chega e sobra.

O fluxo, num relance

Antes de mexer em nada, convém ter o mapa mental. Usar IA local são sempre as mesmas quatro decisões encadeadas:

Se entendes estes quatro passos, entendes 90% do tema. O resto é escolher bem dentro de cada um.

Requisitos de hardware (a pergunta que todos fazem)

A dúvida número um é "será que o meu computador aguenta?". A resposta depende do tamanho do modelo e da quantização, mas há regras práticas claras.

O que manda é a memória: quanta RAM (se corres em CPU) ou VRAM (se tens GPU dedicada) tens livre para carregar o modelo. Como referência, com quantização a 4 bits (Q4_K_M):

• Modelos de 7-8B parâmetros → cerca de 5 GB de ficheiro, correm com 8 GB de RAM/VRAM. É o ponto de partida recomendado.
• Modelos de 13-14B → pedem à volta de 16 GB.
• Modelos de 70B → rondam os 40 GB; território de computadores potentes ou várias GPU.

Três esclarecimentos importantes:

1. Sem GPU também dá. Qualquer portátil moderno corre um 7B em CPU; irá mais devagar (umas poucas palavras por segundo) mas funciona. Com uma GPU dedicada de 8 GB para cima, a coisa voa.
2. Mac com Apple Silicon joga com vantagem. Os chips M partilham a memória entre CPU e GPU (memória unificada), por isso um Mac com 16 GB move modelos que num PC pediriam uma gráfica dedicada. Além disso, em 2026 as ferramentas usam o motor MLX nativo da Apple, que vai mais rápido e consome menos.
3. Deixa margem. O modelo não é o único que ocupa memória: a janela de contexto (a KV cache), o sistema operativo e os restantes programas também puxam. Regra saudável: não enchas a memória a 100%, deixa 10-15% de ar.

Quantização e GGUF, sem tecnicismos

Esta é a peça que mais assusta e a mais fácil de entender com uma analogia. Um modelo "original" guarda cada um dos seus milhares de milhões de parâmetros com muita precisão (16 bits). Quantizar é arredondar esses números para menos bits —8, 5 ou 4— para que o ficheiro ocupe muito menos e vá mais rápido. É como passar de um WAV sem compressão para um MP3 de boa qualidade: ocupa uma fração e, na prática, quase não notas a diferença.

GGUF é simplesmente o formato de ficheiro padrão para isto em local: um único ficheiro que empacota os pesos, o tokenizador e os metadados. Quando procurares modelos vais ver nomes como modelo-7B-Q4_K_M.gguf. Esse sufixo é o nível de quantização, e isto é o único que precisas de recordar:

• Q4_K_M → o ponto ideal. Reduz o tamanho ~75% com apenas 3-5% de perda de qualidade. Se tens dúvidas, este.
• Q5_K_M / Q6_K → um pouco maiores e melhores; útil para código ou raciocínio se te sobrar memória.
• Q8_0 → quase idêntico ao original; só se andares à vontade de RAM/VRAM.
• Q3_K_M / Q2_K → para quando andas muito apertado de memória; nota-se mais a perda.

O "K_M" significa que distribui melhor os bits nas camadas que mais importam para a qualidade. Por isso quase sempre vale mais um Q4_K_M do que um Q4 simples.

Que ferramenta escolher (e para quem)

Todas as ferramentas sérias leem GGUF e usam por baixo o mesmo motor (llama.cpp ou, no Mac, MLX), por isso a velocidade entre elas é quase idêntica. Escolhes por interface e pelo que vais fazer, não por desempenho.

Este é o guia rápido consoante o teu perfil:

• LM Studio — para começar sem complicações. App de secretária com interface polida: procuras o modelo pelo nome, vês quanta RAM pede e se a tua máquina o aguenta, carregas em descarregar e conversas. Zero terminal, zero ficheiros de configuração. Se nunca mexeste nisto, começa aqui.
• Jan — para quem prioriza privacidade e open source. Offline por defeito e com todo o código auditável. Traz a sua própria interface de chat e a filosofia "os teus dados são teus". A escolha se a abertura não é negociável.
• Ollama — para programar e integrar. Funciona por linha de comandos e, o importante, levanta uma API local compatível com a OpenAI. Isso significa que podes ligar o teu modelo local a qualquer app ou script que já usasse a API da OpenAI mudando só o URL. É a peça para construir coisas. Temos um guia dedicado ao Ollama.
• llama.cpp — para espremer o hardware. Não é uma app com interface: é o motor que move as outras. Só desces aqui se quiseres otimizar ao milímetro. Para começar, ignora-o.

Passo a passo: o teu primeiro modelo em local

Vamos com o caminho mais rápido para um resultado. Coloco-o com Ollama porque deixa a API pronta a integrar, mas com o LM Studio seria literalmente "procurar → descarregar → conversar" a partir da interface.

1. Instala o Ollama. Descarrega-o do site (macOS, Windows e Linux) e instala-o como qualquer programa. No Mac e no Windows traz app de secretária; no Linux vai por terminal.

2. Descarrega e executa o teu primeiro modelo. Um único comando baixa o modelo quantizado e arranca-o:

# Arranca um modelo de 8B (descarrega-o na primeira vez)
ollama run llama3.1:8b

# A partir daí, escreves e conversas no terminal.
# Para sair: /bye

A primeira vez demora o que pesar o ficheiro (uns GB). Nas seguintes, o modelo já está em disco e arranca no instante.

3. Verifica o que tens instalado. Útil quando acumulas vários modelos:

# Lista os modelos que tens descarregados
ollama list

# Testa um modelo pequeno e rápido para tarefas leves
ollama run llama3.2:3b

# Apaga um que já não uses para libertar disco
ollama rm llama3.1:8b

4. Integra-o nas tuas apps (opcional). Aqui está a magia para quem programa. O Ollama expõe uma API local em localhost:11434 compatível com o formato da OpenAI:

curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Resume isto numa frase: ..."}]
}'

Mudando o URL base do teu código de api.openai.com para localhost:11434, qualquer app que usasse a OpenAI passa a correr contra o teu modelo local. Sem custo, sem enviar nada para fora.

Os limites (para que não leves surpresas)

Nenhuma análise honesta esconde as letras miudinhas, por isso aqui vão:

• Qualidade com teto. Um 7-14B local não raciocina como o GPT ou o Claude em problemas complexos, código difícil ou cadeias longas de lógica. Para isso, a nuvem continua a ganhar.
• Contexto mais curto. As janelas de contexto gigantes consomem muita memória em local. Se precisas de meter documentos enormes de uma vez, vais sofrer.
• O hardware é o limite. Não podes correr um modelo de 70B num portátil de 8 GB, por muito que o quantizes. A memória manda.
• Velocidade variável. Em CPU pura, um 7B cospe umas poucas palavras por segundo. É usável, mas não esperes a fluidez de um serviço na nuvem com GPUs dedicadas.

Nenhum destes é um defeito: são o preço de ter a IA na tua própria casa. Sabê-los de antemão evita a desilusão de pedir a um modelo local algo para o qual não está feito.

Para quem é a IA local?

Interessa-te se: trabalhas com dados sensíveis que não queres carregar para a nuvem, fazes volume e o custo por token te dói, precisas que funcione offline, ou simplesmente queres aprender como funciona a IA por dentro sem depender de ninguém. Também se és programador e queres prototipar e integrar sem gastar em API cada vez que testas algo.

Não te interessa se: só usas IA de forma pontual e a qualidade máxima importa-te mais do que a privacidade ou o custo, o teu computador anda muito apertado de memória, ou não queres dedicar nem dez minutos a instalar seja o que for. Para esse caso, uma IA na nuvem —ou uma intermédia como o OpenRouter, que te dá muitos modelos por uma só API— encaixa melhor.

A pergunta honesta não é "a IA local é melhor do que o ChatGPT?". Não é no teto, nem pretende. A pergunta é "quanto vale para mim que os meus dados não saiam do meu computador, não pagar por cada utilização e poder trabalhar sem internet?". Se a resposta é "bastante", em 2026 montá-lo custa-te dez minutos e uns gigas de disco. Nunca foi tão fácil ter a tua própria IA, verdadeiramente tua.