Decodificação especulativa: como acelerar LLMs na prática

Para quem desenvolve aplicações, a pergunta é se a resposta chega mais rápido em streaming com a carga de trabalho real. Para quem opera a infraestrutura de inferência, é se esse ganho se mantém com requisições simultâneas e pressão sobre a memória. Já para quem contrata uma API hospedada, é preciso saber se o provedor oferece controles para essa otimização ou ao menos a documenta.

Documentação verificada em 30 de outubro de 2026: vLLM, SGLang e NVIDIA TensorRT-LLM. Os comandos abaixo seguem a documentação disponível nessa data; são exemplos de configuração, não resultados de benchmarks realizados para este artigo.

O que é decodificação especulativa?

Um mecanismo de baixo custo propõe os próximos tokens; o modelo-alvo decide quais podem entrar na resposta. Um token é uma unidade de texto processada pelo modelo, muitas vezes um trecho de uma palavra. O modelo-alvo é aquele cujo comportamento você quer preservar.

Imagine um assistente que escreve uma frase para um editor criterioso. O assistente pode adiantar o trabalho, mas nada chega ao leitor antes da revisão. O ganho está em permitir que o modelo-alvo avalie a continuação proposta de uma vez, sem precisar de uma etapa separada de geração para cada novo token. A NVIDIA descreve esse processo como um mecanismo de elaboração de rascunho seguido de uma passagem de verificação pelo modelo-alvo. Documentação do TensorRT-LLM

Na figura, as letras representam IDs de tokens. O modelo de rascunho propõe A B C. Na decodificação gulosa, que escolhe o próximo token de maior probabilidade, suponha que o modelo-alvo concorde com A B, mas escolha X em seguida. A resposta confirmada passa a ser A B X. Qualquer continuação proposta depois do C rejeitado também seria descartada, pois dependia do prefixo errado.

Quando a saída é gerada por amostragem, aceitar um token exige mais do que conferir se os dois modelos escolheram a mesma palavra. A amostragem especulativa padrão usa as probabilidades do modelo-alvo e da proposta, com uma distribuição de correção quando uma proposta é rejeitada. É essa correção que preserva a distribuição de probabilidade do modelo-alvo. O algoritmo original também permite um token adicional do modelo-alvo quando todo o rascunho é aceito. Artigo original de Leviathan, Kalman e Matias

O modelo menor, portanto, fornece propostas; ele não assume a resposta como alternativa ao modelo-alvo. Com um verificador exato, um modelo de rascunho ruim deve prejudicar a velocidade, sem passar a responder por conta própria de forma silenciosa.

O que significa acelerar sem usar um modelo pior?

A garantia a exigir é a preservação da distribuição do modelo-alvo. Isso não significa receber a mesma resposta aleatória em todas as execuções, eliminar os erros do modelo-alvo ou melhorar seu raciocínio. O vLLM documenta efeitos numéricos e de processamento em lote que podem gerar diferenças mesmo quando o algoritmo é sem perdas. Garantias de ausência de perdas do vLLM

Mantenha fixos os pesos, a quantização e os parâmetros de amostragem do modelo-alvo ao avaliar a técnica. Caso contrário, você estará alterando várias coisas ao mesmo tempo e não conseguirá identificar qual delas causou uma diferença de qualidade.

Principais variantes e onde consultar a documentação de cada engine

Escolha um mecanismo de proposta compatível com o modelo-alvo e com a versão da engine de inferência que você usa. A lógica continua sendo propor e verificar; o que muda é a origem do rascunho.

Um modelo de rascunho separado

Um modelo de linguagem menor gera tokens candidatos usando seus próprios pesos. É a configuração mais intuitiva, mas exige carregar e operar outro modelo. Compatibilidade e concordância importam: ser menor não torna um modelo automaticamente útil. O vLLM normalmente pressupõe um vocabulário compartilhado, embora também documente uma opção restrita para vocabulários diferentes. Modelos de rascunho no vLLM

Se o serviço já está perto do limite de memória, adicionar outro modelo pode ser um mau ponto de partida. Em um serviço sensível à latência, com capacidade disponível e um modelo de rascunho bem ajustado ao alvo, é um experimento controlado razoável.

Decodificação especulativa com EAGLE

