Empilement 3D et l’avenir des chiplets : vers où vont les CPU

Pourquoi les CPU ont changé : physique, économie et la fin du « il suffit de réduire »

Pendant des décennies, on pouvait traiter le progrès des CPU comme un abonnement prévisible : chaque génération devenait plus dense, plus rapide et (globalement) moins chère par unité de calcul. Cette ère ne s’est pas terminée par un communiqué spectaculaire. Elle s’est terminée par mille compromis mineurs — courant de fuite, coût de la lithographie, variabilité et la vérité inconfortable que les fils ne suivent pas la même courbe d’échelle que les transistors.

Quand vous entendez « chiplets » et « empilement 3D », ne le traduisez pas par « ingénierie astucieuse ». Traduisez‑le plutôt par : les vieilles hypothèses économiques et physiques ont cassé, donc le packaging est devenu la nouvelle architecture. L’innovation migre de l’intérieur d’une puce vers entre puces.

Faits et contexte historique (le genre qui vous aide vraiment à raisonner)

• Fait 1 : Le scaling de Dennard (densité de puissance restant stable avec la réduction des transistors) s’est effectivement arrêté au milieu des années 2000, forçant le ralentissement de la montée en fréquence et poussant vers des designs multicœurs.
• Fait 2 : La latence des interconnexions est un goulot notable depuis des années ; les fils sur puce ne deviennent pas proportionnellement plus rapides à chaque nœud, donc « plus grand die » signifie plus de temps passé à déplacer des bits.
• Fait 3 : Les limites de réticule plafonnent la taille d’une exposition lithographique ; les très grands dies deviennent des cauchemars de rendement sauf si on les segmente ou les assemble.
• Fait 4 : L’industrie utilise des modules multi‑puces depuis longtemps (pensez : premiers packages double‑die, modules serveurs), mais les chiplets d’aujourd’hui sont bien plus standardisés et critiques pour la performance.
• Fait 5 : La mémoire à large bande passante (HBM) est devenue pratique en empilant des dies DRAM et en les reliant par TSVs, démontrant que l’intégration verticale peut surpasser la bande passante DIMM traditionnelle.
• Fait 6 : L’empilement de cache 3D dans des CPU courants a montré une leçon précise : ajouter de la SRAM verticalement peut booster la performance sans agrandir le die logique le plus chaud.
• Fait 7 : Les cœurs hétérogènes (concept big/little) existent depuis des années dans le mobile ; ils sont désormais courants dans les serveurs parce que la puissance et les thermiques — pas la fréquence de pointe — définissent le débit.
• Fait 8 : Le packaging avancé (interposers 2.5D, ponts silicium, fan‑out) est maintenant un différenciateur compétitif, pas un détail de fabrication en backend.

Résultat opérationnel : les 10–15 % de gains de performance suivants sont moins susceptibles de venir d’un nouvel ensemble d’instructions et plus susceptibles de venir d’une meilleure localité, de hiérarchies mémoire plus intelligentes et de liens die‑à‑die plus serrés. Si votre charge est sensible à la variance de latence, vous devez traiter le packaging et la topologie comme vous traitez le routage réseau.

Chiplets, interconnexions et pourquoi « socket » ne veut plus dire ce que vous pensez

Un CPU chiplet est un package contenant plusieurs dies, chacun spécialisé : cœurs, cache, contrôleurs mémoire, IO, accélérateurs, parfois même processeurs de sécurité. Le package est le produit. Le « CPU » n’est plus une dalle unique ; c’est un petit système distribué sous un heat spreader.

Les chiplets existent pour trois raisons franches :

1. Rendement : les dies plus petits ont un meilleur rendement ; les défauts ne tuent pas un énorme die entier.
2. Mélange de nœuds de process : logique rapide sur un nœud avancé, IO sur un nœud plus mature et moins cher.
3. Agilité produit : réutiliser un IO die validé sur plusieurs SKUs ; varier le nombre de cœurs et les tuiles de cache sans tout refabriquer.

L’interconnect est maintenant de l’architecture

Dans un die monolithique, les chemins cœur→cache et cœur→mémoire sont majoritairement « internes ». Dans des chiplets, ces chemins peuvent traverser un fabric entre dies. L’interconnect a des caractéristiques de bande passante, latence et congestion, et il peut introduire des effets de topologie qui ressemblent étrangement à un problème réseau — sauf que vous ne pouvez pas y appliquer un tcpdump.

Les packages modernes utilisent des fabrics propriétaires, et l’industrie pousse vers des standards interopérables die‑à‑die comme UCIe. Le point clé n’est pas l’acronyme. C’est que les liaisons die‑à‑die sont traitées comme des IO haute vitesse : sérialisées, cadencées, gérées en puissance, entraînées, parfois relancées. Cela signifie que l’état des liens, les compteurs d’erreurs et les états d’alimentation peuvent affecter la performance de façons qui semblent « aléatoires » à moins de les mesurer.

Blague #1 : Les chiplets sont comme des microservices : tout le monde adore la flexibilité jusqu’à ce qu’il faille déboguer la latence à travers des frontières qu’on a créées volontairement.

NUMA n’était pas nouveau. Vous avez simplement arrêté de le respecter.

