Intel vs AMD pour le travail réel : compilation, rendu, VM et IA

octobre 7, 2025 • février 3, 2026 • Lecture : 31 min • Views: 0

Cet article vous a aidé ?

Votre pipeline CI est lent, votre hôte de VM est instable, les rendus Blender débordent sur demain, et votre « machine IA » est inexplicablement limitée par quelque chose qui n’est pas le GPU.
Le choix de CPU que vous avez fait il y a deux trimestres est maintenant une ligne dans vos rapports d’incident.

Intel vs AMD n’est pas une guerre de fans. Ce sont des compromis qui se traduisent par des minutes de build, des ratios de consolidation de VM, des tempêtes de cache-miss, des limites de puissance, et des « pourquoi ce thread est sur l’E-core ? ».
Prenons la décision comme des adultes qu’on a déjà appelés à 3h du matin.

Ce que « travail réel » signifie réellement

« Travail réel » n’est pas un seul benchmark. C’est un tas de goulots qui tournent selon l’heure :
l’éditeur de liens transforme votre CPU en générateur de cache-miss ; un rendu le transforme en moteur thermique ;
la virtualisation en fait un problème d’ordonnancement ; l’IA en fait un pourvoyeur de mémoire.

La question n’est donc pas « lequel est plus rapide ? » C’est :
quel CPU rend votre charge de travail stable, prévisible et rentable sous une charge soutenue — et lequel crée des modes de défaillance qui vous feront travailler le week-end.

Ce sur quoi vous devriez optimiser

Temps jusqu’au résultat : temps mur de compilation, temps de rendu, débit d’entraînement, ou latence des requêtes.
Latence extrême sous contention : le 1% le plus lent est ce qui casse les déploiements et les SLO.
Déterminisme : des fréquences et un comportement d’ordonnancement stables comptent plus que le pic en laboratoire.
Système mémoire : bande passante, latence, nombre de canaux et topologie NUMA décident souvent du gagnant.
E/S et PCIe : GPUs, NVMe, NIC et passthrough sont des décisions de plateforme, pas seulement des décisions de cœurs CPU.
Réalité puissance/refroidissement : votre baie ne se préoccupe pas de ce que dit la brochure marketing.

Positionnement rapide : qui gagne quoi

Vous pouvez argumenter sur des cas limites indéfiniment. En production, la plupart des décisions se résument à « avons-nous besoin de beaucoup de voies mémoire et d’un débit stable ? » vs « avons-nous besoin de la meilleure latence par thread ? » vs « avons-nous besoin du comportement de plateforme le plus simple ? »

Compilation de gros codebases (Linux kernel, Chromium, LLVM, moteurs de jeu)

AMD gagne souvent en débit par dollar quand vous pouvez alimenter beaucoup de cœurs avec suffisamment de mémoire et d’E/S de stockage.
Intel gagne souvent en latence par cœur et a parfois des avantages dans certains toolchains ou bibliothèques, mais l’ordonnancement sur cœurs hybrides peut compliquer les runners CI.
Règle de décision : si vos builds sont parallèles et favorables au cache, les cœurs aident ; si elles sont soumises au lien et à la latence mémoire, les fréquences et le comportement du cache dominent.

Rendu (Blender, Arnold, V-Ray, pipelines offline)

Les deux gagnent si on leur permet de soutenir la puissance. Le CPU qui maintient les fréquences à 100% de charge dans votre châssis gagne, pas celui avec le plus haut « jusqu’à » sur la fiche technique.
Les forts nombres de cœurs d’AMD peuvent être impitoyables dans des fermes de rendu CPU ; Intel peut être compétitif avec un bon comportement toutes-coeurs et certaines caractéristiques AVX.
Règle de décision : achetez pour la fréquence toutes-coeurs soutenue dans votre enveloppe thermique et votre budget de puissance.

Hôtes VM (KVM/Proxmox/VMware, charges mixtes)

AMD EPYC est fréquemment le choix pragmatique pour la densité : beaucoup de cœurs, beaucoup de canaux mémoire, beaucoup de lignes PCIe, bon perf/W.
Intel Xeon peut briller grâce à la maturité de la plateforme, certains écosystèmes d’accélérateurs, et parfois un meilleur single-thread pour les tâches « bruyantes » de plan de contrôle.
Règle de décision : priorisez la capacité/bande passante mémoire et le budget de lignes PCIe plutôt que le turbo brut des cœurs.

IA (entraînement et inférence, avec GPU mais CPU non négligeable)

Le CPU alimente le GPU : prétraitement des données, tokenization, pipeline d’entrée, compression/décompression, réseau et système de fichiers reposent tous sur le CPU.
AMD gagne souvent sur les canaux mémoire et les lanes en serveurs, ce qui aide à garder les GPUs occupés ; Intel peut gagner sur certaines instructions vectorielles et l’optimisation de bibliothèques selon la pile.
Règle de décision : si vos GPUs attendent, achetez la plateforme CPU/mémoire/E/S qui les empêche d’attendre.

Faits et historique qui comptent encore

