Questa guida alle best practice illustra le metriche disponibili e come selezionarle metriche adatte a configurare Horizontal Pod Autoscaler (HPA) per i tuoi carichi di lavoro di inferenza su GKE. HPA è un modo efficiente per garantire che i server del modello siano in grado di scalare in modo appropriato con il carico di lavoro. La messa a punto fine delle impostazioni HPA è il modo principale per allineare il costo dell'hardware provisionato alle richieste di traffico in modo da 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 GPU con GKE.
Obiettivi
Questa guida è rivolta ai clienti dell'IA generativa, nuovi o esistenti di utenti GKE, ML engineer e LLMOps (DevOps) che è interessato a ottimizzare i carichi di lavoro LLM utilizzando GPU con Kubernetes.
Dopo aver letto questa guida, sarai in grado di:
- Capire le metriche di scalabilità automatica per l'inferenza LLM.
- 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 LLM
In GKE sono disponibili le seguenti metriche:
Metriche server
I server di inferenza LLM più diffusi come TGI, vLLM e NVIDIA Triton emettono e metriche di prestazioni specifiche per i carichi di lavoro. GKE semplifica lo scraping e la scalabilità automatica dei carichi di lavoro in base a queste metriche a livello di server. Puoi utilizzare queste metriche per ottenere informazioni sugli indicatori di rendimento, come la dimensione dei batch, la dimensione della coda e le latenze di decodifica.
In base a queste metriche, puoi indirizzare la scalabilità automatica agli indicatori di rendimento più pertinenti. Le metriche chiave a livello di server per la scalabilità automatica includono:
- Dimensioni coda: numero di richieste in attesa di elaborazione in la coda del server. Utilizza le dimensioni della coda per massimizzare il throughput e ridurre al minimo i costi entro una determinata soglia di latenza target. Per scoprire di più, consulta la relativa sezione di best practice.
- Dimensioni del batch: il numero di richieste sottoposte a inferenza. Utilizza le dimensioni dei batch per raggiungere soglie di latenza target inferiori rispetto alle dimensioni della coda. A Per saperne di più, consulta la relativa sezione di best practice.
Queste metriche sono spesso resistenti alle fluttuazioni del rendimento e del traffico, pertanto rappresentano un punto di partenza affidabile per la scalabilità automatica su diverse configurazioni hardware GPU.
Metriche GPU
Le GPU emettono varie metriche di utilizzo e prestazioni, offrendo il ridimensionamento automatico indipendente dal carico di lavoro per qualsiasi attività basata su GPU, inclusi i carichi di lavoro di inferenza che non dispongono di metriche personalizzate. Per scoprire come configurare la raccolta DCGM, consulta Configurare la raccolta DCGM.
Le metriche GPU comuni per GKE includono:
| Metrica GPU | Utilizzo | Limitazioni |
|---|---|---|
Utilizzo GPU (DCGM_FI_DEV_GPU_UTIL) |
Misura il ciclo di servizio, ovvero il tempo di attività della GPU. | Non misura il lavoro svolto mentre la GPU è attiva. Ciò rende difficile mappare le metriche sul rendimento basate sull'inferenza, come la latenza e il throughput, a una soglia di utilizzo della GPU. |
Utilizzo memoria GPU (DCGM_FI_DEV_FB_USED) |
Misura la quantità di memoria GPU utilizzata in un determinato momento. Questo è utile per i carichi di lavoro che implementano l'allocazione dinamica della memoria GPU. | Per i carichi di lavoro che preallocano la memoria della GPU o non deallocano mai la memoria (ad esempio i carichi di lavoro in esecuzione su TGI e vLLM), questa metrica funziona solo per l'aumento e non verrà ridotta quando il traffico diminuisce. |
Metriche della CPU
In GKE, l'HPA funziona immediatamente con la scalabilità automatica basata su CPU e memoria. Per i carichi di lavoro in esecuzione su CPU, metriche di utilizzo di CPU e memoria sono in genere la metrica di scalabilità automatica principale.
Per i carichi di lavoro di inferenza in esecuzione su GPU, non sono consigliate CPU e memoria di utilizzo perché gli unici indicatori della quantità di risorse consumate da un job perché i carichi di lavoro di inferenza si basano principalmente su risorse GPU. Di conseguenza, l'uso Le metriche della CPU da sole per la scalabilità automatica possono portare a prestazioni e costi non ottimali.
Considerazioni per la scelta delle metriche di scalabilità automatica
Segui le considerazioni e le best practice riportate di seguito per selezionare la metrica migliore. per la scalabilità automatica su GKE al fine di soddisfare il carico di lavoro di inferenza obiettivi di rendimento.
Best practice: utilizza la dimensione della coda per massimizzare il throughput e ridurre al minimo il costo entro una determinata soglia di latenza target
Ti consigliamo di utilizzare l'autoscaling della dimensione della coda quando ottimizzi il throughput e il costo e quando i tuoi target di latenza sono raggiungibili con il throughput massimo della dimensione massima del batch del server del modello.
La dimensione della coda è direttamente correlata alla latenza della richiesta. Le richieste in arrivo vengono messe in coda nel 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é il carico aumenta rapidamente riempie la coda.
La scalabilità automatica basata sulle dimensioni della coda riduce al minimo il tempo di attesa aumentandolo sotto carico. lo scale down quando la coda è vuota. Questo approccio è relativamente facile da implementare e in gran parte indipendente dal carico di lavoro, perché le dimensioni della coda sono indipendenti dalle dimensioni della richiesta, modello o hardware.
Valuta la possibilità di concentrarti sulle dimensioni della coda se vuoi massimizzare la velocità effettiva rispettando la configurazione del server del modello. In attesa della traccia delle dimensioni della coda, non elaborazione, richieste. vLLM e TGI utilizzano il batch continuo, che massimizza richieste in parallelo e riduce la coda quando è disponibile spazio per batch. La coda aumenta notevolmente quando lo spazio per il batch è limitato, quindi utilizza le dimensioni come indicatore per avviare lo scale up. Combinando la scalabilità automatica delle dimensioni della coda con con una velocità effettiva ottimizzata per il batch, puoi massimizzare la velocità effettiva delle richieste.
Determina il valore ottimale della soglia della dimensione della coda per HPA
Tieni presente tolleranza HPA, che per impostazione predefinita è un intervallo di nessuna azione di 0,1 intorno al target per attenuare l'oscillazione.
Per scegliere la soglia corretta per la dimensione 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
La dimensione della coda non controlla direttamente le richieste in parallelo, pertanto la relativa soglia non può garantire una latenza inferiore a quella consentita dalla dimensione massima del batch. Come soluzione alternativa, puoi ridurre manualmente la dimensione massima del batch o utilizzare la scalabilità automatica in base alla dimensione del batch.
Best practice: utilizza la dimensione del batch per raggiungere soglie di latenza target più basse rispetto alle dimensioni della coda
Se disponi di dati sensibili alla latenza, ti consigliamo di scegliere la scalabilità automatica basata sulle dimensioni del batch in cui la scalabilità basata su code non è abbastanza veloce da soddisfare le tue esigenze.
La dimensione del batch è direttamente correlata alla velocità effettiva e alla latenza di una richiesta in entrata. La dimensione del batch è un buon indicatore degli picchi di carico, in quanto un aumento del carico comporta l'aggiunta di più richieste al batch esistente, con conseguente aumento della dimensione del batch. In generale, maggiore è la dimensione del batch, maggiore è la latenza. La scalabilità automatica per le dimensioni del batch garantisce che il carico di lavoro venga scalato per massimizzare il numero di richieste elaborate in parallelo contemporaneamente e fare lo scale down quando meno richieste vengono elaborate in parallelo.
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, la dimensione del batch è importante per carichi di lavoro sensibili alla latenza. I batch di dimensioni maggiori aumentano la velocità effettiva, ma aumentano 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 di dimensione del batch e utilizzare la scalabilità automatica al minimo le richieste in parallelo durante i picchi di carico.
Se il server del tuo modello lo consente, ti consigliamo di personalizzare la dimensione massima del batch come meccanismo di ottimizzazione aggiuntivo. Puoi anche abbinarlo alla scalabilità automatica basata su coda.
Determinare il valore di soglia ottimale per la dimensione del batch per l'HPA
Tieni presente la tolleranza HPA, ovvero un intervallo predefinito di 0,1 senza azioni attorno al valore target per smorzare l'oscillazione.
Per scegliere la soglia giusta per le dimensioni del batch, aumenta in modo sperimentale il carico sulle
sul tuo server e osserva il punto in cui la dimensione del batch raggiunge il picco. Ti consigliamo inoltre di utilizzare
locust-load-inference per i test. Una volta identificato il batch massimo
imposta la dimensione target iniziale leggermente al di sotto di questo valore massimo e diminuiscilo
fino a quando non si ottiene
la latenza preferita.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento delle metriche.
Limitazioni
La scalabilità automatica per le dimensioni del batch, sebbene sia utile per il controllo della latenza, presenta dei limiti. Le diverse dimensioni delle richieste e i vincoli hardware consentono di trovare la dimensione del batch corretta soglia difficile.
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 impedire rapidi il conteggio delle repliche cambia a causa della fluttuazione delle metriche. I valori predefiniti sono 5 minuti per la riduzione (per evitare una riduzione prematura) e 0 per l'aumento (per garantire la reattività). Modifica il valore in base alla volatilità del carico di lavoro e alla reattività preferita.
- Criteri di scalabilità: utilizza questa opzione di configurazione HPA per ottimizzare il comportamento di scale up e scale down. Puoi impostare i "Pod" limite del criterio da specificare il numero assoluto di repliche è cambiato per unità di tempo e la "Percentuale" norme da specificare in base alla variazione percentuale.
Per saperne di più su queste opzioni, consulta Scalabilità automatica orizzontale dei pod in Kubernetes open source documentazione.