Broadcom Tomahawk 6 double la bande passante. Les réseaux d’IA restent confrontés à des difficultés de mise à l’échelle

Broadcom Tomahawk 6 a doublé la capacité de commutation Ethernet sur une seule puce pour atteindre 102,4 térabits par seconde, mais cette avancée ne double pas automatiquement la capacité utile d’un cluster d’IA. Des connexions plus rapides peuvent absorber la bande passante supplémentaire avant que les opérateurs ne raccordent davantage d’accélérateurs. La pression qui en résulte dépasse les commutateurs et touche les configurations des bâtiments, les logiciels et les calendriers de déploiement.

Une tribune publiée le 30 octobre dans Data Center Dynamics a remis cette tension au premier plan. Son auteur, Omar Hassen, cofondateur d’Eridu, estime que le réseau doit structurer les installations d’IA dès le départ. Son avertissement mérite attention, tout comme l’examen du calendrier et des hypothèses qui le sous-tendent.

Broadcom et Nvidia répondent déjà avec une commutation plus rapide et une intégration optique. Les travaux d’ingénierie de Meta ajoutent un autre élément à considérer : la bande passante installée et la bande passante réellement exploitable sont deux choses différentes. Le conflit central oppose l’augmentation des besoins de communication à la capacité du réseau à offrir des performances applicatives prévisibles.

Broadcom Tomahawk 6 change les chiffres, pas toute l’équation

La dernière hausse de bande passante est réelle, mais elle ne prouve pas que la contrainte réseau a disparu.

Broadcom a annoncé l’expédition de Tomahawk 6 le 3 juin 2025. Sa capacité annoncée était de 102,4 térabits par seconde, une mesure du volume global de données transitant par la puce de commutation. L’entreprise a également décrit des fonctions de routage et de connectivité destinées aux infrastructures d’IA.

Cette annonce importe dans l’évaluation du récent argument du mur réseau. Hassen présente l’insuffisance de la bande passante des commutateurs et de la connectivité comme des contraintes pour une infrastructure d’IA productive. Il préconise une connectivité accrue et des réseaux plus plats, c’est-à-dire des conceptions comptant moins de couches de commutation.

L’article constitue l’analyse d’un dirigeant de fournisseur, plutôt qu’une mesure indépendante de l’ensemble du marché. Cette distinction n’invalide pas sa thèse. Elle signifie que les lecteurs doivent distinguer l’argument architectural des affirmations sur les progrès du secteur.

Le calendrier exige une attention particulière. Le lancement de Tomahawk 5 par Broadcom remonte au 16 août 2022, lorsque l’entreprise a annoncé une capacité de commutation de 51,2 térabits. L’annonce suivante a eu lieu en juin 2025, moins de trois ans plus tard.

Ces dates ne permettent pas de considérer l’intervalle entre les annonces de puces comme étant de près de quatre ans. Elles ne permettent pas non plus d’établir à quel moment des systèmes complets sont devenus largement disponibles ou sont entrés en production. L’expédition du silicium, la qualification des équipements et le déploiement opérationnel représentent des étapes distinctes.

Cette distinction modifie la question que les acheteurs devraient poser. Il ne s’agit pas seulement de savoir si les fabricants de commutateurs doublent leur capacité. Il s’agit de déterminer si les systèmes déployables offrent une connectivité utile suffisante aux vitesses requises par la charge de travail prévue.

Une puce plus rapide crée des options de conception. Les opérateurs peuvent répartir sa capacité entre des connexions plus rapides, davantage de connexions ou une combinaison des deux. Le packaging, la conception des équipements et les configurations prises en charge déterminent lesquelles de ces options deviennent des produits concrets.

Par conséquent, une étape importante en matière de bande passante devrait ouvrir une évaluation architecturale plutôt que la conclure. Les acheteurs doivent relier les spécifications de la puce aux équipements qu’ils peuvent se procurer. Ils doivent ensuite relier ces équipements au comportement des applications.