Les CPU chiplet transforment chaque serveur en une machine NUMA plus nuancée. Parfois les « nœuds NUMA » correspondent aux contrôleurs mémoire ; parfois ils correspondent aux complexes de cœurs ; parfois les deux. Dans tous les cas, la localité compte : quel cœur accède à quelle mémoire, quelle tranche de cache de dernier niveau est plus proche, et à quelle fréquence vous traversez l’interconnect.

Si votre playbook de performance commence et se termine par « ajoutez des cœurs » et « épinglez les threads », vous allez heurter le nouveau mur : la contention d’interconnect et de la hiérarchie mémoire. Le package CPU a maintenant des patterns de trafic internes, et votre charge peut créer des points chauds.

Empilement 3D : bande passante verticale, problèmes verticaux

L’empilement 3D consiste à utiliser plusieurs dies empilés verticalement avec des connexions denses (souvent TSVs, micro‑bumps ou hybrid bonding). On l’utilise pour le cache, la DRAM (HBM) et de plus en plus pour des arrangements logique‑sur‑logique.

Pourquoi empiler ?

• Bande passante : les connexions verticales peuvent être bien plus denses que le routage bord à bord du package.
• Latence : la distance physique plus courte peut réduire le temps d’accès pour certaines structures (surtout le cache).
• Efficacité d’aire : vous pouvez ajouter de la capacité sans agrandir l’empreinte 2D d’un die logique chaud.

Mais on n’a rien sans contrepartie. L’empilement 3D introduit un triangle opérationnel désagréable : thermique, rendement et fiabilité.

Cache empilé : pourquoi ça marche

De la SRAM empilée sur un die de calcul vous donne un grand cache de dernier niveau sans rendre le die logique énorme. C’est un énorme gain pour des charges avec des jeux de travail juste au‑dessus des tailles de cache traditionnelles : beaucoup de jeux, certains flux EDA, certaines bases de données en mémoire, magasins clé‑valeur avec clés chaudes, et pipelines d’analytique avec scans répétés.

Du point de vue exploitation, le cache empilé change deux choses :

1. La performance devient plus bimodale. Si votre charge tient dans le cache, vous êtes un héros. Si ce n’est pas le cas, vous retournez à la DRAM et l’avantage s’évapore.
2. La marge thermique devient précieuse. Du silicium supplémentaire au‑dessus du die de calcul affecte l’écoulement de la chaleur ; le comportement turbo et les fréquences soutenues peuvent changer et se traduire par de la variance de latence.

HBM : l’astuce bande passante avec un prix

HBM empile des dies DRAM et les place près du die de calcul (souvent via un interposer). Cela fournit une énorme bande passante comparé aux DIMMs traditionnels, mais la capacité par stack est limitée et le coût est élevé. Cela change aussi la nature des défaillances et de l’observabilité : les erreurs mémoire peuvent apparaître différemment, et la planification de capacité devient un sport différent.

Le packaging 3D et 2.5D impose aussi une nouvelle règle de conception : votre logiciel doit comprendre les niveaux. HBM vs DDR, mémoire proche vs mémoire lointaine, cache sur package vs cache sur die. « Il suffit d’allouer la mémoire » devient une décision de performance.

Blague #2 : Empiler des dies, c’est super jusqu’à ce qu’on se souvienne que la chaleur s’empile aussi, et contrairement à votre backlog elle ne peut pas être reportée.

Le vrai ennemi : les octets, pas les FLOPS

La plupart des systèmes en production ne sont pas limités par le débit arithmétique brut. Ils sont limités par le déplacement des données : de la mémoire au cache, du cache au cœur, du cœur au NIC, du stockage à la mémoire, et retour. Les chiplets et l’empilement 3D reconnaissent dans l’industrie que la mémoire et l’interconnect sont l’événement principal.

C’est là que l’instinct SRE aide. Quand le package CPU devient un fabric, les goulots ressemblent à :

• IPC élevé mais faible débit (attente mémoire ou contention sur verrous).
• CPU peu occupé mais latence élevée (stalls, défauts de cache, mémoire distante).
• Performance qui baisse après montée en charge (le trafic inter‑chiplet croît superlinéairement).

Ce qui change avec les chiplets et l’empilement

La localité mémoire n’est plus optionnelle. Sur un grand die monolithique, l’accès « distant » peut rester assez rapide. Sur des chiplets, un accès distant peut traverser plusieurs sauts de fabric et concurrencer d’autres trafics. Sur une SKU avec cache empilé, le cache « local » peut être plus grand mais la pénalité d’un miss peut être plus visible à cause d’un comportement fréquence/thermique modifié.

La bande passante n’est pas uniforme. Certains dies ont un accès plus proche à certains contrôleurs mémoire. Certains cœurs partagent des tranches de cache plus étroitement. La topologie peut récompenser une bonne ordonnancement et punir un ordonnancement naïf.

La variance de latence devient normale. Les états de gestion de puissance, le clock gating du fabric et les algorithmes de boost peuvent modifier les latences internes. Votre p99 le remarquera avant vos moyennes.

Thermique et consommation : le package est le nouveau champ de bataille

