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

Discussão no Hacker News ↗

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.