Hostovanje Qwen-a na Blackwell-u

Racks NVIDIA GB200 NVL72 sa NVIDIA Blackwell GPU-ovima, međusobno povezani 72-smjernim NVLink-om, jedinstveno su pogodni za implementaciju velikih modela mješavine eksperata (MoE). U ovom blog postu opisujemo inference podešavanje koje opslužuje post-trenirane Qwen3 235B modele koji podržavaju dio saobraćaja kompanije Perplexity. Pokazujemo kako smo prilagodili naš interni inference motor da iskoristi napredna tensor jezgra i brzu međusobnu vezu NVIDIA Blackwell GPU-ova. Sa ovim hardverom obrađujemo veći saobraćaj uz niže troškove, bez žrtvovanja tačnosti osnovnih modela.

Primjena na GB200 NVL72

GB200 NVL72 reckovi se sastoje od 18 čvorova sa 2 NVIDIA Grace CPU-a zasnovana na ARM-u i 4 GPU-a zasnovana na Blackwell-u, od kojih je svaki opremljen sa 180 GB HBM-a. 72 GPU-a su međusobno povezana preko NVLink-a i 18 NVLink Switch ASIC-ova, isporučujući propusni opseg od 1800 GB/s između bilo koja dva para i dijeleći dovoljan memorijski prostor za hostovanje modela sa bilionima parametara. Pored toga, ConnectX-7 InfiniBand adapteri obezbjeđuju dodatni propusni opseg od 400 Gb/s kako unutar čvorova recka tako i preko susjednih reckova.

Da bismo upravljali saobraćajem, odlučili smo da naknadno obučimo i opslužujemo Qwen modele. U ovom blog postu se fokusiramo na Qwen3 235B, ali mnoge od razmatranih tehnika opsluživanja i karakteristika performansi slične su onima kod novijih Qwen3.5 397B i 122B modela na koje prelazimo. U pogledu paralelizma, linearna pažnja je slična potpunoj samostalnoj pažnji, a postojeća implementacija MoE sloja može se lako prilagoditi da primi nove uslove gejtovanja. Da bismo održali dosljednu stopu dekodiranja uz maksimalno povećanje protoka, izabrali smo da razdvojimo preflešovanje od dekodiranja, primjenjujući različite strategije paralelizma za ove dvije vrste čvorova. Komunikacija između preflešera i dekodera obavlja se preko InfiniBand-a, dok je NVLink propusni opseg rezervisan za komunikaciju unutar preflešera i dekodera. Karakteristike performansi Blackwell uređaja pri izvođenju množenja matrica i komunikacije između uređaja, koje su istražene u ovom blog postu, određuju korišćene strategije dijeljenja. U poređenju sa NVIDIA Hopper GPU-ovima, vidimo poboljšanja jezgro po jezgro zbog većeg broja striming multiprocesora, povećanog memorijskog propusnog opsega i nižih latencija od uređaja do uređaja.

Увећај

Naš TransferEngine, koji implementira razdvojeni prefleš, rukovao je proizvoljnim i potencijalno nepodudarnim dijeljenjem preko preflešera i dekodera. KV keševi su raspoređeni u memoriji HND redoslijedom, sa glavama u vodećoj dimenziji i tokenima koji se čuvaju susjednim, kako bi se omogućilo da se podijeljeni KV keš na preflešeru dodatno razdvoji ili spoji u toku prenosa do čvora dekodera.

Preflešeri

Čvorovi preflešera primaju ulazne tokove zahtjeva, popunjavajući KV keševe i prenoseći ih na dekodere radi nastavka generisanja teksta. Preflešovanje je računski intenzivno, pošto se hiljade tokena koji pripadaju sekvenci obrađuju u isto vrijeme.