Sur le papier, vous achetez un CPU avec un TDP et une fréquence boost et vous appelez ça une journée. En réalité, les CPU modernes sont des systèmes gérés en puissance qui négocient constamment les fréquences selon la température, le courant et les caractéristiques de la charge. Les chiplets et les empilements 3D compliquent cette négociation.

Points chauds et gradients thermiques

Avec les chiplets, vous n’avez pas un profil thermique uniforme. Vous avez des points chauds où les cœurs sont denses, des dies IO séparés qui tournent plus frais, et parfois des dies empilés qui empêchent l’extraction de chaleur du die de calcul en dessous. Pour des charges de production longues, les fréquences soutenues comptent plus que les boosts de pointe.

Deux conséquences opérationnelles :

• Les benchmarks mentent plus souvent. Les benchmarks courts atteignent le boost ; la production atteint l’état stationnaire et les limites de puissance.
• Le refroidissement devient de la performance. Un dissipateur marginal ou un problème de flux d’air ne provoquera pas seulement un bridage ; il provoquera de la variance, plus difficile à déboguer.

Fiabilité : plus de connexions, plus d’endroits tristes

Plus de dies et plus d’interconnexions signifie plus de points potentiels de défaillance : micro‑bumps, TSVs, substrats de package et entraînement des liens. Les fournisseurs conçoivent pour cela, bien sûr. Mais sur le terrain, vous le verrez sous forme d’erreurs corrigées, de liens dégradés ou d’incidents « un hôte est bizarre ».

Un adage opérationnel utile, paraphrasant une idée provenant d’une voix notable de la fiabilité : Les systèmes complexes échouent de façons complexes ; réduisez les inconnues et mesurez les bonnes choses. (idée paraphrasée, inspirée de la pensée en ingénierie de la fiabilité souvent attribuée à John Allspaw)

Traduction : n’assumez pas l’uniformité entre hôtes, et n’assumez pas que deux sockets se comportent de la même façon juste parce que le SKU correspond.

Ce que cela signifie pour les SRE : performance, fiabilité et voisins bruyants

Vous n’avez pas besoin de devenir ingénieur packaging. Vous devez arrêter de traiter le « CPU » comme une ressource scalaire unique. Dans un monde chiplet + empilement, vous gérez :

• Calcul topologique (les cœurs ne sont pas à égale distance de la mémoire et du cache)
• Capacité d’interconnect (le fabric interne peut saturer)
• Marge thermique (fréquences soutenues, bridage et p99)
• Politique d’alimentation (capping, turbo et interactions avec l’ordonnanceur)

L’observabilité doit s’élargir

La surveillance hôte traditionnelle — %CPU, load average, mémoire utilisée — échouera de plus en plus à expliquer les goulots. Vous avez besoin d’au moins une prise en main basique sur :

• Localité NUMA (les threads et la mémoire sont‑ils alignés ?)
• Comportement de cache (misses LLC, pression de bande passante)
• Fréquence et bridage (êtes‑vous limité par la puissance ?)
• Placement par l’ordonnanceur (Kubernetes ou systemd a‑t‑il déplacé votre charge ?)

Oui, c’est pénible. Mais c’est moins pénible qu’un trimestre entier de « nous avons mis à jour les CPU et c’est devenu plus lent ».

Mode opératoire de diagnostic rapide : trouver le goulot en quelques minutes

Voici le flux de triage que j’utilise quand un service devient plus lent sur une nouvelle plateforme chiplet/empilée, ou devient plus lent après montée en charge. Le but n’est pas la cause racine parfaite. Le but est de prendre la bonne décision suivante rapidement.

Première étape : déterminer si vous êtes limité par le calcul, la mémoire ou le « fabric »

1. Vérifier la fréquence CPU et le bridage : si les fréquences sont basses sous charge, vous êtes limité par la puissance/thermique.
2. Vérifier la bande passante mémoire et la pression de miss de cache : si les misses LLC et la bande passante sont élevées, vous êtes limité par la mémoire.
3. Vérifier la localité NUMA : si les accès mémoire distants sont élevés, vous êtes probablement lié à la topologie/ordonnanceur.

Deuxième étape : confirmer la topologie et le placement

1. Vérifier les nœuds NUMA et le mapping CPU→nœud.
2. Vérifier l’affinité CPU du processus et la politique mémoire.
3. Vérifier si la charge saute entre nœuds (migrations par l’ordonnanceur).

Troisième étape : isoler une variable et relancer

1. Épingler la charge à un nœud NUMA ; comparer p95/p99.
2. Forcer l’allocation mémoire locale ; comparer le débit.
3. Appliquer une politique d’alimentation conservative ; comparer la variance.

Si vous ne reproduisez pas de changement significatif en contrôlant placement et état de puissance, le problème est probablement au‑dessus (verrous, GC, IO) et vous devriez arrêter d’accuser le package CPU. Les CPU modernes sont compliqués, mais pas magiques.

Tâches pratiques avec commandes : quoi exécuter, ce que cela signifie, quelle décision prendre

Voici des tâches réelles à exécuter sur des hôtes Linux pour comprendre les comportements liés aux chiplets/empilements 3D. Les commandes sont volontairement ennuyeuses. Les outils ennuyeux vous gardent honnêtes.

