Optimiser les coûts ML avec Azure Machine Learning

Plusieurs caractéristiques propres au développement et au déploiement du ML en font une discipline coûteuse.

• Les modèles ML modernes, en particulier en deep learning, exigent des jeux de données massifs. Les stocker, les déplacer et les traiter pèse lourdement sur la facture.
• Les algorithmes complexes eux-mêmes — réseaux de neurones profonds à nombreuses couches ou techniques d'apprentissage par renforcement gourmandes en calcul — requièrent une puissance de traitement considérable.
• Le recours à du matériel spécialisé et rare, comme les GPU pour l'entraînement comme pour l'inférence, ajoute une prime aux coûts de compute.
• Le développement ML est itératif. Réentraîner plusieurs fois avec différents hyperparamètres, découpages de données ou nouvelles données signifie que chaque exécution expérimentale génère des dépenses de calcul supplémentaires. Un seul balayage de tuning d'hyperparamètres peut par exemple lancer des centaines de jobs d'entraînement individuels.
• Le développement ML est un processus complexe en plusieurs étapes : ingestion, nettoyage, transformation, entraînement, hypertuning, prédiction, etc. Le processus MLOps (Machine Learning Operations) accroît le risque de répétitions inutiles et d'opérations qui alourdissent la facture.

Des clients m'ont demandé : combien coûte un entraînement ML ? Je leur réponds que ces facteurs peuvent faire grimper les coûts à des niveaux quasi illimités : un seul entraînement de LLM a déjà dépassé les 150 millions de dollars, et l'entraînement complet se chiffre en milliards. Vous ne paierez pas autant, mais il faut comprendre qu'il n'y a aucun plafond.

Si les points abordés ici sont universels à tous les systèmes MLOps, AML lui-même contribue à réduire la facture. La plateforme ML cloud-native de Microsoft est conçue pour fluidifier l'ensemble du cycle de vie des modèles de machine learning, de la conception et de l'entraînement jusqu'au déploiement et à la gestion en production. Les services AML peuvent être utilisés indépendamment via des interfaces REST, mais ils s'intègrent aussi étroitement entre eux et avec l'écosystème Azure au sens large. Grâce à des architectures éprouvées et taillées pour l'efficacité, les services AML permettent de mettre en œuvre votre ML à moindre coût qu'en mode "do-it-yourself", même en payant pour les services eux-mêmes.

Je laisse de côté ici les modèles préconstruits comme les Large Language Models (LLM) et Azure Cognitive Services pour la vision ou la traduction. Ces services offrent moins de leviers de réglage fins, ce qui appelle une approche d'optimisation différente.

Pour piloter efficacement les coûts, il faut comprendre où va votre budget. Les principaux postes, par ordre approximativement décroissant, sont :

1. Compute : c'est généralement le poste le plus important ; il englobe le calcul (CPU, GPU) et la mémoire consommés pendant l'entraînement et le service des prédictions.
2. Stockage : Azure Blob Storage est massivement utilisé pour les jeux de données, les artefacts de modèles et les images de conteneurs dans Azure Container Registry. Le tier de stockage retenu, les options de redondance et le volume brut de données pèsent sur les coûts.
3. Réseau : même si l'entraînement et la prédiction proprement dits ne devraient pas générer de coûts réseau extrêmes, des frais peuvent s'accumuler avec la sortie de données, le peering VNet, les connexions ExpressRoute et l'usage de NAT Gateway. Transférer des téraoctets de données image depuis du stockage on-premises vers Azure Blob Storage pour l'entraînement, ou multiplier les échanges entre microservices dans un workflow MLOps, peut ainsi engendrer des dépenses réseau.
4. Services : cela inclut les frais des API SaaS Azure, comme Azure AI Search, Document Intelligence ou Bot Service.

Adopter un état d'esprit FinOps, c'est faire siens plusieurs principes fondamentaux.

Le premier est d'éviter le gaspillage. Les choix architecturaux, comme le service à utiliser, comptent, mais l'essentiel des coûts évitables provient des mauvais usages : utiliser des GPU là où des CPU suffiraient à l'entraînement, ou stocker des masses de données inutilisées dans des tiers Blob Storage onéreux.

