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

Um modelo de 70B gera um token por passagem direta (forward pass), e cada passagem recarrega os pesos da VRAM, calcula a atenção em todo o contexto e sincroniza a memória. Entre os tokens, a GPU fica ociosa enquanto aguarda a resolução das dependências sequenciais.

Em uma H100, um modelo de 70B produz um token a cada 30-50ms. A GPU possui 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 fica bloqueado.

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

Este guia cobre a mecânica, as variantes disponíveis em 2026, compensações (trade-offs) da taxa de aceitação e configuração prática no llama.cpp, vLLM, SGLang e TensorRT-LLM.

Como Funciona a Decodificação Autorregressiva (e Por Que é Lenta)

Antes de entender a decodificação especulativa, você precisa entender a restrição autorregressiva que ela contorna. A geração autorregressiva padrão processa tokens sequencialmente:

1. Execute uma passagem direta pelo modelo com o contexto atual.
2. Amostre o próximo token da distribuição de saída.
3. Adicione o token ao contexto.
4. Repita.

Cada etapa requer uma passagem direta completa — carregando pesos da VRAM, calculando a atenção em 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 isso.

O Gap entre Computação e VRAM

As GPUs modernas têm mais FLOPs do que precisam para geração de um único token, então o verdadeiro gargalo é a largura de banda de memória — os pesos devem ser transferidos da VRAM para as unidades de computação em cada passagem direta. Ao gerar um token de cada vez, a GPU passa a maior parte do tempo esperando por transferências de memória em vez de realizar computação útil.

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

O Mecanismo de Rascunho e Verificação (Draft-Verify)

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

Verificar K tokens custa aproximadamente o mesmo que gerar um token autorregressivamente, então quando o rascunho está correto, você obtém K tokens pelo preço de uma etapa de verificação.

Um Exemplo Concreto

Suponha que o modelo de rascunho proponha 5 tokens: ["Eu", " gosto", " de", " cozinhar", " e"]. O modelo alvo os verifica em uma única passagem direta:

O alvo aceita os tokens 1 e 2, então gera " jogar" para o token 3, produzindo três tokens em um ciclo em vez de três passagens diretas separadas. Se o rascunho tivesse estado correto até o token 5, você obteria cinco tokens pelo custo de uma verificação — um aumento de velocidade de 5x apenas naquele ciclo.

O Gargalo de 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 direta do modelo alvo é o gargalo, e os tokens rejeitados representam computação desperdiçada.

É 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 os tokens aceitos esperados por ciclo, não apenas a taxa bruta de aceitação.

A Garantia Matemática

Uma das propriedades mais importantes da decodificação especulativa é que ela produz tokens da mesma distribuição exata que a amostragem autorregressiva padrão do modelo alvo. A etapa de verificação usa amostragem por rejeição — quando o rascunho propõe o token x, o modelo alvo 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 alvo concorda (p(x) ≥ p_draft(x)), o token é sempre aceito. Quando o alvo discorda, o token é aceito com 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 alvo, é por isso que a decodificação especulativa é sem perdas. O modelo de rascunho influencia a velocidade, não a qualidade — os tokens que você obtém 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 compensações entre complexidade de configuração, taxa de aceitação e aumento de velocidade.

Modelos de Rascunho Autônomos

A abordagem mais simples carrega um modelo menor junto com o alvo — tipicamente um modelo de 1B-3B fazendo rascunho para um alvo de 7B-70B.

Prós:

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

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 diferentes (ex: Qwen fazendo rascunho para Llama) tipicamente performam mal

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 alvo. O fator crítico é o alinhamento de distribuição — quão próximo as probabilidades de saída do modelo de rascunho correspondem às do alvo.

A regra de ouro: se a taxa de aceitação do modelo de rascunho cair abaixo de 50%, a decodificação especulativa pode realmente deixar você 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: Heads de Previsão

O EAGLE (Estimativa de Modelo de Linguagem Guiada por Arquitetura Eficiente) elimina a necessidade de um modelo de rascunho separado. Em vez disso, ele anexa heads de previsão autorregressiva leves às camadas internas do modelo alvo.

Como o EAGLE Funciona

O EAGLE treina heads de previsão que recebem estados ocultos das camadas intermediárias do modelo alvo e preveem tokens futuros. Durante a inferência:

1. O modelo alvo executa uma passagem direta através de suas camadas.
2. Em cada camada, o head EAGLE lê o estado oculto e propõe tokens para posições futuras.
3. Múltiplos heads operam em paralelo, cada um prevendo um timestep futuro diferente.
4. O modelo alvo verifica todas as propostas em uma única passagem.

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

Melhorias do EAGLE-3

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

