Recomendaciones de rendimiento y gestión de memoria para Ollama

Si estás pensando en montar un servicio privado de LLMs con Ollama, ya sea en tu propio ISP rural, en un pequeño datacenter o en un PC potente en casa, la gran duda siempre es la misma: ¿cómo exprimir al máximo el rendimiento sin tirar el dinero en hardware que luego no aprovechas?

En el mundo de los modelos de lenguaje grandes, VRAM, RAM, CPU, GPU, cuantización y contexto no son simples palabrejas técnicas: son las piezas que van a determinar si tu clúster vuela o se arrastra. Además, Ollama y llama.cpp gestionan la memoria y el reparto CPU/GPU de forma distinta, y entender esto es clave para decidir si te compensa un nodo gordo con varias GPU o varias máquinas más modestas 1:1 por cliente.

Agrupar GPU en un clúster o dedicarlas 1:1: qué conviene para Ollama

Cuando planteas un SaaS privado con Ollama, el primer dilema es si montar un pool centralizado de GPU o asignar una máquina (o GPU) por cliente. Aquí entra en juego cómo Ollama y llama.cpp usan los recursos:

Nodo “monstruo” con varias GPU: ideal si quieres colas de peticiones compartidas, aprovechar al máximo la GPU con muchos usuarios simultáneos y consolidar administración y mantenimiento.
Máquinas 1:1 por cliente: más aislamiento, menos líos de multi-tenant, predecible en consumo de recursos y muy cómodo para clientes que pagan por “su” máquina.

Ollama actualmente se centra más en aprovechar una o varias GPU locales por instancia que en orquestar un clúster distribuido tipo Kubernetes con reparto fino entre máquinas. Para un ISP pequeño que quiere dar servicio a “usuarios pro”:

Si el objetivo es simplicidad operativa, unas cuantas máquinas bien dimensionadas (16-24 GB VRAM cada una) con Ollama por nodo y reparto de clientes por servidor suelen ser la opción más sensata.
Si quieres jugar a “mini-hyperscaler”, puedes plantear un servidor gordo con varias GPU y un proxy (o varias instancias de Ollama/llama.cpp) para cada cliente, pero la complejidad de scheduling y aislamiento sube bastante.

El factor determinante no es solo la topología, sino qué modelos vas a servir, con qué contexto y cuántas sesiones concurrentes. Eso condiciona directamente cuánta VRAM necesitas por usuario.

Cómo gestiona Ollama la memoria, la VRAM y el reparto CPU/GPU

Ollama se apoya internamente en llama.cpp y otros backends, pero añade una capa de orquestación que simplifica mucho tu vida. A nivel de memoria y rendimiento, hay varios puntos clave:

Mapeo de modelos y carga en memoria

llama.cpp usa mmap para mapear el archivo GGUF del modelo en el espacio de direcciones. Esto permite que el sistema operativo decida qué partes están efectivamente en RAM en cada momento, reduciendo el tiempo de carga inicial respecto a volcar todo el archivo a memoria de golpe.

Ollama, por su parte, se encarga de:

Cargar y descargar modelos de VRAM/RAM según actividad, respetando el tiempo de OLLAMA_KEEP_ALIVE.
Compartir modelos entre sesiones de la misma instancia para evitar recargas innecesarias.
Mostrarte con ollama ps el uso de memoria, la división CPU/GPU y si hay descarga de capas al procesador.

En la práctica, cuando ves un modelo con, por ejemplo, 18%/82% CPU/GPU, significa que una parte de las capas no ha cabido en VRAM y se está ejecutando en la RAM del sistema vía CPU, con el consiguiente impacto en velocidad, como muestran varios análisis de latencia en redes locales.

¿Qué pasa si el modelo no cabe en VRAM?

Aquí está una de las preguntas más importantes: si un modelo entra totalmente en VRAM obtienes el rendimiento esperado al 100%. Pero cuando el modelo excede la VRAM disponible, Ollama reparte capas entre GPU y CPU. ¿Se degrada el rendimiento de forma proporcional a las capas que se caen a RAM, o te “encadena” por completo a la velocidad de la RAM y el bus?

Los datos prácticos con una RTX 4080 de 16 GB son demoledores:

Modelos 100% GPU: del orden de 60 a 140 tokens/s (p. ej. gpt-oss:20b con 14 GB usados llega a ~140 tok/s).
Modelos 70-80% GPU (resto en CPU): bajan a ~19-50 tok/s.
Modelos con ~20% GPU (mayoría en CPU): se quedan en ~12 tok/s (caso gpt-oss:120b, 66 GB de RAM+VRAM usados).

