Programación GPU y gestión de recursos en Ollama: optimización de VRAM y balanceo multi-GPU

Con una GPU de 8 GB de VRAM, por fin logras cargar un modelo 13B y, tras unas pocas inferencias, todo se cae: en pantalla aparece el error «CUDA out of memory».

O inviertes en dos GPU pensando que por fin podrás ejecutar modelos grandes, abres nvidia-smi y solo una tarjeta trabaja mientras la otra está de brazos cruzados.

Al empezar con Ollama caí en estas trampas: VRAM insuficiente, multi-GPU que no servía de nada, velocidad de inferencia que iba y venía. Con el tiempo entendí la lógica de programación GPU de Ollama: muchas cosas no bastan con «configurar y listo»; hay que entender qué hace cada parámetro.

En este artículo reúno esa experiencia para resolver problemas concretos:

• Cómo ejecutar un 13B de forma estable con 8 GB de VRAM (sin OOM inesperado)
• Cómo configurar multi-GPU para que de verdad se use (esquema completo de balanceo)
• Qué parámetros tocar cuando falta VRAM (orden de prioridad)
• Qué es GPU offloading (mecanismo interno de llama.cpp)

Un aviso: el artículo es algo denso; conviene tener nociones de GPU, CUDA y operación básica de Ollama. Si acabas de empezar, mira antes los artículos previos de la serie (sobre todo el sexto sobre optimización de rendimiento); con ese contexto leerás esto con mucha más fluidez.

1. Gestión de memoria GPU: configuración de parámetros al detalle

La programación GPU de Ollama se controla con varios parámetros que reparten capas del modelo entre GPU y CPU. Entenderlos explica por qué a veces falla el OOM aunque «parezca» que hay VRAM suficiente, o por qué la inferencia se vuelve inexplicablemente lenta.

1.1 Parámetros clave

Estos son los más importantes, resumidos en una tabla de referencia:

Parámetro	Función	Valor por defecto	Cuándo ajustarlo
num_gpu	Cuántas capas del modelo se ejecutan en GPU	Detección automática	Redúcelo si falta VRAM
main_gpu	Índice de la GPU principal	0	En multi-GPU, elige qué tarjeta usar
low_vram	Modo de poca VRAM	false	Recomendado con menos de 8 GB
num_batch	Tamaño del batch	512	Baja a 256 si la VRAM aprieta
num_ctx	Longitud del contexto	4096	ctx=2048 en conversaciones cortas ahorra mucha VRAM

El que más confunde suele ser num_gpu: no indica cuántas GPU tienes, sino cuántas capas del modelo se calculan en GPU.

Ejemplo: Llama 2 7B tiene 32 capas. Con num_gpu: 32, las 32 van a GPU. Si falta VRAM y pones num_gpu: 20, 20 capas en GPU y 12 en CPU: la velocidad baja.

low_vram es interesante: al activarlo, Ollama aplica trucos para ahorrar VRAM, por ejemplo mover el KV cache a RAM en lugar de VRAM. Pierdes algo de velocidad, pero evitas el crash.

1.2 Flujo de asignación de VRAM

Al cargar un modelo, Ollama reparte la VRAM así:

1. Detectar VRAM: mira cuánta VRAM libre hay en la GPU
2. Calcular capas: según tamaño del modelo y VRAM, decide cuántas capas caben en GPU
3. Reservar KV cache: deja espacio para la caché de inferencia (también consume VRAM)
4. Inferir: el uso de VRAM varía durante la ejecución

El punto crítico es el paso 2: Ollama calcula automáticamente la mejor repartición. A veces falla cuando la VRAM está justo (8 GB con un 13B); ahí conviene fijar num_gpu a mano.

¿Quieres saber cuántas capas van a GPU? Usa:

ollama run llama3 --verbose

En la salida verás algo como llama_model_load: model loaded - layers: 40/40 on GPU: las 40 capas están en GPU.

1.3 Motor llama.cpp

