Ollama: diferencias entre q4, q8 y fp16

Qué cambia la cuantización de Ollama

La cuantización de Ollama almacena cada peso de un modelo con menos bits que el archivo con el que se entrenó. Una etiqueta que termina en q4_K_M conserva aproximadamente cuatro bits por peso, mientras que fp16 conserva dieciséis. Por eso, la descarga ocupa aproximadamente un tercio y la máquina lee alrededor de un tercio de bytes para generar cada token. Los pesos se redondean a una cuadrícula más gruesa, pero no se descartan. Con cuatro bits, la mayoría de los modelos responden de forma similar a como lo hacen con precisión completa.

Este es todo el intercambio: una huella de memoria mucho menor y más tokens por segundo, a cambio de una pequeña pérdida de precisión. A continuación se explica cómo prever ambos aspectos para un modelo concreto en un equipo concreto, antes de dedicar veinte minutos a descargar un archivo que no cabrá.

Si Ollama todavía no se está ejecutando, empiece por instalar Ollama en un VPS. En esta página se da por hecho que ollama ls ya funciona.

Cómo leer una etiqueta de cuantización de Ollama como q4_K_M

Los modelos locales se distribuyen como archivos GGUF, el formato que usa llama.cpp para almacenar los pesos en disco. Ollama se basa en llama.cpp, por lo que las etiquetas de Ollama conservan sin cambios los nombres de cuantización de llama.cpp.

El número indica el ancho objetivo. q4 significa que la mayoría de los tensores de pesos se empaquetan con cuatro bits cada uno. q8 significa ocho. fp16 no está cuantificado: es el modelo en coma flotante de dieciséis bits, la precisión con la que se publican la mayoría de los modelos.

K indica una cuantización K. Los pesos se agrupan en bloques pequeños y cada bloque almacena su propia escala junto a los valores empaquetados. Un bloque cuyos pesos están cerca de 0.01 obtiene una escala precisa. Un bloque que contiene un valor atípico grande obtiene una escala más amplia. Estas escalas por bloque permiten utilizar un archivo de cuatro bits y también explican por qué un archivo de cuatro bits nunca usa exactamente cuatro bits por peso.

La última letra indica la combinación. S, M y L determinan cuántos tensores se almacenan con un ancho superior al objetivo. En q4_K_M, los tensores que más pierden al redondearse se almacenan con mayor ancho, mientras que la mayoría permanece en cuatro bits. Por eso q4_K_M produce una salida mejor que el q4_0 anterior con un tamaño de archivo prácticamente igual.

Consulte a Ollama para saber qué tiene en disco, en lugar de deducirlo del nombre que escribió:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show muestra architecture, parameters, quantization, context length y embedding length. La línea quantization es la fuente de verdad para un modelo que descargó hace meses y cuya variante ya no recuerda haber elegido.

Los bits por peso determinan el tamaño del archivo

Toda estimación de tamaño parte de un número: cuántos bits por peso utiliza el formato, calculados como promedio de todo el archivo. llama.cpp publica cifras medidas para Llama 3.1 8B en su documentación de cuantización, y se aplican bien a cualquier modelo denso de estructura similar.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

La sorpresa de esa tabla está en la segunda columna. Q4_K_M no utiliza cuatro bits por peso. Mide 4.89 bits, porque las escalas de bloque y los tensores promovidos también ocupan espacio real. Q8_0 mide 8.5 bits en lugar de ocho por el mismo motivo. Use el valor medido y el cálculo quedará a pocos puntos porcentuales del tamaño real del archivo:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Ese es el archivo Q4_K_M de 4.58 GiB, obtenido a partir de dos números. También es, aproximadamente, la memoria que ocupan los pesos una vez cargados. Ollama no descomprime nada al cargar: los pesos cuantizados permanecen en memoria con el mismo formato empaquetado y cada bloque se convierte cuando se utiliza.

Lo que realmente distribuye Ollama para cada tamaño de modelo

