Questa guida alle best practice mostra le metriche disponibili e come selezionare quelle adatte per configurare Horizontal Pod Autoscaler (HPA) per i tuoi workload di inferenza su GKE. L'HPA è un modo efficiente per garantire che i server dei modelli si scalino in modo appropriato con il carico. La messa a punto fine delle impostazioni HPA è il modo principale per allineare il costo dell'hardware provisionato alle richieste di traffico al fine di raggiungere gli obiettivi di rendimento del server di inferenza.
Per esempi di come implementare queste best practice, consulta Configurare la scalabilità automatica per i workload LLM su GPU con GKE.
Obiettivi
Questa guida è rivolta ai clienti di AI generativa, agli utenti GKE nuovi o esistenti, agli ingegneri ML e agli ingegneri LLMOps (DevOps) interessati a ottimizzare i loro carichi di lavoro LLM utilizzando le GPU con Kubernetes.
Dopo aver letto questa guida, dovresti essere in grado di:
- Scopri 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 del server
I server di inferenza LLM più diffusi, come TGI, vLLM e NVIDIA Triton, emettono metriche sul 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 informazioni dettagliate 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 agli indicatori di rendimento più pertinenti. Le metriche chiave a livello di server per la scalabilità automatica includono:
- Dimensioni 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 scoprire di più, consulta la sezione relativa alle best practice.
- Dimensioni del batch: il numero di richieste sottoposte a inferenza. Utilizza le dimensioni dei batch per raggiungere soglie di latenza target inferiori alle dimensioni della coda. Per approfondire, consulta la sezione relativa alle 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 la quantità di lavoro eseguita 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 in uso 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 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 eseguiti su CPU, le metriche sull'utilizzo della CPU e della memoria sono in genere la metrica di scalabilità automatica principale.
Per i carichi di lavoro di inferenza in esecuzione su GPU, non consigliamo di utilizzare l'utilizzo della CPU e della memoria come unici indicatori della quantità di risorse consumate da un job, in quanto i carichi di lavoro di inferenza si basano principalmente sulle risorse GPU. Pertanto, l'utilizzo unicamente delle 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 in modo da raggiungere gli obiettivi di rendimento del tuo carico di lavoro di inferenza.
Best practice: utilizza la dimensione della coda per massimizzare il throughput e ridurre al minimo i costi 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é un aumento del carico riempie rapidamente la coda.
La scalabilità automatica in base alle dimensioni della coda riduce al minimo il tempo di coda aumentando le risorse sotto carico e diminuendole quando la coda è vuota. Questo approccio è relativamente facile da implementare e in gran parte indipendente dal carico di lavoro, poiché 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 al contempo la configurazione del server del modello. La dimensione della coda tiene traccia delle richieste in attesa, non in lavorazione. vLLM e TGI utilizzano il raggruppamento continuo, che massimizza le richieste simultanee e mantiene la coda bassa quando è disponibile spazio per i batch. La coda cresce notevolmente quando lo spazio per i batch è limitato, quindi utilizza il punto di crescita come indicatore per avviare lo scale-up. Combinando la scalabilità automatica delle dimensioni della coda con un throughput batch ottimizzato, puoi massimizzare il throughput delle richieste.
Determina il valore ottimale della soglia della dimensione della coda per l'HPA
Tieni presente la tolleranza HPA, che per impostazione predefinita ha un intervallo di assenza di azioni pari a 0,1 intorno al valore target per smorzare 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 delle metriche.
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 le dimensioni dei batch per raggiungere soglie di latenza target inferiori alle dimensioni della coda
Ti consigliamo di scegliere la scalabilità automatica basata sulle dimensioni dei batch se hai carichi di lavoro sensibili alla latenza in cui la scalabilità basata sulla coda non è sufficientemente rapida per soddisfare i tuoi requisiti.
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 in base alle dimensioni dei batch garantisce che il carico di lavoro venga scalato per massimizzare il numero di richieste elaborate contemporaneamente in parallelo e fare lo scale down quando vengono elaborate meno richieste 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, le dimensioni del batch sono importanti per i carichi di lavoro sensibili alla latenza. 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 i pattern delle dimensioni dei batch e utilizzare la scalabilità automatica per minimizzare le richieste simultanee durante i picchi di carico.
Se il server del 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.
Determina il valore 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 corretta per la dimensione del batch, aumenta sperimentalmente il carico sul tuo server e osserva dove si verificano i picchi della dimensione del batch. 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 valore massimo e diminuiscilo fino a raggiungere 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 dei 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 le dimensioni del batch.
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 dell'HPA per evitare rapide variazioni del conteggio delle repliche a causa di 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à). Modifica il valore in base alla volatilità del tuo carico di lavoro e alla reattività che preferisci.
- Criteri di scalabilità: utilizza questa opzione di configurazione dell'HPA per perfezionare il comportamento di scaling up e scaling down. 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.