Détection de la bande passante mémoire des serveurs cloud : comment les performances réelles d'une mémoire de 8 Go orientent le choix de l'inférence IA

Quantifiez la bande passante mémoire avec le protocole STREAM, identifiez la surallocation et la limitation.

Mis à jour 2026-08-10 · CloudWorth

Bande passante mémoireDétectionSurallocation8 GoInférence IACloudWorthSteal TimeSurvente VPSBenchmark VPS

La bande passante mémoire doit être évaluée avec les courbes STREAM, pas seulement sur la configuration annoncée.

Protocole de détection de bande passante

Lorsqu'on parle de bande passante mémoire d'un serveur cloud, l'erreur la plus courante est de considérer la « mémoire DDR4 de 8 Go nominale » comme une garantie de performance. Les benchmarks réels sont souvent plus honnêtes que les fiches techniques — surtout quand on se prépare à exécuter de l'inférence IA mobile (par exemple un modèle quantifié 7B), la fluctuation de la bande passante mémoire détermine directement la vitesse de génération des tokens. Je me suis donc fixé un protocole de détection reproductible, en utilisant STREAM comme charge principale, avec en plus une courbe de série temporelle pour détecter la surréservation ou la limitation.

Le protocole comporte trois étapes : d'abord exécuter le benchmark Copy/Scale de STREAM et enregistrer le pic de bande passante ; ensuite échantillonner en continu pendant 5 minutes, tracer la courbe de bande passante, et observer si des baisses périodiques de vitesse apparaissent ; enfin, utiliser un seuil de jugement — si la bande passante moyenne est inférieure à 60 % de la valeur nominale, ou si la gigue dépasse 20 %, on peut essentiellement conclure qu'un voisin a « volé » de la bande passante. Ce processus a été implémenté sous forme de script dans /app de CloudWorth : il suffit de saisir l'adresse IP et la clé SSH pour générer un rapport, évitant de taper des commandes à la main.

En complément : puisque la détection peut révéler la vraie bande passante, on peut calculer la prime FinOps lors du choix — par exemple, une instance 8 Go de mémoire facturée 100 yuans/mois, si sa bande passante réelle n'est que la moitié de la valeur nominale, le coût par inférence double ; autant alors réduire la configuration et opter pour une instance à plus haute bande passante.

Détection de la surallocation et de la limitation

Lorsque je reçois un serveur cloud annoncé avec 8 Go de RAM, la première chose que je fais est d'exécuter STREAM pour mesurer la bande passante mémoire réelle, plutôt que de regarder la « configuration parfaite » dans la console. Pourquoi ? Parce que le critère clé de la bande passante mémoire d'un serveur cloud ne réside pas dans le pic, mais dans la présence éventuelle de surallocation ou de limitation. Si l'une des quatre courbes Copy/Scale/Add/Triad de STREAM reste constamment en dessous de 60 % de la valeur de référence des clouds publics de même spécification, ou fluctue de plus de ±15 %, on peut raisonnablement soupçonner que le voisin accapare la bande passante. Une méthode plus simple consiste à exécuter le test trois fois de suite et à vérifier la stabilité : un serveur cloud normal présente de légères fluctuations, mais si chaque minute ressemble à des montagnes russes, cela indique une surallocation de l'hôte.

J'ai l'habitude de tracer la série temporelle sur 30 minutes, avec un seuil d'alerte fixé à 10 % de la bande passante moyenne. Si, lors de l'exécution de memtester ou de sysbench, la courbe de bande passante chute soudainement à un moment donné et ne se rétablit pas avant le prochain redémarrage, c'est la preuve concrète d'une limitation. Ce problème diffère du CPU steal time : le steal affecte l'ordonnancement des vCPU, tandis qu'une bande passante mémoire insuffisante ralentit directement l'inférence de modèles sur 8 Go de RAM — par exemple, lors de l'inférence par lots avec LLaMA 2-7B, le traitement de chaque prompt devient nettement saccadé.

Cela touche aussi au rapport qualité-prix : de nombreux « VPS 8 Go bon marché » affichent des configurations séduisantes, mais la bande passante mesurée est seulement la moitié de celle d'un cloud public au même prix. En convertissant le score STREAM en prix par Mo/s, la prime dépasse en réalité 40 %. Je préfère donc utiliser le ratio « score réel / configuration annoncée » pour choisir ; en dessous de 0,7, je raye directement, pour ne pas perdre de temps en optimisation. Si vous envisagez également de faire de l'inférence IA mobile sur ce type de machine, exécutez d'abord mon protocole de détection avant de commander.