EAGLE, sigla de Extrapolation Algorithm for Greater Language-model Efficiency, usa um componente auxiliar de rascunho treinado e associado ao modelo-alvo. Esse componente aproveita representações internas do modelo-alvo para propor a continuação. Esses componentes treinados, muitas vezes chamados de heads, exigem um checkpoint compatível. O vLLM distingue as configurações eagle e eagle3. Documentação de EAGLE no vLLM

Trate o modelo-alvo e seu checkpoint EAGLE como um par que precisa ser compatível. Não escolha um checkpoint só porque o nome menciona a mesma família de modelos. A família correta, a revisão do modelo e a implementação da engine precisam constar no registro do deploy.

Decodificação especulativa com MTP

A predição de múltiplos tokens, ou MTP, usa a capacidade nativa de um modelo para propor tokens futuros. O vLLM documenta essa opção para famílias de modelos compatíveis e oferece um exemplo de inicialização que dispensa o identificador de um modelo de rascunho separado. Um modelo sem essa capacidade não passa a tê-la só porque você define method como mtp. Documentação de MTP no vLLM

Se você já usa um checkpoint com suporte a MTP, teste a configuração documentada para ele antes de adicionar um modelo de rascunho independente e sem relação com o alvo. Isso reduz as decisões de compatibilidade, embora o desempenho ainda precise ser medido.

A tabela a seguir leva diretamente à documentação das engines. Ela indica onde começar a configuração; não significa que qualquer modelo funcione em todas as combinações.

O nome do algoritmo e a forma de executá-lo são coisas diferentes. As notas da versão atual do TensorRT-LLM removem o modo de execução com uma engine de rascunho separada e mantêm implementações que colocam o componente de rascunho dentro do modelo, como um submódulo. Isso não significa que a abordagem de rascunho e modelo-alvo deixou de existir. Significa que instruções antigas de deploy podem descrever um modo de execução que a versão instalada já não oferece. Notas de versão do TensorRT-LLM

Quando a técnica acelera a resposta — e quando não ajuda

A especulação só compensa quando a saída útil chega mais rápido, considerando todo o trabalho extra. A taxa de aceitação importa, mas é apenas uma parte dessa conta.

A aceitação precisa compensar o custo do rascunho

A taxa de aceitação é o número de tokens aceitos do rascunho dividido pelo número de tokens propostos. Sozinha, ela não diz quanto custou produzir essas propostas. Um modelo de rascunho mais lento pode concordar com o alvo com mais frequência e ainda assim deixar o serviço mais lento.

Uma regra útil para decidir é:

(tempo de rascunho + tempo de verificação + tempo de coordenação) ÷ tokens de saída confirmados < tempo de decodificação por token na configuração de referência

Essa é uma forma de contabilizar o trabalho, não uma previsão de benchmark. Meça a rodada completa no seu hardware. Os “tokens de saída confirmados” incluem um token de correção ou um token extra fornecido pelo modelo-alvo, além das propostas aceitas do rascunho.

Em um assistente de edição de código, a repetição de estruturas locais pode tornar as propostas úteis. Em um assistente de suporte, o rascunho pode acertar as expressões de cortesia e as conexões entre frases, mas ter dificuldade com respostas específicas sobre o produto. Meça essas cargas separadamente antes de usar uma taxa média de aceitação para decidir o deploy.

Rascunhos mais longos também geram mais trabalho que pode acabar descartado. Aumente a profundidade do rascunho apenas enquanto a saída adicional confirmada compensar os custos extras de elaboração, verificação e memória. A Fireworks faz a mesma distinção operacional em suas orientações de ajuste: a aceitação, por si só, não demonstra ganho de velocidade. Orientações de benchmark da Fireworks

O tamanho do lote muda o potencial de ganho

Comece com cargas interativas limitadas pela decodificação e depois teste no pico de requisições simultâneas. O vLLM indica a especulação especificamente para cargas limitadas pela largura de banda da memória, com taxas de requisições médias a baixas. Nessa situação, movimentar os dados do modelo limita o avanço mais do que a capacidade disponível de cálculo. Orientações do vLLM sobre cargas de trabalho

