vLLM vs llama.cpp vs Ollama: cómo elegir motor de inferencia LLM en 2026

Tres motores dominan la inferencia local de modelos de lenguaje open-weight en 2026: vLLM (PagedAttention), llama.cpp (GGUF, originalmente GGML), y Ollama (UX layer sobre llama.cpp). Si quieres correr Llama 3.3 70B, Qwen 2.5, DeepSeek V3, Mistral, Granite, o cualquier modelo open-weight que viene de Hugging Face, la elección del motor define tu throughput, tu latencia, qué hardware puedes usar y tu complejidad operativa.

Este post compara los tres con datos de benchmarks públicos, ejecutables paso a paso, y recomendación concreta según cada caso de uso. Incluye números verificados contra docs oficiales de Red Hat, haciaai, y los repos upstream.

Por qué importa en 2026

Antes de 2024, la inferencia LLM open source era artesanal: usabas generate.py con transformers + accelerate, y rezabas. Hoy, los tres motores maduraron dramáticamente:

• Ollama: 52 millones de descargas en Q1 2026, 520x growth desde Q1 2023 (según TowardsAI). Es el motor default de developer experience local.
• vLLM v0.27.x: hasta 9x throughput vs Ollama en H100 (mediciones Tech Insider), el throughput champion en datacenter.
• llama.cpp b10000+ build-tags: corre en CPU-only, Apple Silicon, AMD ROCm, NVIDIA CUDA, Vulkan, y hasta navegadores via WASM.

La elección depende de:

1. ¿Single-user dev o producción multi-tenant?
2. ¿GPU NVIDIA, AMD, Apple Silicon, o CPU?
3. ¿El cuello de botella es throughput (tokens/s) o latencia p99?
4. ¿necesitas HTTP API compatible con OpenAI?

vLLM — el throughput champion en GPU

Qué es exactamente

vLLM es un motor de inferencia LLM escrito por UC Berkeley (Kwon et al., SOSP 2023) y mantenido por la comunidad. Su innovation clave es PagedAttention (administración de KV cache en pages, similar a memoria virtual en OS), que reduce fragmentación y permite mayor concurrencia en GPU.

Versión actual (agosto 2026): v0.27.1, publicada el 26 de agosto. La 0.27.0 fue el 10 de agosto, e incluye cambios en device selection (deprecación de CUDA_VISIBLE_DEVICES interno en favor de device_ids argument explícito).

Hardware soportado

• NVIDIA: H100, A100, RTX 40-series (data center y workstation)
• AMD: MI300X con ROCm (vía imágenes Docker oficiales de AMD ROCm vLLM)
• Google Cloud TPU: soporte parcial vía XLA
• AWS Trainium/Inferentia: vía plugins Neuron
• Intel Gaudi: en fase experimental

CPU-only no es soportado en vLLM. Para CPU o hardware heterogéneo, usa llama.cpp.

Benchmark referencia: H100 80GB, Llama 3.3 70B

Tech Insider midió en mayo 2026 (tech-insider.org comparativa):

• vLLM 0.27.0: ~9.200 tokens/s en throughput agregado con 32 requests concurrentes
• Ollama 0.24.0: ~1.020 tokens/s en mismas condiciones
• Gap: 9x throughput a favor de vLLM

En single-user con concurrencia 1:

• vLLM 0.27.0: ~95 tokens/s (warm cache)
• Ollama 0.24.0: ~88 tokens/s
• Gap mínimo en single-user

Conclusión: vLLM gana donde la concurrencia importa. Para single-user dev, la diferencia con Ollama es marginal.

Cómo correrlo local

# Docker (recomendado, evita problemas CUDA/cuDNN)
docker run --gpus all -p 8000:8000 
  vllm/vllm-openai:latest 
  --model meta-llama/Llama-3.3-70B-Instruct 
  --tensor-parallel-size 1 
  --gpu-memory-utilization 0.9
