Comment mesurer la bande passante mémoire d'un serveur cloud ? Détecter la survente et les fausses spécifications

Utilisez la méthode d'audit croisé pour démasquer les fausses spécifications de bande passante mémoire.

Mis à jour 2026-08-12 · CloudWorth

bande passante mémoiretests de benchmarkdétection de surventeFinOpsCloudWorthSteal TimeSurvente VPSBenchmark VPS

Le test de bande passante mémoire doit combiner Steal Time et la falaise de cache, et utiliser le taux de prime FinOps pour verrouiller le vrai rapport qualité-prix.

Méthodes de benchmark : STREAM et mbw

Pour tester la bande passante mémoire des serveurs cloud, les deux outils que j'utilise le plus sont STREAM et mbw. STREAM est plutôt axé sur les pics théoriques, adapté pour évaluer les générations matérielles ; mbw est plus proche des pressions de lecture/écriture réelles, particulièrement adapté aux environnements conteneurisés Docker/K8s. Les commandes sont simples :

# STREAM (nécessite une compilation)
gcc -O3 -fopenmp stream.c -o stream
./stream

# mbw (installable via apt/yum)
mbw -n 8 512

Mais ne vous précipitez pas pour tirer des conclusions à partir des chiffres. Les pièges des tests de bande passante mémoire sur serveurs cloud se situent précisément dans la couche de virtualisation. Avant d'exécuter, jetez un œil au steal time dans /proc/stat ; si l'échantillonnage continu dépasse 2%, cela signifie que le CPU physique est accaparé par les voisins, et la bande passante mesurée sera nettement inférieure. Ensuite, observez le « goulot » du cache : augmentez progressivement la taille du tableau de test ; si la bande passante chute soudainement en dessous d'un tiers à un certain point, il est très probable que le cache L3 soit limité ou sujet à contention.

Point important : à partir de combien de différence entre la valeur nominale et la valeur mesurée parle-t-on de fausse déclaration ? J'ai l'habitude de convertir la bande passante mémoire en « prix par GiB », puis de la comparer aux valeurs de référence d'un serveur bare metal de configuration équivalente, afin de calculer le taux de surcoût FinOps. Si le taux de surcoût dépasse 30% mais que la bande passante n'atteint que la moitié de la valeur théorique, on peut fondamentalement conclure à une surallocation ou à une génération matérielle réduite. C'est précisément l'approche de l'audit croisé de CloudWorth — utiliser des benchmarks basés sur des scénarios réels pour identifier le rapport qualité-prix. Le modèle de comparaison complet se trouve dans les marque-pages plus loin. Retenez d'abord un principe : le benchmark n'est pas une fin en soi, l'identification du « point d'inflexion du rapport qualité-prix » l'est.

Détecter les fausses spécifications : Steal Time et Cache

Ne vous réjouissez pas trop vite devant les jolis chiffres de STREAM ou de mbw. Sur les serveurs cloud, le plus piégeux n'est pas une bande passante faible sur un seul point, mais plutôt « des chiffres qui semblent élevés et qui s'effondrent dès qu'on appuie ». J'ai l'habitude de croiser trois mesures : la bande passante mémoire, le Steal Time et le taux de hits du Cache. En particulier, après avoir lancé mbw, vérifiez le steal dans /proc/stat. S'il dépasse 10 % en continu, cela signifie que le CPU de l'hôte est fortement sur-allocaté. Les « vCPU » que vous avez achetés partagent peut-être les cœurs avec vos voisins, et les résultats des tests de bande passante mémoire peuvent être masqués par des valeurs gonflées ou des fluctuations.

Le vrai tueur, c'est le décrochage du Cache. Utilisez stream avec différentes tailles de tableaux. Si la bande passante chute brutalement de plus de 60 % entre 8 Mo et 16 Mo, on peut généralement conclure que le L3 est mutualisé ou que l'instance a été rétrogradée sur une génération de CPU plus ancienne. Par exemple, une société de IPO qui annonce de la « mémoire haute fréquence » mais dont les performances réelles sont inférieures à celles de son modèle d'entrée de gamme : dans ce cas, il faut calculer avec la formule de prime de CloudWorth : (performances réelles / performances annoncées) ÷ (prix / prix moyen de la même catégorie), et si le résultat est inférieur à 0,7, il faut résilier sans hésiter.

Dans les conteneurs, il faut aussi être prudent : Docker partage le noyau par défaut, mbw est affecté par la limitation du cgroup. Il est préférable d'ajouter --cpuset-mems pour lier les nœuds NUMA avant de tester, sinon les résultats ne servent qu'à s'amuser. Pour réellement reproduire un scénario d'inférence IA, je recommande d'exécuter directement une multiplication matricielle mini-batch avec pytorch et de la comparer à la référence de la machine physique. C'est plus fiable que n'importe quel outil de benchmark.

Taux de prime FinOps : le vrai rapport qualité-prix

Pour les tests de bande passante mémoire des serveurs cloud, la plus grande peur n'est pas une mesure inexacte, mais de ne pas savoir comment calculer les coûts après le test. Les sections précédentes sur le Steal Time et le gouffre de cache répondent essentiellement à la même question : votre argent achète-t-il une « configuration nominale » ou une « puissance de calcul réelle » ? Maintenant, en combinant ces deux indicateurs avec les résultats des tests de bande passante, je calcule un « taux de prime FinOps » pour chaque instance — la formule est simple : Taux de prime = bande passante mesurée ÷ bande passante théorique nominale ÷ prix unitaire. Plus le ratio est élevé, plus la bande passante réelle est obtenue pour chaque unité d'investissement ; à l'inverse, c'est typique d'une « configuration gonflée ».

Prenons l'exemple d'une instance d'un fournisseur cloud qui vient d'entrer en bourse, dont le cours de l'action a grimpé de 42 % en une journée puis s'est excusé : 8 cœurs 16G nominaux, bande passante mémoire théorique d'environ 40 Go/s (estimation DDR4 double canal). En mode fixed de mbw, la mesure ne donne que 17 Go/s, accompagnée d'un Steal Time de 5 %, et le gouffre de cache apparaît à 4 Mo (au lieu des 16 Mo attendus pour le L3). Au même moment, une instance de même configuration chez un autre fournisseur cloud établi coûte 18 % plus cher, mais la bande passante mesurée atteint 32 Go/s, avec un Steal Time quasi nul. En calculant, le taux de prime du premier n'est que de 0,43, le second de 0,81 — le moins cher s'avère en réalité être « cher ».

Ce n'est pas tout. En descendant le test dans l'environnement conteneurisé, en exécutant STREAM dans Docker, j'ai remarqué que le quota CPU de cgroup peut limiter silencieusement la bande passante mémoire, surtout dans les scénarios multicœurs où les résultats de mbw peuvent être surestimés. Ainsi, dans ma méthode d'audit croisé, tous les tests de bande passante doivent enregistrer à la fois le temps dans le conteneur et le temps hors conteneur, puis être normalisés avec le taux de prime FinOps. De cette façon, que ce soit KVM ou Xen, qu'il y ait survente ou non, on peut les ramener à une dimension de prix comparable.

Enfin, une dernière remarque : ne croyez pas à la « facturation en temps réel » ou à l'« auto-scaling », ce ne sont que des douceurs sur la facture. Le vrai rapport qualité-prix, c'est de lancer mbw -b 256, de comparer avec le rapport de gouffre de cache de CloudWorth, de calculer le taux de prime de chacun, puis d'éteindre cette machine « bon marché ». La bande passante mémoire ne ment pas, la facture, si.