Inférence IA avec 8 Go de mémoire

8 Go de mémoire sont désormais la configuration « gardienne » pour l'inférence IA sur mobile — un modèle quantifié 7B peut tout juste tenir dans le mappage mémoire, mais le vrai goulot d'étranglement n'est pas la capacité, c'est la bande passante mémoire. Dans le protocole de test de CloudWorth, on exécute STREAM sur 10 tours et on prend la médiane, puis on ajoute une courbe de série temporelle pour observer la volatilité. Si les valeurs de triads restent stables au-dessus de 85 % de la valeur nominale, cela signifie qu'il n'y a pas de limitation ; si elles tombent sous 60 %, il faut suspecter que des voisins surprovisionnés volent de la bande passante.

J'ai l'habitude d'écrire le processus sous forme d'un extrait bash reproductible :

# 先装工具，再跑 STREAM，记录每轮结果
yum install -y stream 2>/dev/null || apt install -y stream
for i in {1..10}; do stream | grep 'Triad:' | awk '{print $2}' >> bw.log; sleep 2; done
# 统计波动率，超过 25% 则标记为“带宽抖动”
awk '{sum+=$1; a[NR]=$1} END {avg=sum/NR; for(i in a) d+=((a[i]-avg)^2); printf "std=%.1f%%\n", sqrt(d/NR)/avg*100}' bw.log

Après l'exécution, vous constaterez que de nombreux VPS 8 Go annoncés « DDR4 3200 » n'ont en réalité que la moitié de la bande passante d'une machine physique. Ce n'est pas de la magie — l'écart entre les benchmarks réels et la configuration annoncée est souvent le taux de surprovisionnement. Lors du choix, plutôt que de vous fier à la « mémoire haute performance » vantée par le vendeur, demandez-lui de fournir la courbe STREAM.

De plus, une bande passante insuffisante affecte directement le débit d'inférence : lors de la phase de décodage de LLaMA-7B, chaque token nécessite de parcourir les poids, et si la bande passante est réduite de moitié, la latence du premier token double. Ainsi, pour faire tourner de l'IA sur une machine de 8 Go, il vaut mieux réduire la configuration CPU mais préserver la bande passante mémoire. D'un point de vue FinOps, si un modèle n'offre que 60 % de la bande passante annoncée mais n'est que 15 % moins cher, le taux de prime est négatif — ce n'est pas rentable. À l'inverse, si la bande passante est conforme et le prix légèrement plus élevé, le rapport qualité-prix est en réalité meilleur.

Enfin, un avertissement : ne confondez pas la vitesse du cache disque avec la bande passante mémoire. Beaucoup de débutants utilisent dd et obtiennent plusieurs Go/s, croyant que c'est la mémoire qui est rapide, alors qu'il s'agit en réalité du cache de pages (page cache). Pour un vrai test, utilisez STREAM ou sysbench, et exécutez plusieurs tours pendant les heures creuses pour observer la volatilité. Pour la liste de contrôle détaillée, reportez-vous à /guides/cloud-memory-bandwidth-test.

Configuration annoncée vs performances réelles

Dans les fiches techniques des fournisseurs cloud, on lit souvent « 8 Go DDR4 3200 », mais la bande passante mémoire réelle est souvent sur-allouée ou limitée. En exécutant STREAM, vous verrez qu’une machine annoncée à 25 Go/s n’atteint en réalité que 12 Go/s—ce n’est pas un cas isolé, c’est la norme dans le cloud public. Pour vérifier la conformité, ne vous limitez pas à free -h ; observez si la courbe de bande passante présente des variations en dents de scie : si elle reste stable sur une valeur faible, c’est une limitation par cgroup ; si elle fluctue, cela peut être dû à un voisin accapareur.

Les mesures réelles sont plus révélatrices que les spécifications. Pour une même configuration de 8 Go, le fournisseur A offre 12 Go/s et le fournisseur B 20 Go/s ; c’est B qui constitue le meilleur choix pour l’inférence IA en termes de rapport qualité-prix. Une machine réduite à 6 Go mais avec une bande passante suffisante est souvent plus adaptée aux modèles mobiles qu’une machine annoncée à 8 Go avec des performances surestimées. Il est recommandé d’utiliser sysbench ou STREAM pour réaliser trois échantillonnages et de noter les valeurs maximales et moyennes.

Si vous pouvez obtenir un « protocole de sondage » avant l’achat, la checklist de CloudWorth vous fera économiser de l’argent—le cœur du FinOps n’est pas de réduire la configuration, mais d’éliminer les fausses annonces.

Comparaison du taux de prime FinOps

