¿Usas LLM abiertos y asistentes de programación en local? Comparte tu entorno

• Un hilo de Ask HN donde usuarios de Hacker News preguntan cómo usan LLM abiertos y asistentes de programación en local y en qué hardware de laptop
• Qué modelos usan (por ejemplo, Ollama, LM Studio, etc.) y qué asistentes de programación/integraciones open source usan (por ejemplo, plugins de VS Code)
• Qué hardware de laptop usan (CPU, GPU/NPU, memoria, GPU dedicada o integrada, SO) y qué rendimiento obtienen en su flujo de trabajo
• Para qué tareas lo usan (autocompletado de código, refactorización, depuración, revisión de código) y qué tan estable es (qué funciona bien y qué se queda corto)

---

• 1) MacBook Pro / Mac Studio (M2~M4 Max, 64~128GB) + LM Studio/Ollama + VS Code Continue

  • Ventajas
    • Gracias a la memoria unificada de Mac, modelos como Qwen3-Coder-30B-A3B, gpt-oss-20b y Gemma 27B corren localmente sin mucho problema, así que sí funciona un flujo tipo “trae el código → resúmelo → haz pequeños cambios”
    • Con solo dejar encendido LM Studio API o Ollama serve, VS Code con Continue.dev, Zed y JetBrains se conectan de inmediato, y en la práctica se siente como una UX parecida a Claude Code
    • La baja latencia típica de Mac ayuda bastante; con unos 50~80 tok/s, completar código o generar comentarios no se siente desesperante
    • Que funcione en avión, tren o completamente offline es una gran ventaja, especialmente para que “el código de la empresa no salga” del entorno local
  • Desventajas
    • A partir de modelos de más de 20B aparecen problemas de temperatura y ruido de ventiladores, y aun con una M4 Max de 128GB, 120B ya se siente lento o al límite
    • Todavía se queda corto para escenarios de agente que “empujan hasta el final con bash-in-a-loop como Claude 4.5 Sonnet”
    • En MacBooks de 24GB o 32GB, la asignación de VRAM se queda corta, así que al final hay que bajar a modelos de 7B~12B, y si aumentas mucho el contexto enseguida se vuelve lento

• 2) Estructura con desktop/workstation con RTX 3090·4090·Pro 6000, y la laptop como cliente ligero

  • Ventajas
    • Se puede probar de todo con llama.cpp / vLLM / Ollama, e incluso ejecutar gpt-oss-120B, “lento pero de verdad”
    • En VS Code se abre Continue o llama-vscode desde la laptop, pero la inferencia corre en la máquina que está en casa, así que casi no hay carga de batería ni calor en la laptop
    • Con una RTX 3090 de 24GB, modelos como gpt-oss-20B y Qwen2.5/3 Coder 14~30B alcanzan velocidades de tokens útiles en la práctica, suficientes para autocompletado y refactorizaciones cortas
    • Mucha gente monta Open WebUI + Ollama en casa y se conecta por VPN/Tailscale, así que puede mantener un entorno privado incluso en remoto
  • Desventajas
    • Si la VRAM de la GPU es de 24GB o menos, para 120B hay que cuantizar muy agresivamente, y la calidad baja de forma visible
    • vLLM rinde bien, pero instalarlo y compilarlo es tedioso, al punto de que se comenta que hay que “volver a probarlo con un runner actualizado”, así que tiene un costo de mantenimiento
    • En portabilidad, en la práctica no ofrece nada; si tu meta es “resolver todo con una sola laptop”, esta estructura no es la indicada

• 3) Configuraciones centradas en gpt-oss-120B (Aider, Codex, agentes locales)

  • Ventajas
    • Varias personas comentaron que, de todo lo que probaron localmente, “esto fue lo más cercano a GPT-5”, especialmente por su precisión en tareas de programación
    • Ya hay experimentos reales funcionando al conectarlo a asistentes de programación abiertos como Aider, Codex o roocode para hacer revisión → corrección → pruebas → commit de una sola vez
    • También se compartieron trucos para forzarlo en llama.cpp con carga mixta CPU+GPU, de modo que hasta con 8GB de VRAM se puede intentar, así que los requisitos de hardware son más flexibles de lo que parece
  • Desventajas
    • La velocidad es el gran problema. Si ChatGPT termina 50 preguntas en 6 minutos, un 120B puede tardar más de 1 hora en pelearse con lo mismo, así que es para gente dispuesta a esperar
    • En herramientas como Codex, hay que hardcodear los parámetros de inferencia para que no se detenga, y escribir AGENTS.md de forma bastante pesada para que trabaje como una persona
    • Solo con una laptop, sostenerlo durante mucho tiempo es difícil por calor, consumo y memoria; en la práctica, lo correcto es verlo como un esquema de “laptop conectada a una GPU remota”

