Prefill e descodificação: porque a inferência de LLM tem duas fases
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
O prefill processa um prompt e cria a sua cache de atenção. A descodificação utiliza essa cache para gerar os tokens seguintes. Um prefill longo ou agrupado em lotes pode utilizar grandes operações matriciais de forma eficiente; a descodificação com lotes pequenos passa frequentemente mais tempo a ler os pesos e as chaves e os valores em cache.
Esta distinção ajuda os engenheiros a diagnosticar separadamente a lentidão do primeiro token e a da geração que se segue.
Identifique a fase lenta
O prefill autorregressivo convencional produz os logits usados para amostrar o primeiro token de saída. Os passos de descodificação seguintes acrescentam um token de cada vez. O tempo até ao primeiro token inclui também a espera em fila, a tokenização, o escalonamento e a entrega pela rede, pelo que um TTFT elevado não prova que o próprio prefill seja lento.
| Sintoma | O que medir antes de alterar o servidor |
|---|---|
| O primeiro token demora mais com prompts mais longos | Tempo em fila e duração do prefill por comprimento da entrada |
| Os tokens seguintes ficam mais lentos com históricos mais longos | Tempo de descodificação e tráfego da KV cache |
| Um novo prompt longo interrompe outros fluxos | Iterações do escalonador e intervalos entre tokens |
| Os servidores separados gastam tempo a transferir o estado | Bytes KV transferidos, largura de banda e espera em fila |
O prefill reutiliza os pesos entre os tokens do prompt. A implementação pode ainda carregar os blocos das matrizes mais de uma vez; não garante uma única leitura literal de cada peso a partir da HBM. Splitwise descreve como estas fases utilizam recursos de hardware diferentes.
O que muda com o prefill por blocos
O prefill por blocos processa um prompt longo ao longo de várias iterações do escalonador. O escalonador documentado do vLLM admite primeiro os pedidos de descodificação em curso e utiliza o orçamento de tokens restante da iteração para o prefill. O tamanho real do bloco depende do orçamento disponível.
Isto pode reduzir as interrupções dos fluxos existentes e, ao mesmo tempo, aumentar o TTFT do novo pedido. Blocos mais pequenos também acrescentam trabalho de escalonamento e voltam a ler o estado anterior da cache. Sarathi-Serve avalia este compromisso; o aumento aproximado de 25% no tempo de prefill com blocos de 512 tokens foi medido para Yi-34B com paralelismo tensorial de grau dois.
O serving desagregado coloca, em alternativa, o prefill e a descodificação em grupos de GPU separados. Permite ajustar cada fase de forma independente, mas tem de transferir a KV cache do pedido. Verifique o custo da transferência e a utilização dos grupos antes de adotar esse desenho. A divisão em blocos altera o escalonador; a desagregação também altera a implementação em produção e a comunicação.
Guia de engenharia: prefill e descodificação inclui cronogramas das duas abordagens.