713 Token al Secondo: L'Architettura Dietro Ultraspeed

Infercom fornisce 713 token al secondo su gpt-oss-120b e 428 tok/s su MiniMax M2.7 Ultraspeed dalla nostra infrastruttura EU. Puoi riprodurre questi numeri con il nostro strumento di benchmark open source.

Ma le affermazioni sulla velocità sono prive di significato senza capire il perché.

Siamo agnostici sull'hardware. Il nostro compito è valutare le architetture di inferenza e implementare l'opzione migliore per ogni workload. Per il decode memory-bound su modelli grandi, attualmente utilizziamo l'architettura dataflow di SambaNova perché affronta il collo di bottiglia della memoria che limita l'inferenza GPU. Questo articolo spiega le ragioni tecniche dietro questa scelta - vedi la nostra panoramica tecnologica per i dettagli di implementazione.

Il Collo di Bottiglia del Decode

Per capire perché alcune inferenze sono più veloci di altre, devi capire cosa succede quando invii un prompt a un LLM. Si verificano due fasi distinte, e stressano l'hardware in modi completamente diversi.

Prefill elabora l'intero prompt di input. Il modello legge tutti i tuoi token in una volta e capisce come ogni parola si relaziona a ogni altra parola - ciò che viene chiamato "attention". Tutti i token di input vengono elaborati in parallelo, che è esattamente ciò per cui le GPU sono state progettate. Migliaia di core rimangono occupati, l'utilizzo è alto, tutto funziona come previsto. Il prefill costruisce anche la cache KV - una struttura di memoria che memorizza i calcoli intermedi di attention così il modello non deve ricalcolarli per ogni nuovo token.

Decode genera token di output uno alla volta. Ogni nuovo token dipende da tutti i token precedenti, quindi il lavoro è intrinsecamente sequenziale. Per ogni token, il modello deve leggere i pesi attivi dalla memoria, leggere l'intera cache KV, calcolare la previsione, quindi aggiungere i dati del nuovo token alla cache. Il calcolo è veloce rispetto all'accesso alla memoria - il tempo va principalmente nell'attesa che i dati arrivino.

La cache KV è più grande di quanto la maggior parte delle persone pensi. Per un modello denso da 70B come Llama a precisione BF16, cresce di circa 0,3 MB per token. Una conversazione con contesto 8K richiede 2,5 GB solo per la cache. A 32K di contesto, sono 10 GB. A 128K, la cache da sola raggiunge 40 GB. Ogni token che generi richiede la lettura di questa intera cache dalla memoria.

Durante il prefill, l'utilizzo della GPU è all'80% o superiore. Durante il decode, scende al 20-40%. Le unità di calcolo restano inattive, in attesa della memoria. Questo è il collo di bottiglia del decode - non un problema software che puoi ottimizzare, ma un disallineamento fondamentale tra l'architettura GPU e il workload. Le GPU sono state progettate per il rendering grafico - matematica matriciale massivamente parallela che funziona bene per l'addestramento delle reti neurali. Ma l'inferenza, specialmente la generazione sequenziale di token, è un problema completamente diverso.

Perché la Larghezza di Banda della Memoria Limita l'Inferenza GPU

Per ogni token di output, il modello deve leggere i pesi attivi dalla memoria, leggere l'intera cache KV, calcolare la previsione e aggiornare la cache. Per i modelli densi, questo significa leggere tutti i parametri. Per i modelli Mixture of Experts (MoE) - ora l'architettura dominante - solo una frazione si attiva per token: DeepSeek V4-Pro ha 1,6T parametri totali ma attiva solo 49B per token, riducendo drasticamente le letture dei pesi. Ma la cache KV cresce comunque con la lunghezza del contesto indipendentemente dall'architettura.

Facciamo i calcoli su un modello denso da 70B per vedere chiaramente il collo di bottiglia. Il calcolo effettivo è banale - 70B parametri significa circa 140 miliardi di operazioni in virgola mobile per token, e una GPU H100 fornisce 2.000 TFLOPS. La matematica richiede circa 0,07 millisecondi.

Ma leggere quei 70B parametri dalla memoria richiede molto più tempo. La larghezza di banda H100 HBM3 è 3,35 TB/s. A FP16, 70B parametri equivalgono a 140GB. Leggerli richiede circa 42 millisecondi.

