GPU à chiplets : pourquoi l’idée est logique — et brutalement difficile

Pourquoi les GPU à chiplets ont du sens (et pourquoi tout le monde les veut)

Si vous exploitez des clusters GPU en production, vous connaissez déjà l’économie du silicium. Pas le prix affiché — l’économie du silicium. Les GPU monolithiques butent simultanément contre plusieurs murs : limites du réticule, rendement, complexité du packaging et distribution d’alimentation. Les chiplets promettent d’étirer ces murs.

Le pitch, en termes simples

Un GPU à chiplets découpe une grande puce en plusieurs dies plus petits (chiplets) et les assemble avec une interconnexion à haute vitesse. Vous obtenez :

• Meilleur rendement : les dies plus petits ont moins de défauts par puce, donc plus de pièces utilisables par wafer.
• Scalabilité : construisez un « GPU plus grand » en ajoutant des chiplets plutôt qu’en refabriquant une puce monstre.
• Composants réutilisables : mélangez des tuiles de calcul, des tuiles de cache, des tuiles IO.
• Flexibilité des nœuds de procédé : placez la SRAM volumineuse du cache sur un nœud, le calcul sur un autre, l’IO sur un nœud moins cher.

Pour les CPU, cette stratégie est déjà courante. Pour les GPU, la logique est la même — jusqu’à ce que vous vous rappeliez ce que font réellement les GPU : un travail massivement parallèle avec un appétit brutal pour la bande passante, synchronisé à très fine granularité, où de petites augmentations de latence peuvent torpiller l’occupation et le débit.

Ce qui change quand un GPU devient « distribué »

Dans un GPU monolithique, le fabric sur puce est essentiellement « suffisamment bon marché » et suffisamment cohérent pour que les programmeurs puissent l’ignorer la plupart du temps. Dans un GPU à chiplets, votre fabric devient une caractéristique produit. Votre hiérarchie de cache devient politique. Votre modèle mémoire devient une négociation.

Les GPU à chiplets ne sont pas juste du matériel. Ce sont un contrat entre :

• le packaging (comment vous connectez physiquement les dies),
• l’interconnect (bande passante/latence/ordre),
• l’architecture mémoire (placement HBM, mappage d’adresses, cohérence),
• le compilateur/runtime (placement des kernels, distribution du travail),
• les pilotes et le système d’exploitation (exposition de la topologie),
• et votre application (schémas d’accès que vous n’aviez peut‑être pas réalisé fragiles).

Blague n°1 : les chiplets sont géniaux parce qu’ils transforment « un gros GPU » en « plusieurs petits GPU », et maintenant vous pouvez déboguer des systèmes distribués sans quitter votre siège.

La partie difficile : faire croire que plusieurs dies sont un seul GPU

La difficulté centrale n’est pas « rendre la bande passante rapide ». C’est « faire en sorte que l’ensemble se comporte comme un seul périphérique face aux pires schémas d’accès que vos utilisateurs vont inévitablement toucher par accident ».

1) Interconnexion : la bande passante fait la une ; la latence en encaisse les frais

Les interconnexions à l’intérieur des boîtiers peuvent être extrêmement larges et rapides. Mais elles restent plus lentes que les fils sur puce, et la latence n’est pas une erreur d’arrondi. Sur les GPU, cela compte parce que :

• beaucoup de kernels sont sensibles à la latence malgré un fort parallélisme,
• la synchronisation fine amplifie la latence en queue,
• l’ordonnanceur suppose certaines propriétés de localité qui cessent d’être vraies.

En production, vous verrez cela comme des « falaises » de performance mystérieuses : le job est rapide jusqu’à ce qu’un tenseur franchisse un seuil, ou qu’une taille de lot change, ou que l’allocateur mémoire décide de placer un buffer « là-bas ».

2) Placement mémoire : HBM est rapide ; la HBM distante est « plutôt rapide »

Les GPU à chiplets gardent presque toujours la mémoire à haute bande passante (HBM) proche de certains dies. Si votre charge peut rester locale, vous gagnez. Si ce n’est pas le cas, l’accès mémoire distant devient une taxe.

Le scénario le plus dangereux est quand l’architecture et le pilote présentent un espace d’adressage unifié qui semble plat, mais se comporte comme du NUMA. « Adresse plate » n’est pas synonyme de « performance plate ».

3) Cohérence et cache : le tueur subtil de performance

