Hébergement de Qwen sur Blackwell

Les racks NVIDIA GB200 NVL72 équipés de GPU NVIDIA Blackwell interconnectés via NVLink 72 voies sont particulièrement adaptés au déploiement de grands modèles de type mélange d'experts (MoE). Dans cet article, nous décrivons la configuration d'inférence utilisée pour les modèles Qwen3 235B post-entraînés, qui prennent en charge une partie du trafic de Perplexity. Nous montrons comment nous avons adapté notre moteur d'inférence interne pour exploiter les cœurs tensoriels avancés et l'interconnexion haut débit des GPU NVIDIA Blackwell. Avec ce matériel, nous traitons un volume de trafic plus important à moindre coût, sans sacrifier la précision des modèles sous-jacents.

Déploiement sur GB200 NVL72

Les racks GB200 NVL72 sont composés de 18 nœuds dotés de 2 CPU NVIDIA Grace basés sur ARM et de 4 GPU basés sur Blackwell, chacun équipé de 180 Go de HBM. Les 72 GPU sont interconnectés via NVLink et 18 ASIC de switch NVLink, offrant une bande passante de 1800 Go/s entre deux pairs et partageant une mémoire suffisante pour héberger des modèles à mille milliards de paramètres. De plus, les adaptateurs InfiniBand ConnectX-7 fournissent une bande passante supplémentaire de 400 Gb/s, tant au sein des nœuds d'un rack qu'entre les racks voisins.

Pour gérer le trafic, nous avons choisi de post-entraîner et de servir les modèles Qwen. Dans cet article, nous nous concentrons sur le modèle Qwen3 235B, mais bon nombre des techniques de service et caractéristiques de performance discutées sont similaires à celles des nouveaux modèles Qwen3.5 397B et 122B vers lesquels nous migrons. En termes de parallélisme, l'attention linéaire est similaire à l'auto-attention complète, et l'implémentation existante de la couche MoE peut être facilement adaptée pour intégrer les nouveaux termes de porte. Afin de maintenir un taux de décodage constant tout en maximisant le débit, nous avons choisi de désagréger le pré-remplissage du décodage, en déployant différentes stratégies de parallélisme pour les deux types de nœuds. La communication entre le pré-remplisseur et le décodeur est gérée via InfiniBand, tandis que la bande passante NVLink est réservée à la communication interne au sein des pré-remplisseurs et des décodeurs. Les caractéristiques de performance des dispositifs Blackwell lors des opérations de multiplication matricielle et de communication inter-dispositifs, explorées dans cet article, déterminent les stratégies de partitionnement utilisées. Par rapport aux GPU NVIDIA Hopper, nous constatons des améliorations noyau par noyau grâce au nombre plus élevé de multiprocesseurs de flux, à une bande passante mémoire accrue et à des latences pair-à-pair plus faibles.

Agrandir

Notre TransferEngine, qui implémente le pré-remplissage désagrégé, a géré un partitionnement arbitraire et potentiellement inégal entre les pré-remplisseurs et les décodeurs. Les caches KV sont organisés en mémoire dans l'ordre HND, avec les têtes dans la dimension principale et les jetons conservés de manière contiguë, afin de permettre à un cache KV partitionné sur un pré-remplisseur d'être davantage divisé ou concaténé à la volée pendant le transfert vers le nœud décodeur.

Pré-remplisseurs

Les nœuds de pré-remplissage reçoivent les jetons d'entrée d'une requête, peuplent les caches KV et les transfèrent aux décodeurs pour poursuivre la génération de texte. Le pré-remplissage est intensif en termes de calcul, car des milliers de jetons appartenant à une séquence sont traités simultanément.

Par conséquent, nous avons trouvé qu'un déploiement à parallélisme tensoriel était approprié, avec le modèle partitionné sur 4 GPU au sein d'un seul nœud GB200, et les projections ainsi que les experts partitionnés (TP=4, EP=4). Étant donné que l'attention et les MLP sont limités par le calcul, les deux bénéficient du parallélisme, en distribuant les experts et les têtes d'attention sur des rangs distincts. Un parallélisme supplémentaire aurait généré des rendements décroissants, car l'amélioration du débit obtenue en hébergeant moins d'experts sur chaque rang (16 au lieu de 32) n'aurait pas compensé le coût supplémentaire d'un all-reduce sur 8 voies et la surcharge liée à la division du code côté hôte sur deux nœuds, nécessitant une communication sur Ethernet.

Qwen3 235B n’a que 4 têtes clé-valeur, ce qui exige que les projections k et v soient répliquées entre des paires de rangs si 8 appareils sont utilisés. Nous aurions pu envisager un découpage plus agressif afin de réduire la quantité de mémoire nécessaire pour stocker les poids sur chaque rang, libérant ainsi de l’espace pour davantage de tokens dans le cache KV. Cependant, nous avons constaté qu’un déploiement plus large n’en valait pas la peine.

En supposant une longueur d'entrée d'environ 6000 jetons, chacun des 128 experts a environ 6000 * 8 / 128 = 375 jetons qui lui sont acheminés, garantissant un problème dense pour le MoE GEMM. Étant donné que cela sature déjà le débit de calcul du dispositif, le parallélisme des données n'est pas nécessaire pour le pré-remplissage.

Malgré le coût croissant de l'attention de manière quadratique, les pré-remplisseurs offrent un débit cohérent, permettant une estimation approximative du nombre de jetons d'entrée pouvant être traités par un nœud par seconde. En s'appuyant sur des mesures suivant le nombre total de jetons d'entrée provenant des requêtes, le nombre de nœuds de pré-remplissage peut être mis à l'échelle pour garantir que le débit global de pré-remplissage est dimensionné en conséquence. Afin d'éviter les files d'attente, le nombre de répliques de pré-remplissage est adapté au nombre total de jetons d'entrée reçus.

Décodeurs

Les nœuds décodeurs reçoivent les caches KV des pré-remplisseurs et génèrent les jetons un par un. Le décodage est généralement limité par la mémoire : avec peu de jetons d'entrée, la multiplication matricielle est entièrement limitée par le coût de chargement des poids de la HBM vers les cœurs tensoriels. En plus d'utiliser une stratégie de partitionnement différente, plusieurs noyaux doivent être ajustés pour mieux paralléliser les calculs et les accès mémoire.

Contrairement au préremplissage, le découpage de l’attention n’est plus bénéfique : répartir les têtes d’attention sur plusieurs appareils signifierait qu’il y a moins d’occasions de parallélisme au sein d’un même appareil. Par conséquent, seuls le parallélisme des données et le parallélisme des experts sont utilisés : les experts sont répartis sur plusieurs appareils, mais chaque appareil gère ses propres caches KV et requêtes. Sans parallélisme de tenseur, la taille du cache KV par token sur un appareil est plus grande. Cependant, de l’espace est libéré en mémoire en plaçant moins d’experts sur un seul nœud. Contrairement à Hopper, où nous avons limité le parallélisme de tenseur au sein d’un seul domaine NVLink dans un nœud à 8 GPU, sur Blackwell, nous avons constaté qu’il est avantageux d’étendre sur plusieurs nœuds au sein d’un domaine, en utilisant jusqu’à 16 appareils.

Afin de maximiser le débit, les décodeurs traitent un nombre plus important de requêtes simultanément. Même si les requêtes supplémentaires entraînent une surcharge minimale dans les couches MoE et autres projections, elles augmentent de manière disproportionnée le coût de l'attention. Pour maintenir une vitesse de décodage minimale raisonnable, le nombre de nœuds décodeurs est mis à l'échelle pour maintenir les tailles de lots par décodeur sous un certain seuil.

De manière similaire aux déploiements Hopper précédents, nous utilisons le décodage spéculatif avec des couches MTP entraînées en interne pour augmenter les taux de décodage. Heureusement, le matériel et les frameworks de programmation sous-jacents sont suffisamment similaires pour partager entièrement l'implémentation entre les deux architectures.

Communication intra-nœud et inter-nœud

La principale différence entre le GB200 NVL72 et les nœuds Hopper précédents est le grand domaine NVLink, qui permet une communication pair-à-pair au-delà de la limite précédente de 8 dispositifs. Même si les dispositifs Blackwell ont été déployés dans des nœuds à 8 GPU, il est très utile de mettre à l'échelle sur plusieurs nœuds via NVLink par rapport au réseau InfiniBand plus lent.

Sur les nœuds de pré-remplissage, nous nous appuyons sur la communication all-reduce au sein des couches d'attention et sur une réduction parallèle par expert qui ressemble étroitement à l'all-reduce. Sur 4 GPU, nous tirons parti à la fois de NVLink et de NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol) : en plus de la bande passante pair-à-pair, nous exploitons également les réductions dans les switches NVLink pour réduire davantage les latences et mettre en œuvre des diffusions rapides. Sur les nœuds décodeurs, une implémentation personnalisée de dispatch et combine all-to-all sur NVLink est utilisée. Les noyaux ont été implémentés en interne en utilisant CuTeDSL et des mappages cuMem ou des mappages multicast.

All-Reduce

Les pré-remplisseurs effectuent une opération all-reduce dans la projection de sortie de la couche d'attention, sommant les contributions des têtes partitionnées sur les rangs participants. Le parallélisme tensoriel n'est efficace que lorsque le coût de la surcharge all-reduce est compensé par la latence réduite des problèmes de multiplication matricielle plus petits. Cette hypothèse se vérifie généralement pour le pré-remplissage.

Sur les systèmes NVIDIA HGX H200 et GB200 NVL72 de classe centre de données, les GPU sont généralement connectés via des switches NVLink. Outre le routage, les switches peuvent effectuer des opérations de réduction sur les dispositifs connectés via SHARP. Après avoir créé des mappages mémoire et les avoir enregistrés dans un groupe multicast à l'aide des API CUDA, les noyaux peuvent utiliser multicast.ld_reduce et multicast.st pour agréger et diffuser des valeurs à travers les switches. Afin de créer une base et des composants réutilisables pouvant être fusionnés dans d'autres noyaux, nous maintenons en interne un noyau all-reduce CuTeDSL utilisant ces primitives.

Dans un système avec N GPU réduisant B octets, une implémentation triviale verrait un pair charger des valeurs depuis tous les autres pairs, pour un total de N * (N - 1) * B octets de trafic de lecture. Une implémentation plus efficace diviserait les données à réduire entre les pairs, chacun réduisant une tranche de l'entrée, puis la diffusant au reste. Cela aboutit à (N - 1) * (B / N) octets lus dans un pair et diffusés au reste, pour un total de (N - 1) * B * 2 lectures et écritures, réduisant le trafic sur les switches.

Agrandir

Avec SHARP, la réduction et la diffusion peuvent être effectuées plus efficacement : au lieu de lire (N - 1) * (B / N) octets dans un dispositif pour l'accumulation locale, seuls B / N sont déplacés depuis le switch, car il effectue lui-même la réduction en utilisant les données des pairs. Pour la diffusion, il existe une amélioration similaire, car le nombre de transactions entre un GPU et le switch sur les canaux NVLink est considérablement réduit. Sans SHARP, le dispositif accumulateur effectuerait (N - 1) * (B / N) transactions via NVLink avec le switch, le switch lisant la même quantité de données depuis les pairs, pour un total de 2 * (N - 1) * (B / N) transactions. Avec SHARP, B / N transactions sont effectuées entre le GPU et le switch, et (N - 1) * (B / N) supplémentaires avec les pairs, pour un total de B transactions.

En raison de sa simplicité, SHARP est un outil précieux, car il fournit une implémentation matérielle directe pour un algorithme. Même si les transferts sont réduits d'une fraction théorique de N / (2 * (N - 1)) (ce qui équivaut à 33 % avec 4 pairs), en pratique, nous observons une amélioration de 10 % des latences de pré-remplissage et de décodage sur les systèmes H200 et GB200 NVL72.

Agrandir

MoE Dispatch - Combine

Pour les modèles MoE, les noyaux dispatch et combine déplacent et regroupent les jetons pour les problèmes MoE GEMM ultérieurs entre les pairs, effectuant une accumulation pondérée par la suite dans combine. Nous avons adapté nos noyaux Dispatch et Combine existants à Blackwell, en les portant vers CuTeDSL, en ajustant les allocations de blocs et en les spécialisant agressivement entre le pré-remplissage et le décodage.

Expert Parallel

Le noyau parallèle par expert (EP) est utilisé dans les pré-remplisseurs. Étant donné que ses entrées sont répliquées sur tous les rangs, le noyau dispatch doit simplement sélectionner les jetons acheminés vers les experts sur le rang actuel. Il agrège les informations de routage et prépare les jetons dans des tampons utilisés comme entrées pour MoE GEMM. Le noyau combine effectue d'abord une accumulation locale entre les contributions des jetons acheminés vers les experts sur le rang actuel, puis il effectue un all-reduce sur tous les rangs.

Pour le décodage, tout le noyau est fusionné en un seul. Le noyau de pré-remplissage est divisé en plusieurs noyaux, car le routage et l'all-reduce nécessitent moins de blocs que l'étape de combine locale. Avec CuTeDSL, nous avons pu créer une bibliothèque générique pour SHARP et l'all-reduce NVLink ainsi que la synchronisation pair-à-pair, en la composant dans les noyaux all-reduce et parallèle par expert.

Agrandir

En termes de performances, nous observons que Blackwell est nettement plus rapide que Hopper, grâce à des vitesses de transfert améliorées, une bande passante mémoire plus élevée et un meilleur débit de calcul. Partitionnés sur 8 dispositifs et plusieurs nœuds sur GB200 (EP=8), les noyaux deviennent plus rapides car l'accumulation locale s'exécute sur beaucoup moins de jetons sur chaque dispositif et, avec SHARP, le coût de la réduction sur plus de rangs est mieux mis à l'échelle. Cependant, en pratique, nous limitons le parallélisme à 4 dispositifs, car ces accélérations ne sont pas universelles pour tous les noyaux.

Data Parallel and Expert Parallel

Le noyau parallèle aux données et parallèle aux experts (DP-EP) est utilisé dans les décodeurs parallèles aux données. Il diffuse différents jetons depuis tous les rangs vers les experts, transférant les résultats vers les rangs d'origine et les accumulant. Puisqu'il implémente un problème all-to-all parcimonieux, il repose uniquement sur NVLink.

Sur Hopper, ce noyau est limité à 8 dispositifs au sein du domaine NVLink d'un seul nœud. Cependant, sur les systèmes GB200, nous pouvons le mettre à l'échelle sur tout un rack. La majeure partie du code est réutilisée. La seule différence est l'utilisation de handles fabric pour échanger les informations des pairs via IMEX pour la configuration initiale.

Agrandir

Comme les tailles de transfert encourues lors du décodage sont petites, elles sont loin de saturer la bande passante NVLink et sont plutôt limitées par la latence. Les latences sont de l'ordre de quelques dizaines de microsecondes et restent relativement stables à mesure que le nombre de pairs augmente, ce qui nous permet de répartir un déploiement sur un plus grand nombre de dispositifs sans encourir de latence supplémentaire significative.

MoE GEMM

Les modèles MoE bénéficient du parallélisme des experts, car le coût de la multiplication de tous les jetons avec tous les experts peut être facilement parallélisé sur plusieurs dispositifs. Avec le parallélisme tensoriel sur les pré-remplisseurs, sur les problèmes denses, l'avantage est assez simple, car chaque rang doit désormais effectuer moins de calculs. Dans le cas du décodage, le parallélisme des données offre un avantage supplémentaire en plus du parallélisme des experts, car le plus grand nombre de requêtes parallèles achemine plus de jetons vers chaque expert, densifiant les problèmes.

