Hosting Qwen na architekturze Blackwell

Szafy NVIDIA GB200 NVL72 z procesorami graficznymi NVIDIA Blackwell połączonymi za pomocą 72-kierunkowego NVLink są wyjątkowo dobrze przystosowane do wdrażania dużych modeli typu mixture-of-experts (MoE). W tym wpisie na blogu opisujemy konfigurację wnioskowania obsługującą dotrenowane modele Qwen3 235B, które wspierają część ruchu Perplexity. Pokazujemy, w jaki sposób dostosowaliśmy nasz wewnętrzny silnik wnioskowania, aby wykorzystać zaawansowane rdzenie tensorowe i szybkie połączenia procesorów graficznych NVIDIA Blackwell. Dzięki temu sprzętowi obsługujemy większy ruch przy niższych kosztach, bez poświęcania dokładności bazowych modeli.

Szafy GB200 NVL72 składają się z 18 węzłów z 2 procesorami NVIDIA Grace opartymi na architekturze ARM oraz 4 procesorami graficznymi opartymi na architekturze Blackwell, z których każdy jest wyposażony w 180 GB pamięci HBM. 72 procesory graficzne są połączone za pośrednictwem NVLink i 18 układów ASIC NVLink Switch, zapewniając przepustowość 1800 GB/s między dowolnymi dwoma punktami i współdzieląc wystarczającą ilość pamięci do obsługi modeli z bilionami parametrów. Ponadto adaptery ConnectX-7 InfiniBand zapewniają dodatkowe 400 Gb/s przepustowości zarówno wewnątrz węzłów szafy, jak i między sąsiednimi szafami.

Aby obsłużyć ruch, zdecydowaliśmy się na dotrenowanie i serwowanie modeli Qwen. W tym wpisie na blogu skupiamy się na Qwen3 235B, ale wiele z omawianych technik serwowania i charakterystyk wydajnościowych jest podobnych do tych w nowszych modelach Qwen3.5 397B i 122B, na które migrujemy. Pod względem równoległości, uwaga liniowa jest podobna do pełnej uwagi własnej (self-attention), a istniejącą implementację warstwy MoE można łatwo dostosować do obsługi nowych członów bramkujących. Aby utrzymać spójną szybkość dekodowania przy jednoczesnej maksymalizacji przepustowości, zdecydowaliśmy się rozdzielić prefill od dekodowania, wdrażając różne strategie równoległości dla obu rodzajów węzłów. Komunikacja między prefillerem a dekoderem odbywa się za pośrednictwem InfiniBand, podczas gdy przepustowość NVLink jest zarezerwowana dla komunikacji wewnątrz prefillerów i dekoderów. Charakterystyka wydajnościowa urządzeń Blackwell podczas wykonywania mnożenia macierzy i komunikacji między urządzeniami, badana w tym wpisie na blogu, determinuje stosowane strategie shardingowe. W porównaniu z procesorami graficznymi NVIDIA Hopper, obserwujemy poprawę jądro po jądrze dzięki większej liczbie procesorów strumieniowych, zwiększonej przepustowości pamięci i niższym opóźnieniom typu peer-to-peer.

Rozdzielone prefill i decode, z InfiniBand między prefillerami i decoderami oraz NVLink wewnątrz każdego wdrożenia.

Nasz TransferEngine, który implementuje rozproszony prefill, obsługiwał dowolny i potencjalnie niedopasowany sharding między prefillerami a dekoderami. Pamięci podręczne KV są rozmieszczone w pamięci w porządku HND, z głowicami w wiodącym wymiarze i tokenami utrzymywanymi w sposób ciągły, aby umożliwić dalszy podział lub konkatenację sharded pamięci podręcznej KV na prefillerze w trakcie przesyłania do węzła dekodera.

Węzły prefillerów odbierają tokeny wejściowe żądania, wypełniając pamięci podręczne KV i przesyłając je do dekoderów w celu kontynuacji generowania tekstu. Prefill jest obliczeniowo intensywny, ponieważ tysiące tokenów należących do sekwencji są przetwarzane w tym samym czasie.

W rezultacie stwierdziliśmy, że wdrożenie z równoległością tensorową jest odpowiednie, przy modelu sharded na 4 procesory graficzne w ramach pojedynczego węzła GB200 oraz projekcjach i ekspertach sharded (TP=4, EP=4). Ponieważ zarówno uwaga, jak i sieci MLP są ograniczone obliczeniowo, oba te elementy korzystają z równoległości, rozdzielając ekspertów i głowice uwagi na osobne rangi. Dalsza równoległość przyniosłaby malejące korzyści, ponieważ wzrost przepustowości wynikający z hostowania mniejszej liczby ekspertów na każdej randze (16 zamiast 32) nie zrównoważyłby dodatkowego kosztu 8-kierunkowej operacji all-reduce oraz narzutu wynikającego z podziału kodu po stronie hosta na dwa węzły, co wymaga komunikacji przez Ethernet.

Qwen3 235B ma tylko 4 głowice klucz-wartość, co wymaga replikacji projekcji k i v między parami rang, jeśli używanych jest 8 urządzeń. Mogliśmy rozważyć bardziej agresywny sharding, aby zmniejszyć ilość pamięci potrzebnej do przechowywania wag na każdej randze, zwalniając Przestrzeń na większą liczbę tokenów w pamięci podręcznej KV. Uznaliśmy jednak, że szersze wdrożenie nie jest opłacalne.

Zakładając długość wejścia wynoszącą około 6000 tokenów, każdy ze 128 ekspertów otrzymuje około 6000 * 8 / 128 = 375 tokenów, co zapewnia gęsty problem dla MoE GEMM. Ponieważ to już nasyca przepustowość obliczeniową urządzenia, równoległość danych nie jest potrzebna dla prefillu.

Pomimo kwadratowo rosnącego kosztu uwagi, prefillery zapewniają spójną przepustowość, co pozwala na przybliżone oszacowanie liczby tokenów wejściowych, które mogą zostać przetworzone przez węzeł w ciągu sekundy. Opierając się na metrykach śledzących całkowitą liczbę tokenów wejściowych z żądań, liczbę węzłów prefillera można skalować, aby zapewnić odpowiednie dopasowanie całkowitej przepustowości prefillu. Aby uniknąć kolejkowania, liczba replik prefillera jest dopasowywana do całkowitej liczby otrzymanych tokenów wejściowych.

Węzły dekodera odbierają pamięci podręczne KV od prefillerów i generują tokeny jeden po drugim. Dekodowanie jest zazwyczaj ograniczone pamięcią: przy niewielkiej liczbie tokenów wejściowych, mnożenie macierzy jest w całości ograniczone kosztem ładowania wag z HBM do rdzeni tensorowych. Oprócz zastosowania innej strategii shardingowej, należy dostosować kilka jąder, aby lepiej zrównoleglić obliczenia i dostęp do pamięci.

W przeciwieństwie do prefillu, sharding uwagi nie jest już korzystny: dzielenie głowic uwagi na wiele urządzeń oznaczałoby mniej możliwości równoległości wewnątrz jednego urządzenia. W rezultacie stosuje się tylko równoległość danych i równoległość ekspertów: eksperci są sharded na wiele urządzeń, ale każde urządzenie zarządza własnymi pamięciami podręcznymi KV i żądaniami. Bez równoległości tensorowej rozmiar pamięci podręcznej KV na token na urządzeniu jest większy. Jednak Przestrzeń w pamięci jest zwalniana dzięki umieszczeniu mniejszej liczby ekspertów na pojedynczym węźle. W odróżnieniu od Hoppera, gdzie ograniczyliśmy równoległość tensorową w ramach jednej domeny NVLink w 8-procesorowym węźle, na Blackwellu stwierdziliśmy, że korzystne jest rozszerzenie operacji na wiele węzłów w ramach jednej domeny, przy użyciu do 16 urządzeń.

Aby zmaksymalizować przepustowość, dekodery przetwarzają większą liczbę żądań jednocześnie. Mimo że dodatkowe żądania wiążą się z minimalnym narzutem w warstwach MoE i innych projekcjach, nieproporcjonalnie zwiększają one koszt uwagi. Aby utrzymać rozsądną minimalną szybkość dekodowania, liczba węzłów dekodera jest skalowana w celu utrzymania rozmiarów partii na dekoder poniżej określonego progu.

Podobnie jak w poprzednich wdrożeniach na Hopperze, używamy dekodowania spekulatywnego z warstwami MTP opracowanymi wewnętrznie, aby zwiększyć szybkość dekodowania. Na szczęście podstawowy sprzęt i frameworki programistyczne są wystarczająco podobne, aby w pełni współdzielić implementację między obiema architekturami.

Główną różnicą między GB200 NVL72 a poprzednimi węzłami Hopper jest duża domena NVLink, która umożliwia komunikację peer-to-peer poza poprzednim limitem 8 urządzeń. Mimo że urządzenia Blackwell zostały wdrożone w węzłach 8-GPU, skalowanie na wiele węzłów przez NVLink w porównaniu do wolniejszej sieci InfiniBand przynosi dużą wartość.

W węzłach prefillera polegamy na komunikacji all-reduce w warstwach uwagi oraz na redukcji równoległej ekspertów, która ściśle przypomina all-reduce. W ramach 4 procesorów graficznych wykorzystujemy zarówno NVLink, jak i NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): oprócz przepustowości peer-to-peer, wykorzystujemy również redukcje w przełącznikach NVLink, aby jeszcze bardziej skrócić opóźnienia i zaimplementować szybkie rozgłaszanie (broadcast). W węzłach dekodera używana jest niestandardowa implementacja dispatch i combine typu all-to-all przez NVLink. Jądra zostały zaimplementowane wewnętrznie przy użyciu CuTeDSL oraz mapowań cuMem lub mapowań multicast.

Prefillery wykonują operację all-reduce w projekcji wyjściowej warstwy uwagi, sumując wkłady głowic sharded między uczestniczącymi rangami. Równoległość tensorowa jest skuteczna tylko wtedy, gdy koszt narzutu all-reduce jest kompensowany przez zmniejszone opóźnienie mniejszych problemów mnożenia macierzy. To założenie zazwyczaj sprawdza się w przypadku prefillu.

W systemach NVIDIA HGX H200 i GB200 NVL72 klasy centrum danych procesory graficzne są zazwyczaj połączone za pomocą przełączników NVLink. Oprócz routingu, przełączniki mogą wykonywać operacje redukcji na połączonych urządzeniach za pośrednictwem SHARP. Po utworzeniu mapowań pamięci i zarejestrowaniu ich w grupie multicast przy użyciu interfejsów API CUDA, jądra mogą używać multicast.ld_reduce i multicast.st do agregowania i rozgłaszania wartości przez przełączniki. Aby stworzyć fundament i komponenty wielokrotnego użytku, które można scalać z innymi jądrami, wewnętrznie utrzymujemy jądro all-reduce CuTeDSL przy użyciu tych prymitywów.

W systemie z N procesorami graficznymi redukującymi B bajtów, trywialna implementacja polegałaby na pobieraniu wartości przez jednego peera od wszystkich pozostałych, co daje łącznie N * (N - 1) * B bajtów ruchu odczytu. Bardziej wydajna implementacja podzieliłaby dane do zredukowania między peery, gdzie każdy redukuje wycinek danych wejściowych, a następnie rozgłasza go do reszty. Skutkuje to (N - 1) * (B / N) bajtami odczytanymi do peera i rozgłoszonymi do reszty, co daje łącznie (N - 1) * B * 2 odczytów i zapisów, redukując ruch przez przełączniki.

Ruch all-reduce w NVSwitch z akumulacją po stronie GPU i redukcją wspomaganą przez przełącznik.

Dzięki SHARP redukcja i rozgłaszanie mogą być wykonywane wydajniej: zamiast wczytywać (N - 1) * (B / N) bajtów do urządzenia w celu lokalnej akumulacji, ze przełącznika przesyłane jest tylko B / N, ponieważ sam przełącznik wykonuje redukcję przy użyciu danych od peerów. W przypadku rozgłaszania występuje podobna poprawa, ponieważ liczba transakcji między procesorem graficznym a przełącznikiem przez kanały NVLink jest znacznie ograniczona. Bez SHARP urządzenie akumulujące wykonywałoby (N - 1) * (B / N) transakcji przez NVLink z przełącznikiem, przy czym przełącznik odczytywałby taką samą ilość danych od peerów, co daje łącznie 2 * (N - 1) * (B / N) transakcji. Z SHARP wykonywanych jest B / N transakcji między procesorem graficznym a przełącznikiem oraz dodatkowe (N - 1) * (B / N) z peerami, co daje łącznie B transakcji.

Dzięki swojej prostocie SHARP jest cennym narzędziem, ponieważ zapewnia bezpośrednią implementację sprzętową algorytmu. Mimo że transfery są zredukowane o teoretyczną frakcję N / (2 * (N - 1)) (co przy 4 peerach wynosi 33%), w praktyce obserwujemy 10% poprawę opóźnień zarówno prefillu, jak i dekodowania w systemach H200 i GB200 NVL72.

Opóźnienie dispatch NVLink i NVLS na H200 i GB200 przy TP=4 z 16 tys. tokenów.

W przypadku modeli MoE jądra dispatch i combine przemieszczają i grupują tokeny dla kolejnych problemów MoE GEMM między peerami, wykonując następnie ważoną akumulację w combine. Dostosowaliśmy nasze istniejące jądra Dispatch i Combine do Blackwell, portując je do CuTeDSL, dostrajając alokacje bloków i agresywnie specjalizując je między prefill i dekodowaniem.

Jądro równoległości ekspertów (EP) jest używane w prefillerach. Ponieważ jego dane wejściowe są replikowane na wszystkie rangi, jądro dispatch musi po prostu wybrać tokeny skierowane do ekspertów na bieżącej randze. Agreguje ono informacje o routingu i przygotowuje tokeny w buforach używanych jako dane wejściowe dla MoE GEMM. Jądro combine najpierw wykonuje lokalną akumulację między wkładami tokenów skierowanych do ekspertów na bieżącej randze, a następnie wykonuje all-reduce na wszystkich rangach.

W przypadku dekodowania całe jądro jest scalone w jedno. Jądro prefill jest podzielone na wiele jąder, ponieważ routing i all-reduce wymagają mniej bloków niż lokalny krok combine. Dzięki CuTeDSL mogliśmy zbudować bibliotekę generyczną zarówno dla SHARP, jak i NVLink all-reduce oraz synchronizacji peer-to-peer, włączając ją zarówno do jąder all-reduce, jak i równoległości ekspertów.

Opóźnienie dispatch i combine dla prefillu w trybie expert-parallel na H200 i GB200 w różnych konfiguracjach expert-parallel.

Pod względem wydajności obserwujemy, że Blackwell jest znacznie szybszy niż Hopper dzięki lepszym szybkościom transferu, wyższej przepustowości pamięci i lepszej przepustowości obliczeniowej. Sharded na 8 urządzeń i wiele węzłów na GB200 (EP=8), jądra stają się szybsze, ponieważ lokalna akumulacja działa na znacznie mniejszej liczbie tokenów na każdym urządzeniu, a dzięki SHARP koszt redukcji na większej liczbie rang lepiej się skaluje. Jednak w praktyce ograniczamy równoległość do 4 urządzeń, ponieważ te przyspieszenia nie są uniwersalne dla wszystkich jąder.

Jądro równoległości danych i równoległości ekspertów (DP-EP) jest używane w dekoderach z równoległością danych. Rozgłasza ono różne tokeny ze wszystkich rang do ekspertów, przesyłając wyniki do oryginalnych rang i akumulując je. Ponieważ implementuje rzadki problem typu all-to-all, opiera się wyłącznie na NVLink.

Na Hopperze to jądro jest ograniczone do 8 urządzeń w domenie NVLink pojedynczego węzła. Jednak w systemach GB200 możemy skalować je na całą szafę. Większość kodu jest ponownie wykorzystywana. Jedyną różnicą jest użycie uchwytów fabric do wymiany informacji o peerach przez IMEX w ramach wstępnej konfiguracji.

Opóźnienie dispatch i combine na GB200 w konfiguracjach data-parallel i expert-parallel.

Ponieważ rozmiary transferów podczas dekodowania są małe, są one dalekie od nasycenia przepustowości NVLink i są zamiast tego ograniczone przez opóźnienia. Opóźnienia wynoszą dziesiątki mikrosekund i pozostają stosunkowo stabilne wraz ze wzrostem liczby peerów, co pozwala nam rozszerzyć wdrożenie na większą liczbę urządzeń bez ponoszenia znaczących dodatkowych opóźnień.

Modele MoE korzystają z równoległości ekspertów, ponieważ koszt mnożenia wszystkich tokenów przez wszystkich ekspertów można łatwo zrównoleglić na wielu urządzeniach. Przy równoległości tensorowej na prefillerach w gęstych problemach korzyść jest dość oczywista, ponieważ każda ranga musi teraz wykonać mniej obliczeń. W przypadku dekodowania równoległość danych zapewnia dodatkową korzyść ponad równoległość ekspertów, ponieważ większa liczba równoległych żądań kieruje więcej tokenów do każdego eksperta, zagęszczając problemy.

W naszej implementacji obecnie polegamy na jądrach CUTLASS CUDA/C++ do mnożenia macierzy. Przeprowadziliśmy ich benchmarki na rzadkich danych wejściowych dekodowania z różnymi schematami kwantyzacji i poziomami równoległości, aby podjąć decyzję o optymalnej strategii shardingowej dla dekoderów. W poniższych benchmarkach wszyscy eksperci są aktywowani pojedynczym tokenem.

Opóźnienie Grouped MoE GEMM w różnych konfiguracjach expert-parallel i schematach kwantyzacji na H200 i GB200.

Odkryliśmy, że skalowanie 128 ekspertów na więcej niż 16 rang przynosi malejące korzyści w przypadku CUTLASS, ponieważ koszt mnożenia 2 ekspertów nie jest znacznie niższy niż mnożenia 4. Na Blackwellu widać wyraźną poprawę w stosunku do Hoppera, nawet w przypadku suboptymalnej strategii skalowania blokowego. Ponieważ wzrost opóźnienia o około 5 us między EP=8 a EP=16 dla dispatch/combine jest równoważony przez spadek o ponad 10 us w koszcie GEMM, w systemach GB200 sharding dekoderów na 16 rang jest uzasadniony, co potwierdzają również kompleksowe benchmarki.

Blackwell wprowadza wsparcie sprzętowe dla nowych 8-bitowych i 4-bitowych schematów kwantyzacji. W przeciwieństwie do Hoppera, który opierał się na czynnikach skalowania per-tensor lub per-block, Blackwell wymaga mikro-skalowania, aby osiągnąć najlepszą przepustowość prefillu i dekodowania. Chociaż schemat skalowania blokowego używany dla modeli takich jak DeepSeek czy Kimi jest dostępny, mikro-skalowanie jest bardziej wydajne.

Wdrożyliśmy Qwen3 235B ze schematem kwantyzacji MXFP8, statycznie konwertując wagi po dostrojeniu modelu. Wpływ na dokładność był podobny do wpływu skalowania blokowego z kwantyzacją stochastyczną, ale uzyskana wydajność była znacznie lepsza, co ilustrują mikro-benchmarki MoE GEMM. Rozważaliśmy również schematy kwantyzacji MXFP4 i NVFP4, chociaż wpływ na dokładność bez Quantization-Aware Training był zbyt znaczący dla początkowej zmiany z Hoppera na Blackwella. Planujemy dokładniej zbadać te formaty w przyszłych pracach.

Przeprowadziliśmy benchmarki dekoderów wdrożeń Blackwell Qwen3 235B i porównaliśmy je z naszymi poprzednimi wdrożeniami na Hopperze. W tej konfiguracji rozważaliśmy skalowanie blokowe dla obu wdrożeń, aby skupić się na wpływie równoległości. Prefillery TP=4 zostały rozdzielone dla obu architektur w celu wyizolowania wydajności dekodowania. Poniższy rysunek ilustruje przepustowość dekodowania przy założeniu realistycznego współczynnika akceptacji szkicu (draft acceptance rate) dostarczanego przez nasze warstwy MTP.

Szybkość dekodowania i przepustowość na GPU dla Qwen3 235B FP8 w różnych konfiguracjach expert-parallel na H200 i GB200, przy założeniu długości akceptacji draftu 0,8.

Na Hopperze sharding wdrożenia na więcej niż 8 procesorów graficznych nie jest opłacalny, ponieważ opóźnienia w sieci InfiniBand, zwłaszcza na adapterach EFA, są znacznie większe. Jednak na Blackwellu osiągamy znacznie wyższą przepustowość dzięki większym domenom NVLink.

Osiągnęliśmy wstępną implementację na Blackwellu poprzez uogólnienie istniejących jąder Hoppera i zwiększenie wydajności jąder opartych na NVLink. Będziemy dalej obniżać koszt serwowania Qwen poprzez poprawę kwantyzacji oraz dostrajanie wydajności dekodowania i przepustowości prefillu pozostałych jąder w potoku.

Wpis na blogu Transfer Engine

Wpis na blogu CuTeDSL

Wpis na blogu Prefill-Disagg

Wpis na blogu Speculative Decoding

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

Wdrażanie na GB200 NVL72

Prefillery

Dekodery

Komunikacja wewnątrz- i międzywęzłowa

All-Reduce

MoE Dispatch - Combine

Równoległość ekspertów

Równoległość danych i równoległość ekspertów

MoE GEMM

Kwantyzacja

Wydajność kompleksowa

Referencje

Cytat