Inferencia-Llm on lo0 — Blog Técnico

Disaggregated serving: prefill y decode en pods especializados

Fri, 22 May 2026 01:00:00 +0200

TL;DR

La inferencia LLM tiene dos fases con perfiles opuestos: prefill (procesar el prompt entero de golpe) es compute-bound, decode (generar token a token) es memory-bandwidth-bound. Ejecutarlas en la misma GPU obliga a elegir entre dos hardware óptimos incompatibles, y deja entre el 60 % y el 80 % de la capacidad de pico sin usar. La industria ha consolidado el patrón en 2026: disaggregated serving — pods separados para cada fase, conectados por un canal de transferencia de KV cache (NIXL sobre UCX, RDMA, o NCCL en su defecto). DistServe demostró 7,4× más request rate a igual SLO; NVIDIA Dynamo 1.0 (GA en GTC 2026) lleva el patrón a producción a escala datacenter. Mezclar hardware heterogéneo —H100 para prefill, GPUs commodity para decode— recorta hasta el 48 % del coste por token. Este artículo explica el porqué, el cómo, y los números que importan para una infraestructura on-premise típica.

Estás aquí: Deploy

Disaggregated serving es una decisión arquitectónica de la etapa Deploy del pipeline LLMOps de seis etapas. No cambia el modelo, no cambia los datos, no cambia las evals — sólo cambia cómo se reparten los pods de inferencia sobre el hardware GPU. Pero ese cambio mueve el throughput agregado entre 2× y 7×.

La analogía: la cocina con dos brigadas

Una cocina industrial seria —cualquiera que sirva más de 50 cubiertos por noche— funciona con dos brigadas distintas y dos espacios físicos separados.

La brigada de prep empieza al alba. Su trabajo es la mise en place: cortar, marinar, blanquear, hervir fondos, preparar componentes complejos. Equipamiento: cuchillos buenos, fogones grandes, hornos de convección, ollas de 40 litros. Es trabajo intensivo en capacidad y se hace de golpe. Cuando termina, queda todo en bandejas etiquetadas listas para usar.

La brigada de pase entra a media tarde. Su trabajo es el servicio: tomar las bandejas de la prep, calentar porciones, emplatar, montar el pase. Equipamiento: salamandras, planchas pequeñas, espátulas finas, mucha vajilla. Es trabajo de muñeca, de ritmo, de no fallar al cliente que tiene el plato delante. La capacidad por hora importa menos que la latencia por plato.

Si haces que la misma persona haga prep y pase, las dos cosas sufren. El cocinero está parado mientras hace mise en place a media tarde. Tiene que parar a emplatar cuando entran cinco pedidos a la vez. Su equipo de trabajo está diseñado para uno o para el otro, no para ambos.

Las cocinas serias resolvieron esto hace décadas: brigadas separadas, espacios separados, equipo separado. Lo único que cruza entre ambas son las bandejas de mise en place.

Las bandejas son el KV cache. La separación es disaggregated serving. El pase de la prep al servicio es la transferencia de KV cache, hoy resuelta con NIXL sobre RDMA. Y los pods especializados son las dos brigadas con sus equipos óptimos.

Recap rápido: prefill y decode

Una petición a un LLM atraviesa siempre dos fases:

Prefill. Coger el prompt completo (por ejemplo, 4.000 tokens) y procesarlo de una sola pasada por todas las capas del modelo. El resultado es el KV cache de esos 4.000 tokens (ver el artículo previo sobre KV cache si quieres recordar qué guarda exactamente). Este paso es masivamente paralelo: todos los tokens van a la vez por las matrices de atención, lo que se traduce en multiplicaciones de matrices enormes y densas. La GPU está al 90-95 % de uso de compute. TTFT (time to first token) lo determina esta fase.

Decode. Una vez está el KV cache listo, el modelo genera tokens uno por uno. Cada token nuevo es una pasada por todas las capas con un solo vector de query, leyendo todo el KV cache acumulado para calcular la atención. No hay paralelismo entre tokens (cada uno depende del anterior). Lo que limita aquí no es el compute sino el ancho de banda: cada paso hay que leer los pesos completos del modelo desde HBM. La GPU está al 20-40 % de uso de compute, pero al 90 % de uso del HBM. TBT (time between tokens) lo determina esta fase.

Fase	Característica	Cuello de botella	Métrica clave
Prefill	Cómputo masivo paralelo sobre N tokens de golpe	TFLOPS (compute)	TTFT
Decode	Streaming de pesos desde HBM, 1 token cada vez	Bandwidth HBM	TBT (inter-token latency)

La asimetría es estructural: prefill quema el compute y deja la memoria a media, decode hace lo contrario. Una GPU diseñada para ser excelente en ambos a la vez es una GPU diseñada para estar mal aprovechada todo el tiempo.

Por qué juntarlas en la misma GPU es un mal negocio

Hasta 2023, la asunción universal era ejecutar prefill y decode en el mismo proceso de inferencia, sobre la misma GPU. El motor scheduler (vLLM, TGI, Triton) decidía en cada ciclo si hacer prefill de una petición nueva o decode de las que ya estaban en marcha. La intuición era que compartir hardware ahorra coste.

La intuición es incorrecta. El problema tiene tres caras:

Interferencia en latencia. Cuando el motor decide hacer prefill de una petición nueva, interrumpe todos los decodes en curso. Eso sube el TBT de las otras peticiones. El usuario que estaba viendo tokens caer fluidos en su pantalla nota un parón de varios cientos de milisegundos. Esto se conoce como prefill-decode interference y degrada la experiencia de forma visible a medida que sube la concurrencia.

Hardware sub-óptimo para cada fase. Una H100 SXM tiene 989 TFLOPS BF16 de compute y 3,35 TB/s de HBM3. Es excelente para prefill, donde el compute es el límite. Para decode, donde lo único que importa es el bandwidth, esos 989 TFLOPS están desaprovechados al 60-70 %. Inversamente, una GPU con menos compute pero similar bandwidth relativo (RTX 4090, L40S) resolvería el decode igual de bien por una fracción del precio.

Utilización agregada baja. En workloads reales con Llama 3 70B y outputs de 512 tokens, alrededor del 80 % del wall-clock se gasta en decode. Eso quiere decir que el 80 % del presupuesto de tu cluster H100 está haciendo lecturas de memoria, no cálculos. Es como pagar un Ferrari para usarlo en cola de aparcamiento.

La idea: pods especializados, KV cache como entregable

Disaggregated serving rompe el ciclo de inferencia en dos servicios distintos:

Pod de prefill. Recibe el prompt, ejecuta el prefill, produce el KV cache. Hardware: GPUs con alto compute (H100, H200, B200). Optimizado para batching agresivo y throughput, no para latencia individual: si llegan 32 prompts en 100 ms, los procesa juntos.

Pod de decode. Recibe el KV cache ya construido, ejecuta la generación token a token, streamea al cliente. Hardware: GPUs con buen bandwidth pero idealmente más baratas por TFLOPS (RTX 4090, L40S, A100, incluso A30 según el caso). Optimizado para latencia por token (TBT bajo).

Entre ambos: una transferencia de KV cache sobre la red, que puede ser nodo-local (shared memory, NVLink), intra-rack (RDMA con InfiniBand o RoCE) o cross-rack (NIXL sobre UCX). El coste de esta transferencia escala linealmente con la longitud del contexto, y es la clave económica del esquema.

El protocolo de transferencia: la economía del movimiento

El KV cache transferido en un Llama 3 70B con 4K de contexto pesa aproximadamente 2,6 GB (80 layers × 8 KV heads × 128 dim × 4 096 tokens × 2 (K y V) × 2 bytes en BF16). Mover 2,6 GB entre dos GPUs no es trivial:

Canal	Bandwidth efectivo	Tiempo para 2,6 GB
NVLink intra-nodo (NVSwitch)	~450 GB/s	~6 ms
Shared memory (mismo nodo, PCIe 5)	~60 GB/s	~45 ms
RDMA InfiniBand 400 Gbps	~50 GB/s	~55 ms
RDMA RoCE 200 Gbps	~25 GB/s	~105 ms
TCP/IP 10 GbE	~1 GB/s	~2,6 s

Lectura inmediata: por encima de InfiniBand-grade, la transferencia es cómoda. Por debajo, lleva al traste el TTFT que estamos intentando mejorar. Disaggregated serving es viable sólo con interconexión decente — no es un patrón para clusters montados con switches Ethernet de consumo.

NVIDIA respondió a esto con NIXL (NVIDIA Inference Transfer Library), publicada a mediados de 2025: una librería que abstrae el transporte (UCX, NCCL, RDMA verbs directos, shared memory) y elige el mejor camino disponible automáticamente. vLLM la integra desde finales de 2025 mediante el NixlConnector. Es ahora el default de facto para nuevos despliegues.

Implementaciones reales en mayo 2026

El recorrido del patrón en dos años:

2024 ene · DistServe (HKU + UCSD): 7,4× requests al mismo SLO
2024 may · SplitWise (Microsoft): variante con hardware heterogéneo
2024 dic · vLLM disagg experimental (SharedStorage + PyNcclConnector)
2025 mar · NIXL release (NVIDIA): librería de transferencia unificada
2025 jul · vLLM NixlConnector estable
2025 nov · SGLang, llm-d, MoonCake adoptan el patrón
2026 mar · NVIDIA Dynamo 1.0 GA (GTC 2026): production-ready a escala datacenter

A día de hoy, el patrón es el default en cualquier framework de serving serio. Los que siguen monolíticos son los pequeños o los educativos.

Tres opciones realistas para una infraestructura on-premise:

vLLM disagg con NixlConnector. El camino más abierto, requiere desplegar dos sets de pods de vLLM (uno con --kv-transfer-config '{"kv_role":"producer"}', otro con "kv_role":"consumer") y un proxy router. Suficiente para clusters de 4-16 GPUs.
SGLang con disagg. Equivalente conceptual, mejor performance en algunos workloads MoE.
NVIDIA Dynamo 1.0. El que se está imponiendo a escala datacenter. Cubre routing, KV cache management, monitorización y scheduling en un solo plano de control. Más pesado, pero la solución de referencia si tu cluster crece por encima de 32 GPUs.

Los números que importan

Lo que la disaggregation desbloquea, en términos directos:

Métrica	Aggregated (monolítico)	Disaggregated	Mejora
Goodput (req/s al SLO)	baseline	1,4 – 2×	hasta 2×
TTFT bajo carga alta	sube agresivo desde QPS 4	estable hasta QPS 7+	~2×
Request rate al mismo SLO (DistServe paper)	baseline	7,4×	7,4×
Throughput MoE en Blackwell (Dynamo, GB300 NVL72)	baseline (Hopper)	hasta 50×	depende del modelo
Coste por token (heterogéneo H100 + commodity)	baseline (todo H100)	-48 %	casi mitad

Hay que leer estos números con cuidado: los más espectaculares (7× y 50×) requieren hardware específico (Blackwell GB200/GB300 NVL72) y modelos específicos (MoE grandes). El rango realista para un on-premise típico es 1,4-2× en goodput y -30 a -50 % en coste por token, dependiendo de cuán heterogénea sea la mezcla de GPUs y de cuán optimizada esté la transferencia de KV cache.

Heterogeneidad: la versión radical

El paso lógico siguiente, propuesto por SplitWise en 2024 y madurado en 2025-2026 (Cronus, Tessera y otros), es mezclar tipos de GPU: GPUs caras de cómputo alto para prefill, GPUs commodity con buen bandwidth para decode.

Coste indicativo (precios de mercado típicos a mediados de 2026):

H100 SXM: ~30-40 k$ capex, ~3-4 $/h amortizado. Perfil compute-pesado.
L40S: ~8-10 k$ capex, ~1,5 $/h. Perfil intermedio, 864 GB/s de bandwidth.
RTX 4090: ~1,5 k$ capex, ~0,30 $/h. Perfil compute-modesto pero 1 TB/s de bandwidth GDDR6X — suficiente para decode de modelos hasta ~30B parámetros.

Un cluster mixto realista para servir un modelo 8B:

2× RTX 4090 (prefill batch) → ~3.000 $ capex, ~0,60 $/h
4× RTX 4090 (decode pool) → ~6.000 $ capex, ~1,20 $/h
TOTAL → ~9.000 $ capex, ~1,80 $/h

Frente a la alternativa monolítica equivalente en throughput:

2× H100 SXM (todo en uno) → ~70.000 $ capex, ~7 $/h

El mismo throughput a una fracción del capex y a la cuarta parte del coste por hora, a costa de complejidad operativa: ahora tienes dos pools que coordinar, una red de transferencia que cuidar, y un scheduler que no es trivial.

Para modelos más grandes (Llama 3 70B), el decode pool ya no cabe en una 4090 individual (el modelo no entra en 24 GB ni siquiera cuantizado a INT4 con margen). Ahí la mezcla razonable es H100 para prefill + L40S o A100 80GB para decode, con ahorro típico del 30-40 % sobre la opción todo-H100.

Aplicado a hardware on-premise típico

Caso 1 — Una o dos RTX 4090: monolítico sigue ganando

Con una sola GPU no hay disaggregation que valga: el patrón requiere mínimo dos GPUs en pods separados. Con dos 4090, técnicamente puedes intentarlo (una para prefill, otra para decode con KV cache transferido por PCIe 5 o RDMA básico), pero el overhead de transferencia se come la ganancia para modelos pequeños donde el prefill ya es rápido.

Recomendación: mantener monolítico (vLLM tradicional, bien configurado con KV cache cuantizado). El siguiente nivel justificable de complejidad es un cluster con interconexión rápida.

Caso 2 — Cluster 4×H100 SXM (320 GB, NVLink): el sweet spot

Configuración mínima realista para disaggregation seria, sirviendo un modelo 70B en producción:

2× H100 (TP=2) → 2 pods de prefill
2× H100 (TP=2) → pods de decode con varias instancias compartiendo TP
NIXL sobre NVLink → transferencia KV cache <6 ms
Router (vLLM o Dynamo) → distribución de prompts y stream

Resultado realista esperado: goodput 1,6-1,9× respecto al mismo cluster en monolítico, con TTFT estable hasta cargas de QPS 7-8 (frente al QPS 4 al que empieza a degradar el monolítico).

Si la mezcla heterogénea es posible (añadir 4-8 L40S al cluster para hacer el decode pool), el coste por token cae adicionalmente entre un 25 % y un 35 %, manteniendo el modelo 70B servido íntegro.

Posición dentro de la arquitectura

Disaggregated serving es una capa transversal a casi todo lo discutido en artículos previos. Toca:

El KV cache porque es el artefacto que se transfiere entre pods. Sin entender bien cuánto pesa el cache y cómo crece con el contexto, no se puede dimensionar la transferencia.
El fine-tuning continuo porque el multi-LoRA hot-swap conserva su semántica: cada pod (prefill o decode) carga los adapters por separado, y el router decide qué adapter aplicar en cada fase.
La topología del cluster: cambia la HW recomendada, el networking exigido y el modelo de costes.

Si estás diseñando una infraestructura de inferencia para 2026 desde cero, disaggregation deja de ser opcional para cualquier cluster que exceda 4 GPUs de capacidad. Si estás modernizando una existente, es la actualización con mejor retorno por euro invertido — siempre que el networking entre pods sea decente (NVLink intra-nodo o RDMA intra-rack como mínimo).

Lo que no hemos cubierto (próximos artículos)

NIXL en detalle: cómo elige el transporte óptimo, cómo se configura UCX, qué pasa cuando RDMA falla y hay que degradar a TCP.
Scheduler de routing: cómo decide el orquestador qué pod recibe qué petición, batching dinámico, manejo de prioridades.
Multi-tenant disagg: aislamiento de KV cache entre tenants, ACLs por adapter, multi-LoRA sobre pods especializados.
Disagg + prefix caching: cómo se combina con el patrón de reutilización de KV cache cuando varios prompts comparten prefijo (system prompt común).
Disagg en edge / inferencia local: viabilidad sobre hardware doméstico (4090 + Mac Studio, por ejemplo), donde la transferencia depende de Thunderbolt o Ethernet residencial.

Ver también

El pipeline LLMOps de seis etapas — el mapa maestro al que pertenece la etapa Deploy. Este post entra en una decisión arquitectónica concreta dentro de esa etapa.
El cluster GPU como plataforma multi-tenant — el patrón de capas Gateway/Quota/Isolation/Observability sobre el cual la disaggregation aquí descrita se sitúa: el cluster H100 que sirve a varios tenants combina ambos patrones.
Operators de inferencia LLM en Kubernetes — los operators (vLLM Production Stack, NVIDIA Dynamo, llm-d, OME) que materializan en Kubernetes los pods especializados de prefill y decode.
KV cache: la memoria de trabajo que sostiene la inferencia LLM — el artefacto exacto que se transfiere entre pods, con la fórmula completa de su tamaño.
PagedAttention por dentro: bloques, tabla de páginas, evicción y el estado del arte del KV cache en 2026 — la mecánica del KV cache que la disaggregation explota a nivel del bloque, y el panorama de optimizaciones derivadas (vAttention, LMCache, RadixAttention).
Fine-tuning continuo en producción — cómo el multi-LoRA hot-swap convive con la disaggregation: cada pod carga adapters por separado, el router elige.

Referencias

Zhong et al., DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving (OSDI 2024).
Patel et al., SplitWise: Efficient Generative LLM Inference Using Phase Splitting (ISCA 2024).
NVIDIA, NVIDIA Dynamo 1.0: Production-Ready Disaggregated Inference (GTC 2026, marzo): https://developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/.
NVIDIA, NIXL: NVIDIA Inference Transfer Library — documentación oficial.
vLLM, Disaggregated Prefilling: https://docs.vllm.ai/en/stable/features/disagg_prefill/.
vLLM, NixlConnector Usage Guide: https://docs.vllm.ai/en/stable/features/nixl_connector_usage/.
Hao AI Lab, Disaggregated Inference: 18 Months Later (UCSD, 2025) — retrospectiva técnica del paper DistServe.

El cluster GPU como plataforma: cómo convertir un cluster compartido en un servicio multi-tenant que tus equipos puedan consumir

Thu, 21 May 2026 07:15:00 +0200

TL;DR

Tener un cluster de GPUs caro y muchas cargas distintas que lo quieren usar no es un problema de infraestructura: es un problema de producto interno. Lo que separa “tenemos un cluster” de “tenemos una plataforma de inferencia” son cuatro capas que el mercado ha consolidado en 2026: una capa de gateway que centraliza autenticación, routing y políticas (LiteLLM, Portkey, Kong AI Gateway); un modelo de aislamiento GPU apropiado al perfil de los tenants (MIG hardware-isolation para multi-tenant no confiable, MPS para procesos del mismo equipo, time-slicing solo para dev); un sistema de quotas y rate limiting con presupuestos por tenant/equipo/proyecto (LiteLLM lo hace en su core a nivel team/user/api-key con 429s descriptivos); y un plano de observabilidad multi-tenant que permite cost attribution real (showback como paso intermedio, chargeback como destino), tracing por tenant y dashboards diferenciados. Aplicado a un cluster GPU mid-scale típico (un nodo con 4-8 H100 SXM y NVLink, un punto habitual para empezar en producción), esto se traduce en decisiones concretas: con ~640 GB de VRAM agregada en 8 GPUs y dos modelos típicos en producción (un modelo grande de 70B+ con tensor parallel y un modelo mediano replicado), el cluster sirve entre decenas y bajos centenares de sesiones simultáneas según mix; el aislamiento GPU se suele resolver con MIG en cargas inferiores y dedicación per-model en cargas grandes; y la métrica de éxito de la plataforma es la utilización efectiva, que en producción típica está en 30-40% y el objetivo razonable de optimización es subirla a 60-70% sin degradar SLA.

