Condividi tramite

Procedure consigliate per GPU per il servizio Azure Kubernetes

L'esecuzione di carichi di lavoro GPU in un cluster del servizio Azure Kubernetes richiede la corretta configurazione e la convalida continua per garantire che le risorse di calcolo siano accessibili, sicure e usate in modo ottimale. Questo articolo illustra le procedure consigliate per la gestione dei nodi abilitati per GPU, la convalida delle configurazioni e la riduzione delle interruzioni del carico di lavoro tramite comandi di diagnostica specifici del fornitore.

I carichi di lavoro GPU, ad esempio il training del modello di intelligenza artificiale, l'inferenza in tempo reale, le simulazioni e l'elaborazione video, spesso dipendono dalle configurazioni seguenti:

  • Correggere la compatibilità del driver GPU e del runtime.
  • Pianificazione accurata delle risorse GPU.
  • Accesso ai dispositivi hardware GPU all'interno dei contenitori.

Le configurazioni errate possono causare costi elevati, errori imprevisti dei processi o sottoutilizzo della GPU.

Imponi posizionamento del carico di lavoro GPU

Per impostazione predefinita, l'utilità di pianificazione del servizio Azure Kubernetes inserisce i pod in qualsiasi nodo disponibile con CPU e memoria sufficienti. Senza materiale sussidiario, ciò può causare due problemi principali:

  1. I carichi di lavoro GPU possono essere pianificati in nodi senza GPU e non possono essere avviati oppure
  2. I carichi di lavoro per utilizzo generico possono occupare nodi GPU, sprecando risorse costose.

Per applicare il posizionamento corretto:

  • Aggiungere taint ai nodi GPU usando una chiave come [gpu-vendor].com/gpu: NoSchedule (ad esempio, nvidia.com/gpu: NoSchedule). Questo impedisce la pianificazione dei carichi di lavoro non GPU.
  • Aggiungere una tolleranza corrispondente nella specifica del pod del carico di lavoro GPU in modo che possa essere pianificata nei nodi GPU contaminati.
  • Definire le richieste e i limiti delle risorse GPU nel pod, per garantire che l'utilità di pianificazione riserva capacità GPU, ad esempio:
resources:
  limits:
    [gpu-vendor].com/gpu: 1
  • Usare i criteri di convalida o i controller di ammissione per imporre che i carichi di lavoro GPU includano le tolleranze necessarie e i limiti delle risorse.

Questo approccio garantisce che solo i carichi di lavoro pronti per GPU approdano su nodi GPU e abbiano accesso alle risorse di calcolo specialistico necessarie.

Prima di distribuire carichi di lavoro GPU di produzione, verificare sempre che i pool di nodi GPU siano:

  • Dotato di driver GPU compatibili.
  • Hosting di un DaemonSet del plug-in del dispositivo Kubernetes integro.
  • Esposizione [gpu-vendor].com/gpu come risorsa pianificabile.

È possibile confermare la versione corrente del driver in esecuzione nei pool di nodi GPU con l'interfaccia di gestione del sistema (SMI) associata al fornitore della GPU.

Il comando seguente viene eseguito nvidia-smi dall'interno del pod di distribuzione del plug-in del dispositivo GPU per verificare l'installazione del driver e l'idoneità del runtime in un pool di nodi abilitato per GPU NVIDIA:

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

L'output dovrebbe essere simile all'output di esempio seguente:

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

Ripetere il passaggio precedente per ogni pool di nodi GPU per confermare la versione del driver installata nei nodi.

Nei pool di nodi abilitati per GPU AMD distribuire in alternativa i componenti GPU AMD ed eseguire il amd-smi comando nel pod del plug-in del dispositivo ROCm per confermare la versione del driver installata.

Mantenere i nodi abilitati per la GPU aggiornati all'immagine del sistema operativo del nodo più recente

Per garantire prestazioni, sicurezza e compatibilità dei carichi di lavoro GPU nel servizio Azure Kubernetes, è essenziale mantenere aggiornati i pool di nodi GPU con le immagini del sistema operativo del nodo consigliate più recenti. Questi aggiornamenti sono fondamentali perché:

  • Includono i driver GPU di livello di produzione più recenti, sostituendo eventuali versioni deprecate o fine del servizio (EOL).
  • Vengono testati completamente per la compatibilità con la versione corrente di Kubernetes.
  • Risolvono le vulnerabilità note identificate dai fornitori di GPU.
  • Incorporano i miglioramenti più recenti del sistema operativo e del runtime dei contenitori per migliorare la stabilità e l'efficienza.

Aggiornare i pool di nodi GPU all'immagine del sistema operativo del nodo consigliata più recente rilasciata dal servizio Azure Kubernetes, impostando il canale di aggiornamento automatico o tramite l'aggiornamento manuale. È possibile monitorare e tenere traccia delle versioni più recenti dell'immagine del nodo usando lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.

Separare i carichi di lavoro GPU quando si usano cluster condivisi

Se un singolo cluster del servizio Azure Kubernetes con pool di nodi GPU esegue più tipi di carichi di lavoro GPU, ad esempio il training del modello, l'inferenza in tempo reale o l'elaborazione batch, è importante separare questi carichi di lavoro per:

  • Evitare interferenze accidentali o conflitti di risorse tra diversi tipi di carico di lavoro.
  • Migliorare la sicurezza e mantenere i limiti di conformità.
  • Semplificare la gestione e il monitoraggio dell'utilizzo delle risorse GPU per categoria di carico di lavoro.