x86-64 vient d’AMD (AMD64). Intel l’a adopté plus tard, et l’industrie a suivi parce que c’était la migration la moins douloureuse.
L’ère « tick-tock » d’Intel a habitué les acheteurs à des réductions de processus prévisibles ; quand ce rythme a rompu, la stabilité de la plateforme est devenue un différenciateur plus important que la fréquence brute.
Les designs chiplet sont devenus grand public avec AMD, permettant des nombres élevés de cœurs et des dies d’E/S flexibles ; cela a changé la courbe « plus de cœurs coûte plus cher ».
NUMA n’a jamais disparu. Les designs multi-die font de la localité mémoire une caractéristique de performance de première classe, pas un détail académique.
AVX-512 est devenu une saga de compatibilité : puissant sur certaines puces Intel, absent ou différent sur d’autres, et généralement à considérer comme « un bonus si vous l’avez », pas une stratégie.
L’ère Spectre/Meltdown a appris à tous que des caractéristiques microarchitecturales peuvent devenir des responsabilités de sécurité avec un impact sur la performance.
Les cœurs hybrides d’Intel ont apporté la complexité d’ordonnancement des laptops aux desktops/serveurs ; cela peut être excellent, mais c’est aussi une nouvelle catégorie de tickets « pourquoi c’est lent ? ».
Le budget de lignes PCIe a été un différenciateur discret dans les plateformes workstation/serveur ; il décide si vous pouvez faire tourner plusieurs GPUs, NVMe rapides et NICs haute vitesse sans compromis.

Compilation : débit, latence et cache

La compilation est une charge cruelle parce qu’elle semble CPU-limited jusqu’à ce que vous l’instrumentiez.
Ensuite vous découvrez que votre CPU cher attend de petites lectures, des misses du page cache, la résolution de symboles, ou une phase mono-thread dans l’éditeur de liens.

Ce qui rend réellement les compilations rapides

Stockage rapide pour le source et les artefacts de build (NVMe, IOPS suffisants, pas de filesystem réseau partagé qui a sa mauvaise journée).
Assez de RAM pour garder en chaud en-têtes, objets et working sets du compilateur.
Bonne performance par thread pour les phases sérielles (étapes de configuration, linkers, goulots de codegen).
Beaucoup de cœurs pour la compilation parallèle, mais seulement si vous pouvez les alimenter sans thrash d’E/S.
Cache et latence mémoire parce que le front-end du compilateur fait beaucoup de pointer chasing.

Intel vs AMD : schémas de compilation

En pratique, le « plus de cœurs pour l’argent » d’AMD gagne souvent pour les grosses builds quand votre système de build parallélise bien.
Intel semble souvent plus réactif pour le développement interactif et certaines phases mono-thread, surtout si les fréquences restent élevées sous charge.

Le piège : acheter un grand nombre de cœurs puis compiler sur un runner avec un petit disque RAM, un SSD lent ou un filesystem partagé surchargé.
C’est comme finir avec 64 cœurs et un build qui fonctionne comme s’il était propulsé par des hamsters.

Blague #1 : Un serveur de build sans RAM suffisante, c’est comme une machine à café sans eau — techniquement impressionnant, pratiquement une scène de crime.

Cœurs hybrides et runners CI

Les designs à cœurs hybrides d’Intel peuvent être excellents, mais les systèmes CI et les outils de build ne sont pas toujours polis quant à l’endroit où les threads atterrissent.
Si vos threads de compilation lourds basculent sur des cœurs d’efficacité, le temps mur et la variance peuvent augmenter.
La correction est rarement « acheter des CPU différents » et plus souvent « pinnez, isolez et mesurez. »

Rendu : cœurs, fréquences et puissance soutenue

Le rendu est honnête. Il prend le CPU que vous avez acheté et le transforme en chaleur pendant des heures.
La mention « boost clock » est surtout du marketing sauf si votre refroidissement et votre alimentation sont réels.

Ce qui compte pour le rendu CPU

Fréquence toutes-coeurs soutenue à des températures sûres, pas le boost single-core.
Nombre de cœurs pour des workloads de rendu parfaitement parallèles.
Bande passante mémoire pour la complexité des scènes et les workloads riches en textures (varie selon le moteur).
Stabilité sous charges AVX/vectorielles. Certains chemins de code réduisent fortement les fréquences sous instructions vectorielles lourdes.

Intel vs AMD : réalité du rendu

Si vous construisez une ferme de rendu, la densité de cœurs d’AMD a historiquement été attrayante, surtout avec des configurations mémoire sensées.
Intel peut absolument gagner dans certaines fenêtres prix/perf et quand le moteur profite de certains mixes d’instructions ou du comportement d’ordonnancement.
Mais le facteur décisif est généralement opérationnel : limites de puissance, refroidissement en baie, et si la plateforme bride.

Le rendu fait aussi de « l’efficacité » une ligne budgétaire. Moins de watts par frame signifie plus de nœuds par baie et moins d’emails fâchés des facilities.

VM et conteneurs : NUMA, IOMMU et voisins bruyants

