Hosting di Qwen su Blackwell

I rack NVIDIA GB200 NVL72 con GPU NVIDIA Blackwell interconnesse tramite NVLink a 72 vie sono particolarmente adatti per implementare modelli MoE (mixture-of-experts) di grandi dimensioni. In questo post del blog, descriviamo la configurazione di inferenza che gestisce i modelli Qwen3 235B post-addestrati che supportano una parte del traffico di Perplexity. Mostriamo come abbiamo adattato il nostro motore di inferenza interno per sfruttare i tensor core avanzati e l'interconnessione ad alta velocità delle GPU NVIDIA Blackwell. Con questo hardware, gestiamo più traffico a un costo inferiore senza sacrificare l'accuratezza dei modelli sottostanti.

Implementazione su GB200 NVL72

I rack GB200 NVL72 sono composti da 18 nodi con 2 CPU NVIDIA Grace basate su ARM e 4 GPU basate su Blackwell, ciascuna dotata di 180 GB di HBM. Le 72 GPU sono interconnesse tramite NVLink e 18 ASIC NVLink Switch, fornendo 1800 GB/s di larghezza di banda tra due peer qualsiasi e condividendo una memoria sufficiente per ospitare modelli da trilioni di parametri. Inoltre, gli adattatori ConnectX-7 InfiniBand forniscono ulteriori 400 Gb/s di larghezza di banda sia all'interno dei nodi di un rack che tra i rack adiacenti.

Per gestire il traffico, abbiamo scelto di post-addestrare e servire i modelli Qwen. In questo post del blog, ci concentriamo su Qwen3 235B, ma molte delle tecniche di servizio e caratteristiche prestazionali discusse sono simili a quelle dei più recenti modelli Qwen3.5 397B e 122B a cui stiamo migrando. In termini di parallelismo, l'attenzione lineare è simile alla self-attention completa e l'implementazione esistente del layer MoE può essere facilmente adattata per accogliere i nuovi termini di gate. Per mantenere un tasso di decodifica coerente massimizzando al contempo il throughput, abbiamo scelto di disaggregare il prefill dalla decodifica, implementando diverse strategie di parallelismo per i due tipi di nodi. La comunicazione tra prefiller e decoder è gestita tramite InfiniBand, mentre la larghezza di banda NVLink è riservata alla comunicazione all'interno dei prefiller e dei decoder. Le caratteristiche prestazionali dei dispositivi Blackwell durante l'esecuzione della moltiplicazione di matrici e della comunicazione tra dispositivi, esplorate in questo post del blog, determinano le strategie di sharding utilizzate. Rispetto alle GPU NVIDIA Hopper, osserviamo miglioramenti kernel per kernel grazie al numero maggiore di streaming multiprocessor, all'aumento della larghezza di banda della memoria e a latenze peer-to-peer inferiori.

Espandi

Il nostro TransferEngine, che implementa il prefill disaggregato, ha gestito lo sharding arbitrario ed eventualmente non corrispondente tra prefiller e decoder. Le cache KV sono disposte in memoria nell'ordine HND, con le testine nella dimensione principale e i token mantenuti contigui, per consentire a una cache KV sharded su un prefiller di essere ulteriormente suddivisa o concatenata in-flight durante il trasferimento al nodo decoder.

Prefiller

I nodi prefiller ricevono i token di input di una richiesta, popolando le cache KV e trasferendole ai decoder per continuare la generazione del testo. Il prefill è computazionalmente intensivo, poiché migliaia di token appartenenti a una sequenza vengono elaborati contemporaneamente.

