Găzduirea Qwen pe Blackwell

Rack-urile NVIDIA GB200 NVL72 cu GPU-uri NVIDIA Blackwell interconectate prin NVLink pe 72 de căi sunt potrivite în mod unic pentru implementarea modelelor mari de tip mixture-of-experts (MoE). În această postare pe blog, descriem configurația de inferență care deservește modelele Qwen3 235B post-antrenate, care asigură o parte din traficul Perplexity. Arătăm cum am adaptat motorul nostru intern de inferență pentru a valorifica nucleele tensoriale avansate și interconexiunea de mare viteză ale GPU-urilor NVIDIA Blackwell. Cu acest hardware, gestionăm mai mult trafic la un cost mai redus, fără a sacrifica precizia modelelor subiacente.

Rack-urile GB200 NVL72 sunt compuse din 18 noduri cu 2 CPU-uri NVIDIA Grace bazate pe ARM și 4 GPU-uri bazate pe Blackwell, fiecare echipat cu 180 GB de HBM. Cele 72 de GPU-uri sunt interconectate prin NVLink și 18 ASIC-uri NVLink Switch, oferind o lățime de bandă de 1800 GB/s între orice doi peers și partajând suficientă memorie pentru a găzdui modele cu mii de miliarde de parametri. În plus, adaptoarele ConnectX-7 InfiniBand oferă o lățime de bandă suplimentară de 400 Gb/s atât în cadrul nodurilor unui rack, cât și între rack-urile învecinate.

Pentru a gestiona traficul, am optat pentru post-antrenarea și servirea modelelor Qwen. În această postare pe blog, ne concentrăm pe Qwen3 235B, dar multe dintre tehnicile de servire discutate și caracteristicile de performanță sunt similare cu cele ale noilor modele Qwen3.5 397B și 122B spre care migrăm. În ceea ce privește paralelismul, atenția liniară este similară cu auto-atenția completă, iar implementarea existentă a stratului MoE poate fi adaptată cu ușurință pentru a acomoda noii termeni de poartă. Pentru a menține o rată de decodare consistentă și a maximiza debitul, am ales să dezagregăm faza de prefill de cea de decodare, implementând strategii de paralelism diferite pentru cele două tipuri de noduri. Comunicarea dintre prefiller și decodor este gestionată prin InfiniBand, în timp ce lățimea de bandă NVLink este rezervată comunicării în cadrul prefillerelor și decodoarelor. Caracteristicile de performanță ale dispozitivelor Blackwell atunci când efectuează înmulțirea de matrice și comunicarea între dispozitive, explorate în această postare pe blog, determină strategiile de sharding utilizate. Comparativ cu GPU-urile NVIDIA Hopper, observăm îmbunătățiri de la un kernel la altul datorită numărului mai mare de multiprocesoare de streaming, lățimii de bandă crescute a memoriei și latențelor peer-to-peer mai mici.

Prefill și decodare dezagregate, cu InfiniBand între componentele de prefill și decodare și NVLink în cadrul fiecărei implementări.

TransferEngine, care implementează prefill-ul dezagregat, a gestionat un sharding arbitrar și posibil nealiniat între prefillere și decodoare. Cache-urile KV sunt dispuse în memorie în ordine HND, cu head-urile în dimensiunea principală și tokenurile menținute contigue, pentru a permite ca un cache KV partajat pe un prefiller să fie divizat în continuare sau concatenat în timpul transferului către nodul decodor.

Nodurile prefiller primesc tokenurile de intrare ale unei cereri, populând cache-urile KV și transferându-le către decodoare pentru a continua generarea textului. Prefill-ul este intensiv din punct de vedere computațional, deoarece mii de tokenuri aparținând unei secvențe sunt procesate în același timp.

În consecință, am constatat că o implementare paralelă pe tensoare este adecvată, cu modelul partajat pe 4 GPU-uri în cadrul unui singur nod GB200, iar proiecțiile și experții partajați (TP=4, EP=4). Deoarece atât atenția, cât și MLP-urile sunt limitate de calcul (compute-bound), ambele beneficiază de paralelism, distribuind experții și head-urile de atenție pe rank-uri separate. Un paralelism suplimentar ar fi adus randamente descrescătoare, deoarece îmbunătățirea debitului prin găzduirea a mai puțini experți pe fiecare rank (16 față de 32) nu ar fi compensat costul suplimentar al unei operațiuni all-reduce cu 8 căi și overhead-ul de a împărți codul de pe partea gazdei pe două noduri, necesitând comunicare prin Ethernet.

