Elegir un modelo de inteligencia artificial para programar basándose únicamente en su número de parámetros puede llevar a resultados inesperados. Una prueba práctica realizada por el desarrollador Rost Glukhov con más de 20 modelos encontró diferencias enormes al generar código y, sobre todo, al producir información estructurada. En su experimento, una versión cuantizada de Qwen 3.5 27B obtuvo una tasa de error del 5 %, mientras algunas configuraciones de modelos considerablemente mayores superaron el 80 %.
Las claves del test de modelos de IA en 20 segundos
- El experimento enfrentó más de 20 modelos a dos tareas reales relacionadas con programación y migración web.
- Qwen 3.5 27B Q3_XXS obtuvo la menor tasa de error, un 5 %, en la prueba estructurada.
- Gemma 4 26B y Nemotron 3 Super quedaron en el 6,2 %.
- Algunas variantes de Qwen 3.5 de 35B y 122B superaron el 60 % de errores.
- Es una prueba individual, no un benchmark independiente generalizable.
Los resultados proceden de una evaluación publicada por Glukhov en abril de 2026. El autor buscaba responder a una cuestión bastante concreta: qué modelos resultaban realmente útiles dentro de su flujo habitual de desarrollo, en lugar de comparar únicamente sus puntuaciones en benchmarks académicos.
Ese matiz importa. Los porcentajes obtenidos no permiten afirmar que Qwen 3.5 27B sea mejor modelo de programación que todos los demás. Lo que muestran es que, bajo las tareas, configuraciones, cuantizaciones y hardware utilizados por el autor, algunos modelos pequeños o intermedios fueron mucho más fiables que alternativas de mayor tamaño.
Dos pruebas diseñadas para encontrar errores que parecen correctos
El experimento utilizó dos trabajos diferentes.
El primero consistía en crear una herramienta de línea de comandos (CLI) escrita en Go para notificar cambios de una web mediante el protocolo IndexNow. El modelo debía investigar el funcionamiento del protocolo, localizar los endpoints adecuados, generar el proyecto y producir pruebas funcionales.
Aquí no bastaba con escribir código sintácticamente correcto. Un modelo podía producir una aplicación perfectamente compilable y, al mismo tiempo, utilizar endpoints inexistentes o interpretar incorrectamente el protocolo.
La segunda tarea estaba destinada a comprobar algo diferente: la capacidad de seguir instrucciones estrictas al generar información estructurada.
Los modelos debían construir un mapa de migración para un sitio web respetando diferentes reglas sobre URLs y slugs, además de incluir exactamente una vez cada origen esperado.
Es precisamente en este segundo ejercicio donde aparecieron diferencias muy grandes.
Según los resultados publicados, Qwen 3.5 27B con cuantización Q3_XXS registró una tasa de error del 5 %. Gemma 4 26B IQ4_XS y Nemotron 3 Super 120B IQ3_XXS quedaron ambos en el 6,2 %, mientras MiniMax M2.5 Free registró un 6,3 %.
Gemma 4 31B IQ3_XXS alcanzó el 7,4 %, seguido por Nemotron 3 mediante OpenCode Zen con un 9 % y otra configuración de Qwen 3.5 27B con un 9,9 %.
A partir de ahí, los resultados empeoraron rápidamente.
Bigpicle quedó en el 12,3 % y Qwen3.6-plus-free alcanzó el 16,5 %. Mimo-v2-flash-free se disparó hasta el 53,8 %.
Algunas configuraciones de Qwen mostraron diferencias todavía mayores: Qwen 3.5 35B IQ3_S registró un 64,2 %, Qwen 3.5 122B IQ3_S un 79 % y Qwen 3.5 122B IQ3_XXS un 82,8 %.
Nemotron Cascade 2 30B llegó al 96,3 %, mientras Qwen 3.5 35B IQ4_XS alcanzó el 98,8 %. Las variantes de GLM-4.7 Flash probadas por el autor terminaron con un 100 % de error.
Son resultados específicos de esta prueba y no deben trasladarse automáticamente a otras cargas de trabajo.
Un modelo de 27B puede superar a otro de 122B en una tarea concreta
Una de las observaciones más interesantes del experimento aparece al comparar el tamaño del modelo con la precisión obtenida.
El ganador de la prueba estructurada fue Qwen 3.5 27B Q3_XXS. El autor afirma que, en su configuración con 16 GB de VRAM, alcanzó además unos 34 tokens por segundo y consiguió completar el proyecto en Go con sus ocho pruebas unitarias superadas.
Frente a ese 5 % de error, las configuraciones probadas de Qwen 3.5 122B llegaron al 79 % y al 82,8 %.
Esto no demuestra que 27.000 millones de parámetros sean mejores que 122.000 millones.
La cuantización utilizada, el formato del prompt, la arquitectura, el contexto, la configuración de inferencia y el tipo concreto de problema pueden alterar mucho el resultado. Dos variantes de un mismo modelo pueden comportarse de forma muy diferente.
Otros estudios también han encontrado que la relación entre tamaño, arquitectura y rendimiento práctico no es lineal. Una evaluación académica publicada en 2026 sobre Gemma 4, Phi-4 y Qwen mostró precisamente que el equilibrio entre precisión y eficiencia depende tanto de la arquitectura como de la estrategia de prompting y la tarea utilizada.
Gemma 4 26B, uno de los modelos que obtiene un 6,2 % en el experimento de Glukhov, forma parte de una familia que Google lanzó oficialmente en marzo de 2026.
Nemotron 3 Super también es un caso interesante. NVIDIA describe el modelo como una arquitectura híbrida Mamba-Transformer de mezcla de expertos (MoE) con unos 120.000 millones de parámetros totales y aproximadamente 12.000 millones activos por token. NVIDIA publica buenos resultados del modelo en diferentes pruebas de razonamiento, código y utilización de herramientas, lo que refuerza otra conclusión: un benchmark concreto mide una capacidad concreta, no una clasificación universal de modelos.
El problema más peligroso no fue que el código no compilara
El experimento encontró además un tipo de fallo especialmente problemático para los desarrolladores: respuestas aparentemente convincentes que contienen información falsa.
Según Glukhov, Qwen 3 14B intentó localizar la documentación de IndexNow en tres ocasiones y terminó accediendo a URLs incorrectas que devolvían errores 404.
En lugar de detenerse al no encontrar la documentación, el modelo generó endpoints y mecanismos de autenticación incorrectos presentados como si fueran válidos.
Para un programador, este comportamiento puede resultar más costoso que un error evidente.
Un fallo de compilación se detecta inmediatamente. Una API inventada, una regla de negocio ligeramente incorrecta o una migración de URLs aparentemente coherente pueden superar una revisión superficial y llegar mucho más lejos dentro del proceso.
Otro ejemplo apareció con Nemotron Cascade 2 30B.
El modelo debía generar un mapa con aproximadamente 80 filas. Según la prueba, solo produjo cinco y dos de ellas contenían slugs incorrectos. El resultado fue una tasa de error del 96,3 %.
Qwen 3.5 35B IQ4_XS sufrió un problema diferente. Generó rutas de categorías en lugar de conservar correctamente los slugs, lo que habría provocado que ocho páginas diferentes terminaran apuntando a una misma URL.
Visualmente, el resultado podía parecer razonable. Operativamente era incorrecto.
Las pruebas automatizadas son tan importantes como el modelo elegido
La principal enseñanza técnica del experimento tiene menos que ver con cuál ocupa la primera posición y más con cómo integrar los LLM en un proceso de desarrollo.
Glukhov terminó utilizando validaciones automáticas para comprobar los mapas de migración. Entre otras cosas, verificó que el último segmento de las URLs coincidiera, que los destinos no conservaran patrones antiguos y que cada origen esperado apareciera exactamente una vez.
El mismo principio se aplica al código generado.
Si una IA crea una función, las pruebas unitarias y de integración pueden comprobar su comportamiento. Si genera JSON, YAML, SQL, configuraciones o datos estructurados, un esquema y unas reglas deterministas pueden detectar muchos errores antes de aceptar el resultado.
La revisión humana continúa siendo necesaria, pero no tiene por qué ser la única barrera.
El experimento también encontró diferencias al modificar el modo de razonamiento. GPT-OSS 20B, según el autor, fallaba en su configuración predeterminada al utilizar herramientas web, mientras que con un modo de razonamiento más intensivo consiguió generar el programa, implementar el procesamiento por lotes y superar las pruebas.
Eso añade otra variable a la selección de modelos: modelo, cuantización y configuración forman parte del mismo sistema.
Los resultados de NVIDIA con Nemotron 3 Super ofrecen un ejemplo diferente de este problema. Su documentación oficial compara variantes BF16 y NVFP4 y muestra diferencias según el benchmark y la precisión utilizada. NVIDIA también señala que el modelo cuenta con 120B parámetros totales pero activa aproximadamente 12B por token, por lo que incluso comparar modelos únicamente por la cifra que acompaña a su nombre puede ser engañoso.
Para un desarrollador que ejecuta modelos localmente, la cuestión deja entonces de ser simplemente «qué LLM tiene más parámetros». Memoria disponible, velocidad de inferencia, cuantización, seguimiento de instrucciones, uso de herramientas y facilidad para validar automáticamente las respuestas pueden resultar igual o más determinantes.
El test de Glukhov no establece un nuevo ranking universal de modelos de programación. Sí ilustra algo que resulta fácil olvidar cuando aparecen modelos cada vez mayores: el mejor LLM es también el que falla de una forma que el sistema puede detectar antes de que su respuesta llegue a producción.
Preguntas frecuentes
¿Cuál fue el mejor modelo de IA para programar en la prueba?
Qwen 3.5 27B Q3_XXS fue el modelo con menor tasa de error en la tarea estructurada, con un 5 %. El resultado corresponde únicamente al entorno y las pruebas realizadas por el autor y no demuestra que sea el mejor modelo para cualquier tarea de programación.
¿Un modelo de IA más grande programa necesariamente mejor?
No. En este experimento algunas configuraciones de 27B obtuvieron mejores resultados que variantes de 35B y 122B. El rendimiento depende también de la arquitectura, cuantización, configuración y tarea evaluada.
¿Por qué es importante validar automáticamente el código generado por IA?
Porque algunos errores pueden producir resultados aparentemente correctos. Tests, validadores de esquemas y comprobaciones deterministas permiten detectar fallos de cobertura, formato o comportamiento antes de utilizar el resultado.
¿La cuantización puede cambiar el rendimiento de un LLM?
Sí. La cuantización reduce los requisitos de memoria y puede permitir ejecutar modelos mayores en hardware limitado, pero también puede modificar su comportamiento y precisión. Los resultados de una variante cuantizada concreta no deberían atribuirse automáticamente a todas las versiones del mismo modelo.
Fuente: Medium: Rost Glukhov y Blog Glukhov
