Melhores práticas de observabilidade GPU para Azure Kubernetes Service (AKS)

Este artigo apresenta as melhores práticas para monitorizar e interpretar sinais de GPU no Azure Kubernetes Service (AKS). Em vez de analisar as métricas da GPU NVIDIA isoladamente, correlaciona-se os sinais entre o contexto de utilização, memória e carga de trabalho para melhorar o desempenho a longo prazo e a eficiência dos nós.

Compreenda a utilização da GPU versus a saturação

Não trate a métrica DCGM_FI_DEV_GPU_UTIL NVIDIA DCGM como uma pontuação direta de eficiência. DCGM_FI_DEV_GPU_UTIL Indica apenas com que frequência os kernels estão ativos, por isso não indica se a carga de trabalho é eficiente em termos de computação. Obtém-se orientações mais precisas ao correlacionar sinais de utilização em vez de os ler de forma independente. Compare DCGM_FI_DEV_GPU_UTIL com DCGM_FI_PROF_SM_ACTIVE, e depois compare DCGM_FI_PROF_SM_ACTIVE com DCGM_FI_PROF_DRAM_ACTIVE para identificar se o seu gargalo é sobrecarga de computação, memória ou lançamento e sincronização.

Alto DCGM_FI_DEV_GPU_UTIL com baixo DCGM_FI_PROF_SM_ACTIVE frequentemente aponta para sobrecarga de lançamento, atritos de sincronização ou contenção de memória. Alto DCGM_FI_PROF_SM_ACTIVE com baixo DCGM_FI_PROF_DRAM_ACTIVE é mais consistente com o comportamento de limitação por cálculo. Maior DCGM_FI_PROF_DRAM_ACTIVE com menor DCGM_FI_PROF_SM_ACTIVE geralmente aponta para execução limitada por memória.

Esta abordagem de correlação em primeiro lugar ajuda a evitar aumentar a escala quando o problema raiz pode ser a eficiência do kernel ou os padrões de acesso à memória. Para semântica métrica detalhada, consulte o guia do utilizador NVIDIA DCGM.

Usar pressão de memória como sinal primário de agendamento

Se a memória se aproximar repetidamente dos limiares de falta de memória, trate esse padrão como um indicador precoce de instabilidade. O Kubernetes não tem sinal nativo de pressão de memória para GPU, pelo que o esgotamento da VRAM normalmente só se manifesta como kill por falta de memória de contentores e disrupção de pods, frequentemente só quando a telemetria do DCGM já demonstra a tendência.

Automatizar ações do ciclo de vida dos nós a partir dos sinais de saúde da GPU

Esta prática é especialmente importante para pools de nós de longa duração de GPU AKS, onde o envelhecimento do host pode variar entre os nós.

Alinhar sinais de observabilidade com decisões de escalabilidade

Para escalonamento vertical, crie um novo pool de nós num SKU de VM da Azure diferente que suporte GPU e migre as cargas de trabalho quando as restrições de energia ou térmicas limitarem o desempenho, por exemplo, quando DCGM_FI_DEV_POWER_USAGE se mantém perto do limite enquanto DCGM_FI_PROF_SM_ACTIVE permanece estável apesar da demanda.

Políticas de observabilidade separadas para MIG e não-MIG

Quando o MIG está ativado, o âmbito de cada métrica muda, por isso interpreta os sinais de forma diferente.

Publicar métricas de eficiência de GPU sensíveis ao custo

Otimize para a visibilidade dos custos, não apenas para o desempenho. Uma métrica derivada de alto valor para equipas da plataforma AKS é os segundos de GPU usados versus os segundos de GPU alocados. Use telemetria DCGM e junções de contexto Kubernetes para publicar esta métrica por namespace e classe de carga de trabalho, depois revê-la ao longo do tempo como um KPI partilhado para equipas de plataforma e finanças. Esta abordagem define uma fonte comum de verdade para decisões de otimização e ajuda a evitar que a sobre-alocação seja oculta pelas médias agregadas de utilização.

Passos seguintes

• Revise as melhores práticas de GPU para AKS.
• Comece com a observabilidade gerida da GPU em AKS.
• Otimize a alocação com nós de GPU multi-instância (MIG).
• Escala com base nos sinais da GPU usando métricas KEDA e DCGM.