Résumé

  • Lors d’un test de performance NCCL sur toutes les liaisons, SoftBank a trouvé un lien limité à une fraction non précisée du débit normal, malgré une LED verte, un Link Status UP et une puissance optique normale. Ces signaux étaient valides, mais trop étroits pour réceptionner une capacité destinée au workload.
  • Les supports de JANOG58 citent le switch, les optics, la NIC, la fibre et un connector sale comme surfaces de diagnostic. Ils ne publient ni cause racine, ni ratio exact, ni valeurs BER/FEC de l’incident, ni réparation mesurée. Les chiffres et remplacements d’optics figurant dans les pages suivantes sont des exemples.
  • La réception d’un système rack-scale doit relier un baseline de performance reproductible par lien aux preuves de couche physique, puis rejouer le même test après réparation. Le nombre de GPU installés, un ASN visible ou un préfixe joignable ne certifient pas cette capacité interne.

Le coût du défaut commence avant la panne. Un rack GB200 NVL72 concentre 72 GPU, 36 CPU, 18 compute trays et neuf switch trays. Le support de SoftBank situe sa consommation au-dessus de 100 kW. Derrière chaque accélérateur se trouvent des câbles passifs, des modules, des switches, un busbar, des power shelves et des collecteurs de refroidissement liquide. Si une liaison critique ne livre qu’une partie du débit attendu, les GPU restent installés, alimentés et comptabilisés, mais une portion du calcul ne peut pas être vendue dans les conditions prévues.

C’est précisément la différence que le cas de JANOG58 permet d’observer. Yasuhiro Uchida et Chaocheng Chang ont présenté, le 16 juillet 2026, la session SoftBank Rack-Scale GPUサーバーのNW設計と運用までの苦悩. La page consacrée au contrôle NCCL réunit quatre observations: toutes les liaisons ont été testées; l’une d’elles n’atteignait qu’une fraction du niveau normal; sa LED restait Green; son Link Status était UP et sa puissance optique paraissait normale.

Le document ne dit pas « un tiers » et ne fournit aucun chiffre exact. Cette absence n’autorise pas une estimation. Elle fixe une frontière probante: le défaut était suffisamment important pour apparaître dans le test global, mais sa magnitude publique reste indéterminée.

La présentation finale compte 56 pages. Un preread séparé en compte neuf et porte, dans son lien officiel, le nom j56-lt4.pdf. Il traite surtout de switches refroidis par liquide, d’interfaces propriétaires de refroidissement et de normalisation. Il documente une dépendance matérielle utile, mais ce n’est pas le journal abrégé de l’anomalie. Il ne faut pas y chercher des compteurs manquants ou une réparation non publiée.

L’architecture explique ensuite pourquoi les contrôles habituels ont pu être corrects sans être suffisants. NVIDIA décrit le même format de référence: 18 compute trays, neuf switch trays, 72 GPU, 36 CPU, avec un fond de panier de câbles passifs, l’alimentation par busbar et les manifolds de refroidissement liquide. Les déclarations de NVIDIA corroborent la forme du produit, pas le comportement du lien observé par SoftBank.

SoftBank sépare aussi son réseau externe en trois fabrics. Le Compute Fabric porte le trafic scale-out des GPU. Le Converged Fabric porte le front-end, le stockage et le bootstrap NCCL. L’OOB Fabric porte l’administration des switches et des serveurs, la supervision du site et la gestion NVSwitch. Cette séparation attribue des fonctions; elle n’élimine pas les dépendances physiques ou les processus communs.

La partie OOB donne un exemple concret. La communication par le port de management vers les leaf switches peut devenir un point de défaillance unique. Une reachability des loopbacks à travers l’underlay du Compute Fabric peut améliorer l’accès opérationnel sans câbler chaque petit port. Les auteurs précisent toutefois que cette solution ne remplace pas l’OOB. Le chemin utilisé pour réparer le fabric de production ne peut pas dépendre exclusivement du fabric qu’il doit réparer.

La même discipline s’applique au lien lent. Une LED verte indique que le circuit d’état voit la condition pour laquelle il a été conçu. Link Status UP indique que l’interface a atteint son état administratif ou protocolaire. Une puissance optique normale indique que la réception lumineuse n’a pas franchi une limite d’alarme. Aucun de ces constats ne promet une marge de correction suffisante, un comportement sain de chaque lane ou le débit end-to-end requis par un collectif NCCL.

Il serait donc faux de conclure que ces signaux ne servent à rien. Ils prouvent la présence et certaines conditions locales. Le cas prouve qu’ils ne suffisent pas à la réception d’un service dont la valeur économique dépend du débit collectif.

Le test NCCL sur toutes les liaisons pose une question plus proche de l’usage. Un workload collectif est limité par la partie lente ou dégradée du graphe de communication, et non par l’état moyen des ports. Une liaison nominalement saine peut ainsi immobiliser une capacité de calcul bien plus coûteuse qu’elle. La valeur perdue n’est pas nécessairement une panne franche: c’est l’écart entre capacité installée et capacité utilisable.

Le support de SoftBank ouvre ensuite cinq surfaces de diagnostic: switch, optics, NIC, fibre et contamination d’un connector. Cette liste ne désigne pas le coupable. Elle décrit une chaîne de dépendances qui traverse plusieurs équipes et contrats. Une erreur peut se trouver à l’émission, à la réception, sur une lane, dans le module, le connector ou le câble, alors que le symptôme visible reste un débit applicatif réduit.

Les pages suivantes expliquent le pre-FEC BER, le post-FEC BER et les histogrammes FEC. Elles montrent des profils normaux et anormaux, ainsi qu’un remplacement d’optics dans un schéma pédagogique. Ces éléments ne constituent pas la télémétrie de l’événement. Le support ne dit pas que le lien a produit les valeurs affichées, atteint les bins montrés ou retrouvé son débit après le remplacement d’un module.