Tâche 1 : Cartographier rapidement la topologie NUMA

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|NUMA|CPU\(s\)'
CPU(s):                               128
Model name:                           AMD EPYC 9xx4
Thread(s) per core:                   2
Core(s) per socket:                   64
Socket(s):                            1
NUMA node(s):                         8

Ce que signifie la sortie : Vous avez 8 nœuds NUMA sur un seul socket. C’est une topologie type chiplet : plusieurs domaines mémoire et des sauts d’interconnect à l’intérieur d’un seul package.

Décision : Si la latence compte, prévoyez d’épingler les services critiques à l’intérieur d’un nœud NUMA et gardez la mémoire locale. L’ordonnancement par défaut peut être « correct », mais « correct » est ce qui tue le p99.

Tâche 2 : Voir quels CPU appartiennent à quel nœud NUMA

cr0x@server:~$ numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0-15
node 0 size: 64000 MB
node 0 free: 61234 MB
node 1 cpus: 16-31
node 1 size: 64000 MB
node 1 free: 60110 MB
node 2 cpus: 32-47
node 2 size: 64000 MB
node 2 free: 59872 MB
node 3 cpus: 48-63
node 3 size: 64000 MB
node 3 free: 62155 MB
node 4 cpus: 64-79
node 4 size: 64000 MB
node 4 free: 60990 MB
node 5 cpus: 80-95
node 5 size: 64000 MB
node 5 free: 61801 MB
node 6 cpus: 96-111
node 6 size: 64000 MB
node 6 free: 61644 MB
node 7 cpus: 112-127
node 7 size: 64000 MB
node 7 free: 62002 MB

Ce que signifie la sortie : Chaque nœud NUMA possède une plage de CPU et un segment mémoire. Si votre processus tourne sur des CPU du nœud 0 mais alloue de la mémoire depuis le nœud 6, vous payez un péage de fabric à chaque accès distant.

Décision : Pour les services sensibles à la latence, alignez le pinning CPU et la politique mémoire. Pour les jobs de débit, vous pouvez préférer l’interleaving pour la bande passante.

Tâche 3 : Vérifier si le noyau enregistre des problèmes de localité NUMA

cr0x@server:~$ numastat -p 1 3
Per-node process memory usage (in MBs) for PID 1 (systemd)
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
----- ----- ----- ----- ----- ----- ----- ----- -----
Numa_Hit      12     10      9      8      9     10      8      9    75
Numa_Miss      1      0      0      0      0      0      0      0     1
Numa_Foreign   0      0      0      0      0      0      0      0     0
Interleave_Hit 0      0      0      0      0      0      0      0     0
Local_Node    12     10      9      8      9     10      8      9    75
Other_Node     1      0      0      0      0      0      0      0     1

Ce que signifie la sortie : Pour PID 1 tout va bien. Pour votre vrai service, si Other_Node est élevé, vous payez des pénalités d’accès distant.

Décision : Si les accès distants sont élevés et que la latence tail est mauvaise, épinglez et localisez. Si votre objectif est le débit et que vous êtes limité par la bande passante, envisagez l’interleaving.

Tâche 4 : Vérifier le comportement de fréquence CPU sous charge

cr0x@server:~$ sudo turbostat --Summary --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgTmp,PkgWatt --interval 5
CPU  Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
-    2850     62.10  4588     86      310.12

Ce que signifie la sortie : Les cœurs occupés tournent haut (Bzy_MHz), la température du package est élevée et la puissance est substantielle. Si Bzy_MHz s’effondre avec le temps tandis que Busy% reste élevé, vous êtes probablement limité par la puissance/thermique.

Décision : Pour les charges soutenues, ajustez le capping de puissance, le refroidissement ou réduisez la concurrence. Ne poursuivez pas les chiffres de boost d’un seul run.

Tâche 5 : Confirmer que la politique d’alimentation (governor) ne vous sabote pas

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

Ce que signifie la sortie : Le governor est réglé sur performance. S’il est sur powersave sur un hôte sensible à la latence, vous demandez essentiellement de la gigue.

Décision : Définissez une politique appropriée par rôle de cluster. Un cluster batch peut économiser de l’énergie ; un cluster OLTP ne doit pas se faire passer pour un portable.

Tâche 6 : Mesurer les migrations d’ordonnanceur (un tueur NUMA silencieux)

cr0x@server:~$ pidstat -w -p $(pgrep -n myservice) 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (128 CPU)

01:10:01 PM   UID       PID   cswch/s nvcswch/s  Command
01:10:02 PM  1001     43210   120.00     15.00  myservice
01:10:03 PM  1001     43210   135.00     20.00  myservice
01:10:04 PM  1001     43210   128.00     18.00  myservice

Ce que signifie la sortie : Les context switches sont modérés. Si vous voyez aussi des migrations CPU fréquentes (via perf ou schedstat), vous pouvez perdre la localité de cache entre chiplets.

Décision : Considérez l’épinglage CPU pour les threads les plus chauds, ou ajustez votre runtime (threads GC, nombre de workers) pour réduire le churn.

Tâche 7 : Vérifier la pression de bande passante mémoire avec pcm-memory (si installé)

cr0x@server:~$ sudo pcm-memory 1 -csv
Time,Ch0Read,Ch0Write,Ch1Read,Ch1Write,SystemRead,SystemWrite
1.00,12.3,5.1,11.8,4.9,198.4,82.1
2.00,12.5,5.0,12.1,4.8,201.0,80.9

