Ollama muy lento: 10 trucos para acelerarlo 3X (2025)

Has montado tu servidor de IA local con Ollama, estás emocionado probando Llama 3 o Mistral, pero… esperas 5-10 segundos por respuesta. O peor: el primer token tarda una eternidad en aparecer. Frustrante, ¿verdad?

La buena noticia: Ollama puede ser MUCHO más rápido. En esta guía te enseño 10 técnicas probadas para acelerar tus modelos locales hasta 3X, desde ajustes simples (5 minutos) hasta optimizaciones avanzadas para exprimir cada gota de rendimiento de tu hardware.

¿Por qué va lento Ollama? Diagnóstico rápido

Antes de optimizar, identifica DÓNDE está el cuello de botella. Los problemas más comunes:

Síntomas y cuellos de botella típicos

1. Primera respuesta muy lenta (10-30 segundos), luego fluido

➜ Problema: Carga del modelo (model loading)

➜ Causa: Modelo en disco, no en VRAM/RAM

2. Generación de tokens lenta constante (1-3 tokens/segundo)

➜ Problema: CPU inference o cuantización excesiva

➜ Causa: GPU no detectada o modelo muy cuantizado

3. Respuestas rápidas con modelos pequeños, lentas con grandes

➜ Problema: VRAM insuficiente (swapping a RAM/CPU)

➜ Causa: Modelo no cabe en VRAM de tu GPU

4. Rendimiento degrada después de múltiples respuestas

➜ Problema: Contexto creciendo, memory leak o thermal throttling

➜ Causa: Contexto muy largo o GPU sobrecalentando

Comando de diagnóstico rápido

Ejecuta esto mientras Ollama responde una query:

watch -n 0.5 nvidia-smi

Observa:

• GPU Utilization: Debería estar 80-100% durante generación
• Memory Usage: Debería estar cerca del tamaño del modelo
• Temperature: Menos de 80°C ideal (thermal throttling sobre 85-90°C)
• Power Draw: Cerca del TDP de la GPU = buena utilización

Si GPU utilization está bajo (0-20%), Ollama está usando CPU. Si memoria está maxed out, modelo no cabe en VRAM.

Trucos inmediatos (resultados en 5 minutos)

1. Mantener el modelo en memoria (keep_alive)

Problema que resuelve: Modelo se descarga de VRAM después de cada uso, siguiente query tiene que recargarlo (10-30 segundos de delay).

Solución: Configurar keep_alive para mantener modelo cargado permanentemente.

# Opción A: Variable de entorno (recomendado)
export OLLAMA_KEEP_ALIVE=-1

# Reiniciar servicio Ollama
sudo systemctl restart ollama

Valores de keep_alive:

• -1: Mantener modelo en memoria indefinidamente (recomendado si tienes VRAM suficiente)
• 5m: Mantener 5 minutos después de última query (default)
• 30m, 1h: Mantener más tiempo pero eventualmente descargar
• 0: Descargar inmediatamente (solo si VRAM MUY limitada)

Opción B: Especificar al ejecutar

ollama run llama3.1 --keep-alive -1

Ganancia esperada: Elimina 10-30 segundos de delay en primera respuesta. ENORME diferencia en uso interactivo.

2. Usar la cuantización adecuada para tu VRAM

Problema que resuelve: Modelo muy grande para tu VRAM hace swapping a RAM/CPU (lentísimo). Modelo demasiado cuantizado genera mal y lento.

Solución: Elegir cuantización que maximice calidad SIN exceder VRAM.

Cómo cambiar modelo/cuantización:

# Listar modelos disponibles en Ollama
ollama list

# Descargar cuantización específica
ollama pull llama3.1:8b-instruct-q4_K_M
ollama pull mistral:7b-instruct-q6_K

# Usar el modelo específico
ollama run llama3.1:8b-instruct-q4_K_M

Regla de oro: Usa la cuantización MÁS ALTA (Q8, Q6) que quepa en tu VRAM sin swapping. Q4 solo si VRAM muy limitada.

Ganancia esperada: 2-3X velocidad vs modelo que hace swap. Calidad mejor con cuantización alta.