Ecco perché i TFLOPS grezzi non predicono la velocità di inferenza. Quando i provider ti mostrano le specifiche GPU, ti stanno mostrando la potenza di calcolo. Ma per il decode, la larghezza di banda della memoria è il collo di bottiglia. I numeri reali confermano questo: l'inferenza GPU in produzione su modelli 70B raggiunge tipicamente 50-150 tok/s. Il calcolo teorico permetterebbe 14.000+ tok/s. Il divario è l'attesa della larghezza di banda della memoria.

Come l'Architettura Dataflow Cambia l'Equazione

La soluzione non sono GPU più veloci - è un'architettura diversa. Diversi vendor hanno costruito chip specificamente per l'inferenza: RDU di SambaNova (Reconfigurable Dataflow Unit), LPU di Groq (Language Processing Unit) e WSE di Cerebras (Wafer-Scale Engine). Ognuno adotta un approccio diverso per risolvere il collo di bottiglia della memoria.

Abbiamo scelto l'architettura dataflow di SambaNova per la nostra infrastruttura EU (8 rack, 128 chip a Monaco) perché gestisce modelli grandi in modo efficiente senza richiedere centinaia o migliaia di chip. Quello che segue spiega specificamente come funziona il dataflow e perché è importante per l'inferenza.

Tre differenze architetturali spiegano perché il dataflow batte le GPU per l'inferenza:

1. Catena di Montaggio vs. Officina

Pensa a una GPU come a un'officina. Ogni lavoratore (core di calcolo) prende un compito, va al magazzino (memoria) per prendere i materiali, esegue il lavoro, torna indietro per memorizzare il risultato, poi prende il compito successivo. Migliaia di lavoratori, ma passano la maggior parte del tempo a camminare verso e dal magazzino.

L'architettura dataflow funziona come una catena di montaggio. Invece di lavoratori che si muovono verso i materiali, i materiali fluiscono attraverso stazioni di lavoro fisse. Ogni operazione è fisicamente disposta sul chip, e i dati fluiscono da una all'altra senza deviazioni verso la memoria. Il chip è progettato in modo che quando un'operazione finisce, il suo output sta già arrivando all'operazione successiva.

SambaNova chiama questo "esecuzione spaziale" - il calcolo viene mappato sul layout fisico del chip piuttosto che schedulato come una sequenza di istruzioni. Il risultato: i dati continuano a muoversi invece di aspettare.

2. Tre Livelli di Storage, Posizionati Strategicamente

La velocità della memoria varia con la distanza dal processore. La memoria più vicina (SRAM, sul chip stesso) è 100x più veloce del livello successivo (HBM), che è ancora molto più veloce della memoria di sistema (DDR). Il trucco è mantenere i dati giusti nel posto giusto.

L'RDU di SambaNova usa tutti e tre i livelli deliberatamente. La SRAM sul chip gestisce i dati più caldi - calcoli intermedi che altrimenti rimbalzerebbero verso la memoria e ritorno. L'HBM (1 terabyte per rack) memorizza i pesi del modello e la cache della conversazione. La DDR (12 terabyte per rack) contiene più modelli e prompt cached per il cambio istantaneo.

La differenza chiave dalle GPU: la gerarchia di memoria dell'RDU è controllata dal software, non gestita dall'hardware. Il compilatore decide cosa va dove, invece di affidarsi alla predizione della cache. Per workload prevedibili come l'inferenza - dove sai esattamente quali pesi ti serviranno in quale ordine - questo elimina i cache miss.

Questo significa anche nessun bisogno di quantizzazione. I provider GPU spesso comprimono i modelli a INT8 o INT4 per ridurre i requisiti di larghezza di banda della memoria - scambiando precisione per velocità. La gerarchia di memoria dataflow risolve il problema della larghezza di banda direttamente, così i modelli girano alla loro precisione nativa senza compromessi.

Questo design permette anche a un singolo rack di eseguire modelli massicci. Eseguire un modello da 671B parametri su GPU richiede 40 rack (320 GPU). SambaNova lo esegue su un rack con 16 RDU perché la gerarchia di memoria scala efficientemente.

Il livello DDR abilita un altro vantaggio: cambio modello veloce. Poiché la DDR è connessa direttamente ai chip (non acceduta attraverso la memoria di sistema come sulle GPU), caricare un modello diverso richiede millisecondi invece dei secondi o minuti richiesti dall'infrastruttura GPU. Un singolo rack può ospitare più modelli e passare da uno all'altro su richiesta.

