OpenAI SemiAnalysis Lens: Vera Rubin NVL72 supera GB200, ma il caso TCO è più circoscritto

Il Vera Rubin NVL72 di NVIDIA ha pubblicato i suoi primi risultati misurati sul silicio, dichiarando un throughput per megawatt dieci volte superiore a GB200 NVL72 a parità di interattività. Il collegamento OpenAI SemiAnalysis passa attraverso Triton, il cui supporto per Rubin contribuisce a rendere l'architettura accessibile al software AI più diffuso.

Il dato principale è convincente, ma confronta Rubin con una base software GB200 di inizio 2025. SemiAnalysis ha riscontrato un vantaggio più contenuto rispetto ai risultati Blackwell di luglio 2026, sebbene Rubin sia rimasta in testa nell'intero intervallo di interattività testato.

Questa distinzione definisce la vera competizione. Rubin non è semplicemente una GPU più veloce che sostituisce una GPU meno recente. È un sistema su scala rack progettato per sostenere un'inferenza reattiva quando dimensioni dei modelli, traffico di memoria e domanda di token aumentano insieme.

Il risultato mette pressione agli operatori GB200, ai fornitori concorrenti di acceleratori e agli sviluppatori che mantengono kernel personalizzati. Lascia inoltre un'importante lacuna di verifica. Il test iniziale ha utilizzato un rack con campioni ingegneristici, un modello di ragionamento meno recente e un carico di lavoro a turno singolo.

Il primo risultato di Rubin cambia il confronto NVL72

Il vantaggio iniziale di Rubin sembra reale, ma il dato di dieci volte rappresenta un confronto nel caso migliore, non un rapporto di prestazioni universale.

CoreWeave ha pubblicato il primo benchmark misurato sul silicio di Vera Rubin NVL72 il 21 luglio 2026. I suoi ingegneri hanno eseguito DeepSeek R1 su Rubin e GB200 NVL72 con le stesse principali ottimizzazioni di inferenza abilitate.

Il test ha misurato il throughput di token in output per megawatt rispetto all'interattività, espressa in token al secondo per ciascun utente. Questo aspetto conta perché un servizio di inferenza deve bilanciare la capacità complessiva con una velocità di risposta accettabile.

A parità di interattività, i risultati misurati sul silicio hanno mostrato fino a dieci volte più throughput di token in output per megawatt. Il confronto ha utilizzato una base GB200 NVL72 del 2025.

CoreWeave afferma che entrambi i sistemi utilizzavano precisione NVFP4, speculative decoding, parallelismo esteso degli esperti e prefill e decode disaggregati. TensorRT-LLM e NVIDIA Dynamo hanno fornito il software di serving.

NVFP4 è il formato numerico a quattro bit di NVIDIA per ridurre l'archiviazione e il calcolo dei modelli. Lo speculative decoding genera token candidati prima della verifica finale, aumentando la velocità di output quando le sue previsioni hanno successo.

Il serving disaggregato separa prefill e decode tra diversi gruppi di GPU. Il prefill elabora il prompt, mentre il decode genera la risposta un token alla volta.

Queste ottimizzazioni contano perché i risultati dei benchmark spesso misurano la qualità del software tanto quanto il silicio. Un kernel, uno scheduler o una ricetta di parallelizzazione meno recente può lasciare inutilizzata una parte significativa della capacità di una GPU.

SemiAnalysis ha adattato i propri dati InferenceX per allinearli alla contabilizzazione di CoreWeave. Il benchmark originale conteggiava l'alimentazione sia delle GPU di prefill sia di quelle di decode, riportando però soltanto i token in output.

Rispetto ai risultati GB300 NVL72 di luglio 2026, Rubin ha fornito quasi il doppio del throughput fino a 100 token al secondo per utente. Il suo vantaggio è salito a circa quattro volte intorno ai 200 token al secondo.

A 300 token al secondo, il rapporto riportato ha raggiunto 5,4 volte. Tuttavia, SemiAnalysis ha osservato che GB300 operava al limite della propria curva di prestazioni sostenibili.

