Températures mémoire : pourquoi la GDDR6X est un problème à part

Rien n’égaye davantage une astreinte que d’avoir une flotte de GPU qui semble « normale » au regard de la température du cœur, mais qui, de façon mystérieuse, voit son hashrate, son frame rate, son débit d’inférence chuter — ou qui commence à redémarrer des nœuds comme s’ils s’ennuyaient.

Le coupable est souvent la mémoire. Plus précisément la GDDR6X, qui peut tourner extrêmement chaude alors que le cœur du GPU affiche un sourire satisfait à 65°C. Si vous ne surveillez que la « Température GPU », vous volez avec des instruments qui n’incluent pas la falaise.

Pourquoi la GDDR6X est différente (et pourquoi elle chauffe autant)

La GDDR6X n’est pas simplement « GDDR6 plus rapide ». Elle a changé la façon dont elle signale les données. Et ce choix de conception résonne jusque dans vos tableaux de bord opérationnels.

PAM4 : quand « plus de bits par cycle » signifie « plus de problèmes analogiques par watt »

La GDDR6X utilise PAM4 (modulation d’amplitude par impulsion à quatre niveaux). Au lieu de deux niveaux de signal (0/1), vous en avez quatre. Cela permet de transporter deux bits par symbole et d’augmenter la bande passante sans doubler la fréquence comme avec le signal NRZ.

En pratique, PAM4 rend la chaîne de signalisation plus sensible. Vous travaillez avec des marges de tension plus faibles, plus d’égalisation et davantage d’efforts pour garder un diagramme d’œil propre. Plus de travail signifie plus de puissance dissipée dans l’interface mémoire — côté contrôleurs/PHY GPU et dans les puces mémoire elles-mêmes.

Le résultat est un schéma connu en production : le cœur du GPU peut être sous contrôle pendant que les températures de jonction mémoire montent vers la zone dangereuse, parce que les sources de chaleur sont réparties autour du package et souvent refroidies par des chemins différents (et pire).

La chaleur mémoire est une « chaleur de bord », et refroidir les bords est pénible

La plupart des systèmes de refroidissement GPU sont optimisés pour le die GPU. C’est la grosse source de chaleur évidente, centrée mécaniquement, et la raison d’être du produit. Les puces mémoire se trouvent autour du périmètre du PCB, reposant fréquemment sur des pads thermiques pour les relier au radiateur principal ou à la backplate.

Les pads thermiques sont pratiques pour la fabrication. Ils sont aussi un excellent moyen de transformer « devrait conduire la chaleur » en « isole réellement la chaleur » si l’épaisseur, la compression ou le placement sont décalés d’un millimètre. Et plus la carte vieillit, plus le pad se comporte comme un chewing-gum rance.

Les températures mémoire n’ont pas la même « sensation » que les températures du cœur

La température du cœur est souvent fortement régulée avec des courbes de ventilateur agressives et un contact de radiateur prévisible. La température de jonction mémoire est une bête différente : forte densité locale, chemins de conduction plus faibles et moins de flux d’air. C’est pourquoi vous pouvez voir un GPU à 70°C avec la mémoire à 104–110°C et penser être en sécurité parce que 70 semble raisonnable.

Règle opérationnelle : pour la GDDR6X, traitez la température mémoire comme une métrique de première classe. Pas « agréable à avoir ». De première classe. Si vous ne l’avez pas, vous êtes borgne et vous vous étonnerez de continuer à vous cogner contre des portes.

Blague #1 : les températures mémoire GDDR6X ressemblent aux câblages « temporaires » de votre datacenter — ignorées jusqu’à devenir l’intrigue principale.

Ce que signifie « température mémoire »

Noms des capteurs : « memory temp », « mem junction », « hotspot » et pourquoi ils divergent

Sur de nombreuses cartes NVIDIA modernes, ce que vous voulez est la température de jonction mémoire — le point le plus chaud à l’intérieur du package mémoire que le modèle de capteur peut estimer ou mesurer. Ce n’est pas la même chose que la température du PCB près de la puce, et ce n’est pas la même chose que le « hotspot GPU » (qui désigne la région la plus chaude du die GPU).

Les vendeurs exposent cela de différentes manières :

• Température GPU : le capteur du cœur, typiquement contrôlé et « raisonnable ».
• GPU Hotspot : la portion la plus chaude du die GPU. Utile, mais pas votre problème mémoire.
• Température de jonction mémoire : ce qui devient généralement critique en premier sur la GDDR6X.

