AIREITERO vLLM Humming é uma opção promissora para servir modelos MoE quantizados com alta concorrência em hardware da classe Hopper, mas os benchmarks públicos não justificam tratá-lo como uma atualização universal de backend. Os resultados em H100 com group-32 e em decodificação batch-1 no Ampere mostram por que é preciso testar o modelo, a GPU, o formato e o tamanho do batch exatos.
Em resumo: o Humming é uma atualização que depende do cenário
O Humming é uma biblioteca de kernels GEMM compilados via JIT para inferência quantizada, lançada pela comunidade do vLLM em parceria com a Ant Group. O projeto atende workloads densos e de mixture-of-experts (MoE) em vários formatos de quantização e gerações de GPUs NVIDIA. O anúncio oficial fala em ganhos de até 5x nos kernels e de 14%–43% no desempenho end-to-end de alguns modelos MoE, mas esses números vêm de combinações específicas de modelo, hardware, formato e concorrência (anúncio do vLLM).
Minha regra para adoção é simples:
- Teste o Humming primeiro em workloads MoE W4A8/W4A16 com batches grandes ou alta concorrência, usando configurações Hopper ou mais recentes compatíveis.
- Não presuma que haverá ganho em decodificação batch-1, GPUs Ampere mais antigas ou escalas group-wise fora do padrão.
- Mantenha um fallback, porque os relatos atuais de issues incluem bugs no roteamento por shape e caminhos lentos específicos do backend.
Um relatório independente sobre o DeepSeek-V4.1-Flash chegou a 5.856 tokens/s de saída com uma configuração baseline ajustada do vLLM, 12.802 com atenção em paralelismo de dados e 17.634 com kernels Humming W4A8 modificados em um único nó com quatro GH200 (relatório de engenharia). O resultado exigiu uma correção no kernel e outro ajuste de tuning. Portanto, ele serve como evidência para uma classe de workloads, não como promessa de desempenho imediato.
O que o Humming muda em uma implantação com vLLM
O Humming transfere a multiplicação de matrizes quantizadas para uma camada flexível de kernels JIT, usada nos caminhos GEMM densos e MoE. O projeto tem como alvo arquiteturas NVIDIA a partir de Turing e vários formatos de baixa precisão (repositório do Humming).
No teste citado com Hopper, o Marlin desquantizou os pesos FP4 para BF16, enquanto o Humming converteu os pesos FP4 para FP8 dentro da SM e usou multiplicação nos tensor cores FP8. Essa diferença só ajudou depois que o workload de decodificação passou a ser limitado por computação. Tráfego de memória, organização dos tiles, tratamento das escalas, overhead de lançamento e pressão sobre os registradores também podem dominar o resultado.
Onde o ganho aparece — e onde ele desaparece
O melhor jeito de interpretar as evidências públicas é como um mapa dos limites de desempenho, não como um único percentual chamativo.
MoE com alta concorrência: o ganho mais consistente
O exemplo oficial com o DeepSeek-V4.1-Flash compara Marlin W4A16 com Humming W4A8 em oito GPUs H20 e reporta throughput MoE end-to-end 14%–43% maior, com o ganho mais expressivo nos níveis altos de concorrência. Um usuário que republicou o benchmark apresentou a comparação concreta: 442 contra 634 tokens/s de saída em concorrência 64, observando também que o formato de quantização havia mudado (discussão do usuário).
O resultado coloca o Humming como uma rota promissora para serving, mas não como um multiplicador de desempenho de kernel em condições estritamente equivalentes.
W4A8 com group-32 em H100: um alerta importante
A issue #38 do Humming testou pesos MXFP4 com ativações MXFP8 e escalas group-32 em uma H100. Todos os caminhos comparados produziram resultados numericamente corretos, mas o caminho fused foi muito mais lento nas shapes reportadas. Em (4096,3072,4096), o Humming fused levou 4.969 ms, contra 0.580 ms do baseline QDQ; em (4096,14336,4096), foram 22.298 ms contra 1.256 ms (issue #38).
Mais tarde, a issue registrou tuning local acima de 500 TFLOPS, enquanto uma implementação experimental chegou a aproximadamente 580–665 TFLOPS com pré-processamento adicional e outro esquema de armazenamento dos pesos. Granularidade das escalas, escolha dos tiles, pressão sobre os registradores e pré-processamento podem, portanto, mudar completamente o resultado.
Decodificação com uma requisição em SM80: não extrapole ganhos para Ampere
A issue #72 relata baixa utilização de INT3 em NVIDIA SM80 durante decodificação com M=1. Em uma CMP 170HX, o kernel Humming medido chegou a cerca de 691 GB/s, contra aproximadamente 1.591 GB/s do pico de largura de banda HBM — utilização de 43,4%. Em uma execução comparável na RTX 5070 Ti SM120, o resultado foi de cerca de 753 GB/s, contra 827 GB/s de pico, ou aproximadamente 91% de utilização (issue #72).
O mesmo relatório cita resultados do repositório em uma A800 de 692,4 GB/s com M=1, apenas 34,0% dos 2.039,04 GB/s de pico informados. Na mesma comparação, o BF16 simples chegou a 1.232,3 GB/s.
“O caminho INT3 atual do Humming em SM80 pode estar abaixo do ideal para esse workload?” —
yangfangyunyun, issue #72 do vLLM Humming
Instalação e o primeiro teste mais seguro
Os materiais oficiais identificam o vLLM 0.29.0 como a versão a partir da qual as instalações CUDA incluem o Humming como dependência. Use --moe-backend humming para o caminho MoE, --linear-backend humming para as camadas lineares compatíveis ou a configuração de quantização do Humming documentada para uma rota específica do modelo (documentação de quantização do vLLM). Consulte a documentação da versão e do modelo antes de copiar uma flag entre arquiteturas.
Comece com um teste controlado:
- Registre as versões do vLLM, CUDA e PyTorch, a arquitetura da GPU, a quantização do checkpoint e a shape do modelo.
- Mantenha constantes o tamanho do prompt, o tamanho da saída, a concorrência e o número de repetições.
- Compare o backend atual com o Humming usando o mesmo comando de serving, acrescentando a flag de backend relevante.
- Meça tokens/s de saída, TTFT, latência entre tokens, memória da GPU e o tempo de inicialização/aquecimento do JIT.
- Repita o teste depois que o cache dos kernels estiver aquecido e, em seguida, avalie batch 1 e a concorrência de produção.
- Mantenha um fallback automático ou manual para shapes não compatíveis e casos em que a seleção falhar.
Ganhar throughput não basta se houver regressão em TTFT, latência de cauda, custo de aquecimento ou uso de memória. O projeto perf-eval do vLLM recomenda receitas em YAML, execuções repetidas, agregação pela mediana e tamanhos fixos de entrada e saída para testes comparáveis (repositório do perf-eval).
O roteamento do backend pode impedir uma configuração válida do Humming
Uma issue separada do vLLM mostra por que testar o fallback é importante. Na issue #60700, um checkpoint MoE W4A8 do compressed-tensors tinha dimensão intermediária de 640. O CUTLASS exigia dimensões alinhadas a 256, enquanto o Humming conseguia lidar com a shape testada, mas uma asserção incondicional era executada antes do carregamento do backend selecionado. Por isso, até o uso explícito de --moe-backend humming falhava.
O patch do autor da issue restringiu a asserção ao CUTLASS. Depois da mudança, todos os 62 shards foram carregados em duas GPUs H100 NVL, e o teste registrou TTFT 12%–50% menor e throughput do sistema 2%–13% maior que sua configuração de referência com CUTLASS (issue #60700). A issue ainda estava aberta no momento da consulta, com a PR #60711 proposta como correção do roteamento.
Portanto, uma inicialização malsucedida do Humming pode ser um problema na verificação de capacidades do vLLM, e não no kernel. Antes de descartar a configuração, verifique o backend selecionado, as restrições de shape e o status da correção.
Uma tabela de decisão para operadores
| Seu workload | Decisão sobre o Humming | Motivo |
|---|---|---|
| MoE com alta concorrência em Hopper/GH200 | Teste cedo | Um trabalho independente de serving chegou a 17.634 tok/s depois de correções e tuning. |
| Decodificação no estilo DeepSeek com batches grandes | Forte candidato | A execução em tensor cores FP8 pode ajudar quando os GEMMs MoE passam a ser limitados por computação. |
| Decodificação batch-1 ou com batch baixo em SM80 | Não presuma ganho | A issue #72 relata 34%–43% de largura de banda efetiva nos caminhos INT3 testados. |
| Escalonamento de ativações group-32 em H100 | Faça benchmark com uma matriz restrita de shapes | A issue #38 mostra regressões severas em um caminho fused. |
| Shapes MoE W4A8 não alinhadas a 256 | Confira a versão do vLLM e as correções de roteamento | Asserções compartilhadas podem impedir o Humming de carregar os pesos. |
| Produção sem orçamento para alterar o código-fonte | Use apenas depois de um bake-off representativo | Alguns ganhos independentes exigiram mudanças no kernel ou nas heurísticas. |
Perguntas frequentes
Quais GPUs são compatíveis com o Humming?
O projeto tem como alvo GPUs NVIDIA a partir de Turing e documenta vários caminhos de quantização. Compatibilidade não significa que todos os formatos e workloads tenham recebido o mesmo nível de otimização; casos em SM80 e configurações de escala incomuns precisam de benchmarks próprios.
O Humming exige um checkpoint já quantizado?
O Humming é uma biblioteca de kernels de inferência, não um quantizador de uso geral. Os fluxos de trabalho citados usam checkpoints com pesos quantizados e esquemas de ativação compatíveis. Por isso, confirme o formato do modelo na documentação e no repositório do vLLM antes de colocá-lo em serving.
O Humming é mais rápido que todos os outros backends do vLLM?
Não. Ele é mais rápido em workloads quantizados específicos, especialmente nos casos de MoE com alta concorrência apresentados nos relatórios. Os resultados variam conforme a arquitetura, o formato, as dimensões, o agrupamento das escalas e o tamanho do batch.
A troca prática é clara: o Humming pode acelerar bastante um serviço vLLM quantizado e bem alinhado ao seu perfil, mas um bake-off curto e repetível faz parte da adoção, já que os resultados públicos dependem da configuração.