O que é a desagregação de Prefill-Decode e porque muda o fornecimento de LLM?

A desagregação de prefill e decode separa o processamento do prompt da geração de tokens, para que cada fase de um LLM possa utilizar diferentes workers, agendas e planos de capacidade.

Um prompt RAG longo exige um grande pico de computação antes do primeiro token, enquanto o decode executa posteriormente muitas iterações mais pequenas e sensíveis à largura de banda da memória. Executar ambas as fases numa única GPU é simples, mas permite que prefill longos interrompam conversas ativas. A desagregação move o pedido e o seu estado KV entre pools, trocando coordenação e custos de transferência adicionais por um controlo independente da latência do primeiro token e por token.

Prefill e Decode Têm Perfis de Recursos Diferentes

O prefill processa todos os tokens do prompt em paralelo e constrói a cache KV, produzindo um pico intensivo em computação cuja duração aumenta com o comprimento do prompt. O decode lê repetidamente os pesos do modelo e o estado KV acumulado para gerar um ou alguns tokens novos.

A DistServe identifica a interferência entre prefill e decode quando ambas as fases partilham GPUs, associando o prefill ao tempo até ao primeiro token e o decode ao tempo por token de saída. Separá-las permite ao scheduler proteger cada objetivo de forma independente. Esta distinção continua visível durante os testes domésticos posteriores.

A desagregação não é paralelismo de modelos comum. O mesmo modelo pode existir em ambos os pools, enquanto os pedidos se deslocam entre fases funcionais, em vez de entre camadas de uma única passagem forward. O resultado intermédio tem de permanecer inspecionável antes de a automatização prosseguir.

A Transferência de KV Liga os Dois Pools de Workers

Depois do prefill, o sistema tem de disponibilizar a cache KV do pedido a um worker de decode. Pode transferir tensores através de PCIe ou de uma rede, utilizar memória partilhada ou posicionar os workers de forma a minimizar o custo de movimentação.

A Splitwise estuda o serving específico por fase com máquinas e agendamento específicos por fase, demonstrando por que motivo a alocação de hardware pode corresponder às diferentes características computacionais do trabalho de prompt e de token. O enfileiramento e a movimentação do estado tornam-se parte do percurso de serving. Esse limite deve ser medido separadamente em condições de funcionamento realistas.

O pool de decode não pode iniciar até ter um estado KV consistente e os metadados do pedido. Contextos grandes aumentam os bytes transferidos, pelo que uma divisão de fases teoricamente mais rápida pode perder para a execução colocalizada numa rede doméstica pequena.

O Dimensionamento Independente Altera o Planeamento de Capacidade

Pools separados podem acrescentar capacidade de prefill para picos de documentos longos sem expandir proporcionalmente a capacidade de decode, ou proteger o decode de voz enquanto a sumarização em segundo plano consome workers de prompt. O controlo de admissão pode direcionar-se a duas filas e dois orçamentos de latência. A consequência prática surge quando várias fontes competem por um contexto limitado.

A Mooncake descreve uma coordenação da cache KV que trata a movimentação e o armazenamento da cache KV como preocupações de primeira classe do serving. A arquitetura demonstra que a desagregação desloca o estrangulamento do simples agendamento de GPUs para a transferência do estado e a coordenação da cache.

O limite de falha é uma escala ou largura de banda insuficiente. Uma ou duas GPUs domésticas podem não ter um dispositivo disponível para especialização, e a duplicação dos pesos do modelo, juntamente com a transferência de KV, pode consumir mais memória e latência do que a interferência eliminada.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Compare os Orçamentos de Fase Colocalizados e Desagregados

Meça os tokens de prompt por segundo, o tempo até ao primeiro token, o tempo por token de saída, os bytes de KV transferidos, o tempo de transferência, a espera na fila, a duplicação da memória do modelo, a energia e a recuperação de falhas para prompts curtos, longos e mistos. Esta dependência deve permanecer explícita na interface final.

Utilize o prefill em blocos como alternativa colocalizada. Teste o prefill em blocos antes de adicionar um segundo pool e, em seguida, compare rastreios de chegada idênticos em ambas as arquiteturas. O resultado tem, portanto, de ser verificado em relação às evidências originais.

Adote a desagregação apenas quando a interferência entre fases for medida e o percurso de transferência preservar ambos os objetivos de latência. Num servidor pequeno, o agendamento colocalizado com blocos de prefill limitados pode proporcionar o mesmo resultado para o utilizador, com menos movimentação de estado.