Mejores LLMs para OpenCode - Pruebas Locales

He probado cómo funciona OpenCode con varios modelos LLM alojados localmente en Ollama, y para comparar, he añadido algunos modelos gratuitos de OpenCode Zen.

OpenCode es una de las herramientas más prometedoras en el ecosistema de herramientas de desarrollo de IA en este momento.

TL;DR - Mejores LLMs para OpenCode

Ganador claro para uso local: Qwen 3.5 27b Q3_XXS en llama.cpp

La cuantificación de 27b en IQ3_XXS entregó un proyecto Go completo y funcional con los 8 tests unitarios pasando, README completo y 34 tokens/segundo en mi configuración de 16 GB de VRAM (CPU+GPU mixtos). Cinco estrellas, sin salvedades. Esta es mi opción predeterminada para sesiones locales de OpenCode.

Qwen 3.5 35b en llama.cpp: rápido para codificar, pero valida todo

El modelo de 35b es excelente para tareas de codificación agentica rápidas, pero mis pruebas de mapas de migración expusieron un problema grave de fiabilidad. En dos ejecuciones con IQ3_S, produjo un 63–73% de discrepancias en los slugs, y en la cuantificación IQ4_XS olvidó incluir los slugs de la página por completo, generando rutas de categoría que mapearían 8 páginas diferentes al mismo URL. La calidad de codificación en la tarea IndexNow fue genuinamente buena, por lo que este modelo vale la pena usar, pero nunca confíes en su salida en tareas estructuradas que siguen reglas sin verificarla. La validación no es opcional.

Sorprendentemente bueno: Bigpicle (de OpenCode Zen)

El más rápido para completar la tarea: 1m 17s. Más importante aún, fue el único modelo que hizo una pausa antes de codificar para buscar realmente la especificación del protocolo IndexNow usando Exa Code Search. Encontró todos los endpoints correctos a la primera. Si tienes acceso a OpenCode Zen, este modelo supera con creces sus expectativas.

Bueno, pero solo con pensamiento profundo: GPT-OSS 20b

En modo predeterminado, GPT-OSS 20b falla: se topa con llamadas WebFetch sin salida y se detiene. Cambia al modo de pensamiento profundo y se convierte en un asistente de codificación genuinamente capaz: análisis de banderas completo, lógica de agrupamiento correcta, tests unitarios que pasan, todo hecho rápido. Ten esto en cuenta antes de descartarlo. GPT-OSS 20b falló en tareas estructuradas incluso en modo alto.

Evita para codificación agentica: GPT-OSS 20b (predeterminado), Qwen 3 14b, devstral-small-2:24b

Estos solían ser mis favoritos por velocidad en tareas de chat y generación. Pero en modo agentico, todos tienen problemas reales. Qwen 3 14b alucina documentación en lugar de admitir que no puede encontrar algo. GPT-OSS 20b (predeterminado) se atasca cuando WebFetch falla. Devstral se confunde con operaciones básicas de archivos. Para OpenCode específicamente, la calidad de seguimiento de instrucciones y llamadas a herramientas importa mucho más que la velocidad bruta.

Sobre esta prueba

Le di a cada modelo ejecutándose en opencode dos tareas/prompt:

1. Crea para mí una herramienta CLI en Go que llame a los endpoints indexnow de Bing y otros motores de búsqueda para notificar sobre cambios en mi sitio web.
2. Preparar un mapa de migración del sitio web.

¿Sabes qué es el protocolo Indexnow, verdad?