• 4) Laptops con mucha RAM como AMD Strix Halo / Ryzen AI / Framework 128GB + llama.cpp/Continue.dev

  • Ventajas
    • Con 128GB de RAM, Qwen3 Coder 30B ya se puede usar de forma práctica, y permite un modo híbrido donde algunas capas van en GPU/NPU y el resto en RAM
    • Según lo que comentan, fue una opción realista cuando “el código no puede salir de la empresa” o cuando “como es AMD, el soporte de drivers en la nube todavía deja que desear”
    • Funciona bien un esquema como lemonade-server, dejando un servidor simple de llama.cpp arrancando automáticamente al iniciar, y conectando el editor por red
  • Desventajas
    • Hay reportes de que en Linux el ahorro de energía / cámara / drivers todavía no están del todo pulidos, y a veces había que esperar al kernel 6.18
    • El rendimiento de la NPU no llega al nivel de NVIDIA, así que ni soñar con “agentes de nivel frontera”; al final se queda como asistente de 20~30B
    • La información para AMD suele estar dispersa entre repos de GitHub y foros, así que la densidad de recursos es menor que en Mac o NVIDIA

• 5) Laptops comunes de 16~32GB (MacBook Air, M2/M3 Pro con poca RAM) + modelos 7B~12B solo para autocompletado FIM

  • Ventajas
    • Incluso usando solo qwen2.5-coder:7b, mistral 7b instruct o gemma3:12b, ya resuelven rápido cosas como “continúa esta línea” o “¿cómo era esta sintaxis de SQL?”
    • Con el plugin llama-vscode o Continue.dev, el autocompletado sigue funcionando aunque se corte internet, así que no rompe el ritmo de trabajo
    • La exigencia de hardware es baja, así que casi no hay calentamiento ni ruido de ventiladores, y la batería tampoco se drena rápido
  • Desventajas
    • En cuanto el contexto se alarga un poco, la tasa de disparates sube enseguida, y tareas como refactorización o generación de tests, donde hay que entender varios archivos a la vez, son casi imposibles
    • La mayoría fue tajante: “esto no reemplaza a los modelos en la nube; sirve solo para autocomplete”
    • Como hay que bajar el modelo agresivamente a 4 bits, el margen para elegir modelos es limitado

• 6) Configuración totalmente offline o priorizando privacidad (Ollama + Open WebUI + VPN)

  • Ventajas
    • Si dejas en casa una Mac Studio M4 Max 128GB o un desktop con Ollama + Open WebUI, desde fuera puedes conectarte por VPN desde laptop o teléfono y todo sigue siendo local
    • Quienes usan esta estructura destacan cosas como “ya casi no uso ChatGPT” o “como la versión no cambia, mis prompts ajustados no se rompen”
    • Dentro de una empresa, es la arquitectura más fácil de explicar cuando existe el requisito de que “ningún código puede usarse para entrenamiento”
  • Desventajas
    • Tienes que encargarte tú mismo de actualizar o cambiar modelos, así que no existe esa sensación de que “se vuelve más inteligente solo” como en la nube
    • Si la GPU es débil, a partir de 20B todo se vuelve lento enseguida, así que al final terminas ampliando hardware y llega el momento de pensar “¿por qué no lo hice en la nube?”

• 7) Conclusión compartida en general

  • Solo con una laptop, todavía es difícil reemplazar Claude Code / GPT-5 + agente, y lo local encaja mejor para generación corta de código, ayuda, resúmenes y autocompletado
  • Por eso, los patrones más repetidos fueron “laptop ↔ caja grande en casa” o “Mac de 128GB para mover rápido solo modelos de 20~30B”
  • Aun así, todos coincidían en lo mismo: si necesitas privacidad garantizada + casi nada de latencia + una versión que no cambie, entonces hoy por hoy lo local sigue siendo la respuesta

[kaydash]

Creo que sería mejor configurar un bearer token y usar ssh tunneling en lugar de usar una VPN.

[savvykang]