La virtualisation est l’endroit où les CPU cessent d’être des « puces » et deviennent des systèmes. Vous achetez maintenant de la topologie : canaux mémoire, lignes PCIe, routage d’interruptions, comportement IOMMU, et facilité d’ordonnancement.

Pourquoi AMD paraît souvent bon pour les hôtes VM

Densité de cœurs aide la consolidation quand vous avez beaucoup de VMs moyennes.
Canaux mémoire comptent pour le débit agrégé et pour éviter les pénalités d’accès NUMA distant.
Lignes PCIe comptent pour pools NVMe, NICs et passthrough GPU sans compromis.

Pourquoi Intel peut être un choix d’entreprise plus sûr parfois

Consistance de la plateforme à travers les générations dans certaines flottes, ce qui réduit la variance opérationnelle.
Alignement écosystème avec certains fournisseurs, outils firmware et stacks de drivers.
Bon single-thread pour les services control-plane et les charges mixtes sensibles à la latence.

NUMA : la taxe invisible

Les problèmes NUMA ressemblent à « ma VM est lente parfois. » L’hôte montre beaucoup de CPU. Le disque semble correct. Le réseau semble correct.
Puis vous réalisez que la moitié des accès mémoire sont distants.

Les systèmes multi-socket Intel et AMD, et même certains designs single-socket à chiplets, peuvent vous mordre ici. La correction est prévisible :
alignez l’allocation vCPU et mémoire, évitez les allocations cross-node, et arrêtez de prétendre qu’« un gros CPU » est une réalité.

Passthrough PCI et bizarreries IOMMU

Pour le passthrough GPU ou le passthrough NIC haute vitesse, les groupements IOMMU et les réglages firmware importent plus que la marque.
Vous voulez une carte mère/BIOS qui se comporte comme un outil, pas comme une boîte à puzzles.

Charges IA : le CPU compte plus que vous ne le souhaitez

Si vous lancez de l’entraînement GPU et pensez « le CPU ne compte pas », vous n’avez probablement jamais vu un GPU à 10k$ inactif parce qu’un thread dataloader est bloqué sur une décompression.

Où les CPU deviennent goulots pour les systèmes IA

Pipeline d’entrée : décodage d’images, parsing d’enregistrements, tokenization, augmentation.
Stockage et système de fichiers : petites lectures, opérations de métadonnées, comportement de cache.
Réseau : déplacement de données pour l’entraînement multi-nœuds ou les couches de serving.
Math côté CPU : prétraitement d’embeddings, feature engineering, post-traitement.
Surcharge d’orchestration : runtime Python, contention de threads, overhead conteneur, interruptions.

Intel vs AMD pour les machines IA

Si vous Construisez des serveurs GPU, l’histoire des lanes et de la mémoire d’AMD peut être une victoire claire : plus d’espace pour GPUs et NVMe sans jeu de piste PCIe.
Intel peut être excellent lorsque votre stack est optimisé autour de certaines bibliothèques, lorsque vous avez besoin d’un fort single-thread pour une inférence à haut QPS, ou quand votre solution vendor l’exige.

Le meilleur indicateur pratique n’est pas le « score benchmark CPU », c’est l’utilisation GPU dans le temps et le débit de bout en bout.
Si vos GPUs ne sont pas occupés, votre choix CPU/plateforme peut en être la cause.

Compromis de plateforme : mémoire, PCIe, puissance et ce que vous regrettez plus tard

Canaux mémoire et capacité

Pour les VMs et l’IA, la capacité et la bande passante mémoire sont souvent le plafond réel.
Un CPU avec « moins de cœurs plus rapides » peut perdre face à un CPU avec « plus de canaux mémoire et suffisamment de cœurs » quand la charge est alimentée par la mémoire.

Si vous sous-provisionnez la mémoire, vous finirez par optimiser des choses qui ne devraient pas nécessiter d’optimisation : contrôles d’échange agressifs, astuces de cache du filesystem, et limites de service étranges.
Ce n’est pas malin. C’est du contrôle des dégâts.

Lignes PCIe et topologie

Multi-GPU, pools NVMe RAID/ZFS, et NIC 100GbE sont gourmands en lanes.
Si vous achetez une plateforme qui ne peut pas les câbler proprement, vous passerez du temps à déboguer pourquoi une carte est bloquée en x4 ou pourquoi deux périphériques partagent la bande passante.

Limites de puissance : la différence entre « benchmark » et « mardi »

La performance CPU est de plus en plus « combien de temps pouvez-vous maintenir les fréquences avant que la plateforme flanche. »
Surveillez les réglages BIOS par défaut qui poussent les limites de puissance pour gagner en marketing, puis qui brident en charge réelle.
Pire : ils chauffent au point de réduire la durée de vie et d’augmenter les taux d’erreur. C’est une taxe de fiabilité déguisée en performance.

La fiabilité est une fonctionnalité, pas une ambiance

Voici votre citation, parce que c’est le boulot :
« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Appliqué aux CPU : n’espérez pas que votre ordonnanceur fera la bonne chose, n’espérez pas que les paramètres BIOS par défaut sont sains, n’espérez pas que votre refroidissement suffit, n’espérez pas que la topologie NUMA n’a pas d’importance.
Mesurez, configurez et validez.