Posljedično, otkrili smo da je primjena paralelna po tenzorima prikladna, pri čemu je model podijeljen na 4 GPU-a unutar jednog GB200 čvora, a projekcije i stručnjaci su podijeljeni (TP=4, EP=4). Pošto su i pažnja i MLP-ovi ograničeni računskim resursima, oboje imaju koristi od paralelizma, raspoređujući stručnjake i glave pažnje preko odvojenih rangova. Dalji paralelizam bi dao sve manji povraćaj, pošto poboljšanje protoka od hostovanja manjeg broja stručnjaka na svakom rangu (16 naspram 32) ne bi nadoknadilo dodatnu cijenu 8-smjernog all-reduce-a i režijske troškove dijeljenja koda na strani hosta na dva čvora, što zahtijeva komunikaciju preko Etherneta.

Qwen3 235B ima samo 4 ključ-vrijednost glave, što zahtijeva da se k i v projekcije replikuju preko parova rangova ako se koristi 8 uređaja. Možemo razmotriti agresivnije dijeljenje da bismo smanjili količinu memorije potrebne za skladištenje težina na svakom rangu, oslobađajući memorijski prostor za više tokena u KV kešu. Međutim, otkrili smo da šira primjena nije isplativa.

Pod pretpostavkom da je ulazna dužina oko 6000 tokena, svaki od 128 stručnjaka ima oko 6000 * 8 / 128 = 375 tokena usmjerenih na njega, čime se obezbjeđuje gust problem za MoE GEMM. Pošto ovo već zasićuje računski protok uređaja, paralelizam podataka nije potreban za prefleš.

Uprkos kvadratno rastućoj cijeni pažnje, preflešeri isporučuju dosljedan protok, omogućavajući grubu procjenu broja ulaznih tokena koje čvor može obraditi u jednoj sekundi. Oslanjajući se na metrike koje prate ukupan broj ulaznih tokena iz zahtjeva, broj čvorova preflešera može se skalirati kako bi se osiguralo da je ukupni protok preflešovanja srazmjerno dimenzionisan. Da bi se izbjeglo čekanje u redu, broj replika preflešera usklađen je sa ukupnim brojem primljenih ulaznih tokena.

Dekoderi

Čvorovi dekodera primaju KV keševe od preflešera i generišu tokove jedan po jedan. Dekodiranje je uglavnom ograničeno memorijom: sa malo ulaznih tokena, množenje matrica je u potpunosti ograničeno cijenom učitavanja težina iz HBM-a u tenzorska jezgra. Osim primjene drugačije strategije dijeljenja, nekoliko kernela mora biti podešeno kako bi se bolje paralelizovali izračuni i pristupi memoriji.

Za razliku od preflešovanja, dijeljenje pažnje više nije korisno: dijeljenje glava pažnje na više uređaja značilo bi da ima manje mogućnosti za paralelizam unutar jednog uređaja. Posljedično, koriste se samo paralelizam podataka i paralelizam stručnjaka: stručnjaci su podijeljeni na više uređaja, ali svaki uređaj upravlja sopstvenim KV keševima i zahtjevima. Bez tenzorskog paralelizma, veličina KV keša po tokenu na uređaju je veća. Međutim, memorijski prostor se oslobađa lociranjem manjeg broja stručnjaka na jednom čvoru. Za razliku od Hopper-a, gdje smo ograničili tenzorski paralelizam unutar jednog NVLink domena u čvoru sa 8 GPU-ova, na Blackwell-u smo otkrili da je širenje na više čvorova unutar domena, koristeći do 16 uređaja, korisno.

Da bi se maksimalno povećao protok, dekoderi istovremeno obrađuju veći broj zahtjeva. Iako dodatni zahtjevi donose minimalne režijske troškove u MoE slojevima i drugim projekcijama, oni nesrazmjerno povećavaju cijenu pažnje. Da bi se održala razumna minimalna brzina dekodiranja, broj čvorova dekodera se skalira kako bi se veličine serija po dekoderu zadržale ispod određenog praga.

Slično prethodnim Hopper primjenama, koristimo spekulativno dekodiranje sa MTP slojevima obučenim internim putem radi povećanja brzine dekodiranja. Srećom, osnovni hardver i programski okviri su dovoljno slični da u potpunosti dijele implementaciju između dvije arhitekture.

