- Mesmo em um M4 MacBook Pro com 24 GB, é possível montar um ambiente de modelo local para tarefas básicas, pesquisa e planejamento
- Qwen 3.5-9B Q4 atende a cerca de 40 tokens/segundo, modo de raciocínio, uso de ferramentas e contexto de 128K
- Ele não consegue resolver problemas complexos por muito tempo de forma autônoma como os melhores modelos, então precisa de instruções passo a passo
- Corrigiu avisos do Elixir Credo, mas falhou em resolver conflitos de rebase sem editar os arquivos
- Modelos locais têm como vantagem funcionar offline e não exigir assinatura, mas envolvem grandes trade-offs de desempenho e configuração
Ambiente para executar modelos locais e critérios de escolha
- Foram feitos testes de configuração para rodar modelos locais em um M4 MacBook Pro com 24 GB de memória e, embora o resultado não seja igual ao de modelos de ponta (SOTA), foi possível montar um ambiente capaz de lidar com tarefas básicas, pesquisa e planejamento sem conexão com a internet
- As ferramentas para execução local incluem Ollama, llama.cpp e LM Studio, cada uma com limitações e modelos disponíveis diferentes
- Na escolha do modelo, ele precisava caber na memória e ainda deixar folga para rodar aplicativos Electron comuns, além de exigir uma janela de contexto de pelo menos 64K, idealmente 128K ou mais
- Tentativas recentes com Qwen 3.6 Q3, GPT-OSS 20B e Devstral Small 24B caberam na memória, mas foram difíceis de usar na prática, enquanto o Gemma 4B rodou bem, mas teve dificuldades no uso de ferramentas
- Os itens de configuração variam de valores conhecidos como temperature até opções mais específicas como K Cache Quantization Type, e os valores adequados também mudam conforme o raciocínio (
thinking) esteja ativado ou não
Configuração com quantização de 4 bits do Qwen 3.5-9B
- qwen3.5-9b@q4_k_s foi o melhor modelo ao rodar no LM Studio, entregando cerca de 40 tokens/segundo, raciocínio ativado, uso bem-sucedido de ferramentas e janela de contexto de 128K ao mesmo tempo
- Ele se distrai com mais facilidade que os melhores modelos, às vezes entra em loop e ocasionalmente interpreta mal os pedidos, mas ainda assim foi bastante bom para um modelo que roda em um MacBook Pro de 24 GB deixando espaço para outras tarefas
- As configurações recomendadas para modo de raciocínio e tarefas de programação foram as seguintes
temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
- Para ativar o raciocínio, é preciso selecionar o modelo no LM Studio, ir em configuration e adicionar o seguinte valor em Prompt Template, no fim da aba Inference
{%- set enable_thinking = true %}
- Esse modelo foi usado tanto no pi quanto no OpenCode; o pi pareceu mais ágil, mas, separadamente da vantagem de permitir construir e customizar o próprio harness, faltavam valores padrão razoáveis
- Pode acabar sendo necessário gastar mais tempo ajustando a configuração do pi do que no projeto em si
Configuração do pi
- Em
~/.pi/agent/models.json, foi registrado o endpoint compatível com OpenAI do LM Studio junto com o modelo qwen3.5-9b@q4_k_s
{
"providers": {
"lmstudio": {
"baseUrl": "http://localhost:1234/v1";,
"api": "openai-completions",
"apiKey": "lm-studio",
"models": [
{
"id": "qwen3.5-9b@q4_k_s",
"reasoning": true,
"compat": { "thinkingFormat": "qwen-chat-template" }
}
]
}
}
}
- Para ocultar blocos de raciocínio dispersos, foi adicionado
"hideThinkingBlock": true em ~/.pi/agent/settings.json
Configuração do OpenCode
- Em
~/.config/opencode/opencode.json, o LM Studio foi registrado como provider local compatível com OpenAI, com uso de ferramentas, contexto de 131072 e máximo de 32768 tokens
{
"$schema": "https://opencode.ai/config.json";,
"provider": {
"lmstudio": {
"npm": "@ai-sdk/openai-compatible",
"name": "LM Studio (local)",
"options": {
"baseURL": "http://127.0.0.1:1234/v1";
},
"models": {
"qwen3.5-9b@q4_k_s": {
"name": "Qwen 3.5 9B Q4_K_S",
"tools": true,
"context_length": 131072,
"max_tokens": 32768
}
}
}
},
"model": "lmstudio/qwen3.5-9b@q4_k_s"
}
Diferenças em relação aos melhores modelos
- Modelos como o Qwen 3.5 9B Q4 ainda não estão no nível dos melhores modelos quando se trata de resolver problemas complexos de forma autônoma por longos períodos
- Pedir que ele crie um aplicativo inteiro de uma vez não foi uma abordagem adequada, e isso pode acabar apenas esquentando o notebook sem produzir resultado
- O formato que funcionou melhor foi um fluxo de trabalho interativo, com comunicação clara em etapas e muitas instruções
- Ao usar modelos locais, o usuário precisa assumir mais do raciocínio e do planejamento, além de dar instruções mais específicas, mas eles ainda foram úteis como assistente de pesquisa, rubber duck e apoio para lembrar rapidamente detalhes de linguagens de programação e comandos de linha de comando
- Não é o aumento de produtividade de 10x promovido pelas grandes empresas de IA, mas oferece ajuda real e uma experiência interessante de uso
Tarefas que funcionaram e tarefas que falharam
-
Correção de avisos do Elixir Credo
- Depois de atualizar o linter
credo do Elixir para a versão mais recente, surgiram avisos no código, e foi pedido ao Qwen que executasse mix credo --strict e sugerisse como resolver, sem editar nada
- O Qwen encontrou, em quatro arquivos de teste, o problema de usar
length/1 para verificar se listas não estavam vazias e sugeriu trocar length(list) > 0 por list != []
- Depois, ao receber a solicitação para editar, o Qwen fez quatro edições paralelas de forma limpa
- Era uma tarefa simples que também poderia ser feita manualmente alternando entre terminal e editor, mas o modelo serviu bem como apoio conveniente
-
Tratamento de conflito de rebase em PR do Dependabot
- Após uma atualização de dependências, houve conflito de git em um PR do Dependabot; como o Dependabot recusou o rebase, o autor baixou tudo e fez o rebase manualmente, depois pediu ao Qwen para verificar
- O conflito era simples: bastava escolher versões mais novas de cada dependência, e o Qwen recomendou manter
sentry em 13.0.1 e tailwind em 0.4.1
- Mas, ao pedir a alteração de fato, o Qwen tentou executar
git add mix.lock && git rebase --continue sem modificar o arquivo, deixando os marcadores de conflito no lugar
- Ele também não percebeu que
git rebase --continue abriria o editor, e o OpenCode travou; isso também pode ter sido apenas um caso isolado
Vantagens e limites dos modelos locais
- Modelos locais envolvem trade-offs importantes, mas têm a vantagem de permitir trabalhar até em um avião, sem conexão com a internet
- Assumindo que o computador já seria comprado de qualquer forma, o custo fica limitado ao consumo de energia, e não há necessidade de assinatura
- O treinamento dos modelos ainda tem um alto custo ambiental, mas as empresas de modelos abertos ainda estão longe do topo em impacto ambiental, e usar hardware pessoal reduz a dependência de datacenters
- Também há diversão em ajustar tudo manualmente e experimentar
- LLMs já tiveram um grande impacto e também trazem muitos aspectos negativos, mas parecem ser uma tecnologia que vai permanecer, e experimentar modelos locais deu a sensação de uma forma mais sustentável e positiva de interagir com essa tecnologia
1 comentários
Comentários do Hacker News
Rodar LLMs localmente é divertido e poderoso, mas concluir trabalho de verdade dá bastante dor de cabeça
Você precisa planejar, escrever especificações e preparar tudo com antecedência, enquanto modelos grandes como OpenAI ou Claude costumam entender de cara com só algumas frases
Se você já está fazendo trabalho sério com modelos grandes, pode simplesmente continuar usando
Mas vejo visão/OCR de forma diferente. Modelos pequenos e médios com pesos abertos já estão parecidos com o estado da arte, e em jobs grandes em lote o custo de tokens de prefill pesa bastante
Também se esquece com frequência que, para usar até um LLM pequeno como um serviço pessoal estável, é preciso deixar 16–24 GB de RAM/VRAM livres e manter isso rodando o tempo todo
No fim, a questão central continua sendo dinheiro
Acho que já chegou quase a um nível realmente utilizável
Gemma 4 31B parece uma nova linha de base para modelos locais. Claro que fica abaixo dos modelos frontier, mas parece menos um experimento científico do que os modelos locais que rodei até agora, ou do que GPT OSS 120B e Nemotron Super 120B
Num M5 Max com 128 GB de RAM, usar a janela de contexto completa de 256K faz o uso de RAM subir para cerca de 70 GB, com algo como 14 GB de overhead do sistema
Parece que uma máquina Panther Lake de 64 GB com Arc B390 completo, ou uma máquina Snapdragon X2 Elite de 48 GB, conseguiria rodar com janela de contexto de 128K~256K, e com 32 GB talvez dê para forçar com 32K de contexto
Até no ano passado, ver esse nível de desempenho numa configuração topo de linha quase mainstream parecia um sonho distante
No fim, o critério é: “o que dá para confiar de forma consistente a este modelo?” O Opus claramente sabe mais e consegue lidar com tarefas mais complexas, mas se você montar bem o contexto, o Gemma é surpreendentemente bom
A diferença no conjunto de tarefas que eu confiaria a cada um dos dois é menor do que parece. Teve resultados muito bons recentemente em ferramentas pessoais e vários projetos, e foi o primeiro modelo local em que consegui confiar o suficiente no modo agente para deixar implementar funcionalidades em projetos não triviais
https://thot-experiment.github.io/gradient-gemma4-31b/
Isso é uma ferramenta relativamente complexa, quase toda feita pelo Gemma 4 dentro do OpenCode, e em algumas horas só precisei intervir manualmente umas 4 vezes
Q6_K_XL, contexto de 128K @ q8, leitura em cerca de 800 tok/s e escrita em cerca de 16 tok/s
Estou esperando o turboquant e MTP do llama.cpp e, se os rumores estiverem certos, talvez dê para chegar a 256K e 25~30 tok/s
Escrevi sobre isso [0] porque o desempenho em benchmark logo após o lançamento impressionou. Mas depois de rodar em ambientes de agentic coding com contexto mais longo, sua posição no ranking caiu um pouco
[0] https://gertlabs.com/blog/gemma-4-economics
O fluxo é planejar com um modelo de ponta e executar com um modelo pequeno. Se você planejar direito e não deixar ambiguidades para o modelo pequeno interpretar, funciona bem
Queria ter visto este post antes de passar o fim de semana inteiro chegando à mesma conclusão
Fiz um teste artificial no mesmo notebook, mandando corrigir cerca de 50 erros de lint em um repositório pequeno de vibe coding em C++. Eu esperava que ele conseguisse lidar com muitas tarefas pequenas sem travar com tanta frequência
GPT OSS 20B até dava para usar, mas era lento, adicionava frases desnecessárias ou repetia coisas, e cometia com frequência o erro de listar correções como se tivessem sido feitas sem de fato modificar o código
O Qwen 3.5 9B usado com Opencode foi muito mais rápido, passou pela maior parte dos avisos de lint sem travar mesmo durante compressão, e corrigiu todos com as mudanças certas
Também tentei uma quantização MLX 4-bit do Qwen 3.5 9B, mas no fim deu crash por falta de memória; quando troquei para GGUF rodando com llama.cpp, funcionou sem crash
Não dá para comparar com modelos frontier de forma alguma. Eles são muito mais lentos, erram informações básicas e não conseguem resolver de uma vez tarefas minimamente complexas
Pedi um resumo da arquitetura do projeto e ele afirmou que o repositório usava bibliotecas que nem existiam ali. Pode variar de pessoa para pessoa, mas ainda assim há utilidade, e espero que com o tempo o ambiente de LLMs locais melhore bastante mesmo em hardware razoável
LLMs locais são ótimos, mas se você lê muito sobre o assunto pode acabar com a impressão de que eles quase alcançam o Opus 4.7
No HN existe um grupo bem pequeno, barulhento e entusiasmado que exagera bastante as capacidades dos LLMs locais
Entre modelos desse tamanho, foi um dos mais rápidos que já testei em GPU local, embora eu só tenha testado em placas Nvidia
Depois vi que ele é MoE e tem só 3.6B de parâmetros ativos, o que explica muita coisa
É útil ter uma visão realista do que dá para fazer com modelos locais, especialmente modelos pequenos como o 9B que o autor usa
Um modelo 9B está no nível de algo como o Sonnet 3.6, então consegue autocompletar e fazer funções pequenas, mas perde o fio quando tenta entender problemas grandes
Ainda assim é interessante e divertido de explorar. Eu mesmo tenho feito muito disso por diversão, criando coisas como harnesses de agentes locais
O projeto atual é um agente sem instalação: https://gemma-agent-explainer.nicklothian.com/
Python, SQL e React rodam todos completamente dentro do navegador. Para a melhor experiência, recomendo o Gemma E4B
Ainda está em desenvolvimento ativo e requer Chrome por causa do suporte a HTML5 Filesystem API e LiteRT. Mas deve dar para fazer funcionar também na maioria dos navegadores baseados em Chromium
A diferença em relação à maioria dos agentes é que ele é sem instalação. O modelo roda no navegador com LiteRT/LiteLLM e tem desempenho melhor que Transformers.js. Com a Filesystem API, também é possível ter acesso opcional de leitura a diretórios sandbox
Ele é autodocumentado, então se você perguntar no painel de ajuda em tempo real algo como “como o system prompt é usado”, ele consegue acessar o próprio código-fonte e responder
Clique em “Tour” para ver tudo, e pretendo abrir o código na semana que vem
Só que os benchmarks que as pessoas usam para avaliar modelos mudam com tanta frequência que fica difícil achar comparações boas. E, para referência, o Sonnet 3.6 saiu cerca de 1 ano depois do GPT-3.5
Sendo crítico, é verdade que esses modelos não estão no mesmo nível do topo atual para tarefas complexas de programação
Mas uma parte considerável do trabalho de escritório é tratar Excel, mover arquivos, traduzir documentos jurídicos engessados, rascunhar emails, fazer trabalho braçal de PPT e coisas assim
Para esse tipo de tarefa, modelos de 30~35B ou mais já bastam, com a vantagem de manter dados da empresa privados
Quando as pessoas falam de modelos locais, o que elas têm em mente são os modelos lançados em abril deste ano. O alvo é Qwen 3.6 27B e, se a GPU for fraca, qwen 35b a3b
Esses modelos já podem ser comparados seriamente aos modelos de nível de ponta atuais
Um exemplo famoso: o caso London Whale do JPMorgan teve uma perda de US$ 6 bilhões por causa de um erro em Excel
Estou pensando em um MacBook M5 Pro 18/20-core com 64 GB de RAM, mas é muito difícil encontrar benchmarks de modelos no mundo real
Por exemplo, seria ótimo se alguém pudesse dizer quantos tokens por segundo dá para conseguir com quantizações Q4 e Q6 do Qwen 3.6 35B/A3B
Inferência local está pendendo para modelos MoE, e vários deles têm throughput decente, mas um tempo até o primeiro token terrível
Escrevi no Bluesky uma configuração meio aleatória que uso num M2 Studio de 32 GB e queria feedback
Sou do tipo que não vai muito bem sem ver exemplos concretos, então estou compartilhando na esperança de receber ajuda
https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...
Estou rodando um modelo quantizado qwen 3.6 9b num M4 Pro com 48 GB, e ele é só mais ou menos utilizável para desenvolvimento básico baseado em pi.dev/cc
Para fazer trabalho realmente significativo, parece que o sweet spot é um desktop com 128 GB. Só que hoje em dia é difícil conseguir uma máquina dessas
Rodar localmente é divertido, mas não dá para esquecer que o próprio tempo também não é de graça
Em projetos pessoais estou migrando cada vez mais para o OpenRouter, e mesmo usando seriamente o maior modelo qwen eu gasto menos de US$ 2~3 por dia
Com um M4 Pro de 48 GB você consegue rodar modelos maiores, então, se a inteligência do modelo é o principal fator de utilidade, talvez faça mais sentido usar algo maior
Concordo que um 9B denso deixa a desejar
Tenho um MacBook Pro M5 de configuração máxima e também testei modelos locais, e em geral eles mal funcionam
Em uma 4090 de 24 GB estou rodando qwen3.6:27B com cerca de 128K de contexto usando as otimizações recentes de memória de valores ativos do turboquant/rotorquant
Recomendo fortemente subir para um modelo desse porte. A combinação q4_xl+rotorquant é muito boa
Também tenho código de referência para jogar para o agente
https://github.com/rapatel0/rq-models
Acho melhor gastar alguns milhares de dólares num Mac do que em assinaturas de API
Modelos locais permitem trabalhar em qualquer lugar, a qualquer hora, sem preocupação com vazamento de privacidade