Différents outils peuvent afficher des libellés différents. Certains n’affichent que la température du cœur et vous laissent deviner. C’est là que vos flottes semblent « stables » jusqu’à ce qu’elles ne le soient plus.

Pourquoi la température de jonction est plus inquiétante qu’elle n’en a l’air

La température de jonction est proche de la réalité du silicium. Si votre jonction mémoire est à 106°C, le petit monde à l’intérieur de cette puce vit intensément. Le silicium peut survivre à des températures élevées, mais la fiabilité est une question de probabilités, pas de promesses. La chaleur accélère les mécanismes de vieillissement. Vous ne verrez peut-être pas un crash immédiat ; vous verrez peut-être une augmentation lente des erreurs corrigeables, une perte de marge temporelle et une instabilité « aléatoire » sous des charges de travail spécifiques.

Comportements de throttling : le GPU se protège, pas votre SLA

La protection thermique existe pour empêcher le matériel de se détruire immédiatement, pas pour préserver votre objectif de débit. Lorsque la mémoire atteint sa limite, vous pouvez observer :

• Réductions de la fréquence mémoire (baisse de performance sans problème apparent de température du cœur)
• Changements dans le comportement de la limite de puissance (boucles de contrôle au niveau de la carte qui compensent)
• Réinitialisations du pilote sous charge soutenue (surtout avec des pads/contact limites)

Faits intéressants et bref historique (8 points)

1. GDDR « a gagné » le monde GPU grand public principalement parce qu’elle a monté en bande passante sans la complexité d’emballage de la HBM pour la plupart des prix.
2. PAM4 n’a pas été inventé pour les GPU ; c’est une technique de signalisation largement utilisée dans les liens haute vitesse quand on a besoin de débit sans augmenter proportionnellement la fréquence.
3. La GDDR6X a fait ses débuts sur les GPU grand public comme saut de bande passante sans réécriture architecturale complète — excellente pour le rapport performance/prix, épicée pour les thermiques par cm².
4. L’histoire thermique de la HBM est différente : la mémoire empilée près du package GPU peut aussi être chaude, mais les chemins de refroidissement et l’intégration diffèrent ; la GDDR6X disperse la chaleur autour de la carte et dans les pads et backplates.
5. Les capteurs de jonction mémoire sont devenus mainstream seulement après que les utilisateurs ont corrélé des throttlings inexpliqués avec la chaleur VRAM ; la télémétrie a évolué parce que la panne était visible et agaçante.
6. Les charges de minage ont rendu les thermiques VRAM célèbres car elles maintiennent une bande passante mémoire élevée en continu — parfait pour révéler un mauvais contact de pad et un flux d’air faible.
7. Les backplates ont changé de rôle de « couverture métallique rigide et esthétique » à « dissipateur secondaire » une fois que les vendeurs ont ajouté des pads thermiques pour coupler la chaleur mémoire via le PCB.
8. Les courbes de ventilateur suivaient historiquement la température du cœur, ce qui explique pourquoi la mémoire surchauffe souvent : la boucle de contrôle surveille le mauvais patient.

Modes de défaillance : throttling, erreurs et la lente agonie du « c’est ok »

1) Throttling soft : la coupe silencieuse de performance

C’est le plus courant. Votre GPU semble sain dans la surveillance générique. Mais une charge mémoire-intense — entraînement, inférence avec activations larges, rendu, minage, noyaux de compression — commence à sous-performer après quelques minutes.

Ce qui se passe : la jonction mémoire grimpe, le firmware/le pilote réduit les fréquences mémoire pour rester dans l’enveloppe thermique, et votre débit chute brutalement sans que personne ne fasse le lien parce que la « Température GPU » est restée stable.

2) Erreurs non correctibles : le « crash aléatoire » qui n’est pas aléatoire

À mesure que la marge diminue, vous pouvez voir des réinitialisations de pilote, des erreurs CUDA, des sorties corrompues ou des plantages d’applications. En entreprise, vous verrez souvent les compteurs d’erreurs corrigeables augmenter en premier — si vous les collectez. Dans des environnements moins instrumentés, vous verrez simplement des jobs qui échouent « parfois ».

3) Fiabilité à long terme : la chaleur est un accélérateur

Une température élevée augmente la vitesse des mécanismes d’usure. Inutile d’en faire une leçon de science des matériaux pour agir : si vous faites fonctionner la mémoire à la limite pendant des mois, attendez-vous à une dégradation plus précoce qu’une flotte fonctionnant 20°C plus froide.

