Sglang on lo0 — Blog Técnico

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.

Sglang on lo0 — Blog Técnico

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

Manifest típico (values.yaml)

Cuándo elegirlo

NVIDIA Dynamo

Qué es exactamente

Las cuatro contribuciones

Grove: scheduler propio

Cuándo elegirlo

llm-d

Filosofía

Números

CNCF y futuro

Cuándo elegirlo

El antecesor común sigue ahí: KServe

Mapa de decisión

Cuándo elegir cada uno

Escenarios concretos

Trampas comunes

Lo que no hemos cubierto

Cerrando la serie

Referencias

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

TL;DR

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

El paper original, en cristiano

El modelo de bloques

La tabla de páginas (block table)

El pool de bloques

Copy-on-write para sampling paralelo

El kernel CUDA

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

Estrategia 1: recompute

Estrategia 2: swap

El problema de la preemption agresiva

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

Chunked prefill integrado con paged KV

Prefix caching cross-session

Sliding window attention

FlashAttention-3 paged

vAttention: paging sin reescribir el kernel

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

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

H2O, SnapKV (2024): eviction por attention score

EvicPress (Microsoft Research, 2026)

KV Cache Transform Coding (KVTC, 2026)

LaProx (2026)

Disaggregated serving: separar prefill de decode

El problema de mezclarlos

DistServe (Zhong et al., 2024)

Splitwise (Microsoft, 2024)

2026: producción

PPD: no todos los prefills son iguales (2026)

RadixAttention: el camino alternativo (SGLang)

La idea

Eviction inteligente del trie

Resultados

Producción

Cuándo elegirlo sobre vLLM

Speculative decoding: la dimensión ortogonal

EAGLE-3 (2025)

Medusa y DeepSeek MTP

Mirror Speculative Decoding (2025)

Estado en 2026

Implicaciones operativas: el config 2026 para vLLM

Trampas y mitos comunes

“PagedAttention vs vAttention” como dilema

“Cache compression sin probar calidad”

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

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