NVIDIA Vera Rubin na OCI avança rumo à escala de vários gigawatts, com CPUs assumindo um papel maior

A NVIDIA e a Oracle anunciaram uma expansão planejada de vários gigawatts em 27 de outubro, junto com a disponibilidade geral do NVIDIA Vera Rubin na OCI. O anúncio combina nova capacidade de GPU com CPUs Vera independentes para o trabalho realizado entre as chamadas ao modelo. Sua relevância vai além de clusters maiores: os clientes podem expandir esses recursos de forma independente à medida que suas aplicações evoluem.

A OCI, sigla para Oracle Cloud Infrastructure, apresenta essa flexibilidade a desenvolvedores que criam agentes, sistemas de software que chamam modelos e executam ferramentas. Essas aplicações alternam entre gerar respostas e realizar tarefas computacionais convencionais. Comprar mais capacidade para servir modelos não torna automaticamente mais rápido o trabalho ao redor deles.

A tensão central está entre expandir a capacidade computacional instalada e manter essa capacidade produtiva. O Google Cloud já promove infraestrutura coordenada de CPUs e aceleradores por meio de Ironwood e Axion. O anúncio da Oracle traz essa mesma competição em nível de sistema para um foco mais nítido, ao mesmo tempo em que dá aos negócios de CPUs da NVIDIA um lugar mais visível ao lado de suas GPUs.

NVIDIA Vera Rubin na OCI combina disponibilidade com um plano de expansão

O lançamento imediato do produto e a expansão planejada da infraestrutura representam marcos diferentes.

Em sua expansão Vera Rubin, NVIDIA e Oracle distinguem a disponibilidade atual da escala futura. Os sistemas Vera Rubin NVL72 e as CPUs Vera estão geralmente disponíveis na OCI. A expansão dos OCI Superclusters com esses sistemas para uma escala de vários gigawatts continua sendo um plano declarado.

Essa distinção importa para leitores que interpretam a manchete. A disponibilidade geral estabelece uma oferta comercial. Isso não significa que toda a expansão planejada esteja instalada, energizada, reservada ou atendendo cargas de trabalho de clientes.

Um gigawatt mede potência, e não trabalho computacional concluído. Converter um compromisso de energia em serviços de IA úteis exige equipamentos, rede, refrigeração, software e implantação pelos clientes. Portanto, a manchete descreve a pegada de infraestrutura pretendida, sem estabelecer um volume correspondente de resultado entregue pelas aplicações.

O rack em si oferece uma referência mais concreta. As especificações do NVL72 da NVIDIA descrevem uma configuração que combina 72 GPUs Rubin e 36 CPUs Vera. Uma GPU, ou unidade de processamento gráfico, processa os cálculos paralelos centrais ao treinamento e à inferência de modelos, o processo de gerar resultados do modelo.

Esses componentes trabalham juntos dentro do rack, mas a oferta separada de CPU atende a uma decisão de compra diferente. Clientes que executam ferramentas ou serviços de aplicações precisam de capacidade computacional fora do sistema de serviço de modelos estreitamente conectado. Oracle e NVIDIA afirmam que os clientes podem escalar seus recursos de CPU e GPU de forma independente.

A implicação prática é flexibilidade na forma como os clientes montam uma aplicação. Uma equipe não precisa necessariamente expandir todos os grupos de recursos sempre que uma etapa fica congestionada. Ela pode avaliar se a geração do modelo, a execução de código, a recuperação de informações ou outra etapa precisa de capacidade adicional.

Trata-se de uma opção arquitetural, e não de uma melhoria automática de eficiência. As aplicações ainda precisam de software que direcione o trabalho aos recursos apropriados e reaja quando a demanda muda. O escalonamento independente oferece aos operadores mais um controle; não determina como eles devem usá-lo.