Et non, votre garantie ne se soucie pas de vos objectifs trimestriels.

4) Effets secondaires : VRM et points chauds sur la carte

La chaleur mémoire n’existe pas seule. Dans des châssis encombrés, les mêmes contraintes d’écoulement d’air qui punissent la VRAM punissent aussi les VRM. Parfois vous corrigez la mémoire en augmentant la vitesse des ventilateurs, pour découvrir que vous avez déplacé la douleur vers les budgets de bruit ou l’usure des ventilateurs. L’ingénierie, c’est des compromis. Choisissez le compromis délibérément.

Une citation, paraphrasée : « L’espoir n’est pas une stratégie. » — idée souvent répétée par des ingénieurs fiabilité et opérations. Prenez-le comme un rappel, pas un autocollant.

Playbook de diagnostic rapide

Ceci est la séquence « vous avez 10 minutes et un pager ». L’objectif est d’identifier si vous êtes limité par la thermique mémoire, la thermique du cœur, la puissance, ou autre chose.

Premier point : confirmez que vous voyez le bon capteur

• Vérifiez si la température de jonction mémoire est exposée dans vos outils.
• Si vous ne pouvez pas la voir, considérez cela comme un blocage d’incident immédiat : vous ne pouvez pas diagnostiquer ce que vous ne pouvez pas observer.

Deuxième point : corrélez la température avec les horloges et les raisons de throttling

• Surveillez la température mémoire, la fréquence mémoire et les états de throttling/perf sous charge soutenue.
• Si la température mémoire augmente et que la fréquence mémoire chute tandis que la température du cœur reste stable, vous avez trouvé votre goulot d’étranglement.

Troisième point : déterminez si c’est environnemental, mécanique ou de configuration

• Environnemental : flux d’air du boîtier, température d’entrée, filtres bouchés, disposition des racks, échappement chaud adjacent.
• Mécanique : contact des pads, épaisseur des pads, couplage backplate, assise du radiateur.
• Configuration : courbes ventilateur liées à la température du cœur, limites de puissance trop élevées, overclock mémoire, choix d’undervolt.

Quatrième point : choisissez l’atténuation à moindre risque

• Augmentez le flux d’air et la vitesse des ventilateurs avant de démonter le matériel.
• Limitez la puissance ou réduisez la fréquence mémoire avant de commencer à remplacer des pads sur une flotte.
• Repad/repastez uniquement lorsque les preuves indiquent un problème de contact ou lorsque vous avez besoin d’une correction permanente.

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

Voici des tâches réelles que vous pouvez exécuter sur des nœuds GPU Linux. Chacune inclut : la commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Check whether your driver exposes memory junction temperature

cr0x@server:~$ nvidia-smi -q -d TEMPERATURE
==============NVSMI LOG==============

Temperature
    GPU Current Temp            : 66 C
    GPU Shutdown Temp           : 95 C
    GPU Slowdown Temp           : 90 C
    GPU Max Operating Temp      : 88 C
    Memory Current Temp         : 104 C

Signification : « Memory Current Temp » est présent. Bien — c’est le capteur sur lequel vous devez alerter pour la GDDR6X.

Décision : Si ce champ manque, vous avez besoin d’une mise à jour du pilote/outillage ou d’une voie alternative de télémétrie. Aucune excuse.

Task 2: Watch memory temp and clocks live under load

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,index,temperature.gpu,temperature.memory,clocks.sm,clocks.mem,pstate,power.draw --format=csv -l 2
timestamp, index, temperature.gpu, temperature.memory, clocks.sm, clocks.mem, pstate, power.draw
2026/01/21 10:14:01.123, 0, 67, 102, 1560, 9501, P2, 240.12 W
2026/01/21 10:14:03.124, 0, 68, 106, 1560, 8100, P2, 239.88 W
2026/01/21 10:14:05.125, 0, 68, 108, 1560, 7001, P2, 238.77 W

Signification : La fréquence mémoire chute à mesure que la température mémoire augmente ; la température du cœur est stable. C’est un throttling VRAM thermique classique.

Décision : Arrêtez d’optimiser le cœur. Concentrez-vous sur le refroidissement mémoire, le flux d’air, la limitation de puissance ou les limites de fréquence mémoire.

