NVIDIA Vera Rubin su OCI punta alla scala multi-gigawatt, con un ruolo maggiore per le CPU

NVIDIA e Oracle hanno annunciato il 27 ottobre una prevista espansione multi-gigawatt, insieme alla disponibilità generale di NVIDIA Vera Rubin su OCI. L’annuncio affianca nuova capacità GPU a CPU Vera autonome per il lavoro che avviene tra le chiamate al modello. La sua rilevanza va oltre cluster più grandi: i clienti possono espandere queste risorse in modo indipendente man mano che le loro applicazioni cambiano.

OCI, abbreviazione di Oracle Cloud Infrastructure, presenta questa flessibilità agli sviluppatori che costruiscono agenti, sistemi software che chiamano modelli ed eseguono strumenti. Queste applicazioni alternano la generazione di risposte all’esecuzione di normali attività computazionali. Acquistare maggiore capacità per servire i modelli non rende automaticamente più veloce il lavoro circostante.

La tensione centrale riguarda l’espansione della capacità computazionale installata e il mantenimento della sua produttività. Google Cloud promuove già infrastrutture coordinate di CPU e acceleratori attraverso Ironwood e Axion. L’annuncio di Oracle porta questa stessa competizione a livello di sistema in primo piano, offrendo al contempo al business delle CPU di NVIDIA una collocazione più visibile accanto alle sue GPU.

NVIDIA Vera Rubin su OCI combina disponibilità e piano di espansione

Il lancio immediato del prodotto e la prevista espansione dell’infrastruttura rappresentano tappe diverse.

Nel loro congiunto ampliamento di Vera Rubin, NVIDIA e Oracle distinguono la disponibilità attuale dalla scala futura. I sistemi Vera Rubin NVL72 e le CPU Vera sono generalmente disponibili su OCI. L’espansione degli OCI Superclusters con questi sistemi fino a una scala multi-gigawatt rimane un piano dichiarato.

Questa distinzione è importante per chi interpreta il titolo. La disponibilità generale attesta un’offerta commerciale. Non significa che l’intera espansione prevista sia installata, alimentata, riservata o al servizio dei carichi di lavoro dei clienti.

Un gigawatt misura la potenza, non il lavoro computazionale completato. Trasformare un impegno di potenza in servizi AI utili richiede apparecchiature, rete, raffreddamento, software e distribuzione presso i clienti. Il titolo descrive quindi l’impronta infrastrutturale prevista, senza stabilire una quantità corrispondente di output applicativo erogato.

Il rack stesso offre un riferimento più concreto. Le specifiche NVL72 di NVIDIA descrivono una configurazione che combina 72 GPU Rubin e 36 CPU Vera. Una GPU, o unità di elaborazione grafica, gestisce i calcoli paralleli centrali per l’addestramento e l’inferenza dei modelli, il processo di generazione degli output del modello.

Questi componenti lavorano insieme all’interno del rack, ma l’offerta separata di CPU risponde a una diversa decisione di acquisto. I clienti che eseguono strumenti o servizi applicativi necessitano di capacità computazionale al di fuori del sistema per servire modelli strettamente interconnesso. Oracle e NVIDIA affermano che i clienti possono scalare in modo indipendente le proprie risorse CPU e GPU.

L’implicazione pratica è una maggiore flessibilità nel modo in cui i clienti assemblano un’applicazione. Un team non deve necessariamente espandere ogni pool di risorse ogni volta che una fase diventa congestionata. Può valutare se la generazione del modello, l’esecuzione del codice, il recupero delle informazioni o un altro passaggio richiedano capacità aggiuntiva.

Si tratta di un’opzione architetturale, non di un miglioramento automatico dell’efficienza. Le applicazioni necessitano comunque di software che indirizzi il lavoro verso le risorse appropriate e reagisca ai cambiamenti della domanda. Lo scaling indipendente offre agli operatori un ulteriore controllo; non decide come debbano usarlo.

Per gli acquirenti, l’annuncio solleva domande separate su disponibilità e consegna. Quali configurazioni possono ottenere ora? Dove possono ottenerle? Quale capacità può impegnare Oracle per l’intera durata della loro distribuzione?