Di conseguenza, abbiamo riscontrato che un'implementazione con parallelismo tensoriale è adatta, con il modello sharded su 4 GPU all'interno di un singolo nodo GB200 e proiezioni ed esperti sharded (TP=4, EP=4). Poiché sia l'attenzione che gli MLP sono limitati dal calcolo, entrambi traggono vantaggio dal parallelismo, distribuendo esperti e teste di attenzione su diversi rank. Un ulteriore parallelismo avrebbe prodotto rendimenti decrescenti, poiché il miglioramento del throughput dovuto all'hosting di un minor numero di esperti su ciascun rank (16 contro 32) non avrebbe compensato il costo aggiuntivo di un all-reduce a 8 vie e il sovraccarico derivante dalla divisione del codice lato host su due nodi, che richiederebbe una comunicazione su Ethernet.

Qwen3 235B ha solo 4 teste key-value, che richiedono che le proiezioni k e v siano replicate su coppie di rank se vengono utilizzati 8 dispositivi. Avremmo potuto considerare uno sharding più aggressivo per ridurre la quantità di memoria necessaria per archiviare i pesi su ciascun rank, liberando Spazio per più token nella cache KV. Tuttavia, abbiamo riscontrato che un'implementazione più ampia non valeva la pena.

Supponendo una lunghezza di input di circa 6000 token, a ciascuno dei 128 esperti vengono indirizzati circa 6000 * 8 / 128 = 375 token, garantendo un problema denso per il GEMM MoE. Poiché ciò satura già il throughput computazionale del dispositivo, il parallelismo dei dati non è necessario per il prefill.

Nonostante il costo quadraticamente crescente dell'attenzione, i prefiller offrono un throughput coerente, consentendo una stima approssimativa del numero di token di input che possono essere elaborati da un nodo in un secondo. Affidandosi a metriche che tracciano il numero totale di token di input dalle richieste, il numero di nodi prefiller può essere aumentato per garantire che il throughput complessivo del prefill sia dimensionato di conseguenza. Per evitare code, il numero di repliche del prefiller viene abbinato al numero totale di token di input ricevuti.

Decoder

I nodi decoder ricevono le cache KV dai prefiller e generano i token uno alla volta. La decodifica è generalmente limitata dalla memoria: con pochi token di input, la moltiplicazione di matrici è interamente limitata dal costo del caricamento dei pesi dalla HBM ai Tensor Core. Oltre a impiegare una diversa strategia di sharding, diversi kernel devono essere modificati per parallelizzare meglio i calcoli e gli accessi alla memoria.

A differenza del prefill, lo sharding dell'attenzione non è più vantaggioso: dividere le teste di attenzione su più dispositivi significherebbe che ci sono meno opportunità di parallelismo all'interno di un singolo dispositivo. Di conseguenza, vengono utilizzati solo il parallelismo dei dati e il parallelismo degli esperti: gli esperti sono sharded su più dispositivi, ma ogni dispositivo gestisce le proprie cache KV e le proprie richieste. Senza parallelismo tensoriale, la dimensione della cache KV per token su un dispositivo è maggiore. Tuttavia, si libera Spazio in memoria posizionando meno esperti su un singolo nodo. A differenza di Hopper, dove abbiamo limitato il parallelismo tensoriale all'interno di un singolo dominio NVLink in un nodo a 8 GPU, su Blackwell abbiamo riscontrato che l'espansione su più nodi all'interno di un dominio, utilizzando fino a 16 dispositivi, è vantaggiosa.

Per massimizzare il throughput, i decoder elaborano un numero maggiore di richieste contemporaneamente. Anche se le richieste aggiuntive comportano un sovraccarico minimo nei layer MoE e in altre proiezioni, aumentano in modo sproporzionato il costo dell'attenzione. Per mantenere una velocità di decodifica minima ragionevole, il numero di nodi decoder viene ridimensionato per mantenere le dimensioni dei batch per decoder al di sotto di una certa soglia.

Analogamente alle precedenti implementazioni su Hopper, utilizziamo la decodifica speculativa con layer MTP addestrati internamente per aumentare i tassi di decodifica. Fortunatamente, l'hardware e i framework di programmazione sottostanti sono abbastanza simili da condividere completamente l'implementazione tra le due architetture.