Task 3: Check throttling reasons (when supported)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE
Performance
    Performance State          : P2
    Clocks Throttle Reasons
        Idle                  : Not Active
        Applications Clocks Setting : Not Active
        SW Power Cap          : Not Active
        HW Slowdown           : Active
            HW Thermal Slowdown : Active
            HW Power Brake Slowdown : Not Active

Signification : Un ralentissement matériel thermique est actif. Cela corrèle souvent avec la jonction mémoire dépassant un seuil même si la température du cœur n’est pas extrême.

Décision : Traitez cela comme un incident thermique, pas comme un bug du pilote. Passez aux vérifications flux d’air/limitation de puissance.

Task 4: Confirm power limit and current draw

cr0x@server:~$ nvidia-smi -q -d POWER | sed -n '1,80p'
Power Readings
    Power Management          : Supported
    Power Draw                : 241.05 W
    Power Limit               : 250.00 W
    Default Power Limit       : 250.00 W
    Enforced Power Limit      : 250.00 W
    Min Power Limit           : 125.00 W
    Max Power Limit           : 300.00 W

Signification : Vous fonctionnez proche de la limite. Réduire la puissance peut diminuer le chauffage du contrôleur mémoire/IO et parfois la température mémoire indirectement.

Décision : Si vous êtes lié thermiquement, testez une limite de puissance inférieure (tâche suivante) avant de toucher au matériel.

Task 5: Apply a conservative power cap (safe, reversible)

cr0x@server:~$ sudo nvidia-smi -pl 220
Power limit for GPU 00000000:01:00.0 was set to 220.00 W from 250.00 W.

Signification : La limite de puissance de la carte est abaissée. Cela réduit généralement la chaleur dans les sous-systèmes GPU+mémoire.

Décision : Relancez la Tâche 2 ; si la température mémoire baisse sensiblement avec peu de perte de débit, conservez la limite et documentez-la comme politique.

Task 6: Force a higher fan speed to test airflow sensitivity

cr0x@server:~$ nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=85"
Attribute 'GPUFanControlState' (server:0[gpu:0]) assigned value 1.
Attribute 'GPUTargetFanSpeed' (server:0[fan:0]) assigned value 85.

Signification : Contrôle du ventilateur forcé. Si les températures mémoire réagissent fortement, vous avez probablement un problème de flux d’air/éventail plus que de contact pur.

Décision : Si +20% de ventilateur entraîne -10°C sur la jonction mémoire, vous disposez d’un chemin de refroidissement qui peut être amélioré par des modifications du flux d’air du châssis.

Task 7: Validate PCIe slot spacing and topology (heat neighbors matter)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity
GPU0     X      PHB     0-15
GPU1    PHB      X      0-15

Signification : La topologie n’affiche pas l’espacement physique directement, mais elle indique si les GPU sont probablement adjacents sur le même root complex. Les cartes adjacentes recirculent souvent la chaleur.

Décision : Si la mémoire d’un GPU est systématiquement plus chaude, vérifiez sa position physique : le « syndrome de la carte du milieu » existe réellement.

Task 8: Check system ambient and inlet temperatures (don’t guess)

cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  54.0°C  (high = +80.0°C, crit = +100.0°C)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +48.9°C  (low  = -10.1°C, high = +84.8°C, crit = +89.8°C)

Signification : Ce n’est pas une lecture d’ambiance parfaite, mais la hausse des températures système et NVMe indique souvent un mauvais flux d’air de châssis ou une température d’entrée élevée.

Décision : Si tout est chaud, corrigez d’abord la pièce/le flux du rack. Un repad GPU ne battra pas une entrée à 35°C.

Task 9: Identify whether workload is memory-bandwidth bound

cr0x@server:~$ nvidia-smi dmon -s pucm -d 2 -c 5
# gpu   pwr gtemp mtemp  sm   mem   enc   dec
# Idx     W     C     C   %     %     %     %
    0   230    67   104   35    92     0     0
    0   232    68   106   35    95     0     0
    0   228    68   108   33    96     0     0
    0   225    68   108   30    97     0     0
    0   221    67   107   28    96     0     0

Signification : « mem % » est élevé tandis que l’utilisation SM est modérée. C’est une charge mémoire-intensive — exactement le type qui punit les thermiques GDDR6X.

Décision : La stratégie de refroidissement doit prioriser la mémoire ; envisagez des limites de fréquence mémoire avec un impact minimal sur les tâches limitées par le calcul, mais attendez-vous à un impact ici.

Task 10: Check kernel and driver logs for Xid resets (symptom of instability)