Queste domande determinano anche quanto peso attribuire al piano di espansione. Una vasta impronta futura è un contesto utile per gli approvvigionamenti a lungo termine. Un’allocazione specifica, una configurazione supportata e una finestra di distribuzione offrono evidenze più immediate per una decisione ingegneristica.

I carichi di lavoro degli agenti mettono sotto pressione il calcolo tra le chiamate al modello

L’annuncio mette sotto pressione i team che misurano la capacità AI principalmente attraverso la propria flotta di GPU.

Una risposta del modello è solo una parte del lavoro di un agente. Dopo aver selezionato un’azione, l’applicazione deve eseguirla, ispezionarne il risultato e decidere cosa accade successivamente. Queste fasi introducono requisiti computazionali diversi e diverse fonti di ritardo.

Si consideri un agente di coding esemplificativo incaricato di riparare un’applicazione malfunzionante. Recupera i file del progetto, chiede a un modello di proporre una modifica, esegue i test e restituisce i risultati per un’altra decisione. Il modello e l’esecutore dei test svolgono lavori diversi, anche se l’utente vive un’unica attività continua.

Aggiungere capacità per servire i modelli aiuta quando la generazione è il vincolo. Aiuta meno quando i test attendono un ambiente di esecuzione o trascorrono tempo compilando dipendenze. La domanda rilevante diventa dove il flusso di lavoro attende, anziché quale componente abbia le specifiche più impressionanti.

NVIDIA e Oracle identificano esplicitamente l’esecuzione di strumenti, il test del codice e il recupero dei dati come attività ad alta intensità di CPU a supporto degli agenti. Una CPU, o unità centrale di elaborazione, esegue istruzioni applicative generiche e gestisce gran parte di questo lavoro circostante. Le aziende posizionano la capacità Vera autonoma come un modo per supportare separatamente queste fasi.

La distribuzione di Vera CPU di Oracle aggiunge un’affermazione sulla scala: una distribuzione iniziale di 150.000 CPU. Oracle descrive inoltre l’accesso anticipato dei clienti e afferma che OpenAI sta portando Vera in produzione per carichi di lavoro agentici. Si tratta di dichiarazioni del fornitore e del cliente presentate attraverso la pubblicazione di Oracle.

Il numero di CPU mostra la portata che Oracle attribuisce all’offerta. Non rivela quanti processori un cliente specifico possa riservare, quanto intensamente li utilizzi o quale throughput applicativo forniscano. Queste distinzioni impediscono che la scala della distribuzione diventi un sostituto delle evidenze operative.

La pressione immediata ricade sui pianificatori dell’infrastruttura e sui team delle applicazioni AI. Devono comprendere l’equilibrio tra le richieste al modello e il lavoro che tali richieste attivano. Un processo di approvvigionamento incentrato sul conteggio degli acceleratori lascia questo equilibrio poco esaminato.

Ciò non significa che ogni applicazione agentica necessiti di una distribuzione CPU specializzata. Alcuni flussi di lavoro trascorrono la maggior parte del tempo in attesa di servizi esterni. Altri generano lunghe risposte del modello con un’esecuzione di strumenti relativamente limitata. La combinazione di risorse appropriata dipende dalla sequenza effettiva di operazioni dell’applicazione.

Lo stesso principio si applica ai flussi di lavoro della conoscenza. Un assistente che cerca in una base di conoscenza AI deve recuperare materiale pertinente prima di produrre una risposta utile. Capacità aggiuntiva di generazione non può compensare documenti inaccessibili, autorizzazioni mancanti o recupero lento.

Per gli acquirenti aziendali, questo collega le decisioni infrastrutturali all’esperienza utente. Un servizio sembra lento quando un’attività si blocca in qualsiasi punto del suo percorso. I clienti raramente distinguono se il ritardo provenga dal modello, da uno strumento, da un database o dal software che li coordina.

L’annuncio incoraggia quindi uno standard di valutazione più ampio. I team dovrebbero chiedersi in che modo l’infrastruttura supporti un’attività completata, compresi i suoi passaggi intermedi. Questa è la pressione creata dal lancio: spiegare le prestazioni dell’applicazione diventa importante quanto descrivere l’hardware installato.

