Tencent HPC chega ao SGLang e desafia os kernels de inferência padrão

O Tencent HPC entrou na ramificação principal do SGLang com três caminhos de operadores otimizados e uma redução relatada de 48,8% na latência de tokens do Hy3. A contribuição leva implementações de Dynamic Attention, Router GEMM e Fused MoE da biblioteca HPC-Ops do Tencent Hunyuan a um mecanismo de inferência de código aberto amplamente utilizado.

O número de destaque merece uma contextualização cuidadosa. TPOT, ou tempo por token de saída, mede a latência média entre tokens gerados depois que o primeiro aparece. Tencent e SGLang relatam melhorias de até 48,8% em configurações Hy3 testadas, e não um ganho universal entre modelos, GPUs e padrões de tráfego.

Ainda assim, trata-se de mais do que outra coleção de benchmarks CUDA isolados. Usuários do SGLang podem acessar os kernels por meio de um framework upstream, em vez de manter um fork privado. Isso coloca o trabalho de operadores da Tencent em concorrência direta com caminhos estabelecidos de SGLang, FlashInfer, CUTLASS, Triton e inferência apoiados por fornecedores.

Tencent HPC sai de uma biblioteca de kernels e entra no SGLang

A mudança importante é a distribuição, não apenas mais um benchmark rápido.

HPC-Ops é uma biblioteca de operadores de inferência de código aberto desenvolvida pela equipe de infraestrutura de IA Hunyuan da Tencent. Seu repositório de operadores abrange operações de atenção, GEMM, computação Mixture-of-Experts, amostragem, normalização e comunicação fundida.

Um operador é um bloco de construção computacional de baixo nível que executa uma tarefa específica do modelo na GPU. Frameworks como o SGLang montam esses blocos no caminho de execução usado para atender solicitações de modelos.

Antes da integração upstream, equipes interessadas em HPC-Ops precisavam instalar e conectar seus componentes em seu próprio ambiente de serving. Esse trabalho envolvia testes de compatibilidade, seleção de backend e adaptação contínua quando qualquer um dos projetos mudava.

A integração na ramificação principal do SGLang altera essa relação. O framework pode reconhecer e despachar operações Hy3 compatíveis para os kernels da Tencent por meio de caminhos de backend mantidos. Os usuários não precisam mais de um fork duradouro do SGLang apenas para avaliar a implementação.

A contribuição inicial se concentra em três áreas sensíveis à latência:

• Dynamic Attention distribui trabalho de decodificação desigual entre unidades de execução da GPU.

• Router GEMM acelera uma multiplicação de matrizes sensível à precisão usada para selecionar especialistas de MoE.

• Fused MoE combina várias etapas de processamento de especialistas para reduzir lançamentos e tráfego de memória.

Cada uma visa uma fonte diferente de atraso na inferência. Juntas, elas tratam as cargas de trabalho irregulares criadas por contextos longos e modelos esparsos.

Hy3 é um caso de teste útil porque combina ambos os problemas. A Tencent descreve o Hy3 como um modelo esparso Mixture-of-Experts projetado para execução agentic, programação e raciocínio estendido. Sua arquitetura ativa apenas parte do modelo para cada token, mas ainda exige atenção sobre um contexto crescente e roteamento entre muitos especialistas.

Essa combinação cria latência fora das grandes multiplicações de matrizes que normalmente dominam benchmarks simplificados. Agendamento, movimentação de dados, conversão de precisão, roteamento e pequenos lançamentos de kernel podem se tornar igualmente importantes durante o serving online.

O resultado ponta a ponta relatado é uma redução de TPOT de até 48,8% em cargas de trabalho Hy3 testadas. Esse número vem do ambiente de benchmark dos autores do projeto e não foi reproduzido de forma independente em um amplo conjunto de hardware.

A distinção importa porque “até” captura o caso medido mais favorável. Ela não descreve a melhoria média para todos os padrões de solicitação. Um servidor com prompts curtos e uniformes pode obter um resultado diferente de outro que atende sessões agentic de comprimentos variados.

HPC-Ops também continua específico de hardware. Seus requisitos publicados identificam a arquitetura SM90 da NVIDIA, Python 3.8 ou posterior e CUDA 12.8 ou posterior. A biblioteca afirma que seus kernels são especialmente ajustados para GPUs NVIDIA H20.

