Provoz Qwen na Blackwellu

Racky NVIDIA GB200 NVL72 s GPU NVIDIA Blackwell propojenými přes 72cestné rozhraní NVLink jsou jedinečně vhodné pro nasazení velkých modelů typu Mixture-of-Experts (MoE). V tomto příspěvku na blogu popisujeme nastavení inference obsluhující dodatečně trénované modely Qwen3 235B, které pokrývají část provozu služby Perplexity. Ukazujeme, jak jsme přizpůsobili náš vlastní inferenční engine tak, aby využíval pokročilá tensorová jádra a vysokorychlostní propojení GPU NVIDIA Blackwell. S tímto hardwarem zvládáme větší provoz při nižších nákladech, aniž bychom obětovali přesnost podkladových modelů.

Nasazení na GB200 NVL72

Racky GB200 NVL72 se skládají z 18 uzlů se 2 CPU NVIDIA Grace založenými na architektuře ARM a 4 GPU založenými na architektuře Blackwell, přičemž každý je vybaven 180 GB HBM. Těchto 72 GPU je propojeno prostřednictvím NVLink a 18 ASIC přepínačů NVLink Switch, což poskytuje šířku pásma 1800 GB/s mezi libovolnými dvěma partnery a sdílí dostatek paměti pro hostování modelů s biliony parametrů. Adaptéry ConnectX-7 InfiniBand navíc poskytují další šířku pásma 400 Gb/s jak uvnitř uzlů racku, tak napříč sousedními racky.

Pro zvládnutí provozu jsme se rozhodli dodatečně trénovat a provozovat modely Qwen. V tomto příspěvku na blogu se zaměřujeme na Qwen3 235B, ale mnoho diskutovaných technik obsluhy a výkonnostních charakteristik je podobných těm u novějších modelů Qwen3.5 397B a 122B, na které migrujeme. Z hlediska paralelismu je lineární pozornost podobná úplné vlastní pozornosti a stávající implementaci vrstvy MoE lze snadno přizpůsobit tak, aby pojala nové výrazy hradel. Abychom zachovali konzistentní rychlost dekódování a zároveň maximalizovali propustnost, zvolili jsme oddělení fáze předběžného plnění (prefill) od dekódování a pro oba typy uzlů nasadili různé strategie paralelismu. Komunikace mezi prefillérem a dekodérem probíhá přes InfiniBand, zatímco šířka pásma NVLink je vyhrazena pro komunikaci v rámci prefillérů a dekodérů. Výkonnostní charakteristiky zařízení Blackwell při provádění maticového násobení a komunikace mezi zařízeními, zkoumané v tomto příspěvku na blogu, určují použité strategie shardování. Ve srovnání s GPU NVIDIA Hopper zaznamenáváme vylepšení jádro po jádru díky vyššímu počtu streamingových multiprocesorů, zvýšené šířce pásma paměti a nižším latencím typu peer-to-peer.

Zvětšit

Náš TransferEngine, který implementuje oddělené předběžné plnění, zvládal libovolné a případně neshodné shardování napříč prefilléry a dekodéry. Mezipaměti KV jsou v paměti uspořádány v pořadí HND, přičemž hlavy jsou v přední dimenzi a tokeny jsou udržovány souvislé, což umožňuje, aby byla shardovaná mezipaměť KV na prefilléru během přenosu do uzlu dekodéru dále rozdělena nebo zřetězena za běhu.

Prefilléry

Uzlů prefilléru přijímají vstupní tokeny požadavku, naplňují mezipaměti KV a přenášejí je do dekodérů pro pokračování generování textu. Předběžné plnění je výpočetně náročné, protože tisíce tokenů patřících do sekvence jsou zpracovávány současně.

V důsledku toho jsme zjistili, že je vhodné nasazení s paralelismem tensorů, přičemž model je rozshardován na 4 GPU v rámci jednoho uzlu GB200 a projekce a experti jsou rozshardováni (TP=4, EP=4). Jelikož jsou jak pozornost (attention), tak sítě MLP náročné na výpočty, obojí těží z paralelismu, který distribuuje experty a hlavy pozornosti napříč samostatnými hodnostmi (ranks). Další paralelismus by přinesl klesající výnosy, protože zlepšení propustnosti díky hostování menšího počtu expertů na každé hodnosti (16 oproti 32) by nevyvážilo dodatečné náklady na 8cestnou operaci all-reduce a režii rozdělení kódu na straně hostitele mezi dva uzly, což vyžaduje komunikaci přes Ethernet.

Qwen3 235B má pouze 4 hlavy klíč-hodnota, což vyžaduje, aby byly projekce k a v replikovány napříč páry hodností, pokud se používá 8 zařízení. Mohli jsme zvážit agresivnější shardování ke snížení množství paměti potřebné k uložení vah na každé hodnosti, čímž by se uvolnil prostor pro více tokenů v mezipaměti KV. Zjistili jsme však, že širší nasazení se nevyplatí.

Za předpokladu délky vstupu kolem 6000 tokenů je na každého ze 128 expertů směrováno přibližně 6000 * 8 / 128 = 375 tokenů, což zajišťuje hustý problém pro MoE GEMM. Jelikož to již saturuje výpočetní propustnost zařízení, paralelismus dat není pro předběžné plnění potřeba.

Navzdory kvadraticky rostoucím nákladům na pozornost poskytují prefilléry konzistentní propustnost, což umožňuje hrubý odhad počtu vstupních tokenů, které mohou být zpracovány uzlem za sekundu. S využitím metrik sledujících celkový počet vstupních tokenů z požadavků lze počet uzlů prefilléru navýšit tak, aby celková propustnost předběžného plnění byla odpovídajícím způsobem dimenzována. Aby se předešlo řazení do front, počet replik prefilléru se přizpůsobuje celkovému počtu přijatých vstupních tokenů.

Dekodéry

Uzlů dekodéru přijímají mezipaměti KV od prefillérů a generují tokeny jeden po druhém. Dekódování je obecně limitováno pamětí: s malým počtem vstupních tokenů je maticové násobení zcela omezeno náklady na načítání vah z HBM do tensorových jader. Kromě použití jiné strategie shardování je nutné vyladit několik jader, aby se lépe paralelizovaly výpočty a přístupy do paměti.

Na rozdíl od předběžného plnění již shardování pozornosti není přínosné: rozdělení hlav pozornosti mezi více zařízení by znamenalo méně příležitostí pro paralelismus v rámci jednoho zařízení. V důsledku toho se používá pouze datový paralelismus a paralelismus expertů: experti jsou rozshardováni mezi více zařízení, ale každé zařízení spravuje své vlastní mezipaměti KV a požadavky. Bez paralelismu tensorů je velikost mezipaměti KV na token na zařízení větší. Místo v paměti se však uvolní umístěním menšího počtu expertů na jeden uzel. Na rozdíl od Hopperu, kde jsme omezili paralelismus tensorů v rámci jedné domény NVLink v uzlu s 8 GPU, jsme na Blackwellu zjistili, že je výhodné rozšířit se napříč více uzly v rámci jedné domény za použití až 16 zařízení.

Aby se maximalizovala propustnost, dekodéry zpracovávají větší počet požadavků současně. I když dodatečné požadavky představují minimální režii ve vrstvách MoE a dalších projekcích, disproporčně zvyšují náklady na pozornost. Pro zachování rozumné minimální rychlosti dekódování se počet uzlů dekodéru škáluje tak, aby velikost dávek (batch sizes) na dekodér zůstala pod určitou prahovou hodnotou.

Podobně jako u předchozích nasazení Hopper používáme spekulativní dekódování s interně natrénovanými vrstvami MTP k zvýšení rychlosti dekódování. Naštěstí jsou podkladový hardware a programovací frameworky dostatečně podobné, aby bylo možné implementaci plně sdílet mezi oběma architekturami.

Komunikace v rámci uzlu a mezi uzly

Hlavním rozdílem mezi GB200 NVL72 a předchozími uzly Hopper je velká doména NVLink, která umožňuje komunikaci peer-to-peer nad rámec předchozího limitu 8 zařízení. I když byla zařízení Blackwell nasazena v uzlech s 8 GPU, škálování napříč více uzly přes NVLink má oproti pomalejší síti InfiniBand velkou hodnotu.

Na uzlech prefilléru spoléháme na komunikaci all-reduce v rámci vrstev pozornosti a na redukci paralelní s experty, která velmi připomíná all-reduce. Napříč 4 GPU využíváme jak NVLink, tak NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): kromě šířky pásma peer-to-peer využíváme také redukce v přepínačích NVLink Switches k dalšímu snížení latencí a implementaci rychlých všesměrových vysílání (broadcasts). Na uzlech dekodérů se používá vlastní implementace odesílání a kombinování typu all-to-all přes NVLink. Jádra byla implementována interně pomocí CuTeDSL a mapování cuMem nebo multicastových mapování.

All-Reduce

Prefilléry provádějí operaci all-reduce ve výstupní projekci vrstvy pozornosti, kde sčítají příspěvky hlav rozshardovaných napříč zúčastněnými hodnostmi. Paralelismus tensorů je efektivní pouze tehdy, když jsou náklady na režii all-reduce vyváženy sníženou latencí menších úloh maticového násobení. Tento předpoklad obvykle platí pro předběžné plnění.

V datacentrových systémech NVIDIA HGX H200 a GB200 NVL72 jsou GPU obvykle propojena přes přepínače NVLink Switches. Kromě směrování mohou přepínače provádět redukční operace napříč připojenými zařízeními prostřednictvím SHARP. Po vytvoření paměťových mapování a jejich registraci do multicastové skupiny pomocí rozhraní CUDA API mohou jádra používat příkazy multicast.ld_reduce a multicast.st k agregaci a všesměrovému vysílání hodnot přes přepínače. Za účelem vytvoření základu a opakovaně použitelných komponent, které lze sloučit do jiných jader, interně udržujeme jádro all-reduce CuTeDSL využívající tyto primitivní funkce.

V systému s N GPU redukujícími B bajtů by triviální implementace spočívala v tom, že jeden peer načítá hodnoty ze všech ostatních peerů, což představuje celkem N * (N - 1) * B bajtů čtecího provozu. Efektivnější implementace by rozdělila data určená k redukci mezi peery, přičemž každý by redukoval výsek vstupu a poté jej vyslal všem ostatním. To má za následek (N - 1) * (B / N) bajtů přečtených do peeru a vyslaných ostatním, což činí celkem (N - 1) * B * 2 čtení a zápisů, čímž se snižuje provoz přes přepínače.

Zvětšit

S protocol SHARP lze redukci a všesměrové vysílání provádět efektivněji: namísto načítání (N - 1) * (B / N) bajtů do zařízení pro lokální akumulaci se z přepínače přesouvá pouze B / N, protože ten provádí samotnou redukci za použití dat z peerů. U všesměrového vysílání dochází k podobnému zlepšení, protože počet transakcí mezi GPU a přepínačem přes kanály NVLink je výrazně snížen. Bez SHARP by akumulační zařízení provádělo 2 * (N - 1) * (B / N) transakcí přes NVLink s přepínačem, přičemž přepínač by četl stejné množství dat od peerů, což činí celkem (N - 1) * (B / N) transakcí přes NVLink s přepínačem. Se SHARP se provádí B / N transakcí mezi GPU a přepínačem a dalších (N - 1) * (B / N) s peery, celkem tedy B transakcí.