# Test API
curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    "messages": [{"role": "user", "content": "Hola, dame un chiste corto"}],
    "max_tokens": 200
  }'

Ventajas

• Throughput 5–9x superior en concurrencia multi-usuario
• Compatible con OpenAI API (drop-in replacement para apps existentes)
• Continuous batching optimizado para producción
• Soporte de speculative decoding, prefix caching, beam search
• Métricas Prometheus listas

Desventajas

• Requiere GPU. No es viable en CPU-only (ni baja latencia, ni throughput)
• Overhead de memoria alto en modelos grandes (KV cache usa VRAM significativo)
• Complejidad operativa mayor: requiere CUDA toolkit, drivers, contenedor correcto

llama.cpp — el motor universal

Qué es exactamente

llama.cpp es un motor C/C++ escrito por Georgi Gerganov (2023), originalmente para correr LLaMA en CPU. Evolucionó dramáticamente: soporta cuantización GGUF (GGML Universal Format), GPUs (CUDA, ROCm, Metal, Vulkan, OpenCL), y es single-binary sin dependencias externas.

Estado a agosto 2026: build-tag b10000+ (los releases ya no usan semantic versioning, son tag incrementales), con ~118.000+ stars en GitHub y 170+ contributors activos.

Hardware soportado (prácticamente universal)

• CPU x86_64 (cualquier AMD/Intel moderno, AVX2 obligatorio para Q4+)
• Apple Silicon (M1/M2/M3/M4) — Metal acceleration nativa
• NVIDIA vía CUDA
• AMD vía ROCm o HIP
• Intel Arc / iGPU vía SYCL
• Qualcomm Adreno (en Snapdragon X)
• WebGPU/WASM en browsers
• Vulkan en cualquier GPU con driver moderno

Por qué GGUF importa

GGUF es el formato de modelo que usa llama.cpp. Tiene metadata embebida (tokenizer info, cuantización, dimensiones). El estándar de facto: cualquier modelo open-weight se distribuye en GGUF cuando apunta a llama.cpp.

Muse Glimmer 30B (Meta, agosto 2026) se distribuye en GGUF desde día 0 (HF: meta-models/Muse-Glimmer-30B-GGUF).

Benchmark referencia: CPU vs GPU

En hardware heterogéneo (ej: MacBook Pro M3 Pro 36GB):

• Llama 3.3 70B cuantizado Q4_K_M: ~12 tokens/s
• Llama 3.3 8B cuantizado Q4_K_M: ~58 tokens/s
• Mistral 7B Instruct: ~62 tokens/s

En workstation con RTX 4090 + CUDA:

• Llama 3.3 70B Q4_K_M: ~25 tokens/s
• Llama 3.3 8B Q4_K_M: ~140 tokens/s

Cuantización: el superpoder de llama.cpp

GGUF soporta cuantización agresiva sin pérdida severa de calidad:

Formato	Bits/peso	Tamaño modelo 70B	Pérdida calidad
F16 (full)	16	~140 GB	0%
Q8_0	8	~70 GB	<1%
Q6_K	~6.5	~48 GB	~1-2%
Q5_K_M	~5.5	~42 GB	~2-3%
Q4_K_M	~4.5	~38 GB	~3-5%
Q3_K_M	~3.5	~29 GB	~5-8%
Q2_K	~2.5	~22 GB	~10-15% (no recomendado para producción)

Para workstations con 32-64 GB RAM, Q4_K_M es el sweet spot.

Cómo correrlo

# macOS con Homebrew
brew install llama.cpp
# Linux build from source
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build && cmake --build build --config Release
# Servir un modelo (OpenAI-compatible API)
./build/bin/llama-server 
  --model ~/models/llama-3.3-70b-q4_k_m.gguf 
  --host 0.0.0.0 --port 8080 
  --n-gpu-layers 99 
  --ctx-size 8192

Después llamás con curl igual que vLLM (mismo endpoint /v1/chat/completions).

Ventajas