Ollama usa llama.cpp como motor de inferencia. Entender su lógica de GPU offloading explica por qué a veces cambiar parámetros apenas mueve la aguja.

Decisión de GPU offloading

llama.cpp calcula así:

VRAM disponible = VRAM total GPU - reserva del sistema (unos cientos de MB)
Tamaño por capa = parámetros del modelo / número de capas
Capas en GPU = min(total capas, VRAM disponible / tamaño por capa)

Hay un truco: solo cuenta la VRAM del modelo, no el KV cache. Ese cache crece con la conversación. Por eso el modelo carga bien y, tras varias inferencias, el KV cache llena la VRAM y todo revienta.

Arquitectura híbrida

GPU y CPU no se reparten el trabajo de forma rígida. En la práctica:

• GPU: multiplicaciones de matrices, operaciones attention (carga computacional alta)
• CPU: embedding, normalización (carga baja)
• Transferencia de datos: ida y vuelta GPU-CPU con overhead

Si solo parte de las capas va a GPU, cada capa calculada en un dispositivo distinto obliga a pasar resultados al siguiente: el offloading parcial se vuelve notablemente más lento.

Mapeo de memoria mmap

llama.cpp carga el modelo con mmap por defecto. Ventajas:

• No lee todo el modelo a memoria; el SO carga bajo demanda
• Varios procesos pueden compartir la misma memoria
• Menor huella de RAM

Para desactivar mmap (en algunos casos da problemas), en el Modelfile:

PARAMETER use_mmap false

2. Configuración multi-GPU: arquitectura completa de balanceo

Con dos o más GPU, la pregunta habitual es: ¿cómo hace Ollama para usarlas todas?

Primero, la mala noticia: Ollama no admite paralelismo de modelo. No puedes partir un modelo a medias entre GPU 0 y GPU 1. Cada instancia de modelo va ligada a una sola GPU.

¿Para qué sirve entonces el multi-GPU? Dos usos:

1. Instancias con modelos distintos: GPU 0 con llama3, GPU 1 con mistral
2. Varias instancias del mismo modelo: balanceo de carga y más throughput

2.1 Una instancia, varias GPU (límites y configuración)

Para que Ollama vea varias GPU, lo más simple es CUDA_VISIBLE_DEVICES:

# Solo GPU 0 y GPU 1
CUDA_VISIBLE_DEVICES=0,1 ollama serve

Problema: por defecto Ollama pone el modelo en GPU 0 y GPU 1 sigue ociosa. Puedes fijar la GPU principal con main_gpu:

# Modelfile
FROM llama3
PARAMETER main_gpu 1  # GPU principal = GPU 1

En la práctica, esto ayuda poco: solo cambias de tarjeta, no aprovechas las dos a la vez.

2.2 Balanceo con varias instancias (recomendado)

Lo que de verdad exprime multi-GPU es levantar varias instancias de Ollama, una por GPU, y repartir peticiones con un balanceador.

Arquitectura:

┌─────────┐
│ Client  │  Envía peticiones de inferencia
└────┬────┘
     │
┌────▼────────────────────┐
│ Nginx (balanceador)      │  Estrategia least_conn
│ Port: 8080              │
└────┬─────────┬──────────┘
     │         │
┌────▼───┐ ┌──▼────┐
│Ollama 1│ │Ollama 2│
│GPU 0   │ │GPU 1   │  Cada instancia con una GPU
│Port    │ │Port    │
│11434   │ │11435   │
└────────┘ └────────┘

Paso 1: levantar varias instancias

# Instancia 1 - GPU 0, puerto 11434
CUDA_VISIBLE_DEVICES=0 OLLAMA_HOST=127.0.0.1:11434 ollama serve &

# Instancia 2 - GPU 1, puerto 11435
CUDA_VISIBLE_DEVICES=1 OLLAMA_HOST=127.0.0.1:11435 ollama serve &