Tâches pratiques : commandes, sorties et décisions

Vous ne choisissez pas Intel ou AMD sur des impressions. Vous choisissez en fonction de ce que vos systèmes vous montrent sous charge.
Ci-dessous des tâches concrètes à exécuter sur des hôtes Linux pour diagnostiquer et décider.

Task 1: Identify CPU topology (cores, threads, NUMA)

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-31
NUMA node1 CPU(s):                    32-63

Ce que cela signifie : un socket, mais deux nœuds NUMA (commun avec les chiplets). L’accès mémoire cross-node peut vous coûter cher.
Décision : pour le pinning VM ou les jobs de rendu, conservez les allocations CPU et mémoire au sein d’un nœud NUMA quand c’est possible (ou au moins testez les deux options).

Task 2: Verify frequency scaling and governor

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Ce que cela signifie : le governor est réglé sur performance, typiquement bon pour les fermes de compilation et la latence.
Décision : si vous voyez powersave sur un serveur qui fait des builds/rendus, attendez-vous à des résultats plus lents et plus variables ; changez le governor ou définissez la politique BIOS/OS en conséquence.

Task 3: Watch real-time throttling and thermals

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 5
Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt
4050      92.10   4395     3600     86      215.3

Ce que cela signifie : le CPU est occupé, la température du package est élevée, et la consommation est substantielle. Si Avg_MHz ou Bzy_MHz s’effondre avec le temps, vous êtes en throttling.
Décision : si les MHz soutenus chutent pendant les rendus, corrigez le refroidissement/les limites de puissance avant d’acheter un CPU « plus rapide ».

Task 4: Confirm microcode and kernel mitigations

cr0x@server:~$ dmesg | egrep -i 'microcode|spectre|meltdown' | tail -n 6
[    0.231] microcode: updated early: 0x2f -> 0x35, date = 2024-02-12
[    0.873] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.873] Spectre V2 : Mitigation: Retpolines; IBPB: conditional; STIBP: always-on; RSB filling
[    0.873] Meltdown   : Mitigation: PTI

Ce que cela signifie : vous payez une taxe de performance pour des mitigations de sécurité, et vous êtes sur un microcode récent.
Décision : si une charge a régressé après des mises à jour, mesurez le coût ; ne retirez pas la sécurité aveuglément — envisagez un rafraîchissement matériel si la taxe est inacceptable.

Task 5: Measure compile throughput with a reproducible build

cr0x@server:~$ /usr/bin/time -v make -j$(nproc)
...
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:42.11
User time (seconds): 24012.55
System time (seconds): 1120.33
Percent of CPU this job got: 620%
Maximum resident set size (kbytes): 25100432

Ce que cela signifie : l’utilisation CPU n’est pas près de 6400% sur une machine 64-thread ; vous laissez des cœurs inactifs — souvent I/O ou contention mémoire.
Décision : si CPU% est bas, arrêtez d’acheter des cœurs et commencez à réparer l’E/S (NVMe, tmpfs pour le répertoire de build, meilleur ccache, plus de RAM).

Task 6: Detect I/O wait during builds or training

cr0x@server:~$ iostat -xz 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.22    0.00    7.10   24.55    0.00   30.13

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   210.0  9800.0 18200.0   8.40   0.32  10.5

Ce que cela signifie : %iowait est élevé ; le CPU attend le stockage.
Décision : si iowait domine, la marque du CPU est secondaire — corrigez la localité de stockage, les problèmes de profondeur de file d’attente, le filesystem, ou déplacez les artefacts de build hors des volumes congestionnés.

Task 7: Check memory pressure and swapping

cr0x@server:~$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0 184320  10240 8123456  0    0   120   240 6200 9800 55  8 30  7  0
18  2  524288  20480  11000 620000  0  4096  150  1200 7500 15000 48 12 20 20 0

Ce que cela signifie : des swaps-out (so) en pics et wa qui monte. Vous paginez.
Décision : plus de cœurs n’aidera pas ; ajoutez de la RAM, réduisez le parallélisme, ou corrigez les processus hors contrôle. Pour les hôtes VM, c’est aussi le signe d’un overcommit mémoire devenu sauvage.

Task 8: Confirm NUMA memory locality for a process

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (renderd)
Node 0          18240.12
Node 1           1120.55
Total           19360.67

Ce que cela signifie : le processus utilise majoritairement la mémoire du Node 0. Bonne localité si ses threads sont sur le Node 0.
Décision : si la mémoire est divisée mais que les threads ne le sont pas, pinnez avec numactl ou ajustez les réglages vNUMA de la VM ; le trafic cross-NUMA peut ruiner les performances de rendu et de VM.

Task 9: Validate virtualization extensions and IOMMU

cr0x@server:~$ egrep -m1 -o 'vmx|svm' /proc/cpuinfo
svm

cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head
[    0.612] AMD-Vi: IOMMU performance counters supported
[    0.613] AMD-Vi: Interrupt remapping enabled