1. Seleção de camadas: Em vez de anexar heads a cada camada, o EAGLE-3 usa otimização bayesiana para selecionar a camada de saída ótima, reduzindo o overhead.
2. Previsão de múltiplos tokens: Cada head prevê múltiplos tokens simultaneamente, aumentando a profundidade do rascunho sem custo computacional proporcional.
3. Eficiência de treinamento: O EAGLE-3 treina nos próprios dados de geração do modelo alvo, melhorando as taxas de aceitação em cargas de trabalho dentro da distribuição.

Taxas de aceitação: O EAGLE-3 tipicamente alcança taxas de aceitação de 60-80% em cargas de trabalho dentro da distribuição, comparado a 40-60% para modelos de rascunho autônomos. 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 heads pré-treinados para seu modelo alvo. A NVIDIA fornece heads EAGLE-3 para vários modelos populares através do TensorRT-LLM e da coleção de Módulos de Decodificação Especulativa 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 autorregressivo — cada token de rascunho depende do anterior, então gerar K tokens de rascunho requer K passagens diretas sequenciais através do head de rascunho, e o overhead do rascunho cresce linearmente com K. O P-EAGLE remove esse limite gerando todos os K tokens de rascunho em uma única passagem direta 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 aumento de velocidade sobre o EAGLE-3 vanilla em cargas de trabalho reais em NVIDIA B200. A vantagem se alarga 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 head P-EAGLE pré-treinado do HuggingFace, defina "parallel_drafting": true na sua config do vLLM, e use o mesmo flag --speculative-model — o vLLM cuida do resto. O P-EAGLE é o estado-da-arte atual para 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 de n-gramas

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

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

Prós:

• Zero overhead de VRAM — nenhum modelo adicional para carregar (~16 MB para a tabela hash)
• Extremamente rápido 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-grama não tem nada a propor
• A taxa de aceitação cai para perto de zero em cargas de trabalho criativas ou diversas
• 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 revisita padrões semelhantes. Pior para: escrita criativa, chat aberto e tarefas de raciocínio.

Ajuste de Parâmetros

Os parâmetros de n-grama 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 negocia 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 a própria computação parcial do modelo como rascunho, então 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 transformer — para gerar tokens de rascunho barato, e o modelo completo então verifica as propostas.

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

Prós:

