Questa guida alle best practice mostra le metriche disponibili e come selezionare quelle adatte per configurare Horizontal Pod Autoscaler (HPA) per i workload di inferenza su GKE. HPA è un modo efficiente per garantire che i server dei modelli vengano scalati 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 per raggiungere gli obiettivi di rendimento del server di inferenza.
Per esempi di come implementare queste best practice, consulta Configura la scalabilità automatica per i workload LLM su GPU con GKE.
Per una panoramica consolidata di tutte le best practice di GKE, consulta Best practice per GKE.Obiettivi
Questa guida è destinata ai clienti dell'AI generativa, agli utenti GKE nuovi o esistenti, agli ML Engineer e agli ingegneri LLMOps (DevOps) interessati a ottimizzare i propri workload LLM utilizzando le GPU con Kubernetes.
Dopo aver letto questa guida, dovresti essere in grado di:
- Comprendi le metriche di scalabilità automatica per l'inferenza LLM.
- Comprendere i compromessi di alto livello quando si valutano le metriche su cui eseguire la scalabilità automatica.
Panoramica delle metriche di scalabilità automatica per l'inferenza LLM
Su GKE sono disponibili le seguenti metriche:
Metriche del server
I server di inferenza LLM più diffusi, come TGI, vLLM e NVIDIA Triton, emettono metriche sul rendimento specifiche per il workload. 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 visibilità su indicatori di prestazioni come dimensione del batch, dimensione della coda e latenze di decodifica.
In base a queste metriche, puoi indirizzare la scalabilità automatica verso gli indicatori di rendimento più pertinenti. Le metriche chiave a livello di server per la scalabilità automatica includono:
- Dimensioni della coda: il numero di richieste in attesa di elaborazione nella 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 saperne di più, consulta la sezione relativa alle best practice.
- Dimensioni batch: il numero di richieste sottoposte a inferenza. Utilizza la dimensione del batch per raggiungere soglie di latenza target inferiori rispetto alla dimensione della coda. Per scoprire di più, consulta la sezione relativa alle best practice.
Queste metriche sono spesso resilienti alle fluttuazioni del rendimento e del traffico, il che le rende un punto di partenza affidabile per la scalabilità automatica in diverse configurazioni hardware della GPU.
Metriche GPU
Le GPU emettono varie metriche di utilizzo e prestazioni, offrendo la scalabilità automatica indipendente dal workload per qualsiasi attività basata su GPU, inclusi i workload 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 periodo di tempo in cui la GPU è attiva. | Non misura la quantità di 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. Ciò è utile per i carichi di lavoro che implementano l'allocazione dinamica della memoria GPU. | Per i workload che preallocano la memoria della GPU o non la deallocano mai (ad esempio i workload in esecuzione su TGI e vLLM), questa metrica funziona solo per lo scale up e non esegue fare lo scale down quando il traffico diminuisce. |
Metriche della CPU
In GKE, HPA funziona immediatamente con la scalabilità automatica basata su CPU e memoria. Per i carichi di lavoro eseguiti sulle CPU, le metriche di utilizzo di CPU e memoria sono in genere la metrica di scalabilità automatica principale.
Per i carichi di lavoro di inferenza eseguiti sulle GPU, non consigliamo l'utilizzo di CPU e memoria come unici indicatori della quantità di risorse consumate da un job perché i carichi di lavoro di inferenza si basano principalmente sulle risorse GPU. Pertanto, l'utilizzo delle sole metriche della CPU per la scalabilità automatica può comportare prestazioni e costi non ottimali.
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 per soddisfare i tuoi obiettivi di rendimento del workload di inferenza.
Best practice: utilizza le dimensioni della coda per massimizzare la velocità effettiva e ridurre al minimo i costi entro una determinata soglia di latenza target
Ti consigliamo la scalabilità automatica delle dimensioni della coda quando ottimizzi il throughput e i costi e quando i tuoi target di latenza sono raggiungibili con il throughput massimo della dimensione massima del batch del server di modelli.
Le dimensioni della coda sono direttamente correlate alla latenza delle richieste. Le richieste in entrata vengono messe in coda nel server di modelli 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é l'aumento del carico riempie rapidamente la coda.
La scalabilità automatica in base alle dimensioni della coda riduce al minimo il tempo di attesa nella coda aumentando la scalabilità in base al carico e riducendola quando la coda è vuota. Questo approccio è relativamente facile da implementare e in gran parte indipendente dal workload, perché le dimensioni della coda sono indipendenti dalle dimensioni della richiesta, dal modello o dall'hardware.
Prendi in considerazione di concentrarti sulle dimensioni della coda se vuoi massimizzare il throughput rispettando la configurazione del server di modelli. La dimensione della coda tiene traccia delle richieste in sospeso, non in elaborazione. vLLM e TGI utilizzano il batch continuo, che massimizza le richieste in parallelo 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.
Determina il valore di soglia ottimale per le dimensioni della coda per l'HPA
Tieni presente la tolleranza HPA, che per impostazione predefinita prevede un intervallo di nessuna azione di 0,1 intorno al valore target per smorzare l'oscillazione.
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 soglie inferiori a 10, ottimizza le impostazioni di scale up dell'HPA per gestire i picchi di traffico.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento delle metriche.
Limitazioni
La dimensione della coda non controlla direttamente le richieste in parallelo, quindi la sua soglia non può garantire una latenza inferiore a quella consentita dalla dimensione massima del batch. Come soluzione alternativa, puoi ridurre manualmente le dimensioni massime del batch o scalare automaticamente in base alle dimensioni del batch.
Best practice: utilizza le dimensioni del batch per raggiungere soglie di latenza target inferiori rispetto alle dimensioni della coda
Ti consigliamo di scegliere la scalabilità automatica basata sulla dimensione batch se hai workload sensibili alla latenza in cui la scalabilità basata sulla coda non è abbastanza veloce per soddisfare i tuoi requisiti.
La dimensione del batch è direttamente correlata al throughput e alla latenza di una richiesta in entrata. La dimensione del batch è un buon indicatore dei 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 in base alla dimensione del batch garantisce che il workload faccia lo scale up per massimizzare il numero di richieste elaborate in parallelo contemporaneamente e fare lo scale down quando vengono elaborate meno richieste in parallelo.
Se le dimensioni della coda soddisfano già i tuoi target di latenza, dai la priorità alla scalabilità automatica. In questo modo, massimizzi sia il throughput sia l'efficienza dei costi. Tuttavia, le dimensioni del batch sono utili per i carichi di lavoro sensibili alla latenza. Batch di dimensioni maggiori aumentano il throughput, ma aumentano anche la latenza a causa della fase di precompilazione di alcune richieste che interrompono la fase di decodifica di altre nei server di modelli di batching continuo. Puoi monitorare i pattern delle dimensioni dei batch e utilizzare la scalabilità automatica per ridurre al minimo le richieste in parallelo durante i picchi di carico.
Se il server di modelli lo consente, ti consigliamo di personalizzare la dimensione massima del batch come meccanismo di ottimizzazione aggiuntivo. Puoi anche combinarlo con la scalabilità automatica basata sulla coda.
Determina il valore di soglia ottimale della dimensione del batch per l'HPA
Tieni presente la tolleranza HPA, che è un intervallo di inattività predefinito di 0,1 intorno al valore target per smorzare l'oscillazione.
Per scegliere la soglia della dimensione del batch corretta, aumenta sperimentalmente il carico sul server e osserva dove la dimensione del batch raggiunge il picco. Ti consigliamo inoltre di utilizzare lo strumento
locust-load-inference per i test. Una volta identificata la dimensione massima del batch, imposta il valore target iniziale leggermente al di sotto di questo massimo e diminuiscilo finché non viene raggiunta la latenza preferita.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento della metrica.
Limitazioni
La scalabilità automatica in base alle dimensioni del batch, sebbene utile per il controllo della latenza, presenta delle limitazioni. Le dimensioni variabili delle richieste e i vincoli hardware rendono difficile trovare la soglia corretta per la dimensione del batch.
Best practice: ottimizza la configurazione dell'HPA
Ti consigliamo di impostare queste opzioni di configurazione dell'HPA:
- Finestra di stabilizzazione: utilizza questa opzione di configurazione di HPA per evitare variazioni rapide del numero di repliche dovute a metriche fluttuanti. I valori predefiniti sono 5 minuti per la riduzione (per evitare una riduzione prematura) e 0 per l'aumento (per garantire la reattività). Regola il valore in base alla volatilità del workload 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 della policy "Pod" per specificare il numero assoluto di repliche modificate per unità di tempo e il limite della policy "Percentuale" per specificare la variazione percentuale.
Per scoprire di più su queste opzioni, consulta la sezione Scalabilità automatica orizzontale dei pod nella documentazione di Kubernetes open source.