La même prudence s’applique aux affirmations selon lesquelles le réseau aurait irrémédiablement pris du retard sur le calcul. Il n’existe aucun ratio universel décrivant tous les modèles, clusters ou déploiements. Certaines applications échangent fréquemment des données ; d’autres conservent davantage de travail en local.

La conclusion défendable est plus limitée et plus utile. La capacité de commutation a progressé, tandis que la capacité seule demeure une description incomplète de l’infrastructure d’IA. La pression apparaît lorsque les besoins de communication de la charge de travail dépassent la capacité pratique du réseau à les satisfaire.

Des ports plus rapides peuvent absorber tout le gain de bande passante

Un commutateur peut devenir plus rapide sans raccorder davantage d’accélérateurs à la vitesse requise.

La distinction cruciale se situe entre la bande passante totale et le radix, soit le nombre de connexions indépendantes qu’un commutateur prend en charge à une vitesse donnée. Aucun de ces chiffres n’a de sens sans l’autre. Un nombre élevé de connexions à une vitesse inférieure ne décrit pas la même capacité que ce même nombre à une vitesse supérieure.

L’arithmétique explique pourquoi la mise à l’échelle de la bande passante des commutateurs peut décevoir les planificateurs d’infrastructures. Si la capacité globale double tandis que la bande passante requise par connexion double également, le nombre théorique de connexions reste inchangé. Il s’agit d’une relation conditionnelle, non d’une affirmation mesurée concernant tous les commutateurs commercialisés.

Cette relation importe, car les installations d’IA doivent répondre à la fois aux besoins de vitesse de communication et de taille des clusters. Répondre à une exigence peut consommer les ressources prévues pour l’autre. Les opérateurs ne peuvent pas supposer qu’une nouvelle génération de commutateurs développe les deux dimensions de manière égale.

Un connecteur physique ajoute une autre complication. Il ne correspond pas toujours à une connexion indépendante d’accélérateur. Les équipements peuvent combiner des canaux pour former des liaisons plus rapides ou diviser les connexions prises en charge au moyen de configurations breakout.

Les acheteurs ont donc besoin de connaître la configuration prise en charge, plutôt qu’un nombre de connecteurs mis en avant. Ils doivent également savoir combien de connexions desservent les accélérateurs et combien relient les commutateurs. La capacité répartie entre les couches de commutation ne peut pas simultanément desservir un point terminal.

Les spécifications de Tomahawk 6 de Broadcom illustrent pourquoi les détails de configuration importent. L’entreprise décrit un réseau à deux niveaux prenant en charge plus de 100 000 accélérateurs à 200 gigabits par seconde par liaison. Il s’agit d’une affirmation de conception du fournisseur liée à une vitesse de connexion donnée, et non d’une garantie universelle pour les clusters.

La précision sur la vitesse doit accompagner le chiffre d’échelle. La retirer rend les comparaisons trompeuses. Une conception prenant en charge une vaste population de points terminaux à une vitesse ne peut pas automatiquement prendre en charge la même population à une vitesse supérieure.

La même discipline s’applique aux couches de commutation. Ajouter une couche peut étendre un réseau, mais cela introduit également davantage d’équipements et de connexions. La pertinence de ce compromis dépend du trafic qui la traverse.

Un réseau plus vaste n’est pas nécessairement plus lent dans tous les sens utiles. Des chemins supplémentaires peuvent fournir de la capacité et de la résilience lorsque la conception et les logiciels les exploitent efficacement. De même, un nombre réduit de couches ne garantit pas de meilleures performances applicatives.

La contrainte pratique réside dans le modèle de communication que le réseau doit soutenir. Une conception peut bien gérer un trafic localisé tout en rencontrant des difficultés lorsque les applications communiquent entre des groupes éloignés. La bande passante globale peut masquer cette différence.

C’est pourquoi comparer les générations de commutateurs exige davantage que de vérifier si la capacité a doublé. Une comparaison pertinente maintient constants la vitesse des points terminaux, la charge de travail, les exigences de résilience et la topologie. La topologie désigne l’organisation des équipements et des liaisons.