Este es el quinto post de la serie MLOps para LLMs. Es el más operacionalmente orientado y atraviesa varias etapas del pipeline (Deploy + Observe + transversales). El “estás aquí” señala las dos etapas activas porque la noción de plataforma multi-tenant no vive en una sola.

Estás aquí: Deploy + Observe (cluster como producto)

La pregunta que cambia el marco

Cuando un equipo de plataforma adquiere hardware GPU caro y empieza a montar inferencia, la primera versión casi siempre es mononosa: un modelo, un cliente, una latencia objetivo. Funciona. Cuando llega el segundo equipo pidiendo el mismo recurso, la mononosa se vuelve política interna: ¿cuántas réplicas le damos? ¿Qué hacemos si chocan los SLA? ¿Quién paga los tokens del experimento del equipo B? Y cuando llega el tercero, lo que era un proyecto de SRE pasa a ser un proyecto de producto interno.

La distinción no es técnica, es de marco. Un cluster es infra. Una plataforma es un servicio con clientes, contratos y métricas de éxito. El cambio de marco implica:

Clientes identificables (tenants), no usuarios anónimos.
Contratos (latency SLA, throughput garantizado, modelos disponibles), no “lo que dé tiempo”.
Métricas de éxito que no son técnicas sino de producto: adopción, satisfaction, cost per query por tenant, tiempo del primer “hello world”.

Este post recorre cómo se opera ese cambio de marco. Lo aterriza sobre un cluster mid-scale (4-8 H100 SXM con NVLink en un solo nodo), configuración habitual cuando se empieza con inferencia LLM seria; pero los principios se generalizan a cualquier topología, desde un nodo único con dos GPUs hasta clusters multi-nodo con InfiniBand.

Las cuatro capas de una plataforma de inferencia multi-tenant

La arquitectura canónica que se ha establecido en 2026 tiene cuatro capas que cualquier plataforma multi-tenant seria implementa, en orden de afuera hacia adentro:

Cada capa resuelve un problema concreto. Vamos a una por una.

Capa 1 — AI Gateway: la puerta de entrada única

El AI Gateway es el componente que tus tenants ven. Es una API HTTP/gRPC compatible con OpenAI (típicamente /v1/chat/completions, /v1/embeddings, /v1/models) que centraliza todo lo que pasa antes de tocar los backends de inferencia.

Por qué centralizar

Sin gateway, los tenants se conectan directamente a vLLM o al modelo que sea. Cada cambio (rotar un endpoint, añadir un modelo, cambiar credenciales, aplicar política) requiere notificar a todos los tenants. Cada tenant tiene su propia lógica de retry, su propio logging, su propio modelo de auth. Es inoperable a partir del tercer cliente.

Con gateway, el cambio se hace en un sitio. Los tenants tienen una URL estable y unas credenciales; el resto es problema del gateway.

Las tres opciones dominantes 2026

LiteLLM es la opción OSS más popular, Python-first, modelo de despliegue como proxy. Soporta 100+ proveedores (OpenAI, Anthropic, Bedrock, vLLM self-hosted, Ollama, etc.) detrás de una API OpenAI-compatible unificada. Hierarchy nativa multi-tenant con Organizations → Teams → Users → API Keys, cada nivel con budget independiente. Versión Apache 2.0 cubre lo básico; RBAC, SSO, audit logs y team-level enforcement requieren versión Enterprise paga. Despliegue en K8s con Helm chart oficial.

Portkey es la opción comercial / SaaS más madura. Single control plane que enforces budgets, quotas, permissions, compliance. Real-time spending tracking con alerting. RBAC, audit, workspaces, SSO incluidos. Trade-off: dependencia de un servicio externo y modelo de pricing por requests.

Kong AI Gateway es la opción para organizaciones que ya tienen Kong como API gateway. Plug-in AI sobre el gateway Kong existente, integra con su modelo de plugins, consumers y rate-limits. Si tu equipo de plataforma ya opera Kong, es la fricción más baja.

Cuándo elegir cada uno

Situación	Gateway
OSS puro, self-host, equipo Python-first	LiteLLM
Necesitas RBAC, SSO, audit log out-of-the-box, presupuesto disponible	Portkey
Ya operas Kong como API gateway corporativo	Kong AI Gateway
Greenfield enterprise con compliance estricto	Portkey (probablemente)
Empresa media OSS-first sin compliance regulado	LiteLLM (típicamente)

Lo que el gateway tiene que hacer mínimo

Independientemente de la opción, lo que cualquier deployment serio debe enforcer:

Auth y identidad: cada request lleva una API key resoluble a un tenant + usuario + equipo.
Routing por modelo: el tenant pide model: "gpt-4o"; el gateway decide si va a OpenAI, a Azure OpenAI, a tu vLLM con Qwen3 32B (fallback más barato), según política.
Rate limiting: RPS por tenant, TPM (tokens por minuto), concurrency limits.
Caching de respuestas idénticas: 5-30% de las queries de RAG son repetidas; cachear ahorra latencia y coste.
OTel emission: cada llamada produce un span con gen_ai.* semantic conventions y tenant_id como atributo. Cubierto en post de Evals y MCP observability.
Failover: si vLLM se cae, el gateway redirige a OpenAI API. Si OpenAI rate-limita, el gateway tira a Anthropic. Política configurable.

Ejemplo de configuración LiteLLM multi-tenant

# litellm-config.yaml — ejemplo simplificado
model_list:
 - model_name: llama-3-70b
 litellm_params:
 model: openai/llama-3-70b
 api_base: http://vllm-llama3-70b.inference/v1
 api_key: os.environ/VLLM_API_KEY

 - model_name: qwen3-32b
 litellm_params:
 model: openai/qwen3-32b
 api_base: http://vllm-qwen3-32b.inference/v1
 api_key: os.environ/VLLM_API_KEY

 - model_name: gpt-4o
 litellm_params:
 model: openai/gpt-4o
 api_key: os.environ/OPENAI_API_KEY

router_settings:
 routing_strategy: usage-based-routing-v2
 fallbacks:
 - llama-3-70b: [qwen3-32b, gpt-4o]  # si vLLM cae, fallback al externo

general_settings:
 master_key: os.environ/LITELLM_MASTER_KEY
 database_url: os.environ/DATABASE_URL  # Postgres para budgets/keys

# Hierarchy: Organizations → Teams → Users → API Keys
# Se crean vía API, no en YAML estático

Crear un team con presupuesto:

curl -X POST http://litellm/team/new \
 -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
 -d '{
 "team_alias": "soporte-chat",
 "max_budget": 500, # 500 USD/mes
 "budget_duration": "30d",
 "tpm_limit": 100000, # 100K tokens/min
 "rpm_limit": 1000, # 1000 requests/min
 "models": ["llama-3-70b", "qwen3-32b"] # acceso a estos
 }'

Y la API key del team:

curl -X POST http://litellm/key/generate \
 -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
 -d '{
 "team_id": "<team-id>",
 "duration": "30d",
 "metadata": {"environment": "production", "app": "support-bot"}
 }'

Esa API key es lo que el tenant usa. Cada request que pase con ella consumirá del budget del team. Cuando se agote, LiteLLM devuelve HTTP 429 con descripción.

Capa 2 — Policy & Quota Plane: qué puede hacer cada tenant

El gateway es donde se enforza. La política es lo que se enforza. Cinco ejes de política multi-tenant:

Quotas técnicas

TPM (tokens por minuto): el límite duro de consumo. Para un Llama 3 70B en TP=5, ~3000 tokens/s salidos sostenidos = 180K TPM agregados. Si tienes 10 tenants, asignar 18K cada uno como techo.
RPS / RPM: control de carga, no de consumo. Una sesión de 4K tokens cuenta como una request; un batch de 100 mini-completions también. Útil contra abuso.
Concurrency: cuántas requests simultáneas activas por tenant. Importante para SLA de latencia: 100 RPS con concurrency=50 se traducen en 2 segundos por request.

Budgets económicos

Mensual por tenant: hard cap en USD.
Diario y por hora: soft caps para evitar runaway en un solo día.
Por proyecto / API key: granularidad fina dentro de un mismo tenant.

LiteLLM tiene un campo max_budget en cada nivel de la jerarquía (organization, team, user, api key). Los presupuestos se heredan/restringen hacia abajo.

Whitelist y blacklist de modelos

Tenants con cargas críticas → solo modelos estables (llama-3-70b, gpt-4o). Tenants de investigación → acceso también a modelos experimentales.

Priority classes

No todos los requests son iguales. Tres clases típicas:

Guaranteed: cargas con SLA, latencia respetada incluso bajo presión.
Best-effort: cargas normales sin SLA estricto.
Spot: batches que pueden esperar, evictable si llega un guaranteed.

El paper Token Management in Multi-Tenant AI Inference Platforms (2026) formaliza esto con un modelo de token pools por priority class que se ha empezado a adoptar en producción. Mantiene P99 latency garantizada para guaranteed workloads incluso bajo overload, throttling selectivo sobre spot.

Admission control

Antes de aceptar una request: ¿hay capacidad? Si no, devolver 429 inmediatamente en vez de encolar y degradar a todos. Es la disciplina operacional más infravalorada — un cluster con admission control bien hecho tiene latencia predecible; sin él, catastrophic degradation cuando llega el pico.

El patrón típico en 2026

# Política conceptual para un tenant "soporte-chat"
tenant: soporte-chat
quotas:
 tpm: 50000
 rpm: 500
 max_concurrency: 30
budget:
 monthly_usd: 800
 alert_thresholds: [0.5, 0.8, 0.95] # avisa cuando llegues
models_allowed:
 - llama-3-70b
 - qwen3-32b
priority: guaranteed
fallback_on_overload:
 - qwen3-32b  # si guaranteed se llena, fallback
 - gpt-4o-mini  # último recurso, modelo externo

Capa 3 — Isolation Plane: aislar las cargas físicamente

Esta es la capa más densa técnicamente. Tienes un nodo con varias GPUs H100 SXM interconectadas por NVLink. ¿Cómo las particionas entre tenants?

Tres mecanismos NVIDIA para compartir GPU

MIG (Multi-Instance GPU) es el aislamiento más fuerte. Particiona la GPU en hasta 7 instancias con memoria HBM separada físicamente y compute units (SMs) dedicados. Los tenants en MIG diferentes no pueden tocarse: una carga no consume memoria que otra necesita, una no degrada el throughput de otra. Aislamiento hardware. Disponible en A100, H100, B100, B200.

MPS (Multi-Process Service) es soft. Múltiples procesos comparten la GPU concurrentemente, NVIDIA reparte SMs según uso. Buen rendimiento si todos los procesos son tuyos y confías en ellos. Peor para multi-tenant entre clientes que no se conocen porque un proceso ruidoso puede degradar a los otros.

Time-slicing es lo más simple: la GPU se asigna alternadamente, slot por slot, a procesos distintos. Latencia mucho peor (waits entre slots); no se recomienda para cargas de producción con SLA.

La elección para multi-tenant 2026

Según el survey de adopción enterprise: 80% usa MIG para multi-tenant no confiable (clientes distintos que no se conocen) y MPS para entornos confiados (procesos del mismo equipo) donde quieres maximizar throughput. Time-slicing solo se usa en dev/staging para que cada developer toque GPU sin coste de exclusividad.

Limitación importante de MIG: aísla compute y memoria HBM, pero el camino PCIe sigue siendo compartido. Para cargas PCIe-bound (mucho tráfico host↔device), tenants en MIG distintos pueden seguir afectándose. Para inferencia LLM, el path principal es HBM, así que esto rara vez es problema. Pero conviene saberlo.

Las particiones MIG en H100

Una H100 (80GB HBM3) se puede particionar en perfiles fijos:

Perfil	SM	Memoria	Instancias máx por GPU
1g.10gb	14	10 GB	7
1g.20gb	14	20 GB	4
2g.20gb	28	20 GB	3
3g.40gb	42	40 GB	2
7g.80gb	98	80 GB	1 (toda la GPU)

Para un cluster mid-scale con NVLink, MIG tiene un problema fundamental: cuando particionas con MIG, se desactiva el NVLink entre GPUs. Una H100 en MIG no participa en tensor parallel multi-GPU. Si vas a servir un modelo grande con tensor parallel (Llama 3 70B con TP=4 o TP=8, por ejemplo), esas GPUs deben estar enteras, sin MIG.

Esto define la decisión arquitectónica. Hay dos enfoques principales:

Enfoque A — Modelo grande compartido con quotas en gateway

Todas las GPUs del nodo sirven un único modelo grande con tensor parallel que abarca el nodo entero. Todos los tenants comparten esa instancia. El aislamiento se hace en la capa de gateway (quotas, rate limiting) y la capa de policy (priority classes). El kernel del cluster es una sola instancia vLLM enorme con --max-num-seqs=128 o similar; vLLM internamente reparte tiempo de GPU entre las requests activas con continuous batching.

Ventajas: aprovechas todas las GPUs al máximo, NVLink activo, mejor utilización del KV cache. Desventajas: aislamiento blando — un tenant que satura no degrada a otros directamente (vLLM bachea), pero sí compite por slots del batch. Necesitas priority classes serias.

Enfoque B — Dedicar GPUs por modelo / tenant

Divides las GPUs en pools dedicados a modelos distintos. Ejemplos en un nodo de 8 GPUs:

4 GPUs: modelo grande de 70B con TP=4.
2 GPUs: modelo mediano de 32B replicado (2 instancias independientes) para tenants con SLA estricto.
2 GPUs: cargas misceláneas (modelos más pequeños, experimentación).

Ventajas: aislamiento físico entre modelos / tenants críticos. Desventajas: peor utilización agregada; algunas GPUs idle mientras otras saturan.

Enfoque C (avanzado) — MIG en algunas GPUs + dedicar el resto

Si tienes cargas pequeñas (modelos de 4B, 7B), puedes hacer MIG en 1-2 GPUs para servirlas y dedicar las restantes a tensor parallel del modelo grande. Combina aislamiento fuerte para cargas chicas con aprovechamiento del NVLink para el modelo grande.

La elección operativa: empieza por A, sube a C si hace falta

En la mayoría de despliegues, el Enfoque A (modelo grande compartido + quotas) es el punto de partida correcto. La utilización es mejor, la operación es más simple, y los aislamientos blandos del gateway funcionan para cargas razonables.

Cuando hay un tenant con SLA estricto que no tolera competir con otros, mueves a Enfoque B para ese tenant en particular (dedicar GPUs a una instancia del modelo solo para él), manteniendo el resto del cluster compartido.

Enfoque C es para cuando tienes 10+ tenants con perfiles muy heterogéneos.

Aislamiento a nivel Kubernetes

Independiente del aislamiento GPU, en K8s se aplica aislamiento de pod:

Namespaces por tenant: tenant-soporte, tenant-legal, etc.
ResourceQuotas y LimitRanges: límites de CPU/memoria por namespace.
NetworkPolicies: tenant A no puede hablar con namespaces de tenant B.
PriorityClasses K8s: clases con valor numérico que define preemption order si llega un pod más crítico.
PodDisruptionBudgets: cuántos pods de cada deployment pueden caer simultáneamente.

Capa 4 — Observability Plane: ver lo que pasa por tenant

La cuarta capa: observabilidad con dimensión tenant. Sin esto, no puedes hacer cost attribution, no puedes debugear incidentes de un solo tenant, no puedes mostrar dashboards a stakeholders.

Las cuatro propiedades obligatorias

1. tenant_id en todos los spans. El AI gateway resuelve la API key y atribuye un tenant_id. Ese ID se propaga vía params._meta o headers OTel a todos los componentes downstream (vLLM, retrieval, MCP servers, tools). Cualquier span en cualquier sistema lleva ese label. Es lo que permite reconstruir traces tenant-específicos.

2. Métricas labeled por tenant. gen_ai.usage.input_tokens{tenant="soporte-chat"} o equivalentes. Prometheus, Grafana, agrupable por tenant.

3. Cost attribution real. La suma de tokens × cost/token por tenant da el coste. Para vLLM self-hosted, el coste es por hora de GPU + parte proporcional de tokens (puedes calcular un cost-per-1k-tokens equivalente).

4. Audit log inmutable. Cada API key usada, cada modelo invocado, cada cambio de quota, cada budget exceeded. Para compliance.

Showback vs chargeback

Distinción importante de FinOps que ha ganado claridad en 2026:

Showback: visibilidad sin consecuencia. “Equipo de soporte, has consumido $623 este mes en LLM”. Información, no factura. Permite detectar abusos sin penalizar antes de que el equipo entienda.

Chargeback: el coste se imputa al presupuesto del equipo. Cuando se acaba, se acaba. Cambia comportamiento.

La práctica que funciona: 6-18 meses en showback mientras se calibran tags, se identifican misattributions, se forma a los equipos. Después chargeback cuando los números son creíbles. Lanzar chargeback el día 1 cuando los costs aún están sucios crea pelea política inmediata; lanzar showback prepara terreno para que el chargeback aterrice ordenadamente.

Solo 14% de organizaciones tienen chargeback activo según un survey reciente, lo que indica que esto sigue siendo mayoritariamente showback en producción real.

Herramientas

Kubecost: cost allocation por namespace, deployment, pod en Kubernetes. Para el coste de la GPU compartida, allocate proporcionalmente a tokens consumidos por tenant.
Finout: FinOps platform que combina cloud bills + LLM API costs en una vista unificada con tagging virtual.
Langfuse: ya cubierto. Cost tracking por trace, agrupable por usuario o session metadata.
LiteLLM tracking nativo: el master DB de LiteLLM mantiene running spend por team, user, API key, accesible vía API o UI.

Dashboard mínimo multi-tenant

Cualquier plataforma debería tener:

Resumen por tenant: spend mensual, RPS actual, TPM consumido, % budget gastado, sesiones activas.
Top usuarios dentro de cada tenant (para detección de abuso interno).
Latencia p95 por tenant: SLA tracking.
Errores 429 / 503: cuántas requests están siendo rate-limitadas o rechazadas por overload.
Cost trend: trayectoria mensual con proyección.
Drift por tenant (de la serie post-tracing): si un tenant empieza a tener peores resultados, alerta.

Dimensionado en clusters GPU mid-scale: decisiones concretas

Bajemos a hardware. Tomamos como referencia un nodo con N H100 SXM (entre 4 y 8) con NVLink/NVSwitch, 80 GB HBM3 cada una. Eso da entre 320 GB y 640 GB de VRAM agregada. Conectividad inter-GPU 900 GB/s (NVLink 4) o 600 GB/s (NVLink 3) según generación. Ancho de banda HBM por GPU 3.35 TB/s.

Decisiones por defecto

Empezar con Enfoque A: todas las GPUs del nodo sirviendo un único modelo grande de 70B en BF16 con tensor parallel = N. Capacidad real esperada (calculada para un nodo HGX estándar de 8 GPUs como ejemplo; escala aproximadamente lineal con N):

VRAM modelo (70B BF16): ~140 GB (≈ 17.5 GB/GPU en TP=8).
VRAM overhead vLLM + activations: ~10 GB/GPU.
VRAM libre para KV cache: ~52 GB/GPU. En un nodo de 8 GPUs son ~416 GB agregados; en uno de 4 son ~210 GB.
Con --kv-cache-dtype=fp8 y un modelo 70B GQA: ~320 KB/token.
Capacidad agregada de cache (nodo de 8 GPUs): ~1.3M tokens repartibles entre sesiones simultáneas.

Esto se traduce en throughput y concurrencia (cifras orientativas para un nodo de 8 GPUs):

Sesiones simultáneas	Contexto medio por sesión	Throughput agregado (tokens/s)
32	16K	~5000
64	8K	~8000
128	4K	~12000

Latencias típicas: TTFT ~150ms a tráfico bajo, TPOT ~15-20 ms/tok. Con concurrencia alta, TTFT sube hasta ~500ms si el queue está saturado.

Esquema de tenants ejemplo