A verificação em paralelo pode aproveitar capacidade de processamento que ficaria ociosa. Porém, um servidor ocupado talvez já use essa capacidade para outras requisições. Na prática, reduzir a latência de uma conversa isolada não comprova um aumento da vazão total de um endpoint com muito tráfego.

O continuous batching muda quais requisições compartilham cada etapa de geração. Avalie a especulação com esse escalonador, incluindo o padrão real de chegada das requisições. Um endpoint de desenvolvimento com pouco tráfego e um endpoint de produção com fila representam experimentos diferentes.

Não adote um limite universal de tamanho de lote. O ponto em que a técnica deixa de compensar depende do modelo, do hardware, do método de rascunho e do escalonador. Acompanhe tanto a latência quanto a capacidade: a velocidade com que uma resposta chega em streaming e o volume de tráfego que o serviço sustenta dentro da meta de latência.

A memória pode anular o ganho

O componente de rascunho disputa um espaço finito na memória da GPU. Pesos separados, estado do rascunho e áreas de trabalho para verificação podem ocupar memória que, de outra forma, atenderia a requisições. O KV cache, que armazena o estado de atenção dos tokens existentes, também entra nessa conta.

Pense em um assistente de documentos que responde rápido a prompts curtos, mas opera perto do limite com documentos longos. Um teste bem-sucedido de especulação com prompts curtos não mostra se o rascunho ainda caberá na memória junto com o cache de produção. Teste o maior contexto que você pretende oferecer, com um volume realista de requisições simultâneas.

As orientações do SGLang para erros de falta de memória incluem explicitamente reduzir a reserva de memória, os tamanhos de captura de grafos, o tamanho da árvore de rascunho e o número de requisições simultâneas. Se for preciso reduzir a concorrência para a especulação caber na memória, há uma contrapartida a medir, não uma otimização sem custo. Solução de problemas de memória no SGLang

Acelere a etapa que faz o usuário esperar

Uma resposta lenta pode significar demora até a saída começar, lentidão no streaming depois que ela começa ou atrasos fora do modelo. A especulação atua na geração. Se a aplicação passa a maior parte do tempo buscando documentos ou esperando uma chamada de ferramenta, acelerar o ciclo de decodificação pode mudar muito pouco a experiência.

Meça separadamente o tempo em fila, o prefill e o decode. O prefill processa o prompt; o decode gera a continuação. O guia de inferência de LLMs explica essas etapas, e o guia de tokens por segundo diferencia a velocidade de saída da vazão total de requisições.

Como ativar a decodificação especulativa

Ative a especulação no processo que serve o modelo e compare com o mesmo modelo-alvo sem a técnica. Os exemplos pressupõem que a engine já esteja instalada, que o hardware comporte os modelos escolhidos e que você tenha acesso aos pesos. Use a documentação correspondente à versão do deploy; uma página latest não garante compatibilidade com um contêiner antigo.

Como configurar no vLLM

O vLLM recebe um objeto JSON por meio de --speculative-config. Este exemplo com modelo de rascunho separado usa o modelo-alvo, o modelo de rascunho e o comprimento de rascunho da documentação de inferência online:

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

O 5 é a quantidade de propostas do exemplo, não uma recomendação de valor ideal. A documentação marca como obsoletas as flags antigas e separadas --speculative-model e --num-speculative-tokens. Exemplos de inicialização do vLLM

Como exemplo de MTP nativo, o checkpoint base Xiaomi MiMo usa a seguinte configuração documentada:

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

Esse exemplo usa outro modelo; ele não fornece um modelo de rascunho que possa ser encaixado no alvo Qwen acima. O limite é o suporte do checkpoint: o MTP precisa existir no modelo e ser compatível com a engine. Exemplo de inicialização com MTP no vLLM

Como configurar no SGLang

O exemplo atual do escalonador com sobreposição de execução do SGLang fornece um par Qwen com modelo-alvo e modelo de rascunho separado:

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

O modo atual com sobreposição exige --speculative-eagle-topk 1. Uma árvore mais larga copiada de outro exemplo é incompatível com esse modo. Use em conjunto as configurações documentadas de escalonamento e de rascunho. Exemplo do escalonador com sobreposição no SGLang

