Tencent Abre o Código-Fonte do AngelSpec e Desafia a Decodificação Especulativa de Tamanho Único

A Tencent Hunyuan abriu o código-fonte do AngelSpec após relatar uma inferência do Hy3-A21B até 2,40 vezes mais rápida do que a decodificação autorregressiva padrão. O framework combina suporte a treinamento, avaliação e implantação para duas rotas distintas de decodificação especulativa. Sua afirmação central desafia uma suposição comum: um único método de rascunho não consegue lidar com eficiência com todas as cargas de trabalho de modelos de linguagem.

O AngelSpec inclui previsão de múltiplos tokens, ou MTP, que propõe vários tokens futuros por meio de um gerador autorregressivo leve. Também introduz o DFly, um sistema de difusão em blocos que elabora em paralelo um grupo maior de tokens. A Tencent afirma que o DFly entregou throughput 10,5% a 11,8% maior do que o DFlash em suas condições de serving testadas.

Essa comparação importa porque o DFlash já havia afastado a decodificação especulativa de rascunhos estritamente sequenciais. O AngelSpec não propõe apenas outro gerador mais rápido. Ele organiza duas abordagens contrastantes em torno da carga de trabalho que cada uma executa melhor e, em seguida, ajusta a verificação às condições de execução.

O resultado é um framework aberto com uma visão mais operacional da aceleração de inferência. Desenvolvedores podem inspecionar o caminho de treinamento, testar os modelos de rascunho Hy3 lançados e examinar como o desempenho muda com o tráfego. No entanto, os ganhos relatados pela Tencent vêm de seus próprios modelos, configurações e projeto de avaliação. Resultados independentes em produção continuam sendo a evidência decisiva que falta.

AngelSpec Transforma uma Escolha de Pesquisa em uma Escolha de Implantação

O AngelSpec trata a decodificação especulativa como um problema de seleção de carga de trabalho, não como uma disputa por uma arquitetura universal de rascunho.

Os pesquisadores da Tencent enviaram a primeira versão do artigo do AngelSpec em 28 de julho de 2026. Uma versão revisada foi publicada em 29 de julho. A empresa então anunciou o lançamento de código aberto com código de treinamento e pesos do modelo de rascunho Hy3-A21B.

A decodificação especulativa usa um gerador menor ou mais barato para propor vários tokens futuros. O modelo-alvo completo verifica essas propostas em conjunto e aceita o prefixo correspondente. Quando as propostas são precisas, o sistema produz vários tokens válidos enquanto evita um número equivalente de passagens caras pelo modelo-alvo.

O método preserva a distribuição de saída do modelo-alvo quando implementado com o processo necessário de verificação e rejeição. Portanto, ele muda a eficiência com que os tokens são gerados, em vez de substituir as respostas do modelo-alvo pelas respostas do gerador.

A qualidade do rascunho ainda determina se essa vantagem teórica se torna um ganho prático de velocidade. Um gerador fraco produz tokens rejeitados, adicionando trabalho sem avançar a geração. Um gerador grande pode prever com precisão, mas consumir tempo e memória demais. A verificação também pode se tornar cara quando os sistemas testam mais candidatos do que uma solicitação justifica.

O AngelSpec reúne essas variáveis em um único framework de treinamento e avaliação. Ele oferece suporte a MTP e decodificação especulativa paralela em blocos, incluindo geração de estados ocultos, treinamento de contexto longo, fluxos de rollout e avaliação de aceitação online. O lançamento pretende cobrir uma parte maior do caminho entre um checkpoint de pesquisa e um serviço de inferência em operação.

As duas rotas de rascunho do framework dividem o problema de acordo com o comportamento da saída. A Tencent treina seu gerador MTP com dados conversacionais variados, nos quais a linguagem é aberta e os próximos tokens permanecem relativamente incertos. Ela treina a rota de difusão em blocos com código e matemática, nos quais continuações mais longas frequentemente seguem estruturas mais previsíveis.

Essa especialização é a mudança mais importante do anúncio. Muitas comparações de decodificação especulativa perguntam qual método vence em média. O AngelSpec pergunta, em vez disso, qual estrutura de rascunho se adapta a uma distribuição específica e expõe ambas as estruturas por meio de um caminho comum de desenvolvimento.

