Capítulo 9 — Decodificação Especulativa

Nono post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que revela a brecha matemática do gargalo sequencial da autorregressão — e mostra a aritmética de quando ela compensa.

Por que este capítulo existe

Os capítulos 7 e 8 atacaram a concorrência, mantendo a GPU ocupada em muitas sequências ao mesmo tempo. Nenhum deles altera o fato de que cada sequência ainda recebe apenas um token de saída por iteração. Esse piso parece inescapável porque a passagem direta do transformer realmente depende do token escolhido antes. A decodificação especulativa é a observação de que a dependência é sobre a geração, não sobre a verificação: dado um candidato para o token t+1, o modelo alvo consegue rodar uma única passagem direta que pergunta "eu teria escolhido este?" e ao mesmo tempo calcula a distribuição para t+2 assumindo que o candidato está correto. O capítulo 9 percorre o mecanismo, os algoritmos de rascunho (EAGLE, Medusa, Lookahead, MTP, n-gram, suffix) e a aritmética que decide quando a especulação é vitória.

9.1 A ideia de verificação preserva a correção exatamente

Um mecanismo de rascunho barato propõe N tokens candidatos. O alvo — o modelo caro que queremos — faz uma única passagem direta sobre o prefixo concatenado com esses N candidatos. Como a passagem do transformer é paralela em todas as posições, o alvo produz sua própria distribuição de próximo token em cada uma das N+1 posições nessa mesma passagem. O prefixo mais longo em que os candidatos concordam com o alvo é aceito; o primeiro desacordo é onde o engine passa a usar a escolha do próprio alvo e descarta o resto. A regra de aceitação — aceite x sorteado do rascunho q com probabilidade min(1, p(x)/q(x)), caso contrário amostre do resíduo normalizado (p−q)₊ — deixa a distribuição de saída idêntica à amostragem direta do alvo. A especulação preserva a correção; o rascunho afeta apenas a velocidade. Em GPUs modernas, a passagem de verificação com N=4 custa aproximadamente 1,2–1,5× uma iteração normal de decodificação, porque a atenção agora cobre N+1 posições de consulta mas continua bem dentro do regime memory-bound.

9.2 EAGLE amarra o rascunho ao estado oculto do alvo

As primeiras implementações usavam um modelo pequeno separado como rascunho — um Llama-7B rascunhando para um Llama-70B — o que funciona, mas custa um segundo fluxo pela HBM para os pesos do rascunho e limita a aceitação porque os dois modelos não compartilham representações. O EAGLE, refinado em EAGLE-2 e EAGLE-3 entre 2024 e 2025, amarra o rascunho ao alvo: uma única camada transformer treinada para prever o estado oculto da próxima camada do alvo, projetado pelo próprio embedding de saída do alvo. Não há um conjunto separado de 7B pesos para transmitir; a cabeça de rascunho tem algumas centenas de megabytes. O EAGLE-2 adiciona expansão dinâmica em árvore de rascunho — uma árvore de candidatos verificada numa única passagem de atenção com uma máscara customizada — de modo que o alvo escolhe o melhor entre vários caminhos, e não apenas o único palpite do rascunho. O EAGLE-3 acrescenta mistura de features de múltiplas camadas, consumindo camadas intermediárias do alvo em vez de apenas a penúltima. As taxas de aceitação ficam em 75–85 por cento em chat e código com N entre 5–8, traduzindo-se em speedups fim a fim de 3–4× sobre a decodificação simples. O Medusa segue o caminho alternativo — cabeças paralelas de rascunho que preveem vários tokens futuros em uma passagem, em vez de autoregressivamente — com um treino mais simples e aceitação ligeiramente menor. Decodificação por n-gram e por suffix é o almoço grátis para cargas repetitivas (edição de código, saídas em template), onde o rascunho é apenas uma consulta ao contexto recente.

9.3 A própria passagem de verificação vira o teto

A fórmula do speedup é exata o suficiente para escrever: E[tokens_aceitos] / (T_rascunho/T_decodificação + 1 + α·N), onde α é o overhead de verificação por posição, tipicamente 0,05–0,15. Dois tetos aparecem. Primeiro, α·N cresce com N, então aumentar N indefinidamente não ajuda; o pico fica em torno de N=6–8 com p=0,8, N=10–12 com p=0,9. Engines que fixam N em código perdem o ótimo quando a carga varia. Segundo, e de forma mais sutil, o speedup assintótico quando p tende a 1 é 1/α — cerca de 10× para α=0,10, 20× para α=0,05 — porque a própria passagem de verificação é a parede. Engines em produção mediram picos de speedup nessa faixa em cargas altamente repetitivas e não foram além. A especulação também interage com o batching: em batches grandes a passagem direta do alvo já está próxima de compute-bound, e os tokens extras de verificação a empurram ainda mais, então o speedup encolhe conforme o batch cresce. O ponto ideal da especulação é batch pequeno ou médio em cargas sensíveis à latência — exatamente o regime em que mora o compute subutilizado do capítulo 1.

O que o capítulo 9 prepara

Os capítulos 5 a 9 esgotaram o kit de modelo e runtime — quantização, poda, destilação, batching, KV paginada, decodificação especulativa. Nada disso se instala como uma biblioteca que se faz pip install e esquece. Alguém precisa costurar tudo em um runtime que possua um modelo numa GPU, rode um batch contínuo e exponha uma API de inferência. Esse runtime é o engine. O capítulo 10 percorre os cinco engines que dominam a pilha de 2026 — vLLM, TensorRT-LLM, SGLang, TGI e Ollama — e os trade-offs mecânicos que decidem qual é a escolha certa para cada deployment.

Próximo — Capítulo 10: A Camada de Engine de LLM. vLLM, TensorRT-LLM, SGLang, TGI, Ollama — engines como runtime de um único nó, escolhidos por mecanismo em vez de benchmark.