3. Percorso Pianificato vs. GPS che Ricalcola

Le GPU prendono decisioni di scheduling a runtime. L'hardware bilancia costantemente quali thread girano dove, gestisce conflitti quando più core hanno bisogno degli stessi dati e coordina punti di sincronizzazione. Questa flessibilità è preziosa per workload imprevedibili - ma l'inferenza non è imprevedibile. Conosci l'architettura del modello. Conosci la sequenza delle operazioni. L'unica variabile sono i dati di input.

Il compilatore RDU sfrutta questa prevedibilità. Pre-pianifica l'intera esecuzione - quale chip gestisce quale layer, quando i dati si muovono tra i chip, persino l'esatto ciclo di clock in cui ogni operazione inizia. Nessuna decisione a runtime, nessun overhead di coordinamento, nessuna attesa per i ritardatari. Pensalo come la differenza tra un autista delle consegne che segue il GPS turn-by-turn (ricalcolando costantemente) versus un robot di magazzino Amazon che segue un percorso pre-ottimizzato attraverso la struttura. Quando sai che il layout non cambia, la pianificazione batte l'improvvisazione.

4. Pipeline Continua vs. Stop-and-Go

L'inferenza GPU tradizionale gira come una serie di operazioni discrete. Lancia il calcolo attention. Aspetta che finisca. Scrivi i risultati in memoria. Lancia l'operazione successiva. Leggi i risultati dalla memoria. Ripeti. Ogni passaggio tra operazioni costa tempo - non per il calcolo, ma per scritture in memoria, lanci di kernel e sincronizzazione. Su un'inferenza lunga che genera centinaia di token, questi passaggi si sommano.

L'esecuzione dataflow fonde le operazioni in pipeline continue. I dati fluiscono da attention a feedforward al layer successivo senza fermarsi. I risultati intermedi restano on-chip invece di fare viaggi di andata e ritorno verso la memoria. L'esecuzione assomiglia meno a una staffetta (passa il testimone, aspetta, corri) e più a un fiume (flusso continuo attraverso una serie di stazioni di elaborazione).

Numeri di Performance Reali

Queste differenze architetturali si traducono in vantaggi di velocità misurabili. Artificial Analysis, che fa benchmark dei provider in modo indipendente, misura costantemente SambaNova tra i provider di inferenza più veloci - con gpt-oss-120b che raggiunge 685 tok/s e MiniMax M2.7 a 426 tok/s nei loro benchmark live.

Come si confronta? I provider basati su GPU raggiungono tipicamente 50-150 tok/s su modelli grandi. La differenza di velocità 3-10x riflette direttamente il vantaggio architetturale - e il divario si allarga man mano che i modelli crescono, perché la larghezza di banda della memoria diventa più un collo di bottiglia. Per saperne di più su cosa significano queste metriche e quando ognuna conta, vedi Velocità di Inferenza LLM Spiegata.

L'Era del Decode: Perché Questo Conta Ora

Per anni, le conversazioni sull'infrastruttura AI si sono centrate sulla potenza di calcolo. Più TFLOPS, cluster più grandi, run di training più veloci. Aveva senso quando la sfida dominante era addestrare modelli più grandi. Ma l'inferenza - specialmente l'inferenza agentica - cambia completamente il problema.

Gli agenti non rispondono solo a un prompt e si fermano. Ragionano attraverso contesti lunghi, generano molti token, chiamano tool, iterano. Ogni generazione di token rientra nello stesso ciclo di decode. Il movimento inefficiente dei dati accumula latenza token dopo token. Token più veloci si traducono in più intelligenza perché il sistema può esplorare più passaggi di ragionamento entro lo stesso budget di tempo. Ecco perché la velocità conta così tanto per il coding agentico.

Efficienza Energetica: Un Effetto Collaterale di un'Architettura Migliore

Inferenza più veloce per watt non è solo un argomento di sostenibilità. Influisce direttamente sull'economia operativa. I rack SambaNova di Infercom assorbono circa 10 kW ciascuno. L'infrastruttura GPU equivalente gira a 40-50 kW o più per rack - quattro o cinque volte la potenza per capacità di inferenza comparabile. Gli RDU usano anche raffreddamento ad aria standard, mentre i deployment GPU ad alta densità spesso richiedono infrastruttura di raffreddamento a liquido che aggiunge costi e complessità.