Sans ces conditions, la mise à l’échelle de la bande passante des commutateurs peut sembler impressionnante tout en laissant le problème opérationnel largement inchangé. Avec elles, les acheteurs peuvent identifier quelle partie de la conception en bénéficie réellement.

La pression pèse sur les propriétaires de clusters avant les utilisateurs d’applications

Les limites du réseau deviennent un problème d’exploitation lorsque des capacités de calcul payées attendent les communications.

Considérons une tâche d’entraînement distribué, dans laquelle plusieurs accélérateurs coopèrent pour mettre à jour un modèle. Chaque accélérateur exécute une partie du calcul. À des points définis, les participants échangent des informations avant de poursuivre.

Une opération collective coordonne cet échange entre un groupe de processeurs. All-reduce, par exemple, combine les contributions et distribue le résultat combiné. Son achèvement dépend des communications requises par le groupe.

La conséquence importante est la coordination. Un accélérateur qui termine son travail local ne peut pas toujours avancer de façon indépendante. Des communications retardées peuvent prolonger le délai avant la reprise d’un calcul utile.

Cela ne signifie pas que le réseau explique chaque accélérateur inactif. La préparation des données, le comportement des logiciels, les limites de mémoire et la planification peuvent également restreindre les performances. Attribuer toute sous-utilisation au réseau masquerait le véritable diagnostic.

Pour le propriétaire d’un cluster, la question pertinente est de savoir quelle contrainte détermine l’achèvement de la tâche. Des commutateurs plus rapides ont une valeur limitée lorsqu’une autre ressource fixe le rythme. À l’inverse, des processeurs plus rapides offrent moins d’avantages lorsque la communication reste sur le chemin critique.

Cette situation met sous pression la planification de l’infrastructure. Les équipes achats peuvent acquérir accélérateurs et équipements réseau dans le cadre de processus distincts, mais l’application les expérimente conjointement. Un décalage devient visible pendant l’exécution de la charge de travail, après que les décisions d’équipement ont déjà limité les solutions disponibles.

La même relation apparaît dans l’inférence, le processus consistant à exécuter un modèle entraîné pour générer une sortie. Lorsqu’un modèle s’étend sur plusieurs accélérateurs, la communication devient une partie du traitement de la requête. Son importance dépend de la manière dont l’application répartit le travail.

Les modèles de mélange d’experts sélectionnent des composants spécialisés du modèle selon les entrées. Lorsque ces composants résident sur des appareils différents, l’acheminement du travail entre eux ajoute des besoins de communication. L’organisation du déploiement détermine quelle quantité de trafic traverse le réseau.

Une autre organisation sépare le prefill, qui traite une invite d’entrée, du decode, qui génère la sortie suivante. Le transfert de l’état d’attention intermédiaire du modèle entre ces étapes introduit un besoin de transfert. Ce compromis peut être avantageux, mais sa valeur dépend en partie du comportement du réseau.

Ces exemples expliquent pourquoi les goulots d’étranglement des réseaux d’IA doivent être évalués par charge de travail. Les résultats d’entraînement ne permettent pas automatiquement de prédire les performances d’inférence. Une configuration optimisée pour un modèle de communication peut se comporter différemment avec un autre.

Les utilisateurs d’applications rencontrent ces contraintes indirectement. Ils constatent des temps d’achèvement, une régularité du service et une capacité disponible, plutôt que des spécifications de commutateurs. Les acheteurs en entreprise ont donc besoin d’éléments de preuve sur le service qui reflètent leur utilisation attendue.

Les opérateurs de clusters font face à l’obligation la plus immédiate : identifier où la communication limite le travail utile, puis déterminer si des changements de matériel, de logiciel ou de placement peuvent y remédier. Augmenter partout la bande passante constitue un substitut coûteux à la compréhension de la contrainte.

Le changement de planification qui en résulte est concret. Les exigences réseau doivent être intégrées à la conception de la charge de travail et aux décisions d’installation avant que les achats ne figent l’architecture. Attendre l’apparition d’une congestion visible laisse moins d’options pratiques.

Davantage de capacité de commutation ne peut pas résoudre tous les problèmes de trafic

