English 
简体中文 
繁體中文 
Русский 
Español 
Deutsch 
Français 
Português 
Italiano 
Türkçe 
Polski 
Nederlands 
日本語 
한국어 
Bahasa Indonesia 
Bahasa Melayu 
العربية 
हिन्दी 
Tiếng Việt 
ภาษาไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی Fiabilité des liaisons et surveillance dans les fabrics IA
Un job d’entraînement est un calcul synchrone réparti sur des milliers de GPU : chaque opération collective attend la liaison la plus lente. Un seul transceiver instable ne ralentit pas un serveur d’une fraction — il bloque tout le job, et s’il tombe complètement en panne, le job redémarre depuis le dernier checkpoint. L’optique cesse donc d’être un composant pour devenir un budget de fiabilité. Cette page couvre l’arithmétique des pannes, les métriques qui prédisent les problèmes, la façon dont les fabrics surveillent et isolent les mauvaises liaisons, et les pratiques opérationnelles qui maintiennent le taux de pannes bas.
Pourquoi une seule liaison compte
| Événement | Effet sur un job d’entraînement |
|---|---|
| Flap de liaison (secondes) | les opérations collectives expirent ou réessaient ; le temps de step s’envole ; avec NCCL/RCCL, un blocage assez long interrompt le job |
| Liaison à vitesse/largeur réduite | chaque all-reduce est cadencé par elle ; le débit de tout le cluster tombe à la part de cette liaison |
| TEB pré-FEC élevé, aucune erreur non corrigible | rien encore — mais la marge a disparu ; au prochain après-midi chaud, elle flappe |
| Erreurs FEC non corrigibles | perte de paquets → tempêtes de retransmission RDMA → blocage |
| Panne franche | redémarrage du job depuis le checkpoint : de quelques minutes à une heure de calcul perdu sur tout le cluster |
Le coût d’un redémarrage depuis un checkpoint sur un job de mille GPU se mesure en heures-GPU ; c’est ce chiffre qu’il faut comparer au prix d’optiques et d’une QA de meilleure qualité.
Arithmétique des pannes
La fiabilité d’un transceiver s’exprime en FIT (pannes par 10⁹ heures-dispositif) ou en MTBF.
| Hypothèse | Valeur |
|---|---|
| Extrémités optiques dans le fabric | 4 000 (un cluster à deux niveaux de 1 024 GPU) |
| FIT par extrémité (optiques 400G matures, bien refroidies) | 200–500 |
| Pannes franches attendues par mois | 4 000 × 350 × 10⁻⁹ × 720 h ≈ 1 |
| Taux de flap de liaison observé en pratique | 5–20 × plus élevé que les pannes franches — saleté, marge limite, thermique, firmware |
Les pannes franches sont donc rares et prévisibles ; ce sont les flaps et les liaisons dégradées qui dominent, et ils sont en grande partie évitables — c’est pourquoi la surveillance et la QA sont rentables.
Métriques qui prédisent les problèmes
| Métrique | Source | Sain | Agir |
|---|---|---|---|
| TEB pré-FEC par voie | VDM CMIS ; compteurs FEC de l’hôte | < 10⁻⁷ | > 10⁻⁶ en hausse ; > 10⁻⁵ planifier le remplacement |
| Mots de code FEC non corrigibles | hôte | 0 | tout incrément = incident |
| Erreurs de symbole par voie | hôte (Ethernet) / perfquery (IB) | équilibrées, proches de zéro | une voie qui domine |
| Puissance Rx par voie vs référence | DDM | à moins de 1 dB du premier jour, voies à moins de 2 dB entre elles | −2 dB par rapport à la référence |
| Tendance du bias Tx | DDM | stable | +15–20 % par rapport à la référence (Bias Tx et vieillissement) |
| Température du module | DDM | < 60 °C | > 65 °C ou +10 °C par rapport aux voisins |
| eSNR (CMIS) | VDM | > 18–20 dB | en baisse sur une voie |
| Flaps de liaison par port | journaux du commutateur, fabric manager | 0 | n’importe lequel |
| Vitesse/largeur négociée | commutateur / ibstat | complète | en dessous du nominal |
Définitions et formats : VDM et métriques FEC, Surveillance.
Architecture de surveillance
| Fabric | Collecte | Outils |
|---|---|---|
| InfiniBand | le gestionnaire de sous-réseau/fabric interroge les compteurs de chaque port et l’EEPROM/DDM du câble | gestionnaires de classe UFM, ibdiagnet, mlxlink -m |
| Ethernet (RoCE) | streaming gNMI/OpenConfig de l’état du transceiver et du FEC toutes les 10–60 s ; repli sur SNMP | gnmic → Prometheus/Grafana, télémétrie constructeur (Lecture du DDM avec des outils) |
| Côté hôte | compteurs NIC : retransmissions, CNP, paquets hors séquence ; journaux NCCL/RCCL pour les timeouts | node exporters |
| Côté job | variance du temps de step, détection des traînards | métriques du framework d’entraînement |
Corrélez les trois : un pic de temps de step à 14 h 05, une excursion du TEB pré-FEC sur le leaf 7 voie 3 à 14 h 04 et un pic de température de module dans la baie 12 forment un diagnostic complet.
Isolement et remédiation
- Désactivation automatique du port / contournement de route quand les erreurs non corrigibles ou les flaps franchissent un seuil — les fabric managers et les NOS prennent en charge des politiques d’erreur de liaison ; le routage adaptatif détourne entre-temps les flux autour d’une liaison dégradée.
- Videz le nœud si son port NIC est en cause ; planifiez le job autour de lui.
- Testez le module sur l’établi : identité, DDM par voie comparé à sa référence du premier jour, sommes de contrôle, version de firmware (Check transceiver, DDM).
- Nettoyez et réinspectez le MPO des deux côtés avant d’incriminer le module — la saleté est la cause la plus fréquente (Incompatibilités de couche physique).
- Échangez et observez : si les erreurs suivent le module, faites un RMA ; si elles restent sur le port, examinez la cage, la fibre et l’extrémité distante.
Pratiques qui réduisent le taux de pannes
| Pratique | Effet |
|---|---|
| Contrôle à réception et rodage (24–72 h en charge et en température) | élimine la mortalité infantile avant qu’elle n’atteigne un job |
| Référence de DDM par voie dès le premier jour | transforme une précision absolue (±3 dB) en écarts précis |
| Garder les modules < 60 °C — flux d’air, OSFP à ailettes/plat correctement choisi, aucune admission bloquée | la durée de vie double tous les −10 °C |
| Nettoyer chaque connecteur à chaque accouplement ; capuchons sur les ports inutilisés | la plupart des flaps sont dus à la saleté |
| Firmware à jour pour les modules et les hôtes | corrige l’interopérabilité CMIS (Problèmes CMIS) |
| Optiques homogènes et validées par niveau | moins de surprises d’interopérabilité DSP hôte/module |
| Pièces de rechange rodées et référencées, 3–5 % | remplacement sans second incident |
| Revue de tendance hebdomadaire | remplacer les lasers vieillissants selon un calendrier, pas après une panne |
Où va la technologie
Des débits par voie plus élevés (200G/voie, 1,6T) resserrent encore les marges ; les optiques linéaires (LPO) et co-packagées suppriment le DSP et sa surveillance — reportant la visibilité du TEB vers l’hôte — tout en promettant moins de composants et moins de chaleur (Modulation et DSP, Transceivers dans les clusters IA). Quel que soit le module, la discipline reste la même : établir une référence, surveiller les écarts, agir sur les tendances.
Dans CodingBox
CodingBox est le maillon établi de cette boucle : lectures de contrôle à réception et de rodage, références par voie du premier jour stockées par numéro de série dans la code database, et lectures post-mortem des modules retirés — identité, firmware, sommes de contrôle et DDM comparés à leur propre historique — si bien que les décisions de RMA reposent sur des données plutôt que sur la dernière ligne de journal du port.