Résumé

  • Oracle décrit une topologie Clos à trois niveaux supportant jusqu'à 131 072 GPU, avec des paliers de latence documentés d'environ 2, 5 et 8 microsecondes.
  • Sa propre documentation de création de cluster précise que les instances sont provisionnées « sous réserve de la capacité hôte » dans le réseau RDMA, et recommande une API de rapport de capacité avant toute création.
  • Les quotas par défaut limitent une location à 15 réseaux de cluster et 500 instances par pool : l'échelle annoncée n'est pas la configuration par défaut.

Un chiffre de capacité annoncé et un chiffre de capacité planifiable ne se mesurent pas avec la même unité. Chez Oracle, la première unité est architecturale et publiée ; la seconde dépend de bâtiments, de câbles, de commutateurs et de quotas.

La publication d'architecture d'Oracle décrit un réseau de cluster « zettascale » comme une topologie Clos à trois niveaux qui prend en charge jusqu'à 131 072 GPU, avec une connectivité non bloquante de 400 Gbps par GPU et une latence descendant jusqu'à 2 microsecondes. La même publication détaille le découpage : le premier niveau de commutateurs dessert jusqu'à 256 GPU avec une latence unidirectionnelle d'environ 2 µs, le deuxième jusqu'à 2 048 GPU à environ 5 µs, et le troisième jusqu'à 131 072 GPU à environ 8 µs (Oracle, architecture des superclusters OCI).

Cette troisième marche est le cœur du sujet. Toute charge d'entraînement qui franchit un palier de la topologie change de profil de latence, et une grappe de 131 072 GPU n'est pas 512 fois plus rapide qu'une grappe de 256 : elle est plus grande, avec une latence inter-nœuds supérieure d'environ 8 µs au lieu de 2 µs. Pour un entraînement synchrone, ce délai s'ajoute à chaque synchronisation collective, et la taille utile d'une tâche est donc bornée par la topologie autant que par le nombre d'accélérateurs (Oracle, First Principles: Zettascale OCI Superclusters).

La documentation opérationnelle d'Oracle fixe ensuite une seconde limite, plus prosaïque. Pour créer un réseau de cluster, « les instances sont provisionnées jusqu'à ce que le nombre requis d'instances dans le pool soit lancé, sous réserve de la capacité hôte pour les nœuds du réseau RDMA du cluster », et Oracle recommande d'utiliser l'opération CreateComputeCapacityReport pour vérifier la disponibilité d'une forme avant de créer le réseau (Oracle, création d'un réseau de cluster). La même réserve est répétée à l'agrandissement (Oracle, redimensionnement d'un réseau de cluster).

Autrement dit, le plafond annoncé est une propriété du tissu ; le plafond effectif est une propriété du parc. Oracle documente par ailleurs que les réseaux de cluster ne sont pris en charge que dans certaines régions et certains domaines de disponibilité, sur du matériel compatible, et que créer plusieurs instances HPC ou GPU nécessite « typiquement » une augmentation de limite de service (Oracle, réseaux de cluster avec pools d'instances).

Les valeurs par défaut publiées vont dans le même sens. Le tableau des limites de service d'OCI indique 15 réseaux de cluster par location et 500 instances par pool d'instances, avec un renvoi à une demande pour les valeurs supérieures (Oracle, limites par service). Ce ne sont pas des plafonds architecturaux — ils sont relevables — mais ce sont les valeurs qu'une organisation obtient sans négocier.

Il faut ici séparer ce qui est documenté de ce qui est mesuré. Oracle publie une architecture et des règles de provisionnement ; l'entreprise ne publie pas, à notre connaissance, le plus grand cluster effectivement livré et simultanément planifiable à une date donnée. Le chiffre de 32 768 GPU (4 096 nœuds à 8 GPU) d'un guide de solution Oracle illustre d'ailleurs que le « maximum » dépend de la génération d'accélérateurs et de la date du document (Oracle, déployer un cluster GPU bare metal).

Les résultats du trimestre donnent la mesure agrégée, pas la granularité par cluster. Oracle a déclaré 850 mégawatts de capacité de centre de données supplémentaires livrés aux clients au cours du trimestre clos le 31 août 2026, et plus de 300 000 GPU livrés à des clients AI Cloud depuis la fin du trimestre précédent (Oracle, résultats du T1 FY27). Ces chiffres décrivent un volume réparti sur des milliers de clients et de configurations ; ils ne disent pas quelle grappe unique a été mise sous tension.

La conclusion utile pour un acheteur n'est donc pas que l'échelle annoncée serait fausse. Elle est que l'échelle annoncée et l'échelle octroyée sont deux grandeurs différentes, que la seconde est conditionnée par la capacité hôte d'un tissu RDMA physiquement limité — Oracle plafonne la distance câble entre un GPU et le premier commutateur à 40 mètres — et qu'un acheteur qui dimensionne un plan d'entraînement sur le chiffre public peut découvrir que la contrainte se trouve dans une demande de quota et une vérification de capacité, pas dans une carte produit.

Sources