ReaDy acelera a decodificação de LLMs híbridos em 3,16 vezes em uma única B200

Pesquisadores apresentaram o ReaDy, um método de decodificação especulativa para modelos híbridos com atenção linear. Em sete benchmarks de matemática, geração de código e diálogo, ele acelera a geração em média 3,16 vezes em comparação com a decodificação autorregressiva convencional. O teste foi feito com o Qwen3.8-27B em uma única NVIDIA B200. Em relação à solução anterior, o DSpark, o ReaDy leva vantagem de forma consistente: é melhor nos sete testes, em média 7,97% em vazão (throughput) e 8,50% em comprimento da sequência aceita.

Por que o rascunho olha para o lugar errado

A decodificação especulativa funciona de forma simples. Um modelo de rascunho leve (drafter) prevê vários tokens à frente de uma só vez, e o modelo principal os verifica em uma única passada e aceita o prefixo correto. Quanto mais longa a cadeia aceita, menos passos caros o modelo grande precisa executar.

Muitos rascunhos atuais se baseiam nas features ocultas do modelo-alvo. Os autores do ReaDy apontam um ponto fraco dessa abordagem: essas features carregam o próprio "foco de contexto", que nem sempre coincide com o que as posições seguintes do rascunho precisam. Para o primeiro token, uma parte do histórico é mais importante; para o quarto, pode ser necessária outra. Um único conjunto de features atende a essas demandas de forma desigual.

Como o ReaDy funciona

Os modelos lineares híbridos mantêm estados recorrentes compactos, nos quais se acumulam associações históricas. Para a aceleração, isso é uma boa fonte de contexto adicional: o modelo-alvo já o calculou, e ele ocupa pouco espaço. Segundo os autores, o ReaDy é o primeiro a usar esses estados para buscar contexto específico para cada posição do rascunho.

O mecanismo é este:

• Cada posição do rascunho recebe uma query treinável própria.
• A query lê contexto adicional diretamente dos estados recorrentes confirmados (committed) do modelo-alvo.
• Um módulo leve de leitura de estados (state reader) incorpora o que foi encontrado às representações do rascunho por meio de atualizações residuais.
• A leitura de estados de baixo ranque e operadores fundidos (fused) mantêm baixo o custo extra de computação e de entrada e saída.

O método parte do backbone paralelo e da cabeça de previsão sequencial do DSpark. A adaptação ocorre em duas etapas. Nas ablações, os autores avaliaram a capacidade do reader, as fontes de estados e o ponto de inserção das atualizações residuais. O resumo não traz resultados concretos dessas ablações.

Os números

• Benchmarks: sete, abrangendo matemática, código e diálogo.
• Modelo e hardware: Qwen3.8-27B, uma NVIDIA B200.
• Aceleração média em relação à autorregressão: 3,16x.
• Contra o DSpark: throughput +7,97%, comprimento de aceitação +8,50% em média.
• Resultado melhor que o do DSpark em cada um dos sete testes.

Vale observar a relação entre as métricas. Um aumento de 8,50% no comprimento de aceitação com um ganho de 7,97% na vazão indica que quase todo o ganho vem de rascunhos mais precisos, e que a computação extra da leitura de estados consome apenas uma pequena parte dele. Isso é coerente com a ênfase dos autores na leitura de baixo ranque e nos operadores fused.

O que verificar antes de adotar

O método está preso à arquitetura. Ele exige estados recorrentes, então serve para modelos lineares híbridos e não se aplica, dessa forma, a transformers clássicos com atenção completa. Se a sua produção roda com modelos HLA, vale incluir o ReaDy na lista de candidatos: o código é aberto no GitHub (StartLuxLabs/ReaDy), e a adaptação em duas etapas significa que o rascunho precisa ser treinado para o seu modelo-alvo, em vez de ser usado pronto.

A descrição não traz dados importantes para a operação real. Não está claro como o método se comporta com batches grandes, contextos longos e memória limitada. Todas as medições foram feitas em uma única B200, e a comparação com o DSpark usa um único conjunto de testes. Antes de colocar os 3,16x no cálculo de custo de inferência, rode o método no seu próprio tráfego: código, matemática e diálogo podem estar distribuídos de outra forma aí, e a velocidade dos métodos especulativos depende muito da previsibilidade do texto.