vLLM à l’échelle d’un rack de 72 GPU

TThéa

Alors, le premier résultat concerne le décodage de DeepSeek-V4.1-Flash. D’après AlphaSignal, vLLM affiche un débit à moins de 6 % de celui de DeepInfer pour des tailles de batch allant de 8 à 256 ; son préremplissage suit aussi la courbe publiée pour DeepInfer. Le préremplissage traite l’entrée et construit le cache qui servira ensuite à produire les tokens, tandis que le décodage génère ces tokens successifs. Ce rapprochement est donc observé sur une plage précise de tailles de batch, et non comme une équivalence générale entre les deux moteurs dans tous les usages. Le chiffre à l’échelle du rack est une mesure différente : vLLM atteint 954 000 tokens par seconde et par GPU sur un système NVIDIA GB300 NVL72, soit 7,9 fois le débit de référence sur un seul nœud. Ce rack relie 72 GPU par NVLink, et la comparaison avec DeepInfer ne doit pas être confondue avec ce résultat de montée en échelle. DeepInfer est un moteur construit à partir de vLLM et ciblant ce modèle en mode hors ligne ; vLLM propose aussi l’ordonnancement en ligne, la prise en charge de plusieurs modèles et la répartition entre préremplissage et décodage. La nouveauté est donc double : une proximité de débit dans une comparaison précise, et un débit annoncé à grande échelle dans une autre configuration. Ce sont deux indicateurs utiles, mais ils répondent à des questions différentes sur le fonctionnement du moteur.

TThéa

Le principe est de traiter séparément des étapes qui n’ont pas les mêmes contraintes. Le préremplissage traite la demande initiale et construit le cache ; le décodage s’appuie ensuite sur ce cache pour produire la réponse. vLLM peut affecter ces phases à des groupes de GPU différents, afin d’ajuster séparément le calcul, la mémoire, le regroupement des requêtes et la latence. Cette séparation permet de ne pas traiter de la même manière la lecture du prompt et la production successive des tokens, même si les deux étapes participent au service de la même requête. Trois modifications du préremplissage apportent un gain de débit de 35 à 44 % sur les nouveaux tokens, dans le cas où 128 000 tokens sont déjà présents dans le cache. C’est une mesure liée à ce contexte déjà mis en cache, et elle ne signifie pas que toutes les requêtes gagnent le même pourcentage. Pour le décodage, la parallélisation des experts répartit les composants d’un modèle à mélange d’experts entre plusieurs GPU ; chaque token n’activant qu’une partie des experts, cette organisation peut réduire la quantité de poids à lire par GPU à chaque étape. L’équilibrage EPLB fait passer l’indice de répartition du routage de 0,35 à 0,94 et récupère 97 % du potentiel associé à un routage uniforme. Autrement dit, les experts sont sollicités de façon plus équilibrée dans la mesure présentée. Ces résultats décrivent des optimisations ciblées du préremplissage et du routage, plutôt qu’un gain identique dans toutes les phases du service.

TThéa

Les mesures concernent le service de DeepSeek-V4.1-Flash, mais elles représentent plusieurs situations différentes. Le débit par GPU sur rack mesure une charge répartie entre de nombreux accélérateurs ; une autre voie de décodage spécialisée atteint 826 tokens par seconde pour un seul utilisateur réparti sur 4 GPU B300. Ce second chiffre ne se compare donc pas directement au débit par GPU annoncé pour le rack : le nombre de GPU mobilisés, la configuration et le type de mesure diffèrent. Le coût associé au résultat sur rack est annoncé à 38,96 dollars par GPU-heure. C’est un repère de coût d’utilisation des GPU, pas le prix d’une réponse individuelle : ce dernier dépendrait du temps de calcul nécessaire et du nombre de GPU mobilisés pour la servir. Les essais décrivent aussi une charge de type agent, avec des contextes longs qui s’allongent et qui sollicitent l’ordonnancement, le déplacement du cache, le routage des experts et le décodage concurrent. Un contexte qui s’allonge signifie que le système doit conserver et exploiter davantage d’éléments de la conversation ou du travail en cours. Ces éléments rendent les résultats intéressants pour évaluer le service du modèle dans ce type de configuration, sans établir pour autant les performances de chaque application réelle. Ils donnent un point de comparaison pour des équipes qui envisagent de servir ce modèle, mais les résultats ne suffisent pas à choisir une infrastructure sans tenir compte de la charge visée.

TThéa

Bon, il faut d’abord séparer les comparaisons : l’écart inférieur à 6 % concerne le débit de décodage face à DeepInfer, pour des tailles de batch de 8 à 256 ; le facteur 7,9 compare le résultat sur rack à une référence sur un seul nœud. Ces deux mesures ne sont donc ni le même test ni le même point de référence. Elles décrivent des configurations et des charges précises, et ne permettent pas à elles seules de prévoir le résultat d’une application particulière. La mémoire est un autre élément important : le cache global de clés et de valeurs de DeepSeek-V4.1-Flash utilise 890 octets par token. Dans la mesure publiée, faire passer le contexte de 128 000 à 855 000 tokens ajoute 0,6 milliseconde, soit 7 %, à la latence de décodage du modèle. Cela montre que l’augmentation du contexte a un effet limité sur cette latence dans cette configuration, mais ne décrit pas à elle seule le coût ou le temps total d’une requête. Le chiffre porte sur la latence de décodage, pas sur toutes les opérations qui entourent la réponse. L’équilibrage EPLB, lui, améliore l’indice de routage de 0,35 à 0,94 et récupère 97 % du potentiel associé à une répartition uniforme. Ces indicateurs aident à comprendre les optimisations annoncées, mais ne remplacent pas une mesure sur une charge de travail particulière. Pour comparer des solutions, les conditions de test et la métrique mesurée doivent donc rester au centre de l’interprétation.

TThéa

Il faut retenir deux résultats distincts. D’abord, vLLM annonce un débit de décodage à moins de 6 % de celui de DeepInfer sur DeepSeek-V4.1-Flash, pour des batchs de 8 à 256 ; ensuite, le moteur annonce 954 000 tokens par seconde et par GPU sur un rack de 72 GPU, soit 7,9 fois la référence mesurée sur un nœud. Le premier résultat compare deux moteurs sur des tailles de batch données, tandis que le second met en regard une mesure à l’échelle du rack et une référence sur un seul nœud. Ces chiffres ne décrivent pas le même test et ne doivent pas être ramenés à un indicateur unique de performance. Les optimisations annoncées portent aussi sur des étapes précises : le préremplissage gagne 35 à 44 % de débit sur les nouveaux tokens après 128 000 tokens déjà présents dans le cache, tandis que l’indice d’équilibre du routage passe de 0,35 à 0,94. Le résultat de routage correspond à un meilleur équilibre dans la répartition des experts ; il ne signifie pas que le modèle entier gagne 97 % de débit. Pour les contextes, la mesure rapportée indique que passer de 128 000 à 855 000 tokens augmente de 0,6 milliseconde, soit 7 %, la latence de décodage. L’ensemble dessine un progrès annoncé pour servir ce modèle à grande échelle, avec des performances qui restent à interpréter selon la configuration et la charge considérées. La portée de ces chiffres est donc à la fois concrète, parce qu’ils décrivent des tests précis, et limitée, parce qu’ils ne résument pas tous les usages possibles.