Ask HN: Alguém substituiu Claude/GPT por um modelo local para programação diária?

Discussão no Hacker News ↗

Muitos desenvolvedores estão experimentando substituir assistentes de programação em nuvem como Claude e GPT por modelos locais de open weights, como Qwen 3.6 e Gemma 4, muitas vezes rodando em GPUs com muita VRAM ou Macs com muita RAM. Eles relatam que os modelos locais podem ser “bons o suficiente” para projetos pessoais, trabalho sensível à privacidade e tarefas bem delimitadas — especialmente quando combinados com harnesses agentic fortes como Pi ou OpenCode —, mas ainda ficam atrás dos modelos de fronteira em programação complexa, em grandes repositórios ou com alta autonomia. Um tema recorrente é que custo de hardware, eletricidade, complexidade de configuração e ferramentas mais fracas muitas vezes superam as assinaturas, enquanto o acesso barato por API a modelos potentes não americanos (por exemplo, DeepSeek, Kimi, GLM) atualmente oferece o meio-termo mais prático.

Sentimento geral

  • Muito poucas pessoas substituíram totalmente Claude/GPT por modelos locais para programação diária.
  • Muitas usam um híbrido: open weights locais para a maior parte do trabalho, e modelos de fronteira (Claude/GPT/DeepSeek/Kimi/GLM) para planejamento, bugs difíceis ou revisões.
  • Consenso: local é “bom e está melhorando”, mas ainda geralmente fica atrás dos melhores modelos de nuvem em confiabilidade, raciocínio e trabalho em repositórios grandes.

Hardware e desempenho

  • Configurações úteis costumam envolver:
    • GPUs de alta VRAM (RTX 3090/4090/6000, 4×5070, Radeon 7900XTX/R9700).
    • Apple silicon com muita RAM (M4/M5/Mac Studio 64–512 GB) ou Strix Halo 128 GB.
  • Relatos típicos de desempenho:
    • ~40–150 tok/s de decode, 400–4000 tok/s de prefill em modelos de ~30–35B, dependendo de MTP, quant e concorrência.
  • A eletricidade não é trivial, mas geralmente é muito mais barata do que o CAPEX de hardware; algumas contas rápidas de TCO mostram que APIs de nuvem ainda saem mais baratas para muitos usuários.

Escolha de modelos e qualidade percebida

  • Modelos locais mais elogiados para programação:
    • Qwen 3.6 27B dense (muitas vezes em quant Q4–Q6). Frequentemente comparado a algo entre Haiku e o Sonnet antigo.
    • Qwen 3.6 35B A3B (MoE) pela velocidade; muitas vezes um pouco pior que o 27B dense em programação.
    • Gemma 4 (26–31B, incluindo variantes QAT) como um modelo geral forte, às vezes mais fraco que Qwen no uso de ferramentas.
    • DeepSeek V4 Flash / ds4 em rigs Apple ou GPU de ponta para trabalho com muito raciocínio.
  • Modelos MoE abertos grandes (Qwen 3.5 122B-A10B, Nemotron, MiniMax) podem ser fortes, mas exigem muita RAM e são mais lentos; alguns acham que são piores do que dense de 27B–35B bem ajustados.

Harnesses, ferramentas e fluxos de trabalho

  • A qualidade do harness é vista como pelo menos tão importante quanto o modelo:
    • Populares: pi.dev, Claude Code (apontado para endpoints locais), OpenCode, Crush, Aider, CLIs personalizadas, VS Code/Copilot para servidores locais llama.cpp.
  • Padrões eficazes:
    • Fluxos de trabalho agentic com ferramentas rígidas, subagentes ou planos em várias etapas.
    • Modelo de fronteira escreve a spec/plano; modelo local implementa.
    • Vários agentes locais com papéis restritos (plano, esquema, código, testes, revisão).

Limitações e pontos de dor

  • Problemas comuns:
    • Loops, over-thinking e chamadas de ferramenta/edição quebradas, especialmente com quantização agressiva ou amostragem ruim.
    • Limites de contexto e peculiaridades de cache; a qualidade cai em contextos longos apesar de janelas nominais grandes.
    • Lentidão e ruído de ventoinha em laptops; repositórios complexos parecem “demorar uma eternidade” em comparação com a nuvem.
    • Complexidade de configuração: drivers, escolhas de quant, configurações de KV cache, batching, config do harness.
  • Muitos relatam que modelos locais parecem um dev capaz, mas júnior; modelos de fronteira parecem mais um mid/senior forte, especialmente para arquitetura e bugs difíceis.

Privacidade, custo e estratégia

  • Motivos para ir para o local:
    • Privacidade/compliance de dados, evitar lock-in, medo de aumentos futuros de preço ou regulação, prazer em mexer e ajustar.
    • “Bom o suficiente” para projetos pessoais, scripting, glue code e tarefas com documentos.
  • Motivos para não ir:
    • Custo de hardware vs assinaturas frontier subsidiadas de $20–$100/mês.
    • Modelos de nuvem (especialmente DeepSeek/Kimi/GLM) são extremamente baratos por token e claramente mais capazes.
  • Padrão emergente: abordagem em camadas—primeiro local, depois APIs baratas de open weights, e por fim frontier só quando realmente necessário.