AIREITERvLLM Humming è un candidato molto interessante per servire modelli MoE quantizzati con alta concorrenza su hardware di classe Hopper, ma i benchmark pubblici non giustificano l’idea di considerarlo un aggiornamento universale del backend. I test su H100 con group-32 e quelli sul decode a batch 1 su Ampere mostrano perché sia indispensabile verificare il comportamento sul modello, sulla GPU, sul formato e sulla dimensione del batch effettivamente utilizzati.
In breve: Humming è un’accelerazione da verificare caso per caso
Humming è una libreria di kernel GEMM compilati JIT per l’inferenza quantizzata, sviluppata dalla community di vLLM insieme ad Ant Group. Supporta workload dense e mixture-of-experts (MoE), diversi formati di quantizzazione e varie generazioni di GPU NVIDIA. L’annuncio ufficiale parla di accelerazioni dei kernel fino a 5x e di miglioramenti end-to-end del 14%–43% in alcuni workload MoE, ma si tratta di risultati ottenuti con specifiche combinazioni di modello, hardware, formato e concorrenza (annuncio di vLLM).
La mia regola per decidere se adottarlo è semplice:
- Provalo per primo nei workload MoE W4A8/W4A16 con batch elevati o alta concorrenza, su configurazioni Hopper o successive supportate.
- Non dare per scontato il miglioramento nel decode a batch 1, sulle GPU Ampere più datate o con schemi di scaling group-wise poco comuni.
- Mantieni un fallback, perché le issue attuali segnalano problemi di instradamento delle shape e percorsi lenti legati a backend specifici.
Un report indipendente su DeepSeek-V4.1-Flash ha raggiunto 5.856 token di output al secondo con una baseline vLLM ottimizzata, 12.802 con l’attention in data parallel e 17.634 con kernel Humming W4A8 modificati, su un singolo nodo composto da quattro GH200 (report tecnico). Il risultato ha richiesto una correzione del kernel e un intervento di tuning: è quindi una prova del potenziale per una determinata classe di workload, non una promessa valida senza modifiche.
Cosa cambia davvero in una distribuzione vLLM
Humming porta la moltiplicazione di matrici quantizzata in un livello di kernel JIT flessibile, utilizzato nei percorsi GEMM dense e MoE. Il progetto punta alle architetture NVIDIA dalla Turing in poi e a diversi formati low-bit (repository di Humming).
Nel test su Hopper citato, Marlin riconvertiva i pesi FP4 in BF16, mentre Humming portava i pesi FP4 a FP8 direttamente nello SM e usava la moltiplicazione sui tensor core FP8. Questa differenza diventava utile solo quando il workload di decode era realmente limitato dalla capacità di calcolo. Negli altri casi possono prevalere il traffico di memoria, il tiling delle shape, la gestione degli scale factor, l’overhead dei launch e la pressione sui registri.
Dove l’accelerazione si vede e dove invece svanisce
I dati pubblici vanno letti come una mappa dei limiti prestazionali, non come un’unica percentuale da applicare a qualsiasi configurazione.
MoE ad alta concorrenza: il caso più convincente
L’esempio ufficiale con DeepSeek-V4.1-Flash confronta Marlin W4A16 e Humming W4A8 su otto GPU H20 e riporta un throughput MoE end-to-end superiore del 14%–43%, con il miglioramento maggiore ai livelli di concorrenza più elevati. Un utente che ha ripubblicato il benchmark ha indicato il confronto concreto: da 442 a 634 token di output al secondo con concorrenza 64, precisando però che era cambiato anche il formato di quantizzazione (discussione dell’utente).
Il risultato rende Humming una strada molto promettente per il serving, non un semplice moltiplicatore delle prestazioni a parità di formato.
W4A8 group-32 su H100: un campanello d’allarme importante
L’issue #38 di Humming ha testato pesi MXFP4 con attivazioni MXFP8 e scale group-32 su una H100. Tutti i percorsi confrontati erano corretti dal punto di vista numerico, ma nelle shape riportate il percorso fused era molto più lento. Con (4096,3072,4096), Humming fused impiegava 4.969 ms contro gli 0.580 ms della baseline QDQ; con (4096,14336,4096), i tempi erano rispettivamente 22.298 ms e 1.256 ms (issue #38).
In seguito, la stessa issue ha registrato un tuning locale oltre i 500 TFLOPS, mentre un’implementazione sperimentale ha raggiunto circa 580–665 TFLOPS con preprocessing aggiuntivo e una diversa gestione dello storage dei pesi. Granularità degli scale factor, scelta dei tile, pressione sui registri e preprocessing possono quindi ribaltare completamente il risultato.
Decode su SM80 con una singola richiesta: niente conclusioni affrettate su Ampere
L’issue #72 segnala una bassa utilizzazione di INT3 su NVIDIA SM80 nel decode con M=1. Su una CMP 170HX, il kernel Humming misurato ha raggiunto circa 691 GB/s rispetto a una banda HBM di picco di circa 1.591 GB/s: un’utilizzazione del 43,4%. Su una RTX 5070 Ti SM120, un test comparabile ha raggiunto circa 753 GB/s contro gli 827 GB/s di picco, pari a circa il 91% (issue #72).
Lo stesso report cita i risultati del repository su A800: 692,4 GB/s con M=1, appena il 34,0% dei 2.039,04 GB/s di picco dichiarati. Nello stesso confronto, il percorso BF16 puro ha raggiunto 1.232,3 GB/s.
«L’attuale percorso INT3 di Humming su SM80 potrebbe essere subottimale per questo workload?» —
yangfangyunyun, issue #72 di vLLM Humming
Installazione e primo test senza rischi inutili
La documentazione ufficiale indica vLLM 0.29.0 come la versione a partire dalla quale le installazioni CUDA includono Humming come dipendenza. Usa --moe-backend humming per il percorso MoE, --linear-backend humming per i layer lineari supportati oppure la configurazione di quantizzazione Humming documentata per i modelli che la richiedono (documentazione sulla quantizzazione di vLLM). Prima di riutilizzare un flag su un’altra architettura, controlla sempre la documentazione della release e del modello.
Il primo test dovrebbe essere il più controllato possibile:
- Annota versione di vLLM, CUDA e PyTorch, architettura della GPU, quantizzazione del checkpoint e shape del modello.
- Mantieni costanti lunghezza del prompt, lunghezza dell’output, concorrenza e numero di ripetizioni.
- Confronta il backend attuale con Humming usando lo stesso comando di serving e aggiungendo il flag del backend pertinente.
- Misura token di output al secondo, TTFT, latenza tra i token, memoria della GPU e tempo di avvio/warm-up della compilazione JIT.
- Ripeti il test dopo il riscaldamento della cache dei kernel, poi verifica sia il batch 1 sia la concorrenza prevista in produzione.
- Mantieni un fallback automatico o manuale per le shape non supportate e per i casi in cui la selezione del backend fallisce.
Un aumento del throughput da solo non basta se peggiorano TTFT, latenza di coda, costo del warm-up o consumo di memoria. Il progetto perf-eval di vLLM raccomanda ricette YAML, esecuzioni ripetute, aggregazione tramite mediana e lunghezze fisse per input e output, così da ottenere confronti affidabili (repository di perf-eval).
L’instradamento del backend può bloccare una configurazione Humming valida
Un’altra issue di vLLM mostra perché sia importante testare anche il fallback. Nell’issue #60700, un checkpoint MoE W4A8 basato su compressed-tensors aveva una dimensione intermedia pari a 640. CUTLASS richiedeva dimensioni allineate a 256, mentre Humming era in grado di gestire la shape testata; tuttavia, un’asserzione non condizionata veniva eseguita prima del caricamento del backend selezionato. Di conseguenza falliva anche l’uso esplicito di --moe-backend humming.
La patch proposta dal segnalatore limitava l’asserzione a CUTLASS. Dopo la modifica, tutti i 62 shard venivano caricati su due GPU H100 NVL e il test riportava un TTFT inferiore del 12%–50% e un throughput di sistema superiore del 2%–13% rispetto alla configurazione CUTLASS di riferimento (issue #60700). Al momento della verifica, l’issue risultava ancora aperta e la PR #60711 era stata proposta come correzione per l’instradamento.
Un avvio fallito con Humming potrebbe quindi dipendere dai controlli sulle capacità di vLLM, non dal kernel. Prima di abbandonare la configurazione, verifica il backend selezionato, i vincoli sulle shape e lo stato delle correzioni disponibili.
Una tabella decisionale per chi gestisce il serving
| Il tuo workload | Decisione su Humming | Perché |
|---|---|---|
| MoE ad alta concorrenza su Hopper/GH200 | Provalo subito | Un test indipendente ha raggiunto 17.634 tok/s dopo correzioni e tuning. |
| Decode in stile DeepSeek con batch elevati | Candidato molto forte | L’esecuzione sui tensor core FP8 può aiutare quando i GEMM MoE diventano limitati dal calcolo. |
| Decode a batch 1 o ridotto su SM80 | Non dare per scontato il miglioramento | L’issue #72 riporta una banda effettiva del 34%–43% nei percorsi INT3 testati. |
| Scaling delle attivazioni group-32 su H100 | Fai benchmark su un insieme ristretto di shape | L’issue #38 mostra regressioni pesanti in uno dei percorsi fused. |
| Shape MoE W4A8 non allineate a 256 | Controlla versione di vLLM e correzioni sull’instradamento | Asserzioni condivise possono bloccare Humming prima del caricamento dei pesi. |
| Produzione senza budget per modifiche al codice sorgente | Usalo solo dopo un confronto rappresentativo | Alcuni miglioramenti indipendenti hanno richiesto modifiche ai kernel o alle euristiche. |
Domande frequenti
Quali GPU supporta Humming?
Il progetto punta alle GPU NVIDIA dalla generazione Turing in poi e documenta diversi percorsi di quantizzazione. Il supporto non significa che ogni formato e workload siano ottimizzati allo stesso livello: i casi SM80 e gli schemi di scaling meno comuni richiedono benchmark dedicati.
Humming richiede un checkpoint già quantizzato?
Humming è una libreria di kernel per l’inferenza, non un quantizzatore generico. I flussi di lavoro citati usano checkpoint con pesi quantizzati e schemi di attivazione compatibili; prima del serving, verifica quindi il formato del modello nella documentazione e nel repository di vLLM.
Humming è più veloce di qualsiasi altro backend di vLLM?
No. È più veloce in alcuni workload quantizzati, soprattutto nei casi MoE ad alta concorrenza riportati nei benchmark. I risultati cambiano in base ad architettura, formato, dimensioni, raggruppamento degli scale factor e dimensione del batch.
Il compromesso pratico è chiaro: Humming può velocizzare in modo significativo un servizio vLLM quantizzato e ben abbinato, ma un confronto breve e ripetibile fa parte del processo di adozione, perché i risultati pubblici dipendono dalla configurazione.