Un réseau peut disposer d’une capacité globale suffisante tout en acheminant le trafic par les mauvais chemins.

Imaginez un réseau disposant de plusieurs itinéraires possibles entre des appareils qui communiquent. Si des transferts intensifs se concentrent sur le même itinéraire, un autre peut rester sous-utilisé. Augmenter la bande passante totale installée ne garantit pas une répartition efficace du trafic.

C’est ici que les spécifications matérielles rencontrent le comportement du transport, c’est-à-dire les règles que les terminaux utilisent pour envoyer, acquitter et récupérer les données. Ces règles influencent l’efficacité avec laquelle une application exploite les chemins disponibles. Elles déterminent également ce qui se produit lorsque la congestion ou des pertes interrompent la communication.

Les travaux publiés par Meta sur le réseau d’entraînement distribué fournissent un exemple opérationnel. Ses ingénieurs ont décrit des défis de routage, la coordination avec les logiciels de communication et une planification tenant compte de la topologie du réseau. Leur expérience plaide pour considérer le réseau comme un système plutôt que comme un simple achat de commutateurs.

RoCE, ou accès direct à la mémoire distante sur Ethernet convergé, permet aux appareils d’accéder à de la mémoire distante via un réseau Ethernet. Le récit de Meta explique que l’exploitation de tels réseaux a nécessité des changements allant au-delà de la vitesse brute des liens. La leçon porte sur l’intégration, et non sur une approbation universelle d’une configuration donnée.

Le placement des tâches constitue une partie de cette intégration. Maintenir à proximité, dans le réseau, les appareils qui communiquent intensivement peut réduire le trafic sur les liens contraints. Les répartir autrement peut accroître la pression, même si le nombre total d’accélérateurs reste inchangé.

Les décisions de planification influencent donc la qualité apparente du matériel. Un benchmark utilisant un placement favorable peut produire des résultats qui disparaissent dans des conditions de production moins ordonnées. Les acheteurs devraient comprendre cette distinction avant de considérer les performances de benchmark comme un engagement de service.

La conception du transport MetaRoCE de Meta, publiée le 24 août 2026, prolonge le même débat. L’entreprise décrit le transfert d’une plus grande part de la gestion des chemins vers les terminaux réseau et la prise en charge de paquets arrivant dans le désordre. Elle indique avoir validé cette approche avec du matériel réseau AMD Pensando.

Il s’agit de résultats rapportés par l’entreprise, dans les conditions de test qu’elle indique. Ils n’établissent pas un comportement équivalent pour chaque accélérateur, adaptateur ou environnement de production. Leur importance tient au fait qu’un grand opérateur s’attaque aux limites du réseau par la conception du transport, parallèlement à l’infrastructure physique.

Broadcom, Nvidia et Meta ne devraient donc pas être réduits à une simple compétition sur la capacité des commutateurs. Leurs travaux couvrent différentes parties du système de communication. Les améliorations matérielles et logicielles peuvent se compléter.

Pour les acheteurs, cela complique les comparaisons entre fournisseurs, mais améliore les questions qu’ils peuvent poser. Les performances dépendent-elles d’un adaptateur spécifique ? La bibliothèque de communication exige-t-elle des réglages particuliers ? Comment le trafic est-il redistribué après la défaillance d’un lien ?

Ces questions relient les goulets d’étranglement des réseaux d’IA à la responsabilité opérationnelle. Quelqu’un doit maintenir la configuration qui produit le résultat promis. Une fonctionnalité de performance a une valeur pratique limitée si l’équipe d’exploitation ne peut ni l’observer ni la diagnostiquer.

L’implication plus large est que les performances applicatives ne peuvent pas être déduites de la seule capacité agrégée. Un routage efficace, des terminaux compatibles et le placement des charges de travail déterminent quelle part de cette capacité devient utile. Un silicium plus rapide crée de la marge ; le système décide avec quelle efficacité l’utiliser.

L’intégration optique répond aux enjeux d’énergie, tout en soulevant des questions opérationnelles

