Phase 17 - Lesson 17

Disaggregated Prefill/Decode — NVIDIA Dynamo y llm-d

El prefill está limitado por cómputo (compute-bound); el decode está limitado por memoria (memory-bound). Ejecutar ambos en la misma GPU desperdicia un recurso. La desagregación los divide en pools separados y traslada el caché KV entre ellos a través de NIXL (RDMA/InfiniBand o fallback de TCP). NVIDIA Dynamo (anuncio de GTC 2025, 1.0 GA) se sitúa por encima de vLLM/SGLang/TRT-LLM — su Planner Profiler + SLA Planner ajustan automáticamente las proporciones de prefill:decode para cumplir con los SLO. NVIDIA publica ganancias de rendimiento (throughput) en este rango — developer.nvidia.com (06/2025) muestra una mejora de ~6x para DeepSeek-R1 MoE en GB200 NVL72 + Dynamo en el régimen de latencia media, y la página del producto Dynamo (developer.nvidia.com, sin fecha) anuncia hasta 50x de rendimiento MoE en GB300 NVL72 + Dynamo vs Hopper. La cifra de "30x" es un agregado de la comunidad en los informes de la stack Blackwell + Dynamo + DeepSeek-R1; no hemos encontrado una sola fuente primaria que declare exactamente 30x, por lo que debe tratarse como una afirmación direccional. llm-d (Red Hat + AWS) es nativo de Kubernetes: prefill / decode / enrutador como Services independientes con HPA por rol. llm-d 0.5 agrega descarga (offloading) jerárquica de KV, enrutamiento LoRA consciente de caché, red UCCL y escala a cero (scale-to-zero). Aspectos económicos: un consolidado interno de múltiples divulgaciones de clientes sugiere ahorros del 30–40% en un gasto de inferencia de la clase de

M (es decir, $600-800K/año) al cambiar de servicio compartido (colocated) a desagregado con Dynamo a un SLA constante; la cifra específica de M→$600-800K es un compuesto interno, no un estudio de caso publicado — úselo como un anclaje de orden de magnitud, no como una cita de referencia. Los prompts cortos (<512 tokens, salida corta) no justifican el costo de transferencia.

Type: Learn Languages: Python (stdlib, simulador simple de desagregado vs compartido) Prerequisites: Phase 17 · 04 (vLLM Serving Internals), Phase 17 · 08 (Inference Metrics) Time: ~75 minutos

Objetivos de Aprendizaje

El Problema

Ejecuta Llama 3.3 70B en 8 H100s. Bajo una carga de trabajo mixta (prompts largos + salidas cortas), las GPUs quedan inactivas durante el decode porque la mayor parte del cómputo se gastó en el prefill. Bajo una carga de trabajo diferente (prompts cortos + salidas largas), ocurre lo contrario. Un prefill + decode compartido (colocated) significa que superprovisiona ambos.

Impacto en el presupuesto: entre el 20% y el 40% del tiempo de GPU se desperdicia en el recurso incorrecto. Está comprando cómputo de H100 para ejecutar decode limitado por memoria, o comprando ancho de banda de HBM de H100 para ejecutar prefill limitado por cómputo. Ambos son desperdicios costosos.

La desagregación divide el prefill y el decode en pools independientes dimensionados para el cuello de botella de cada uno. El caché KV se transfiere desde el pool de prefill al pool de decode mediante una interconexión de alto ancho de banda.

El Concepto

Por qué difieren los cuellos de botella

Prefill — ejecuta el transformer sobre todo el prompt de entrada en una sola pasada hacia adelante (forward). Las multiplicaciones de matrices dominan; limitado por cómputo (compute-bound). El FP8 de la H100 ofrece ~2000 TFLOPS de rendimiento (throughput) útil. La eficiencia de lote (batch) es buena — una pasada procesa muchos tokens.

Decode — genera un token a la vez, leyendo todos los pesos en cada iteración. Limitado por el ancho de banda de la memoria (memory-bandwidth-bound). HBM3 ofrece ~3 TB/s. La eficiencia de lote es buena solo a alta concurrencia — la lectura de pesos se amortiza a lo largo del lote.

Compartirlos: compra GPUs optimizadas para ambos. H100 es buena en ambos pero cuesta lo mismo de cualquier manera. A escala, querrá el pool de prefill en H100 / pesado en cómputo; el pool de decode en H200 / pesado en memoria, o con cuantización agresiva.

La arquitectura

                 ┌──────────────┐
  Solicitud →    │  Enrutador   │ ───────────────────────┐
                 └──────┬───────┘                        │
                        │                                │
                        ▼ (solo prompt)                  │
                 ┌──────────────┐    Caché KV    ┌───────▼──────┐
                 │Pool de prefill│ ─── NIXL ───► │Pool de decode│
                 │  (cómputo)   │                │  (memoria)   │
                 └──────────────┘                └──────┬───────┘
                                                        │ tokens
                                                        ▼
                                                     Cliente

