Anubhav lo plantea con claridad en su artículo: el mejor modelo local para programar no es el que tiene la puntuación más alta en un benchmark, sino el que tu máquina puede ejecutar realmente sin congelarse. Defiende elegir un modelo local de código por hardware, latencia y privacidad, y no por capturas de pantalla de leaderboards: «You cannot pick a model based on a leaderboard. You have to pick a model based on your silicon.» Con esa metodología estoy de acuerdo casi por completo. Pero tengo una pregunta previa, y creo que importa más.
La pregunta no es «qué modelo local gana». Es dónde encaja un modelo local, si es que encaja. Mantengo LM Studio y un MCP local en marcha, uso estos modelos a diario — y aun así los considero inadecuados para producción. En «The Harness Is the Cheap Part» argumenté que una LLM local no debe situarse donde se exige precisión de producción. El trabajo real lo entrego a la nube. Este artículo es una buena ocasión para afilar esa idea hasta convertirla en una sola línea.
Por dónde pasa la frontera
La frontera no es «local frente a nube» como cosmovisión. Pasa por la naturaleza de la tarea. Hay bucles agénticos dominados por el coste de tokens: un script lee un test fallido, propone un arreglo, compila, repite — cincuenta veces al día. Anubhav describe exactamente este escenario y extrae la conclusión correcta: «You buy the hardware once and run infinite tokens.» Esas iteraciones son baratas, de alto volumen y tolerantes al error — un intento fallido aislado no cuesta nada, porque el bucle volverá a intentarlo de todos modos. Aquí es donde un modelo local encaja a la perfección.
Y luego está la salida de la que depende el resultado: el parche final, la decisión de arquitectura, el código que va a revisión y a producción. Aquí el coste de un error no es «un token de más», sino una release rota. Esa salida va a la nube — en mi caso, a Claude. Los bucles baratos y de alto volumen corren en local; la salida crítica en precisión va a la nube. Esa es la frontera, y importa más que cualquier ranking de modelos.
Qué merece conservarse de la metodología
Lo más valioso del texto no es la lista de modelos, sino el método de ingeniería: «elige por tu silicio, no por el leaderboard.» Eso me lo quedaría entero, porque no se pudre con el siguiente lanzamiento.
- Q4_K_M como suelo práctico de calidad. Anubhav advierte sin rodeos: «==The tradeoff is a slight loss in reasoning capability.==» Por debajo de Q4 para código, un modelo «forget basic syntax and hallucinate variables.» Coincide con mi experiencia.
- Un modelo más pequeño en Q8 supera a uno más grande en Q2. «I always recommend running a smaller parameter model at Q8 rather than a bigger model at Q2.» Perseguir el número de parámetros y luego machacarlo con cuantización agresiva es autoengaño.
- La caché KV compite con los pesos por la memoria unificada. El contexto ocupa RAM física junto a los pesos del modelo; eso, y no solo el tamaño de los pesos, es lo que suele topar con el techo.
- El swap a disco mata el rendimiento. Si se acaba la memoria unificada, tu «generation speed will immediately drop from 30 tokens a second to 1 token a second.» Eso no es degradación, es el final.
- Apunta a ~15 tok/s para chat y ~40 tok/s para autocompletado. «Latency will kill your focus faster than a slightly wrong answer will» — una formulación que firmo. Por debajo del umbral: toma un modelo más pequeño o cuantiza más fuerte.
Y los niveles de hardware — tres clases prácticas (~16 GB unificados, 32–64 GB o 24 GB de VRAM, 128 GB y multi-GPU) — son un marco honesto para la conversación «qué puedo ejecutar siquiera», sin ilusiones.
Dónde frenaría
Lo que merece cautela es la concreción de 2026. El artículo nombra modelos y cifras bastante definidos: un modelo estrella de 80B MoE con «==it scores 58.7% on SWE-bench Verified==», una familia de modelos de 27B, un lanzamiento de Google en abril bajo Apache 2.0, una familia de código de Mistral plegada en un único modelo de 128B, un modelo de razonamiento aparte y un especialista estrecho en autocompletado. No puedo confirmar ni esos nombres ni esas cifras. El ecosistema open-weight, como escribe el propio autor, «moves incredibly fast» — algunos de estos modelos podrían haber sido renombrados, y varias cifras de SWE-bench no tengo forma de verificarlas. Por eso trato los nombres y las puntuaciones como ilustración, no como hecho: muestran cómo razonar (por nivel y cuantización), pero la tabla concreta quedará obsoleta para el siguiente lanzamiento. Apóyate en los principios, no en la tabla.
Veredicto
Como marco por niveles de hardware el artículo es útil: conecta con honestidad «qué hay en tu máquina» con «qué puedes ejecutar» y fija los umbrales de latencia correctos. Como leaderboard de modelos no hay que fiarse: los nombres y las cifras de SWE-bench son fugaces y en parte no verificables. Lo único que merece guardarse aquí es esto: elige por tu silicio y tu nicho, no por una captura de pantalla de SWE-bench. Y el nicho de los modelos locales son los bucles agénticos baratos y de alto volumen, donde un error sale barato. La precisión sigue viviendo en la nube.