Decodificação Especulativa: Inferência de LLMs 20-50% Mais Rápida

Um modelo de 70B gera um token por passagem de frente, e cada passagem recarrega os pesos da VRAM, calcula a atenção através do contexto e sincroniza a memória. Entre os tokens, a GPU fica ociosa enquanto aguarda que as dependências sequenciais sejam resolvidas.

Em uma H100, um modelo de 70B produz um token a cada 30-50ms. A GPU tem capacidade de computação suficiente para processar múltiplos tokens em paralelo, mas a dependência sequencial impede isso — cada token depende do anterior, e o pipeline entra em estagnação.

A decodificação especulativa quebra esse gargalo, permitindo gerar múltiplos tokens no tempo que normalmente levaria para gerar um, sem alterar a distribuição de saída. Os tokens obtidos são estatisticamente idênticos aos que seriam obtidos com a decodificação autoregressiva padrão; a única diferença é a velocidade com que são obtidos.

Este guia cobre os mecanismos, as variantes disponíveis em 2026, os compensatórios da taxa de aceitação e a configuração prática em llama.cpp, vLLM, SGLang e TensorRT-LLM.

Como a Decodificação Autoregressiva Funciona (e Por Que É Lenta)

Antes de entender a decodificação especulativa, é necessário entender a restrição autoregressiva que ela contorna. A geração autoregressiva padrão processa tokens sequencialmente:

1. Executa uma passagem de frente pelo modelo com o contexto atual.
2. Amostra o próximo token da distribuição de saída.
3. Acrescenta o token ao contexto.
4. Repete.

Cada etapa requer uma passagem de frente completa — carregando pesos da VRAM, calculando a atenção através de todo o contexto e produzindo um único token. Para um modelo com 70B de parâmetros, isso leva aproximadamente 30-50ms por token em uma H100. A GPU tem capacidade de computação sobrando — poderia processar mais trabalho em paralelo — mas a dependência sequencial impede.

A Lacuna entre Computação e VRAM

As GPUs modernas têm mais FLOPs do que o necessário para a geração de um único token, portanto, o verdadeiro gargalo é a largura de banda da memória — os pesos devem ser transmitidos da VRAM para as unidades de computação a cada passagem de frente. Ao gerar um token de cada vez, a GPU gasta a maior parte do tempo aguardando transferências de memória em vez de realizar computações úteis.

A decodificação especulativa aborda isso dando mais trabalho à GPU por cada transferência de memória. Em vez de um token por passagem de frente, ela gera K tokens por passagem de frente, amortizando o custo de memória entre múltiplas saídas.

O Mecanismo de Rascunho-Verificação

A decodificação especulativa funciona em ciclos repetitivos de rascunho-verificação. Um mecanismo de rascunho rápido propõe K tokens candidatos — de um modelo de rascunho pequeno, de uma busca n-gram ou de um cabeçalho de previsão acoplado ao modelo de destino — e o modelo de destino verifica todos os K em uma única passagem de frente. A fase de rascunho é barata, tipicamente 5-20% do tempo da passagem de frente do modelo de destino, enquanto a verificação compara cada token rascunhado com o que o modelo de destino teria gerado, aceitando o prefixo correspondente mais longo e reamostrando a partir da primeira rejeição em diante.

Verificar K tokens custa aproximadamente o mesmo que gerar um token autoregressivamente, de modo que, quando o rascunho está correto, obtém-se K tokens pelo preço de uma etapa de verificação.

Um Exemplo Concreto

Suponha que o modelo de rascunho proponha 5 tokens: ["I", " like", " cooking", " and", " traveling"]. O modelo de destino os verifica em uma única passagem de frente:

O destino aceita os tokens 1 e 2, então gera " playing" para o token 3, produzindo três tokens em um único ciclo em vez de três passagens de frente separadas. Se o rascunho tivesse estado correto até o token 5, obteriam-se cinco tokens pelo custo de uma verificação — uma aceleração de 5x apenas nesse ciclo.

O Gargalo da Verificação

Na prática, a verificação domina o tempo de execução — 42-95% do ciclo, dependendo do método e do tamanho do modelo. A passagem de frente do modelo de destino é o gargalo, e os tokens rejeitados representam trabalho de computação desperdiçado.