Para cargas que variam, o SGLang também documenta a especulação adaptativa para configurações EAGLE compatíveis. Leia os requisitos desse recurso antes de esperar que a profundidade do rascunho se ajuste sozinha. Especulação adaptativa no SGLang

Como configurar no TensorRT-LLM

O TensorRT-LLM recebe os parâmetros de especulação em uma configuração YAML. Salve o conteúdo abaixo como speculative.yaml:

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

O comprimento do rascunho e o checkpoint vêm do exemplo de configuração especulativa da NVIDIA. Inicie o modelo-alvo correspondente usando a CLI de inferência documentada:

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

Confira tanto a geração do checkpoint quanto o nome da configuração. A NVIDIA documenta Eagle como um alias de compatibilidade para Eagle3, mas checkpoints de gerações anteriores de EAGLE continuam incompatíveis com esse modo. Restrição de checkpoints no TensorRT-LLM

Se você também está escolhendo a engine de inferência, consulte a comparação entre vLLM e SGLang. Um bom modelo de rascunho não compensa a ausência de outro recurso que a sua aplicação exige da engine.

Quem usa uma API hospedada também se beneficia?

Sim, quando o provedor documenta e habilita a técnica; o nível de controle depende do serviço. Você não precisa ter suas próprias GPUs para aproveitar uma otimização de inferência do provedor.

A Fireworks AI, provedora de inferência hospedada, documenta modelos de rascunho padrão para a maioria dos modelos compatíveis em deploys dedicados. Um modelo sem rascunho padrão roda sem especulação baseada em modelo, a menos que seja configurado de outra forma. A Fireworks gerencia a configuração de inferência serverless; portanto, as flags de deploys dedicados não demonstram que todo endpoint serverless usa especulação. Documentação de deploy da Fireworks

Para quem usa a API para gerar novamente um arquivo com pequenas edições, a Fireworks também documenta o recurso Predicted Outputs: basta fornecer o texto esperado no campo prediction da requisição. Esse texto conhecido funciona como outra fonte de propostas e pode ser usado junto com a especulação baseada em modelo. O recurso é útil quando você já conhece boa parte da resposta, em vez de fazer uma pergunta aberta. Predicted Outputs da Fireworks

Para qualquer outro endpoint hospedado, consulte a documentação do próprio serviço antes de afirmar que ele oferece esse benefício ou de acrescentar um parâmetro. A compatibilidade da API, por si só, não informa qual modelo de rascunho roda por trás do endpoint — nem se existe algum.

Onde as promessas passam do ponto

A decodificação especulativa melhora a inferência sob certas condições; não é um multiplicador universal de velocidade. Não há promessa numérica de aceleração aqui porque um resultado obtido com outro modelo-alvo, outro modelo de rascunho, outra GPU e outro perfil de tráfego não descreve o seu serviço.

“Mais tokens aceitos deixam a aplicação mais rápida” ignora o custo do rascunho, a fila e tudo o que a aplicação faz além de gerar texto. “Um rascunho maior é melhor” desconsidera o trabalho descartado após uma rejeição. “Sem perdas significa textos idênticos” confunde uma distribuição de amostragem com um resultado aleatório específico.

O erro mais caro é transformar o resultado de um endpoint com pouco tráfego em uma promessa de capacidade de produção. Um assistente de programação pode parecer mais rápido para quem o desenvolve enquanto o endpoint compartilhado atende a menos sessões simultâneas. Defina se o objetivo é melhorar a latência de resposta, a vazão sustentada ou as duas, e deixe essa decisão explícita nos critérios de implantação.

O que colocar em prática na próxima semana

Quem desenvolve deve testar um mecanismo de proposta compatível quando a decodificação for o gargalo. Quem opera deve exigir ganho sob carga de produção. Equipes que usam APIs hospedadas devem começar pelos controles que o provedor de fato documenta.

Se a maior parte da espera acontece antes da geração, resolva esse gargalo primeiro. Se o rascunho não cabe na memória ou não existe checkpoint compatível, mantenha o modelo-alvo funcionando normalmente. A disponibilidade de um recurso não comprova que o seu deploy precisa dele.

Dúvidas de quem desenvolve com LLMs

Assine a newsletter para receber guias práticos sobre desenvolvimento e operação de sistemas de IA.