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 menos precisa, no se eliminan. Con cuatro bits, la mayoría de los modelos responden de forma similar a la versión 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 aspectos para un modelo concreto en un servidor concreto, antes de dedicar veinte minutos a descargar un archivo que no cabrá.

Si Ollama todavía no está en ejecución, comience por instalar Ollama en un VPS. Esta página asume 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 con 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 usa una escala precisa. Un bloque que contiene un valor atípico grande usa 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 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 se deterioran al redondearse se almacenan con mayor ancho, mientras que la mayor parte permanece en cuatro bits. Por eso q4_K_M produce una salida mejor que el q4_0 anterior con un tamaño de archivo casi idéntico.

Pida a Ollama que muestre lo que 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 referencia válida para un modelo que descargó hace meses y cuya elección ya no recuerda.

Bits por peso y origen del tamaño del archivo

Toda estimación de tamaño parte de un número: cuántos bits asigna el formato a cada peso, promediados en todo el archivo. llama.cpp publica valores medidos 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 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 la misma razón. Use el valor medido y el cálculo se aproximará a unos 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 representa, con suficiente aproximación, la memoria que ocupan los pesos una vez cargados. Ollama no desempaqueta nada al cargar: los pesos cuantizados permanecen en memoria con el mismo formato empaquetado y cada bloque se convierte cuando se utiliza.

Qué ofrece 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. Estos son los tamaños de Qwen3 en agosto de 2026, obtenidos de la lista de etiquetas de la página del modelo.

[
  {
    "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 una opción de compromiso que la biblioteca ofrezca a regañadientes. Es la opción predeterminada elegida por el proyecto original, por lo que igualarla es el primer paso razonable para cualquier modelo que no haya probado personalmente. El mismo razonamiento determina las etiquetas utilizadas en ejecutar Qwen 3 en un VPS.

Las proporciones se mantienen en todas las filas. Pasar de q4_K_M a q8_0 requiere aproximadamente un setenta por ciento más, no exactamente el doble, porque los tensores de embeddings 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 ocupa 20 GB de pesos, una cantidad que ya supera la capacidad de un equipo de 16 GB con cualquier 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 su cuenta.

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 todas las capas, 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 una solicitud 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 números del modelo proceden de su propia configuración: 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 el 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 por encima de los pesos. Aumente la ventana a 32k y la caché por sí sola alcanza 4.83 GB, casi tanta memoria como los pesos cuantizados. El mínimo para todo el modelo pasa a ser 10 GB. Se considera un mínimo porque los búferes de cómputo y el sistema operativo se suman a esa cifra. Consulte el valor real en la columna SIZE de ollama ps después de cargar el modelo.

La ventana se configura 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 después la columna CONTEXT de ollama ps para confirmar con qué ventana se cargó realmente el modelo en ejecución. OLLAMA_KV_CACHE_TYPE también cuantiza la 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. Configuración de num_ctx y su coste explica la ventana en detalle.

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

Hay que contar el peso del modelo, la caché KV y el margen para el sistema operativo y cualquier otro proceso en ejecución. Dos GB de margen resultan cómodos en un VPS pequeño.

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 funciona con comodidad. 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 instrucciones es la hora más útil que puede dedicar 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 se distribuye por igual en todo lo que hace un modelo. La fluidez es lo último que se pierde, precisamente por eso el daño es fácil de pasar por alto: un modelo con una cuantización deficiente sigue escribiendo 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, donde un pequeño error en el paso dos se convierte en una respuesta incorrecta en el paso ocho. 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 un modelo tiene que devolver JSON que analiza su código, el daño de la cuantización aparece como un error de análisis, no como una prosa ligeramente peor. Por eso lo detecta el mismo día. Un agente de programación es la versión más exigente de esta prueba, porque ejecuta el modelo mediante una llamada a una herramienta tras otra. Por tanto, dirigir un agente a su servidor de Ollama dejará al descubierto una cuantización demasiado agresiva en una tarde.

Por debajo de cuatro bits, la pérdida se acentúa. Los tipos de q3 y de dos bits existen para quienes intentan ejecutar un modelo grande en hardware limitado, y son una opción real cuando la alternativa es no ejecutar el modelo. No son una buena 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. No intente resolverlo 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 por la RAM

Use 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 compra un margen de seguridad, no un modelo notablemente más inteligente.

Use fp16 sólo por dos motivos. O cuantiza el modelo usted mismo y necesita el archivo de origen, o mide una línea base para saber cuánto ha perdido su compilación de cuatro bits. Servir el modelo desde fp16 consume tres veces más memoria que q4_K_M, pero la diferencia es imperceptible para la mayoría de las personas en una comparación a ciegas. En un equipo que sólo usa CPU, también reduce la tasa de tokens a un tercio.

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 requieren prácticamente la misma RAM (memoria de acceso aleatorio), y el modelo más grande sabe más. Pruebe esto con sus propios prompts en lugar de aceptarlo sin comprobarlo.

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 mediante 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 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 para 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. 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 velocidad de generación de tokens. La cuantización es el factor que más permite aumentar el rendimiento en un equipo sin GPU.

El procesamiento del prompt se comporta de otra forma. Leer un prompt largo está limitado por la capacidad de cálculo y no por el ancho de banda. Por eso, añadir núcleos ayuda en esa fase, pero apenas mejora la velocidad de generación. Un equipo que procesa rápidamente un prompt de 4k y después genera lentamente se está comportando con normalidad.

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

Cuantizar un modelo usted mismo

Ollama puede crear un modelo cuantizado a partir de un modelo fuente fp16 o fp32. Esto resulta útil cuando ha ajustado un modelo y no existe ninguna etiqueta de biblioteca. Indique en un Modelfile la ubicación de 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. La línea quantization de ollama show permite verificar que la compilación se realizó según lo solicitado.

Qué 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 (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 tasa de ejecución exclusiva 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 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 una 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 a la que la biblioteca lo apunte 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 debo 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 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 uno más pequeño en q8_0, así que pruebe 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, 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, y no ocho, por el mismo motivo. Use la cifra medida para hacer estimaciones: el número de parámetros multiplicado por los bits por peso y dividido entre ocho da el tamaño del archivo en bytes.

¿Cuánta RAM necesita un modelo 8B en una VPS que sólo usa la 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, con un mínimo aproximado de 5.8 GB antes de incluir los búferes de cálculo y el sistema operativo. Con una ventana de 32k, la caché por sí sola ocupa 4.83 GB. Planifique 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, significa que los pesos y la caché KV no cabían en la VRAM, por lo que 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.