Après plusieurs séries de tests STREAM, si l'on ne considère que la bande passante mémoire nominale de 8 Go, il est facile d'être induit en erreur par le « pic théorique » des fournisseurs de cloud. Dans mon processus de détection CloudWorth, je divise les valeurs mesurées de STREAM Copy et Triad par la bande passante nominale de l'offre, pour obtenir un « taux de réalisation de la bande passante mémoire ». Si un VPS de 8 Go annonce une bande passante nominale de 20 Go/s mais ne mesure que 8 Go/s, le taux de réalisation est de 40 % — il faut alors se demander : est-ce de la survente, une limitation de débit, ou un voisin qui accapare la bande passante du contrôleur mémoire ?

Une approche plus concrète consiste à convertir ce taux en prime FinOps. Par exemple, pour deux offres de 8 Go de mémoire, l'offre A coûte 30 yuan par mois avec une bande passante mesurée de 12 Go/s ; l'offre B coûte 45 yuan par mois avec 9 Go/s. En calculant le « coût mensuel par Go/s de bande passante », A revient à 2,5 yuan et B à 5 yuan — le taux de prime de B atteint 100 %. Beaucoup de VPS bon marché semblent avoir un bon rapport qualité-prix, mais si la bande passante mémoire est limitée, la vitesse de génération de tokens lors de l'inférence IA chute nettement, ce qui rend finalement le coût unitaire de calcul plus élevé.

Lors de mes tests de stress de la bande passante mémoire, j'enregistre également pidstat et /proc/pressure/memory pour distinguer un véritable goulot d'étranglement physique de bande passante d'une fausse baisse causée par le steal CPU de la plateforme cloud. Pour vérifier rapidement le taux de prime de votre offre, vous pouvez consulter la liste de contrôle de détection CloudWorth, qui contient des scripts STREAM prêts à l'emploi et des recommandations de seuils. Ne vous fiez pas uniquement à la mémoire nominale : le taux de réalisation de la bande passante est l'indicateur clé pour choisir une offre de 8 Go destinée à l'inférence IA.

Recommandations pour la migration vers une configuration inférieure

Si vous faites de l'inférence IA mobile sur un serveur cloud avec 8 Go de RAM, la détection de la bande passante mémoire du serveur cloud ne doit pas se fier uniquement aux valeurs nominales. J'ai rencontré une instance « 8 Go » où le STREAM mesurait un Copy de seulement 4,2 Go/s, alors qu'un bare metal de même configuration pouvait atteindre 12 Go/s—ce n'est pas de la surallocation, c'est une limitation QoS. Avant de réduire la configuration, il est conseillé d'observer la courbe de série temporelle pendant 24 heures pour déclencher des seuils, par exemple si la vitesse chute au-delà de 6 Go/s par seconde, cela signifie que le fournisseur traite la bande passante mémoire comme une ressource élastique.

Réduire la configuration ne consiste pas simplement à passer la RAM de 8 Go à 4 Go, il faut aussi tenir compte du couplage entre la bande passante mémoire et la vitesse du cache disque. Beaucoup de petites instances VPS utilisent le cache NVMe pour soutenir les I/O, mais si la bande passante mémoire est limitée, un taux de hit de cache élevé ne sert à rien. J'ai testé avec sysbench : sur la même machine, après réduction, la bande passante mémoire est passée de 8 Go/s à 3 Go/s, et la latence d'inférence a doublé—l'argent économisé ne compense pas.

Il y a un piège lié au taux de prime FinOps : en comparant le cloud public et les VPS bon marché, ne regardez pas seulement le prix par Go de mémoire. Divisez la valeur mesurée par STREAM par le prix pour calculer la « bande passante par yuan ». Vous découvrirez alors que beaucoup de configurations « élevées et bon marché » ont en réalité des primes très élevées. Avant une migration vers une configuration inférieure, comparez la courbe STREAM de l'instance cible avec celle de l'instance actuelle sur 24 heures. Si après réduction la fluctuation de bande passante dépasse 30 %, il est recommandé de conserver la configuration d'origine ou de changer de fournisseur.

Rappelez-vous : pour savoir si la bande passante mémoire est conforme, utilisez la courbe, pas les valeurs nominales. La réduction de configuration n'est pas une opération arithmétique, c'est un processus de recueil de preuves. Pendant la première semaine après la migration, exécutez STREAM une fois par jour et enregistrez le nombre de fois où le throttling est déclenché. Si cela dépasse 3 fois, demandez immédiatement un remboursement ou un rollback—c'est la recommandation pratique de CloudWorth.