Os pesos que acompanham o lançamento também tornam a proposta mais testável do que um artigo que descreve um sistema indisponível. A Tencent afirma ter lançado geradores MTP e DFly para Hy3-A21B por meio de seus canais de modelos. Os desenvolvedores ainda precisam do modelo-alvo correspondente e de hardware de serving adequado, mas não precisam recriar todas as etapas de treinamento antes de começar a avaliação.

O Hy3 oferece um alvo exigente para o lançamento. O repositório oficial do modelo Hy3 descreve um modelo mixture-of-experts com 295 bilhões de parâmetros totais e 21 bilhões de parâmetros ativos. Ele também lista uma camada MTP de 3,8 bilhões de parâmetros e uma janela de contexto de 256.000 tokens.

Essas especificações tornam a eficiência de inferência economicamente importante. Apenas uma fração do modelo completo é ativada para cada token, mas o serving ainda exige memória substancial, comunicação e computação do modelo-alvo. Um gerador que aumenta a saída aceita por etapa de verificação pode melhorar a latência ou o throughput sem retreinar o modelo principal.

Portanto, o AngelSpec chega como mais do que outro acessório do Hy3. Ele oferece um framework explícito para escolher, treinar e avaliar sistemas de rascunho à medida que as condições de serving mudam. Esse escopo mais amplo pressiona a decodificação especulativa de tamanho único.

Os Ganhos Relatados Pressionam Estratégias Estáticas de Rascunho

A afirmação mais forte da Tencent não é apenas o pico de aceleração, mas a liderança do DFly em todos os níveis de concorrência testados, de 4 a 64.

Segundo o artigo, o DFly entregou uma aceleração ponta a ponta de 1,98 a 2,40 vezes em relação à decodificação autorregressiva no Hy3-A21B. A Tencent também relata throughput 10,5% a 11,8% maior do que o DFlash e uma saída média aceita cerca de 30% mais longa.

Concorrência mede quantas solicitações o sistema de serving processa ao mesmo tempo. Ela altera o equilíbrio entre computação, eficiência de batching, pressão de memória e overhead de verificação. Um método que parece rápido para uma solicitação pode perder sua vantagem quando muitas solicitações disputam os mesmos aceleradores.

A Tencent afirma que o DFly alcançou o maior throughput médio em cada nível de concorrência testado, de 4 a 64. Esse intervalo importa porque inclui tráfego relativamente leve e serviço com batching mais intenso. O resultado sugere que o agendador e a estratégia de verificação do DFly contribuíram para além da taxa bruta de aceitação do modelo de rascunho.

Os números ainda exigem interpretação cuidadosa. Uma aceleração de 2,40 vezes não significa que todos os usuários vejam respostas chegando 2,40 vezes mais rápido. A aceleração ponta a ponta depende da carga de trabalho do benchmark, do tamanho da saída, da mistura de solicitações, da política de batching, do perfil de hardware e da configuração de referência.

Throughput e latência também respondem a perguntas diferentes. Throughput mede quanto trabalho um sistema conclui ao longo do tempo. Usuários interativos frequentemente se importam mais com o tempo até o primeiro token e com o atraso entre os tokens posteriores. Um serviço pode aumentar o throughput total enquanto produz melhorias menores ou desiguais para uma solicitação individual.

Essa distinção pressiona equipes de inferência que usam políticas fixas de rascunho. Uma política estática pode escolher um comprimento de rascunho, uma profundidade de verificação ou um gerador para todo o tráfego. O AngelSpec defende que essas escolhas devem responder ao domínio, às características da solicitação, à carga online e ao hardware de implantação.

O alvo dessa pressão, portanto, não é uma empresa específica. É a abordagem que trata a decodificação especulativa como um anexo fixo ao modelo. Se as descobertas da Tencent se confirmarem em outros cenários, os operadores precisarão de lógica de roteamento e agendamento que entenda quando o trabalho de rascunho continua sendo valioso.