Lo scaling indipendente affronta un problema di pianificazione

Separare la crescita di CPU e GPU aiuta solo quando l’applicazione può sfruttare efficacemente tale separazione.

Il meccanismo alla base di NVIDIA Vera Rubin su OCI è semplice a livello architetturale. Mantenere insieme le risorse strettamente connesse dove il modello le richiede. Fornire capacità computazionale separata per le attività circostanti, la cui domanda segue uno schema diverso.

L’architettura della piattaforma Rubin di NVIDIA descrive un sistema progettato attorno a calcolo, rete e software coordinati. NVLink, la connessione ad alta velocità di NVIDIA tra processori, supporta la comunicazione all’interno del sistema di calcolo del modello. Questa connessione interna serve uno scopo diverso dall’allocazione di un pool separato di worker per l’esecuzione degli strumenti.

Questa distinzione evita un malinteso comune. Lo scaling indipendente non implica che ogni componente all’interno di un rack NVL72 cambi in modo indipendente. Descrive come i clienti possano far crescere risorse CPU e GPU distinte nell’intera infrastruttura applicativa.

Torniamo all’esempio dell’agente di coding. Un picco di attività di test potrebbe richiedere worker di esecuzione aggiuntivi mentre la domanda del modello rimane relativamente stabile. Un diverso carico di lavoro potrebbe generare più richieste al modello senza produrre un aumento corrispondente nella compilazione o nei test.

Un’allocazione fissa rischia di lasciare sottoutilizzato un pool di risorse mentre un altro sviluppa una coda. Pool indipendenti offrono agli operatori un modo per correggere questo squilibrio. Il guadagno dipende dal fatto che il loro software riconosca il vincolo e predisponga capacità utile in tempo.

Qui la pianificazione, ovvero l’assegnazione del lavoro alle risorse disponibili, diventa centrale. Un’applicazione deve decidere dove viene eseguito uno strumento, quali dati riceve e quando restituisce il risultato. Processori aggiuntivi rimangono una risposta incompleta se il lavoro non può raggiungerli in modo efficiente.

Il posizionamento dei dati complica la decisione. Un worker necessita di accesso a file, dipendenze, credenziali e stato applicativo pertinente. Spostare l’esecuzione lontano dall’infrastruttura che serve i modelli crea un altro confine che il software deve gestire.

Questo confine non rappresenta intrinsecamente uno svantaggio. Può supportare un’allocazione e un isolamento più chiari. Tuttavia, un acquirente dovrebbe includerne le conseguenze operative nella valutazione del beneficio di pool di risorse separati.

Una valutazione utile segue un’attività rappresentativa dall’invio al completamento. Registra il tempo impiegato per generare l’output del modello, attendere gli strumenti, eseguire il codice, recuperare informazioni e ritentare passaggi falliti. L’obiettivo è identificare dove una capacità aggiuntiva cambia il risultato.

Anche il completamento con successo è importante. Un’esecuzione più rapida è meno preziosa se produce più attività fallite o richiede ulteriori tentativi. Un confronto significativo mantiene costanti l’attività e i criteri di accettazione, esaminando al contempo le risorse consumate.

Questi sono principi di valutazione, non risultati pubblicati nell’annuncio. Spiegano quali evidenze sosterrebbero l’argomento delle aziende sull’efficienza. Il lancio stabilisce l’architettura disponibile; le misurazioni dei clienti devono stabilirne il valore per applicazioni specifiche.

La sfida operativa cresce quando i carichi di lavoro cambiano nel tempo. Un servizio che oggi risponde principalmente a domande potrebbe eseguire più azioni dopo un aggiornamento del prodotto. Lo scaling indipendente offre spazio per reagire, purché l’applicazione esponga le informazioni di cui gli operatori hanno bisogno.

Questo rende l’offerta CPU più di un accessorio al lancio delle GPU. Crea un ulteriore ambito in cui NVIDIA e Oracle possono partecipare all’infrastruttura applicativa. Se i clienti ne trarranno vantaggio dipende da quanto tale infrastruttura corrisponda al lavoro che effettivamente svolgono.