3. Activar Flash Attention 2 (si tu GPU lo soporta)

Problema que resuelve: Mecanismo de atención tradicional es lento en contextos largos (escala cuadráticamente).

Solución: Flash Attention optimiza matemática del mecanismo de atención (hasta 3X más rápido en contextos largos).

Requisitos:

• GPU NVIDIA con compute capability 8.0+ (RTX 30xx, 40xx, A100, H100)
• Ollama 0.1.33+ (verificar con ollama --version)

Activación:

# Variable de entorno
export OLLAMA_FLASH_ATTENTION=1

# Reiniciar Ollama
sudo systemctl restart ollama

# Verificar en logs que está activo
journalctl -u ollama -f | grep flash

Ganancia esperada: 20-40% más rápido en general, hasta 3X en contextos muy largos (8K+ tokens).

Nota: No todas las arquitecturas de modelos soportan Flash Attention. Si causa errores, deshabilita (export OLLAMA_FLASH_ATTENTION=0).

Optimizaciones de GPU (nivel intermedio)

4. Forzar uso de GPU (si Ollama usa CPU)

Problema que resuelve: Ollama no detecta GPU y corre en CPU (10-20X más lento).

Diagnóstico:

# Verificar que NVIDIA drivers funcionan
nvidia-smi

# Debería mostrar tu GPU y uso VRAM

# Verificar que Ollama detecta GPU
ollama list
# Ejecuta un modelo y observa nvidia-smi

Solución si no detecta GPU:

# 1. Verificar CUDA Toolkit instalado
nvcc --version

# Si no está instalado:
sudo apt install nvidia-cuda-toolkit

# 2. Verificar variable de entorno
export CUDA_VISIBLE_DEVICES=0

# 3. Forzar GPU específica (si tienes múltiples)
export OLLAMA_GPU_DEVICE=0

# 4. Reiniciar Ollama
sudo systemctl restart ollama

Ganancia esperada: 10-20X vs CPU. Crítico.

5. Ajustar num_gpu (capas en GPU vs CPU)

Problema que resuelve: Modelo parcialmente en GPU, parcialmente en CPU (híbrido lento).

Solución: Controlar cuántas capas del modelo van a GPU.

# Ver cuántas capas tiene el modelo
ollama show llama3.1 --modelfile

# Ajustar num_gpu al ejecutar
ollama run llama3.1 --num-gpu 999

# O especificar número concreto de capas
ollama run llama3.1 --num-gpu 35

Valores de num_gpu:

• 999 o -1: Todas las capas posibles en GPU (recomendado si cabe en VRAM)
• 0: Forzar CPU únicamente (útil para debugging)
• 20, 30, etc.: Número específico de capas en GPU (resto en CPU)

Cuándo usar valores intermedios: Si modelo casi cabe en VRAM pero no del todo, mejor algunas capas en CPU que swap constante.

Ganancia esperada: 30-50% si estaba haciendo offload innecesario a CPU.

6. Aumentar contexto de forma inteligente (num_ctx)

Problema que resuelve: Contexto default (2048 tokens) puede ser limitante, pero aumentarlo mucho hace generación lenta.

Solución: Ajustar contexto según caso de uso.

# Aumentar contexto a 4096 tokens
ollama run llama3.1 --ctx-size 4096

# Contexto muy largo (8192) solo si necesitas
ollama run llama3.1 --ctx-size 8192

Tradeoffs:

• Contexto bajo (2048): Rápido pero olvida conversaciones largas
• Contexto medio (4096-8192): Balance óptimo para chat
• Contexto alto (16K-32K): Lento, solo para análisis de documentos largos

Impacto en VRAM: Contexto más largo consume más VRAM (crecimiento lineal).

Fórmula aproximada: VRAM extra ≈ (num_ctx × hidden_size × num_layers) / 1e9 GB

Ganancia esperada: No acelera per se, pero optimiza velocidad vs capacidad contextual.

Optimizaciones de sistema (nivel avanzado)

7. Usar mmap para carga rápida de modelos

Problema que resuelve: Carga de modelo desde disco a memoria es lenta (10-30 segundos).

