CloudWatch observe chaque GPU d’EKS et chiffre le gaspillage d’accélérateurs

Novembre 2026. AWS présente CloudWatch accelerated compute insights à KubeCon North America 2026. 12 novembre 2026. La capacité est disponible dans toutes les régions où CloudWatch Omni l’est déjà. Pourquoi c’est important : les GPU sont devenus la ressource la plus chère de l’informatique moderne, et la plupart des organisations les exploitent encore à l’aveugle — sans pouvoir dire qui utilise quelle carte, ni ce que le gaspillage leur coûte.

L’angle mort le plus coûteux du budget

Un seul cluster d’entraînement peut tourner des jours durant et coûter des millions de dollars. Pour rentabiliser ce capital, les équipes mettent les accélérateurs en commun sur des clusters partagés. Mais dans ces environnements, les équipes plateforme ne savent pas répondre à trois questions de base : quelle équipe utilise quel accélérateur, un workload d’inférence génère-t-il des tokens de façon efficace, et qu’est-ce qui gaspille de l’argent.

Le symptôme est connu. Quand un workload se dégrade — un accélérateur défaillant, un nœud qui bride thermiquement —, les équipes ne le découvrent qu’après un crash de run ou à la réception de la facture. Les signaux nécessaires pour isoler la cause (traces de requêtes, logs du kernel, métriques mémoire de la carte elle-même) ne sont ni collectés ni reliés entre eux. Faute de pouvoir pointer un accélérateur précis, la parade par défaut consiste à cycler l’instance entière : on sacrifie sept GPU sains pour traiter la panne d’un seul, puis on attend une capacité devenue rare.

C’est exactement le trou que la nouvelle capacité cherche à boucher. Son argument tient en une phrase, reprise par AWS dans l’annonce : « les GPU sont la ressource la plus chère de l’informatique moderne, et pourtant la plupart des organisations les opèrent avec très peu de visibilité ».

Ce que fait accelerated compute insights

Accelerated compute insights fournit une vue opérationnelle unique de chaque accélérateur de la flotte. Concrètement, elle affiche qui utilise les cartes GPU et AWS AI Accelerators à travers Amazon EKS, détecte les pannes et les goulets d’étranglement au moment où ils surviennent, estime l’impact financier de chaque problème, puis relie ces constats aux actions qui les résolvent.

La nouveauté tient au rapprochement de trois sources que les outils de monitoring classiques ne croisent jamais : la télémétrie de l’accélérateur, les frontières de workload et les données de tarification AWS. C’est ce croisement qui permet de transformer une métrique brute en une question de budget.

Chaque accélérateur du cluster est enrichi des métadonnées Kubernetes : pod, namespace, nœud, node group et labels personnalisés (équipe, application). On obtient ainsi une consommation par équipe et par workload sur l’ensemble de la flotte — ce qui répond enfin à la question « qui utilise quoi ».

Un détail de conception mérite l’attention : la détection automatique des GPU partitionnés en MIG (Multi-Instance GPU). La capacité reconnaît aussi d’autres schémas de partitionnement, comme le DRA (Dynamic Resource Allocation) de Kubernetes et le time-slicing, en lisant les labels des devices. Aucune configuration n’est requise.

Trois familles d’accélérateurs, une seule vue

Sur EKS, la capacité couvre les GPU NVIDIA, les AWS Trainium et les AWS Inferentia. Les métriques des cartes NVIDIA et Inferentia sont normalisées dans un schéma commun — via une couche baptisée Unified Accelerator Health Layer — puis présentées dans une vue unique Accelerator Health. Une équipe qui gère un parc mixte pilote donc tous ses types d’accélérateurs au même endroit, sans multiplier les dashboards par fournisseur.

Le croisement avec la tarification débouche sur trois catégories de gaspillage récupérable :

• Écarts d’efficacité à l’entraînement : une utilisation des tensor cores (MFU) faible par rapport à la référence historique du workload, signe que le job ne tire pas toute la valeur du matériel ;
• Inférence sous la capacité : des endpoints qui servent moins de requêtes que le matériel ne peut en absorber, corrélés à l’utilisation des devices ;
• Ressources inactives : de la capacité allouée mais non consommée.

Pour chaque constat, la capacité identifie le workload ou le nœud responsable. Précision importante, donnée par AWS : il s’agit d’un outil opérationnel, pas d’un outil de facturation. Les montants affichés sont des estimations destinées à guider les décisions, et l’autorité comptable reste AWS Cost Explorer et le Cost and Usage Report.

De l’alerte à la réparation, via l’agent DevOps