Díky své jednoduchosti je SHARP cenným nástrojem, protože poskytuje přímočarou hardwarovou implementaci algoritmu. Ačkoli jsou přenosy sníženy o teoretický podíl N / (2 * (N - 1)) (což při 4 peerech představuje 33 %), v praxi pozorujeme 10% zlepšení jak latencí předběžného plnění, tak dekódování na systémech H200 i GB200 NVL72.

Zvětšit

MoE Dispatch - Combine

U modelů MoE přesouvají a seskupují jádra dispatch a combine tokeny pro následné úlohy MoE GEMM mezi peery a následně provádějí váženou akumulaci ve fázi combine. Přizpůsobili jsme naše stávající jádra Dispatch a Combine pro Blackwell tím, že jsme je portovali na CuTeDSL, upravili alokace bloků a agresivně je specializovali mezi předběžným plněním a dekódováním.

Paralelismus expertů

Jádro paralelismu expertů (EP) se používá v prefillérech. Jelikož jsou jeho vstupy replikovány napříč všemi hodnostmi, odesílací jádro (dispatch kernel) musí jednoduše vybrat tokeny směrované k expertům na aktuální hodnosti. Agreguje informace o směrování a připravuje tokeny do vyrovnávacích pamětí používaných jako vstupy pro MoE GEMM. Kombinační jádro (combine kernel) nejprve provádí lokální akumulaci mezi příspěvky tokenů směrovaných k expertům na aktuální hodnosti a poté provádí operaci all-reduce napříč všemi hodnostmi.

Pro dekódování je celé jádro sloučeno do jednoho. Jádro předběžného plnění je rozděleno do více jader, protože směrování a all-reduce vyžadují méně bloků než lokální krok combine. S CuTeDSL jsme mohli vytvořit obecnou knihovnu pro all-reduce SHARP i NVLink a synchronizaci peer-to-peer a začlenit ji do jader all-reduce i expert parallel.

Zvětšit

Z hlediska výkonu pozorujeme, že Blackwell je podstatně rychlejší než Hopper, a to díky vylepšeným přenosovým rychlostem, vyšší šířce pásma paměti a lepší výpočetní propustnosti. Při rozshardování na 8 zařízení a více uzlů na GB200 (EP=8) se jádra stávají rychlejšími, protože lokální akumulace běží na mnohem menším počtu tokenů na každém zařízení a se SHARP se náklady na redukci napříč více hodnostmi lépe škálují. V praxi však omezujeme paralelismus na 4 zařízení, protože toto zrychlení není univerzální pro všechna jádra.

Paralelismus dat a paralelismus expertů

Jádro paralelismu dat a paralelismus expertů (DP-EP) se používá v datově paralelních dekodérech. Vysílá různé tokeny ze všech hodností k expertům, přenáší výsledky do původních hodností a kumuluje je. Jelikož implementuje řídký (sparse) problém all-to-all, spoléhá se výhradně na NVLink.

Na Hopperu je toto jádro omezeno na 8 zařízení v rámci domény NVLink jednoho uzlu. Na systémech GB200 jej však můžeme škálovat napříč celým rackem. Většina kódu je znovu použita. Jediným rozdílem je použití fabric handle pro výměnu informací o peerech přes IMEX pro počáteční nastavení.

Zvětšit

Vzhledem k tomu, že velikosti přenosů vznikající při dekódování jsou malé, zdaleka nesaturují šířku pásma NVLink a jsou namísto toho omezeny latencí. Latence se pohybují v desítkách mikrosekund a zůstávají relativně stabilní s rostoucím počtem peerů, což nám umožňuje rozšířit nasazení na větší počet zařízení bez výrazného nárůstu dodatečné latence.

MoE GEMM

Modely MoE těží z paralelismu expertů, protože náklady na násobení všech tokenů se všemi experty lze snadno paralelizovat mezi více zařízeními. S paralelismem tensorů na prefillérech je u hustých problémů přínos poměrně přímočarý, protože každá hodnost nyní musí provádět méně výpočtů. V případě dekódování přináší datový paralelismus další výhodu nad rámec paralelismu expertů, protože větší počet paralelních požadavků směruje více tokenů ke každému expertovi, čímž se problémy zahustí.

V naší implementaci se v současnosti spoléháme na jádra CUTLASS CUDA/C++ pro maticové násobení. Provedli jsme jejich benchmark na řídkých vstupech pro dekódování s různými schématy kvantování a úrovněmi paralelismu, abychom urcili optimální strategii shardování pro dekodéry. V níže uvedených srovnávacích testech jsou všichni experti aktivováni jediným tokenem.

Zvětšit

Zjistili jsme, že škálování 128 expertů na více než 16 hodností přináší s CUTLASS klesající výnosy, protože náklady na násobení 2 expertů nejsou podstatně nižší než násobení 4. Na Blackwellu je oproti Hopperu zřetelné zlepšení, a to i u suboptimální strategie škálování bloků. Vzhledem k tomu, že nárůst latence o přibližně 5 us mezi EP=8 a EP=16 u operace dispatch/combine je vyvážen poklesem o více než 10 us v nákladech na GEMM, je na systémech GB200 shardování dekodérů na 16 hodností oprávněné, což potvrzují i end-to-end benchmarky.

Kvantování

Blackwell přináší hardwarovou podporu pro nová 8bitová a 4bitová schémata kvantování. Na rozdíl od Hopperu, který se spoléhal na faktory škálování pro jednotlivé tensory nebo bloky, vyžaduje Blackwell mikroskopické škálování (microscaling) k dosažení nejlepší propustnosti předběžného plnění a dekódování. Přestože je schéma škálování bloků používané pro modely jako DeepSeek nebo Kimi k dispozici, mikroskopické škálování je efektivnější.

Nasadili jsme Qwen3 235B se schématem kvantování MXFP8 a po doladění modelu jsme váhy staticky zkonvertovali. Dopad na přesnost byl podobný jako dopad škálování bloků se stochastickým kvantováním, ale poskytovaný výkon byl mnohem lepší, jak ukazují mikrobenchmarky MoE GEMM. Zvážili jsme také schémata kvantování MXFP4 a NVFP4, ačkoliv dopad na přesnost bez tréninku s vědomím kvantování (Quantization-Aware Training) byl pro počáteční přechod z Hopperu na Blackwell příliš významný. Plánujeme tyto formáty podrobněji prozkoumat v budoucí práci.

End-to-end výkon

Provedli jsme benchmark dekodérů nasazení Blackwell Qwen3 235B a porovnali je s našimi předchozími nasazeními Hopper. V tomto nastavení jsme u obou nasazení zvážili škálování bloků, abychom se zaměřili na dopad paralelismu. Prefilléry TP=4 byly pro obě architektury odděleny, aby se izoloval výkon dekódování. Níže uvedený obrázek znázorňuje propustnost dekódování za předpokladu realistické míry přijetí konceptu (draft acceptance rate) poskytované našimi vrstvami MTP.

Zvětšit

Na Hopperu není shardování nasazení na více než 8 GPU životaschopné, protože latence přes InfiniBand, zejména na adaptérech EFA, jsou podstatně pomalejší. Na Blackwellu však dosahujeme podstatně vyšší propustnosti díky větším doménám NVLink.

Počáteční implementace na Blackwellu jsme dosáhli zobecněním stávajících jader Hopper a posunutím výkonu jader založených na NVLink. Budeme dále snižovat náklady na obsluhu Qwen vylepšením kvantování a doladěním výkonu dekódování a propustnosti předběžného plnění ostatních jader v pipeline.

Reference

Příspěvek na blogu o Transfer Engine

Příspěvek na blogu o CuTeDSL

Příspěvek na blogu o Prefill-Disagg

Příspěvek na blogu o spekulativním dekódování

CUTLASS

NVLink

Citace

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