Throughput in Output vs. throughput di sistema
Quando un benchmark riporta il Throughput in Output - come i 713 tok/s che misuriamo su gpt-oss-120b - intende i token in streaming verso una singola richiesta dopo il primo token. Questo è il numero che determina quanto velocemente un utente riceve una risposta completa. Il throughput di sistema è diverso: la letteratura ingegneristica lo definisce come il numero di token di output al secondo che un server di inferenza genera su tutti gli utenti e le richieste; la documentazione di benchmarking lo chiama "TPS per system" in contrasto con "TPS per user". I due si muovono in direzioni opposte sotto carico: al crescere della concorrenza, il throughput di sistema sale verso la saturazione dell'hardware mentre il Throughput in Output di ciascun utente scende.
Perché il batching crea il trade-off
La fase di decode dell'inferenza è limitata dalla larghezza di banda della memoria: per ogni token generato, l'hardware deve trasferire in streaming i pesi del modello dalla memoria. Il batching ammortizza quel costo - carica i pesi una volta, fa avanzare le richieste di molti utenti nello stesso passaggio. I benchmark di continuous batching di Anyscale hanno mostrato un throughput fino a 23x superiore rispetto al serving ingenuo richiesta per richiesta.
Il rovescio della medaglia: tutti nel batch condividono la stessa larghezza di banda della memoria, quindi un batch più grande significa token più lenti per ciascun utente. Databricks ha misurato il trade-off concretamente: con batch size 64 su una A100, il throughput è cresciuto di 14x - mentre la latenza di ogni richiesta è cresciuta di 4x. Il throughput di sistema è in definitiva una preoccupazione del provider - determina il suo costo per token e la pianificazione della capacità. Come utente, sperimentate solo il Throughput in Output della vostra richiesta; la policy di batching del provider decide dove esso si colloca.
Cosa guardare in pratica
Nel valutare i provider, ancoratevi ai numeri per richiesta: Throughput in Output e latenza inter-token sotto carico realistico - un valore di throughput di sistema da titolone non dice nulla sull'esperienza che riceveranno le vostre richieste. Anche l'architettura conta: hardware che mantiene un'alta utilizzazione a batch size bassi può fornire un'alta velocità per richiesta senza dipendere da batching aggressivo - che è la premessa progettuale dell'architettura dataflow su cui funziona la nostra piattaforma.
Fonti
Termini correlati
Token al Secondo
L'unità standard per la velocità di generazione degli LLM - e perché lo stesso numero può significare due cose diverse.
Latenza vs. Throughput
Il trade-off fondamentale del serving: output totale del sistema vs. velocità di ciascun utente.
Prefill vs. Decode
Le due fasi dell'inferenza LLM - elaborazione parallela del prompt vs. generazione token per token.
Scopri come l'architettura dataflow di SambaNova cambia l'economia dell'inferenza - e perché abbiamo costruito su di essa.