Qwen3 235B are doar 4 head-uri key-value, ceea ce impune ca proiecțiile k și v să fie replicate între perechi de rank-uri dacă se folosesc 8 dispozitive. Am fi putut lua în considerare o partiționare mai agresivă pentru a reduce cantitatea de memorie necesară pentru stocarea greutăților pe fiecare rank, eliberând spațiu pentru mai multe tokenuri în cache-ul KV. Totuși, am constatat că o implementare mai amplă nu ar merita.

Presupunând o lungime de intrare de aproximativ 6000 de tokenuri, fiecare dintre cei 128 de experți are aproximativ 6000 * 8 / 128 = 375 de tokenuri rutiate către acesta, asigurând o problemă densă pentru MoE GEMM. Deoarece acest lucru saturează deja debitul computațional al dispozitivului, paralelismul de date nu este necesar pentru prefill.

În ciuda costului în creștere pătratică al atenției, prefillerele oferă un debit constant, permițând o estimare aproximativă a numărului de tokenuri de intrare care pot fi procesate de un nod într-o secundă. Bazându-se pe metrici care urmăresc numărul total de tokenuri de intrare din cereri, numărul de noduri prefiller poate fi scalat pentru a se asigura că debitul general de prefill este dimensionat în mod corespunzător. Pentru a evita cozile, numărul de replici prefiller este corelat cu numărul total de tokenuri de intrare primite.

Nodurile decodor primesc cache-urile KV de la prefillere și generează tokenuri unul câte unul. Decodarea este, în general, limitată de memorie (memory bound): cu puține tokenuri de intrare, înmulțirea de matrice este determinată în întregime de costul încărcării ponderilor din HBM în Tensor Cores. Pe lângă utilizarea unei strategii de sharding diferite, mai multe kerneluri trebuie ajustate pentru a paraleliza mai bine calculele și accesul la memorie.

Spre deosebire de prefill, partiționarea atenției nu mai este benefică: împărțirea head-urilor de atenție între mai multe dispozitive ar însemna mai puține oportunități de paralelism în cadrul unui singur dispozitiv. În consecință, se folosesc doar paralelismul de date și paralelismul experților: experții sunt partiționați între mai multe dispozitive, dar fiecare dispozitiv își gestionează propriile cache-uri KV și propriile cereri. Fără paralelism pe tensori, dimensiunea cache-ului KV per token pe un dispozitiv este mai mare. Totuși, spațiul din memorie este eliberat prin plasarea unui număr mai mic de experți pe un singur nod. Spre deosebire de Hopper, unde am limitat paralelismul pe tensori în cadrul unui singur domeniu NVLink într-un nod cu 8 GPU-uri, pe Blackwell am constatat că extinderea pe mai multe noduri în cadrul unui domeniu, folosind până la 16 dispozitive, este avantajoasă.

Pentru a maximiza debitul, decodoarele procesează un număr mai mare de cereri în mod concurent. Chiar dacă cererile suplimentare generează un overhead minim în straturile MoE și în alte proiecții, ele cresc disproporționat costul atenției. Pentru a menține o viteză minimă rezonabilă de decodare, numărul de noduri decodor este scalat pentru a menține dimensiunile loturilor per decodor sub un anumit prag.

În mod similar implementărilor anterioare Hopper, utilizăm decodarea speculative cu straturi MTP antrenate intern pentru a spori ratele de decodare. Din fericire, hardware-ul subiacent și cadrele de programare sunt suficient de similare pentru a partaja pe deplin implementarea între cele două arhitecturi.

Principalul diferențiator între GB200 NVL72 și nodurile Hopper anterioare este domeniul NVLink mare, care permite comunicarea peer-to-peer dincolo de limita anterioară de 8 dispozitive. Chiar dacă dispozitivele Blackwell au fost implementate în noduri cu 8 GPU-uri, există o valoare considerabilă în scalarea pe mai multe noduri prin NVLink, comparativ cu rețeaua InfiniBand mai lentă.