Deuxièmement, standardisez votre architecture. Cela passe par l'utilisation des services AML, par exemple les Compute Targets dans les AML Workspaces pour l'entraînement, plutôt que de gérer vos propres flottes de Machines Virtuelles Azure. L'équipe Azure a bâti des systèmes efficaces qui vous font économiser : avec l'entraînement AML, vous ne payez que le compute nécessaire à l'entraînement, et non des VM facturées en continu (sauf à gérer vous-même l'autoscaling). Cela suppose aussi d'adopter des workflows standards, comme un pattern Continuous Training (CT) où du nouveau code ou de nouvelles données déclenchent automatiquement l'exécution d'un AML Pipeline. Ainsi, l'ingestion, l'entraînement, la vérification et le déploiement se produisent exactement quand il le faut, sans exécutions superflues ni attentes assez longues pour rendre les processus inefficaces.

Troisièmement, n'allez pas trop loin dans l'optimisation et tomber dans l'illusion d'efficacité. Compresser agressivement les données d'entraînement pour économiser sur le stockage peut paradoxalement faire grimper le coût global, à cause d'un temps CPU bien plus élevé pour la décompression à chaque epoch.

N'oubliez pas que le temps de vos ingénieurs coûte cher ; évitez de leur faire passer un temps disproportionné sur des micro-optimisations. Mettez ce temps à profit en privilégiant des architectures propres et maintenables plutôt que des optimisations ponctuelles : impossible d'anticiper aujourd'hui les besoins futurs, mais le moment venu de réduire les coûts, vous voudrez une architecture qui rende cet effort réalisable.

Enfin, pensez à itérer vos optimisations, en commençant par les plus gros postes de coût. Vous ne pouvez pas tout traiter en un seul cycle ; mieux vaut s'attaquer aux opportunités les plus accessibles, puis revérifier où se concentrent les coûts.

Ne ciblez pas le premier dépassement de coût qui attire votre attention. Le temps consacré à le corriger serait peut-être mieux employé ailleurs.

DoiT Cloud Intelligence (console.doit.com) dote les utilisateurs Azure d'outils puissants pour comprendre et maîtriser leurs dépenses cloud. Vous pouvez créer des rapports de facturation et des dashboards, définir des budgets et des alertes, recevoir des avertissements en cas d'anomalies de coût et obtenir des recommandations proactives d'économies. Une utilisation régulière de ces outils est la clé pour repérer les tendances, mettre en évidence les valeurs aberrantes et cibler les plus belles opportunités d'économies.

Optimiser les coûts d'entraînement

La phase d'entraînement est souvent la plus gourmande en ressources et, par conséquent, la plus coûteuse du cycle de vie ML. Elle consomme énormément de données et de puissance de calcul, et nécessite de nombreux cycles itératifs.

Right-sizing des machines : en surveillant l'utilisation des ressources (CPU, GPU, mémoire) avec Azure Monitor pendant l'entraînement, vous pouvez prendre des décisions éclairées. Si un GPU haut de gamme (par exemple une série ND H100 v5) reste constamment sous-utilisé, passer à une option plus économique (par exemple une VM série NCasT4_v3) a tout son sens.

N'utilisez les GPU que lorsque c'est nécessaire. Si votre modèle ne tire pas parti de l'accélération GPU, opter pour des VM optimisées CPU (comme la série F) revient moins cher. Quand vous utilisez des GPU, assurez-vous que votre code est pleinement optimisé pour exploiter leurs capacités, par exemple via des batch sizes adaptés et des pipelines de chargement de données efficaces.