I rivali del cloud competono attorno all'applicazione AI completa

L'annuncio di Oracle si inserisce in una competizione sui sistemi coordinati, incluso il calcolo generico che supporta i modelli AI.

Google Cloud offre un confronto utile perché collega esplicitamente lo sviluppo di acceleratori e CPU. Il suo annuncio su Ironwood e Axion affronta il coordinamento richiesto dai flussi di lavoro degli agenti. Ironwood è una TPU, il processore specializzato di Google per il machine learning, mentre Axion supporta il calcolo generico.

La rilevanza è architetturale. Google descrive l'accelerazione dei modelli insieme ai servizi applicativi, alla preparazione dei dati e alle altre attività necessarie attorno ad essa. Oracle e NVIDIA stanno ora sottolineando un'esigenza comparabile attraverso i sistemi Rubin e le CPU Vera disponibili separatamente.

Ciò non stabilisce prodotti o prestazioni equivalenti. Le piattaforme differiscono per processori, ambienti software, offerte di servizi e modalità di distribuzione. I loro annunci indicano tuttavia una domanda d'acquisto condivisa: quanto bene il sistema completo supporta l'applicazione?

Per Oracle, le CPU Vera autonome ampliano la discussione oltre l'accesso agli acceleratori NVIDIA. L'azienda può proporre risorse per il serving dei modelli e per l'esecuzione delle attività che lo circondano. Questo offre ai clienti un'ulteriore configurazione da valutare nel decidere dove eseguire i propri agenti.

Per NVIDIA, l'annuncio estende l'importanza commerciale della sua CPU oltre il suo ruolo all'interno di un rack integrato. Se i clienti adotteranno Vera per servizi di esecuzione separati, NVIDIA parteciperà a una porzione più ampia della loro architettura di calcolo.

Questa opportunità non va confusa con un caso universale di migrazione. Le applicazioni esistenti portano con sé dipendenze consolidate e pratiche operative. I team devono valutare una nuova configurazione rispetto al lavoro necessario per adottarla e mantenerla.

La pressione competitiva raggiunge anche le implementazioni server convenzionali. Gli acquirenti che considerano Vera vorranno confronti con i sistemi sui quali già eseguono i propri strumenti e servizi applicativi. L'infrastruttura nota offre una base pratica perché i team ne comprendono il comportamento con i propri carichi di lavoro.

Il confronto più solido parte quindi dall'applicazione esistente del cliente. Esamina se cambiare la piattaforma di esecuzione migliora il completamento delle attività, la reattività, il consumo di risorse o l'affidabilità operativa. Un vantaggio a livello di componente affronta solo una parte della decisione.

Anche la continuità del software conta. Un'azienda con un ambiente consolidato per il serving dei modelli valuterà come una nuova configurazione si integri nei suoi processi di deployment e supporto. Qualsiasi valutazione hardware che ignori tali processi sottostima il lavoro di adozione.

Per questo il racconto competitivo dovrebbe restare separato da affermazioni non supportate su un vincitore. Il lancio di Oracle amplia le opzioni disponibili. La strategia di Google per CPU e acceleratori fornisce un contesto pertinente. Nessuno dei due annunci stabilisce quale piattaforma offra il risultato migliore per ogni carico di lavoro degli agenti.

Il cambiamento più ampio riguarda ciò che i fornitori chiedono ai clienti di valutare. Le specifiche degli acceleratori restano rilevanti, ma l'ambiente di esecuzione di supporto entra sempre più nella stessa conversazione. I provider di infrastruttura devono spiegare come i loro componenti cooperino lungo l'intera attività.

Per i lettori che seguono NVIDIA Vera Rubin su OCI, questo è il quadro competitivo più utile. Il titolo riguarda impegni infrastrutturali più ampi. La decisione d'acquisto riguarda se una particolare combinazione di servizi possa supportare un'applicazione in modo più efficace della sua configurazione attuale.

Disponibilità e numero di processori lasciano aperte questioni importanti