Isso limita a portabilidade imediata, mas não elimina a importância da disponibilidade upstream. O SGLang tornou-se um ponto de integração comum para criadores de modelos, equipes de infraestrutura e desenvolvedores de kernels. Entrar nele expõe o trabalho da Tencent a testes mais realistas do que um repositório independente normalmente recebe.

Isso também segue uma integração semelhante ao vLLM. Em julho, os backends de atenção e MoE do HPC-Ops entraram na ramificação principal do vLLM como opções de primeira classe. Os benchmarks do vLLM que os acompanham relataram menor latência de primeiro token e de token de saída em oito GPUs H20.

Assim, o SGLang se torna o segundo grande ecossistema de serving em que a Tencent pode testar se seus kernels orientados à produção funcionam além da própria infraestrutura da Tencent. Esse é o verdadeiro acontecimento por trás do benchmark.

Por que o Tencent HPC importa para o serving online de modelos

O desempenho moderno de inferência depende de gerenciar trabalho irregular, não apenas de maximizar a taxa bruta de matrizes.

Benchmarks offline frequentemente usam comprimentos fixos de prompt, lotes previsíveis e formatos de tensor estáveis. O tráfego de produção se comporta de forma diferente. As solicitações chegam continuamente, os contextos crescem em ritmos distintos e os usuários interrompem a geração em pontos imprevisíveis.

Uma solicitação pode trazer um contexto de 16.000 tokens, enquanto outra acaba de começar com 1.000 tokens. Um agendamento de atenção estático pode atribuir muito mais trabalho a um bloco de GPU do que a outro. A tarefa mais curta termina cedo, enquanto a mais longa determina quando todo o lançamento é concluído.

Dynamic Attention tenta reduzir esse desequilíbrio. O HPC-Ops divide o trabalho do cache de chave-valor em blocos menores e atribui esses blocos de acordo com a carga de trabalho atual. O mapeamento é reconstruído à medida que os comprimentos das solicitações mudam durante a decodificação.

Um cache de chave-valor armazena estados de atenção anteriores para que o modelo não recalcule todo o seu histórico a cada novo token. Históricos mais longos exigem que mais dados em cache sejam lidos e processados.

O HPC-Ops descreve um agendador que divide solicitações em blocos uniformes e os distribui entre arrays cooperativos de threads. Um array cooperativo de threads, ou CTA, é um grupo de threads de GPU que executa uma unidade de trabalho agendada.

A biblioteca relata desempenho do Dynamic Attention de até 2,88 vezes o de sua linha de base static split-k em testes selecionados de comprimento variável. Seus resultados mais amplos de atenção incluem ganhos frente a FlashInfer, FlashAttention e TensorRT-LLM em configurações especificadas.

Esses números em nível de operador não devem ser confundidos com uma melhoria ponta a ponta do servidor. Um kernel de atenção mais rápido afeta apenas a parcela da latência total gasta nessa operação. Agendamento de solicitações, comunicação, carregamento de modelos, amostragem e outras camadas permanecem no caminho.

Ainda assim, a atenção se torna cada vez mais relevante à medida que os contextos crescem. Aplicações agentic adicionam repetidamente resultados de ferramentas, documentos recuperados e raciocínio intermediário a uma sessão ativa. Isso cria exatamente os comprimentos desiguais de cache visados pelo agendamento dinâmico.

Um assistente de programação oferece um exemplo concreto. Uma solicitação pode conter uma função pequena e uma instrução curta. Outra pode incluir um mapa do repositório, vários arquivos, logs de build e todo o histórico da conversa.

Colocar ambas as solicitações em um lote contínuo melhora a utilização, mas cria trabalho de atenção desigual. Uma política de divisão estática deixa algumas unidades de GPU ociosas ou lança blocos vazios para solicitações mais curtas.

O agendamento dinâmico tenta fazer com que essas solicitações coexistam de maneira mais eficiente. O maior benefício deve aparecer quando os comprimentos das sequências diferem substancialmente e o servidor tem trabalho simultâneo suficiente para reequilibrar.