La cohérence entre dies est coûteuse. Ne pas faire de cohérence est aussi coûteux, mais dans une autre monnaie : complexité logicielle et risque de correction.

Les GPU jouent déjà avec la cohérence (différents niveaux de cache, régions non cohérentes, atomiques avec règles spéciales). Les chiplets augmentent les enjeux. Si vous voulez la sémantique « un seul GPU », vous avez besoin de :

• règles d’ordonnancement bien définies,
• atomiques efficaces à travers les dies,
• stratégies d’invalidation de cache qui ne fondent pas la performance,
• comportement prévisible sous contention.

4) Ordonnancement du travail : l’endroit où vous exécutez un kernel compte maintenant

Avec des chiplets, vous ne pouvez plus traiter le périphérique comme un pool uniforme d’unités de calcul. Il faut répondre à :

• Quel chiplet exécute quels blocs ?
• Où sont les données ?
• Quel est le coût des communications inter-chiplets ?
• Que se passe-t-il quand plusieurs kernels se disputent le même interconnect ?

Le runtime peut essayer d’être intelligent. Il réussira parfois. Il se surclassera aussi parfois d’une manière que vous ne découvrirez qu’à 2 h du matin, après une mise à jour du pilote.

5) Fiabilité : plus de composants, plus de surface de défaillance

Plus de dies et plus de liens signifient plus de choses qui peuvent se dégrader. Un seul lien marginal peut se manifester par :

• pics ECC intermittents,
• réinitialisations de pilote de type « Xid » sous charge,
• baisses silencieuses de performance quand le système réentraîne un lien à une vitesse inférieure,
• résultats de benchmarks affreusement incohérents.

Voici la lentille de fiabilité qui compte : quand un GPU monolithique est malade, c’est généralement évident. Quand un GPU à chiplets est légèrement malade, cela peut ressembler à « le modèle est devenu plus lent cette semaine ». Ce sont les incidents coûteux.

Une idée paraphrasée d’une voix notable de la fiabilité (attribuée) : Werner Vogels soutient souvent que « tout échoue, donc concevez pour l’échec ». Les GPU à chiplets sont cette maxime rendue silicium.

Faits et histoire intéressants qui comptent

Quelques points de contexte qui changent réellement votre manière de penser les GPU à chiplets, pas juste des anecdotes pour les slide decks :

1. La limite du réticule de photolithographie est un plafond dur : vous ne pouvez pas imprimer des dies monolithiques arbitrairement grands en une seule exposition, donc « faites-le plus grand » finit par ne plus être une option.
2. Le rendement chute de façon non linéaire avec la surface du die : les grosses puces ne coûtent pas seulement plus cher ; elles échouent plus souvent, faisant des SKU haut de gamme un exercice de binning et de prières.
3. Les modules multi-puces (MCM) ne sont pas nouveaux : les fournisseurs de CPU ont expédié des packages multi-dies pendant des décennies, mais les schémas d’accès GPU sont plus rudes parce que bande passante et synchronisation exercent une pression constante.
4. HBM a changé la donne du packaging : déplacer la mémoire sur un interposer à côté du GPU a poussé l’industrie vers le packaging avancé, préalable aux chiplets.
5. Les interconnexions sont maintenant des produits : ce qui était autrefois une conception de fabric interne est de plus en plus exposé comme « largeur de lien » et « topologie », impactant l’approvisionnement et la planification de capacité.
6. Les piles logicielles GPU traitent déjà « plusieurs dispositifs » : l’entraînement multi-GPU et les communications collectives existent, mais les chiplets cherchent à masquer la complexité multi-die sous une abstraction de périphérique unique — plus difficile que d’admettre que c’est multi-dispositif.
7. NUMA a donné cette leçon depuis des années : une mémoire unifiée avec accès non uniforme fonctionne très bien jusqu’à ce que votre allocateur et votre ordonnanceur ne soient pas d’accord avec vos chemins chauds.
8. Les consoles et SoC mobiles mélangent depuis longtemps des blocs hétérogènes : les chiplets étendent cette modularité au calcul haute performance, mais avec des exigences de latence et de bande passante plus strictes.

Où ça échoue en production : goulots réels et leur manifestation

Falaises de performance qui ressemblent à une « régression aléatoire »

