Optimización del rendimiento de Ollama: guía completa de cuantización, batch processing y ajuste de memoria

Actualización 2026-06-08: variables de entorno revisadas con la documentación oficial de Ollama — las capas GPU se ajustan con la opción de modelo num_gpu (no existe OLLAMA_GPU_LAYERS); reserva VRAM con OLLAMA_GPU_OVERHEAD (bytes); la cuantización del KV cache usa OLLAMA_KV_CACHE_TYPE. Los benchmarks son orientativos y varían según versión y hardware.

Tu modelo de 14B arranca, pero la inferencia va a 10 tokens/s. ¿O directamente falla con OOM y se cierra? El ventilador de la GPU a tope y pantalla negra.

Situación típica: descargas llama3 8B con ilusión, ejecutas ollama run y la VRAM no alcanza. O error y cierre, o tan lento que duele. Cambias a una versión Q4, funciona, pero te preguntas: ¿cuánta calidad perdiste?

Al empezar con Ollama caí en lo mismo: 8 GB de VRAM y un modelo 14B, pensando que con arrancar bastaba. Resultado: CUDA out of memory o palabra por palabra.

El problema no es el hardware. Es la configuración.

Aquí repasamos tres palancas: cuantización, batch processing y ajuste de memoria. Con estas tres claras, el rendimiento de tu LLM local puede duplicarse — no marketing, sino tokens/s reales.

1. Cuantización: equilibrio calidad/velocidad de Q4 a FP16

1.1 ¿Qué es la cuantización? ¿Por qué GGUF es el formato dominante?

En pocas palabras: cuantizar es «comprimir» el modelo.

Los parámetros originales van en FP16 (16 bits). Un modelo 7B en FP16 pide unos 14 GB solo de parámetros. Si pasas cada parámetro a 4 bits, en teoría bajas a ~3,5 GB. Menos bits, menos memoria y más velocidad.

El costo: pérdida de precisión. Como bajar una foto 4K a 720p: pierdes detalle, pero en muchos casos «sirve».

GGUF triunfa por una razón: comodidad. Lo diseñó el equipo de llama.cpp, soporta mmap y carga bajo demanda sin leer todo el modelo a RAM. Con 16 GB de RAM puedes correr 13B — con formatos clásicos, imposible.

1.2 Tipos de cuantización: Q4_0, Q4_K_M, Q5_K_M, Q8_0

Lo que confunde a muchos: Q4_0, Q4_1, Q4_K_M, Q5_K_M, Q8_0… ¿cuál elegir?

Tabla comparativa de los tipos habituales:

Tipo de cuantización	Ratio de compresión	Memoria (modelo 7B)	Pérdida de calidad	Escenario
Q4_0	~4,5x	~4,0 GB	Alta	VRAM muy justa, calidad secundaria
Q4_K_M	~4,5x	~4,7 GB	Muy baja	Mejor relación calidad/costo, uso diario
Q5_K_M	~3,5x	~5,8 GB	Mínima	Prioridad calidad, VRAM suficiente
Q8_0	~2x	~7,2 GB	Casi nula	Máxima calidad, VRAM amplia
FP16	1x	~14 GB	Ninguna	Investigación, GPU potente

En resumen: Q4_K_M es la opción por defecto. La diferencia con FP16 en respuestas, salvo que busques fallos, no se nota en chat cotidiano.

Q5_K_M si tienes VRAM de sobra y te importa la calidad. Q8_0 solo con 24 GB o más — y entonces quizá conviene un modelo más grande.

1.3 Árbol de decisión para elegir cuantización

Lógica simple:

Paso 1: mira la VRAM

• VRAM ≤ 8 GB: solo Q4_K_M; 7B justo, 14B con CPU offload
• VRAM 12-16 GB: Q4_K_M para 14B; 7B puede ir a Q5_K_M
• VRAM ≥ 24 GB: Q5_K_M o Q8_0, incluso modelos 70B

Paso 2: mira el uso

• Chat y código: Q4_K_M basta
• Traducción o escritura exigente: Q5_K_M
• Investigación o benchmarks: Q8_0 o FP16

