Esecuzione kernel per kernel vs. streaming
Una GPU esegue una rete neurale come una sequenza di kernel: esegui un'operazione, scrivi il risultato intermedio in memoria, recuperalo per l'operazione successiva, sincronizza, ripeti. Gli ingegneri di SambaNova osservano che ognuno di quei confini aggiunge latenza, traffico di memoria e costo energetico - una penalità pagata su ogni token, che si accumula lungo la fase di decode autoregressiva in cui i token vengono generati uno alla volta.
Un processore dataflow mappa invece il calcolo su una griglia di unità di calcolo e di memoria come una pipeline continua: mentre un'operazione viene eseguita, i dati per la successiva sono già in fase di recupero, e le attivazioni intermedie rimangono locali sul chip invece di fare round-trip verso la memoria esterna. Il paper pubblicato da SambaNova sull'SN40L descrive la fusione di pipeline di 20 o più operatori in una singola chiamata kernel - dove la fusione convenzionale su GPU combina tipicamente da 1 a 5 operatori - ammortizzando l'overhead di lancio dei kernel e riservando la larghezza di banda della memoria a ciò che conta: lo streaming dei pesi e della KV-cache.
Perché è importante specificamente per l'inferenza
L'inferenza LLM ha due fasi con appetiti hardware opposti. Il prefill (elaborazione del prompt) è intensivo in calcolo e parallelo - lavoro per cui le GPU sono ben adatte, come SambaNova stessa riconosce. Il decode (generazione dei token) è limitato dalla larghezza di banda della memoria: ogni token richiede lo streaming dei pesi del modello dalla memoria, quindi l'efficienza di esecuzione e il movimento dei dati determinano la velocità. L'esecuzione dataflow è costruita esattamente per questa fase - motivo per cui il settore chiama l'attuale spostamento verso carichi di lavoro agentici e intensivi in generazione l'era del decode.
La conseguenza pratica si manifesta nella velocità per richiesta a batch size bassi. Il serving su GPU recupera l'efficienza del decode raggruppando molti utenti insieme, scambiando la latenza individuale con il throughput aggregato. Una pipeline dataflow mantiene un'alta utilizzazione senza dipendere da batch grandi - offrendo un'alta velocità per singola richiesta. Sulla nostra infrastruttura basata su SN40L a Monaco di Baviera, questo si traduce in 713 token al secondo su gpt-oss-120b e 428 token al secondo su MiniMax M2.7 Ultraspeed, misurati per richiesta su hardware di produzione.
Il sistema di memoria che lo sostiene
L'esecuzione in streaming richiede una memoria progettata attorno ad essa. L'SN40L accoppia il suo tessuto dataflow a un sistema di memoria a tre livelli - 520 MB di SRAM on-chip, 64 GB di HBM per socket e DDR collegata direttamente - che SambaNova descrive come il modo per scalare il memory wall dell'AI: la SRAM contiene i dati locali più caldi, l'HBM trasferisce in streaming i pesi del modello attivo, e il livello DDR ospita modelli aggiuntivi e cache dei prompt, consentendo il cambio di modello in millisecondi anziché nei secondi necessari agli stack GPU.
Fonti
Termini correlati
RDU (Reconfigurable Dataflow Unit)
Il processore AI di SambaNova - chip AI costruiti appositamente, progettati per l'esecuzione dataflow invece dell'elaborazione istruzione per istruzione.
Prefill vs. Decode
Le due fasi dell'inferenza LLM - elaborazione parallela del prompt vs. generazione token per token.
Latenza vs. Throughput
Il trade-off fondamentale del serving: output totale del sistema vs. velocità di ciascun utente.
Scopri come l'architettura dataflow di SambaNova cambia l'economia dell'inferenza - e perché abbiamo costruito su di essa.