Ce que signifie la sortie : La bande passante lecture/écriture système est élevée. Si elle est proche des limites de la plateforme pendant votre incident, vous êtes limité par la mémoire, pas par le CPU.

Décision : Réduisez le trafic mémoire : corrigez la disposition des données, réduisez les copies, augmentez le hit rate du cache, ou migrez vers une plateforme avec cache empilé/HBM si votre jeu de travail y correspond.

Tâche 8 : Observer les signaux de cache‑miss et stalls avec perf

cr0x@server:~$ sudo perf stat -p $(pgrep -n myservice) -e cycles,instructions,cache-misses,branches,branch-misses -a -- sleep 10
 Performance counter stats for 'system wide':

    38,112,001,220      cycles
    52,880,441,900      instructions              #    1.39  insn per cycle
       902,110,332      cache-misses
     9,221,001,004      branches
       112,210,991      branch-misses

      10.002113349 seconds time elapsed

Ce que signifie la sortie : Beaucoup de cache misses. L’IPC est correct, mais les misses peuvent toujours dominer le temps mur selon la charge. Sur les CPU chiplet, les misses peuvent se traduire en trafic de fabric et en accès mémoire distants.

Décision : Si les misses de cache corrèlent avec des pics de latence, priorisez la localité : épinglez les threads, réduisez la contention sur l’état partagé et testez des SKUs avec cache empilé quand le jeu de travail est juste au‑dessus du LLC.

Tâche 9 : Vérifier les erreurs mémoire et les tempêtes d’erreurs corrigées

cr0x@server:~$ sudo ras-mc-ctl --summary
Memory controller events summary:
  Corrected errors: 24
  Uncorrected errors: 0
  No DIMM labels were found

Ce que signifie la sortie : Des erreurs corrigées existent. Une hausse du taux peut causer une dégradation de performance et un comportement imprévisible, et sur des plateformes de packaging avancé vous voulez le remarquer tôt.

Décision : Si les erreurs corrigées augmentent, planifiez une maintenance : reseat, remplacer les DIMMs, mettre à jour le firmware ou retirer l’hôte du service. N’attendez pas que les erreurs non corrigées vous apprennent l’humilité.

Tâche 10 : Valider la santé des liens/PCIe (le die IO fait partie de l’histoire)

cr0x@server:~$ sudo lspci -vv | sed -n '/Ethernet controller/,+25p' | egrep 'LnkSta:|LnkCap:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Ce que signifie la sortie : Le lien fonctionne à la vitesse/largeur attendue. Si vous voyez des liens downtrainés, la performance IO baisse et des cycles CPU sont gaspillés en surcharge d’interrupts/paquets.

Décision : Les liens downtrainés déclenchent : vérifiez les risers, les réglages BIOS, le firmware et l’assise physique. N’« optimisez » pas le logiciel autour d’un matériel cassé.

Tâche 11 : Confirmer la distribution des interruptions (éviter les accumulations IRQ sur un seul cœur)

cr0x@server:~$ cat /proc/interrupts | egrep 'eth0|mlx|ens' | head
  55:   10223342          0          0          0   IR-PCI-MSI 524288-edge      ens3f0-TxRx-0
  56:          0    9981221          0          0   IR-PCI-MSI 524289-edge      ens3f0-TxRx-1
  57:          0          0    9875522          0   IR-PCI-MSI 524290-edge      ens3f0-TxRx-2

Ce que signifie la sortie : Les interruptions sont réparties sur les CPU. Si toutes les interruptions arrivent sur un CPU d’un nœud NUMA tandis que votre charge tourne ailleurs, vous aurez du trafic inter‑nœud et de la gigue.

Décision : Épinglez les IRQ proches du nœud NUMA du NIC et des threads de service qui consomment les paquets. La localité s’applique aussi à l’IO.

Tâche 12 : Vérifier la politique mémoire et exécuter un test local explicite

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 ./bench --duration 30
throughput=118223 ops/s
p99_latency_ms=3.4

Ce que signifie la sortie : Vous avez forcé CPU et mémoire sur le nœud 2. Comparez cela aux résultats non épinglés. Un large delta indique des pénalités NUMA/fabric.

Décision : Si l’épinglage améliore significativement le p99, implémentez le placement (CPUAffinity systemd, topology manager Kubernetes, ou pinning côté application) plutôt que de chasser des micro‑optimisations.

Tâche 13 : Inspecter les hugepages et les indicateurs de pression TLB

cr0x@server:~$ grep -E 'HugePages_Total|HugePages_Free|Hugepagesize' /proc/meminfo
HugePages_Total:    4096
HugePages_Free:     3900
Hugepagesize:       2048 kB

Ce que signifie la sortie : Les hugepages sont disponibles. Sur des charges intensives en mémoire, les hugepages peuvent réduire les misses TLB, ce qui compte davantage quand la latence mémoire est déjà plus haute à cause des accès distants.

Décision : Si le profilage montre une pression TLB, activez les hugepages et validez l’impact. Ne faites pas de cargo‑culting — mesurez.

