LM Studio e Qwen: como LLMs locais se saem em programação num MacBook M4 Pro

Modelos de linguagem locais já podem ser usados para escrever e editar código sem enviar o código-fonte para a nuvem, mas o conforto desse trabalho ainda depende muito da tarefa e da folga de hardware. Um experimento num MacBook Pro com M4 Pro e 48 GB de memória mostra que a combinação de LM Studio com modelos modernos de pesos abertos já entrega um resultado sólido no modo chat, mas com agentes completos logo esbarra em memória, aquecimento e tempo de execução. O ponto de partida é simples: modelos na nuvem são cômodos, mas têm limites, dependem da rede e, o maior problema para muitos desenvolvedores, dados, código e prompts vão para servidores remotos.

Rodar localmente promete privacidade e controle total, mas exige entender como o modelo consome RAM e VRAM, quanta memória sobra para o contexto e em que os formatos como GGUF e MLX se diferenciam. Os testes foram feitos num MacBook Pro com chip M4 Pro e 48 GB de memória unificada, em que CPU e GPU dividem um único pool de memória. Isso ajuda a acomodar modelos maiores, mas também significa que o modelo disputa recursos com a IDE, o Docker e dezenas de abas do navegador.

Uma parte à parte da análise trata da escolha do modelo para o hardware. O autor recomenda olhar não só o tamanho em bilhões de parâmetros, mas também a especialização, a quantização, o suporte a function calling e o tipo de arquitetura. Para programação, ele pegou o Qwen3-Coder 30B A3B Instruct nas variantes MLX e GGUF e o comparou com Qwen3-Coder Next, Qwen3.

5, Nvidia Nemotron-3 Nano e Gemma 4 26B A4B. O artigo explica bem o sentido prático das siglas: por exemplo, A3B indica a abordagem MoE, em que de um modelo grande só uma parte dos parâmetros é ativada, de modo que a velocidade fica próxima à de modelos pequenos e a qualidade, à de modelos maiores. Como ambiente de execução foi escolhido o LM Studio: nele é fácil baixar o modelo, subir um servidor local, ativar o CORS e conectar agentes como Claude Code, Open Code, Kilo Code e Aider.

A previsão de desempenho do Qwen3-Coder prometia cerca de 150 tokens por segundo, mas a medição real no LM Studio ficou mais perto de 82 tokens por segundo, o que traz a conversa da teoria de volta à prática.

O mais interessante começa nas medições. No modo chat comum, os modelos locais já não parecem um brinquedo, mas um meio-termo funcional. O Qwen3-Coder 30B A3B Instruct em MLX 4bit completou todo o cenário de três etapas em cerca de 2 minutos e 9 segundos e chegou à nota final de 8,5 de 10.

O Gemma 4 26B A4B em GGUF mostrou um dos melhores equilíbrios: cerca de 2 minutos e 23 segundos e 10 de 10 no final. Os modelos que raciocinam mais deram resultado melhor, mas ao custo de tempo: o Qwen3.5 35B A3B chegou a 10 de 10 em cerca de 5 minutos e 43 segundos, e o Qwen3.

5 27B se estendeu por quase meia hora. A conclusão desta parte é sóbria: em velocidade de resposta, os modelos locais já são em alguns casos comparáveis aos da nuvem, principalmente sem o modo de raciocínio, mas no mesmo tempo costumam perder deles em qualidade. Em compensação, os MoE recentes parecem bem mais práticos que as variantes densas.

No modo agente, o quadro muda bruscamente. O contexto cresce, o número de chamadas aumenta, e segundos viram minutos ou até dezenas de minutos. O Aider com o mesmo Qwen3-Coder MLX 4bit terminou o cenário em 2 minutos e 50 segundos com nota 9,5, o Open Code em 7 minutos e 33 segundos com nota 9, mas o Kilo Code com o mesmo modelo levou 15 minutos e 5 segundos e chegou a apenas 6 pontos.

Com o mais pesado Qwen3.5 35B A3B, o Kilo Code já trabalhou por 57 minutos e 3 segundos, embora a qualidade final tenha subido para 9 de 10. O Claude Code com o Gemma 4 26B terminou o experimento com a nota máxima de 10 de 10, mas gastou 21 minutos e 14 segundos no total, e a combinação de Claude Code com Qwen3-Coder simplesmente falhava por falta de memória para o contexto.

Ao mesmo tempo, o notebook sofria visivelmente: a GPU esquentava até cerca de 100 graus, as ventoinhas quase não se calavam e o swap em alguns cenários inchava até 20 GB. Nesse contexto, os agentes na nuvem eram simplesmente mais cômodos: por exemplo, o Kilo Code com o Qwen3.5 Plus deu 9 de 10 em 6 minutos e 53 segundos, e o Claude Opus 4.

6, 10 de 10 em 12 minutos e 15 segundos, ainda que já pagando.

O resumo é simples: LLMs locais já podem ser considerados a sério para chat privado, tarefas pontuais de refatoração e cenários simples em que o controle dos dados importa mais que a velocidade absoluta. Mas se é preciso um modo agente permanente num notebook de trabalho, principalmente ao lado de IDE, navegador e Docker, a pilha local continua sendo, por ora, um meio-termo. O cenário mais sensato dessa experiência é usar MoE recentes, agentes mais simples como Aider ou Open Code e, se possível, levar o modelo local para uma máquina separada, como um Mac mini.