Questa guida alle best practice mostra le metriche disponibili e come selezionarle per configurare Horizontal Pod Autoscaler(HPA) per i carichi di lavoro 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. Il perfezionamento delle impostazioni HPA è il modo principale per allineare il costo dell'hardware di cui è stato eseguito il provisioning alle richieste di traffico per raggiungere gli obiettivi di prestazioni del server di inferenza.
Per esempi di come implementare queste best practice, vedi Configurare la scalabilità automatica per i carichi di lavoro LLM su TPU con GKE.
Obiettivi
Questa guida è rivolta ai clienti di IA generativa, agli utenti GKE nuovi o esistenti, agli ML engineer e agli ingegneri LLMOps (DevOps) interessati a ottimizzare i propri carichi di lavoro JetStream con host singolo utilizzando TPU con Kubernetes.
Dopo aver letto questa guida, sarai in grado di:
- Scopri le metriche chiave della scalabilità automatica per l'inferenza JetStream a singolo host.
- Scopri i compromessi di alto livello quando prendi in considerazione le metriche in base alle quali applicare 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 delle prestazioni. 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 su base continuativa e le elabora contemporaneamente utilizzando 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 un singolo host JetStream, ciò ha due implicazioni per la latenza e la velocità effettiva:
- Le richieste non saranno arretrate nelle code se la frequenza di richieste in entrata è inferiore a quella con cui gli slot di decodifica sono in grado di elaborare le richieste. 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 messe in backlog nelle code una volta che la frequenza di richieste in entrata supera la frequenza con cui gli slot di decodifica sono in grado di elaborare le richieste. Se JetStream ha un backlog, la latenza delle richieste aumenterà in modo più significativo e proporzionale al numero di richieste in backlog, mentre la velocità effettiva rimarrà costante.
Le seguenti metriche del server avranno la correlazione maggiore con questi indicatori di prestazioni rilevanti; ti consigliamo di utilizzarli per la scalabilità automatica:
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 sotto forma di percentuale del numero totale di richieste che JetStream è in grado di gestire. Questa metrica ha una forte correlazione con la velocità effettiva. Per scoprire di più, consulta la sezione relativa alle best practice.
Queste metriche sono spesso resilienti alle prestazioni e alle fluttuazioni del traffico, il che le rende un punto di partenza affidabile per la scalabilità automatica in diverse configurazioni dell'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 per ottimizzare 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 entrata si trovano in coda nella coda di precompilazione dei server del modello prima di essere elaborate e questo tempo di coda si aggiunge alla latenza complessiva. Le dimensioni della coda sono un indicatore sensibile dei picchi di carico, poiché un carico maggiore riempie rapidamente la coda.
La scalabilità automatica basata sulle dimensioni della coda di precompilazione riduce al minimo il tempo in coda aumentando il carico sotto carico e lo scale down quando la coda è vuota. Questo approccio è relativamente facile perché le dimensioni della coda sono indipendenti dalle dimensioni, dal modello o dall'hardware della richiesta.
Valuta la possibilità di concentrarti sulle dimensioni della coda di precompilazione se vuoi massimizzare la velocità effettiva di ogni replica del server del modello. Tracce dimensioni coda di precompilazione in attesa, non in elaborazione, richieste. JetStream utilizza il raggruppamento continuo, che massimizza le richieste simultanee e mantiene la coda bassa quando è disponibile spazio per i batch. La coda aumenta in modo significativo quando lo spazio per il 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à effettiva batch ottimizzata, puoi massimizzare la velocità effettiva delle richieste.
Determinare il valore ottimale della soglia 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 fino a quando le richieste non raggiungono la latenza preferita. Utilizza lo strumento locust-load-inference per i test. Per soglie inferiori a 10, ottimizza le impostazioni di scale up dell'HPA in modo da 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 è un intervallo di nessuna azione di 0,1 attorno al valore target per attenuare 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 slot_used per raggiungere soglie di latenza target più basse rispetto alle dimensioni della coda
Ti consigliamo di scegliere la scalabilità automatica basata su slot_used se hai carichi di lavoro sensibili alla latenza in cui la scalabilità basata su code non è abbastanza veloce da soddisfare i tuoi requisiti.
La scalabilità automatica su slot_used assicura che la velocità effettiva dei carichi di lavoro aumenti per massimizzare il numero di richieste elaborate in parallelo contemporaneamente e lo scale down quando il numero di richieste elaborate in parallelo è inferiore. Ciò ha due implicazioni per la latenza. In primo luogo, poiché la scalabilità automatica basata su slot_used scala per garantire uno slot per ogni richiesta in entrata, quanto vicino alla soglia sia impostata su 1 corrisponderà alla probabilità che una richiesta passi del tempo in coda e di conseguenza abbia una latenza più elevata. In secondo luogo, i batch di dimensioni maggiori 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 pattern di dimensione del batch e utilizzare la scalabilità automatica per ridurre al minimo le richieste in parallelo 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.
Consigliamo inoltre di regolare la dimensione del batch per dispositivo su un valore appropriato prima di esplorare la scalabilità automatica basata su slot_used. Se vuoi, puoi anche abbinare questa opzione alla scalabilità automatica basata su coda.
Determina il valore ottimale della soglia percentuale di slots_used per l'HPA
Per scegliere la soglia giusta per la dimensione del batch, aumenta in modo sperimentale il carico sul server e osserva il punto in cui la dimensione del batch raggiunge il picco. Ti consigliamo inoltre di utilizzare lo strumento locust-load-inference per i test. Dopo aver identificato una dimensione ottimale per il batch di dispositivo in cui l'utilizzo della memoria è massimizzato, puoi configurare il target della percentuale slot_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, pur essendo utile per il controllo della latenza, presenta dei limiti. Dimensioni delle richieste e vincoli hardware variabili complicano l'individuazione della soglia percentuale slot_used corretta. Una regola di scalabilità che tenta di mantenere la percentuale media di slot_used al di sotto del 100% indica che la regola di scalabilità tenta di mantenere un numero di slot disponibili diverso da zero. Questi slot disponibili corrispondono alla velocità effettiva disponibile che non viene utilizzata, il che non è l'ideale se vuoi sfruttare al meglio le TPU disponibili.
Best practice: usa la memoria a larghezza di banda elevata (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é non prende in considerazione le 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é sulle metriche del server, ti consigliamo l'utilizzo di HBM come migliore alternativa per la scalabilità automatica con slot_used, poiché entrambi corrispondono alla velocità effettiva. Per ulteriori 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 (OOM). Ti consigliamo vivamente di eseguire il ridimensionamento in base alla metrica HBM per bilanciare il throughput e la stabilità. Consigliamo di non scalare con le dimensioni della coda di precompilazione e l'utilizzo di HBM contemporaneamente poiché, con l'aumento del carico, l'utilizzo di HBM aumenterà e di attivare 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 massimo previsto è inferiore. Tieni presente che questo valore dovrà essere determinato in modo sperimentale e dipenderà fortemente dall'HBM totale e dalle lunghezze previste di prompt e risposte. Ti consigliamo di utilizzare lo strumento locust-load-inference per gli esperimenti e i test.
Analogamente alla dimensione del batch per dispositivo, imposta la soglia per massimizzare l'utilizzo della memoria della TPU, riducendo al minimo il rischio di comportamento dell'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 queste opzioni di configurazione HPA:
- Finestra di stabilizzazione: utilizza questa opzione di configurazione HPA per evitare modifiche rapide al numero di repliche dovute alla fluttuazione delle metriche. 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à). Regola il valore in base alla volatilità dei carichi di lavoro e alla reattività che preferisci.
- Criteri di scalabilità: utilizza questa opzione di configurazione dell'HPA per ottimizzare 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.