Tâche 14 : Détecter le bridage et les raisons de limite de puissance (exemple Intel via RAPL)

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|rapl' | tail -n 5
[ 8123.221901] intel_rapl: power limit changed to 210W
[ 8123.222110] CPU0: Package power limit exceeded, capping frequency

Ce que signifie la sortie : Le système applique un power‑cap. Votre benchmark a pu tourner avant le cap ; les runs de production s’exécutent pendant celui‑ci.

Décision : Alignez les réglages BIOS/firmware de puissance avec l’intention de la charge. Si vous limitez pour des budgets d’énergie du datacenter, ajustez les SLO et peaufinez la concurrence.

Trois mini‑histoires d’entreprise de l’ère des chiplets

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a migré une couche API sensible à la latence vers de nouveaux serveurs. Même nombre de cœurs qu’avant, fréquences de boost annoncées plus élevées, et un chiffre L3 massif qui semblait de l’argent gratuit. Le déploiement était prudent : 5 % en canary, les métriques semblaient correctes, puis 25 %, puis 50 %.

À environ la moitié de la flotte, la latence p99 a commencé à fluctuer. Pas une montée régulière — des fluctuations. Les graphiques formaient une dent de scie qui a fait argumenter sur les patterns de trafic et le GC. L’utilisation CPU restait modérée. Le réseau semblait propre. Le stockage était calme. Le canal d’incident s’est rempli de la pire phrase des opérations : « Rien n’a l’air anormal. »

La mauvaise hypothèse : ils ont traité le CPU comme uniforme et supposé que si le %CPU moyen était correct, le CPU n’était pas le goulot. En réalité, la charge était ordonnancée à travers des nœuds NUMA et allouait fréquemment de la mémoire à distance à cause du comportement d’allocation du runtime et de la liberté du scheduler de conteneurs à déplacer les tâches. Les accès distants n’étaient pas catastrophiques ; ils étaient variables, ce qui a détruit la latence tail.

Ils l’ont prouvé en épinglant le service à un seul nœud NUMA et en forçant l’allocation locale en test. Le p99 s’est stabilisé immédiatement et la dent de scie a disparu. Le correctif n’était pas glamour : ordonnanceur conscient de la topologie, épinglage CPU pour les pods les plus chauds et une politique mémoire délibérée. Ils ont aussi cessé de sur‑consolider pods sensibles à la latence et batch sur le même socket. « Plus d’utilisation » n’était pas l’objectif ; la latence prévisible l’était.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une fintech exécutait un moteur de risque qui scannait un grand jeu de données en mémoire de façon répétée. Ils ont acheté une SKU CPU avec cache empilé parce qu’un benchmark fournisseur montrait un gros gain. Les premiers tests étaient prometteurs. Le débit s’est amélioré. Tout le monde a célébré. Puis ils ont fait ce que font les entreprises : ils ont « optimisé ».

L’équipe a augmenté la parallélisme agressivement, supposant que le cache supplémentaire maintiendrait l’échelle. Ils ont aussi activé une politique turbo plus agressive dans le BIOS pour chasser des accélérations de courte durée. En staging, la charge finissait plus vite — la plupart du temps.

En production, l’optimisation a échoué de deux manières. D’abord, les threads supplémentaires ont augmenté le trafic cross‑chiplet parce que la charge avait une structure partagée mal partitionnée. L’interconnect est devenu congestionné. Ensuite, la politique turbo a élevé rapidement les températures, provoquant un bridage thermique en plein run. Le système n’a pas seulement ralenti ; il est devenu imprévisible. Certains runs terminaient vite ; d’autres frappaient le bridage et traînaient.

Le correctif a été presque ennuyant : réduire le parallélisme pour maintenir la localité, partitionner le dataset plus soigneusement et définir une politique d’alimentation optimisée pour la fréquence soutenue plutôt que le boost de pointe. Le cache empilé a encore aidé — mais seulement quand le logiciel respectait la topologie et l’enveloppe thermique. La leçon : plus de cache n’excuse pas un mauvais comportement d’échelle.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande équipe plateforme d’entreprise a standardisé une « checklist de bring‑up hardware » pour les nouvelles générations de CPU. Elle incluait des baselines BIOS/firmware, versions de microcode, vérification de la topologie NUMA et un ensemble fixe de tests smoke perf/latence épinglés à des nœuds spécifiques.

Quand un lot de nouveaux serveurs est arrivé, les smoke tests ont montré une régression subtile : la bande passante mémoire était plus faible que prévu sur un nœud NUMA, et la latence p99 sous une charge mixte synthétique était pire. Rien ne tombait en erreur. La plupart des équipes auraient déclaré « dans la variance » et seraient passées à autre chose.

La checklist a forcé l’escalade. Il s’est avéré qu’un réglage BIOS lié à l’interleaving mémoire et à la gestion de puissance différait de la baseline à cause d’un changement de défaut fournisseur. Les serveurs fonctionnaient techniquement, juste pas de la même façon que le reste de la flotte. Ce mismatch serait devenu un cauchemar d’astreinte plus tard, car un comportement hétérogène dans un groupe autoscalé transforme les incidents en jeux de probabilité.