É por isso que a taxa de aceitação é tão importante. Cada token rejeitado após o primeiro é trabalho de verificação desperdiçado. Os melhores métodos de decodificação especulativa maximizam o número esperado de tokens aceitos por ciclo, não apenas a taxa de aceitação bruta.

A Garantia Matemática

Uma das propriedades mais importantes da decodificação especulativa é que ela produz tokens da mesma distribuição exata da amostragem autoregressiva padrão a partir do modelo de destino. A etapa de verificação usa amostragem por rejeição — quando o rascunho propõe o token x, o modelo de destino calcula sua própria probabilidade p(x) e o rascunho calcula p_draft(x). A probabilidade de aceitação é:

min(1, p(x) / p_draft(x))

Quando o destino concorda (p(x) ≥ p_draft(x)), o token é sempre aceito. Quando o destino discorda, o token é aceito com uma probabilidade proporcional à razão, e os tokens rejeitados são reamostrados de uma distribuição residual:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

Este procedimento garante que a sequência de saída siga exatamente a distribuição do modelo de destino, razão pela qual a decodificação especulativa é sem perdas. O modelo de rascunho influencia a velocidade, não a qualidade — os tokens obtidos são estatisticamente indistinguíveis da decodificação padrão, com a mesma perplexidade e distribuição. A única diferença é a latência.

Estratégias de Modelo de Rascunho

O mecanismo de rascunho é a variável que mais importa. Diferentes abordagens têm diferentes compensatórios entre a complexidade de configuração, a taxa de aceitação e a aceleração.

Modelos de Rascunho Independentes

A abordagem mais simples carrega um modelo menor ao lado do destino — tipicamente um modelo de 1B-3B fazendo rascunho para um destino de 7B-70B.

Prós:

• Conceitualmente direto
• Funciona com qualquer modelo de destino
• O modelo de rascunho pode ser ajustado para corresponder à distribuição do destino

Contras:

• Requer carregar um segundo modelo na VRAM (1-4 GB dependendo do tamanho)
• A qualidade do modelo de rascunho determina diretamente a taxa de aceitação
• Rascunhos entre famílias (ex., Qwen fazendo rascunho para Llama) geralmente têm desempenho ruim

Regra geral: Use modelos da mesma família. Gemma 2 2B faz bom rascunho para Gemma 2 27B. Llama 3.2 1B faz bom rascunho para Llama 3.1 70B. Rascunhos entre famílias tendem a ter baixas taxas de aceitação porque as distribuições de tokens divergem.

Encontrando Modelos de Rascunho Compatíveis

Nem todos os modelos pequenos funcionam como modelos de rascunho para um dado destino. O fator crítico é o alinhamento de distribuição — o quão de perto as probabilidades de saída do modelo de rascunho correspondem às do destino.

A regra de ouro: se a taxa de aceitação do modelo de rascunho cair abaixo de 50%, a decodificação especulativa pode, na verdade, deixá-lo mais lento. O overhead de executar o modelo de rascunho mais a verificação supera o benefício quando a maioria das propostas é rejeitada.

EAGLE e EAGLE-3: Cabeçalhos de Previsão

EAGLE (Estimação de Modelo de Linguagem Guiada por Arquitetura Eficiente) elimina a necessidade de um modelo de rascunho separado. Em vez disso, ele acopla cabeçalhos de previsão autoregressivos leves às camadas internas do modelo de destino.

Como o EAGLE Funciona

O EAGLE treina cabeçalhos de previsão que tomam estados ocultos das camadas intermediárias do modelo de destino e preveem tokens futuros. Durante a inferência:

1. O modelo de destino executa uma passagem de frente através das suas camadas.
2. Em cada camada, o cabeçalho EAGLE lê o estado oculto e propõe tokens para posições futuras.
3. Múltiplos cabeçalhos operam em paralelo, cada um prevendo um passo de tempo futuro diferente.
4. O modelo de destino verifica todas as propostas em uma única passagem.

A vantagem: os cabeçalhos EAGLE são treinados especificamente para corresponder à distribuição do modelo de destino. Eles veem as representações internas do destino diretamente, o que lhes dá um alinhamento muito melhor do que um modelo de rascunho independente.