Es decir, no es un simple “pierdo un 30% de rendimiento porque el 30% está en CPU”, sino que la latencia de mover datos entre RAM y VRAM y de ejecutar capas en CPU multiplica el cuello de botella. Un 20B totalmente en GPU puede ser 10-11 veces más rápido que un 120B mayoritariamente en CPU.

Así que, para tu clúster: el objetivo nº1 es que los modelos críticos de uso interactivo quepan enteros en VRAM. Lo que no entre, mejor reservarlo para tareas batch, nocturnas o de baja prioridad.

Modelos MoE (Mixture of Experts) y descarga a CPU

Modelos tipo Mixture of Experts (como GLM 4.7 Flash o algunos Qwen y DeepSeek) tienen muchos parámetros totales, pero solo activan una fracción de expertos por token. Esto, en teoría, puede ayudar en escenarios de VRAM limitada porque no todas las partes del modelo se usan a la vez.

En la práctica, con Ollama:

Un MoE de 30B-A3B (30B totales, 3B activos) como glm-4.7-flash se mueve sobre los 30-35 tok/s con descarga parcial al CPU, bastante digno para su tamaño.
La ventaja MoE no compensa si el modelo sigue excediendo la VRAM y obliga a mover muchas capas por el bus.
Ollama no “entiende” el MoE como algo especial a nivel de scheduler, simplemente ve capas y memoria. La magia MoE está en la arquitectura del modelo, no en Ollama.

Conclusión práctica: MoE ayuda, pero no obra milagros. Si sobrepasas mucho la VRAM, seguirás pagando la factura de la RAM y la CPU. Mejor usar MoE para exprimir un poco más el límite, no para justificar trabajar siempre fuera de VRAM.

Comparativa llama.cpp vs Ollama para exprimir el hardware

Muchos debates empiezan con la típica pregunta: “¿por qué usar Ollama y no llama.cpp directamente?”. A nivel de rendimiento y gestión de memoria, merece la pena distinguir muy bien los papeles de cada uno.

llama.cpp: el quirófano de los tensores

llama.cpp es el motor C++ de alto rendimiento. Su objetivo es exprimir hasta el último ciclo de CPU y de GPU, con especial mimo a CPU x86 con AVX, Apple Silicon y GPU NVIDIA/AMD. Está pensado para quien quiere:

Ajustar quantización al detalle (Q4_K_M, Q5_0, Q8_0, Q2_K…).
Controlar número de capas en GPU con --n-gpu-layers.
Manejar contexto, batch, número de hilos, gramáticas GBNF y demás parámetros finos.

Nivel bajo, sí, pero muy potente. A nivel de memoria:

Usa mmap para cargar el modelo y deja al kernel decidir qué se mantiene en RAM.
Permite elegir con precisión qué capas pasan a GPU con -ngl, ajustando el consumo de VRAM al milímetro.
Integra K-Quants para reducir tamaño con el menor impacto posible en calidad.

En resumen: llama.cpp es perfecto si quieres montar tu propio servicio súper optimizado donde tú mandas en cada parámetro y no te importa ensuciarte las manos con opciones de línea de comandos y configuración avanzada.

Ollama: el orquestador de backends

Ollama está escrito en Go y se apoya en llama.cpp (y otros motores como vLLM en algunos escenarios) como backend. Su propuesta es darte una experiencia tipo “Docker para modelos”:

CLI simple: ollama pull, ollama run, ollama list, ollama ps.
API REST en 127.0.0.1:11434 por defecto, lista para conectar GUIs como Open WebUI o aplicaciones propias.
Gestión de modelos: descarga desde su registry, actualización, almacenamiento local, copia y push de tus propios modelos.
Detección automática de hardware: analiza GPU, RAM y contexto para ajustar capas GPU/CPU sin que toques --n-gpu-layers.

La diferencia real es de nivel de abstracción: llama.cpp es el motor en bruto, Ollama es el coche completo listo para conducir. A cambio de algo menos de control extremo, obtienes:

Arrancar modelos con un solo comando.
Colas de peticiones y descarga automática tras inactividad (OLLAMA_KEEP_ALIVE).
Integración directísima con GUIs y frameworks.

Para un usuario final o para dar servicio generalista a clientes de un ISP, Ollama suele ser la opción clara. Para modelos XXL muy ajustados o para sacarle todo el jugo a una GPU concreta, llama.cpp puede tener una ligera ventaja si lo sabes tunear bien.