Le symptôme classique : le même code, la même taille d’entrée, un jour différent, soudainement 15–30 % plus lent. Pas de chute évidente d’utilisation GPU. Aucun goulot CPU évident. Le coupable est souvent le placement — un buffer finit « distant » du chiplet exécutant le kernel chaud, ou l’ordonnanceur change la distribution des blocs.

Latence de queue et jitter

Les chiplets ajoutent des files supplémentaires : arbitration du fabric, contrôle de flux au niveau du lien, trafic de cache inter-die. Le débit moyen peut sembler correct tandis que le P99 explose. Si vous exécutez de l’inférence ou des étapes d’entraînement à contrainte temporelle, vous le ressentirez.

Contention d’interconnexion : la « restriction invisible »

Dans un GPU monolithique, de nombreux chemins internes sont surdimensionnés pour les charges typiques. Dans un GPU à chiplets, l’interconnect est une ressource partagée avec un nom. Deux kernels qui allaient bien seuls peuvent se battre quand ils sont co-schedulés, et vous ne le verrez pas dans les graphiques habituels d’« utilisation SM ».

Pièges de correction (rares, mais coûteux)

La plupart des problèmes de GPU à chiplets sont des problèmes de performance. Les pires sont des problèmes de correction qui n’apparaissent que sous des conditions spécifiques de synchronisation et d’ordre mémoire — généralement quand des atomiques traversent des frontières de chiplet ou quand des copies peer-to-peer se chevauchent avec du calcul.

Blague n°2 : « Ça a passé les tests unitaires » est une belle phrase, comme « le parachute s’est ouvert finalement ».

Trois mini-histoires d’entreprise depuis le terrain

Mini-histoire 1 : un incident causé par une mauvaise hypothèse

Une équipe a déployé un nouveau SKU GPU dans un cluster mixte. La fiche marketing indiquait « périphérique unique, espace d’adressage mémoire unifié ». Les ingénieurs ont supposé que « périphérique unique » signifiait « performance uniforme », alors ils ont conservé leur allocateur indifférent au placement et laissé le runtime gérer.

La charge était un modèle de recommandation avec des tables d’embeddings périodiquement mises à jour et lues en permanence. Sur les anciens GPU monolithiques, le schéma était tolérable. Sur le nouveau matériel, certaines étapes d’entraînement grimpaient en durée, mais seulement quand les embeddings dépassaient un seuil de taille. Le pic corrélait avec des phases de communication collective, ce qui a induit en erreur l’astreinte qui a blâmé le réseau.

Ils ont passé deux jours à regarder les compteurs NIC et la télémétrie du switch. Rien. Puis quelqu’un a exécuté un microbenchmark qui touchait des pages mémoire avec un pas régulier et a trouvé une latence bimodale. Le runtime plaçait les shards d’embeddings chauds « distants » du chiplet exécutant les kernels à charge d’embeddings assez souvent pour casser les SLOs de temps par étape.

La correction fut embarrassante de simplicité : épingler les shards chauds à la mémoire locale au chiplet exécutant les kernels gourmands en embeddings, et restructurer la phase de mise à jour pour regrouper le trafic inter-chiplet. La leçon plus profonde n’était pas « épingler la mémoire ». C’était « ne pas traiter un espace d’adressage unifié comme un modèle de coût uniforme ».

Mini-histoire 2 : une optimisation qui a échoué

Une autre organisation a tenté d’augmenter le débit des nœuds GPU en activant un chevauchement agressif : précharger le lot suivant en mémoire GPU pendant que le lot actuel calcule, exécuter des copies asynchrones, garder l’interconnect occupé. Sur le papier, parfait.

Sur le matériel à chiplets, ce chevauchement est devenu un embouteillage. Le moteur de préfetch et les kernels de calcul ont commencé à se concurrencer sur les mêmes chemins inter-dies. Au lieu de masquer la latence, le chevauchement l’a amplifiée : les défauts de cache déclenchaient des fetchs distants, les fetchs distants concurrençaient les DMA asynchrones, et l’arbitrage de l’interconnect punissait les deux. L’utilisation GPU restait élevée, mais le temps d’étape empirait et le jitter augmentait.

Ils « ont résolu » le problème en désactivant le préfetch, ce qui a amélioré la stabilité mais laissé des performances sur la table. La vraie correction a pris plus de temps : rendre le préfetch conscient de la topologie, limiter les transferts en vol, et ordonnancer les DMA pour éviter les fenêtres de trafic inter-die à pic. Leur plus grand gain est venu d’une métrique ennuyeuse : un plafonnement sur les lectures distantes en cours.