Creo que empezar con self-hosting de LLM va a seguir sin cuadrar en términos de costo-beneficio durante los próximos 5 años, porque la inversión inicial es demasiado alta. Planeo volver a evaluarlo en 3 a 5 años, cuando aparezca hardware suficientemente rápido con una ventaja de precio atractiva, aunque sea limitado a autocompletado de código.

Configuraciones que revisé

1. Configuración todo en uno: no es posible ejecutar un LLM en el equipo de trabajo. Incluso para correr herramientas de desarrollo y apps basadas en navegador, ya falta RAM.
2. Configuración con una máquina dedicada para LLM: en la empresa no hay tarjeta gráfica, así que no se puede ejecutar. Y tampoco es fácil adelantar la inversión en especificaciones, incluso para una PC personal.

[GN⁺]

Comentarios de Hacker News

• Quería experimentar directamente con IA, así que compré una Dell Precision 3620 Tower i7-7700 usada.
  Le amplié la RAM y también cambié la fuente de poder para ponerle una RTX 3060 como GPU.
  Instalé Ubuntu Server, la configuré como un nodo del clúster k3s de mi casa y estoy ejecutando Ollama y OpenWebUI.
  La uso sobre todo para el etiquetado y resumen con IA de Karakeep, pero también para analizar la cámara del driveway y detectar vehículos de reparto con código Python.

• Estoy ejecutando Ollama sobre CPU, sin GPU, en una Dell Precision T710 (Xeon E6320, 120GB RAM, RAID5 SSD 240TB).
  Estoy trabajando en un proyecto para indexar con RAG las leyes electorales de los 50 estados y visualizar problemas de inconsistencias terminológicas y alucinaciones.
  El objetivo es identificar las brechas de integridad en los procedimientos electorales.
  El mapa mental relacionado puede verse en Election Frauds v1.4 Mindmap PDF

  • Es realmente genial usar tu talento en proyectos sociales como este.

• Sí programo con LLM locales, pero ni pensarlo en una laptop.
  Los uso en un servidor con GPU, cambiando modelos con llama.cpp + llama-swap.
  La configuración que más me ha satisfecho es Aider + gpt-oss-120b.
  Tal vez también se podría con Ryzen AI Max+ 128GB RAM, pero el hardware que no es NVIDIA es muy lento.
  También puedes elegir solo proveedores sin retención de datos a través de OpenRouter.
  Pero GPT5 o Claude son mucho más rápidos y baratos que hacerlo en local.

  • Hice un agente RAG con gpt-oss-120b y lo entrené con documentación de GCP.
    ChatGPT obtuvo 46/50 en 6 minutos, y gpt-oss-120b logró 47/50 en 1 hora.
    Lo ejecuté en un entorno con i7 + 64GB RAM + GPU de 8GB VRAM.
  • Enlace de GitHub de llama-swap

• Si quieres ejecutar un agente de código local en Mac, puedes hacerlo así:

  1. npm install -g @openai/codex
  2. brew install ollama; ollama serve
  3. ollama pull gpt-oss:20b
  4. codex --oss -m gpt-oss:20b
     Funciona sin internet y requiere Mac con M1 o superior + 24GB de memoria GPU.
     El modelo 120b rinde 1.5 veces más que el 20b, pero exige 5 veces más recursos.
  • LM Studio es más simple y también se integra con JetBrains IDE o Zed.
  • Me pregunto si con el modelo 20b realmente pudiste crear código que valiera la pena.

• Estoy ejecutando Qwen3-Coder-30B-A3B Q4 quant con llama.cpp en una MacBook Pro 64GB.
  En VSCode uso continue.dev y configuro el prompt del sistema de forma breve.
  Obtengo una velocidad de 50 tokens por segundo y 550 tokens de procesamiento.
  En tareas cortas y claras muestra una calidad similar a la de los modelos frontier.
  Estoy satisfecho porque es rápido y estable incluso en entornos offline.
  Para tareas más complejas uso la API de Claude o Deepseek.

  • Me gustaría saber si probaste el modelo Instinct de continue.dev y cómo se compara con Qwen.
  • También hubo una solicitud para compartir el enlace de descarga en Hugging Face y saber si en una máquina de 128GB convendría usar otro quant.
  • También hubo un comentario preguntando cómo ejecutar Qwen3 en llama-vscode (enlace al issue).

