vLLM vs Ollama (2026): Servidores LLM Locales, PagedAttention y Costos de GPU Cloud

1. Arquitecturas Fundamentales: PagedAttention vs el Runtime de llama.cpp

La disparidad de rendimiento entre vLLM y Ollama no responde a simples trucos de optimización de código; proviene de filosofías de ingeniería contrapuestas respecto a la gestión de memoria de video, la planificación de lotes (batch scheduling) y el tratamiento de la caché de claves y valores (KV Cache) del Transformer.

vLLM: Virtualización de Memoria Mediante PagedAttention

Durante la generación autorregresiva de texto, cada nuevo token debe atender a todos los tokens precedentes dentro de la ventana de contexto. Para evitar calcular reiteradamente los vectores de clave y valor en cada capa, los pesos calculados se retienen en la memoria VRAM de la GPU: esto constituye el KV Cache. En los motores de inferencia convencionales, este espacio se asigna de forma estática y contigua con base en la longitud máxima de secuencia configurada (por ejemplo, 8,192 o 128,000 tokens). Debido a que las peticiones reales presentan longitudes variables y desconocidas a priori, esta asignación contigua ocasiona dos graves problemas:

• Fragmentación Interna: La memoria VRAM reservada para el tamaño máximo de respuesta queda completamente vacía y bloqueada si la generación concluye tempranamente.
• Fragmentación Externa: Los allocators de memoria dejan espacios dispersos que no alcanzan a albergar nuevas solicitudes entrantes, desperdiciando valiosa memoria física.

Estudios académicos de la Universidad de California en Berkeley demostraron que los motores tradicionales desperdician entre un 60% y un 80% de la VRAM total exclusivamente por fragmentación del KV Cache. Para erradicar este cuello de botella, los creadores de vLLM diseñaron PagedAttention.

Inspirado en el mecanismo clásico de memoria virtual por páginas de los sistemas operativos, PagedAttention divide la memoria del KV Cache en bloques discretos no contiguos (normalmente configurados para contener 16 o 32 tokens). Una tabla de páginas lógica mapea las direcciones continuas de la secuencia con bloques físicos asignados dinámicamente desde un pool global de memoria de la GPU:

Al reducir la merma de memoria por debajo del 4%, vLLM puede alojar decenas de peticiones simultáneas adicionales dentro de la misma tarjeta gráfica. Complementado con continuous batching (procesamiento por lotes a nivel de iteración), vLLM inserta solicitudes recién recibidas en la siguiente iteración de inferencia sin aguardar a que los usuarios previos terminen sus generaciones.

Ollama: Daemon en Go con el Motor Nativo de llama.cpp

Ollama adopta una arquitectura orientada a la simplicidad radical para el desarrollador. Es una aplicación escrita en Go que empaqueta y gestiona llama.cpp, el célebre runtime de inferencia en C/C++ desarrollado por Georgi Gerganov.

llama.cpp logra una portabilidad sin rival mediante kernels de cómputo altamente optimizados para AVX-512, ARM NEON, NVIDIA CUDA, AMD ROCm y Apple Metal. Emplea mapeo directo de memoria en disco (mmap) para cargar modelos compilados en el formato binario GGUF.

Sin embargo, el diseño base de Ollama está optimizado para la experiencia interactiva de un único usuario. En su configuración por defecto, las solicitudes se atienden en una cola secuencial FIFO. Aunque Ollama introdujo soporte para concurrencia básica mediante el parámetro OLLAMA_NUM_PARALLEL, su planificador interno fragmenta el contexto en slots estáticos predefinidos dentro de un buffer circular. Al recibir una ráfaga concurrente, cuando estos slots fijos se saturan, las peticiones entrantes deben esperar en un buffer HTTP, disparando de inmediato la latencia Time-to-First-Token (TTFT).

2. Benchmarks de Rendimiento y Latencia (1 a 128 Streams Concurrentes)

Para cuantificar con rigor la capacidad real de respuesta, nuestro laboratorio sometió ambos sistemas a pruebas de carga progresiva bajo idénticas condiciones de cómputo. Evaluamos dos arquitecturas abiertas de referencia:

1. Llama 3.3 70B Instruct: Desplegado en un nodo con 2x NVIDIA H100 80GB SXM5 interconectadas por NVLink 4 (ancho de banda bidireccional de 900 GB/s).
2. Qwen 2.5 32B Coder: Evaluado en 1x NVIDIA A100 80GB PCIe.

