Ask HN: ¿Alguien ha reemplazado Claude/GPT por un modelo local para programar a diario?

Discusión en Hacker News ↗

Sentimiento general

  • Muy pocas personas han reemplazado por completo Claude/GPT con modelos locales para programar a diario.
  • Muchos usan un enfoque híbrido: pesos abiertos locales para la mayor parte del trabajo, modelos frontera (Claude/GPT/DeepSeek/Kimi/GLM) para la planificación, errores difíciles o revisiones.
  • Consenso: lo local es “bueno y cada vez mejor”, pero todavía suele estar por detrás de los mejores modelos en la nube en fiabilidad, razonamiento y trabajo con repos grandes.

Hardware y rendimiento

  • Las configuraciones útiles suelen implicar:
    • GPU con mucha VRAM (RTX 3090/4090/6000, 4×5070, Radeon 7900XTX/R9700).
    • Apple silicon con mucha RAM (M4/M5/Mac Studio 64–512 GB) o Strix Halo 128 GB.
  • Informes típicos de rendimiento:
    • ~40–150 tok/s en decode, 400–4000 tok/s en prefill en modelos de ~30–35B, según MTP, cuantización y concurrencia.
  • La electricidad no es trivial, pero normalmente es mucho más barata que el CAPEX de hardware; algunos cálculos rápidos de TCO muestran que las API en la nube siguen siendo más baratas para muchos usuarios.

Elección de modelos y calidad percibida

  • Los modelos locales más elogiados para programar:
    • Qwen 3.6 27B denso (a menudo cuantización Q4–Q6). Se compara con frecuencia con algo entre Haiku y Sonnet anteriores.
    • Qwen 3.6 35B A3B (MoE) por velocidad; a menudo algo peor que el 27B denso en programación.
    • Gemma 4 (26–31B, incluidas variantes QAT) como un modelo general sólido, a veces peor que Qwen en uso de herramientas.
    • DeepSeek V4 Flash / ds4 en equipos Apple o GPU de gama alta para trabajo con mucho razonamiento.
  • Los grandes modelos abiertos MoE (Qwen 3.5 122B-A10B, Nemotron, MiniMax) pueden ser potentes, pero requieren mucha RAM y son más lentos; algunos los consideran peores que los 27B–35B densos bien ajustados.

Harnesses, herramientas y flujos de trabajo

  • La calidad del harness se considera al menos tan importante como la del modelo:
    • Populares: pi.dev, Claude Code (apuntado a endpoints locales), OpenCode, Crush, Aider, CLIs personalizadas, VS Code/Copilot hacia servidores locales de llama.cpp.
  • Patrones eficaces:
    • Flujos de trabajo agentic con herramientas estrictas, subagentes o planes de varios pasos.
    • El modelo frontera escribe la especificación/plan; el modelo local implementa.
    • Varios agentes locales con roles estrechos (plan, esquema, código, pruebas, revisión).

Limitaciones y puntos de dolor

  • Problemas comunes:
    • Bucles, exceso de razonamiento y llamadas a herramientas/edición rotas, especialmente con cuantización agresiva o un muestreo deficiente.
    • Límites de contexto y peculiaridades de la caché; la calidad cae en contextos largos pese a ventanas nominales grandes.
    • Lentitud y ruido de ventiladores en portátiles; los repos complejos se sienten “eternos” comparados con la nube.
    • Complejidad de la configuración: drivers, elección de cuantización, ajustes de KV cache, batching, configuración del harness.
  • Muchos informan que los modelos locales se sienten como un dev capaz pero junior; los modelos frontera se sienten más como un mid/senior fuerte, especialmente para arquitectura y bugs complicados.

Privacidad, coste y estrategia

  • Razones para irse a local:
    • Privacidad/cumplimiento de datos, evitar dependencia de un proveedor, miedo a futuras subidas de precios o regulación, gusto por trastear.
    • “Suficientemente bueno” para proyectos personales, scripting, código pegamento, tareas con documentos.
  • Razones para no hacerlo:
    • Coste del hardware frente a suscripciones frontier fuertemente subvencionadas de $20–$100/mes.
    • Los modelos en la nube (especialmente DeepSeek/Kimi/GLM) son extremadamente baratos por token y claramente más capaces.
  • Patrón emergente: enfoque por capas—primero local, luego API baratas de pesos abiertos, y modelos frontera solo cuando realmente se necesitan.