Melhorias do EAGLE-3

O EAGLE-3 (2025) refina a abordagem com três mudanças-chave:

1. Seleção de camada: Em vez de acoplar cabeçalhos a cada camada, o EAGLE-3 usa otimização bayesiana para selecionar a camada de saída ideal, reduzindo o overhead.
2. Previsão de múltiplos tokens: Cada cabeçalho prevê múltiplos tokens simultaneamente, aumentando a profundidade do rascunho sem custo de computação proporcional.
3. Eficiência de treinamento: O EAGLE-3 treina com os próprios dados de geração do modelo de destino, melhorando as taxas de aceitação em cargas de trabalho dentro da distribuição.

Taxas de aceitação: O EAGLE-3 tipicamente atinge taxas de aceitação de 60-80% em cargas de trabalho dentro da distribuição, em comparação com 40-60% para modelos de rascunho independentes. Em cargas de trabalho de geração de código com alta repetição, a aceitação pode exceder 85%.

Configuração: O EAGLE-3 requer cabeçalhos pré-treinados para o seu modelo de destino. A NVIDIA fornece cabeçalhos EAGLE-3 para vários modelos populares através do TensorRT-LLM e da coleção Speculative Decoding Modules no HuggingFace. Implementações de terceiros existem para vLLM e SGLang.

P-EAGLE: Rascunho Paralelo (Março 2026)

A principal limitação do EAGLE-3 é o rascunho autoregressivo — cada token de rascunho depende do anterior, de modo que gerar K tokens de rascunho requer K passagens de frente sequenciais através do cabeçalho de rascunho, e o overhead do rascunho cresce linearmente com K. O P-EAGLE remove esse teto gerando todos os K tokens de rascunho em uma única passagem de frente através de um rascunhador leve de 4 camadas treinado para prever até 10 tokens em paralelo.

O resultado: O P-EAGLE entrega até 1,69x de aceleração em relação ao EAGLE-3 vanilla em cargas de trabalho reais na NVIDIA B200. A vantagem amplia-se em valores de K mais altos — onde o rascunho sequencial do EAGLE-3 se torna um gargalo, o rascunho paralelo do P-EAGLE não incorre em custo adicional.

Configuração no vLLM: Baixe um cabeçalho P-EAGLE pré-treinado do HuggingFace, defina "parallel_drafting": true na sua configuração do vLLM e use a mesma bandeira --speculative-model — o vLLM cuida do resto. O P-EAGLE é o estado da arte atual para a decodificação especulativa baseada em EAGLE, e, se você estiver implantando EAGLE em 2026, o P-EAGLE é a variante a ser usada.

Decodificação Especulativa N-gram

A decodificação especulativa n-gram substitui um rascunho neural por correspondência de padrões contra o histórico do prompt. O algoritmo procura sequências repetidas de n-grams no contexto, e, quando a sequência de tokens atual corresponde a um padrão previamente visto, propõe os tokens que seguiram aquele padrão anteriormente — por exemplo, se o modelo já gerou def calculate_total(items): e encontra def calculate_total( novamente, ele sabe que os próximos tokens provavelmente serão items): com base na ocorrência anterior.

As variantes de mapa n-gram (ngram-map-k, ngram-map-k4v) usam tabelas de hash para buscas mais rápidas em vez de varredura linear, com a chave de hash como o n-gram atual de tamanho N e o valor como a sequência de tokens que seguiu.

Prós:

• Overhead zero de VRAM — nenhum modelo adicional a carregar (~16 MB para a tabela de hash)
• Extremamente rápida para cargas de trabalho repetitivas (edição de código, refatoração, geração de templates)
• Taxas de aceitação podem atingir 90%+ em cargas de trabalho com alta auto-similaridade

Contras:

• Inútil para geração nova — se o padrão não apareceu antes, o n-gram não tem nada a propor
• A taxa de aceitação cai para perto de zero em cargas de trabalho criativas ou diversificadas
• Profundidade de rascunho limitada (tipicamente 2-4 tokens por correspondência)

