Les outils de surveillance du CPU et de la mémoire ne se transposent pas aussi facilement aux GPU sur Kubernetes. Alors que la plateforme fournit généralement des métriques d’utilisation au niveau du conteneur ou du pod, les équipes chargées de la plateforme doivent, lorsqu’elles partagent un GPU, construire elles-mêmes la plupart des couches de visibilité, d’allocation et de facturation, depuis la collecte des données jusqu’à la détermination de la part des coûts revenant à chaque équipe.
L’importance du problème tient au fait que le GPU représente généralement le poste le plus coûteux de la facture d’infrastructure. L’analyse indique que le coût d’exploitation ne se limite pas au prix du nœud : il inclut également le temps d’ingénierie nécessaire pour combler les lacunes de mesure, vérifier l’exactitude des chiffres et empêcher les charges de dépasser ce que Kubernetes leur a alloué.
Pourquoi les métriques habituelles ne suffisent-elles pas ?
L’outil NVIDIA DCGM exporter, avec lequel commencent de nombreux opérateurs, fournit par défaut des données au niveau du dispositif physique. Lorsqu’un pod possède un GPU entier, cela peut suffire, mais la situation change en cas d’utilisation du time-slicing ou de MPS pour partager le dispositif. Dans ce cas, la même valeur peut apparaître pour chaque pod utilisant un GPU, donnant l’impression que trois charges ont consommé 300 % d’une unité qui n’existe pas réellement.
Le problème est que les graphiques peuvent sembler corrects alors que les données sous-jacentes ne sont pas valides pour l’attribution. Les équipes peuvent donc construire des rapports et des tableaux de bord complets à partir de chiffres qui ne distinguent pas réellement les consommateurs.
Qu’est-ce qui change concrètement pour les équipes chargées de la plateforme ?
Le GPU diffère également du CPU par son modèle d’allocation des ressources. Dans Kubernetes, le GPU apparaît généralement comme une ressource entière telle que nvidia.com/gpu: 1, et le planificateur ne permet pas de gérer les fractions de la manière habituelle avec les processeurs. Le partage effectif se produit sous le niveau du planificateur, via le time-slicing, MPS ou MIG, ce qui rend plus complexe la comparaison entre ce que la charge a demandé et ce qu’elle a utilisé.
Les équipes ont également besoin de contrôles indépendants pour vérifier que ce que Kubernetes a enregistré comme alloué correspond à ce que l’application peut réellement utiliser. En effet, la variable d’environnement NVIDIA_VISIBLE_DEVICES peut, si une configuration appropriée ne l’en empêche pas, permettre au conteneur de voir tous les GPU du nœud, même si le planificateur ne lui en a attribué qu’un seul.
En outre, l’expression « utilisation du GPU à 80 % » n’a pas nécessairement une seule signification. Elle peut mesurer uniquement la présence d’un noyau en fonctionnement pendant une partie de la fenêtre d’échantillonnage, sans préciser la consommation de la capacité de calcul ou de la bande passante mémoire. Dans certains frameworks, comme vLLM, la majeure partie de la mémoire du GPU peut être réservée au démarrage, ce qui fait de la mémoire ou de la bande passante un indicateur plus important que le taux d’utilisation global.
Facturation : la mémoire est plus facile à attribuer que le calcul
La bibliothèque NVIDIA NVML peut afficher la quantité de mémoire détenue par chaque processus, puis relier le processus au pod et à l’équipe qui en est responsable, en sachant que la somme des valeurs ne correspondra pas à la totalité de la mémoire de la carte, en raison de la partie réservée par le pilote lui-même.
En revanche, l’attribution du temps de calcul entre des charges fonctionnant en parallèle reste d’une précision limitée. Deux charges peuvent apparaître comme étant chacune active à 90 %, sans que les métriques indiquent laquelle a consommé 70 % de la capacité et laquelle en a consommé 30 %. L’analyse propose donc d’utiliser la mémoire du GPU comme base pratique pour la facturation interne, tout en traitant la mesure du calcul comme un indicateur opérationnel et non comme une référence précise pour facturer.
Le choix du modèle de partage modifie les calculs
Le partage d’un GPU ne correspond pas à un modèle unique. Le time-slicing alterne l’accès au dispositif sans isolation, MPS permet d’exécuter simultanément des noyaux provenant de différents processus, tandis que MIG divise le matériel en partitions fixes. Néanmoins, les services cloud peuvent facturer l’intégralité du GPU physique même lorsqu’une seule partie est utilisée ; en outre, les cartes des gammes A100 et H100 peuvent être divisées en sept instances au maximum, selon l’article.
Le Dynamic Resource Allocation (DRA) devrait constituer la voie future de la gestion des ressources, mais il se trouve encore dans une phase de maturation. Les outils qui l’entourent, notamment les outils de mise à l’échelle comme Karpenter, suivent eux aussi cette évolution.
Pourquoi cette information est-elle importante ?
Sur AWS, le prix du GPU compatible avec MIG le moins cher de la gamme A100 atteint environ 22 dollars de l’heure, soit environ 14 dollars avec la tarification spot, contre environ 5 dollars de l’heure pour une instance comparable reposant uniquement sur un CPU, selon l’article. Une erreur d’attribution de l’utilisation ne constitue donc pas un petit problème comptable : elle peut affecter directement les décisions relatives à la capacité, aux coûts et à l’équité de la répartition entre les équipes.
La conclusion éditoriale est que l’exécution de GPU sur Kubernetes nécessite encore un modèle opérationnel différent de celui du CPU et de la mémoire. Les équipes chargées de la plateforme doivent déterminer ce qui peut être mesuré avec précision, établir des règles claires de répartition des coûts et éviter de fonder leurs décisions comptables sur un indicateur général du GPU qui ne décrit pas la consommation réelle. En parallèle, la source indique que la maturation du DRA et le partitionnement du matériel pourraient progressivement réduire cet écart, mais le calendrier et les limites des outils actuels restent deux questions ouvertes.