2 Votre organisation construit des pipelines de machine learning qui fonctionnent à grande échelle. Les jeux d’entraînement se mesurent en téraoctets. Les feature stores, qui contiennent des données dérivées et des features calculées, en ajoutent d’autres. Les points de contrôle de modèles, les artefacts des modèles entraînés et les caches d’inférence en ajoutent encore. Les données d’expérimentation, les journaux des entraînements et les métadonnées de millions d’expériences élargissent encore l’empreinte. Les méthodes traditionnelles de planification de la capacité, qui mesurent l’utilisation actuelle et la projettent en supposant une croissance linéaire, sous-estiment de manière catastrophique les besoins de stockage des organisations d’IA. Le stockage pour le machine learning n’est pas linéaire. Les jeux d’entraînement grossissent à mesure que vous ajoutez des sources de données et allongez les fenêtres historiques. Les feature stores grossissent à mesure que vous calculez de nouvelles features et étendez le feature engineering. Les référentiels de modèles s’accumulent à mesure que vous entraînez des variantes, et les données d’expérimentation s’entassent si vous ne les élaguez pas énergiquement. La courbe de croissance est raide et ses points d’inflexion imprévisibles. Si votre stockage sature en plein entraînement, vous n’avez que quelques minutes pour ajouter de la capacité avant que la tâche échoue et que vous perdiez des jours de progression. Pour les CDO et les responsables de l’ingénierie IA, la planification de la capacité de stockage n’est pas un exercice ponctuel. C’est une discipline continue qui exige de comprendre les schémas de croissance des données, de prévoir avec des marges et d’architecturer une infrastructure de stockage capable d’évoluer de manière élastique. Cet article explique comment les organisations d’IA doivent aborder la planification de la capacité de stockage. Comprendre la croissance de vos données : mesurer plutôt que supposer La première étape pour bâtir un modèle de planification précis consiste à comprendre où votre stockage est réellement consommé. De nombreuses organisations d’IA planifient leur capacité sur la base d’hypothèses (« nous pensons avoir besoin d’environ 500 téraoctets pour nos données d’entraînement ») sans savoir ce que contiennent ces 500 téraoctets ni comment ils évoluent. Cela exige de l’instrumentation. Vous devez suivre finement la consommation de stockage : combien pour les jeux d’entraînement, les feature stores, les points de contrôle de modèles, les données d’expérimentation, les caches d’inférence. Vous devez connaître le rythme de croissance de chaque catégorie. Certaines, comme les caches d’inférence, peuvent croître et décroître au gré des déploiements de features ; d’autres, comme les jeux d’entraînement historiques, croissent plus régulièrement à mesure que vous archivez de nouvelles données. La deuxième étape consiste à comprendre les points d’inflexion. Quand les jeux de données augmentent-ils brusquement ? Lorsqu’une équipe ML étend son feature engineering, la consommation du feature store peut doubler en quelques semaines. Lorsque vous étendez un jeu d’entraînement vers le passé pour inclure plus d’historique, sa taille peut bondir. Lorsque vous ajoutez une nouvelle source de données (une API, une base de données, un ensemble de capteurs), la courbe de croissance change. Suivre ces points d’inflexion exige une communication continue entre vos équipes de data engineering et d’exploitation du stockage. Lorsque de nouvelles initiatives sont prévues (projets de feature engineering, extension de jeux d’entraînement, nouvelles sources de données), votre équipe stockage doit en être informée pour en projeter l’impact. La troisième étape consiste à distinguer les besoins de stockage transitoires et persistants. Toutes les données stockées dans votre infrastructure d’IA ne sont pas permanentes. Les données d’expérimentation peuvent être conservées quelques semaines ou quelques mois puis supprimées. Les données intermédiaires des pipelines de feature engineering peuvent être temporaires. Les caches d’inférence peuvent être vidés lors du déploiement de nouveaux modèles. Cette distinction vous aide à prévoir si votre courbe de croissance continuera indéfiniment à monter ou si elle se stabilisera. Les méthodes de prévision : dépasser la projection linéaire L’extrapolation linéaire, qui projette la consommation actuelle, fonctionne pour une organisation mature aux besoins de stockage stables. Pour les organisations d’IA qui développent encore leurs capacités et étendent leurs pipelines, elle sous-estime massivement les besoins. Prévoyez plutôt la consommation de stockage au moyen d’un modèle multifactoriel qui tient compte des différents moteurs de croissance : La prévision de la croissance des jeux de données exige de comprendre comment vos jeux d’entraînement vont s’étendre. Si vous archivez des données de ventes, projetez en fonction de la croissance de l’activité ; des données de capteurs, en fonction des plans de déploiement des capteurs ; des données comportementales, en fonction de la croissance du nombre d’utilisateurs. Interrogez vos équipes data engineering et produit sur leurs projets d’extension et traduisez-les en croissance de stockage. La croissance du feature store dépend du rythme du feature engineering. Si votre équipe crée régulièrement de nouvelles features, projetez la croissance en fonction du nombre de features créées et du stockage par feature. Tenez compte des features composites calculées à partir de features plus simples : le stockage hiérarchisé pour l’IA (en anglais) aide à maîtriser cette croissance tout en préservant performances et rentabilité. Le stockage des modèles et des expériences croît au rythme du développement des modèles. Si votre équipe mène cinquante expériences par semaine, calculez l’impact de stockage par expérience (poids, points de contrôle, journaux, métadonnées) et projetez-le. À mesure que votre organisation grandit, la cadence des expériences peut s’accélérer et faire croître le stockage. Le stockage d’inférence et de cache croît avec les déploiements. Chaque modèle déployé en production génère des données de cache et d’inférence. Projetez ce stockage en fonction du nombre de modèles à déployer et de la taille de votre charge d’inférence. Combinez ces prévisions pour obtenir une projection globale. Surtout, projetez non seulement le stockage total, mais aussi les besoins en bande passante. Si votre croissance prévue implique d’ajouter un pétaoctet au troisième trimestre, ce n’est pas seulement une question de capacité, mais aussi de bande passante réseau : votre infrastructure peut-elle absorber un pétaoctet de nouvelles données dans les délais prévus ? Sinon, vous devez soit accélérer la planification de la capacité, soit ralentir l’ingestion des données. Prévoir des marges pour les pics et l’incertitude L’une des causes les plus fréquentes d’incidents de production liés au stockage est l’absence de marge suffisante pour absorber des pics inattendus ou des erreurs de prévision. Vous atteignez le seuil de capacité prévu, puis un nouveau jeu de données prioritaire est ingéré, ou les règles de conservation des données d’expérimentation sont assouplies, et vous voilà soudain à 95 % d’utilisation, sans aucune marge. Votre planification de la capacité doit inclure des marges explicites pour l’incertitude et les pics. Une approche courante consiste à maintenir en permanence au moins 20 à 30 % de capacité libre dans votre infrastructure de stockage. Vous disposez ainsi d’une réserve pour les pics, d’une souplesse opérationnelle, et vous évitez de travailler en limite de capacité, où la moindre erreur de prévision pose problème. Pour le stockage du chemin critique (jeux d’entraînement et feature stores qui soutiennent directement vos modèles de production), la marge doit être plus importante. Si une tâche d’entraînement échoue faute de stockage, le coût est élevé : ressources de calcul inactives, mises à jour de modèles retardées, impact possible sur les applications en aval. Comprendre le coût total de possession du stockage (en anglais) permet de justifier le maintien de 30 à 40 % de capacité libre sur les jeux de données critiques comme un investissement raisonnable dans la fiabilité opérationnelle. Prévoyez aussi une extension rapide de la capacité. Si vos prévisions annoncent une croissance rapide, assurez-vous que votre architecture de stockage peut évoluer de manière élastique. Si vous prévoyez de passer de 10 à 30 pétaoctets en dix-huit mois, votre infrastructure peut-elle ajouter 100 téraoctets en un seul mois si nécessaire ? Si la réponse est non, vous avez un problème d’architecture que la planification seule ne résoudra pas. Considérations d’architecture : votre stockage peut-il suivre ? La planification de la capacité ne porte pas seulement sur le volume de stockage nécessaire, mais aussi sur la capacité de votre architecture à le fournir avec les performances qu’exigent vos charges de travail d’IA. Les charges d’entraînement sont gourmandes en bande passante et sensibles à la latence. Lorsqu’une tâche d’entraînement lit des données, elle a besoin d’un débit élevé. Une bande passante de stockage insuffisante devient un goulot d’étranglement qui empêche vos coûteux GPU d’être pleinement utilisés. Si vous prévoyez de passer de 10 à 50 entraînements simultanés, la bande passante de votre stockage doit augmenter en conséquence. Votre infrastructure peut-elle fournir le débit nécessaire ? De même, les feature stores et les caches d’inférence exigent à la fois de la capacité et des performances d’E/S suffisantes. La latence de service des features influe directement sur la latence d’inférence : si votre feature store est sous-dimensionné ou mal provisionné, la latence d’inférence augmente et peut enfreindre les SLA. La planification de la capacité ne peut donc pas être dissociée de la planification des performances. Prévoyez la capacité de stockage, mais aussi le débit. Calculez la consommation de bande passante agrégée de vos charges prévues et assurez-vous que votre infrastructure peut la fournir. Pour de nombreuses organisations, cela oriente les choix d’architecture. Un stockage désagrégé, où calcul et stockage sont des ressources indépendantes, facilite l’évolution de chacun séparément. Si vous prévoyez une forte croissance du stockage et une croissance plus modérée du calcul, le stockage désagrégé et les stratégies pour augmenter le stockage tout en réduisant les coûts (en anglais) vous permettent de faire évoluer le stockage de manière élastique sans surprovisionner le calcul. La localité compte aussi. Si vos charges d’IA s’exécutent dans plusieurs régions ou zones de disponibilité, où résideront vos données ? Rapatrier des données d’entraînement d’une région à l’autre entraîne des coûts réseau et des pénalités de latence. Une planification de la capacité qui ignore la localité des données est incomplète. Instaurer une discipline de planification de la capacité Une planification efficace de la capacité de stockage dans les organisations d’IA exige une discipline continue et une collaboration transverse. Vos équipes stockage et infrastructure doivent disposer d’instances régulières d’échange avec les équipes data engineering, ingénierie ML et produit. C’est là que vous découvrez les nouvelles initiatives sur les données, mettez à jour les prévisions et repérez les risques tôt. Mettez en place une supervision et des alertes qui suivent l’utilisation de la capacité en temps réel. Lorsque l’utilisation dépasse certains seuils (70 %, 80 %, 90 %), alertez votre équipe d’infrastructure pour qu’elle ajoute de la capacité de manière proactive plutôt que de réagir à une panne. Pour l’infrastructure critique, envisagez une analyse prédictive qui anticipe le franchissement des seuils et déclenche automatiquement l’ajout de capacité. Tenez à jour un plan de capacité révisé au moins chaque trimestre. À mesure que les priorités de votre organisation évoluent, que de nouvelles initiatives sont lancées et que les schémas de croissance changent, votre plan doit en tenir compte. Un plan de capacité figé deviendra inévitablement inexact. Gagner en confiance dans vos prévisions Le dernier aspect, et le plus important, de la planification de la capacité de stockage est de gagner en confiance dans la justesse de vos prévisions. Cela suppose de comparer régulièrement vos prévisions à la consommation réelle. Votre jeu d’entraînement a-t-il crû aussi vite que prévu ? Le feature store a-t-il grossi plus ou moins vite qu’attendu ? Les règles de conservation des données d’expérimentation ont-elles tenu, ou ont-elles dérivé au-delà de ce que vous aviez prévu ? Ces comparaisons améliorent les prévisions au fil du temps. Les données historiques de votre organisation sont le meilleur indicateur de sa croissance future. En suivant l’écart entre le réel et le prévu, vous affinez votre méthode et gagnez en précision. Les organisations qui gèrent le mieux la capacité de stockage de leurs charges d’IA sont celles qui en font une discipline continue. Elles maintiennent une visibilité permanente sur la consommation de stockage, prévoient avec des marges adaptées, architecturent le stockage à la fois pour la capacité et les performances, comparent le réel au prévu et affinent sans cesse leurs modèles. À mesure que votre organisation d’IA grandit et que ses besoins de stockage augmentent, le coût d’une erreur de prévision augmente aussi. Le sous-provisionnement provoque des incidents et ralentit le développement ; le surprovisionnement gaspille du capital et réduit l’efficacité opérationnelle. Faire de la planification de la capacité une discipline stratégique est le moyen de trouver cet équilibre et de bâtir une infrastructure de stockage qui sert réellement les besoins de votre organisation. Pour aller plus loin Le stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais) Architecture de cible de sauvegarde évolutive (en anglais) Augmenter le stockage tout en réduisant les coûts (en anglais) Pipelines de données d’IA : architecture, étapes et bonnes pratiques (en anglais) Le coût total de possession du stockage de données (en anglais) Le coût du stockage par téraoctet : guide de calcul pour l’entreprise Exemples chiffrés pour des charges spécifiques : calcul du stockage de vidéosurveillance, stockage des caméras-piétons et croissance du stockage de l’imagerie médicale.