Enseignement : le chevauchement n’est pas universellement bon. Sur les chiplets, il peut provoquer un effondrement par congestion auto-infligé. Traitez l’interconnect comme un réseau partagé, parce que fonctionnellement, c’en est un.

Mini-histoire 3 : une pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme avait l’habitude, qui semblait paranoïaque : pour chaque nouvelle génération de GPU, ils exécutaient chaque nuit une petite suite de « contrôles de sanity topologique ». Pas des benchmarks. Des contrôles. Largeurs de liens, distances NUMA rapportées, accès pair, compteurs ECC, microbenchmarks basiques pour accès local vs distant.

Un matin, la suite a signalé que plusieurs nœuds avaient une vitesse de lien entre chiplets inférieure à l’attendu. Personne ne s’était encore plaint ; les jobs d’entraînement terminaient toujours. Mais la variance grimpait, et les nœuds devenaient subtilement plus lents.

Il s’est avéré qu’un lot de systèmes avait un réglage de firmware qui provoquait un réentraînement du lien sous certaines conditions thermiques. Le matériel ne tombait pas bruyamment en panne ; il s’adaptait silencieusement en rétrogradant la vitesse. L’équipe a mis les nœuds en quarantaine, appliqué une mise à jour firmware, et les a requalifiés avant le prochain grand lancement de modèle.

Cette pratique ennuyeuse a évité un incident de semaine de lancement où « le modèle manque parfois la fenêtre d’entraînement » aurait été attribué à tout sauf à la cause réelle. Le travail ops le plus précieux est celui que personne ne remarque parce qu’il a fonctionné.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici le type de choses à faire quand le comportement d’un GPU à chiplets est suspect. Les outils exacts varient selon le fournisseur, mais le flux de travail est le même : établir la topologie, mesurer la localité, valider la santé des liens, puis corréler avec les phases de la charge.

Tâche 1 : Identifier les modèles GPU et versions du pilote

cr0x@server:~$ nvidia-smi
Tue Jan 21 10:12:44 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54       Driver Version: 550.54       CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|-------------------------------+----------------------+----------------------+
|  0  H100 SXM5            On   | 00000000:41:00.0 Off |                    0 |
|  1  H100 SXM5            On   | 00000000:61:00.0 Off |                    0 |
+-----------------------------------------------------------------------------+

Ce que cela signifie : Établissez la base : version du pilote/CUDA et SKU GPU. Les changements de performance liés aux chiplets suivent souvent des mises à jour de pilote.

Décision : Si la régression coïncide avec un changement de pilote, reproduisez sur le pilote précédent ou figez les versions pendant l’enquête.

Tâche 2 : Afficher la topologie GPU (liens, affinité NUMA)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      NV4     0-31            0
GPU1    NV4      X      0-31            0

Ce que cela signifie : « NV4 » indique une classe de lien GPU-GPU à haute vitesse ; l’affinité CPU/NUMA vous indique quels sockets sont « proches ».

Décision : Si l’affinité CPU couvre des sockets de manière inattendue, liez votre job au nœud NUMA le plus proche et re-mesurez.

Tâche 3 : Confirmer la largeur/vitesse du lien PCIe pour chaque GPU

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Ce que cela signifie : Si un lien est downgrader (x8, GT/s plus faible), les transferts hôte-périphérique et certains chemins pair souffrent.

Décision : Tout « (downgraded) » ou largeur réduite : mettez le nœud en quarantaine, vérifiez BIOS/firmware, reposez les risers/câbles si applicable.

Tâche 4 : Inspecter la topologie NUMA depuis l’OS

cr0x@server:~$ numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 256000 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 256000 MB

Ce que cela signifie : Confirme la localité CPU et mémoire que vous pouvez contrôler.

Décision : Épinglez les threads CPU et les allocations mémoire hôte au nœud NUMA le plus proche des GPU utilisés.

Tâche 5 : Vérifier le statut IOMMU (peut affecter le comportement DMA)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz root=/dev/nvme0n1p2 ro iommu=pt intel_iommu=on

Ce que cela signifie : « iommu=pt » réduit généralement la surcharge de traduction pour le DMA des périphériques.