Melhor para: Refatoração de código, preenchimento de templates, documentação repetitiva e qualquer carga de trabalho onde o modelo revisite padrões semelhantes. Pior para: escrita criativa, chat aberto e tarefas de raciocínio.

Ajuste de Parâmetros

Os parâmetros n-gram importam mais do que você esperaria. Os padrões funcionam para código, mas cargas de trabalho de texto precisam de ajuste:

Para cargas de trabalho de texto, reduza size-n para 8-10 e aumente min-hits para 2. Isso troca a frequência de correspondência por taxas de aceitação mais altas por correspondência.

Decodificação Auto-Especulativa

A decodificação auto-especulativa (também chamada de LayerSkip ou auto-especulação) usa o próprio cálculo parcial do modelo como rascunho, de modo que nenhum modelo separado é necessário.

Como Funciona

Em vez de executar o modelo completo para cada token, a decodificação auto-especulativa executa uma versão truncada — pulando algumas camadas do transformador — para gerar tokens de rascunho com baixo custo, e o modelo completo então verifica as propostas.

Por exemplo, um modelo de 32 camadas pode executar com apenas 16 camadas para rascunho, e então verificar com todas as 32 camadas. A passagem de frente truncada é mais rápida porque processa menos camadas, e os tokens de rascunho se beneficiam de ver as mesmas camadas iniciais que o destino.

Prós:

• Nenhum peso adicional de modelo a carregar
• Naturalmente alinhado com a distribuição do destino (mesma arquitetura, camadas parciais)
• Funciona bem para modelos com redundância significativa em camadas mais profundas

Contras:

• Requer modificar o motor de inferência para suportar passagens de frente parciais
• Complicações de cache KV — o rascunho usa cache KV parcial que deve ser reconciliado com o cache do modelo completo
• As taxas de aceitação são tipicamente mais baixas do que EAGLE ou modelos de rascunho bem ajustados

Implementação no llama.cpp: A PR #18471 introduziu a decodificação auto-especulativa usando o histórico do contexto como rascunho. O modelo reutiliza tokens do seu próprio histórico de geração para propor continuações, particularmente eficaz para cargas de trabalho de codificação onde padrões se repetem dentro da mesma janela de contexto.

MTP (Previsão de Múltiplos Tokens)

O MTP é uma forma especializada de decodificação especulativa construída diretamente em certos checkpoints de modelo. O Qwen 3.6 distribui variantes GGUF padrão e habilitadas para MTP.

Como difere: Os cabeçalhos MTP são incorporados à arquitetura do modelo durante o treinamento. O modelo carrega cabeçalhos de previsão extras que propõem múltiplos tokens futuros em uma única passagem de frente. Não há modelo de rascunho separado — os cabeçalhos MTP são parte do próprio modelo de destino.

Compensações:

• Nenhum modelo de rascunho para gerenciar — o MTP é ativado com --spec-type draft-mtp --spec-draft-n-max N
• Os cabeçalhos MTP adicionam ~1-2 GB de overhead de VRAM
• Funciona melhor em arquiteturas MoE (Qwen 3.6 35B-A3B) onde o roteamento esparsos mantém os cabeçalhos MTP baratos

Para benchmarks detalhados sobre MTP vs decodificação padrão em Qwen 3.6 27B e 35B, veja Qwen 3.6 MTP vs Standard em GPU de 16GB.

Taxas de Aceitação: O Que Significam na Prática

A taxa de aceitação (α) é a métrica individualmente mais importante para o desempenho da decodificação especulativa. Ela determina se você está obtendo uma aceleração ou pagando um overhead.

A Fórmula de Aceleração

Tokens aceitos esperados por passagem de verificação:

E[aceitos] = α × K

Onde K é o número de tokens de rascunho propostos por ciclo. Se α = 0,7 e K = 5, você aceita 3,5 tokens por passagem — uma aceleração de 3,5x em relação à decodificação padrão (que produz 1 token por passagem).

Taxa de Aceitação por Método

Quando a Taxa de Aceitação Cai

A taxa de aceitação não é constante ao longo de uma geração. Ela varia por:

• Posição do token: Tokens iniciais tendem a ter maior aceitação (mais contexto, menos incerteza). Tokens posteriores caem à medida que o modelo explora continuações mais diversificadas.
• Tipo de carga de trabalho: Edição de código com padrões repetidos vê α > 80%. Escrita criativa aberta vê α < 40%.
• Temperatura: Temperatura mais alta aumenta a divergência entre rascunho e destino, reduzindo a aceitação. A decodificação especulativa funciona melhor em temperatura baixa (0,0-0,7).

Limite crítico: Se a sua taxa de aceitação efetiva (α × K) cair abaixo de 1,0, a decodificação especulativa é mais lenta do que a decodificação padrão. O overhead do rascunho mais o tempo de verificação excede o custo de uma única etapa autoregressiva.

Decodificação Especulativa em Produção: O Que Realmente Acontece

Papers de pesquisa relatam acelerações de 2-4x, mas benchmarks de produção contam uma história mais matizada — as acelerações diminuem com o tamanho do lote, a verificação domina o tempo do ciclo, e nenhum único método vence em todas as cargas de trabalho.

Achados do SpecDecode-Bench (2026)

Uma avaliação sistemática de cinco variantes de SD (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) em vLLM através de quatro modelos e seis cargas de trabalho revelou:

1. SD funciona, mas as acelerações diminuem com o tamanho do lote. No tamanho de lote 1, o EAGLE alcança até 1,96x no Llama-3-70B. No tamanho de lote 128, isso cai para 1,21x. O sistema torna-se limitado por computação em alta concorrência, e a GPU tem menos capacidade ociosa para especulação.

2. A verificação domina o tempo de execução (42-95%). A passagem de frente do modelo de destino é o gargalo. Reduzir a verificação desperdiçada em tokens rejeitados é a via mais promissora para melhoria.

3. Nenhum método único vence em todos os lugares. O EAGLE-3 é a melhor escolha geral. Os métodos de modelo de rascunho excel quando o modelo de destino é grande (70B+). O n-gram é ótimo para edição de código e tarefas de alta sobreposição.

4. A análise de Oracle revela uma lacuna. O limite superior teórico para estratégias combinadas de n-gram + EAGLE atinge ~4,9x em cargas de trabalho de edição de código, mas as implementações atuais alcançam 2-3x. Há espaço para otimização.

Expectativas Práticas de Aceleração

O efeito do tamanho do lote é crítico. Em lotes pequenos, a GPU tem computação ociosa para especulação. Em lotes grandes, o sistema já está saturado, e a decodificação especulativa adiciona overhead sem benefício proporcional.

Monitoramento em Produção

Você deve rastrear a taxa de aceitação em produção. Uma taxa de aceitação em declínio sinaliza que seu modelo de rascunho está divergindo do destino — seja porque a carga de trabalho mudou, ou porque o modelo de rascunho precisa de re-treinamento.

Métricas-chave para monitorar:

• Taxa de aceitação por solicitação (deve ser estável em torno da sua linha de base)
• Tokens por segundo com vs sem decodificação especulativa (a aceleração real)
• Tempo de verificação como percentual do tempo do ciclo (deve ser 42-95%)
• Tempo da passagem de frente do modelo de rascunho (deve ser < 20% do tempo do modelo de destino)

Se a sua taxa de aceitação cair abaixo de 40%, desative a decodificação especulativa para essa solicitação. O overhead não vale a pena.

Configuração Prática

A escolha do motor importa tanto quanto a estratégia de rascunho — veja Ollama vs vLLM vs LM Studio e outros runtimes locais para ver como cada runtime lida com loteamento, compatibilidade de API e throughput antes de escolher um caminho de decodificação especulativa.

llama.cpp

Para configuração geral do servidor e carregamento GGUF, comece com o início rápido do llama.cpp; as bandejas abaixo adicionam decodificação especulativa por cima.

llama.cpp suporta múltiplos métodos de decodificação especulativa através da bandeira --spec-type:

# Modelo de rascunho (independente)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Obrigatório: --parallel 1 para decodificação especulativa

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (ajuste para carga de trabalho de texto)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Auto-especulativa (cargas de trabalho de codificação)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Bandejas críticas:

• --parallel 1 — A decodificação especulativa no llama.cpp requer modo de lote único. Esta é uma limitação atual.
• --spec-draft-n-max — Número de tokens de rascunho por ciclo. Comece com 3-5; valores mais altos aumentam a pressão de VRAM.
• --spec-ngram-simple-size-n — Comprimento do n-gram de busca. O padrão 12 funciona bem para código; reduza para 8 para texto.

Armadilhas comuns:

• Esquecer --parallel 1 — o servidor ignorará silenciosamente a decodificação especulativa.
• Usar modelos de rascunho entre famílias — as taxas de aceitação colapsam, negando qualquer aceleração.
• Definir --spec-draft-n-max alto demais — cada token de rascunho extra custa VRAM para o buffer de rascunho. Os retornos decrescentes começam em torno de 5-8.

vLLM

O início rápido do vLLM cobre a implantação base; as bandejas abaixo habilitam a decodificação especulativa em um servidor vLLM existente.

vLLM suporta decodificação especulativa através das bandeiras --speculative-model e --speculative-num-steps:

# Modelo de rascunho
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (rascunho paralelo)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

A decodificação especulativa do vLLM é integrada ao loteamento contínuo, de modo que funciona sob cargas de trabalho concorrentes. O agendador lida com múltiplos slots de token dentro de uma única passagem de frente, e o gerenciador de memória lida com o cache KV para ambos os modelos de rascunho e destino.

SGLang

SGLang suporta decodificação especulativa através da sua bandeira --speculative-algorithm:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

A arquitetura RadixAttention do SGLang combina-se bem com a decodificação especulativa porque o cache de prefixo reduz o custo de verificação — o modelo de destino reutiliza a atenção em cache para prefixos compartilhados, tornando cada passagem de verificação mais barata do que uma passagem de frente a frio.

TensorRT-LLM

TensorRT-LLM fornece decodificação especulativa de nível de produção com o Triton Inference Server. A configuração é mais envolvida, mas oferece o melhor desempenho em hardware NVIDIA:

1. Construa o motor TensorRT para ambos os modelos de destino e rascunho.
2. Configure o repositório de modelos com model.yaml especificando a configuração de decodificação especulativa.
3. Inicie o Triton com a API LLM / backend PyTorch.

TensorRT-LLM suporta variantes de modelo de rascunho e EAGLE-3. Para cargas de trabalho de geração de código, o TensorRT-LLM com decodificação especulativa n-gram demonstrou redução de latência de 2-3x em implantações de produção.

Quando Usar Decodificação Especulativa

Use Quando

• Modelos de destino grandes (7B+): O overhead do mecanismo de rascunho é amortizado sobre a computação do destino. A decodificação especulativa brilha quando o modelo de destino é lento — quanto maior o destino, mais valiosa a aceleração.
• Cargas de trabalho de temperatura baixa: A decodificação especulativa funciona melhor em temperatura 0,0-0,7, onde a distribuição do modelo de destino é concentrada e o rascunho tem uma melhor chance de corresponder.
• Aplicações interativas: Cargas de trabalho sensíveis à latência (chat, completamento de código, chamadas de ferramentas de agente) se beneficiam mais. O processamento em lote onde você já está saturando a GPU vê menos benefício.
• Geração e edição de código: Alta repetição em padrões de código torna a decodificação n-gram e auto-especulativa particularmente eficaz.

Pule Quando

• Modelos de destino pequenos (< 3B): O overhead do modelo de rascunho se aproxima do tempo da passagem de frente do destino. A aceleração é marginal ou negativa.
• Amostragem de temperatura alta: Em temperatura > 0,7, a distribuição do modelo de destino é muito ampla para o rascunho corresponder com confiabilidade.
• Escrita criativa e geração aberta: Baixas taxas de aceitação em conteúdo novo tornam o overhead não vantajoso.
• Tamanhos de lote altos (> 32): O sistema torna-se limitado por computação, e a decodificação especulativa adiciona overhead sem benefício proporcional. O SpecDecode-Bench mostra a aceleração caindo de 1,96x para 1,21x à medida que o tamanho do lote vai de 1 a 128.

Combinando Métodos

Configurações avançadas combinam múltiplas estratégias de decodificação especulativa. A análise de oracle do SpecDecode-Bench mostrou que combinar adaptativamente n-gram e EAGLE pode empurrar a aceleração para 4,9x em cargas de trabalho de edição de código.