Pe nodurile prefiller, ne bazăm pe comunicarea all-reduce în cadrul straturilor de atenție și pe o reducere paralelă a experților care seamănă îndeaproape cu all-reduce. Pe 4 GPU-uri, valorificăm atât NVLink, cât și NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): pe lângă lățimea de bandă peer-to-peer, exploatăm și reducerile din NVLink Switches pentru a reduce și mai mult latențele și a implementa broadcast-uri rapide. Pe nodurile decodor, se folosește o implementare personalizată de tip all-to-all dispatch și combine prin NVLink. Kernelurile au fost implementate intern folosind mapări CuTeDSL și cuMem sau mapări multicast.

Prefillerele efectuează o operațiune all-reduce în proiecția de ieșire a stratului de atenție, însumând contribuțiile head-urilor partajate pe rank-urile participante. Paralelismul pe tensoare este eficient numai atunci când costul overhead-ului all-reduce este compensat de latența redusă a problemelor mai mici de înmulțire de matrice. Această presupunere este valabilă de obicei pentru prefill.

Pe sistemele NVIDIA HGX H200 și GB200 NVL72 de clasă pentru centre de date, GPU-urile sunt de obicei conectate prin NVLink Switches. Pe lângă rutare, comutatoarele pot efectua operațiuni de reducere între dispozitivele conectate prin intermediul SHARP. După crearea mapărilor de memorie și înregistrarea acestora într-un grup multicast utilizând API-urile CUDA, kernelurile pot folosi multicast.ld_reduce și multicast.st pentru a agrega și difuza valori prin intermediul comutatoarelor. Pentru a crea o fundație și componente reutilizabile care pot fi fuzionate în alte kerneluri, menținem intern un kernel CuTeDSL all-reduce folosind aceste primitive.

Într-un sistem cu N GPU-uri care reduc B octeți, o implementare trivială ar determina un peer să încarce valori de la toți ceilalți peers, pentru un total de N * (N - 1) * B octeți de trafic de citire. O implementare mai eficientă ar împărți datele de redus între peers, fiecare reducând o porțiune din intrare, apoi difuzând-o către restul. Aceasta are ca rezultat (N - 1) * (B / N) octeți citiți de un peer și difuzați către restul, pentru un total de (N - 1) * B * 2 citiri și scrieri, reducând traficul prin comutatoare.

Trafic NVSwitch all-reduce cu acumulare pe partea GPU și reducere asistată de switch.

Cu SHARP, reducerea și broadcast-ul pot fi efectuate mai eficient: în loc să citească (N - 1) * (B / N) octeți într-un dispozitiv pentru acumulare locală, doar B / N sunt mutați din comutator, deoarece acesta efectuează chiar reducerea folosind datele de la peers. Pentru broadcast, există o îmbunătățire similară, deoarece numărul de tranzacții dintre un GPU și comutator prin canalele NVLink este redus considerabil. Fără SHARP, dispozitivul care acumulează ar efectua (N - 1) * (B / N) tranzacții prin NVLink cu comutatorul, comutatorul citind aceeași cantitate de date de la peers, pentru un total de 2 * (N - 1) * (B / N) tranzacții. Cu SHARP, sunt efectuate B / N tranzacții între GPU și comutator și încă (N - 1) * (B / N) cu peers, pentru un total de B tranzacții.

Datorită simplității sale, SHARP este un instrument valoros, deoarece oferă o implementare hardware directă pentru un algoritm. Chiar dacă transferurile sunt reduse cu o fracțiune teoretică N / (2 * (N - 1)) (ceea ce înseamnă 33% cu 4 peers), în practică observăm o îmbunătățire de 10% atât a latențelor de prefill, cât și a celor de decodare pe sistemele H200 și GB200 NVL72.

Latența de dispatch NVLink și NVLS pe H200 și GB200 la TP=4 cu 16K tokenuri.