Cluster con 4 tenants y un pool de research:

Tenant	TPM cap	RPM cap	Concurrency	Budget	Priority	Modelos
Soporte chat	80K	800	50	1500 USD/mes	Guaranteed	llama-3-70b, qwen3-32b
Legal RAG	30K	200	15	600 USD/mes	Guaranteed	llama-3-70b
Agente code	50K	300	25	1200 USD/mes	Best-effort	llama-3-70b, qwen-coder
Data extr. batch	40K	1000	40	400 USD/mes	Spot	llama-3-70b, qwen3-32b
Research / notebooks	10K	100	5	200 USD/mes	Spot	todos

Suma TPM: 210K. Capacidad agregada del cluster: ~180K TPM sostenidos. Está overcommit del ~15%, asumiendo que no todos los tenants llegan al techo simultáneamente. Es lo normal y deseable; si todos lo hacen al mismo tiempo, las priority classes degradan ordenadamente.

Cuándo añadir hardware

Señales que indican que el nodo se ha quedado pequeño:

TTFT p95 sostenida > 500 ms durante horas de pico → el queue se está acumulando.
vllm:num_requests_waiting constantemente > 20 → admission control empezando a rechazar.
Utilización GPU sostenida > 80% en horas críticas sin caer abajo en horas valle → no hay margen.
Tasa de 429 sobre los tenants guaranteed > 1% → la plataforma rompe SLA en producción.

Cuando varios de estos se cumplan, el siguiente paso natural es añadir otro nodo HGX con NVLink interno y montar una segunda instancia vLLM del mismo modelo. El gateway hace load balancing entre las dos instancias. Throughput agregado se duplica; latencia se mantiene.

Trampas operativas comunes

Gateway sin auth: backdoor al cluster

Tu vLLM está en un Service ClusterIP, la app principal habla con él. Algún tenant directo descubre el endpoint y le pega directamente sin pasar por el gateway. Quotas y costs se evaden silenciosamente. NetworkPolicy estricta: solo el gateway puede hablar con los Service vLLM; el resto del cluster no.

MIG y NVLink incompatibles

Activas MIG en una GPU pensando que tendrás aislamiento + multi-GPU; descubres que MIG desactiva NVLink. Cualquier modelo grande con TP queda inservible. Decide MIG vs NVLink globalmente por cluster, no por GPU individual.

Quotas pegadas al techo del cluster

Sumas los TPM de todos los tenants y dan exactamente la capacidad del cluster. Cuando dos tenants pico simultáneamente, ambos esperan o uno rechaza. Overcommit 10-20% es saludable (asume que no todos pican a la vez); más es peligroso.

Sin observabilidad multi-tenant desde el día 1

Lanzas con quotas y aislamiento pero sin tenant_id en spans. A los 3 meses, tu CFO pregunta “¿cuánto cuesta el agente de soporte vs el de legal?” y no puedes responder. OTel con tenant_id obligatorio desde la primera versión, aunque no haya dashboards aún; tener los datos vale más que tener dashboards perfectos sin datos.

Showback que nunca llega a chargeback

Llevas 18 meses en showback, los equipos saben los números, nadie cambia comportamiento. Sin la presión del chargeback real, el incentivo se diluye. Calendario explícito para la transición a chargeback, con dueño y deadline.

Modelos no whitelisteados consumiendo presupuesto

Un equipo descubre que LiteLLM tiene gpt-4o configurado. Lo usa sin permiso. El budget se quema en API externa cuando la idea era usar el self-hosted barato. Whitelist explícita por team de modelos accesibles.

Priority classes mal calibradas

Todo el mundo se declara “guaranteed”. En el primer pico, no queda nada por degradar y todo sufre. Priority classes solo para casos críticos con justificación. La mayoría debería ser best-effort.

Sin failover desde el gateway

Tu vLLM se cae. El gateway no tiene fallback configurado y devuelve 503 a todos los tenants. Fallback configurado a otro modelo, idealmente externo (OpenAI) para cargas guaranteed, aunque pague más por hora — la disponibilidad vale más que el coste por hora.

Roadmap operativo de arranque

Si parte de cero con un nodo GPU vacío, el orden mínimo es el siguiente. Cada hito es un día de trabajo con margen, no apretado:

Día 1-2 — Infra base K8s. NVIDIA GPU Operator + nvidia-device-plugin + dcgm-exporter + NetworkPolicies cluster-default. Validación: un pod básico con nvidia.com/gpu: 1 se schedulea.

Día 3 — vLLM con un modelo grande y tensor parallel del nodo entero. Helm chart de vLLM Production Stack (o vLLM bare manifests). Pesos del modelo en PVC compartido (CephFS o NFS). Validación: una petición curl contra el Service interno responde.

Día 4 — AI Gateway: LiteLLM. Helm chart, Postgres para budgets, master key, primer model_list pointing a vLLM. Validación: una petición OpenAI-compatible vía LiteLLM responde con el mismo contenido que el vLLM directo.

Día 5 — Multi-tenancy básica. Crear teams, API keys, budget, model whitelist. Probar con dos teams. Validación: el segundo team usando el modelo que no tiene whitelisteado recibe 403.

Día 6 — Observabilidad mínima. Prometheus + Grafana scraping vLLM y LiteLLM. Dashboard con TTFT, TPOT, throughput, num_requests_waiting, budget_consumed_per_team. Validación: visible en Grafana con datos reales.

Día 7-8 — Cliente piloto. Un tenant real (idealmente uno interno controlado) empieza a usar. Mide latencias reales, descubre los primeros incidentes operativos.

Día 9-10 — Tuning. Ajustar --max-num-seqs, --gpu-memory-utilization, priority classes, quotas según lo aprendido del piloto.

Día 11-14 — Onboarding del segundo tenant + iteración. Repeat. Cada nuevo tenant onboarded revela nuevos casos.

A las dos semanas tienes una plataforma operacional con dos tenants reales y datos para decidir si está lista para más. La línea de avance de aquí en adelante es horizontal (más tenants) hasta saturar; a partir de ahí, vertical (más hardware).

Lo que no hemos cubierto (próximos posts)

Fine-tuning continuo en producción (post 6, decidido): LoRA/QLoRA/DPO, dataset curation, eval gates, A/B versioning con tráfico real entre versiones del modelo.
Constitutional AI y alignment runtime: opción que sigue en la mesa.
Edge LLMs: cuando un cluster H100 es demasiado caro para una carga concreta, modelos distillados corriendo en NPUs o GPUs consumer.
GPU networking deep dive: NCCL, InfiniBand, GPUDirect, RDMA. Para clusters multi-nodo con tensor parallel cross-host.

Referencias

Multi-tenancy y aislamiento GPU:

Multitenant GPU Infrastructure: 4 Powerful Design Rules — survey de patrones enterprise.
Run Multiple LLMs on One GPU: MIG, Time-Slicing, and MPS Guide (Spheron).
A Practical Guide to GPU Partitioning with MIG (Medium).
GPU Partitioning for AI Workloads: NVIDIA MIG with SUSE Virtualization (KubeCon EU 2026).
Predictable LLM Serving on GPU Clusters (arxiv 2508.20274).
Token Management in Multi-Tenant AI Inference Platforms (arxiv 2603.00356) — paper de priority + admission control.

AI Gateways:

FinOps multi-tenant:

Cross-references:

Posts previos serie 4: Panorama MLOps LLMs, RAG sobre Kafka, Pipeline de 6 etapas, PostgreSQL + Qdrant.
Posts relevantes de la serie inferencia: vLLM en Kubernetes — el escenario de nodo HGX multi-GPU que aquí desarrollamos. Operators LLM K8s — vLLM Production Stack y OME que el gateway puede dirigir.
Observabilidad: Evals, MCP observability, eBPF + drift.

Operators de inferencia LLM en Kubernetes: OME, vLLM Production Stack, NVIDIA Dynamo y llm-d

Mon, 18 May 2026 17:00:00 +0200

TL;DR

Servir un LLM en producción no es ejecutar un binario: es coordinar un modelo (decenas de gigabytes que tardan minutos en cargar), un runtime (vLLM, SGLang, TensorRT-LLM con cien flags), GPUs heterogéneas (NVLink, MIG, PCIe), prefill y decode que viven mejor separados, un cache de KV que quiere offloading a tiers más fríos, routing inteligente que aproveche prefix caching, y autoscaling que reaccione a métricas que no son CPU%. Un Deployment plano de Kubernetes solo cubre el primer 20% de esto. El otro 80% lo cubren los operators de inferencia LLM, que en 2026 son cuatro relevantes: OME (LMSYS, julio 2025, multi-engine con foco en SGLang), vLLM Production Stack (Helm chart curado del propio vLLM con LMCache para tiered KV), NVIDIA Dynamo (sucesor oficial de Triton, multi-engine, scheduler propio Grove) y llm-d (donación CNCF de marzo 2026 por Red Hat + Google + IBM + CoreWeave + NVIDIA, sobre vLLM, foco en escala distribuida). Detrás de los cuatro está KServe, el operator madre del CNCF que normalizó el concepto de InferenceService y sobre el que varios se apoyan. Este artículo recorre la jerarquía completa, da un mapa de decisión y enseña a no perderse cuando alguien suelte siete siglas en la primera reunión.

Este artículo cierra la serie de inferencia LLM. Los anteriores fueron KV cache: la memoria de trabajo que sostiene la inferencia LLM, vLLM en Kubernetes: la pieza de inferencia LLM que sí escala y PagedAttention por dentro y el estado del arte del KV cache en 2026. Allí explicamos qué pasa dentro de un proceso de inferencia. Aquí explicamos cómo se coordinan muchos procesos de inferencia a través de Kubernetes.

La analogía: de `init.d` a systemd a operators

El que lleva 20 años en sysadmin reconocerá el patrón. Hace décadas, arrancar un servicio en Linux era un script shell en /etc/init.d/: start, stop, status, recargado a mano. Cuando los servicios se hicieron más complejos —dependencias entre ellos, monitorización, restart on failure, slots por usuario— se hizo evidente que un script no bastaba. Llegó systemd, que convirtió “un servicio” en una unidad declarativa con dependencias, recursos, restart policy, sockets, timers. El script no desapareció; se subió un nivel de abstracción.

Kubernetes hizo el mismo movimiento para servicios distribuidos. Un Deployment declara “quiero N réplicas de este contenedor”; un Service declara “estas réplicas se exponen así”; un Ingress declara “este tráfico HTTP entra aquí”. El controller traduce la declaración en estado real y mantiene el sistema convergente.

Servir LLMs en 2024 era el equivalente al /etc/init.d/: cada equipo escribía sus Deployment/Service/HPA con scripts customizados de carga de modelo, drenaje de sesiones, manejo de GPU. Lo cubrimos en el artículo de vLLM en Kubernetes: se puede hacer, y de hecho funciona, pero es repetitivo, frágil y nadie está extrayendo las abstracciones correctas. Servir LLMs en 2026 ha vivido la misma transición que los servicios: ha aparecido el equivalente a systemd —los operators de inferencia— que normalizan las abstracciones y dejan al ingeniero declarar lo importante: “este modelo, con este runtime, así de escalable, con esta política de routing”.

Hay cuatro operators relevantes en 2026 y un quinto antecesor común. Vamos por orden.

Por qué un operator, y no solo un Deployment

Listar lo que un operator de inferencia aporta sobre un Deployment plano es la mejor manera de entender qué problema resuelve:

Modelo como ciudadano de primera clase. En un Deployment, el modelo es “lo que descargas en un initContainer y montas como volumen”. En un operator, el modelo es una CustomResource con metadatos (origen, fingerprint, licencia, GPU requirements). Pueden compartirse entre InferenceServices, versionarse, replicarse a múltiples nodos. Es la diferencia entre “un fichero” y “un artifact gestionado”.

Runtime como ciudadano de primera clase. Idem para el runtime (vLLM/SGLang/TRT-LLM): no es “una imagen Docker con flags”; es una ServingRuntime que declara qué args acepta, qué métricas exporta, qué tipos de despliegue soporta (single-node, multi-node TP, PD-disag). Cambiar de runtime es cambiar una referencia, no reescribir todos los manifests.

Composición declarativa. Una InferenceService (CRD nuclear de KServe y descendientes) referencia un modelo y un runtime, declara la política de escalado, enlaza observabilidad, configura routing. El controller compone todas las piezas: Deployment(s), Service, HPA, eventualmente LeaderWorkerSet, ScaledObject de KEDA, HTTPRoute de Gateway API. Tú declaras intención; el operator emite los 8 recursos derivados.

Prefill–decode disaggregation operacional. Como vimos en el artículo de PagedAttention, separar prefill y decode en pools distintos puede dar 7× goodput. Modelar eso con Deployments planos es viable, pero requiere coordinar dos sets de pods, un transport para mover KV cache, routing condicional. Un operator lo modela como una sola InferenceService con dos sub-pools.

Autoscaling con métricas LLM. El HPA estándar no entiende vllm:num_requests_waiting. Un operator integra KEDA o Prometheus Adapter automáticamente y expone las métricas correctas como knobs del CRD.

Multi-tenancy. Múltiples modelos en el mismo cluster, con cuotas, prioridades y fairness. Un Deployment por modelo escalando independientemente está bien hasta el quinto modelo; a partir de ahí, la coordinación de GPUs entre tenants se vuelve operationally hostil.

Lifecycle del modelo. Pesos en PVC compartido, calentamiento del primer pod, rolling updates con maxUnavailable: 0, drenaje de sesiones activas, observabilidad integrada. Cosas que en Deployment plano hay que reinventar en cada equipo.

Si tu carga es un modelo, un nodo, hasta tres réplicas, un Deployment plano basta y un operator es overkill. Si tu carga es dos o más modelos, escalado serio, disaggregation o multi-tenancy, un operator deja de ser opcional.

KServe: el antecesor común

Antes de los cuatro nuevos, hay que mencionar a KServe, que es el operator madre del que descienden conceptualmente todos los demás. Nació como KFServing dentro del proyecto Kubeflow en 2019, pasó a llamarse KServe al independizarse en 2021, y en 2025 fue aceptado en la CNCF como proyecto incubando hacia graduado.

La contribución conceptual de KServe es el CRD InferenceService, que se ha convertido en el vocabulario común del campo: un objeto K8s declarativo que une un model (origen + metadata) con un predictor (runtime + recursos) y produce un servicio HTTP listo. Bajo el capó, el controller emite Deployments, Services, HorizontalPodAutoscalers, Knative Services si haces serverless, Istio VirtualServices si haces traffic splitting.

KServe fue diseñado en una era pre-LLM: sus primeros casos de uso eran modelos scikit-learn, TensorFlow y PyTorch tradicionales servidos como REST APIs simples. Eso le da fortalezas (es maduro, lleva 6 años en producción en Bloomberg, JPMorgan y otros) y debilidades (no fue diseñado para gestionar tensor parallel multi-nodo, prefill–decode disaggregation, ni los patrones específicos de LLMs).

La forma en la que el ecosistema ha reaccionado es elegante: los nuevos operators de LLM heredan o se inspiran en InferenceService pero extienden la API con primitivos específicos de LLM. OME es el ejemplo más claro: usa el nombre InferenceService y la idea de “modelo + runtime → servicio”, pero añade BaseModel, ServingRuntime con flags LLM-aware, y modos de despliegue (PD-disag, multi-node) que KServe no contempla nativamente.

OME (Open Model Engine)

OME lo publicó el equipo de LMSYS en julio 2025 (anunciado en su blog). Es un operator que entiende SGLang en profundidad (es su runtime de primera clase) pero también soporta vLLM, TensorRT-LLM y Triton.

La jerarquía de CRDs

OME modela el dominio con cuatro CRDs principales:

BaseModel y ClusterBaseModel: el modelo en sí. Define origen (Hugging Face, S3, URL), fingerprint, metadatos. La versión Cluster* es global; la BaseModel es namespaced. Permite que múltiples InferenceService referencien el mismo modelo sin duplicar la descarga.
FineTunedWeight: adapters LoRA o pesos finetuneados que se sirven encima de un BaseModel. Crítico para multi-tenant donde cada cliente tiene su finetune.
ServingRuntime y ClusterServingRuntime: el runtime (vLLM, SGLang, etc.) con su configuración. Declara qué args acepta, qué métricas exporta, qué modos de despliegue soporta.
InferenceService: la pieza central, declarativa, que une BaseModel + ServingRuntime + infraestructura.

apiVersion: ome.io/v1beta1
kind: InferenceService
metadata:
 name: llama3-70b-prod
 namespace: inference
spec:
 model:
 name: meta-llama-3-70b-instruct  # referencia a un BaseModel
 runtime:
 name: sglang-h100  # referencia a un ServingRuntime
 deploymentMode: PrefillDecodeDisaggregated  # standard | PD | MultiNode | Serverless
 prefill:
 minReplicas: 2
 maxReplicas: 8
 resources:
 requests:
 nvidia.com/gpu: 4
 decode:
 minReplicas: 4
 maxReplicas: 16
 resources:
 requests:
 nvidia.com/gpu: 1
 router:
 type: cache-aware  # SGLang router con cache awareness
 autoscaling:
 metricSource: keda
 metrics:
 - type: prometheus
 metricName: vllm_requests_waiting
 threshold: "10"

Esto es lo que el operador toma como entrada. La salida son aproximadamente 8 recursos derivados que serían un horror declarar a mano: dos LeaderWorkerSets (uno por pool prefill/decode), dos Services, un Deployment para el router, ScaledObjects de KEDA por cada pool, HTTPRoute de Gateway API, y un PriorityClass que conecta con Kueue para gang scheduling.

Los cuatro modos de despliegue

OME materializa la InferenceService de forma distinta según deploymentMode:

Standard: un Deployment con N réplicas; clásico. Para modelos pequeños o single-GPU.
PrefillDecodeDisaggregated: dos pools coordinados; el router de SGLang los enruta.
MultiNode: tensor parallel sobre múltiples nodos vía LeaderWorkerSet, con NCCL/InfiniBand. Para modelos >70B donde un solo nodo no llega.
Serverless: Knative-style scale-to-zero. Para cargas esporádicas donde el coste de mantener GPUs encendidas no compensa. Trade-off: el primer request paga el coste de cold start del modelo (minutos).

Integración con el ecosistema K8s

OME no inventa primitivos donde ya existen. Se apoya en:

Kueue para gang scheduling: todos los pods de un tensor parallel deben arrancar a la vez o ninguno; Kueue lo garantiza.
LeaderWorkerSet (LWS) para multi-nodo: workers se unen al cluster Ray del leader, ciclo de vida atómico (caída de uno reinicia el grupo).
KEDA para autoscaling por métricas Prometheus específicas de LLM (queue depth, GPU cache usage, TTFT p95).
Gateway API y su Inference Extension para routing avanzado (model-aware, prefix-aware, weighted canary).

La consecuencia: OME se siente “idiomáticamente Kubernetes”. No introduce conceptos nuevos donde no hace falta; usa primitivos estándar y se concentra en lo específico del dominio LLM.

Cuándo elegirlo

OME es la opción natural si SGLang es tu runtime principal y/o si vienes del ecosistema KServe y quieres una evolución idiomática. Es maduro pero relativamente joven (un año en el momento de este artículo); espera bordes ásperos en features avanzadas.

vLLM Production Stack

vLLM Production Stack es el proyecto oficial del propio vLLM para producción en Kubernetes. Su filosofía es opuesta a la de OME: en lugar de un operator con CRDs nuevos, es un Helm chart curado que despliega un conjunto coherente de piezas.

Las tres piezas

El stack tiene tres componentes:

