Porque é que o processamento dos prompts pode ser mais rápido do que a geração local de tokens?

O processamento do prompt pode ser mais rápido do que a geração de tokens, porque um acelerador avalia muitos tokens de entrada em paralelo, mas tem de descodificar os tokens de saída sequencialmente.

Um painel de IA doméstica pode indicar centenas ou milhares de tokens de prompt por segundo, enquanto a saída transmitida chega a uma velocidade muito inferior. Estes números descrevem fases de execução diferentes, e não medições contraditórias. O prefill processa o contexto fornecido como um bloco e cria o estado de atenção, enquanto o decode executa repetidamente o modelo para aceitar um novo token de cada vez. A diferença depende do comprimento do prompt, do tamanho do modelo, da largura de banda da memória, do agrupamento de pedidos, da disposição da cache e de outros pedidos em segundo plano partilharem ou não o mesmo acelerador.

O Prefill e o Decode Resolvem Problemas Computacionais Diferentes

O processamento do prompt, frequentemente designado por prefill, avalia a sequência de entrada e cria o estado KV necessário para a geração posterior. O decode só começa depois de esse estado inicial existir e prolonga a sequência token a token.

A investigação sobre disponibilização de LLM descreve o prefill limitado pelo processamento e o decode limitado pela largura de banda da memória como fases distintas, com comportamentos diferentes do hardware.

Assim, o mesmo modelo pode apresentar um valor elevado de débito de prefill e um valor muito inferior de tokens de saída sem qualquer avaria. Cada métrica contabiliza tokens que percorrem um percurso de execução diferente.

Os Tokens do Prompt Podem Ser Avaliados em Matrizes com Grande Paralelismo

Durante o prefill, estão disponíveis várias posições de consulta em simultâneo. As multiplicações de matrizes podem combinar o trabalho entre a sequência, o lote, as cabeças e as dimensões ocultas, dando ao acelerador operações paralelas suficientes para se manter ocupado.

O FlashAttention reduz a sobrecarga da atenção através de um cálculo de atenção em blocos que evita materializar repetidamente a matriz de atenção completa na memória lenta do dispositivo.

Prompts mais longos aumentam o trabalho total de prefill, mas também podem melhorar a utilização aritmética até que a capacidade da memória, os limites do kernel ou a complexidade da atenção se tornem dominantes.

Trata-se do débito ao longo do bloco de entrada, e não de uma indicação de que o servidor conseguiria emitir o mesmo número de tokens de saída independentes por segundo.

O Decode Não Pode Finalizar o Token Seguinte Antes do Atual

A geração autorregressiva seleciona ou amostra um token, acrescenta-o à sequência e executa depois outro passo do modelo condicionado pelo resultado aceite. O token seguinte aceite não é conhecido antecipadamente.

O DistServe separa as duas fases porque as iterações de decode acedem repetidamente aos pesos do modelo e ao estado KV ativo, produzindo apenas uma pequena quantidade de nova saída por sequência.

O agrupamento de vários utilizadores pode paralelizar várias sequências de decode, mas uma conversa continua a avançar através de uma cadeia de decisões de tokens dependentes.

O decode especulativo pode verificar vários candidatos gerados em conjunto, mas o decode normal continua a ser serial quando não há candidatos aceites antecipadamente.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Um Elevado Débito de Prompts Pode Ainda Resultar Num Longo Atraso Até ao Primeiro Token

Os tokens por segundo dividem o trabalho de prompt concluído pelo tamanho do prompt. Um contexto muito longo pode apresentar um débito impressionante e, ainda assim, demorar vários segundos até aparecer o primeiro token gerado.

A ZimaSpace separa o carregamento, a avaliação do prompt e a geração na sua explicação sobre as fases da latência de IA. Um modelo já carregado elimina o atraso de recarregamento, mas não elimina o custo de avaliar um prompt grande.

O tempo até ao primeiro token é, por isso, a melhor medida interativa do prefill. Os tokens de prompt por segundo são úteis para comparar a eficiência com que o ambiente de execução processa diferentes comprimentos de entrada.

Prefills Longos Podem Tornar Mais Lentos os Utilizadores que Já Estão em Decode

Um prompt documental exigente em termos de processamento pode entrar no mesmo acelerador enquanto outro utilizador recebe tokens transmitidos. Se o ambiente de execução combinar ambas as cargas sem controlo, o prefill de grandes dimensões pode prolongar as iterações de decode.

O DistServe regista uma forte interferência entre prefill e decode quando as duas fases são colocadas e agendadas em conjunto.

O servidor pode continuar a apresentar uma utilização agregada elevada, mas a conversa ativa sofre intervalos maiores entre tokens. O débito e a fluidez visível para o utilizador podem evoluir em sentidos opostos.

Trabalhadores separados, agendamento sensível à fase ou oportunidades de decode reservadas podem proteger a saída interativa quando o hardware e o ambiente de execução os suportam.

O Fracionamento Troca Alguma Eficiência do Prefill por uma Melhor Capacidade de Resposta

Um ambiente de execução pode dividir um prompt longo em blocos mais pequenos e intercalar esses blocos com o trabalho de decode. O prompt requer mais ciclos de agendamento, mas nenhum prefill monopoliza uma única iteração muito longa.

O Sarathi-Serve utiliza prefills divididos em blocos para reduzir a interferência, mantendo oportunidades úteis de agrupamento.

O melhor tamanho de bloco depende dos comprimentos dos prompts, da arquitetura do modelo, da capacidade do acelerador e do objetivo de latência para as conversas ativas.

Meça separadamente o tempo de processamento do prompt, o tempo até ao primeiro token, o tempo entre tokens e os tokens de saída por segundo. A fase com o menor débito anunciado não é automaticamente a fase responsável pela espera mais longa do utilizador.