La biblioteca publica una etiqueta q4_K_M, una q8_0 y una fp16 para la mayoría de las familias. Algunas familias más recientes rompen este patrón y aparecen en la biblioteca sólo con etiquetas cloud, sin nada que descargar para ningún tamaño. Ese es el límite que se alcanza al intentar ejecutar GLM 5.2 en un VPS. Estos son los tamaños de Qwen3 a fecha de octubre de 2026, obtenidos de la lista de etiquetas de la página del modelo. Todas las cifras siguientes corresponden al espacio en disco antes de cargarse en la RAM. Dos o tres de estos modelos pueden llenar el volumen root de un VPS pequeño. Por eso conviene saber dónde almacena Ollama los modelos que descarga antes de empezar a acumular etiquetas.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

La etiqueta predeterminada es importante en este caso. ollama pull qwen3:8b descarga exactamente los mismos 5.2 GB que ollama pull qwen3:8b-q4_K_M, porque la etiqueta sin sufijo es la compilación q4_K_M. Q4_K_M no es un compromiso que la biblioteca ofrezca de mala gana. Es la opción predeterminada elegida por el proyecto original. Por eso, usarla como referencia es el primer paso razonable para cualquier modelo que todavía no haya probado personalmente. El mismo criterio determina las etiquetas elegidas en ejecutar Qwen 3 en un VPS.

Las proporciones se mantienen en todas las filas. Pasar de q4_K_M a q8_0 cuesta aproximadamente un 70 % más, en lugar de exactamente el doble, porque los tensores de embedding y de salida no escalan igual que el resto. fp16 ocupa aproximadamente tres veces más que q4_K_M. Un modelo 32B en q4_K_M contiene 20 GB de pesos. Esa cifra ya supera lo que puede alojar un equipo con 16 GB si se necesita cualquier ventana de contexto. Para consultar una visión más amplia de qué modelos caben en cada equipo, vea qué modelos puede alojar usted mismo.

Por qué la caché KV es un segundo coste que depende del contexto

Los pesos son el coste fijo. La caché KV (caché de claves y valores) es el coste variable. Cada token de la ventana de contexto conserva sus vectores de clave y valor en cada capa, por lo que la caché crece de forma lineal con la ventana permitida. Se asigna para toda la ventana cuando se carga el modelo, no a medida que se llena la conversación. Por eso una ventana larga consume memoria incluso con un prompt de una sola palabra.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Esos valores proceden de la configuración del propio modelo: 36 capas, 8 cabezas de clave/valor y una dimensión de cabeza de 128. ollama show proporciona la arquitectura y el número de parámetros, y config.json del modelo en Hugging Face proporciona el resto. Multiplique el coste por token por el tamaño de la ventana y la caché deja de ser un error de redondeo.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Con 4096 tokens, la ventana predeterminada que Ollama elige cuando hay menos de 24 GiB de VRAM (incluido un VPS que sólo usa CPU), la caché añade 0.6 GB a los pesos. Si aumenta la ventana a 32k, la caché por sí sola alcanza 4.83 GB. Es casi tanta memoria como los pesos cuantizados, y el mínimo para todo el modelo pasa a ser de 10 GB. Se considera un mínimo porque los búferes de cómputo y el sistema operativo se suman a esa cantidad. Consulte la cifra real en la columna SIZE de ollama ps después de cargar el modelo. En una GPU con entre 24 y 48 GiB de VRAM, la ventana predeterminada es de 32k; a partir de 48 GiB es de 256k. Por tanto, en una tarjeta grande no dé por supuesto el valor de 4k.

La ventana se establece en el servidor, no por petición, cuando ejecuta Ollama como servicio:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