Comunicazione intra-nodo e inter-nodo

La differenza principale tra GB200 NVL72 e i precedenti nodi Hopper è l'ampio dominio NVLink, che consente la comunicazione peer-to-peer oltre il limite precedente di 8 dispositivi. Anche se i dispositivi Blackwell sono stati implementati in nodi a 8 GPU, c'è molto valore nello scalare su più nodi tramite NVLink rispetto alla rete InfiniBand più lenta.

Sui nodi prefiller, ci affidiamo alla comunicazione all-reduce all'interno dei layer di attenzione e a una riduzione parallela degli esperti che assomiglia molto all'all-reduce. Su 4 GPU, sfruttiamo sia NVLink che NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): oltre alla larghezza di banda peer-to-peer, sfruttiamo anche le riduzioni negli NVLink Switch per ridurre ulteriormente le latenze e implementare broadcast veloci. Sui nodi decoder, viene utilizzata un'implementazione personalizzata di dispatch e combine all-to-all su NVLink. I kernel sono stati implementati internamente utilizzando CuTeDSL e mapping cuMem o mapping multicast.

All-Reduce

I prefiller eseguono un'operazione di all-reduce nella proiezione di output del layer di attenzione, sommando i contributi delle teste sharded sui rank partecipanti. Il parallelismo tensoriale è efficace solo quando il costo del sovraccarico dell'all-reduce è compensato dalla ridotta latenza dei problemi di moltiplicazione di matrici più piccoli. Questa ipotesi solitamente è valida per il prefill.

Sui sistemi NVIDIA HGX H200 e GB200 NVL72 di classe datacenter, le GPU sono solitamente collegate tramite NVLink Switch. Oltre al routing, gli switch possono eseguire operazioni di riduzione tra dispositivi collegati tramite SHARP. Dopo aver creato i mapping di memoria e averli registrati in un gruppo multicast utilizzando le API CUDA, i kernel possono utilizzare multicast.ld_reduce e multicast.st per aggregare e trasmettere valori attraverso gli switch. Per creare una base e componenti riutilizzabili che possono essere fusi in altri kernel, manteniamo internamente un kernel all-reduce CuTeDSL utilizzando queste primitive.

In un sistema con N GPU che riducono B byte, un'implementazione banale avrebbe un peer che carica valori da tutti gli altri peer, per un totale di N * (N - 1) * B byte di traffico di lettura. Un'implementazione più efficiente dividerebbe i dati da ridurre tra i peer, ciascuno dei quali ridurrebbe una fetta dell'input, per poi trasmetterla al resto. Ciò si traduce in (N - 1) * (B / N) byte letti in un peer e trasmessi al resto, per un totale di (N - 1) * B * 2 letture e scritture, riducendo il traffico sugli switch.

Espandi

Con SHARP, la riduzione e il broadcast possono essere eseguiti in modo più efficiente: invece di leggere (N - 1) * (B / N) byte in un dispositivo per l'accumulo locale, solo B / N vengono spostati dallo switch, poiché esegue la riduzione stessa utilizzando i dati dei peer. Per il broadcast, c'è un miglioramento simile, poiché il numero di transazioni tra una GPU e lo switch sui canali NVLink è notevolmente ridotto. Senza SHARP, il dispositivo di accumulo eseguirebbe (N - 1) * (B / N) transazioni su NVLink con lo switch, con lo switch che legge la stessa quantità di dati dai peer, per un totale di 2 * (N - 1) * (B / N) transazioni. Con SHARP, vengono eseguite B / N transazioni tra la GPU e lo switch, e altre (N - 1) * (B / N) con i peer, per un totale di B transazioni.