Para os compradores, o anúncio cria perguntas separadas sobre disponibilidade e entrega. Quais configurações podem obter agora? Onde podem obtê-las? Que capacidade a Oracle pode garantir ao longo do ciclo de vida de sua implantação?

Essas perguntas também determinam quanto peso atribuir ao plano de expansão. Uma grande pegada futura é um contexto útil para aquisições de longo prazo. Uma alocação específica, uma configuração compatível e uma janela de implantação fornecem evidências mais imediatas para uma decisão de engenharia.

Cargas de trabalho de agentes pressionam a computação entre as chamadas ao modelo

O anúncio pressiona equipes que medem a capacidade de IA principalmente por sua frota de GPUs.

A resposta de um modelo é apenas parte do trabalho de um agente. Depois de selecionar uma ação, a aplicação precisa executá-la, inspecionar o resultado e decidir o que acontece em seguida. Essas etapas introduzem diferentes exigências computacionais e diferentes fontes de atraso.

Considere um agente de programação ilustrativo encarregado de corrigir uma aplicação com falha. Ele recupera arquivos do projeto, pede a um modelo que proponha uma mudança, executa testes e devolve os resultados para outra decisão. O modelo e o executor de testes realizam trabalhos diferentes, embora o usuário vivencie uma única tarefa contínua.

Adicionar capacidade para servir modelos ajuda quando a geração é a restrição. Isso ajuda menos quando os testes aguardam um ambiente de execução ou passam tempo compilando dependências. A pergunta relevante passa a ser onde o fluxo de trabalho espera, e não qual componente tem as especificações mais impressionantes.

NVIDIA e Oracle identificam explicitamente a execução de ferramentas, os testes de código e a recuperação de dados como tarefas intensivas em CPU que dão suporte aos agentes. Uma CPU, ou unidade central de processamento, executa instruções gerais de aplicações e gerencia grande parte desse trabalho ao redor. As empresas posicionam a capacidade Vera independente como uma forma de dar suporte a essas etapas separadamente.

A implantação de CPU Vera da Oracle acrescenta uma alegação de escala: uma implantação inicial de 150.000 CPUs. A Oracle também descreve o acesso antecipado de clientes e afirma que a OpenAI está levando a Vera à produção para cargas de trabalho de IA agêntica. Essas são declarações de fornecedor e cliente apresentadas por meio da publicação da Oracle.

A contagem de CPUs mostra a escala que a Oracle atribui à oferta. Ela não revela quantos processadores um cliente específico pode reservar, com que intensidade eles são executados ou quanto de throughput de aplicação entregam. Essas distinções impedem que a escala da implantação se torne um substituto para evidências operacionais.

A pressão imediata recai sobre planejadores de infraestrutura e equipes de aplicações de IA. Eles precisam entender o equilíbrio entre solicitações aos modelos e o trabalho que essas solicitações desencadeiam. Um processo de aquisição centrado na contagem de aceleradores deixa esse equilíbrio pouco analisado.

Isso não significa que toda aplicação de agentes precise de uma implantação especializada de CPU. Alguns fluxos de trabalho passam a maior parte do tempo esperando por serviços externos. Outros geram longas respostas de modelos com relativamente pouca execução de ferramentas. A combinação adequada de recursos depende da sequência real de operações da aplicação.

O mesmo princípio se aplica a fluxos de trabalho de conhecimento. Um assistente que pesquisa uma base de conhecimento de IA precisa recuperar material relevante antes de produzir uma resposta útil. Capacidade adicional de geração não pode compensar documentos inacessíveis, permissões ausentes ou recuperação lenta.

Para compradores empresariais, isso conecta decisões de infraestrutura à experiência do usuário. Um serviço parece lento quando uma tarefa para em qualquer ponto de seu caminho. Os clientes raramente distinguem se o atraso veio do modelo, de uma ferramenta, de um banco de dados ou do software que os coordena.