Réduire l’énergie consacrée aux communications est utile, mais les affirmations d’efficacité exigent un périmètre clairement défini.

Nvidia a annoncé des commutateurs réseau photoniques en mars 2025, dont les produits Ethernet Spectrum-X et InfiniBand Quantum-X. Son annonce plaçait l’intégration optique au centre de sa stratégie réseau. Broadcom a également décrit des options d’intégration optique pour Tomahawk 6.

L’optique co-packagée place les composants optiques à proximité de la puce du commutateur, au sein d’un boîtier intégré. Cette approche raccourcit une partie du trajet électrique emprunté avant que les signaux ne deviennent lumineux. Les fournisseurs la présentent comme un moyen d’améliorer l’efficacité des communications à haute vitesse.

Cela répond à une partie importante du problème, mais pas à l’ensemble. Une connexion optique plus efficace ne résout pas à elle seule un mauvais placement du trafic. Elle n’établit pas non plus qu’une installation complète consomme moins d’énergie pour une même production applicative.

Le périmètre de mesure compte. Une comparaison peut couvrir les composants optiques, les équipements réseau ou l’ensemble de l’installation informatique. Il s’agit d’affirmations différentes, qui devraient rester distinctes.

De même, une meilleure efficacité des communications ne se traduit pas automatiquement par une amélioration applicative équivalente. Le résultat dépend de la part du temps que l’application consacre à communiquer. Il dépend également de l’éventuelle domination d’une autre contrainte après l’amélioration des communications.

Il s’agit d’une relation générale de performance, et non d’un argument contre l’intégration optique. La suppression d’une contrainte peut en révéler une autre. Les acheteurs doivent savoir quelle amélioration subsiste lorsqu’elle est mesurée au niveau de l’application.

La conception opérationnelle soulève d’autres questions. Les équipements dotés de composants intégrés peuvent modifier les procédures de remplacement et la planification des pièces détachées. Les détails pertinents dépendent du système concerné ; les affirmations générales sur la maintenabilité exigent donc de la prudence.

Une équipe chargée des achats devrait déterminer quels composants les techniciens peuvent remplacer de façon indépendante. Elle devrait également comprendre la procédure permettant d’isoler une panne. Ces éléments influencent la manière dont une amélioration d’efficacité s’intègre dans un environnement d’exploitation.

Les comparaisons de fiabilité exigent une discipline similaire. Le comportement de défaillance d’un composant et la disponibilité d’un service sont liés, mais différents. Des chemins redondants et des logiciels de récupération peuvent préserver la progression de l’application même lorsque des composants individuels échouent.

Inversement, un composant très fiable ne garantit pas un service ininterrompu. Des erreurs logicielles, des erreurs de configuration et des défaillances ailleurs dans le système peuvent toujours affecter l’application. L’évaluation de la conception complète évite qu’un indicateur de fiabilité étroit ne devienne une affirmation de service non étayée.

L’angle sceptique le plus solide concerne donc le périmètre. Une commutation plus rapide et l’intégration optique résolvent des problèmes d’ingénierie identifiables. Les preuves doivent montrer comment ces solutions affectent la charge de travail, l’installation et le processus de maintenance achetés.

Cette norme s’applique également aux prédictions d’un mur réseau permanent. Les contraintes peuvent se déplacer à mesure que changent les applications, les logiciels de transport et les équipements. La question utile est de savoir quelle limitation régira le prochain déploiement, non si une technologie l’emportera indéfiniment.

Pour les opérateurs, Broadcom Tomahawk 6 s’inscrit dans cette évaluation comme une avancée matérielle concrète. Sa valeur dépend de la conception qu’il permet et des résultats que cette conception produit.

Surveiller les systèmes déployables, les résultats des charges de travail et le comportement de récupération

Les prochaines preuves devraient relier les capacités des produits à des résultats opérationnels reproductibles.

Au cours des prochains mois, le premier signal sera la disponibilité de systèmes complets dans des configurations précisées. Les annonces de puces établissent le progrès technique, mais les acheteurs ont besoin d’équipements qu’ils peuvent qualifier, installer et prendre en charge. Le lien entre ces jalons mérite une présentation explicite.