Décision : Si vous voyez un IOMMU strict avec des charges DMA lourdes, testez le mode passthrough pendant une fenêtre de maintenance.

Tâche 6 : Surveiller horloges GPU, puissance et raisons de throttling

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,PERFORMANCE | egrep -i "Clocks|Power Draw|Perf|Throttle"
Performance State                  : P0
Power Draw                         : 612.45 W
Clocks
    Graphics                        : 1410 MHz
    SM                              : 1410 MHz
    Memory                          : 1593 MHz
Clocks Throttle Reasons
    Thermal Slowdown                : Not Active
    Power Brake Slowdown            : Not Active

Ce que cela signifie : Si les chiplets sont thermiquement contraints ou power-capped, le comportement de l’interconnect peut changer en raison de downclocking.

Décision : Si le throttling est actif, corrigez le refroidissement/politique d’alimentation avant de chasser des « régressions logicielles » fantômes.

Tâche 7 : Vérifier les compteurs d’erreurs ECC (signal précoce de liens/mémoire malades)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Volatile|Uncorr|Corr"
Volatile Uncorr. ECC                    : 0
Volatile Corr. ECC                      : 12

Ce que cela signifie : Les erreurs corrigées qui augmentent sous charge peuvent indiquer une instabilité de la mémoire ou de l’interconnect marginale.

Décision : Si les ECC corrigées augmentent régulièrement, exécutez les diagnostics du fournisseur et envisagez de retirer le nœud de la production.

Tâche 8 : Confirmer l’accès peer-to-peer entre GPUs

cr0x@server:~$ nvidia-smi topo -p2p r
GPU0 GPU1
GPU0  X   OK
GPU1 OK   X

Ce que cela signifie : « OK » indique que le P2P est pris en charge/activé ; si c’est « N/A » ou « Disabled », les transferts inter-dispositifs retombent sur l’hôte.

Décision : Si le P2P est indisponible de manière inattendue, vérifiez les paramètres BIOS (ACS), les réglages pilote et les privilèges de conteneur.

Tâche 9 : Mesurer local vs distant via un microbenchmark de timing (sanity rapide)

cr0x@server:~$ /usr/bin/time -f "elapsed=%e" python3 -c 'import torch; a=torch.randn(8192,8192,device="cuda"); b=a.t().contiguous(); torch.cuda.synchronize()'
elapsed=0.41

Ce que cela signifie : C’est grossier mais reproductible. Si les temps sont bimodaux entre exécutions, vous avez probablement une variance de placement/topologie.

Décision : Si la variance est élevée, épinglez l’affinité du processus et contrôlez le comportement de l’allocateur ; puis comparez à nouveau.

Tâche 10 : Capturer utilisation GPU et débit mémoire au fil du temps

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 1 -c 5
# gpu  pwr  u  c  v  m  t
# Idx  W    %  %  %  %  C
0      610  85 99  0  72 68
0      612  83 99  0  73 69
0      608  40 98  0  70 69
0      611  86 99  0  72 68
0      613  84 99  0  73 69

Ce que cela signifie : Une chute d’utilisation avec des horloges stables peut indiquer des stalls (souvent mémoire/interconnect).

Décision : Corrélez les chutes avec la timeline des kernels ; si memory% reste élevé pendant que le calcul chute, suspectez un accès distant ou une contention.

Tâche 11 : Valider que le conteneur voit les périphériques et la topologie attendus

cr0x@server:~$ nvidia-container-cli info | egrep -i "NVRM|CUDA|Device Index"
NVRM version:   550.54
CUDA version:   12.4
Device Index:   0
Device Index:   1

Ce que cela signifie : Confirme que le runtime conteneur n’a pas caché des périphériques ni désaligné la pile pilote.

Décision : Si les périphériques diffèrent entre l’hôte et le conteneur, corrigez la configuration du runtime avant toute investigation de performance.

Tâche 12 : Vérifier les logs kernel et PCIe/AER pour instabilité des liens

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i "AER|pcie|Xid|NVRM" | tail -n 8
Jan 21 09:12:01 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: id=00e0
Jan 21 09:12:01 server kernel: pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 21 09:12:02 server kernel: NVRM: Xid (PCI:0000:41:00): 48, pid=29133, errorString=Double Bit ECC Error

Ce que cela signifie : Un spam AER corrigé plus des Xid GPU est un signal d’alerte fiabilité. Les liens chiplet peuvent accroître la sensibilité.