Datos de referencia:

• 7B Q4_K_M: ~4,7 GB VRAM
• 14B Q4_K_M: ~9 GB VRAM
• 70B Q4_K_M: ~40 GB VRAM

Mi consejo: empieza con Q4_K_M. Si la calidad no convence, sube a Q5_K_M. No persigas «sin pérdida» de entrada; a veces es sugestión.

1.4 Cómo descargar una versión cuantizada concreta

Ollama descarga Q4_K_M por defecto. ¿Otra versión?

# Descarga Q4_K_M por defecto
ollama run llama3

# Especificar cuantización Q5
ollama run llama3:70b-q5

# Especificar cuantización Q8
ollama run llama3:70b-q8

No todos los modelos tienen todas las variantes. Consulta la biblioteca oficial o:

# Ver modelos locales
ollama list

# Ver detalles del modelo (incluida cuantización)
ollama show llama3 --modelfile

Si eres usuario avanzado, puedes cuantizar con llama.cpp y controlar precisión y parámetros. Es juego de nivel superior; aquí no lo desarrollamos.

2. Batch processing: subir el throughput un 50-150%

2.1 ¿Por qué el batch acelera?

Muchos no lo tienen claro. Analogía: en caja del super, atender de uno en uno es lento; procesar varios carritos seguidos, el cajero rinde más.

En GPU pasa lo mismo: un token aislado deja la unidad de cómputo esperando datos. El batch agrupa tokens y mantiene la GPU ocupada.

Ojo: el batch sube el throughput, no la latencia de una sola petición. Solo tú, poco cambio. Con API y varias peticiones concurrentes, el throughput puede duplicarse o más.

2.2 Parámetro num_batch

num_batch es el parámetro central de batch en Ollama; por defecto 512.

A mayor valor, más uso de GPU y más throughput. Costo: 20-40 % más de VRAM.

Ajuste según VRAM libre:

Situación VRAM	num_batch recomendado	Efecto esperado
VRAM ajustada	512 (por defecto)	Seguro, algo de GPU ociosa
VRAM media	1024	+50-80 % throughput
VRAM holgada	2048	+100-150 % throughput

En mi experiencia: RTX 3080 (10 GB) con 7B Q4_K_M, num_batch 1024 va estable; 2048 a veces dispara OOM. RTX 4090 con 14B, 2048 sin problema.

2.3 num_ctx y KV Cache

num_ctx es el tamaño de ventana de contexto; por defecto 2048. Impacta la memoria del KV Cache.

El KV Cache guarda resultados previos para no recalcular. Más contexto, más caché.

Fórmula aproximada:

Memoria KV Cache ≈ 2 × capas × dimensión oculta × num_ctx × bytes de precisión

Cifras orientativas:

• 7B, num_ctx=4096: +1-2 GB
• 14B, num_ctx=8192: +3-4 GB

Con contextos largos (32K, 128K), la VRAM sube rápido. Muchos creen que solo los parámetros llenan la GPU; a menudo es el KV Cache.

Trampa: algunos modelos permiten num_ctx enorme (llama3 hasta 128K), pero si lo pones al máximo, revienta la VRAM. Para el día a día, 4096 u 8192 bastan.

2.4 Configuración de batch en la práctica

Ejemplos directos.

Opción 1: Modelfile

# Crear desde modelo base
FROM llama3

# Tamaño de batch
PARAMETER num_batch 1024

# Ventana de contexto
PARAMETER num_ctx 4096

# Conservar system prompt
PARAMETER num_keep 128

Guarda como Modelfile y crea el modelo:

ollama create my-llama3 -f Modelfile
ollama run my-llama3

Opción 2: API options

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Explica la computación cuántica",
  "options": {
    "num_batch": 1024,
    "num_ctx": 4096
  }
}'

Comparativa de rendimiento (RTX 3080, 7B Q4_K_M):

num_batch	Throughput (tokens/s)	Uso VRAM
512	45	5,2 GB
1024	72	6,1 GB
2048	98	7,4 GB

De 512 a 1024, +60 % throughput con menos de 1 GB extra. Buen trato.