È possibile isolare i carichi di lavoro GPU all'interno di un singolo cluster del servizio Azure Kubernetes usando spazi dei nomi e criteri di rete. Ciò consente una governance più chiara tramite quote, limiti e configurazioni di registrazione specifiche del carico di lavoro.

Scenario di esempio

Si consideri un cluster del servizio Azure Kubernetes che ospita due diversi tipi di carico di lavoro GPU che non devono comunicare tra loro:

  • Carichi di lavoro di training: processi di training del modello di intelligenza artificiale a elevato utilizzo di risorse.
  • Carichi di lavoro di inferenza: servizi di inferenza in tempo reale sensibili alla latenza.

È possibile usare la procedura seguente per separare i due carichi di lavoro:

  1. Creare spazi dei nomi dedicati per tipo di carico di lavoro usando il kubectl create namespace comando.

    kubectl create namespace gpu-training
kubectl create namespace gpu-inference

  2. Etichettare i pod del carico di lavoro GPU per tipo, come illustrato nell'esempio seguente:

    metadata:
  namespace: gpu-training
  labels:
    workload: training

  3. Applicare criteri di rete per isolare il traffico tra i tipi di carico di lavoro. Il manifesto seguente blocca tutti i dati in ingresso e in uscita per lo spazio dei gpu-training nomi (a meno che non sia consentito in modo esplicito):

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: gpu-training
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress: []
  egress: []

Questo criterio:

  • Si applica a tutti i pod nello gpu-training spazio dei nomi .
  • Nega tutto il traffico in ingresso e in uscita per impostazione predefinita, supportando l'isolamento sicuro.

Questo modello migliora chiarezza, controllo e sicurezza negli ambienti GPU condivisi, soprattutto quando i tipi di carico di lavoro hanno profili di runtime, livelli di rischio o requisiti operativi diversi.

Ottimizzare l'utilizzo delle risorse nei nodi GPU usando GPU a istanze multipla (MIG)

Diversi intervalli di carichi di lavoro GPU in requisiti di memoria e distribuzioni più piccole (ad esempio NVIDIA A100 40 GB) potrebbero non avere bisogno di un'intera GPU. Tuttavia, un singolo carico di lavoro per impostazione predefinita monopolizza la risorsa GPU anche quando è sottoutilizzata.

Il servizio Azure Kubernetes supporta l'ottimizzazione delle risorse nei nodi GPU suddividendoli in sezioni più piccole usando GPU a istanza multipla (MIG), in modo che i team possano pianificare processi più piccoli in modo più efficiente. Altre informazioni sulle dimensioni della GPU supportate e su come iniziare a usare GPU a più istanze nel servizio Azure Kubernetes.

Usare dischi dati NVMe temporanei come cache ad alte prestazioni

Per i carichi di lavoro di intelligenza artificiale in esecuzione in macchine virtuali GPU nel servizio Azure Kubernetes, l'accesso rapido e affidabile all'archiviazione temporanea è fondamentale per ottimizzare le prestazioni di training e inferenza. I dischi dati NVMe temporanei offrono archiviazione a bassa latenza e velocità effettiva elevata direttamente collegata all'host della macchina virtuale, rendendoli ideali per scenari come la memorizzazione dei set di dati nella cache, l'archiviazione di checkpoint intermedi e i pesi del modello o lo spazio di lavoro per la pre-elaborazione e l'analisi dei dati.

Quando si distribuiscono pool di nodi abilitati GPU per i carichi di lavoro di intelligenza artificiale, configurare dischi dati NVMe temporanei per fungere da cache ad alte prestazioni o spazio di lavoro temporaneo. Questo approccio consente di eliminare i colli di bottiglia di I/O, accelerare le operazioni con uso intensivo di dati e assicura che le risorse GPU non siano inattive durante l'attesa dei dati.

I dischi dati NVMe temporanei sono supportati in un'ampia gamma di famiglie di macchine virtuali GPU di Azure. A seconda delle dimensioni della macchina virtuale GPU, ha fino a 8 dischi dati NVMe temporanei con una capacità combinata fino a 28 TiB. Per configurazioni dettagliate sulle dimensioni delle macchine virtuali, vedere la documentazione della serie ND H100 v5 o la documentazione relativa alle dimensioni della macchina virtuale per la famiglia di GPU scelta.

Per semplificare il provisioning e la gestione, usare Azure Container Storage, che consente di rilevare e orchestrare automaticamente i dischi NVMe effimeri per i carichi di lavoro Kubernetes.

Gli scenari consigliati includono:

  • Memorizzazione nella cache di ampi set di dati e checkpoint del modello per l'addestramento e l'inferenza dell'intelligenza artificiale.
  • Memorizzazione nella cache dei pesi del modello per l'inferenza dell'intelligenza artificiale. Ad esempio, il modello di hosting KAITO come artefatti OCI su NVMe locale.
  • Fornire spazio rapido per processi batch e pipeline di dati.

Importante

I dati nei dischi NVMe temporanei sono temporanei e andranno persi se la macchina virtuale viene deallocata o ridistribuita. Usare questi dischi solo per dati non critici, temporanei e archiviare informazioni importanti sulle soluzioni di archiviazione di Azure persistenti.

Per ulteriori indicazioni sui dischi dati NVMe temporanei, vedere Migliori pratiche per dischi dati NVMe temporanei in AKS.

Passaggi successivi

Per altre informazioni sulla distribuzione e la gestione del carico di lavoro GPU nel servizio Azure Kubernetes, vedere gli articoli seguenti:

  • Last updated on