Serving engines: pods de vLLM, configurados con los flags que llevamos viendo en toda la serie (--enable-prefix-caching, --kv-cache-dtype fp8, etc.). El Helm chart te deja declararlos como una lista; despliega los Deployments y Services subyacentes.
Request router: un proxy delante de los engines que decide a cuál enviar cada petición. Soporta varias políticas:
- Round-robin: trivial, para baseline.
- Session-based: clava cada sesión a una réplica para mantener su KV cache.
- Prefix-aware: detecta prefijos compartidos entre peticiones y las enruta a la réplica que ya los tenga cacheados.
- KV-aware: ve el gpu_cache_usage_perc de cada réplica y evita las saturadas.
- Disaggregated-prefill con LMCache nativo: separa prefill y decode con LMCache como transport del KV cache entre ambos.
Observability stack: Prometheus + Grafana con dashboards listos. Mide TTFT, TBT (Time-Between-Tokens), throughput, queue depth, GPU memory.

LMCache y el tiered KV

Una de las piezas más interesantes que mete el stack es LMCache, que añade un caché de KV con múltiples tiers: GPU HBM como L1, CPU RAM como L2, disco local como L3, y opcionalmente storage remoto como L4. Cuando un bloque de KV cache no cabe en HBM, en lugar de evictarlo y recalcularlo, LMCache lo baja a un tier inferior. Para cargas con prefijos compartidos y multi-turn, el ahorro es brutal.

LMCache se integra como sidecar de los engines y como parte del transport en disaggregated-prefill. El Production Stack lo trae habilitado por defecto en su Helm chart.

Manifest típico (values.yaml)

servingEngineSpec:
 modelSpec:
 - name: llama3-8b
 repository: vllm/vllm-openai
 tag: v0.6.3
 modelURL: meta-llama/Meta-Llama-3-8B-Instruct
 replicaCount: 3
 requestCPU: 4
 requestMemory: 16Gi
 requestGPU: 1
 vllmConfig:
 enablePrefixCaching: true
 kvCacheDtype: fp8
 maxModelLen: 32768
 enableChunkedPrefill: true

routerSpec:
 routingLogic: prefix-aware  # round-robin | session | prefix-aware | kv-aware
 sessionKey: x-user-id  # cuando routingLogic=session

cacheserverSpec:
 enabled: true # LMCache para tiered KV
 storageBackends:
 - cpu
 - disk  # offload a disco local

observabilitySpec:
 prometheus:
 enabled: true
 grafana:
 enabled: true
 dashboards:
 - vllm-engine-metrics
 - lmcache-metrics

Esto es declarativo pero no son CRDs: son valores de un Helm chart. La diferencia con OME no es semántica (ambos parten de declaración) sino operacional: con Helm, los cambios pasan por helm upgrade; con CRDs, pasan por kubectl apply. Para equipos que ya viven en GitOps con Argo CD o Flux, ambos enfoques se integran limpiamente, pero los flujos son distintos.

Cuándo elegirlo

Si tu único runtime es vLLM y quieres lo más cercano a “el camino feliz que recomienda el proyecto”, esto. Es la versión productivizada y mantenida por la misma gente que escribe el motor. Las desventajas: ata a vLLM (no es genérico) y no resuelve algunos casos avanzados como multi-tenancy con cuotas estrictas o gang scheduling, donde OME u operators full-fledged son superiores.

NVIDIA Dynamo

NVIDIA Dynamo es el sucesor oficial de Triton Inference Server, anunciado en GTC 2025 y fusionado con la marca como Dynamo-Triton en marzo de ese año. Triton llevaba años siendo el motor de inferencia más usado en infraestructuras NVIDIA “serias”; Dynamo es lo que NVIDIA cree que la nueva generación necesita.

Qué es exactamente

Dynamo es un framework de inferencia distribuida, no exactamente un operator de Kubernetes. Tiene runtime propio (puede correr engines), scheduler (Grove), routing inteligente, gestión de KV cache multi-tier y disaggregation. Soporta como engines a SGLang, TensorRT-LLM y vLLM, pero los engines son ejecutados por Dynamo, no a la inversa: el modelo es “Dynamo gestiona, el engine ejecuta”.

En Kubernetes, Dynamo se despliega vía operator + CRDs propios, normalizados con la integración K8s que NVIDIA formalizó a finales de 2025 (la cubre esta nota de InfoQ). Los CRDs son específicos del producto: definen un DynamoCluster, una topología de prefill/decode workers, una política de routing.

Las cuatro contribuciones

Dynamo se vende sobre cuatro pilares, con números reportados por NVIDIA:

Disaggregated serving built-in con scheduler propio.
Smart routing basado en estado de cache: si un worker ya tiene cacheada la mayoría de un prompt, la petición va ahí.
Multi-tier KV cache: análogo a LMCache, con HBM/RAM/SSD/NVMe.
Autoscaling integrado con el scheduler de Dynamo.

El número marketing: hasta 30× más throughput que Triton legacy en el mismo hardware. Con todas las precauciones que merece un benchmark de vendor.

Grove: scheduler propio

Una decisión polémica de Dynamo es no apoyarse al 100% en el scheduler de Kubernetes y, en su lugar, traer un scheduler propio llamado Grove que entiende topologías de GPU. Grove decide qué worker corre en qué GPU física, qué interconexiones (NVLink/InfiniBand) son relevantes, y cómo distribuir tensor parallel entre nodos. Esto le da más control que kube-scheduler estándar.

Operacionalmente: si tu cluster es “puro Kubernetes” con kube-scheduler y workloads heterogéneos (no solo LLMs), Grove añade un componente adicional a operar. Si tu cluster es dedicado a inferencia LLM y ya hay equipo dedicado a operarlo, Grove te da más palancas.

Cuándo elegirlo

Dynamo tiene sentido si:

Tu infraestructura es NVIDIA-heavy (Hopper, Blackwell, GB200) y quieres aprovechar lo más reciente de TensorRT-LLM con la integración de Triton-de-toda-la-vida pero modernizado.
Ya eras usuario de Triton para inferencia legacy (visión, recomendación) y quieres mantener el ecosistema.
Tienes equipo SRE dedicado a inferencia y la complejidad operacional adicional de Grove no es un problema.

Es la opción vendor-specific del cuarteto. A cambio te da el soporte de NVIDIA y la integración de primera con su hardware. Si tu organización ya pelea con NVIDIA por GPUs, igual te llaman para ofrecer asistencia con Dynamo.

llm-d

llm-d es el más joven y el más “político” de los cuatro. En marzo de 2026, en KubeCon Europe Amsterdam, Red Hat, Google Cloud, IBM Research, CoreWeave y NVIDIA anunciaron la donación conjunta del proyecto a la CNCF como Sandbox, con soporte de AMD, Cisco, Hugging Face, Intel, Lambda, Mistral AI, UC Berkeley y University of Chicago. Una coalición de vendor-neutralidad explícita.

Filosofía

llm-d se posiciona como el “Kubernetes blueprint” vendor-neutral para inferencia distribuida. No es un runtime; es un sistema que se monta encima de vLLM (motor por defecto) y orquesta el plano de control.

Las primitivas que el proyecto pone sobre la mesa:

Routing inteligente con prefix-cache awareness y load-aware balancing.
Tiered KV cache con offload a CPU y disco para multi-turn.
Prefill/decode disaggregation sobre interconnects rápidos.
Wide expert-parallelism para servir Mixture-of-Experts (MoE) muy grandes —un patrón crítico que DeepSeek-V3 y Mixtral popularizaron— donde los expertos viven en distintas GPUs y hay que enrutar tokens al experto correcto.

Números

El release v0.5 valida ~3.1k tok/s por GPU de decode B200, y hasta 50k output tok/s en una topología 16×16 B200 prefill/decode. El benchmark más interesante: orden de magnitud de reducción de TTFT vs una baseline round-robin. Es decir, el routing inteligente vale lo que se dice.

CNCF y futuro

Donar a la CNCF como Sandbox significa gobernanza neutral: ningún vendor manda. Para una organización que recela de quedar atado a un único proveedor, llm-d es probablemente la apuesta más segura a medio plazo. El precio: como cualquier proyecto Sandbox, todavía no es “boring” en el sentido en que vLLM lo es. Hay churn de API, features que se mueven, documentación que va por detrás del código.

Cuándo elegirlo

llm-d tiene sentido si:

Quieres portabilidad multi-vendor sin ataduras a NVIDIA, Red Hat o Google.
Tu carga incluye MoE grandes (DeepSeek-V3, Mixtral 8x22B, Llama 4 Behemoth si confirma tamaño), donde wide expert parallelism es decisivo.
Tu organización ya está cómoda con CNCF Sandbox (proyectos en evolución activa, no aún 1.0 estable).
Quieres apostar por el proyecto que probablemente sea el estándar de facto en 2-3 años.

El antecesor común sigue ahí: KServe

Vale la pena reconectar antes de la comparativa: KServe sigue vivo y muy usado en organizaciones que sirven tanto LLMs como modelos tradicionales (scikit-learn, XGBoost, PyTorch CV). Su InferenceService es lo bastante genérico como para servir cualquier modelo, incluyendo vLLM o SGLang como ServingRuntime. Lo que no hace bien es lo específico de LLM: disaggregation, tensor parallel multi-nodo, routing con awareness de KV cache. Si tu organización ya tiene KServe en producción para otros modelos, añadir un operator específico de LLM al lado (OME, vLLM Stack o llm-d) es razonable. Pelearlo todo desde KServe puro no.

Mapa de decisión

Dimensión	OME	vLLM Prod Stack	NVIDIA Dynamo	llm-d
Filosofía	Operator clásico K8s-idiomático	Helm chart curado	Framework con scheduler propio	Blueprint CNCF vendor-neutral
CRDs propios	Sí (BaseModel, ServingRuntime, InferenceService…)	No (Helm values)	Sí (DynamoCluster)	Sí (KServe-derived + extensions)
Runtime primario	SGLang (primera clase), también vLLM/TRT-LLM/Triton	vLLM exclusivamente	TensorRT-LLM (primera clase), también SGLang/vLLM	vLLM (primera clase)
PD-disaggregation	Sí, declarativo	Sí, con LMCache	Sí, scheduler propio	Sí, nativo
Multi-nodo TP	Sí, via LWS	Limitado	Sí, via Grove	Sí, via LWS y MoE EP
Multi-modelo en cluster	Sí, multi-tenant maduro	Sí (lista de modelos en values)	Sí	Sí
Multi-LoRA	Sí, primera clase (FineTunedWeight CRD)	Limitado	Sí	En roadmap
Tiered KV cache	Vía LMCache (integración externa)	LMCache nativo	Multi-tier propio	Sí, nativo
Routing inteligente	Cache-aware via SGLang router	Prefix-aware / KV-aware / session-based	Smart routing propio	Prefix-cache + load-aware
Scheduler GPU	kube-scheduler + Kueue	kube-scheduler	Grove (propio)	kube-scheduler + Kueue
Hardware	NVIDIA, AMD ROCm, Intel	NVIDIA, AMD ROCm	NVIDIA exclusivo (con énfasis)	NVIDIA, AMD, Intel — neutral
Madurez (mid-2026)	Joven, en evolución	Estable	Estable, vendor-driven	CNCF Sandbox, evolución rápida
Gobernanza	LMSYS (académico-industrial)	vLLM project (académico)	NVIDIA (vendor)	CNCF (neutral)
Curva de aprendizaje	Media (4 CRDs nuevos)	Baja (Helm values familiar)	Media-alta (Grove + CRDs propios)	Media (similar a KServe extendido)

Cuándo elegir cada uno

Elige OME si:

SGLang es tu motor principal.
Necesitas multi-LoRA serving en producción.
Te encaja la abstracción jerárquica (BaseModel → ServingRuntime → InferenceService) y vienes de o convives con KServe.
Tienes appetito por un proyecto joven y muy activo.

Elige vLLM Production Stack si:

vLLM es tu único motor y quieres alinearte con lo que el proyecto recomienda.
Tu equipo ya vive en Helm y no quiere aprender CRDs nuevos.
LMCache + routing avanzado dentro de un solo Helm chart es exactamente lo que necesitas.
Tu escala es media (decenas de réplicas), no extrema.

Elige NVIDIA Dynamo si:

Tu infraestructura es NVIDIA-heavy y quieres el path más optimizado para Hopper/Blackwell.
Ya operabas Triton para inferencia legacy y la transición es natural.
Aceptas vendor lock-in a cambio de soporte directo NVIDIA.
Tu organización tiene equipo SRE dedicado a inferencia.

Elige llm-d si:

Quieres apostar por el estándar CNCF futuro, neutro entre vendors.
Tu carga incluye MoE grandes con wide expert parallelism.
Operas en multi-cloud o multi-hardware y la portabilidad es valiosa.
Aceptas la inmadurez de un proyecto Sandbox a cambio de la apuesta a futuro.

Elige KServe puro si:

Ya sirves modelos no-LLM y quieres unificar; los LLMs son una minoría de tu carga.
Necesitas el caso de uso más conservador y maduro.
Aceptas que features avanzadas de LLM (disaggregation, MoE EP, smart routing) te tocará añadirlas con piezas externas.

Escenarios concretos

Escenario A — Startup pequeña, 1-2 modelos, 1-3 nodos GPU. Probablemente no necesitas operator. Deployment + Service + HPA con métricas de KEDA, como en el artículo de vLLM en Kubernetes. Cuando crezcas a 5+ modelos, evalúa.

Escenario B — Empresa media, 5-15 modelos, multi-tenant interno. vLLM Production Stack o OME son las opciones razonables. Production Stack si vLLM es todo lo que vas a usar; OME si quieres flexibilidad de runtime y CRDs idiomáticos.

Escenario C — Plataforma interna corporativa o servicio externo a clientes finales. llm-d o Dynamo. llm-d si valoras vendor-neutralidad; Dynamo si vives en infraestructura NVIDIA y quieres el camino que ellos recomiendan.

Escenario D — Cluster mixto LLM + modelos tradicionales. KServe como base, operator de LLM al lado (OME es lo más natural por su parentesco conceptual).

Trampas comunes

“Voy a empezar con KServe puro porque es maduro”. Para LLMs medianos en adelante, KServe puro deja muchas optimizaciones sobre la mesa. Lo razonable es KServe como base si convives con otros modelos, pero operator LLM-específico al lado.

“Voy a montar todo a mano para entenderlo”. Razonable en PoC, suicida en producción. Hay 8 recursos derivados por modelo. Multiplica por 10 modelos. Estás escribiendo 80 YAMLs y manteniéndolos. Usa un operator.

“Voy a elegir el que más me gusta y luego pivoto si me equivoco”. Pivotar entre operators no es gratis: aunque la abstracción InferenceService se está homogeneizando, los detalles (cómo se modela LoRA, cómo se configura routing, cómo se exponen métricas) varían. Migrar de OME a Dynamo es un proyecto de semanas, no de días.

“Voy a poner Dynamo porque es de NVIDIA y mejor”. Solo si tu organización ya está alineada con su filosofía operacional (scheduler propio, vendor lock-in aceptable). Para muchos casos, vLLM Production Stack o llm-d dan 95% del valor con menos fricción.

“Helm chart vs operator es una decisión técnica”. Es una decisión cultural/operacional. Si tu equipo entrega vía Argo CD con Helm values en Git, Production Stack encaja sin fricción. Si tu equipo vive en kubectl apply -f directo y la idea de operators te resulta natural, OME o llm-d.

Lo que no hemos cubierto

Mooncake: el sistema de cache de KV compartido entre instancias que Kimi/Moonshot lleva en producción a cientos de millones de queries. Es un primitivo (no un operator completo), pero se integra como tier de cache con varios de los anteriores.
Ray Serve LLM: la oferta de Anyscale, en Kubernetes a través de KubeRay. Más vinculado al ecosistema Ray que a los CRDs nativos K8s. Útil si Ray ya es parte de tu infraestructura.
Fireworks AI, Modular MAX: plataformas comerciales con primitivos similares, pero hospedadas. No son operators K8s; son competidores en otra capa.
Gateway API Inference Extension: la propuesta sigwg para extender Gateway API con primitivos LLM (model-aware routing, sticky sessions, fairness). En 2026 está en alpha; los operators de arriba ya empiezan a soportarla. Cuando madure, el routing dejará de ser problema de cada operator y será parte del estándar de Kubernetes.
Inference observability stack genérico: Prometheus + Grafana se está estandarizando en torno a las métricas vllm:* que cubrimos en el artículo de vLLM. Hay esfuerzo de OpenTelemetry para LLMs (gen-ai semantic conventions) que probablemente sea el siguiente eslabón.

Cerrando la serie

Esta serie de cuatro artículos ha recorrido la inferencia LLM en producción de abajo arriba:

KV cache: la memoria de trabajo que sostiene la inferencia LLM — por qué cada token consume VRAM y cuánto.
vLLM en Kubernetes: la pieza de inferencia LLM que sí escala — cómo se sirve un modelo en producción con un Deployment serio.
PagedAttention por dentro y el estado del arte del KV cache en 2026 — qué pasa dentro del motor a nivel del bloque, y qué ha llegado después.
Este — cómo se orquestan muchos modelos en cluster.

Si has llegado aquí, tienes el vocabulario y el mapa para sentarte en una reunión donde cinco personas tiren siglas y reconocer cada una en su sitio. Y, lo más importante, para empezar a tomar decisiones razonadas sobre por dónde empezar.

Referencias

Operators y proyectos cubiertos:

OME — Open Model Engine (GitHub) — operator de LMSYS para LLM serving con SGLang/vLLM/TRT-LLM/Triton.
Introducing OME (LMSYS Blog, jul 2025) — anuncio y arquitectura.
vLLM Production Stack (GitHub) — Helm chart oficial de vLLM para K8s.
vLLM Production Stack docs — instalación y configuración.
LMCache (GitHub) — caché de KV con tiers.
NVIDIA Dynamo — sucesor de Triton.
NVIDIA Dynamo Addresses Multi-Node LLM Inference Challenges (InfoQ, dic 2025) — integración K8s.
llm-d (GitHub) — proyecto CNCF Sandbox.
IBM, Red Hat, and Google donated llm-d to CNCF (The New Stack) — anuncio KubeCon EU 2026.
Red Hat bets big on Kubernetes inference with llm-d (SiliconANGLE, mar 2026) — cobertura del anuncio.

Antecesores y primitivos:

KServe (sitio) y KServe joins CNCF (The New Stack).
Kueue — gang scheduling.
LeaderWorkerSet — workloads coordinados como tensor parallel multi-pod.
KEDA — autoscaling por métricas externas.
Gateway API — sucesor del Ingress.

Análisis y perspectivas:

Building Efficient LLM Inference with the Cloud Native Quartet: KServe, vLLM, llm-d, and WG Serving (Jimmy Song) — visión integradora.
Complete Guide to llm-d CNCF Sandbox (DEV Community) — walkthrough operacional.
Artículos previos en este blog: KV cache, vLLM en Kubernetes, PagedAttention deep dive.

PagedAttention por dentro: bloques, tabla de páginas, evicción y el estado del arte del KV cache en 2026

Mon, 18 May 2026 15:00:00 +0200

TL;DR

PagedAttention (Kwon et al., SOSP 2023) fue la idea que convirtió la gestión del KV cache de un problema de malloc clásico —reservar contiguo, malgastar el 60-80%— en un problema resuelto como lo resuelven los sistemas operativos desde hace medio siglo: bloques pequeños de tamaño fijo, una tabla de páginas por proceso, asignación bajo demanda. El paper midió un desperdicio menor al 4% y 2-4× más throughput agregado en el mismo hardware. Tres años después, PagedAttention sigue siendo el modelo mental dominante, pero su implementación literal ya no es la de ningún sistema de inferencia serio: la propia documentación de vLLM califica al paper original de “documento histórico”. Han llegado vAttention (paginar usando la MMU de CUDA, no la indirección software), EvicPress (combinar compresión y evicción), KVTC (transform coding del cache), LaProx (evicción como aproximación matricial), disaggregated serving (prefill y decode en GPUs distintas, en producción en NVIDIA Dynamo, llm-d, Mooncake y media docena más), RadixAttention de SGLang (trie de prefijos compartidos, con hit rates del 85% en cargas de agentes) y la nueva generación de speculative decoding (EAGLE-3, DeepSeek MTP, Mirror Speculative). Este artículo desmonta PagedAttention al nivel del bloque, explica qué hace vLLM hoy en su lugar, y traza el mapa del estado del arte para que no te pierdas eligiendo entre quince siglas en la primera reunión.