cr0x@server:~$ sudo journalctl -k -n 50 | egrep -i "nvrm|xid"
Jan 21 10:12:44 server kernel: NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
Jan 21 10:12:44 server kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed!

Signification : « Fallen off the bus » peut être dû à la puissance, au PCIe, ou à l’instabilité/thermique. Lorsqu’il apparaît après une charge soutenue et qu’il corrèle avec une jonction mémoire élevée, suspectez la thermique VRAM ou le stress thermique au niveau de la carte.

Décision : Réduisez la limite de puissance et les fréquences mémoire, validez le flux d’air, puis enquêtez sur le refroidissement physique. Vérifiez aussi l’alimentation/les câbles PCIe séparément.

Task 11: Verify persistence mode (prevents some clock/telemetry weirdness)

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:01:00.0.

Signification : Le mode persistence maintient le pilote initialisé ; il peut stabiliser la surveillance et réduire le rembourrage de ré-initialisation entre les jobs.

Décision : Activez-le à l’échelle de la flotte sur les nœuds de calcul sauf si votre environnement l’interdit explicitement.

Task 12: Set application clocks (if supported) to reduce memory heat

cr0x@server:~$ sudo nvidia-smi -ac 8100,1500
Applications clocks set to "(MEM 8100, SM 1500)" for GPU 00000000:01:00.0

Signification : Vous épinglez les fréquences mémoire et SM. Réduire la fréquence mémoire fait souvent baisser significativement la température de jonction sur la GDDR6X.

Décision : Utilisez ceci comme atténuation ciblée pour les charges mémoire-bound ou les châssis thermiquement contraints.

Task 13: Validate fan tach and failures (because “fan 0 is fine” is a lie)

cr0x@server:~$ nvidia-smi --query-gpu=fan.speed,temperature.gpu,temperature.memory --format=csv
fan.speed, temperature.gpu, temperature.memory
32 %, 66, 104

Signification : La vitesse du ventilateur est faible tandis que la mémoire est élevée. Si votre courbe de ventilateur dépend du cœur, elle peut ne jamais monter assez pour la VRAM.

Décision : Ajustez la politique des ventilateurs pour tenir compte de la température mémoire (via un démon ou l’outil du vendeur), ou définissez un plancher de ventilateur minimum pendant les charges mémoire-intenses.

Task 14: Check physical throttling by observing clocks over time after mitigation

cr0x@server:~$ nvidia-smi --query-gpu=temperature.memory,clocks.mem,power.draw --format=csv -l 5
temperature.memory, clocks.mem, power.draw
108, 7001, 222.14 W
102, 8100, 220.90 W
98,  8100, 221.33 W
96,  8100, 221.05 W

Signification : La température mémoire a baissé et la fréquence mémoire s’est rétablie avec la même limite de puissance. Vous avez prouvé le goulot d’étranglement et l’efficacité du correctif.

Décision : Intégrez le changement dans la gestion de la configuration ; planifiez une remediation matérielle uniquement pour les cas isolés.

Trois petites histoires d’entreprise du terrain

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

Une entreprise a déployé un nouveau lot de GPU dans un cluster d’inférence existant. Ils avaient fait les vérifications habituelles : les températures du cœur semblaient excellentes, la puissance restait dans le budget du rack, et les premiers tests rapides étaient concluants. Ils ont donc déclaré la victoire, mis en production et sont partis.

Deux semaines plus tard, des échecs de jobs intermittents ont commencé. Pas des échecs propres — la moitié du lot finissait, l’autre moitié retournait des sorties absurdes ou plantait avec des réinitialisations de pilote. L’astreinte a effectué la danse prévisible : blâmer le modèle, blâmer CUDA, blâmer le kernel. Puis se blâmer entre eux. Cardio corporate standard.

La mauvaise hypothèse était simple : « Si la température du cœur est stable, le GPU est thermiquement stable. » Ce n’était pas le cas. Sous des charges réelles, les modèles subissaient de longues périodes de bande passante mémoire élevée. Les températures de jonction mémoire atteignaient silencieusement leur limite thermique, déclenchant des baisses de fréquence mémoire et une instabilité occasionnelle.

Ils ne le voyaient pas parce que leur pile de monitoring ne scrappait que la « Température GPU ». La température mémoire n’était pas collectée, et personne n’a remarqué la dérive des fréquences mémoire. Une fois la télémétrie de jonction mémoire ajoutée, la corrélation a été embarrassante et immédiate.