É por isso que TPOT importa mais do que um único número de throughput. Throughput mede a saída agregada de todas as solicitações. TPOT reflete mais diretamente a rapidez com que um usuário individual vê tokens sucessivos durante a geração.

Para agentes interativos, a entrega lenta de tokens se acumula em respostas longas e chamadas repetidas de ferramentas. Um TPOT menor pode encurtar cada segmento de geração, permitindo que a próxima etapa da ferramenta ou do modelo comece mais cedo.

A integração também pressiona a seleção padrão de kernels dentro dos frameworks de inferência. O SGLang já oferece várias implementações de atenção e MoE, cada uma otimizada para modelos, precisões e GPUs diferentes. Um novo backend precisa superar essas opções sem criar regras de configuração frágeis.

Essa concorrência beneficia os operadores apenas quando o despacho do framework permanece compreensível. Uma equipe de infraestrutura precisa saber quando o HPC-Ops é ativado, quais formatos ele suporta e qual fallback atende uma solicitação não compatível.

Ela também precisa de evidências do próprio tráfego. Benchmarks públicos podem identificar um backend promissor, mas não conseguem reproduzir todas as combinações de comprimento de sequência, tamanho de lote, quantização, paralelismo e objetivo de nível de serviço.

Equipes que avaliam a contribuição devem medir TPOT mediano e de cauda, tempo até o primeiro token, throughput de solicitações, uso de memória da GPU e consistência de saída. A latência média por si só pode ocultar interrupções que afetam os usuários mais lentos.

A mesma disciplina se aplica ao conhecimento técnico que envolve uma avaliação. Equipes de engenharia podem preservar comandos de benchmark, notas de implantação e análise de falhas em uma base de conhecimento pesquisável, em vez de depender de conversas dispersas.

O Tencent HPC importa porque oferece a essas equipes mais um caminho de execução mantido para testar. Seu valor virá de melhorias reproduzíveis no serving, não do maior número em um gráfico de lançamento.

Dynamic Attention e Fused MoE atacam gargalos diferentes

O ganho Hy3 relatado vem da eliminação de vários pequenos atrasos que se acumulam durante cada token gerado.

Dynamic Attention visa o desequilíbrio de carga durante a atenção. Fused MoE visa a fragmentação depois que o modelo roteia tokens para especialistas selecionados. Router GEMM fica entre os dois e acelera a decisão que atribui esses especialistas.

MoE, ou Mixture-of-Experts, substitui algumas camadas neurais densas por uma coleção maior de redes feed-forward especializadas. Um roteador seleciona um pequeno subconjunto de especialistas para cada token, limitando a computação realizada por token.

Essa esparsidade reduz a computação ativa, mas introduz irregularidade. Especialistas diferentes podem receber contagens diferentes de tokens. O servidor precisa calcular pontuações de roteamento, organizar tokens, executar várias multiplicações de matrizes menores e combinar saídas ponderadas.

Implementações convencionais frequentemente separam essas ações em vários kernels. Elas reúnem tokens em buffers específicos de especialistas, lançam operações de matriz, aplicam ativações, quantizam valores intermediários e reduzem as saídas selecionadas.

Cada separação pode gerar outro lançamento e outra passagem pela memória de alta largura de banda. Esses custos são pequenos isoladamente, mas significativos durante a decodificação com lotes pequenos, em que cada operação de especialista processa relativamente poucos tokens.

O HPC-Ops usa um caminho MoE FP8 fundido. FP8 é um formato de ponto flutuante de oito bits que reduz o tráfego de memória e aumenta o throughput disponível dos tensor cores em comparação com formatos mais amplos.

O caminho fundido combina o pré-processamento relacionado ao roteamento, a multiplicação de matrizes de gate e expansão, a quantização de ativação, a projeção de volta à largura do modelo e a redução ponderada. A Tencent afirma que a implementação lê os tokens originais por meio de índices de roteamento, em vez de primeiro copiá-los para buffers de especialistas reunidos.

Esse design busca eliminar tanto a movimentação de memória quanto os intervalos entre lançamentos de kernel. Ele também altera como a implementação oculta a latência.

Em vez de depender fortemente de pipelining de software dentro de um único bloco de GPU, o HPC-Ops aumenta o número de blocos residentes para formatos de baixa latência. O agendamento de hardware pode então alternar entre blocos enquanto outro trabalho aguarda dados.