Décision : Mettez le nœud en quarantaine ; exécutez des diagnostics étendus ; ne vous contentez pas de « redémarrer » en espérant.

Tâche 13 : Confirmer l’affinité CPU d’un job en cours

cr0x@server:~$ ps -o pid,psr,comm -p 29133
  PID PSR COMMAND
29133  27 python3

Ce que cela signifie : Le processus est actuellement planifié sur le cœur CPU 27 (probablement nœud NUMA 1 dans l’exemple précédent).

Décision : Si le GPU est plus proche du nœud NUMA 0, épinglez le processus/threads sur le nœud 0 et retestez.

Tâche 14 : Forcer l’affectation NUMA pour un run de benchmark

cr0x@server:~$ numactl --cpunodebind=0 --membind=0 python3 -c 'import os; print("ok");'
ok

Ce que cela signifie : Vous pouvez forcer la localité pour les CPU et les allocations mémoire hôte.

Décision : Si le temps d’étape s’améliore et que la variance diminue, votre goulot inclut la localité côté hôte (souvent négligée dans les débats « seulement GPU »).

Feuille de diagnostic rapide

Quand quelque chose est lent sur des systèmes GPU de classe chiplet, vous n’avez pas le temps pour des arguments philosophiques sur « le runtime devrait gérer ça ». Vous avez besoin d’une boucle serrée : identifiez si vous êtes lié par le calcul, la mémoire ou le fabric, puis prouvez-le avec des preuves topologiques.

Première étape : écarter les tueurs ennuyeux (alimentation, thermiques, réentraînement des liens)

• Vérifiez les horloges et les raisons de throttling (Tâche 6).
• Vérifiez la largeur/vitesse du lien PCIe et les logs AER (Tâches 3 et 12).
• Vérifiez les compteurs ECC (Tâche 7).

Si l’un de ces éléments est rouge, corrigez les conditions matérielles/firmware avant de profiler les kernels. Profiler un nœud malade, c’est écrire de la fiction.

Deuxième étape : confirmer les hypothèses de topologie et de localité

• Rapport de topologie GPU (Tâche 2).
• Disposition NUMA de l’OS (Tâche 4).
• Disponibilité P2P (Tâche 8).
• Visibilité du conteneur (Tâche 11).

Si vous voyez un décalage de topologie entre « ce que vous pensez avoir acheté » et « ce que l’OS voit », arrêtez-vous. Corrigez ce décalage.

Troisième étape : corréler la performance aux phases et à la contention

• Exécutez un microbenchmark simple de façon répétée et cherchez la bimodalité (Tâche 9).
• Capturez les modèles d’utilisation/mémoire pendant l’exécution lente (Tâche 10).
• Épinglez NUMA et comparez (Tâches 13–14).

Si la même charge bascule entre modes rapide et lent, vous avez probablement une variance de placement ou un réentraînement de lien. Si c’est constamment lent sous concurrence, vous avez probablement une contention du fabric.

Erreurs courantes (symptôme → cause racine → correction)

1) Symptom : temps par étape bimodal (alternance rapide/lent)

Cause racine : le placement mémoire ou de l’ordonnanceur n’est pas stable ; les données chaudes atterrissent parfois « distantes » du chiplet qui exécute.

Correction : appliquez un placement déterministe quand c’est possible (réglages d’allocateur, sharding explicite), épinglez CPU/NUMA, et évitez les migrations implicites en régime permanent.

2) Symptom : utilisation GPU élevée, débit faible

Cause racine : contention d’interconnect ou stalls mémoire ; les SM semblent « occupés » mais attendent des fetchs distants ou des atomiques.

Correction : réduisez le trafic inter-chiplets (réordonnez le layout des données, fusionnez les kernels pour améliorer la localité), plafonnez les DMA/prefetch concurrents, et isolez les voisins bruyants.

3) Symptom : régression après mise à jour du pilote, sans changement de code

Cause racine : les heuristiques d’ordonnancement ont changé ; nouveau comportement par défaut pour P2P, partitionnement type MIG, ou politique d’allocation mémoire modifiée.

Correction : testez A/B les versions de pilote ; figez les versions connues bonnes pour la production ; documentez les versions validées avec vos schémas de charge.

4) Symptom : erreurs Xid occasionnelles sous forte charge, qui disparaissent au reboot