A ideia é usar n-gram para padrões que já apareceram antes, onde a aceitação é alta e o overhead é perto de zero, e recorrer a EAGLE para tokens novos. Na prática, isso requer suporte do motor para especulação de múltiplos métodos — vLLM e TensorRT-LLM têm suporte experimental, mas as implementações de nível de produção ainda estão amadurecendo.

Por enquanto, a combinação mais prática é MTP + n-gram no llama.cpp. O MTP lida com a especulação neural, enquanto o n-gram pega padrões repetitivos que o MTP perde. No Qwen 3 27B, esta combinação atinge 120 tokens/segundo em comparação com 67 tokens/segundo padrão — uma aceleração de 1,8x.

Considerações de Custo

A decodificação especulativa troca computação por latência. A computação total por token é aproximadamente a mesma — você está apenas fazendo mais trabalho em paralelo em vez de sequencialmente.

Impacto no custo da GPU:

• A latência de solicitação única melhora em 20-50%, o que importa para aplicações interativas.
• O throughput (tokens/segundo através de muitas solicitações) melhora menos — a GPU já está saturada em tamanhos de lote altos.
• O uso de VRAM aumenta pelo tamanho do modelo de rascunho (1-4 GB para rascunhos independentes, mínimo para n-gram/EAGLE).

Inferência em nuvem: A $2-4/hora por H100, a decodificação especulativa reduz a latência por solicitação sem aumentar o custo por token. Para processamento em lote onde você já está saturando a GPU, o benefício de custo é mínimo — você está pagando pelo mesmo tempo de GPU de qualquer forma.

Quando a decodificação especulativa economiza dinheiro: Aplicações interativas onde você cobra por solicitação e deseja reduzir o tempo-para-primeiro-token. Uma aceleração de 2x significa que seus usuários esperam metade do tempo, e você pode servir mais solicitações por segundo no mesmo hardware.

Quando não economiza: Processamento em lote onde você já está maximizando a utilização da GPU. A computação extra da decodificação especulativa não aumenta o throughput — ela apenas muda o perfil de latência.

O Que Vem a Seguir

A decodificação especulativa está amadurecendo de novidade de pesquisa para padrão de produção. A fronteira está empurrando além das limitações atuais:

• Geração paralela no nível do modelo: a decodificação especulativa empurra múltiplos tokens por passagem de frente na camada de inferência sem tocar na distribuição de saída. Modelos de linguagem difusivos apostam estruturalmente diferente, gerando múltiplos tokens por passagem de frente como parte da própria arquitetura do modelo. Veja o que vem depois dos LLMs para ver como isso se compara à abordagem de rascunho-verificação acima, e aos modelos de espaço de estado e modelos mundiais JEPA no outro extremo da paisagem pós-transformador.

• Decodificação Especulativa Especulativa (SSD): Paralleliza os estágios de rascunho e verificação através de hardware separado. O modelo de rascunho executa assincronamente, pre-especulando para múltiplos resultados de verificação prováveis. Resultados iniciais mostram até 2x de aceleração sobre decodificação especulativa otimizada, e 5x sobre decodificação autoregressiva. Ainda não pronto para produção, mas a direção é clara.

• SpecSA (Verificação Esparsa Especulativa): Combina decodificação especulativa com atenção esparsa dinâmica. Transforma atenção esparsa em uma carga de trabalho orientada a verificação, atingindo até 3,49x de throughput final em relação à decodificação esparsa autoregressiva. Relevante para modelos de longo contexto onde a atenção esparsa já está em uso.

• Especulação adaptativa: Alternar automaticamente entre métodos de n-gram, EAGLE e modelo de rascunho com base nas características da carga de trabalho. A análise de oracle mostra potencial intocado significativo — as implementações atuais alcançam 2-3x, mas o limite teórico é 4,9x.

• Decodificação especulativa multimodal: Estendendo rascunho-verificação para modelos de linguagem visuais e geração de vídeo. Pesquisas iniciais mostram que os mesmos princípios se aplicam, mas as estratégias de verificação precisam de adaptação para modalidades não-textuais.

Estrutura de Decisão