Nota: el directorio de datos por defecto es ~/.ollama; ambas instancias comparten almacenamiento de modelos. No hay problema: mmap permite compartir el mismo archivo entre procesos.

Paso 2: Nginx como balanceador

# /etc/nginx/conf.d/ollama.conf
upstream ollama_cluster {
    least_conn;  # Menos conexiones primero
    server 127.0.0.1:11434;
    server 127.0.0.1:11435;
}

server {
    listen 8080;

    location / {
        proxy_pass http://ollama_cluster;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Respuesta en streaming
        proxy_buffering off;
        proxy_cache off;
    }
}

least_conn envía cada petición nueva a la instancia con menos conexiones activas. Así repartes carga entre las dos GPU.

Paso 3: cliente

El cliente solo apunta al puerto de Nginx:

# Llamada vía Nginx (reparto automático)
curl http://localhost:8080/api/generate -d '{
  "model": "llama3",
  "prompt": "Hola"
}'

O cambia la dirección por defecto del cliente Ollama:

export OLLAMA_HOST=http://localhost:8080
ollama run llama3

2.3 Comparativa de estrategias de balanceo

Nginx ofrece varias estrategias, cada una con su caso:

Estrategia	Principio	Cuándo usarla
Round-robin (por defecto)	Reparto secuencial	Escenarios simples, modelos del mismo tamaño
least_conn	A la instancia más libre	Recomendada para inferencia
IP Hash	Misma IP → misma instancia	Cuando necesitas afinidad de sesión

En inferencia, la duración de cada petición varía: unas segundos, otras minutos. Con round-robin puedes saturar una instancia y dejar la otra ociosa. least_conn evita eso.

Para reparto más uniforme y conmutación si una instancia cae, añade health check:

upstream ollama_cluster {
    least_conn;
    server 127.0.0.1:11434 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:11435 max_fails=3 fail_timeout=30s;
}

Tras 3 fallos seguidos, Nginx saca temporalmente esa instancia del cluster e intenta de nuevo a los 30 segundos.

3. Optimización de VRAM: cuantización, contexto y batch en la práctica

Cuando falta VRAM, el orden de ajuste es: cuantización > longitud de contexto > tamaño de batch > capas GPU.

¿Por qué? La cuantización impacta más: el mismo modelo en Q4 usa ~25 % de la VRAM de FP16. Cambiar capas GPU mueve cálculo a CPU: ahorras VRAM pero pierdes velocidad.

3.1 Nivel de cuantización

Cuantizar = guardar parámetros con menos bits. FP16 usa 16 bits por parámetro; Q4, 4. Pierdes algo de precisión, pero en pruebas Q4 suele costar un 2-3 % de calidad, aceptable en la mayoría de casos.

Comparativa de niveles:

Cuantización	VRAM (vs FP16)	Pérdida de precisión	Escenario
Q4_K_M	~25 %	2-3 %	Recomendado: equilibrio rendimiento/calidad
Q5_K_M	~33 %	1-2 %	Cuando pides un poco más de precisión
Q8_0	~50 %	0,5 %	Casi precisión original
FP16	100 %	Ninguna	Investigación, benchmarks

Referencia: Llama 2 13B

• FP16: ~26 GB VRAM
• Q4_K_M: ~8 GB VRAM
• Q8_0: ~13 GB VRAM

Con 8 GB, un 13B Q4 entra justo; el KV cache suma y en inferencia es fácil quedarse sin margen.

Consejo: uso diario, Q4_K_M basta. Traducción o generación de código exigente: Q5_K_M o Q8_0.

Ollama descarga Q4 por defecto. Otras cuantizaciones, sufijo en el nombre:

# Q4 (por defecto)
ollama pull llama3

# Q8
ollama pull llama3:8b-q8_0

3.2 Optimizar la longitud de contexto

El KV cache guarda el historial de conversación. Su VRAM escala con la longitud del contexto.

Fórmula aproximada:

VRAM KV cache ≈ num_ctx × num_layers × hidden_dim × 2 bytes