L'annuncio stabilisce prodotti e piani, senza però dimostrare guadagni universali nella produttività dei clienti.

La prima incertezza riguarda il collegamento tra disponibilità generale e accesso pratico. Un lancio pubblico non specifica l'allocazione, la sede di deployment o il calendario di consegna di ogni cliente. Gli acquirenti hanno bisogno di questi dettagli prima di tradurre un annuncio in un piano di implementazione.

La seconda riguarda l'impronta pianificata da più gigawatt. L'annuncio descrive un'espansione, ma il titolo da solo non fornisce un calendario di consegna completo. I lettori dovrebbero distinguere la scala prevista dalla capacità operativa man mano che saranno disponibili ulteriori informazioni.

La terza riguarda i risultati applicativi. Un'ampia implementazione di CPU e una nuova generazione di GPU non quantificano, da sole, quanto più velocemente un agente completi un lavoro utile. Ciò richiede un carico di lavoro definito e un confronto con una base di riferimento chiara.

La pubblicazione di Oracle include affermazioni sulle prestazioni, ma restano dichiarazioni dell'azienda se non sono supportate da una metodologia valutabile in modo indipendente. Gli acquirenti dovrebbero esaminare la configurazione, il software, il carico di lavoro e il perimetro di misurazione alla base di qualsiasi miglioramento pubblicizzato.

Il perimetro è particolarmente importante per gli agenti. Misurare la velocità di esecuzione di un processore è diverso dal misurare un'attività completa che include chiamate al modello e servizi esterni. Un miglioramento in una fase non dimostra lo stesso miglioramento nell'intero flusso di lavoro.

Esiste anche una distinzione tra utilizzo delle risorse e valore per il cliente. Un processore molto attivo potrebbe gestire lavoro produttivo, tentativi ripetuti o calcoli non necessari. Un'elevata attività acquista significato solo quando contribuisce a risultati accettati.

Al contrario, parte della capacità inattiva ha una funzione operativa. Le applicazioni possono mantenere margine per picchi, guasti o requisiti di tempo di risposta. Una valutazione dovrebbe distinguere gli sprechi evitabili dalla capacità mantenuta per rispettare un impegno di servizio.

La scalabilità indipendente trasferisce inoltre decisioni all'operatore dell'applicazione. I team devono stabilire quando aggiungere capacità, quanta conservarne e come reagire quando le dipendenze falliscono. La flessibilità è preziosa, ma introduce scelte che richiedono misurazione e giudizio operativo.

La sicurezza aggiunge un'altra dimensione. Gli agenti che eseguono codice generato necessitano di controlli sul proprio ambiente e sui propri accessi. Una sandbox, un ambiente di esecuzione isolato, limita ciò a cui quel codice può accedere, ma la sua efficacia dipende dall'implementazione circostante.

I clienti dovrebbero valutare autorizzazioni di esecuzione, gestione dei dati e contenimento dei guasti insieme al throughput. Un worker più veloce con accessi inappropriati non crea un sistema di produzione migliore. Questo conta soprattutto quando l'agente recupera informazioni proprietarie o agisce attraverso strumenti aziendali connessi.

La migrazione pone una questione distinta. Spostare un'applicazione in un ambiente CPU diverso richiede di verificare le dipendenze software e la compatibilità di deployment. Lo sforzo pertinente dipende dall'applicazione, quindi un ampio annuncio di lancio non può risolvere la questione per ogni cliente.

Queste incertezze non invalidano il lancio. Identificano le prove necessarie per giudicarlo con accuratezza. Le aziende hanno annunciato un'opzione infrastrutturale con una chiara logica architetturale; i conseguenti benefici operativi restano dipendenti dal carico di lavoro.

L'interpretazione prudente è quindi specifica. Risorse CPU e GPU indipendenti offrono ai clienti un altro modo per affrontare una domanda non allineata. Se tale opzione riduca gli sprechi o migliori la reattività deve essere dimostrato tramite risultati a livello applicativo.

Monitorare l'accesso alla capacità, le misurazioni dei clienti e il software di esecuzione

