Phase 17 - Lesson 17

Disaggregated Prefill/Decode — NVIDIA Dynamo e llm-d

O prefill é limitado por computação (compute-bound); o decode é limitado por memória (memory-bound). Executar ambos na mesma GPU desperdiça um dos recursos. A desagregação divide-os em pools separados e transfere o cache KV entre eles via NIXL (RDMA/InfiniBand ou fallback para TCP). O NVIDIA Dynamo (anúncio da GTC 2025, 1.0 GA) fica acima do vLLM/SGLang/TRT-LLM — seu Planner Profiler + SLA Planner ajustam automaticamente as proporções de prefill:decode para atender aos SLOs. A NVIDIA publica ganhos de throughput nessa faixa — developer.nvidia.com (06/2025) mostra uma melhoria de ~6x para DeepSeek-R1 MoE em GB200 NVL72 + Dynamo no regime de média latência, e a página do produto Dynamo (developer.nvidia.com, sem data) anuncia até 50x mais throughput de MoE em GB300 NVL72 + Dynamo vs Hopper. O número de "30x" é um agregado da comunidade entre relatórios da stack Blackwell + Dynamo + DeepSeek-R1; não encontramos uma única fonte primária declarando exatamente 30x, portanto, trate-o como uma alegação direcional. O llm-d (Red Hat + AWS) é nativo de Kubernetes: prefill / decode / roteador como Services independentes com HPA por função. O llm-d 0.5 adiciona descarregamento (offloading) hierárquico de KV, roteamento de LoRA ciente de cache, rede UCCL e escala até zero (scale-to-zero). Aspectos econômicos: um rollup interno de múltiplas divulgações de clientes sugere economias de 30-40% em gastos de inferência na faixa de

M (ou seja, $600-800K/ano) ao mudar de serviço compartilhado (colocated) para desagregado com Dynamo sob SLA constante; o valor específico de M→$600-800K é um composto interno, não um estudo de caso publicado — use-o como uma referência de ordem de grandeza, não como uma citação de referência. Prompts curtos (<512 tokens, saída curta) não justificam o custo de transferência.

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

Objetivos de Aprendizado

O Problema

Você executa o Llama 3.3 70B em 8 H100s. Sob carga de trabalho mista (prompts longos + saídas curtas), as GPUs ficam ociosas durante o decode porque a maior parte da computação foi gasta no prefill. Sob uma carga de trabalho diferente (prompts curtos + saídas longas), ocorre o oposto. O prefill + decode compartilhado (colocated) significa que você superprovisiona ambos.

Impacto no orçamento: 20-40% do tempo de GPU é desperdiçado no recurso errado. Você está comprando computação H100 para executar decode limitado por memória, ou comprando largura de banda de HBM da H100 para executar prefill limitado por computação. Ambos representam um desperdício caro.

A desagregação divide o prefill e o decode em pools separados dimensionados para o gargalo de cada um. O cache KV é transferido do pool de prefill para o pool de decode por meio de uma interconexão de alta largura de banda.

O Conceito

Por que os gargalos diferem

Prefill — executa o transformer sobre todo o prompt de entrada em uma única passagem direta (forward). As multiplicações de matrizes dominam; limitado por computação (compute-bound). O FP8 da H100 oferece ~2000 TFLOPS de throughput útil. A eficiência de lote (batch) é boa — uma passagem direta processa muitos tokens.

Decode — gera um token por vez, lendo todos os pesos a cada iteração. Limitado por largura de banda de memória (memory-bandwidth-bound). A HBM3 oferece ~3 TB/s. A eficiência de lote é boa apenas com alta concorrência — a leitura de pesos é amortizada ao longo do lote.

Compartilhá-los: você compra GPUs otimizadas para ambos. A H100 é boa em ambos, mas custa o mesmo de qualquer maneira. Em escala, você deseja o pool de prefill em H100 / pesado em computação; pool de decode em H200 / pesado em memória, ou com quantização agressiva.

A arquitetura

                 ┌──────────────┐
  Requisição →   │   Roteador   │ ───────────────────────┐
                 └──────┬───────┘                        │
                        │                                │
                        ▼ (apenas prompt)                │
                 ┌──────────────┐    Cache KV    ┌───────▼──────┐
                 │Pool de prefill│ ─── NIXL ───► │Pool de decode│
                 │ (computação) │                │  (memória)   │
                 └──────────────┘                └──────┬───────┘
                                                        │ tokens
                                                        ▼
                                                     Cliente

NIXL é o transporte inter-nós da NVIDIA. Usa RDMA/InfiniBand quando disponível, com fallback para TCP caso contrário. A latência de transferência é real — tipicamente de 20 a 80 ms para o cache KV de um prompt de 4K tokens no 70B FP8. É por isso que prompts curtos não justificam a desagregação: a taxa de transferência excede a economia.

Dynamo vs llm-d

NVIDIA Dynamo (anúncio da GTC 2025, 1.0 GA):

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

Use o Dynamo se desejar um orquestrador gerenciado acima da stack. Use o llm-d se desejar primitivos nativos do Kubernetes e estiver comprometido com o ecossistema CNCF.

Aspectos Econômicos

Composto interno (não é um único estudo de caso publicado — âncora de ordem de grandeza):

Sintetizamos esse número a partir de múltiplas divulgações de clientes, em vez de um único estudo de caso citável; o ponto de dados publicado mais próximo é o da Baseten com TTFT 2x mais rápido / throughput 61% maior com roteamento Dynamo KV (baseten.co, 10/2025), e a projeção da VAST + CoreWeave de 60-130% mais tokens/$ a uma taxa de hit de KV de 40-60% (vastdata.com, 12/2025). As economias vêm do dimensionamento correto de cada pool; cargas de trabalho pesadas em prefill (RAG com prefixos de 8K+) se beneficiam mais do que as equilibradas.

Quando NÃO desagregar

O roteador integra-se com a Fase 17 · 11

Os roteadores desagregados são cientes do cache KV (Fase 17 · 11). Uma requisição chega ao pool de decode que contém seu prefixo — se não houver correspondência, o fluxo segue prefill → decode. A taxa de acerto (hit rate) e a desagregação se complementam — o roteador ciente do cache determina se um novo prefill é sequer necessário.

MoE na Blackwell é onde os números reais estão

O GB300 NVL72 + Dynamo mostra um throughput de MoE de até 50x em relação aos baselines Hopper. O roteamento de especialistas (expert routing) do MoE é pesado em computação no prefill, mas pesado em memória no decode (caches de especialistas), de modo que a desagregação é uma vitória dupla. O serviço de modelos de fronteira em 2026 é dominado por MoE (DeepSeek-V3, futuras variantes do GPT-5).

Números que você deve lembrar

Os números de benchmark variam — a NVIDIA e a stack de inferência postam resultados atualizados a cada trimestre. Verifique novamente antes de citar.

Use

code/main.py simula o serviço compartilhado vs desagregado. Relata o throughput, o custo por requisição e o ponto de cruzamento do comprimento do prompt.

Coloque em Produção

Esta lição produz outputs/skill-disaggregation-decider.md. Dada a carga de trabalho e o cluster, decide se deve desagregar.

Exercícios

  1. Execute code/main.py. Em qual comprimento de prompt a desagregação supera o compartilhamento?
  2. Projete o pool de prefill e o pool de decode para um serviço de RAG com comprimento de prefixo P99 de 8K e saída de 300.
  3. Dynamo vs llm-d: escolha um para uma operação puramente em Kubernetes sem preferência de runtime Python.
  4. Calcule o custo de transferência de KV: prefill de 4K no 70B FP8 = ~500 MB de KV. Em RDMA a 100 GB/s, a transferência = 5 ms. Em TCP a 10 GB/s = 50 ms. Qual deles importa para o seu SLA?
  5. O roteamento de especialistas MoE altera os padrões de acesso ao KV. Como a desagregação se comporta com MoE que ativa diferentes especialistas por token?

Termos-Chave

Termo O que dizem O que realmente significa
Serviço desagregado "separar prefill/decode" Pools de GPU separados para cada fase
NIXL "transporte da NVIDIA" Transferência de KV inter-nós do Dynamo (RDMA/TCP)
NVIDIA Dynamo "o orquestrador" Coordenador acima da stack para vLLM/SGLang/TRT-LLM
llm-d "nativo de Kubernetes" Stack desagregada K8s da Red Hat + AWS
Planner Profiler "auto-configuração do Dynamo" Mede a carga de trabalho, configura proporções de pools
SLA Planner "política do Dynamo" Combina taxas de prefill:decode para atingir SLOs
packDomain: rack "topologia do llm-d" Agrupa prefill+decode no mesmo rack para KV rápido
UCCL "coletivo unificado" Camada de rede do llm-d 0.5 para escala até zero
Roteamento de especialistas MoE "especialista por token" Padrão do DeepSeek-V3; a desagregação ajuda

Leituras Adicionais