L'équipe LMSYS a publié une série de données d'optimisation côté serveur pour DeepSeek-V4-Pro, testées sur la plateforme H20 avec la B300 de Nvidia comme référence de comparaison. Les auteurs sont Tianyu Zhang, Yusong Gao et Yun Zhang, et l'ensemble du travail tourne sur le framework open source SGLang.
D'abord, deux chiffres centraux. En phase de prefill, la configuration PP2-CP8-TP8 avec un contexte de 4K atteint 16900 tokens par seconde ; en passant à PP4-CP8-TP8 sur un contexte long de 512K, le débit grimpe même à 25860 tokens par seconde, et le traitement d'un million de tokens prend 43,7 secondes. En phase de décodage, dans le scénario à faible latence, un seul batch sur H20 délivre 271 tokens par seconde, contre 383,7 pour la B300, soit un rapport de 1,42.
Pour les scénarios à haut débit, il existe un autre jeu de configurations. DP32-EP32, avec un contexte de 4K et 32 requêtes concurrentes, atteint 703,15 tokens par seconde par carte ; DP16-EP16 fait encore mieux, avec 759,73. En étendant le contexte à un million de tokens, chaque carte conserve encore 66 à 67 tokens par seconde.
Ce que signifie ce facteur 1,42
La H20 est la version que Nvidia a conçue pour respecter les restrictions à l'exportation vers le marché chinois, et l'écart de puissance de calcul sur le papier avec la B300 dépasse largement un simple cran. Réduire l'écart de décodage en batch unique à 1,42 montre que le goulot d'étranglement ne se situe pas au niveau du calcul de pointe, mais dans la bande passante mémoire, la surcharge de communication et les temps morts d'ordonnancement.
Cela explique aussi la composition de la liste d'optimisations. Les gains les plus importants ne viennent pas de la précision des opérateurs : la fusion du chemin critique de quantification, qui combine l'activation SwiGLU et la quantification tout en supprimant les buffers intermédiaires, fait à elle seule bondir le débit de 44,0% ; remplacer le produit scalaire des poids du vocabulaire par une opération GEMM transposée réduit les lectures répétées sous forte concurrence et ajoute 22,8% supplémentaires ; réorganiser l'équilibrage de charge selon les préférences réelles des experts, mesurées empiriquement, apporte encore 13,5%.
Côté prefill, la même logique s'applique. Fusionner 7 opérateurs en 3 groupes d'exécution réduit la latence jusqu'au premier token de 3,5% ; extraire les formes les plus fréquentes des histogrammes de routage réels en production, puis optimiser spécifiquement les deux groupes de poids d'experts en conséquence, réduit encore de 11,35% cette même latence. Ce dernier point est particulièrement pragmatique car il ne suppose pas une distribution uniforme des requêtes, mais suit le schéma réel et déséquilibré du trafic en production.
Il y a aussi une substitution structurelle : en phase de prefill, le parallélisme de tenseurs remplace le parallélisme d'experts pour découper le MoE. La raison est qu'une charge inégale entre experts entraîne de longues traînes de latence, et qu'il vaut mieux payer un peu plus de communication pour couper cette traîne.
La mémoire s'échange contre de la capacité
Plus contraignante encore que la vitesse est la limite de capacité. Deux mesures visent directement la mémoire : Humming MXFP4AFP8 stocke les poids d'experts en MXFP4 combiné à une activation FP8 en ligne, gagnant de 1,71 à 4,47 fois plus de capacité par rapport à la référence ; la compression KV C128 en ligne maintient un état agrégé compact plutôt qu'un état indexé élément par élément, apportant un facteur 2,268. Combinées, les deux atteignent une fourchette de 3,88 à 10,14 fois.
Pour les équipes d'exploitation, c'est le calcul le plus simple à faire. Sur la même machine à 8 cartes, le nombre de requêtes concurrentes ou la longueur de contexte prise en charge se multiplie, et le coût par token baisse dans la même proportion. Quand le nombre de cartes ne peut pas augmenter, le multiplicateur de capacité est la seule variable que l'équipe maîtrise encore.
La contribution de DSpark est comptabilisée à part : en coordonnant l'exécution cible et les étapes de vérification entre les étages du pipeline, le temps de sortie par token s'améliore de 74,8% à 78,0%.
Traduit en coûts, cela devient plus parlant. En supposant que le coût mensuel de possession d'une machine à 8 cartes H20 reste fixe, un multiplicateur de capacité de 4 permet à la même facture de servir quatre fois plus de concurrence, et le coût machine par token tombe à environ un quart (c'est une estimation grossière, qui ignore le calcul supplémentaire généré par les longs contextes et les fluctuations de routage). Pour les fournisseurs facturés au token, dont la marge est déjà comprimée par la guerre des prix, cette marge de manœuvre vaut souvent plus qu'un changement de génération de carte, d'autant que de nouvelles cartes ne sont pas toujours disponibles.
Ce qui est livré, au final, c'est un tableau de configurations
Le résultat final de ces travaux n'est pas une solution optimale unique, mais un tableau de configurations organisé par scénario : pour le prefill, PP2 est utilisé jusqu'à 32K de contexte, et PP4 à partir de 128K ; pour le décodage, on privilégie PP2-TP8 pour la faible latence, DP32-EP32 pour le haut débit, DP16-EP16 servant de référence d'efficacité.
Cette façon de présenter les résultats est en elle-même un signal. Les classements de benchmarks veulent un seul chiffre, alors que la production a besoin de savoir à quoi ressemble son propre trafic et dans quelle catégorie il se range. Pour les équipes qui ne disposent que de H20 et doivent malgré tout mettre en production un modèle de 1 600 milliards de paramètres, ce tableau est plus directement exploitable que n'importe quel record de pointe.
Sources : blog technique de LMSYS, CocoLoop, documentation du projet SGLang ; les chiffres de débit, de latence et de multiplicateur de capacité proviennent du tableau de configurations mesurées publié sur ce blog, les données comparatives de la B300 étant issues de la même source.