Recomendaciones de hardware: VRAM, RAM, CPU y disco para Ollama

Para dimensionar tu clúster, no basta con mirar la GPU. El equilibrio entre VRAM, RAM, CPU, disco y contexto manda más de lo que parece.

VRAM: el recurso crítico

La VRAM es el cuello de botella principal. A nivel orientativo:

8 GB VRAM: suficiente para modelos pequeños/medios cuantizados (7B, algún 13B en Q4_K_M con contexto modesto).
16 GB VRAM: punto dulce actual para uso serio: 14B, 20B, 24B en Q4_K_M totalmente en GPU con contextos de ~16-32K.
24 GB o más: necesario si quieres 30B-35B con contexto amplio en GPU o manejar varias sesiones concurrentes de modelos medianos sin empezar a descargar capas.

Algunos valores prácticos en una RTX 4080 16 GB con contexto ~19K y cuantización Q4_K_M:

gpt-oss:20b (20B): ~14 GB, 100% GPU, ~140 tok/s.
qwen3:14b: ~12 GB, 100% GPU, ~62 tok/s.
mistral-3:14b: ~13 GB, 100% GPU, ~70 tok/s.

Cualquier modelo que supere estos márgenes acaba mezclando CPU/GPU. En tu proyecto, si quieres dar contexto grande tipo 80-100K a varios usuarios, cada salto en contexto también aumenta el consumo efectivo de VRAM, porque la KV cache crece.

RAM del sistema y CPUs: más importantes de lo que parece

Cuando Ollama descarga capas al CPU, tu procesador se vuelve parte del motor de inferencia. En las pruebas con un i7-14700 (8P+12E) y 64 GB DDR5-6000:

Modelos con un 20-30% de capas en CPU siguen siendo usables (~30-50 tok/s).
Cuando el porcentaje de CPU sube del 50%, la experiencia de chat empieza a sentirse pesada, sobre todo si el contexto es grande.

Recomendaciones sensatas para un nodo de servicio:

RAM mínima 16 GB: solo para jugar con 7B y 13B ligeros.
RAM recomendada 32-64 GB: para uso serio multiusuario con modelos de 14-24B y contexto amplio.
CPU con al menos 8 núcleos (o combinación P+E moderna) para amortiguar la descarga de capas sin que el nodo se colapse, y también considerar cómo configurar perfiles de rendimiento en sistemas Windows si aplicara.

Disco: el elefante silencioso

Los ficheros de modelos pesan una barbaridad. La cuantización ayuda, pero aun así:

Modelos pequeños cuantizados: ~2 GB.
Modelos medianos cuantizados: 5-20 GB.
Modelos grandes: fácilmente 40-200 GB o más; hay checkpoints que sobrepasan 1 TB.

Como regla rápida, reserva siempre un margen de al menos 2-3 veces el tamaño de cada modelo entre fichero base, variantes, cachés y logs, y valora opciones de almacenamiento local frente a nube híbrida. Y usa SSD NVMe: los tiempos de carga y la paginación de mmap lo agradecen muchísimo.

Cuantización, contexto y elección de modelos: impacto directo en rendimiento

Aunque a veces se pasa por alto, la cuantización que elijas y la longitud de contexto marcan enorme diferencia en consumo de memoria y velocidad.

La “piedra rosetta” de la cuantización

De forma simplificada, puedes pensar en estas variantes:

FP16: modelo casi sin compresión, máxima calidad, tamaño brutal. Requiere mucha VRAM/RAM.
Q8_0: compresión suave, calidad casi idéntica a FP16, pero tamaño aún grande.
Q4_K_M: el estándar “equilibrado” para uso local. Reduce el tamaño a la mitad con solo ~1-2% de pérdida de precisión media. Es la opción recomendada para la mayoría de despliegues.
Q2_K: compresión extrema, tamaño mínimo, pero el modelo se vuelve claramente menos fiable, con más alucinaciones.

En la práctica, para un SaaS local con varios clientes, apostar por modelos Q4_K_M es la mejor relación calidad/rendimiento/consumo de VRAM. Q8_0 es útil si tienes mucha VRAM y quieres exprimir un poco más de calidad en un modelo pequeño/mediano.

Longitud de contexto (num_ctx) y su coste oculto

El parámetro num_ctx en Ollama/llama.cpp define cuántos tokens puede “ver” el modelo a la vez: sistema, historial de chat, prompt actual y respuesta. A nivel conceptual:

Ventanas pequeñas (2K-4K): menos memoria, más rapidez, pero pierdes contexto en conversaciones largas o documentos grandes.
Ventanas medianas (8K-32K): punto medio razonable para la mayoría de usos profesionales.
Ventanas gigantes (64K-128K+): espectaculares sobre el papel, pero consumen mucha más VRAM y empeoran el rendimiento si el hardware va justo.

Además, si forzas un num_ctx superior al contexto con el que el modelo fue entrenado, puedes encontrarte con comportamientos raros y bajadas de calidad. No basta con subir el valor en la configuración, hay un límite arquitectónico.

Para tu escenario, lo sensato es:

Ofrecer planes “normales” con contexto 8K-16K, que caben bien en VRAM.
Reservar contextos 64K-100K solo para máquinas o GPUs premium, y asumir la caída de tokens/s.

Buenas prácticas de rendimiento y gestión de memoria con Ollama

Más allá del hardware, hay varias decisiones de configuración y arquitectura que pueden marcar la diferencia a la hora de que tu clúster vaya fino.

Asegura que los modelos críticos estén 100% en GPU

Antes de dar un modelo a un cliente, conviene probarlo y comprobar con ollama ps que el campo PROCESSOR indica 100% GPU cuando está en uso. Si ves divisiones tipo 60/40 CPU/GPU o peores, toca:

Pasar a una cuantización más agresiva (por ejemplo de Q8_0 a Q4_K_M).
Usar un modelo más pequeño (por ejemplo 20B en vez de 35B).
Reducir num_ctx si el cliente puede vivir con un contexto algo menor.

Es preferible un 20B bien afinado a 140 tok/s que un 120B arrastrándose a 12 tok/s para chat interactivo. Los usuarios valoran mucho más la fluidez de la experiencia que una hipotética mejora de calidad difícil de percibir.

Ajusta OLLAMA_KEEP_ALIVE y la estrategia de modelos cargados

El parámetro OLLAMA_KEEP_ALIVE define cuánto tiempo mantiene Ollama un modelo en memoria tras la última petición. Valores posibles:

0: se descarga justo al terminar la respuesta. Ahorra memoria, pero penaliza con tiempos de carga constantes.
X m (p. ej. 5m, 15m): equilibra RAM/VRAM y agilidad. Ideal para servicios con picos puntuales.
-1: el modelo se queda siempre cargado mientras el servicio está activo. Muy útil para modelos “estrella” de tu SaaS.

En un escenario multiusuario, suele funcionar bien mantener uno o dos modelos base siempre cargados (por ejemplo, un 14B generalista y otro de código) y descargar el resto tras unos minutos de inactividad.

Control de variables de entorno y rutas de modelos

Ollama permite ajustar su comportamiento con varias variables de entorno que influyen en cómo se gestionan recursos y acceso:

OLLAMA_MODELS: ruta donde se almacenan los modelos. Interesante para enviarlos a un disco/SSD dedicado de mayor capacidad.
OLLAMA_HOST: interfaz y puerto del API (por defecto 127.0.0.1:11434). Si lo expones a LAN, limita bien el firewall.
OLLAMA_ORIGINS: CORS para GUIs web externas (Open WebUI, paneles propios, etc.).
OLLAMA_DEBUG: modo debug para ver logs detallados de carga de modelos, detección de GPU, errores de CUDA/ROCm, etc.

En Linux, estos parámetros se suelen configurar mediante systemd (con systemctl edit ollama.service), mientras que en Windows y macOS se establecen como variables de entorno del sistema o del usuario.

Monitorización y logs

En un clúster, necesitas tener claro qué pasa en cada nodo. Para ello:

En Linux, usa journalctl -u ollama para seguir los logs del servicio. Con -f lo ves en tiempo real.
Complementa con nvidia-smi o equivalente en AMD para ver VRAM, carga de GPU y consumo.
Integra métricas (tokens/s, colas, errores) en tu stack de observabilidad si vas en serio con el SaaS.

Detectar a tiempo que un modelo se está ejecutando mayoritariamente en CPU, o que se han quedado colas atascadas, te ahorra muchos disgustos con clientes; y herramientas para descubrir la IP en tu red local pueden ayudar al inventario de nodos.

Elección de modelos y casos de uso típicos en Ollama

Con todo lo anterior, la otra pata del rendimiento es elegir el modelo adecuado para cada tarea, no solo para “ir a tope” sino también para controlar consumo y latencia.