En una instalación con systemd, configúrela en un drop-in:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Reinicie con sudo systemctl restart ollama y compruebe después la columna CONTEXT de ollama ps para confirmar la ventana con la que se cargó realmente el modelo en ejecución. OLLAMA_KV_CACHE_TYPE cuantifica la propia caché: f16 es el valor predeterminado, q8_0 utiliza aproximadamente la mitad de la memoria de f16 y q4_0 aproximadamente una cuarta parte. Es una opción global, por lo que todos los modelos de ese servidor reciben el mismo tratamiento. La cuantificación de la caché sólo tiene efecto cuando Flash Attention está habilitado. Ollama lo habilita automáticamente cuando el backend lo admite, y OLLAMA_FLASH_ATTENTION=1 lo fuerza. En un equipo pequeño con una ventana larga, reducir a la mitad la caché libera más memoria que cualquier otro cambio individual. Configuración de num_ctx y su coste explica la ventana en detalle. La caché también se dimensiona una vez por cada ranura de petición simultánea, no una vez por servidor. Por tanto, si permite que Ollama responda a dos prompts a la vez, duplica la cifra que acaba de calcular. Esa es la base del cálculo para elegir el número de ranuras paralelas y el límite de la cola.

Qué cabe en un VPS de 8, 16 o 32 GB

Hay que contar el presupuesto, la caché KV, el margen para el sistema operativo y cualquier otro proceso en ejecución. En un VPS pequeño, 2 GB de margen ofrecen una holgura cómoda.

8 GB. Un modelo 4B en q4_K_M ocupa 2.6 GB y deja espacio para una ventana larga. Un modelo 8B en q4_K_M cabe con la ventana predeterminada de 4k y muy poco margen. No planifique usar 8B con una ventana de 32k aquí, porque el mínimo de 10 GB ya supera la memoria disponible.

16 GB. 8B en q4_K_M con una ventana de 16k o 32k ofrece un margen cómodo. 14B en q4_K_M ocupa 9.3 GB de pesos y cabe con una ventana moderada. 8B en q8_0 ocupa 8.9 GB, por lo que también cabe. Comparar ambos modelos con sus propios prompts es la forma más útil de dedicar una hora a este tema.

32 GB. 14B en q8_0 (16 GB) y 32B en q4_K_M (20 GB) se cargan correctamente. La compilación de 32B con una ventana grande se acercará al límite, así que supervise ollama ps en lugar de darlo por supuesto.

Qué degrada primero la cuantización

El error de cuantización no afecta por igual a todas las tareas que realiza un modelo. La fluidez es lo último que se pierde. Precisamente por eso, el daño puede pasar desapercibido: un modelo mal cuantizado todavía genera frases bien redactadas. Lo primero que se pierde es la precisión. Por ejemplo, la recuperación exacta de un número de versión, una firma de API o una fecha. También se degradan las cadenas largas de razonamiento, en las que un error pequeño en el paso dos produce una respuesta incorrecta en el paso ocho. Lo mismo ocurre con los formatos de salida estrictos, donde un corchete incorrecto hace que falle una llamada a una herramienta.

Este último caso es la prueba práctica. Cuando el modelo debe devolver JSON que analiza su código, el daño de la cuantización aparece como un error de análisis y no como una prosa ligeramente peor. Por eso se detecta el mismo día. Un agente de programación es la versión más exigente de esta prueba, porque ejecuta una llamada a una herramienta tras otra. Por tanto, dirigir un agente a su servidor de Ollama permite detectar una cuantización demasiado agresiva en una tarde.

Por debajo de cuatro bits, la pérdida aumenta rápidamente. Los tipos q3 y de dos bits existen para quienes intentan ejecutar un modelo grande en hardware pequeño. Son una opción válida cuando la alternativa es no ejecutar el modelo. No son una buena opción predeterminada. La diferencia entre q4_K_M y q8_0 es lo bastante pequeña como para que una tabla de perplejidad publicada no resuelva la elección para su carga de trabajo. No intente resolverla de ese modo. Ejecute ambos modelos con treinta de sus propios prompts y revise la salida.

Cuándo merece la pena q8_0 o fp16

Descarga q8_0 cuando la memoria esté realmente disponible y la tarea penalice los errores pequeños: extracción estructurada, llamadas a herramientas y código que deba compilar. En ese caso compras una garantía, no un modelo perceptiblemente más inteligente.