O DFlash fornece a comparação mais direta. Seu design de difusão em blocos usa estados ocultos do modelo-alvo para prever vários tokens de rascunho em paralelo. A abordagem evita gerar cada proposta por meio de uma etapa separada e sequencial do gerador.

Os autores do DFlash relataram aceleração superior a seis vezes em experimentos selecionados e ganhos sobre o EAGLE-3. Esses resultados usaram alvos e condições de teste diferentes, portanto não devem ser comparados diretamente com o máximo de 2,40 vezes do AngelSpec. A afirmação relevante da Tencent é a comparação controlada com o DFly relatada em sua própria avaliação do Hy3.

Sistemas no estilo EAGLE permanecem outra referência importante. Eles usam recursos do modelo-alvo para orientar um gerador autorregressivo menor, frequentemente organizando propostas para uma verificação eficiente. Esses sistemas podem oferecer resultados estáveis em textos variados, mas dependências sequenciais dentro do rascunho podem limitar a rapidez com que sequências longas de candidatos são propostas.

O MTP ocupa uma versão mais leve dessa rota autorregressiva. É mais fácil de integrar quando o alvo já expõe camadas de previsão compatíveis. O próprio lançamento do Hy3 pela Tencent inclui uma camada MTP, tornando o modelo um ambiente de teste natural para comparar o rascunho leve com um sistema especializado paralelo em blocos.

A pressão do AngelSpec sobre implantações existentes é prática. As equipes precisam decidir se o modelo adicional, a lógica de agendamento, o profiling e o uso de memória produzem tokens aceitos suficientes para justificar sua complexidade. O framework oferece código e pesos para explorar essa questão, mas não torna a resposta universal.

Como o AngelSpec Torna o DFly Mais Seletivo

O DFly combina rascunho paralelo com informação autorregressiva e, em seguida, emprega o trabalho de verificação onde o retorno esperado é maior.

Um gerador de difusão em blocos prevê várias posições simultaneamente em vez de concluí-las uma a uma. A previsão paralela reduz a latência do rascunho, especialmente quando o bloco de candidatos é longo. No entanto, tokens dentro de uma frase ou sequência de código dependem fortemente de tokens anteriores nesse mesmo bloco.

Essa dependência cria uma fraqueza. Se cada posição for prevista a partir de vizinhos mascarados ou incompletos, propostas posteriores podem deixar de receber informações que um gerador autorregressivo recebe naturalmente. Um erro inicial pode encurtar o prefixo aceito pelo modelo-alvo, desperdiçando grande parte do bloco proposto.

O DFly aborda essa tensão com dois componentes conectados. Sua espinha dorsal é condicionada a recursos do modelo-alvo, ao mesmo tempo que mantém a geração paralela em blocos. Uma cabeça autorregressiva condicionada ao predecessor também fornece às previsões informações sobre tokens anteriores, melhorando as dependências dentro do bloco proposto.

A arquitetura não transforma todo o rascunho em um processo sequencial convencional. O design da Tencent tenta preservar o trabalho paralelo na espinha dorsal enquanto adiciona informação suficiente sobre predecessores para melhorar a consistência dos candidatos. Esse equilíbrio é central para o aumento alegado no comprimento médio aceito.

O comprimento aceito é o número de tokens propostos que o modelo-alvo aprova antes de encontrar uma divergência. Prefixos aceitos mais longos distribuem cada etapa cara de verificação por uma quantidade maior de saída útil. Ainda assim, maximizar apenas o comprimento aceito pode ser enganoso se produzir e verificar esses candidatos consumir tempo demais.

Por isso, o AngelSpec adiciona um método adaptativo de verificação chamado D-Cut. A profundidade de verificação se refere a quanto de cada continuação proposta o modelo-alvo verifica. Uma profundidade fixa pode investir demais em candidatos incertos ou parar cedo demais em candidatos altamente previsíveis.

O D-Cut trata a capacidade de verificação como um recurso compartilhado no nível do lote. Ele estima o valor esperado de manter posições adicionais de candidatos e compara esse valor a um custo de execução perfilado. O agendador pode então direcionar mais trabalho de verificação para prefixos de alta confiança em várias solicitações.