Pentru modelele MoE, kernelurile de trimitere (dispatch) și combinare (combine) mută și grupează tokenuri pentru problemele MoE GEMM subsecvente între peers, efectuând ulterior o acumulare ponderată în combine. Am adaptat kernelurile noastre existente Dispatch și Combine la Blackwell, portându-le la CuTeDSL, ajustând alocările de blocuri și specializându-le în mod agresiv între prefill și decodare.

Kernelul de paralelism pe experți (EP) este utilizat în prefillere. Deoarece intrările sale sunt replicate pe toate rank-urile, kernelul de dispatch trebuie pur și simplu să selecteze tokenurile rutiate către experții de pe rank-ul curent. El agregă informațiile de rutare și pregătește tokenurile în buffere utilizate ca intrări pentru MoE GEMM. Kernelul combine efectuează mai întâi o acumulare locală între contribuțiile tokenurilor rutiate către experții de pe rank-ul curent, apoi efectuează un all-reduce pe toate rank-urile.

Pentru decodare, întregul kernel este fuzionat într-unul singur. Kernelul de prefill este împărțit în mai multe kerneluri, deoarece rutarea și all-reduce necesită mai puține blocuri decât pasul de combinare locală. Cu CuTeDSL, am putut construi o bibliotecă generică atât pentru SHARP, cât și pentru NVLink all-reduce și sincronizarea peer-to-peer, compunând-o atât în kernelurile all-reduce, cât și în cele de paralelism pe experți.

Latența de dispatch și combinare a prefill-ului paralel pe experți pe H200 și GB200 în configurații paralele pe experți.

Din punct de vedere al performanței, observăm că Blackwell este substanțial mai rapid decât Hopper, datorită vitezelor de transfer îmbunătățite, a lățimii de bandă mai mari a memoriei și a unui debit computațional superior. Partajat pe 8 dispozitive și pe mai multe noduri pe GB200 (EP=8), kernelurile devin mai rapide pe măsură ce acumularea locală rulează pe mult mai puține tokenuri pe fiecare dispozitiv și, cu SHARP, costul reducerii pe mai multe rank-uri scalează mai bine. Cu toate acestea, în practică, limităm paralelismul la 4 dispozitive, deoarece aceste accelerări nu sunt universale pentru toate kernelurile.

Kernelul de paralelism de date și de paralelism pe experți (DP-EP) este utilizat în decodoarele paralele de date. El difuzează diferite tokenuri de la toate rank-urile către experți, transferând rezultatele către rank-urile de origine și acumulându-le. Deoarece implementează o problemă complexă de tip all-to-all rară, se bazează exclusiv pe NVLink.

Pe Hopper, acest kernel este limitat la 8 dispozitive în cadrul domeniului NVLink al unui singur nod. Cu toate acestea, pe sistemele GB200 îl putem scala pe un întreg rack. Cea mai mare parte a codului este reutilizată. Singura diferență este utilizarea manetelor fabric pentru a schimba informații peer prin IMEX pentru configurarea inițială.

Latența de dispatch și combinare pe GB200 în configurații paralele pe date și paralele pe experți.

Deoarece dimensiunile transferurilor generate în timpul decodarii sunt mici, ele sunt departe de a satura lățimea de bandă NVLink și sunt în schimb limitate de latență. Latențele sunt de ordinul zecilor de microsecunde și rămân relativ stabile pe măsură ce numărul de peers crește, permițându-ne să extindem o implementare pe un număr mai mare de dispozitive fără a genera o latență suplimentară semnificativă.

Modelele MoE beneficiază de paralelismul pe experți, deoarece costul înmulțirii tuturor tokenurilor cu toți experții poate fi paralelizat cu ușurință pe mai multe dispozitive. Cu paralelismul pe tensoare pe prefillere, în problemele dense beneficiul este destul de direct, deoarece fiecare rank trebuie acum să efectueze mai puține calcule. În cazul decodării, paralelismul de date oferă un beneficiu suplimentar pe lângă paralelismul pe experți, deoarece numărul mai mare de cereri paralele rutează mai multe tokenuri către fiecare expert, densificând problemele.