A biblioteca informa que seu operador Fused MoE é até 1,6 vez mais rápido com paralelismo de tensores e 1,5 vez mais rápido com paralelismo de especialistas. Suas comparações publicadas incluem implementações do SGLang, vLLM Triton e vLLM CUTLASS.

O paralelismo de tensores divide os cálculos do modelo entre GPUs. O paralelismo de especialistas posiciona diferentes especialistas de MoE em diferentes workers, exigindo que os tokens se desloquem até os workers que contêm os especialistas selecionados.

A melhor escolha depende do formato do modelo, da velocidade da interconexão, da concorrência de solicitações e dos limites de memória. Um kernel local fundido não pode eliminar a comunicação exigida por uma arquitetura distribuída de especialistas.

O Router GEMM aborda uma restrição mais sutil. GEMM significa multiplicação de matrizes de propósito geral, a operação central por trás de muitas camadas de redes neurais.

Um roteador multiplica ativações de menor precisão por pesos cujas pequenas diferenças numéricas podem afetar a seleção de especialistas. Reduzir esses pesos de forma agressiva demais pode alterar a decisão de roteamento e, portanto, modificar a saída do modelo.

Usar aritmética FP32 completa protege a precisão, mas os tensor cores atuais não oferecem o mesmo throughput em FP32 disponível para formatos de menor precisão. Uma implementação direta pode recorrer à computação mais lenta nos CUDA cores.

O HPC-Ops decompõe cada peso FP32 em dois componentes BF16. O BF16 preserva a faixa de expoente do FP32, usando menos bits de mantissa.

Um componente carrega a parte principal do peso. O segundo carrega um resíduo escalonado, com o projeto documentando uma escala de 1/256. O kernel então executa duas multiplicações em tensor cores BF16 e combina os resultados.

Os dois cálculos permanecem dentro de um único kernel. Eles compartilham a movimentação de entrada, mantêm acumuladores intermediários em registradores e gravam o resultado final uma única vez.

A Tencent informa desempenho de até 3,22 vezes o das referências FP32 ou TF32 do cuBLAS para formatos selecionados de roteador e compressão de estado. A alegação representa formatos de operadores testados, não todas as cargas de trabalho GEMM.

O mecanismo importa porque tenta preservar o comportamento de roteamento enquanto aproveita o throughput do hardware de menor precisão. Velocidade sem uma seleção comparável de especialistas seria uma troca ruim para inferência em produção.

Essa questão de precisão também explica por que os detalhes de validação de saída são importantes. Um benchmark deve comparar decisões de roteamento ou saídas finais do modelo, não apenas o tempo de execução.

A integração anterior ao vLLM relatou qualidade de saída equivalente em sua comparação de MoE. A integração ao SGLang agora cria outra oportunidade para mantenedores e usuários testarem o comportamento numérico entre implementações de frameworks.

Juntos, os três operadores formam uma história coerente de execução. O Dynamic Attention distribui o trabalho de contexto. O Router GEMM decide para onde vai a computação esparsa. O Fused MoE executa essa computação com menos fronteiras.

A melhoria é, portanto, uma história de mecanismos, e não a alegação de que um único kernel monolítico se tornou quase duas vezes mais rápido. Vários gargalos foram reduzidos, e seu valor combinado depende de quanto cada um contribui para uma carga de trabalho específica.

O que a alegação de 48,8% de TPOT não estabelece

O benchmark mais forte é um indício confiável para testes, mas não é uma garantia de desempenho portátil.

A redução relatada se aplica à avaliação Hy3 da Tencent e às condições de hardware compatíveis. Nem esse número nem a documentação atual estabelecem o mesmo resultado para todos os modelos do SGLang.

O Hy3 combina comportamento de atenção específico do modelo, roteamento esparso, execução FP8 e uma estrutura particular de especialistas. Um modelo denso sem camadas MoE não pode se beneficiar dos caminhos Fused MoE ou Router GEMM.

Um modelo que use embeddings rotacionais diferentes, ordem de normalização, dimensões de cabeças, escalas de quantização ou layouts de cache pode exigir trabalho de integração. Ele também pode ativar apenas parte do HPC-Ops.

