Cuantizar un modelo con mis propias manos

Llevo tiempo descargando modelos ya comprimidos, con sus etiquetas Q4, Q5 u Q8, y fiándome de que quien los preparó sabía lo que hacía. Esta vez quise hacerlo yo: coger un modelo tal como lo publica su creador, comprimirlo con llama.cpp a varios tamaños y comprobar con mis propias tareas cuánto se pierde en cada escalón. Spoiler: se pierde menos de lo que temía en unas cosas y mucho más de lo que esperaba en otras.

«Con la cuantización, cualquier modelo cabe en tu gráfica.» Lo he leído en foros, lo he oído en vídeos y, dicho así, suena a magia: el modelo que no te cabía, aprietas un botón y te cabe.

Tiene su parte de verdad. La cuantización es comprimir el modelo guardando sus números con menos precisión, y un modelo comprimido ocupa mucho menos. Lo que la frase se calla es el precio. Comprimir es redondear, y redondear demasiado estropea cosas. La pregunta interesante no es si cabe, sino qué deja de hacer bien cuando cabe.

Si las etiquetas Q4 o Q8 te suenan a chino, las explico en Más de cincuenta modelos probados en casa. Aquí voy a la práctica.

Pregunta razonable: si en internet ya hay versiones comprimidas de casi todo, ¿para qué cuantizar a mano?

Tenía tres motivos. El primero, entenderlo: llevaba meses eligiendo entre Q4 y Q5 por intuición. El segundo, que no siempre hay versión comprimida de lo que quieres, sobre todo si es un modelo poco conocido o uno que has afinado tú. Y el tercero, que las versiones que se descargan las prepara gente distinta, con criterios distintos, y a veces no sabes qué hay dentro.

La herramienta fue llama.cpp, el motor que hay debajo de varios programas cómodos y que trae sus propias utilidades para convertir y comprimir modelos. Lo hice en el servidor gráfico, el de la RTX 4070 de 12 GB y 64 GB de RAM, durante la primera quincena de octubre de 2026.

Elegí un Qwen 3 de 8B, por una razón práctica: sin comprimir, en 16 bits, ocupa unos 16 GB y no cabe en mi gráfica, pero casi todas sus versiones comprimidas sí caben. Así podía comparar la velocidad en igualdad de condiciones.

El proceso, sin entrar en comandos, tiene tres pasos:

1. Descargar el modelo original tal como lo publica su creador, en su formato de origen. Fueron unos 16 GB.
2. Convertirlo a GGUF, el formato que usa llama.cpp, sin comprimir todavía. llama.cpp trae un script para eso. La conversión tardó unos diez minutos.
3. Comprimirlo con la herramienta de cuantización de llama.cpp, eligiendo el nivel. Cada versión tardó entre cinco y quince minutos, y el procesador trabajaba a tope mientras tanto.

Dos cosas que nadie me avisó y que conviene saber antes de empezar. La primera, el disco: entre el original, la conversión y las versiones comprimidas, llegué a tener unos 60 GB ocupados por un solo modelo de 8B. La segunda, la memoria: comprimir no necesita gráfica, pero sí RAM de sobra para el modelo sin comprimir. Con los 64 GB del servidor fue holgado; en el portátil, con 32, lo habría hecho sufrir. Y una de sentido común: el modelo original lo descargué de la página oficial de su creador, no de una copia subida por un desconocido.

Saqué seis versiones: Q8_0, Q6_K, Q5_K_M, Q4_K_M, Q3_K_M y Q2_K. De más precisión a menos, de más grande a más pequeño.

Todas medidas con llama.cpp, el mismo contexto de 8.192 tokens y la misma pregunta. El token es el trozo de palabra con el que el modelo escribe. Fíjate en una cosa: entre Q8 y Q4 la velocidad sube bastante; de Q4 para abajo apenas se gana nada. Eso ya me dio la primera pista de dónde estaba el punto dulce.

Para medir la calidad usé mi examen de siempre, el que paso a cada modelo nuevo: resumir en español un documento técnico de unas diez páginas, clasificar treinta correos reales en cinco categorías, extraer los diez campos de una factura en un formato ordenado y escribir una función sencilla en Python. Con temperatura baja, las mismas instrucciones copiadas de un fichero y las mismas muestras para todas las versiones.

Yo esperaba que la calidad fuera bajando poco a poco y por igual en todo. No fue así.