Le prossime prove dovrebbero collegare l'infrastruttura annunciata a capacità ottenibile e carichi di lavoro dei clienti completati.

Il primo segnale consiste in informazioni di accesso più specifiche. Nei prossimi mesi, i clienti dovrebbero seguire configurazioni supportate, sedi di deployment, termini di allocazione e tappe dell'espansione. Questi dettagli chiarirebbero come i prodotti annunciati si traducano in capacità pratica.

Informazioni di consegna più concrete rafforzerebbero l'ipotesi che l'espansione supporti la pianificazione dei clienti nel breve termine. Una continua enfasi sulla scala aggregata, senza dettagli corrispondenti sull'accesso, lascerebbe quella parte della storia meno definita.

Questo segnale è importante separatamente per i sistemi GPU e per le CPU autonome. I clienti che adottano l'uno non hanno necessariamente gli stessi requisiti o le stesse tempistiche dei clienti che adottano l'altra. Informazioni di disponibilità separate renderebbero più semplice valutare la proposta di scalabilità indipendente.

Il secondo segnale è la misurazione da parte dei clienti di flussi di lavoro completi. Le prove utili descriverebbero l'applicazione, la sua configurazione precedente, le risorse modificate e i criteri di accettazione. Spiegherebbero inoltre cosa è accaduto al completamento delle attività e al consumo di risorse.

Una valutazione di un agente di coding, per esempio, dovrebbe includere esecuzione e test invece di fermarsi alla generazione del modello. Un'applicazione di retrieval dovrebbe includere l'accesso alle informazioni sottostanti. Il confronto diventa più persuasivo quando segue l'attività dell'utente attraverso tali confini.

Le prove che una capacità Vera aggiuntiva rimuova un vincolo di esecuzione misurato sosterrebbero l'argomento centrale del lancio. Risultati che mostrassero che la maggior parte del ritardo si verifica altrove restringerebbero i casi d'uso pertinenti. Entrambi gli esiti aiuterebbero gli acquirenti a prendere decisioni più informate.

Il terzo segnale è un software di produzione che renda più semplici da gestire pool di risorse separati. Osservate come le applicazioni gestiscono l'allocazione dei worker, l'accesso ai dati, lo stato di esecuzione e i guasti. Queste capacità determinano se le risorse indipendenti funzionano come un servizio coordinato.

Questo segnale merita attenzione perché un'opzione hardware non crea automaticamente un'architettura applicativa utilizzabile. Gli operatori hanno bisogno di visibilità sufficiente per capire dove il lavoro è in attesa e di controllo sufficiente per intervenire. Un coordinamento migliore rafforzerebbe il caso dell'efficienza senza richiedere che ogni componente migliori in ugual misura.

Insieme, questi segnali offrono un modo concreto per seguire NVIDIA Vera Rubin su OCI. Le divulgazioni sulla capacità affrontano la consegna. Le misurazioni dei clienti affrontano il valore. Il software di esecuzione affronta il lavoro pratico di collegare i componenti disponibili.

Per gli sviluppatori, l'annuncio è un motivo per esaminare dove i propri flussi di lavoro degli agenti impiegano tempo. Per gli acquirenti aziendali, è un motivo per richiedere prove a livello applicativo. Per gli utenti, il risultato rilevante rimane un servizio che completa lavoro utile in modo affidabile.

Prima di impegnarsi in una nuova configurazione infrastrutturale, seguite un'attività rappresentativa attraverso il sistema e identificate il suo vincolo effettivo. Chiedete al fornitore di distinguere la capacità disponibile dall'espansione pianificata e le affermazioni sui componenti dai risultati applicativi misurati. Includete esecuzione, retrieval, guasti e ripristino nella valutazione. Mantenete coerenti il carico di lavoro e i criteri di accettazione nel confronto tra alternative. Questo approccio consente una valutazione equa di NVIDIA Vera Rubin su OCI, mantenendo al contempo la decisione d'acquisto legata al lavoro che i clienti devono svolgere. Quale fase della vostra applicazione migliorerebbe con capacità CPU o GPU aggiuntiva, e quale misurazione mostrerebbe tale miglioramento?