Se você já anda a usar ferramentas de IA há algum tempo, provavelmente já passou por isto: encontra um modelo open source que parece brutal, quer testá-lo na sua própria máquina e, dez minutos depois, já está metido no caos do costume. Não sabe se a sua GPU aguenta, não percebe quanta VRAM realmente precisa e acaba por descarregar uma coisa tão pesada que o computador parece estar a pedir socorro.
Executar modelos localmente soa muito bem e, em muitos casos, vale mesmo a pena. Tem mais privacidade, controla melhor o custo, não depende de uma API externa e pode montar fluxos bastante potentes no seu próprio hardware. Mas também há muito teatro à volta disto. Nem toda a gente precisa de IA local e nem todas as máquinas estão feitas para correr certos modelos sem sofrer.
Neste post vamos fazer isto como deve ser. Primeiro ver se a sua máquina aguenta usando CanIRun.ai, depois instalar Ollama, descarregar um modelo, testá-lo localmente e, a partir daí, ligá-lo a ferramentas como Open Code ou Cloud Code se quiser usar esse modelo no seu fluxo do dia a dia.
Porque é que pode fazer sentido correr IA localmente
O primeiro motivo costuma ser o mais óbvio: privacidade. Se está a trabalhar com código, notas, documentos internos ou simplesmente não gosta da ideia de mandar tudo para terceiros, correr o modelo na sua própria máquina dá-lhe um nível de controlo muito diferente.
O segundo motivo é o custo. No momento em que começa a usar APIs a sério, sobretudo para programar ou iterar muito, a conta deixa de ter piada. Em local paga em hardware e eletricidade, claro, mas em troca pode experimentar sem estar sempre a olhar para o contador.
E o terceiro, que para mim é dos mais interessantes, é o controlo. Pode escolher o modelo que quiser, mudar quantizações, testar um afinado para código, outro para raciocínio, outro para RAG, e montar um fluxo muito mais alinhado com a forma como trabalha. Não fica dependente de uma empresa mudar o modelo, meter limites estranhos ou cortar uma funcionalidade de um dia para o outro.
Agora, um ponto importante: local não significa automaticamente melhor. Se tem um portátil mais modesto, ou se quer correr um modelo de 30B como se as leis da física fossem opcionais, a realidade vai bater forte. E por isso convém começar pelo que quase toda a gente ignora.
Antes de descarregar seja o que for, veja se a sua máquina aguenta
A forma mais rápida de deixar de perder tempo é entrar em CanIRun.ai. Esse site deteta a sua máquina e mostra, com estimativas bastante úteis, que modelos devem correr bem, quais ficam no limite e quais são simplesmente má ideia.
A parte boa é que não fica só pelo nome do modelo. Mostra VRAM, tamanho de contexto e diferentes quantizações, que é exatamente o que precisa de olhar se não quiser ir às cegas.
Se no CanIRun.ai um modelo aparecer como Runs great ou Runs well, ótimo. Se aparecer como Tight fit ou Barely runs, isso não quer dizer impossível, mas é um aviso claro de que provavelmente vai sacrificar velocidade, contexto ou estabilidade. E se o site disser que o modelo é pesado demais, não tente ser esperto. Não há problema nenhum em começar por um modelo mais pequeno. Muita gente quer começar logo por um monstro porque fica mais bonito dizer isso no X ou no YouTube. Isso não é engenharia. É vaidade.
A VRAM é o que realmente manda nisto
Aqui está uma das ideias-chave. Quando falamos de correr modelos localmente, não interessa apenas ter uma GPU, mas sim quanta VRAM essa GPU tem.
VRAM é a memória da gráfica. E é aí que, idealmente, quer meter os pesos do modelo e boa parte do trabalho de inferência. Se o modelo cabe confortavelmente aí, a experiência muda completamente. Se não cabe, começam os remendos: uma parte vai para a RAM, outra passa para CPU, a latência sobe e aquilo que em teoria ia usar todos os dias transforma-se num castigo.
Por isso não chega pensar “este modelo é 7B” ou “aquele é 14B”. A quantização também conta. O mesmo modelo pode ocupar muito menos em Q4_K_M do que em Q8_0 ou F16, mas isso não vem de graça: está a equilibrar memória, qualidade e desempenho.
A forma simples de pensar nisto é esta:
- Se estiver curto de VRAM, interessam-lhe modelos mais pequenos ou quantizações mais agressivas.
- Se tiver VRAM de sobra, pode subir de tamanho ou usar quantizações mais confortáveis.
- Se o modelo “quase cabe”, a experiência real costuma ser pior do que muita gente imagina.
E atenção a mais uma coisa: a VRAM não afeta apenas se o modelo arranca ou não. Também afeta quanto contexto consegue usar e a velocidade real quando começa a meter prompts longos, ferramentas ou fluxos de código. Um modelo que responde mais ou menos bem a uma pergunta curta pode cair logo quando lhe pede trabalho sério.
Nota: o CanIRun.ai dá uma estimativa muito útil, mas continua a ser uma estimativa. Use-o como filtro inicial, não como verdade absoluta gravada em pedra.
Instalar o Ollama sem complicar a vida
Se o que quer é levantar modelos localmente sem transformar isto num projeto paralelo, Ollama é uma das opções mais cómodas neste momento. Instala, descarrega o modelo e siga. Sem acrobacias estranhas com runtimes nem drama desnecessário.
Em Linux ou macOS pode instalá-lo assim:
curl -fsSL https://ollama.com/install.sh | shSe estiver em Windows, o mais sensato é descarregar o instalador do site oficial ou usar WSL se o seu fluxo já vive aí.
Quando tiver isso pronto, confirme que ficou bem instalado:
ollama --versionE se quiser verificar que o serviço local está de pé e a expor o endpoint compatível com OpenAI, faça este teste:
curl http://localhost:11434/v1/modelsEsse detalhe importa porque é exatamente isso que depois lhe permite ligar o Ollama a outras ferramentas.
Descarregar um modelo com ollama pull
Aqui entra o critério. Não comece pelo modelo mais bruto que viu numa comparação qualquer. Comece por algo que a sua máquina consiga mesmo correr.
Para programação ou testes gerais, um ponto de partida bastante sensato é este:
ollama pull qwen2.5-coder:7bSe quiser algo mais generalista, também pode olhar para famílias como qwen3:8b, llama3.1:8b ou algum modelo pequeno da Gemma, mas a ideia principal é a mesma: escolha em função do seu hardware, não do hype.
Quando a descarga terminar, pode listar o que tem localmente:
ollama listIsso mostra-lhe o nome exato do modelo para usar depois em CLI ou em clientes externos.
Teste o modelo localmente antes de o enfiar noutras ferramentas
Isto é mais importante do que parece. Antes de o ligar ao Open Code, Cloud Code ou qualquer fluxo com agentes, teste-o diretamente. Assim percebe se responde bem, se é demasiado lento ou se a máquina começa logo a sofrer.
O teste mais simples é este:
ollama run qwen2.5-coder:7bDepois, lá dentro, pode pedir-lhe algo básico mas útil, por exemplo:
Escreve uma função debounce em TypeScript e explica porque funciona.Se já notar lentidão aqui, não espere milagres quando o meter dentro de um fluxo com ferramentas, contexto longo e código real. IA local fica muito bonita numa demo, mas o que interessa é se lhe serve mesmo no trabalho do dia a dia.
Como usá-lo depois com Open Code e Cloud Code
Aqui é que a coisa fica interessante. O Ollama expõe compatibilidade com a API da OpenAI em http://localhost:11434/v1, e isso abre a porta a qualquer cliente que suporte endpoints OpenAI-compatible.
No Open Code, isto encaixa bastante bem porque permite configurar providers personalizados e modelos locais. Um exemplo de configuração seria algo assim:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen2.5-coder:7b": {
"name": "Qwen 2.5 Coder 7B (local)"
}
}
}
}
}Com isso, o Open Code consegue falar com o seu modelo local como se fosse só mais um provider, mas sem sair da sua máquina.
No Cloud Code, ou em qualquer cliente parecido, a ideia é a mesma se ele permitir configurar um provider compatível com OpenAI ou uma baseURL personalizada. Se deixar, aponte para:
http://localhost:11434/v1E use como nome do modelo aquele que já tem carregado no Ollama.
Se a ferramenta não permitir mudar o endpoint e só funcionar com APIs fechadas do fornecedor, então não vai conseguir ligar o Ollama diretamente e pronto. Mais vale dizer isto sem rodeios. Às vezes o problema não é a sua máquina. É que o cliente não foi pensado para esse fluxo.
Expectativas realistas: local é útil, mas não faz magia
Esta é a parte que a internet adora maquilhar. Se tiver uma GPU decente e escolher bem o modelo, consegue montar uma experiência realmente útil. Mas não espere que um modelo local pequeno renda como o melhor modelo cloud do momento em tarefas pesadas de raciocínio, arquitetura ou agentes complexos.
Onde o local costuma fazer muito sentido é quando está a iterar rápido, valoriza a privacidade, quer automatizar coisas muito específicas, repete as mesmas tarefas várias vezes, faz protótipos ou simplesmente prefere manter o custo debaixo de controlo.
Onde convém assentar um bocado os pés na terra é quando alguém quer usar um modelo local apertado para substituir absolutamente tudo. Se o seu hardware for limitado, vai conseguir fazer coisas úteis, sim, mas com compromissos. Menos velocidade, menos contexto confortável e muito mais necessidade de escolher bem o caso de uso.
E não há problema nenhum nisso. Na verdade, usar IA local com cabeça costuma resumir-se exatamente a isto: saber que tarefas fazem sentido em local e quais não fazem.
E se eu quiser usar modelos fine-tuned
Também pode. E em muitos casos faz bastante sentido.
Se encontrar um modelo fine-tuned para código, SQL, suporte, RAG ou aquilo que faz repetidamente, pode conseguir um comportamento mais afinado do que com um modelo generalista. Mas não confunda “fine-tuned” com “milagroso”. Se a base for fraca ou o hardware estiver engasgado, o tuning não o salva da realidade.
A graça do Ollama e do ecossistema open está exatamente aí: pode testar várias opções e ficar com a que lhe der o melhor equilíbrio entre qualidade, memória e velocidade para o seu caso real.
A ideia principal com que eu ficava
Se lhe apetece experimentar IA local, não comece por descarregar coisas à toa e esperar pelo melhor. Comece por olhar para o CanIRun.ai, perceber quanta VRAM tem de verdade, escolher um modelo que encaixe na sua máquina e levantar primeiro algo simples com Ollama.
Quando isso estiver a funcionar bem, aí sim, ligue-o ao Open Code, ao Cloud Code ou ao cliente que fizer sentido para o seu fluxo. Mas por esta ordem. Primeiro compatibilidade real, depois escolha do modelo, depois integração. Não ao contrário.
Porque se fizer o caminho ao contrário, o mais provável é acabar a dizer que IA local é péssima, quando na realidade o que era péssimo era a abordagem.
Se quiser, noutro post posso descer isto ainda mais à terra e montar configurações concretas conforme o tipo de máquina que tem: portátil normal, desktop com GPU dedicada ou mini servidor em casa.
O que você achou?
Deixe sua opinião, pergunta ou sugestão. Os comentários são sincronizados com GitHub Discussions .