GB200 non poteva raggiungere quel livello di interattività nella configurazione testata. Rubin ha continuato fino a 350 token al secondo, dove ha prodotto 70.703 token in output al secondo per megawatt.

Questo non invalida l'affermazione di CoreWeave. Il primo Rubin sostiene chiaramente un'interattività più elevata rispetto ai sistemi Blackwell misurati. Cambia però ciò che gli acquirenti dovrebbero dedurre dal dato principale.

Un valore di dieci volte descrive un singolo carico di lavoro, punto operativo, base software e metodo di contabilizzazione. Non significa che ogni implementazione Rubin sostituisca immediatamente dieci rack GB200.

La conclusione più solida è più circoscritta e più utile. Rubin mantiene l'efficienza quando il serving si sposta verso batch più piccoli e risposte individuali più rapide, ambiti in cui il throughput di Blackwell cala nettamente.

Questo comportamento influenza direttamente agenti di coding, sistemi di ricerca e applicazioni di sicurezza. Questi servizi generano molte chiamate sequenziali al modello, rendendo difficile nascondere la latenza con batch di grandi dimensioni.

Perché le prestazioni per megawatt contano ora più dei FLOPS di picco

La capacità elettrica è diventata un limite pratico, quindi i token utili per megawatt possono contare più del throughput aritmetico teorico.

Il conteggio dei FLOPS di picco di un acceleratore misura le sue operazioni in virgola mobile massime in condizioni specifiche. Non descrive l'efficienza con cui un rack completo serve un modello di ragionamento.

L'inferenza sposta pesi, attivazioni e dati della KV-cache tra memoria e unità di calcolo. La KV cache archivia le informazioni di attenzione dei token precedenti, evitando che il modello ricalcoli l'intera sequenza.

Contesti più lunghi ingrandiscono questa cache. I modelli mixture-of-experts inviano inoltre i token tra sottoreti specializzate, creando traffico di comunicazione tra le GPU.

Rubin affronta questi vincoli come sistema NVL72 completo. Il rack combina 72 GPU Rubin, 36 CPU Vera, networking ConnectX-9, processori BlueField-4 e switch NVLink 6.

NVIDIA indica 20,7 terabyte di memoria HBM4 nell'intero rack. Specifica inoltre 260 terabyte al secondo di banda aggregata degli switch NVLink 6.

Ogni GPU riceve 3,6 terabyte al secondo di banda scale-up all-to-all. Il networking scale-up collega gli acceleratori all'interno di un unico grande dominio di calcolo, consentendo loro di comportarsi come un dispositivo unificato.

Rubin affronta quindi l'efficienza dell'inferenza a più livelli. Operazioni tensoriali più rapide gestiscono l'algebra matriciale, HBM4 fornisce i pesi e NVLink sposta i token tra gli esperti.

Le CPU Vera gestiscono lo spostamento dei dati e le attività degli agenti che gravano sulla CPU. Queste possono includere chiamate a strumenti, compilazione del codice, orchestrazione ed esecuzione in sandbox.

Le specifiche NVL72 di NVIDIA dichiarano 3.600 petaflops di prestazioni di inferenza NVFP4 a livello rack. L'azienda dichiara inoltre un decimo del costo per token rispetto a GB200 NVL72.

Questi dati rimangono dichiarazioni aziendali dipendenti dal carico di lavoro. Tuttavia, l'architettura del rack spiega perché il vantaggio di Rubin cresce con l'aumento dell'interattività.

I batch di grandi dimensioni aiutano una GPU a rimanere occupata perché molti utenti condividono ogni caricamento dei pesi. Un servizio interattivo rapido riduce le opportunità di batching, aumentando la pressione sulla banda di memoria e sulla pianificazione.

La banda HBM4 di Rubin, pari a 22 terabyte al secondo per GPU, le offre più margine in queste condizioni. SemiAnalysis stima 2,8 volte la banda di memoria globale di Blackwell Ultra.

Una banda più elevata non riduce automaticamente la latenza della memoria. Sposta più dati al secondo, ma un singolo accesso può comunque richiedere un tempo simile.

Il vantaggio più ampio di Rubin ad alta interattività riflette quindi diversi meccanismi che lavorano insieme. Nessuna singola specifica di picco lo spiega completamente.