Este artículo cierra una mini-serie. El primero —KV cache: la memoria de trabajo que sostiene la inferencia LLM— explicó por qué cada token consume VRAM. El segundo —vLLM en Kubernetes: la pieza de inferencia LLM que sí escala— mostró cómo se sirve eso en producción. Éste baja al fondo: cómo se gestiona el cache dentro del motor, y qué hay después de PagedAttention.

La analogía: pasar de `malloc()` al kernel multiproceso

Un programa C ingenuo pide memoria con malloc(N) y recibe un bloque contiguo de N bytes. Si pide muchos bloques de tamaños distintos y los libera en cualquier orden, el heap se llena de huecos: hay tres megabytes libres en total, pero ningún hueco contiguo de un megabyte, y el siguiente malloc(1MB) falla. Fragmentación externa. Si reserva siempre el peor caso “para estar seguro” —malloc(MAX_POSSIBLE_SIZE)— el heap se queda lleno con bloques medio vacíos. Fragmentación interna.

Los sistemas operativos modernos no permiten que eso pase con la memoria virtual de un proceso. La memoria virtual se divide en páginas (4 KB típicamente), cada una asignada a un marco físico en RAM mediante una tabla de páginas específica del proceso. El proceso ve un espacio contiguo enorme; el SO lo respalda con marcos físicos dispersos, asignados bajo demanda y liberados cuando dejan de usarse. El concepto tiene 50 años y funciona.

Antes de PagedAttention, los motores de inferencia LLM eran programas C ingenuos. Cada sesión reservaba un bloque contiguo de KV cache dimensionado al peor caso max_context_len × bytes_per_token × n_layers × 2. Una conversación que usa 273 tokens reservaba sitio para 32 768. Cuando el motor servía 50 sesiones simultáneas, el 60-80% de la VRAM dedicada a KV cache estaba reservada y vacía. El paper de PagedAttention midió este desperdicio en cargas reales y propuso lo evidente: tratar el KV cache como memoria virtual. Bloques físicos pequeños (16 tokens), tabla de páginas por sesión, asignación bajo demanda. El resultado: < 4% de desperdicio, 2-4× más throughput agregado en el mismo hardware.

La idea no era nueva fuera del mundo LLM, era nueva dentro. Y eso vale como contribución: a veces traer una técnica madura de otro campo es más impactante que inventar algo desde cero.

El paper original, en cristiano

Kwon et al. publicaron Efficient Memory Management for Large Language Model Serving with PagedAttention en SOSP 2023 e implementaron simultáneamente vLLM, que en seis meses pasó de proyecto académico a “el motor de inferencia que todo el mundo usa”. Las tres aportaciones del paper, en orden de importancia:

Cuantificación del problema: medir el desperdicio en sistemas existentes y mostrar que el 60-80% de la VRAM se estaba quemando en peor-caso reservations que no se usaban.
El algoritmo de paging: cómo dividir el KV cache, qué tamaño de bloque elegir, cómo gestionar la tabla de páginas en GPU.
El kernel CUDA: cómo implementar la operación de atención cuando los tokens de una secuencia están dispersos por la VRAM, sin destruir el rendimiento.

El modelo de bloques

El KV cache se divide en bloques de tamaño fijo. La elección por defecto en vLLM es 16 tokens por bloque, decisión que el paper justifica con un barrido empírico: bloques más pequeños reducen la fragmentación interna pero aumentan el overhead de metadata y de indirección; bloques más grandes mejoran throughput pero pierden eficiencia. 16 es el punto razonable para los modelos y cargas medidas.

Cada bloque almacena los K y V de N tokens consecutivos de una sola sesión en una sola capa del modelo. Para un Llama 3 8B con 32 capas, una sesión de 128 tokens necesita aproximadamente 128 / 16 × 32 = 256 bloques (uno por capa por grupo de 16 tokens). Los bloques son lógicamente independientes entre sí: pueden vivir en cualquier dirección física de VRAM.

La tabla de páginas (block table)

Cada sesión tiene asociada una block table: una lista ordenada de identificadores de bloques físicos. Cuando vLLM calcula la atención para el token 200 de la sesión X, mira la block table de X, encuentra que el bloque que contiene el token 200 está en la posición 200 / 16 = 12 de la lista, lee qué bloque físico corresponde y va a buscarlo.

La block table vive en VRAM, no en RAM como la tabla de páginas del SO. Si viviese en CPU, cada paso de decode tendría que hacer una indirección PCIe, lo que mataría el throughput. Está en VRAM, junto al cache, y el kernel CUDA la lee como una estructura más durante el cómputo.

Cuando una sesión genera su token N-ésimo, vLLM mira si el último bloque de la block table aún tiene huecos (N mod 16 != 0). Si los tiene, escribe ahí. Si no, pide un bloque nuevo del pool global, lo añade al final de la block table y escribe en su primera posición. Crecer la sesión cuesta una asignación O(1) en el pool global más una append O(1) a la block table. Liberar una sesión devuelve sus bloques al pool: también O(N_bloques) y rapidísimo.

El pool de bloques

El pool global se dimensiona al arrancar el motor. Lo típico:

bloques_disponibles = (VRAM_total - modelo - activations - overhead) / block_size_bytes

Para una RTX 4090 (24 GB) sirviendo Llama 3 8B BF16 con cache también en BF16:

modelo: ~16 GB
activations: ~1.5 GB
overhead vLLM: ~1 GB
disponible para KV cache: ~5.5 GB
block_size = 16 tokens × 32 capas × 2 (K,V) × 8 KV heads × 128 head_dim × 2 bytes = 2 MB
bloques disponibles ≈ 5.5 GB / 2 MB ≈ 2800 bloques
tokens cacheables totales (todas sesiones) ≈ 2800 × 16 = 44800 ≈ 44 K tokens

Si una sola sesión pide 32 K tokens, ocupa 2 000 bloques (de 2 800). Si las sesiones son más cortas, caben más simultáneas. El pool es un recurso compartido global, no per-sesión, y ahí está la clave del aprovechamiento.

Copy-on-write para sampling paralelo

Una sutileza elegante del paper: cuando una petición usa sampling paralelo o beam search, las N secuencias comparten el prefijo (el prompt + lo que se haya generado hasta el punto de divergencia). En lugar de duplicar el KV cache de ese prefijo, vLLM hace que las N secuencias compartan los bloques físicos vía la block table. Solo cuando una secuencia diverge —genera un token distinto que las otras— vLLM copia el último bloque afectado (no toda la secuencia) y la rama esa pasa a tener su propia versión.

Esto es exactamente lo que hace el kernel de Linux con fork(): copy-on-write de las páginas. La memoria solo se duplica cuando se modifica. En beam search con N=4 y prefijos largos, el ahorro es enorme.

El kernel CUDA

El reto técnico no obvio: el cómputo de atención debe seguir la indirección de la block table para cada token. En la versión naïve (cache contiguo), el kernel asume que los tokens 0..N-1 de la sesión X están en direcciones contiguas y los lee de un tirón. Con paging, los tokens 0..15 están en el bloque #7, los 16..31 en el #2, los 32..47 en el #11, etc.

El kernel paged_attention de vLLM resuelve esto con block-aware tiling: divide el cómputo de atención en chunks alineados con el tamaño de bloque (16 tokens), y para cada chunk localiza el bloque físico vía la block table y lo procesa. Es más complejo que el kernel contiguo, pero el coste medido es solo 5-10% de latencia adicional frente a la operación contigua equivalente, contra una ganancia de 2-4× en throughput agregado por la mejor utilización de VRAM. Compromiso aplastante.

Evicción y preemption: qué hace cuando el pool se agota

El KV cache crece. Cada token nuevo en cualquier sesión consume bloques. En un servidor con tráfico alto, el pool global se vacía. ¿Qué hacer cuando llega una nueva petición y no hay bloques libres?

Tres opciones: rechazar la petición (mala UX), bloquear hasta que algo se libere (mala latencia), o expulsar alguna sesión existente para hacer sitio (preemption). vLLM elige la tercera, con dos estrategias seleccionables:

Estrategia 1: recompute

Cuando vLLM expulsa una sesión, libera todos sus bloques y la pone en cola de espera. Cuando vuelve a haber sitio (otras sesiones terminan), vLLM rehace el prefill entero de la sesión expulsada desde el prompt original. El KV cache se reconstruye desde cero.

Ventaja: liberación instantánea, no consume bandwidth de PCIe. Coste: la sesión rehace todo el cómputo del prefill, segundos o decenas de segundos para prompts largos.

Estrategia 2: swap

vLLM mueve los bloques de la sesión expulsada a RAM de CPU (vía PCIe), liberando la VRAM. Cuando la sesión vuelva a tocar, vLLM la trae de vuelta a VRAM.

Ventaja: conserva el cache, no rehace cómputo. Coste: tiempo de transferencia PCIe (~32 GB/s en PCIe gen4 x16). Mover 4 GB de KV cache cuesta ~125 ms ida y vuelta.

vLLM elige entre las dos en función del tamaño del cache de la sesión y de la latencia esperada. Para sesiones cortas, recompute suele ganar; para sesiones largas con prompts grandes, swap. Es configurable con --swap-space.

El problema de la preemption agresiva

Hay un fallo de modo: si el sistema está saturado y vLLM no para de expulsar y reincorporar las mismas sesiones, todas hacen poco progreso y el throughput se hunde. Este es thrashing, exactamente el mismo problema que tiene un SO cuando la presión de paginación es muy alta.

La solución operativa es la misma que en SO: admission control. Configurar --max-num-seqs para limitar cuántas sesiones puede atender vLLM simultáneamente. Si llegan más, esperan en la cola HTTP. Mejor tener 10 sesiones avanzando rápido que 100 thrasheando.

Lo que vLLM hace hoy: más allá del paper original

La documentación oficial de vLLM señala que el paper de PagedAttention es ya un documento histórico que ya no describe la implementación actual. ¿Qué ha cambiado?

Chunked prefill integrado con paged KV

El kernel original asumía que el prefill ocupaba el batch entero un paso, y el decode ocupaba batches separados. El motor actual mezcla prefill (troceado en chunks) con decode en el mismo paso, usando el mismo paged KV cache para ambos. Esto mejora la utilización de tensor cores cuando hay pocas peticiones en prefill y muchas en decode.

Prefix caching cross-session

El paper original ya tenía copy-on-write para sampling paralelo en una sola petición. La extensión natural fue compartir bloques de prefijo entre peticiones distintas que llegan con el mismo system prompt. En vLLM se activa con --enable-prefix-caching. Es una versión más simple que la de SGLang (no usa radix tree explícito, hace hash de bloques) pero efectiva: 30-70% mejora de TTFT en cargas con prompts compartidos.

Sliding window attention

Modelos como Mistral 7B usan atención con ventana deslizante: solo atienden a los últimos K tokens (4 096 en Mistral). El motor mantiene únicamente los bloques de la ventana activa, liberando los más viejos. Esto cambia la economía: para esos modelos, el cache no crece sin límite.

FlashAttention-3 paged

Las versiones recientes de FlashAttention (especialmente FA-3) tienen kernels paged-aware optimizados para Hopper (H100). vLLM los usa por defecto en H100 cuando están disponibles, con ganancias adicionales del 15-30% sobre el kernel paged original.

vAttention: paging sin reescribir el kernel

El paper de vAttention (Prabhu et al., arxiv 2405.04437) hace una observación incómoda: el coste de PagedAttention no es solo el 5-10% del kernel. Hay dos costes ocultos:

Inadaptable a kernels nuevos: cada vez que sale una optimización de atención (FlashAttention-2, FlashAttention-3, kernel custom), hay que reescribir su versión paged. Eso ha hecho que vLLM frecuentemente esté 1-2 versiones por detrás del frente de FlashAttention.
Block tables en VRAM: pequeño pero constante. Para muchas sesiones, las block tables ocupan VRAM y cuestan accesos.

La propuesta de vAttention: usar CUDA Virtual Memory Management (VMM), las primitivas de virtual memory que NVIDIA expone desde CUDA 11.2. Con VMM puedes reservar un rango virtual contiguo enorme y asignar memoria física bajo demanda en porciones, mapeándolas en posiciones del rango virtual. El kernel de atención ve un rango contiguo (no necesita ser paged-aware); el runtime mete el paging dentro de la API de CUDA.

Resultado medido en el paper: hasta 1.99× decode throughput sobre vLLM con FlashAttention-2 original. Y el kernel de atención es el de FlashAttention estándar, sin modificar.

La idea es disruptiva porque sugiere que la abstracción del paper de PagedAttention era inadecuada: el problema nunca fue que el cache tenía que ser físicamente paginado, sino que la asignación tenía que ser dinámica. La forma de resolverlo es delegar el paging al hardware (MMU + VMM de CUDA), no implementarlo en software.

vAttention no ha desplazado a PagedAttention en vLLM por inercia y por consideraciones de portabilidad (VMM no está disponible en GPUs AMD ni Intel; PagedAttention sí). Pero los runtimes nuevos —y algunos forks de vLLM— ya lo están adoptando. Es plausible que en 2027 sea el default.

Compresión y evicción inteligente: lo que ha llegado en 2025-2026

PagedAttention y vAttention atacan dónde vive el cache. Otra línea de trabajo ataca qué vive en el cache: si no necesitas todo el KV de un contexto largo, ¿por qué guardarlo todo?

StreamingLLM (Xiao et al., 2024): los attention sinks

El precursor conceptual. Observación: los primeros 4 tokens de cualquier contexto reciben atención desproporcionada de los tokens posteriores, incluso cuando semánticamente no son relevantes (son “sinks” para que el softmax se normalice). Si descartas todo el cache excepto los primeros 4 tokens más una ventana deslizante de los últimos K, el modelo sigue generando con calidad razonable indefinidamente.

Impacto: permite contexto efectivamente infinito con cache acotado. Coste: olvido real del contenido medio.

H2O, SnapKV (2024): eviction por attention score

Variantes que mantienen un score acumulado de atención por token y, cuando el cache se llena, descartan los tokens con menor score. Son métodos por sesión, no por sistema: cada sesión decide qué partes de su propio cache descartar.

EvicPress (Microsoft Research, 2026)

El paper EvicPress: Joint KV-Cache Compression and Eviction for Efficient LLM Serving hace una observación elegante: hasta ahora, evicción y compresión se han tratado como técnicas separadas. Si vas a expulsar un bloque, ¿por qué no comprimirlo y guardarlo en RAM o NVMe en lugar de tirarlo? Y si lo tienes comprimido en un tier más lento, ¿cuándo merece la pena descomprimirlo y volver a HBM?

EvicPress modela el problema como optimización conjunta sobre múltiples tiers de almacenamiento (HBM, RAM, NVMe), aplica compresión lossy a los bloques candidatos a evicción y mantiene metadata para decidir cuándo trasladar de un tier a otro. Resultados: 2.19× faster TTFT a igual calidad de generación.

La idea importa porque cambia el framing: el KV cache deja de ser “está o no está” para pasar a ser “está, en qué tier, con qué fidelidad”. Es directamente análogo a la jerarquía de caches L1/L2/L3 en CPUs.

KV Cache Transform Coding (KVTC, 2026)

KV Cache Transform Coding for Compact Storage in LLM Inference (arxiv 2511.01815) aplica al KV cache una técnica clásica de compresión de imágenes y vídeo: transform coding, similar a DCT en JPEG/MPEG. Descompone los bloques de KV en una base de transformadas, descarta los coeficientes de menor energía y guarda el resto. Testeado con Llama 3, Mistral NeMo y R1-Qwen 2.5, supera a quantization (INT4) y a SVD como métodos de compresión del cache. Importante: el resultado es un cache comprimido reutilizable, no comprimido on-the-fly cada vez.

LaProx (2026)

LaProx: Reformulating KV Cache Eviction Problem for Long-Context LLM Inference (arxiv 2605.07234) reformula la evicción de KV cache. Hasta ahora la mayoría de métodos son head-wise y por promedios —miran scores por cabeza de atención y los promedian para decidir qué descartar—. LaProx la convierte en un problema output-aware y layer-wise: aproximar la multiplicación entre los attention maps y los projected value states como una matriz que se puede comprimir minimizando el error en la salida real del modelo, no en métricas auxiliares.

La consecuencia práctica: las decisiones de evicción mejoran porque están alineadas con lo que realmente afecta a la generación, no con un proxy.

Disaggregated serving: separar prefill de decode

PagedAttention y derivados optimizan un motor sirviendo peticiones mezcladas. La siguiente revolución conceptual fue darse cuenta de que prefill y decode no deberían correr en la misma GPU.

El problema de mezclarlos

Prefill es compute-bound: usa los tensor cores intensamente. Decode es memory-bound: mueve el KV cache a través del HBM. Si los mezclas en el mismo batch, una de las dos fases siempre va a ralentizar a la otra. Si entra una petición con prompt de 32 K tokens mientras hay 50 sesiones en decode, el prefill pausa a todas durante un segundo o más. Si llega una avalancha de prefills, los decodes en curso ven su latencia de token siguiente subir.

DistServe (Zhong et al., 2024)

DistServe (arxiv 2401.09670) propuso lo evidente: dedicar GPUs distintas a prefill y a decode. Las peticiones llegan a una GPU de prefill, que procesa el prompt y produce el KV cache inicial; ese KV cache se transfiere a una GPU de decode, que se encarga de generar los tokens uno a uno. Resultado: 7.4× más goodput, o el mismo throughput con SLO 12.6× más estrictos.

El truco no obvio es la transferencia del KV cache entre nodos. En GPUs con NVLink/NVSwitch del mismo nodo es trivial (~300 GB/s). Entre nodos con InfiniBand, el coste es manejable pero no despreciable. DistServe asume topologías que lo soporten.

Splitwise (Microsoft, 2024)

Splitwise llevó la idea un paso más allá: GPUs heterogéneas. Los prefills, compute-bound, corren en H100 o A100 (compute-optimizadas). Los decodes, memory-bound, corren en GPUs con más memoria por dólar pero menor compute (algunas variantes datacenter). Ganancia: 1.4× más throughput por dólar.

2026: producción

Disaggregated serving es ya producción mainstream:

NVIDIA Dynamo (sucesor de Triton): primitivo nativo.
vLLM: soporta disaggregation con flags --disaggregation-prefill-instances / --disaggregation-decode-instances.
SGLang, Ray Serve LLM, llm-d, LMCache, Mooncake: idem.
Operadores con stacks propios: Fireworks, Perplexity, Meta, Amazon, Modular, DeepInfra, Weka.

Disaggregated Inference: 18 Months Later (Hao AI Lab, 2026) hace una retrospectiva: lo que en 2024 era investigación es, en 2026, “como tener separados webservers de bases de datos”. Asumido.

PPD: no todos los prefills son iguales (2026)

El refinamiento más reciente: Not All Prefills Are Equal: PPD Disaggregation for Multi-turn LLM Serving (arxiv 2603.13358). Observación: en cargas multi-turn (asistentes conversacionales, agentes), los “prefills” sucesivos tienen estructura distinta: el primer turno es prompt nuevo, los siguientes son extensiones del cache anterior. PPD discrimina entre tipos de prefill y los enruta a clusters distintos, mejorando aún el aprovechamiento.

RadixAttention: el camino alternativo (SGLang)