Portanto, o anúncio incentiva um padrão de avaliação mais amplo. As equipes devem perguntar como a infraestrutura dá suporte a uma tarefa concluída, incluindo suas etapas intermediárias. Essa é a pressão criada pelo lançamento: explicar o desempenho da aplicação passa a ser tão importante quanto descrever o hardware instalado.

O escalonamento independente aborda um problema de agendamento

Separar o crescimento de CPUs e GPUs ajuda apenas quando a aplicação consegue usar essa separação de forma eficaz.

O mecanismo por trás do NVIDIA Vera Rubin na OCI é direto no nível arquitetural. Mantenha juntos os recursos estreitamente conectados onde o modelo precisa deles. Forneça capacidade computacional separada para tarefas ao redor cuja demanda segue um padrão diferente.

A arquitetura da plataforma Rubin da NVIDIA descreve um sistema projetado em torno de computação, rede e software coordenados. O NVLink, conexão de alta velocidade da NVIDIA entre processadores, dá suporte à comunicação dentro do sistema de computação de modelos. Essa conexão interna atende a uma finalidade diferente da alocação de um grupo separado de trabalhadores para execução de ferramentas.

Essa distinção evita um mal-entendido comum. O escalonamento independente não implica que cada componente dentro de um rack NVL72 seja alterado de forma independente. Ele descreve como os clientes podem ampliar recursos distintos de CPU e GPU em toda a infraestrutura de suas aplicações.

Retome o exemplo do agente de programação. Um pico de atividade de testes pode exigir trabalhadores adicionais de execução enquanto a demanda por modelos permanece relativamente estável. Outra carga de trabalho pode gerar mais solicitações aos modelos sem produzir um aumento correspondente em compilação ou testes.

Uma alocação fixa corre o risco de deixar um grupo de recursos subutilizado enquanto outro desenvolve uma fila. Grupos independentes oferecem aos operadores uma forma de ajustar esse desequilíbrio. O ganho depende de seu software reconhecer a restrição e provisionar capacidade útil a tempo.

É aqui que o agendamento, a atribuição de trabalho aos recursos disponíveis, se torna central. Uma aplicação precisa decidir onde uma ferramenta é executada, quais dados recebe e quando seu resultado retorna. Processadores extras continuam sendo uma resposta incompleta se o trabalho não consegue alcançá-los com eficiência.

A localização dos dados complica a decisão. Um trabalhador precisa acessar arquivos, dependências, credenciais e o estado relevante da aplicação. Afastar a execução da infraestrutura de serviço de modelos cria outro limite que o software precisa gerenciar.

Esse limite não é inerentemente uma desvantagem. Ele pode favorecer uma alocação e um isolamento mais claros. No entanto, um comprador deve incluir suas consequências operacionais ao avaliar o benefício de grupos de recursos separados.

Uma avaliação útil acompanha uma tarefa representativa desde o envio até a conclusão. Ela registra o tempo gasto gerando resultado do modelo, esperando por ferramentas, executando código, recuperando informações e repetindo etapas que falharam. O objetivo é identificar onde a capacidade adicional altera o resultado.

A conclusão bem-sucedida também importa. Uma execução mais rápida tem menos valor se produzir mais tarefas com falha ou exigir tentativas adicionais. Uma comparação significativa mantém a tarefa e os critérios de aceitação constantes enquanto examina os recursos consumidos.

Esses são princípios de avaliação, e não resultados publicados no anúncio. Eles explicam quais evidências sustentariam o argumento de eficiência das empresas. O lançamento estabelece a arquitetura disponível; as medições dos clientes precisam estabelecer seu valor para aplicações específicas.

O desafio operacional cresce quando as cargas de trabalho mudam ao longo do tempo. Um serviço que hoje responde principalmente a perguntas pode realizar mais ações após uma atualização de produto. O escalonamento independente oferece espaço para reagir, desde que a aplicação exponha as informações de que os operadores precisam.