L'Hazy Research lab di Stanford ha sviluppato una metodologia per misurare l'"intelligenza per watt" - output utile per unità di energia consumata. Secondo questa metrica, l'architettura dataflow fornisce fino a 5x più intelligenza per joule rispetto all'inferenza basata su GPU.

Questa efficienza deriva dalle stesse decisioni architetturali che abilitano la velocità. Mantenere i dati on-chip riduce il traffico di memoria. Meno traffico di memoria significa meno energia spesa per spostare dati. Lo scheduling statico elimina i cicli sprecati. Tutto si accumula.

Cosa Viene Dopo: Inferenza Disaggregata

L'industria sta rispondendo. La prossima evoluzione è già in corso: inferenza disaggregata, dove prefill e decode girano su hardware completamente separato.

La logica è semplice. Il prefill è compute-bound - beneficia di TFLOPS grezzi e alto parallelismo. Il decode è memory-bound - ha bisogno di larghezza di banda e accesso alla memoria a bassa latenza. Far girare entrambi sullo stesso chip significa che una fase è sempre subottimale. Perché scendere a compromessi quando puoi specializzare?

Al GTC 2026, Jensen Huang ha annunciato che NVIDIA si sta muovendo verso l'inferenza disaggregata. SambaNova e Intel hanno annunciato un'architettura simile: le GPU gestiscono il prefill (costruzione della cache KV), gli RDU gestiscono il decode (generazione veloce di token), e le CPU Xeon gestiscono l'orchestrazione e l'esecuzione dei tool.

Questo conta ancora di più per i workload agentici. Quando un agente ragiona attraverso un compito complesso, potrebbe iterare dozzine di volte - ragionando, chiamando tool, validando risultati, ripetendo. Ogni iterazione colpisce la fase di decode. La latenza si accumula attraverso le iterazioni. Un miglioramento 3x nella velocità di decode non rende solo le risposte individuali più veloci; abilita più passaggi di ragionamento entro lo stesso budget di tempo.

Questo non è teorico - i guadagni di efficienza sono troppo significativi per essere ignorati. Aspettati che l'inferenza disaggregata diventi standard per i deployment ad alte prestazioni nei prossimi anni.

La Conclusione

L'inferenza GPU colpisce un muro sui modelli grandi perché il decode è memory-bound, non compute-bound. Il chip resta inattivo in attesa dei dati. L'architettura dataflow risolve questo con esecuzione spaziale, memoria a livelli, scheduling statico e pipeline continue. Il risultato: inferenza 3-10x più veloce sui workload memory-bound.

Il collo di bottiglia del decode non sta andando via - anzi, sta peggiorando man mano che i modelli crescono e i workload agentici richiedono più token per task. L'industria sta rispondendo con hardware specializzato e architetture disaggregate. Infercom usa SambaNova perché fornisce la migliore combinazione di velocità, efficienza e supporto per modelli grandi per il deployment EU oggi. Ci adatteremo man mano che il panorama hardware evolve.

Non devi crederci sulla parola. benchmark.infercom.ai ti permette di eseguire i tuoi prompt reali contro la nostra infrastruttura. Artificial Analysis pubblica benchmark indipendenti tra provider. Testa alle tue tipiche lunghezze di input e output. Testa durante le ore di punta. I vantaggi architetturali si vedono nei numeri.

Fai i conti. È così che sai.

Ulteriori Letture

Risorse tecniche SambaNova:

• Inference Speed or Throughput? With RDUs, You Don't Have to Choose
• The Decode Era of AI: Why Dataflow Matters More Than Ever
• Solving the Decode Bottleneck: Why Agentic Inference Needs Hybrid Hardware

Analisi indipendenti:

• SambaNova Provider Analysis - Artificial Analysis
• DeepSeek R1 671B with 95% Fewer Chips - TechRadar

Risorse Infercom:

• Benchmark di Performance - I nostri numeri reali
• Panoramica Tecnologica - Come implementiamo l'architettura dataflow
• Velocità di Inferenza LLM Spiegata - Cosa significano le metriche
• Coding Agentico - Perché la velocità conta per lo sviluppo assistito da AI