Esta é uma decisão de serving, não apenas uma decisão de modelo. Duas solicitações executadas no mesmo modelo podem justificar diferentes profundidades de verificação. Uma conclusão estruturada de código pode sustentar um prefixo longo e confiante, enquanto uma resposta de chat aberta pode divergir após apenas alguns tokens.

O hardware também muda o cálculo. Um lote de verificação maior pode ser eficiente em uma configuração de acelerador e caro em outra. Custos de comunicação, largura de banda de memória, kernels e paralelismo do modelo-alvo afetam se outra posição candidata economiza tempo.

É por isso que o AngelSpec traça o perfil do custo de runtime em vez de depender apenas de estimativas de probabilidade. Uma candidata pode parecer propensa a ser aceita, mas ainda oferecer baixa utilidade se sua verificação expandir um lote para um formato ineficiente. O agendador precisa tanto de confiança quanto de custo de sistema medido.

A documentação de decodificação especulativa da Nvidia ilustra como frameworks de implantação já expõem configurações específicas de cada método. Seu suporte a DFlash exige um modelo draft, comprimento draft, token de máscara e camadas-alvo selecionadas. O AngelSpec leva o problema adiante, em direção à alocação adaptativa entre solicitações ativas.

A divisão por domínio complementa essa adaptação de runtime. O MTP continua sendo a rota leve para respostas conversacionais com maior incerteza. O DFly é voltado para código e matemática, onde blocos paralelos podem capturar sequências previsíveis mais longas. Nenhum dos métodos recebe automaticamente o direito a todas as solicitações.

Considere um serviço de programação com IA gerando uma suíte de testes repetitiva. Imports, assinaturas de funções e padrões de asserções podem tornar o próximo bloco relativamente previsível. O DFly pode propor uma continuação mais longa, e o D-Cut pode manter uma verificação mais profunda enquanto a confiança permanece alta.

Agora considere o mesmo serviço respondendo a uma pergunta ambígua sobre arquitetura. Várias explicações válidas podem começar a partir do mesmo prompt. O prefixo aceito pode encurtar porque o drafter e o alvo escolhem formulações diferentes. Uma proposta MTP menor pode evitar o gasto de recursos em um bloco candidato longo com baixa probabilidade de sobreviver.

Esse mecanismo torna o lançamento mais relevante do que uma melhoria isolada de benchmark. Ele redefine a decodificação especulativa como uma política que abrange dados de treinamento, arquitetura draft, classificação de solicitações e custo de serving. O ganho de velocidade vem da coordenação dessas camadas, e não da maximização de uma única métrica isolada.

O Que os Números do AngelSpec Não Comprovam

O AngelSpec fornece evidências primárias críveis, mas ainda não comprova que o DFly vence entre modelos, hardwares ou tráfego de produção.

Os resultados do artigo vêm da equipe que projetou o framework e treinou os modelos draft. As comparações reportadas não foram reproduzidas de forma independente no momento do lançamento. Os leitores devem tratar os ganhos de velocidade como alegações medidas pela empresa, e não como garantias universais de desempenho.

A dependência de modelo é a primeira limitação. O DFly usa recursos internos do alvo, portanto um drafter fica fortemente vinculado à arquitetura e às características de treinamento de seu alvo. Um drafter Hy3-A21B não pode simplesmente se tornar um acelerador plug-and-play para uma família de modelos não relacionada.

Essa conexão aumenta os custos de treinamento e manutenção. Cada alvo compatível pode precisar de seu próprio processo de extração de estados ocultos, mistura de dados de treinamento, checkpoint e ciclo de validação. Atualizações do modelo-alvo também podem exigir novos testes de compatibilidade ou um novo treinamento do drafter.

A dependência de hardware cria outra incerteza. A Tencent afirma que o D-Cut usa custo de runtime traçado, reconhecendo que a melhor política de verificação muda entre sistemas. Uma política ajustada para um cluster pode precisar de novos perfis antes de funcionar bem em aceleradores ou topologias de rede diferentes.