Les Azure Spot Virtual Machines (VM Low Priority) offrent d'excellentes économies. Pour des jobs d'entraînement tolérants aux pannes (et vos systèmes devraient l'être !), les VM Spot peuvent générer jusqu'à 90 % d'économies par rapport aux tarifs pay-as-you-go. Elles conviennent parfaitement, par exemple, aux tâches de tuning d'hyperparamètres impliquant de nombreux essais indépendants, où l'interruption d'un seul essai ne compromet pas l'ensemble du processus.

Environnements de développement

Pour la phase de développement, Jupyter Notebooks ou Visual Studio Code dans un AML workspace offrent des postes de travail managés dans le cloud. Vous ne payez que le temps d'exécution effectif grâce aux politiques d'auto-shutdown, contrairement à un laptop puissant amorti 24h/24 et 7j/7 ou à une VM qui tourne en permanence tant que vous n'avez pas pensé à l'éteindre. Pour économiser davantage, déchargez les tâches lourdes : disposer de ressources puissantes dans votre environnement de développement, c'est payer un ensemble fixe de ressources sur toute la journée de travail. Plutôt que de lancer un entraînement dans votre notebook, soumettez les jobs longs et intensifs comme des AML training jobs qui s'exécuteront sur des Compute Clusters autoscalés et économes.

Stockage des données

Pour le MLOps sur Azure, Azure Blob Storage est la référence en stockage objet. J'ai vu des projets démarrer avec un simple disque local et passer à des Managed Disks, ou démarrer sur un réseau local et migrer vers Azure Files, mais ces options sont coûteuses : Blob Storage est le standard pour le ML et bien moins cher. Choisir les bons tiers d'accès (Hot, Cool, Archive) selon la fréquence d'accès est essentiel. La mise en place de politiques de gestion du cycle de vie permet d'automatiser ces transitions. Si vous n'entraînez par exemple que sur de nouvelles données, archivez ou supprimez automatiquement les anciennes au bout d'un mois.

Prédiction

Une fois vos modèles entraînés, vous les déployez pour servir les prédictions (inférence). Les AML Endpoints font économiser en s'autoscalant à partir de métriques intégrées. Comme pour l'entraînement, choisir l'instance la plus petite qui reste efficace permet aussi d'économiser. Le co-hébergement de modèles, ou déploiement multi-modèles, permet à plusieurs petits modèles de partager le même déploiement d'endpoint, réduisant la surcharge par modèle si ces derniers sont souvent appelés séquentiellement ou par la même application. Cependant, si un endpoint n'est pas utilisé, l'autoscaling ne le ramènera pas à zéro ressource ; à vous donc de l'éteindre. Si vous avez une application d'inférence à très faible trafic, veillez à scaler les endpoints à zéro ou bien déployez-la sur Azure Container Apps ou Azure Functions.

Pour les cas d'usage non temps réel, les Batch Endpoints sont nettement moins chers que la prédiction en ligne et offrent un meilleur débit, au prix d'une latence plus élevée. Optimiser le batch size et la configuration du compute cluster sous-jacent vous procurera les meilleures économies.

Monitoring : garder un œil sur les coûts et les performances

Les services AML disposent d'un monitoring intégré — autre avantage par rapport au "do-it-yourself". Ce monitoring fait baisser les coûts en s'assurant que vous tirez le meilleur parti des ressources pour produire des modèles de qualité.

Il existe deux types de monitoring : le Monitoring d'infrastructure, principalement via Azure Monitor, qui suit l'utilisation des ressources (CPU, GPU, mémoire) ainsi que la durée des jobs d'entraînement, la latence de prédiction et le QPS.

À l'inverse, le Monitoring de modèle suit des métriques propres au modèle, comme le score F1. Après le déploiement, ce monitoring vous aide à détecter la dérive des données, le feature skew et les biais de prédiction, afin de décider quand il vaut effectivement la peine d'investir dans un réentraînement. Un modèle de détection de fraude peut par exemple dériver et nécessiter un réentraînement précisément lorsque les montants de transaction évoluent progressivement ou que la nature de la fraude change, mais pas autrement.

Tout relier : les AML Pipelines

Les AML Pipelines réduisent les coûts ML en enchaînant les étapes efficacement et maîtrisent les coûts d'engineering en automatisant les tâches répétitives. Une orchestration robuste pour définir et gérer des workflows ML complexes évite les étapes d'exécution superflues et l'accumulation de données. Parmi les fonctionnalités : la parallélisation (traitement fan-out/fan-in, utile pour le tuning d'hyperparamètres), l'exécution conditionnelle (n'exécuter des étapes que si certaines conditions sont remplies, par exemple ne déployer un modèle que si sa précision dépasse un seuil défini), ainsi que la mise en cache et la réutilisation de composants (lorsque les entrées et le code d'une étape de pipeline sont inchangés, sa sortie en cache est réutilisée, ce qui économise du compute).

Optimiser les coûts ML est un effort continu, qui combine des choix technologiques pertinents et un processus FinOps solide. En exploitant pleinement les capacités d'AML, en respectant des principes architecturaux sains et en restant vigilant sur vos dépenses, vous garantissez à vos initiatives ML une valeur métier maximale sans peser sur votre budget. Commencez par identifier vos plus gros postes de coût et engagez-vous à mettre en œuvre une ou deux des stratégies évoquées ici durant le prochain trimestre. Vos résultats financiers vous remercieront.