Decodificação especulativa em paralelo acelera o SGLang em até 4 vezes e ganha código aberto

Se você executa LLMs em produção, certamente já ouviu falar de decodificação especulativa. A ideia é simples: um pequeno modelo de rascunho prevê rapidamente vários tokens à frente, e um modelo maior os verifica em uma única passagem. Se as previsões estiverem corretas, você obtém vários tokens pelo custo de uma só etapa, sem alterar a qualidade da resposta. É por isso que o método se tornou praticamente um padrão nas plataformas de inferência em produção. Agora, um novo trabalho avança nessa direção: geração paralela do rascunho com preservação das dependências causais. O ganho anunciado é de até 4 vezes na capacidade de processamento do SGLang, e o código foi disponibilizado publicamente.

O problema do EAGLE-3

O EAGLE-3 é considerado uma das abordagens mais fortes de decodificação especulativa. A geração do rascunho é autorregressiva: para prever o quinto token, é preciso primeiro prever o quarto, e assim por diante. As previsões são precisas, mas essa precisão custa tempo. Cada token adicional no rascunho exige mais uma passagem sequencial de propagação direta. Surge uma armadilha conhecida: você quer prever mais tokens à frente, mas a própria geração do rascunho começa a atrasar o processo e consome o ganho.

Imagine uma linha de montagem em que cada trabalhador espera o anterior terminar. Adicionar trabalhadores não adianta: a velocidade é determinada pelo comprimento da cadeia.

O que foi proposto no lugar da cadeia

O DFlash deu um passo anterior em direção à solução. Inspirado em modelos de linguagem por difusão, ele gera todo o rascunho em paralelo: uma única passagem pela rede de rascunho produz um bloco inteiro de tokens. A latência deixa de crescer com o comprimento do rascunho. Mas o paralelismo completo tem um preço: os tokens do bloco são previstos quase independentemente uns dos outros, enquanto, na linguagem, a próxima palavra depende muito da anterior. Isso pode reduzir a proporção de tokens aceitos pelo modelo verificador.

A julgar pelo título, o novo trabalho resolve justamente esse impasse. As dependências causais entre os tokens do rascunho são incorporadas à profundidade da própria rede: em vez de etapas sequenciais ao longo do tempo, a dependência é «codificada» nas camadas percorridas por uma mesma passagem paralela. Em termos simples, a ordem é considerada dentro de uma única passagem, em vez de por meio de várias passagens consecutivas. Assim, a geração do rascunho mantém a velocidade das abordagens paralelas e se aproxima da precisão das autorregressivas.

Para conferir os detalhes específicos da arquitetura, os tamanhos dos modelos e as tabelas completas de medições, vale consultar o artigo e o repositório. A cifra de «até 4 vezes» se refere à capacidade de processamento no SGLang e, como sempre ocorre com «até», descreve o melhor cenário, não o resultado típico.

Como aplicar isso na prática

Primeiro: se você usa SGLang e já ativou a decodificação especulativa, faz sentido testar o novo método com seu próprio tráfego. O ganho depende muito do modelo, do comprimento das respostas, do tamanho do lote e da proporção de tokens aceitos pelo modelo verificador. Com respostas curtas ou lotes grandes, o efeito pode ser bem mais modesto do que o título sugere.

Segundo: não olhe apenas para os tokens por segundo. Também importam o tempo até o primeiro token, o comportamento sob carga elevada e o consumo de memória de GPU da rede de rascunho. A memória adicional destinada ao rascunho pode tirar espaço do cache KV e reduzir o número de solicitações simultâneas.

Terceiro: treinar a rede de rascunho exige dados e recursos computacionais. Se você fizer um ajuste fino ou trocar o modelo base, precisará treinar novamente o modelo de rascunho; caso contrário, a taxa de aceitação de tokens cairá. Inclua isso no custo de implementação.

Limitações e conclusão

Por enquanto, os resultados vêm de uma única publicação, com poucas reproduções independentes. O método está vinculado a uma plataforma específica, e adaptá-lo ao vLLM, ao TensorRT-LLM ou a kernels próprios exigirá trabalho. Ainda assim, a direção é clara: a corrida não é por um modelo base mais inteligente, mas por gastar menos etapas sequenciais com cada token. Para equipes cuja conta de GPU se tornou a principal despesa, vale testar no próximo sprint um código aberto que promete multiplicar o desempenho: basta comparar a capacidade de processamento e a taxa de aceitação de tokens em solicitações reais antes e depois.