Ollama: q4_K_M, q8_0 o fp16, ¿cuál elegir?

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 una cuarta parte y la máquina lee una cuarta parte 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.

Ese 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 efectos 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. Esta página supone 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á cuantizado: es el modelo en coma flotante de 16 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 todos 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 son las que hacen utilizable un archivo de cuatro bits y también explican por qué un archivo de cuatro bits nunca tiene 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 anterior q4_0 con casi el mismo tamaño de archivo.

Consulte qué tiene Ollama en el 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 elección ya no recuerda.

Bits por peso es de donde sale el tamaño del archivo

Toda estimación de tamaño parte de un número: cuántos bits por peso usa 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 una arquitectura 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 usa cuatro bits por peso. Usa 4.89 bits, porque las escalas de bloque y los tensores promocionados también ocupan espacio real. Q8_0 usa 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 archivo real:

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.

Qué incluye realmente 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 únicamente con etiquetas cloud, sin nada que descargar en ningún tamaño. Ese es el límite con el que se encuentra al intentar ejecutar GLM 5.2 en un VPS. Estos son los tamaños de Qwen3 en agosto 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 ocupar RAM, y dos o tres de ellas juntas llenarán 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 aquí. 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 una solución de compromiso que la biblioteca ofrezca a regañadientes. Es la opción predeterminada que eligió el proyecto upstream, por lo que usarla es el primer paso lógico para cualquier modelo que aún no haya probado personalmente. El mismo criterio determina las opciones de etiqueta 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 embeddings y de salida no escalan igual que el resto. fp16 ocupa aproximadamente el triple que q4_K_M. Un modelo de 32B en q4_K_M contiene 20 GB de pesos. Eso ya supera lo que puede alojar un equipo con 16 GB incluso sin una ventana de contexto. Para obtener una visión más amplia de qué modelos caben en cada máquina, consulte qué modelos puede alojar por cuenta propia.

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 linealmente con el tamaño de ventana permitido. Se asigna para toda la ventana cuando se carga el modelo, no a medida que se completa 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 muestra 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 la ventana predeterminada de Ollama de 4096 tokens, 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 el modelo completo pasa a ser 10 GB. Se habla de un mínimo porque los búferes de cómputo y el sistema operativo se suman a esa cantidad. Consulte el valor real en la columna SIZE de ollama ps después de cargar el modelo.

La ventana se establece en el servidor, no por solicitud, 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 la columna CONTEXT de ollama ps para confirmar con qué ventana se cargó realmente el modelo en ejecución. OLLAMA_KV_CACHE_TYPE cuantiza también la propia caché: f16 es el valor predeterminado, q8_0 usa aproximadamente la mitad de memoria que 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. En un equipo pequeño con una ventana larga, reducir a la mitad la caché libera más memoria que cualquier otro cambio individual. Configurar num_ctx y su coste explica la ventana con más detalle. La caché también se dimensiona una vez por cada ranura de solicitud simultánea, no una vez por servidor. Por tanto, permitir que Ollama responda a dos prompts a la vez duplica la cantidad que acaba de presupuestar. Ese es el cálculo en el que se basa elegir el número de ranuras en paralelo y el límite de la cola.

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

Hay que reservar memoria para los pesos, la caché KV, el sistema operativo y cualquier otro proceso en ejecución. En un VPS pequeño, reservar 2 GB de margen suele ser suficiente.

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

16 GB. 8B en q4_K_M funciona cómodamente con una ventana de 16k o 32k. 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 propias solicitudes es la prueba más útil que puede hacer sobre este tema.

32 GB. 14B en q8_0 (16 GB) y 32B en q4_K_M (20 GB) se cargan correctamente. La versión 32B con una ventana amplia se acercará al límite, así que supervise ollama ps en lugar de dar por hecho que habrá margen.

Qué se degrada primero con la cuantización

El error de cuantización no se distribuye de manera uniforme en las capacidades de un modelo. La fluidez es lo último que se pierde, y precisamente por eso el daño es fácil de pasar por alto: un modelo cuantizado de forma deficiente todavía escribe frases correctas. La precisión se pierde primero. La recuperación exacta de un número de versión, una firma de API o una fecha. Las cadenas largas de razonamiento, en las que un pequeño error en el paso dos produce una respuesta incorrecta en el paso ocho. Los formatos de salida estrictos, en los que un corchete incorrecto hace que falle una llamada a una herramienta.

