Leçon 3 — Le coût
Le paradoxe des factures d'IA
Comme vu en leçon 1, le calcul utile ne coûte presque rien : un affinage vaut quelques euros. Pourtant les factures dérapent régulièrement d'un facteur cinq ou dix.
L'explication tient en une phrase : vous ne payez pas pour le calcul que vous utilisez, vous payez pour les ressources que vous avez réservées. Une machine allumée qui ne fait rien coûte exactement le même prix qu'une machine qui entraîne.
Voici les cinq mécanismes, dans l'ordre de leur contribution réelle aux dérapages.
Mécanisme 1 — Les machines allumées sans travail
C'est la première cause, et de très loin.
Le scénario est toujours le même : quelqu'un lance une machine GPU pour un entraînement, l'entraînement finit, la personne part en week-end, et la machine tourne. Un GPU haut de gamme à 8 € l'heure oublié pendant un week-end de trois jours coûte environ 600 €. Oublié un mois, près de 6 000 €.
Les variantes sont nombreuses : un notebook managé laissé ouvert, une machine de test créée pour une démonstration, un cluster provisionné pour une expérience abandonnée.
Les remèdes, par ordre d'efficacité :
Utiliser les travaux managés du niveau 2 plutôt que des machines brutes. La plateforme éteint la machine à la fin du travail, et le problème disparaît structurellement. C'est la raison principale pour laquelle le service managé se rentabilise.
Un arrêt automatique sur inactivité, configuré sur tous les notebooks. Trente ou soixante minutes sans activité, extinction. Les trois plateformes le proposent, et il est désactivé par défaut.
Une politique d'étiquetage : toute ressource porte un propriétaire, un projet et une date d'expiration. Sans étiquette, personne ne sait à qui appartient une machine, et personne n'ose l'éteindre.
Un rapport hebdomadaire des ressources les plus coûteuses, envoyé à l'équipe. La simple visibilité change les comportements plus efficacement que n'importe quelle règle.
Mécanisme 2 — Les points de terminaison d'inférence provisionnés en permanence
Le deuxième piège, et il est plus insidieux parce qu'il paraît légitime.
Vous déployez un modèle derrière un point de terminaison. Il est provisionné en continu, avec au moins une instance, et il est facturé en continu — même s'il reçoit dix requêtes par jour.
Un point de terminaison avec GPU à 2 € l'heure représente environ 1 450 € par mois, pour un service qui pourrait ne consommer que quelques minutes de calcul réel.
Les remèdes :
Vérifier si le GPU est nécessaire. Comme signalé en leçon 1, beaucoup de modèles répondent en quelques dizaines de millisecondes sur processeur. Passer un point de terminaison de GPU à processeur divise souvent le coût par dix, sans effet perceptible.
Utiliser l'inférence sans serveur quand le trafic est intermittent. Vous payez à la requête, avec un temps de démarrage à froid en contrepartie. Pour un usage interne occasionnel, c'est presque toujours le bon choix.
Passer au traitement par lots. Si vos prédictions ne sont pas consommées à la seconde, la leçon sur le déploiement l'explique : une tâche nocturne remplace un service permanent. C'est le levier le plus radical.
Regrouper plusieurs modèles sur un même point de terminaison plutôt que d'en provisionner un par modèle.
Mécanisme 3 — Le surdimensionnement
Le réflexe est de prendre la machine la plus puissante disponible « pour aller plus vite ». Cela produit souvent l'inverse d'une économie.
Pourquoi cela ne va pas plus vite : sur beaucoup d'entraînements, le goulot d'étranglement n'est pas le GPU mais le chargement des données. Le GPU attend. Doubler sa puissance ne change rien au temps total, et double le prix à l'heure.
Comment le vérifier : regardez le taux d'utilisation du GPU pendant l'entraînement. En dessous de 60 %, votre problème est ailleurs — chargement des données, prétraitement, taille de lot trop petite. Corriger cela est gratuit et souvent plus efficace que changer de machine.
Sur l'inférence, le surdimensionnement est encore plus courant : un point de terminaison configuré pour un pic qui n'arrive jamais. Mesurez votre trafic réel, dimensionnez sur le percentile haut observé, et laissez la mise à l'échelle automatique gérer les pics.
Mécanisme 4 — Le stockage qui s'accumule
Moins spectaculaire, et régulier.
Ce qui s'accumule silencieusement : les données intermédiaires de pipelines, écrites et jamais nettoyées. Les points de sauvegarde de tous les entraînements, y compris les cinquante expériences ratées. Les journaux conservés indéfiniment. Les jeux de données dupliqués parce que trois personnes ont fait leur propre copie.
Les remèdes : des règles de cycle de vie sur les espaces de stockage — passage automatique en classe archive après trente jours, suppression après un an ; le nettoyage des artefacts intermédiaires en fin de pipeline ; et un inventaire annuel des données conservées, qui révèle systématiquement des surprises.
Mécanisme 5 — Les frais de sortie de données
Le poste que personne n'anticipe.
Faire entrer des données est gratuit ; les faire sortir est facturé au gigaoctet. Les situations qui coûtent : un jeu d'images téléchargé régulièrement pour travailler en local, un export nocturne vers un système sur site, une réplication vers un autre fournisseur, ou des utilisateurs qui téléchargent massivement des résultats.
Les remèdes : traiter les données là où elles sont plutôt que de les déplacer — c'est le principe le plus important ; utiliser un réseau de diffusion de contenu si des fichiers sont téléchargés à répétition ; et regrouper les transferts plutôt que de les multiplier.
Une note utile : la réglementation européenne sur les données a commencé à encadrer ces frais lorsqu'ils entravent le changement de fournisseur, et plusieurs grands acteurs les ont supprimés dans ce cas précis. Cela ne concerne pas les transferts d'exploitation courante.
Le levier le plus rentable : les instances spot
Une instance spot est une machine louée sur la capacité excédentaire du fournisseur, à 60 à 90 % de remise, que celui-ci peut reprendre à tout moment avec un préavis de quelques minutes.
Pourquoi c'est parfait pour l'entraînement : un entraînement qui sauvegarde son état toutes les dix minutes perd au maximum dix minutes de travail lors d'une reprise, puis redémarre ailleurs. La sauvegarde régulière est de toute façon une bonne pratique.
Pourquoi c'est inadapté à l'inférence : un service en ligne ne peut pas disparaître sans préavis.
Ce qu'il faut mettre en place : une sauvegarde périodique de l'état d'entraînement, une reprise automatique depuis la dernière sauvegarde, et une tolérance à un temps total variable. Les plateformes managées gèrent une grande partie de cette logique pour vous.
L'ordre de grandeur : un entraînement à 100 € en tarif à la demande revient à 20 ou 30 € en spot. Sur une année d'expérimentation intensive, l'économie est considérable.
Les autres leviers tarifaires : les engagements de durée — un à trois ans — donnent 30 à 60 % de remise sur une charge stable et prévisible. Ils conviennent à l'inférence en production, pas à l'expérimentation. Et le choix de la région influe : les écarts de prix entre régions atteignent 20 à 30 %, à arbitrer avec les contraintes de latence et de localisation des données.
Estimer un budget avant de commencer
Une méthode simple qui donne un ordre de grandeur fiable.
Pour l'entraînement : nombre d'expériences prévues × durée moyenne en heures × prix horaire de la machine. Puis multipliez par trois : vous ferez plus d'essais que prévu, et certains échoueront. Appliquez la remise spot si vous l'utilisez.
Pour l'inférence : si c'est en continu, prix horaire × 730 heures par mois, par instance. Si c'est sans serveur ou par lots, nombre de prédictions × coût unitaire.
Pour le reste : ajoutez 30 % pour le stockage, les services annexes, la journalisation et les transferts.
Le garde-fou indispensable : configurez une alerte de budget dès le premier jour, avant même de lancer la première machine. Toutes les plateformes le permettent en deux minutes. Une alerte à 50 %, une à 80 %, une à 100 % du budget mensuel prévu. C'est la mesure la plus rentable de tout ce cours, et elle est presque toujours mise en place après le premier incident plutôt qu'avant.
La liste de contrôle du coût
- Une alerte de budget est configurée, avec des seuils.
- L'arrêt automatique sur inactivité est activé sur tous les notebooks.
- Les entraînements passent par des travaux managés qui éteignent les machines.
- Les instances spot sont utilisées pour l'entraînement, avec sauvegardes.
- Le taux d'utilisation du GPU a été vérifié avant de choisir une machine plus puissante.
- La nécessité d'un GPU pour l'inférence a été vérifiée, pas supposée.
- Les points de terminaison à faible trafic sont sans serveur ou remplacés par du traitement par lots.
- Des règles de cycle de vie existent sur le stockage.
- Toute ressource porte un propriétaire et un projet en étiquette.
- Un rapport de coût est envoyé chaque semaine à l'équipe.
À retenir
- Vous payez les ressources réservées, pas le calcul utilisé : une machine oisive coûte le prix d'une machine qui travaille.
- Cause numéro un : les machines allumées sans travail. Le remède structurel est le travail managé qui éteint tout seul.
- Cause numéro deux : les points de terminaison provisionnés en permanence pour un trafic occasionnel.
- Le surdimensionnement ne fait pas gagner de temps si le goulot est le chargement des données : vérifiez le taux d'utilisation du GPU.
- Le stockage accumulé et les frais de sortie sont les deux postes silencieux.
- Les instances spot divisent le coût d'entraînement par trois à cinq ; c'est le levier le plus rentable.
- Configurez une alerte de budget avant de lancer la première machine.
Leçon suivante — La sécurité : ce qui reste à votre charge →