Ils ont corrigé la baseline, réimagé les hôtes, relancé les mêmes tests épinglés et obtenu les résultats attendus. Pas de héros. Pas d’incident nocturne. Juste de la discipline opérationnelle : mesurer, standardiser et refuser d’accepter la variance silencieuse dans un monde où les packages sont de petits systèmes distribués.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptôme : pics de latence p99 après montée en nombre de cœurs

Cause racine : contention cross‑chiplet et augmentation des accès mémoire distants quand les threads se répartissent sur des nœuds NUMA ; les structures de données partagées amplifient le trafic.

Correctif : partitionner l’état, réduire le partage inter‑threads, épingler les workers critiques dans un nœud NUMA et utiliser un ordonnancement conscient de la topologie.

2) Symptôme : utilisation CPU modérée mais faible débit

Cause racine : stalls mémoire (misses LLC, latence DRAM), congestion du fabric ou migrations fréquentes se cachent derrière « pas occupé ».

Correctif : utilisez perf stat et des outils de bande passante mémoire ; vérifiez numastat ; épinglez et localisez ; réduisez le churn de l’allocateur et les copies.

3) Symptôme : nouveaux serveurs plus rapides en benchmark mais pires en production

Cause racine : les benchmarks frappent les boosts et les états de cache chauds ; la production atteint les limites de puissance soutenue et des charges mixtes.

Correctif : testez avec des runs en état stationnaire, incluez des métriques p99 et validez sous concurrence et conditions thermiques réalistes.

4) Symptôme : un hôte dans une flotte est constamment bizarre

Cause racine : lien PCIe downtrainé, canal mémoire dégradé, tempêtes d’erreurs corrigées ou dérive BIOS affectant puissance/topologie.

Correctif : vérifiez lspci -vv, résumés RAS, versions microcode/BIOS ; mettez en quarantaine et remédiez plutôt que d’ajuster autour du problème.

5) Symptôme : gigue de latence après activation de fonctionnalités d’économies d’énergie

Cause racine : états C agressifs, clock gating du fabric, scaling de fréquence ou limites de puissance du package causent des comportements de réveil/boost variables.

Correctif : utilisez un governor performance pour les niveaux latence, ajustez les états power BIOS et validez avec turbostat sous charge réelle.

6) Symptôme : débit PPS réseau en baisse après rafraîchissement hardware

Cause racine : IRQs et threads sur différents nœuds NUMA ; l’IO die et la localité NIC comptent, et le trafic inter‑nœud ajoute de la latence.

Correctif : alignez l’affinité IRQ et les threads d’application sur le nœud NUMA du NIC ; confirmez la largeur/vitesse du lien ; évitez la sur‑consolidation.

7) Symptôme : « On a ajouté du cache empilé mais aucun gain »

Cause racine : le jeu de travail ne rentre pas, ou la charge est limitée par la bande passante plutôt que par la latence de cache ; le gain est spécifique à la charge.

Correctif : profilez les taux de miss de cache et la bande passante ; testez des tailles de données représentatives ; envisagez HBM ou des changements algorithmiques si vous êtes lié par la bande passante.

8) Symptôme : après containerisation, performance régressée sur CPU chiplet

Cause racine : le scheduler de conteneurs a déplacé les threads à travers CPU/nœuds NUMA ; les quotas cgroup CPU ont introduit de la variabilité ; la localité du page cache s’est aggravée.

Correctif : utilisez CPU manager/topology manager, définissez correctement requests/limits, et épinglez les pods gourmands en mémoire sur des nœuds NUMA.

Listes de contrôle / plan étape par étape pour nouvelles plateformes

Plan étape par étape : mettre en production une nouvelle plateforme chiplet/empilée

1. Topologie de base : enregistrez lscpu et numactl --hardware pour le SKU ; stockez‑les avec vos artefacts de build.
2. Standardiser le firmware : réglages BIOS, microcode et politiques de puissance doivent être cohérents dans le pool.
3. Choisir une posture de puissance par tier : les clusters latence ont la politique performance ; les clusters batch peuvent être intentionnellement power‑cappés.
4. Exécuter des smoke tests épinglés : mesurez débit et p99 avec CPU+mémoire liés à un nœud ; puis exécutez non épinglé ; comparez les deltas.
5. Valider la marge de bande passante mémoire : si votre charge est liée à la mémoire, la planification de capacité devient planification de bande passante.
6. Valider la localité IO : vérifier la santé des liens PCIe et la distribution des IRQ ; assurer que l’affinité NIC correspond au placement CPU.
7. Décider d’une politique de placement : soit adopter NUMA (épingler et localiser), soit interleaver explicitement pour la bande passante. Ne faites pas d’« hybride accidentel ».
8. Déployer avec détection de variance : surveillez non seulement les médianes mais la dispersion entre hôtes ; alertez tôt sur « un hôte bizarre ».
9. Documenter les modes de défaillance : signatures de bridage, seuils d’erreurs corrigées et comment mettre un hôte en quarantaine.
10. Retester après mises à jour du noyau : les changements d’ordonnanceur peuvent aider ou nuire à la gestion de la topologie ; validez périodiquement.

Checklist : choisir entre cache empilé et plus de bande passante mémoire

