In che modo la dimensione del batch influisce sulla latenza del primo token e su quella per token?

I batch più grandi spesso migliorano il throughput totale dei token, ma possono aumentare il ritardo del primo token e la latenza per token a causa delle code, delle iterazioni più pesanti e della pressione sulla memoria.

Un modello locale con batch pari a uno potrebbe sfruttare poco il proprio acceleratore, perché ogni passaggio di decodifica trasferisce i pesi del modello per una quantità di lavoro molto ridotta. Combinare le richieste ammortizza questo trasferimento e aumenta il throughput. Tuttavia, le richieste potrebbero dover attendere l'ammissione, i prefill lunghi possono bloccare le decodifiche e ogni sequenza attiva aggiunge lavoro per la cache KV e per i token; perciò il batch migliore dipende dal fatto che l'obiettivo sia il throughput, la reattività o il goodput entro un determinato obiettivo di latenza.

Il batching ammortizza il lavoro del modello tra le richieste

Un'operazione matriciale in batch elabora insieme i token di più sequenze, migliorando l'utilizzo dell'hardware e distribuendo i costi fissi di avvio o trasferimento dei pesi su una quantità maggiore di lavoro utile. I vantaggi sono massimi prima che si saturino la capacità di calcolo, la larghezza di banda della memoria, la capacità della cache o l'overhead di pianificazione.

La pianificazione a livello di iterazione di Orca introduce una pianificazione a livello di iterazione, così le sequenze completate possono uscire e nuovi lavori possono entrare tra un'iterazione di decodifica e l'altra. In questo modo non è necessario che ogni richiesta attenda il membro più lento di un batch statico.

La dimensione del batch può indicare il massimo configurato, le sequenze ammesse o i token elaborati in una singola iterazione. Questi valori differiscono con il batching continuo, quindi i report sulle prestazioni dovrebbero specificare quale quantità è stata controllata e osservata. Questa distinzione resta visibile anche durante i successivi test domestici.

La latenza del primo token include l'accodamento e il prefill

Il tempo al primo token inizia quando arriva una richiesta e include l'attesa nello scheduler, il prefill del prompt e il primo passaggio di decodifica. Una policy che attende di assemblare un batch può aumentare il tempo in coda, mentre l'ammissione di un prompt di grandi dimensioni può occupare un'iterazione e ritardare le richieste interattive già presenti.

Un confronto attuale sul batching continuo spiega come il batching continuo ammetta e rimuova dinamicamente le richieste e come una pianificazione aggressiva bilanci il throughput e il TTFT. Chiarisce perché la sola dimensione del batch non possa prevedere la reattività al primo token. Il risultato intermedio deve restare ispezionabile prima che l'automazione proceda.

Il prefill suddiviso in blocchi può alternare i prompt lunghi con il lavoro di decodifica, ma la dimensione dei blocchi diventa un ulteriore compromesso. I blocchi piccoli proteggono i token interattivi, ma aggiungono overhead di pianificazione; i blocchi grandi migliorano l'efficienza del prefill, creando però intervalli di blocco più lunghi. Questo limite dovrebbe essere misurato separatamente in condizioni operative realistiche.

La latenza per token dipende dall'iterazione attiva

Durante la decodifica, ogni passaggio produce generalmente un token per sequenza attiva. Un numero maggiore di sequenze amplia il batch e può aumentare la durata di ogni iterazione, anche se il numero complessivo di token al secondo cresce. Contesti di lunghezza diversa, pressione sulla cache, preemption e sincronizzazione distribuita aggiungono variabilità.

La disaggregazione tra prefill e decodifica di DistServe separa il prefill dalla decodifica perché hanno caratteristiche computazionali e obiettivi di servizio differenti. Il progetto mostra perché l'ottimizzazione del throughput complessivo possa entrare in conflitto sia con il TTFT sia con il tempo per token generato. La conseguenza pratica emerge quando diverse fonti competono per una quantità limitata di contesto.

Il limite critico consiste nello scegliere il batch più grande da un grafico di throughput offline per un assistente domestico interattivo. Se l'accodamento o gli intervalli tra i token violano l'obiettivo rivolto all'utente, il throughput nominale non costituisce un goodput utilizzabile, indipendentemente dall'utilizzo dell'acceleratore.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Tracciare il limite del goodput del batching

Riproduci chat brevi, prompt RAG lunghi e attività in background a tassi di arrivo controllati. Varia il numero massimo di sequenze e i limiti dei token elaborati in batch, misurando i percentili del TTFT, la latenza tra i token, la latenza end-to-end, il throughput dei prompt e dell'output, la profondità della coda, l'utilizzo della cache, la preemption e le richieste rifiutate.

Usa il comportamento del batching continuo descritto nel comportamento del batching continuo per distinguere i limiti configurati dal batch effettivo osservato in ogni iterazione. Mantieni fisse le distribuzioni dei prompt e degli output e indica la percentuale di richieste che soddisfa sia gli obiettivi relativi al primo token sia quelli relativi agli intervalli tra i token.

Scegli l'impostazione che massimizza il lavoro completato entro questi obiettivi, anziché i token al secondo grezzi. Isola o assegna una priorità inferiore ai batch in background quando riducono il goodput interattivo e ripeti i test dopo modifiche al modello, alla quantizzazione, alla combinazione dei contesti o allo scheduler.