La metrica di potenza include anche le scelte infrastrutturali. Apparecchiature di raffreddamento, networking, processori host, storage e perdite di conversione consumano tutti elettricità oltre il package GPU.

NVIDIA ha progettato Rubin per il refrigerante liquido in ingresso a 45 gradi Celsius. Nelle strutture compatibili, questa temperatura supporta il dry cooling senza chiller tradizionali.

L'azienda afferma che il suo approccio a circuito chiuso può ridurre il consumo idrico e l'overhead di raffreddamento. Questi vantaggi dipendono dalla progettazione della struttura e non dovrebbero essere presunti per ogni data center esistente.

SemiAnalysis ha utilizzato la stessa ipotesi di power usage effectiveness per i sistemi raffreddati a liquido. Questa scelta conservativa impedisce che la progettazione delle strutture di Rubin gonfi il confronto sul silicio.

Il risultato favorisce comunque Rubin. Ancora più importante, mostra perché l'architettura del rack è diventata inseparabile dall'economia degli acceleratori.

Un acquirente non può valutare Rubin confrontando soltanto i FLOPS della GPU. L'unità rilevante è il sistema di serving che offre una velocità di risposta richiesta entro un budget di potenza fisso.

Il supporto software OpenAI SemiAnalysis offre a Rubin un punto di partenza anticipato

Rubin può riutilizzare importanti kernel Blackwell, abbreviando il lavoro di implementazione prima che gli sviluppatori inizino il tuning specifico per l'architettura.

L'angolazione OpenAI SemiAnalysis non è una partnership hardware con OpenAI. Si riferisce al supporto di Rubin apparso in OpenAI Triton insieme a PyTorch, vLLM, CUDA e altri progetti pubblici.

Triton è un linguaggio e compilatore open source per scrivere kernel GPU con sintassi simile a Python. Un kernel è un programma specializzato che esegue un'operazione di calcolo sulla GPU.

OpenAI ha introdotto la programmazione Triton per rendere lo sviluppo di kernel ad alte prestazioni più accessibile del codice CUDA a basso livello. I compilatori PyTorch e i progetti di inferenza fanno ora affidamento sui kernel generati da Triton per molte operazioni.

NVIDIA ha rilasciato una developer preview di CUDA 13.4 con supporto per Rubin e istruzioni PTX aggiornate. PTX è il linguaggio di istruzioni intermedio di NVIDIA per descrivere le operazioni GPU.

La preview CUDA consente agli sviluppatori di esaminare le nuove capacità di Rubin e iniziare il porting del software. NVIDIA avverte che questa preview è software pre-release e non adatta ai benchmark di produzione.

SemiAnalysis riferisce che le modifiche per Rubin hanno raggiunto anche i repository di PyTorch, vLLM e OpenAI Triton. Questa esposizione pubblica concede agli sviluppatori di framework il tempo per adattarsi prima dell'ampia disponibilità cloud.

Il multiprocessore streaming di Rubin utilizza il target SM107. Ancora più importante, può eseguire i principali kernel della famiglia Blackwell SM100 in librerie come CUTLASS, DeepGEMM e FlashMLA.

Blackwell non ha ereditato la stessa comodità da Hopper. Il suo modello di programmazione dei Tensor Core ha richiesto riscritture sostanziali dei kernel prima che gli sviluppatori potessero avvicinarsi al potenziale dell'hardware.

Rubin preserva una quota maggiore di quell'investimento. I team possono iniziare con kernel Blackwell funzionanti, implementare prima e ottimizzare successivamente le operazioni più preziose.

La compatibilità non deve essere confusa con le prestazioni massime. SemiAnalysis afferma che il tuning specifico per l'architettura rimane necessario per raggiungere il limite pratico di velocità.

Rubin aumenta la memoria condivisa dai 228 KiB di Blackwell a una modalità opzionale da 328 KiB. Anche Tensor Memory cresce fino a 256 KiB, offrendo ai kernel più spazio per accumulatori e informazioni di scaling.