Ejemplo Llama 2 7B:

• num_layers = 32
• hidden_dim = 4096
• num_ctx = 4096

El KV cache ronda ~2 GB. Con ctx=8192, ~4 GB. Duplicas ctx, duplicas KV cache.

Estrategias:

1. Conversaciones cortas: num_ctx: 2048

   • Ahorras la mitad de VRAM de KV cache
   • Suficiente para Q&A y tareas simples

2. Documentos largos: no subas ctx a 16000 de golpe; usa chunking

   • Trocea el documento y procesa por partes
   • Más estable y controlable

En Modelfile:

FROM llama3
PARAMETER num_ctx 2048  # Menor longitud de contexto

Un mito: muchos creen que ctx bajo empeora la salida. No es así: ctx solo limita cuánto historial «recuerda» el modelo. Si la conversación ya es corta, ctx=2048 y ctx=4096 se comportan igual.

3.3 Batch y concurrencia

num_batch fija cuántos tokens se procesan a la vez. Por defecto 512.

Batch grande: mejor paralelismo, pero pico de VRAM más alto.

Con VRAM justa, bajar batch alivia picos:

FROM llama3
PARAMETER num_batch 256  # De 512 a 256

En pruebas, batch 512→256 baja el pico ~20 %. Pierdes algo de velocidad, menos que al recortar capas GPU.

Concurrencia

Ollama procesa peticiones en serie por defecto. Varias peticiones simultáneas hacen cola.

Para más concurrencia:

1. Varias instancias: el esquema multi-GPU + Nginx de arriba
2. Cola en aplicación: Redis Queue u otro, repartiendo tú las peticiones

La segunda encaja mejor sin multi-GPU. En código:

import redis
from queue import Queue

# Cola con Redis
r = redis.Redis()
r.lpush('ollama_queue', request_data)

# Worker en segundo plano
request = r.rpop('ollama_queue')
ollama.generate(request)

4. Casos prácticos: tres escenarios reales

Después de la teoría, tres problemas y cómo los resolvimos.

4.1 Escenario 1: 13B estable con 8 GB de VRAM

Problema

RTX 3060 (8 GB), Llama 2 13B Q4: el modelo ~8 GB, entra justo. Tras unas inferencias, OOM: el KV cache llena la VRAM.

Solución

Idea: menos KV cache + menor pico de VRAM.

FROM llama2:13b-q4

PARAMETER num_gpu 30      # 13B tiene 40 capas; solo 30 en GPU
PARAMETER low_vram true   # KV cache en RAM
PARAMETER num_ctx 2048    # Mitad de contexto → mitad de KV cache
PARAMETER num_batch 256   # Batch menor, pico más bajo

Combinados, el uso se estabiliza ~6 GB, ~2 GB de margen.

Resultado

• VRAM: de ~8 GB a ~6 GB estable
• Velocidad: ~8 tokens/s (más lento que todo en GPU, mucho más que solo CPU)
• Estabilidad: sin OOM

Pagas velocidad: 10 capas en CPU y transferencias GPU-CPU. Pero el modelo corre sin caerse a la primera.

4.2 Escenario 2: balanceo dual-GPU y más throughput

Problema

Dos RTX 3090 (24 GB cada una), API Ollama pública. Una instancia serializa peticiones; en picos, cola larga.

nvidia-smi: una GPU ~70 %+, la otra ~20 %.

Solución

Varias instancias + Nginx (capítulo 2). Script de arranque:

#!/bin/bash
# start_ollama_cluster.sh

# Instancia 1 - GPU 0
CUDA_VISIBLE_DEVICES=0 \
OLLAMA_HOST=127.0.0.1:11434 \
OLLAMA_MODELS=/home/user/.ollama \
nohup ollama serve > ollama1.log 2>&1 &