Le correctif n’était pas exotique. Ils ont mis un plafonnement de puissance conservateur et un plancher de ventilateur minimum sur les nœuds exécutant ces modèles. Ensuite, ils ont planifié le repadding pour les plus mauvais cas. L’incident s’est terminé dès qu’ils ont arrêté de considérer le GPU comme une seule température.

Mini-histoire 2 : l’optimisation qui s’est retournée contre eux

Une autre organisation chassait le bruit et les économies d’énergie dans un laboratoire à usage mixte. Quelqu’un a proposé une politique de ventilateur « intelligente » : garder les ventilateurs bas sauf si le cœur GPU dépassait 78°C. Cela fonctionnait bien en démo — silencieux, civilisé, et la valeur affichée restait contrôlée.

Ils l’ont déployée largement, y compris sur des systèmes exécutant des lots mémoire-intensifs la nuit. Le lendemain matin, le débit avait chuté. Pas catastrophiquement, mais suffisamment pour rater des délais internes et déclencher l’archéologie Slack habituelle sur « pourquoi le cluster est lent ».

La politique a fonctionné exactement comme conçue. C’était le problème. Les températures du cœur n’ont jamais dépassé le seuil, donc les ventilateurs ne sont pas montés. La température de jonction mémoire est montée dans la zone de throttling, les fréquences mémoire sont tombées, et les jobs ont pris plus de temps. Des jobs plus longs signifiaient un bain de chaleur prolongé. Le bain de chaleur a entraîné des températures mémoire encore plus élevées. L’optimisation est devenue une boucle de rétroaction de sous-performance polie.

Ils ont annulé la politique de ventilateur et l’ont remplacée par quelque chose de moins intelligent : un plancher minimum de ventilateur lorsque l’utilisation mémoire reste élevée pendant plus d’une courte fenêtre, plus des alertes sur la jonction mémoire. Le bruit a légèrement augmenté. Le débit est revenu. Personne n’a écrit de billet de blog sur cette victoire, car les solutions ennuyeuses ne sont pas célébrées.

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

Une troisième équipe exploitait des GPU dans un datacenter où les changements matériels étaient lents et les audits fréquents. Ils ne pouvaient pas « simplement repadder » les cartes sans contrôle de changement. Ils ont donc traité la gestion thermique comme une politique, pas comme des exploits héroïques.

Chaque nœud avait une télémétrie standardisée : température du cœur, jonction mémoire, hotspot (quand disponible), vitesse du ventilateur, puissance tirée et fréquences. Ils avaient des alertes non seulement sur la température mémoire absolue, mais aussi sur le delta : si la température mémoire augmentait plus vite que la normale pour un profil de charge donné, le nœud était signalé pour inspection.

Quand un lot de jobs a soudainement ralenti, ils n’ont pas deviné. Les dashboards ont montré des fréquences mémoire qui plongeaient sur un sous-ensemble de nœuds tandis que le reste restait stable. Ces nœuds avaient aussi une température d’entrée légèrement plus élevée, due à un changement de flux d’air du rack après une maintenance non liée.

Ils ont corrigé le flux d’air, et les performances se sont normalisées sans toucher un seul GPU. La partie « ennuyeuse » a été la victoire : instrumentation cohérente et une politique simple qui supposait que la mémoire pouvait être le facteur limitant.

Blague #2 : La seule chose plus sensible que la signalisation PAM4 est un postmortem où quelqu’un dit « nous n’avons pas pensé avoir besoin de cette métrique. »

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: core temp is fine, performance still drops after 5–15 minutes

Cause racine : la jonction mémoire atteint la limite thermique ; la fréquence mémoire throttle.

Correctif : surveiller la jonction mémoire ; augmenter le flux d’air/plancher ventilateur ; plafonner la puissance ; réduire les fréquences mémoire ; envisager le repadding si les températures sont anormalement élevées pour le modèle/châssis.

2) Symptom: “random” CUDA errors or driver resets under sustained load

Cause racine : perte de marge thermique (souvent mémoire), parfois combinée à un overclock mémoire agressif ou une stabilité d’alimentation insuffisante.

Correctif : supprimer les overclocks mémoire, réduire la limite de puissance, valider le flux d’air, vérifier les logs pour les motifs Xid, puis inspecter le refroidissement physique et le câblage PCIe.

3) Symptom: one GPU in a multi-GPU box runs much hotter memory temps than peers

Cause racine : emplacement physique (carte du milieu), recirculation d’échappement, entrée obstruée, ou contact de pad inégal.

