vLLM ensina nós de decode a devolver o KV-cache e acelera o TTFT em até 3,3 vezes

A equipe do vLLM adicionou a transferência bidirecional de KV-cache à inferência desagregada. Agora, os nós de prefill podem buscar nos nós de decode o cache já calculado dos turnos anteriores do diálogo e deixam de recalcular todo o contexto a cada turno. Em prompts longos de vários turnos, o tempo até o primeiro token (TTFT) cai em até 3,3 vezes.

Onde o tempo se perdia

No esquema de disaggregated serving, as fases de prefill e decode rodam em pools de GPU diferentes. O prefill processa o prompt e constrói o KV-cache, depois o entrega a um nó de decode, que gera a resposta token por token. A separação faz sentido: o prefill é limitado por computação, o decode, por memória e largura de banda, e cada pool pode ser ajustado para a sua carga.

A transferência do cache, porém, era unidirecional, do prefill para o decode. Por isso, do segundo turno em diante havia trabalho redundante. O cliente envia todo o histórico do diálogo mais a nova mensagem. O cache desse histórico já está no nó de decode, mas o nó de prefill não sabe disso e recalcula tudo.

Em um chat comum, isso é tolerável. Para agentes, não. O ciclo de um agente tem dezenas de passos: chamada de ferramenta, resposta, raciocínio, nova chamada. O contexto cresce até dezenas de milhares de tokens, enquanto a parte nova a cada passo é pequena. Paga-se o custo integral do prefill por algo que já havia sido calculado um minuto antes.

Como funciona o canal reverso

A ideia é simples. Depois de gerar a resposta, o nó de decode mantém o KV-cache tanto do prompt quanto dos tokens gerados. Quando chega o turno seguinte, o nó de prefill pode pedir a ele o prefixo coincidente, recebê-lo e calcular apenas a parte nova no final. Dali em diante, tudo segue como antes: o cache completo vai para o decode.

Em vez de recalcular todo o histórico, ocorre uma transferência pela rede de tensores já prontos. O ganho aparece onde a transferência pelo interconnect custa menos que o novo cálculo. Quanto mais longo o prefixo comum, maior essa diferença.

Principais números do anúncio:

• aceleração do TTFT: até 3,3x;
• cenário: prompts longos de vários turnos;
• o que se economiza: o compute de prefill repetido sobre o histórico já processado;
• direção da transferência: decode → prefill, além de prefill → decode;
• plataforma: vLLM em configuração com nós de prefill e decode separados.

O valor de 3,3x foi indicado como limite superior. É o melhor caso em diálogos longos, e não um resultado médio garantido. Em uma conversa curta, com prefixo pequeno, a diferença será bem mais modesta.

O que ficou de fora

A versão resumida do anúncio não traz detalhes dos quais depende o efeito real: qual transporte e qual conector são usados, em que hardware e modelo foram feitas as medições, como muda a carga na rede e como o esquema afeta a vazão como um todo. É provável que isso esteja detalhado no texto completo do blog, e vale lê-lo antes da adoção.

Há também uma questão de arquitetura. Para devolver o cache, o nó de decode precisa mantê-lo, e a HBM da GPU é limitada. Quanto mais longas as sessões, maior a pressão sobre a memória e mais importante a política de evicção. Se o cache já foi removido, não há ganho, e o prefill volta ao recálculo completo.

Quem se beneficia na prática

Em primeiro lugar, as equipes que já executam o vLLM em configuração desagregada e atendem agentes, assistentes de programação ou outras sessões longas. Para elas, o TTFT nos passos finais do ciclo determina a velocidade percebida do produto.

Antes da adoção, vale verificar no seu próprio tráfego:

• qual é a fração de prefixo repetido entre os turnos e como ela cresce ao longo da sessão;
• se a largura de banda do interconnect entre os nós de prefill e decode é suficiente;
• por quanto tempo os nós de decode mantêm o cache e com que frequência ele é removido antes do turno seguinte;
• como o p95/p99 do TTFT muda, e não apenas o melhor resultado.

Se os prefixos forem longos e as sessões couberem na janela de retenção do cache, o efeito pode ficar próximo do declarado. Se os diálogos forem curtos ou fragmentados, o ganho será menor, e a complexidade adicional do esquema pode não compensar.