Questa guida alle best practice mostra le metriche disponibili e come selezionarne di adatte per configurare l'Horizontal Pod Autoscaler(HPA) per i workload di inferenza JetStream a host singolo con TPU su GKE. L'HPA è un modo efficiente per garantire che i server dei modelli si scalino in modo appropriato in base al carico. La messa a punto delle impostazioni HPA è il modo principale per allineare il costo dell'hardware di cui è stato eseguito il provisioning alle richieste di traffico al fine di raggiungere gli obiettivi di rendimento del server di inferenza.
Per esempi di come implementare queste best practice, consulta Configurare la scalabilità automatica per i carichi di lavoro LLM su TPU con GKE.
Obiettivi
Questa guida è rivolta ai clienti di AI generativa, agli utenti GKE nuovi o esistenti, agli ingegneri ML e agli ingegneri LLMOps (DevOps) interessati a ottimizzare i loro carichi di lavoro JetStream a host singolo utilizzando le TPU con Kubernetes.
Dopo aver letto questa guida, dovresti essere in grado di:
- Scopri le metriche chiave della scalabilità automatica per l'inferenza JetStream a singolo host.
- Comprendi i compromessi di alto livello quando valuti le metriche su cui eseguire la scalabilità automatica.
Panoramica delle metriche di scalabilità automatica per l'inferenza JetStream
Ti consigliamo di utilizzare le seguenti metriche:
Metriche del server
JetStream, come molti altri server di inferenza LLM, fornisce metriche sul rendimento. GKE semplifica il monitoraggio e la scalabilità automatica di JetStream in base a queste metriche a livello di server. Per configurare la scalabilità automatica, devi prima capire in che modo la pipeline delle richieste di JetStreams influisce sugli indicatori chiave del rendimento. Tutte le richieste in entrata passano attraverso una coda di precompilazione, una coda di trasferimento e una coda di generazione, per poi diventare una richiesta di decodifica. JetStream accetta le richieste di decodifica in modo continuo ed elabora contemporaneamente un numero fisso di thread di decodifica. La percentuale di motori di decodifica occupati con la gestione di una richiesta di decodifica in un determinato momento viene misurata come metrica jetstream_slots_used_percentage.
Per la scalabilità di JetStream su un singolo host, questo ha due implicazioni per la latenza e la velocità effettiva:
- Le richieste non verranno inserite in coda se la frequenza delle richieste in arrivo è inferiore alla frequenza con cui gli slot di decodifica possono elaborarle. Se JetStream non ha un backlog, il throughput sarà proporzionale alla frequenza delle richieste in arrivo. La latenza rimarrà in gran parte costante, ma aumenterà leggermente e proporzionalmente al numero di richieste di decodifica simultanee, poiché le nuove richieste di decodifica accettate interromperanno la decodifica.
- Le richieste verranno inserite in coda quando la frequenza delle richieste in arrivo supera la frequenza con cui gli slot di decodifica possono elaborarle. Se JetStream ha un backlog, la latenza delle richieste aumenterà in modo più significativo e proporzionale al numero di richieste in coda, mentre il throughput rimarrà costante.
Le seguenti metriche del server avranno la correlazione più stretta con questi indicatori di prestazioni pertinenti. Ti consigliamo di utilizzarle per l'autoscaling:
jetstream_prefill_backlog_size: il numero di richieste in attesa di elaborazione nella coda del server (backlog). Questa metrica ha una forte correlazione con la latenza. Per scoprire di più, consulta la sezione relativa alle best practice.jetstream_slots_used_percentage: il numero di richieste sottoposte a inferenza come percentuale del numero totale di richieste che JetStream è in grado di gestire. Questa metrica ha una forte correlazione con il throughput. Per scoprire di più, consulta la sezione relativa alle best practice.
Queste metriche sono spesso resistenti alle fluttuazioni del rendimento e del traffico, il che le rende un punto di partenza affidabile per la scalabilità automatica su diverse configurazioni hardware TPU.
Metriche TPU
Poiché la pubblicazione di modelli LLM è limitata dalla memoria e non dall'elaborazione, ti consigliamo di eseguire la scalabilità di JetStream in base all'utilizzo della memoria anziché con altre metriche TPU, poiché riflette meglio l'utilizzo delle risorse dell'hardware. Per scoprire di più, consulta la sezione relativa alle best practice.
Considerazioni per la scelta delle metriche di scalabilità automatica
Utilizza le seguenti considerazioni e best practice per selezionare la metrica migliore per la scalabilità automatica su GKE in modo da raggiungere i tuoi obiettivi di rendimento del carico di lavoro di inferenza.
Best practice: utilizza la dimensione della coda (backlog) di precompilazione per massimizzare il throughput e ridurre al minimo i costi entro una determinata soglia di latenza target
Ti consigliamo di utilizzare la scalabilità automatica della dimensione della coda di precompilazione quando ottimizzi il throughput e il costo e quando i tuoi target di latenza sono raggiungibili con il throughput massimo della dimensione del batch per dispositivo del server del modello.
La dimensione della coda di precompilazione è direttamente correlata alla latenza della richiesta. Le richieste in arrivo vengono messe in coda nella coda di precompilazione dei server dei modelli prima di essere elaborate e questo tempo di coda si aggiunge alla latenza complessiva. La dimensione della coda è un indicatore sensibile dei picchi di carico, poiché l'aumento del carico riempie rapidamente la coda.
La scalabilità automatica in base alle dimensioni della coda di precompilazione riduce al minimo il tempo di attesa della coda eseguendo il ridimensionamento in base al carico e il ridimensionamento verso il basso quando la coda è vuota. Questo approccio è relativamente facile da implementare perché le dimensioni della coda sono indipendenti dalle dimensioni della richiesta, dal modello o dall'hardware.
Valuta la possibilità di concentrarti sulle dimensioni della coda di precompilazione se vuoi massimizzare il throughput di ogni replica del server del modello. La dimensione della coda di precompilazione monitora le richieste in attesa, non in elaborazione. JetStream utilizza il raggruppamento continuo, che massimizza le richieste simultanee e mantiene la coda bassa quando è disponibile spazio per i batch. La coda cresce notevolmente quando lo spazio del batch è limitato, quindi utilizza il punto di crescita come indicatore per avviare lo scale-up. Combinando la scalabilità automatica delle dimensioni della coda con la velocità in batch ottimizzata, puoi massimizzare la velocità in termini di richieste.
Determina il valore ottimale della soglia della dimensione della coda per HPA
Per scegliere la soglia corretta per le dimensioni della coda, inizia con un valore compreso tra 3 e 5 e aumentalo gradualmente fino a quando le richieste non raggiungono la latenza preferita. Utilizza lo strumento locust-load-inference per i test. Per le soglie inferiori a 10, perfeziona le impostazioni di scalabilità HPA per gestire i picchi di traffico.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento della metrica.
Limitazioni
Tieni presente la tolleranza HPA, che per impostazione predefinita ha un intervallo di assenza di azioni pari a 0,1 intorno al valore target per smorzare l'oscillazione.
La dimensione della coda di precompilazione non controlla direttamente le richieste concorrenti, pertanto la relativa soglia non può garantire una latenza inferiore a quella consentita dalla dimensione del batch per dispositivo. Come soluzione alternativa, puoi ridurre manualmente la dimensione del batch per dispositivo o utilizzare la scalabilità automatica in base alla dimensione del batch.
Best practice: utilizza la percentuale di slots_used per raggiungere soglie di latenza target inferiori alle dimensioni della coda
Ti consigliamo di scegliere la scalabilità automatica basata su slots_used se hai carichi di lavoro sensibili alla latenza in cui la scalabilità basata sulla coda non è abbastanza veloce per soddisfare i tuoi requisiti.
La scalabilità automatica su slots_used garantisce che il throughput dei carichi di lavoro venga aumentato per massimizzare il numero di richieste elaborate contemporaneamente in parallelo e venga ridotto quando le richieste da elaborare in parallelo sono meno. Ciò ha due implicazioni per la latenza. Innanzitutto, poiché la scalabilità automatica basata su slots_used si basa su un numero di slot per ogni richiesta in arrivo, la vicinanza della soglia a 1 corrisponderà alla probabilità che una richiesta rimanga in coda per un certo periodo di tempo e di conseguenza abbia una latenza più elevata. In secondo luogo, dimensioni dei batch più grandi aumentano la velocità effettiva, ma anche la latenza a causa della fase di precompilazione di alcune richieste che interrompe la fase di decodifica di altre nei server di modelli con batching continuo. Puoi monitorare i pattern delle dimensioni dei batch e utilizzare la scalabilità automatica per ridurre al minimo le richieste simultanee durante i picchi di carico.
Se la dimensione della coda soddisfa già i tuoi target di latenza, dai la priorità alla scalabilità automatica. In questo modo vengono massimizzati sia il throughput sia l'efficienza in termini di costi. Tuttavia, slots_used è utile per i carichi di lavoro sensibili alla latenza.
Ti consigliamo inoltre di ottimizzare la dimensione del batch per dispositivo su un valore appropriato prima di esplorare la scalabilità automatica basata su slots_used. Se vuoi, puoi anche abbinarlo alla scalabilità automatica basata su coda.
Determina il valore ottimale della soglia percentuale di slots_used per l'HPA
Per scegliere la soglia corretta per la dimensione del batch, aumenta sperimentalmente il carico sul server e osserva dove si verificano i picchi della dimensione del batch. Ti consigliamo inoltre di utilizzare lo strumento locust-load-inference per i test. Una volta identificata una dimensione batch ottimale per dispositivo in cui l'utilizzo della memoria è massimizzato, puoi configurare il target percentuale di slots_used. Imposta il valore target iniziale leggermente al di sotto di 1 e diminuiscilo fino a raggiungere la latenza preferita.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento della metrica.
Limitazioni
Tieni presente la tolleranza HPA, ovvero un intervallo predefinito di 0,1 senza azioni attorno al valore target per smorzare l'oscillazione.
La scalabilità automatica in base alla percentuale di slot_used, sebbene utile per il controllo della latenza, presenta delle limitazioni. Le dimensioni variabili delle richieste e i vincoli hardware rendono difficile trovare la soglia percentuale di slots_used corretta. Una regola di scala che tenta di mantenere la percentuale media di slots_used al di sotto del 100% significa che la regola di scala sta tentando di mantenere un numero non nullo di slot disponibili. Questi slot disponibili corrispondono al throughput disponibile non utilizzato, il che non è l'ideale se vuoi sfruttare al meglio le TPU disponibili.
Best practice: utilizza la memoria ad alta larghezza di banda (HBM) TPU per massimizzare l'utilizzo dell'hardware
L'utilizzo della memoria HBM (High Bandwidth Memory) delle TPU ha la corrispondenza più diretta con l'utilizzo dell'hardware, anche rispetto alle metriche di sistema, poiché queste non tengono conto delle dimensioni delle richieste. Sebbene la scalabilità in base alle dimensioni della coda massimizzi meglio l'utilizzo dell'hardware, lo fa a spese della latenza. Se preferisci fare affidamento sulle metriche di sistema anziché su quelle del server, ti consigliamo di utilizzare l'utilizzo HBM come la migliore alternativa per la scalabilità automatica con slots_used, poiché entrambe corrispondono al throughput. Per ulteriori informazioni sulla memoria TPU, consulta Come funziona una TPU.
L'aumento della dimensione del batch oltre il punto ottimale migliora il throughput, ma aumenta anche il rischio di errori di esaurimento della memoria (OOM). Ti consigliamo vivamente di eseguire il ridimensionamento in base alla metrica HBM per bilanciare il throughput e la stabilità. Ti consigliamo di non eseguire il ridimensionamento contemporaneamente in base alle dimensioni della coda di precompilazione e all'utilizzo dell'HBM, poiché con l'aumento del carico l'utilizzo dell'HBM aumenterà e attiverà prima il ridimensionamento.
Determina il valore ottimale della soglia di utilizzo dell'HBM TPU per l'HPA
Prima di scegliere la soglia di utilizzo della memoria, ti consigliamo di impostare la dimensione del batch per dispositivo su un valore che massimizzi la memoria utilizzata quando il carico previsto è massimo. Tieni presente che questo valore dovrà essere determinato sperimentalmente e dipenderà in gran parte dall'HBM totale, nonché dalla lunghezza prevista del prompt e della risposta. Ti consigliamo di utilizzare lo strumento locust-load-inference per le sperimentazioni e i test.
Come per la dimensione del batch per dispositivo, imposta la soglia per massimizzare l'utilizzo della memoria TPU riducendo al minimo il rischio di un comportamento OOM.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento della metrica.
Limitazioni
Esistono due fattori che riducono l'efficacia con cui la latenza e il throughput corrispondono all'utilizzo dell'HBM, ovvero la volatilità dell'utilizzo dell'HBM e la frequenza di campionamento inferiore delle metriche TPU in generale. Inoltre, anche se esiste ancora una corrispondenza tra l'utilizzo dell'HBM e la latenza, gli aumenti dell'utilizzo dell'HBM influiscono sulla latenza molto meno degli aumenti del numero di richieste in coda.
Best practice: ottimizza la configurazione dell'HPA
Ti consigliamo di impostare le seguenti opzioni di configurazione HPA:
- Finestra di stabilizzazione: utilizza questa opzione di configurazione HPA per evitare rapide variazioni del numero di repliche a causa di metriche fluttuanti. I valori predefiniti sono 5 minuti per il ridimensionamento verso il basso (per evitare un ridimensionamento prematuro) e 0 per il ridimensionamento verso l'alto (per garantire la reattività). Modifica il valore in base alla volatilità dei carichi di lavoro e alla reattività che preferisci.
- Criteri di scalabilità: utilizza questa opzione di configurazione HPA per perfezionare il comportamento di scalabilità verso l'alto e verso il basso. Puoi impostare il limite del criterio "Pod" per specificare il numero assoluto di repliche modificate per unità di tempo e il limite del criterio "Percentuale" per specificare la variazione percentuale.
Per scoprire di più su queste opzioni, consulta la sezione Scalabilità automatica pod orizzontale nella documentazione di Kubernetes open source.