Hallan 7 modelos «muertos» entre los 305 de la biblioteca de Ollama: no saben escribir código

Cuando un desarrollador ejecuta un modelo de lenguaje en su propio ordenador, casi siempre descarga un archivo comprimido de un catálogo público. Esa compresión se llama cuantización: los pesos del modelo no se almacenan en 16 bits, sino en 2–8, para que el archivo quepa en memoria. Estos archivos los publican los operadores de los catálogos o voluntarios, y ni las páginas del catálogo ni los metadatos indican que alguien haya comprobado el archivo en la práctica.

Los investigadores decidieron verificarlo a escala de un catálogo entero: tomaron las 305 compilaciones elegibles (etiquetas) de la biblioteca oficial de Ollama y ejecutaron tareas de programación en cada una. Siete compilaciones, es decir, el 2,3%, resultaron inservibles: resolvieron como máximo 6 de las 164 tareas.

Cómo se buscaron los archivos muertos

La muestra incluyó 15 familias de modelos: ocho especializadas en código y siete de uso general. En total, 35 variantes de modelos; 291 compilaciones están cuantizadas y 14 se almacenan en precisión estándar de 16 bits. A ellas se sumaron 22 archivos populares de la comunidad en Hugging Face, procedentes de 12 repositorios.

La comprobación tuvo dos fases:

• Filtro rápido. 15 tareas de HumanEval+, seleccionadas entre las 39 que resolvieron las 23 configuraciones sanas de Qwen2.5-Coder. Una compilación que resolvía menos de 9 de las 15 pasaba a ser sospechosa. La generación tarda unos 30 segundos por archivo. • Ejecución completa. Los sospechosos recibieron las 164 tareas de HumanEval+. Se consideró inservible una compilación que resolvía menos del 10% y, además, quedaba muy por debajo de su propia versión en alta precisión.

Todas las ejecuciones se hicieron en una GPU RTX 4090 con decodificación voraz y semilla fija (seed 42), de modo que una segunda ejecución en otra máquina produjo las mismas 225 respuestas, byte a byte. De paso apareció un error en el propio recuento: por los tiempos de espera agotados, la tarea HumanEval/15 se contabilizaba como fallida casi en todas partes. Tras revisar de nuevo las compilaciones sospechosas, quedaron 39 en lugar de 50, pero los siete principales sospechosos no cambiaron.

Las siete son versiones muy comprimidas de modelos de hasta 4000 millones de parámetros. Cinco pertenecen a Qwen y phi3.5. Las otras dos son etiquetas de llama3.2 de 1000 millones de parámetros. No se reconstruyeron por la licencia de los pesos originales, así que su causa sigue sin aclararse. Dos archivos de la comunidad tampoco funcionaron; se examinaron aparte con distintas plantillas de chat.

Los archivos están intactos; el problema es la receta

Los investigadores reconstruyeron cinco de los sospechosos a partir de los pesos originales, con la receta indicada en los metadatos, es decir, sin calibración. Después compararon los tensores: tipo, forma y bytes. El resultado fue inesperado: los cinco archivos del catálogo coincidieron por completo con la reconstrucción. No hay ninguna corrupción durante la conversión. Son cuantizaciones exactas de los pesos originales; simplemente, no funcionan.

A continuación probaron la calibración. Se trata de la matriz de importancia (imatrix): estadísticas de activaciones recogidas sobre una muestra de texto. Indica al cuantizador dónde el error de redondeo resulta más peligroso, y así este ajusta con más precisión las escalas de los bloques. La matriz se construyó o bien con 100 fragmentos de WikiText-2 de 512 tokens, o bien con 1,5 MB de código Python del repositorio llama.cpp.

El resultado fue este:

• En Qwen2.5-Coder-3B, en tres de los cuatro niveles de compresión rotos, el resultado subió de cero a entre 76 y 113 tareas de 164, es decir, un 46–69%. La versión de cuatro bits del mismo modelo resuelve alrededor del 80%. • La misma receta sin calibración aplicada a Qwen2.5-Coder-1.5B dio un modelo funcional. Por tanto, la avería no se puede predecir a partir de la receta por sí sola. • Entre las 66 compilaciones que pasaron el filtro y se revisaron por muestreo, no hay ninguna inservible.

La primera versión del estudio elegía la referencia según el autor de la conversión y no según la receta, y calificaba los archivos de defectuosos. La reconstrucción con la misma receta corrigió esa conclusión.

Qué deben hacer los operadores de catálogos y los usuarios

Los problemas con archivos en los catálogos ya se habían dado antes. En 2024, los mantenedores de llama.cpp descubrieron que una parte de las conversiones usaba un preprocesamiento de texto incorrecto antes de la tokenización, y los usuarios se quejaron de fallos. Dos años después, 26 de las 305 etiquetas oficiales siguen sin indicar el tipo de tokenizador.

Los autores recomiendan lo siguiente:

• Antes de publicar, pasar las compilaciones de pocos bits por una prueba corta de ejecución de código. Para ello han publicado la herramienta quantcheck y los datos de la auditoría. • Si una compilación suspende la prueba, hay que calibrarla o no publicarla. • Los usuarios no deberían dar por verificada una etiqueta del catálogo, sobre todo con 2–3 bits por peso y en modelos de hasta 4000 millones de parámetros.

También hay limitaciones. La comprobación cubre solo modelos de código, una única biblioteca oficial y una pequeña muestra de Hugging Face. Las dos etiquetas inservibles de llama3.2-1B quedaron sin explicación. El filtro se apoya en tareas seleccionadas a partir de compilaciones sanas de Qwen, y entre los modelos deepseek-coder-1.3B hay seis etiquetas que obtienen entre 1 y 6 de 15 incluso en alta precisión, aunque esa es otra historia. Pero la conclusión principal es clara: coincidir exactamente con la receta no garantiza que el archivo funcione, y una prueba barata de 30 segundos detectó lo que llevaba meses en el catálogo.