În implementarea noastră, ne bazăm în prezent pe kerneluri CUTLASS CUDA/C++ pentru înmulțirea de matrice. Le-am evaluat prin benchmark-uri pe intrări de decodare rare cu diverse scheme de cuantificare și niveluri de paralelism pentru a decide strategia optimă de sharding pentru decodoare. În benchmark-urile de mai jos, toți experții sunt activați cu un singur token.

Latența GEMM MoE grupat în configurații paralele pe experți și scheme de cuantizare pe H200 și GB200.

Am constatat că scalarea a 128 de experți pe mai mult de 16 rank-uri aduce randamente descrescătoare cu CUTLASS, deoarece costul înmulțirii a 2 experți nu este substanțial mai mic decât cel al înmulțirii a 4. Există o îmbunătățire clară pe Blackwell față de Hopper, chiar și pe strategia suboptimă de scalare pe blocuri. Deoarece creșterea latenței de aproximativ 5 us între EP=8 și EP=16 pentru dispatch/combine este compensată de o scădere de peste 10 us a costului GEMM, pe sistemele GB200, sharding-ul decodoarelor pe 16 rank-uri este justificat, așa cum este confirmat și de benchmark-urile end-to-end.

Blackwell introduce suport hardware pentru noile scheme de cuantificare pe 8 biți și 4 biți. Spre deosebire de Hopper, care se baza pe factori de scalare per-tensor sau per-bloc, Blackwell necesită microscalare pentru a obține cel mai bun debit de prefill și decodare. În timp ce schema de scalare pe blocuri utilizată pentru modele precum DeepSeek sau Kimi este disponibilă, microscalarea este mai eficientă.

Am implementat Qwen3 235B cu schema de cuantificare MXFP8, convertind ponderile în mod static după fine-tuning-ul modelului. Impactul asupra preciziei a fost similar cu cel al scalării pe blocuri cu cuantificare stohastică, dar performanța oferită a fost mult îmbunătățită, așa cum ilustrează microbenchmark-urile MoE GEMM. De asemenea, am luat în considerare schemele de cuantificare MXFP4 și NVFP4, deși impactul asupra preciziei fără Quantization-Aware Training a fost prea semnificativ pentru tranziția inițială de la Hopper la Blackwell. Planificăm să explorăm aceste formate mai amănunțit în lucrări viitoare.

Am evaluat prin benchmark decodoarele implementărilor Blackwell Qwen3 235B și le-am comparat cu implementările noastre anterioare Hopper. În această configurație, am luat în considerare scalarea pe blocuri pentru ambele implementări pentru a ne concentra asupra impactului paralelismului. Prefillerele TP=4 au fost separate pentru ambele arhitecturi pentru a izola performanța de decodare. Figura de mai jos ilustrează debitul de decodare presupunând o rată de acceptare a ciornelor (draft) realistă oferită de straturile noastre MTP.

Viteza de decodare și throughput-ul per GPU pentru Qwen3 235B FP8 în configurații paralele pe experți pe H200 și GB200, presupunând o lungime de acceptare a draftului de 0.8.

Pe Hopper, sharding-ul implementării pe mai mult de 8 GPU-uri nu este viabil, deoarece latențele prin InfiniBand, în special pe adaptoarele EFA, sunt substanțial mai lente. Cu toate acestea, pe Blackwell, obținem un debit substanțial mai mare, datorită domeniilor NVLink mai mari.

Am obținut o implementare inițială pe Blackwell prin generalizarea kernelurilor Hopper existente și îmbunătățirea performanței kernelurilor bazate pe NVLink. Vom reduce în continuare costul de servire a Qwen prin îmbunătățirea cuantificării și prin optimizarea performanței de decodare și a debitului de prefill ale celorlalte kerneluri din conductă.

Postare pe blog despre Transfer Engine

Postare pe blog despre CuTeDSL

Postare pe blog despre Prefill-Disagg

Postare pe blog despre decodarea speculative

CUTLASS

NVLink

BibTeX

@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}
}

Implementarea pe GB200 NVL72

Prefillere

Decodoare

Comunicare intra-nod și inter-nod

All-Reduce

MoE Dispatch - Combine

Paralelism pe experți

Paralelism de date și paralelism pe experți

MoE GEMM

Cuantificare

Performanță End-to-End

Referințe

Citare