L'architettura aggiunge aggiornamenti inline dei descrittori Tensor Memory Accelerator. TMA è un meccanismo hardware che sposta dati multidimensionali senza richiedere alle normali unità di esecuzione di gestire ogni trasferimento.

In un layer mixture-of-experts, ogni esperto possiede una matrice di pesi separata. Blackwell può dover riscrivere e sincronizzare un descrittore quando cambia l'esperto attivo.

Rubin può passare il nuovo indirizzo con l'istruzione di trasferimento. Un descrittore può quindi servire diversi esperti senza una riscrittura intermedia della memoria.

Questo riduce l'overhead di dispatch durante il decoding con batch ridotti. Illustra inoltre perché i reali guadagni nell'inferenza derivano da piccoli miglioramenti nello spostamento dei dati, non soltanto da motori matriciali più grandi.

Rubin raddoppia il throughput dei Tensor Core FP8 e FP4 rispetto a Blackwell, secondo le divulgazioni architetturali di NVIDIA. Aggiunge inoltre una sincronizzazione più fine tra blocchi di thread dipendenti.

Queste funzionalità aiutano gli sviluppatori a creare kernel fusi più grandi. La fusione combina più operazioni, riducendo lanci ripetuti e spostamenti non necessari attraverso la memoria.

Il vantaggio software va oltre la preparazione al lancio. Strumenti compatibili permettono a più sviluppatori di analizzare il comportamento di Rubin, segnalare difetti e ottimizzare le architetture di modelli più diffuse.

Tuttavia, il supporto pubblico è ancora agli inizi. Le limitazioni della preview di CUDA mostrano che il codice disponibile non equivale a uno stack produttivo maturo.

L’integrazione con PyTorch e vLLM può abilitare le funzionalità di base, lasciando però incompleta una parte sostanziale dell’ottimizzazione. Gli operatori dovrebbero distinguere tra “funziona su Rubin” e “sfrutta Rubin in modo efficiente”.

Il precedente storico invita alla cautela. L’inferenza su GB200 è migliorata nel primo anno, con la maturazione di kernel, scheduler e ricette di serving distribuito.

Rubin parte da una posizione di compatibilità più solida. Il suo vantaggio finale dipenderà comunque dalla capacità dei manutentori dei framework di trasformare le nuove istruzioni in miglioramenti affidabili a livello di modello.

Il Tensor Core LUT a 3 bit punta al collo di bottiglia della memoria

La funzionalità di inferenza più interessante di Rubin comprime i pesi all’interno del Tensor Core, riducendo il traffico di memoria senza un passaggio separato di dequantizzazione.

Rubin aggiunge una modalità di operando B basata su tabella di ricerca alla sua istruzione di moltiplicazione-accumulazione di matrici. SemiAnalysis la descrive come il primo formato Tensor Core di NVIDIA che utilizza un codebook interno non uniforme.

In questa modalità, ogni peso memorizzato diventa un indice a tre bit. L’indice seleziona uno degli otto valori E4M3 a otto bit da una tabella di ricerca condivisa da un blocco di pesi.

Il Tensor Core ricostruisce il valore selezionato all’interno dell’operazione matriciale. Il software non deve generare una matrice di pesi decompressa separata prima della moltiplicazione.

Includendo il codebook condiviso, SemiAnalysis calcola un ingombro di memorizzazione pari a 3,125 bit per peso. Il codebook contiene 64 bit condivisi tra 512 pesi.

Il design differisce dai formati NVFP4 e MXFP. Questi formati usano il block scaling, applicando una scala uniforme a un gruppo di valori a bassa precisione.

Una tabella di ricerca può distribuire in modo disomogeneo i suoi otto valori. Può concentrare le voci vicino ai cluster densi di pesi o rappresentare distribuzioni positive e negative asimmetriche.

Questa flessibilità può preservare più informazioni rispetto all’arrotondamento uniforme con un numero di bit simile. Non garantisce una migliore qualità del modello.

Un codebook copre 512 pesi, mentre NVFP4 può adattare la propria scala su gruppi molto più piccoli. I risultati dipenderanno dai dati di calibrazione, dall’adattamento del codebook e dalla sensibilità del modello.