• Sem pesos de modelo adicionais para carregar
• Naturalmente alinhado com a distribuição do alvo (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 diretas 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 menores do que EAGLE ou modelos de rascunho bem ajustados

Implementação no llama.cpp: O PR #18471 introduziu decodificação auto-especulativa usando histórico de contexto como rascunho. O modelo reutiliza tokens de seu próprio histórico de geração para propor continuação, 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)

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

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

Compensações:

• Sem modelo de rascunho para gerenciar — MTP é ativado com --spec-type draft-mtp --spec-draft-n-max N
• Heads 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 heads MTP baratos

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

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

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

A Fórmula de Aumento de Velocidade

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 — um aumento de velocidade de 3.5x sobre a 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 conforme o modelo explora continuação mais diversas.
• 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 alvo, baixando a aceitação. A decodificação especulativa funciona melhor em temperatura baixa (0.0-0.7).

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

Decodificação Especulativa em Produção: O Que Acontece de Verdade

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

Descobertas do SpecDecode-Bench (2026)

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

1. SD funciona, mas os aumentos de velocidade encolhem com o tamanho do batch. No tamanho de batch 1, o EAGLE alcança até 1.96x no Llama-3-70B. No tamanho de batch 128, isso cai para 1.21x. O sistema se torna limitado por computação em alta concorrência, e a GPU tem menos capacidade ociosa sobrando para especulação.

2. Verificação domina o tempo de execução (42-95%). A passagem direta do modelo alvo é o gargalo. Reduzir a verificação desperdiçada em tokens rejeitados é o caminho mais promissor para melhoria.

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

4. Análise de oráculo revela uma lacuna. O limite superior teórico para estratégias combinadas de n-grama + 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 Aumento de Velocidade

O efeito do tamanho do batch é crítico. Em batches pequenos, a GPU tem computação ociosa sobrando para especulação. Em batches 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 alvo — 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 pedido (deve ser estável em torno da sua linha de base)
• Tokens por segundo com e sem decodificação especulativa (o aumento de velocidade real)
• Tempo de verificação como porcentagem do tempo do ciclo (deve ser 42-95%)
• Tempo de passagem direta do modelo de rascunho (deve ser < 20% do tempo do modelo alvo)

Se sua taxa de aceitação cair abaixo de 40%, desative a decodificação especulativa para esse pedido. 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 como cada runtime lida com batching, compatibilidade de API e throughput antes de escolher um caminho de decodificação especulativa.

llama.cpp

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

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

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

# n-grama
llama-server \
  --model modelo-alvo.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-grama (ajuste para carga de trabalho de texto)
llama-server \
  --model modelo-alvo.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-especulativo (cargas de trabalho de codificação)
llama-server \
  --model modelo-alvo.gguf \
  --spec-type draft-self

Flags críticos:

• --parallel 1 — A decodificação especulativa no llama.cpp requer modo de batch ú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 na VRAM.
• --spec-ngram-simple-size-n — Comprimento do n-grama de consulta. 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 diferentes — as taxas de aceitação colapsam, anulando qualquer aumento de velocidade.
• Definir --spec-draft-n-max muito alto — cada token de rascunho extra custa VRAM para o buffer de rascunho. Retornos diminutos começam em torno de 5-8.

vLLM

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

O vLLM suporta decodificação especulativa através dos flags --speculative-model e --speculative-num-steps:

# Modelo de rascunho
vllm serve modelo-alvo \
  --speculative-model modelo-rascunho \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

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

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

# n-grama
vllm serve modelo-alvo \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

A decodificação especulativa do vLLM é integrada com batching contínuo, então funciona sob cargas de trabalho concorrentes. O escalonador lida com múltiplos slots de tokens dentro de uma única passagem direta, e o gerenciador de memória lida com o cache KV tanto para o modelo de rascunho quanto para o alvo.

SGLang

O SGLang suporta decodificação especulativa através do flag --speculative-algorithm:

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

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

TensorRT-LLM

O 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 engine TensorRT para ambos os modelos alvo e de 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.

O 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 de n-gramas demonstrou redução de latência de 2-3x em implantações de produção.

Quando Usar Decodificação Especulativa

Use Quando

• Modelos alvo grandes (7B+): O overhead do mecanismo de rascunho é amortizado sobre a computação do alvo. A decodificação especulativa brilha quando o modelo alvo é lento — quanto maior o alvo, mais valioso o aumento de velocidade.
• Cargas de trabalho de baixa temperatura: A decodificação especulativa funciona melhor em temperatura 0.0-0.7, onde a distribuição do modelo alvo é concentrada e o rascunho tem melhor chance de corresponder.
• Aplicações interativas: Cargas de trabalho sensíveis a latência (chat, conclusão de código, chamadas de ferramentas de agente) se beneficiam mais. Processamento em batch 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 o n-grama e a decodificação auto-especulativa particularmente eficazes.

Pule Quando

• Modelos alvo pequenos (< 3B): O overhead do modelo de rascunho se aproxima do tempo de passagem direta do alvo. O aumento de velocidade é marginal ou negativo.
• Amostragem de alta temperatura: Em temperatura > 0.7, a distribuição do modelo alvo é muito ampla para o rascunho corresponder de forma confiável.
• Escrita criativa e geração aberta: Baixas taxas de aceitação em conteúdo novo tornam o overhead não vale a pena.
• Tamanhos de batch altos (> 32): O sistema se torna limitado por computação, e a decodificação especulativa adiciona overhead sem benefício proporcional. O SpecDecode-Bench mostra o aumento de velocidade caindo de 1.96x para 1.21x conforme o tamanho do batch vai de 1 para 128.

Combinando Métodos

Configurações avançadas combinam múltiplas estratégias de decodificação especulativa. A análise de oráculo do SpecDecode-Bench mostrou que combinar adaptativamente n-grama e EAGLE pode empurrar o aumento de velocidade para 4.9x em cargas de trabalho de edição de código.

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

Por enquanto, a combinação mais prática é MTP + n-grama no llama.cpp. O MTP lida com a especulação neural, enquanto o n-grama captura padrões repetitivos que o MTP perde. No Qwen 3 27B, esta combinação alcança 120 tokens/seg comparado a 67 tokens/seg padrão — um aumento de velocidade 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 de GPU:

• A latência de pedido único melhora em 20-50%, o que importa para aplicações interativas.
• O throughput (tokens/seg através de muitos pedidos) melhora menos — a GPU já está saturada em tamanhos de batch altos.
• O uso de VRAM aumenta pelo footprint do modelo de rascunho (1-4 GB para rascunhos autônomos, mínimo para n-grama/EAGLE).

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

Quando a decodificação especulativa economiza dinheiro: Aplicações interativas onde você cobra por pedido e quer reduzir o tempo até o primeiro token. Um aumento de velocidade de 2x significa que seus usuários esperam metade do tempo, e você pode servir mais pedidos por segundo no mesmo hardware.

Quando não: Processamento em batch 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 Há Por Vir

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:

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

• SpecSA (Verificação Especulativa Esparsa): Combina decodificação especulativa com atenção esparsa dinâmica. Transforma atenção esparsa em uma carga de trabalho orientada à verificação, alcançando até 3.49x de throughput ponta-a-ponta sobre decodificação esparsa autorregressiva. Relevante para modelos de contexto longo onde atenção esparsa já está em uso.

• Especulação adaptativa: Alternando automaticamente entre métodos de n-grama, EAGLE e modelo de rascunho baseados em características da carga de trabalho. A análise de oráculo mostra potencial significativo não explorado — 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 visão-linguagem e geração de vídeo. Levantamentos 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.

Framework de Decisão