Pourquoi l'observabilité des GPU sur Kubernetes nécessite une ingénierie spécifique

L'exécution de charges de travail IA sur Kubernetes révèle un contraste marqué entre la gestion des CPU et celle des GPU. Alors que l'utilisation du CPU et de la mémoire est accompagnée de métriques natives par pod et d'une attribution des coûts, les GPU partagés n'offrent rien de tout cela par défaut. En octobre 2026, les ingénieurs de plateforme doivent reconstruire manuellement la visibilité sur leur composant d'infrastructure le plus onéreux.

Ce qui s'est passé

Pendant des années, les utilisateurs de Kubernetes se sont appuyés sur des tableaux de bord standard pour suivre la consommation des ressources. Ces outils comparent ce qu'un conteneur a demandé avec ce qu'il a réellement utilisé, permettant aux équipes d'identifier le gaspillage et d'allouer les coûts par namespace. Ce modèle fonctionne parfaitement pour le CPU et la mémoire car le noyau suit automatiquement l'utilisation par conteneur. Cependant, ce flux de travail établi s'avère totalement inefficace lorsqu'il est appliqué aux unités de traitement graphique (GPU).

Lorsque les charges de travail migrent vers les GPU, les hypothèses valables pour les autres ressources ne tiennent plus. Les équipes de plateforme se retrouvent à reconstruire chaque couche de visibilité depuis zéro. Elles doivent créer leurs propres métriques, définir leurs propres normes de précision et inventer des règles pour répartir les factures. Cet effort manuel est particulièrement pénible car les coûts liés aux GPU représentent la dépense principale dans les budgets d'infrastructure IA modernes.

Comment cela fonctionne

Le problème fondamental réside dans la manière dont les métriques GPU sont exposées. Des outils comme l'exportateur DCGM de NVIDIA rapportent les données au niveau du périphérique physique par défaut. Cette approche fonctionne lorsqu'un seul pod possède l'intégralité d'un GPU. Toutefois, lorsque plusieurs pods partagent un GPU via le découpage temporel (time-slicing) ou le Multi-Process Service (MPS), l'exportateur attribue la même valeur totale d'utilisation à chaque pod. Si trois pods partagent un GPU, chacun apparaît comme utilisant 100 % du périphérique, ce qui aboutit à un chiffre absurde d'utilisation totale de 300 %. Le pilote n'expose qu'un seul jeu de compteurs pour l'ensemble du GPU, rendant impossible la distinction de la consommation individuelle de chaque charge de travail.

Le dimensionnement optimal (rightsizing) devient également complexe. Contrairement aux CPU, qui prennent en charge les millicores et le sur-engagement (overcommitting), les GPU sont généralement demandés sous forme d'unités entières. Le partage fractionné se produit au niveau inférieur au planificateur (scheduler) via le découpage temporel ou les partitions Multi-Instance GPU (MIG), ce qui signifie que les demandes Kubernetes ne correspondent pas exactement à l'utilisation réelle. De plus, les métriques d'utilisation du GPU sont ambiguës. Un GPU peut afficher une utilisation de 100 % tout en effectuant un calcul minimal, car les frameworks réservent souvent la majeure partie de la mémoire au démarrage. L'utilisation de la mémoire reste la métrique la plus fiable pour l'attribution, car le temps de calcul est difficile à mesurer précisément dans des environnements concurrents.

Détails clés

• L'exportateur DCGM de NVIDIA rapporte les données au niveau du périphérique, entraînant des chiffres d'utilisation gonflés lorsque les GPU sont partagés entre plusieurs pods.
• Les demandes de GPU dans Kubernetes sont des ressources à nombre entier, empêchant les stratégies de sur-engagement et de rafale (bursting) courantes avec les CPU.
• La variable d'environnement NVIDIA_VISIBLE_DEVICES peut permettre aux pods d'accéder à tous les GPU d'un nœud si elle n'est pas correctement écrasée par le plugin de périphérique.
• Les métriques d'utilisation du calcul sont peu fiables pour les charges de travail partagées, car elles indiquent une activité plutôt qu'une consommation proportionnelle des ressources.
• L'utilisation de la mémoire est le signal le plus précis pour l'attribution des coûts, bien qu'elle ne tienne pas compte des tranches de mémoire réservées par le pilote.
• Les fournisseurs cloud facturent les nœuds GPU comme des lignes uniques, nécessitant une décomposition manuelle pour attribuer les coûts à des modèles spécifiques ou à des équipes.

Pourquoi c'est important

Pour les développeurs logiciels, l'absence d'observabilité native des GPU se traduit directement par une charge de travail d'ingénierie inutile et une opacité financière. Les équipes ne peuvent pas simplement adopter leurs playbooks existants de surveillance des CPU. Au lieu de cela, elles doivent investir beaucoup de temps dans la création d'outils personnalisés pour suivre l'utilisation, appliquer des garde-fous et répartir les coûts. Cela détourne les ressources du développement produit vers la maintenance de l'infrastructure. Sans données précises, les organisations risquent de surdimensionner le matériel coûteux ou de ne pas refacturer les coûts aux bonnes équipes, entraînant des inefficacités budgétaires.

La complexité s'étend aux décisions d'architecture technique. Différents paradigmes de partage, tels que le découpage temporel, MPS et MIG, modifient les calculs sous-jacents pour l'allocation des ressources. L'allocation dynamique des ressources (DRA) mûrit dans Kubernetes, mais l'écosystème, y compris les autoscaleurs, doit encore rattraper son retard. Les ingénieurs doivent comprendre quel mode de partage utilisent leurs nœuds pour interpréter correctement les métriques. Une mauvaise interprétation de ces signaux peut entraîner des décisions de mise à l'échelle erronées et des goulots d'étranglement en termes de performance.

Ce que vous pouvez faire

• Auditez votre configuration actuelle de surveillance des GPU pour identifier si les métriques sont gonflées en raison du rapport au niveau du périphérique partagé.
• Priorisez les métriques d'utilisation de la mémoire plutôt que l'utilisation du calcul pour l'attribution des coûts et les modèles de refacturation.
• Vérifiez que le plugin de périphérique NVIDIA écrase correctement la variable d'environnement NVIDIA_VISIBLE_DEVICES dans tous les pods.
• Évaluez les fonctionnalités d'allocation dynamique des ressources (DRA) dans les nouvelles versions de Kubernetes pour une meilleure gestion des ressources.
• Développez des scripts personnalisés pour décomposer les factures des fournisseurs cloud et pondérer les coûts GPU selon des modèles matériels spécifiques.
• Établissez des définitions claires de l'utilisation pertinentes pour vos charges de travail IA spécifiques, telles que l'empreinte mémoire ou la bande passante.