Alcuni layer potrebbero inoltre richiedere una precisione maggiore. Una ricetta di quantizzazione aggressiva può risparmiare memoria, danneggiando però l’accuratezza del ragionamento o destabilizzando l’output.

Il meccanismo hardware affronta comunque un vincolo centrale dell’inferenza. Durante la decodifica a batch ridotto, le GPU attendono spesso l’arrivo dei pesi del modello dalla HBM.

Ridurre la dimensione di memorizzazione di ciascun peso consente alla memoria di fornire più pesi al secondo. Riduce inoltre l’energia necessaria per spostare quei bit nel sistema.

SemiAnalysis ha utilizzato un ipotetico modello da 2,8 trilioni di parametri per illustrare l’effetto sulla capacità. Il calcolo collocava il payload dei pesi grezzi vicino a 1,09 terabyte con il formato di Rubin.

Il confronto escludeva KV cache, attivazioni, replica e overhead di serving. Dimostra quindi la memorizzazione dei pesi, non la memoria totale richiesta per il deployment.

Con 288 gigabyte di HBM4 per GPU Rubin, i pesi compressi richiederebbero circa quattro package. Nell’esempio, una rappresentazione alternativa a bassa precisione ne richiedeva circa sei.

Un minor numero di GPU coinvolte può ridurre comunicazioni e replica. Può anche lasciare più memoria per contesti più lunghi, batch più grandi o la KV cache.

Tuttavia, la modalità LUT presenta vincoli di implementazione. SemiAnalysis osserva che non può trasporre la matrice B, limitando le operazioni che possono utilizzarla direttamente.

Anche il benchmark pubblico sembra non usare questa funzionalità. Il vantaggio iniziale di Rubin non può quindi essere attribuito all’inferenza con tabella di ricerca a tre bit.

Questo è al tempo stesso incoraggiante e incerto. Rubin dispone di ulteriori capacità del silicio che il software futuro potrà sfruttare, ma la loro accuratezza e il loro valore in produzione restano da verificare.

NVIDIA ha inoltre aggiunto la sparsità delle attivazioni runtime 2:4. Questo metodo conserva due valori in ogni gruppo di quattro e ignora gli altri due durante le operazioni supportate.

A differenza della precedente sparsità dei pesi, la sparsità delle attivazioni runtime non richiede di potare e riaddestrare permanentemente il modello. L’hardware può comprimere i valori intermedi mentre il modello è in esecuzione.

NVIDIA non ha però pubblicato evidenze sull’accuratezza derivante dallo scarto di metà dei valori di attivazione selezionati prima delle operazioni successive. Neppure il risultato di CoreWeave sembra utilizzare questa funzione.

Queste capacità inutilizzate rappresentano il margine di ottimizzazione di Rubin. Non dovrebbero entrare nei calcoli attuali del TCO come guadagni futuri garantiti.

Gli acquirenti dovrebbero richiedere test di qualità a livello di modello insieme ai dati di throughput. Un formato a minor numero di bit riduce i costi di serving solo se il modello risultante soddisfa lo stesso obiettivo di accuratezza e affidabilità.

Rubin vince il test del TCO, ma la baseline modifica il margine

Rubin sembra meno costoso per token erogato nonostante costi di possesso più elevati, anche se il suo vantaggio si riduce rispetto a sistemi Blackwell completamente ottimizzati.

Il costo totale di proprietà combina hardware, elettricità, infrastrutture, networking, manutenzione e spese operative. Offre una visione più ampia rispetto alle sole prestazioni per watt.

SemiAnalysis ha applicato il proprio modello di possesso dell’operatore al throughput di output normalizzato. L’analisi ha evitato le tariffe di noleggio cloud, che possono includere scarsità, condizioni contrattuali e margini del provider.

L’analisi ha rilevato che Rubin è meno costoso per token di output a ogni livello di interattività misurato rispetto ai risultati di GB200 e GB300 di luglio 2026. Il vantaggio cresceva all’aumentare della velocità di risposta.

Rispetto all’attuale baseline GB200, Rubin era circa 1,5 volte meno costoso fino a 100 token al secondo per utente. Il vantaggio relativo raggiungeva circa tre volte nella fascia tra 200 e 250 token.