Modelos para chat general y asistentes

Para conversaciones, soporte, redacción de correos, resúmenes y tareas generales, modelos como:

Qwen3 14B: excelente seguimiento de instrucciones y buena velocidad en 100% GPU.
Mistral 3 14B: muy equilibrado en calidad de lenguaje y rendimiento.
Gemma y Llama 3.x en configuraciones de 7-14B: buenas opciones generalistas para usuarios menos exigentes o hardware más justo.

Con estas familias en Q4_K_M y contexto 8K-16K tienes una base sólida para la inmensa mayoría de usuarios profesionales sin saturar la VRAM.

Modelos para código y desarrollo

Para generación de código, revisión y tareas de desarrollo, conviene optar por modelos específicos:

qwen3-coder:30b: fuerte en programación y herramientas, aunque parte del modelo acaba en CPU en 16 GB VRAM.
DeepSeek-coder, CodeLlama y otras variantes de código para tamaños menores, si quieres más ligereza.

Si vas a ofrecer “planes de desarrollador”, plantéate un nodo con más de 16 GB de VRAM para alojar estos modelos sin sufrir demasiado la descarga a CPU.

Modelos multimodales y visión

Para tareas que combinan texto e imagen (análisis de capturas, documentos escaneados, etc.), los modelos con etiqueta Vision (llava, moondream, bakllava, qwen-vl…) son los que debes montar. Aquí:

El consumo de VRAM aumenta y la velocidad de tokens suele ser más baja.
Conviene limitarlos a tareas concretas y no mezclarlos con chat intensivo de muchos usuarios.

Si tienes un pool de GPU mixto (por ejemplo 5070 + 5060 + 4060, 48 GB VRAM total), puede ser interesante dedicar una de las tarjetas a modelos de visión y otra a texto puro, evitando saturar un único dispositivo con todo.

Instalación, despliegue y variantes de ejecución (nativo, Docker, contenedores)

A nivel operativo, Ollama se puede instalar de varias formas: nativo en Windows, macOS o Linux, o en contenedores (Podman, Docker…).

En Linux, por ejemplo, puedes desplegar llama.cpp en un contenedor optimizado con GPU:


Description=llama
After=network-online.target


Image=ghcr.io/ggml-org/llama.cpp:server-cuda
ContainerName=llama
PublishPort=8000:8000
AddDevice=nvidia.com/gpu=all
Environment=NVIDIA_DRIVER_CAPABILITIES=all
Environment=NVIDIA_VISIBLE_DEVICES=all

Exec=--host 0.0.0.0 \
     --port ${PORT} \
     -m ${MODEL_PATH} \
     -ngl ${NGL} \
     -c ${CONTEXT_SIZE} \
     --flash-attn on \
     --batch-size ${BATCH}

Volume=/data/models:/models:Z
Network=llama.network


Restart=always
Environment=PORT=8000
Environment=MODEL_PATH=/models/gemma-4-E4B-it-Q8_0.gguf
Environment=NGL=99
Environment=CONTEXT_SIZE=128000
Environment=BATCH=512


WantedBy=default.target

Este tipo de despliegue te permite separar Ollama, llama.cpp y otras herramientas en contenedores, controlar versiones y aislar recursos por servicio (y, si quieres, por cliente).

Para gestionar modelos de Hugging Face en GGUF o Safetensors, puedes usar herramientas como rust-hf-downloader y luego importarlos en Ollama mediante Modelfiles, donde defines FROM, TEMPLATE, parámetros por defecto y prompt system, además de mantener sincronización y backups locales de los artefactos si trabajas con varios nodos.

Una vez tienes las piezas montadas, el resto son decisiones de gobernanza: qué modelos ofreces a qué clientes, con qué límites de contexto y cuál es la política de actualizaciones y cuantizaciones para no romper compatibilidad ni rendimientos esperados.

Si tienes claro que la prioridad es que los modelos entren completos en VRAM, que la cuantización se mantenga en un equilibrio razonable (Q4_K_M) y que el contexto no se dispare más allá de lo que tu hardware puede soportar, montar un SaaS privado de Ollama sobre un clúster de tamaño medio deja de ser ciencia ficción y pasa a ser una inversión razonable: pagas GPU donde realmente aporta, cuidas la RAM para soportar descargas puntuales y usas las herramientas de orquestación (Ollama, llama.cpp, contenedores, Open WebUI) para dar a tus clientes la experiencia de “ChatGPT privado” pero con tus propias reglas y sin depender de la nube.