Cada cliente simulado envió prompts con un promedio de 1,024 tokens de entrada, solicitando 256 tokens de respuesta generada. Escalamos la carga desde 1 cliente aislado hasta 128 clientes concurrentes en paralelo.

Comprendiendo TTFT e ITL en Aplicaciones Interactivas

En la experiencia de usuario de asistentes conversacionales y flujos de trabajo con agentes autónomos, dos indicadores dictan la percepción de velocidad:

• Time-to-First-Token (TTFT): El tiempo transcurrido desde que el usuario envía el prompt hasta que el servidor emite el primer token. Está gobernado por la fase de prefill, un proceso intensivo en operaciones matriciales (GEMM) limitado por la potencia de cálculo bruta (compute-bound).
• Inter-Token Latency (ITL): El intervalo transcurrido entre la emisión de cada token subsiguiente durante la fase de decodificación. Es un proceso limitado por el ancho de banda de memoria de la GPU (memory-bandwidth bound / GEMV), requiriendo leer la totalidad de los parámetros del modelo en VRAM para emitir cada token individual.

vLLM incorpora Chunked Prefill, una técnica que fragmenta prompts masivos en bloques más pequeños que se intercalan dentro de la misma iteración en la que otros usuarios están decodificando tokens. Esto erradica las pausas molestas (bubbles) donde un prompt de 40,000 tokens congelaba la emisión de texto de decenas de usuarios conectados. Ollama procesa la fase de prefill de manera secuencial en su mayor parte, lo que provoca pausas abruptas en el streaming cuando nuevos clientes envían contextos extensos.

3. Requerimientos de Hardware y Formatos de Cuantización: AWQ, FP8 vs GGUF

La cuantización comprime los pesos de 16 bits en coma flotante (FP16/BF16) a representaciones de 8 o 4 bits, reduciendo drásticamente la huella de memoria VRAM y multiplicando la velocidad de inferencia al disminuir el volumen de datos que debe viajar por el bus de memoria HBM.

Matriz de Asignación de VRAM para Modelos de Frontera

Para dimensionar adecuadamente la infraestructura, consideremos los requerimientos mínimos de memoria VRAM al cargar los pesos del modelo sumados a un buffer de KV Cache para 32,000 tokens de contexto:

Nótese cómo el soporte nativo de FP8 en vLLM permite alojar la totalidad del sofisticado Llama 3.3 de 70B en una única GPU NVIDIA H100 de 80GB, conservando una calidad matemática indistinguible del original y evitando el costo de adquirir múltiples aceleradores.

4. Escalabilidad Multi-GPU e Inferencia Distribuida: Tensor Parallelism vs Layer Splitting

Cuando las dimensiones de una red neuronal superan la capacidad de una tarjeta gráfica individual, los motores deben distribuir los parámetros entre múltiples dispositivos. La ingeniería que sustenta este proceso en vLLM y Ollama se sitúa en peldaños tecnológicos diametralmente distintos.

vLLM: Paralelismo Tensorial Distribuido (TP)

vLLM implementa Tensor Parallelism basado en los principios de Megatron-LM, coordinado mediante Ray o PyTorch Distributed. En lugar de enviar capas secuenciales a diferentes tarjetas, vLLM divide las matrices de pesos internas a lo largo de la dimensión oculta de la red:

• Paralelismo por Columnas: En el módulo de autoatención, las matrices de proyección de consultas, claves y valores ($W_q, W_k, W_v$) se dividen verticalmente entre $N$ GPUs. Cada procesador calcula un subconjunto de cabezas de atención en simultáneo.
• Paralelismo por Filas: La matriz de proyección final ($W_o$) se divide horizontalmente. Una única operación colectiva All-Reduce sobre el bus NVLink reconstruye el estado oculto completo con una latencia de microsegundos.
• Pipeline Parallelism (PP): Para arquitecturas colosales desplegadas en clusters con decenas de servidores, vLLM combina Tensor Parallelism dentro del nodo con Pipeline Parallelism entre nodos, comunicándose mediante interfaces InfiniBand RDMA o 400GbE RoCE.

Ollama: División Secuencial de Capas en llama.cpp

Ollama carece de soporte para paralelismo tensorial distribuido. Al ejecutarse en una máquina con varias GPUs, delega en la función de división de capas de llama.cpp (--tensor-split). Si asignas un modelo de 80 capas en dos GPUs, ubica las capas 0 a 39 en la GPU 0 y las capas 40 a 79 en la GPU 1.