O hardware cria outra fronteira. Os requisitos do HPC-Ops atualmente se concentram em GPUs NVIDIA SM90 e CUDA 12.8 ou posterior. Os resultados publicados mais fortes se concentram no H20.

Isso deixa sistemas NVIDIA Ampere, configurações Blackwell, aceleradores AMD e outros hardwares fora do escopo demonstrado. O SGLang oferece suporte a uma gama mais ampla de ambientes do que este backend atualmente atende.

Mesmo no H20, o formato do tráfego pode alterar o resultado. O Dynamic Attention oferece a vantagem mais clara quando um lote contém comprimentos de sequência desiguais. Solicitações curtas e uniformes dão ao agendador menos desequilíbrio para corrigir.

O Fused MoE também depende do tamanho do lote. A equipe do vLLM relatou seus maiores ganhos em lotes pequenos e médios, nos quais lançamentos convencionais e passagens de memória consomem uma parcela maior do tempo total.

Em alta concorrência, operações matriciais maiores podem usar a GPU com eficiência suficiente para reduzir a diferença. A comunicação também pode predominar quando o paralelismo de especialistas abrange vários dispositivos ou nós.

O número de 48,8% portanto precisa de contexto da matriz completa de benchmarks. Os leitores devem procurar comprimentos de prompt, comprimentos de saída, concorrência, tamanho do paralelismo de tensores, tamanho do paralelismo de especialistas, precisão de cache, clocks de GPU e configuração de referência.

A qualidade da referência é especialmente importante. Um backend padrão pode ser uma comparação razoável para novos usuários, mas pode não representar a melhor alternativa ajustada.

A arquitetura modular de paralelismo de especialistas do SGLang permite kernels personalizados e backends especializados. FlashInfer, DeepGEMM, Triton, CUTLASS e os kernels nativos do SGLang continuam a evoluir, portanto os resultados comparativos podem mudar rapidamente.

A data de integração também importa. O código do branch principal recebe mudanças rápidas antes que uma versão estável chegue a implantações mais amplas. Um backend integrado ainda pode precisar de empacotamento, documentação, testes de compatibilidade e salvaguardas operacionais.

A precisão numérica continua sendo outra área para verificação independente. O Router GEMM aproxima a computação de pesos FP32 usando dois componentes BF16. Esse design busca precisão de nível FP32, mas usuários posteriores devem testar o comportamento no nível do modelo.

Verificações úteis incluem concordância de saída sob decodificação determinística, sobreposição de índices de roteamento, perplexidade em dados representativos e avaliação no nível de tarefa. Uma pequena diferença numérica pode ser inofensiva, ou pode redirecionar tokens para especialistas diferentes.

A confiabilidade em produção vai além da correspondência numérica. Os kernels precisam lidar com formatos de limite, pressão de memória, cancelamento, batching contínuo, cache de prefixos e comprimentos de sequência variáveis sem falhas raras.

A revisão de código aberto ajuda a identificar esses problemas, mas visibilidade não é o mesmo que maturidade. As versões do SGLang mostram com que frequência o suporte a modelos, kernels, caminhos de quantização e comportamento de agendamento mudam.

A Tencent afirma que o HPC-Ops já oferece suporte a inferência em larga escala dentro de seu próprio ambiente. Essa experiência é significativa, mas implantações externas frequentemente expõem combinações que uma frota interna de modelos nunca utiliza.

Há também uma questão de manutenção. O código upstream reduz o ônus de manter um fork, mas o pacote externo HPC-Ops e sua matriz de compatibilidade ainda precisam de responsabilidade ativa.

Os usuários devem acompanhar a rapidez com que Tencent e SGLang respondem a relatórios de regressão. Também devem verificar se a integração contínua cobre as combinações compatíveis de GPU, precisão e modelo.

Nenhuma dessas limitações invalida o resultado. Elas definem o que o resultado realmente diz.

Tencent e SGLang apresentaram um benchmark forte e específico para modelo, voltado a um backend upstream em hardware Hopper compatível. Alegações mais amplas exigem reprodução mais ampla.

A resposta certa não é adoção automática nem rejeição. É um teste controlado em comparação com o melhor backend existente, sob os próprios objetivos de nível de serviço da organização.

Três sinais decidirão se Tencent HPC mudará o padrão

