Questa guida alle best practice illustra le metriche disponibili e come selezionare quelle adatte per configurare la scalabilità automatica pod orizzontale (HPA) per i carichi di lavoro di inferenza su GKE. HPA orizzontale è un modo efficiente per garantire che i server di modelli vengano scalati in modo appropriato in base al carico. La regolazione precisa delle impostazioni HPA pod orizzontale è il modo principale per allineare il costo dell'hardware di cui hai eseguito il provisioning alle esigenze di traffico per 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 sulle 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 di AI generativa, agli utenti GKE nuovi o esistenti, agli ingegneri di machine learning e agli ingegneri LLMOps (DevOps) interessati a ottimizzare i carichi di lavoro LLM utilizzando le GPU con Kubernetes.
Dopo aver letto questa guida, dovresti essere in grado di:
- Comprendere le metriche di scalabilità automatica per l'inferenza LLM.
- Comprendere i compromessi di alto livello quando si considerano le metriche su cui eseguire la scalabilità automatica.
Panoramica delle metriche di scalabilità automatica per l'inferenza LLM
Le seguenti metriche sono disponibili su GKE:
Metriche del server
I server di inferenza LLM più diffusi, come TGI, vLLM e NVIDIA Triton, emettono metriche di rendimento specifiche per il carico 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 visibilità sugli indicatori di rendimento, come le dimensioni del batch, le dimensioni della coda e le latenze di decodifica.
In base a queste metriche, puoi indirizzare la scalabilità automatica sugli 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 in 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 del batch: il numero di richieste sottoposte a inferenza. Utilizza le dimensioni del batch per raggiungere soglie di latenza target inferiori rispetto alle dimensioni della coda. Per saperne 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 GPU.
Metriche GPU
Le GPU emettono varie metriche di utilizzo e rendimento, offrendo la scalabilità automatica 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 lavoro, ovvero la quantità di tempo in cui la GPU è attiva. | Non misura la quantità di lavoro svolto mentre la GPU è attiva. Ciò rende difficile mappare le metriche di 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. È utile per i carichi di lavoro che implementano l'allocazione dinamica della memoria GPU. | Per i carichi di lavoro che preallocano la memoria GPU o non deallocano mai la memoria (ad esempio i carichi di lavoro in esecuzione su TGI e vLLM), questa metrica funziona solo per fare lo scale up e non per fare lo scale down quando il traffico diminuisce. |
Metriche della CPU
In GKE, HPA pod orizzontale funziona immediatamente con la scalabilità automatica basata su CPU e memoria. Per i carichi di lavoro in esecuzione 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 in esecuzione sulle GPU, non consigliamo l'utilizzo di CPU e memoria come unici indicatori della quantità di risorse utilizzate 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 costi e rendimento 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 raggiungere gli obiettivi di rendimento del carico di lavoro di inferenza.
Best practice: utilizza le dimensioni della coda 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 quando ottimizzi il throughput e i costi e quando i 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 basata sulle dimensioni della coda riduce al minimo il tempo di coda eseguendo lo scale up in caso di carico e 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, dal modello o dall'hardware.
Valuta la possibilità di concentrarti sulle dimensioni della coda se vuoi massimizzare il throughput rispettando la configurazione del server di modelli. Le dimensioni della coda monitorano le richieste in attesa, non quelle in elaborazione. vLLM e TGI utilizzano il batch continuo, che massimizza le richieste simultanee e mantiene bassa la coda quando è disponibile spazio batch. La coda aumenta in modo significativo quando lo spazio batch è limitato, quindi utilizza il punto di crescita come indicatore per avviare lo scale up. Combinando la scalabilità automatica delle dimensioni della coda con il throughput batch ottimizzato, puoi massimizzare il throughput delle richieste.
Determinare il valore di soglia delle dimensioni della coda ottimale per la scalabilità automatica HPA
Tieni presente la tolleranza della scalabilità automatica pod orizzontale, che per impostazione predefinita è un intervallo di non azione di 0,1 intorno al valore target per attenuare l'oscillazione.
Per scegliere la soglia delle dimensioni della coda corretta, inizia con un valore compreso tra 3 e 5 e aumentalo gradualmente finché le richieste non raggiungono la latenza preferita. Utilizza lo
locust-load-inference strumento per i test. Per le soglie inferiori a 10, regola con precisione le impostazioni di scale up della scalabilità HPA pod orizzontale per gestire i picchi di traffico.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento delle metriche.
Limitazioni
Le dimensioni della coda non controllano direttamente le richieste in parallelo, quindi la soglia non può garantire una latenza inferiore a quella consentita dalle dimensioni massime del batch. Come soluzione alternativa, puoi ridurre manualmente le dimensioni massime del batch o eseguire la scalabilità automatica 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 sulle dimensioni del batch se hai carichi di lavoro sensibili alla latenza in cui la scalabilità basata sulla coda non è abbastanza veloce da soddisfare i tuoi requisiti.
Le dimensioni del batch sono direttamente correlate al throughput e alla latenza di una richiesta in entrata. Le dimensioni del batch sono un buon indicatore per i picchi di carico, poiché un aumento del carico comporta l'aggiunta di più richieste al batch esistente, causando dimensioni del batch maggiori. In generale, maggiore è la dimensione del batch, maggiore è la latenza. La scalabilità automatica in base alle 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 il numero di richieste elaborate in parallelo è inferiore.
Se le dimensioni della coda soddisfano già i target di latenza, dai la priorità alla scalabilità automatica. In questo modo, massimizzi sia il throughput sia l'efficienza in termini di costi. Tuttavia, le dimensioni del batch sono utili per i carichi di lavoro sensibili alla latenza. Le dimensioni maggiori del batch 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 batch continuo. Puoi monitorare i pattern delle dimensioni del batch e utilizzare la scalabilità automatica per ridurre al minimo le richieste simultanee 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 abbinare questa opzione alla scalabilità automatica basata sulla coda.
Determinare il valore di soglia delle dimensioni del batch ottimale per la scalabilità automatica HPA
Tieni presente la tolleranza della scalabilità automatica pod orizzontale, che per impostazione predefinita è un intervallo di non azione di 0,1 intorno al valore target per attenuare l'oscillazione.
Per scegliere la soglia delle dimensioni del batch corretta, aumenta sperimentalmente il carico sul server e osserva dove raggiungono il picco le dimensioni del batch. Ti consigliamo inoltre di utilizzare lo
locust-load-inference strumento per i test. Dopo aver identificato le dimensioni massime del batch, imposta il valore target iniziale leggermente al di sotto di questo valore massimo e riducilo finché non raggiungi la latenza preferita.
Puoi anche creare una dashboard personalizzata di Cloud Monitoring per visualizzare il comportamento delle metriche.
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 delle dimensioni del batch corretta.
Best practice: ottimizza la configurazione della scalabilità automatica pod orizzontale
Ti consigliamo di impostare queste opzioni di configurazione HPA:
- Finestra di stabilizzazione: utilizza questa opzione di configurazione HPA orizzontale per impedire modifiche rapide del conteggio delle repliche a causa delle 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à). Regola il valore in base alla volatilità del carico di lavoro e alla reattività preferita.
- Policy di scalabilità: utilizza questa opzione di configurazione HPA pod orizzontale per regolare con precisione il comportamento di scale up e scale down. 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 saperne di più su queste opzioni, consulta scalabilità automatica orizzontale dei pod nella documentazione di Kubernetes open source.