Comment vérifier la génération matérielle d'un serveur cloud ? Lancement de l'EPYC 9006, guide pour éviter les vieux CPU

Repérez les vieux CPU avec les benchmarks et Steal Time

Mis à jour 2026-08-07 · CloudWorth

génération matérielleEPYC 9006vieux CPUvérification par benchmarkCloudWorthSteal TimeSurvente VPSBenchmark VPS

Ne vous fiez pas aux configurations annoncées, utilisez les benchmarks et Steal Time pour démasquer la prime des vieux CPU.

Comment vérifier la génération du CPU

Ne vous fiez pas trop vite à l'« EPYC 9006 » indiqué dans la console. J'ai vu trop de pages promotionnelles arborer un nouveau fleuron, alors que le /proc/cpuinfo révèle en réalité un processeur de trois ou quatre ans. Le moyen le plus direct pour vérifier la génération : lscpu ou cat /proc/cpuinfo, regardez le Model name et le Stepping. Par exemple, la série AMD EPYC 9006 appartient à l'architecture Turin ; une simple comparaison avec les anciens EPYC 7002/7003 permet de les distinguer. Si vous trouvez pénible de mémoriser chaque modèle, lancez un test monocœur Geekbench ou sysbench dans CloudWorth, et étudiez-le en parallèle du Steal Time — les benchmarks ne mentent pas, et le temps CPU volé encore moins.

Un piège facile à négliger : la même instance peut se voir attribuer différentes générations selon les zones de disponibilité. J'ai l'habitude de commencer par cat /sys/devices/system/cpu/cpu0/cpufreq/base_frequency pour voir la fréquence de base, puis d'utiliser dd pour mesurer la différence de vitesse avant et après la mise en cache du disque. L'écart de bande passante du cache des anciens CPU est très marqué, tandis que les nouveaux CPU sont beaucoup plus réguliers.

Pour aller plus loin : lancez une petite instance mono-cœur, exécutez stress-ng --cpu 1 pendant 3 minutes, et surveillez le champ steal dans /proc/stat. Si le steal dépasse 10 %, c'est que le voisin vous pique des ressources — ce n'est peut-être pas un problème de génération, mais de surallocation. Mais si vous constatez un steal élevé, un score faible et un ancien modèle, vous pouvez être sûr que le fournisseur pratique une prime sur les vieux CPU. Dans ce cas, ne soyez pas timide : calculez selon la méthode FinOps. Pour le même prix, avec une instance à la demande de nouvelle génération, le rapport performance/prix par cœur n'est-il pas doublé ?

Mon conseil : faites passer la « configuration annoncée » au rang de simple référence, et traitez le « benchmark réel + Steal Time + courbe de cache disque » comme une chaîne de preuves. Une fois ces trois éléments vérifiés, les vieux CPU n'auront plus nulle part où se cacher chez vous.

À quel point l'EPYC 9006 est-il plus performant ?

L'EPYC 9006 (Turin) est basé sur l'architecture Zen 5, avec une amélioration officielle de l'IPC d'environ 17 % par rapport à la génération précédente, et des performances système annoncées comme 1,7 fois supérieures. Mais attention : ce sont des chiffres au niveau du serveur complet, pas ce que vous obtiendrez directement sur un serveur cloud. Les pages marketing des fournisseurs cloud affichent EPYC 9006, mais l'instance réelle peut recevoir un ancien CPU d'un cluster voisin — ce genre de décalage de génération matérielle est monnaie courante dans l'industrie.

Mon habitude est de vérifier en trois étapes :

• lscpu pour voir le modèle/stepping, en les comparant au tableau public des générations de CPU ;
• Lancer Geekbench ou sysbench, et recouper avec les scores nominaux d'une configuration équivalente ;
• Surveiller surtout le Steal Time : si le %st dans top est supérieur à 1 % sur le long terme, cela signifie que l'hôte partagé est fortement surprovisionné, et même un CPU plus récent sera ralenti par ses voisins.