Os números de destaque públicos também comprimem diversas cargas de trabalho em intervalos. Código, matemática e conversa têm previsibilidades diferentes. A taxa média de throughput pode ocultar categorias fracas, comprimentos de prompt desfavoráveis ou padrões de tráfego nos quais a sobrecarga de drafting se aproxima da computação-alvo economizada.

O comportamento em contexto longo merece atenção especial. O AngelSpec oferece suporte a treinamento de contexto longo, e o Hy3 lista uma janela de contexto de 256.000 tokens. No entanto, grandes caches de chave-valor aumentam a pressão sobre a memória e podem alterar o custo relativo de drafting e verificação. Resultados em contextos mais curtos não podem determinar o desempenho próximo à janela máxima do modelo.

A preservação de qualidade também exige disciplina de implementação. A decodificação especulativa pode preservar a distribuição do alvo por meio do algoritmo adequado de aceitação e rejeição. Atalhos de implantação, verificação aproximada, amostragem alterada ou quantização incompatível podem modificar as saídas. Os operadores precisam validar tanto a velocidade quanto a equivalência comportamental.

A memória é outro custo real. O modelo-alvo, o modelo draft, as interfaces de estados ocultos e buffers adicionais de runtime precisam coexistir. Mesmo um drafter leve pode reduzir o espaço disponível para o cache de chave-valor ou lotes maiores. A troca de capacidade resultante pode eliminar um ganho de throughput em implantações limitadas por memória.

A complexidade operacional também importa. Um serviço de produção deve monitorar comprimento de aceitação, tempo de drafting, tempo de verificação, comportamento de fila e desempenho de fallback. O roteamento entre MTP e DFly introduz outra camada de decisão, cujos erros podem enviar as cargas de trabalho erradas para o drafter errado.

O lançamento open source torna essas questões testáveis, o que é valioso. Ele não as responde automaticamente. As equipes devem reproduzir uma linha de base autoregressiva em seu próprio hardware antes de comparar qualquer rota do AngelSpec.

Depois, devem separar as medições por carga de trabalho e nível de tráfego. Categorias úteis incluem chat interativo, conclusão de código, raciocínio matemático, rastros de uso de ferramentas e geração de textos longos. Cada categoria deve incluir percentis de latência, throughput, consumo de memória, comprimento de aceitação e verificações de equivalência de saída.

Uma comparação justa com DFlash também exige condições equivalentes. Devem ser usados o mesmo modelo-alvo, precisão, framework de serving, distribuição de prompts, comprimento de saída e concorrência. Caso contrário, alegações arquiteturais podem se misturar à qualidade dos kernels ou às diferenças de configuração.

O feedback da comunidade oferece sinais iniciais, mas não substitui uma reprodução controlada. Relatos de implantação local frequentemente usam modelos quantizados, hardware de consumo ou mecanismos de serving modificados. Esses resultados podem revelar problemas de compatibilidade, embora raramente correspondam de perto o suficiente à configuração do artigo para validar seu intervalo de destaque.

A lacuna de benchmark não torna o AngelSpec irrelevante. Ela define a próxima etapa da história. A Tencent forneceu uma arquitetura, um caminho de código e pesos de modelo que equipes externas podem contestar sob condições que os autores originais não controlaram.

Três Sinais Determinarão se o AngelSpec Vai Além do Hy3

A importância do AngelSpec dependerá de replicação independente, suporte mais amplo a modelos e evidências de que o roteamento adaptativo resiste ao tráfego real de produção.

O primeiro sinal é um benchmark reproduzível do Hy3-A21B por uma equipe independente de inferência. O teste mais sólido usaria os pesos MTP e DFly lançados, ao mesmo tempo em que reportaria hardware, precisão, versões de framework, composição de prompts e comprimentos de saída. Ele deveria comparar decodificação autoregressiva, MTP, DFlash e DFly sob condições equivalentes.

Uma replicação próxima ao intervalo de 1,98 a 2,40 vezes da Tencent fortaleceria a alegação central. Ganhos consistentes sobre o DFlash também sugeririam que o condicionamento de predecessores e o D-Cut agregam valor além do drafting geral por difusão de blocos. Ganhos menores ou instáveis reduziriam o apelo prático do AngelSpec.