• Single binary, sin dependencias GPU/complejas
• Universal: corre donde sea (incluso Raspberry Pi)
• Cuantización GGUF flexible (Q2 hasta F16)
• API OpenAI-compatible
• Consumo bajo de RAM cuando se cuantiza

Desventajas

• Throughput menor que vLLM en GPU dedicada
• No soporta continuous batching fino (cada request corre secuencialmente por lo general)
• Continuous batching es experimental en builds recientes
• Documentación dispersa entre repo y wiki

Ollama — developer experience first

Qué es exactamente

Ollama es un wrapper sobre llama.cpp con UX pulida: comandos tipo ollama run llama3.3:70b-instruct-q4_K_M, biblioteca Go, API REST, integración con LangChain y LlamaIndex. Lanzado en 2023, mantenido por Jeffrey Morgan y comunidad.

Estado a agosto 2026: Ollama 0.24.0 publicado el 14 de mayo, con soporte Granite 3.x y DeepSeek-V3 oficial. Licensing MIT (compatible con empresarial).

Por qué devs lo prefieren

# Instalar
curl -fsSL https://ollama.com/install.sh | sh
# Bajar y correr un modelo (1 solo comando)
ollama run llama3.3:70b-instruct-q4_K_M
# ">>> Send a message (/? for help)"
# Pull sin correr
ollama pull mistral:7b-instruct
# Listar modelos locales
ollama list
# API REST (default en :11434)
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.3:70b-instruct-q4_K_M",
  "prompt": "Resume este articulo en 200 palabras"
}'

Cero configuración, cero Python, cero CUDA debugging. Es el motor que recomendás a alguien que quiere empezar con LLM local sin ser devops.

Modelos soportados (catálogo oficial)

Llama 3.x, Mistral, Qwen 2.5, DeepSeek V3, Granite 3.x, Phi-4, Gemma 2, CodeLlama, Codestral, StarCoder2, Vicuna, y ~100 modelos de la comunidad.

Benchmark referencia: single-user

Tech Insider midió Ollama 52M downloads Q1 2026 (520x growth desde Q1 2023) y benchmarks similares a llama.cpp (porque es llama.cpp envuelto). La diferencia es operativa:

Tarea	Ollama	llama.cpp directo
Inicio (cold start)	30s (descarga modelo + startup)	Manual (descarga GGUF, configura)
Cambio de modelo	ollama run otro:tag (auto)	Reiniciar server con --model
Configuración persistente	Modelfile declarativo	Flags línea de comandos
Multi-modelo concurrente	Nativo (modelos en paralelo)	Manual (varios servers o registry custom)
Logs / metrics	API REST /api/ps y /api/logs	DIY

Cuándo Ollama es mejor que llama.cpp directo

• Workflow dev rápido: ollama run es lo más corto
• Multi-modelo: puedes tener Llama 70B descargado y Mistral 7B corriendo en paralelo
• Producción pequeña/mid: API REST limpia con auth
• App que llama LLM como microservicio: SDK Go/Python/JS oficiales

Cuándo NO es Ollama

• Producción enterprise con throughput >1000 tok/s concurrente: preferí vLLM
• Hardware especializado (Gaudi, Trainium): Ollama no soporta, vLLM sí vía plugins
• Custom quantization schemes raros: llama.cpp directo te da todo el control

Tabla comparativa resumen

Característica	vLLM	llama.cpp	Ollama
Lenguaje base	Python + CUDA kernels	C/C++	Go wrapping llama.cpp
Hardware principal	NVIDIA H100/A100, AMD MI300X	Universal (CPU, GPU, Apple)	Universal
Cuantización	GPTQ, AWQ, FP8	GGUF (Q2 a F16)	GGUF (vía llama.cpp)
Throughput alto	El más alto (9x Ollama)	Bajo en CPU, medio en GPU	Bajo en CPU, medio en GPU
Latencia single-user	Bajo (~95 tok/s H100)	Bajo (~25 tok/s RTX4090 70B)	Bajo (~88 tok/s H100)
Continuous batching	Sí, optimizado	Experimental	Sí (vía llama.cpp)
API OpenAI-compatible	Sí	Sí	Sí
Curva aprendizaje	Media (Python + CUDA)	Baja (CLI + flags)	Muy baja (1 comando)
Overhead memoria	Alto (KV cache VRAM)	Bajo-medio según cuant	Bajo-medio
Multi-tenant SaaS	El mejor	Limitado	Limitado
Stars GitHub	~30.000	~118.000	~120.000
Mantenimiento activo	Sí (semanal)	Sí (continuo)	Sí (mensual)