Este último caso es la prueba práctica. Cuando un 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 vagamente peor, por lo que lo detecta el mismo día. Un agente de programación es la versión más exigente de esta prueba, porque hace que el modelo ejecute llamadas a herramientas una tras otra. Por eso, dirigir un agente a su servidor Ollama dejará al descubierto una cuantización demasiado agresiva en una tarde.

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

Cuándo compensa q8_0 o fp16 por la RAM

Descarga q8_0 cuando la memoria esté realmente disponible y la tarea penalice los errores pequeños: extracción estructurada, llamadas a herramientas o código que tenga que compilar. En este caso compras un margen de seguridad, no un modelo perceptiblemente más inteligente.

Descarga fp16 sólo por dos motivos. O cuantizas tú mismo el modelo y necesitas el archivo de origen, o mides una línea base para saber cuánto has sacrificado 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 usa CPU, también reduce a un tercio la velocidad de generación de tokens.

La regla más importante, con un presupuesto de memoria fijo, es esta: 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 casi la misma RAM (memoria de acceso aleatorio), y el modelo más grande sabe más. Compruébalo con tus propios prompts en lugar de aceptarlo sin verificar.

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

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

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 el valor teórico para un host con DDR4-3200 de doble canal. Su parte es menor, porque un VPS comparte ese bus con todos los demás inquilinos de la máquina. Por tanto, 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 aproximadamente duplica la tasa de tokens. La cuantización es el factor que más puede aumentar la velocidad en un equipo sin GPU. Que la tasa resultante sea aceptable depende del modelo. Nemotron 3.5 Lightning en un VPS analiza ese cálculo para una compilación concreta e incluye la etiqueta y la cantidad de RAM. 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 aplicar otro nivel de reducción de precisión.

El procesamiento del prompt se comporta de otra forma. Leer un prompt largo está limitado por la capacidad de cálculo, no por el ancho de banda. Por eso, más núcleos ayudan en esa fase, pero casi no aumentan la velocidad de generación. Un equipo que procesa rápidamente un prompt de 4k y después genera despacio funciona con normalidad.

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 propias cifras prevalezcan.

Cuantizar un modelo usted mismo

Ollama puede crear un modelo cuantizado a partir de un origen fp16 o fp32. Esto es útil cuando ha ajustado un modelo y no existe ninguna etiqueta de biblioteca. Indique en un Modelfile dónde están los pesos sin cuantizar:

FROM /path/to/my/model/f16

Después, cree el modelo y confirme el resultado:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize acepta q8_0, q4_K_S y q4_K_M. Aquí no existe ninguna opción q6_K ni q5_K_M. Para esos casos, cuantice el modelo con la herramienta propia de llama.cpp e importe el archivo GGUF resultante. Esta vía de importación tiene su propio problema: una discrepancia en la plantilla de chat puede hacer que el modelo responda con texto ilegible. La importación de un archivo GGUF en Ollama explica cómo resolverlo. La línea quantization de ollama show permite verificar que la compilación hizo lo que se solicitó.

Lo que verá cuando algo falle

Todo se ejecuta en la CPU cuando esperaba que se ejecutara en 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 (memoria 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 de la CPU, porque cada token espera a la parte más lenta. Reduzca la ventana de contexto, cuantice la caché o descargue una compilación más pequeña. Añadir núcleos no ayudará.

El modelo se termina mientras se carga. Compruebe el registro del kernel y el 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 configurada, toda la máquina puede quedar bloqueada 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 a la que apunte ahora la biblioteca. Ejecute ollama show con la etiqueta exacta que solicita su 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 distribuye la biblioteca de Ollama 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. Use q8_0 sólo cuando tenga 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 sea fijo, un modelo más grande en q4_K_M suele superar a un modelo más pequeño en q8_0. Pruebe primero esa combinación antes de asignar más RAM a la precisión.

¿q4_K_M significa realmente cuatro bits por peso?

No. Medido en Llama 3.1 8B, usa 4.89 bits por peso, porque cada bloque de pesos almacena su propia escala y los tensores más sensibles se promocionan a un tipo más ancho. Q8_0 usa 8.5 bits, y no ocho, por la misma razón. Use la cifra medida 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 una VPS que sólo usa 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, lo que deja un mínimo cercano a 5.8 GB antes de contar los búferes de cómputo 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 división como 48%/52% CPU/GPU, indica 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 más grande de lo que puede alojar la tarjeta. 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.