Les événements de santé peuvent être routés vers l’AWS DevOps Agent pour une investigation plus poussée. L’agent raisonne sur la télémétrie des accélérateurs, les logs CloudWatch, les changements d’infrastructure récents, la configuration des jobs et les runbooks que vous avez rédigés. Il distingue des modes de défaillance qui n’appellent pas la même action : un nœud dont la tendance d’erreurs mémoire s’accélère et qui mérite un remplacement, face à un problème de pilote qui se résout par un redémarrage.

Par défaut, l’agent présente un plan d’action argumenté à valider. Pour boucler plus vite, on peut l’autoriser à exécuter lui-même, via les API AWS, les remédiations qu’il juge bien comprises. C’est le prolongement logique de l’approche CloudWatch Omni, déjà présentée sur ce blog pour l’observation des agents IA, que vous retrouverez dans notre analyse dédiée.

L’activer en quelques minutes

Le chemin d’installation est court, à condition de partir de l’add-on officiel. Si vous exécutez de l’inférence auto-hébergée sur EKS, installez ou mettez à jour l’Amazon CloudWatch Observability EKS add-on en version v7.0.1 ou supérieure. L’add-on découvre chaque GPU NVIDIA et chaque device Inferentia du cluster et commence à émettre des données OpenTelemetry, sans setup par nœud ni pipeline à configurer.

helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm install amazon-cloudwatch-observability \
  aws-observability/amazon-cloudwatch-observability \
  --namespace amazon-cloudwatch --create-namespace

Une fois la télémétrie en flux, ouvrez CloudWatch Omni. La vue y est applicative plutôt qu’infrastructurelle : les workloads d’inférence apparaissent à côté des services et des agents IA qui les appellent, avec la santé, l’utilisation et le gaspillage de chaque accélérateur rattachés au workload. Quand un endpoint montre un débit faible ou un time to first token élevé, Omni remonte la cause jusqu’au workload, au nœud ou à la carte responsable — et indique quoi changer, sans changer d’outil.

Cette capacité complète une fondation posée tout au long de 2025 et 2026 : OTel Container Insights (GA en juin 2026) pour les métriques d’infrastructure, l’Application Performance Monitoring activé par défaut (février 2026), et l’observabilité réseau des conteneurs (novembre 2025). Il manquait la couche des accélérateurs eux-mêmes ; elle est désormais en place.

Ce que ça change face au bricolage DCGM + Prometheus

Beaucoup d’équipes exposent déjà les métriques de leurs cartes via le DCGM exporter de NVIDIA vers Prometheus et Grafana. Ce bricolage, devenu standard, résout la collecte : utilisation, mémoire, température, par GPU. Ce qu’il ne résout pas, c’est le reste de la chaîne.

La différence d’accelerated compute insights tient à quatre choses que le binôme DCGM + Prometheus ne croise pas par défaut : les métadonnées Kubernetes (qui consomme quoi, par équipe), la détection automatique du partitionnement (MIG, DRA, time-slicing), la jonction avec la tarification AWS qui transforme une métrique en euros, et la remédiation guidée par l’agent DevOps. Autrement dit, la collecte était déjà un problème résolu ; c’est la corrélation entre la métrique, le tenant et le coût qui ne l’était pas.

Le positionnement est donc simple. Si vous avez déjà une pile DCGM + Grafana mature, la valeur ajoutée se concentre sur la couche prix/gaspillage et sur la remédiation automatisée — le reste, vous l’avez. Si vous n’avez rien, accelerated compute insights est le chemin le plus court, parce qu’il livre d’un coup la collecte, la normalisation multi-fournisseurs et la corrélation applicative.

Verdict

Si vous exploitez des GPU ou des Trainium/Inferentia sur EKS — et surtout si vous les mutualisez entre équipes — installez l’add-on CloudWatch Observability v7.0.1 et activez accelerated compute insights avant votre prochaine revue de coûts. C’est le premier outil qui relie télémétrie par carte, frontières de workload et tarification dans une même vue, et c’est précisément ce qu’il faut pour remplacer le réflexe « cycler l’instance entière » par « réparer la carte fautive ». Si vous n’avez pas encore d’accélérateurs en production, notez simplement la dépendance pour le jour où vous y passerez — et ne payez pas d’observabilité GPU tant que votre parc n’en justifie pas le coût.

Références

• The New Stack — « Expensive accelerators, no workload-level visibility: Introducing Amazon CloudWatch accelerated compute insights » (11 novembre 2026)
• ETTAYEB — « AWS livre CloudWatch Omni pour observer et évaluer les agents IA »
• ETTAYEB — « CloudWatch centralise les logs multi-comptes sans pipeline maison »