Resumen

  • Oracle documenta una red de clústeres de tres niveles que soporta hasta 131.072 GPU, pero la creación de la red está limitada por la capacidad física disponible en el nodo dentro del RDMA y por cuotas de tenencia muy por debajo de esa cifra.
  • La latencia no es uniforme: el primer nivel llega hasta 2 µs, el segundo a 5 µs y el tercero a 8 µs, de modo que un trabajo de entrenamiento que abarque todo el tejido paga la latencia del nivel más profundo.

Qué anuncia Oracle y qué documenta Oracle

La página de infraestructura de IA de Oracle presenta la computación zettascale como una capacidad de nube: clústeres que llegan a 131.072 GPU de NVIDIA con interconexión no bloqueante. En una entrada de blog de OCI, la arquitectura se describe con más detalle: la red de clústeres zettascale entrega 52 Pbps de ancho de banda no bloqueante a 400 Gbps por puerto y con latencia mínima de 2 microsegundos (blog de OCI sobre superclústeres zettascale). Esa misma publicación describe la topología: una red Clos de tres niveles que soporta hasta 131.072 GPU, con 400 Gbps de conectividad no bloqueante a cada GPU.

La documentación de OCI sobre redes de clústeres con grupos de instancias describe la arquitectura operativa real: grupos de instancias idénticas, de tipo HPC, GPU o bare metal optimizado, conectadas por una red RDMA de baja latencia "de hasta microsegundos de un solo dígito, comparable a los clústeres HPC locales" (documentación de OCI sobre redes de clústeres). Un clúster es un conjunto de máquinas bare metal físicamente próximas entre sí. No es una abstracción software.

La latencia por niveles y por qué importa

Si la red es un Clos de tres niveles, la latencia depende de cuántos niveles atraviesa una comunicación. Oracle describe la escalera: el primer nivel sirve hasta 256 GPU con 2 µs de latencia unidireccional; el segundo llega a 2.048 GPU con 5 µs; el tercero soporta hasta 131.072 GPU con 8 µs. Un trabajo que quepa en 256 GPU nunca toca el segundo nivel; uno que abarque las 131.072 paga la latencia del tercero en cada salto que cruce niveles.

Esto es una restricción de física y topología, no de marketing. Cuanto más grande es el trabajo de entrenamiento distribuido, más sincronizaciones cruzan niveles y más se acumula la latencia. Oracle dice que usa control de congestión en lugar de control de flujo por prioridad (PFC) como mecanismo principal, para evitar el bloqueo de red en entornos multiinquilino y multicarga de trabajo. También limita la distancia de cable entre una GPU y el conmutador de primer salto a 40 metros como máximo. Esos detalles no aparecen en el anuncio del tamaño máximo; describen el coste operativo de operar un clúster a gran escala.

El techo que fija la capacidad del host

La documentación de OCI sobre creación de redes de clústeres es explícita: "Las instancias se aprovisionan hasta que se inicia el número requerido de instancias en el grupo, sujeto a la capacidad del host para los nodos de la red RDMA del clúster" (creación de una red de clústeres). La misma página indica que para determinar si hay capacidad disponible para una forma concreta antes de crear una red de clústeres, el usuario debe usar la operación CreateComputeCapacityReport. Es decir, Oracle publica una API específica para comprobar si el clúster solicitado cabe físicamente en el tejido en ese momento.

El lenguaje de escalado es idéntico: "Cuando se aumenta el tamaño, las instancias se aprovisionan hasta que se inicia el número requerido de instancias en el grupo de instancias, sujeto a la capacidad del host para los nodos de la red RDMA del clúster" (redimensionar una red de clústeres). No hay una cifra de máximo por clúster publicada; hay una descripción de un proceso que se detiene cuando el hardware físico se agota.

Las cuotas de tenencia

El tercer techo es administrativo. La página de límites de servicio de OCI muestra un valor predeterminado de 15 redes de clústeres por tenencia para Oracle Universal Credits, y 500 instancias por grupo de instancias (límites por servicio). Aumentar esos valores requiere una solicitud. Las cuotas no son el límite arquitectónico, pero son el límite que un cliente encuentra de entrada antes de pedir un aumento.

Un clúster de 131.072 GPU con 8 GPU por nodo implica 16.384 máquinas bare metal. Ese despliegue está muy por encima de las cuotas predeterminadas y requiere acuerdos de capacidad específicos con Oracle. El anuncio describe una capacidad que Oracle puede construir; la documentación describe lo que un cliente puede aprovisionar por defecto.

Qué evidencia falsificaría esta conclusión

La pregunta no es si Oracle puede construir un clúster de 131.072 GPU, sino si un cliente puede programar uno. Lo que cerraría esa brecha sería la publicación de una especificación de clúster entregado con cifras verificables de latencia medida entre las GPU más alejadas de un mismo trabajo, una confirmación independiente de que un cliente opera un solo trabajo sobre el nivel más profundo del tejido, o la divulgación de cuántas de las 850 MW de capacidad de IA entregadas en el trimestre que terminó el 31 de agosto de 2026 corresponden a clústeres de nivel tres (resultados del primer trimestre del año fiscal 2027). Mientras Oracle no publique el máximo de clúster entregado por cliente en lugar de la capacidad máxima construible, la distancia entre el techo anunciado y el programable sigue siendo una cuestión abierta.

Fuentes