Qwen futtatása Blackwellen

A 72 irányú NVLink-en keresztül összekapcsolt NVIDIA Blackwell GPU-kkal felszerelt NVIDIA GB200 NVL72 rackek kiválóan alkalmasak nagy, kevert szakértői (MoE) modellek üzembe helyezésére. Ebben a blogbejegyzésben bemutatjuk a Perplexity adatforgalmának egy részét kiszolgáló, utóhangolt Qwen3 235B modelleket kiszolgáló inferencia-beállítást. Bemutatjuk, hogyan igazítottuk saját fejlesztésű inferenciamotorunkat az NVIDIA Blackwell GPU-k fejlett tenzormagjainak és nagy sebességű összekapcsolásának kihasználására. Ezzel a hardverrel nagyobb adatforgalmat kezelünk alacsonyabb költséggel anélkül, hogy feladnánk az alapul szolgáló modellek pontosságát.

Üzembe helyezés a GB200 NVL72-n

A GB200 NVL72 rackek 18 csomóbból állnak, amelyek 2 ARM-alapú NVIDIA Grace CPU-t és 4 Blackwell-alapú GPU-t tartalmaznak, egyenként 180 GB HBM-mel felszerelve. A 72 GPU az NVLink és 18 NVLink Switch ASIC révén van összekapcsolva, ami 1800 GB/s sávszélességet biztosít bármely két partner között, és elegendő memóriát oszt meg egymással a billió paraméteres modellek futtatásához. Ezenkívül a ConnectX-7 InfiniBand adapterek további 400 Gb/s sávszélességet biztosítanak mind a racken belüli csomópontok között, mind a szomszédos rackek felé.

Az adatforgalom kezelése érdekében a Qwen modellek utóhangolása és kiszolgálása mellett döntöttünk. Ebben a blogbejegyzésben a Qwen3 235B modellre fókuszálunk, de a tárgyalt kiszolgálási technikák és teljesítményjellemzők nagy része hasonlít az újabb Qwen3.5 397B és 122B modellekére, amelyekre éppen átállunk. A párhuzamosság tekintetében a lineáris figyelem (attention) hasonló a teljes önfigyeléshez, és a meglévő MoE rétegimplementáció könnyen hozzáigazítható az új kaputagok befogadásához. Annak érdekében, hogy fenntartsuk a konzisztens dekódolási sebességet és maximálisra növeljük az áteresztőképességet, a prefill (előkitöltés) és a dekódolás szétválasztása mellett döntöttünk, és különböző párhuzamossági stratégiákat alkalmazunk a kétféle csomóponttípushoz. A prefiller (előkitöltő) és a dekódoló közötti kommunikáció InfiniBanden keresztül történik, míg az NVLink sávszélesség a prefillerek és dekódolók belüli kommunikáció számára van fenntartva. A Blackwell eszközök mátrixszorzás és eszközök közötti kommunikáció során tapasztalt teljesítményjellemzői – amelyeket ebben a blogbejegyzésben mutatunk be – határozzák meg az alkalmazott sharding (szeletelési) stratégiákat. Az NVIDIA Hopper GPU-khoz képest tagonkénti (kernel-by-kernel) javulást tapasztalunk a nagyobb számú streaming multiprocesszornak, a megnövelt memóriasávszélességnek és az alacsonyabb peer-to-peer késleltetéseknek köszönhetően.

Nagyítás

A szétválasztott prefillt megvalósító TransferEngine motorunk tetszőleges és esetlegesen eltérő shardingot kezel a prefillerek és dekódolók között. A KV gyorsítótárak (cache) a memóriában HND sorrendben helyezkednek el, a fejek a vezető dimenzióban, a tokenek pedig folytonosan vannak tartva, így a prefilleren lévő shardt KV gyorsítótár tovább osztható vagy összefűzhető a dekódoló csomópontba történő átvitel során.

Prefillerek

A prefiller csomópontok fogadják a kérés bemeneti tokenjeit, feltöltik a KV gyorsítótárakat, és továbbítják azokat a dekódolóknak a szöveggenerálás folytatásához. A prefill számítási szempontból intenzív, mivel egy sorozathoz tartozó tokenek ezreit dolgozza fel a rendszer egyszerre.