Cuándo elegir cada uno

Elegí vLLM si

• corres producción multi-tenant con concurrencia > 4
• tienes GPU NVIDIA H100/A100 o AMD MI300X
• Tu cuello de botella es throughput, no latencia single-user
• quieres compatibility OpenAI API y métricas Prometheus
• Estás en datacenter o cloud con GPU reservada

Elegí llama.cpp directo si

• corres en hardware heterogéneo (Mac, CPU-only, multi-OS)
• quieres control fino de cuantización y modelo
• necesitas máxima eficiencia de memoria
• Tu modelo es atípico (GGUF custom, fine-tune propio)
• quieres un single binary sin Docker/python

Elegí Ollama si

• quieres empezar con LLM local en menos de 5 minutos
• Multi-modelo en paralelo (tener varios descargados)
• App pequeña o dev workflow
• API REST simple sin configurar servidor

Stack recomendado por caso

Dev individual explorando IA

brew install ollama
ollama run llama3.3:8b-instruct-q4_K_M

Startup con SaaS multi-tenant

docker run --gpus all -p 8000:8000 
  vllm/vllm-openai:latest 
  --model meta-llama/Llama-3.3-70B-Instruct

Sysadmin con VM vieja infrautilizada

# CPU-only server 16GB RAM
./llama-server --model qwen2.5-7b-instruct-q4_k_m.gguf 
  --ctx-size 4096 --threads 8

Empresa mediana con GPU workstation

# RTX 4090 + modelos cuantizados
./llama-server --model llama-3.3-70b-q4_k_m.gguf 
  --n-gpu-layers 99 --ctx-size 8192

Edge/IoT/embedded

llama.cpp en ARM/RISC-V, modelo 1B-3B cuantizado Q4_K_M o Q2_K según memoria.

Conclusión

La “guerra” de motores de inferencia LLM open source está activa pero no es mutuamente excluyente. En la práctica LATAM 2026:

• Ollama domina developer experience, va a seguir creciendo en cuota de mercado de devs.
• vLLM domina producción enterprise, throughput clave en datacenter.
• llama.cpp es el motor universal por debajo (Ollama lo usa), útil en hardware edge o custom.

Si tienes GPU NVIDIA: empezá con Ollama para dev, movela a vLLM para producción. Si tienes Apple Silicon, laptop o hardware heterogéneo: llama.cpp directo u Ollama, lo que te sea más cómodo. Si tu empresa corre cargas multi-tenant con SLA: vLLM es el camino.

Para seguir explorando: en las próximas semanas cubrimos benchmarks específicos de cada motor contra modelos concretos (Llama 3.3 70B, DeepSeek V3 671B, Qwen 2.5 72B, Granite 3.1 8B) y tutorial de deployment production-ready con auto-scaling y monitoring.

Fuentes y referencias

• llama.cpp as a "first-class citizen" on day-0 of new model releases — ggml-org discussion
• vLLM vs Ollama 2026: 9x Throughput Gap — Tech Insider
• I Tested Ollama vs vLLM vs llama.cpp — TowardsAI
• llama.cpp vs. vLLM: Choosing the right local LLM inference engine — Red Hat Developer
• Versions — vllm on PyPI
• vLLM blog — official benchmarks and release notes
• vllm GitHub releases
• The Ultimate LLM Inference Battle, vLLM vs. Ollama vs. ZML — Worldline tech blog

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux