Latence r&e9duite et débit accru avec le déploiement multinœud de DeepSeek

Dans la plupart des systèmes, la latence et le débit sont souvent des objectifs contradictoires qui nécessitent des compromis lors de la conception et du déploiement. Par exemple, dans les grands modèles de langage denses, l'augmentation de la taille des lots peut améliorer le débit, mais augmente aussi la latence; l'augmentation du parallélisme de tenseurs au sein d'une seule machine peut réduire la latence, mais diminue le nombre de réplicas, ce qui entraîne un débit plus faible.

Les modèles de mélange d'experts (MoE), tels que DeepSeek-V3/R1, ont récemment démontré d'excellentes capacités et une grande efficacité opérationnelle. Par exemple, le modèle DeepSeek-V3/R1 compte 671 milliards de paramètres au total, mais chaque jeton n'utilise que 37 milliards de paramètres lors de l'inférence. Cette architecture de modèle présente à la fois des défis et des opportunités pour les systèmes d'inférence.

Cet article démontre que, contrairement aux systèmes conventionnels, les modèles MoE comme DeepSeek-V3/R1 peuvent atteindre simultanément un débit plus élevé et une latence plus faible lors de l'utilisation d'un plus grand nombre de processeurs graphiques (GPU) dans des déploiements multinœuds dans la plupart des scénarios.

Architectures de déploiement

Agrandir

Agrandir

En raison du grand nombre de petits experts que comporte le modèle, les déploiements doivent être r&e9partis sur plusieurs appareils. Nous avons examiné à la fois les déploiements sur un nœud unique avec 8 GPU H200 et les déploiements multinœuds sur 8 GPU H100.

Ces deux architectures de déploiement mettent à profit le parallélisme des données, orchestré par notre planificateur de requ&eates interne. L'implémentation du parallélisme des données implique le lancement de plusieurs instances de moteurs d'inférence, chacune fonctionnant de manière indépendante pour traiter et maintenir les requ&eates. Le planificateur de requ&eates, qui communique avec le moteur par l'intermédiaire de gRPC, est chargé de r&e9partir les requ&eates de manière aussi uniforme que possible, tout en facilitant la r&e9utilisation du cache KV et en envoyant les requ&eates avec un préfixe partiellement correspondant aux serveurs contenant le cache. Les instances de moteurs ne s'&e9tendent pas sur plusieurs nœuds. Elles peuvent facultativement utiliser le parallélisme de tenseurs pour fractionner l'attention sur plusieurs appareils. Les instances sont interconnectées via NVLink pour un nœud unique ou InfiniBand pour les déploiements multinœuds, ce qui permet de distribuer et de collecter les experts.

La configuration de déploiement sur un nœud unique offre une latence supérieure avec de petites tailles de lots; cependant, les performances se dégradent rapidement en cas de charge accrue.

Pour déployer le moteur de service, nous lançons un module (pod) par nœud h&e9bergeant plusieurs instances de moteur. PyTorch gère la mise en place de la communication distribuée et la n&e9gociation de l'initialisation de NVSHMEM. Pour la communication, nous nous appuyons sur des noyaux CUDA personnalisés décrits dans un billet de blogue préc&e9dent. L'implémentation des deux déploiements est pratiquement identique, le modèle sélectionnant les noyaux appropriés à utiliser en fonction de la structure qui met en œuvre le parallélisme des experts.

Techniques de parallélisation

Avant d'aborder nos comparaisons de performances, il est essentiel de comprendre les principales stratégies de parallélisation qui permettent de déployer des modèles MoE massifs comme DeepSeek-V3/R1.

Parallélisme de tenseurs

Dans le cadre de l'inférence par grands modèles de langage (LLM), le parallélisme de tenseurs (TP) est g&e9néralement utilisé pour r&e9duire l'utilisation de la m&e9moire et le volume de calcul par GPU, ce qui permet de r&e9duire la latence. En règle g&e9n&e9rale, nous pouvons fractionner les projections Linear dans les couches d'attention et les couches perceptuelles multicouches (MLP) selon les dimensions des lignes ou des colonnes, et fractionner les op&e9rations d'attention selon la dimension de la tête d'attention.

Grâce au TP, l'architecture Llama-3 ne pr&e9sente aucun calcul en double pour la projection Linear et les op&e9rations d'attention entre les GPU, ce qui constitue une m&e9thode de fractionnement id&e9ale. Cependant, dans les modèles DeepSeek-V3/R1, le TP ne permet pas d'atteindre ce r&e9sultat.

Les modèles DeepSeek-V3/R1 utilisent l'attention multilatente (MLA). Une couche MLA utilise d'abord une projection Linear kv_a_proj pour calculer le vecteur latent, puis une autre projection Linear kv_b_proj pour le transformer dans l'espace de chaque tête d'attention. Puisque toutes les têtes d'attention partagent le m&e9me vecteur latent, le TP ne peut pas fractionner ce vecteur latent; par cons&e9quent, tous les rangs TP doivent r&e9pliquer les paramètres et les calculs de kv_a_proj et kv_b_proj. De même, comme le MLA stocke le vecteur latent dans le cache KV, chaque rang TP conserve une copie identique de ce cache KV.

Malgré une certaine duplication dans le MLA, le parallélisme de tenseurs offre tout de même une r&e9duction partielle des besoins en calcul, ce qui le rend pr&e9cieux pour les sc&e9narios n&e9cessitant des vitesses de sortie &e9lev&e9es.

Parallélisme d'experts

Les modèles DeepSeek-V3/R1 remplacent les couches MLP par des couches MoE. Une couche MoE comprend 256 experts acheminés et un expert partagé. Chaque jeton est acheminé vers 8 experts acheminés diff&e9rents pour le calcul, et les r&e9sultats font l'objet d'une sommation pond&e9r&e9e. Chaque jeton est en outre traité par l'expert partagé, et son r&e9sultat est ajouté à celui provenant des experts acheminés.

Le parallélisme d'experts (EP) sert d'approche de fractionnement typique pour les couches MoE, chaque GPU gèrant 256 / EP experts acheminés tout en conservant une copie de l'expert partagé. Par rapport au TP, l'avantage de l'EP r&e9side dans sa capacité à distribuer les calculs sur un plus grand nombre de GPU, ce qui r&e9duit les besoins en calcul et l'utilisation de la m&e9moire par GPU.

Avant d'effectuer le calcul des experts, tous les GPU doivent exécuter une communication AllToAll pour acheminer les jetons vers les GPU où se trouvent les experts correspondants; après ce calcul, une autre communication AllToAll est n&e9cessaire pour rassembler les r&e9sultats provenant des divers GPU et effectuer la sommation pond&e9r&e9e. Nous avons implémenté une version optimisée de ces deux noyaux de communication AllToAll, Dispatch et Combine, à l'aide de NVSHMEM. Dans notre billet de blogue préc&e9dent, nous avons d&e9taillé l'implémentation, et nos noyaux ont &e9té publiés en open source sur GitHub.

Parallélisme de données

Grâce à l'EP, nous pouvons distribuer le calcul MoE sur 128 GPU ou plus. Cependant, le calcul MLA ne peut pas être partitionné avec l'EP. Nous pouvons alors introduire le parallélisme de données (DP). Chaque groupe DP dispose d'une copie int&e9grale de la couche MLA. Chaque groupe DP accepte des entr&e9es diff&e9rentes et ex&e9cute les calculs de la couche MLA de manière ind&e9pendante.

Le DP et le TP de la couche MLA peuvent être combinés, un groupe DP étant divisé en plusieurs rangs TP. L'EP de la couche MoE peut être combiné avec le DP/TP de la couche MLA. EP = DP * TP. Par exemple, sur 16 machines, EP128 DP32 TP4 signifie que les experts acheminés sont r&e9partis sur 128 GPU, chaque groupe de 4 GPU formant un groupe DP, pour un total de 32 groupes DP ind&e9pendants.

Nœud unique par rapport au multinœud

Les 671 milliards de paramètres de DeepSeek d&e9passent la capacité de m&e9moire d'une seule machine H100 à 8 GPU (80 Go * 8), mais une seule machine H200 à 8 GPU peut int&e9gralement accueillir l'ensemble du modèle (141 Go * 8). Avec la configuration EP8 DP8 TP1, le modèle utilise environ 100 Go de m&e9moire par GPU, ce qui laisse approximativement 40 Go pour le cache KV et d'autres r&e9sultats intermédiaires. Un jeton occupe 70 272 octets du cache KV. En supposant que chaque requ&eate comporte 5 000 jetons, chaque GPU peut accuellir environ 100 requ&eates.

Nous voulions comprendre les diff&e9rences de performance entre les déploiements sur un nœud unique et sur plusieurs nœuds selon diverses configurations. Nous avons utilisé une machine H200 pour le déploiement sur un nœud unique et jusqu'à 16 machines H100 pour les déploiements multinœuds. Pour chaque environnement de déploiement, nous avons utilisé des combinaisons de TP 1, 2, 4 et 8, ainsi que des tailles de lots par GPU de 1, 2, 4, 8, 16, 32, 64 et 128. Nous avons supposé que chaque requ&eate avait une longueur de cache KV de 5 000 jetons. Nous avons &e9galement supposé que la pr&e9diction multitoken (MTP) pr&e9dit 1 jeton suppl&e9mentaire (c'est-à-dire que la longueur de la requ&eate de chaque requ&eate est de 2) et avons tablé de manière prudente sur un taux d'acceptation de 60 %. La figure ci-dessous illustre le débit et la vitesse de sortie pour diff&e9rentes configurations.

Agrandir

L'axe horizontal repr&e9sente la vitesse de sortie par requ&eate en jetons par seconde (jetons/s). L'axe vertical utilise une &e9chelle logarithmique pour illustrer le débit par machine en jetons/s. Nous avons marqué la frontière de Pareto pour chaque configuration EP à l'aide de lignes de couleurs diff&e9rentes.

Dans les sc&e9narios exigeant des vitesses de sortie extr&e9mement &e9lev&e9es, l'utilisation d'une configuration EP8 DP1 TP8 sur un nœud unique avec une taille de lot de 1 permet d'atteindre une vitesse de sortie supérieure à 100 jetons/s, mais le débit est extr&e9mement faible, &e9quivalent à la vitesse de sortie. Dans ce scénario, le lot entier ne comporte que 2 jetons, qui peuvent être acheminés vers au plus 2 * 8 = 16 experts, activant un total d'au plus 57 milliards de paramètres.

Dans la plage de vitesse de sortie de 40 à 80 jetons/s, à mesure que le débit augmente, la vitesse de sortie diminue de manière significative. En revanche, l'EP128 offre un débit environ 5 fois plus élev&e9 que le déploiement sur un nœud unique pour une m&e9me vitesse de sortie.

Ce ph&e9nomène s'explique par l'analyse du comportement des déploiements sur un nœud unique : l'augmentation de la taille des lots est directement corr&e9l&e9e à une augmentation des experts activés. Lorsque la taille du lot est de 1, le nombre moyen d'experts activés par GPU est de 2 * 8 / 8 = 2. Lorsque le lot est suffisamment grand, tous les experts sont activés, ce qui signifie que chaque GPU active 256 / 8 = 32 experts. Activer un plus grand nombre d'experts oblige le GPU à lire davantage de paramètres en m&e9moire, ce qui accroît consid&e9rablement la pression sur la bande passante de la m&e9moire. La phase de d&e9codage des grands modèles de langage étant d&e9jà limit&e9e par la bande passante de la m&e9moire plutôt que par les performances de calcul, l'augmentation de la taille des lots lors d'un déploiement sur un nœud unique r&e9duit sensiblement la vitesse de sortie.

La comparaison des quatre configurations de déploiement multinœuds (EP16, EP32, EP64 et EP128) r&e9vèle que des valeurs d'EP plus &e9lev&e9es d&e9placent la frontière de Pareto vers des améliorations simultan&e9es du débit et de la vitesse de sortie.

L'utilisation d'un nombre d'EP plus &e9lev&e9 signifie que chaque GPU se voit attribuer moins d'experts. Par exemple, EP128 signifie que chaque GPU est responsable de 256 / 128 = 2 experts, de sorte que la pression sur la bande passante de la m&e9moire est consid&e9rablement r&e9duite. En d'autres termes, en utilisant un nombre d'EP plus important, nous b&e9n&e9ficions effectivement d'une plus grande bande passante m&e9moire. Lorsque la taille de lot par GPU est inf&e9rieure à 64, l'augmentation de la taille du lot n'affecte pas de manière significative la vitesse de calcul des experts, car l'augmentation du nombre d'entr&e9es n'accroît pas de fa&e9on notable la pression sur la bande passante m&e9moire. Par cons&e9quent, nous observons qu'avec l'EP128, l'augmentation de la taille des lots n'affecte pas la vitesse de sortie de manière aussi marqu&e9e.

Il est int&e9ressant de noter que, pour les tailles de lots plus importantes (64 requ&eates par GPU), nous avons observé un nouveau ph&e9nomène : le débit du déploiement sur un nœud unique est l&e9gèrement supérieur à celui du déploiement multinœud. Cela s'explique en partie par le fait que le protocole NVLink intra-nœud possède une bande passante plus &e9lev&e9e que l'InfiniBand inter-nœuds. Une autre raison tient aux limites de notre propre implémentation. Nous analyserons ce ph&e9nomène plus en d&e9tail par la suite.

En raison de limitations de la capacité de la m&e9moire, la configuration EP8 DP8 TP1 ne peut pas atteindre une taille de lot de 128 par GPU; par cons&e9quent, le déploiement multinœud demeure le meilleur choix dans les sc&e9narios visant un débit plus &e9levé.

Chevauchement des calculs et des communications

Comme nous l'avons brièvement mentionné ci-dessus au sujet du parallélisme d'experts, les GPU sont inactifs pendant la communication de la couche MoE. Pour r&e9duire les temps morts et abaisser la latence, nous devons trouver des tâches de calcul ind&e9pendantes des données pour occuper ce temps d'inactivité.

Agrandir

La partie supérieure de la figure ci-dessus illustre le flux de calcul d'une couche. Le calcul MoE d&e9pend de l'op&e9ration Dispatch, et le calcul de la couche suivante d&e9pend du r&e9sultat de Combine.

Nous pla&e7ons l'expert partagé sur chaque GPU. De cette fa&e7on, le calcul de l'expert partagé ne n&e9cessite pas de communication AllToAll. Par cons&e9quent, nous pouvons effectuer le calcul de l'expert partagé imm&e9diatement après l'envoi Dispatch Send, puis attendre la fin de la r&e9ception Dispatch Recv. Nous appelons ce sch&e9ma de chevauchement « Dispatch Overlap ».

Le chevauchement Dispatch Overlap offre une mise en œuvre simple et une grande applicabilité. Cette technique masque le temps de calcul de l'expert partagé pour toutes les tailles d'EP et de lots.

Pour accroître encore le chevauchement entre le calcul et la communication, nous avons utilisé les micro-lots (micro-batching) mentionnés dans le rapport technique de DeepSeek afin de briser la d&e9pendance des données. Comme le montre la partie inf&e9rieure de la figure, nous avons divisé le calcul d'une couche Transformer en 5 &e9tapes :

Étape 1 : InputNorm, QKVProj, AppendKV, BMM

Étape 2 : BMM, Attn, OProj, PostNorm, Gate

Étape 3 : Dispatch Send, expert partagé (Shared Expert)

Étape 4 : Dispatch Recv, MoE, Combine Send

Étape 5 : Combine Recv

Dans les 3 premières couches Transformer denses, nous utilisons le lot entier. Dans les 58 couches Transformer MoE suivantes, nous divisons uniformément le lot en deux micro-lots. Les deux micro-lots s'ex&e9cutent en alternance, avec un d&e9calage de 3 &e9tapes. Puisqu'il n'y a pas de dépendance de données entre ces deux micro-lots, nous pouvons basculer vers le calcul de l'autre micro-lot après Dispatch Send et après Combine Send.

Ventilation de la latence

Ensuite, nous comparons les effets du chevauchement par le biais d'une exp&e9rience, et nous comparons &e9galement les diff&e9rences de performance entre le déploiement sur un nœud unique EP8 et le déploiement multinœud EP128. Pour faciliter la comparaison, nous avons utilisé des GPU H100 pour l'exp&e9rience suivante. Nous avons utilisé un TP de 1, une taille de lot de 128 par GPU, une longueur de requ&eate (Query) de 2 par requ&eate et une longueur de cache KV de 5 000.

Agrandir

La figure ci-dessus pr&e9sente le temps total consacré à une couche Transformer MoE ainsi que la proportion de latence des diff&e9rents types de noyaux. À l'exception de Dispatch, Combine et GroupGEMM, le temps d'ex&e9cution des autres noyaux doit être identique dans les s&e9ries EP8, EP128 NoOverlap et EP128 DispatchOverlap, car la taille des lots est la m&e9me.

Chevauchement

Comparons d'abord les effets des trois m&e9thodes de chevauchement. NoOverlap a pris 2 667 µs au total, tandis que DispatchOverlap a pris 2 651 µs, soit une &e9conomie de 16 µs ou seulement 0,6 %. MicroBatch a montré une am&e9lioration très marqu&e9e, avec un temps de 1 896 µs, soit une acc&e9lération de 29 %. Le temps de Dispatch et celui de Combine ont tous deux &e9té r&e9duits de manière significative. Le Dispatch est passé de 593 µs à 367 µs, et le Combine de 1 012 µs à 237 µs.

Il est à noter que pour les noyaux de calcul, la division d'un lot de taille 128 en deux lots de taille 64 augmente le temps d'ex&e9cution total. Par cons&e9quent, bien que le temps consacré à la communication ait diminué de 1 001 µs, le temps total n'a r&e9gressé que de 771 µs. Nous expliquerons cette raison à l'aide du modèle Roofline dans la section suivante.

Pour cette raison, l'utilisation de micro-lots n'am&e9liore pas toujours les performances.

Agrandir

La figure ci-dessus montre l'amélioration des performances de Microbatch par rapport à DispatchOverlap pour des tailles de lots de 4 à 128. Lorsque la taille du lot est inf&e9rieure à 32, Microbatch r&e9duit les performances de 5 % à 40 %. Lorsque la taille du lot est supérieure ou &e9gale à 32, Microbatch peut améliorer les performances de 10 % à 35 %.

EP8 par rapport à EP128

Revenons à la figure pr&e9c&e9dente pour comparer EP8 et EP128 Microbatch. EP8 a pris 1 802 µs au total, ce qui est l&e9gèrement inf&e9rieur aux 1 896 µs d'EP128. Outre l'augmentation du temps d'ex&e9cution du noyau engendr&e9e par Microbatch mentionnée pr&e9cedemment, les principales diff&e9rences r&e9sident dans GroupGEMM, utilisé pour le calcul MoE, ainsi que dans les deux noyaux de communication, Dispatch et Combine.

Le GroupGEMM d'EP8 a pris 555 µs, tandis que celui d'EP128 a pris 270 µs, soit une r&e9duction de moitié. C'est là l'avantage fondamental du déploiement multinœud.

Malheureusement, le temps consacré à la communication a augmenté de 213 µs, ce qui a grandement neutralisé l'avantage de GroupGEMM. Lors de tests de performance distincts sur nos noyaux de communication, nous avons constaté qu'ils ne parviennent à atteindre que la moitié de la bande passante d'InfiniBand. Nous continuerons d'optimiser nos noyaux de communication.

Un autre noyau qui accuser un retard sensible est GEMM. Microbatch a augmenté le temps de GEMM de 95 µs. Nous analyserons GEMM de manière plus approfondie dans la section Roofline ci-dessous. Nous estimons que l'implémentation actuelle de GEMM n'a pas encore atteint des performances optimales.

Modèle Roofline

Le modèle Roofline est un excellent outil pour analyser les performances des noyaux. Son axe horizontal correspond à l'intensité arithm&e9tique, qui est le rapport entre les op&e9rations en virgule flottante (FLOP) et les octets d'entr&e9e/sortie en m&e9moire. La valeur de l'axe horizontal peut être calcul&e9e directement à partir de la s&e9mantique du noyau. L'axe vertical repr&e9sente la performance obtenue, calcul&e9e en divisant les FLOP par la latence mesur&e9e lors de l'essai de r&e9f&e9rence.

La limite sup&e9rieure th&e9orique des performances d'un noyau est directement d&e9termin&e9e par les sp&e9cifications du GPU. La performance de cr&e9te en FP8 du H100 est de 1 979 TFLOP/s, repr&e9sent&e9e par une ligne horizontale dans le modèle Roofline. La bande passante m&e9moire du H100 est de 3,35 To/s, repr&e9sent&e9e par la pente d'une ligne passant par l'origine. Ces deux lignes donnent respectivement les limites de performance pour les noyaux limit&e9s par le calcul et ceux limit&e9s par la m&e9moire.

Nous abordons ci-dessous les performances des noyaux GroupGEMM et GEMM.

GroupGEMM

Le noyau GroupGEMM de la couche MoE ex&e9cute le calcul suivant : il y a un total de g groupes, et le i-ième groupe possède m_i jetons, ce qui donne lieu à une multiplication matricielle de [m_i, k] x [k, n] -> [m_i, n]. Lors des tests de performance, nous supposons que le nombre de jetons dans chaque groupe est le m&e9me, noté m_i = m. Le nombre de FLOP pour GroupGEMM est alors de 2 * g * m * k * n, et le nombre d'octets d'entr&e9e/sortie en m&e9moire est de g * (m * k + n * k + m * n).

Dans le modèle DeepSeek-V3/R1, il y a 256 experts, et chaque jeton est réparti vers 8 experts pour le calcul. En supposant une taille de lot de 128, une longueur de requête de 2 et une configuration EP128 DP128, le nombre moyen de jetons reçus par chaque expert (c.-à-d. m) est 128 * 2 * 8 * 128 / 256 = 1024. De même, nous pouvons calculer m pour d’autres configurations et tailles de lot.

Nous avons utilisé l'implémentation GroupGEMM de DeepGEMM pour les tests de performance. Les points de test ont couvert des combinaisons de configurations EP8, EP16, EP32, EP64 et EP128 avec un TP de 1 et des tailles de lots de 1 à 128.

Agrandir

La figure ci-dessus pr&e9sente le modèle Roofline pour GroupGEMM sous diff&e9rentes configurations EP. Diff&e9rents EP correspondent à un nombre diff&e9rent de groupes. La figure illustre des courbes de performance presque superpos&e9es, ce qui indique que les performances de GroupGEMM sont principalement d&e9termin&e9es par le nombre total de jetons (repr&e9sent&e9 par g * m).

Les &e9toiles signalent les points de données correspondant à une taille de lot de 128 par GPU pour chaque configuration EP. En comparant ces points de données marqu&e9s, nous pouvons voir qu'à mesure que l'EP augmente (et que le DP augmente de manière synchrone), le nombre de jetons par expert m augmente également. Pour l'EP8, m=128, tandis que pour l'EP128, m=2048.

À mesure que m augmente, l'intensité arithm&e9tique augmente également. Dans la plupart des configurations, GroupGEMM est limit&e9 par la bande passante de la m&e9moire, de sorte qu'une augmentation de m améliore les performances.

GEMM

Le noyau GEMM correspond aux projections Linear dans le modèle, telles que les projections Q/K/V/O. Pour une multiplication matricielle de [m, k] x [k, n] -> [m, n], le nombre de FLOP est de 2 * m * k * n, et le nombre d'octets d'entr&e9e/sortie en m&e9moire est de m * k + n * k + m * n. Nous pouvons &e9galement tester la latence pour des tailles de lots de 1 à 128.

Agrandir

La figure ci-dessus montre le modèle Roofline pour GEMM sous diff&e9rentes configurations EP. Nous pouvons observer que les performances de GEMM sont limit&e9es par la bande passante de la m&e9moire. Lorsque la taille du lot augmente, l'intensité arithm&e9tique augmente &e9galement, am&e9liorant ainsi les performances.

Micro-lots

Lors de l'utilisation de micro-lots, nous divisons le lot de manière &e9gale en deux parties. D'après les deux figures ci-dessus, nous pouvons constater que lorsque m devient m/2, l'efficacité de la multiplication matricielle diminue. Par cons&e9quent, l'ex&e9cution de deux multiplications matricielles de taille m/2 prend plus de temps que l'ex&e9cution d'une seule multiplication matricielle de taille m.

Pr&e9diction multitoken

Tout au long de cet article, nous avons supposé l'utilisation de la prédiction multitoken (MTP) pour le décodage spéculatif. Le MTP fait passer la longueur de requête de 1 à 2. Pour la multiplication matricielle, cela équivaut à remplacer m par m * 2, augmentant ainsi l'efficacité de la multiplication matricielle. D'un autre côté, si nous tracions le modèle Roofline pour le MLA, nous constaterions que l'augmentation de la longueur des requêtes accroît sensiblement l'efficacité du noyau MLA.

Par cons&e9quent, l'utilisation du MTP joue un rôle important dans l'efficacité du modèle.

Mise en oeuvre et optimisations

Dans cette section, nous pr&e9senterons quelques d&e9tails d'implémentation et d'optimisation de notre modèle DeepSeek-V3/R1.

Quantification

DeepSeek-V3/R1 a &e9té entraîné nativement sur FP8 en utilisant un sch&e9ma de quantification par bloc, les poids étant quantifiés de manière statique et les activations à la volée. Plutôt que de calculer un facteur d'échelle par canal ou par matrice de manière statique, les facteurs d'échelle sont calculés sur des vecteurs de 128 éléments pour les activations et sur des tuiles de 128 x 128 éléments pour les matrices, ce qui limite la dégradation de la précision due à la quantification.

Chez Perplexity, nous nous appuyons sur une combinaison de noyaux CUDA et Triton pour prendre en charge l'inférence, CUDA étant utilisé pour les noyaux les plus sensibles aux performances et modifiés peu fréquemment (tels que l'attention et GEMM), tandis que Triton met en œuvre un large éventail de noyaux d'activation, de normalisation et utilitaires. Triton nous a permis d'adapter rapidement les noyaux au schéma de quantification par bloc.

Pour les couches lin&e9aires et MoE, nous combinons les noyaux Deep GEMM avec nos propres noyaux Triton GEMM, car nous avons remarqué que pour certaines dimensions de matrices et de faibles tailles de lots, Split-K offre une latence plus faible. Si la couche non quantifi&e9e effectue une multiplication (M, K) x (K, N), elle n&e9cessite un facteur d'&e9chelle (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) pour la quantification par bloc. Pour cette quantification par bloc, les facteurs d'&e9chelle des activations sont calculés à la vol&e9e, au lieu d'être pr&e9-calibrés. Les facteurs d'&e9chelle des activations n'&e9tant agr&e9g&e9s que le long de la dimension K et non de la dimension M, les noyaux ne n&e9cessitent que de l&e9gères modifications pour prendre en charge ce sch&e9ma.

Agrandir

La fonction d'activation SiLU utilisée par DeepSeek-V3/R1 a n&e9cessité des modifications substantielles pour prendre en charge les graphes CUDA, la quantification par bloc et les nombres de jetons acheminés dynamiquement. La quantification par bloc peut poser des problèmes car elle introduit des r&e9ductions horizontales; toutefois, le noyau segmentait d&e9jà les activations le long de leur dimension cach&e9e en blocs de 1 024 &e9l&e9ments. Au sein d'un m&e9me bloc, le tenseur à quantifier &e9tait subdivisé en blocs de 128 pour calculer la plus grande valeur absolue, Triton g&e9n&e9rant des r&e9ductions maximales inter-distorsions efficaces, ce qui ajoute un surd&e9bit minimal.

Pour prendre en charge l'acheminement MoE sous les graphes CUDA, les noyaux doivent connaître les informations d'acheminement indiquant le nombre de jetons par expert, plutôt que de planifier le travail en fonction de la taille des tampons allou&e9s pour contenir la limite sup&e9rieure des comptes de jetons. Nous ne pouvons pas diviser le problème en fonction des dimensions du tenseur d'entr&e9e, de sorte que nous lançons un nombre fixe de noyaux persistants qui lisent les informations d'acheminement pour d&e9terminer combien de jetons sont renseign&e9s et pour r&e9partir dynamiquement le travail de traitement des activations entre eux.

Nous avons d&e9jà int&e9gré certains de nos noyaux en amont dans le projet FlashInfer et, à l'avenir, nous publierons davantage de notre code en open source.

Couche MLA

Nous utilisons FlashInfer pour le calcul MLA. FlashInfer prend en charge des paramètres de table de pages flexibles et offre des performances extr&e9mement &e9lev&e9es.

Nous avons fusionné q_a_proj et kv_a_proj en un seul qkv_a_proj. La latence est pass&e9e de 15,4 µs + 14,8 µs = 30,2 µs à 16,7 µs.

Nous avons d&e9composé kv_b_proj en deux matrices, k_b_proj et v_b_proj. Nous avons &e9crit un noyau BMM quantifié par bloc FP8 pour les calculs associ&e9s à ces deux matrices.

Graphe CUDA

Le graphe CUDA peut r&e9duire consid&e9rablement le surd&e9bit de lancement des noyaux, ce qui est crucial pour les performances. Nous cr&e9ons un graphe CUDA pour chaque taille de lot.

Avant de d&e9velopper notre noyau AllToAll, nous utilisions torch.all_to_all_single() pour la communication AllToAll. Cette op&e9ration exige que tous les GPU utilisent la m&e9me taille de lot. Cependant, diff&e9rents groupes DP peuvent ex&e9cuter des tailles de lots diff&e9rentes.

Pour garantir la compatibilité de all_to_all_single() avec divers groupes DP utilisant des tailles de lots diff&e9rentes, nous avons d'abord utilisé une op&e9ration allreduce() avant chaque ex&e9cution du modèle pour obtenir la taille de lot maximale parmi tous les groupes DP. Ensuite, nous avons fait en sorte que tous les groupes DP utilisent cette taille de lot pour l'ex&e9cution.

Bien que cette approche garantisse que nous pouvons utiliser un graphe CUDA, elle pr&e9sente trois inconv&e9nients. Premièrement, elle n&e9cessite une op&e9ration allreduce() suppl&e9mentaire. Deuxièrement, les groupes DP dot&e9s de tailles de lots plus petites sont contraints d'utiliser un remplissage (padding). Troisièrement, elle complexifie notre code d'implémentation.

Après avoir implémenté notre propre noyau AllToAll, nous n'exigeons plus que tous les GPU utilisent la m&e9me taille de lot. Par cons&e9quent, nous n'avons plus besoin d'ex&e9cuter d'op&e9rations allreduce() suppl&e9mentaires ni d'effectuer un remplissage des tailles de lots.

Routeur MoE

Le routeur MoE est implémenté en Triton et s'appuie sur un tri modifié issu de la bibliothèque standard, qui effectue &e9galement le suivi des indices des &e9l&e9ments tri&e9s. L'implémentation est partagée entre tous les modèles MoE, car l'acheminement Mixtral est un cas particulier des acheminements DeepSeek où le groupe Top-K est identique au groupe de tous les experts. Les noyaux parsemés consomment directement les indices et les scores Top-K, tandis que les sch&e9mas de distribution/combinaison denses reposant sur les communications all-to-all n&e9cessitent que les informations d'acheminement soient agr&e9g&e9es par expert plutôt que par jeton.

Travaux futurs

Dans le cadre de nos travaux futurs, nous pr&e9voyons d'optimiser davantage les performances du modèle DeepSeek.

La prochaine optimisation la plus importante est la désagr&e9gation de la pr&e9charge (Prefill Disaggregation). Les phases de pr&e9charge et de d&e9codage du modèle DeepSeek-V3/R1 pr&e9sentent des caractéristiques de calcul très diff&e9rentes. Toutes deux peuvent b&e9n&e9cier de stratégies d'optimisation et de sch&e9mas de déploiement diff&e9rents.

Pour la couche MLA, pendant la phase de décodage, nous utilisons l'absorption de matrices pour r&e9duire le nombre de FLOP du calcul MLA. Pendant la phase de précharge, projeter d'abord le vecteur latent dans l'espace K/V, puis effectuer le calcul sous forme d'attention multitéte (MHA) donnerait de meilleurs r&e9sultats.

Si la pr&e9charge et le décodage s'ex&e9cutent sur le m&e9me GPU, pour att&e9nuer l'impact de la pr&e9charge sur la vitesse de sortie du décodage, nous utilisons g&e9n&e9ralement une pr&e9charge par morceaux (chunked prefill) pour diviser la requ&eate en plusieurs morceaux aux fins de la pr&e9charge. Le cache KV stockant le vecteur latent, il devient difficile de convertir le MLA en un format MHA.

Pour la couche MoE, lors de la phase de décodage, nous utilisons des valeurs d'EP et de DP aussi grandes que possible pour augmenter le nombre de jetons d'entr&e9e par expert, am&e9liorant ainsi les performances de GroupGEMM. Pendant la phase de précharge, le nombre de jetons &e9tant d&e9jà suffisamment grand, GroupGEMM est d&e9jà limité par le calcul. Par cons&e9quent, pour la pr&e9charge, nous pouvons recourir à des EP et des DP plus petits.

Si la pr&e9charge et le décodage s'ex&e9cutent sur le m&e9me GPU, tant qu'un groupe DP effectue une pr&e9charge, la latence des couches MoE sur tous les GPU augmentera, ce qui nuira sensiblement à la vitesse de sortie du décodage.

Outre la désagr&e9gation de la pr&e9charge, nous pr&e9voyons &e9galement d'optimiser les aspects suivants :

Performances d'AllToAll : notre noyau AllToAll ne parvient actuellement qu'à atteindre 1/3 de la bande passante d'InfiniBand. Nous continuerons d'optimiser ce noyau.

Décodage sp&e9culatif de style EAGLE : dans les données ci-dessus, nous avons supposé l'utilisation du décodage spéculatif pour prédire 1 jeton. EAGLE peut utiliser une structure arborescente pour pr&e9dire plusieurs jetons, am&e9liorant ainsi la longueur d'acceptation, ce qui peut accroître consid&e9rablement la vitesse de sortie.

Noyau GEMM : dans le modèle Roofline pr&e9senté pr&e9c&e9demment, nous pouvons constater que l'efficacité du noyau GEMM est encore loin de la limite th&e9orique. Nous continuerons d'optimiser ce noyau.

GB200 NVL72 : dans la dernière solution GB200 NVL72 de NVIDIA, 72 GPU Blackwell sont interconnectés via un protocole NVLink haute vitesse. Pour les modèles à architecture MoE, cela repr&e9sente un très grand d&e9fi et une opportunité majeure.

Conclusion

Le déploiement multinœud des modèles DeepSeek MoE permet d'atteindre ce qui est habituellement impossible avec les LLM denses : am&e9liorer simultan&e9ment le débit et la latence. En r&e9partissant les experts sur un plus grand nombre de GPU, nous r&e9duisons la pression sur la bande passante de la m&e9moire par appareil, ce qui permet un traitement plus rapide et un débit système accru. Nos exp&e9riences montrent que les configurations EP128 atteignent un débit jusqu'à 5 fois plus &e9levé à des vitesses de sortie &e9quivalentes par rapport aux déploiements sur un nœud unique.

Les techniques de chevauchement entre les calculs et les communications, telles que les micro-lots, r&e9duisent consid&e9rablement le surd&e9bit de communication multinœud, notre implémentation affichant une acc&e9lération allant jusqu'ar 40 %. Nos noyaux de communication AllToAll personnalisés et nos implémentations de noyaux optimisées ont permis le déploiement efficace du modèle à 671 milliards de paramètres.

À mesure que les architectures MoE gagnent en popularité en raison de leurs capacités, ces stratégies de déploiement fournissent des informations pr&e9cieuses pour mettre à l'&e9chelle de tels modèles de manière efficace.

Références

Rapport technique sur DeepSeek-V3

Aperçu du système d'inférence DeepSeek-V3/R1

Megatron-LM : Entraînement de modèles de langage à plusieurs milliards de paramètres grâce au parallélisme de modèle

EAGLE : L'échantillonnage sp&e9culatif n&e9cessite de repenser l'incertitude des caract&e9ristiques

Citation

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}