Ennek eredményeként azt találtuk, hogy a tenzorpárhuzamos üzembe helyezés a megfelelő, ahol a modell 4 GPU-ra van szeletelve egyetlen GB200 csomóponton belül, a vetítések és a szakértők pedig szét vannak osztva (TP=4, EP=4). Mivel mind a figyelem, mind az MLP számításigényes, mindkettő profitál a párhuzamosságból, szétosztva a szakértőket és a figyelmi fejeket a különálló rangok között. A további párhuzamosság csökkenő hozamot eredményezett volna, mivel a kevesebb szakértő rangonkénti befogadásából eredő áteresztőképesség-javulás (16 helyett 32) nem kompenzálta volna a 8-irányú all-reduce többletköltségét, valamint azt a rezsiköltséget, hogy a gazdagép oldali kódot két csomópont között kell felosztani, ami Etherneten keresztüli kommunikációt igényel.

A Qwen3 235B-nek mindössze 4 key-value feje van, ezért 8 eszköz használata esetén a k és v projekciókat a rangpárok között meg kell ismételni. Megfontolhattunk volna agresszívebb shardingot is, hogy csökkentsük az egyes rangokon a súlyok tárolásához szükséges memória mennyiségét, így több token számára szabadulhatott volna fel hely a KV-gyorsítótárban. Ugyanakkor úgy találtuk, hogy a szélesebb körű telepítés nem érte volna meg.

Feltételezve, hogy a bemeneti hossza körülbelül 6000 token, a 128 szakértő mindegyikére nagyjából 6000 * 8 / 128 = 375 token jut, ami sűrű feladatot biztosít a MoE GEMM számára. Mivel ez már telíti az eszköz számítási áteresztőképességét, az adatpárhuzamosság nem szükséges a prefillhez.

A figyelem quadratikusan növekvő költsége ellenére a prefillerek egyenletes áteresztőképességet biztosítanak, lehetővé téve egy hozzávetőleges becslést arra vonatkozóan, hogy hány bemeneti tokent képes egy csomópont feldolgozni egy másodperc alatt. A kérésekből származó bemeneti tokenek teljes számát követő metrikákra támaszkodva a prefiller csomópontok száma skálázható annak biztosítására, hogy az általános prefill áteresztőképesség ennek megfelelően legyen méretezve. A sorban állás elkerülése érdekében a prefiller replikák számát a kapott bemeneti tokenek teljes számához igazítjuk.

Dekódolók

A dekódoló csomópontok fogadják a KV gyorsítótárakat a prefillerektől, és egyenként generálják a tokeneket. A dekódolás általában memóriakorlátos: kevés bemeneti token esetén a mátrixszorzás teljes egészében a súlyoknak a HBM-ből a tenzormagokba történő betöltési költségétől függ. A eltérő sharding stratégia alkalmazása mellett számos kernelt finomítani kell a számítások és a memóriahozzáférések jobb párhuzamosítása érdekében.

A prefill-lel ellentétben az attention shardingje már nem előnyös: az attention fejek több eszköz közötti felosztása azt jelentené, hogy egyetlen eszközön belül kevesebb lehetőség marad a párhuzamosításra. Ennek következtében csak az adatpárhuzamosságot és a szakértőpárhuzamosságot használjuk: a szakértőket több eszköz között shardeljük, de minden eszköz a saját KV-gyorsítótárait és kéréseit kezeli. Tensor párhuzamosság nélkül egy eszközön a tokenenkénti KV-gyorsítótár mérete nagyobb. Ugyanakkor a memóriában hely szabadul fel azáltal, hogy kevesebb szakértő található egyetlen node-on. A Hopperrel ellentétben, ahol egy 8-GPU-s node-on belül egyetlen NVLink-doménre korlátoztuk a tensor párhuzamosságot, a Blackwellen azt találtuk, hogy előnyös a doménen belüli több node-ra kiterjesztés, akár 16 eszközig.

Az áteresztőképesség maximalizálása érdekében a dekódolók nagyobb számú kérést dolgoznak fel párhuzamosan. Annak ellenére, hogy a további kérések minimális többletterhet jelentenek a MoE rétegekben és egyéb vetítésekben, aránytalanul növelik a figyelem költségét. Az elfogadható minimális dekódolási sebesség fenntartása érdekében a dekódoló csomópontok számát úgy skálázzák, hogy az egy dekódolóra jutó kötegméretek (batch sizes) egy bizonyos küszöbérték alatt maradjanak.

A korábbi Hopper üzembe helyezésekhez hasonlóan spekulatív dekódolást használunk a házon belül betanított MTP rétegekkel a dekódolási sebesség növelése érdekében. Szerencsére az alapul szolgáló hardver és programozási keretrendszerek eléggé hasonlítanak ahhoz, hogy a megvalósítást teljes egészében megosszuk a két architektúra között.

Csomóponton belüli és csomópontok közötti kommunikáció

A fő különbség a GB200 NVL72 és a korábbi Hopper csomópontok között a nagy NVLink tartomány, amely lehetővé teszi a peer-to-peer kommunikációt a korábbi 8 eszközös határon túl. Annak ellenére, hogy a Blackwell eszközök 8 GPU-s csomópontokba lettek telepítve, nagy értéket képvisel a több csomópontra való skálázás az NVLinken keresztül a lassabb InfiniBand hálózathoz képest.

A prefiller csomópontokon a figyelmi rétegeken belüli all-reduce kommunikációra, valamint az all-reduce-ra nagyon hasonlító, szakértői párhuzamos redukcióra támaszkodunk. 4 GPU-n keresztül az NVLinket és az NVIDIA SHARP-ot (Scalable Hierarchical Aggregation and Reduction Protocol) egyaránt kihasználjuk: a peer-to-peer sávszélesség mellett az NVLink Switchekben lévő redukciókat is kiaknázzuk a késleltetések további csökkentése és a gyors broadcast (szórás) megvalósítása érdekében. A dekódoló csomópontokon az NVLinken keresztüli egyedi all-to-all dispatch (küldési) és combine (összevonási) megvalósítást használunk. A kerneleket házon belül implementáltuk CuTeDSL és cuMem leképezések vagy multicast leképezések használatával.

All-Reduce

A prefillerek all-reduce műveletet hajtanak végre a figyelmi réteg kimeneti vetítésében, összegezve a részt vevő rangok között megosztott fejek hozzájárulásait. A tenzorpárhuzamosság csak akkor hatékony, ha az all-reduce rezsi költségét ellensúlyozza a kisebb mátrixszorzási feladatok csökkentett késleltetése. Ez a feltétel általában érvényes a prefillre.

Az adatközponti kategóriájú NVIDIA HGX H200 és GB200 NVL72 rendszerekben a GPU-k általában NVLink Switcheken keresztül csatlakoznak. Az útválasztás mellett a switchek képesek redukciós műveleteket végezni a csatlakoztatott eszközök között a SHARP-on keresztül. Miután létrehozták a memórialépéseket, és regisztrálták azokat egy multicast csoportba a CUDA API-k használatával, a kernelek a multicast.ld_reduce és multicast.st utasításokkal összesíthetik és szórhatják az értékeket a switcheken keresztül. Olyan alapok és újrafelhasználható komponensek létrehozása érdekében, amelyek más kernelekbe ágyazhatók, házon belül fenntartunk egy CuTeDSL all-reduce kernelt ezen primitívek használatával.

Egy N darab GPU-t tartalmazó rendszerben, amely B bájtot redukál, egy triviális megvalósítás során egy peer betölti az értékeket az összes többi peertől, ami összesen N * (N - 1) * B bájt olvasási adatforgalmat eredményez. Egy hatékonyabb megvalósítás felosztaná a redukálandó adatot a peerek között, mindegyik a bemenet egy szeletét redukálná, majd szórná a többi felé. Ez (N - 1) * (B / N) bájt beolvasását eredményezi egy peerbe és szórását a többiek felé, ami összesen (N - 1) * B * 2 olvasást és írást jelent, csökkentve a switcheken átmenő adatforgalmat.

Nagyítás

A SHARP használatával a redukció és a szórás hatékonyabban hajtható végre: ahelyett, hogy (N - 1) * (B / N) bájtot olvasna be egy eszköz a helyi akkumulációhoz, csak B / N bájt kerül átmozgatásra a switchetől, mivel az maga végzi el a redukciót a peerektől származó adatok felhasználásával. A szórásnál hasonló javulás tapasztalható, mivel a GPU és a switch közötti tranzakciók száma az NVLink csatornákon keresztül jelentősen csökken. SHARP nélkül az akkumuláló eszköz (N - 1) * (B / N) tranzakciót hajtana végre az NVLinken keresztül a switchel, miközben a switch ugyanennyi adatot olvasna be a peerektől, ami összesen 2 * (N - 1) * (B / N) tranzakciót jelent. SHARP-mal B / N tranzakció történik a GPU és a switch között, és további (N - 1) * (B / N) a peerekkel, ami összesen B tranzakciót eredményez.

Egyszerűsége miatt a SHARP értékes eszköz, mivel egy algoritmushoz közvetlen hardveres megvalósítást biztosít. Annak ellenére, hogy az átvitelek elméleti N / (2 * (N - 1)) hányaddal csökkennek (ami 4 peer esetén 33%-nak felel meg), a gyakorlatban 10%-os javulást tapasztalunk mind a prefill, mind a dekódolás késleltetésében a H200 és GB200 NVL72 rendszereken egyaránt.

Nagyítás

MoE Dispatch - Combine

MoE modellek esetén a dispatch és combine kernelek áthelyezik és csoportosítják a tokeneket a peerek közötti későbbi MoE GEMM feladatokhoz, majd a combine során súlyozott akkumulációt hajtanak végre. Meglévő Dispatch és Combine kerneljeinket átültettük a Blackwellre azáltal, hogy portoltuk őket CuTeDSL-re, finomítottuk a blokk-allokációkat, és agresszíven specializáltuk őket a prefill és a dekódolás között.

Szakértői párhuzamos (Expert Parallel)

A szakértői párhuzamos (EP) kernel a prefillerekben van használatban. Mivel a bemenetei replikálva vannak az összes rang között, a dispatch kernelnek egyszerűen ki kell választania az aktuális rangon lévő szakértőkhöz irányított tokeneket. Összesíti az útválasztási információkat, és a MoE GEMM bemeneteként használt pufferekbe készíti elő a tokeneket. A combine kernel először helyi akkumulációt hajt végre az aktuális rangon lévő szakértőkhöz irányított tokenek hozzájárulásai között, majd all-reduce műveletet végez az összes rang között.

Dekódolás esetén az egész kernel eggyé olvad össze. A prefill kernel több kernelre oszlik, mivel az útválasztás és az all-reduce kevesebb blokkot igényel, mint a helyi combine lépés. A CuTeDSL segítségével egy általános könyvtárat építhettünk ki mind a SHARP, mind az NVLink all-reduce és a peer-to-peer szinkronizálás számára, beépítve azt mind az all-reduce, mind a szakértői párhuzamos kernelekbe.

Nagyítás

Teljesítmény szempontjából azt tapasztaljuk, hogy a Blackwell lényegesen gyorsabb, mint a Hopper, a javult átviteli sebességnek, a magasabb memóriasávszélességnek és a jobb számítási áteresztőképességnek köszönhetően. A GB200-akon 8 eszközre és több csomópontra szeletelve (EP=8) a kernelek gyorsabbá válnak, mivel a helyi akkumuláció sokkal kevesebb tokenen fut az egyes eszközökön, és a SHARP-pal a több rangon átívelő redukció költsége jobban skálázódik. A gyakorlatban azonban a párhuzamosságot 4 eszközre korlátozzuk, mivel ezek a sebességnövekedések nem univerzálisak minden kernel esetében.

Adatpárhuzamos és szakértői párhuzamos (Data Parallel and Expert Parallel)

Az adatpárhuzamos és szakértői párhuzamos (DP-EP) kernel az adatpárhuzamos dekódolókban van használatban. Különböző tokeneket szór szét az összes rangról a szakértők felé, átvéve az eredményeket az eredeti rangokra, és akkumulálva azokat. Mivel egy ritka (sparse) all-to-all feladatot valósít meg, kizárólag az NVLinkre támaszkodik.

Hopperen ez a kernel az egyetlen csomópont NVLink tartományán belüli 8 eszközre van korlátozva. A GB200 rendszereken azonban egy egész rackre kiterjedően tudjuk skálázni. A kód nagy része újra van felhasználva. Azetlen különbség a fabric leképezések használata a peer információk IMEX-en keresztüli cseréjéhez a kezdeti beállítás során.

Nagyítás

Mivel a dekódolás során előforduló átviteli méretek kicsik, távol állnak az NVLink sávszélesség telítésétől, és helyette késleltetés-korlátosak. A késleltetések a tíz mikroszekundumos tartományban mozognak, és viszonylag stabilak maradnak a peerek számának növekedésével, ami lehetővé teszi, hogy az üzembe helyezést nagyobb számú eszközre terjesszük ki anélkül, hogy jelentős további késleltetés lépne fel.

MoE GEMM

A MoE modellek profitálnak a szakértői párhuzamosságból, mivel az összes token és az összes szakértő szorzásának költsége könnyen párhuzamosítható több eszköz között. A prefillereken alkalmazott tenzorpárhuzamossággal a sűrű feladatok esetén az előny teljesen egyértelmű, mivel így minden rangnak kevesebb számítást kell végeznie. Dekódolási esetben az adatpárhuzamos koncepció további előnyt biztosít a szakértői párhuzamosság mellett, mivel a párhuzamos kérések nagyobb száma több tokent irányít az egyes szakértőkhöz, sűrűbbé téve a feladatokat.

