Il debutto di NVIDIA Vera Rubin in MLPerf detta il ritmo, ma lo status di anteprima conta
NVIDIA è entrata in MLPerf Inference v6.1 con Vera Rubin NVL72, riportando un throughput fino a 3,7 volte superiore rispetto al predecessore GB300 NVL72. Il debutto di NVIDIA Vera Rubin in MLPerf offre agli acquirenti di infrastrutture la prima valutazione tra pari della prossima piattaforma AI rack-scale dell'azienda. Accanto al dato principale, però, emerge un limite importante: Vera Rubin rimane un sistema in anteprima.
Questa distinzione definisce la vera competizione. NVIDIA non sta semplicemente confrontando una generazione di GPU con un'altra. Sostiene invece che rack strettamente integrati possano trasformare nuovi chip, networking e software di serving in una migliore economia dell'inferenza.
La più ampia presentazione MLPerf di AMD fino a oggi mostra perché questa tesi è ora sotto pressione. AMD ha pubblicato risultati competitivi su hardware disponibile, ampliato la copertura dei workload e evidenziato implementazioni che raggiungono 512 acceleratori. NVIDIA guida i confronti selezionati con Vera Rubin, ma i clienti devono stabilire se il vantaggio di un sistema in anteprima si traduca in valore concretamente implementabile.
I risultati MLPerf di NVIDIA Vera Rubin stabiliscono un vantaggio iniziale
Il debutto evidenzia un ampio guadagno prestazionale generazionale su due modelli impegnativi, sebbene non rappresenti ancora una piattaforma di produzione commercializzata.
I risultati sono arrivati il 16 settembre 2026, nell'ambito della pubblicazione MLPerf v6.1. MLPerf Inference misura come i sistemi servono modelli AI addestrati in condizioni standardizzate di accuratezza e latenza.
MLCommons ha riportato un record di 30 organizzazioni partecipanti in questo ciclo. Sono comparsi cinque nuovi processori o acceleratori, inclusi MI350P di AMD, già disponibile, e Arc Pro B70 di Intel. NVIDIA Rubin e Vera Rubin NVL72 sono entrati come sistemi in anteprima.
NVIDIA ha presentato risultati Vera Rubin per DeepSeek-R1 e Qwen3-VL-235B. DeepSeek-R1 testa il serving di modelli di ragionamento, mentre Qwen3-VL combina input linguistici e visivi per attività quali la classificazione dei prodotti.
I risultati Vera Rubin dell'azienda mostrano il maggiore guadagno relativo nello scenario interattivo di Qwen3-VL. In questo caso, un Vera Rubin NVL72 ha fornito 1.307 query al secondo. Un risultato comparabile per GB300 NVL72 ha raggiunto 349 query al secondo.
Ne deriva l'aumento in evidenza di circa 3,7 volte. Lo scenario interattivo impone inoltre un limite di latenza di 1,5 secondi, rendendo il risultato più rilevante del throughput batch senza vincoli per applicazioni reattive.
Il vantaggio era minore, ma comunque sostanziale, negli altri scenari Qwen3-VL. Vera Rubin ha raggiunto 2.393 campioni al secondo offline, rispetto ai 1.305 di GB300. Il risultato server ha raggiunto 2.323 query al secondo, rispetto a 1.210.
Questi risultati equivalgono a un throughput offline superiore di circa 1,8 volte e a un throughput server superiore di 1,9 volte. La differenza mostra perché un singolo moltiplicatore massimo non può descrivere l'intero sistema.
Su DeepSeek-R1, Vera Rubin ha registrato 652.750 token al secondo nello scenario interattivo. Un risultato GB300 NVL72 con 72 GPU ha raggiunto 260.098 token al secondo con gli stessi vincoli di latenza pubblicati.
Questo confronto supporta l'affermazione di NVIDIA di un throughput DeepSeek-R1 fino a 2,5 volte superiore. NVIDIA ha usato TensorRT-LLM per questo workload, mentre la presentazione Qwen3-VL ha impiegato vLLM con NVIDIA Dynamo.
La tabella delle prestazioni pubblicata riporta inoltre le soglie di accuratezza accanto a ciascun risultato. La voce Vera Rubin per DeepSeek-R1 punta al 99 percento dell'accuratezza FP16, con un punteggio di corrispondenza esatta dell'81,9132 percento.
Per Qwen3-VL, l'obiettivo era il 99 percento della qualità BF16. Il benchmark richiedeva un punteggio F1 gerarchico di categoria di almeno 0,7824 utilizzando un dataset del catalogo prodotti Shopify.
Queste soglie contano perché un'inferenza più rapida ha valore limitato se una compressione numerica aggressiva danneggia l'output del modello. MLPerf richiede che le presentazioni soddisfino soglie di qualità definite prima che i relativi dati prestazionali siano conteggiati.
Tuttavia, il debutto copre soltanto due modelli di benchmark. Non stabilisce la leadership in ogni workload linguistico, di raccomandazione, video, vocale o di retrieval in MLPerf Inference v6.1.
Questa portata più ristretta non è insolita per hardware in anteprima. Significa però che gli acquirenti dovrebbero interpretare il risultato come un primo segnale di sistema, non come un verdetto universale.
Perché un throughput maggiore cambia l'economia dell'inferenza AI
Le prestazioni dell'inferenza contano finanziariamente quando un throughput aggiuntivo serve più richieste utili senza aumentare in modo proporzionale hardware, energia o complessità operativa.
L'addestramento produce un modello, ma l'inferenza viene eseguita ogni volta che quel modello risponde a un utente. Un assistente per consumatori, un agente di coding, un servizio di ricerca o un sistema documentale possono attivare numerose chiamate di inferenza durante un singolo compito.
Gli agenti di ragionamento intensificano questo schema. Generano token intermedi, chiamano strumenti, esaminano i risultati e rivedono i propri piani. Una risposta visibile può richiedere diversi passaggi del modello dietro l'interfaccia.
Questo comportamento rende i token al secondo economicamente importanti. Un sistema più veloce può servire più richieste concorrenti, ridurre le code o fornire tracce di ragionamento più lunghe nella stessa finestra temporale.
Tuttavia, il throughput massimo è solo una parte del calcolo. Gli acquirenti necessitano anche di una latenza di risposta accettabile, accuratezza costante, utilizzo elevato, domanda energetica gestibile e software affidabile.
MLPerf separa diversi scenari di implementazione per questo motivo. Lo scenario offline enfatizza l'elaborazione in massa. Lo scenario server modella richieste in arrivo variabili, mentre quello interattivo impone requisiti di reattività più stringenti.
La più forte prestazione relativa di Vera Rubin appare in questo contesto interattivo sensibile alla latenza. Ciò suggerisce che i suoi miglioramenti architetturali diventino particolarmente preziosi quando un sistema non può nascondere i ritardi dietro grandi batch.
L'esito è rilevante per i prodotti che fanno pagare l'accesso, il consumo o il lavoro completato. Se un rack gestisce più richieste a un livello di servizio richiesto, l'operatore ottiene maggiore capacità da quell'infrastruttura.
Eppure il throughput non equivale automaticamente a ricavi. Deve esistere domanda, il software deve mantenere gli acceleratori occupati e il servizio completo deve evitare colli di bottiglia al di fuori del server del modello.
Storage, fabric di rete, database, filtri di sicurezza e logica applicativa possono tutti limitare le prestazioni effettivamente erogate. Un benchmark isola il sistema in prova in modo più netto di quanto possano fare la maggior parte degli ambienti di produzione.
Anche il costo per token è più complesso della semplice divisione del costo delle apparecchiature per il throughput di picco. Include elettricità, raffreddamento, networking, manutenzione, finanziamento, ingegneria del software, tempi di inattività e ammortamento.
NVIDIA afferma che Vera Rubin riduce i costi per token, ma la pubblicazione v6.1 non presenta un confronto completo del costo totale di proprietà in produzione. Il benchmark fornisce evidenze sulle prestazioni, non un modello d'acquisto completo.
I team infrastrutturali dovrebbero quindi tradurre questi risultati nei propri profili di traffico. Un servizio visivo di ricerca prodotti potrebbe concentrarsi sul throughput server di Qwen3-VL. Una piattaforma di ragionamento potrebbe dare priorità alla latenza e alla generazione di token di DeepSeek-R1.
Il risultato diventa più prezioso quando il benchmark assomiglia al workload dell'acquirente. Diventa meno decisivo quando architettura del modello, lunghezza delle richieste, comportamento di batching o vincoli del servizio differiscono in modo sostanziale.
Questa è la pressione economica che i concorrenti di NVIDIA devono affrontare. Non devono vincere ogni grafico, ma devono offrire abbastanza prestazioni implementabili, maturità software e flessibilità da produrre un business case complessivamente migliore.
Il codesign rack-scale è il meccanismo delle prestazioni
Il vantaggio di Vera Rubin deriva dal trattare 72 GPU, CPU, memoria, networking e software di inferenza come un unico sistema coordinato.
Un rack NVL72 collega 72 acceleratori all'interno di un dominio scale-up ad alta larghezza di banda. Il networking scale-up consente a questi acceleratori di cooperare come parti di un unico grande sistema anziché comportarsi come server isolati.
NVIDIA afferma che NVLink e NVLink Switch di sesta generazione offrano tassi di pacchetti 10 volte superiori rispetto a Ethernet standard. L'azienda dichiara inoltre una latenza tre volte inferiore nel confronto pertinente.
Queste affermazioni sull'interconnessione provengono da NVIDIA e non dovrebbero essere trattate come benchmark di rete indipendenti. Ciononostante, spiegano la scelta progettuale alla base del sistema presentato.
I grandi modelli di ragionamento e visione-linguaggio spostano quantità sostanziali di dati durante l'inferenza. Pesi del modello, attivazioni, stati di attenzione e decisioni di routing devono raggiungere rapidamente le risorse di calcolo corrette.
Vera Rubin utilizza HBM4, una generazione di memoria ad alta larghezza di banda collocata vicino alla GPU. La configurazione rack di NVIDIA include 72 GPU Rubin e 36 CPU Vera, secondo l'architettura pubblicata.
Il software suddivide quindi il lavoro tra queste risorse. Il serving disaggregato separa prefill e decode, consentendo a risorse differenti di specializzarsi in fasi distinte della generazione di testo.
Il prefill elabora l'input dell'utente e costruisce lo stato di attenzione interno del modello. Il decode genera la risposta token per token, spesso con vincoli di memoria e latenza diversi.
La separazione di queste fasi può migliorare l'utilizzo quando il software assegna ciascuna di esse alle risorse appropriate. Può anche creare overhead di coordinamento, rendendo cruciali interconnessioni veloci e una pianificazione efficace.
Le presentazioni di NVIDIA hanno utilizzato parallelismo degli esperti su larga scala per modelli mixture-of-experts. Questo design del modello attiva solo livelli esperti selezionati per ciascun token anziché eseguire ogni volta l'intera rete.
L'approccio può ridurre il calcolo, ma crea comunicazioni irregolari. I token devono essere instradati verso gli esperti corretti, elaborati e restituiti senza che i ritardi di rete annullino i risparmi.
L'aritmetica a precisione ridotta costituisce un'altra parte del meccanismo. NVIDIA ha utilizzato NVFP4, un formato numerico a quattro bit concepito per ridurre l'uso della memoria e aumentare il throughput computazionale.
Il sistema ha applicato precisione ridotta ai pesi, alle operazioni di attenzione e alla cache key-value. Una cache key-value conserva informazioni di attenzione precedenti affinché il modello non ricalcoli l'intera conversazione per ogni nuovo token.
La precisione ridotta consente a più dati di entrare in memoria e riduce il movimento tra unità di calcolo. Le soglie di accuratezza di MLPerf forniscono una protezione contro perdite di qualità inaccettabili.
La cifra prestazionale finale non è quindi una misurazione pura del silicio Rubin. Riflette processori, memoria, networking, formati numerici, kernel, framework di serving e ottimizzazioni specifiche per il benchmark.
Questo è centrale nella strategia di NVIDIA. L'azienda vuole che i clienti valutino l'intera piattaforma perché il suo vantaggio competitivo si estende oltre le specifiche dei singoli acceleratori.
La strategia può creare vantaggi per gli operatori che cercano uno stack unico supportato. Può anche aumentare la dipendenza dall'ambiente hardware e software strettamente connesso di NVIDIA.
Per gli acquirenti, questa dipendenza non è automaticamente negativa. Una piattaforma coordinata può ridurre il lavoro di integrazione e produrre prestazioni prevedibili su sistemi qualificati.
Il compromesso emerge quando i clienti desiderano una maggiore scelta hardware, software portabile o controllo indipendente sui singoli componenti. È qui che l'approccio concorrente di AMD diventa rilevante.
AMD mette sotto pressione la narrazione della piattaforma con hardware disponibile
La performance di AMD nella v6.1 non annulla i vantaggi selezionati di Vera Rubin, ma impedisce a NVIDIA di dominare senza opposizione la più ampia narrativa dell'inferenza.
AMD è passata da tre famiglie di modelli in MLPerf Inference v6.0 a sei nella v6.1. I suoi risultati hanno coperto carichi di lavoro di linguaggio, ragionamento, raccomandazione e text-to-video sugli acceleratori MI355X, MI350X e MI350P.
La submission di MLPerf dell'azienda evidenzia prestazioni competitive con otto GPU su GPT-OSS-120B. AMD afferma che MI355X ha superato specifiche submission NVIDIA B200 e B300 negli scenari offline e server.
AMD ha inoltre riportato miglioramenti derivanti dal lavoro sul software a parità di hardware MI355X. Il throughput server di GPT-OSS-120B con otto GPU è aumentato del 38% rispetto al round precedente.
Il throughput offline è salito del 28%, mentre le prestazioni single-stream di Wan 2.2 sono migliorate del 70%. Si tratta dei confronti effettuati da AMD tra i risultati sottoposti per v6.1 e v6.0.
Lo stesso schema sostiene uno degli argomenti centrali di NVIDIA. L'hardware, da solo, non determina il valore nel ciclo di vita di un sistema di inferenza. I miglioramenti software possono sbloccare più lavoro utile dopo il deployment.
AMD ha raggiunto un'efficienza di scalabilità del 95% con 72 GPU MI355X su GPT-OSS-120B. L'efficienza di scalabilità misura quanto la crescita del throughput segua da vicino l'aggiunta di acceleratori.
Crusoe ha poi sottoposto un sistema AMD con 512 GPU. Ha prodotto 5,75 milioni di token offline al secondo su GPT-OSS-120B e 2,90 milioni su DeepSeek-R1, secondo AMD.
All'epoca, era il maggior numero di acceleratori sottoposto a MLPerf Inference. Illustra inoltre una via concorrente alla scalabilità, basata su grandi cluster e un ambiente software aperto.
Il confronto con Vera Rubin non è diretto. Submission diverse possono utilizzare modelli, dimensioni di sistema, scenari e ottimizzazioni approvate differenti.
Un risultato aggregato con 512 acceleratori non dimostra un'economia per rack migliore rispetto a un sistema Vera Rubin con 72 GPU. Analogamente, il vantaggio di Vera Rubin su Qwen3-VL non risolve la questione della competitività di AMD su GPT-OSS-120B.
Questa è una difficoltà comune nella lettura di MLPerf. Ogni fornitore può enfatizzare i carichi di lavoro, gli scenari e le dimensioni di sistema che rafforzano maggiormente la propria tesi.
MLCommons riduce questa libertà attraverso regole standard, soglie di accuratezza, revisione dei risultati e dettagli di configurazione pubblicati. Non può rendere identici sistemi diversi.
I confronti più utili mantengono costanti modello, scenario, obiettivo di latenza, requisito di accuratezza, numero di acceleratori e divisione. Le differenze al di fuori di queste variabili dovrebbero restare visibili.
La concorrenza va inoltre oltre NVIDIA e AMD. Google ha partecipato alla v6.1, Intel ha introdotto risultati per Arc Pro B70 e vari cloud provider hanno sottoposto sistemi partner.
I risultati di inferenza di Lambda dimostrano come i system builder possano ottenere ulteriori miglioramenti usando la stessa generazione di acceleratori. Il suo sistema Blackwell Ultra con quattro GPU è migliorato di quasi il 9% rispetto alla v6.0.
Lambda ha inoltre utilizzato una submission nella divisione open per eseguire un carico di lavoro edge-agentic con Kimi K2.6 su hardware datacenter. Secondo Lambda, il modello contiene oltre mille miliardi di parametri.
Queste submission rafforzano un punto più ampio. L'unità competitiva si sta spostando da un processore verso uno stack di servizi configurato che include modelli, framework, orchestrazione e infrastruttura.
NVIDIA offre attualmente la versione più integrata di questo stack. AMD cerca di indebolire l'assunto secondo cui l'integrazione richieda una piattaforma esclusivamente NVIDIA.
La pressione su NVIDIA, quindi, non consiste semplicemente nel rimanere la più veloce. Deve dimostrare che il suo vantaggio prestazionale genera un valore operativo sufficiente a giustificare l'impegno verso la sua architettura.
Cosa i risultati preview non dimostrano
L'affermazione più solida riguarda il throughput del benchmark verificato, mentre le affermazioni su costi, ricavi, disponibilità e leadership generale nei carichi di lavoro richiedono ulteriori prove.
MLCommons identifica Vera Rubin e Vera Rubin NVL72 come submission preview. Questa etichetta indica ai lettori che la piattaforma non viene rappresentata come l'AMD MI350P disponibile in questo round di risultati.
Lo status preview non rende un risultato non valido. MLPerf pubblica comunque la configurazione e applica il proprio processo di benchmark. Tuttavia, limita ciò che gli acquirenti possono dedurre sui sistemi commercialmente distribuiti.
L'hardware in produzione può incontrare vincoli che non emergono in una submission ingegneristica. Maturità del firmware, tassi di guasto, disponibilità dei componenti, raffreddamento, tempi di installazione e gestione della flotta influenzano tutti la capacità reale.
La submission Vera Rubin è arrivata inoltre da NVIDIA e dal partner Nebius. Una riproduzione più ampia tra system builder indipendenti fornirebbe prove più solide che le prestazioni si trasferiscano tra deployment diversi.
L'ecosistema NVIDIA di generazione precedente offre un precedente favorevole. Diciannove partner hanno partecipato con piattaforme NVIDIA alla v6.1, inclusi otto che utilizzavano sistemi Blackwell NVL72 multi-node.
Questa ampiezza suggerisce che NVIDIA sappia portare progetti ottimizzati attraverso una vasta rete di fornitori. Non garantisce che la configurazione preview di Vera Rubin arrivi invariata o nei tempi previsti ovunque.
La copertura dei carichi di lavoro crea un'altra incertezza. La piattaforma ha debuttato su DeepSeek-R1 e Qwen3-VL, due carichi adatti al suo design rack-scale e al suo stack software.
Non ha pubblicato risultati Vera Rubin su GPT-OSS-120B, raccomandazione, voce, generazione di immagini, RAG o Wan 2.2 nella divisione closed. I round futuri dovrebbero mostrare se il vantaggio si generalizza.
NVIDIA ha inoltre citato miglioramenti prestazionali post-scadenza su GPT-OSS-120B e DLRMv3. L'azienda ha dichiarato esplicitamente che MLCommons non aveva verificato quei risultati successivi.
Questi numeri dovrebbero restare al di fuori delle conclusioni dirette del benchmark finché non superano lo stesso processo di revisione. I test del fornitore possono indicare una direzione, ma non hanno lo stesso peso probatorio.
I dati energetici sono un altro elemento mancante nel confronto principale. Il throughput per rack conta, ma gli operatori spesso affrontano una capacità elettrica fissa prima di esaurire lo spazio a pavimento.
Un rack più veloce può comunque complicare i deployment se richiede una distribuzione di potenza più densa o un raffreddamento a liquido più impegnativo. Le prestazioni per watt determineranno quanto lavoro utile possa rientrare nel limite di una struttura.
NVIDIA sostiene che un throughput maggiore riduca il costo per token. Questa conclusione è plausibile quando gli altri fattori restano stabili, ma il risultato pubblicato non fornisce una contabilità completa dei costi.
Termini di acquisto, utilizzo, energia, manutenzione, finanziamento e lavoro software possono modificare il numero finale. Gli acquirenti necessitano di dati di produzione misurati sui propri carichi di lavoro.
Il benchmark non può neppure garantire la reattività per l'utente finale. Il serving del modello può essere rapido mentre retrieval, chiamate a strumenti, database o API esterne generano gran parte del ritardo.
MLPerf v6.1 inizia ad affrontare questa lacuna con nuovi test di retrieval-augmented generation ed edge-agentic. Più della metà dei partecipanti ha utilizzato il suo harness incentrato sulle API, che applica un'architettura client-server.
MLCommons afferma che questo harness supporterà una transizione verso MLPerf Endpoints per i test datacenter. Il cambiamento dovrebbe avvicinare le misurazioni a servizi distribuibili, anziché a motori di modelli isolati.
Questa evoluzione potrebbe rafforzare o indebolire la tesi della piattaforma NVIDIA. Uno stack strettamente integrato dovrebbe beneficiare della misurazione del servizio completo, ma le dipendenze esterne possono diluire i vantaggi grezzi degli acceleratori.
La lettura prudente è specifica. Vera Rubin ha ottenuto un notevole debutto preview, sottoposto a revisione, su DeepSeek-R1 e Qwen3-VL. Non ha ancora dimostrato una leadership universale né un'economia di produzione completa.
Tre segnali determineranno se il vantaggio reggerà
Il vantaggio iniziale di Vera Rubin diventa strategicamente importante solo se i sistemi in consegna lo riproducono su più carichi di lavoro e sotto vincoli operativi misurabili.
Il primo segnale è un'ampia disponibilità in produzione. I clienti dovrebbero cercare istanze cloud, sistemi partner e rack installati che espongano dettagli di configurazione comparabili con la submission preview.
Un rollout di successo dimostrerebbe che NVIDIA può trasformare un risultato ingegneristico ottimizzato in infrastruttura ripetibile. Ritardi o configurazioni sostanzialmente diverse indebolirebbero questa conclusione.
La disponibilità dovrebbe includere più di annunci di spedizione. Gli acquirenti necessitano di rilasci software stabili, networking qualificato, procedure di assistenza e prove che i sistemi sostengano le prestazioni per lunghi periodi operativi.
Il secondo segnale è il prossimo round di benchmark indipendente. Vera Rubin necessita di risultati oltre DeepSeek-R1 e Qwen3-VL, soprattutto su retrieval, raccomandazione, video e ulteriori modelli linguistici.
Una copertura più ampia sosterrebbe l'affermazione di NVIDIA secondo cui un'unica piattaforma possa gestire carichi di inferenza diversificati. Una copertura ristretta lascerebbe più spazio ad acceleratori specializzati e cluster concorrenti.
I futuri risultati di MLPerf Endpoints saranno particolarmente rivelatori. Dovrebbero misurare sistemi esposti via API che assomigliano più da vicino ai servizi acquistati e gestiti dalle imprese.
Occorre osservare se il throughput grezzo di Vera Rubin resista all'aggiunta dell'orchestrazione delle richieste, di componenti di retrieval e di confini di servizio realistici. Un vantaggio più ridotto suggerirebbe che i colli di bottiglia si siano spostati altrove.
Il terzo segnale è il progresso del software competitivo. I miglioramenti di AMD nella v6.1 mostrano che gli acceleratori installati possono ottenere prestazioni sostanziali senza una nuova generazione hardware.
Se ROCm, i framework open di serving e i sistemi partner continueranno a migliorare rapidamente, gli acquirenti potrebbero accettare prestazioni di picco inferiori in cambio di flessibilità o compatibilità con l'infrastruttura esistente.
Se il software NVIDIA migliora allo stesso ritmo, il vantaggio iniziale di Vera Rubin potrebbe amplificarsi. L'azienda ha già riportato un guadagno di 1,6 volte su Qwen3-VL per GB300 tra v6.0 e v6.1.
La velocità del software conta quindi due volte. Aumenta le prestazioni attuali e modifica il modo in cui i clienti stimano la vita utile di un sistema costoso.
I team di procurement dovrebbero richiedere risultati per i propri modelli esatti, lunghezze di contesto, modelli di batch e obiettivi di latenza. Dovrebbero inoltre testare guasti, upgrade e cambiamenti dei carichi di lavoro.
Gli sviluppatori dovrebbero osservare quali ottimizzazioni raggiungano i framework comuni senza richiedere un esteso lavoro personalizzato. Una tecnica ottimizzata per il benchmark crea un valore limitato se i team ordinari non possono distribuirla o mantenerla.
I responsabili di prodotto AI dovrebbero collegare le metriche infrastrutturali agli esiti per gli utenti. Un'inferenza più rapida può supportare latenza inferiore, più passaggi di ragionamento, maggiore concorrenza o richieste multimodali più lunghe.
Il risultato MLPerf di NVIDIA Vera Rubin presenta un'apertura credibile a favore del codesign rack-scale. Il suo confronto di picco pari a 3,7 volte è significativo, ma appartiene a uno scenario definito.
La decisione successiva non è se il benchmark preview sembri veloce. Lo è chiaramente. La decisione è se i sistemi in consegna conservino quel vantaggio dopo che energia, software, disponibilità e carichi di lavoro reali entreranno nell'equazione.
Chiedete ai fornitori di riprodurre il vostro obiettivo di livello di servizio più esigente prima di scegliere una piattaforma. Quindi confrontate insieme throughput sostenuto, latenza, accuratezza, utilizzo e impegno operativo. Questa valutazione rivelerà se il vantaggio di Vera Rubin nel benchmark si trasformerà in una duratura economia dell'inferenza o rimarrà un impressionante risultato preview.
