Bästa praxis för GPU-observerbarhet för Azure Kubernetes Service (AKS)

Den här artikeln innehåller metodtips för övervakning och tolkning av GPU-signaler på Azure Kubernetes Service (AKS). I stället för att titta på NVIDIA GPU-mått isolerat korrelerar du signaler mellan användnings-, minnes- och arbetsbelastningskontexter för att förbättra långsiktig prestanda och nodeffektivitet.

Important

AKS-förhandsversionsfunktioner är tillgängliga via självbetjäning och frivillig registrering. Förhandsversioner tillhandahålls "i befintligt skick" och "i mån av tillgång," och de är undantagna från servicenivåavtal och begränsad garanti. AKS-förhandsversioner stöds delvis av kundsupport efter bästa förmåga. Därför är dessa funktioner inte avsedda för produktionsanvändning. Mer information finns i följande supportartiklar:

Förstå GPU-användning jämfört med mättnad

Behandla inte NVIDIA DCGM-måttet DCGM_FI_DEV_GPU_UTIL som en direkt effektivitetspoäng. DCGM_FI_DEV_GPU_UTIL anger bara hur ofta kernels är aktiva, så det anger inte om arbetsbelastningen är beräkningseffektiv. Du får mer exakt vägledning genom att korrelera användningssignaler i stället för att läsa dem oberoende av varandra. Jämför DCGM_FI_DEV_GPU_UTIL med DCGM_FI_PROF_SM_ACTIVEoch jämför DCGM_FI_PROF_SM_ACTIVE sedan med DCGM_FI_PROF_DRAM_ACTIVE för att identifiera om flaskhalsen är beräkning, minne eller start och synkronisering.

Hög DCGM_FI_DEV_GPU_UTIL med låg DCGM_FI_PROF_SM_ACTIVE pekar ofta på startoverhead, synkroniseringsfördröjningar eller minneskonflikter. Hög DCGM_FI_PROF_SM_ACTIVE med låg DCGM_FI_PROF_DRAM_ACTIVE är mer konsekvent med beräkningsbundet beteende. Högre DCGM_FI_PROF_DRAM_ACTIVE med lägre DCGM_FI_PROF_SM_ACTIVE pekar vanligtvis på minnesbunden körning.

Note

DCGM_FI_PROF_SM_ACTIVE och DCGM_FI_PROF_DRAM_ACTIVE är DCGM-profileringsfält och kanske inte visas som standard för alla NVIDIA GPU-arkitekturtyper som erbjuds i Azure VM-storlekar (Virtual Machine).

Den här korrelationsmetoden hjälper dig att undvika utskalning när rotproblemet kan vara kerneleffektivitet eller minnesåtkomstmönster. Detaljerad måttsemantik finns i användarhandboken för NVIDIA DCGM.

Använd minnestryck som primär schemaläggningssignal

Om minnet upprepade gånger närmar sig tröskelvärden för slut på minne ska du behandla det mönstret som en tidig indikator på instabilitet. Kubernetes har ingen inbyggd GPU-minnestryckssignal, så VRAM-överbelastning visas oftast endast som container-OOM-avbrott och poddavbrott, ofta långt efter att DCGM-telemetri visar trenden.

Automatisera nodlivscykelåtgärder från GPU-hälsosignaler

Den här metoden är särskilt viktig för långlivade AKS GPU-nodpooler där värdarnas åldrande kan variera mellan noder.

Justera observerbarhetssignaler med skalningsbeslut

För vertikal skalning skapar du en ny nodpool på en annan Azure GPU-aktiverad vm-SKU och migrerar arbetsbelastningar när energi- eller termiska begränsningar begränsar dataflödet, till exempel när DCGM_FI_DEV_POWER_USAGE förblir nära gränsen medan DCGM_FI_PROF_SM_ACTIVE förblir platt trots efterfrågan.

Separata MIG- och icke-MIG-observabilitetspolicyer

När MIG är aktiverat ändras omfånget för varje mått, så tolka signalerna på olika sätt.

Publicera kostnadsmedvetna GPU-effektivitetsmått

Optimera för kostnadssynlighet, inte bara prestanda. Ett härlett mått med högt värde för AKS-plattformsteam är GPU-sekunder som används jämfört med tilldelade GPU-sekunder. Använd DCGM-telemetri- och Kubernetes-kontextkopplingar för att publicera måttet efter namnområdes- och arbetsbelastningsklass och granska det sedan över tid som en delad KPI för plattforms- och ekonomiteam. Den här metoden definierar en vanlig sanningskälla för optimeringsbeslut och hjälper till att förhindra att överallokering döljs av aggregerade användningsgenomsnitt.

Nästa steg

  • Last updated on