A inferência de LLMs em produção esbarra na largura de banda de memória das GPUs. Gerar um token por vez deixa os núcleos de computação ociosos na maior parte do ciclo.
A técnica de decodificação especulativa resolve esse limite. Ela gera múltiplos tokens candidatos em paralelo e valida o lote em um único passo computacional.
Por que a inferência tradicional de LLMs é lenta na GPU?
A inferência autoregressiva comum é lenta porque a GPU passa quase todo o tempo transferindo pesos da memória principal. Em batch size = 1, a intensidade aritmética é mínima.
O modelo Roofline descreve esse limite físico. Para cada token gerado, a GPU lê todos os parâmetros da rede da memória HBM para a SRAM local.
Considere um modelo de 70B de parâmetros em FP16 (140 GB de pesos):
- Em uma GPU NVIDIA H100 SXM5 com largura de banda de 3,35 TB/s (
3.350 GB/s), o tempo mínimo para ler os pesos éT_load = 140 GB ÷ 3.350 GB/s ≈ 41,8 ms/token. - Esse piso físico limita a taxa máxima a cerca de 24 tokens por segundo em uma sequência isolada.
- Enquanto os 140 GB trafegam pelo barramento, os núcleos tensores operam com menos de 3% de utilização teórica.
A decodificação especulativa converte essa ociosidade em velocidade real. O sistema valida vários tokens candidatos no mesmo ciclo de leitura de memória.
Como funciona a matemática da decodificação especulativa?
A decodificação especulativa opera em duas etapas coordenadas: a fase de rascunho (draft phase) e a fase de verificação paralela (verification phase).
Na primeira fase, um mecanismo leve propõe uma sequência de γ tokens candidatos (x_1, x_2, ..., x_γ). Na segunda fase, o modelo principal processa todos os candidatos em um único forward pass.
O algoritmo de Leviathan et al. (2023) e Chen et al. (2023) introduziu a amostragem com rejeição modificada. Esse método assegura fidelidade matemática exata à distribuição do modelo alvo.
Pipeline de Decodificação Especulativa:
[Draft Mechanism] ──> Gera γ tokens: [t_1, t_2, t_3, t_4]
│
▼
[Target Model] ──> 1 forward pass paralelo sobre [t_1, t_2, t_3, t_4]
│
▼
[Modified Rejection] ─> min(1, p(t_i) / q(t_i))
├─ t_1: Aceito (✓)
├─ t_2: Aceito (✓)
├─ t_3: Rejeitado (✗) ──> Amostra correção de p'(x)
└─ t_4: Descartado
Para cada token candidato x_i, com probabilidade q(x_i) no draft e p(x_i) no target:
- O token é aceito com probabilidade
min(1, p(x_i) / q(x_i)). - Se aceito, ele entra na resposta e a verificação segue para o próximo token
x_{i+1}. - Se rejeitado no índice
k ≤ γ, os tokens posteriores (x_{k+1}ax_γ) são descartados. - Um substituto é amostrado da distribuição residual
p'(x) = max(0, p(x) - q(x)) ÷ Σ max(0, p(y) - q(y)). - O ciclo é concluído, emitindo
ktokens válidos de uma só vez.
A expectativa de tokens aceitos depende de α e γ:
E[N] = (1 - α^(γ + 1)) ÷ (1 - α)
O speedup efetivo S é dado por S = E[N] ÷ (γ × c + 1), onde c = T_draft ÷ T_target. Quando α ≥ 0,75, o ganho atinge facilmente de 2,0× a 3,0×.
Quais são as principais arquiteturas de especulação?
Existem quatro abordagens principais para gerar tokens de rascunho, variando em complexidade, consumo de VRAM e taxa de concordância.
A escolha ideal depende da infraestrutura de hardware e do perfil da carga de trabalho em produção.
1. Modelo Draft Independente (Independent Draft Model)
Utiliza um modelo menor da mesma família como rascunho, como o Llama-3-8B rascunhando para o Llama-3-70B.
- Vantagens: Aproveita modelos pré-treinados existentes sem treinamento adicional.
- Desvantagens: Exige VRAM extra para dois modelos e requer alinhamento estrito de vocabulário e tokenizador.
2. Medusa: Cabeças Neurais Múltiplas (Multi-Head Decoding)
Proposto por Cai et al. (2024), o Medusa adiciona K cabeças MLP leves sobre a última camada oculta do modelo principal.
Cada cabeça prevê um token futuro. O sistema constrói uma árvore de candidatos e valida múltiplos caminhos prováveis com atenção em árvore (Tree Attention).
3. EAGLE e EAGLE-2: Especulação em Nível de Features
O framework EAGLE-2 (Li et al., 2024) realiza a auto-regressão no espaço de embeddings e estados ocultos da penúltima camada.
Ao operar sobre representações contextuais ricas, o EAGLE-2 alcança taxas de aceitação superiores a 80% em tarefas de código e raciocínio lógico.
4. Prompt Lookup e N-Gram Matching
Mecanismo sem parâmetros que identifica repetições de padrões (n-grams) no prompt e histórico. É eficiente para tarefas redundantes, como edição de código e síntese em RAG corporativo.
| Arquitetura | VRAM Adicional | Taxa de Aceitação Média (α) | Complexidade de Setup | Ideal Para |
|---|---|---|---|---|
| Independent Draft | Média (pesos do modelo draft) | 65% a 78% | Baixa (modelos prontos) | Clusters com VRAM disponível |
| Medusa (Tree) | Mínima (< 2% dos parâmetros) | 70% a 82% | Média (fine-tuning de heads) | Baixa latência em GPU única |
| EAGLE-2 | Mínima (1 camada Transformer) | 78% a 88% | Média | Raciocínio, matemática e código |
| Prompt Lookup | Zero (sem parâmetros) | 50% a 70% (tarefa-dependente) | Muito baixa | Geração de código e JSON estruturado |
Como configurar decodificação especulativa no vLLM?
O vLLM implementa decodificação especulativa integrada nativamente com o algoritmo de gerenciamento de memória PagedAttention.
Para servir um modelo Llama-3-70B utilizando um Llama-3-8B como draft via vLLM, configure os parâmetros na inicialização:
# Servindo Llama-3-70B com Llama-3-8B como Draft Model no vLLM
vllm serve meta-llama/Meta-Llama-3-70B-Instruct \
--tensor-parallel-size 4 \
--speculative-model meta-llama/Meta-Llama-3-8B-Instruct \
--num-speculative-tokens 5 \
--use-v2-block-manager \
--gpu-memory-utilization 0.90 \
--port 8000
Para utilizar especulação sem modelo adicional baseada no contexto (Prompt Lookup), utilize a flag --speculative-model [prompt_lookup]:
# Servindo com Prompt Lookup Decoding para alta velocidade em código e RAG
vllm serve meta-llama/Meta-Llama-3-70B-Instruct \
--tensor-parallel-size 4 \
--speculative-model [prompt_lookup] \
--num-speculative-tokens 4 \
--prompt-lookup-max-n-gram 3 \
--port 8000
Em fluxos de orquestração de agentes de IA, essa configuração reduz a latência inter-token de 38 ms para menos de 14 ms, viabilizando interações em tempo real.
Como a decodificação especulativa gerencia o KV Cache?
A decodificação especulativa gerencia o KV Cache alocando blocos dinâmicos para ramos da árvore de candidatos e consolidando apenas os nós aprovados.
Diferente da geração comum, a verificação em árvore (Tree Attention) cria múltiplos caminhos concorrentes de contexto.
O gerenciador de memória do runtime executa três passos estruturados:
- Alocação de Rascunho: O engine reserva blocos virtuais de KV Cache para os
γtokens rascunhados, compartilhando o histórico comum. - Forward Pass com Máscara: Uma matriz de atenção customizada garante que cada candidato veja apenas seus ancestrais na árvore, evitando contaminação.
- Poda e Consolidação: Ao definir o ponto de corte, os ramos rejeitados são liberados instantaneamente (
O(1)), promovendo apenas o caminho aceito.
Integrado ao PagedAttention, esse gerenciamento elimina qualquer necessidade de cópia redundante de tensores na memória física da GPU.
Quais são os trade-offs entre latência individual e throughput?
A decodificação especulativa prioriza a latência de sequências individuais em vez do throughput agregado sob saturação total.
Entender o comportamento sob carga evita erros comuns de dimensionamento na infraestrutura de produção.
- Baixa Concorrência (
batch size ≤ 4): A GPU possui núcleos ociosos. A decodificação especulativa acelera cada requisição em até3,2×. - Alta Concorrência (
batch size ≥ 64): O volume de requisições preenche os núcleos tensores. O sistema transita para o regime limitado por computação. - Sobrecarga sob Saturação: Em alta carga, verificar tokens rejeitados compete com outras requisições, reduzindo o rendimento total de tokens por segundo.
Para agentes autônomos e interfaces interativas onde a latência por usuário é crítica, a decodificação especulativa é o padrão ideal.
Perguntas Frequentes
A decodificação especulativa altera a qualidade ou criatividade do modelo?
Não. O algoritmo de amostragem com rejeição modificada garante que a distribuição estatística de saída seja idêntica à do modelo original. O texto gerado preserva a exata mesma qualidade, coerência e precisão.
Posso usar decodificação especulativa com modelos locais no Ollama ou vLLM?
Sim. O vLLM suporta modelos draft independentes, Medusa e Prompt Lookup nativamente. No Ollama, suporte a modelos draft está disponível através do backend llama.cpp.
Qual é a diferença entre decodificação especulativa e quantização?
A quantização reduz a precisão numérica dos pesos para diminuir o consumo de memória. A decodificação especulativa altera o fluxo de execução para gerar múltiplos tokens por ciclo. Ambas podem ser combinadas.
O que acontece quando o modelo draft erra a previsão de um token?
O modelo alvo rejeita o token divergente, descarta as previsões posteriores e amostra imediatamente o token correto da distribuição residual. O ciclo nunca propaga erros na resposta final.
Quantos tokens de rascunho (γ) devo configurar em produção?
O valor ideal de γ fica entre 3 e 5 tokens. Valores acima de 7 aumentam o desperdício computacional em rejeições precoces sem gerar ganhos proporcionais de velocidade.
Conclusão
A decodificação especulativa é uma evolução indispensável para a viabilidade econômica de modelos de linguagem em larga escala. Ao superar o gargalo de memória, sistemas como Medusa, EAGLE-2 e vLLM triplicam a velocidade com fidelidade matemática absoluta.
Na Produtora MaxVision, projetamos arquiteturas completas de inteligência artificial corporativa, agentes autônomos e infraestrutura de alta performance. Descubra nossas soluções em Inteligência Artificial ou fale com nossos especialistas para dimensionar seu cluster de inferência.