Il confronto tra Rubin e la baseline software GB200 del 2025 ha prodotto un risultato più ampio. Rubin ha raggiunto un picco vicino a otto volte di minor costo intorno a 150 token al secondo per utente.

Quella vecchia baseline spiega gran parte della differenza tra il titolo di marketing di NVIDIA e un confronto pratico per l’acquisto. Un GB200 ottimizzato nel 2026 è più capace rispetto al suo stato iniziale di deployment.

SemiAnalysis stima inoltre che Rubin comporti un costo di possesso per GPU superiore sia a GB200 sia a GB300. Il suo guadagno di throughput deve compensare questo maggiore onere di sistema.

Nel carico di lavoro esaminato ci riesce, soprattutto con obiettivi di interattività impegnativi. L’economia diventa meno decisiva a velocità di risposta inferiori, dove Blackwell può usare batch più grandi in modo efficace.

Questo rende la decisione di acquisto dipendente dal carico di lavoro.

Per l’inferenza altamente interattiva

• Rubin mantiene velocità di risposta che GB200 non riesce a raggiungere nella configurazione testata.

• La sua larghezza di banda di memoria e il fabric del rack diventano più preziosi quando la dimensione del batch diminuisce.

• Gli agenti di coding e i servizi di ricerca in tempo reale rientrano in questo profilo.

Per l’inferenza orientata al throughput

• Il software Blackwell maturo può ridurre il vantaggio relativo di Rubin.

• L’infrastruttura esistente e la capacità riservata possono superare un vantaggio teorico di efficienza.

• I costi di migrazione meritano di essere inclusi nel modello TCO dell’operatore.

Per i modelli a contesto lungo

• Il più ampio pool di memoria di Rubin offre agli operatori più spazio per pesi e KV cache.

• Il benchmark iniziale a turno singolo non misura direttamente questo vantaggio.

• I test su agenti multi-turno forniranno un segnale più rappresentativo.

Il benchmark ha utilizzato DeepSeek R1 671B con un input di 8.000 token e un output di 1.000 token. Quel modello e quella forma di sequenza non rappresentano tutti i carichi di lavoro produttivi del 2026.

SemiAnalysis sostiene che i modelli più recenti, da molti trilioni di parametri, dovrebbero favorire la capacità e la larghezza di banda di Rubin. Tale affermazione resta un’aspettativa tecnica finché non arriveranno risultati comparativi.

CoreWeave ha inoltre eseguito il test su un rack Dell in versione engineering sample senza un fabric scale-out. Lo scale-out collega più rack, mentre il backplane NVLink interno fornisce connettività scale-up.

Il test riuscito supporta l’operazione expert-parallel interna al rack. Non stabilisce prestazioni, affidabilità o efficienza in un deployment di grandi dimensioni su più rack.

La concorrenza aggiunge un altro vincolo. MI455X di AMD offre 432 gigabyte di HBM4 per acceleratore, rispetto ai 288 gigabyte di Rubin.

Su 72 acceleratori, il design Helios di AMD fornisce 31,1 terabyte di memoria. Rubin fornisce 20,7 terabyte nel suo rack NVL72.

Il vantaggio di capacità di AMD può essere rilevante per modelli grandi e contesti lunghi. NVIDIA risponde con il proprio ecosistema software consolidato, il fabric NVLink e una precedente esperienza operativa su scala rack.

I sistemi TPU di Google offrono un altro percorso integrato. Combinano acceleratori personalizzati, interconnessioni, compilatori e servizi cloud sotto un unico operatore.

La competizione sul TCO non si limita quindi a Rubin e GB200. Gli acquirenti devono confrontare intere ricette di serving usando lo stesso modello, obiettivo di accuratezza, latenza, lunghezza del contesto e contabilizzazione energetica.

Rubin detiene attualmente il più forte risultato pubblico iniziale. Le evidenze non stabiliscono ancora un unico rapporto di costo fisso per l’inferenza in produzione.

Cosa dovranno dimostrare i prossimi benchmark