Correctif : ajuster l’espacement ou l’affectation des slots ; ajouter des ventilateurs de châssis ou du guidage d’air ; définir une politique par GPU pour ventilateur/puissance ; repadder si c’est exclusivement mauvais sur plusieurs châssis.

4) Symptom: changing core undervolt doesn’t improve memory temps

Cause racine : la température mémoire est entraînée par l’IO/power mémoire et le chemin de refroidissement ; l’undervolt du cœur aide parfois, mais pas toujours.

Correctif : cibler la mémoire : réduire la fréquence mémoire, plafonner la puissance de la carte, améliorer le contact pad/backplate et le flux d’air sur les zones mémoire.

5) Symptom: repasting the GPU core did nothing

Cause racine : vous avez réparé la mauvaise interface ; les pads mémoire sont le facteur limitant, pas la pâte du cœur.

Correctif : inspecter/remplacer les pads thermiques avec la bonne épaisseur et compression ; assurer une pression uniforme du radiateur/backplate ; valider avec la télémétrie avant/après.

6) Symptom: memory temps improved briefly after cleaning, then got worse again

Cause racine : la poussière faisait partie du problème, mais la courbe ventilateur ou la dérive de la température de la pièce vous ramène au bord ; possible aussi pompe/âge des pads.

Correctif : implémenter des planchers de ventilateur pour les charges mémoire-intenses ; vérifier la température d’entrée ; planifier le remplacement préventif des pads pour les cartes à fort temps d’utilisation.

7) Symptom: memory temps readings are missing or always zero

Cause racine : incompatibilité pilote/outil, GPU/firmware non supporté, ou utilisation d’un outil qui ne lit que les capteurs du cœur.

Correctif : mettre à jour le pilote ; utiliser nvidia-smi -q comme vérité terrain ; mettre à jour les exporters de monitoring ; ne construisez pas de politiques sur des données absentes.

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

Étape par étape : stabiliser un système GDDR6X chaud sans toucher au matériel

1. Collecter les températures de jonction mémoire et les fréquences mémoire. Si vous ne pouvez pas, arrêtez-vous et corrigez la télémétrie.
2. Exécuter une charge soutenue de 10–15 minutes. Surveillez si les fréquences mémoire descendent pendant que la température du cœur reste stable.
3. Forcer les ventilateurs à grande vitesse pendant 5 minutes. Si la température mémoire baisse rapidement, le flux d’air est un levier important.
4. Appliquer un plafonnement de puissance conservateur. Retester ; conserver la limite si l’impact sur le débit est acceptable.
5. Définir un plancher minimum de ventilateur en production pour les charges mémoire-intenses. Liez-le au type de charge ou aux motifs d’utilisation du GPU, pas seulement à la température du cœur.
6. Retirer les overclocks mémoire. Si vous overclockez la VRAM en production, vous choisissez le drame.

Étape par étape : décider de repadder (et comment éviter d’empirer les choses)

1. Prouvez que c’est un problème de contact. Comparez le même modèle dans des châssis similaires ; si une carte est un outlier de 10–20°C, suspectez les pads/contact.
2. Vérifiez la garantie et le contrôle de changement. Ne transformez pas une correction thermique en incident de conformité.
3. Documentez l’épaisseur des pads avant retrait. Une mauvaise épaisseur est la façon dont vous échangez la chaleur mémoire contre un montage de radiateur déformé.
4. Remplacez les pads par la bonne épaisseur et la conductivité appropriée. Une haute conductivité n’aide pas si la compression est incorrecte.
5. Validez avec la télémétrie. Vous voulez des températures de jonction mémoire avant/après sous la même charge.
6. Déployez les changements lentement. Un châssis, un type de carte, une recette de pad à la fois.

Checklist opérationnelle : sur quoi alerter pour la GDDR6X

• Température de jonction mémoire : alerter sur des valeurs absolues élevées et sur la durée maintenue au-dessus de votre seuil choisi.
• Baisse de fréquence mémoire : alerter quand la fréquence mémoire s’écarte de l’attendu sous une charge stable.
• Anomalies de la vitesse des ventilateurs : ventilateur bas à température mémoire élevée est généralement un problème de politique ou une défaillance de ventilateur.
• Drapeaux de ralentissement thermique : si disponibles, traitez-les comme actionnables, pas informatifs.
• Logs d’erreurs : événements Xid ou réinitialisations répétées corrèlent avec l’instabilité ; enquêtez les thermiques en parallèle de la puissance et du PCIe.

