Autoscaling GPU mal calibré : qui paie les 80 000 € de facture cloud ?

La plupart des incidents que craint un consultant Kubernetes sont bruyants : un cluster qui tombe, un déploiement qui échoue, un pod en CrashLoopBackOff. Tout le monde le voit dans la minute. La dérive de coûts GPU, elle, est le sinistre parfait : tout fonctionne, l'inférence répond, les dashboards sont verts. Et pourtant, en arrière-plan, des cartes graphiques facturées plusieurs euros de l'heure tournent à vide.

Sur un cluster managé (EKS, GKE, AKS), un node pool de GPU NVIDIA A100 ou H100 coûte entre 3 et 12 € de l'heure par carte. Un pool de huit cartes laissé allumé un week-end de trois jours, c'est mécaniquement entre 1 700 et 6 900 € envolés sans qu'un seul modèle n'ait servi une prédiction utile. Multipliez par un environnement de pré-production oublié, une boucle de retry dans un Argo Workflow qui relance des jobs d'entraînement, et la facture mensuelle peut doubler.

Le problème n'est pas technique au sens classique : rien n'est cassé. Le problème est contractuel et assurantiel. Quand le client découvre 80 000 € de surcoût non budgétés, il cherche un responsable. Et le consultant qui a conçu le scheduling GPU est le premier regardé.

Voici un scénario représentatif, reconstitué à partir de configurations réellement vues en mission. Un consultant MLOps est mandaté pour mettre en place l'autoscaling d'une plateforme d'inférence Triton sur GKE. Il configure le Cluster Autoscaler avec un node pool dédié GPU, et un HPA sur les pods KServe basé sur la latence.

Trois réglages, anodins isolément, se combinent en bombe à retardement :

• Le node pool GPU a un min-nodes de 1 au lieu de 0 : au moins une machine A100 reste allumée en permanence, week-ends compris.
• Le scaleDownDelayAfterAdd du Cluster Autoscaler est laissé à 10 minutes, mais un PodDisruptionBudget mal écrit empêche en pratique le drain des nœuds.
• Un DaemonSet de monitoring tolère le taint GPU et tourne sur chaque nœud, ce qui fait croire à l'autoscaler que le nœud est toujours occupé : il ne redescend jamais.

Résultat : un pool dimensionné pour un pic à 8 nœuds reste bloqué à 6 nœuds en continu pendant six semaines avant que quelqu'un n'ouvre la console de facturation.

Le client réclame ce surcoût au consultant. C'est là que se joue la question : faute professionnelle, ou aléa d'exploitation ?

Un consultant n'est pas l'assureur de la facture cloud de son client. La justice française raisonne en obligation de moyens : on vous reproche une faute, pas un mauvais résultat en soi. La ligne de partage tourne autour de trois questions.

1. Aviez-vous la maîtrise du paramètre fautif ?

Si le min-nodes à 1 est un choix que vous avez posé sans le documenter ni le justifier, la faute de conception est difficile à contester. Si en revanche le client a modifié votre configuration après la livraison, ou refusé un quota que vous aviez préconisé, la responsabilité bascule vers lui.

2. Aviez-vous une mission de surveillance ?

Concevoir un autoscaling et surveiller la facturation au quotidien sont deux missions distinctes. Si votre contrat s'arrête à la mise en production, le client ne peut pas vous reprocher de ne pas avoir vu la dérive six semaines durant : la surveillance FinOps lui incombait.

3. Aviez-vous mis des garde-fous ?

Le réflexe qui sauve : livrer toujours un budget alert, un quota de ressources (ResourceQuota / LimitRange) et un node pool capable de descendre à zéro. Ces garde-fous, documentés, démontrent que vous avez agi en professionnel diligent.

Un consultant qui a écrit noir sur blanc « je recommande d'activer des alertes de budget à 120 % du prévisionnel et de plafonner le node pool à 4 nœuds » se protège énormément, même si le client n'a pas suivi la recommandation. C'est la trace écrite qui transforme un sinistre en non-lieu.

La dérive de coûts GPU est un dommage immatériel pur : aucun bien endommagé, aucune blessure, juste un préjudice financier. C'est exactement le terrain de l'assurance RC Pro du consultant informatique.

Si une faute de conception est caractérisée — un paramètre que vous maîtrisiez, livré sans garde-fou — votre RC Pro intervient sur deux fronts :

• L'indemnisation du préjudice financier subi par le client, dans la limite des plafonds de votre contrat, déduction faite d'une éventuelle part de responsabilité du client.
• Vos frais de défense : avocat, expertise technique pour démontrer la part réelle de votre faute, et négociation amiable. Sur un litige à 80 000 €, ces frais se chiffrent vite en milliers d'euros, même si vous avez raison.

Attention au point clé : la RC Pro couvre la faute, pas la mauvaise affaire. Si le surcoût provient d'un choix d'architecture que le client a validé en connaissance de cause, ou d'un dépassement de budget que vous aviez signalé, il n'y a pas de faute à indemniser — mais la protection juridique reste utile pour le démontrer.

La meilleure assurance reste de rendre la dérive impossible ou, à défaut, de prouver que vous n'en êtes pas l'auteur. Voici la checklist du consultant MLOps prudent.

1. Node pool GPU scalable à zéro. Sauf besoin métier explicite, aucun pool GPU ne doit avoir un min-nodes supérieur à 0. C'est la première cause de cartes oubliées allumées.
2. ResourceQuota et LimitRange par namespace. Plafonnez le nombre de GPU qu'une équipe peut consommer. Une boucle Argo qui pète un plafond échoue proprement au lieu de saigner le budget.
3. Alertes de budget côté cloud. Configurez systématiquement un budget alert GCP/AWS/Azure à 80 % et 120 % du prévisionnel, et envoyez-le au client. La détection rapide limite le sinistre.
4. Documentez chaque arbitrage coût/perf. Chaque fois que vous choisissez un GPU plus cher ou une min-replica, écrivez pourquoi. C'est cette trace qui vous disculpe.
5. Cadrez la frontière de mission par écrit. Précisez si la surveillance FinOps post-mise-en-production fait partie ou non de votre prestation. L'ambiguïté contractuelle est ce qui vous expose le plus.

Ces réflexes, combinés à une RC Pro adaptée aux métiers MLOps, font la différence entre un sinistre qui vous coûte votre réputation et un incident géré sereinement. Pour aller plus loin sur les garanties spécifiques à votre activité, consultez notre page dédiée au consultant MLOps Kubernetes.

Un dernier point souvent négligé : la dérive de coûts n'est pas qu'un problème de configuration, c'est aussi un problème de gouvernance. Mettez en place avec le client une revue mensuelle FinOps des dépenses GPU, même brève. Vous y gagnez doublement : vous détectez les dérives avant qu'elles ne deviennent des sinistres, et vous démontrez, en cas de litige, que vous aviez instauré un dispositif de contrôle. Cette culture du suivi partagé est souvent ce qui dissuade un client de chercher un coupable : le sujet a été regardé ensemble, à temps.