Como dividir um LLM em dois: o passo a passo de prefill-decode disaggregation

Resumo: A Cloudflare anunciou em 2026 uma nova infraestrutura para rodar modelos de linguagem em escala global. A jogada técnica central é simples de explicar e muito poderosa: separar a fase de “ler o prompt” da fase de “gerar resposta” em servidores diferentes — uma técnica conhecida como prefill-decode disaggregation. Em ganhos publicados, a latência entre tokens (p90) caiu de ~100 ms para 20–30 ms. Veja como isso funciona, quando vale a pena copiar a ideia e como pensar no Brasil.

Os dois tempos de um LLM

Toda inferência de LLM tem duas fases bem distintas:

• Prefill: o modelo lê o prompt inteiro de uma vez e preenche o cache de chave-valor (KV cache). É um trabalho compute-bound — o gargalo é o poder de cálculo da GPU.
• Decode: o modelo gera um token de cada vez, lendo o KV cache. É um trabalho memory-bound — o gargalo é a largura de banda de memória da GPU.

Em arquiteturas tradicionais, a mesma GPU faz tudo. Isso significa duas coisas ruins: (1) durante o decode, o silício de cálculo fica ocioso; (2) durante o prefill, a memória de outras requisições é congestionada.

O que muda com a disaggregação

Em prefill-decode disaggregation, prefill e decode rodam em servidores diferentes, otimizados para cada fase. O fluxo:

1. O usuário envia o prompt para o servidor de prefill.
2. O prefill server processa o prompt e gera o KV cache.
3. O KV cache é transferido para um decode server (geralmente via interconexão rápida).
4. O decode server gera os tokens de saída.

Resultado prático: cada GPU faz aquilo que sabe fazer melhor. A própria Cloudflare publicou ganhos de 3x na latência inter-token; estudos independentes mostram até 2x de throughput em cargas mistas. A Cloudflare também construiu um motor próprio chamado Infire para gerenciar GPUs com mais eficiência e diminuir tempo de partida do modelo.

Como pensar isso na sua arquitetura

1. Quando vale a pena

Para volume alto e prompts longos. Se sua aplicação tem prompts de 200 caracteres e poucos usuários por segundo, ganho marginal. Se é RAG corporativo, agente com contexto grande, ou chatbot multi-tenant — vale estudar.

2. Como medir antes de mexer

Capture três métricas básicas em produção: TTFT (Time To First Token), ITL (Inter-Token Latency) e RPS (Requests Per Second). Se o TTFT é o problema, o gargalo provavelmente é prefill. Se o ITL piora com carga, provavelmente é decode.

3. Como aplicar passo a passo

• Passo A: separar o tráfego por característica (prompts longos vs. curtos) e enviar para pools diferentes. É um “prefill-decode pobre” que já dá ganho.
• Passo B: usar engines que suportam disaggregação nativa (vLLM, NVIDIA Dynamo, SGLang têm flags para isso).
• Passo C: orquestrar transferência de KV cache via RDMA / NVLink — geralmente exige cluster próprio ou serviço como Cloudflare Workers AI / Infire.

Por que importa (e o status no Brasil)

Para times brasileiros, o ganho mais imediato é em latência percebida em aplicações de chat e em custo por token em workloads pesados de RAG. Em 2026, com o crescimento de agentes corporativos (que disparam dezenas de chamadas para cada interação do usuário), uma redução de 3x no ITL transforma a experiência. Ainda assim, montar prefill/decode disaggregation in-house é complexo — para a maioria das empresas, a estratégia certa é escolher um provedor (Cloudflare, NVIDIA Dynamo, vLLM gerenciado) que já entregue isso.

Riscos e limitações

Disaggregação não é bala de prata. Os custos aparecem em três frentes: (1) transferência do KV cache consome banda e adiciona um hop de rede; (2) orquestração fica mais complexa, com mais coisas para monitorar; (3) cargas pequenas podem ficar piores que numa arquitetura agregada simples. Faça benchmarks com seu próprio tráfego antes de adotar.

Cenário

A separação de prefill e decode deve virar padrão em infraestrutura séria de LLM nos próximos 12–18 meses. NVIDIA Dynamo, vLLM, SGLang, BentoML e Cloudflare já oferecem caminhos. Para 2027, espere que provedores de nuvem brasileiros e regionais ofereçam o mesmo, com SLAs em português.

Conclusão prática

Se você opera um produto sério com LLM, comece medindo TTFT e ITL hoje. Em seguida, teste vLLM 0.6+ ou outro engine com suporte a disaggregação em um ambiente de staging. O ganho de latência é real e tende a se traduzir em retenção e em menor custo por token. Para quem é apenas usuário de API, o ganho vem “de graça” conforme provedores adotam a técnica — mas vale checar a documentação para comparar.

Fonte internacional de referência: InfoQ — Cloudflare Builds High-Performance Infrastructure for Running LLMs e Cloudflare Blog.