Cosa causa i cali di utilizzo della GPU durante il batching continuo degli LLM?
I cali di utilizzo della GPU compaiono solitamente quando lo scheduler del continuous batching non riesce ad assemblare lavoro eseguibile o ad alimentare l'acceleratore senza uno stallo dovuto a una dipendenza.
Un server LLM domestico può segnalare un throughput elevato e mostrare comunque cali periodici della GPU tra le iterazioni di decodifica. Il continuous batching rimuove le sequenze completate e ne ammette di nuove, ma non può creare lavoro quando gli arrivi sono poco frequenti, i blocchi KV non sono disponibili, i prefill lunghi bloccano la decodifica o il runtime della CPU prepara i batch troppo lentamente. La sincronizzazione e lo spostamento dei dati possono creare intervalli vuoti anche con una coda di richieste piena.
La disponibilità delle richieste e il ricambio delle sequenze possono svuotare un batch
Il continuous batching sostituisce le sequenze completate ai confini delle iterazioni. Se gli arrivi sono a raffica, gli output terminano contemporaneamente o i limiti di ammissione mantengono le richieste fuori dalla coda eseguibile, il numero di token attivi può scendere al di sotto dell'intervallo operativo efficiente della GPU.
I benchmark sulla composizione continua dei batch confrontano l'appartenenza statica e continua alle richieste con lunghezze di input, lunghezze di output e tempi di arrivo variabili. Il segnale caratteristico è un numero ridotto di token eseguibili durante i cali di utilizzo, nonostante un acceleratore in buone condizioni e l'assenza di errori di memoria.
Una coda realmente vuota non è un difetto dello scheduler. Confronta il tasso di arrivo, le sequenze ammesse e i token pianificati per iterazione prima di interpretare ogni intervallo inattivo come capacità persa. Questa distinzione resta visibile durante i successivi test domestici.
Prefill, decodifica e allocazione KV creano bolle nello scheduler
Il prefill elabora molti token del prompt con kernel ad alta intensità di calcolo, mentre la decodifica fa avanzare ogni sequenza di un token alla volta ed è spesso limitata dalla memoria. La combinazione delle due fasi può ritardare la decodifica, mentre la prenotazione o il recupero dei blocchi KV possono interrompere l'ammissione tra un'iterazione e l'altra.
Il design dello scheduling del prefill suddiviso in blocchi utilizza un prefill suddiviso in blocchi per impedire ai prompt lunghi di monopolizzare le iterazioni di servizio. Il suo meccanismo identifica intervalli vuoti correlati ai confini del prefill, all'allocazione KV o alla preemption delle richieste, anziché a una domanda debole. Il risultato intermedio deve restare ispezionabile prima che l'automazione lo segua.
Se i cali della GPU aumentano con la lunghezza del prompt ma non con quella dell'output, lo scheduling del prefill è la causa più probabile. Se seguono la pressione sulla cache o le espulsioni, la responsabilità è dell'ammissione in memoria, anche quando la coda resta piena. Questo confine deve essere misurato separatamente in condizioni operative realistiche.
L'alimentazione dalla CPU e la sincronizzazione tra dispositivi possono affamare i kernel
La tokenizzazione, il sampling, le decisioni dello scheduler, i metadati dei tensori, le copie dall'host al dispositivo, le operazioni collettive distribuite e la registrazione dei log avvengono al di fuori dei kernel principali. Un thread della CPU sovraccarico o una sincronizzazione bloccante può lasciare la GPU in attesa tra batch altrimenti validi. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.
La ricerca sull'interferenza tra prefill e decodifica separa le risorse di prefill e decodifica per ridurre le interferenze e raggiungere gli obiettivi di latenza. Il risultato conferma che un singolo grafico di utilizzo combina il comportamento dello scheduler, dell'host, della comunicazione e dell'acceleratore. Questa dipendenza deve restare esplicita nell'interfaccia finale.
Il confine del guasto è un breve intervallo di campionamento che segnala come utilizzo zero i normali confini dei kernel. Conferma i cali con una traccia o con i contatori hardware; la media del dashboard può creare valli apparenti che non riducono i token al secondo.
Allinea le sequenze temporali della coda, dello scheduler e dei kernel
Riproduci arrivi controllati costanti e a raffica registrando richieste in attesa, ammesse e in esecuzione, token di prompt e di decodifica per iterazione, blocchi KV liberi, preemption, tempo dello scheduler della CPU, tokenizzazione, sampling, copie, operazioni collettive, intervalli tra i lanci dei kernel, frequenze della GPU e throughput dell'output.
Confronta il modello con il comportamento del continuous batching, quindi varia una alla volta la frequenza di arrivo, la lunghezza del prompt, la dimensione del prefill suddiviso in blocchi, il budget della cache e l'affinità della CPU. Mantieni invariati modello, quantizzazione e obiettivo di latenza. Il risultato deve quindi essere verificato rispetto alle evidenze originali.
Classifica ogni valle come assenza di domanda, stallo di ammissione, interferenza del prefill, pressione sulla cache, carenza di risorse dell'host o sincronizzazione prima di intervenire sulla configurazione. Ottimizza il confine responsabile; forzare un batch più grande non può risolvere una coda vuota o un thread dell'host bloccato.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Cosa induce il pianificatore di un agente IA a ripetere passaggi già completati?
Traccia i passaggi ripetuti del pianificatore attraverso la persistenza dello stato, le prove di completamento, l’analisi dei risultati degli strumenti, la conservazione del contesto,...
Cosa causa gli errori di autorizzazione solo all'interno dei sottoprocessi degli agenti IA?
Confronta l'identità del processo padre e di quello figlio, la vista del filesystem, l'ambiente, le capacità, i criteri di sicurezza e il percorso dell'eseguibile...
Cosa causa la saturazione della CPU quando la transcodifica hardware e l’IA video vengono eseguite insieme?
Monitora la saturazione della CPU tra offload dei codec, conversione dei pixel, copie dei frame, pre-elaborazione dell’IA, audio, sottotitoli, archiviazione e pianificazione dei processi.