Descarga fp16 por sólo dos motivos. Puede que estés cuantificando el modelo tú mismo y necesites el archivo de origen, o que estés midiendo una línea base para saber cuánto has perdido con tu compilación de cuatro bits. Servir desde fp16 consume tres veces más memoria que q4_K_M para una diferencia que la mayoría de las personas no puede distinguir a ciegas. En un equipo que sólo use CPU, también reduce a un tercio la tasa de generación de tokens.

La regla más importante, con un presupuesto de memoria fijo, es la siguiente: un modelo más grande en q4_K_M suele superar a un modelo más pequeño en q8_0. 9.3 GB de pesos 14B frente a 8.9 GB de pesos 8B ocupan prácticamente la misma RAM (memoria de acceso aleatorio), y el modelo más grande contiene más conocimiento. Compruébalo con tus propios prompts en lugar de darlo por cierto.

La inferencia sólo con CPU está limitada por el ancho de banda de la memoria

La mayoría de los planes VPS no incluyen GPU, por lo que el modelo se ejecuta en la memoria del sistema mediante la CPU del host. La generación queda limitada por el ancho de banda de la memoria, no por la capacidad de cálculo, porque producir un token requiere leer todos los pesos una vez. Esto establece un límite que no depende del número de núcleos contratados.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

Cincuenta GB/s es aproximadamente la cifra teórica de un host con DDR4-3200 de doble canal. Su parte es menor porque un VPS comparte ese bus con todos los demás tenants de la máquina, así que considere esas cifras un límite que nadie alcanza. Lo importante es la tendencia: en la CPU, reducir a la mitad los bits por peso duplica aproximadamente la velocidad de generación de tokens. La cuantización es el ajuste que más velocidad aporta en un equipo sin GPU. La tolerancia a la velocidad resultante depende del modelo, y Nemotron 3.5 Lightning en un VPS desarrolla ese cálculo para una compilación y una etiqueta concretas, con la cantidad de RAM incluida. La otra mitad de la espera depende de cuánto texto decida generar el modelo: a diez tokens por segundo, una respuesta de seiscientos tokens tarda un minuto completo. Por eso, limitar la respuesta con num_predict suele reducir más el tiempo de espera que bajar otro nivel de precisión.

El procesamiento del prompt funciona de otra manera. Leer un prompt largo está limitado por la capacidad de cálculo y no por el ancho de banda, así que los núcleos adicionales ayudan en esa fase, pero apenas mejoran la velocidad de generación. Un equipo que procesa rápidamente un prompt de 4k y después genera texto lentamente se comporta de forma normal.

No dé por válidos estos cálculos sin verificarlos. Mida los tokens por segundo en su propio equipo con el mismo prompt para cada cuantización y deje que sus mediciones prevalezcan sobre estas cifras.

Cuantizar un modelo manualmente

Esto es importante cuando ha ajustado un modelo y no existe ninguna etiqueta de biblioteca. La ruta depende del formato final que quiera obtener, porque Ollama ya no genera los K-quants de GGUF que se miden en esta página.

Para un K-quant como q4_K_M, cuantice el modelo antes de que Ollama vea el archivo. Ollama no cuantiza modelos GGUF durante la importación y rechaza --quantize cuando el origen es GGUF. Cuantice el GGUF sin cuantizar con llama-quantize de llama.cpp y, después, importe el archivo terminado. Esta ruta de importación tiene su propio problema: una discrepancia en la plantilla de chat puede hacer que el modelo responda con texto incoherente. Importar un archivo GGUF en Ollama explica cómo resolverlo. La línea quantization de ollama show permite verificar que el archivo importado corresponde a la compilación prevista.

El --quantize propio de Ollama sólo funciona con importaciones de safetensors. Apunte un Modelfile al directorio que contiene los pesos safetensors sin cuantizar:

FROM /path/to/safetensors/directory

Después, compile el modelo:

ollama create --quantize int4 mymodel

A fecha de Ollama v0.40.2 (comprobado el 2026-10-11), --quantize acepta int4, int8, nvfp4, mxfp4 y mxfp8. q4 y q8, así como fp4 y fp8, se interpretan como alias de int4 y int8. Los nombres GGUF, como q4_K_M, q4_K_S, q8_0, q6_K y q5_K_M, se rechazan con un error unsupported quantize type. Estos tipos no son los K-quants de GGUF de las tablas anteriores. Por tanto, no use las cifras de bits por peso y tamaño de archivo de esta página para predecir sus valores.