Cette distinction sépare diagnostic, intervention et restauration. Le BER peut révéler des erreurs avant correction; la FEC peut montrer la marge consommée par la correction. Le remplacement contrôlé d’un composant peut tester une hypothèse. Seule la répétition du test qui avait détecté le problème peut montrer que le débit utile est revenu.

Or le dossier public ne fournit ni benchmark avant/après, ni composant causal, ni chronologie complète de réparation. On ne peut donc pas écrire que « l’optics a été remplacée et le lien réparé ». On peut écrire que l’équipe a découvert un angle mort de sa réception et a proposé des indicateurs physiques plus proches du mécanisme.

La conclusion opérationnelle du deck est explicite: Link UP = OK est insuffisant. SoftBank propose de mieux comprendre BER et FEC, de collecter et analyser chaque semaine et chaque mois les logs d’interface et d’optics, et de passer d’une détection centrée sur interface down à la recherche de signes de dégradation.

Il s’agit d’un projet de monitoring, pas d’un résultat prédictif. Aucun seuil d’alerte, taux de faux positif, incident détecté à l’avance ou gain de disponibilité n’est publié. Une tendance mensuelle peut repérer une dérive lente et masquer une perturbation brève. Sa valeur dépend du baseline propre au lien, de la conservation des changements et de l’autorité qui déclenche une intervention.

La granularité commerciale change encore le risque. Le support compare des services fournis au niveau du rack, du tray et du GPU. Il conclut que SoftBank offre actuellement des unités rack et tray après avoir pesé les compromis. Le service par GPU reste une option étudiée, pas l’offre actuelle déclarée.

Au niveau du rack, la séparation est plus simple pour un client, mais celui-ci hérite de dépendances communes: Compute Fabric, CDU, NVSwitch, compute tray et busbar. Au niveau du tray, l’accès devient plus fin mais exige un partitionnement NVLink. Le processus de management NVSwitch est commun dans le rack; le deck le qualifie de point de défaillance unique et associe un SLA plus élevé à une redondance au niveau rack ou scalable unit.

Ces choix attribuent le pouvoir. SoftBank contrôle la qualification, l’admission des workloads, le monitoring et la décision de restauration sur la plateforme qu’il exploite. NVIDIA et les fournisseurs de switch, NIC et optics contrôlent le design de référence, le firmware, les diagnostics privilégiés, les listes de qualification et les remèdes de support. L’équipe facility contrôle l’électricité, le refroidissement liquide et l’accès physique.

JANOG contrôle la publication de la session. Ce rôle est légitime, mais il ne lui donne aucun mandat pour certifier une liaison de production. Une conférence rend une expérience inspectable; elle ne devient ni l’opérateur, ni le client, ni l’autorité de réception.

La facture suit ces frontières. SoftBank finance câblage dense, optics, switches, pièces de rechange, laboratoire représentatif, puissance électrique, refroidissement et travail de diagnostic entre fournisseurs. Le tenant paie par des jobs retardés et des accélérateurs inactifs lorsqu’un lien nominalement accepté sous-performe. Un acheteur plus petit supporte proportionnellement davantage le coût d’un rack de réserve, d’un lab et de compétences spécialisées, ce qui renforce sa dépendance envers l’intégrateur.

SoftBank a déclaré en décembre 2025 que sa plateforme utilisant 1 224 GPU Blackwell avait commencé à fonctionner le 22 décembre, et qu’une extension au-delà de 4 000 était prévue. Le premier chiffre est une déclaration de déploiement; le second est un projet. Aucun ne mesure combien de liens satisfont un baseline d’acceptation à un instant donné.

Il ne faut pas non plus transférer le résultat d’un autre système. TOP500 décrit CHIE-4 comme un système DGX B200 avec InfiniBand NDR400. Son classement appartient à ce système, pas au GB200 NVL72 examiné à JANOG58.

Un meilleur régime de réception commencerait par l’identité de la topologie. Pour chaque lien requis, le service owner conserverait la distribution NCCL attendue, ou un autre baseline portable, avec le link state, la puissance optique, les compteurs par lane, le pre/post-FEC BER et l’histogramme FEC. Module, fibre, extrémités switch/NIC, firmware, workload et horodatage feraient partie du même dossier.

Lorsqu’un lien s’écarte de sa distribution, un seul élément borné serait changé à la fois. Les compteurs avant/après seraient conservés. Puis le test complet, identique à celui qui avait révélé le défaut, serait rejoué. Une tendance, une alerte, un ticket, un échange de composant et une restauration vérifiée ne seraient pas confondus dans un seul statut « fermé ».

Le client n’a pas nécessairement besoin de tous les compteurs propriétaires. Mais l’opérateur doit pouvoir prouver que le lien a atteint le débit déclaré à la réception et qu’il a retrouvé la même distribution après intervention. Sinon, le fournisseur du diagnostic contrôle aussi la preuve de sortie.

La visibilité externe reste un autre plan. Des préfixes de management et de clients peuvent rester joignables tandis que le chemin collectif interne sous-performe. Un ASN et BGP établissent une identité de routage et une reachability vers la périphérie; ils ne certifient pas le fabric GPU derrière le préfixe. Ils ne donnent pas non plus à un registre, une organisation de standards ou une conférence l’autorité de déclarer le rack apte au service.

La leçon de JANOG58 n’est donc ni « remplaçons l’état par BER », ni « ajoutons des compteurs ». Il faut relier l’état nominal, les preuves physiques et la performance de workload dans une chaîne que la réparation peut rejouer. La réception doit prouver un débit, pas une couleur.

Sources