Komunikacija unutar čvora i između čvorova

Glavna razlika između GB200 NVL72 i prethodnih Hopper čvorova je veliki NVLink domen, koji omogućava komunikaciju od uređaja do uređaja izvan prethodnog ograničenja od 8 uređaja. Iako su Blackwell uređajni primijenjeni u čvorovima sa 8 GPU-ova, postoji velika vrijednost u skaliranju preko više čvorova preko NVLink-a u poređenju sa sporijom InfiniBand mrežom.

Na čvorovima preflešera oslanjamo se na all-reduce komunikaciju unutar slojeva pažnje i na redukciju paralelnu sa stručnjacima koja veoma podsjeća na all-reduce. Preko 4 GPU-a iskoristimo i NVLink i NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): pored propusnog opsega od uređaja do uređaja, koristimo i redukcije u NVLink svičevima radi daljeg smanjenja latencija i implementacije brzog emitovanja. Na čvorovima dekodera koristi se prilagođena all-to-all dispečerska i kombinovana implementacija preko NVLink-a. Kerneli su implementirani interno korišćenjem CuTeDSL i cuMem mapiranja ili multikast mapiranja.

All-Reduce

Preflešeri obavljaju all-reduce operaciju u izlaznoj projekciji sloja pažnje, sumirajući doprinose glava podijeljenih preko rangova koji učestvuju. Tenzorski paralelizam je efikasan samo kada su režijski troškovi all-reduce-a nadoknađeni smanjenom latencijom manjih problema množenja matrica. Ova pretpostavka obično važi za prefleš.

Na NVIDIA HGX H200 i GB200 NVL72 sistemima klase data centara, GPU-ovi su obično povezani preko NVLink svičeva. Pored rutinga, svičevi mogu obavljati operacije redukcije preko povezanih uređaja putem SHARP-a. Nakon kreiranja memorijskih mapiranja i njihovog registrovanja u multikast grupu korišćenjem CUDA API-ja, kerneli mogu koristiti multicast.ld_reduce i multicast.st za agregiranje i emitovanje vrijednosti kroz svičeve. Da bismo kreirali temelj i komponente za višekratnu upotrebu koje se mogu spojiti u druge kernele, interno održavamo CuTeDSL all-reduce kernel koristeći ove primitive.

U sistemu sa N GPU-ova koji vrše redukciju B bajtova, trivijalna implementacija bi imala da uređaj učitava vrijednosti sa svih drugih uređaja, za ukupno N * (N - 1) * B bajtova ulaznog saobraćaja. Efikasnija implementacija bi podijelila podatke za redukciju na uređaje, pri čemu svaki vrši redukciju odsječka ulaza, a zatim ga emituje ostatku. Ovo rezultira sa (N - 1) * (B / N) bajtova pročitanih na uređaj i emitovanih ostatku, za ukupno (N - 1) * B * 2 čitanja i pisanja, čime se smanjuje saobraćaj preko svičeva.

Увећај

Sa SHARP-om, redukcija i emitovanje se mogu obaviti efikasnije: umjesto čitanja (N - 1) * (B / N) bajtova u uređaj radi lokalne akumulacije, samo se B / N premješta sa sviča, pošto on sam vrši redukciju koristeći podatke sa uređaja. Za emitovanje postoji slično poboljšanje, pošto je broj transakcija između GPU-a i sviča preko NVLink kanala znatno smanjen. Bez SHARP-a, uređaj za akumulaciju bi obavio (N - 1) * (B / N) transakcija preko NVLink-a sa svičem, pri čemu svič čita istu količinu podataka sa uređaja, za ukupno 2 * (N - 1) * (B / N) transakcija. Sa SHARP-om, B / N transakcija se obavlja između GPU-a i sviča, a dodatnih (N - 1) * (B / N) sa uređajima, za ukupno B transakcija.