Isso torna a oferta de CPU mais do que um acessório do lançamento de GPU. Ela cria outro espaço em que NVIDIA e Oracle podem participar da infraestrutura de aplicações. Se os clientes se beneficiarão dependerá de quão de perto essa infraestrutura corresponde ao trabalho que eles realmente realizam.

Rivais de Nuvem Competem em Torno da Aplicação de IA Completa

O anúncio da Oracle faz parte de uma competição por sistemas coordenados, incluindo a computação de uso geral que dá suporte aos modelos de IA.

Google Cloud oferece uma comparação útil porque conecta explicitamente o desenvolvimento de aceleradores e CPUs. Seu anúncio sobre Ironwood e Axion aborda a coordenação exigida pelos fluxos de trabalho de agentes. Ironwood é uma TPU, o processador especializado do Google para aprendizado de máquina, enquanto Axion oferece suporte à computação de uso geral.

A relevância é arquitetural. O Google descreve a aceleração de modelos ao lado dos serviços de aplicação, da preparação de dados e de outros trabalhos necessários ao seu redor. Oracle e NVIDIA agora enfatizam uma necessidade comparável por meio dos sistemas Rubin e das CPUs Vera disponíveis de forma independente.

Isso não estabelece produtos ou desempenho equivalentes. As plataformas diferem em seus processadores, ambientes de software, ofertas de serviços e modelos de implantação. Ainda assim, seus anúncios apontam para uma questão de compra comum: quão bem o sistema completo dá suporte à aplicação?

Para a Oracle, CPUs Vera independentes ampliam a discussão para além do acesso a aceleradores NVIDIA. A empresa pode oferecer recursos para servir modelos e executar o trabalho que os cerca. Isso dá aos clientes outra configuração a avaliar ao decidir onde seus agentes devem operar.

Para a NVIDIA, o anúncio amplia a importância comercial de sua CPU para além de seu papel dentro de um rack integrado. Se os clientes adotarem Vera para serviços de execução separados, a NVIDIA passará a participar de uma parcela maior de sua arquitetura computacional.

Essa oportunidade não deve ser confundida com um argumento para migração universal. Aplicações existentes trazem dependências e práticas operacionais consolidadas. As equipes precisam ponderar uma nova configuração em relação ao trabalho necessário para adotá-la e mantê-la.

A pressão competitiva também alcança implantações convencionais de servidores. Compradores que consideram Vera desejarão comparações com os sistemas que já executam suas ferramentas e serviços de aplicação. A infraestrutura conhecida fornece uma referência prática porque as equipes entendem seu comportamento em suas próprias cargas de trabalho.

A comparação mais sólida, portanto, começa com a aplicação existente do cliente. Ela examina se a mudança da plataforma de execução melhora a conclusão de tarefas, a capacidade de resposta, o consumo de recursos ou a confiabilidade operacional. Uma vantagem em nível de componente aborda apenas parte dessa decisão.

A continuidade do software também importa. Uma empresa com um ambiente consolidado de serving de modelos considerará como uma nova configuração se encaixa em seus processos de implantação e suporte. Qualquer avaliação de hardware que ignore esses processos subestima o trabalho de adoção.

É por isso que a narrativa competitiva deve permanecer separada de alegações infundadas sobre vencedores. O lançamento da Oracle amplia suas opções disponíveis. A estratégia de CPU e aceleradores do Google fornece um contexto relevante. Nenhum dos anúncios estabelece qual plataforma entrega o melhor resultado para toda carga de trabalho de agentes.

A mudança mais ampla está no que os fornecedores pedem que os clientes avaliem. As especificações dos aceleradores continuam relevantes, mas o ambiente de execução que lhes dá suporte entra cada vez mais na mesma conversa. Os provedores de infraestrutura precisam explicar como seus componentes cooperam ao longo de uma tarefa.

Para leitores que acompanham NVIDIA Vera Rubin no OCI, esse é o enquadramento competitivo mais útil. A manchete trata de compromissos maiores de infraestrutura. A decisão de compra trata de saber se uma combinação específica de serviços pode apoiar uma aplicação de forma mais eficaz do que sua configuração atual.

