Qué están probando
La pregunta original parte de un usuario que quiere saber si alguien logra sacar partido a agentes locales en 16 GB de VRAM para tareas cotidianas, investigación y desarrollo. Dice que ya ha probado Goose, Hermes Agent y OpenCode, pero sin llegar a un resultado satisfactorio. En las respuestas, la idea que más se repite no es “cambia de *harness*”, sino “empieza por un modelo que funcione bien y luego ajusta el resto”.
Entre las configuraciones que aparecen hay varias repeticiones de una misma familia: Qwen 3.8 27B en distintas cuantizaciones, Qwen 3.5 9B, Gemma 4 12B IT y variantes de Qwen orientadas a contexto largo o a programación. Un usuario afirma que Strata con Qwen 3.8 Flash Next va bien en 16 GB de VRAM porque mantiene los expertos en RAM y solo conserva en VRAM los más usados. Otro comenta que, con una RTX 5060 Ti de 16 GB y 32 GB de RAM, usa Qwen3.8 con un contexto de 128K y lo considera claramente mejor que opciones más pequeñas.
El patrón que se repite: más RAM del sistema y menos herramientas
Varios mensajes coinciden en una misma estrategia: compensar la falta de VRAM con más memoria principal y con *harnesses* menos cargados de herramientas. Un participante describe una configuración con Qwen 3.8-27B y 32 GB de RAM en la que trabaja sobre programación dentro de OpenCode y usa como único servidor MCP una instancia de SearXNG para buscar información cuando la memoria interna no basta. Otro explica que ha retirado herramientas JSON y las ha sustituido por llamadas de consola para ahorrar espacio en el *system prompt* y dejar más margen al contexto útil.
Ese enfoque tiene una consecuencia práctica clara: en equipos de 16 GB, cada herramienta adicional consume contexto y complica la ejecución. Un comentarista señala que otros *harnesses* recortan gran parte del contexto disponible solo para tareas básicas por culpa de demasiadas herramientas innecesarias. La idea de fondo es que, con margen estrecho, el diseño de la cadena de herramientas importa tanto como el modelo elegido.
Qué uso parece funcionar mejor
Las respuestas no describen un único caso de uso ganador, pero sí varias fronteras bastante claras. Para programación ligera, algunos usuarios dicen que OpenCode les funciona bien con modelos ajustados. Uno cuenta que usa un MacBook Air M4 con 16 GB de memoria unificada y llama.cpp con Qwen3.5-9B en Q4_K_M; dice que el *tool calling* con entradas muy cortas funciona bien, pero que en tareas de código algo más largas llama.cpp acaba sin memoria y falla. Ese mismo usuario añade que el chat integrado le ronda los 15 tokens por segundo, suficiente para un uso práctico si no se fuerza demasiado el sistema.
También hay quien apunta a usos más cercanos a un asistente personal. Un participante describe un flujo con Pi que le permite gestionar su base de conocimiento, revisar y clasificar correo, ejecutar su sistema de productividad y aplicar cambios en el repositorio. Según su testimonio, el truco está en cargar habilidades bajo demanda y en reducir el *system prompt* a lo imprescindible. Ese mismo usuario insiste en que, con 16 GB, hay que ser frugal: el modelo, el contexto y el flujo de herramientas dejan poco margen para improvisar.
Límites que siguen apareciendo
El hilo también deja ver las limitaciones de estas configuraciones. No todo el mundo consigue resultados aceptables: un usuario dice que, incluso en un portátil con 128 GB de memoria, sigue prefiriendo opciones no locales porque la velocidad o la calidad no le convencen. Otro comenta que, aunque el sistema funciona, la velocidad cae o el soporte se vuelve inestable en tareas con imágenes o en flujos más complejos.
Hay además una diferencia importante entre “funciona” y “sirve de verdad”. Varias respuestas hablan de contextos de 70K, 128K o incluso más, pero esos datos no equivalen a una validación independiente del rendimiento general: son experiencias de usuarios, en su hardware y con sus ajustes concretos. Lo que sí queda claro es que 16 GB de VRAM obliga a elegir entre más contexto, más velocidad o más complejidad de herramientas. No suele haber espacio para todo a la vez.
Para quien esté montando hoy un equipo local, la lectura práctica es bastante sencilla: si el objetivo es un agente útil y no una demo, los comentarios favorecen modelos medianos bien afinados, bastante RAM de sistema, pocas herramientas y un *harness* que no gaste contexto de forma innecesaria. Lo que no queda resuelto en la conversación es hasta qué punto estas recetas son repetibles en otras GPU de 16 GB y con cargas más exigentes como investigación larga o desarrollo con varias sesiones simultáneas.
