Guia de decodificação especulativa no vLLM com GPUs AMD

{ "resumo": "## O problema da decodificação autorregressiva\n\nEm sistemas de serving de LLMs, a decodificação autorregressiva é a linha de base: o modelo gera um token, o anexa à sequência e repete o processo para o próximo token. Gerar quatro tokens exige quatro passos sequenciais de decodificação, o que pode dominar a latência e limitar o throughput em gerações longas.\n\n## A ideia central do speculative decoding\n\nO speculative decoding não substitui o modelo original; ele o mantém como modelo-alvo, responsável pelo resultado final, e adiciona um componente leve de rascunho (draft) na frente. O ciclo tem duas partes: o draft propõe candidatos a tokens futuros e o modelo-alvo os verifica em uma única passada. A verificação ocorre da esquerda para a direita: tokens aceitos são confirmados; ao primeiro token rejeitado, os candidatos seguintes são descartados e o próprio modelo-alvo fornece o token de substituição. Quando vários candidatos são aceitos, múltiplos tokens podem ser confirmados em uma única passada de verificação, preservando o comportamento de saída do modelo original.\n\n## Cinco métodos de rascunho\n\nOs métodos se dividem em três categorias conforme a arquitetura do draft:\n\n- Native MTP: usa um caminho auxiliar de previsão embutido na arquitetura do próprio modelo-alvo, gerando candidatos sequencialmente. Como compartilha componentes com o modelo (como tabela de embeddings), a sobrecarga de memória tende a ser modesta.\n- Gemma 4 MTP: usa um componente de rascunho com checkpoint separado, mas emparelhado ao modelo-alvo, reutilizando ativações e o cache KV do alvo. Também gera candidatos sequencialmente.\n- EAGLE-3: rede de rascunho dedicada e autorregressiva. Captura estados ocultos de três estágios do forward pass do alvo (início, meio e fim), concatena e projeta em uma representação fundida, combinada com o embedding do token amostrado.\n- DFlash: rede dedicada que prevê um bloco inteiro de posições futuras em paralelo, em uma única passada. Parte de um token âncora conhecido e usa o contexto fundido do alvo como representações Key/Value adicionais em todas as camadas do draft. Posições posteriores não são condicionadas às anteriores na mesma passada.\n- DSpark: usa um backbone estilo DFlash e adiciona um cabeçote sequencial leve (Markov) que ajusta os logits com base no token anterior selecionado, corrigindo combinações inconsistentes. Um cabeçote de confiança para seleção de prefixo existe no desenho, mas não estava ativo nos experimentos.\n\n## Como habilitar e onde obter checkpoints\n\nNo vLLM, a configuração usa --speculative-config, com os métodos mtp, eagle3, dflash e dspark. O MTP nativo não exige checkpoint separado; os demais precisam de um modelo de rascunho compatível. É preciso reservar memória extra de GPU para os pesos do draft quando houver checkpoint separado. Checkpoints pré-treinados são publicados no Hugging Face por Google (assistentes MTP para Gemma 4), Z-Lab (DFlash), Red Hat AI (EAGLE-3, DFlash e DSpark), DeepSeek (coleção DeepSpec), LightSeek (EAGLE para Kimi) e Inferact (MiniMax e Kimi).\n\n## Medições em GPUs AMD\n\nOs experimentos usaram AMD Instinct MI300X e MI355X com a plataforma ROCm, benchmarks baseados em tarefas reais (GSM8K, MATH500, HumanEval, MBPP) em vez de sequências aleatórias. Os resultados variaram conforme modelo, método, carga de trabalho e profundidade de proposta: para gemma-4-26B-A4B-it, DFlash atingiu 2,87× no MATH500 e Gemma 4 MTP 2,74× no GSM8K; para Qwen3-8B, DSpark variou de 1,15× a 1,63×; para Qwen3.5-122B-A10B, o maior valor de MTP nativo foi 2,20× no MATH500. Para Kimi-K2.5, DFlash chegou a 2,68× e EAGLE-3 a 2,33×. A proposta associada ao maior throughput não foi constante: nos métodos sequenciais, o throughput costuma subir nos primeiros valores de N e depois estabilizar; para DFlash e DSpark, N=7 frequentemente esteve entre as melhores configurações.\n\n## Ajustes e observabilidade\n\nO texto trata o speculative decoding como otimização de runtime, não como configuração fixa. Recomenda-se começar de uma configuração suportada (por exemplo, N=1 no MTP nativo), medir com cargas representativas e monitorar throughput, comprimento médio aceito, taxa de aceitação geral e taxa de aceitação por posição. Janelas maiores de proposta aumentam as chances de confirmar vários tokens, mas a aceitação pode cair nas posições finais, fazendo o throughput estagnar ou regredir. Aceitação alta não implica necessariamente throughput maior, pois o draft tem custo próprio.\n\n## Treinar um speculator\n\nPara treinar um rascunhador para um novo modelo-alvo, o fluxo envolve preparar prompts representativos, gerar respostas com o próprio modelo-alvo (o tokenizer ou template aplicados a respostas existentes não tornam os dados específicos do alvo), escolher o modo de obtenção dos estados ocultos (online, offline ou híbrido), coletar as informações do alvo, treinar e testar aceitação e throughput.", "hook": "O speculative decoding permite ao vLLM verificar vários tokens rascunhados em uma única passada do modelo-alvo, mas o ganho de throughput variou bastante entre métodos e modelos: de 1,08× a até 2,87× nos testes. Um guia da equipe do vLLM explica cinco abordagens de rascunho - native MTP, Gemma 4 MTP, EAGLE-3, DFlash e DSpark - com medições em GPUs AMD Instinct MI300X e MI355X usando ROCm.", "entities": ["vLLM", "AMD Instinct", "ROCm", "EAGLE-3", "DFlash", "DSpark", "Gemma 4", "Qwen"], "themes": ["economia-de-tokens", "open-weights-e-modelos-locais"], "story_key": "vllm-speculative-decoding-amd", "reasoning": { "story_key": "Guia técnico central do vLLM sobre speculative decoding em GPUs AMD, com medições comparativas de cinco métodos.", "themes": { "economia-de-tokens": "Assunto central é eficiência de inferência: throughput de tokens, aceitação e ajuste de num_speculative_tokens.", "open-weights-e-modelos-locais": "Aborda ecossistema de draft models públicos no Hugging Face e execução local em hardware AMD com ROCm." }, "entities": { "vLLM": "Plataforma de serving onde os métodos são habilitados e medidos.", "AMD Instinct": "GPUs MI300X e MI355X usadas nos experimentos.", "ROCm": "Plataforma de software usada no ambiente de teste.", "EAGLE-3": "Um dos cinco métodos de rascunho avaliados.", "DFlash": "Método de rascunho paralelo avaliado, com bons resultados.", "DSpark": "Método híbrido paralelo com correção sequencial avaliado.", "Gemma 4": "Família de modelos-alvo com MTP dedicado e resultados de benchmark.", "Qwen": "Família de modelos-alvo com múltiplos resultados de benchmark." }, "excluded": { "Kimi", "MiniMax", "DeepSeek", "Red Hat AI", "Z-Lab", "Google", "LightSeek", "Inferact": "Editores de checkpoints ou modelos-alvo secundários, não sujeitos centrais do fato.", "MI300X", "MI355X": "Variantes normalizadas para a família AMD Instinct." } } }