Mientras vLLM iteraba sobre PagedAttention con prefix caching basado en hashing, SGLang tomó otra ruta: mantener un trie (radix tree) explícito de todos los prefijos que existen actualmente en el cache.

La idea

Cuando llega una petición nueva con tokens [t1, t2, t3, ..., tN], SGLang baja por el trie tokens-a-tokens. Si los primeros K tokens del prompt coinciden con un camino del trie, esos K tokens ya tienen su KV cache calculado y se reutilizan. Solo se procesa el prefill de los tokens N-K restantes.

Esto es prefix caching, pero con una estructura de datos que captura todas las relaciones de prefijo entre todas las sesiones activas simultáneamente, no solo los matches exactos de hash. Si dos peticiones comparten 137 tokens iniciales, RadixAttention lo encuentra; si una tercera comparte 89, también.

Eviction inteligente del trie

Los nodos del trie tienen un score basado en cuántas veces se han usado recientemente y cuántos descendientes tienen. Cuando hay presión de memoria, SGLang descarta los nodos menos valiosos primero, manteniendo los caminos más “calientes”. Esto es LRU + un peso por reutilización potencial.

Resultados

El paper de SGLang y benchmarks posteriores reportan hasta 6.4× throughput vs sin prefix caching, y un gap consistente del 29% sobre el prefix caching basado en hash de vLLM en cargas mixtas. En cargas con prefijos muy compartidos (agentes ReAct, multi-tenant SaaS, repo Q&A con system prompt común), los hit rates llegan al 60-85% y el ahorro de coste por petición es de 5-12×.

Producción

SGLang está en producción en xAI (sirviendo Grok 3) y Microsoft Azure (DeepSeek R1 en GPUs AMD), entre otros. No es un experimento; es un sistema de inferencia maduro.

Cuándo elegirlo sobre vLLM

Para cargas con prefijos compartidos masivos y predecibles, SGLang gana claramente. Para cargas genéricas mezcladas, vLLM rinde mejor por simplicidad operativa. El criterio operativo: si tu hit rate de prefix caching estimado en vLLM pasaría del 50%, plantéate SGLang.

Speculative decoding: la dimensión ortogonal

PagedAttention y sus sucesores optimizan dónde y cómo vive el cache. Speculative decoding ataca cómo se generan los tokens, ortogonalmente al cache. La idea genérica: usar un modelo pequeño y rápido para adivinar varios tokens por adelantado, validarlos en paralelo con el modelo grande y aceptar los que coinciden.

EAGLE-3 (2025)

EAGLE-3 (huggingface.co/papers/2401.15077, versión 3 de 2025) entrena una cabeza auto-regresiva pequeña que se condiciona en tres puntos del hidden state del modelo target (early, middle, late layers) en lugar de solo en el último. Esta fusión tri-layer es la razón por la que EAGLE-3 supera a EAGLE-2 en un 20-40%. Latencia medida: 2-6× speedup según tamaño de modelo y batch.

Medusa y DeepSeek MTP

Medusa fija N cabezas de decodificación adicionales al modelo, cada una prediciendo posición +1, +2, +3. DeepSeek-V3 ships con MTP (Multi-Token Prediction) nativo, n=4, entrenado conjuntamente con el modelo principal (no es un drafter externo). En inferencia, basta un flag en SGLang o vLLM (--speculative-model deepseek-v3-mtp) y obtienes 1.8× speedup out of the box, sin entrenar nada adicional, sin pesos extras que hospedar.

Mirror Speculative Decoding (2025)

Mirror Speculative Decoding (arxiv 2510.13161) ataca un límite que se daba por dado: la verificación de los tokens especulados sigue siendo serial dentro del modelo target. Mirror Decoding reorganiza el cómputo para paralelizar también la verificación, rompiendo la barrera serial del paradigma original. Las ganancias añadidas dependen del modelo y del batch, pero el paper lo posiciona como el próximo paso de la trayectoria EAGLE → EAGLE-2 → EAGLE-3.

Estado en 2026

Speculative decoding dejó de ser optimización experimental en 2026 para convertirse en capa por defecto de cualquier stack serio. Combinado con KV cache optimizado, los números reportados son 2.8× menos latencia y 47% menos coste por token.

Caveat operativo: speculative decoding es contraproducente en cargas de baja concurrencia. Si el modelo target tiene poco batch para llenar la GPU, las cabezas especulativas no compensan su overhead. Por debajo de ~4 sesiones simultáneas, suele bajar el throughput. Por encima, lo sube. Mídelo en tu carga antes de activarlo.

Implicaciones operativas: el config 2026 para vLLM

Si en 2026 montas vLLM en producción sin pensar mucho, los flags razonables por defecto son:

args:
- --model=...
- --tensor-parallel-size=N
- --max-model-len=...
- --kv-cache-dtype=fp8  # cuantización del cache
- --enable-prefix-caching  # ahorro fácil en cargas con prompts compartidos
- --enable-chunked-prefill  # mejor mezcla prefill/decode
- --gpu-memory-utilization=0.92  # ya cubierto en el post anterior
- --speculative-model=...  # SI batch sostenido >4
- --num-speculative-tokens=4  # acompaña al anterior
- --max-num-seqs=128  # admission control para evitar thrashing
- --preemption-mode=recompute  # o swap si sesiones largas

Para cargas con prefijos masivamente compartidos (agentes), considera migrar a SGLang: el delta de eficiencia compensa la curva de aprendizaje. Para cargas de baja latencia con modelos estables (entrenados in-house, no cambias cada semana), TensorRT-LLM sigue ganando en latencia pura. Para todo lo demás —que es la mayoría—, vLLM con los flags de arriba está dentro del 10% del óptimo en throughput.

Para arquitecturas grandes (>100 sesiones concurrentes, SLO estricto), disaggregated serving ya no es opcional. NVIDIA Dynamo o llm-d como orquestadores; vLLM o SGLang como motores debajo. La división típica: 1 nodo de prefill por cada 3-4 de decode, ajustando ratios según la longitud media de los prompts.

Trampas y mitos comunes

“PagedAttention vs vAttention” como dilema

No es un dilema. vAttention es una optimización de runtime; el modelo mental sigue siendo paging. La elección es entre dos implementaciones del mismo concepto. Operativamente: si tienes la versión de vLLM que lo soporta y CUDA VMM disponible, vAttention da más throughput; si no, paged va perfectamente.

“Cache compression sin probar calidad”

La industria de papers de compresión es prolífica y los benchmarks varían enormemente entre los del autor y los reales en producción. Compresión 8× parece mágico hasta que mides degradación en tu corpus real. Siempre evalúa con tus datos antes de activar compresión agresiva. Un FP8 cache es seguro casi siempre. Un INT4 cache requiere medir caso por caso.

“Prefix caching con prompts no determinísticos”

Si tu pipeline inyecta timestamps, IDs únicos o cualquier variabilidad en el system prompt, el hit rate de prefix caching se cae a cero. Es la trampa más común. Para que funcione, los prompts compartidos deben ser bit-a-bit idénticos. Estructura los prompts en capas: parte estática primero, variable al final.

“Speculative decoding en cargas bajas”

Ya lo mencionamos: por debajo de ~4 sesiones simultáneas, speculative suele ser contraproducente. Si tu carga es batch puro o muy esporádica, no la actives.

“Disaggregated en cluster sin red rápida”

Si tu inter-nodo es Ethernet 25 GbE o peor, la transferencia del KV cache entre prefill y decode se convierte en cuello de botella. Disaggregation es para clusters con InfiniBand o RoCE 100/200/400 GbE. Sin eso, mejor colocated.

Lo que no hemos cubierto

Hay terreno suficiente para otra serie:

Mooncake (Kimi/Moonshot, 2024+): KV cache como pool compartido entre instancias, persistente en RAM/NVMe. Producción real con cientos de millones de queries.
LMCache: cache de KV persistente en disco entre arranques de vLLM. Reduce el coste de los primeros tokens en cargas con repetición temporal.
vLLM Production Stack: distribución k8s-native de vLLM con HPA, métricas, multi-modelo, ya probada en producción a escala.
Inference scheduling teórico: hay literatura aplicando CFS-like algorithms (el scheduler de Linux) al LLM serving. Promete fairness multi-tenant medible. Aún en fase académica.
Quantization del modelo combinada con quantization del cache: AWQ/GPTQ sobre los pesos + FP8 sobre el cache + INT4 sobre cache evictado. La pirámide completa.

Referencias

Los papers fundacionales y las extensiones más leídas, en orden cronológico:

Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — paper original.
Dao et al., FlashAttention-2 (2023) y FlashAttention-3 (2024) — kernels de atención sobre los que vLLM y vAttention apoyan.
Xiao et al., Efficient Streaming Language Models with Attention Sinks (StreamingLLM, 2024).
Zhong et al., DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving (OSDI 2024).
Patel et al., Splitwise: Efficient Generative LLM Inference Using Phase Splitting (Microsoft, 2024).
Li et al., EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty (2024) y EAGLE-2/3 (2024-2025).
Prabhu et al., vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention (Microsoft, 2024-2025).
Zheng et al., SGLang: Efficient Execution of Structured Language Model Programs (RadixAttention, 2024).
DeepSeek-AI, DeepSeek-V3 Technical Report (2024) — MTP nativo, base de speculative decoding del estado del arte.
Mirror Speculative Decoding: Breaking the Serial Barrier in LLM Inference (2025).
KV Cache Transform Coding for Compact Storage in LLM Inference (KVTC, 2026).
EvicPress: Joint KV-Cache Compression and Eviction for Efficient LLM Serving (Microsoft Research, 2026).
LaProx: Reformulating KV Cache Eviction Problem for Long-Context LLM Inference (2026).
Not All Prefills Are Equal: PPD Disaggregation for Multi-turn LLM Serving (2026).

Operacional:

vLLM Paged Attention design doc — la propia doc señala que el paper original es ya “historical”.
Disaggregated Inference: 18 Months Later — Hao AI Lab @ UCSD, retrospectiva de la transición a disaggregated.
Top 10 KV Cache Compression Techniques for LLM Inference — survey reciente útil como mapa.
Artículos anteriores en este blog: KV cache: la memoria de trabajo que sostiene la inferencia LLM y vLLM en Kubernetes: la pieza de inferencia LLM que sí escala.

vLLM en Kubernetes: la pieza de inferencia LLM que sí escala

Mon, 18 May 2026 13:00:00 +0200

TL;DR

vLLM es el motor de inferencia que convierte una GPU de propósito general en un servidor LLM productivo. Su valor no está en correr un modelo —eso lo hace cualquier transformers.pipeline con tres líneas de Python— sino en exprimir la GPU hasta el último gigabyte y el último ciclo: PagedAttention para el KV cache, continuous batching para mezclar peticiones, scheduler propio para repartir tiempo de GPU entre sesiones. Kubernetes es su hábitat natural porque vLLM se comporta como un proceso UNIX moderno —tiene endpoint de health, métricas Prometheus, draining ordenado, recursos declarables— y K8s ya sabe cómo gestionarlos. Pero hay trampas: el HPA estándar no escala vLLM bien, el modelo tarda minutos en cargar, y los rolling updates ingenuos cortan sesiones a medio decodificar. Este artículo desmonta el motor y luego lo encaja, con manifests reales, en un cluster que sí pueda servirlo.

Este artículo es la continuación natural de KV cache: la memoria de trabajo que sostiene la inferencia LLM. Allí explicamos por qué cada token consume VRAM. Aquí vemos qué se hace con esa VRAM cuando la quieres ofrecer como servicio.

La analogía: kernel multiproceso para tu GPU

Imagina que tienes un único procesador y necesitas servir cien procesos concurrentes sin que ninguno bloquee a los demás. Nadie en su sano juicio escribiría un bucle while-true que despacha procesos uno a uno: instalaría un sistema operativo. El kernel se encarga del scheduling, de la paginación de memoria, del aislamiento, de las prioridades, de la limpieza al terminar. El “proceso” se convierte en una abstracción cómoda y el kernel hace el trabajo sucio.

vLLM es, para tu GPU, lo que el kernel es para tu CPU. Frente a la GPU, una conversación con un LLM es un proceso que vive durante muchos pasos de decodificación, ocupa una porción de VRAM (su KV cache) y demanda tiempo de cómputo cada vez que toca generar un token. Tienes cien de esos procesos a la vez. Necesitas:

Repartir tiempo de GPU entre ellos sin pausarlos enteros (sería desastroso si una conversación larga monopoliza la GPU).
Gestionar la memoria con paginación porque, igual que en RAM, reservar contiguo es ineficiente.
Encolar peticiones nuevas cuando la GPU está saturada y servirlas en orden razonable.
Recuperar recursos cuando una sesión termina.

PagedAttention es la memoria virtual del KV cache. Continuous batching es el scheduler con time-slicing que reparte la GPU token a token. El servidor OpenAI-compatible es la interfaz de syscalls uniforme. Llamarlo “kernel” para la GPU es marketing, pero es marketing que captura bien la idea.

Qué hace vLLM por dentro

Continuous batching: dejar de esperar al más lento

El motor de inferencia naïve hace static batching: agrupa N peticiones, las procesa hasta que todas terminan, devuelve y empieza otra ronda. El problema es obvio: si una petición pide 8 tokens y otra pide 800, las otras siete esperan a la lenta. La utilización de GPU se cae a plomo.

Continuous batching (Yu et al., 2022, popularizado por vLLM) cambia el modelo. En cada paso de decode —que produce un token para cada sesión activa— el motor compone el batch con los tokens activos de TODAS las sesiones que estén vivas en ese instante. Cuando una sesión termina su generación, libera su slot inmediatamente y otra petición de la cola lo ocupa. El batch nunca se queda esperando a la sesión más lenta porque nadie está bloqueado: todos avanzan al ritmo de un token por paso.

El paper original midió 5–23× más throughput que el static batching equivalente. El número exacto depende de la variabilidad de la longitud de las respuestas, pero el orden de magnitud se mantiene en la práctica.

La consecuencia para el operador es contraintuitiva: una sola réplica vLLM rinde como tres réplicas naïve. No tiene sentido añadir pods sin justificarlo con métricas reales.

PagedAttention: la memoria virtual del KV cache

Ya lo dejamos apuntado en el artículo del KV cache: el motor naïve reserva un bloque contiguo por sesión, dimensionado al peor caso (max_context_len), y desperdicia el 60–80% de la VRAM porque las sesiones reales no llegan ni de lejos a su techo.

PagedAttention pide prestada la solución que los sistemas operativos llevan medio siglo usando: dividir la VRAM en bloques pequeños (16 tokens en la implementación por defecto) y mantener una tabla de páginas lógicas → físicas por sesión. Una sesión que tiene 273 tokens de contexto ocupa 18 bloques (no necesariamente contiguos), y crece de bloque en bloque conforme genera. El paper midió <4% de desperdicio —un orden de magnitud mejor que la asignación contigua— y eso se traduce en 2–4× más throughput agregado en el mismo hardware, porque caben más sesiones a la vez.

Hay un coste: cada operación de atención debe indirectarse por la tabla de páginas. Pero los kernels CUDA de vLLM están escritos para que esa indirección sea barata, y el resultado neto es masivamente positivo.

Prefill vs decode: dos fases con perfiles opuestos

Una petición LLM tiene dos fases con perfiles de GPU radicalmente distintos:

Prefill: procesa el prompt entero de golpe. Es compute-bound: usa los tensor cores intensamente, la GPU está al 90%+, dura entre cientos de ms y unos pocos segundos según el tamaño del prompt.
Decode: genera token a token. Es memory-bound: el cómputo es modesto pero hay que leer el KV cache entero por cada token, dura desde unas decenas de ms por token hasta minutos para respuestas largas.

Un servidor naïve trata cada petición como una unidad y sirve las dos fases en serie. vLLM las desacopla: mezcla peticiones en prefill con peticiones en decode en el mismo paso (técnica llamada chunked prefill cuando además trocea prefills largos). Resultado: la GPU está siempre ocupada haciendo algo —los tensor cores con prefills, el ancho de banda HBM con decodes— en lugar de oscilar entre fases.

Implicación operativa: la métrica “% utilización GPU” del nvidia-smi engaña. Una GPU al 100% haciendo prefills puede tener su HBM bandwidth ocioso. Una GPU al 40% haciendo decodes puede tener el HBM saturado. Para LLM serving, la métrica útil es el ancho de banda HBM efectivo, no el porcentaje de cómputo.

Tensor parallel: cuando el modelo no cabe en una GPU

Llama 3 70B en BF16 son ~140 GB. No hay una sola GPU en el mercado que lo aguante. La solución es tensor parallel: dividir cada capa del modelo por columnas y ejecutar las particiones en N GPUs en paralelo, sincronizando con un all-reduce tras cada capa.

Para N=5 GPUs y un modelo de 70B, cada GPU ve aproximadamente 28 GB de pesos. Suena bien hasta que recuerdas que el all-reduce de cada capa significa leer y escribir tensores grandes entre GPUs. Si las GPUs comparten NVLink/NVSwitch (300–900 GB/s), el all-reduce es barato. Si comparten solo PCIe (~32 GB/s gen4 x16), el all-reduce se come la mitad del tiempo y el throughput se hunde.

Implicación para K8s, que viene a continuación: el scheduler tiene que garantizar que las N GPUs estén físicamente cerca. Esto se traduce en NodeAffinity al producto correcto (NVIDIA-H100-80GB-HBM3), pod único con nvidia.com/gpu: N (no N pods compartiendo) y, si hace falta multi-nodo, InfiniBand con NCCL como transporte.

El servidor OpenAI-compatible

Por encima de todo lo anterior, vLLM expone un servidor HTTP con endpoints idénticos a los de OpenAI: /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models. Soporta streaming Server-Sent Events. Soporta tool calling. Soporta logprobs.

El valor de esto es enorme y se subestima: cualquier cliente que use la SDK de OpenAI funciona sin cambios. Tu aplicación apunta a https://vllm.tu-cluster.local/v1 en vez de a https://api.openai.com/v1, y todo lo demás —los SDKs de LangChain, LlamaIndex, OpenAI Python, OpenAI JS— funciona. Es la razón principal por la que vLLM ha ganado tracción sobre alternativas técnicamente comparables: es la opción aburrida que funciona.

Por qué Kubernetes es el hábitat natural

vLLM es un proceso bien comportado: arranca, expone métricas, atiende un endpoint de health, recibe SIGTERM con dignidad, declara los recursos que necesita. Kubernetes lleva diez años perfeccionando la gestión de procesos así. Lo único que K8s ha tardado en absorber bien es la GPU, y eso ya está resuelto.

GPU como recurso primitivo

El plumbing es el siguiente:

El nodo tiene driver NVIDIA instalado (o lo instala el GPU Operator).
Un DaemonSet, nvidia-device-plugin, registra las GPUs físicas como recursos nvidia.com/gpu ante kubelet.
El scheduler de Kubernetes ve esos recursos como ve CPU y memoria, los pone en su contabilidad y los asigna a Pods que los piden.
El nvidia-container-toolkit se asegura de que containerd inyecte los devices correctos en el contenedor al arrancar.

Para el pod, pedir una GPU es esto:

resources:
 requests:
 nvidia.com/gpu: 1
 limits:
 nvidia.com/gpu: 1

Sin MIG ni MPS ni time-slicing configurados, una GPU no se comparte entre pods: la pides entera o no la pides. Para vLLM —que quiere toda la GPU para sí— esto es lo deseable.

El ciclo de vida del Pod vLLM

Diferencias con un Pod de webapp típico:

