Resumo: A decodificação especulativa permite que o vLLM verifique vários tokens drafts em uma única passagem do modelo alvo. Em nossos experimentos, seu efeito no throughput de tokens de saída variou conforme os métodos de draft e as comprimentos de proposta, e também dependeu da família de modelos, ponto de controle de draft, carga de trabalho e comportamento de aceitação.

Introdução: Os grandes modelos de linguagem suportam uma ampla gama de aplicações, mas servi-los em escala requer cuidadosa otimização. A decodificação autocrônica padrão é a base usada por maioria dos sistemas de serviço LLM: o modelo gera um token, o anexa à sequência e então usa a sequência atualizada para gerar o próximo token. Este processo é simples e confiável, mas o loop de serviço ainda avança um token comprometido de cada vez, pois os tokens de saída devem ser produzidos em ordem estritamente de esquerda para direita. A decodificação especulativa [1] baseia-se nesta base através de um mecanismo draft-and-verify. Um componente draft leve propõe tokens candidatos futuros, e o modelo alvo verifica esses candidatos antes de comprometê-los. Quando vários tokens de draft são aceitos, o sistema pode comprometer vários tokens de saída de uma única etapa de verificação do modelo alvo preservando o comportamento de saída do modelo alvo. Este post explora como funciona a decodificação especulativa no vLLM e compartilha medições do nosso ambiente de teste. Primeiro, revisamos a base da decodificação autocrônica e o processo draft-and-verify. Em seguida, examinamos cinco abordagens de draft especulativo: MTP nativo, Gemma 4 MTP, EAGLE-3, DFlash e DSpark. Estes métodos diferem em como o componente draft recebe informações do modelo alvo e se os tokens candidatos são gerados sequencialmente, autoregressivamente, em paralelo ou por uma abordagem híbrida. Finalmente, mostramos como habilitar os métodos testados em nosso ambiente, relatamos medições de nossos experimentos em GPU AMD Instinct↓ MI300X e MI355X usando a plataforma de software aberta ROCm↓, e discutimos considerações práticas de ajuste e observabilidade.

Base da decodificação autocrônica: Na decodificação autocrônica padrão, cada passo de decodificação produz e compromete um novo token. Por exemplo, gerar quatro tokens de saída requer quatro passos de decodificação sequenciais: Etapa 1:context→model→T1 Etapa 2:context + T1→model→T2 Etapa 3:context + T1 T2→model→T3 Etapa 4:context + T1 T2 T3→model→T4 Após cada etapa, o token gerado é anexado à sequência e se torna a entrada do próximo passo. Isso torna o loop de decodificação simples, mas também exige um passo de decodificação do modelo para cada token de saída. Durante gerações longas, este loop token por token pode dominar a latência e limitar o throughput do serviço.

A pergunta-chave por trás da decodificação especulativa é, portanto: podemos preservar o comportamento de saída do modelo original enquanto reduzimos a frequência com que a geração avança apenas um token de cada vez? A decodificação especulativa aborda isso separando a proposta da verificação. Um componente draft propõe primeiro vários tokens candidatos futuros. O modelo original, atuando como modelo alvo, então verifica esses candidatos antes de comprometê-los.

Ideia central da decodificação especulativa: A decodificação especulativa não substitui o modelo original. Em vez disso, mantém o modelo original como modelo alvo, que continua responsável pelo resultado final, e adiciona uma etapa de proposta mais rápida na frente dele. O processo tem duas partes: Draft : propor vários tokens candidatos futuros. Verify : usar o modelo alvo para verificar esses candidatos.

Em cada rodada de decodificação especulativa, como ilustrado na Figura 1, um componente draft leve propõe um ou mais tokens futuros. Estes tokens são apenas candidatos e não são comprometidos imediatamente. O modelo alvo avalia então a sequência de tokens candidatos em uma única passagem de verificação. A verificação procede de esquerda para direita. Cada token de draft é verificado usando o resultado do modelo alvo na posição correspondente. Os tokens aceitos são comprometidos na sequência de saída. Quando um token de draft é rejeitado, os candidatos seguintes...