Cursos/MLOps local/VRAM y OOM

VRAM y OOM: vLLM vs Ollama/llama.cpp

La mayoría de setups locales no mueren porque el modelo “sea malo”: mueren porque no cabe, porque el contexto dispara la KV cache o porque usas un runtime pensado para concurrencia cuando solo necesitas estabilidad.

Objetivos de aprendizaje
  • Separar memoria de pesos, KV cache, contexto y batch.
  • Decidir cuándo usar vLLM, Ollama o llama.cpp.
  • Aplicar una ruta de fixes antes de comprar hardware.
En cristiano: OOM. Out of memory significa que el runtime necesita más memoria GPU de la disponible. Puede pasar aunque “el modelo pese menos que tu VRAM”, porque también cuentan contexto, KV cache, batch, fragmentación y overhead.

Regla rápida

  • Ollama: más simple y estable para uso personal, pruebas y baja concurrencia.
  • llama.cpp: mucho control, GGUF, CPU/GPU mixto y multi-GPU práctico.
  • vLLM: throughput y concurrencia cuando el modelo cabe con margen.
Idea clave. Si estás al límite de VRAM, vLLM suele ser menos indulgente que Ollama o llama.cpp. Si necesitas muchas peticiones concurrentes, vLLM empieza a tener sentido.
Terminal
# Observa GPU y memoria mientras pruebas
nvidia-smi -l 1

# Ollama: mira modelo, tamaño y contexto efectivo
ollama ps

# vLLM: empieza conservador
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.85

Ruta de fixes antes de rendirte

  1. Baja `max-model-len`: contexto largo consume mucha memoria.
  2. Prueba un quant más pequeño o un modelo menor.
  3. Reduce batch/concurrencia.
  4. Deja margen de VRAM: no apuntes a 99% de uso.
  5. Si necesitas estabilidad, prueba llama.cpp/Ollama antes de vLLM.
  6. Si necesitas concurrencia, usa vLLM pero con modelo que quepa holgado.
Terminal
# llama.cpp server con modelo GGUF
./llama-server \
  -m ./models/modelo-q4_k_m.gguf \
  --ctx-size 4096 \
  --n-gpu-layers 99 \
  --host 0.0.0.0 \
  --port 8080
Cuidado. La KV cache crece con el contexto y las sesiones activas. Un modelo que responde bien a 4k puede caerse a 16k, aunque los pesos sean los mismos.
Comprueba que funciona. Haz tres pruebas: 4k, 8k y 16k de contexto. Registra VRAM, tiempo al primer token, tokens/segundo y errores. Sin esa tabla, no sabes si tu cambio mejoró algo.
Guardar y reabrir el proyecto.
Elige runtime por carga real: Ollama para simplicidad, llama.cpp para control y vLLM para concurrencia. El peor setup es elegir vLLM “porque es rápido” y vivir en OOM.

Fuentes oficiales

← Mapa de servingllama.cpp server →