Cause racine : lien marginal ou interconnect thermosensible ; le reboot réentraîne le lien, mais le problème revient.

Correction : vérifiez les tendances AER et ECC ; mettez le nœud en quarantaine ; mettez à jour le firmware ; validez le refroidissement et l’alimentation ; remplacez les composants suspects.

5) Symptom : effondrement du débit multi-processus en activant le chevauchement/prefetch

Cause racine : effondrement par congestion auto-infligée sur le fabric cross-die dû à trop de transferts en vol.

Correction : limitez les transferts en cours, planifiez les copies hors des phases compute critiques, et testez avec une concurrence réaliste — pas des benchmarks mono-job.

6) Symptom : « P2P est pris en charge » mais les transferts restent lents

Cause racine : le P2P existe mais est routé par un chemin plus lent (p.ex. classe de lien différente), ou les réglages ACS/IOMMU forcent des détours.

Correction : vérifiez la topologie, les paramètres PCIe, et mesurez la bande passante effective ; ne supposez pas que « OK » signifie « assez rapide ».

7) Symptom : pics de latence inference P99 sans saturation CPU

Cause racine : jitter d’arbitrage du fabric, thrashing de cache entre chiplets, ou contention due aux DMA d’arrière-plan.

Correction : priorisez la localité, réduisez l’état mutable partagé, isolez l’inférence de l’entraînement/prétraitement, et limitez les transferts d’arrière-plan.

Listes de contrôle / plan pas à pas

Checklist d’achat (avant d’acheter une flotte)

1. Exigez des détails de topologie : combien de tuiles, comment la HBM est attachée, et si « un périphérique » cache un comportement NUMA.
2. Demandez le comportement de l’interconnect sous contention : que se passe-t-il quand plusieurs moteurs se concurrencent (calcul, DMA, collectives).
3. Validez la maturité du pilote : exigez une version que vous pouvez figer et une voie de support pour les régressions de performance.
4. Testez avec vos pires kernels : pas seulement GEMM ; incluez embeddings, scatter/gather, atomiques, accès irréguliers.
5. Exigez de la télémétrie : compteurs pour la santé des liens, erreurs corrigées, et tout comportement d’auto-réduction de vitesse.

Checklist de mise en service (nouveau matériel dans votre DC)

1. Mesurez la largeur/vitesse des liens PCIe sur chaque nœud (Tâche 3) et consignez-les.
2. Enregistrez la topologie GPU (Tâche 2) et assurez-vous qu’elle correspond à la configuration SKU attendue.
3. Vérifiez la baseline ECC à l’idle et après un burn-in (Tâche 7).
4. Exécutez une suite microbenchmark de localité pour détecter les pénalités « distantes » (Tâche 9 répétée, plus vos propres tests).
5. Vérifiez que le runtime conteneur voit les bons périphériques (Tâche 11).
6. Mettez en place des alertes sur AER, Xid et tendances ECC corrigées (Tâche 12 + ingestion métriques).

Checklist de triage performance (quand un job est lent)

1. Confirmez la santé du nœud : throttling, réentraînement de lien, ECC (Tâches 6, 3, 7).
2. Capturez la topologie et l’affinité : topo GPU, NUMA, affinité CPU (Tâches 2, 4, 13).
3. Relancez avec binding NUMA et comparez (Tâche 14).
4. Capturez la série temporelle d’utilisation (Tâche 10) pendant la phase lente.
5. Réduisez la concurrence : exécutez seul sur le nœud pour voir si c’est dû à la contention.
6. Changez une variable à la fois : taille de lot, réglages de chevauchement, comportement de l’allocateur, version du pilote.

Checklist de conception (pour les ingénieurs écrivant kernels/modèles)

1. Supposez NUMA : gardez les données chaudes proches du calcul qui les utilise.
2. Minimisez les atomiques et synchronisations fines inter-chiplet.
3. Privilégiez les transferts en bloc plutôt que le trafic ping-pong.
4. Mesurez explicitement les pénalités de localité ; ne vous fiez pas au langage marketing « mémoire unifiée ».
5. Concevez pour un placement prévisible : un sharding stable vaut mieux qu’une migration dynamique astucieuse en production.

FAQ

1) Les GPU à chiplets sont-ils essentiellement les mêmes que multi-GPU ?

