Questa guida alle best practice mostra le metriche disponibili e come selezionare quelle adatte per configurare Horizontal Pod Autoscaler(HPA) per i carichi di lavoro di inferenza JetStream a host singolo con TPU su GKE. HPA è un modo efficiente per garantire che i server del modello vengano scalati in modo appropriato in base al carico. La messa a punto delle impostazioni di HPA è il modo principale per allineare il costo dell'hardware di cui è stato eseguito il provisioning alle esigenze di traffico per raggiungere gli obiettivi di rendimento del server di inferenza.
Per esempi di implementazione di queste best practice, consulta Configurare la scalabilità automatica per i carichi di lavoro LLM sulle TPU con GKE.
Obiettivi
Questa guida è rivolta a clienti dell'AI generativa, utenti GKE nuovi o esistenti, ML Engineer e LLMOps (DevOps) Engineer interessati a ottimizzare i propri workload JetStream a host singolo utilizzando le TPU con Kubernetes.
Dopo aver letto questa guida, dovresti essere in grado di:
- Comprendere le metriche chiave di scalabilità automatica per l'inferenza JetStream su un singolo host.
- Comprendi i compromessi di alto livello quando scegli 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 di richieste JetStream influisce sugli indicatori chiave di 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 e le elabora contemporaneamente utilizzando un numero fisso di thread di decodifica. La percentuale di motori di decodifica occupati a gestire una richiesta di decodifica in un determinato momento viene misurata come metrica jetstream_slots_used_percentage
.
Per lo scaling di JetStream su un singolo host, ciò ha due implicazioni per la latenza e la velocità effettiva:
- Le richieste non verranno accumulate nelle code se la frequenza delle richieste in arrivo è inferiore alla frequenza con cui gli slot di decodifica possono elaborarle. Se JetStream non ha backlog, la velocità effettiva sarà proporzionale alla velocità delle richieste in entrata. La latenza rimarrà per lo più costante, ma aumenterà leggermente e proporzionalmente al numero di richieste di decodifica simultanee, poiché le richieste di decodifica appena accettate interromperanno la decodifica.
- Le richieste verranno accumulate nelle code una volta che la velocità di ricezione delle richieste supera la velocità 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 backlog, mentre il throughput rimarrà costante.
Le seguenti metriche del server avranno la correlazione più forte con questi indicatori di rendimento pertinenti. Ti consigliamo di utilizzarli per la scalabilità automatica:
jetstream_prefill_backlog_size
: il numero di richieste in attesa di elaborazione nella coda del server (arretrato). Questa metrica ha una forte correlazione con la latenza. Per saperne di più, consulta la sezione Best practice correlata.jetstream_slots_used_percentage
: il numero di richieste in fase di inferenza in percentuale del numero totale di richieste che JetStream è in grado di gestire. Questa metrica ha una forte correlazione con il throughput. Per saperne di più, consulta la sezione Best practice correlata.
Queste metriche sono spesso resilienti alle fluttuazioni di rendimento e traffico, il che le rende un punto di partenza affidabile per la scalabilità automatica in diverse configurazioni hardware TPU.
Metriche TPU
Poiché il servizio LLM è limitato dalla memoria e non dal calcolo, ti consigliamo di scalare JetStream in base all'utilizzo della memoria anziché ad altre metriche TPU, in quanto riflette meglio l'utilizzo delle risorse dell'hardware. Per saperne di più, consulta la sezione Best practice correlata.
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 soddisfare i tuoi obiettivi di rendimento del carico di lavoro di inferenza.
Best practice: utilizza le dimensioni del backlog (coda) di precompilazione per massimizzare il throughput e ridurre al minimo i costi entro una determinata soglia di latenza target
Consigliamo la scalabilità automatica delle dimensioni della coda di precompilazione quando ottimizzi il throughput e il costo e quando i target di latenza sono raggiungibili con il throughput massimo delle dimensioni del batch per dispositivo del server del modello.
Le dimensioni della coda di precompilazione sono direttamente correlate alla latenza delle richieste. Le richieste in entrata vengono accodate nella coda di precompilazione dei server del modello 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 basata sulla dimensione della coda di precompilazione riduce al minimo il tempo di attesa nella coda aumentando le risorse in caso di carico e riducendole 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.
Se vuoi massimizzare la velocità effettiva di ogni replica del server del modello, valuta la possibilità di concentrarti sulle dimensioni della coda di precompilazione. Le dimensioni della coda di precompilazione tengono traccia delle richieste in sospeso, non in elaborazione. JetStream utilizza il batch continuo, che massimizza le richieste simultanee e mantiene la coda bassa quando lo spazio batch è disponibile. La coda aumenta in modo significativo quando lo spazio batch è limitato, quindi utilizza il punto di crescita come segnale per avviare lo scale up. Combinando la scalabilità automatica delle dimensioni della coda con la velocità effettiva ottimizzata dei batch, puoi massimizzare la velocità effettiva delle richieste.
Determinare il valore di soglia ottimale per la 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 finché 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 prevede un intervallo di inattività di 0,1 intorno al valore target per smorzare l'oscillazione.
Le dimensioni della coda di precompilazione non controllano direttamente le richieste simultanee, pertanto la sua soglia non può garantire una latenza inferiore a quella consentita dalle dimensioni 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 slots_used per raggiungere soglie di latenza target inferiori rispetto 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 in base a slots_used garantisce che il throughput dei tuoi workload aumenti per massimizzare il numero di richieste elaborate in parallelo contemporaneamente e diminuisca quando il numero di richieste elaborate in parallelo è inferiore. Ciò ha due implicazioni per la latenza. Innanzitutto, poiché la scalabilità automatica basata su slots_used viene eseguita per garantire uno slot per ogni richiesta in entrata, la vicinanza della soglia a 1 corrisponde alla probabilità che una richiesta trascorra del tempo in coda e di conseguenza abbia una latenza maggiore. In secondo luogo, batch di dimensioni maggiori aumentano la velocità effettiva, ma anche la latenza a causa della fase di precompilazione di alcune richieste che interrompono la fase di decodifica di altre nei server del modello di batch 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 le dimensioni della coda soddisfano 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 impostare le dimensioni del batch per dispositivo su un valore appropriato prima di esplorare la scalabilità automatica basata su slots_used. Se vuoi, puoi anche abbinare questa opzione alla scalabilità automatica basata sulla coda.
Determinare il valore soglia ottimale della percentuale slots_used per HPA
Per scegliere la soglia della dimensione batch corretta, aumenta sperimentalmente il carico sul server e osserva dove raggiunge il picco. 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 la percentuale target di slots_used. Imposta il valore target iniziale leggermente inferiore a 1 e diminuiscilo finché non raggiungi la latenza preferita.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento della metrica.
Limitazioni
Tieni presente la tolleranza HPA, che è un intervallo di inattività predefinito di 0,1 intorno al valore target per smorzare l'oscillazione.
La scalabilità automatica in base alla percentuale di slots_used, sebbene utile per il controllo della latenza, presenta delle limitazioni. Le dimensioni variabili delle richieste e i vincoli hardware rendono difficile trovare la giusta soglia della percentuale slots_used. Se una regola di scalabilità tenta di mantenere la percentuale media di slots_used al di sotto del 100%, significa che la regola di scalabilità tenta di mantenere un numero diverso da zero di slot disponibili. Questi slot disponibili corrispondono alla velocità effettiva disponibile non utilizzata, il che non è l'ideale se vuoi sfruttare al meglio le TPU disponibili.
Best practice: utilizza la memoria ad alta larghezza di banda (HBM) della TPU per massimizzare l'utilizzo dell'hardware
L'utilizzo della memoria ad alta larghezza di banda (HBM) della TPU ha la corrispondenza più diretta con l'utilizzo dell'hardware, anche rispetto alle metriche di sistema, poiché non tengono conto delle dimensioni delle richieste. Sebbene lo scaling in base alle dimensioni della coda massimizzi meglio l'utilizzo dell'hardware, lo fa a scapito della latenza. Se preferisci affidarti alle metriche di sistema anziché a quelle del server, ti consigliamo l'utilizzo della memoria HBM come migliore alternativa per la scalabilità automatica con slots_used, poiché entrambe corrispondono alla velocità effettiva. Per maggiori informazioni sulla memoria TPU, vedi Come funziona una TPU.
L'aumento della dimensione del batch oltre il punto ottimale migliora la velocità effettiva, ma aumenta anche il rischio di errori di esaurimento della memoria. Ti consigliamo vivamente di scalare in base alla metrica HBM per bilanciare throughput e stabilità. Ti consigliamo di non eseguire lo scaling contemporaneamente con le dimensioni della coda di precompilazione e l'utilizzo di HBM, poiché all'aumentare del carico, l'utilizzo di HBM aumenterà e attiverà prima lo scaling.
Determina il valore soglia ottimale di utilizzo della HBM della TPU per HPA
Prima di scegliere la soglia di utilizzo della memoria, ti consigliamo di impostare le dimensioni del batch per dispositivo su un valore che massimizzi la memoria utilizzata quando il sistema funziona con il carico massimo previsto. Tieni presente che questo valore dovrà essere determinato in modo sperimentale e dipenderà molto dall'HBM totale, nonché dalle lunghezze previste di prompt e risposte. Ti consigliamo di utilizzare lo strumento locust-load-inference
per i tuoi esperimenti e test.
Analogamente alla dimensione del batch per dispositivo, imposta la soglia per massimizzare l'utilizzo della memoria TPU riducendo al minimo il rischio di comportamento OOM.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento della metrica.
Limitazioni
Esistono due avvertenze che riducono la forza con cui la latenza e il throughput corrispondono all'utilizzo di HBM, ovvero la volatilità dell'utilizzo di HBM e la frequenza di campionamento inferiore delle metriche TPU in generale. Inoltre, sebbene esista ancora una corrispondenza tra l'utilizzo di HBM e la latenza, gli aumenti dell'utilizzo di HBM influiscono sulla latenza molto meno degli aumenti del numero di richieste in coda.
Best practice: ottimizza la configurazione di HPA
Ti consigliamo di impostare queste opzioni di configurazione di HPA:
- Finestra di stabilizzazione: utilizza questa opzione di configurazione di HPA per impedire modifiche rapide del conteggio delle repliche a causa di metriche fluttuanti. I valori predefiniti sono 5 minuti per lo scale down (per evitare una riduzione prematura) e 0 per lo scale up (per garantire la reattività). Modifica il valore in base alla volatilità dei carichi di lavoro e alla reattività che preferisci.
- Policy di scalabilità: utilizza questa opzione di configurazione HPA per ottimizzare il comportamento di scalabilità orizzontale e riduzione della scalabilità. Puoi impostare il limite dei criteri "Pod" per specificare il numero assoluto di repliche modificate per unità di tempo e il limite dei criteri "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.