Para la segunda tarea, tengo un plan de migrar algunas publicaciones antiguas de este sitio web desde el formato de URL de blog (por ejemplo https://www.glukhov.org/post/2024/10/digital-detox/) hacia clústeres temáticos (como la URL de este artículo: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). Así que le pedí a cada LLM en OpenCode que preparara un mapa de migración para mí, según mi estrategia.

Ejecutaba la mayoría de los LLMs en Ollama alojado localmente, y algunos otros en llama.cpp alojado localmente. Bigpicle y otros modelos de lenguaje muy grandes provenían de OpenCode Zen.

Resultado de cada modelo

qwen3.5:9b

Fallo completo en la primera tarea. El modelo pasó por su proceso de pensamiento, identificando correctamente los servicios relevantes (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex), pero nunca llamó a ninguna herramienta. Produjo un resumen de “Build” sin tocar un solo archivo. Sin ninguna llamada a herramientas.

qwen3.5:9b-q8_0

Un paso adelante respecto a la cuantificación predeterminada: al menos creó un go.mod y un main.go. Pero inmediatamente se atascó, admitió que necesitaba añadir importaciones faltantes, intentó reescribir todo el archivo usando un heredoc de shell y falló. El tiempo de compilación fue de 1m 27s por algo que no funcionaba.

Qwen 3 14b

Alucinación clásica bajo presión. Intentó obtener la documentación de IndexNow tres veces seguidas, cada vez obteniendo un 404 de una URL incorrecta (github.com/Bing/search-indexnow). En lugar de admitir que no podía encontrar nada, fabricó una respuesta con aire de seguridad: endpoint de API incorrecto, método de autenticación incorrecto. Cuando le empujé a buscar de nuevo, produjo una segunda respuesta fabricada apuntando a otra URL que también devolvía 404. La información que reportó era incorrecta. Este es el modo de fallo que más quiero evitar.

GPT-OSS 20b

Al menos el comportamiento fue honesto y metódico. Intentó una larga cadena de llamadas WebFetch — indexnow.org, varios repositorios de GitHub, las propias páginas de Bing — y obtuvo 404s o bloqueos de Cloudflare en casi todo. Documentó cada fallo de forma transparente. Al final, tampoco pudo recopilar información suficiente para construir una herramienta funcional, pero a diferencia de Qwen 3 14b, no inventó nada. Simplemente no pudo avanzar.

GPT-OSS 20b (pensamiento profundo)

Una historia significativamente diferente del modo predeterminado. Con el pensamiento profundo habilitado, el modelo se recuperó de las mismas búsquedas sin salida y logró construir una herramienta completa y funcional, con análisis de banderas adecuado (--file, --host, --key, --engines, --batch, --verbose), GET para URLs individuales y POST por lotes para múltiples, según la especificación de IndexNow.

Cuando pedí documentación y tests unitarios, entregó ambos. Los tests pasaron:

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

Rápido, también: compilación inicial en 22.5s. El pensamiento profundo hace que gpt-oss:20b sea realmente usable.

qwen3-coder:30b

El fallo más interesante. De hecho compiló y ejecutó la herramienta contra endpoints reales, vio errores reales de API de Bing, Google y Yandex, y comenzó a corregirlos:

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

Ese instinto es bueno. El problema: se ejecutaba al 720% de CPU y solo al 7% de GPU, extremadamente ineficiente para un modelo de 22 GB. Tardó 11m 39s y el resultado final aún fue “no exactamente lo esperado”. También creó un README.md, un buen detalle. No es un mal modelo, solo muy lento en mi configuración y no logró dominar completamente el formato del protocolo IndexNow.

qwen3.5:35b (Ollama)

Resultados sólidos pero lentos. Creó un proyecto Go adecuado, escribió tests y todos pasaron:

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

El inconveniente: tiempo de compilación de 19m 11s. Para un modelo de 27 GB ejecutándose con una división CPU/GPU de 45%/55%, eso es demasiado lento para uso interactivo. La calidad está ahí, pero la latencia mata el flujo de trabajo.

Bigpicle (big-pickle)

El destacado para la primera tarea. Antes de escribir una sola línea de código, utilizó Exa Code Search para investigar realmente el protocolo IndexNow:

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

Y encontró los endpoints correctos:

• Global: https://api.indexnow.org/indexnow
• Bing: https://www.bing.com/indexnow
• Yandex: https://webmaster.yandex.com/indexnow
• Yep: https://indexnow.yep.com/indexnow
• Amazon: https://indexnow.amazonbot.amazon/indexnow

Resolvió el problema de importación de cobra de forma limpia (go mod tidy) y la herramienta estuvo lista en 1m 17s. La respuesta de límite de velocidad que recibió de Bing durante las pruebas fue en realidad el comportamiento esperado para una clave de prueba inválida; el modelo identificó correctamente esto como “la herramienta está funcionando”. Impresionante.

devstral-small-2:24b

Se confundió a nivel básico: intentó escribir comandos de shell (go mod init indexnowcli, go mod tidy) directamente en el archivo go.mod, provocando errores de análisis. De alguna manera logró compilar un binario (7.9M), pero la CLI resultante era demasiado simple: solo indexnowcli <url> <key> sin manejo de banderas, sin soporte para múltiples motores, nada. Tardó 2m 59s + 1m 28s en obtener una herramienta que no era realmente útil.

qwen3.5:27b (llama.cpp, cuantificación IQ3_XXS)

Este me impresionó más que todos los ejecutores locales. Ejecutándose como Qwen3.5-27B-UD-IQ3_XXS.gguf en llama.cpp (mayormente CPU), creó una herramienta completa con cobertura de tests total — los 8 tests pasando — y un README adecuado con instrucciones de instalación y explicación del protocolo:

PASS    indexnow    0.003s

Motores soportados: Bing, Yandex, Mojeek, Search.io. Tiempo de compilación: 1m 12s para la herramienta, 1m 27s para tests y documentación. Velocidad: 34 tokens/segundo. Calidad: 5 estrellas. Resultado increíble para un modelo cuantificado ejecutándose en CPU+GPU.

qwen3.5:35b (llama.cpp, cuantificación IQ3_S)

Ejecutándose como Qwen3.5-35B-A3B-UD-IQ3_S.gguf en llama.cpp. Mis notas aquí son breves: “¡excelente!” — lo que dice todo. El modelo más grande al mismo nivel de cuantificación entregó resultados al menos tan buenos como la variante de 27b, si no mejores.

Resultados del mapa de migración

Para la segunda tarea ejecuté un lote separado: 7 modelos, todos con las mismas instrucciones, estructura del sitio y lista de páginas. La restricción era explícita: el slug (el último segmento de la ruta) debe permanecer igual. Por ejemplo, /post/2024/04/reinstall-linux/ debe convertirse en /.../reinstall-linux/, no en otra cosa.

Medí cuántas discrepancias de slug produjo cada modelo: casos donde el slug de destino generado difería del slug de origen.

Modelo	Líneas	Discrepancias de slug	Tasa de error
minimax-m2.5-free	80	4	5.0%
Nemotron 3	78	4	5.1%
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5.0%
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7.4%
Bigpicle	81	9	11.1%
mimo-v2-flash-free	80	42	52.5%
Qwen 3.5 35b IQ3_S -segunda ejecución (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

Una cosa que todos los 7 modelos hicieron de forma idéntica: las URLs antiguas del formato 2022 tenían un prefijo de mes incrustado en el slug (ej., /post/2022/06-git-cheatsheet/ → slug 06-git-cheatsheet). Cada modelo eliminó ese prefijo y usó git-cheatsheet como el nuevo slug. Eso son 4 discrepancias consistentes en los tres mejores modelos: así que su línea base es de 4 errores cada uno, no cero.

La verdadera divergencia comienza por encima de esa línea base. minimax-m2.5-free, Nemotron 3 y Qwen 3.5 27b Q3_XXS solo violaron la regla del slug en esos 4 caminos heredados: nada más. Qwen 3.5 27b Q3_M añadió 2 más (cambió el slug del artículo cognee y puso en minúsculas Base64). Bigpicle añadió 5 más encima de los 4, acortando mayoritariamente los slugs largos.

Los valores atípicos están en una categoría diferente. Qwen 3.5 35b IQ3_S reescribió consistentemente los slugs desde los títulos de las páginas en lugar de preservar el origen (ej., executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). La segunda ejecución fue ligeramente mejor (51 vs 59) pero mostró el mismo comportamiento. También alucinó una ruta de origen: cambió silenciosamente comparing-go-orms-gorm-ent-bun-sqlc a comparing-go-orms-gorm-ent-bun-sql (eliminó la c), por lo que ambos lados de esa línea coincidían entre sí, pero ambos estaban equivocados. mimov2 fue agresivamente similar al acortar: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

La cuantificación IQ4_XS del 35b es una categoría de fallo diferente por completo: 98.8% de discrepancias de slug — pero el problema no son slugs incorrectos, es que el modelo olvidó incluir los slugs por completo. En lugar de /new-section/page-slug/, produjo rutas de categoría como /developer-tools/terminals-shell/ y /rag/architecture/. Ocho páginas de origen terminaron mapeadas a /developer-tools/terminals-shell/ — todas apuntando al mismo URL, lo que sería catastrófico si se usara. /developer-tools/ por sí solo recopiló cinco páginas separadas. La salida es completamente inutilizable.

Para esta tarea, el Qwen 3.5 27b Q3_XXS cuantificado más pequeño coincidió con los mejores rendimientos, mientras que dos cuantificaciones de 35b fallaron estrepitosamente, cada una a su manera.

Conclusión

Me siento satisfecho ejecutando tanto Qwen 3.5 35b como Qwen 3.5 27b localmente en llama.cpp con pesos cuantificados: las restricciones de hardware son reales (16 GB VRAM significan cuantificaciones IQ3/IQ4), pero el flujo de trabajo es sólido.

El 27b Q3_XXS es el conductor diario fiable. Sigue las instrucciones con precisión, produce una salida completa y es lo suficientemente rápido para uso interactivo. En la tarea del mapa de migración coincidió con los mejores modelos en la nube.

El 35b es capaz pero impredecible en tareas estructuradas. Para codificación abierta —escríbeme una herramienta, construye esto— rinde bien. Pero cuando la tarea tiene reglas estrictas (como “el slug debe permanecer igual”), alucina libremente en todas las cuantificaciones que probé: reescribiendo slugs desde títulos, eliminando slugs por completo, e incluso editando silenciosamente las rutas de origen para que su salida incorrecta parezca autoconsistente. Si usas el 35b para cualquier cosa que produzca salida estructurada que planeas usar directamente, incorpora un paso de validación en tu flujo de trabajo. No asumas que la salida es correcta solo porque parece plausible.

Si tienes curiosidad sobre la velocidad a la que rinden estos LLMs, consulta Mejores LLMs para Ollama en GPU de 16GB VRAM.