Zbog svoje jednostavnosti, SHARP je vrijedan alat, pošto obezbjeđuje jednostavnu hardversku implementaciju za algoritam. Iako su prenosi smanjeni teorijskim razlomkom N / (2 * (N - 1)) (što iznosi 33% sa 4 uređaja), u praksi primjećujemo poboljšanje od 10% u latencijama i preflešovanja i dekodiranja na H200 i GB200 NVL72 sistemima.

Увећај

MoE Dispeč - Kombinovanje

Za MoE modele, dispečerski i kombinovani kerneli pomjeraju i grupišu tokove za naknadne MoE GEMM probleme između uređaja, obavljajući naknadnu ponderisanu akumulaciju u kombinovanju. Prilagodili smo naše postojeće dispečerske i kombinovane kernele za Blackwell, prenoseći ih na CuTeDSL, prilagođavajući alokacije blokova i agresivno ih specijalizujući između preflešovanja i dekodiranja.

Paralelno sa stručnjacima

Kernel paralelan sa stručnjacima (EP) koristi se u preflešerima. Pošto su njegovi ulazi replikovani na svim rangovima, dispečerski kernel treba jednostavno da izabere tokove usmjerene na stručnjake na trenutnom rangu. On agregira informacije o rutiranju i priprema tokove u baufere koji se koriste kao ulazi za MoE GEMM. Kombinovani kernel prvo obavlja lokalnu akumulaciju između doprinosa tokena usmjerenih na stručnjake na trenutnom rangu, a zatim obavlja all-reduce na svim rangovima.

Za dekodiranje, cijeli kernel je spojen u jedan. Prefleš kernel je podijeljen na više kernela, pošto ruting i all-reduce zahtijevaju manje blokova nego korak lokalnog kombinovanja. Sa CuTeDSL-om, mogli smo da izgradimo generičku biblioteku i za SHARP i za NVLink all-reduce i sinhronizaciju između uređaja, ugrađujući je u all-reduce kernel i kernel paralelan sa stručnjacima.

Увећај

Što se tiče performansi, primjećujemo da je Blackwell znatno brži od Hopper-a, zbog poboljšanih brzina prenosa, većeg memorijskog propusnog opsega i boljeg računskog protoka. Podijeljeni na 8 uređaja i više čvorova na GB200 sistemima (EP=8), kerneli postaju brži pošto se lokalna akumulacija izvršava na znatno manjem broju tokena na svakom uređaju i, sa SHARP-om, cijena redukcije na više rangova se bolje skalira. Međutim, u praksi ograničavamo paralelizam na 4 uređaja, pošto ova ubrzanja nisu univerzalna za sve kernele.

Paralelno sa podacima i stručnjacima

Kernel paralelan sa podacima i stručnjacima (DP-EP) koristi se u dekoderima paralelnim sa podacima. On emituje različite tokove sa svih rangova na stručnjake, prenoseći rezultate na izvorne rangove i akumulirajući ih. Pošto implementira rijedak all-to-all problem, oslanja se isključivo na NVLink.

Na Hopper-u, ovaj kernel je ograničen na 8 uređaja unutar NVLink domena jednog čvora. Međutim, na GB200 sistemima možemo ga skalirati preko cijelog recka. Većina koda se ponovo koristi. Jedina razlika je upotreba fabric ručki za razmjenu informacija o uređajima preko IMEX-a za početno podešavanje.

Увећај

Pošto su veličine prenosa nastale tokom dekodiranja male, one su daleko od zasićenja NVLink propusnog opsega i umjesto toga su ograničene latencijom. Latencije su u desetinama mikrosekundi i ostaju relativno stabilne kako se broj uređaja povećava, što nam omogućava da proširimo primjenu na veći broj uređaja bez izazivanja značajne dodatne latencije.

MoE GEMM

MoE modeli imaju koristi od paralelizma stručnjaka, pošto se cijena množenja svih tokena sa svim stručnjacima može lako paralelizovati na više uređaja. Sa tenzorskim paralelizmom na preflešerima, na gustim problemima prednost je prilično jasna, pošto svaki rang sada mora da obavi manje izračunavanja. U slučaju dekodiranja, paralelizam podataka pruža dodatnu prednost povrh paralelizma stručnjaka, pošto veći broj paralelnih zahtjeva usmjerava više tokena na svakog stručnjaka, čineći probleme gustim.

