Meu setup de IA local: OpenCode + LocalAI

Existe uma narrativa confortável de que dá para trocar todas as ferramentas de IA pagas por modelos rodando na sua própria máquina e zerar a conta. Eu andei por esse caminho e o resultado foi diferente: hoje eu rodo híbrido, com dois nós locais e três provedores remotos, e escolho onde mandar cada tarefa.

Este texto é o que eu gostaria de ter lido antes de começar: a arquitetura como ela é, não como o marketing diz que poderia ser.

A arquitetura

São duas peças:

• LocalAI roda como container e expõe uma API compatível com a da OpenAI. É o servidor de inferência.
• OpenCode é o cliente de linha de comando. Ele fala com qualquer endpoint compatível com OpenAI, então não precisa saber que do outro lado tem uma GPU na sua rede em vez de um data center.

No ~/.config/opencode/opencode.json isso vira um bloco de provider por endpoint:

{
  "provider": {
    "localai-local": {
      "api": "openai",
      "options": { "baseURL": "http://127.0.0.1:8080/v1" },
      "models": { }
    },
    "localai-lan": {
      "api": "openai",
      "options": { "baseURL": "http://IP-DO-SEU-HOST:8080/v1" },
      "models": { }
    }
  }
}

O mesmo cliente enxerga os dois nós locais e os provedores remotos, e a escolha do modelo vira só uma flag na hora de chamar.

Dois nós locais, com papéis diferentes

Eu tenho duas instâncias de LocalAI apontando para máquinas distintas: uma no notebook que eu uso para trabalhar e outra num host com GPU na rede local. As duas expõem o mesmo tipo de API, mas o que cada uma aguenta carregar é bem diferente.

Alguns exemplos do que está carregado no nó local hoje:

curl -s http://127.0.0.1:8080/v1/models | jq -r '.data[].id'

ornith-1.5-9b-q4
gemma-4-e4b-it-qat-mtp
minicpm5-2b-q8
arch-router-1.5b-q4
embeddinggemma-300m
whisper-large-turbo
glm-ocr

Repare que não é só texto: tem modelo de embedding, transcrição de áudio e OCR na mesma lista. Isso muda o que dá para fazer localmente — indexar um diretório de código, transcrever uma reunião ou extrair texto de um PDF não precisam de nuvem nenhuma.

Separar em dois nós resolve um problema prático de VRAM: um modelo de 9B quantizado em 4 bits cabe no notebook para tarefas rápidas de leitura e resumo, mas quando eu preciso de mais capacidade eu aponto para o host com GPU em vez de tentar espremer o modelo maior onde ele não cabe.

Nem tudo roda local

Aqui está a parte que a narrativa costuma omitir. Além dos dois nós locais, o meu config tem três provedores remotos. Não é descuido nem preguiça: é consequência de três limites que aparecem na prática.

Raciocínio longo. Modelo pequeno quantizado em 4 bits vai bem em tarefa curta e bem delimitada. Quando o problema exige encadear várias decisões dependentes, a diferença de qualidade para um modelo de fronteira aparece na hora.

Uso de ferramentas. Um agente que precisa chamar ferramenta de forma confiável depende de o modelo respeitar formato. Em modelos menores isso falha com uma frequência que transforma produtividade em debug do próprio agente.

Contexto. Janela de contexto grande é caro em VRAM. Passar um repositório inteiro para um modelo local é justamente o caso em que ele pior performa.

Então a regra que eu uso é por natureza da tarefa, não por ideologia:

Um modelo local que resolve 70% das minhas chamadas já tira 70% do volume da fatura. Insistir nos outros 30% com o modelo errado custa mais caro do que pagar por eles.

Plugins e MCPs

O OpenCode tem sistema de plugins e suporte a MCP. Minha lista é curta e honesta: um plugin meu, que sincroniza configuração entre os ambientes, e um plugin de terceiros para organização de sessão. No MCP eu uso o XPipe, para mexer em servidor remoto sem trocar de janela, e o markitdown, para converter documento em markdown antes de jogar no contexto.

Lista curta é resultado de tentativa e erro. Cada plugin a mais é mais um lugar para o agente se comportar diferente do que você espera, e cada MCP é um processo a mais para manter de pé. Prefiro resolver no prompt.

O que isso custa de verdade

Não vou colocar percentual de economia neste texto. Qualquer número que eu escrevesse aqui dependeria do seu consumo, do preço da energia onde você mora e de quantas horas sua GPU fica ociosa, e o "economizei 90%" que circula por aí costuma ser chute com cara de dado.

O que dá para afirmar sem inventar:

• Para o que roda local, o custo marginal deixa de ser por token e vira energia elétrica mais desgaste de hardware.
• O hardware é custo afundado: se você já tem a máquina, o gasto é zero; se não tem, você está comprando uma GPU que talvez não se pague.
• O custo que ninguém contabiliza é tempo. Instalar e manter LocalAI, baixar modelo, ajustar camada na GPU, descobrir por que a inferência ficou lenta depois de uma atualização — isso é trabalho não remunerado que sai do seu fim de semana.

Esse último ponto é o que eu subestimaria de novo se começasse hoje.

Onde o caminho local perde

• Qualidade. Um modelo local bom não é um modelo de fronteira. Para tarefa de raciocínio, a diferença não é sutil.
• Latência. O primeiro token de um modelo que precisa ser carregado na VRAM demora. Numa sessão interativa, isso se sente.
• VRAM manda em tudo. Tamanho do modelo, tamanho da quantização e tamanho do contexto competem pelo mesmo recurso. Não tem jeito de ter os três.
• Você vira o SRE de si mesmo. Quando o serviço de inferência cai às 23h, não tem suporte para abrir chamado.

Como montar o seu

1. Rode o LocalAI em container com as bibliotecas de GPU certas para a sua placa.
2. Suba um modelo pequeno primeiro e confirme o endpoint: curl http://127.0.0.1:8080/v1/models.
3. Aponte o OpenCode para ele com um bloco de provider, como no exemplo acima.
4. Rode por uma semana mantendo os provedores remotos ligados. Anote em que tipo de tarefa você troca para o remoto — esse padrão é o seu roteamento, e ele é pessoal.
5. Só depois que o padrão estiver claro, comece a mover tarefa por tarefa para o local.

O passo 4 é o que eu pularia de novo se estivesse com pressa — e é o único que evita você achar que o problema é a ferramenta quando na verdade é o tipo de tarefa que você estava mandando para ela.

Fechando

Rodar modelo local vale a pena por controle, privacidade e previsibilidade de custo. Não vale a pena como substituto ideológico de tudo. O ganho real veio de parar de tratar "local vs. nuvem" como uma decisão de time de futebol e passar a tratar como decisão de engenharia, tarefa por tarefa.