Pour les systèmes Broadcom Tomahawk 6, des informations utiles identifieraient les vitesses de terminaux prises en charge, les nombres de connexions et les topologies réseau. Elles distingueraient les configurations disponibles des options prévues. Elles expliqueraient également quelles fonctionnalités logicielles sont prêtes pour une utilisation opérationnelle.

De telles preuves renforceraient l’argument selon lequel une commutation plus récente peut atténuer les contraintes actuelles. Des écarts persistants entre les capacités annoncées et les équipements qualifiés l’affaibliraient. Aucun de ces résultats ne suppose que tous les opérateurs suivent le même calendrier de déploiement.

Le signal suivant est la performance des charges de travail dans des conditions comparables. Une comparaison utile maintient constantes l’application et la configuration des accélérateurs, tout en identifiant les changements réseau. Sinon, les améliorations peuvent provenir de changements non liés dans le logiciel ou le matériel informatique.

Les comparaisons d’entraînement devraient rapporter le comportement d’achèvement de l’application parallèlement aux mesures de communication. Les comparaisons d’inférence devraient décrire les caractéristiques des requêtes et les conditions de service. Un résultat dépourvu de son contexte de charge de travail fournit des indications d’achat limitées.

La latence de queue, c’est-à-dire les temps d’achèvement inhabituellement longs, mérite également de l’attention. Les performances moyennes peuvent masquer des retards qui affectent le travail coordonné ou l’expérience utilisateur. Les acheteurs doivent savoir si les améliorations restent cohérentes sous une demande soutenue.

Des résultats solides montreraient qu’une capacité accrue ou un transport amélioré réduit une contrainte applicative significative. Des résultats faibles montreraient peu de bénéfice une fois des conditions d’exploitation réalistes intégrées à la comparaison. L’un comme l’autre est plus instructif qu’un nouveau record de bande passante isolé.

Le dernier signal est le comportement de récupération face aux pannes et à une demande mixte. Un réseau devrait être évalué lorsque des liens tombent en panne, que le trafic se déplace ou que plusieurs applications se disputent les ressources. Ces conditions révèlent si l’architecture préserve un travail utile au-delà d’une démonstration soigneusement agencée.

Pour un transport piloté par les terminaux, les preuves pertinentes comprennent le matériel compatible et le comportement dans différentes topologies réseau. Pour l’intégration optique, elles comprennent les procédures de maintenance et la continuité du service lors de problèmes de composants. Il s’agit d’extensions pratiques des affirmations techniques, et non de préoccupations distinctes.

Des résultats de récupération reproductibles renforceraient la confiance dans des déploiements plus vastes. Un dépannage difficile ou un comportement instable nuancerait les bénéfices apparents d’une capacité accrue. Le résultat compte, car les opérateurs doivent prendre en charge le système tout au long de sa durée de vie.

Les équipes d’ingénierie devraient conserver les hypothèses qui sous-tendent chaque comparaison, notamment le placement des charges de travail, la configuration des équipements et les versions logicielles. Une base de connaissances d’ingénierie consultable peut aider à maintenir ces décisions disponibles lorsque les conditions de déploiement évoluent.

Avant d’approuver le prochain cluster, demandez aux fournisseurs de démontrer l’application que vous envisagez d’exécuter dans les conditions d’exploitation prévues. Exigez la configuration de connexion prise en charge, les hypothèses concernant le logiciel de communication et le comportement après une panne. Conservez ces conclusions avec la décision d’achat, afin que les équipes ultérieures puissent distinguer une limite de conception d’un problème de configuration. Broadcom Tomahawk 6 établit que la capacité des commutateurs progresse ; vos critères d’acceptation devraient établir si cette avancée améliore le travail utile. Commencez par les besoins de communication de la charge de travail, comparez des systèmes complets à ces besoins et faites de la préparation au déploiement une partie de l’évaluation des performances. Quel réseau peut soutenir votre application lorsque l’installation est sollicitée, imparfaite et exploitée au-delà du benchmark ?