FAQ

1) Pourquoi la GDDR6X chauffe-t-elle plus que la GDDR6 ?

Parce que la signalisation PAM4 et le PHY/égalisation associés augmentent généralement la consommation dans le sous-système mémoire à une même bande passante. Plus de bande passante = plus de chaleur, et le chemin de refroidissement est souvent pire que celui du die GPU.

2) Quelle est une température « sûre » pour la mémoire GDDR6X ?

Cela dépend de la carte spécifique et de ses points de throttling, mais opérationnellement : ne vivez pas près du seuil de throttling. Visez à garder la jonction mémoire confortablement en dessous du point où les fréquences commencent à chuter sous charge soutenue.

3) Pourquoi mon cœur GPU est à 65°C mais la mémoire est à plus de 100°C ?

Différentes sources de chaleur, différents chemins de refroidissement. Le cœur a un contact direct avec le radiateur via la pâte ; la mémoire repose sur des pads et souvent moins de flux d’air. La température du cœur ne représente pas les composants les plus chauds de la carte.

4) L’undervolt du cœur GPU va-t-il améliorer les températures VRAM ?

Parfois un peu, souvent pas assez. Si la mémoire est le goulot, vous devez généralement agir sur la fréquence mémoire, la puissance de la carte, le flux d’air ou le contact des pads.

5) Les backplates aident-elles les températures GDDR6X ?

Oui — si des pads thermiques couplent les régions chaudes à la backplate et si la backplate dispose d’un flux d’air ou d’une masse pour dissiper la chaleur. Une backplate décorative sans couplage est principalement du style.

6) Pourquoi l’augmentation de la vitesse des ventilateurs a-t-elle aidé plus la mémoire que le cœur ?

Les températures du cœur sont fortement couplées au radiateur principal et régulées. Les températures mémoire sont souvent limitées par le flux d’air autour des bords de la carte. Plus de flux d’air peut aider de façon disproportionnée la VRAM et les zones VRM.

7) Dois-je repadder chaque carte GDDR6X de façon préventive ?

Non. Le repadding est invasif, risque des problèmes de garantie/conformité, et peut être mal fait. Utilisez la télémétrie pour identifier les outliers ou les systèmes qui throttlent chroniquement, puis ciblez ceux-là.

8) Pourquoi ma température mémoire augmente-t-elle uniquement sur certains workloads ?

Parce que certains workloads saturent la bande passante mémoire ou maintiennent continuellement les contrôleurs mémoire occupés. Ces charges génèrent une chaleur mémoire soutenue même quand l’utilisation SM est modérée.

9) Les pads thermiques peuvent-ils « vieillir » et causer une hausse de la température mémoire dans le temps ?

Oui. Les pads peuvent durcir, se comprimer (creep) ou perdre la pression de contact effective au fil du temps et des cycles thermiques. Le symptôme est une progression des températures de jonction mémoire pour la même charge et les mêmes conditions ambiantes.

10) Quelle est la meilleure métrique à ajouter si je ne peux en ajouter qu’une ?

La température de jonction mémoire. Si vous pouvez aussi, ajoutez la fréquence mémoire et les raisons de throttling pour prouver la cause et l’effet.

Conclusion : les prochaines étapes qui font vraiment la différence

La GDDR6X transforme les « thermiques GPU » en un problème à deux corps. Vous ne pouvez plus gérer seulement le die. Vous devez gérer l’écosystème mémoire : pads, flux d’air, politique des ventilateurs, limites de puissance et comportement des workloads.

Faites ceci ensuite, dans l’ordre :

1. Intégrez la température de jonction mémoire à votre monitoring et à vos alertes, aux côtés de la fréquence mémoire.
2. Exécutez un test de charge soutenue et confirmez si les fréquences mémoire baissent à mesure que les températures augmentent.
3. Appliquez d’abord l’atténuation la moins risquée : planchers ventilateur, améliorations du flux d’air et plafonnement conservateur de la puissance.
4. Envisagez la remediation matérielle (repadding/inspection) seulement pour les outliers ou les flottes qui continuent de throttler dans des conditions d’exploitation raisonnables.

Une fois que vous traitez la mémoire comme un domaine thermique de première classe, l’histoire du « throttling mystère » disparaît en grande partie. Pas parce que le matériel est devenu plus gentil — mais parce que vous avez arrêté de demander à un seul capteur d’expliquer une carte entière.