Ce que cela signifie : la virtualisation matérielle est présente (svm pour AMD, vmx pour Intel) et l’IOMMU est active.
Décision : si l’IOMMU est désactivée, le passthrough PCI sera douloureux ou impossible ; corrigez le BIOS et les paramètres du kernel avant d’accuser le choix du CPU.

Task 10: Inspect KVM/QEMU host for steal time and contention

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.0 (server)  01/10/2026  _x86_64_  (64 CPU)

12:00:01 AM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
12:00:02 AM  all  62.0  0.0  7.5   1.0     0.0  0.5    0.0   29.0

Ce que cela signifie : faible iowait et pas de steal sur l’hôte ; bien. Dans les invités, le steal est le canari pour l’oversubscription.
Décision : si les invités montrent du steal élevé, réduisez l’overcommit, réservez des cœurs pour les services bruyants, ou séparez les VMs sensibles à la latence.

Task 11: Check PCIe link width and speed (GPU/NVMe bottlenecks)

cr0x@server:~$ sudo lspci -s 65:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

Ce que cela signifie : le GPU tourne à la largeur et la vitesse de lien complète.
Décision : si vous voyez x8 ou moins de façon inattendue, vérifiez le câblage du slot, la bifurcation ou le partage de lanes. C’est un choix de plateforme qui vous mord, pas la performance brute du CPU.

Task 12: Verify huge pages and memory backing for VMs

cr0x@server:~$ grep -i huge /proc/meminfo | head
AnonHugePages:    12582912 kB
HugePages_Total:      2048
HugePages_Free:       1024
Hugepagesize:         2048 kB

Ce que cela signifie : les huge pages sont configurées et partiellement libres.
Décision : pour des VMs à haut débit (bases, NFV), les huge pages peuvent réduire la pression TLB. Si vos hôtes fragmentent et que les huge pages ne sont pas disponibles, planifiez une allocation au boot et des fenêtres de maintenance.

Task 13: Detect scheduler weirdness with hybrid cores (Intel)

cr0x@server:~$ ps -eo pid,comm,psr,pri,ni,cls --sort=-pri | head
  PID COMMAND         PSR PRI  NI CLS
 9421 clang++          11 139  -   TS
 9418 clang            37 139  -   TS
 9416 ld               2  139  -   TS

Ce que cela signifie : les processus tournent sur des IDs CPU spécifiques (PSR).
Décision : si des threads critiques atterrissent régulièrement sur des cœurs plus lents (souvent observable sur certaines plages CPU), définissez l’affinité CPU pour les agents de build ou utilisez cpuset/cgroup pour partitionner.

Task 14: Determine whether the GPU is being starved (AI training)

cr0x@server:~$ nvidia-smi dmon -s pucm -d 2 -c 3
# gpu   pwr  sm   mem  enc  dec  mclk  pclk
# Idx     W   %    %    %    %   MHz   MHz
    0    95  42   18    0    0  8101  1410
    0    96  39   17    0    0  8101  1410
    0    92  44   19    0    0  8101  1410

Ce que cela signifie : l’utilisation SM oscille autour de ~40%. Si votre modèle devrait saturer le GPU, vous êtes probablement limité par l’entrée ou par le CPU.
Décision : profilez l’utilisation CPU du dataloader, le débit stockage et le réseau ; envisagez plus de cœurs CPU, du stockage plus rapide, ou un meilleur parallélisme de prétraitement avant d’acheter plus de GPUs.

Mode opératoire de diagnostic rapide

Quand la performance est mauvaise, ne commencez pas par « Intel vs AMD. » Commencez par le goulot. Voici l’ordre de triage qui vous fait gagner du temps et de la dignité.

Première étape : confirmez que le système ne vous ment pas

Vérifiez le throttling (thermique/power) : la fréquence s’effondre-t-elle sous charge soutenue ?
Vérifiez la politique de governor/power : êtes-vous coincé en powersave ou en mode éco agressif ?
Vérifiez les régressions microcode/BIOS : une mise à jour récente a-t-elle changé le comportement ?

Deuxième étape : classez le goulot en 60 secondes

CPU-bound : fort user CPU, faible iowait, fréquences stables.
I/O-bound : iowait élevé, latence stockage/await en hausse, CPU% bas pour le job.
Memory-bound : beaucoup de cache-miss (si mesuré), fautes de page fréquentes, ou accès NUMA distants.
Scheduler-bound : files de runnable élevées, basculements de contexte massifs, migrations de threads, pics de latence extrême.

Troisième étape : mappez au bon « type de correctif »

Si CPU-bound : plus de cœurs (débit) ou des cœurs plus rapides (latence) ; considérez des optimisations ISA/bibliothèques.
Si memory-bound : plus de canaux, mémoire plus rapide, meilleure placement NUMA ; réduisez le trafic cross-node.
Si I/O-bound : scratch NVMe local, tuning filesystem, caching, évitez les FS distants pour les artefacts chauds.
Si scheduler-bound : isolez des cœurs, pinnez les workloads, ajustez les cgroups, réduisez l’interférence des voisins bruyants.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse (NUMA « n’a pas d’importance »)