• Si vas a comprar una Mac, recomiendo como mínimo un modelo Pro.
  La Air no tiene ventilador, así que no maneja bien la temperatura, y creo que una Studio es mejor que una Mac mini.
  Con la app TG Pro puedes ajustar los ventiladores para que reaccionen más agresivamente (unos $20).
  Ejecuto el modelo GPT OSS 20B en una MacBook Pro M4 Pro + 24GB RAM, pero la ventana de contexto es pequeña.
  Con el modelo de 128GB probablemente se podría programar offline todo el día.

  • La Mac mini también tiene ventilador, y la Studio solo es una versión con un chip más potente.
  • Si vas a comprar una Mac, lo ideal sería una configuración con chip Max o Ultra + memoria al máximo.
  • La MacBook Pro de 128GB tiene un rendimiento abrumador en caché de contexto.
  • La ventana de contexto base es pequeña, pero en gpt-oss-20b puede ampliarse 4 veces.
  • También hubo opiniones de que incluso con M3/M4 + 128GB la velocidad cae al procesar prompts largos.

• Estoy usando una Apple M4 Max 128GB conectada por USB-C a una GPD Win 4 (Ubuntu 24.04).
  Combino Claude Code, RA.Aid y llama.cpp para distribuir tareas con Agent Organizer.
  Claude automatiza desde el diseño de arquitectura hasta la revisión de código.

  • Hubo una pregunta sobre qué papel cumple la GPD Win 4 y si se usa para procesamiento distribuido con modelos pequeños.
  • También hubo comentarios preguntando la velocidad de procesamiento de tokens de cada modelo.
  • Y otra pregunta sobre qué es exactamente Agent Organizer.

• Si quieres ver estaciones de trabajo para LLM, recomiendo el canal de YouTube de Alex Ziskind(@AZisk).
  Tiene varias reseñas de workstations para LLM locales.
  Presenta bien y sus consejos son prácticos.

  • Seguramente tiene patrocinio, pero impresiona que asuma el riesgo de comprar el equipo él mismo para hacer las reseñas.
  • También hubo un comentario recomendándolo como “un canal que va directo al grano, sin relleno”.

• En una MacBook Pro M4 Max 128GB uso principalmente LMStudio y Ollama.
  Los modelos son qwen3-coder-30b A3B Instruct 8-bit MLX y gpt-oss-120b-MXFP4-Q8.
  Tiene límites para generar grandes cantidades de código, pero es suficiente para resumir y documentar repos locales.
  La comunidad relacionada también es muy activa.

  • r/LocalLLM
  • r/LocalLLaMA
  • Si usas Coderunner en Mac (enlace de GitHub), puedes ejecutar en sandbox de forma segura el código generado por el LLM.
  • Si conectas la API de LM Studio con qwen CLI, puedes crear un entorno similar a Claude Code.
    Para generar README prefiero gemma3-27b-it-qat y gpt-oss-120b.

• En una MacBook Pro M1 Pro 32GB + Asahi Linux estoy ejecutando Qwen3:32b por CLI.
  Lo uso para recibir ayuda con ensamblador ARMv8 y temas relacionados con SoC.
  La velocidad es apenas un poco más lenta que mi velocidad de lectura, así que es bastante usable.
  Me interesó Qwen3-coder después de escuchar que es más rápido.
  Prefiero un entorno totalmente local sin nube ni integración con agentes.
  Como Ollama se ha alejado de su enfoque offline, ahora quiero cambiarme a llama.cpp.
  Como el formato del modelo es distinto, estoy pensando si podré usar directamente los modelos de Ollama.
  [Atención] En Linux el consumo eléctrico es alto, así que hay que usarlo conectado a la corriente.

  • Qwen3 Coder tiene una arquitectura MoE (30B con 3B activos), así que es mucho más rápido.
    Es menos inteligente para tareas generales, pero muy eficiente para trabajo centrado en programación.

[chcv0313]

Mientras sigo leyendo... me hace pensar que, inesperadamente, sí podría haber demanda para DGX SPARK, ¿no? Al principio pensaba: ¡esa cosa tiene una relación costo-rendimiento pésima, quién la compraría!, pero...

[aer0700]

Debido a la política interna de seguridad, no estamos usando en absoluto APIs externas de LLM, y estamos usando lo que nos provee el departamento interno de gestión de la nube: GPT OSS basado en vllm.

[aer0700]

Es un poco ambiguo llamarlo local.