Práticas recomendadas de observabilidade de GPU para AKS (Serviço de Kubernetes do Azure)

Este artigo fornece as práticas recomendadas para monitorar e interpretar sinais de GPU em AKS (Serviço de Kubernetes do Azure). Em vez de examinar as métricas de GPU da NVIDIA isoladamente, você correlaciona indicadores de utilização, memória e contexto de carga de trabalho para melhorar o desempenho de longo prazo e a eficiência dos nós.

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Entender a utilização de GPU versus saturação

Não trate a métrica DCGM_FI_DEV_GPU_UTIL NVIDIA DCGM como uma pontuação de eficiência direta. DCGM_FI_DEV_GPU_UTIL indica apenas a frequência com que os kernels estão ativos, portanto, ele não informa se a carga de trabalho é eficiente em termos de computação. Você obtém diretrizes mais precisas correlacionando sinais de utilização em vez de lê-los 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 gargalo é computação, memória ou lançamento e sincronização.

Um DCGM_FI_DEV_GPU_UTIL alto com um DCGM_FI_PROF_SM_ACTIVE baixo geralmente indica sobrecarga de inicialização, travamentos de sincronização ou disputa de memória. Um DCGM_FI_PROF_SM_ACTIVE alto com DCGM_FI_PROF_DRAM_ACTIVE baixo é mais consistente com o comportamento limitado pela capacidade de computação. Maior DCGM_FI_PROF_DRAM_ACTIVE com menor DCGM_FI_PROF_SM_ACTIVE geralmente indica uma execução com limitação de memória.

Note

DCGM_FI_PROF_SM_ACTIVE e DCGM_FI_PROF_DRAM_ACTIVE são campos de criação de perfil DCGM e podem não aparecer por padrão para todos os tipos de arquitetura de GPU NVIDIA oferecidos em tamanhos de VM (Máquina Virtual) Azure.

Essa abordagem que prioriza a correlação ajuda a evitar a expansão horizontal quando o problema principal pode estar na eficiência do kernel ou nos padrões de acesso à memória. Para obter semântica de métrica detalhada, consulte o guia do usuário do NVIDIA DCGM.

Use a pressão de memória como sinal primário para agendamento

Se a memória se aproximar repetidamente dos limites fora da memória, trate esse padrão como um indicador inicial de instabilidade. O Kubernetes não possui um indicador nativo de pressão sobre a memória da GPU; por isso, o esgotamento da VRAM geralmente só se manifesta por meio do encerramento de contêineres devido a OOM e da interrupção de pods, muitas vezes bem depois de a telemetria do DCGM já ter indicado essa tendência.

Automatizar ações do ciclo de vida dos nós com base nos sinais de integridade da GPU

Essa prática é especialmente importante para conjuntos de nós de GPU do AKS de longa duração, nos quais o envelhecimento dos hosts pode variar entre os nós.

Alinhar sinais de observabilidade com decisões de dimensionamento

Para dimensionamento vertical, crie um novo pool de nós em uma SKU diferente de VM habilitada para GPU no Azure e migre cargas de trabalho quando restrições térmicas ou de energia limitam a taxa de transferência, por exemplo, quando DCGM_FI_DEV_POWER_USAGE permanece perto do limite enquanto DCGM_FI_PROF_SM_ACTIVE permanece plano apesar da demanda.

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

Quando o MIG está habilitado, o escopo de cada métrica muda, portanto, interprete os sinais de forma diferente.

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

Otimize para visibilidade de custo, não apenas desempenho. Uma métrica derivada de alto valor para equipes de plataforma do AKS é os segundos de GPU usados em comparação com os segundos de GPU alocados. Use a telemetria do DCGM e as junções de contexto do Kubernetes para publicar essa métrica por namespace e classe de carga de trabalho e examine-a ao longo do tempo como um KPI compartilhado para equipes de plataforma e finanças. Essa abordagem define uma fonte comum de verdade para decisões de otimização e ajuda a impedir que a alocação excessiva seja ocultada por médias de utilização agregada.

Próximas Etapas