Une société SaaS de taille moyenne a migré son cluster de virtualisation principal. Les anciens hôtes étaient modestes : moins de cœurs, comportement mono-NUMA, et des performances « suffisantes ».
Les nouveaux hôtes étaient des bêtes — plus de cœurs, mémoire plus rapide, mieux sur le papier.

En une semaine, le canal d’incidents s’est animé. Certaines VMs de base de données montraient des pics de latence pendant des tâches de fond routinières.
Pas toujours, pas de façon prédictible. Les graphiques d’utilisation CPU semblaient corrects. La latence stockage semblait correcte. Le réseau était ennuyeux.
La rotation on-call a développé une superstition : « ne pas déployer après le déjeuner. »

La fausse hypothèse était simple : « un socket = mémoire uniforme. » La nouvelle plateforme exposait deux nœuds NUMA, et l’hyperviseur plaçait joyeusement des vCPUs sur un nœud pendant que les allocations mémoire dérivaient vers l’autre sous pression.
L’accès mémoire distant s’est transformé en « jitter aléatoire », et le jitter en latence extrême.

La correction n’était pas exotique. Ils ont ajusté le vNUMA des VMs, pinné les VMs les plus sensibles à un set de CPU aligné sur un nœud, et arrêté de surcommiter la RAM sur ces hôtes.
Les performances se sont stabilisées immédiatement. Pas d’héroïsme, juste conscience de la topologie.

La leçon : Intel ou AMD n’a pas causé cet incident. La croyance que la topologie est optionnelle l’a fait.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (tuning power agressif)

Un studio créatif faisait tourner des nœuds de rendu CPU la nuit et voulait réduire les coûts énergétiques. Quelqu’un a été ambitieux et appliqué des caps de puissance agressifs dans le BIOS sur toute la flotte.
Le « test rapide » était un rendu court qui finissait bien, donc le changement a été déployé.

Un mois plus tard, les délais ont commencé à glisser. Les rendus du soir ne terminaient plus. La file s’est allongée.
Le studio a d’abord blâmé la nouvelle version du renderer, puis le stockage, puis « les mises à jour Windows » parce que c’est la tradition.

Le vrai problème : les charges toutes-coeurs soutenues sous les nouveaux caps plaçaient les CPUs à des fréquences nettement plus basses qu’avant.
Le test court ne l’avait pas révélé parce qu’il vivait dans la fenêtre turbo ; les rendus de production vivaient dans la réalité thermique en régime permanent.

Pire, les fréquences plus basses augmentaient le temps de rendu suffisamment pour que les nœuds tournent plus longtemps — la consommation totale n’a pas baissé comme prévu, et l’arriéré a créé du stress opérationnel.
Ils ont rétabli des limites raisonnables, puis réintroduit des caps avec des mesures sur des runs longs et un tuning par nœud.

La leçon : vous pouvez optimiser les watts, mais vous devez mesurer sur des workloads en régime permanent. Le turbo est un menteur bien élevé.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (hôtes baseline + canary)

Une société financière faisait tourner des charges mixtes : builds CI, VMs internes, et quelques services d’inférence. Ils voulaient tester une nouvelle génération de CPU.
Ils ont fait la chose rare : construit deux hôtes canaris avec RAM, stockage, paramètres BIOS et versions du kernel identiques, et les ont fait tourner en parallèle avec la charge de production pendant des semaines.

Pendant l’essai, une mise à jour du kernel a introduit un changement d’ordonnancement qui a légèrement augmenté le jitter sur une architecture pour certains services sensibles à la latence.
Ce n’était pas catastrophique, mais visible sur la queue de latence.

Parce qu’ils avaient une baseline et un canari, ils l’ont détecté tôt, corrélé avec la fenêtre de mise à jour, et retenu cette version du kernel en production.
Pas d’incidents. Pas de salle de crise. Juste un « pas aujourd’hui » silencieux.

La leçon : l’outil de performance le plus efficace est une expérience contrôlée. C’est aussi la chose la moins glamour de la salle, donc on l’oublie.

Erreurs courantes : symptômes → cause → correctif

1) Les builds sont plus lentes après un « upgrade » vers plus de cœurs

Symptômes : le temps mur de build s’améliore à peine ; l’utilisation CPU est faible ; iowait monte.

Cause : le stockage et le page cache ne peuvent pas alimenter la compilation parallèle ; le scanning d’en-têtes et les écritures d’objets saturent les IOPS.

Correctif : placez le répertoire de build sur NVMe local, augmentez la RAM, activez/taillez ccache, réduisez -j à une valeur qui n’entraîne pas de thrash, et évitez les files partagées pour les artefacts chauds.

2) Jitter de latence VM qui semble « aléatoire »

Symptômes : pics périodiques de latence invité ; le CPU hôte semble sous-utilisé ; pas de problème d’E/S évident.

Cause : désalignement NUMA ou ballooning mémoire provoquant des accès mémoire distants ; overcommit causant du steal time.