# Instancia 2 - GPU 1
CUDA_VISIBLE_DEVICES=1 \
OLLAMA_HOST=127.0.0.1:11435 \
OLLAMA_MODELS=/home/user/.ollama \
nohup ollama serve > ollama2.log 2>&1 &

# Precargar modelo en ambas instancias
sleep 5
curl http://127.0.0.1:11434/api/pull -d '{"name": "llama3"}'
curl http://127.0.0.1:11435/api/pull -d '{"name": "llama3"}'

echo "Cluster Ollama iniciado en puertos 11434 y 11435"

Nginx con least_conn para reparto uniforme.

Resultado

• Throughput global: ~+80 % (serial → dos instancias en paralelo)
• Uso medio por GPU: de ~40 % a ~80 % (ambas trabajando)
• Latencia en picos: ~-50 % (menos cola)

En prueba: 100 peticiones, una instancia ~10 min; con balanceo dual, poco más de 5 min.

4.3 Escenario 3: asignación dinámica de VRAM

Problema

Varios modelos de distinto tamaño; al cambiar hay que retocar capas GPU a mano. Olvidas un ajuste y crashea. ¿Automatizar?

Solución

Script que elige Modelfile según VRAM libre:

#!/bin/bash
# auto_offload.sh - Configuración automática de GPU offloading

# VRAM libre actual (MB)
GPU_MEM_FREE=$(nvidia-smi --query-gpu=memory.free --format=csv,noheader,nounits | head -1)

# Tamaños de referencia (MB)
declare -A MODEL_SIZES
MODEL_SIZES["llama3:8b-q4"]=5000
MODEL_SIZES["llama3:70b-q4"]=40000
MODEL_SIZES["mistral:7b-q4"]=4500

MODEL_NAME=$1

if [ -z "$MODEL_NAME" ]; then
    echo "Uso: $0 <model_name>"
    exit 1
fi

MODEL_SIZE=${MODEL_SIZES[$MODEL_NAME]}

if [ -z "$MODEL_SIZE" ]; then
    echo "Tamaño desconocido para $MODEL_NAME"
    exit 1
fi

# ¿Cabe todo en GPU?
if [ $GPU_MEM_FREE -gt $MODEL_SIZE ]; then
    # Offloading completo a GPU
    echo "Offloading completo a GPU (VRAM suficiente)"
    cat > /tmp/modelfile_temp <<EOF
FROM $MODEL_NAME
PARAMETER num_gpu -1  # -1 = toda la GPU
PARAMETER low_vram false
EOF
else
    # GPU parcial según ratio
    OFFLOAD_RATIO=$((GPU_MEM_FREE * 100 / MODEL_SIZE))
    echo "Offloading parcial a GPU ($OFFLOAD_RATIO%)"
    cat > /tmp/modelfile_temp <<EOF
FROM $MODEL_NAME
PARAMETER num_gpu $OFFLOAD_RATIO
PARAMETER low_vram true
PARAMETER num_ctx 2048
EOF
fi

# Crear modelo
ollama create "${MODEL_NAME}-auto" -f /tmp/modelfile_temp
echo "Creado ${MODEL_NAME}-auto con configuración automática"

Uso:

# Crea modelo con configuración adaptada
./auto_offload.sh llama3:70b-q4

Resultado

• Se adapta a cambios de VRAM
• Menos errores de configuración manual
• Cambiar de modelo sin retocar parámetros cada vez

Puedes extenderlo: monitor que baje a low_vram si falta memoria, o precarga nocturna con cron.

5. Buenas prácticas y monitorización

5.1 Configuración recomendada por VRAM

Tabla rápida según tu hardware:

VRAM	Modelo recomendado	Cuantización	Capas GPU	Otros parámetros
6 GB	7B	Q4	Parcial (~50 %)	low_vram=true, ctx=2048
8 GB	7B	Q4	GPU completa	ctx=2048 (prudente)
8 GB	13B	Q4	Parcial (~75 %)	low_vram=true, ctx=2048, batch=256
12 GB	13B	Q4	GPU completa	ctx=4096 viable
16 GB	13B	Q8 o Q5	GPU completa	ctx=4096
16 GB	70B	Q4	Parcial (~50 %)	low_vram=true
24 GB	70B	Q4	GPU completa	ctx=4096 viable
48 GB (dual)	70B	Q4	GPU completa	Varias instancias + balanceo