3. Ajuste de memoria: tres estrategias contra OOM

3.1 Asignación de memoria GPU

Ollama gestiona la VRAM con cierta inteligencia:

1. ¿Cabe el modelo entero?
2. Si sí, todo a GPU
3. Si no, offload parcial a CPU

«Inteligente» no es perfecto: a veces falla el cálculo o un caso límite y aparece OOM.

Parámetro clave: num_gpu. Controla cuántas capas van a GPU. -1 = automático. Manual, p. ej. num_gpu: 20: 20 capas en GPU, el resto en CPU.

3.2 Estrategia 1: bajar de cuantización

Lo más directo: OOM → cuantización más agresiva.

Ruta de degradación:

Q8_0 → Q5_K_M → Q4_K_M → Q4_0

Cada paso ahorra ~20-25 % VRAM.

Ejemplo: 14B Q5_K_M pide ~11 GB y falla. Q4_K_M ~9 GB (-18 % VRAM); en chat diario la calidad casi no se nota.

En 8 GB corrí 7B Q4_K_M sin drama. 14B Q4_K_M justo; contexto largo → OOM. Compromiso: 14B Q4_0, algo peor pero usable.

3.3 Estrategia 2: inferencia híbrida con CPU offload

VRAM insuficiente: reparte carga con CPU.

num_gpu fija capas en GPU. Modelo de 32 capas con num_gpu: 24: 8 capas en CPU.

Costo: más lento. CPU puede ser 10× más lenta que GPU. Mejor que no arrancar.

Configuración:

# Modelfile
FROM llama3
PARAMETER num_gpu 24

O vía API:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Hola",
  "options": {
    "num_gpu": 24
  }
}'

Velocidad híbrida (14B Q4_K_M, RTX 3080 10 GB + i7-12700K):

num_gpu	Velocidad	VRAM
40 (todo GPU)	OOM	12 GB (excedido)
30	18 tokens/s	9,2 GB
20	12 tokens/s	6,5 GB
0 (solo CPU)	4 tokens/s	0,5 GB

Con num_gpu=30 la velocidad es aceptable y no revienta VRAM. Ahí está el valor del híbrido.

3.4 Estrategia 3: optimizar KV Cache

El KV Cache se ignora a menudo y puede ser el mayor consumidor.

Método 1: Flash Attention

Atención optimizada que reduce mucho el uso de VRAM.

# Variable de entorno
export OLLAMA_FLASH_ATTENTION=1

# O al arrancar Docker
docker run -e OLLAMA_FLASH_ATTENTION=1 ollama/ollama

Efecto: -30-50 % VRAM en KV Cache. Muy recomendable activarlo.

Método 2: reducir num_ctx

Más contexto, más caché. Si no necesitas 32K:

PARAMETER num_ctx 2048  # Por defecto; suficiente para chat

Método 3: num_keep para el system prompt

num_keep fija cuántos tokens no se recortan al deslizar contexto. Igual a la longitud del system prompt evita que se pierda.

PARAMETER num_keep 128

3.5 Flujo práctico ante OOM

Ante OOM, sigue este orden:

Paso 1: revisar VRAM

nvidia-smi

Paso 2: revisar parámetros del modelo

ollama show llama3 --modelfile

Comprueba num_ctx, num_batch, etc.

Paso 3: degradar paso a paso

• Bajar num_batch: 1024 → 512
• Bajar num_ctx: 4096 → 2048
• Bajar cuantización: Q5_K_M → Q4_K_M

Paso 4: CPU offload
num_gpu al 70-80 % del total de capas.

Paso 5: solo CPU
Sin VRAM, CPU. Lento pero funciona.

# Forzar CPU puro con la opción de modelo num_gpu=0 (API o Modelfile)
curl http://localhost:11434/api/generate -d '{"model":"llama3","prompt":"hola","options":{"num_gpu":0}}'

Inferencia solo CPU ronda 1/10 de la GPU. Para uso ocasional o batch offline, puede valer.

4. Benchmarks y referencia de hardware

4.1 Velocidad de inferencia por hardware

Tabla orientativa para comparar con tu equipo:

NVIDIA (7B Q4_K_M)