Disponibilidade e Quantidades de Processadores Deixam Questões Importantes em Aberto

O anúncio estabelece produtos e planos, mas não estabelece ganhos universais de produtividade para os clientes.

A primeira incerteza diz respeito à conexão entre disponibilidade geral e acesso prático. Um lançamento público não especifica a alocação, o local de implantação ou o cronograma de entrega de cada cliente. Os compradores precisam desses detalhes antes de transformar um anúncio em um plano de implementação.

A segunda diz respeito à presença planejada de vários gigawatts. O anúncio descreve uma expansão, mas a manchete por si só não fornece um cronograma completo de entrega. Os leitores devem distinguir a escala pretendida da capacidade operacional à medida que mais informações se tornem disponíveis.

A terceira diz respeito aos resultados das aplicações. Uma grande implantação de CPUs e uma nova geração de GPUs não quantificam, por si só, quanto mais rapidamente um agente conclui um trabalho útil. Isso exige uma carga de trabalho definida e uma comparação com uma referência clara.

A publicação da Oracle inclui alegações de desempenho, mas elas continuam sendo afirmações da empresa, a menos que sejam respaldadas por uma metodologia que possa ser avaliada de forma independente. Os compradores devem examinar a configuração, o software, a carga de trabalho e o limite de medição por trás de qualquer melhoria anunciada.

Esse limite é especialmente importante para agentes. Medir a velocidade de execução de um processador é diferente de medir uma tarefa completa que inclui chamadas de modelo e serviços externos. Uma melhoria em uma etapa não estabelece a mesma melhoria em todo o fluxo de trabalho.

Também há uma distinção entre utilização de recursos e valor para o cliente. Um processador ocupado pode estar realizando trabalho produtivo, tentativas repetidas ou computação desnecessária. A atividade elevada só se torna significativa quando contribui para resultados aceitos.

Por outro lado, alguma capacidade ociosa atende a um propósito operacional. As aplicações podem manter margem para picos, falhas ou requisitos de tempo de resposta. Uma avaliação deve distinguir desperdício evitável de capacidade reservada para cumprir um compromisso de serviço.

O escalonamento independente também transfere decisões ao operador da aplicação. As equipes precisam determinar quando adicionar capacidade, quanto manter e como responder quando dependências falham. A flexibilidade é valiosa, mas introduz escolhas que exigem medição e julgamento operacional.

A segurança acrescenta outra dimensão. Agentes que executam código gerado precisam de controles sobre seu ambiente e acesso. Um sandbox, um ambiente de execução isolado, limita o que esse código pode alcançar, mas sua eficácia depende da implementação ao redor.

Os clientes devem avaliar permissões de execução, tratamento de dados e contenção de falhas junto com o throughput. Um worker mais rápido com acesso inadequado não cria um sistema de produção melhor. Isso importa especialmente quando o agente recupera informações proprietárias ou atua por meio de ferramentas empresariais conectadas.

A migração apresenta uma questão distinta. Mover uma aplicação para um ambiente de CPU diferente exige verificar dependências de software e compatibilidade de implantação. O esforço relevante depende da aplicação, portanto um anúncio amplo de lançamento não pode resolvê-lo para todos os clientes.

Essas incertezas não invalidam o lançamento. Elas identificam as evidências necessárias para julgá-lo com precisão. As empresas anunciaram uma opção de infraestrutura com uma justificativa arquitetural clara; os benefícios operacionais resultantes continuam dependentes da carga de trabalho.

A interpretação cautelosa, portanto, é específica. Recursos independentes de CPU e GPU dão aos clientes outra maneira de lidar com demandas desalinhadas. Se essa opção reduz desperdícios ou melhora a capacidade de resposta deve ser estabelecido por meio de resultados em nível de aplicação.

