Decodificação especulativa no vLLM: um guia prático de configuração e decisão

Você adiciona --speculative-model à configuração do seu vLLM, roda um benchmark e vê aproximadamente 2× de throughput em tokens. Três semanas depois, sua latência P99 subiu, algumas requisições estão batendo OOM e seu engenheiro de plantão está olhando para métricas que não fazem sentido. O modelo está tecnicamente “mais rápido”, mas os usuários reclamam que a API parece mais lenta.

A decodificação especulativa é uma otimização condicional — entrega ganhos reais nas cargas de trabalho certas e silenciosamente degrada todo o resto. A maioria dos times descobre em qual categoria está da pior maneira possível. Este artigo é um framework operacional para tomar essa decisão com dados, não com intuição.

Como a decodificação especulativa funciona

O conceito é elegante: um modelo menor (draft) gera tokens candidatos rapidamente, e o modelo alvo verifica todos de uma vez em uma única passagem. Em vez de rodar o modelo grande k vezes para gerar k tokens, você roda o modelo pequeno k vezes e o modelo grande apenas uma vez. A economia vem do fato de que uma passagem de verificação é muito mais rápida que k passagens de geração.

Mas isso só funciona quando tokens suficientes do draft são aceitos. A taxa de aceitação é a variável-chave.

Escolhendo o modelo draft certo

O ponto ideal é uma proporção de tamanho entre 1:8 e 1:12, usando modelos da mesma família e mesma distribuição de treinamento:

• 1B draft contra 70B alvo (~1:70): muito pequeno — gera tokens rápido, mas erra demais, e a maioria é rejeitada
• 8B draft contra 70B alvo (~1:9): no ponto ideal — bom equilíbrio entre qualidade de previsão e custo computacional
• 13B draft contra 70B alvo (~1:5): prevê bem, mas custa 13B parâmetros de VRAM

O custo em memória

Rodar decodificação especulativa significa rodar dois modelos simultaneamente. No pior caso com Llama-3.1-70B:

• BF16: ~140GB — não cabe em uma H100 de 80GB
• INT8: ~70GB — cabe em uma H100 com ~10GB livres
• INT4 (AWQ/GPTQ): ~35GB — mais eficiente em memória, mas com alguma perda de qualidade

Adicionar um modelo draft de 8B consome ~16GB de VRAM que saem diretamente do orçamento do KV cache. Isso reduz o comprimento máximo de contexto e o tamanho do batch.

O efeito da temperatura

A temperatura afeta dramaticamente a taxa de aceitação. Em temperatura=0 (greedy), o modelo alvo é altamente previsível e o draft acerta a maioria dos tokens. Em temperatura=0.7+, o alvo escolhe tokens mais surpreendentes, e as suposições do draft erram com mais frequência.

A regra prática: monitore spec_decode_draft_acceptance_rate em produção. Abaixo de ~0.5, você está adicionando latência, não removendo — desligue.

Framework de decisão

1. Meça primeiro: rode o mesmo prompt em diferentes temperaturas e observe a taxa de aceitação
2. Em alta QPS, a decodificação especulativa pode piorar: benchmarks do time vLLM mostram 1.4–1.8× de slowdown com GPU saturada
3. Quantização do modelo alvo reduz a taxa de aceitação: INT8 penaliza menos que INT4, mas ambos introduzem desvios na distribuição de probabilidade
4. Não confie em benchmarks de terceiros: as condições do seu ambiente — hardware, distribuição de prompts, temperatura, QPS — são únicas

A decodificação especulativa é uma ferramenta poderosa, mas não é gratuita. Meça nas suas condições reais antes de ativar em produção.