Ask HN: ¿Alguien ha reemplazado Claude/GPT por modelos locales para la programación diaria?
(news.ycombinator.com)- Algunos desarrolladores ya están dejando por completo los modelos en la nube por privacidad de datos y por el uso gratuito de los LLM, y pueden trabajar con un entorno de codificación offline containerizado y aislado en sandbox sin llamadas a redes externas
- Los modelos principales son Qwen3.6 35B-A3B (rápido gracias a 3b parámetros activos) y modelos densos de 27B, con un tradeoff entre precisión al programar y velocidad de generación de tokens
- La combinación más mencionada es Pi harness con llama.cpp, y que las llamadas a herramientas (tool calling) hayan empezado a funcionar de forma consistente en modelos locales mejoró mucho la experiencia de uso
- Frente a Claude Opus, los modelos locales están al nivel de "un junior que necesita guía vs un senior que diseña contigo", por lo que son esenciales prompts precisos y descomposición de tareas
- Hoy los modelos locales son evaluados como más o menos al nivel frontier de hace 8 a 18 meses, pero ofrecen ventajas reales: gratis, privacidad y sin preocuparse por cuotas
Casos de migración a modelos locales y configuraciones de hardware
- Se ejecuta Qwen3.6 35B-A3B con Pi harness en una Mac Studio de 128GB o una MacBook con 36GB de RAM, y se completó el rediseño total de la página principal y el blog de un sitio web basado en Django + Wagtail
- Sin acceso a internet, el modelo no siempre sabe qué hacer al desarrollar con Wagtail, que es menos conocido
- Para tareas complejas se usa Qwen3.5 122b, pero con 10b parámetros activos es bastante lento
- En un entorno de memoria unificada Strix Halo 128GB, Pi se aísla en un contenedor y solo se le permite acceso al directorio de trabajo, sin credenciales
- Para chat y traducción se usa Gemma 4 31B, y para audio Gemma 4 12B
- Aunque tienen muchos modelos como Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash y GPT-OSS 120B, para programar el óptimo es 35B-A3B
- En una máquina dual RTX3090 armada hace 5 años, se logran ~150tok/s con modelos Qwen y Gemma en cuantización UD-Q4_K_XL, procesando todo el contexto de 300k dentro de la VRAM
- Reemplazó una suscripción Claude de $100/mes, y para uso personal lo gratuito pesa más
- Se realizaron proyectos variados como launcher para Android TV, portal de administración k8s, integración con Home Assistant y gestión de compras y dieta
- Con una RTX 6000, la combinación de Qwen 3.6 27b + Open Code cubre el 90% de la programación, pero para tareas muy complejas y pulido de UI se vuelve a Codex
- En 256k de contexto, al superar 100k baja la calidad y la velocidad, y después de 150k se vuelve grave
- En una RTX 5090, se usa Qwen 3.6 27b (cuantización Q6) + llama.cpp, limitando la GPU de 600W a 450W para mantener bajo el ruido
- Ya se extendió a tareas cotidianas como commits de ramas, generación de PR, liquidación de facturas con Stripe CLI y análisis de carga en Elasticsearch
Tipos de modelos y características de rendimiento
- La distinción entre MoE y modelos densos impacta directamente en la calidad al programar
- Qwen3.5-122B es en realidad 122B-A10B, un MoE donde solo se activan 10B, mientras que Qwen3.6-27B es un modelo denso donde los 27B completos siempre están activos
- La calidad equivalente en un modelo denso puede aproximarse con la media geométrica entre parámetros activos y totales del MoE, sqrt(35×10)≈18.7
- El MoE ofrece menor calidad que un denso del mismo tamaño, pero es más rápido y puede ejecutarse incluso con offload a RAM de CPU
- El nivel de cuantización afecta la aparición de loops y la precisión
- La cuantización Q8 es más lenta, pero reduce loops y ahorra tiempo total
- Es muy sensible a la cuantización de la parte K del caché KV; con F16 K + Q8 V disminuyen mucho los loops
- Agregar una segunda GPU no busca velocidad de inferencia sino más capacidad de VRAM
- Gemma-4 31B denso y 26B MoE tienen calidad similar en cuantización Q4, pero el MoE es ~3 veces más rápido (150tok/s vs 46tok/s)
Límites de los modelos locales y estrategias para compensarlos
-
Necesidad de prompts precisos
- Si se dejan suposiciones abiertas, el modelo toma el camino más corto (por ejemplo, CSS dentro de HTML) y produce resultados que no son los mejores a nivel de arquitectura
- Si no se especifica la arquitectura, hace arreglos rápidos y desordenados; si no se le pide quitar frases de debug, las deja
- Claude Opus infiere la intención del usuario, pero los modelos Qwen pequeños hacen solo lo que se les indica; hay que "activar" explícitamente el conocimiento de diseño
-
Loops y errores en herramientas de edición
- Se equivoca con frecuencia al llamar herramientas de edición y, en vez de reintentar, consume tokens de razonamiento y vuelve a leer archivos
- Muchas veces un reintento directo corrige la llamada de edición, pero el modelo asume que el problema es más fundamental y gasta tokens de más
- Un enfoque de edición basado en hashes (referenciando el hash de cada línea de código) puede reducir errores, pero luego colapsa de otra manera cuando se agota la calidad del contexto
- Restringir la reescritura y forzar edición mediante reglas en AGENTS.md mejora parcialmente el problema
-
Gestión de la ventana de contexto
- Una ventana de 65,000 se supera solo con leer la estructura de archivos de código; se necesitan más de 200k
- Qwen3.6-35b maneja correctamente 128k en 16gb de VRAM dentro de un contexto de 256k
- Qwen3.6-27B soporta contexto de 1 millón de tokens, pero en un DGX Spark con caché KV f16 requiere cerca de 100GB de memoria
Problemas de caché de prompts y preservación del razonamiento
- Los modelos híbridos de Qwen tienen problemas para manejar prompt caching y vuelven a procesar todo el contexto en cada turno
- La mayoría de los modelos locales no fueron entrenados para preservar todo el razonamiento entre turnos, así que después de cadenas largas de tool calling hay que reprocesar con el razonamiento eliminado
- Qwen 3.6 sí fue entrenado para preservar razonamiento, y mejora la reutilización del caché con
chat-template-kwargs = {"preserve_thinking": true}
- Los LLM modernos ya no usan solo full attention, sino también local attention (sliding window, modelo de espacio de estados Mamba-2)
- Full attention tiene costo O(n²) y es caro, además de débil para razonamiento cuyos valores se reemplazan con el tiempo
- Local attention guarda snapshots y, al recalcular el caché, retoma desde el último snapshot; si el snapshot es grande, hay límites para conservarlo
- Desde Qwen 3.5 se usa Gated DeltaNet, alternando capas de attention y SSM
- Vulkan resulta paradójicamente más rápido que ROCm, y mantener llama.cpp en su versión más reciente es importante para resolver el problema de reprocesamiento
- La divergencia del tokenizador, donde los tokens generados de forma autorregresiva se parsean distinto en el prefill, sigue siendo difícil de resolver
Debate sobre costos y economía eléctrica
- 2x RTX3090 cuestan unos $4400, equivalentes a 3.6 años de Claude a $100/mes, sin incluir electricidad ni otras piezas
- Incluso en 3.6 años, es probable que las GPU de alta capacidad sigan manteniendo precio
- En regiones con electricidad cara, el punto de equilibrio puede ser de alrededor de 1 año
- El consumo eléctrico es más bajo de lo esperado
- A plena carga de 1.2kw, cuesta alrededor de $0.12/hora, y con solar sale todavía más barato
- La carga de inferencia no se parece a jugar, así que el problema energético es menor; el sistema queda en 200W en reposo y 350-450W en inferencia
- Sobre cuándo comprar hardware
- Ahora no sería un buen momento para comprar; el próximo buen momento se proyecta dentro de 24 a 36 meses
- Una Mac mini M4 Pro con 48gb de RAM unificada, por ~$2k, se recomienda como equipo económico para inferencia, con ~150tok/s y potencial de uso por 10 años
- La AMD R9700 con 32gb de VRAM por ~$1200-1400 sería mejor para IA que 2x 9070
- Rentar capacidad (suscripción cloud) también es una estrategia válida; no todo el mundo puede invertir mucho dinero en hardware
Evaluación frente a modelos frontier
- Se repite la valoración de que los modelos locales están al nivel de "la calidad de modelos punteros de hace 8 a 12 meses"
- En benchmarks, Qwen 3.6 35B-A3B supera a Claude 4 Opus, aunque existe la posibilidad de benchmark gaming en algunos modelos open source
- En una prueba de sistema operativo para navegador en YouTube, Qwen 3.6 generó más funciones operativas que Claude 4 Opus
- Aun así, eso sería frente a modelos frontier de hace un año, y muchos objetan que un MoE de 3B activos no se puede comparar con Opus o Sonnet actuales
- La discusión gira en gran parte alrededor de la falta de acuerdo sobre qué significa "nivel Opus"
- El término se usa desde Claude 3 Opus en 2024, pero sigue habiendo brecha frente a los modelos más nuevos como Opus 4.8 y 4.6
- En noviembre del año pasado hubo un salto escalonado en los modelos frontier con Opus 4.5 y GPT 5.2, y normalmente "nivel Opus" se refiere a 4.5 en adelante
- Los modelos open weights más grandes requieren hardware del nivel de servidores con 8x H100; los modelos caseros todavía no llegan ahí
- Algunas personas sitúan a los modelos locales entre Haiku 4.5 y Sonnet 4.5, capaces de dar buenos resultados con micromanagement
- Es probable que siempre exista una brecha entre frontier y local, pero para muchos usuarios lo local ya es suficientemente práctico
Estrategias de harness y flujo de trabajo
- Pi harness es la recomendación más repetida y funciona como un kit para desarrollar agentes; lo comparan con "el neovim del vscode de Claude"
- Incluye herramientas básicas (acceso a archivos, edición y bash), y se le pueden agregar extensiones como adaptadores MCP y búsqueda web
- Con el comando
/treese vuelve al contexto previo a una llamada de herramienta fallida, y con/newse reinicia el contexto
- Los flujos jerárquicos y con reparto de roles ayudan a compensar las limitaciones
- El modelo frontier redacta especificaciones, diseño y plan de ejecución, mientras el modelo local implementa
- Se conectan agentes por rol (project manager, schema agent, coding agent), y con un orquestador y Playwright solo se pasa el error a la siguiente etapa
- Dividir el trabajo en TODOs atómicos y señalar archivos de referencia ahorra contexto
- OpenCode cambia el prompt del sistema en cada turno, por lo que a veces no es compatible con el caché KV, y su soporte para LLM locales es manual y complejo
- Ollama recibe críticas por añadir modelos cloud y monetización; se recomiendan llama.cpp y llama-swap, y en macOS llm-mlx es 10-15% más rápido
Ejemplos de configuraciones concretas
- En un entorno con AMD 7900xtx 24gb + 5950x + 64gb DDR4, se ejecuta Qwen3.6-27B-MTP-UD-Q4_K_XL con llama.cpp Vulkan
- Flags principales:
-ngl 99(offload de todas las capas a GPU),-c 80000(contexto de 80K),--cache-type-k q8_0 --cache-type-v q8_0(caché KV de 8 bits),-fa on(flash attention),--spec-type draft-mtp(draft MTP) - Sampling:
--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0(valores recomendados por Qwen para coding) - Rendimiento: generación de tokens ~65t/s, procesamiento de prompts ~600t/s, cold start ~30 segundos
- Con la combinación de Crush harness + Headroom + búsqueda web Exa MCP, se canceló la suscripción personal a Claude Code
- Flags principales:
- En una V100 32GB, se usa Qwen3.6-27B-UD-Q4_K_XL + Pi, aplicando el fork llama-cpp-turboquant y un parche MTP
- Con 200,000 de contexto,
--spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3logra 45-60 t/s
- Con 200,000 de contexto,
- En Strix Halo 128GB con Qwen3.6-35B-A3B, el procesamiento de prompts ronda ~800tps y la generación 50tps, con consumo casi nulo en reposo
- Se lamenta que no exista versión 122B, y en memoria unificada los modelos densos son lentos por límites de ancho de banda
- También se expresan quejas por la falta de detalles, y se pide especificar con precisión cuantización, parámetros, contexto, GPU, VRAM y configuración del harness
2 comentarios
Cuando usé Pi-coding-agent+Qwen3.6-27B-MTP-GGUF, el rendimiento fue más o menos comparable a Sonnet 4.5. Fue suficiente para crear apps sencillas y, cuando hacía falta, de vez en cuando le conectaba APIs gratuitas (como GLM5.1). El consumo eléctrico de GPUs del nivel de una 4090/5090 sí es alto, pero con un agente bien hecho no hay muchas situaciones en las que realmente tengas que dejarlo corriendo durante horas.
Comentarios de Hacker News
Greenpants: La privacidad de los datos y los LLM gratuitos son importantes para mí, así que uso Pi coding harness dentro de contenedores y sandbox, completamente offline.
Uso Qwen3.6 35B en una Mac Studio de 128GB o una MacBook de 36GB, y como los parámetros activos son 3B, va bastante rápido. Rediseñé por completo mi sitio y blog con Django + Wagtail, pero como Wagtail es menos conocido, sin internet el agente no siempre lo maneja bien
Para tareas complejas también usé Qwen3.5 122B, pero como tiene 10B activos es mucho más lento. Comparado con modelos grandes como Claude, hay que formular las preguntas con mucha precisión, y los supuestos que uno deja en blanco suelen resolverse por el camino fácil, tomando decisiones arquitectónicas poco deseables como meter CSS en el HTML
También falla seguido al llamar herramientas de edición y cae en bucles. Qwen3.6 35B tiene conocimiento general, pero es como un junior al que hay que ir guiando todo el tiempo; Claude Opus se parece más a un senior con quien puedes pensar la arquitectura. Si Opus da una aceleración de 15x, Qwen totalmente offline da más o menos 5x, pero sigue siendo impresionante si consideras que es gratis
llama.cppen otro contenedorPermito acceso a la red, pero bloqueo las credenciales y solo dejo acceso al directorio de trabajo y
~/.pi. Uso una laptop Strix Halo con 128GiB de memoria unificada, y como prefiero no programar con herramientas propietarias, no puedo hacer una comparación seria con modelos frontierSigo siendo escéptico con la IA, así que paso más tiempo tratando de romper los modelos y ver sus fortalezas y debilidades que usándolos de verdad, pero para coding con agentes elijo más seguido Qwen 3.6 35B-A3B. Para chat general y traducción uso mucho Gemma 4 31B, y para audio Gemma 4 12B
También tengo guardados Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7 y GPT-OSS 120B, pero para programar en esta configuración Qwen 3.6 35B-A3B es actualmente lo más cercano al sweet spot
Si dejas que qwen complete los detalles por su cuenta, entra en un bucle justo antes de escribir. El problema de que no pueda editar también es raro, así que en
AGENTS.mdcambié las reglas para limitar la edición en lugar de reescribir, y ayudó un pocoEl enfoque puede verse en https://blog.can.ac/2026/02/12/the-harness-problem/. No lo he benchmarkeado bien, pero por sensación parece haber menos errores de edición, aunque puede variar según el entorno
horsawlarway: Para uso personal cancelé la suscripción de 100 dólares al mes de Claude y la reemplacé con pi harness apuntando a unsloth studio y modelos Qwen y Gemma
En una máquina con doble RTX3090 que armé hace unos 5 años corro
unsloth/Qwen3.6-35B-A3B-MTP-GGUFyunsloth/gemma-4-26B-A4B-it-GGUFcon cuantización UD-Q4_K_XL, y ambos manejan unos 150tok/s y 300k de contexto total dentro de la VRAMNo son tan buenos como Claude, pero son gratis, y para uso personal la diferencia no es un gran problema. También uso OpenClaw en el mismo servidor de inferencia, y es un caso de uso que encaja bastante bien con modelos locales
Por ejemplo, hice un launcher alternativo para Android TV, un portal de administración para servicios en k8s, integraciones y automatizaciones de Home Assistant, gestión de compras y comidas, y flujos de trabajo de ComfyUI para generar assets 3D. Si fuera software que genera dinero, seguiría recomendando proveedores pagos, pero los modelos locales también pueden hacer cosas bastante geniales
gemmacuantizado con UD-Q4_K_XL, quizá también valga la pena revisar modelos QAT comounsloth/gemma-4-26B-A4B-it-qat-GGUFConsulta https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF y https://blog.google/innovation-and-ai/technology/developers-.... La actualización del 9 de junio también añadió soporte para MTP
unsloth/Qwen3.6-35B-A3B-MTP-GGUFen una sola 3090, con contexto de 128k y cuantización Q4_K, y da alrededor de 40~60tok/sLo más molesto fue la calidad de salida en tareas reales de programación de complejidad media. Tenía que estar cambiando todo el tiempo entre “empujar con prompts” e “implementar yo mismo”, y la carga de cambio de contexto era alta porque cada pocos minutos tenía que decidir si yo estaba pidiéndolo mal o si al modelo no le daba
Tampoco logra pasar bien de detalles de implementación de bajo nivel a diseño de alto nivel, e incluso cosas como tablas no las renderiza fácilmente. Con Claude no tengo esos problemas, así que por ahora me cuesta verlo como reemplazo; ojalá en unos meses ya sea posible. Reemplacé Claude CLI con
aider, aunque quizá esa decisión tampoco sea la óptimabluejay2387: Resuelvo alrededor del 90% de mi trabajo de programación con Qwen 3.6 27B, Open Code, habilidades personalizadas y Semble
No es tan inteligente como CC o Codex, pero puede sacar adelante la mayoría de las tareas. Tengo una RTX 6000, así que el TPS es suficientemente rápido, y originalmente esta GPU era para otro trabajo
Lo probé como experimento para ver qué tan cerca podía llegar de los modelos frontier, y resultó lo bastante bueno como para seguir usándolo. Para tareas realmente complejas o para pulir la UI todavía vuelvo a Codex, y la UI parece ser el punto más débil de Qwen
No lo recomendaría. No mucha gente tiene una RTX 6000, y el costo equivale a varios años de suscripción a MAX CC o Codex. Aun así, se ve potencial, y en unos años podría ser práctico
En un contexto de 256k fijé el compact target en 75%, y cuando la conversación pasa de 100k la calidad y la velocidad empiezan a caer; después de 150k se vuelve muy problemático. También probé Qwen 3.5 122B, pero programaba mucho peor que 3.6 27B. Gemma 4 31B es buena para otras tareas, pero para programación Qwen va por delante, y Nemotron Super 120B también rindió peor que Qwen para programar, lo cual me sorprendió
Como es local, no tengo que preocuparme en absoluto por precio por token, cuotas, husos horarios ni sensibilidad de los datos. Limité la GPU de 600W a 450W y así queda muy silenciosa incluso durante la inferencia
Lo uso mucho no solo para programar, sino también para tareas cotidianas. Le encargo cosas como hacer commit en una rama y crear un PR, traer facturas impagas o vencidas con Stripe CLI y conciliarlas con un CSV bancario, resumir la causa de la carga actual usando credenciales de Elasticsearch, o verificar si el codebase soporta X y dónde está implementado
A10B es un modelo de mezcla de expertos, así que solo se activan 10B parámetros a la vez, mientras que Qwen3.6-27B es un modelo denso donde los 27B parámetros están siempre activos. Por eso, en muchas tareas un modelo denso de 27B puede rendir mejor que 122B-A10B
Es mejor hacerlo yo mismo, y la implementación sale desastrosa o falla por completo al depurar. Salvo por una búsqueda algo más inteligente, todo lo que esté por debajo de Sonnet se siente como una pérdida de tiempo
También me parece raro usar Codex para pulir UI. Codex es famoso por ser malo en UI y está muy por detrás de Claude Opus. Altman incluso publicó que están mejorando eso en el siguiente modelo
pierotofy: La combinación Llama.cpp + Qwen3.6-35B(MTP) + OpenCode es bastante capaz en una sola RTX 3090, y más rápida que la mayoría de los modelos en la nube
La calidad se siente como usar un modelo puntero de hace 8 a 12 meses. Dejé la configuración en https://github.com/pierotofy/LocalCodingLLM/
Me interesa conocer experiencias de usuarios de Mac con configuraciones parecidas. Veo mucho debate sobre lo local, pero la línea base cambia todo el tiempo y no conozco bien la terminología. Quisiera una impresión objetiva de lo que se pierde y se gana al pasarse a local
codinhood: No creo que esta pregunta vaya a tener muchas respuestas “reales”. Ahora mismo el costo de oportunidad de no usar los modelos más nuevos y mejores es demasiado alto
Aunque lo investigue cada mes, siempre llego a la misma conclusión. Por ahora no vale la pena el tiempo, esfuerzo y costo de acercar un modelo local y su ecosistema de herramientas de programación a Sonnet/Opus de Claude Code
Si ya valiera la pena, habría sido algo tan disruptivo que estaría en las noticias. No niego que alguien pueda haberlo resuelto, pero se parece más a aplicar la navaja de Occam para no caer en una madriguera interminable
Los modelos de nivel Mythos están en la frontera de razonamiento, pero no sirven de mucho para el tipo de problemas que la mayoría de los desarrolladores intenta resolver. Lo más probable es que la familia actual Sonnet/Opus, alrededor de 4.8, termine siendo el nivel ampliamente usado en empresas
Los modelos locales todavía no llegan ahí, pero las familias DeepSeek, Kimi, GPT y MiniMax se pueden usar barato vía APIs de NVIDIA, OpenRouter o Groq, y están bastante al nivel de Sonnet
Así puedo seguir resolviendo lo necesario mientras traslado gradualmente más cosas a local. Incluso con el mismo hardware, la configuración local está mucho mejor que hace 2 meses, y comparada con hace 6 meses la mejora es dramática
Si de verdad crees que se llegará ahí en unos años, conviene empezar a experimentar desde ahora, y sobre todo en proyectos cortos o pequeños, o en proyectos grandes bien modularizados, podrías llevarte una buena sorpresa
sosodev: La pregunta abarca un rango demasiado amplio de capacidades y expectativas. Si solo corres modelos de 8B y esperas vibe coding o one-shot, está difícil
Si puedes correr modelos de alrededor de 30B, funcionan bastante bien en tareas con un alcance apropiado y bien definido. En este rango, por ahora Gemma4-31B y Qwen3.6-27B se ven como las mejores opciones
Si quieres inferencia más rápida, puedes cambiar a modelos MoE, pero en la mayoría de tareas se nota una caída clara. En tareas de alcance pequeño también se puede hacer one-shot o vibe coding, pero aun así funciona mucho mejor si hay guía
Si quieres capacidades de nivel frontera, necesitas al menos 128GB de memoria y mucho cómputo o muchísima paciencia. A la mayoría le falta dinero o paciencia. La paciencia con modelos locales no solo es esperar tokens, también incluye el esfuerzo de configurarlos y hacer que corran bien de acuerdo con tu flujo de trabajo y tu hardware
No creo que vaya a rendir bien en one-shot, salvo cambios muy triviales en un IDE o harness. Aun así, si una persona lleva el volante, va viendo el camino y maneja por debajo del límite de velocidad, como copiloto para tareas de contexto pequeño a mediano es rápido y suficientemente bueno
Comparado con hace unos años es sorprendente, y si no fuera por esto probablemente casi no usaría IA para programar. No me gusta la sensación de volverme torpe o quedarme bloqueado porque se cayó la conexión a internet
No esperaba confiabilidad perfecta, pero pensé que si le señalaba la diferencia al menos en el segundo intento lo corregiría. En la práctica, afirmó con toda seguridad que el código ya era igual y además añadió otro bug sutil
No sé qué tipo de trabajo sería suficiente para un modelo tan basura. Puede aparentar ser competente durante unos minutos, pero al final el resultado no cuadra. Como mucho, lo veo útil para búsqueda más inteligente o autocompletado
mgsram: Después de usar LLM locales durante cerca de un año, ahora me establecí con una combinación de Qwen3.6 27B denso GGUF, OpenCode y llmster (LM Studio) en una Mac Studio con 512GB de RAM
También probé Qwen 3.6 35B-A3B, pero la precisión del modelo denso está un escalón arriba, a cambio de sacrificar tokens por segundo. Qwen3.6 27B normalmente me da entre 25 y 40 tok/s
Al principio lo usaba en herramientas simples, pero en los últimos 3 o 4 meses lo he usado de verdad para programación de nivel producción en un stack de software automotriz en C/C++ y herramientas en Python. Que vaya más lento incluso ayuda a avanzar a un ritmo adecuado
Para desarrollo nuevo o reescrituras, trabajo con Sonnet para armar el diseño, la arquitectura, el razonamiento y un plan de ejecución detallado; luego lo divido en partes y lo meto como prompts precisos. Para trabajo sobre código existente hace falta criterio, y cuando siento los límites del modelo local vuelvo a Claude Code
Recientemente, con Qwen 3.6 hice una reescritura completa en C de un servicio de gestión de energía basándome en código C++ existente, un parser complejo de especificaciones en Excel y una herramienta para traducir contenido en CJK al inglés y meterlo en un KG
3abiton: Como todos mencionan Qwen, yo también corro Qwen 3.6 35B Q8(MTP) con Strix Halo y llama.cpp
Me da alrededor de 40 a 50 t/s y el rendimiento es realmente bueno. Lo he usado directamente con forge-code en zsh, y con contexto largo de más de 150k la calidad cae y empieza a olvidar
wsintra2022: Leyendo los comentarios aquí, no queda claro si son bots de proveedores de IA tratando de desanimar el uso local, o gente que de verdad tuvo malas experiencias con modelos de IA locales
Correr Qwen 3.6 27B con cuantización de 8k en una Mac Studio de 64GB no es una superpotencia universal de nivel frontera; simplemente está bien. Es gratis, privado, y la magia está en llevar a un ingeniero experimentado de la flojera a todavía más flojera
Uso llama.cpp y opencode para planear y ejecutar cambios de código, y luego me voy a recostar en la hamaca, lavar los platos o hacer otra cosa. Entro con tmux y ssh para revisar. Esa es la parte realmente sorprendente
garethsprice: En una Ada 4000 con 20GB de VRAM uso OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM, y la generación anda por unos 55 tok/s
OpenCode mete mucho contexto, así que en la práctica se siente más lento de lo que dicen los números. También han mencionado mucho Pi, así que pronto lo voy a revisar
Hago el plan con Opus, dejo que el agente local lo siga y luego lo valido con Opus. No es 100% local, pero estos modelos cada vez forman más parte del flujo de trabajo de producción
Por ahora quizá no valga la pena a menos que te guste meterle tiempo y dinero como hobby. No son tan buenos como Opus u otros modelos de frontera, pero en el rango donde aumentan las tareas repetitivas son “lo suficientemente buenos”
No hace falta un Rolls Royce para ir al supermercado si tienes un Corolla usado. También se vuelven posibles nuevos flujos de trabajo que con LLM de frontera salen demasiado caros. Lo dejé toda la noche haciendo fuzz testing como si fuera un usuario con Chrome devtools MCP, y hasta verificando capturas con multimodal; si piensas en el costo de Claude+capturas, impresiona
Eso de que van “12 a 18 meses detrás de la frontera” parece cierto. En 12 a 18 meses quizá se puedan correr modelos locales de nivel Opus por menos de 5 mil dólares, aunque los modelos de frontera también estarán más adelantados
arjie: No es local ni tampoco programación conversacional, pero corro DeepSeek V4 Flash con dos RTX Pro 6000 Blackwell
La velocidad bruta es de 160 tok/s, pero es un modelo de razonamiento. Mi uso es para escritura automática de código y revisión automática de otros sistemas. A veces hago que Pi escriba código y es rapidísimo, pero por costumbre sigo usando sobre todo CC y Codex
Todos los sitios que encontré estaban agotados, o solo vendían a empresas, o se veían sospechosos
stymaar: Ejecuta Qwen3.6-35B-A3B en una Strix Halo 128GB Bosgame M5
Tiene demasiada VRAM para este modelo, pero Qwen no lanzó una versión 122B de Qwen3.6 que fuera la que mejor se ajustaría a mi hardware. A cambio, el costo de electricidad es casi despreciable. Como originalmente es un chip para laptop, casi no consume en reposo, y aun procesando prompts apenas pasa un poco de 120W
Qwen3.6 es sorprendentemente efectivo, así que solo uso Claude de vez en cuando, como para alrededor del 10% de mis necesidades totales. Incluso con el plan más barato puedo mantenerme por debajo del límite. La velocidad es de unos 800tps en procesamiento de prompts y 50tps en generación de tokens, sin usar decodificación especulativa
Kostic: Para uso personal conecto VSCode con llama.cpp para correr Qwen 3.6 27B o Gemma 4 31B, y es suficiente como para cancelar suscripciones en la nube
Qwen va bastante bien para programar, con contexto q4@176k en la primera GPU y unos 70~50tok/s con MTP. Gemma usa ambas GPU y maneja análisis de sentimiento de documentos, resúmenes, corrección y traducción a 25tok/s con contexto q8@64k
Para flujos de trabajo por lotes es un poco lento, pero sirve. Si llama.cpp soporta MTP en modo tensor split, quizá se pueda aumentar más
En el trabajo sigo usando LLM frontier porque yo no pago el costo, y obviamente son mejores. Ojalá en un año salga un modelo de 30B al nivel de Sonnet 4.6/Opus 4.5
El procesamiento de prompts empieza en 800t/s y baja hasta 400t/s. Como normalmente mis prompts iniciales son de 16k~24k tokens, tardan entre 60 y 90 segundos en procesarse; no es ideal, pero es aceptable
jodoherty: En una RTX Pro 6000 Blackwell corre Gemma 4 31B con Pi y lo usa para toda su programación con agentes
Le parece útil, y este proyecto paralelo se parece a la forma en que en su trabajo acotan y ejecutan proyectos: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
Hay que aplicar arquitectura cuidadosa y bastante TDD. La idea es resolver las partes difíciles al principio y envolverlas en una interfaz simple y fácil de usar para eliminar el riesgo técnico
En algunos proyectos va 2 o 3 veces más rápido que escribirlo directamente, y en proyectos aburridos o muy amplios le permite reunir ideas y probarlas rápido, ahorrando entre 5 y 10 veces el tiempo
Su configuración alterna entre vLLM con
nvidia/Gemma-4-31B-IT-NVFP4y llama.cpp conunsloth/gemma-4-31B-it-qat-GGUF, que tiene MTP. Limita la energía de la GPU a 400W. Su configuración actual de llama.cpp da entre 60 y 150t/s según la tasa de aceptación del draft MTP, y el prefill da entre 1500 y 4000t/s según la longitud y profundidad del contextojborak: Corre Qwen3.6 27B MTP Q6_K en llama.cpp con cuatro RTX 5070 y un AMD Threadripper 1950X de primera generación, y le funciona bien como driver diario de Pi
La velocidad es de unos 50~60tok/s. También conecta otras apps como OpenWeb UI, y últimamente configuró el gateway para LLM Bifrost como punto de entrada predeterminado para acceder a modelos
También probó Qwen3.6 35B A3B, pero el 27B le encaja mejor para programación. Como es un modelo denso es más lento, pero la calidad parece mucho mejor. El 35B A3B da 130~140tok/s sin MTP, así que es absurdamente rápido
En realidad no hacen falta cuatro 5070 para correr Qwen3.6 27B; con tres, o quizá dos, podría bastar. Pero si usas MTP para acelerar el 27B, el modelo draft necesita su propio contexto y consume más memoria
También hay que recordar que el prompt de sistema de las herramientas se carga en el modelo en cada conversación. Cuando inicia Pi responde muy rápido, pero si interactúa con Hermes CLI cada prompt mete mucho contexto con skills, tools, etc., y eso se queda hasta el final de la conversación, así que se vuelve mucho más lento
La privacidad está bien, pero también le gusta no tener límites ni preocuparse por el uso. Si el futuro es la “ingeniería de bucles”, con modelos en la nube vas a quemar tokens y dinero. Su sistema consume 200W en reposo y 350~450W con alta carga de inferencia, y además la decodificación no es tan eficiente, así que las GPU quedan ociosas más seguido de lo esperado. Algún avance como diffusion podría acelerar la decodificación y mejorar el aprovechamiento de las GPU ociosas
Mi primera impresión es que está muy inclinada al rendimiento de cómputo y se queda corta de VRAM, así que parece buena para gamers pero no tan buena para correr LLM. Yo también uso una 5070 en mi desktop
cuttysnark: Con modelos locales ha tenido cierto éxito encadenando varios agentes en un flujo de trabajo
Cada agente usa prompts distintos y un modelo distinto de ollama según su rol. Un agente de project manager o de esquema (
qwen3:14b) no usa el mismo modelo que un agente de programación (qwen2.5-coder:7b)Entre cada etapa hay un orquestador y tareas de Playwright, y trata de exponer los errores al agente que generó el bloque de código anterior. Solo los bloques sin errores pasan a la siguiente etapa
La mayor mejora fue agregar una definición de servicio backend-for-agents para que el agente de esquema solo produzca un manifest basado en tareas y lo pase al siguiente agente. En resumen, define el flujo de trabajo para dividirlo en tareas muy específicas para los agentes y luego pasarlo a la siguiente etapa. Así no se pierde la base, y también aparecen puntos donde una persona puede intervenir en flujos que van 25% o 90% bien
Algo como “usando solo esta GPU de consumo, y con el modelo y flujo de trabajo que quieras, qué tan bien resuelves el benchmark xyz”. Estaría bueno algo tipo “The Local AI challenge”, donde a los participantes se les da máximo 1 hora y se puntúa la proporción respondida, la precisión y el tiempo total
Por ejemplo, darle la misma tarea de programación a dos modelos o a distintas semillas del mismo modelo, y que un revisor elija el mejor resultado. Existe una visión según la cual el cerebro humano también funciona como miles de mini columnas corticales que ven cada situación de forma ligeramente distinta y luego votan por mayoría
HappySweeney: Con Optane y mucha RAM, probé durante la noche un modelo cercano al modelo completo para escribir funciones, a unos 0.7t/s
La prueba actual consiste en convertir una función escalar en una función de transposición de matriz de bits usando AVX512. Los modelos en la nube lo resuelven fácilmente, pero Kimi 2.6 y GLM 5.1 fallan de forma desastrosa
etoxin: Aún no he podido reemplazarlos. En proyectos del trabajo uso openspec, y para imitar hardware local sin gastar una fortuna pago por versiones alojadas de los modelos locales más populares y recientes
La mayoría de los modelos locales pequeños no manejan bien las llamadas a herramientas, pero los modelos más grandes ya suelen hacerlo bien. Algo que todavía no se ha considerado del lado local es que los ingenieros productivos normalmente ejecutan varios chats de CLI al mismo tiempo junto con git worktree. Yo normalmente tengo 3 worktree y chats de CLI abiertos
blurbleblurble: Ahora mismo, más que el modelo en sí, el límite está en la usabilidad de los arneses alternativos, a los que curiosamente les faltan funciones como manejo de colas, interrupción, subagentes y objetivos
Es posible hacer funcionar OpenCode, pero la configuración es muy manual y tosca. Hice un script que convierte automáticamente la configuración de
llama-servera configuración de OpenCode, y ayuda, pero no es lo idealEn serio he considerado crear otro arnés de programación en mi tiempo libre. Tengo algunas ideas para hacerlo mejor
He usado los agentes CLI de Claude, Cursor y Pi, arneses personalizados hechos por mí, e incluso gastown, y Pi simplemente cumple. Hace lo que necesito, las herramientas base están bien, se integra bien con otras herramientas y me hace preocuparme menos
Si puedes correr modelos de alrededor de 30B a una velocidad decente, Pi va a sorprender bastante a mucha gente. Si le agregas extensiones como https://pi.dev/packages/pi-mcp-adapter?name=mcp y https://pi.dev/packages/pi-web-access?name=search, también obtienes acceso MCP a herramientas web, búsqueda de perplexity, control de Chrome con https://browsermcp.io/, y para Firefox https://github.com/mozilla/firefox-devtools-mcp
No es tan bueno como los modelos de primer nivel subsidiados, pero es gratis y sigue siendo capaz. Personalmente también me he divertido mucho con https://pi.dev/docs/latest/sdk; otros proveedores cobran miles de dólares al mes por este tipo de acceso por API
_bobm: Cuando hablamos de modelos Claude/GPT, hay que pensar qué es realmente ese “modelo”
Basta con recordar cómo GPT puede ir enviando la parte de razonamiento paso a paso, y cómo puede adjuntar resúmenes en encabezados Markdown del propio bloque de razonamiento. Si observas el endpoint de API y el comportamiento de salida, estos supuestos modelos SOTA no son lo que parecen, y a nivel de infraestructura no son comparables en absoluto con modelos locales
Operar a esta escala implica una enorme orquestación, y sus limitaciones llevan a innovaciones que no se explican abiertamente. No creo que sea imposible alcanzarlos, pero servir un modelo local con llama o vLLM apenas está al nivel del alfabeto A, B, C
Lo que realmente hace falta es replicar la orquestación insinuada arriba. Los “modelos” SOTA no son un único modelo, sino una orquestación profunda de varios modelos trabajando juntos. Por eso un solo modelo no podrá alcanzarlos hasta reproducir esa orquestación en entrenamiento y arquitectura
Creo que el modelo en sí dentro de esta configuración orquestada, tal como se ofrece al consumidor común, no sería muchísimo mejor que Qwen 3.6. Si cambias de perspectiva, empiezas a ver la escala de la “magia”
También me gustaría ver un ejemplo concreto de eso que dices sobre GPT enviando la parte de razonamiento junto con resúmenes en encabezados Markdown
cheekygeeky: El desarrollador de software de nuestro equipo es la persona más inteligente que he conocido, y usa OpenCode y Tmux con modelos de código abierto
Para programar prefiere DeepSeek por encima de todo y dice que “está bastante bien”. Lo corre en un i9, 128GB de RAM y dos 3090. https://www.msn.com/en-us/news/technology/china-s-open-deeps...
pianopatrick: Si hubiera benchmarks y competencias para este tipo de flujo de trabajo, sería posible ver qué funciona bien
Algo como: “usando solo esta GPU de consumo, con el modelo y flujo de trabajo que quieras, qué tan bien resuelves el benchmark xyz”. Me gustaría ver una competencia tipo “The Local AI challenge”, donde los participantes tengan como máximo 1 hora y se puntúe por tasa de respuesta, precisión y tiempo de finalización
bravetraveler: Lo uso casi “orgánicamente”, y cualquier uso reducido de LLM también es local
En un sistema Strix de 128GB, variantes menos densas de Qwen o Gemma dan entre 50~80tok/s de salida. No pienso suscribirme a Anthropic/OpenAI ni nada parecido, y aunque este fuera el último modelo local, tampoco lo necesitaría. El uso de herramientas dentro del modelo cubre la preocupación por la actualidad
GodelNumbering: Como alguien que conversa con LLM todo el día, creo que la combinación de modelo frontier de código abierto + buen arnés ya es suficiente
Para una migración completa a despliegue local todavía hacen falta una o dos generaciones más de hardware. Aun así, como las compañías de hardware están priorizando con fuerza el segmento de centros de datos, puede que ese momento no llegue tan rápido
milchek: Lo intentó en una MacBook Pro de 36 GB, pero más allá de tareas muy básicas no tuvo mucho éxito.
Incluso usando modelos pequeños, el contexto se agotaba rápido y además eran lentos. Para lograr un rendimiento más o menos decente, parece que se necesitan 128 GB de memoria, y el costo del hardware sube mucho.
Al final, la cuestión es si pagar una suscripción a modelos frontier o enterrar ese dinero en equipo. Claro, si la privacidad es importante, casi no hay otra opción más que gastar en hardware de gama alta.
acc_297: Se pregunta si ayudaría aplicar RLHF de forma cotidiana a un modelo de tamaño medio en cada prompt para ajustarlo finamente a sus hábitos personales de uso.
No sabe si afinar el modelo manualmente lo arruinaría o lo mejoraría. Le gustaría que, dando feedback de forma constante, se pudieran reducir ciertos tics de los modelos generalistas, como la adulación excesiva, la verbosidad o la molesta costumbre de explicar con analogías, pero no sabe si el feedback de prompts de una sola persona bastaría.
También ha oído que agentes internos de empresa afinados con documentación interna muestran comportamientos raros y no necesariamente resultan más útiles que los modelos estándar. Le gustaría poder editar todas las respuestas del agente y afinarlo con la diferencia entre la versión original y la editada.
Personalmente, quitaría muchos adjetivos y lo depuraría hacia respuestas más directas, pero viendo el trabajo de investigadores de alineación como Owain Evans, le preocupa que ese tipo de ajuste pueda empujarlo hacia tendencias difíciles de predecir.
Cree que el trabajo de Owain Evans era SFT. En Twitter alguien decía que RL es menos vulnerable al fenómeno que él mostró, así que le gustaría experimentarlo por su cuenta.
heisenbit: Hace falta trabajo de configuración, pero en el proceso está aprendiendo mucho.
En una M4 MBP de 48 GB usa principalmente
qwen/qwen3.6-35b-a3b mlx, y apenas queda margen para un Docker dev-container y tareas básicas. Lo ejecuta con LM Studio y lo usa desde VSCode.Cambiar el system prompt para mejorar la integración de herramientas marcó una gran diferencia. Antes, en vez de aplicar cambios, muchas veces regeneraba el código y terminaba estropeándolo más de lo que ayudaba.
Para evitar ruido y calor, casi siempre usa el modo de bajo consumo incluso cuando está conectado a la corriente. Con el rendimiento máximo la velocidad es aproximadamente el doble, pero consume más del doble de energía.
Lo máximo que pudo hacer fue una reestructuración simple de una página, y separar un store de Pinia fracasó. GPT-5.4 resolvió esa tarea sin problemas. Cree que, ajustando más la guía de uso de herramientas y las herramientas de soporte alrededor, el rendimiento aún podría mejorar.
nfrankel: Lo intentó y en teoría funciona: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
Los resultados dependen del modelo y, al final, el límite es la computadora. Su equipo, por desgracia, no pudo con ello.
K0balt: Ha obtenido resultados bastante buenos con qwen 3.6 27b dense.
Dependiendo de la tarea, está a la altura de Claude Haiku 4.5 y quizá a veces llegue a nivel Sonnet.
jderekw: Usa AMD Lemonade como equipo de uso diario.
Empezó con Ollama, pasó a LMStudio, y ahora se ha estandarizado en AMD Lemonade porque ayuda a monitorear cRAM, CPU, GPU y gRAM. Gracias a la capacidad multmodelo de Lemonade, puede ejecutar fácilmente stacks de LLM, voz a texto, NPU y generación de imágenes.
La plataforma funciona también con chipsets de Nvidia, Apple, Intel y AMD.
redox99: Modelos que se pueden correr en casa, como Qwen 35B, no están para nada cerca de Opus ni GPT 5.5.
Los modelos abiertos que sí se acercan andan por el orden de 1T de parámetros, así que hay que olvidarse de correrlos en casa. Es como manejar un cacharro viejo: habrá quien te convenza de que está bien para ir de A a B, pero no está bien.
Salvo que necesites privacidad absoluta, lo hagas por diversión o tengas un caso especial como estar en un avión, no hay una razón lógica. Si ni siquiera puedes pagar los 20 dólares de Codex, que está fuertemente subsidiado, usar una API de modelos chinos supera por mucho a estos modelos pequeños.
sj_tech: En una Mac Mini de 128 GB usa Qwen 3.6 35B A3B para agentic coding con GitHub Copilot Extension for VSCode.
Está bien para el tamaño del modelo, pero cuando el problema se vuelve demasiado grande ha visto que cae en bucles. Sirve si lo usas para ahorrar tiempo en cosas que ya sabes hacer.
julianlam: En una Framework 13 con 32 GB de memoria corre Qwen 3.6 35B-A3B con llama.cpp y obtiene 15 tok/s.
Produce código y texto más rápido de lo que él puede leer.
moezd: Todavía no. Si no tienes puro juego de Apple o una GPU decente, aunque tengas mucha RAM e hilos, lo máximo suele ser 30~50 tok/s, y eso con thinking desactivado.
Sin ese tipo de optimización, el modelo se consume MCP, skills y descripciones del agente a lo loco, y te quedas viendo secarse la pintura antes de ver el primer token de salida.
Servir modelos locales obliga a ahorrar cada token de la ventana de contexto, justo lo contrario de la dirección en la que Claude/GPT/Copilot están empujando a la industria.
mitchell_h: Lo intentó, pero la ventana de contexto no era lo bastante grande.
Claro, hace falta hardware capaz de mover una ventana de contexto así, y en su DGX Spark el modelo q4_k_xl con toda la KV cache en f16 requiere unos 100 GB de memoria.
drnick1: Me pregunto cuál es el mejor modelo de código actual que se pueda ejecutar en una GPU de consumo de gama alta
Suponiendo que tienes una RTX 3090/4090, también me pregunto qué stack recomendarían. Quisiera saber si sería una combinación como Llama.cpp + OpenCode
bijowo1676: Me pareció interesante una configuración donde usas modelos frontier caros para escribir y actualizar documentos Markdown de especificaciones de la app, requisitos del producto y arquitectura, y luego haces que modelos baratos o locales implementen esas especificaciones
Markdown comprime mejor la información que cientos de archivos fuente y cabe bien en la ventana de contexto, pero para pulir las partes toscas hacen falta una segunda y tercera pasada. Me pregunto si alguien lo ha hecho de esta manera
grmnygrmny2: Tenía reparos éticos con usar productos de OpenAI o Anthropic, así que también era reacio a adoptar LLMs en general
Los modelos locales resuelven la mayor parte de ese rechazo moral, así que llevo como un mes usándolos para el trabajo y proyectos personales. El hardware que tengo son Macs con 32GB y una PC gamer con una 3080 de 10GB, así que mi límite es algo como Qwen3.6-35B-A3B en varias cuantizaciones, pero es suficiente
Son unos 200~400 PP y 20~30 TG, y me tomó algo de tiempo aprender a usarlos bien. Hay tareas en las que hay que supervisarlos o marcarles la dirección, pero son bastante útiles
Nunca he usado CC, así que no puedo comparar, pero sirven como buen asistente o programador en pareja para cosas desde C++ embebido hasta Vue. Estaría bien poder correr 27B, y a veces este modelo parece estar a punto de entender algo pero no lo logra, aunque es raro
Ahorran mucho tiempo en muchas tareas, y eran buenos para meterse a depurar y corregir bugs incluso con instrucciones bastante ambiguas. Para el harness uso Pi