Lo que verá cuando algo falle

Todo se ejecuta en la CPU cuando esperaba usar la GPU. Lea la columna PROCESSOR:

ollama ps

Muestra 100% GPU, 100% CPU o una división como 48%/52% CPU/GPU. Una división significa que los pesos y la caché KV no cabían en la VRAM (RAM de vídeo, la memoria de la tarjeta gráfica), por lo que parte del modelo se colocó en la memoria del sistema. La velocidad se aproxima entonces a la tasa de la CPU, porque cada token espera a la parte lenta. Reduzca la ventana de contexto, cuantice la caché o use una compilación más pequeña. Añadir núcleos no ayudará.

El modelo termina durante la carga. Compruebe el kernel y el registro del servicio:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Una línea que contenga Out of memory: Killed process significa que el total de los pesos, la caché KV y los búferes superó la memoria disponible en el equipo. En un VPS sin swap configurado, todo el equipo puede quedar bloqueado durante varios segundos antes de que aparezca esa línea.

Las respuestas empeoraron y no cambió nada. Dos compilaciones del mismo modelo pueden coexistir en ollama ls con etiquetas diferentes, y un script que descarga el nombre sin sufijo seguirá la referencia que la biblioteca tenga asignada en ese momento. Ejecute ollama show con la etiqueta exacta que solicita el cliente y lea la línea quantization, en lugar de confiar en el nombre del archivo de configuración.

FAQ

¿Qué cuantización de Ollama debería descargar?

Empiece con q4_K_M. Es la etiqueta predeterminada que la biblioteca de Ollama publica para la mayoría de los modelos, por lo que ollama pull qwen3:8b y ollama pull qwen3:8b-q4_K_M descargan el mismo archivo. Cambie a q8_0 sólo cuando haya memoria disponible y la tarea penalice los errores pequeños, como las llamadas a herramientas o la salida JSON estructurada. Cuando el presupuesto de memoria es fijo, un modelo más grande en q4_K_M suele superar a un modelo más pequeño en q8_0. Pruebe esa combinación antes de dedicar más RAM a la precisión.

¿q4_K_M significa realmente cuatro bits por peso?

No. Medido en Llama 3.1 8B, son 4.89 bits por peso, porque cada bloque de pesos almacena su propia escala y los tensores más sensibles se promueven a un tipo más amplio. Q8_0 mide 8.5 bits, no ocho, por la misma razón. Use el valor medido para hacer estimaciones: el número de parámetros multiplicado por los bits por peso y dividido por ocho da el tamaño del archivo en bytes.

¿Cuánta RAM necesita un modelo 8B en un VPS que usa sólo CPU?

Sume los pesos, la caché KV y el margen disponible. Qwen3 8B en q4_K_M ocupa 5.2 GB de pesos. Con la ventana predeterminada de 4096 tokens, la caché añade 0.6 GB, para un mínimo aproximado de 5.8 GB antes de contar los búferes de cálculo y el sistema operativo. Con una ventana de 32k, la caché por sí sola ocupa 4.83 GB. Reserve 8 GB para una ventana corta y 16 GB si necesita una ventana larga.

¿Por qué mi modelo usa el 100% de la CPU si el servidor tiene una GPU?

Ejecute ollama ps y lea la columna PROCESSOR. 100% CPU o una distribución como 48%/52% CPU/GPU significa que los pesos y la caché KV no cabían en la VRAM. Por eso Ollama colocó una parte o todo el modelo en la memoria del sistema. La causa habitual es que la ventana de contexto es mayor que la capacidad de la tarjeta, porque la caché se asigna para toda la ventana cuando se carga el modelo. Reduzca la ventana con OLLAMA_CONTEXT_LENGTH, establezca OLLAMA_KV_CACHE_TYPE=q8_0 para reducir la caché a la mitad o descargue una cuantización más pequeña.