Megvalósításunkban jelenleg a mátrixszorzáshoz CUTLASS CUDA/C++ kernelekre támaszkodunk. Ezeket ritka dekódolási bemeneteken, különböző kvantálási sémákkal és párhuzamossági szintekkel benchmarkoltuk a dekódolók optimális sharding stratégiájának meghatározása érdekében. Az alábbi benchmarkokban minden szakértő egyetlen tokennel van aktiválva.

Nagyítás

Azt találtuk, hogy a 128 szakértő 16-nál több rangra történő skálázása csökkenő hozamot eredményez a CUTLASS-szal, mivel 2 szakértő szorzásának költsége nem lényegesen alacsonyabb, mint 4-é. A Blackwellen egyértelmű javulás látható a Hopperhez képest, még az alulteljesítő blokkskálázási stratégia mellett is. Mivel a dispatch/combine EP=8 és EP=16 közötti, mintegy 5 us-os késleltetésnövekedését ellensúlyozza a GEMM költségének több mint 10 us-os csökkenése, a GB200 rendszereken indokolt a dekódolók 16 rangra történő szeletelése, amit a végpontok közötti (end-to-end) benchmarkok is megerősítenek.

Kvantálás

A Blackwell hardveres támogatást vezet be az új 8 bites és 4 bites kvantálási sémákhoz. A Hopperrel ellentétben, amely tenzoronkénti vagy blokkonkénti skálázási tényezőkre támaszkodott, a Blackwell mikroskálázást igényel a legjobb prefill és dekódolási áteresztőképesség eléréséhez. Bár az olyan modellekhez, mint a DeepSeek vagy a Kimi, használt blokkskálázási séma elérhető, a mikroskálázás hatékonyabb.

Az MXFP8 kvantálási sémával helyeztük üzembe a Qwen3 235B-t, statikusan konvertálva a súlyokat a modell finomhangolása után. A pontosságra gyakorolt hatás hasonló volt a sztochasztikus kvantálással végzett blokkskálázás hatásához, de a nyújtott teljesítmény sokkal jobb volt, amint azt a MoE GEMM mikrobenchmarkok is szemléltetik. Megfontoltuk az MXFP4 és NVFP4 kvantálási sémákat is, bár a Quantization-Aware Training (kvantálástudatos tanítás) nélküli pontossági hatás túl jelentős volt a Hopperről a Blackwellre történő kezdeti átálláshoz. Tervezzük ezen formátumok alaposabb feltárását a jövőbeli munkánk során.

Végpontok közötti (End-to-End) teljesítmény

Benchmarkoltuk a Blackwell Qwen3 235B üzembe helyezések dekódolóit, és összehasonlítottuk őket a korábbi Hopper üzembe helyezéseinkkel. Ebben a beállításban mindkét üzembe helyezésnél a blokkskálázást vettük figyelembe, hogy a párhuzamosság hatására fókuszálhassunk. A dekódolási teljesítmény izolálása érdekében a TP=4 prefillereket különválasztottuk mindkét architektúrához. Az alábbi ábra a dekódolási áteresztőképességet szemlélteti, feltételezve az MTP rétegeink által biztosított reális vázlat-elfogadási arányt (draft acceptance rate).

Nagyítás

Hopperen az üzembe helyezés 8-nál több GPU-ra történő szeletelése nem életképes, mivel az InfiniBand-en keresztüli késleltetések – különösen az EFA adaptereken – lényegesen lassabbak. A Blackwellen azonban lényegesen nagyobb áteresztőképességet érünk el a nagyobb NVLink tartományoknak köszönhetően.

Kezdeti Blackwell implementációt értünk el a meglévő Hopper kernelek általánosításával és az NVLink-alapú kernelek teljesítményének növelésével. A jövőben tovább csökkentjük a Qwen kiszolgálásának költségét a kvantálás javításával, valamint a pipeline-ban szereplő többi kernel dekódolási teljesítményének és prefill áteresztőképességének finomhangolásával.

Hivatkozások

Transfer Engine blogbejegyzés

CuTeDSL blogbejegyzés

Prefill-Disagg blogbejegyzés

Spekulatív dekódolás blogbejegyzés

CUTLASS

NVLink

Idézet

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