Resumo

O número que domina a discussão pública sobre a nuvem Oracle é 131.072. É o teto de GPUs que a empresa associa ao seu cluster zettascale, e é um número de engenharia, não de marketing: descreve quantos aceleradores a malha de rede foi projetada para endereçar em uma única entidade de cluster. O problema começa quando esse número é lido como uma promessa de capacidade disponível.

A documentação oficial da Oracle descreve algo mais estreito, e mais útil: um cluster pode ser anunciado em um tamanho, mas a quantidade de instâncias GPU que um cliente consegue provisionar dentro dele depende de onde há capacidade de host disponível na rede RDMA, e essa disponibilidade é verificável antes da implantação.

Essa distinção entre teto anunciado e teto agendável é o que separa uma métrica de arquitetura de uma expectativa de entrega. A Oracle não esconde isso. Sua documentação de limites de serviço expõe cotas padrão de tenancy que restringem recursos de computação de alto desempenho e de rede, e suas páginas de rede de cluster descrevem uma topologia de três camadas de latência. Juntas, essas duas fontes descrevem as restrições reais sob as quais o número de 131.072 se torna operacional.

O que a malha realmente promete

A rede de cluster da OCI é construída em torno de uma hierarquia de latência em vez de uma malha plana. A documentação de computação de alto desempenho da Oracle descreve três camadas de comunicação, da mais próxima à mais distante: um domínio de baixa latência dentro do qual os nós se comunicam com o menor atraso, uma camada intermediária de conectividade, e uma camada externa mais ampla que conecta o cluster a recursos fora dele (https://docs.oracle.com/en-us/iaas/Content/Compute/References/high-performance-compute.htm). O significado prático é direto: dois jobs agendados no mesmo cluster podem experimentar latências diferentes entre GPUs dependendo de quais nós recebem, e a diferença vem da posição na topologia, não da carga.

Isso importa para cargas de trabalho de treinamento de modelos grandes, onde a comunicação coletiva entre milhares de GPUs domina o tempo de execução. Um cluster que entrega 131.072 GPUs distribuídas por três camadas de latência não é a mesma máquina que um cluster que entrega 131.072 GPUs em uma única camada. A Oracle projeta a camada de baixa latência para a comunicação mais sensível, mas a própria existência de camadas superiores significa que a alocação de nós determina o desempenho. O teto de contagem de GPUs e o teto de desempenho efetivo são, portanto, medidos de maneiras diferentes.

Onde a capacidade de host se torna o limite

O segundo limite é mais concreto. A documentação de redimensionamento de rede de cluster da Oracle afirma que o provisionamento de instâncias é restringido pela capacidade de host disponível na rede RDMA, e a plataforma oferece uma operação de verificação de capacidade para que um cliente possa descobrir, antes de tentar provisionar, se há hosts disponíveis (https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/resize-cluster-network.htm). Essa é uma admissão de arquitetura, não uma nota de rodapé: um cluster pode ter espaço de endereçamento de rede para 131.072 GPUs enquanto o número de instâncias que podem ser realmente iniciadas em um determinado momento é limitado por quantos hosts físicos estão conectados e livres.

O terceiro limite é contratual. Os limites de serviço da Oracle definem cotas padrão de tenancy para recursos de computação de alto desempenho e de rede, e essas cotas são por conta, não por cluster (https://docs.oracle.com/en-us/iaas/Content/General/service-limits/default.htm). Um cliente com acesso a uma região zettascale ainda enfrenta um teto de conta que precisa ser elevado por solicitação. A trilha de evidências, portanto, aponta para uma leitura única: o número de 131.072 é um teto de projeto de rede, e os limites que um cliente encontra na prática são definidos pela topologia de latência, pela capacidade de host na malha e pelas cotas de tenancy, cada um documentado separadamente.

Consequência limitada

Nada disso torna o número de 131.072 falso ou inútil. Um teto de projeto de rede é uma afirmação real sobre o que a arquitetura foi construída para endereçar, e as camadas de latência e APIs de verificação de capacidade são exatamente as ferramentas que tornam esse teto verificável em vez de aspiracional. O que a evidência não sustenta é a inferência de que 131.072 GPUs estão simultaneamente disponíveis para um único cliente. A documentação da Oracle não afirma isso, e suas próprias páginas de limites de serviço e de capacidade de cluster descrevem por que não.

Fontes