Beam search, speculative decoding e Medusa

01 · Conceito

Conceito

A lição 7.3 deixou o decode numa posição desconfortável: em batch 1, o Qwen3.8-27B transmite cerca de 54 GB de pesos da memória para cada token que emite. A cadeia serial — o token $t+1$ não pode ser finalizado antes do token $t$ — parece forçar esse preço. Esta lição cobre os métodos que gastam trabalho paralelo extra em volta da cadeia, e eles otimizam duas coisas muito diferentes. O beam search compra qualidade de saída. O speculative decoding e o Medusa compram velocidade, extraindo mais de um token de cada leitura cara de pesos — e o Qwen3.8-27B chega com sua própria versão nativa do truque.

Beam search primeiro, brevemente, porque ele é o estranho no grupo. Em vez de uma sequência parcial ele mantém $b$ candidatas, estende cada uma com próximos tokens plausíveis, pontua pela log-probabilidade cumulativa (com normalização por comprimento, senão saídas curtas vencem por padrão) e poda de volta para $b$. Ele brilha quando a verossimilhança em nível de sequência importa — transdução restrita, algumas tarefas estruturadas — e decepciona em diálogo aberto, onde os beams colapsam em texto quase duplicado e insossamente provável. A largura multiplica compute e uso de KV cache (beams compartilham prefixos por meio de block tables com copy-on-write). É um algoritmo de busca, não uma aceleração.

O speculative decoding ataca a latência diretamente. Um draft model barato propõe um bloco de $k$ tokens futuros de forma autorregressiva; o target model caro então avalia todas as $k$ posições numa única passagem — o mesmo formato paralelo de um prefill curto, uma leitura de pesos amortizada sobre $k$ candidatos. Uma regra de aceitação compara a probabilidade do draft com a do target token a token: os tokens aceitos são efetivados, e na primeira rejeição o sufixo dependente é descartado e um token corrigido é amostrado de uma distribuição ajustada. Feito corretamente (Leviathan et al.), a saída se distribui exatamente como se o target tivesse decodificado sozinho sob o mesmo sampler — mais forte do que apenas checar concordância de argmax.

Quanto isso ajuda? Uma conta ilustrativa de guardanapo: com probabilidade de aceitação por token $\alpha$ e comprimento de bloco $k$, o número esperado de tokens comprometidos por passagem do target é

contando o token bônus que o próprio target fornece. Com $\alpha = 0.8$ e $k = 4$: $0.8^{5} = 0.32768$, então $\mathbb{E} = (1 - 0.32768)/0.2 \approx 3.36$ tokens por passagem — cada leitura de 54 GB de pesos agora rende três e pouco tokens em vez de um. Os números são ilustrativos, não benchmarks do Qwen; taxas reais de aceitação dependem dos prompts, das configurações do sampler e do quanto o draft imita o target.

Agora o desvio clássico: “speculative decoding economiza computação”. Não economiza — ele aumenta o total de FLOPs. O draft roda a cada token, o target repontua cada proposta, e todo sufixo rejeitado é desperdício puro. Se o decode fosse limitado por compute, a especulação o deixaria mais lento. Ela vence porque a lição 7.3 mostrou que o decode é limitado por banda: as unidades aritméticas ficam ociosas enquanto os pesos fluem, então a matemática extra de verificação é praticamente de graça, e o recurso escasso — bytes movidos por token comprometido — cai pelo fator de aceitação. Corrigir esse equívoco diz quando recorrer à técnica: serving sensível à latência, com batch pequeno. Em batches grandes a leitura de pesos já está amortizada entre sequências, e o apelo da especulação se dissipa.

O próprio draft é uma tensão: fraco demais e as propostas são rejeitadas; grande demais e propor custa o que verificar economiza; e um modelo separado precisa ser hospedado, agendado e mantido compatível com o target. O Medusa (Cai et al.) dissolve o modelo separado ao parafusar heads leves de decoding no próprio target, cada uma prevendo um token num offset futuro; os heads propõem uma pequena árvore de continuações que uma única passagem de verificação poda até um caminho aceito. Os heads precisam ser treinados contra o checkpoint base exato — mudou a base, retreine os heads.

O Qwen3.8-27B dá o passo final: o model card afirma que ele foi treinado com multi-token prediction ao longo de múltiplos passos. O drafter não é parafusado depois; o próprio tronco aprendeu a propor vários tokens futuros como parte do pretraining. Na inferência isso funciona como fonte nativa de draft — nenhum segundo modelo para implantar, nenhum head post-hoc para ajustar, propostas que vêm das mesmas representações que o verificador usa. Serving stacks que dão suporte a isso (o model card lista vLLM e SGLang entre seus runtimes) podem verificar propostas de MTP exatamente como fariam com as de um draft model.

Uma campanha pública em RTX 5090 mostra por que isso precisa ser medido atrás de um gate de correção. Nesse relatório, um stack acelerado stock com TurboQuant 4-bit KV e MTP3 subiu, mas falhou canários de saída exata, JSON, ferramentas, coding e multi-turn, então o resultado de velocidade ficou em HOLD em vez de virar vitória publicada. Depois do patch #40914, os mesmos canários congelados passaram, e o C1 pareado reportou decode real de 151,27 tok/s, TTFT de 0,920 s, E2E de 7,69 s e 830 de 834 propostas de MTP aceitas (99,52 por cento). Isso é um estudo de caso útil para esse stack, não um número universal do Qwen: a lição é correção antes da velocidade, depois estatísticas de aceitação e formato da carga ao lado do throughput.

A contabilidade é a parte silenciosamente difícil. Candidatos em árvore compartilham um prefixo e divergem depois; máscaras de attention precisam impedir que ramos leiam uns aos outros; estados aceitos são efetivados em ordem enquanto ramos rejeitados liberam seus blocos de cache. Um bug aqui produz tokens plausíveis porém errados, então valide contra o decode base de forma distribucional. Clientes de streaming também precisam tolerar rajadas: quando quatro tokens são aceitos de uma vez, eles chegam de uma vez.

A distinção durável é o propósito. O beam search paga por múltiplas hipóteses para escolher uma sequência melhor. A especulação paga um proponente para expor trabalho paralelo enquanto o target permanece autoritativo sobre a distribuição. O Medusa move o proponente para dentro da arquitetura — e o treinamento de MTP do Qwen3.8-27B o move todo o caminho até o pretraining, transformando um truque de serving numa propriedade do próprio modelo.