Grazie alla sua semplicità, SHARP è uno strumento prezioso, in quanto fornisce un'implementazione hardware diretta per un algoritmo. Anche se i trasferimenti sono ridotti di una frazione teorica di N / (2 * (N - 1)) (che equivale al 33% con 4 peer), in pratica osserviamo un miglioramento del 10% sia nelle latenze di prefill che di decodifica sia sui sistemi H200 che GB200 NVL72.

Espandi

MoE Dispatch - Combine

Per i modelli MoE, i kernel di dispatch e combine spostano e raggruppano i token per i successivi problemi GEMM MoE tra peer, eseguendo un accumulo ponderato successivamente in combine. Abbiamo adattato i nostri kernel Dispatch e Combine esistenti a Blackwell, portandoli su CuTeDSL, modificando le allocazioni dei blocchi e specializzandoli in modo aggressivo tra prefill e decodifica.

Expert Parallel

Il kernel expert parallel (EP) viene utilizzato nei prefiller. Poiché i suoi input sono replicati su tutti i rank, il kernel di dispatch deve semplicemente selezionare i token indirizzati agli esperti sul rank corrente. Aggrega le informazioni di routing e prepara i token in buffer utilizzati come input per il GEMM MoE. Il kernel combine esegue prima un accumulo locale tra i contributi dei token indirizzati agli esperti sul rank corrente, quindi esegue un all-reduce su tutti i rank.

Per la decodifica, l'intero kernel è fuso in uno solo. Il kernel di prefill è diviso in più kernel, poiché il routing e l'all-reduce richiedono meno blocchi rispetto al passaggio di combine locale. Con CuTeDSL, potremmo costruire una libreria generica sia per SHARP che per l'all-reduce NVLink e la sincronizzazione peer-to-peer, componendola sia nei kernel all-reduce che in quelli expert parallel.

Espandi

Dal punto di vista delle prestazioni, osserviamo che Blackwell è sostanzialmente più veloce di Hopper, grazie a velocità di trasferimento migliorate, maggiore larghezza di banda della memoria e miglior throughput computazionale. Sharded su 8 dispositivi e più nodi su GB200 (EP=8), i kernel diventano più veloci poiché l'accumulo locale viene eseguito su molti meno token su ciascun dispositivo e, con SHARP, il costo della riduzione su più rank scala meglio. Tuttavia, in pratica, limitiamo il parallelismo a 4 dispositivi, poiché queste accelerazioni non sono universali per tutti i kernel.

Data Parallel e Expert Parallel

Il kernel data parallel e expert parallel (DP-EP) viene utilizzato nei decoder data parallel. Trasmette token diversi da tutti i rank agli esperti, trasferendo i risultati ai rank di origine e accumulandoli. Poiché implementa un problema sparso all-to-all, si basa esclusivamente su NVLink.

Su Hopper, questo kernel è limitato a 8 dispositivi all'interno del dominio NVLink di un singolo nodo. Tuttavia, sui sistemi GB200 possiamo scalarlo su un intero rack. Gran parte del codice viene riutilizzato. L'unica differenza è l'uso di handle fabric per scambiare informazioni sui peer su IMEX per la configurazione iniziale.

Espandi

Poiché le dimensioni del trasferimento subite durante la decodifica sono piccole, sono ben lontane dal saturare la larghezza di banda NVLink e sono invece limitate dalla latenza. Le latenze sono nell'ordine delle decine di microsecondi e rimangono relativamente stabili all'aumentare del numero di peer, consentendoci di diffondere un'implementazione su un numero maggiore di dispositivi senza incorrere in una latenza aggiuntiva significativa.

MoE GEMM

I modelli MoE traggono vantaggio dal parallelismo degli esperti, poiché il costo della moltiplicazione di tutti i token con tutti gli esperti può essere facilmente parallelizzato su più dispositivi. Con il parallelismo tensoriale sui prefiller, sui problemi densi il vantaggio è piuttosto diretto, poiché ogni rank deve ora eseguire meno calcoli. Nel caso della decodifica, il parallelismo dei dati fornisce un ulteriore vantaggio oltre al parallelismo degli esperti, poiché il maggior numero di richieste parallele instrada più token a ciascun esperto, densificando i problemi.