Acompanhe o Acesso à Capacidade, as Medições dos Clientes e o Software de Execução

As próximas evidências devem conectar a infraestrutura anunciada à capacidade obtível e às cargas de trabalho dos clientes concluídas.

O primeiro sinal são informações de acesso mais específicas. Nos próximos meses, os clientes devem acompanhar configurações compatíveis, locais de implantação, condições de alocação e marcos de expansão. Esses detalhes esclarecem como os produtos anunciados se traduzem em capacidade prática.

Informações de entrega mais concretas reforçariam o argumento de que a expansão apoia o planejamento dos clientes no curto prazo. A ênfase contínua na escala agregada, sem detalhes correspondentes sobre acesso, deixaria essa parte da história menos resolvida.

Esse sinal importa separadamente para os sistemas de GPU e as CPUs independentes. Os clientes que adotam um deles não têm necessariamente os mesmos requisitos ou cronogramas dos clientes que adotam o outro. Informações separadas sobre disponibilidade tornariam a proposta de escalonamento independente mais fácil de avaliar.

O segundo sinal é a medição, pelos clientes, de fluxos de trabalho completos. Evidências úteis descreveriam a aplicação, sua configuração anterior, os recursos alterados e os critérios de aceitação. Também explicariam o que aconteceu com a conclusão de tarefas e o consumo de recursos.

Uma avaliação de agente de programação, por exemplo, deve incluir execução e testes, em vez de parar na geração pelo modelo. Uma aplicação de recuperação deve incluir acesso às informações subjacentes. A comparação se torna mais persuasiva quando acompanha a tarefa do usuário através dessas fronteiras.

Evidências de que capacidade adicional de Vera elimina uma restrição de execução medida sustentariam o argumento central do lançamento. Resultados que mostram que a maior parte do atraso ocorre em outro lugar delimitariam os casos de uso relevantes. Qualquer um dos resultados ajudaria os compradores a tomar decisões mais informadas.

O terceiro sinal é o software de produção que torna pools de recursos separados mais fáceis de operar. Observe como as aplicações lidam com a alocação de workers, o acesso a dados, o estado de execução e as falhas. Essas capacidades determinam se os recursos independentes funcionam como um serviço coordenado.

Esse sinal merece atenção porque uma opção de hardware não cria automaticamente uma arquitetura de aplicação utilizável. Os operadores precisam de visibilidade suficiente para entender onde o trabalho espera e de controle suficiente para responder. Uma coordenação melhor reforçaria o argumento de eficiência sem exigir que cada componente melhore igualmente.

Juntos, esses sinais fornecem uma maneira fundamentada de acompanhar NVIDIA Vera Rubin no OCI. Divulgações de capacidade abordam a entrega. Medições dos clientes abordam o valor. O software de execução aborda o trabalho prático de conectar os componentes disponíveis.

Para desenvolvedores, o anúncio é um motivo para examinar onde seus próprios fluxos de trabalho de agentes gastam tempo. Para compradores empresariais, é um motivo para solicitar evidências em nível de aplicação. Para usuários, o resultado relevante continua sendo um serviço que conclui trabalho útil de forma confiável.

Antes de assumir o compromisso com uma nova configuração de infraestrutura, acompanhe uma tarefa representativa por todo o sistema e identifique sua restrição real. Peça ao provedor que diferencie a capacidade disponível da expansão planejada e as alegações sobre componentes dos resultados medidos na aplicação. Inclua execução, recuperação, falhas e recuperação operacional na avaliação. Mantenha a carga de trabalho e os critérios de aceitação consistentes ao comparar alternativas. Essa abordagem oferece uma avaliação justa de NVIDIA Vera Rubin no OCI, mantendo a decisão de compra vinculada ao trabalho que os clientes precisam realizar. Qual etapa da sua aplicação seria aprimorada por capacidade adicional de CPU ou GPU, e qual medição demonstraria essa melhoria?