Tre segnali determineranno se il risultato ingegneristico iniziale di Rubin diventerà un vantaggio produttivo duraturo.

Il primo segnale è la prevista submission di NVIDIA a InferenceX nel terzo trimestre del 2026. SemiAnalysis afferma che NVIDIA si è impegnata a fornire numeri Rubin verificabili in modo indipendente attraverso quel benchmark.

Una submission credibile dovrebbe testare modelli attuali in configurazioni di serving documentate. Dovrebbe riportare insieme interattività, throughput di output, confini del consumo energetico e impostazioni di ottimizzazione.

Risultati contro sistemi GB200 e GB300 di luglio 2026 rafforzerebbero il confronto attuale. Una ripetizione della vecchia baseline GB200 lascerebbe irrisolta la principale preoccupazione metodologica.

Il secondo segnale è un carico di lavoro per agenti multi-turno. L’inferenza a turno singolo non può riprodurre chiamate ripetute agli strumenti, KV cache in crescita e lunghezze dei prompt variabili nel corso di una sessione agente.

SemiAnalysis sta sviluppando uno scenario AgentX con contributori dell’infrastruttura e del serving open source. La sua analisi di Rubin identifica il lavoro agentico a contesto lungo come un probabile punto di forza architetturale.

Rubin dovrebbe ampliare il proprio vantaggio quando capacità di memoria e larghezza di banda predominano. Se il vantaggio resta invariato o si riduce, l’argomento a favore del rack per contesti lunghi diventa meno convincente.

Il terzo segnale è un software pubblico maturo. Gli sviluppatori dovrebbero seguire le release di produzione di CUDA, PyTorch, vLLM, Triton, TensorRT-LLM e Dynamo.

La compatibilità funzionale arriverà prima delle prestazioni ottimizzate. L’evidenza decisiva verrà da kernel stabili che sfruttino le funzionalità specifiche di Rubin per movimento della memoria, sincronizzazione e bassa precisione.

L’inferenza LUT a tre bit merita un’attenzione particolare. I test pubblicati devono riportare accuratezza, metodi di calibrazione, layer interessati e throughput end-to-end rispetto a NVFP4.

La sparsità delle attivazioni richiede lo stesso trattamento. Tassi aritmetici più elevati contano poco se la perdita di qualità costringe gli operatori a usare un modello più grande o a ripetere richieste non riuscite.

Feynman solleva anche una questione software di più lungo termine. NVIDIA ha identificato la propria prossima architettura come SM140, mentre Rubin usa SM107.

SemiAnalysis prevede che Feynman richieda riscritture più ampie dei kernel, simili alla difficile transizione da Hopper a Blackwell. Il vantaggio di compatibilità di Rubin potrebbe quindi durare solo una generazione.

Per gli acquirenti di infrastruttura, la decisione immediata non riguarda il fatto che Rubin abbia specifiche migliori. Le ha.

La domanda più difficile è se uno specifico carico di lavoro ne tragga abbastanza beneficio da giustificare modifiche al deployment. Gli operatori hanno bisogno di test basati sul proprio modello, sulla distribuzione dei contesti, sull’obiettivo di risposta e sulla capacità energetica esistente.

Per gli sviluppatori, l’azione utile è seguire fin d’ora il supporto dei kernel e le ricette di benchmark. Il profiling iniziale può rivelare se un’applicazione è limitata dal calcolo, dal traffico HBM, dal networking o dalla pianificazione.

Per i team di prodotto AI, occorre monitorare i risultati a livello utente. Token più veloci contano solo quando riducono il tempo di completamento delle attività, migliorano l'affidabilità degli agenti o consentono di servire più clienti contemporaneamente.

Il thread OpenAI SemiAnalysis collega in ultima analisi tre livelli: strumenti kernel aperti, analisi indipendenti delle prestazioni e hardware NVIDIA su scala rack. Nessuno di questi livelli può convalidare Rubin da solo.

Rubin manterrà il proprio vantaggio sui modelli moderni, sugli agenti multi-turn e su test riproducibili in modo indipendente? Sono queste evidenze, più che un singolo multiplo da titolo, a dover determinare il prossimo impegno nell'infrastruttura di inferenza.