NIXL es el transporte inter-nodos de NVIDIA. Utiliza RDMA/InfiniBand quando está disponible, con fallback a TCP de lo contrario. La latência de transferência es real — típicamente de 20 a 80 ms para el caché KV de un prompt de 4K tokens en 70B FP8. Es por esto que los prompts cortos no justifican la desagregación: la tasa de transferencia supera el ahorro.

Dynamo vs llm-d

NVIDIA Dynamo (anuncio de GTC 2025, 1.0 GA):

llm-d (Red Hat + AWS, nativo de Kubernetes):

Use Dynamo si desea un orquestador administrado por encima del resto de la stack. Use llm-d si desea primitivas nativas de Kubernetes y está comprometido con el ecosistema CNCF.

Aspectos Económicos

Consolidado interno (no es un solo estudio de caso publicado — anclaje de orden de magnitud):

Sintetizamos esta cifra a partir de múltiples divulgaciones de clientes en lugar de un único estudio de caso referenciable; el punto de datos publicado más cercano es la mejora de TTFT 2x más rápido / rendimiento 61% mayor de Baseten con el enrutamiento Dynamo KV (baseten.co, 10/2025), y la proyección de VAST + CoreWeave de 60–130% más tokens/$ a una tasa de acierto de KV de 40–60% (vastdata.com, 12/2025). Los ahorros provienen de dimensionar adecuadamente cada pool; las cargas de trabajo pesadas en prefill (RAG con prefijos de más de 8K) se benefician más que las equilibradas.

Cuándo NO desagregar

El enrutador se integra con la Fase 17 · 11

Los enrutadores desagregados son conscientes del caché KV (Fase 17 · 11). Una solicitud llega al pool de decode que tiene su prefijo — si no hay coincidencia, el flujo sigue prefill → decode. La tasa de aciertos y la desagregación se complementan — el enrutador consciente del caché determina si es necesario un nuevo prefill.

MoE en Blackwell es donde están los números reales

GB300 NVL72 + Dynamo muestra un rendimiento MoE hasta 50x en comparación con las líneas base de Hopper. El enrutamiento de expertos de MoE es pesado en cómputo en prefill pero pesado en memoria en decode (cachés de expertos), por lo que la desagregación es una ganancia doble. El servicio de modelos de frontera en 2026 está dominado por MoE (DeepSeek-V3, futuras variantes de GPT-5).

Números que debe recordar

Los números de los benchmarks varían — NVIDIA y la stack de inferencia publican resultados actualizados cada trimestre. Verifique antes de citar.

Uso

code/main.py simula el servicio compartido vs desagregado. Informa del rendimiento, el costo por solicitud y el cruce de longitud del prompt.

Puesta en Producción

Esta lección produce outputs/skill-disaggregation-decider.md. Dada la carga de trabajo y el cluster, decide si se debe desagregar.

Ejercicios

  1. Ejecute code/main.py. ¿En qué longitud de prompt la desagregación supera a la compartición?
  2. Diseñe el pool de prefill y el pool de decode para un servicio de RAG con una longitud de prefijo P99 de 8K y una salida de 300.
  3. Dynamo vs llm-d: elija uno para un entorno puramente de Kubernetes sin preferencia de entorno de ejecución de Python.
  4. Calcule el costo de transferencia de KV: prefill de 4K en 70B FP8 = ~500 MB de KV. A 100 GB/s de RDMA, transferencia = 5 ms. A 10 GB/s de TCP = 50 ms. ¿Cuál de ellos importa para su SLA?
  5. El enrutamiento de expertos MoE cambia los patrones de acceso a KV. ¿Cómo se comporta la desagregación con MoE que activa diferentes expertos por token?

Términos Clave

Término Lo que la gente dice Lo que realmente significa
Servicio desagregado "separar prefill/decode" Pools de GPU separados para cada fase
NIXL "transporte de NVIDIA" Transferencia de KV inter-nodos de Dynamo (RDMA/TCP)
NVIDIA Dynamo "el orquestador" Coordinador por encima de la stack para vLLM/SGLang/TRT-LLM
llm-d "nativo de Kubernetes" Stack desagregada de K8s de Red Hat + AWS
Planner Profiler "auto-configuración de Dynamo" Mide la carga de trabajo, configura proporciones de pools
SLA Planner "política de Dynamo" Adapta las proporciones de prefill:decode para cumplir con los SLO
packDomain: rack "topologia de llm-d" Agrupa prefill+decode en el mismo rack para transferencia rápida de KV
UCCL "colectivo unificado" Capa de red de llm-d 0.5 para escala a cero
Enrutamiento de expertos MoE "experto por token" Patrón de DeepSeek-V3; la desagregación ayuda

Lecturas Adicionales