A próxima etapa envolve adoção, reprodutibilidade e expansão além de um modelo e uma família de GPUs.

O primeiro sinal é o benchmarking independente do Hy3 dentro do SGLang. Operadores externos devem reproduzir a melhoria de TPOT relatada com comandos publicados e detalhes completos de configuração.

Uma reprodução útil incluiria TPOT mediano e P99, tempo até o primeiro token, throughput de saída, uso de memória e falhas de solicitações. Ela deveria testar tanto cargas de trabalho de comprimentos mistos quanto uniformes.

Uma confirmação próxima da faixa relatada reforçaria a alegação da Tencent de que a otimização combinada dos operadores altera materialmente a latência de decodificação percebida pelo usuário. Ganhos muito menores sugeririam que o resultado máximo depende fortemente de um formato específico de carga de trabalho.

O segundo sinal é o suporte além de Hy3 e H20. O HPC-Ops já publica cobertura de benchmark para DeepSeek-V3, modelos Hunyuan e Qwen3-235B no nível de operador.

A integração no nível do framework é mais difícil. Cada modelo pode diferir no layout de atenção, ordem de normalização, quantização, roteamento de especialistas e execução distribuída.

O suporte a outro modelo MoE amplamente implantado mostraria que o backend oferece infraestrutura reutilizável, em vez de um caminho Hy3 ajustado de forma estreita. O suporte a Blackwell também testaria se o projeto pode se adaptar além de seu alvo Hopper original.

O roadmap do projeto lista quantização mais ampla, hardware futuro, megakernels e comunicação de baixa precisão. Um megakernel combina várias operações consecutivas para reduzir a sobrecarga de lançamento e o tráfego de memória intermediário.

Se esses itens chegarem com integração ao SGLang e benchmarks públicos, Tencent HPC se tornará um concorrente mais amplo entre os backends de inferência. Se o progresso continuar limitado a algumas configurações H20, ele permanecerá valioso, mas especializado.

O terceiro sinal é se os usuários do SGLang selecionam o backend em implantações reais. Estrelas em repositórios e microbenchmarks isolados oferecem evidências limitadas de adoção operacional.

Sinais mais úteis incluem receitas de implantação, documentação do framework, relatórios de bugs de frotas externas, testes de compatibilidade e atividade sustentada de mantenedores. A inclusão em versões estáveis importa mais do que a mera presença no branch principal.

A adoção pressionaria kernels concorrentes a melhorar o agendamento de comprimentos mistos, a precisão de roteadores e a fusão de MoE. Os mantenedores do SGLang então enfrentariam um desafio produtivo: selecionar o backend mais rápido sem criar padrões confusos ou frágeis.

Relatórios de falhas seriam igualmente informativos. Eles revelariam formatos não compatíveis, casos extremos numéricos, atrito de empacotamento ou restrições operacionais ocultas por benchmarks controlados.

Para desenvolvedores, a pergunta imediata é prática. O novo backend reduz a latência para o modelo, a GPU e o padrão de tráfego exatos que eles operam?

Para compradores de infraestrutura, a questão é econômica sem exigir uma comparação pública de preços. Um TPOT menor pode aumentar a capacidade utilizável e melhorar a velocidade de resposta interativa, mas apenas se a confiabilidade e a qualidade da saída permanecerem estáveis.

Para equipes de produto de IA, o efeito pode ir além de um painel de benchmarks. A entrega mais rápida de tokens encurta sessões de programação, loops de agentes, análise de documentos e outros fluxos de trabalho que realizam várias chamadas ao modelo por tarefa.

Tencent HPC conquistou uma avaliação séria porque seus operadores agora fazem parte do caminho upstream do SGLang. A integração remove uma barreira entre um resultado de pesquisa otimizado e um teste em produção.

O número de 48,8% deve iniciar esse teste, não encerrá-lo. Equipes que executam Hy3 em hardware Hopper compatível podem agora comparar o backend com sua configuração atual do SGLang.

Todos os demais devem acompanhar os três sinais: reprodução independente, suporte mais amplo a modelos e hardware e evidências de implantação sustentada. Juntos, eles determinarão se Tencent HPC se tornará uma opção comum de inferência ou permanecerá uma vantagem especializada do Hy3.