La clasificación de correos aguantó muchísimo: Q8 acertó 27 de 30, Q4_K_M 27 de 30 y hasta Q3_K_M 26 de 30. Solo Q2_K bajó a 22. Para decidir si un correo es una factura, una queja o una consulta, el modelo comprimido casi no se entera de que lo han comprimido.

El resumen también aguantó razonablemente hasta Q4. En Q3 empezó a repetir alguna idea y a dejarse un apartado entero; en Q2 mezclaba cosas de dos secciones distintas con toda la seguridad del mundo.

La sorpresa llegó con la factura. En Q8, Q6 y Q5 sacó bien los diez campos. En Q4_K_M, nueve: cambió una cifra del importe con IVA. En Q3_K_M, siete, y dos de los fallos eran números: un dígito del número de factura y la fecha con el día y el mes cambiados. En Q2_K, además, rompió el formato que le pedía y devolvió una lista a medias. Justo lo que menos perdona un error: números que parecen correctos y no lo son.

Y la función en Python, algo parecido: funcionaba a la primera hasta Q5; en Q4 tenía un error pequeño en un caso límite; en Q3 y Q2 no arrancaba.

La lección me descolocó un poco: la compresión no estropea el modelo «en general», estropea antes lo que exige precisión. Clasificar es tolerante; copiar una cifra exacta, no.

Buscando por qué Q3 y Q2 salían tan mal, di con algo que no conocía: llama.cpp permite comprimir usando una «matriz de importancia». Dicho en llano, antes de comprimir le pasas al modelo un texto de muestra, la herramienta mira qué partes del modelo se usan más con ese tipo de texto y las redondea con más cuidado.

Repetí Q3_K_M y Q4_K_M con una matriz de importancia calculada sobre unos textos en español míos: correos, actas y documentación técnica sin datos de clientes. El cálculo tardó casi una hora. Mejoró, pero no hizo milagros: Q4_K_M pasó a sacar bien los diez campos de la factura y Q3_K_M subió de siete a ocho. En Q2 no lo probé; a esas alturas ya había decidido que no lo iba a usar para nada serio.

Esto lo marco como experimental: es una sola prueba, con un solo modelo y pocas muestras. Pero me explicó por qué dos versiones «Q4» descargadas de sitios distintos no siempre rinden igual: puede que una se hiciera con matriz de importancia y otra no, o con textos de muestra muy diferentes.

Después de todo esto, mi criterio ha quedado así:

• Clasificar, etiquetar, ordenar: Q4_K_M sin pensarlo mucho, y Q3 si la memoria aprieta. La tarea aguanta.
• Resumir y redactar: Q4_K_M o Q5_K_M. Por debajo, se nota.
• Extraer datos exactos, números, fechas, código: Q5_K_M o Q6_K, y comprobando siempre una muestra a mano. Aquí el ahorro de memoria sale caro.
• Q2: para ver si un modelo arranca en una máquina justa. No para trabajar.

Y una regla que ya aplicaba y ahora aplico con más convicción: entre un modelo grande muy comprimido y uno más pequeño poco comprimido, pruebo los dos con mi tarea. En la extracción de la factura, este mismo 8B en Q6 acertó más que el Qwen 3 de 14B que uso a diario, comprimido en Q3 para la ocasión, ocupando parecido.

¿Cuantizaría otra vez a mano? Para modelos que ya vienen comprimidos por gente de fiar, no me compensa: descargo el Q4_K_M o el Q5_K_M y listo. Lo haré cuando no haya versión comprimida, o cuando quiera una matriz de importancia hecha con textos parecidos a los míos.

¿Hace la cuantización que cualquier modelo quepa en tu gráfica? Casi: lo que hace es cambiar memoria por calidad, y ese cambio no es igual para todas las tareas. De Q8 a Q4 ahorré casi la mitad de la memoria y en mis tareas perdí poco, salvo en los números. De Q4 para abajo ahorré 1,7 GB más y perdí justo lo que más me importa no perder.

Lo que me costó: unas once horas repartidas en tres tardes, entre descargas, conversiones, pruebas y apuntar resultados, y unos 60 GB de disco que borré al terminar. Ni un euro, salvo la luz. Si quieres ver en qué programa uso cada modelo después, está en Ollama, LM Studio, llama.cpp y Unsloth, cuál uso para cada cosa, y si lo que buscas es saber qué se puede hacer sin gráfica, empieza por Una inteligencia artificial en el portátil en una tarde.