Construire un serveur d'inférence à 576 GB de VRAM : journal de mise en service

La plupart des articles consacrés aux serveurs décrivent la machine qui a été commandée. Celui-ci décrit la machine qui a été construite — y compris les deux défauts qu’elle présentait lors de sa première mise sous tension, et celui que nous n’avons jamais complètement expliqué.

Configuration : rack 7U · 2× AMD EPYC 7643 (96C/192T) · 512 GB DDR4 ECC · 6× NVIDIA RTX PRO 6000 Blackwell Max-Q, 576 GB GDDR7 · 2 TB + 4 TB NVMe
Assemblage et mise en service : août 2026, atelier Kentino, Prague · Statut : livré

Nous pensons que c’est l’article le plus utile. N’importe qui peut recopier une liste de composants.

Ce que c’est

Six cartes RTX PRO 6000 Blackwell Max-Q, 96 GB chacune, sur une plateforme EPYC Rome à double socket avec 512 GB de mémoire ECC. 576 GB de VRAM dans un seul boîtier, de quoi héberger un modèle de 753 milliards de paramètres en 4 bits avec encore de la place pour un million de tokens de contexte.

La variante Max-Q a son importance. À 300 W par carte au lieu de 600, six d’entre elles tiennent dans une enveloppe thermique et électrique qu’un atelier — puis, plus tard, une salle serveur — peut réellement fournir. La puissance mesurée à la prise en pleine charge est de ~2.9 kW, soit environ 80 % d’un seul circuit 16 A/230 V.

Le châssis est notre propre conception 7U : deux blocs de quatre baies GPU refroidis indépendamment, de sorte qu’aucune carte ne se trouve dans le flux d’air chaud de plus de trois autres.

Le premier défaut : deux GPU tournant discrètement à mi-vitesse

Le système a démarré, les six cartes ont été détectées, nvidia-smi semblait parfait.

Deux d’entre elles fonctionnaient en PCIe Gen4 x8 au lieu de x16.

Rien ne signalait d’erreur. Le pilote était satisfait, les cartes fonctionnaient, l’inférence tournait. Le seul moyen de s’en apercevoir était de mesurer la bande passante hôte-vers-carte pour chaque GPU et de constater que deux d’entre eux renvoyaient 13.9 GB/s là où les autres renvoyaient 27,7.

La cause était un défaut de couche physique sur deux connecteurs du châssis — pas les cartes, pas la carte mère, pas la conception des risers. Les deux liaisons ont été déplacées vers des connecteurs libres et les six ont alors confirmé du Gen4 x16 en charge. Les deux connecteurs suspects sont consignés nommément dans le dossier de fabrication et resteront inutilisés pendant toute la vie de la machine.

Un GPU qui entraîne à la moitié de sa largeur de lien ne se signale pas. Si votre procédure de mise en service ne mesure pas la bande passante PCIe par carte en charge, vous livrerez ce défaut sans jamais le savoir.

Le deuxième défaut : un motif ECC qui ne venait pas de la mémoire

En cours de mise en service, deux barrettes DIMM ont commencé à enregistrer des erreurs ECC corrigibles. Corrigible signifie que le matériel les a détectées et corrigées : aucune perte de données, aucun résultat faux, aucun impact sur quoi que ce soit. Mais deux modules qui remontent des erreurs, ce sont normalement deux modules à remplacer.

Nous ne les avons pas remplacés, et la raison est la partie intéressante.

Les événements étaient espacés de 4 h 30 min et 4 h 01 min, et chacun se déclenchait sur les deux modules dans la même seconde. Deux modules de mémoire indépendamment défaillants ne tombent pas en panne à intervalle quasi fixe, et certainement pas dans la même seconde trois fois de suite. Ce n’est pas à cela que ressemble du silicium qui se dégrade. C’est la signature de quelque chose d’extérieur et de périodique.

L’intervalle correspondait à une charge de commutation de forte puissance présente dans l’environnement de mise en service. Nous avons ensuite mené environ 20 heures de soak test instrumenté sous charge réelle soutenue, avec une télémétrie minute par minute sur les six GPU, le processeur, la mémoire, les disques et le journal d’événements du BMC. Zéro événement ECC.

Les modules sont donc restés en place.

Ce que nous prenons soin de dire : nous n’avons jamais corrélé ces événements avec un cycle journalisé de la source suspectée. L’attribution relève de la déduction, pas de la preuve. Nous avons communiqué au client l’observation, l’intervalle et la fenêtre de test, et nous avons dit clairement qu’il ne s’agit pas d’une cause racine prouvée. Si la cause était environnementale, elle ne suit pas la machine — et vingt heures de silence en charge constituent une bonne indication, pas une garantie.