Dans notre implémentation, nous nous appuyons actuellement sur les noyaux CUDA/C++ CUTLASS pour la multiplication matricielle. Nous les avons évalués sur des entrées de décodage parcimonieuses avec divers schémas de quantification et niveaux de parallélisme afin de décider de la stratégie de partitionnement optimale pour les décodeurs. Dans les benchmarks ci-dessous, tous les experts sont activés avec un seul jeton.

Agrandir

Nous avons constaté que le passage à l'échelle de 128 experts sur plus de 16 rangs génère des rendements décroissants avec CUTLASS, car le coût de la multiplication de 2 experts n'est pas sensiblement inférieur à la multiplication de 4. Il y a une nette amélioration sur Blackwell par rapport à Hopper, même sur la stratégie de mise à l'échelle par bloc sous-optimale. Étant donné que l'augmentation de latence d'environ 5 µs entre EP=8 et EP=16 du dispatch/combine est compensée par une diminution de plus de 10 µs du coût de GEMM, sur les systèmes GB200, le partitionnement des décodeurs sur 16 rangs est justifié, comme le confirment également les benchmarks de bout en bout.

Quantification

Blackwell introduit un support matériel pour de nouveaux schémas de quantification 8 bits et 4 bits. Contrairement à Hopper, qui reposait sur des facteurs de mise à l'échelle par tenseur ou par bloc, Blackwell nécessite une micro-mise à l'échelle pour obtenir le meilleur débit de pré-remplissage et de décodage. Bien que le schéma de mise à l'échelle par bloc utilisé pour des modèles tels que DeepSeek ou Kimi soit disponible, la micro-mise à l'échelle est plus efficace.

Nous avons déployé Qwen3 235B avec le schéma de quantification MXFP8, en convertissant les poids statiquement après le réglage fin du modèle. L'impact sur la précision était similaire à l'impact de la mise à l'échelle par bloc avec quantification stochastique, mais les performances fournies étaient bien meilleures, comme l'illustrent les micro-benchmarks MoE GEMM. Nous avons également envisagé les schémas de quantification MXFP4 et NVFP4, bien que l'impact sur la précision sans entraînement tenant compte de la quantification était trop important pour la transition initiale de Hopper vers Blackwell. Nous prévoyons d'explorer ces formats plus en profondeur dans de futurs travaux.

Performance de bout en bout

Nous avons évalué les décodeurs des déploiements Blackwell Qwen3 235B et les avons comparés à nos déploiements Hopper précédents. Dans cette configuration, nous avons pris en compte la mise à l'échelle par bloc sur les deux déploiements afin de nous concentrer sur l'impact du parallélisme. Les pré-remplisseurs TP=4 ont été séparés pour les deux architectures afin d'isoler la performance de décodage. La figure ci-dessous illustre le débit de décodage en supposant un taux d'acceptation de brouillon réaliste fourni par nos couches MTP.

Agrandir

Sur Hopper, le partitionnement du déploiement sur plus de 8 GPU n'est pas viable, car les latences sur InfiniBand, en particulier sur les adaptateurs EFA, sont nettement plus lentes. Cependant, sur Blackwell, nous obtenons un débit nettement plus élevé, grâce aux domaines NVLink plus larges.

Nous avons obtenu une implémentation initiale de Blackwell en généralisant les noyaux Hopper existants et en poussant les performances des noyaux basés sur NVLink. Nous réduirons davantage le coût de service de Qwen en améliorant la quantification et en affinant la performance de décodage et le débit de pré-remplissage des autres noyaux du pipeline.

Références

Article de blog sur le moteur de transfert

Article de blog sur CuTeDSL

Article de blog sur le pré-remplissage désagrégé

Article de blog sur le décodage spéculatif

CUTLASS

NVLink

Citation

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