Correctif : configurez vNUMA, pinnez les vCPUs, liez la mémoire, réduisez l’overcommit pour les VMs sensibles, et validez avec numastat et les métriques de steal des invités.

3) Les nœuds de rendu benchmarkent bien mais sous-performent en production

Symptômes : les tests courts sont rapides ; les rendus longs ralentissent ; les températures sont élevées ; les fréquences chutent.

Cause : throttling thermique/puissance, attentes irréalistes sur le boost, ou chemins AVX lourds provoquant une baisse de fréquence.

Correctif : mesurez la fréquence soutenue, améliorez le refroidissement, définissez des limites de puissance sensées, et validez sous un rendu long en régime permanent.

4) Faible utilisation GPU en entraînement/inférence

Symptômes : GPUs au repos ; cœurs CPU occupés ; iowait disque ou attente réseau présentes.

Cause : pipeline d’entrée CPU-bound ou stockage-bound ; trop peu de workers de dataloader ; décompression lente ; latence FS distante.

Correctif : augmentez le parallélisme du dataloader avec précaution, déplacez les datasets sur NVMe local, pré-décodez/packez les données, et surveillez le débit de bout en bout plutôt que le seul temps modèle.

5) « Même SKU, performance différente »

Symptômes : des hôtes identiques se comportent différemment ; l’un est plus lent ou plus variable.

Cause : defaults BIOS différents (puissance, interleaving mémoire, SMT), versions microcode différentes, ou un hôte thermiquement désavantagé.

Correctif : standardisez les réglages firmware, figez les versions, validez avec un workload baseline, et traitez le BIOS comme de la gestion de configuration, pas du folklore.

6) Services à threads lourds qui régressent sur CPUs hybrides

Symptômes : latence extrême plus élevée ; temps de réponse imprévisible ; CPU semble « pas si occupé ».

Cause : l’ordonnanceur place des threads critiques sur des cœurs plus lents ou migre trop agressivement ; la mixité de performance des cœurs crée de la variance.

Correctif : isolez les cœurs de performance pour les services critiques, utilisez cgroups/cpuset, et validez avec des métriques par cœur ; évitez de compter sur les valeurs par défaut.

Blague #2 : Si votre plan de performance est « on va juste autoscaler », félicitations — vous venez d’inventer une excuse très coûteuse.

Listes de contrôle / plan étape par étape

Étape par étape : choisir Intel vs AMD pour une nouvelle station de travail (compilation + rendu + VMs occasionnelles)

Notez la charge dominante en heures/semaine : compilation, rendu, VMs, prétraitement IA.
Sélectionnez la classe de goulot : sensible à la latence (single-thread), débit (toutes-coeurs), bande passante mémoire, ou intensif en E/S.
Fixez un objectif RAM : 64–128GB pour builds/rendus multi-projets sérieux ; plus si vous exécutez plusieurs VMs.
Planifiez le stockage : un NVMe pour l’OS, un pour scratch/build/cache, optionnellement un pour datasets/projets.
Décidez de la stratégie de cœurs :
- Si vous compilez de gros codebases toute la journée : priorisez cœurs, cache et RAM suffisante et scratch rapide.
- Si le rendu est prioritaire : priorisez la performance toutes-coeurs soutenue et le refroidissement.
Validez les lanes plateforme : besoins GPU + NVMe + NIC. N’achetez pas une plateforme qui vous force à des compromis connus.
Exécutez un benchmark canari sur un repo/une scène représentative avant d’acheter 20 machines.

Étape par étape : choisir un CPU hôte de virtualisation (édition « ne pas être appelé »)

Inventoriez les profils de VM : CPU par VM, RAM par VM, IOPS stockage par VM, et si vous faites du passthrough.
Décidez la politique d’overcommit à l’avance : overcommit CPU possible ; overcommit mémoire seulement avec plan et monitoring.
Dimensionnez les canaux et la capacité mémoire avant le nombre de cœurs. La mémoire affamée rend les cœurs décoratifs.
Modélisez le comportement NUMA : planifiez un placement aligné nœud pour les grosses VMs ; évitez de les étaler sauf nécessité.
Confirmez la marge de lignes PCIe : NICs, NVMe, HBAs, GPUs. La famine de lanes est un regret permanent.
Standardisez BIOS et microcode : traitez-les comme la configuration de la flotte ; gardez un profil connu-good.
Planifiez l’observabilité : compteurs perf par hôte, steal dans les invités, et latence stockage.

Étape par étape : sélection CPU/plateforme pour serveur IA (centré GPU, mais pas aveugle au CPU)

Commencez par les GPUs : nombre, génération PCIe, alimentation et refroidissement.
Raisonnez à rebours les besoins CPU : pouvez-vous alimenter ces GPUs ? Considérez le dataloader CPU, la compression et le réseau.
Priorisez la bande passante mémoire : assez de canaux et vitesse pour le prétraitement et le travail côté hôte.
Priorisez les E/S : NVMe local pour datasets, assez de lanes, et une vraie NIC si vous faites de l’entraînement distribué.
Mesurez l’utilisation GPU tôt avec un pipeline réaliste ; n’acceptez pas « ça entraîne » comme critère de validation.

