# DPD no HyperPod: Prefill e Decode Disagregados em Produção

O SageMaker HyperPod agora suporta Disaggregated Prefill and Decode (DPD), separando as duas fases de inferência LLM em pools de GPU dedicados conectados via EFA e GPU-Direct RDMA. Essa mudança resolve um dos problemas mais persistentes em produção: um único request de contexto longo degradando a latência de token de todos os requests concorrentes. Neste artigo, analiso os trade-offs reais, os padrões de falha que você vai encontrar e um playbook para habilitar DPD em workloads financeiros de alta exigência.

- URL: https://fernando.moretes.com/blog/dpd-no-hyperpod-prefill-e-decode-disagregados-em-producao-amazon-sagem

- Markdown: https://fernando.moretes.com/blog/dpd-no-hyperpod-prefill-e-decode-disagregados-em-producao-amazon-sagem/article.md?lang=pt

- Published: 2026-07-07T09:03:51.930Z

- Category: IA & Agentes

- Tags: sagemaker-hyperpod, llm-inference, disaggregated-inference, gpu-optimization, efa-rdma, kv-cache, financial-ai, mlops

- Reading time: 10 min

- Source: [Amazon SageMaker HyperPod now supports disaggregated prefill and decode](https://aws.amazon.com/about-aws/whats-new/2026/7/amazon-sagemaker-hyperpod-dpd/)

---

Desde que comecei a trabalhar com inferência LLM em ambientes financeiros de produção, o problema mais difícil não era o modelo em si — era a contenção entre prefill e decode no mesmo hardware. Um único request de análise de contrato de 32 mil tokens conseguia silenciosamente arruinar o P99 de latência de token de centenas de requests simultâneos de chat. O DPD no HyperPod é a primeira resposta nativa da AWS que ataca esse problema na camada certa: separação de recursos com transferência de KV cache via RDMA, sem mudar o modelo e sem reescrever o serving stack.

## Por que prefill e decode são problemas fundamentalmente diferentes

Prefill e decode têm perfis de hardware completamente opostos, e esse é o ponto central que justifica toda a arquitetura DPD. O prefill processa todos os tokens do prompt de uma só vez em uma única passagem forward — é compute-bound, satura FLOPs de GPU e se beneficia de GPUs com alta densidade de cálculo (como H100 SXM). O decode, por outro lado, gera um token por vez em autoregressive fashion — é memory-bandwidth-bound, porque a cada passo precisa carregar os pesos do modelo e o KV cache inteiro da VRAM para os registradores de cálculo. Isso significa que colocar os dois na mesma GPU é um compromisso estrutural: você está usando hardware de compute intensivo para um workload limitado por bandwidth de memória.

O problema se agrava com contextos longos. Um prompt de 128k tokens em um modelo de 70B parâmetros pode levar centenas de milissegundos só no prefill — durante esse tempo, a GPU está completamente ocupada e os requests de decode em fila ficam parados. O resultado prático em produção é o que chamamos de **prefill stall**: o Time to First Token (TTFT) explode para requests de decode concorrentes, e o Inter-Token Latency (ITL) fica errático. Em sistemas financeiros onde você tem SLOs de P95 < 200ms para ITL em assistentes de atendimento ao cliente, um único request de análise de documento longo pode violar SLOs de dezenas de usuários simultâneos.

A solução clássica era over-provisionar — manter GPUs suficientes para que a contenção fosse rara. Com DPD, a lógica muda: você dimensiona prefill e decode independentemente, de acordo com a distribuição real do seu tráfego.

## Arquitetura DPD no SageMaker HyperPod com EKS

Fluxo de inferência disagregada: o roteador inteligente direciona requests curtos diretamente ao pool de decode e requests longos pelo caminho prefill→KV transfer→decode via EFA RDMA.

### 🌐 Ingress & Routing

- Intelligent Router HyperPod Inference Op. (edge)
- API Gateway or ALB (frontend)

### ⚡ Prefill Pool (compute-bound)

- Prefill Node H100 / p5.48xlarge (compute)
- Prefill Node H100 / p5.48xlarge (compute)

### 🔄 KV Cache Transfer

- EFA + GPU-Direct RDMA Transfer KV Cache Tensor (network)

### 🧠 Decode Pool (bandwidth-bound)

- Decode Node H100 / p5.48xlarge (ai)
- Decode Node H100 / p5.48xlarge (ai)
- Decode Node H100 / p5.48xlarge (ai)

### 📦 Config & Observability

- InferenceEndpointConfig pdSpec CRD (ci)
- CloudWatch ITL / TTFT / Goodput (data)

### Fluxos

- client -> apigw: request HTTP/S
- apigw -> router: encaminha
- router -> prefill1: contexto longo
- router -> decode1: prompt curto (bypass)
- prefill1 -> efa: KV cache tensor
- prefill2 -> efa: KV cache tensor
- efa -> decode1: RDMA write
- efa -> decode2: RDMA write
- decode1 -> cw: métricas ITL/TTFT
- crd -> router: configura pdSpec

## O que a transferência de KV cache via EFA RDMA realmente significa para latência

O KV cache é a estrutura de dados que armazena as projeções de chave e valor calculadas durante o prefill para cada camada do transformer. Para um modelo de 70B parâmetros com contexto de 32k tokens, o KV cache pode facilmente ocupar 10-20 GB dependendo da precisão (fp16/bf16) e do número de camadas. Transferir esse volume entre nós em tempo real é o desafio central do DPD — e é aqui que o EFA com GPU-Direct RDMA faz diferença concreta.

GPU-Direct RDMA permite que a GPU escreva diretamente na memória de outra GPU em outro nó, sem passar pela CPU e sem copiar dados para a RAM do host. Em termos práticos, com EFA em instâncias p5.48xlarge (que possuem 3200 Gbps de largura de banda EFA agregada), a transferência de um KV cache de 16 GB pode ocorrer em dezenas de milissegundos — uma fração do tempo que o decode levaria para gerar os primeiros tokens de qualquer forma. O overhead de transferência, portanto, é absorvido pelo pipeline e não aparece como latência adicional perceptível para o usuário final em contextos longos.

O ponto crítico é o sizing correto do pool de prefill em relação ao pool de decode. Se o pool de prefill for subdimensionado, o KV cache se acumula esperando slots de transferência e você recria o problema de stall que estava tentando resolver — agora na camada de rede em vez da GPU. A recomendação que tenho aplicado é monitorar a fila de transferência de KV cache como uma métrica de primeira classe, com alarme em CloudWatch quando o tempo médio de espera de transferência exceder 15% do TTFT alvo.

## Impacto esperado do DPD em workloads de produção

- **~60%** — Redução no P99 de ITL sob carga mista. Requests de decode não mais bloqueados por prefill de contexto longo
- **10–20 GB** — Tamanho típico de KV cache para 70B / 32k tokens (bf16). Volume transferido via EFA RDMA por request disagregado
- **1:2–1:3** — Razão típica prefill:decode nodes para RAG financeiro. Ajuste conforme distribuição real de input/output tokens do seu tráfego
- **3200 Gbps** — Largura de banda EFA agregada em p5.48xlarge. Habilita transferência de KV cache sem gargalo de rede para a maioria dos modelos

## Configurando DPD: o que o pdSpec realmente controla

A habilitação de DPD é feita adicionando uma seção `pdSpec` ao `InferenceEndpointConfig` custom resource que você já usa com o HyperPod Inference Operator no EKS. Isso é arquiteturalmente importante: não é um novo tipo de recurso, não é uma nova API, é uma extensão do CRD existente. Isso significa que sua pipeline de GitOps, seus workflows de aprovação e seus controles de RBAC no Kubernetes continuam funcionando sem alteração.

O `pdSpec` controla três dimensões principais: (1) a definição dos pools — quantos nós de prefill e quantos de decode, em quais instance types; (2) a política de roteamento — o threshold de tokens acima do qual o router direciona para o caminho disagregado em vez de enviar diretamente ao decoder; e (3) a composição com KV cache offloading, que permite que o cache seja parcialmente movido para CPU memory ou NVMe quando a VRAM do pool de decode estiver sob pressão.

O ponto que mais vejo ser ignorado em implementações iniciais é o threshold do router. O anúncio deixa claro que o router inteligente envia prompts curtos diretamente ao decoder — isso é correto, porque para prompts de 512 tokens ou menos, o overhead de transferência de KV cache via RDMA pode ser comparável ao tempo de prefill em si, eliminando o benefício. Na prática, tenho usado 2048 tokens como threshold inicial e ajustando com base em medições reais de TTFT nos dois caminhos. Você quer que o threshold esteja no ponto onde o tempo de transferência de KV cache seja menor que a diferença de TTFT entre prefill no decoder vs. prefill no pool dedicado.

Para ambientes financeiros com requisitos de isolamento de dados, vale notar que os pools de prefill e decode operam dentro do mesmo cluster HyperPod EKS, então os controles de VPC, security groups e IAM que você já tem se aplicam. O tráfego de KV cache via EFA não sai da rede física do cluster.

## Playbook: Habilitando DPD em um endpoint HyperPod existente

1. **Audite a distribuição de tokens do seu tráfego atual** — Antes de qualquer mudança, colete histogramas de input token count e output token count por tipo de request (chat, RAG, análise de documento). Você precisa saber qual percentual do tráfego tem prompt > 2048 tokens — esse é o tráfego que se beneficia do caminho disagregado. Se for menos de 10% do volume mas causa 80% dos P99 violations, DPD é exatamente o que você precisa.

2. **Verifique pré-requisitos: EFA-capable instances e HyperPod EKS orchestrator** — DPD requer o orquestrador EKS (não Slurm) e instance types com suporte a EFA. As instâncias p5.48xlarge (8x H100 SXM, 3200 Gbps EFA) são o target principal. Confirme que seu cluster tem o HyperPod Inference Operator atualizado para a versão que inclui o campo pdSpec no CRD InferenceEndpointConfig — verifique o release notes do HyperPod Inference.

3. **Defina a topologia inicial de pools no pdSpec** — Comece com uma razão conservadora: 1 nó de prefill para 2 nós de decode. Para workloads de RAG financeiro com documentos longos (32k-128k tokens), considere 1:1 inicialmente. Defina o threshold do router em 2048 tokens. Especifique o mesmo instance type para ambos os pools na primeira iteração — isso simplifica o capacity planning e o troubleshooting.

4. **Instrumente TTFT, ITL e KV transfer queue antes do rollout** — Configure CloudWatch dashboards com: (a) TTFT P50/P95/P99 separado por caminho (disaggregado vs. direto), (b) ITL P50/P95/P99 por tipo de request, (c) KV cache transfer latency e queue depth no pool de prefill. Sem esses sinais, você não consegue distinguir se um problema de latência é do prefill, da transferência ou do decode.

5. **Habilite DPD em staging com traffic shadowing antes de produção** — Use o HPA do Kubernetes para configurar autoscaling independente nos pools de prefill e decode baseado em métricas customizadas (queue depth, GPU utilization por fase). Faça shadow traffic do seu percentil 99 de requests mais longos contra o endpoint DPD em staging e compare TTFT/ITL com o endpoint monolítico. Só promova para produção quando o P95 de TTFT no caminho disagregado for ≤ TTFT monolítico + overhead de transferência medido.

6. **Ative composição com KV cache offloading para decode pool sob pressão de VRAM** — O anúncio confirma que DPD é composável com KV cache offloading existente. Para modelos grandes (70B+) com alta concorrência, o decode pool pode ficar sem VRAM para armazenar todos os KV caches ativos. Habilite offloading para CPU memory como primeira camada e NVMe como segunda, e monitore hit rate do cache em VRAM — se cair abaixo de 70%, considere adicionar nós de decode antes de depender do offloading.

> **Threshold do roteador: o parâmetro mais impactante que ninguém ajusta:** O threshold de tokens do roteador inteligente determina qual percentual do seu tráfego paga o overhead de transferência de KV cache via RDMA. Defina muito baixo e você penaliza requests curtos com latência de rede desnecessária. Defina muito alto e os requests médios continuam causando stall no decoder. Meça o TTFT nos dois caminhos em produção com A/B routing por pelo menos 24 horas antes de fixar o valor — a distribuição de tokens muda significativamente entre horário de pico e off-peak em sistemas financeiros.

## DPD em pipelines agenticos e RAG financeiro: o caso de uso que mais justifica a mudança

O caso de uso onde DPD entrega o maior retorno em ambientes financeiros não é o chat simples — é o pipeline agentico com RAG sobre documentos longos. Considere um agente de análise de contratos que, em cada step do ReAct loop, faz retrieval de chunks de documentos regulatórios (CVM, BACEN, IOSCO) e os inclui no contexto. Cada invocação do LLM pode ter 16k-64k tokens de contexto, seguida de uma resposta curta de 200-500 tokens. Esse padrão — prefill longo, decode curto — é exatamente o perfil que mais sofre com contenção em hardware monolítico e mais se beneficia com DPD.

Em um sistema que tenho desenhado para análise de compliance de derivativos, o padrão de tráfego é: 70% dos requests têm menos de 1024 tokens (perguntas de chat do analista), 25% têm entre 4k e 32k tokens (RAG sobre regulação), e 5% têm mais de 64k tokens (análise completa de contrato). Esse 5% era responsável por mais de 60% das violações de SLO de ITL. Com DPD, esses requests vão para o pool de prefill dedicado, e os 70% de requests curtos nunca são afetados.

Há uma implicação de custo importante aqui: com hardware monolítico, você precisava over-provisionar o cluster inteiro para proteger o P99 desse 5%. Com DPD, você dimensiona o pool de prefill para absorver o throughput de prefill necessário e o pool de decode para o throughput de geração — e esses dois números são muito diferentes. Em termos práticos, para o padrão descrito acima, o pool de prefill pode ser 30-40% menor que o pool de decode, resultando em redução de custo total mesmo adicionando a complexidade da disagregação.

A composabilidade com KV cache offloading mencionada no anúncio é particularmente relevante aqui: em pipelines agenticos com múltiplos steps, o mesmo KV cache pode ser reutilizado entre chamadas se o contexto for incrementalmente expandido. Isso é prefix caching, e quando combinado com DPD, você pode ter o KV cache do prefill de um step anterior já disponível no pool de decode para o próximo step, reduzindo TTFT em steps subsequentes do agente.

## Anti-padrões que vejo repetidamente em implementações de DPD

- **Usar instance types diferentes para prefill e decode na primeira implementação.** A diferença de VRAM e bandwidth entre, digamos, p5.48xlarge (prefill) e p4d.24xlarge (decode) complica o sizing e o troubleshooting. Comece homogêneo, diferencie depois com dados.
- **Ignorar a fila de transferência de KV cache como métrica de observabilidade.** Equipes focam em GPU utilization e esquecem que o gargalo pode estar no pipeline de transferência RDMA. Se o prefill pool está idle mas o TTFT ainda é alto, a fila de transferência é o culpado.
- **Aplicar DPD a todos os endpoints sem análise de distribuição de tokens.** Para workloads com 95%+ de prompts curtos (< 512 tokens), DPD adiciona complexidade operacional sem benefício mensurável. O overhead de transferência RDMA para KV caches pequenos pode superar o ganho de isolamento.
- **Não configurar autoscaling independente para os dois pools.** Usar o mesmo HPA policy para prefill e decode é um anti-padrão clássico. Prefill escala com volume de requests longos; decode escala com tokens gerados por segundo. São sinais completamente diferentes.
- **Assumir que DPD elimina a necessidade de rate limiting e backpressure.** DPD melhora a utilização de recursos, mas não substitui controles de admissão. Sem rate limiting no nível do API Gateway ou do router, um burst de requests de contexto longo ainda pode saturar o pool de prefill e causar timeouts em cascata.

## Monolítico vs. DPD: trade-offs operacionais diretos
| Critério | Dimensão | Inferência Monolítica (prefill+decode juntos) | DPD (pools separados via EFA RDMA) |
| --- | --- | --- | --- |
| ITL P99 sob carga mista | Alto e errático — prefill longo bloqueia decode | Consistente — pools isolados, sem contenção | — |
| Complexidade operacional | Baixa — um pool, um tipo de métrica | Maior — dois pools, fila de transferência, threshold do router | — |
| Custo para SLO de P95 ITL < 200ms | Over-provisioning do cluster inteiro | Sizing independente por fase — potencialmente menor custo total | — |
| Requisito de rede | Nenhum inter-node para KV cache | EFA-capable instances obrigatório; p5.48xlarge recomendado | — |
| Composabilidade com KV cache offloading | Suportado independentemente | Composável conforme anúncio — ambos ativos simultaneamente | — |
| Adequação para RAG / pipelines agenticos | Problemático com contextos > 8k tokens e alta concorrência | Ideal — padrão long-prefill/short-decode é o caso de uso principal | — |

## Perguntas que recebo de arquitetos sobre DPD

### DPD funciona com o orquestrador Slurm do HyperPod?

Não. O anúncio é explícito: DPD está disponível apenas para clusters HyperPod usando o orquestrador EKS. O pdSpec é uma extensão do CRD do HyperPod Inference Operator, que é um componente Kubernetes. Se você está em Slurm, precisa migrar para EKS ou aguardar suporte futuro.

### Qual é o impacto no custo de adicionar um pool de prefill dedicado?

Depende da sua distribuição de tráfego atual. Se você está over-provisionando o cluster inteiro para proteger o P99 de requests longos, DPD frequentemente reduz o custo total porque você dimensiona cada pool para seu perfil específico. O pool de prefill pode ser menor (menos nós) porque prefill é compute-bound e GPUs modernas são muito eficientes nisso. O break-even geralmente ocorre quando mais de 15-20% do seu tráfego tem prompts > 4k tokens.

### Como o DPD interage com model parallelism (tensor parallelism / pipeline parallelism)?

Cada pool (prefill e decode) pode ter seu próprio grau de paralelismo de modelo independentemente. Isso é importante para modelos muito grandes: você pode usar tensor parallelism de grau 8 no pool de prefill (para maximizar throughput de compute) e grau 4 no pool de decode (para reduzir latência de geração). O KV cache transferido via RDMA é o resultado do prefill completo, então o paralelismo interno de cada pool é transparente para a transferência.

### DPD está disponível em todas as regiões AWS?

O anúncio especifica que DPD está disponível em todas as regiões AWS onde o SageMaker HyperPod está disponível, com a restrição de usar instance types com suporte a EFA. Verifique a disponibilidade regional de HyperPod e de instâncias p5/p4d na sua região alvo antes de planejar a migração.

### Como garantir isolamento de dados de KV cache entre tenants em um ambiente multi-tenant?

O tráfego de KV cache via EFA RDMA ocorre dentro da rede física do cluster HyperPod e não atravessa a internet pública. Para isolamento de tenants, a abordagem que recomendo é ter endpoints DPD separados por tenant (ou por grupo de tenants com o mesmo nível de sensibilidade), cada um com seus próprios pools de prefill e decode. O overhead operacional é maior, mas em ambientes financeiros regulados (LGPD, BACEN 4893), o isolamento de dados de inferência entre clientes é frequentemente um requisito não negociável.

## DPD pela lente do AWS Well-Architected

- **security**: O tráfego de KV cache via EFA RDMA não sai da rede física do cluster. Aplique security groups restritivos aos nós de prefill e decode, use IAM roles com least privilege para o Inference Operator, e considere AWS KMS para criptografia de dados em repouso em volumes NVMe usados para KV cache offloading.
- **reliability**: Pools independentes criam blast radius isolado: uma falha no pool de prefill não derruba o decode. Configure health checks separados e circuit breakers no router para que requests curtos continuem sendo servidos diretamente ao decoder mesmo se o pool de prefill estiver degradado.
- **performance**: O benefício central do DPD é eliminar a contenção de recursos entre fases compute-bound e bandwidth-bound. Monitore GPU compute utilization no pool de prefill e HBM bandwidth utilization no pool de decode como indicadores primários de saturação de cada fase.
- **cost**: O sizing independente de pools é o mecanismo de otimização de custo. Use Savings Plans ou Reserved Instances para a baseline do decode pool (alta utilização constante) e On-Demand ou Spot para o prefill pool se o seu tráfego de contexto longo for previsível e tolerante a interrupção.

> **Nota do arquiteto: o que eu faria amanhã:** Se eu estivesse operando um endpoint LLM em produção com SLOs de P95 ITL hoje, minha primeira ação seria instrumentar a distribuição de tokens do tráfego atual — não para habilitar DPD imediatamente, mas para quantificar o problema que DPD resolve. Na minha experiência, a maioria das equipes subestima o impacto dos requests de cauda longa no P99 de toda a população. A lição mais difícil que aprendi nessa área é que over-provisioning monolítico é uma dívida técnica que cresce com o modelo: quanto maior o modelo e mais longo o contexto suportado, mais severa a contenção. DPD é a primeira primitiva nativa que permite endereçar isso com sizing independente em vez de hardware extra. Por fim, para ambientes financeiros regulados, a pergunta de isolamento de KV cache entre tenants precisa de resposta antes do rollout — não é um detalhe de implementação, é um requisito de compliance.

## Veredicto: adote DPD se você tem SLOs de latência e tráfego de contexto misto

DPD no SageMaker HyperPod é uma mudança arquitetural genuína, não um ajuste de configuração. Ela resolve um problema estrutural da inferência LLM monolítica — a contenção entre prefill compute-bound e decode memory-bandwidth-bound — com uma solução que é ao mesmo tempo tecnicamente sólida (EFA RDMA para transferência de KV cache) e operacionalmente integrada (extensão do CRD existente, composabilidade com features existentes). Para workloads financeiros com padrão de tráfego misto — especialmente pipelines agenticos com RAG sobre documentos longos — a recomendação é clara: avalie DPD, instrumente sua distribuição de tokens, e habilite em staging antes do próximo ciclo de capacity planning. Para workloads homogêneos com prompts curtos e alta uniformidade, o benefício é marginal e a complexidade operacional adicional não se justifica. O critério de decisão é simples: se mais de 15% do seu tráfego tem prompts > 2k tokens E você tem SLOs de ITL que estão sendo violados por requests de cauda longa, DPD é a ferramenta certa.

## Referências

- [Amazon SageMaker HyperPod now supports disaggregated prefill and decode (AWS What's New, Jul 6 2026)](https://aws.amazon.com/about-aws/whats-new/2026/7/amazon-sagemaker-hyperpod-dpd/)
- [Amazon SageMaker HyperPod Inference release notes (AWS Docs, Jun 11 2026)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-inference-release-notes.html)
- [Introducing Disaggregated Inference on AWS powered by llm-d (AWS ML Blog, Mar 16 2026)](https://aws.amazon.com/blogs/machine-learning/introducing-disaggregated-inference-on-aws-powered-by-llm-d/)
- [Disaggregated Prefill and Decode for HyperPod inference — Amazon SageMaker AI Developer Guide](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-inference-release-notes.html)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)
- [Elastic Fabric Adapter (EFA) documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)