Aanbevolen GPU-procedures voor Azure Kubernetes Service (AKS)

Voor het uitvoeren van GPU-workloads op een AKS-cluster is de juiste installatie en continue validatie vereist om ervoor te zorgen dat rekenresources toegankelijk, veilig en optimaal worden gebruikt. In dit artikel vindt u een overzicht van aanbevolen procedures voor het beheren van GPU-knooppunten, het valideren van configuraties en het verminderen van workloadonderbrekingen met behulp van leverancierspecifieke diagnostische opdrachten.

GPU-workloads, zoals training van AI-modellen, realtime deductie, simulaties en videoverwerking, zijn vaak afhankelijk van de volgende configuraties:

• Corrigeer het GPU-stuurprogramma en de runtimecompatibiliteit.
• Nauwkeurige planning van GPU-resources.
• Toegang tot GPU-hardwareapparaten in containers.

Onjuiste configuraties kunnen leiden tot hoge kosten, onverwachte taakfouten of GPU-ondergebruik.

Plaatsing van GPU-workloads afdwingen

Standaard plaatst de AKS-planner pods op elk beschikbaar knooppunt met voldoende CPU en geheugen. Zonder hulp kan dit leiden tot twee belangrijke problemen:

1. GPU-workloads kunnen worden gepland op knooppunten zonder GPU's en kunnen niet worden gestart, of
2. Workloads voor algemeen gebruik kunnen GPU-knooppunten in beslag nemen en kostbare resources verspillen.

De juiste plaatsing afdwingen:

• Taint uw GPU-knooppunten met behulp van een sleutel zoals [gpu-vendor].com/gpu: NoSchedule (bijvoorbeeld nvidia.com/gpu: NoSchedule). Dit blokkeert dat niet-GPU-workloads daar worden gepland.
• Voeg een overeenkomende tolerantie toe in de gpu-workloadpodspecificatie, zodat deze kan worden gepland op de tainted GPU-knooppunten.
• Definieer GPU-resourceaanvragen en -limieten in uw pod om ervoor te zorgen dat de scheduler GPU-capaciteit reserveert, zoals:

resources:
  limits:
    [gpu-vendor].com/gpu: 1

• Gebruik validatiebeleid of toegangscontrollers om af te dwingen dat GPU-workloads de vereiste toleranties en resourcelimieten bevatten.

Deze aanpak garandeert dat alleen GPU-workloads terechtkomen op GPU-knooppunten en toegang hebben tot de gespecialiseerde rekenresources die ze nodig hebben.

Voordat u GPU-workloads voor productie implementeert, moet u altijd controleren of uw GPU-knooppuntgroepen het volgende zijn:

• Uitgerust met compatibele GPU-stuurprogramma's.
• Host een gezonde Kubernetes Device Plugin DaemonSet.
• [gpu-vendor].com/gpu Beschikbaar maken als een schedulable resource.

U kunt de huidige stuurprogrammaversie die wordt uitgevoerd op uw GPU-knooppuntgroepen bevestigen met de systeembeheerinterface (SMI) die is gekoppeld aan de GPU-leverancier.

De volgende opdracht wordt uitgevoerd nvidia-smi vanuit de implementatiepod van de GPU-apparaatinvoegtoepassing om de installatie van stuurprogramma's en runtimegereedheid in een knooppuntgroep met NVIDIA GPU-functionaliteit te controleren:

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

De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer:

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

Herhaal de bovenstaande stap voor elke GPU-knooppuntgroep om te bevestigen dat de versie van het stuurprogramma op uw knooppunten is geïnstalleerd.

Implementeer op uw AMD GPU-knooppuntgroepen ook de AMD GPU-onderdelen en voer de amd-smi opdracht uit in de POD van de ROCm-apparaatinvoegtoepassing om te bevestigen dat de versie van het stuurprogramma is geïnstalleerd.

Knooppunten met GPU bijgewerkt houden naar de meest recente installatiekopieën van het knooppuntbesturingssysteem

Om de prestaties, beveiliging en compatibiliteit van uw GPU-workloads op AKS te garanderen, is het essentieel om uw GPU-knooppuntgroepen up-to-date te houden met de meest recente aanbevolen installatiekopieën van knooppuntbesturingssystemen. Deze updates zijn essentieel omdat ze:

• Neem de nieuwste GPU-stuurprogramma's op productieniveau op, waarbij alle afgeschafte of end-of-life-versies (EOL) worden vervangen.
• Zijn volledig getest op compatibiliteit met uw huidige Kubernetes-versie.
• Los bekende beveiligingsproblemen op die zijn geïdentificeerd door GPU-leveranciers.
• Neem de nieuwste verbeteringen in het besturingssysteem en de containerruntime op voor verbeterde stabiliteit en efficiëntie.

Werk uw GPU-knooppuntpool(s) bij naar de meest recente aanbevolen installatiekopieën van het knooppuntbesturingssysteem die door AKS zijn vrijgegeven, door het kanaal autoupgrade of via handmatige upgrade in te stellen. U kunt de meest recente releases van knooppuntinstallatiekopieën bewaken en bijhouden met behulp van de AKS-releasetracker.

Gpu-workloads scheiden bij het gebruik van gedeelde clusters

Als in één AKS-cluster met GPU-knooppuntgroepen meerdere typen GPU-workloads worden uitgevoerd, zoals modeltraining, realtime deductie of batchverwerking, is het belangrijk om deze workloads te scheiden van:

• Vermijd onbedoelde interferentie of resourceconflicten tussen verschillende workloadtypen.
• Verbeter de beveiliging en behoud de nalevingsgrenzen.
• Vereenvoudig het beheer en de bewaking van GPU-resourcegebruik per workloadcategorie.

U kunt GPU-workloads binnen één AKS-cluster isoleren met behulp van naamruimten en netwerkbeleid. Dit maakt duidelijker beheer mogelijk via workloadspecifieke quota, limieten en logboekregistratieconfiguraties.

Voorbeeldscenario

Overweeg een AKS-cluster dat als host fungeert voor twee verschillende GPU-workloadtypen die niet met elkaar hoeven te communiceren:

• Trainingsworkloads: Resource-intensieve AI-modeltrainingstaken.
• Deductieworkloads: Latentiegevoelige realtime deductieservices.

U kunt de volgende stappen gebruiken om de twee werkbelastingen te scheiden:

1. Maak toegewezen naamruimten per workloadtype met behulp van de kubectl create namespace opdracht.

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

2. Label GPU-workloadpods per type, zoals wordt weergegeven in het volgende voorbeeld:

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

3. Pas netwerkbeleid toe om verkeer tussen workloadtypen te isoleren. Het volgende manifest blokkeert alle toegangs- en uitgaand verkeer voor de gpu-training naamruimte (tenzij expliciet toegestaan):

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

Dit beleid:

• Is van toepassing op alle pods in de gpu-training naamruimte.
• Weigert standaard al het binnenkomende en uitgaande verkeer, dat sterke isolatie ondersteunt.

Dit model verbetert de duidelijkheid, controle en veiligheid in gedeelde GPU-omgevingen, met name wanneer workloadtypen verschillende runtimeprofielen, risiconiveaus of operationele vereisten hebben.

Resourcegebruik op GPU-knooppunten optimaliseren met GPU (MIG) met meerdere exemplaren

Verschillende GPU-workloads variëren in geheugenvereisten en kleinere implementaties (bijvoorbeeld NVIDIA A100 40 GB) hebben mogelijk geen volledige GPU nodig. Een enkele workload wordt standaard echter gebruikt om de GPU-resource zelfs te onderbenutten.

AKS ondersteunt resourceoptimalisatie op GPU-knooppunten door ze op te splitsen in kleinere segmenten met behulp van GPU (MIG) voor meerdere exemplaren, zodat teams efficiënter kleinere taken kunnen plannen. Meer informatie over de ondersteunde GPU-grootten en hoe u aan de slag kunt met GPU's met meerdere exemplaren op AKS.

Tijdelijke NVMe-gegevensschijven gebruiken als cache met hoge prestaties

Voor AI-workloads die worden uitgevoerd op GPU-VM's in AKS, is snelle en betrouwbare toegang tot tijdelijke opslag essentieel voor het maximaliseren van training en deductieprestaties. Tijdelijke NVMe-gegevensschijven bieden opslag met hoge doorvoer, lage latentie die rechtstreeks is gekoppeld aan de VM-host, waardoor ze ideaal zijn voor scenario's zoals het opslaan van gegevenssets in de cache, het opslaan van tussenliggende controlepunten en modelgewichten, of het bieden van scratchruimte voor gegevensvoorverwerking en analyse.

Bij het implementeren van GPU-ondersteunde knooppuntgroepen voor AI-workloads configureert u tijdelijke NVMe-gegevensdisks om te fungeren als cache met hoge prestaties of tijdelijke ruimte. Deze aanpak helpt bij het elimineren van I/O-knelpunten, versnelt gegevensintensieve bewerkingen en zorgt ervoor dat uw GPU-resources niet inactief zijn tijdens het wachten op gegevens.

Tijdelijke NVMe-gegevensschijven worden ondersteund in een breed scala aan Azure GPU-VM-families. Afhankelijk van de GROOTTE van de GPU-VM heeft het maximaal 8 tijdelijke NVMe-gegevensschijven met een gecombineerde capaciteit van maximaal 28 TiB. Raadpleeg de documentatie van de ND H100 v5-serie of de VM-groottedocumentatie voor de gekozen GPU-serie voor gedetailleerde configuraties voor VM-grootten.

Gebruik Azure Container Storage, waarmee tijdelijke NVMe-schijven automatisch kunnen worden gedetecteerd en ingedeeld voor uw Kubernetes-workloads om het inrichten en beheren te vereenvoudigen.

Aanbevolen scenario's zijn:

• Grote gegevenssets en modelcontrolepunten opslaan in de cache voor AI-training en deductie.
• Gewichten van het cachemodel voor AI-inferentie. Bijvoorbeeld, KAITO-hostingmodel als OCI-artefacten op lokale NVMe.
• Snelle scratchruimte bieden voor batchtaken en gegevenspijplijnen.

Zie De aanbevolen procedures voor kortstondige NVMe-gegevensschijven in AKS voor meer informatie over tijdelijke NVMe-gegevensschijven.

Volgende stappen

Zie de volgende artikelen voor meer informatie over de implementatie en het beheer van GPU-workloads in AKS:

• Maak een gpu-knooppuntgroep in uw AKS-cluster .

• Bewaak GPU-workloads met behulp van zelfbeheerde NVIDIA DCGM-exporteur.

• Uw GPU-workloads automatisch schalen op basis van algemene GPU-metrische gegevens met KEDA en DCGM-exporteur.