Capítulo 12 — Serving desagregado y Kubernetes
Duodécima entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que por fin parte prefill y decode en flotas GPU distintas y muestra las primitivas de Kubernetes que mantienen los pods del lado correcto de la interconexión.
Por qué existe este capítulo
El Capítulo 11 trazó una frontera limpia entre motores y plataformas — hasta que el propio motor señala que prefill y decode son cargas contradictorias. Prefill está limitado por cómputo; decode está limitado por ancho de banda de memoria. Ejecutarlos sobre la misma GPU obliga a un pedazo de hardware a ser bueno en dos cosas contradictorias y acaba mediocre en ambas. El serving desagregado los parte en flotas GPU distintas, envía la caché KV entre las flotas y permite que cada flota se ajuste a su propia carga. El precio es complejidad operativa, pagada en primitivas de Kubernetes, en topología de pods y en la red que transporta el tráfico KV. El Capítulo 12 recorre la forma de esa complejidad — los componentes, la ruta de transferencia y los CRDs (LeaderWorkerSet, PodCliqueSet de Grove, KAI Scheduler) que la expresan.
12.1 Prefill y decode quieren chips distintos a relojes distintos
Sobre el mismo H100, un prefill largo puede alcanzar genuinamente el 60–80 por ciento del pico de FLOPs, y un paso de decode usa el 5–15 por ciento de FLOPs mientras satura el 70–90 por ciento del ancho de banda HBM. Intercalarlos bajo batching continuo es un compromiso viable pero fuga por dos sitios. El pass de cómputo del prefill golpea el mismo bus HBM sobre el que los decodes en cola intentan hacer streaming, y el tiempo entre tokens se infla. La tarjeta también corre en un único punto de operación: ajusta para prefill y el decode va estrangulado por ancho de banda; ajusta para decode y el prefill va estrangulado por cómputo. Los prompts se han alargado de cientos a miles de tokens conforme RAG y agentes han tomado el tráfico de producción, y el coste del intercalado ha crecido con ellos. La desagregación da a cada fase su propia flota. Los workers de prefill pueden correr sobre tarjetas de FLOPs brutos (H100 SXM, B200). Los workers de decode pueden correr sobre tarjetas de capacidad y ancho de banda (H200, MI300X). Cada flota se dimensiona a su propia carga — un tráfico de contexto largo y salida corta necesita más prefill; el tráfico de chat necesita más decode.
12.2 La forma son cuatro componentes más una ruta de transferencia de KV
Un despliegue desagregado funcional tiene cuatro componentes. Los workers de prefill aceptan una petición, computan el prefill, emiten el primer token y preparan la caché KV para transferir. Los workers de decode aceptan una caché KV entrante y sus metadatos, la instalan en su pool de atención paginada y ejecutan batching continuo sobre sus generaciones en curso. Un router de caché KV — el plano de control — mantiene una vista de la capacidad libre de KV de cada worker de decode, del llenado de su batch y de la localidad de red, y asigna la salida de cada prefill para minimizar el coste de transferencia y balancear la carga. Un gateway de frontend termina la conexión HTTP del usuario, hace streaming del primer token desde el worker de prefill y luego cambia de forma transparente a hacer streaming del resto desde el worker de decode. La restricción crítica es la transferencia de KV: una secuencia GQA de 70B a 4.096 tokens son 1,5–2 GB, y tiene que moverse del nodo de prefill al de decode dentro del mismo presupuesto de TTFT de 50–100 ms que el usuario está mirando. NVLink a 900 GB/s dentro de un nodo e InfiniBand a 400 Gb/s entre nodos hacen que los números salgan — si los pods aterrizan del lado correcto de la red.
12.3 LeaderWorkerSet, Grove y KAI expresan la topología
Kubernetes no tenía originalmente una primitiva para "estos dos pods tipados son una réplica lógica". LeaderWorkerSet, añadido upstream en 2024, expresa una réplica multi-pod con un leader (digamos prefill) y workers (digamos decodes); el controlador mantiene el grupo como una única unidad de scheduling. PodCliqueSet de NVIDIA Grove (2025, parte de NVIDIA AI Enterprise) generaliza más con cliques tipadas (prefill, decode, router), cada una con su propia plantilla y tamaño, más una descripción de topología de clique de cómo se relacionan las cliques. Grove somete el conjunto entero al scheduler junto con restricciones de localidad intra-clique e inter-clique. Ninguno de los dos CRDs basta por sí solo; ambos necesitan un scheduler que conozca la topología física del cluster, lo que el scheduler por defecto de Kubernetes no hace. KAI Scheduler — open-sourced desde Run:ai en 2024 — consume un grafo de topología producido por nvidia-smi topo --matrix y el subnet manager de InfiniBand, y puntúa colocaciones candidatas contra él. Cuando una clique de Grove pide nvlinkDomain: required, KAI restringe la colocación a un único dominio coherente NVLink (las ocho GPUs de una baseboard HGX sobre un NVSwitch). Cuando la topología inter-clique dice sameInfiniBandIsland, KAI mantiene las cliques dentro de un mismo grupo de leaf-switch donde el round-trip de KV se queda bajo 100 μs.
Lo que prepara el Capítulo 12
El Capítulo 12 dio al despliegue una foto estática: en un momento dado, un número fijo de cliques está corriendo y sirviendo tráfico. El tráfico real no es estático — los asistentes de chat oscilan 30× de pico a valle a lo largo del día, las herramientas de desarrollador van a cero los fines de semana, los productos de consumo siguen al sol. El Capítulo 13 recorre la historia del autoscaling: por qué el HPA estándar es el scaler equivocado para el serving de LLMs, qué señales KEDA escala en su lugar, cómo Knative expresa la escala-a-cero, y qué comprime un cold start de 60–180 segundos hasta algo que una aplicación de cara al usuario pueda absorber.
Próximamente — Capítulo 13: Autoscaling y mitigación de cold start. KEDA, Knative, CRIU, cache de CUDA graphs, NVMe — el stack que permite que la escala-a-cero conviva con usuarios reales.