Startup largo. Cargar 16 GB de pesos en VRAM por encima de la red tarda 30 segundos en el mejor caso y 5 minutos en el peor. Una readinessProbe con initialDelaySeconds: 30 y failureThreshold: 3 mata el pod antes de que arranque. Solución: startupProbe con threshold alto antes de que la livenessProbe empiece a evaluar.
Warm-up útil. El primer prefill compila kernels CUDA específicos del shape de entrada. Las primeras 2–3 peticiones son sensiblemente más lentas. Si la latencia importa desde el segundo 1, conviene disparar un POST de warm-up tras el ready.
Draining no instantáneo. SIGTERM no debe matar las sesiones en curso. vLLM, configurado con --disable-graceful-shutdown false (default), termina las peticiones activas antes de cerrar. Esto puede tardar 30–180 segundos. terminationGracePeriodSeconds debe acomodarlo.
Rollouts hostiles. Un rolling update naïve (maxUnavailable: 1) puede dejarte sin réplicas atendiendo si la nueva tarda en cargar. Pon maxSurge: 1, maxUnavailable: 0 para que el pod nuevo esté Ready antes de drenar el viejo.

Anatomía de un despliegue en serio

Antes que nada: GPU Operator

Sin GPU Operator (o instalación manual equivalente), un Pod con nvidia.com/gpu: 1 se queda Pending para siempre. Lo que el operator instala como DaemonSets en cada nodo con GPU:

nvidia-driver-daemonset — el driver kernel-mode (si no lo tienes instalado al nivel del host).
nvidia-device-plugin-daemonset — registra las GPUs como recurso de kubelet.
nvidia-container-toolkit-daemonset — la integración con containerd.
nvidia-dcgm-exporter — métricas Prometheus de la GPU (utilización, temperatura, ECC errors, memoria).
gpu-feature-discovery — labels del nodo: nvidia.com/gpu.product, nvidia.com/gpu.memory, etc., imprescindibles para NodeAffinity.

La instalación recomendada es el chart Helm oficial. La parte sensible es alinear el driver con la versión del kernel del host: si los nodos llevan kernel 6.x, el operator necesita un branch de driver compatible.

Deployment vLLM completo y comentado

Lo siguiente despliega Llama 3 8B con KV cache cuantizado FP8, hasta 32K de contexto, en una RTX 4090. Es el manifest de referencia; los comentarios explican las decisiones no obvias.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: vllm-llama3-8b
 namespace: inference
spec:
 replicas: 1
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxSurge: 1
 maxUnavailable: 0 # nunca quedarse sin réplicas durante el rollout
 selector:
 matchLabels:
 app: vllm-llama3-8b
 template:
 metadata:
 labels:
 app: vllm-llama3-8b
 annotations:
 prometheus.io/scrape: "true"
 prometheus.io/port: "8000"
 prometheus.io/path: "/metrics"
 spec:
 # Solo nodos con la GPU que esperamos
 nodeSelector:
 nvidia.com/gpu.product: NVIDIA-GeForce-RTX-4090
 tolerations:
 - key: nvidia.com/gpu
 operator: Exists
 # Predescargar pesos si no están en el PVC compartido
 initContainers:
 - name: model-download
 image: ghcr.io/huggingface/huggingface-cli:latest
 command: ["sh", "-c"]
 args:
 - |
 if [ ! -f /models/llama-3-8b/config.json ]; then
 huggingface-cli download meta-llama/Meta-Llama-3-8B-Instruct \
 --local-dir /models/llama-3-8b --local-dir-use-symlinks False
 fi
 env:
 - name: HF_TOKEN
 valueFrom:
 secretKeyRef:
 name: huggingface
 key: token
 volumeMounts:
 - name: models
 mountPath: /models
 containers:
 - name: vllm
 image: vllm/vllm-openai:v0.6.3
 args:
 - --model=/models/llama-3-8b
 - --served-model-name=llama-3-8b
 - --tensor-parallel-size=1
 - --max-model-len=32768
 - --kv-cache-dtype=fp8
 - --enable-chunked-prefill
 - --enable-prefix-caching
 - --gpu-memory-utilization=0.92
 - --port=8000
 ports:
 - name: http
 containerPort: 8000
 - name: metrics
 containerPort: 8000 # mismo puerto que http; /metrics
 resources:
 requests:
 cpu: "4"
 memory: 8Gi
 nvidia.com/gpu: 1
 limits:
 cpu: "8"
 memory: 16Gi
 nvidia.com/gpu: 1
 startupProbe:
 httpGet:
 path: /health
 port: 8000
 periodSeconds: 10
 failureThreshold: 60 # 10 min de gracia para cargar el modelo
 readinessProbe:
 httpGet:
 path: /health
 port: 8000
 periodSeconds: 5
 livenessProbe:
 httpGet:
 path: /health
 port: 8000
 periodSeconds: 20
 failureThreshold: 3
 volumeMounts:
 - name: models
 mountPath: /models
 readOnly: true # ningún proceso debe escribir aquí en runtime
 - name: shm
 mountPath: /dev/shm  # vLLM usa shared memory para IPC entre workers
 volumes:
 - name: models
 persistentVolumeClaim:
 claimName: model-cache
 - name: shm
 emptyDir:
 medium: Memory
 sizeLimit: 4Gi
 terminationGracePeriodSeconds: 120 # acomoda drenaje de sesiones activas
---
apiVersion: v1
kind: Service
metadata:
 name: vllm-llama3-8b
 namespace: inference
spec:
 selector:
 app: vllm-llama3-8b
 ports:
 - name: http
 port: 80
 targetPort: 8000

Cinco cosas que no se ven en primera lectura:

/dev/shm en memoria, 4 GB. vLLM lanza procesos worker (uno por GPU en tensor parallel, además del driver) que se comunican por shared memory. El default de Docker (64 MB) revienta en cuanto el modelo es mediano. Sin esto, el pod arranca pero falla en cuanto sirve la primera petición compleja.
--enable-prefix-caching. Si los prompts de tu carga comparten estructura (system prompt común, few-shot examples), vLLM reutiliza el KV cache de la parte común. Ganancia gratis del 30–60% en TTFT.
--gpu-memory-utilization=0.92. vLLM reserva el % indicado de la VRAM para sí. El 8% restante deja margen para activations, kernels CUDA, y el overhead que no se cuenta. Bajarlo da seguridad; subirlo más de 0.95 invita al OOM.
PVC ReadOnlyMany ideal. El modelo no cambia en runtime. Varios pods pueden montar el mismo PVC sin contención.
Ningún livenessProbe que tarde menos que el terminationGracePeriodSeconds. Si un drain tarda 90s y la liveness mata a los 60s, los rollouts pierden sesiones.

Tensor parallel multi-pod: LeaderWorkerSet

Cuando el modelo necesita más GPUs de las que tiene un solo nodo, el patrón es un grupo de pods coordinados, uno por GPU, que se comportan como una única réplica. Esto se modeló durante años con StatefulSet más init scripts; desde Kubernetes 1.32, el primitivo idiomático es LeaderWorkerSet (LWS):

apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
 name: vllm-llama3-70b
 namespace: inference
spec:
 replicas: 1
 leaderWorkerTemplate:
 size: 5 # 1 leader + 4 workers = 5 pods, 5 GPUs
 restartPolicy: RecreateGroupOnPodRestart
 leaderTemplate:
 spec:
 nodeSelector:
 nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3
 containers:
 - name: vllm-leader
 image: vllm/vllm-openai:v0.6.3
 args:
 - --model=/models/llama-3-70b
 - --tensor-parallel-size=5
 - --distributed-executor-backend=ray
 # ...
 workerTemplate:
 spec:
 nodeSelector:
 nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3
 containers:
 - name: vllm-worker
 image: vllm/vllm-openai:v0.6.3
 # los workers se unen al cluster Ray del leader

LWS garantiza el orden de arranque (workers primero, leader después) y el ciclo de vida atómico (si un worker cae, se reinicia el grupo entero, no un solo pod). Sin esto, la coordinación es manualmente frágil.

Una alternativa más sencilla, si todas las GPUs del tensor parallel caben en un solo nodo (caso de los HGX H100 con 8 GPUs y NVSwitch interno): un único Pod con nvidia.com/gpu: 5, --tensor-parallel-size=5, y vLLM se encarga de todo internamente. Sin Ray, sin LWS, mucho más simple. Es el camino recomendado cuando se puede.

Autoscaling: HPA estándar no sirve

El HPA por CPU% es inútil para vLLM. La GPU hace el trabajo; la CPU del pod está al 5–10% incluso al máximo de carga. Tampoco sirve el porcentaje de utilización de la GPU del dcgm-exporter: un pod al 100% de GPU% con gpu_cache_usage_perc=15% está atendiendo una sesión larga sin saturar, mientras que un pod al 60% de GPU% con gpu_cache_usage_perc=95% está al borde de la expulsión de sesiones.

Las métricas correctas las exporta el propio vLLM en /metrics (formato Prometheus):

Métrica	Qué dice	Cuándo escalar
`vllm:num_requests_waiting`	Peticiones encoladas sin entrar al batch.	Si pasa de 5–10 sostenidos.
`vllm:num_requests_running`	Peticiones activas en el batch.	Para capacity planning, no para escalar.
`vllm:gpu_cache_usage_perc`	% del KV cache ocupado.	Si >80% sostenido, hay riesgo de preemption.
`vllm:time_to_first_token_seconds`	Latencia del prefill (histograma).	Si p95 supera tu SLA.
`vllm:e2e_request_latency_seconds`	Latencia total por petición.	Métrica de salida.

Para que el HPA las consuma, dos caminos: Prometheus Adapter (expone métricas custom al API de K8s) o KEDA (escala por queries Prometheus directamente, mucho más cómodo). Con KEDA:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: vllm-scaler
 namespace: inference
spec:
 scaleTargetRef:
 name: vllm-llama3-8b
 minReplicaCount: 1
 maxReplicaCount: 8
 pollingInterval: 10
 cooldownPeriod: 120 # 2 min antes de scale-down (sesiones largas)
 triggers:
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.monitoring:9090
 threshold: '5'
 query: |
 sum(vllm:num_requests_waiting{app="vllm-llama3-8b"})

El cooldownPeriod largo es importante: si bajas réplicas mientras hay sesiones decodificando, las matas. Mejor 2 minutos de holgura.

Observabilidad: las cuatro métricas que importan

De todo lo que /metrics exporta, un dashboard mínimo necesita estas cuatro:

TTFT p50/p95 (time to first token) — lo que percibe el usuario al pulsar enviar.
TPOT p50/p95 (time per output token) — la “velocidad” del streaming.
Throughput agregado (tokens generados/segundo del cluster) — para capacity planning.
Queue depth (vllm:num_requests_waiting) — el indicador adelantado: si crece, todo se va a degradar.

A esto se le suma utilización HBM y memoria libre por GPU (de dcgm-exporter) para detectar saturación de bandwidth y problemas de fragmentación. Un dashboard Grafana decente con esas 6 gráficas adelanta el 90% de los incidentes.

Dos escenarios concretos

Reutilizamos los mismos hardwares del artículo anterior para tener continuidad. Mismas matemáticas de cache, ahora con el motor montado.

Escenario A — 1×RTX 4090 (workstation o nodo K8s pequeño)

Topología: 1 Pod, --tensor-parallel-size=1, 1 GPU, 1 nodo.
Modelo: hasta 8B BF16 (Llama 3 8B, Qwen3 8B, Mistral 7B) o hasta 14B en FP8/AWQ.
PVC: SSD local del nodo. La 4090 lee 1 TB/s de HBM; un SSD NVMe a 5 GB/s tarda 5 segundos en alimentar 25 GB de pesos a VRAM, despreciable frente a la inicialización.
HPA: irrelevante dentro de la 4090 (siempre 1 réplica de vLLM por GPU), pero útil entre nodos: 3 réplicas en 3 nodos con 4090 cada uno, el Service de K8s reparte round-robin.
Concurrencia útil: 4–8 sesiones simultáneas con 8K de contexto, 1–2 con 32K.
Caso de uso natural: PoC, equipos pequeños, ambientes departamentales, edge.

El manifest de arriba está dimensionado para este escenario. Cambiando solo el modelo y los args, el mismo Deployment sirve Qwen, Mistral o el que toque.

Escenario B — 5×H100 SXM (cluster con NVLink/NVSwitch)

Topología: 1 Pod con nvidia.com/gpu: 5 en un nodo HGX, --tensor-parallel-size=5. Si la plataforma no permite agrupar 5 GPUs en un solo Pod, LeaderWorkerSet con 5 pods coordinados por Ray.
Modelo: hasta 70B BF16 (Llama 3 70B) o hasta 200B+ en FP8 con cuantización del cache.
PVC: NVMe directamente atado al nodo, o storage en red rápido (Ceph con red 25/100 GbE, Lustre, GPFS). Cargar 140 GB de pesos por una red lenta tarda 5 minutos por arranque.
HPA: irrelevante dentro del cluster de 5 GPUs (las 5 son una unidad indivisible), pero útil añadiendo más nodos HGX completos cuando la carga pasa de cierto umbral. Esto se combina con Cluster Autoscaler si la infraestructura subyacente lo permite.
Concurrencia útil: 32–128 sesiones simultáneas con contextos medianos, 4–16 con contextos enormes.
Caso de uso natural: servicio interno corporativo, exposición pública con SLA, multi-tenant.

A y B, lado a lado

Aspecto	A (1×4090)	B (5×H100 SXM)
Topología Pod	1 pod, 1 GPU	1 pod con 5 GPUs (o LWS de 5)
Modelo máximo BF16	8 B	70 B
TTFT @ 8K contexto, idle	~250 ms	~80 ms
TPOT, idle	~30 ms/tok	~15 ms/tok
Throughput @ concurrencia 16	~50 tok/s/sesión	~200 tok/s/sesión
Drain de sesiones	30–60 s	60–180 s
Autoscaling útil	Réplicas en nodos pares	Nodos completos vía Cluster Autoscaler
Multi-tenancy razonable	Limitada: 4–8 sesiones	Holgada: 32–128 sesiones
Coste indicativo (hardware)	~2 K €	~250 K € (≈ 125×)

La asimetría sigue siendo la del artículo anterior: 125× más caro, sólo ~4× más throughput por sesión y ~10× más concurrencia. Lo que el cluster compra no es proporcional; compra acceso a modelos un orden de magnitud más grandes y latencias suficientemente bajas para uso interactivo a escala. Si tu carga es batch o agentes asincrónicos donde la latencia no es crítica, varias 4090s rinden sorprendentemente cerca.

vLLM frente a TensorRT-LLM y SGLang

Honestamente, los tres son buenos motores. La elección depende de criterios prácticos, no técnicos. Mapa de decisión, no benchmark:

Criterio	vLLM	TensorRT-LLM	SGLang
Hardware soportado	NVIDIA, AMD ROCm, Intel Gaudi	NVIDIA exclusivamente	NVIDIA, AMD ROCm
Latencia pura (TTFT)	Buena	Mejor: kernels compilados al hardware exacto	Buena
Throughput agregado	Excelente	Excelente	Excelente (RadixAttention)
Despliegue	Trivial: imagen Docker + args	Complejo: build engine por modelo + por GPU	Moderado
API OpenAI-compatible	Nativa, completa	Sí, a través de Triton Inference Server	Sí
Soporte de modelos nuevos	Días tras release	Semanas (recompilar engine)	Días
Quantization	AWQ, GPTQ, FP8 cache	INT4/INT8/FP8 muy maduros	AWQ, FP8
Multi-modal	Sí (Llava, Pixtral, Qwen-VL)	Sí	Excelente, prioritario
Function calling / tool use	Bueno	Limitado	Primera clase
Comunidad / cadencia release	Muy activa, semanal	Activa, NVIDIA-driven	Muy activa, académica
Licencia	Apache 2.0	Apache 2.0	Apache 2.0

Cuándo elegir cada uno:

vLLM: el “boring choice” que funciona. Camino con menos fricción para llegar a producción. Si tu equipo no tiene un especialista dedicado al inference serving, esto. Soporta hardware variado, modelos al día, API estable, comunidad enorme.
TensorRT-LLM: cuando la latencia por petición es la métrica única que importa y tu modelo es estable (entrenado in-house, no cambias cada quincena). El precio del rendimiento es que cada modelo + cada GPU + cada versión de TRT requiere rebuild del engine, y eso bloquea iteración rápida.
SGLang: para cargas dominadas por agentes (tool calling intensivo) o multi-modal complejo. Su RadixAttention —caching estructural de prompts con prefijos compartidos— brilla en patrones tipo ReAct donde el mismo system prompt se repite miles de veces.

Para la mayoría de equipos que están empezando con LLM serving on-prem, vLLM es la respuesta correcta hasta que tengas datos en producción que te empujen a otra cosa.

Trampas operativas frecuentes

Una lista de gotchas que se ven una y otra vez:

El modelo se descarga en cada rolling update

Síntoma: cada deploy tarda 5+ minutos en estar disponible. Causa: no hay PVC compartido. Cada pod nuevo descarga el modelo desde Hugging Face de cero. Remedio: PVC ReadOnlyMany sobre un storage rápido, o un mirror local del registry (un Pod con huggingface-cli que sirve un directorio por HTTP). En CI/CD, hidratar el PVC antes del rollout es 1 línea de bash.

readiness con timeout corto que mata pods cargando

Síntoma: pods nuevos entran en CrashLoopBackOff durante la primera carga del modelo. Causa: readinessProbe con timeout demasiado bajo dispara antes de que vLLM termine de cargar; livenessProbe lo remata. Remedio: startupProbe con failureThreshold: 60 o más (10 minutos de gracia) antes de que la liveness empiece a evaluar.

KV cache sin cuantizar y luego OOM

Síntoma: el pod arranca bien, atiende cinco minutos, OOMKilled cuando llega la sesión número cinco con contexto largo. Causa: KV cache en BF16 (default) consume el doble que en FP8. Remedio: --kv-cache-dtype=fp8. Pérdida de calidad despreciable en la inmensa mayoría de casos, capacidad duplicada.

Confundir réplicas con concurrencia

Síntoma: el HPA escala a 8 réplicas con poca carga real y la factura cloud sube. La latencia no mejora. Causa: alguien configuró targetAverageUtilization: 50% sobre CPU, pensando que es “carga”. Realidad: una sola réplica vLLM atiende decenas de sesiones simultáneas. Remedio: HPA sobre vllm:num_requests_waiting. Si la cola está vacía, una réplica basta aunque la GPU esté al 90%.

Tensor parallel en GPUs sin NVLink

Síntoma: throughput 3× peor del esperado, GPUs al 30%, mucho tráfico PCIe. Causa: tensor_parallel=4 en 4 GPUs conectadas solo por PCIe; el all-reduce satura el bus en cada capa. Remedio: o las GPUs comparten NVLink/NVSwitch (modelos SXM/HGX), o pipeline parallel (peor latencia pero menos all-reduce), o reduces TP y aceptas que no cabe el modelo entero.

Sesiones cortadas en rolling update

Síntoma: usuarios ven respuestas truncadas durante el deploy. Causa: terminationGracePeriodSeconds: 30 (default) no llega para drenar generaciones largas. Remedio: terminationGracePeriodSeconds: 120–180. Combinado con maxUnavailable: 0, los rollouts son invisibles para los usuarios activos.

Lo que no hemos cubierto (próximos artículos)

vLLM con LoRA adapters en caliente: servir un base model + N adapters específicos por tenant sin recargar pesos.
Disaggregated serving: separar prefill y decode en pods especializados, cada uno optimizado para su perfil de GPU.
Quantization deep-dive: AWQ vs GPTQ vs FP8 dinámico vs FP4, trade-offs reales, cuándo cada uno.
Gateway API + AI Inference Extensions: la propuesta sigwg para que los LLMs sean ciudadanos de primera en K8s (routing por modelo, sticky session por conversación, fairness multi-tenant).
Multi-modal serving: el mismo runtime, otro tipo de peticiones —imágenes, audio, embeddings—.