Aunque este esquema logra cargar el modelo en la memoria agregada, el cálculo es estrictamente secuencial: mientras la GPU 0 calcula las capas 0 a 39, la GPU 1 está 100% inactiva; cuando el cálculo pasa a la GPU 1, la GPU 0 se apaga. Además, los tensores intermedios deben viajar por el bus PCIe de la placa madre. Ollama no puede escalar horizontalmente entre diferentes máquinas o nodos de Kubernetes.

5. Integración de APIs en Producción, Observabilidad y Kubernetes

La puesta en producción de un modelo de lenguaje exige convivencia fluida con balanceadores de carga, sistemas de observabilidad corporativos y orquestadores de contenedores.

Ecosistema de Producción en vLLM: Nativo para la Nube

vLLM fue concebido desde sus orígenes como un microservicio cloud-native. Expone de manera nativa los endpoints compatibles con la API de OpenAI:

• POST /v1/chat/completions: Streaming completo mediante Server-Sent Events (SSE), contadores de tokens consumidos y códigos de parada.
• POST /v1/completions: Completado clásico con soporte de decodificación especulativa y cálculo de logprobs.
• POST /v1/embeddings: Extracción de vectores densos con modelos modernos (BGE-M3, NV-Embed).
• GET /health: Endpoints de liveness y readiness para control de ciclo de vida en Kubernetes.

En el plano de la observabilidad, vLLM exporta telemetría detallada en GET :8000/metrics en formato Prometheus estándar. Los ingenieros de fiabilidad de sitios (SRE) pueden configurar alertas inmediatas sobre:

• vllm:num_requests_running y vllm:num_requests_waiting (peticiones en ejecución vs encoladas).
• vllm:gpu_cache_usage_factor (porcentaje de saturación del KV Cache y preemptions).
• vllm:avg_generation_throughput_toks_per_s (velocidad de generación en tiempo real).
• vllm:time_to_first_token_seconds_bucket (histograma de percentiles P50/P90/P99 de TTFT).

Ollama: Experiencia de Desarrollo Ágil y Modelfiles

Frente a los manifiestos de Kubernetes y la configuración de controladores CUDA que exige vLLM, Ollama brilla con una velocidad de configuración sin parangón en el escritorio del programador. Con una única línea de comando descarga pesos, resuelve dependencias y levanta un REPL interactivo:

Ollama expone una interfaz compatible con OpenAI (localhost:11434/v1) y una API REST nativa en JSON (/api/generate, /api/chat), facilitando su integración con IDEs como Cursor, plugins como Continue.dev o interfaces web locales como Open-WebUI y AnythingLLM.

6. Costo Total de Propiedad (TCO) y Matemática de Punto de Equilibrio (Breakeven)

Una de las decisiones más complejas para un director de tecnología (CTO) o líder de FinOps consiste en determinar cuándo conviene alquilar GPUs dedicadas en la nube gestionadas con vLLM, frente a consumir APIs serverless de modelos abiertos o APIs comerciales propietarias cerradas.

Costos de Instancias GPU Cloud en 2026

Los precios de cómputo GPU se estructuran entre proveedores tradicionales (hiperescaladores como AWS, GCP, Azure) y nubes especializadas en hardware de IA (RunPod, Lambda Labs, CoreWeave):

• AWS EC2 g5.12xlarge (4x NVIDIA A10G 24GB): ~$5.67 USD / hora on-demand (~$4,139 USD / mes continuo).
• RunPod Secure Cloud (1x NVIDIA H100 80GB SXM5): ~$2.99 USD / hora on-demand (~$2,182 USD / mes continuo).
• RunPod Community / Spot (1x NVIDIA A100 80GB PCIe): ~$1.64 USD / hora (~$1,197 USD / mes continuo).
• Lambda Labs (Cluster 8x NVIDIA H100 80GB SXM5): ~$23.92 USD / hora (~$17,461 USD / mes continuo).

Costos de APIs Comerciales y Serverless

• API Propietaria de Frontera (OpenAI GPT-4o): $2.50 USD / 1M tokens de entrada; $10.00 USD / 1M tokens de salida (Costo combinado de ~$4.37 USD / 1M tokens asumiendo ratio 3:1 de entrada vs salida).
• Inferencia Serverless Abierta (Groq Llama 3.3 70B): $0.59 USD entrada / $0.79 USD salida por 1M tokens (Costo combinado ~$0.64 USD / 1M tokens).
• Inferencia Serverless Abierta (Together AI Llama 3.3 70B): ~$0.88 USD / 1M tokens combinados.