Solución: Memory-mapped files (mmap) mapean modelo directamente desde disco sin copiar a RAM.

# Activar mmap (default en versiones recientes)
export OLLAMA_MMAP=1

# Si tienes problemas, deshabilitar
export OLLAMA_MMAP=0

Ventajas de mmap:

• Carga inicial más rápida (segundos vs minutos en modelos grandes)
• Menos consumo RAM (sistema gestiona paging)
• Múltiples modelos pueden compartir memoria

Desventajas:

• Rendimiento depende de velocidad del disco (SSD NVMe recomendado)
• Primera inferencia puede ser ligeramente más lenta (page faults)

Ganancia esperada: 50-70% reducción en tiempo de carga de modelo.

8. Mover modelos a disco NVMe (si tienes HDD)

Problema que resuelve: Modelos en HDD = carga lenta, swapping lento si VRAM insuficiente.

Solución: Almacenar modelos Ollama en SSD NVMe.

# Ver dónde están los modelos actualmente
ls -lh ~/.ollama/models/

# Mover a SSD NVMe (ejemplo: montado en /mnt/nvme)
sudo systemctl stop ollama
mv ~/.ollama/models /mnt/nvme/ollama-models
ln -s /mnt/nvme/ollama-models ~/.ollama/models
sudo systemctl start ollama

Velocidades comparativas:

• HDD (7200 RPM): 100-150 MB/s lectura secuencial
• SATA SSD: 500-550 MB/s
• NVMe Gen 3: 3,000-3,500 MB/s
• NVMe Gen 4: 7,000+ MB/s

Ganancia esperada: 5-10X reducción tiempo carga modelo si venías de HDD.

9. Monitorizar y controlar temperatura GPU

Problema que resuelve: GPU sobrecalienta (85-90°C+), activa thermal throttling, rendimiento cae 30-50%.

Solución: Mejorar cooling y monitorizar temperaturas.

Monitorización:

# Temperatura en tiempo real
watch -n 1 nvidia-smi --query-gpu=temperature.gpu,power.draw,clocks.sm --format=csv

# Límite de temperatura
nvidia-smi -q -d TEMPERATURE

Mejoras de cooling:

• Limpieza: Polvo acumulado reduce cooling 20-30%
• Pasta térmica: Reemplazar si GPU tiene +2 años
• Curva de ventilador: Aumentar RPM fans (MSI Afterburner en Windows, nvidia-settings en Linux)
• Flujo de aire case: Añadir fans intake/exhaust, cable management
• Undervolt: Reducir voltage GPU (menos calor, mismo rendimiento) – avanzado

Temperaturas ideales:

• Excelente: 60-70°C bajo carga
• Aceptable: 70-80°C
• Preocupante: 80-85°C (empieza throttling leve)
• Problema: 85-90°C+ (throttling severo, reduce vida útil)

Ganancia esperada: 20-50% si había throttling térmico. Bonus: GPU dura más años.

10. Ajustar batch size (uso avanzado, APIs)

Problema que resuelve: Procesamiento de múltiples requests en paralelo ineficiente.

Solución: Ajustar batch size para procesar múltiples prompts simultáneamente.

Nota: Esto es relevante principalmente si usas Ollama vía API con múltiples requests concurrentes (ej: backend de app, integración con n8n).

# Configurar batch size (variable de entorno)
export OLLAMA_MAX_BATCH_SIZE=512

# Restart Ollama
sudo systemctl restart ollama

Valores recomendados:

• Default (128): Suficiente para uso personal
• 256-512: Múltiples usuarios concurrentes (5-10)
• 1024+: Workloads masivos (decenas de requests simultáneos)

Tradeoff: Batch size mayor = más latencia por request individual, pero throughput total más alto.

Ganancia esperada: 2-3X throughput en escenarios multi-usuario. No afecta uso interactivo individual.

Comparativa: Antes vs Después (caso real)

Setup de ejemplo: RTX 4060 Ti 16GB, Llama 3.1 8B

Optimizaciones aplicadas en este caso:

1. keep_alive = -1 (elimina recarga)
2. Cambio a Q6_K (calidad mejor, velocidad igual en 16GB VRAM)
3. Flash Attention activado
4. Limpieza GPU + mejora cooling (elimina throttling)
5. Modelos en SSD NVMe