FAQ

1) Pour des serveurs de compilation, vaut-il mieux acheter plus de cœurs ou des cœurs plus rapides ?

Si vos builds se parallélisent bien et que votre stockage/RAM suivent, plus de cœurs gagnent. Si le temps de link ou les étapes sérielles dominent, des cœurs plus rapides gagnent.
Mesurez l’utilisation CPU pendant les builds ; un CPU% bas suggère que vous n’êtes pas lié aux cœurs.

2) Le design à cœurs hybrides d’Intel en fait-il un mauvais choix pour le travail réel ?

Pas intrinsèquement. Il rend les valeurs par défaut plus risquées. Si vous exécutez des services sensibles à la latence ou une CI prévisible, vous pourriez avoir besoin de pinning et d’isolation.
Si vous ne voulez pas penser à l’ordonnancement, choisissez une plateforme à cœurs uniformes.

3) Les CPU AMD sont-ils moins stables pour la virtualisation ?

Sur des plateformes serveur mûres, la stabilité dépend surtout de la qualité du firmware, des fournisseurs de cartes et de votre discipline de configuration.
AMD EPYC est largement déployé pour la virtualisation. Traitez BIOS/microcode comme partie du système, pas comme une réflexion après coup.

4) Qu’est-ce qui compte le plus pour la densité VM : les cœurs ou la RAM ?

Pour la plupart des flottes VM réelles, la RAM. L’overcommit CPU peut être survivable ; l’overcommit mémoire devient souvent générateur d’incidents.
Si vous swappez sur l’hôte, vous n’exécutez plus une plateforme VM — vous exécutez une plateforme de déception.

5) Ai-je besoin d’AVX-512 pour l’IA ou le rendu ?

Généralement non. Cela peut aider dans certaines inférences CPU-bound ou workloads vectoriels lourds, mais l’écosystème est incohérent.
Planifiez autour du débit de bout en bout et des bibliothèques que vous utilisez réellement, pas de la trivia d’une extension d’instructions.

6) Pourquoi mon CPU cher est-il sous-performant dans Blender ?

Le rendu soutenu expose les limites thermiques et de puissance. Vérifiez les fréquences et températures soutenues.
Assurez-vous aussi que la mémoire est correctement configurée (canaux peuplés) et que le système ne bride pas à cause du VRM ou des contraintes du châssis.

7) Pour un serveur GPU IA, comment savoir si le CPU est le goulot ?

Surveillez l’utilisation GPU dans le temps. Si l’utilisation SM est faible et que le CPU est occupé ou que l’iowait est élevé, le pipeline CPU/stockage limite le débit.
Corrigez la localité des données et le prétraitement d’abord ; ensuite envisagez des upgrades CPU.

8) Intel est-il toujours meilleur pour la latence mono-thread ?

Souvent compétitif, parfois leader, mais pas « toujours ». AMD peut être excellent en performance par thread aussi, selon la génération et les réglages de puissance.
L’ennemi réel est la variance : throttling, contention en arrière-plan et comportement de l’ordonnanceur.

9) Puis-je « résoudre » la performance en augmentant juste `-j` dans les builds ?

Vous pouvez aussi éteindre un feu de cuisine en ouvrant plus de fenêtres. Ça change l’aération, pas la physique.
Au-delà d’un certain point, plus de parallélisme augmente les cache-miss et la contention E/S ; ajustez -j selon l’utilisation CPU mesurée et l’iowait.

10) Quelle est la recommandation par défaut la plus sûre si je n’ai pas le temps de benchmarker ?

Pour les hôtes VM et les serveurs multi-GPU : privilégiez les plateformes avec des canaux mémoire et des lignes PCIe abondants (souvent AMD EPYC dans de nombreuses gammes de prix).
Pour des stations de développement interactives : privilégiez une forte performance par thread et un refroidissement stable, et évitez les compromis de plateforme bizarres.

Étapes suivantes que vous pouvez réellement exécuter

Voici le jeu d’actions pratique. Faites cela, et la décision Intel vs AMD devient évidente au lieu d’émotionnelle.

Choisissez trois workloads représentatifs : un build, un scénario VM, un rendu ou une étape de pipeline IA.
Exécutez les commandes ci-dessus sur votre système actuel pendant ces workloads. Classez le goulot (CPU, mémoire, E/S, ordonnanceur).
Corrigez d’abord les goulots bon marché : capacité RAM, scratch NVMe, réglages BIOS puissance/thermiques, pinning NUMA.
Puis seulement choisissez le matériel :
- Si vous êtes vraiment CPU-bound et parallèle : achetez des cœurs (souvent valeur AMD, parfois Intel selon le prix et la plateforme).
- Si vous êtes sériel/sensible à la latence : achetez de la performance par thread et évitez la variance d’ordonnancement.
- Si vous êtes mémoire/E/S-bound : achetez des canaux, de la capacité et des lanes ; la marque CPU est secondaire.
Standardisez firmware et politiques OS comme vous standardisez les configs. Les régressions de performance aiment les « snowflakes » configurés à la main.