Referencias

Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — paper original de vLLM.
Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022) — paper que popularizó continuous batching.
Documentación oficial de vLLM — operacional y bien mantenida.
NVIDIA GPU Operator — instalación y troubleshooting de la capa GPU en Kubernetes.
LeaderWorkerSet — primitivo para workloads coordinados como tensor parallel multi-pod.
KEDA — autoscaling event-driven, idóneo para escalar por métricas de cola.
TensorRT-LLM y SGLang — los dos comparables más serios.
LMSYS Chatbot Arena — benchmarks periódicos comparando los tres motores.
Artículo previo en este blog: KV cache: la memoria de trabajo que sostiene la inferencia LLM.

KV cache: la memoria de trabajo que sostiene la inferencia LLM

Mon, 18 May 2026 10:00:00 +0200

TL;DR

El KV cache es la memoria de trabajo que un modelo de lenguaje mantiene durante una conversación. Sin él, cada token nuevo obligaría a recalcular toda la conversación desde el principio, con un coste cuadrático en la longitud del texto. Con él, el coste es lineal pero a cambio el cache vive en VRAM y crece con cada token. En la práctica, no es el modelo lo que limita cuánto contexto puedes servir: es el KV cache. Para una RTX 4090 con Llama 3 8B, cabe el modelo en 16 GB y queda apenas espacio para ~64 K tokens de cache totales (sumando todas las sesiones simultáneas). Entender este número es la diferencia entre prometerle a un cliente “contexto de 128 K” y entregárselo.

Estás aquí: Deploy

Este post abre la serie de fundamentos de inferencia LLM. Dentro del pipeline LLMOps de seis etapas que articula todo el sistema, el KV cache vive en la etapa Deploy: es la pieza que dicta cuánto tráfico cabe en tu motor de inferencia y, por tanto, cuánta plataforma puedes ofrecer encima.

La analogía: el orador con amnesia

Imagina que asistes a una conferencia técnica de dos horas. El ponente, cada vez que va a decir una frase nueva, rebobina mentalmente toda la charla desde el inicio, recompone el hilo, y solo entonces continúa. Su próxima frase requiere rememorar la anterior; la siguiente, las dos anteriores; al cabo de una hora, cada palabra nueva le cuesta una hora de recapitulación. Una conferencia así sería materialmente imposible.

Ahora imagina al mismo ponente con un cuaderno donde apunta, mientras habla, las dos o tres ideas clave de cada frase: sujeto, objeto, vínculo con lo anterior. Antes de cada frase nueva, ojea el cuaderno y sigue. Su próxima palabra sólo cuesta una ojeada al cuaderno, no rebobinar la charla entera.

Ese cuaderno, en un transformer, se llama KV cache. Sin él, los modelos de lenguaje conversacionales serían inviables. Con él, son productos comerciales. Pero el cuaderno pesa: y entender cuánto, dónde y por qué, es lo que separa una infraestructura de inferencia que funciona de una que se cae al tercer cliente concurrente.

El mecanismo en sí (en cristiano)

Un transformer genera texto un token cada vez. Para decidir el siguiente token, el modelo aplica un mecanismo llamado atención sobre todos los tokens previos: pregunta “¿qué partes del contexto anterior son relevantes para predecir lo que viene ahora?”.

Internamente, cada token de entrada se proyecta a tres vectores:

Q (Query): “qué estoy buscando”
K (Key): “qué oferta este token”
V (Value): “qué información lleva este token”

La atención del token actual contra el contexto se calcula multiplicando su Q contra las K de todos los tokens previos, normalizando con softmax, y ponderando las V correspondientes. Resultado: una representación contextualizada del token actual.

Q·Kᵀ → softmax × V

representación del token N

Aquí está la clave: para predecir el token N, sólo necesito Q nuevo (el del token N) y K, V de todos los tokens anteriores. Las K y V de los tokens 1..N-1 no han cambiado desde la iteración anterior. Recalcularlas sería tirar trabajo.

El KV cache es exactamente eso: la memoria que guarda K y V de cada token ya procesado, en cada capa del modelo, para no recalcularlos.

Por qué existe: el coste cuadrático sin él

Generar un texto de N tokens implica N pasos. En el paso i, se calcula la atención sobre i tokens anteriores. Sin cache, en cada paso recomputas las K, V de los i-1 tokens anteriores más las del nuevo. La cuenta total de cómputos de atención crece como:

$$\sum_{i=1}^{N} i = \frac{N(N+1)}{2} \approx \frac{N^2}{2}$$

Con KV cache, sólo procesas el token nuevo en cada paso: coste lineal en N.

0 25% 50% 75% 100%

0 1K 2K 3K 4K

con KV cache (lineal) sin KV cache (cuadrático)

Los números concretos son demoledores:

Tokens generados	Sin KV cache (operaciones)	Con KV cache	Ratio
128	8 256	128	64×
1 024	524 800	1 024	512×
4 096	8 390 656	4 096	2 048×
32 768	536 887 296	32 768	16 384×

A los 32 K tokens, el cache te ahorra cuatro órdenes de magnitud de cómputo. No es una optimización: es lo que hace que la inferencia conversacional sea posible.

El precio: cuánto pesa la mochila

El KV cache se paga en VRAM. La fórmula, por secuencia, es:

KV_size = 2 · n_layers · n_kv_heads · head_dim · context_len · bytes_per_param
↑
K y V

Por token (sin el context_len), es una constante propia del modelo. Veamos números reales:

Modelo	n_layers	n_kv_heads	head_dim	Bytes/token (BF16)	GB a 8 K ctx	GB a 32 K	GB a 128 K
Llama 3 8B (MHA hipotético)	32	32	128	524 288	4.00	16.00	64.00
Llama 3 8B (GQA real)	32	8	128	131 072	1.00	4.00	16.00
Llama 3 70B (GQA)	80	8	128	327 680	2.50	10.00	40.00
Qwen3 8B (GQA)	36	8	128	147 456	1.12	4.50	18.00
Mistral 7B (GQA)	32	8	128	131 072	1.00	4.00	16.00

Dos lecturas inmediatas:

Sin GQA, no hay 128 K que valga. Un Llama 3 8B con atención multi-head clásica necesitaría 64 GB sólo de KV cache para una única secuencia con 128 K tokens. Es decir, no cabe en ninguna GPU consumer. Por eso Meta, Mistral y compañía adoptaron Grouped Query Attention.
El KV cache puede ser mayor que el modelo. Llama 3 8B BF16 ocupa ~16 GB. Con 128 K de contexto, su cache son otros 16 GB. Una sola sesión empata al modelo en VRAM.

0 10 20 30 40 GB

0 8K 32K 64K 128K

≈ VRAM libre tras cargar 8B en una 4090

Llama 3 8B Qwen3 8B Llama 3 70B

La línea roja punteada marca la VRAM realista disponible en una RTX 4090 después de cargar el modelo. Cualquier modelo cuya curva cruza esa línea no podrá servir ese contexto sin estrategias adicionales (cuantización del cache, offload, particionado).

La inferencia es memory-bound, no compute-bound

Hay un equívoco común: pensar que “GPU rápida = inferencia rápida”. En el régimen donde realmente operan los servicios de inferencia con KV cache, lo que se mide es el ancho de banda de memoria. Cada token nuevo exige leer las K y V de todos los tokens anteriores desde HBM. El cómputo es modesto; el movimiento de datos, masivo.

Por eso, una H100 SXM (3.35 TB/s de HBM3) puede ser 2–3× más rápida que una A100 (1.55–2 TB/s) sin que la frecuencia ni el número de cores expliquen del todo la diferencia. Lo explica el ancho de banda.

Y por eso, también, las ofertas de “GPU baratas con mucha VRAM pero HBM lenta” (algunas variantes con GDDR6 o LPDDR5) decepcionan en inferencia con contextos largos: tienen sitio para guardar el cache pero les cuesta una eternidad releerlo.

Trucos para que el cuaderno sea más fino

Tres técnicas, en orden cronológico, han ido aplanando el tamaño del KV cache:

Multi-Head Attention (MHA). El planteamiento original del transformer (Vaswani et al., 2017). Cada cabeza de atención tiene su propia K y V. Caro en cache pero teóricamente máximo en expresividad. Es lo que tenían los modelos hasta ~2023.

Multi-Query Attention (MQA). Una sola K y V compartida por todas las cabezas. Reduce el cache n_heads veces. Funciona razonablemente pero degrada calidad de generación en algunos benchmarks.

Grouped Query Attention (GQA). El término medio que ha ganado. Las cabezas se agrupan: en Llama 3 8B, 32 cabezas de query comparten K, V en grupos de 4 → 8 grupos de KV. Reduce el cache 4× respecto a MHA con casi idéntica calidad. Es el estándar de facto desde 2024.

Multi-Head Latent Attention (MLA). La innovación de DeepSeek-V2/V3: en vez de almacenar K, V por cabeza, comprime el estado en un vector latente más pequeño y proyecta a K, V en el momento. El cache puede llegar a 70 bytes/token, dos órdenes de magnitud menos que GQA. Es la razón principal por la que DeepSeek-V3 (671 B parámetros, 37 B activos) es servible en infraestructura abordable.

Nota: la barra de MLA es ilustrativa con valores típicos publicados por DeepSeek; la implementación exacta depende del tamaño latente. Lo importante es el orden de magnitud.

A esto se suma una cuarta técnica ortogonal: cuantizar el cache a FP8, INT8 o incluso INT4. vLLM y TensorRT-LLM ya lo soportan en producción. Pasar de BF16 (2 bytes) a FP8 (1 byte) divide el cache por dos con coste pequeño en calidad. Pasar a INT4, por cuatro, con coste algo mayor.

El siguiente dragón: la fragmentación

Hasta aquí hemos hablado del cache como si fuera un bloque contiguo. En la práctica, un servidor de inferencia atiende decenas de sesiones simultáneas, cada una con su propio cache que crece a un ritmo distinto. La asignación naïve —reservar el máximo posible por sesión— desperdicia entre el 60 % y el 80 % de la VRAM según el paper original de PagedAttention.

sesión A

sesión B

sesión C

sesión D

→ ~70 % de VRAM reservada y vacía

 <rect x="0" y="22" width="30" height="20" class="used blk"/>
<rect x="30" y="22" width="30" height="20" class="used blk"/>
<rect x="60" y="22" width="30" height="20" class="used blk"/>
<rect x="90" y="22" width="30" height="20" class="used blk"/>
<rect x="120" y="22" width="30" height="20" class="used blk"/>
<rect x="150" y="22" width="30" height="20" class="used blk"/>
<rect x="180" y="22" width="30" height="20" class="free blk"/>
<rect x="210" y="22" width="30" height="20" class="free blk"/>
<rect x="0" y="44" width="30" height="20" class="used blk"/>
<rect x="30" y="44" width="30" height="20" class="used blk"/>
<rect x="60" y="44" width="30" height="20" class="used blk"/>
<rect x="90" y="44" width="30" height="20" class="free blk"/>
<rect x="120" y="44" width="30" height="20" class="free blk"/>
<rect x="150" y="44" width="30" height="20" class="free blk"/>
<rect x="180" y="44" width="30" height="20" class="free blk"/>
<rect x="210" y="44" width="30" height="20" class="free blk"/>
</g>

→ < 4 % desperdicio (paper vLLM)

PagedAttention —la idea de Kwon et al. (2023) que dio origen a vLLM— resuelve esto pidiendo prestada una técnica de los sistemas operativos: dividir la VRAM en bloques pequeños (típicamente de 16 tokens) y mantener una tabla de páginas lógicas → físicas por sesión. Una sesión ya no reserva un bloque contiguo enorme: crece un bloque cada vez, y los bloques pueden estar dispersos por la VRAM. Resultado: ocupación efectiva del 90 % en lugar del 30 %, y por tanto 2–4× más throughput agregado en el mismo hardware.

PagedAttention merece artículo propio. Lo dejo apuntado para el siguiente.

Aplicado a la infraestructura Fibercli

Bajemos a casos concretos.

Caso 1 — RTX 4090 (24 GB, Ada Lovelace)

Configuración típica con Qwen3-8B BF16:

Modelo BF16: ~16 GB
Activations + overhead: ~2 GB
VRAM disponible para KV cache: ~6 GB (con margen)

Con 144 KB/token (Qwen3-8B GQA), eso son ~43 K tokens totales de cache distribuidos entre todas las sesiones simultáneas. En la práctica:

Concurrencia	Contexto máximo por sesión
1	32 768
4	8 192
8	4 096
16	2 048

Si necesitas anunciar “soportamos 32 K de contexto” con concurrencia 4+, hay que cuantizar el cache (FP8 baja a 72 KB/token, duplica capacidad) o subir el modelo de gama (un 4B con GQA y cache cuantizado holgaría).

Caso 2 — Cluster 5×H100 SXM (400 GB total, NVLink)

Con tensor parallel = 5 y Llama 3 70B BF16:

Modelo BF16: ~140 GB (28 GB/GPU)
Overhead vLLM por GPU: ~2 GB
VRAM libre para KV por GPU: ~50 GB → ~250 GB agregados

Con 320 KB/token (Llama 3 70B GQA), eso son ~800 K tokens totales de cache. Mucho margen para servir contextos largos con concurrencia alta:

Concurrencia	Contexto máximo por sesión
4	200 000
16	50 000
64	12 500

Para DeepSeek-V3 671 B con MLA: la economía cambia radicalmente porque el cache es ~100× más fino. Lo que limita ya no es el cache sino la VRAM del propio modelo (cuantizado FP8 son ~671 GB → no cabe en 5×H100, hace falta cluster mayor o FP4).

Implicaciones operativas

Tres observaciones que repetimos en cada consultoría:

Primero, el contexto máximo anunciado por un modelo no es el que puedes servir en tu hardware. Llama 3 8B “soporta” 128 K, pero en una 4090 con 4 sesiones simultáneas tu contexto efectivo son ~8 K. Es trivial comprobarlo antes de prometérselo al cliente.

Segundo, cuantizar el KV cache es de las optimizaciones con mejor relación coste/beneficio en el contexto ENS. No toca los pesos, no afecta a la reproducibilidad de auditoría, y duplica capacidad. vLLM lo soporta vía --kv-cache-dtype fp8.

Tercero, si los SLA dictan contextos largos con muchos usuarios concurrentes, GQA es necesario pero no suficiente. A medio plazo, hay que mirar modelos con MLA o variantes de attention con compresión.

Lo que no hemos cubierto (próximos artículos)

PagedAttention y su implementación en vLLM: bloques, tabla de páginas, evicción.
Prefix caching: cuando varias peticiones comparten el system prompt, no hace falta recomputar las K, V de la parte común.
Speculative decoding y su interacción con el cache.
Cache offloading: mover bloques fríos a RAM o a NVMe, técnica clave para contextos > 1 M.

Ver también

El pipeline LLMOps de seis etapas — el mapa maestro del sistema en producción del que la etapa Deploy es una caja entre seis. Este post entra en una de las decisiones críticas dentro de Deploy.
PagedAttention por dentro: bloques, tabla de páginas, evicción y el estado del arte del KV cache en 2026 — deep-dive teórico al nivel del bloque y panorama de optimizaciones derivadas (vAttention, EvicPress, RadixAttention, speculative decoding). Continúa este post desde la teoría académica.
Fine-tuning continuo en producción: del tráfico real al adapter desplegado — cómo se cierra el ciclo entre inferencia y entrenamiento incremental sobre el mismo stack (vLLM + Postgres), con presupuestos de VRAM que incluyen explícitamente el KV cache durante eval.
Disaggregated serving: prefill y decode en pods especializados — el KV cache deja de ser un buffer privado de la GPU para convertirse en el artefacto que se transfiere entre pods. Aquí la fórmula del tamaño del cache determina la economía de la transferencia.
El cluster GPU como plataforma multi-tenant — cómo se convierte el cluster en un servicio con tenants, gateway, quotas y aislamiento. Es donde el KV cache deja de ser sólo un recurso de rendimiento y pasa a ser un asunto de plataforma.
vLLM en Kubernetes: la pieza de inferencia LLM que sí escala — el motor que materializa todo lo que aquí se discute, desplegado en K8s con tensor parallel y autoscaling.

Referencias

Vaswani et al., Attention Is All You Need (NeurIPS 2017) — paper fundacional del transformer.
Ainslie et al., GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints (EMNLP 2023).
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — paper original de vLLM.
DeepSeek-AI, DeepSeek-V2 Technical Report (2024) — introducción de Multi-Head Latent Attention.
Documentación oficial de vLLM: https://docs.vllm.ai/.
Llama 3 model card (Meta): especificaciones GQA, n_layers, n_kv_heads.

Inferencia-Llm on lo0 — Blog Técnico

Disaggregated serving: prefill y decode en pods especializados

TL;DR

Estás aquí: Deploy

La analogía: la cocina con dos brigadas

Recap rápido: prefill y decode

Por qué juntarlas en la misma GPU es un mal negocio

La idea: pods especializados, KV cache como entregable

El protocolo de transferencia: la economía del movimiento

Implementaciones reales en mayo 2026

Los números que importan

Heterogeneidad: la versión radical

Aplicado a hardware on-premise típico

Caso 1 — Una o dos RTX 4090: monolítico sigue ganando

Caso 2 — Cluster 4×H100 SXM (320 GB, NVLink): el sweet spot

Posición dentro de la arquitectura

Lo que no hemos cubierto (próximos artículos)

Ver también

Referencias

El cluster GPU como plataforma: cómo convertir un cluster compartido en un servicio multi-tenant que tus equipos puedan consumir

TL;DR

Estás aquí: Deploy + Observe (cluster como producto)

La pregunta que cambia el marco

Las cuatro capas de una plataforma de inferencia multi-tenant

Capa 1 — AI Gateway: la puerta de entrada única

Por qué centralizar

Las tres opciones dominantes 2026

Cuándo elegir cada uno

Lo que el gateway tiene que hacer mínimo

Ejemplo de configuración LiteLLM multi-tenant

Capa 2 — Policy & Quota Plane: qué puede hacer cada tenant

Quotas técnicas

Budgets económicos

Whitelist y blacklist de modelos

Priority classes

Admission control

El patrón típico en 2026

Capa 3 — Isolation Plane: aislar las cargas físicamente

Tres mecanismos NVIDIA para compartir GPU

La elección para multi-tenant 2026

Las particiones MIG en H100

Enfoque A — Modelo grande compartido con quotas en gateway

Enfoque B — Dedicar GPUs por modelo / tenant

Enfoque C (avanzado) — MIG en algunas GPUs + dedicar el resto

La elección operativa: empieza por A, sube a C si hace falta

Aislamiento a nivel Kubernetes

Capa 4 — Observability Plane: ver lo que pasa por tenant

Las cuatro propiedades obligatorias

Showback vs chargeback

Herramientas

Dashboard mínimo multi-tenant

Dimensionado en clusters GPU mid-scale: decisiones concretas

Decisiones por defecto

Esquema de tenants ejemplo

Cuándo añadir hardware

Trampas operativas comunes

Gateway sin auth: backdoor al cluster

MIG y NVLink incompatibles

Quotas pegadas al techo del cluster

Sin observabilidad multi-tenant desde el día 1

Showback que nunca llega a chargeback

Modelos no whitelisteados consumiendo presupuesto

Priority classes mal calibradas

Sin failover desde el gateway

Roadmap operativo de arranque

Lo que no hemos cubierto (próximos posts)

Referencias

Operators de inferencia LLM en Kubernetes: OME, vLLM Production Stack, NVIDIA Dynamo y llm-d

TL;DR

La analogía: de init.d a systemd a operators

Por qué un operator, y no solo un Deployment

KServe: el antecesor común

OME (Open Model Engine)

La jerarquía de CRDs

Los cuatro modos de despliegue

Integración con el ecosistema K8s

Cuándo elegirlo

vLLM Production Stack

Las tres piezas

LMCache y el tiered KV

La analogía: de `init.d` a systemd a operators

La analogía: pasar de `malloc()` al kernel multiproceso