Une remarque pratique qui nous a coûté du temps : cette plateforme utilise une gestion des erreurs confiée en priorité au firmware, si bien que les compteurs ECC côté Linux affichent zéro quoi qu’il arrive. L’état de santé de la mémoire doit être lu dans le journal d’événements du BMC. Si vous surveillez edac et rien d’autre, vous ne surveillez rien.

Ce que la machine fait réellement

Toutes les valeurs ont été mesurées sur ce système précis, et non reprises d’une fiche technique.

Calcul et régularité

Mesure	Résultat
Matmul dense FP16, par carte	291 à 302 TFLOPS (3.5 % d’écart sur six cartes)
Bande passante VRAM, par carte	~1,471 GB/s (uniforme à 0.2 % près)
Inférence en parallélisme de données sur six GPU	3,859 tok/s · 90.8 % d’efficacité de montée en charge
Écart entre réplicas sur les six GPU	0.45 %

Ce demi-pour-cent d’écart entre six cartes est le chiffre qui nous importe le plus. Il signifie qu’aucune carte ne sous-performe en silence — et il n’a de sens que parce que le défaut PCIe ci-dessus a d’abord été trouvé.

Inférence sur très grand modèle

GLM-5.2 — 753 milliards de paramètres (40 B actifs), 4 bits, 341 GB résidents sur six cartes :

Requêtes simultanées	1	4	16	32	48
Génération tok/s	38.0	78.5	117 à 120	148.1	172.2

La machine charge également le contexte natif de 1,048,576 tokens du modèle sur ce matériel — 494 GiB de VRAM, laissant 6.6 GiB libres sur la carte la plus sollicitée. Cela fonctionne, mais la marge est mince et nous l’avons dit.

Le réglage du micro-lot de préremplissage (-b/-ub 4096) a fait passer le traitement du prompt de 403 à 606 tok/s, un gain de 50 % pour une modification d’une seule ligne. Le décodage spéculatif a apporté +53 % en flux unique mais coûté 6 % sur le traitement par lots de prompts longs : il est donc activé par charge de travail plutôt que globalement.

Rodage

810,033 matmuls sur six GPU à 100 % de charge. Zéro erreur de calcul. Pic à 88 °C, 300 W soutenus par carte, aucun throttling thermique — clocks_event_reasons indiquait Not Active du début à la fin.

Là où cette machine est juste, et nous l’avons dit

La marge thermique est d’environ 2 °C. Pic à 88 °C pour un seuil de throttling autour de 90 °C, avec une température ambiante de 28 à 33 °C dans un atelier non climatisé, en août. Dans une pièce en dessous de 25 °C, la marge est confortable. Dans une pièce chaude, non. Les charges réelles soutenues ont atteint les mêmes températures que le rodage synthétique : ce n’est donc pas une inquiétude purement théorique.

Le levier évident est un plafond de puissance GPU — 260 W au lieu de 300 W. Nous n’avons pas mesuré ce que cela coûte en débit sur cette machine, nous ne l’avons donc pas recommandé comme si nous l’avions fait. Testez-le sur votre propre charge de travail.

La pile logicielle est spécifique et fragile. GLM-5.2 ne tourne ni sous vLLM ni sous SGLang sur cette génération de GPU — trois limitations amont distinctes. llama.cpp est la voie qui fonctionne. Par ailleurs, l’installation de vLLM embarque un correctif local qui règle un plantage en accès concurrent avec les modèles quantifiés, et ce correctif ne survit pas à un pip install -U vllm. Figez vos versions.

Double socket signifie NUMA. La bande passante hôte-vers-carte se répartit par socket : les GPU 0 à 2 sur l’un, 3 à 5 sur l’autre, avec une pénalité d’environ 20 % pour les tampons hôte alloués sur le mauvais nœud. Ce n’est pas un défaut — c’est de la physique — mais il faut épingler les processus avec numactl là où la bande passante hôte↔carte compte.

Un test est véritablement incomplet. L’étape finale de charge maximale combinée CPU+GPU a été interrompue par une panne de l’appareillage de distribution électrique de l’atelier. La vingtaine d’heures de tests d’endurance en charge mixte couvre le cas d’exploitation réel : nous avons donc signalé ce manque plutôt que de rebaptiser discrètement les essais d’endurance en test manquant.

Pourquoi nous publions les défauts

Un rapport de mise en service qui dit que tout a été validé ne vous apprend rien sur les gens qui l’ont rédigé. Toute machine de cette complexité présente un défaut à la première mise sous tension. La question est de savoir s’il est trouvé sur notre banc ou dans votre rack.

Sur cette configuration, il s’agissait de deux connecteurs qui dégradaient un quart du tissu GPU à mi-vitesse, invisibles pour tous les indicateurs d’état du système. Il a fallu une mesure pour le trouver et dix minutes pour le corriger.

C’est à cela que sert la mise en service.