Nella nostra implementazione, ci affidiamo attualmente ai kernel CUTLASS CUDA/C++ per la moltiplicazione di matrici. Li abbiamo confrontati su input di decodifica sparsi con vari schemi di quantizzazione e livelli di parallelismo per decidere la strategia di sharding ottimale per i decoder. Nei benchmark seguenti, tutti gli esperti vengono attivati con un singolo token.

Espandi

Abbiamo riscontrato che scalare 128 esperti su più di 16 rank produce rendimenti decrescenti con CUTLASS, poiché il costo della moltiplicazione di 2 esperti non è sostanzialmente inferiore alla moltiplicazione di 4. C'è un chiaro miglioramento su Blackwell rispetto a Hopper, anche sulla strategia di scaling a blocchi sub-ottimale. Poiché l'aumento della latenza di circa 5 us tra EP=8 ed EP=16 del dispatch/combine è controbilanciato da una diminuzione di oltre 10 us nel costo del GEMM, sui sistemi GB200, lo sharding dei decoder su 16 rank è giustificato, come confermato anche dai benchmark end-to-end.

Quantizzazione

Blackwell introduce il supporto hardware per nuovi schemi di quantizzazione a 8 e 4 bit. A differenza di Hopper, che si basava su fattori di scaling per tensore o per blocco, Blackwell richiede il microscaling per ottenere il miglior throughput di prefill e decodifica. Sebbene lo schema di scaling a blocchi utilizzato per modelli come DeepSeek o Kimi sia disponibile, il microscaling è più efficiente.

Abbiamo implementato Qwen3 235B con lo schema di quantizzazione MXFP8, convertendo i pesi staticamente dopo aver perfezionato il modello. L'impatto sull'accuratezza è stato simile all'impatto dello scaling a blocchi con quantizzazione stocastica, ma le prestazioni fornite sono state molto migliorate, come illustrato dai microbenchmark MoE GEMM. Abbiamo anche preso in considerazione gli schemi di quantizzazione MXFP4 e NVFP4, sebbene l'impatto sull'accuratezza senza Quantization-Aware Training fosse troppo significativo per la transizione iniziale da Hopper a Blackwell. Prevediamo di esplorare questi formati più a fondo nei lavori futuri.

Prestazioni end-to-end

Abbiamo analizzato i decoder delle implementazioni di Blackwell Qwen3 235B e li abbiamo confrontati con le nostre precedenti implementazioni su Hopper. In questa configurazione, abbiamo considerato lo scaling a blocchi su entrambe le implementazioni per concentrarci sull'impatto del parallelismo. I prefiller TP=4 sono stati separati per entrambe le architetture al fine di isolare le prestazioni di decodifica. La figura seguente illustra il throughput di decodifica presupponendo un tasso di accettazione della bozza realistico fornito dai nostri layer MTP.

Espandi

Su Hopper, lo sharding dell'implementazione su più di 8 GPU non è fattibile, poiché le latenze su InfiniBand, in particolare sugli adattatori EFA, sono sostanzialmente più lente. Tuttavia, su Blackwell, otteniamo un throughput sostanzialmente più elevato, grazie ai domini NVLink più ampi.

Abbiamo ottenuto un'implementazione iniziale su Blackwell generalizzando i kernel Hopper esistenti e spingendo le prestazioni dei kernel basati su NVLink. Ridurremo ulteriormente il costo di servizio di Qwen migliorando la quantizzazione e ottimizzando le prestazioni di decodifica e il throughput di prefill degli altri kernel nella pipeline.

Riferimenti

Post del blog Transfer Engine

Post del blog CuTeDSL

Post del blog Prefill-Disagg

Post del blog Speculative Decoding

CUTLASS

NVLink

Citazione

@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}