Nvidia Vera su OCI porta le CPU standalone in competizione con Xeon
Nvidia Vera su OCI offre ai clienti Oracle un'opzione di CPU standalone, mentre test separati riportano oltre il doppio della larghezza di banda della memoria di un server dual Xeon. Nvidia e Oracle hanno annunciato la disponibilità generale il 27 ottobre, insieme a piani per espandere la loro infrastruttura IA su scala multi-gigawatt. La distinzione è importante: i processori sono disponibili in modo indipendente, mentre l'espansione resta un piano.
Il benchmark è di Tom’s Hardware, che ha testato un server Vera separato anziché Oracle Cloud Infrastructure, o OCI. Fornisce prove delle capacità del processore, senza stabilire le prestazioni di un'istanza Oracle. Questo articolo analizza tali evidenze pubblicate; non presenta test hardware originali.
La questione competitiva riguarda il lavoro eseguito tra le risposte di un modello IA. I processori Intel Xeon e AMD EPYC gestiscono già questi servizi nelle infrastrutture aziendali. La decisione di Oracle offre a Nvidia un'altra via di accesso a quel mercato, con il trasferimento dei dati in memoria e l'esecuzione delle applicazioni che diventano criteri d'acquisto accanto alla compatibilità del processore.
Nvidia Vera su OCI separa la capacità CPU dagli acquisti di GPU
Oracle offre Vera come capacità di calcolo distribuibile in modo indipendente, assegnando al processore un ruolo che va oltre l'hosting degli acceleratori Nvidia.
Una CPU, o unità centrale di elaborazione, esegue le istruzioni delle applicazioni e gestisce le attività di calcolo generiche. Una GPU, o unità di elaborazione grafica, esegue carichi di lavoro paralleli comunemente usati per addestrare e far funzionare i modelli IA. Queste risorse supportano fasi diverse di un'applicazione IA, anche quando i clienti le acquistano insieme.
L'annuncio relativo al deployment standalone della CPU descrive esplicitamente la possibilità per i clienti di scalare le risorse CPU e GPU in modo indipendente. Ciò crea una scelta concreta per le organizzazioni il cui software richiede maggiore capacità di elaborazione delle applicazioni senza un corrispondente aumento della capacità dei modelli.
Vera Rubin NVL72 è la configurazione rack più ampia annunciata insieme alle CPU. Collega 72 GPU tramite NVLink, l'interconnessione Nvidia per la comunicazione tra processori. I servizi Vera standalone affrontano un'altra decisione d'acquisto: dove eseguire il software che circonda questi modelli.
Consideriamo un assistente di programmazione esemplificativo. Un modello propone una modifica, un servizio di esecuzione la testa e l'applicazione restituisce i risultati per un'altra risposta del modello. Il servizio di test consuma risorse CPU anche se il modello stesso viene eseguito altrove.
Un cliente potrebbe aver bisogno di capacità di esecuzione aggiuntiva nei periodi di punta, mentre il proprio servizio di modelli ha ancora margine. Acquistare queste risorse separatamente consente di allineare più strettamente l'infrastruttura alla domanda. Che ciò migliori l'efficienza dipende dall'utilizzo effettivo delle risorse dell'applicazione.
L'annuncio di disponibilità di Oracle dovrebbe inoltre essere distinto dall'espansione fisica pianificata. La scala multi-gigawatt descrive la prevista realizzazione dell'infrastruttura, anziché una misurazione della capacità Vera standalone attualmente in esecuzione. Non stabilisce quante apparecchiature i clienti possano riservare immediatamente.
Questa distinzione cambia il modo in cui gli acquirenti dovrebbero leggere la notizia. La disponibilità generale definisce un'offerta commerciale, mentre la scala del deployment riguarda fornitura, costruzione e adozione da parte dei clienti. Nessuna delle due espressioni, da sola, stabilisce le prestazioni delle applicazioni.
L'offerta standalone cambia inoltre il rapporto di Nvidia con i potenziali clienti. Un team può valutare la sua CPU per un servizio senza decidere prima di distribuire un sistema Rubin completo. Il processore deve quindi giustificarsi in base ai requisiti propri del servizio.
Ciò crea un confronto più impegnativo rispetto alla decisione di aggiungere un acceleratore. Gli acquirenti possono chiedersi se Vera gestisca la loro applicazione meglio dell'infrastruttura esistente, inclusi carichi di lavoro che non comunicano mai direttamente con le GPU Rubin.
La competizione che ne deriva ruota attorno a una nota questione aziendale: quale configurazione di server esegue il lavoro richiesto con uno sforzo operativo accettabile? Il posizionamento IA di Nvidia attira l'attenzione, ma il comportamento ordinario delle applicazioni determinerà dove si inserirà il processore.
La pressione ricade sui servizi tra le chiamate al modello
Vera standalone esercita pressione competitiva sui servizi CPU che determinano la rapidità con cui un'applicazione IA può continuare a lavorare.
Un agente IA è un software che utilizza gli output del modello per selezionare ed eseguire azioni. La sua applicazione può recuperare informazioni, eseguire programmi, ispezionare risultati e richiedere un'altra risposta del modello. Ogni azione introduce dipendenze che un modello più veloce da solo non può eliminare.
Supponiamo che un assistente debba cercare documenti interni prima di rispondere a una domanda tecnica. La sua risposta dipende dal completamento del recupero, dalla verifica delle autorizzazioni e dall'arrivo dei risultati al modello. Una capacità aggiuntiva del modello fa poco per un ritardo all'interno di quel servizio di recupero.
Lo stesso ragionamento si applica all'esecuzione del codice. Un modello può generare rapidamente un test mentre l'applicazione attende un ambiente di esecuzione occupato. Migliorare quell'ambiente diventa utile quando i ritardi di esecuzione rappresentano una quota significativa dell'attività complessiva.
Oracle identifica questi servizi circostanti tra i propri carichi di lavoro CPU agentici. I suoi esempi includono esecuzione di strumenti, recupero, analisi e applicazioni operative. Si tratta di adattamenti di carico di lavoro proposti, non di garanzie che ogni deployment ne tragga vantaggio.
La pressione immediata ricade sui team infrastrutturali che selezionano la prossima piattaforma per questi servizi. Devono stabilire se le loro applicazioni trascorrano il tempo elaborando, spostando dati in memoria, accedendo allo storage o attendendo un altro sistema. Ogni collo di bottiglia indica un investimento diverso.
Intel e AMD restano rilevanti perché gli acquirenti dispongono già di software, procedure di deployment ed esperienza operativa costruiti attorno ai loro processori. Questo investimento esistente ha un valore pratico. Un processore concorrente deve offrire vantaggi sufficienti a giustificare l'introduzione di un altro ambiente supportato.
Il confronto va quindi oltre una classifica dei benchmark. Un servizio più veloce che richiede modifiche estese all'applicazione affronta una decisione di adozione diversa rispetto a uno che esegue il software esistente con adattamenti minimi.
Oracle ha inoltre un incentivo a distinguere attentamente i servizi. I clienti hanno bisogno di infrastrutture che supportino il loro mix di carichi di lavoro, anziché di una singola raccomandazione sul processore applicata a ogni applicazione. Un catalogo più ampio crea più scelte e più lavoro di valutazione.
Per gli sviluppatori, questo cambia il punto di partenza delle discussioni sull'ottimizzazione. Prima di scegliere l'hardware, un team necessita di prove che mostrino quale parte dell'applicazione ritardi i risultati utili. In caso contrario, una CPU promettente diventa una risposta a un problema non identificato.
Per gli acquirenti aziendali, la conseguenza è simile. Una proposta di infrastruttura IA dovrebbe considerare l'esecuzione delle applicazioni accanto al serving dei modelli. Valutare solo il modello rischia di trascurare i sistemi che determinano se gli utenti ricevano risultati completi e tempestivi.
La pressione è più forte dove questi servizi circostanti faticano già sotto concorrenza, ovvero con molte attività in esecuzione contemporaneamente. È qui che il comportamento del processore sotto carico sostenuto diventa più rilevante di una dimostrazione isolata.
La larghezza di banda della memoria della CPU Vera punta a uno specifico collo di bottiglia
L'argomentazione architetturale di Vera parte dal mantenere i core CPU riforniti di dati, anziché trattare il numero di core come prova sufficiente delle prestazioni.
La larghezza di banda della memoria misura quanti dati un sistema può trasferire dalla memoria nel tempo. Le applicazioni che elaborano ripetutamente grandi set di dati possono raggiungere questo limite prima di esaurire la capacità aritmetica. Aggiungere risorse di elaborazione offre quindi un aiuto limitato, a meno che non migliori la consegna dei dati.
La descrizione dell'architettura di memoria Vera di Nvidia specifica 88 core, 176 thread e fino a 1,2 terabyte al secondo di larghezza di banda della memoria. I thread sono percorsi di esecuzione che consentono al software di distribuire il lavoro tra le risorse di elaborazione disponibili.
Il chip utilizza LPDDR5X, una tecnologia di memoria a basso consumo. Nvidia descrive inoltre un fabric di coerenza di seconda generazione, l'interconnessione interna che mantiene dati condivisi coerenti all'interno del processore. La sua larghezza di banda di bisezione dichiarata è di 3,4 terabyte al secondo.
Questi dati sulla larghezza di banda descrivono parti diverse del sistema. Il traffico verso la memoria esterna e la comunicazione interna svolgono funzioni correlate, ma le loro valutazioni non possono essere sostituite l'una con l'altra. Nessuna delle due specifiche indica direttamente la rapidità con cui un'applicazione viene completata.
La larghezza di banda della memoria della CPU Vera diventa rilevante quando il lavoro utile dipende dall'accesso ripetuto a dati oltre le piccole e veloci cache del processore. Una cache conserva vicino alle risorse di esecuzione le informazioni usate di frequente, riducendo la necessità di recuperarle dalla memoria principale.
Un servizio analitico esemplificativo potrebbe analizzare ripetutamente un set di dati operativo mentre risponde a richieste concorrenti. Se queste scansioni saturano i trasferimenti di memoria, una larghezza di banda aggiuntiva offre una via plausibile verso un throughput più elevato. Il throughput misura il lavoro completato nel tempo.
Un'altra applicazione potrebbe trascorrere la maggior parte del tempo in attesa dello storage remoto. Lo stesso miglioramento della memoria affronterebbe una porzione minore del suo ritardo. Ecco perché le caratteristiche del carico di lavoro contano più dell'etichetta di categoria attribuita al software.
Anche la compatibilità Arm rientra in questa valutazione. Arm è l'architettura delle istruzioni del processore supportata da Vera, che definisce le istruzioni che il software può eseguire. Le applicazioni esistenti e le loro dipendenze necessitano di build compatibili prima che le loro prestazioni diventino un confronto utile.
Un servizio scritto in un linguaggio portabile può comunque dipendere da componenti specifici dell'architettura. Estensioni di database, software di sicurezza e librerie compilate meritano attenzione. L'avvio riuscito di un'applicazione non stabilisce che ogni dipendenza segua lo stesso percorso ottimizzato.
Questo è il meccanismo centrale alla base dell'opportunità di Nvidia: offrire un processore le cui caratteristiche di consegna dei dati ed esecuzione si adattino a servizi di valore. È una proposta più specifica della sostituzione di tutte le CPU aziendali.
Il caso architetturale stabilisce un motivo per testare Vera. Non risolve la decisione d'acquisto, perché il comportamento del software, la configurazione del deployment e l'utilizzo sostenuto determinano quanta parte di questa capacità raggiunga gli utenti.
I benchmark Vera vs Xeon stabiliscono un vantaggio con confini chiari
Il risultato di Tom’s Hardware supporta un vantaggio nella larghezza di banda della memoria nella configurazione testata, lasciando però non misurate le prestazioni delle applicazioni su OCI.
I benchmark della memoria dei server della pubblicazione confrontano Vera con un sistema dual Intel Xeon 6980P. Riportano oltre il doppio della larghezza di banda in STREAM triad, un benchmark che misura i trasferimenti di memoria sostenuti tramite operazioni su array.
Il sistema Vera testato utilizzava memoria LPDDR5X-9600. Il confronto con Xeon impiegava MRDIMM, moduli di memoria progettati per velocità di trasferimento più elevate, operanti a 8.800 megatransfer al secondo. Questi dettagli di configurazione aiutano a definire l’ambito del risultato.
Tom’s Hardware riferisce inoltre che il posizionamento dei thread ha influenzato in modo sostanziale la larghezza di banda di Vera. È stata utilizzata una policy OpenMP spread, un’impostazione che distribuisce i thread di esecuzione parallela tra le risorse di elaborazione. La pubblicazione ha dichiarato che ulteriori dettagli sulla configurazione dei test accompagneranno la sua prossima recensione.
Questi risultati sono rilevanti perché mostrano un vantaggio misurato che va oltre una specifica del produttore. Tuttavia, la misurazione risponde a una domanda più circoscritta rispetto a quella se Vera renda un’intera applicazione due volte più veloce.
Un servizio può combinare elaborazione in memoria con accesso allo storage, comunicazione di rete ed esecuzione seriale. Per esecuzione seriale si intende il lavoro che deve avvenire in sequenza. Migliorare un componente lascia invariati quelli rimanenti.
Questa distinzione è particolarmente pertinente per gli agenti. Un workflow potrebbe eseguire brevemente un’operazione ad alta intensità di memoria, per poi attendere molto più a lungo uno strumento esterno. Il tempo di completamento totale rifletterebbe entrambe le fasi, indipendentemente dalla posizione del processore nei benchmark.
Il confronto Vera vs Xeon coinvolge inoltre configurazioni complete. Il risultato misurato riflette processori, memoria, software e ottimizzazione che operano insieme. Gli acquirenti dovrebbero evitare di attribuire l’intera differenza a una singola caratteristica architetturale.
Il posizionamento dei thread aggiunge un ulteriore motivo per esaminare l’ambiente. Una policy di posizionamento favorevole in laboratorio potrebbe richiedere una configurazione esplicita in produzione. Le macchine virtuali, che dividono i server fisici in ambienti software isolati, introducono un ulteriore livello di deployment da valutare.
Un confronto equo dovrebbe consentire un’ottimizzazione ragionevole su ciascuna piattaforma. Lasciare un concorrente con impostazioni inadatte misurerebbe le scelte di configurazione insieme alle differenze hardware. Al contrario, richiedere una manutenzione insolita per mantenere un risultato introduce un onere operativo che vale la pena documentare.
Il benchmark pubblicato non stabilisce una classifica dell’efficienza energetica. Ciò richiede misurazioni del consumo energetico mentre i sistemi svolgono un lavoro comparabile. Un risultato sulla larghezza di banda da solo non può rivelare quanta energia consumi un’attività applicativa completata.
Non stabilisce neppure un vincitore universale tra database, compilazione o server applicativi. Carichi di lavoro diversi sollecitano risorse diverse, anche quando condividono un linguaggio o un framework di deployment.
La larghezza di banda della memoria della CPU Vera merita quindi attenzione come punto di forza dimostrato nella configurazione riportata. Il successivo passo probatorio consiste nel tradurre questo punto di forza in risultati applicativi ripetibili sul servizio effettivo che gli acquirenti possono distribuire.
Il rollout di Oracle lascia spazio a Intel e richiede verifiche sul deployment
Oracle sta aggiungendo Vera mantenendo al contempo un percorso basato su Intel per i sistemi Rubin, rendendo la scelta in base al carico di lavoro più credibile rispetto alla narrativa di una sostituzione totale.
La configurazione HGX Rubin NVL8 pianificata combina otto GPU Rubin con due processori Intel Xeon 6 a 64 core e 4 terabyte di memoria DDR5. DDR5 è una generazione ampiamente utilizzata di tecnologia di memoria per server. Questa offerta pianificata mantiene un percorso applicativo x86 accanto a Vera.
X86 è l’architettura di istruzioni utilizzata dai processori server Intel e AMD discussi qui. Mantenere questa opzione è importante per le applicazioni con requisiti software esistenti, anche quando un altro processore produce risultati migliori in test selezionati.
La più ampia roadmap infrastrutturale di Oracle cita inoltre il proseguimento del lavoro con AMD e Intel. Elenca istanze AMD EPYC E7 pianificate e offerte X14 basate su Intel Diamond Rapids. Si tratta ancora di elementi della roadmap, non di alternative già disponibili stabilite da questo annuncio.
Il contesto competitivo è di conseguenza più complesso di Nvidia che entra e delle CPU incumbent che escono di scena. Oracle sta ampliando le combinazioni disponibili di processori e acceleratori. Gli acquirenti possono separare la compatibilità delle applicazioni dalla scelta dell’hardware per il serving dei modelli.
La disponibilità stessa richiede una lettura attenta. Le dettagliate specifiche delle istanze Vera di Oracle descrivono offerte sia bare-metal sia di macchine virtuali Flex. Il bare metal consente a un cliente l’uso diretto di un server fisico, anziché di una porzione virtualizzata.
La configurazione a doppio processore descritta offre 176 core, 352 thread e 1 terabyte di memoria di sistema. Questi dettagli delle istanze devono essere distinti dalle specifiche di un singolo processore.
Il post di Oracle sulle CPU annuncia la disponibilità generale, ma afferma anche che le istanze raggiungeranno regioni selezionate in questo trimestre. Questa formulazione lascia una questione pratica su quando un determinato cliente potrà ottenere capacità adeguata in una località richiesta.
Un impegno regionale è importante per le organizzazioni con requisiti di residenza dei dati. Un processore disponibile altrove non risolve un deployment limitato a una giurisdizione specifica. Anche la capacità deve essere sufficiente per il servizio previsto, anziché essere semplicemente accessibile per una valutazione.
Oracle afferma inoltre che inizialmente saranno resi disponibili 150.000 CPU nelle sue regioni. L’annuncio non fornisce un’allocazione regione per regione né prove che ogni unità elencata stia già servendo carichi di lavoro dei clienti.
Le sue dichiarazioni sulle prestazioni richiedono una separazione analoga. Oracle cita l’affermazione di Nvidia secondo cui le prestazioni CPU agentiche sarebbero fino all’80% più veloci, identificando però tali risultati come benchmark della piattaforma. Non sono misurazioni a livello di istanza OCI.
Questa divulgazione limita il grado di sicurezza con cui gli acquirenti possono tradurre l’affermazione in una previsione per il servizio. La risposta appropriata è testare insieme l’istanza prevista, la build dell’applicazione e le impostazioni operative.
Il lavoro di migrazione rientra in questa valutazione. Un team necessita di dipendenze compatibili, immagini di deployment, monitoraggio e procedure di ripristino prima di spostare un servizio importante. Questi requisiti non screditano l’hardware; definiscono il lavoro necessario per utilizzarlo in modo affidabile.
Il caso di adozione più forte combina miglioramenti applicativi con cambiamenti operativi gestibili. Un vantaggio del processore che supera queste verifiche merita maggiore peso rispetto a uno visibile solo in condizioni che il cliente non può riprodurre.
Tre segnali mostreranno se Vera standalone otterrà un’adozione più ampia
Le prossime evidenze dovrebbero stabilire capacità accessibile, prestazioni applicative riproducibili e utilizzo sostenuto oltre le prime valutazioni.
Il primo segnale è una disponibilità regionale più chiara. Nei prossimi mesi, gli acquirenti dovrebbero cercare accesso alle istanze documentato nelle località richieste dalle loro applicazioni. Un rollout che supporti deployment ripetibili rafforzerebbe il caso di Vera come opzione infrastrutturale pratica.
Le informazioni sulla capacità dovrebbero descrivere ciò che i clienti possono ottenere, anziché soltanto ciò che Oracle intende distribuire. Accesso alle prenotazioni, limiti di servizio e documentazione della configurazione aiutano a collegare un annuncio di lancio a una decisione operativa.
Il secondo segnale è un testing indipendente e riproducibile delle applicazioni OCI. Dovrebbe confrontare servizi che svolgono lavoro equivalente, con build software compatibili e impostazioni chiaramente documentate. I risultati più utili mostrerebbero sia il lavoro completato sia i tempi di risposta con concorrenza sostenuta.
Il tempo di risposta merita particolare attenzione in prossimità della saturazione. Un server può riportare un throughput medio interessante mentre una minoranza di richieste attende molto più a lungo. Questi ritardi possono influenzare gli utenti i cui workflow dipendono dal completamento di ogni chiamata a uno strumento.
Per la questione Vera vs Xeon, il lavoro equivalente conta più di categorie di marketing identiche. I test dovrebbero spiegare la configurazione della memoria, l’ottimizzazione del software e l’allocazione delle risorse. Altrimenti, i lettori non possono capire se un risultato si estenda oltre la configurazione testata.
L’evidenza che il vantaggio di larghezza di banda riportato migliori i servizi ad alta intensità di memoria rafforzerebbe l’argomento architetturale. Risultati dominati da colli di bottiglia non correlati restringerebbero l’insieme delle applicazioni in cui tale argomento si applica.
Il terzo segnale è un’adozione sostenuta in produzione con risultati dei carichi di lavoro divulgati. La partecipazione dei clienti è utile, ma un deployment nominato da solo fornisce evidenze limitate su prestazioni o impegno operativo. Le descrizioni dell’applicazione e del suo comportamento misurato sarebbero più informative.
Resoconti utili spiegherebbero perché un servizio è stato spostato, cosa è cambiato dopo il deployment e quali limitazioni sono rimaste. Dovrebbero inoltre distinguere gli effetti del processore dai cambiamenti simultanei a software, storage o progettazione dell’applicazione.
Un’adozione più ampia tra servizi adatti sosterrebbe il caso di Nvidia per un’attività CPU indipendente nell’infrastruttura cloud. Una concentrazione in un insieme limitato di deployment specializzati indicherebbe un ruolo più ristretto. Entrambi gli esiti possono coesistere con solidi risultati nei benchmark di memoria.
Per gli sviluppatori, l’azione immediata consiste nel misurare le fasi dipendenti dalla CPU già presenti nelle loro applicazioni. Identificate i punti in cui l’esecuzione si blocca, preservate un carico di lavoro rappresentativo e documentate l’ambiente. Questo crea una base utile prima di valutare un altro processore.
I team possono organizzare questi risultati in una base di conoscenza ricercabile, mantenendo le note di configurazione collegate ai risultati applicativi. Lo scopo è preservare il contesto quando confronti successivi producono esiti diversi.
Nvidia Vera su OCI merita una valutazione laddove il traffico di memoria o l’esecuzione della CPU limitino già il lavoro utile. Iniziate con un servizio il cui collo di bottiglia sia misurato, quindi confrontate deployment completi sotto un carico rappresentativo. Mantenete esplicite le versioni delle applicazioni, le scelte di ottimizzazione e le allocazioni delle risorse. Chiedetevi se eventuali guadagni persistano durante i periodi di maggiore attività e se il team possa gestire il servizio in modo affidabile. Richiedete evidenze sulla capacità regionale prima di considerare la disponibilità consolidata. Separate le affermazioni del produttore dalle misurazioni indipendenti e preservate i limiti di ciascun risultato. La domanda utile per l’acquisto è concreta: questo processore migliora il lavoro che la vostra applicazione svolge realmente, in condizioni che il vostro team può riprodurre?