O relatório independente mais útil publicaria mais do que o throughput médio. Ele deveria incluir tempo até o primeiro token, latência entre tokens, latência de cauda, uso de memória, comprimento aceito e desempenho em diferentes níveis de concorrência. Essas medições mostrariam se a eficiência agregada melhora a experiência do usuário.

O segundo sinal é o suporte a outra grande família de modelos-alvo. Atualmente, o AngelSpec tem suas evidências mais claras e pesos draft lançados em torno do Hy3. Uma portabilidade bem-sucedida para Qwen, Llama ou outro modelo aberto amplamente implantado testaria se seu framework se generaliza além da arquitetura da Tencent.

A portabilidade também revelaria o custo real de adoção. Pesquisadores precisariam gerar estados ocultos do alvo, treinar drafters especializados, integrar a verificação e traçar o comportamento de runtime. Uma portabilidade documentada com esforço razoável de engenharia fortaleceria a alegação do framework de usabilidade ponta a ponta.

A falta de portabilidades sugeriria que o AngelSpec é principalmente um pacote de otimização do Hy3. Esse resultado ainda poderia beneficiar os usuários dos modelos da Tencent, mas enfraqueceria o argumento mais amplo em favor de um framework unificado de decodificação especulativa.

O terceiro sinal é a evidência de produção em cargas de trabalho mistas. O argumento da Tencent depende da heterogeneidade, portanto um benchmark estático não pode validá-lo integralmente. O teste decisivo é saber se um serviço ativo consegue escolher entre MTP e DFly enquanto o tráfego, os domínios e a utilização de hardware mudam.

Os operadores devem observar com que frequência as decisões de roteamento melhoram a saída aceita por unidade de custo de verificação. Também devem medir taxas de fallback e erros de roteamento. Um sistema adaptativo complexo precisa superar uma linha de base mais simples depois de incluídas suas sobrecargas de monitoramento e agendamento.

Esse teste é especialmente relevante para serviços que combinam chat, programação, trabalho matemático e ações de agentes. Esses produtos geram saídas com entropia e comprimento muito diferentes. Eles oferecem as condições nas quais o drafting especializado deve superar uma política universal.

Se implantações com cargas de trabalho mistas mostrarem ganhos estáveis, os concorrentes enfrentarão pressão para expor controles de roteamento semelhantes. Os frameworks de serving podem evoluir da seleção de um algoritmo especulativo no lançamento para a atribuição de algoritmos e orçamentos de verificação por solicitação.

Se os ganhos desaparecerem fora de cargas de trabalho selecionadas, métodos mais simples continuarão atraentes. O MTP pode ser mais fácil de operar, especialmente quando um modelo já vem com camadas compatíveis. Estratégias draft estáticas também reduzem o número de modelos e políticas que as equipes precisam manter.

Desenvolvedores que avaliam o lançamento devem preservar seus resultados de teste e decisões de configuração em uma base de conhecimento de engenharia pesquisável. Experimentos de decodificação especulativa envolvem variáveis interativas suficientes para que execuções não documentadas rapidamente se tornem impossíveis de comparar.

O AngelSpec já mudou a questão enfrentada por engenheiros de inferência. A escolha deixou de ser apenas habilitar ou não a decodificação especulativa. Agora, trata-se de saber se o drafter, a distribuição de treinamento, a política de verificação e o perfil de hardware correspondem suficientemente bem a cada solicitação para economizar trabalho real.

Os próximos um a três meses devem revelar se equipes externas reproduzem os números da Tencent, portam o DFly além do Hy3 e validam o roteamento adaptativo sob demanda real. Até lá, o AngelSpec é um experimento aberto sério, com resultados primários promissores, não um vencedor consolidado.

Para equipes que servem Hy3 hoje, o próximo passo útil é um benchmark controlado contra suas configurações autoregressivas e MTP existentes. Para todos os demais, a questão central é mais restrita: o drafting orientado pela carga de trabalho oferece eficiência sustentada suficiente para justificar outro modelo e outra camada de agendamento? A resposta determinará se o AngelSpec se torna um framework de inferência amplamente adotado ou permanece uma vantagem bem projetada ligada principalmente à própria família de modelos da Tencent.