Metodtips för GPU för Azure Kubernetes Service (AKS)

Att köra GPU-arbetsbelastningar i ett AKS-kluster kräver korrekt konfiguration och kontinuerlig validering för att säkerställa att beräkningsresurserna är tillgängliga, säkra och optimalt utnyttjade. Den här artikeln beskriver metodtips för att hantera GPU-aktiverade noder, validera konfigurationer och minska arbetsbelastningsavbrott med hjälp av leverantörsspecifika diagnostikkommandon.

GPU-arbetsbelastningar, till exempel AI-modellträning, slutsatsdragning i realtid, simuleringar och videobearbetning, beror ofta på följande konfigurationer:

• Korrigera GPU-drivrutinen och körningskompatibiliteten.
• Korrekt schemaläggning av GPU-resurser.
• Åtkomst till GPU-maskinvaruenheter i containrar.

Felkonfigurationer kan leda till höga kostnader, oväntade jobbfel eller GPU-underutnyttjande.

Framtvinga GPU-arbetsbelastningsplacering

Som standard placerar AKS-schemaläggaren poddar på alla tillgängliga noder med tillräckligt med CPU och minne. Utan vägledning kan detta leda till två viktiga problem:

1. GPU-arbetsbelastningar kan schemaläggas på noder utan GPU:er och kan inte startas, eller
2. Allmänna arbetsbelastningar kan uppta GPU-noder, vilket slösar bort kostsamma resurser.

Så här framtvingar du rätt placering:

• Taint dina GPU-noder med hjälp av en nyckel som [gpu-vendor].com/gpu: NoSchedule (t.ex. nvidia.com/gpu: NoSchedule). Detta blockerar icke-GPU-arbetsbelastningar från att schemaläggas där.
• Lägg till en matchande tolerans i specifikationen för GPU-arbetsbelastningspodden så att den kan schemaläggas på de fördärvade GPU-noderna.
• Definiera GPU-resursbegäranden och gränser i podden för att säkerställa att schemaläggaren reserverar GPU-kapacitet, till exempel:

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

• Använd valideringsprinciper eller antagningskontrollanter för att framtvinga att GPU-arbetsbelastningar innehåller nödvändiga toleranser och resursgränser.

Den här metoden garanterar att endast GPU-klara arbetsbelastningar hamnar på GPU-noder och har åtkomst till de specialiserade beräkningsresurser som krävs.

Innan du distribuerar GPU-produktionsarbetsbelastningar kontrollerar du alltid att dina GPU-nodpooler är:

• Utrustad med kompatibla GPU-drivrutiner.
• Värd för en felfri DaemonSet för Kubernetes Device Plugin.
• Exponera [gpu-vendor].com/gpu som en schemaläggningsbar resurs.

Du kan bekräfta den aktuella drivrutinsversionen som körs på dina GPU-nodpooler med systemhanteringsgränssnittet (SMI) som är associerat med GPU-leverantören.

Följande kommando körs inifrån din GPU-enhets-plugin-distributionspodd nvidia-smi för att verifiera drivrutinsinstallation och körningsberedskap i en NVIDIA GPU-aktiverad nodpool:

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

Dina utdata bör likna följande exempelutdata:

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

Upprepa steget ovan för varje GPU-nodpool för att bekräfta drivrutinsversionen som är installerad på noderna.

I dina AMD GPU-aktiverade nodpooler kan du alternativt distribuera AMD GPU-komponenterna och köra amd-smi kommandot i plugin-podden för ROCm-enheten för att bekräfta drivrutinsversionen som är installerad.

Håll GPU-aktiverade noder uppdaterade till den senaste nod-OS-avbildningen

För att säkerställa prestanda, säkerhet och kompatibilitet för dina GPU-arbetsbelastningar i AKS är det viktigt att hålla dina GPU-nodpooler uppdaterade med de senaste rekommenderade nodoperativsystemavbildningarna. Dessa uppdateringar är viktiga eftersom de:

• Inkludera de senaste GPU-drivrutinerna i produktionsklass och ersätt eventuella inaktuella versioner eller EOL-versioner (end-of-life).
• Testas fullständigt för kompatibilitet med din aktuella Kubernetes-version.
• Åtgärda kända sårbarheter som identifierats av GPU-leverantörer.
• Införliva de senaste förbättringarna av operativsystemet och containerkörningen för förbättrad stabilitet och effektivitet.

Uppgradera dina GPU-nodpooler till den senaste rekommenderade nod-OS-avbildningen som släpptes av AKS, antingen genom att ange kanalen autoupgrade eller genom manuell uppgradering. Du kan övervaka och spåra de senaste nodbildversionerna med hjälp av AKS-versionsspåraren.

Separera GPU-arbetsbelastningar när du använder delade kluster

Om ett enda AKS-kluster med GPU-nodpooler kör flera typer av GPU-arbetsbelastningar, till exempel modellträning, slutsatsdragning i realtid eller batchbearbetning, är det viktigt att separera dessa arbetsbelastningar till:

• Undvik oavsiktlig interferens eller resurskonkurrering mellan olika arbetsbelastningstyper.
• Förbättra säkerheten och upprätthålla efterlevnadsgränser.
• Förenkla hanteringen och övervakningen av GPU-resursanvändning per arbetsbelastningskategori.

Du kan isolera GPU-arbetsbelastningar i ett enda AKS-kluster med hjälp av namnområden och nätverksprinciper. Detta möjliggör tydligare styrning via arbetsbelastningsspecifika kvoter, gränser och loggningskonfigurationer.

Exempelscenario

Överväg ett AKS-kluster som är värd för två olika GPU-arbetsbelastningstyper som inte behöver kommunicera med varandra:

• Träningsarbetsbelastningar: Resursintensiva AI-modellträningsjobb.
• Slutsatsdragningsarbetsbelastningar: Svarstidskänsliga realtidsinferenstjänster.

Du kan använda följande steg för att separera de två arbetsbelastningarna:

1. Skapa dedikerade namnområden per arbetsbelastningstyp med kommandot kubectl create namespace .

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

2. Märka GPU-arbetsbelastningspoddar efter typ, som du ser i följande exempel:

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

3. Använd nätverksprinciper för att isolera trafik mellan arbetsbelastningstyper. Följande manifest blockerar alla ingresser och utgående objekt för gpu-training namnområdet (såvida det inte uttryckligen tillåts):

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

Den här principen:

• Gäller för alla poddar i gpu-training namnområdet.
• Nekar all inkommande och utgående trafik som standard, vilket stöder stark isolering.

Den här modellen förbättrar tydligheten, kontrollen och säkerheten i delade GPU-miljöer, särskilt när arbetsbelastningstyper har olika körningsprofiler, risknivåer eller driftkrav.

Optimera resursanvändningen på GPU-noder med hjälp av GPU för flera instanser (MIG)

Olika GPU-arbetsbelastningar varierar i minneskraven och mindre distributioner (t.ex. NVIDIA A100 40GB) kanske inte behöver en hel GPU. Men en enskild arbetsbelastning monopoliserar GPU-resursen som standard även när den är underutnyttad.

AKS stöder resursoptimering på GPU-noder genom att dela upp dem i mindre sektorer med hjälp av GPU för flera instanser (MIG), så att teamen kan schemalägga mindre jobb mer effektivt. Läs mer om GPU-storlekar som stöds och hur du kommer igång med GPU:er för flera instanser i AKS.

Använda tillfälliga NVMe-datadiskar som cache med höga prestanda

För AI-arbetsbelastningar som körs på virtuella GPU-datorer i AKS är snabb och tillförlitlig åtkomst till tillfällig lagring avgörande för att maximera tränings- och slutsatsdragningsprestanda. Tillfälliga NVMe-datadiskar ger lagring med högt dataflöde och låg latens som är direkt kopplad till den virtuella datorns värd, vilket gör dem idealiska för scenarier som cachelagring av datauppsättningar, lagring av mellanliggande kontrollpunkter och modellvikter eller tillhandahålla utrymme för förbearbetning och analys av data.

När du distribuerar GPU-aktiverade nodpooler för AI-arbetsbelastningar, konfigurerar du tillfälliga NVMe-datadiskar för att fungera som högpresterande cacheminne eller tillfälligt utrymme. Den här metoden hjälper till att eliminera I/O-flaskhalsar, påskyndar dataintensiva åtgärder och säkerställer att dina GPU-resurser inte går på tomgång i väntan på data.

Tillfälliga NVMe-datadiskar stöds i en mängd olika azure GPU VM-familjer. Beroende på storleken på den virtuella GPU-datorn har den upp till 8 tillfälliga NVMe-datadiskar med en kombinerad kapacitet på upp till 28 TiB. Detaljerade konfigurationer av VM-storlekar finns i dokumentationen i ND H100 v5-serien eller dokumentationen om VM-storlek för din valda GPU-familj.

För att förenkla etablering och hantering använder du Azure Container Storage, som automatiskt kan identifiera och orkestrera tillfälliga NVMe-diskar för dina Kubernetes-arbetsbelastningar.

Rekommenderade scenarier är:

• Cachelagring av stora datamängder och modellkontrollpunkter för AI-träning och införande.
• Cachelagring av modellvikter för AI-slutsatsdragning. Till exempel KAITO-hostingmodell som OCI-artefakter på lokal NVMe.
• Ger snabbt temporärt utrymme för batchjobb och datapipelines.

Mer information om tillfälliga NVMe-datadiskar finns i Metodtips för tillfälliga NVMe-datadiskar i AKS.

Nästa steg

Mer information om distribution och hantering av GPU-arbetsbelastningar på AKS finns i följande artiklar:

• Skapa en GPU-aktiverad nodpool i ditt AKS-kluster .

• Övervaka GPU-arbetsbelastningar med självhanterad NVIDIA DCGM-exportör.

• Skala dina GPU-arbetsbelastningar automatiskt baserat på vanliga GPU-mått med KEDA och DCGM-exportör.