Checklist de optimización completo

Usa este checklist para optimizar tu setup Ollama:

Básico (5 minutos)

• ☐ Activar keep_alive=-1 para mantener modelo en memoria
• ☐ Verificar que Ollama usa GPU (nvidia-smi durante inference)
• ☐ Elegir cuantización óptima para tu VRAM (Q4/Q6/Q8)
• ☐ Activar Flash Attention si GPU soporta (OLLAMA_FLASH_ATTENTION=1)

Intermedio (20 minutos)

• ☐ Configurar num_gpu para máximo uso GPU
• ☐ Ajustar num_ctx según caso de uso (4096-8192 sweet spot)
• ☐ Activar mmap (OLLAMA_MMAP=1)
• ☐ Monitorizar temperatura GPU (watch nvidia-smi)

Avanzado (1-2 horas)

• ☐ Mover modelos a SSD NVMe si estaban en HDD
• ☐ Mejorar cooling GPU (limpieza, pasta térmica, curva fans)
• ☐ Configurar batch size para workloads multi-usuario
• ☐ Considerar upgrade GPU si VRAM es cuello de botella recurrente

Cuándo el hardware es el límite (y qué hacer)

A veces, después de optimizar todo, sigues necesitando MÁS. Señales de que hardware es el límite:

• Modelos que quieres usar no caben en VRAM ni con Q4
• GPU utilization 100% constante pero respuestas aún lentas
• Temperaturas controladas pero rendimiento sigue bajo expectativas

Opciones de upgrade (2025)

Alternativa sin hardware: Servicios cloud

Si upgrade no es opción ahora, considera:

• RunPod / Vast.ai: Alquiler GPU por horas (0.30-0.80 USD/hora RTX 4090)
• Google Colab Pro: 10-50 USD/mes, GPUs compartidas
• AWS / Lambda Labs: Instancias GPU bajo demanda

Útil para workloads esporádicos intensivos, pero para uso diario homelab local sigue siendo más económico.

Preguntas Frecuentes

¿Cuántos tokens por segundo son buenos?

Depende de GPU y modelo. Benchmarks aproximados para Llama 3.1 8B Q4:

• RTX 3060 12GB: 25-35 t/s (bueno)
• RTX 4060 Ti 16GB: 35-50 t/s (excelente)
• RTX 4090 24GB: 80-120 t/s (bestial)
• CPU (Ryzen 7): 1-3 t/s (lento, solo emergencias)

Modelos más grandes (70B, 405B) generan mucho más lento incluso en GPUs potentes.

¿Pierde mucha calidad un modelo cuantizado?

Depende de la cuantización:

• Q8_0: Prácticamente indistinguible del modelo original (FP16)
• Q6_K: Muy poca pérdida de calidad (<5%), imperceptible en uso normal
• Q4_K_M: Pérdida leve (~10%), aceptable para la mayoría de tareas
• Q2/Q3: Pérdida notable, solo usar si VRAM extremadamente limitada

Regla: usa Q6 o Q8 si caben en tu VRAM, Q4 si no hay alternativa. Evita Q2/Q3.

¿Por qué contextos largos son tan lentos?

El mecanismo de atención (attention) de transformers escala cuadráticamente: O(n²) donde n = longitud contexto. Contexto 2X más largo = 4X más operaciones. Por eso:

• Contexto 2K: rápido
• Contexto 8K: 16X más lento que 2K (en teoría, optimizaciones ayudan)
• Contexto 32K: 256X más lento (prácticamente inusable sin optimizaciones)

Flash Attention ayuda enormemente aquí (cambia complejidad a lineal en práctica).

¿Ollama es más lento que otras alternativas (LM Studio, text-generation-webui)?

No necesariamente. Rendimiento similar en condiciones óptimas. Diferencias:

• Ollama: Simplicidad, menos configuración, bueno «out of the box»
• LM Studio: Interfaz gráfica amigable, similar rendimiento
• text-generation-webui: Más opciones avanzadas, curva aprendizaje mayor
• llama.cpp directo: Máximo control, configuración manual todo

Ollama usa llama.cpp bajo el capó, así que rendimiento base es idéntico. Diferencias vienen de defaults y UX.

¿Puedo usar múltiples GPUs con Ollama?

Sí, Ollama soporta multi-GPU automáticamente. Distribuye capas del modelo entre GPUs. Configuración:

export CUDA_VISIBLE_DEVICES=0,1  # Usar GPU 0 y 1
ollama run llama3.1:70b

Ollama detectará ambas GPUs y distribuirá modelo entre ellas. Suma VRAM efectiva (2x RTX 3090 24GB = 48GB VRAM disponible).

¿Es mejor que el modelo haga swap a RAM o usar cuantización más agresiva?

Cuantización más agresiva es MUCHO mejor. Swap a RAM/CPU es lentísimo:

• GPU inference: 100X más rápido que CPU
• VRAM bandwidth: 500-1,000 GB/s
• RAM bandwidth: 50-100 GB/s
• PCIe bandwidth: 16-32 GB/s (cuello de botella GPU↔RAM)

Prioridad: Modelo completo en VRAM (aunque sea Q4) > Swap parcial a RAM con Q8.

¿Es importante la CPU para Ollama o solo la GPU?

GPU es 95% del rendimiento. CPU importa poco si todo corre en GPU. Sin embargo:

• Carga inicial modelo: CPU rápida ayuda ligeramente
• Pre-procesamiento texto: CPU (irrelevante, <100ms)
• Si GPU saturada: CPU potente permite offload eficiente
• Multi-tasking: CPU decente evita que sistema se congele mientras Ollama trabaja

Recomendación mínima: 4 cores / 8 threads modernos. Más allá de eso, prioriza invertir en GPU.

¿Es necesario SSD NVMe o vale SATA SSD?

SATA SSD es suficiente, NVMe es lujo que se nota pero no crítico:

• HDD: Lento, frustante, no recomendado (salvo almacenamiento pasivo)
• SATA SSD: Bueno, 90% del rendimiento NVMe para Ollama
• NVMe Gen 3: Excelente, carga modelos muy rápido
• NVMe Gen 4/5: Overkill, diferencia imperceptible vs Gen 3 para Ollama

Si ya tienes SATA SSD, no urge upgrade. Si montas desde cero, NVMe Gen 3 son baratos ahora (80-100 EUR/1TB).

Recursos adicionales

Guías relacionadas en El Diario IA:

• Servidor IA casero: Guía completa 2025
• Error «CUDA out of memory» en Ollama: 7 soluciones
• RAG: Dale memoria a tu IA local
• Homelab completo 2025: Guía definitiva desde cero

Documentación oficial:

• Ollama GitHub (issues frecuentes, tips comunidad)
• llama.cpp (motor bajo el capó de Ollama)

Conclusión

Ollama puede ser MUCHO más rápido de lo que experimentas por defecto. Con las 10 técnicas de esta guía puedes lograr mejoras de 2-3X en velocidad de generación y eliminar delays frustrantes de carga de modelos.

Quick wins inmediatos (5 minutos):

1. export OLLAMA_KEEP_ALIVE=-1 (elimina recarga modelo)
2. Verifica GPU se esté usando (nvidia-smi)
3. Usa cuantización óptima para tu VRAM (Q6 > Q4 si cabe)
4. export OLLAMA_FLASH_ATTENTION=1 (si GPU RTX 30xx+)

Optimizaciones adicionales (20-60 minutos):

1. Ajustar num_gpu, num_ctx según uso
2. Mover modelos a SSD NVMe
3. Mejorar cooling GPU

Resultado: Experiencia de IA local fluida, comparable a APIs cloud pero con privacidad total y cero costes recurrentes.

Si después de optimizar todo sigues necesitando más velocidad, probablemente sea momento de considerar upgrade de GPU. Pero exprime tu hardware actual primero: te sorprenderá cuánto rendimiento dejas sobre la mesa con configuración default.

¿Conseguiste acelerar tu Ollama? ¿Qué optimización te dio mejores resultados? ¿Otras técnicas que uses? Comparte en comentarios para ayudar a la comunidad.