GPU	VRAM	tokens/s	Nota
RTX 3060	12 GB	52	Buena relación precio/rendimiento
RTX 3080	10 GB	68	Opción estable
RTX 3090	24 GB	95	Puede 14B Q4
RTX 4070 Ti	12 GB	78	Ventaja arquitectura nueva
RTX 4090	24 GB	120	Configuración top

NVIDIA (14B Q4_K_M)

GPU	VRAM	tokens/s	Nota
RTX 3060	12 GB	28	Justo
RTX 3080	10 GB	OOM	Requiere CPU offload
RTX 3090	24 GB	55	Cómodo
RTX 4090	24 GB	72	Muy rápido

Apple Silicon (Metal)

Dispositivo	RAM	7B tokens/s	14B tokens/s
M2 Air 8 GB	8 GB	35	OOM
M2 Pro 16 GB	16 GB	48	22
M2 Max 32 GB	32 GB	58	32
M2 Ultra 64 GB	64 GB	65	45

Ventaja de Apple: memoria unificada amplia. Rendimiento por núcleo menor que GPU dedicada alta gama.

Solo CPU

CPU	RAM	7B tokens/s	14B tokens/s
i7-12700K	32 GB	6	3
Ryzen 9 7950X	64 GB	8	4
M2 Max (solo CPU)	32 GB	12	6

Funciona, lento. Mejor para batch que chat en tiempo real.

4.2 Datos de mejora de throughput con batch

Efecto de num_batch (RTX 3080, 7B Q4_K_M, varias peticiones concurrentes):

num_batch	Latencia por petición	Throughput concurrente	VRAM
512	22 ms/token	45 tokens/s	5,2 GB
1024	22 ms/token	72 tokens/s	6,1 GB
2048	22 ms/token	98 tokens/s	7,4 GB

Hallazgos:

• Latencia por petición casi igual: el batch no penaliza una sola solicitud
• Throughput casi duplicado: 2048 vs 512, +118 % en concurrencia
• Costo VRAM controlado: +118 % throughput por +2,2 GB

4.3 Variables de entorno útiles

# Flash Attention (muy recomendado)
export OLLAMA_FLASH_ATTENTION=1

# Cuantización del KV cache: f16(def)/q8_0(~mitad)/q4_0(~cuarto), requiere Flash Attention
export OLLAMA_KV_CACHE_TYPE=q8_0

# Reservar VRAM para el sistema/otras apps (bytes, por defecto 0)
export OLLAMA_GPU_OVERHEAD=1073741824  # reservar 1 GB

# Tiempo de vida del modelo (por defecto 5 min)
export OLLAMA_KEEP_ALIVE=24h

# Longitud de contexto por defecto (sobrescribe la del modelo)
export OLLAMA_CONTEXT_LENGTH=4096

# Límite de peticiones concurrentes
export OLLAMA_MAX_QUEUE=512

# Nivel de log
export OLLAMA_DEBUG=1

Ejemplo Docker Compose completo:

version: '3'
services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    restart: unless-stopped
    environment:
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_MAX_QUEUE=512
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  ollama_data:

Guarda como docker-compose.yml y:

docker-compose up -d

Lectura relacionada

• Guía completa de aceleración por GPU en Ollama
• Embeddings locales y RAG con Ollama
• Guía de hardware para Llama 70B en local

Resumen

Tres pasos de optimización:

Paso 1: elige cuantización
Según VRAM. Q4_K_M es el equilibrio habitual. Con margen, Q5_K_M.

Paso 2: ajusta batch
Si sobra VRAM, sube num_batch a 1024 o 2048. Throughput al doble, poco más de memoria.

Paso 3: resuelve OOM
Flash Attention, num_ctx menor o CPU offload. Prueba en orden hasta equilibrio.

La optimización es iterativa: hardware, tamaño de modelo y uso cambian. Empieza por cuantización, confirma que arranca, luego batch, y al final variables avanzadas.

Si tienes un caso concreto — modelo, error, configuración — comenta o revisa la documentación oficial de Ollama. La comunidad aporta mucha experiencia práctica, más que la teoría sola.