• Si votre jeu de travail dépasse légèrement le LLC et que vous voyez beaucoup de misses LLC : le cache empilé peut être un gros gain.
• Si la bande passante mémoire est proche du maximum et que les stalls dominent : le cache empilé ne vous sauvera peut‑être pas ; priorisez la bande passante (plateformes HBM, plus de channels) ou réduisez le trafic.
• Si la latence tail compte : préférez des solutions qui réduisent la variance (localité, politique de puissance stable) plutôt que le pic brut.

Checklist : quoi éviter en adoptant des CPU à forte charge de chiplets

• Ne supposez pas « un socket = uniforme. » Mesurez le comportement NUMA.
• Ne tolérez pas la dérive BIOS dans un groupe autoscalé.
• Ne peaufinez pas les applications sans d’abord vérifier le comportement de puissance et de bridage.
• Ne mélangez pas workloads latence et batch sur le même socket à moins d’avoir une isolation stricte.

FAQ

1) Les chiplets sont-ils toujours plus rapides que les dies monolithiques ?

Non. Les chiplets sont principalement une stratégie économique et de vélocité produit, avec des bénéfices de performance quand l’interconnect et la topologie sont bien gérés. Une mauvaise localité peut effacer le gain.

2) L’empilement 3D fera‑t‑il chauffer davantage les CPU ?

Souvent, oui en pratique. Les stacks peuvent empêcher l’évacuation de la chaleur et créer des points chauds. Les fournisseurs conçoivent autour de cela, mais des charges soutenues peuvent voir un bridage plus précoce ou plus de variance.

3) Le tuning NUMA est‑il désormais obligatoire ?

Pour les services sensibles à la latence sur des CPU à forte charge de chiplets, c’est presque obligatoire. Pour du batch parfaitement parallèle, vous pouvez souvent vous en passer — jusqu’à ce que vous ne puissiez plus.

4) Quels workloads bénéficient le plus du cache empilé ?

Les charges avec un jeu de travail plus grand que le cache normal mais plus petit que des patterns streaming DRAM‑friendly : workloads clé‑valeurs chauds, certaines analyses, certaines simulations et structures de données en mémoire majoritairement en lecture.

5) Quel est le risque opérationnel d’un packaging avancé ?

Plus de composants et de liens peuvent signifier plus de dégradations subtiles : tempêtes d’erreurs corrigées, downtraining de liens ou variance plateforme. Vos pratiques de monitoring et de quarantaine comptent davantage.

6) Les chiplets signifient‑ils que « plus de cœurs » va cesser d’aider ?

Plus de cœurs aideront toujours pour les charges parallèles, mais l’échelle devient plus sensible à la bande passante mémoire, la congestion interconnect et la contention d’état partagé. Les gains faciles sont partis.

7) Comment HBM change la planification de capacité ?

HBM vous pousse vers un modèle en niveaux : très haute bande passante mais capacité limitée. Planifiez ce qui doit rester en HBM, ce qui peut déborder sur la DDR, et comment votre allocateur/runtime se comporte.

8) UCIe va‑t‑il rendre les packages CPU modulaires comme des blocs PC ?

Finalement, plus modulaires qu’aujourd’hui — mais n’attendez pas du plug‑and‑play. L’intégrité du signal, l’alimentation, les thermiques et la validation restent difficiles, et la « norme » n’éliminera pas la physique.

9) Quel est le changement le plus simple « assez bon » pour réduire la latence tail sur CPU chiplet ?

Épinglez vos threads les plus chauds à un nœud NUMA et gardez leur mémoire locale. Puis vérifiez avec un test A/B épinglé. Si ça aide, investissez dans un ordonnancement conscient de la topologie.

10) Dois‑je acheter des SKUs avec cache empilé pour tout ?

Non. Achetez‑les pour les workloads qui démontrent une sensibilité au cache lors du profilage. Sinon vous paierez du silicium qui ne fera que garnir votre tableau de procurement.

Étapes pratiques suivantes

L’empilement 3D et les chiplets ne sont pas une mode ; ils dessinent la route à venir. Le CPU devient un système distribué au niveau package avec des contraintes thermiques et topologiques. Vos logiciels et vos opérations doivent s’y adapter.

Ce qu’il faut faire la semaine prochaine (pas le prochain trimestre)

1. Choisissez un service avec SLOs de latence et exécutez le test NUMA épinglé vs non épinglé (numactl) pour quantifier la sensibilité.
2. Ajoutez deux panneaux au niveau hôte : fréquence/bridage CPU (dérivé de turbostat) et accès NUMA distant (numastat/PMU si disponible).
3. Standardisez les baselines BIOS/microcode pour chaque pool matériel ; alertez sur la dérive.
4. Rédigez un runbook d’une page utilisant le Mode opératoire de diagnostic rapide ci‑dessus pour que l’astreinte n’accuse pas le réseau par réflexe.
5. Décidez votre philosophie de placement : priorité à la localité pour les tiers latence ; interleave/bande passante pour les tiers débit — puis appliquez‑la.

Si vous ne faites rien d’autre, faites ceci : arrêtez de traiter le %CPU comme la vérité. Sur les designs chiplet et empilés, le %CPU est une impression. Mesurez la localité, mesurez la bande passante et mesurez le bridage. Ensuite vous pourrez argumenter avec confiance, et c’est le seul type de dispute que les opérations peuvent se permettre.