La Fórmula de Punto de Equilibrio (Breakeven) de CBStack

Para calcular el volumen mensual exacto de tokens ($V_{tokens}$) a partir del cual autohospedar vLLM en una GPU cloud dedicada resulta más económico que consumir APIs bajo demanda, aplicamos la ecuación de equilibrio de CBStack FinOps:

Al resolver la fórmula para ambos escenarios se revelan los siguientes umbrales operativos:

• Punto de Equilibrio frente a OpenAI GPT-4o: $$\frac{\$2,182 + \$150 + \$500}{\$0.00000437} \approx \mathbf{16.2 \text{ millones de tokens al mes}}$$ Si tu organización supera los 16.2 millones de tokens mensuales (equivalente a procesar unos 500,000 tokens al día), autohospedar Llama 3.3 70B en vLLM sobre una GPU H100 dedicada es financieramente superior a pagar la API de GPT-4o, generando ahorros sustanciales mientras se retiene el control total de los datos.
• Punto de Equilibrio frente a Serverless Abierto (Together AI / Groq): $$\frac{\$2,832}{\$0.00000088} \approx \mathbf{54.8 \text{ millones de tokens al mes}}$$ Frente a proveedores serverless ultra optimizados en precio, el punto de rentabilidad se sitúa en torno a los 55 millones de tokens mensuales. Si el volumen es inferior, pagar por token sin asumir el costo ocioso de una GPU encendida las 24 horas es la estrategia más prudente.

7. Gobernanza Empresarial y Despliegues Air-Gapped (DeepSeek-R1 y Llama 3.3)

En sectores con regulaciones estrictas—como la banca corporativa, seguros, instituciones de salud (cumplimiento HIPAA) y entidades gubernamentales o de defensa—está terminantemente prohibido canalizar datos sensibles o propiedad intelectual a través de APIs públicas externas.

Tanto vLLM como Ollama permiten un despliegue 100% Air-Gapped, con corte total de tráfico de salida a internet:

• Retención Cero de Datos (Zero Data Retention): Los pesos de los modelos se resguardan en buckets privados S3 o discos NVMe cifrados con llaves KMS propias. Ningún prompt o vector de activación sale de la Virtual Private Cloud (VPC).
• Modelos de Razonamiento de Frontera (DeepSeek-R1): La arquitectura MoE (Mixture-of-Experts) de 671 mil millones de parámetros de DeepSeek-R1 (con 37B activos por token) y sus variantes destiladas basadas en Llama y Qwen (7B, 14B, 32B, 70B) ofrecen capacidades analíticas al nivel de OpenAI o1. Al autohospedarlas con vLLM en redes aisladas, la empresa adquiere razonamiento avanzado sin ceder soberanía digital.
• Despliegues Tácticos en Edge con Ollama: Para laptops corporativas de auditoría legal o estaciones de campo sin conectividad, los modelos GGUF de Ollama pueden empaquetarse en imágenes de contenedor inmutables que arrancan de forma completamente offline.

8. Matriz Comparativa Exhaustiva Cara a Cara

La siguiente tabla resume las dimensiones arquitectónicas, operativas y de rendimiento entre vLLM y Ollama para facilitar la toma de decisiones:

9. Preguntas Frecuentes (FAQ Técnicas)

10. Recomendación Estratégica y Hoja de Ruta para Arquitectos

En la ingeniería de software actual, vLLM y Ollama no son herramientas antagónicas que compiten por el mismo nicho; son capas complementarias en una arquitectura de inteligencia artificial híbrida y madura.

• El Modelo Híbrido Corporativo: Dota a cada ingeniero de software, científico de datos e investigador con Ollama en sus computadoras locales o MacBook Pros con Apple Silicon. Esto permite un desarrollo ágil de agentes autónomos, iteraciones locales de prompts sin costo de infraestructura y experimentación protegida sin peligro de fuga de datos corporativos.
• La Capa de Producción en la Nube: Cuando esos prototipos maduren y se integren en el producto digital, canaliza todo el tráfico de backend a través de un cluster de Kubernetes operando con vLLM sobre instancias GPU dedicadas (A100/H100 o nodos de RTX 4090). vLLM provee las métricas de Prometheus, la eficiencia de memoria de PagedAttention, el rendimiento de continuous batching y los acuerdos de nivel de servicio (SLAs) que exigen miles de usuarios concurrentes.