A inferência de LLMs opera sob duas dinâmicas físicas opostas. O processamento do prompt (prefill) satura os Tensor Cores. A geração autorregressiva token a token (decode) satura a memória HBM.
Quando ambas as fases compartilham a mesma GPU, prompts longos bloqueiam decodes ativos. Essa contenção gera picos severos no Time-to-First-Token (TTFT). Ocorre também forte instabilidade na Inter-Token Latency (ITL).
Duas inovações resolvem esse impasse: o Chunked Prefill no agendador e o desacoplamento físico Prefill-Decode Disaggregation (PD).
A assimetria física entre prefill e decode
A fase de prefill é limitada por computação (compute-bound). A fase de decode é limitada por largura de banda de memória (memory-bandwidth-bound). Essa assimetria dita como a GPU consome tempo em cada etapa.
No prefill, o modelo recebe todos os tokens de entrada juntos. Ele executa multiplicações de matrizes densas (GEMM). A intensidade aritmética supera facilmente 300 FLOPs por byte lido da memória.
No decode, o modelo gera um token por passo. Ele realiza operações matriz-vetor (GEMV). Para cada token, a GPU precisa transferir todos os pesos e o histórico de KV Cache da HBM.
A intensidade aritmética no decode cai para a faixa de 15 a 30 FLOPs por byte. Os Tensor Cores passam de 85% a 95% do tempo ociosos, aguardando dados da memória.
O modelo Roofline formaliza o ponto de equilíbrio de hardware (ridge point). Ele define a intensidade necessária para saturar a computação da GPU:
I_ridge = Capacidade_Computacional (FLOP/s) ÷ Largura_de_Banda_HBM (Bytes/s)
Na arquitetura NVIDIA H100 SXM5 em precisão FP16:
I_ridge = (989.5 × 10^12 FLOP/s) ÷ (3.35 × 10^12 Byte/s) ≈ 295.4 FLOPs/byte
Na arquitetura NVIDIA H200 SXM com memória HBM3e de 4.8 TB/s:
I_ridge = (989.5 × 10^12 FLOP/s) ÷ (4.80 × 10^12 Byte/s) ≈ 206.1 FLOPs/byte
O prefill opera acima desse limiar. O decode opera muito abaixo. Otimizar ambos com a mesma configuração na mesma GPU gera desperdício de silício.
| Métrica de Execução | Fase de Prefill | Fase de Decode |
|---|---|---|
| Regime de Gargalo | Compute-Bound (Tensor Cores) | Memory-Bandwidth-Bound (HBM) |
| Operação Algébrica Principal | Matriz-Matriz Densa (GEMM) | Matriz-Vetor (GEMV) |
| Intensidade Aritmética | > 300 FLOPs/byte | 15 a 30 FLOPs/byte |
| Utilização de Tensor Cores | 80% a 95% (saturação) | 5% a 15% (ociosidade) |
| Métrica Crítica de SLA | Time-to-First-Token (TTFT) | Inter-Token Latency (ITL) |
O problema do Head-of-Line Blocking no Continuous Batching
O agendamento por lotes contínuos (Continuous Batching) sofre de bloqueio de início de fila (Head-of-Line Blocking). A chegada de um prompt extenso suspende todas as requisições ativas de decode no cluster.
Ao receber um prompt de 8.000 tokens, a GPU monopoliza seus núcleos para processar o bloco. A operação dura centenas de milissegundos.
Durante essa janela, usuários conectados sofrem travamentos no fluxo de texto (stream jitter). A latência entre tokens consecutivos (ITL) salta de 25 ms para mais de 500 ms no percentil P99.
Ao mesmo tempo, novas requisições acumulam tempo de fila. Isso degrada o Time-to-First-Token (TTFT) e viola os acordos de nível de serviço (SLOs).
Continuous Batching Tradicional (HoL Blocking):
Iteração N: [Decode req 1] [Decode req 2] [Decode req 3] -> 30 ms
Iteração N+1: [--- PREFILL MONOLÍTICO DE 8K TOKENS (Req 4) ---] -> 450 ms (Decode congelado)
Iteração N+2: [Decode req 1] [Decode req 2] [Decode req 3] [Decode req 4] -> 32 ms
Esse comportamento em dente de serra compromete a estabilidade de agentes e assistentes conversacionais em tempo real.
Chunked Prefill e Piggybacking no agendador de iteração
O Chunked Prefill divide prompts longos em blocos uniformes de tamanho fixo. O agendador intercala essas fatias com os passos de decode a cada iteração.
A técnica foi demonstrada no paper Sarathi-Serve (arXiv:2403.02310). Em vez de processar 4.096 tokens em um bloco único, o sistema cria fatias discretas de 1.024 tokens.
A cada iteração, o agendador combina um chunk de prefill com todos os decodes pendentes. Esse processo recebe o nome técnico de Piggybacking.
O chunk de prefill consome ciclos ociosos dos Tensor Cores enquanto a GPU transfere tensores do decode na HBM. O tempo total por iteração permanece estável entre 35 e 45 ms.
Agendamento com Chunked Prefill (Sarathi-Serve / vLLM):
Iteração N: [Chunk 1 (1024 tok) Req 4] + [Decode 1, 2, 3] -> 40 ms
Iteração N+1: [Chunk 2 (1024 tok) Req 4] + [Decode 1, 2, 3] -> 40 ms
Iteração N+2: [Chunk 3 (1024 tok) Req 4] + [Decode 1, 2, 3] -> 40 ms
Iteração N+3: [Chunk 4 (1024 tok) Req 4] + [Decode 1, 2, 3] -> 40 ms (Prefill concluído)
Iteração N+4: [Decode req 1] [Decode req 2] [Decode req 3] [Decode req 4] -> 32 ms
O número de iterações necessárias para processar o prompt depende do tamanho da fatia:
N_iter = ⌈ L_prompt ÷ C_chunk ⌉
Um prompt de 3.200 tokens com C_chunk = 1.024 é concluído em exatamente 4 iterações. Os fluxos paralelos continuam gerando texto sem pausas perceptíveis.
O vLLM e o SGLang adotam Chunked Prefill nativo em seus agendadores de produção.
Limites do Chunked Prefill e a necessidade de desacoplamento físico
O Chunked Prefill estabiliza o ITL, mas introduz sobrecarga computacional na atenção parcial acumulada. Esse overhead ocorre pela necessidade de consultar estados calculados em blocos anteriores.
No processamento do segundo chunk, a projeção de Query calcula atenção contra o primeiro chunk. No quarto bloco, a atenção abrange todas as três fatias precedentes.
O volume de operações de atenção cresce com o número de blocos encadeados. Para prompts acima de 32.000 tokens, o tempo total de prefill pode subir de 15% a 35% frente ao prefill monolítico.
Além disso, a GPU permanece presa a uma configuração única de paralelismo de tensores (Tensor Parallelism - TP).
O prefill se beneficia de TP = 4 ou TP = 8 para acelerar operações densas. O decode sofre com alto TP pela latência do All-Reduce em matrizes pequenas.
Para eliminar esse conflito de forma definitiva, os motores modernos adotam a separação física de nós (PD Disaggregation).
Arquitetura de Prefill-Decode Disaggregation (PD)
A desagregação Prefill-Decode divide a infraestrutura em dois grupos de servidores independentes conectados por rede rápida. Os nós de prefill cuidam da ingestão de contexto. Os nós de decode cuidam da geração token a token.
Essa arquitetura foi formalizada no DistServe (OSDI 2024) e no Splitwise (ISCA 2024).
Cada grupo recebe hardware e paralelismo otimizados para seu respectivo regime:
- Nós de Prefill (P-Nodes): Focados em FLOPS brutos e precisão FP8/FP4. Utilizam alto paralelismo (
TP = 4ouTP = 8) para liquidar prompts em alta velocidade. - Nós de Decode (D-Nodes): Focados em capacidade e largura de banda de memória HBM. Utilizam baixo paralelismo (
TP = 1ouTP = 2) e paralelismo de pipeline (PP).
Ao concluir o prompt, o P-Node gera o primeiro token. Em seguida, ele transfere o tensor de KV Cache para o D-Node designado.
O D-Node assume a requisição a partir do segundo token. Ele executa a transmissão da resposta até o fim do texto.
Cluster Desacoplado (PD Disaggregation):
Cliente -> [Load Balancer / Global Scheduler]
|
+---> [Pool de P-Nodes (Compute: TP=8, FP8)]
| (Gera 1º token + KV Cache)
| === Transferência RDMA 400G ===> [Pool de D-Nodes (HBM: TP=1)]
| (Gera tokens 2..N)
+---> Stream para Cliente
Transferência de KV Cache via RDMA e Pipelining Assíncrono
A viabilidade da desagregação PD depende de transferir o KV Cache entre servidores sem adicionar latência perceptível. Essa comunicação utiliza redes RDMA de 400 Gbps (InfiniBand NDR ou RoCEv2) com GPUDirect RDMA.
O tamanho do KV Cache para uma requisição de S_tokens é determinado pela estrutura do modelo:
S_KV (bytes) = 2 × L × n_kv × d_k × b_elem × S_tokens
No modelo Llama-3-70B (L = 80, n_kv = 8, d_k = 128, precisão FP16 com b_elem = 2):
S_token = 2 × 80 × 8 × 128 × 2 = 327.680 bytes/token = 320 KB/token
Para um prompt de 4.096 tokens, o volume transferido atinge 1,28 GB:
S_total = 4.096 × 320 KB = 1.310.720 KB = 1.28 GB
Em uma interface InfiniBand NDR 400 Gbps com vazão efetiva de 50 GB/s, o tempo bruto de transferência é:
T_transfer = 1.28 GB ÷ 50 GB/s = 0.0256 s = 25.6 ms
Para anular esse tempo de espera, motores como Mooncake (arXiv:2407.00079) e SGLang utilizam pipelining assíncrono.
Quando uma camada do modelo conclui o cálculo no P-Node, ela despacha seu KV Cache via RDMA. Essa transmissão ocorre em paralelo com a computação da camada seguinte.
Ao terminar a última camada, mais de 90% do KV Cache já reside na memória do D-Node. O atraso residual aparente cai para menos de 3 milissegundos.
Ganhos de Goodput e Benchmarks de Produção
A desagregação PD multiplica a eficiência do cluster sob restrições rígidas de latência. A métrica de referência é o Goodput, que contabiliza apenas requisições entregues dentro dos prazos de TTFT e ITL.
Medições do framework DistServe (OSDI 2024) comprovam ganhos substanciais em escala:
- Goodput Total: Aumento de 2.0x a 4.4x na capacidade de requisições por segundo atendidas dentro dos SLOs.
- Latência P99 de TTFT: Redução de até 10x no tempo de emissão do primeiro token.
- Latência P99 de ITL: Redução de até 5x na oscilação de geração token a token.
- Custo Operacional: Economia de até 45% na despesa de infraestrutura por milhão de tokens gerados.
| Abordagem de Inferência | TTFT P99 (Prompt 4k) | ITL P99 (Jitter) | Goodput Relativo | Complexidade de Rede |
|---|---|---|---|---|
| Continuous Batching Clássico | 2.100 ms | 280 ms | 1.0x (Base) | Baixa (Local) |
| Chunked Prefill Co-alocado | 650 ms | 48 ms | 2.1x | Baixa (Local) |
| PD Disaggregation (RDMA 400G) | 180 ms | 22 ms | 4.2x | Média/Alta (Cluster) |
Como planejar a transição no seu cluster de inferência
A escolha entre Chunked Prefill local e Desagregação PD depende do volume de requisições e da infraestrutura disponível.
Para clusters com até 8 GPUs em nó único, o Chunked Prefill é a solução imediata ideal. Utilize chunk_size = 512 para decodes rápidos ou chunk_size = 1024 para equilibrar vazão total.
Para parques com mais de 16 GPUs sob alta concorrência, a PD Disaggregation é a escolha recomendada. A topologia requer rede RoCEv2 ou InfiniBand, além de agendadores integrados ao vLLM ou SGLang.
A infraestrutura de IA avança para a especialização de hardware por fase de inferência. Essa arquitetura transforma clusters heterogêneos em plataformas previsíveis, eficientes e de alta capacidade.
Perguntas Frequentes sobre Chunked Prefill e PD Disaggregation
O que é o problema de Head-of-Line Blocking na inferência de LLMs?
É o congelamento que ocorre quando um prompt extenso monopoliza os núcleos da GPU, pausando a geração de todas as outras requisições ativas no mesmo lote.
Qual é a diferença fundamental entre Chunked Prefill e PD Disaggregation?
O Chunked Prefill fatia o prompt na mesma GPU via software. A PD Disaggregation separa GPUs em nós dedicados de prefill e nós dedicados de decode interconectados por RDMA.
Como a transferência de KV Cache não adiciona latência na desagregação PD?
Motores modernos utilizam redes RDMA de 400 Gbps com pipelining assíncrono. O cache de cada camada é transmitido enquanto a camada seguinte ainda é calculada no nó de prefill.
Quando vale a pena migrar de Chunked Prefill para um cluster com PD Disaggregation?
A migração é vantajosa para frotas com mais de 16 GPUs que atendem alto volume com contextos longos (acima de 16k tokens) e exigem garantias rígidas de TTFT e ITL.