Son estimaciones conservadoras. KV cache y reserva del sistema también cuentan. Conversaciones largas: mejor ir con margen.

5.2 Herramientas de monitorización

nvidia-smi en tiempo real

# Actualizar cada segundo
nvidia-smi -l 1

# Solo uso de VRAM
nvidia-smi --query-gpu=memory.used,memory.free --format=csv -l 1

Durante inferencia ves cómo sube la VRAM.

Logs verbose de Ollama

ollama run llama3 --verbose

Incluye:

• Capas en GPU offloading
• Memoria del modelo
• Si mmap está activo
• Asignación de KV cache

GPU offloading: 40/40 layers = todo en GPU.

Script de monitorización

#!/bin/bash
# monitor_gpu.sh

LOG_FILE="gpu_memory.log"

while true; do
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    GPU_MEM=$(nvidia-smi --query-gpu=memory.used,memory.free --format=csv,noheader)
    echo "$TIMESTAMP $GPU_MEM" >> $LOG_FILE
    sleep 5
done

En segundo plano, histórico cuando lo necesites.

5.3 Problemas frecuentes

Problema 1: OOM en inferencia

Pasos:

1. nvidia-smi: confirma que falta VRAM
2. Revisa configuración:
   • ¿Cuantización Q4?
   • ¿ctx demasiado grande? (prueba 2048)
   • ¿batch alto? (prueba 256)
   • ¿Todas las capas en GPU? (reduce capas)
3. Si sigue fallando: low_vram=true

Prioridad: cuantización > ctx > batch > capas GPU > low_vram

Problema 2: inferencia lenta

Comprueba capas en GPU:

ollama run your_model --verbose | grep "GPU offloading"

GPU offloading: 20/40 layers = mitad en CPU; lentitud esperada.

Solución: cuantización más ligera (Q4→Q8) o más VRAM. Si no, acepta la velocidad.

Problema 3: VRAM inestable

Suele ser KV cache creciendo con la conversación.

Solución: limita ctx o recorta historial en la app (p. ej. últimas 10 vueltas).

Problema 4: multi-GPU pero solo una tarjeta activa

Comprueba Nginx:

curl http://localhost:8080/api/tags

Si responde, el reparto funciona.

Si una GPU sigue mucho más cargada:

• ¿Falta least_conn?
• ¿Instancia caída? (revisa logs)
• ¿Modelo cargado solo en una instancia?

Resumen

En pocas ideas:

1. Falta VRAM → cuantización primero: Q4 ahorra ~75 % vs FP16 con poca pérdida
2. Cuidado con KV cache: ctx largo = más presión de VRAM
3. Multi-GPU = balanceo: instancia única multi-GPU ayuda poco; varias instancias + Nginx
4. Entiende llama.cpp: offloading es cálculo por capas, con coste de transferencia

Configuraciones listas para copiar:

Estable con 8 GB:

PARAMETER num_gpu 30
PARAMETER low_vram true
PARAMETER num_ctx 2048
PARAMETER num_batch 256

Arranque balanceo dual-GPU:

CUDA_VISIBLE_DEVICES=0 OLLAMA_HOST=127.0.0.1:11434 ollama serve &
CUDA_VISIBLE_DEVICES=1 OLLAMA_HOST=127.0.0.1:11435 ollama serve &

Si te sirvió, mira el resto de la serie: el sexto artículo cubre cuantización y batch; este profundiza en GPU; el octavo trata despliegue multi-modelo con escenarios más complejos.

Dudas: Ollama GitHub Discussions tiene muchos casos reales. O comenta abajo; si lo veo, respondo.

---