Non. Le multi-GPU est explicite : vous avez plusieurs dispositifs et vous les coordonnez. Les GPU à chiplets essaient de ressembler à un seul dispositif, ce qui est plus difficile car le runtime doit préserver les attentes « GPU unique » tout en gérant des coûts de type NUMA.

2) Si le fournisseur présente un espace d’adressage unifié, pourquoi devrais-je me soucier de la localité ?

Parce qu’un espace d’adressage unifié est une commodité, pas de la physique magique. Si une mémoire est à un hop d’interconnect, votre coût d’accès change. Sur des kernels gourmands en bande passante, « un hop » peut être la différence entre le pic et le plateau.

3) Quelles charges souffrent le plus sur les designs chiplet ?

Accès mémoire irréguliers, embeddings, scatter/gather, charges de graphe, synchronisation fine, kernels riches en atomiques, et tout ce qui provoque des rebonds de lignes de cache entre dies fréquents.

4) Quelles charges en bénéficient le plus ?

L’algèbre linéaire dense avec bonne localité, les kernels embarrassingly parallel, et les charges qui peuvent être partitionnées pour que chaque chiplet travaille surtout sur ses propres données. Si vous pouvez garder la HBM locale, vous pouvez gagner gros.

5) Est-ce principalement un problème matériel ou logiciel ?

Les deux, mais c’est le logiciel où vous ressentirez la douleur en premier. Le matériel fixe les contraintes ; le logiciel décide si vous les atteignez. Le runtime et le pilote sont en pratique votre middleware de systèmes distribués.

6) Comment les chiplets affectent-ils le débogage et l’observabilité ?

Ils font mentir plus souvent le « métrique unique ». Vous avez besoin de métriques conscientes de la topologie : santé des liens, latence sensible à la localité, et contention par moteur. L’utilisation GPU agrégée n’est pas suffisante.

7) Dois-je éviter les GPU à chiplets en production aujourd’hui ?

Évitez la première génération de tout si votre activité ne tolère pas les surprises. Si vous avez besoin du ratio performance/prix et pouvez investir dans le profiling et l’optimisation consciente de la topologie, les chiplets sont un pari raisonnable — mais ne les exploitez pas comme des monolithes.

8) Quel est le premier contrôle opérationnel à implémenter ?

L’ordonnancement conscient de la topologie. Si votre ordonnanceur de cluster ne peut pas placer les jobs avec affinité GPU/CPU et isoler les voisins bruyants, vous passerez votre vie à expliquer le jitter.

9) La « contention du fabric » est-elle réellement mesurable ?

Parfois directement via des compteurs fournisseurs, souvent indirectement via analyse de timeline et expériences contrôlées : exécutez mono-tenant vs multi-tenant, basculez le chevauchement, et observez comment le temps par étape change avec la concurrence.

10) Quelle est la croyance erronée la plus commune ?

Que « un périphérique GPU » implique « latence et bande passante uniformes ». Cette croyance est la façon dont vous vous retrouvez avec des falaises de performance qui semblent surnaturelles.

Conclusion : prochaines étapes pratiques

Les GPU à chiplets sont logiques parce que l’industrie a manqué de repas gratuits sur l’échelle monolithique. Ils sont brutalement difficiles parce que les GPU sont allergiques à la latence cachée et à la localité imprévisible. Si vous traitez les chiplets comme un monolithe plus grand, vous aurez un incident plus grand.

Prochaines étapes qui fonctionnent réellement en production :

• Construisez une baseline topologique pour chaque nœud : vitesses de liens, affinité NUMA, statut P2P, compteurs ECC.
• Rendez votre ordonnanceur conscient de la topologie : colocalisez les threads CPU et la mémoire avec les GPU qu’ils alimentent, et isolez les charges qui se battent sur le fabric.
• Mesurez la sensibilité à la localité tôt : ajoutez des microbenchmarks et des « détecteurs de bimodalité » à la qualification, pas aux postmortems.
• Contrôlez la concurrence et le chevauchement : plafonnez les transferts en vol et ne supposez pas que plus de chevauchement rime avec plus de performance.
• Épinglez et documentez les versions de pilote : traitez le pilote/runtime comme faisant partie du matériel, car pour les chiplets c’en est pratiquement un.

Le gain est réel : meilleur rendement, meilleure scalabilité, et une voie quand la physique du die unique dit « non ». Le coût est aussi réel : vous exploitez un système distribué à des vitesses térahertz. Agissez comme tel.