Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit les meilleures pratiques pour surveiller et interpréter les signaux GPU sur Azure Kubernetes Service (AKS). Au lieu d’examiner les métriques GPU NVIDIA en isolation, vous mettez en corrélation les signaux entre l’utilisation, la mémoire et le contexte de charge de travail pour améliorer les performances à long terme et l’efficacité des nœuds.
Important
Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :
Comprendre l’utilisation du GPU et la saturation
Ne traitez pas la métrique DCGM_FI_DEV_GPU_UTIL NVIDIA DCGM comme un score d’efficacité direct.
DCGM_FI_DEV_GPU_UTIL indique uniquement la fréquence à laquelle les noyaux sont actifs, de sorte qu’il ne vous indique pas si la charge de travail est efficace pour le calcul. Vous obtenez des conseils plus précis en mettant en corrélation les signaux d’utilisation au lieu de les lire indépendamment. Comparez avec DCGM_FI_DEV_GPU_UTIL, puis comparez-les DCGM_FI_PROF_SM_ACTIVEDCGM_FI_PROF_SM_ACTIVEDCGM_FI_PROF_DRAM_ACTIVE pour identifier si votre goulot d’étranglement est le calcul, la mémoire ou la surcharge de lancement et de synchronisation.
Élevé DCGM_FI_DEV_GPU_UTIL avec faible DCGM_FI_PROF_SM_ACTIVE indique souvent une surcharge de lancement, des blocages de synchronisation ou une contention de mémoire. Un DCGM_FI_PROF_SM_ACTIVE élevé avec un DCGM_FI_PROF_DRAM_ACTIVE faible se révèle plus cohérent avec le comportement lié au calcul. Une valeur plus élevée DCGM_FI_PROF_DRAM_ACTIVE avec des valeurs plus faibles DCGM_FI_PROF_SM_ACTIVE indiquent généralement une exécution dépendante de la mémoire.
Note
DCGM_FI_PROF_SM_ACTIVE et DCGM_FI_PROF_DRAM_ACTIVE sont des champs de profilage DCGM et peuvent ne pas apparaître par défaut pour tous les types d’architecture GPU NVIDIA proposés dans les tailles de machines virtuelles Azure.
Cette approche de corrélation première vous permet d’éviter un scale-out lorsque le problème racine peut être l’efficacité du noyau ou les modèles d’accès à la mémoire. Pour obtenir une sémantique de métrique détaillée, consultez le guide de l’utilisateur NVIDIA DCGM.
Utiliser la pression de la mémoire comme signal de planification principal
Si la mémoire approche à plusieurs reprises des seuils de mémoire insuffisante, traitez ce modèle comme un indicateur précoce de l’instabilité. Kubernetes n’a pas de signal de pression de mémoire GPU natif, donc l'épuisement de la VRAM se manifeste généralement uniquement lorsque le conteneur est terminé par OOM et perturbe le pod, souvent bien après que la télémétrie DCGM ait montré la tendance.
Automatiser les actions de cycle de vie des nœuds à partir de signaux d’intégrité GPU
Cette pratique est particulièrement importante pour les pools de nœuds GPU AKS de longue durée où le vieillissement de l’hôte peut varier entre les nœuds.
Aligner les signaux d’observabilité avec les décisions de mise à l’échelle
Pour la mise à l’échelle verticale, créez un nouveau pool de nœuds sur une autre machine virtuelle Azure avec SKU compatible GPU et migrez les charges de travail lorsque des contraintes thermiques ou de puissance limitent le débit, par exemple lorsque DCGM_FI_DEV_POWER_USAGE se maintient près de la limite tandis que DCGM_FI_PROF_SM_ACTIVE demeure constant malgré la demande.
Stratégies d’observabilité MIG et non MIG distinctes
Quand MIG est activé, l’étendue de chaque métrique change, donc interpréter les signaux différemment.
Publier des métriques d’efficacité GPU prenant en charge les coûts
Optimisez la visibilité des coûts, et non seulement les performances. Une métrique dérivée à valeur élevée pour les équipes de plateforme AKS est des secondes GPU utilisées et des secondes GPU allouées. Utilisez la télémétrie DCGM et le contexte Kubernetes pour publier cette métrique par classe d’espace de noms et de charge de travail, puis examinez-la au fil du temps en tant qu’indicateur de performance clé partagé pour les équipes de plateforme et de finance. Cette approche définit une source courante de vérité pour les décisions d’optimisation et empêche l’allocation excessive d’être masquée par les moyennes d’utilisation agrégées.
Étapes suivantes
- Révisez les meilleures pratiques GPU pour AKS.
- Commencez avec l’observabilité managée AKS du GPU.
- Optimisez l’allocation avec des nœuds GPU multi-instances (MIG).
- Adapter en fonction des signaux GPU à l’aide des métriques KEDA et DCGM.