U našoj implementaciji trenutno se oslanjamo na CUTLASS CUDA/C++ kernele za množenje matrica. Testirali smo ih na rijetkim ulazima dekodiranja sa različitim šemama kvantizacije i nivoima paralelizma kako bismo odredili optimalnu strategiju dijeljenja za dekodere. U testovima performansi u nastavku, svi stručnjaci se aktiviraju sa jednim tokenom.

Увећај

Otkrili smo da skaliranje 128 stručnjaka na više od 16 rangova daje sve manji povraćaj sa CUTLASS-om, pošto cijena množenja 2 stručnjaka nije znatno niža od množenja 4. Postoji jasno poboljšanje na Blackwell-u u odnosu na Hopper, čak i na suboptimalnoj strategiji skaliranja blokova. Pošto je povećanje latencije od oko 5 us između EP=8 i EP=16 za dispeč/kombinovanje nadmašeno smanjenjem od više od 10 us u cijeni GEMM-a, na GB200 sistemima je opravdano dijeljenje dekodera na 16 rangova, što je potvrđeno i end-to-end testovima performansi.

Kvantizacija

Blackwell uvodi hardversku podršku za nove šeme 8-bitne i 4-bitne kvantizacije. Za razliku od Hopper-a, koji se oslanjao na faktore skaliranja po tenzoru ili po bloku, Blackwell zahtijeva mikroskaliranje da bi postigao najbolji protok preflešovanja i dekodiranja. Iako je šema skaliranja blokova koja se koristi za modele kao što su DeepSeek ili Kimi dostupna, mikroskaliranje je efikasnije.

Primijenili smo Qwen3 235B sa MXFP8 šemom kvantizacije, statički konvertujući težine nakon fino podešavanja modela. Uticaj na tačnost bio je sličan uticaju skaliranja blokova sa stohastičkom kvantizacijom, ali su isporučene performanse bile znatno bolje, što ilustruju MoE GEMM mikrotestovi performansi. Takođe smo razmotrili MXFP4 i NVFP4 šeme kvantizacije, mada je uticaj na tačnost bez obuke svjesne kvantizacije bio prevelik za početni prelazak sa Hopper-a na Blackwell. Planiramo da detaljnije istražimo ove formate u budućem radu.

End-to-end performanse

Testirali smo dekodere Blackwell Qwen3 235B primjena i uporedili ih sa našim prethodnim Hopper primjenama. U ovom podešavanju razmotrili smo skaliranje blokova preko obje primjene kako bismo se fokusirali na uticaj paralelizma. TP=4 preflešeri su odvojeni za obje arhitekture kako bi se izolovale performanse dekodiranja. Slika ispod ilustruje protok dekodiranja pod pretpostavkom realne stope prihvatanja nacrta koju isporučuju naši MTP slojevi.

Увећај

Na Hopper-u, dijeljenje primjene na više od 8 GPU-ova nije izvodljivo, pošto su latencije preko InfiniBand-a, posebno na EFA adapterima, znatno sporije. Međutim, na Blackwell-u ostvarujemo znatno veći protok zahvaljujući većim NVLink domenima.

Postigli smo početnu Blackwell implementaciju generalizacijom postojećih Hopper kernela i guranjem performansi kernela zasnovanih na NVLink-u. Dalje ćemo smanjivati cijenu opsluživanja Qwen-a poboljšanjem kvantizacije i fino podešavanjem performansi dekodiranja i protoka preflešovanja drugih kernela u cjevovodu.

Reference

Objjava na blogu o Transfer Engine-u

Objava na blogu o CuTeDSL-u

Objava na blogu o Prefill-Disagg-u

Objava na blogu o spekulativnom dekodiranju

CUTLASS

NVLink

Цитирање

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