Le bénéfice direct de cette démarche est de calculer la prime FinOps : si un serveur cloud annoncé comme EPYC 9006 n'obtient en réalité que 80 % des performances de l'ancienne génération, alors que vous payez le prix de la nouvelle génération, cela revient à dépenser 25 % de plus par cœur inutilement. Le score réel par rapport à la configuration annoncée est plus honnête que n'importe quel discours marketing. Dans la section suivante, je donnerai les commandes de détection exactes. Mais rappelez-vous d'abord ceci : la génération n'est pas un argument d'achat, ce sont les mesures qui comptent.

Benchmarks réels vs spécifications

De nombreux vendeurs affichent « EPYC 9006 » sur leurs pages marketing, mais le vCPU qui vous est réellement alloué peut encore tourner sur un Rome, voire Naples, vieux de plusieurs années. Pour la génération matérielle des serveurs cloud, il ne faut pas se fier uniquement aux spécifications. Après avoir obtenu une instance, j'ai l'habitude de faire deux choses : lscpu pour voir le Model name, puis sysbench en mono-cœur. Mais le plus important reste le Steal Time — le temps de CPU volé par les voisins sur un VPS partagé. Un %st constamment supérieur à 5% dans top indique une surallocation sévère : les performances d'un nouveau CPU se retrouvent diluées au niveau d'un ancien.

En utilisant CloudWorth pour examiner une instance, je croise sa base de benchmarks et l'indicateur Steal : si le score réel est nettement inférieur à la moyenne de sa génération, il y a de fortes chances que ce soit une configuration dégradée ou du vieux matériel. Par exemple, le score mono-cœur d'un EPYC 9006 devrait être environ 30% plus élevé que celui d'un Milan ; s'il n'est supérieur que de 5%, il faut suspecter une allocation sur un ancien nœud. Avec cat /proc/cpuinfo pour vérifier le family/model/stepping, puis en comparant avec les noms de code officiels d'AMD, on peut généralement confirmer le diagnostic.

C'est ce que FinOps appelle le « taux de surcote » : annoncer une nouvelle génération mais fournir un ancien CPU, c'est payer pour des performances qui n'existent pas. Le cycle de renouvellement matériel des fournisseurs cloud est généralement de 3 à 4 ans. Les anciens CPU montrent des écarts nets en bande passante mémoire et en jeu d'instructions AVX-512 ; les requêtes de base de données et les tâches de compilation révèlent immédiatement ces différences. Mon approche : d'abord sonder avec l'outil de benchmark de /app, puis calculer le rapport qualité-prix selon les performances réelles ; si le taux de surcote dépasse 15%, je change d'instance. Ne vous fiez pas aux spécifications, les benchmarks et le Steal vous diront la vérité.

Vérification du surcoût FinOps

Les surcoûts CPU dans les factures cloud se cachent souvent dans les générations de matériel : la page promotionnelle annonce EPYC 9006, mais c'est un ancien CPU qui est réellement alloué, avec des performances à 70 % et un prix inchangé. Cette prime FinOps peut être démasquée grâce aux benchmarks et au Steal Time.

cat /proc/cpuinfo | grep "model name" | head -1
sysbench cpu run --threads=1 | grep "events per second"

Prenons mon instance : le prétendu AMD EPYC 9006 n'atteint que 1800 au test monocœur, alors que les nouveaux modèles obtiennent en moyenne 2800, soit un écart de 35 %. En vérifiant le steal time dans /proc/stat, un taux supérieur à 5 % indique que les voisins accaparent le CPU, preuve d'une surallocation sévère.

Taux de surcoût FinOps = (score annoncé - score réel) / score annoncé. Au-delà de 20 %, il faut réduire la configuration ou changer de fournisseur. Ne vous fiez pas à la configuration annoncée : croisez le Steal Time de CloudWorth (/app) avec les benchmarks réels pour démasquer la prime des anciens CPU. Souvenez-vous : l'argent économisé est le vrai bénéfice du FinOps.