Throughput (serving LLM)

Throughput di output vs. throughput di sistema

Quando un benchmark riporta il throughput di output, come i 713 tok/s che misuriamo su gpt-oss-120b, si riferisce ai token che arrivano in streaming a una singola richiesta dopo il primo token. È il numero che determina quanto velocemente un utente riceve una risposta completa. Il throughput di sistema è un'altra cosa. La letteratura tecnica lo definisce come il numero di token di output al secondo che un server di inferenza genera per tutti gli utenti e le richieste. La documentazione dei benchmark lo chiama "TPS per sistema", in contrapposizione a "TPS per utente". Sotto carico i due valori si muovono in direzioni opposte: con l'aumentare della concorrenza, il throughput di sistema sale verso la saturazione dell'hardware, mentre il throughput di output di ciascun utente scende.

Perché il batching crea il compromesso

La fase di decode dell'inferenza è limitata dalla larghezza di banda della memoria: per ogni token generato, l'hardware deve leggere dalla memoria i pesi del modello. Il batching distribuisce questo costo. I pesi vengono caricati una volta e, nello stesso passaggio, avanzano le richieste di molti utenti. I benchmark di continuous batching di Anyscale hanno mostrato un throughput fino a 23x più alto rispetto a un servizio ingenuo, una richiesta alla volta.

Il rovescio della medaglia: tutti gli utenti del batch condividono la stessa larghezza di banda della memoria, quindi un batch più grande significa token più lenti per ognuno. Databricks ha misurato concretamente il compromesso: 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 un problema del provider, perché determina il suo costo per token e la pianificazione della capacità. Come utente vivi solo il throughput di output della tua richiesta, e dove si colloca lo decide la politica di batching del provider.

Cosa guardare nella pratica

Quando valuti i provider, parti dai numeri per richiesta: throughput di output e latenza inter-token sotto un carico realistico. Un valore di throughput di sistema da titolo di giornale non dice nulla sull'esperienza che avranno le tue richieste. Conta anche l'architettura. Un hardware che mantiene un utilizzo elevato anche con batch piccoli può offrire un'alta velocità per richiesta senza dipendere da un batching aggressivo. È questa l'idea alla base dell'architettura dataflow su cui gira la nostra piattaforma.