3 Les équipes de machine learning ont besoin d’énormes capacités de stockage. Les jeux de données d’entraînement des grands modèles de langage représentent des téraoctets. Les points de contrôle des modèles s’accumulent rapidement au fil des itérations. Les feature stores conservent des mois, voire des années de données historiques. Et lorsque les performances se dégradent et qu’il faut réentraîner avec les données d’il y a neuf mois, mieux vaut les avoir conservées intégralement et sans modification. Cette croissance explosive crée une économie inattendue : pour l’IA, les coûts de stockage dépassent souvent ceux du calcul. Les organisations dépensent des centaines de milliers de dollars en GPU, pour se retrouver tout autant limitées par leurs systèmes de stockage. Comprendre le coût total de possession du stockage (en anglais) est indispensable pour budgéter les projets de ML. C’est là qu’intervient la déduplication, qui réduit l’empreinte de stockage en éliminant les données redondantes. Mais ses bénéfices varient fortement selon les types de données de ML. Les jeux de données d’entraînement des modèles de langage peuvent se dédupliquer avec un taux de 2:1, les points de contrôle de modèles atteindre 10:1, tandis que certaines charges de ML se dédupliquent à peine. Beaucoup d’organisations constatent qu’elles peuvent augmenter leur stockage tout en réduisant leurs coûts (en anglais) grâce à une déduplication bien pensée. Il est essentiel de comprendre l’impact réaliste de la déduplication avant de concevoir son stockage. Surestimer la déduplication conduit à sous-dimensionner et à buter sur des limites en plein projet. La sous-estimer conduit à surprovisionner et à gaspiller du capital. Choisir la mauvaise stratégie (en ligne ou a posteriori) peut créer des goulots d’étranglement dans votre pipeline d’entraînement. Comment fonctionne la déduplication et pourquoi elle compte pour les données de ML La déduplication identifie les blocs de données répétés et ne les stocke qu’une seule fois. Si vous avez dix copies du même jeu de données de 1 Go, la déduplication le stocke une fois avec neuf pointeurs. Si des milliers de points de contrôle partagent des bibliothèques communes, les composants partagés ne sont stockés qu’une fois et référencés. Pour les systèmes de stockage, c’est un levier puissant. Les systèmes de sauvegarde qui stockent des snapshots quotidiens de bases de données atteignent des taux de 10:1 ou 20:1, car chaque snapshot est presque identique à celui de la veille : seuls les blocs modifiés diffèrent. Les messageries qui stockent des milliers de copies des mêmes supports marketing se dédupliquent aussi très bien. Les données de ML, en revanche, sont fondamentalement différentes. La plupart des jeux de données de ML sont intrinsèquement uniques. Les jeux de données d’images contiennent des millions d’images distinctes ; les séries temporelles financières, des séquences de transactions uniques. Entraîner plusieurs fois sur ces jeux de données consomme un stockage égal à leur taille multipliée par le nombre d’exécutions. La déduplication n’y peut rien, car il n’y a rien de redondant à éliminer, sauf si votre pipeline stocke des résultats intermédiaires, des données en cache ou des copies de jeux de données. La déduplication excelle en revanche avec les points de contrôle de modèles et les artefacts intermédiaires. Les points de contrôle d’un modèle de langage aux itérations 10 000 et 10 001 peuvent différer de moins de 1 % : la plupart des poids et paramètres sont identiques. La déduplication stocke le delta et crée une référence vers l’itération précédente, ce qui réduit le stockage de 90 % ou plus. Vous pouvez ainsi conserver l’historique complet des points de contrôle, indispensable pour analyser une dégradation des performances, corriger des erreurs ou exécuter l’inférence avec d’anciennes versions, sans en payer le coût de stockage. Les taux de déduplication selon les types de charges de ML En conditions réelles, les taux de déduplication des charges de ML varient selon le type de données et les pratiques d’entraînement. Les connaître permet de dimensionner le stockage de manière réaliste. Les jeux de données d’entraînement des grands modèles de langage se dédupliquent généralement avec un taux de 1,2:1 à 1,5:1. Le texte brut est largement unique : des documents différents ne contiennent pas de blocs communs significatifs. Mais si le prétraitement crée des jeux de données intermédiaires (versions tokenisées, converties ou nettoyées) et que vous les conservez tous pour la reproductibilité, le taux monte à 2:1 ou 3:1. Certaines organisations conservent plusieurs versions d’un jeu de données avec différents nettoyages ou filtrages ; la déduplication est alors très utile. Les points de contrôle de modèles et les artefacts d’entraînement se dédupliquent bien davantage. Scénario type : vous entraînez un modèle de langage en enregistrant un point de contrôle toutes les 1 000 itérations. Entre les itérations 10 000 et 10 001, environ 99 % des poids sont identiques. La déduplication peut atteindre 50:1 ou plus, ce qui revient à stocker mille points de contrôle pour le prix d’une vingtaine. L’économie du stockage s’en trouve transformée : conserver l’historique complet de l’entraînement devient réaliste, et non plus prohibitif. Les feature stores des systèmes de ML en production présentent des caractéristiques intermédiaires. Ils conservent des valeurs historiques sur des mois ou des années. Les snapshots successifs de features se dédupliquent avec un taux de 3:1 à 8:1, selon la fréquence de recalcul des features et le nombre de versions conservées. Les artefacts d’entraînement intermédiaires (fichiers de prétraitement temporaires, résultats de validation, journaux) se dédupliquent avec un taux de 2:1 à 4:1. Ces fichiers sont créés à plusieurs reprises au fil des étapes du pipeline et rarement nettoyés, ce qui en fait de bons candidats à la déduplication. Déduplication en ligne ou déduplication a posteriori Le moment de la déduplication, c’est-à-dire le moment où le système de stockage détecte et élimine les doublons, influe profondément sur l’empreinte de stockage comme sur les performances du pipeline. Ce choix doit être au cœur de vos décisions d’architecture de stockage. La déduplication en ligne intervient pendant l’écriture des données. Lorsque votre pipeline d’entraînement écrit un point de contrôle, le système de stockage identifie immédiatement les blocs existants et les référence au lieu de stocker des copies. Les gains d’espace sont maximaux et immédiats. Mais la déduplication en ligne a un coût : la détection consomme des cycles de calcul et augmente la latence d’écriture. Pour des points de contrôle de plusieurs téraoctets, même une légère hausse de latence peut perturber le débit et allonger l’entraînement. La déduplication a posteriori intervient après l’écriture. Votre pipeline écrit les points de contrôle en taille réelle ; plus tard, un service d’arrière-plan analyse le stockage, identifie les doublons et réorganise les données. L’impact sur les performances d’écriture est minime : votre pipeline écrit à pleine vitesse. Il faut en revanche disposer d’une capacité suffisante pour accueillir la taille complète des données, plus le surcoût de la déduplication, avant la fin du traitement en arrière-plan. Si votre stockage est géré au plus juste, cela peut poser problème. La plupart des organisations qui déploient la déduplication pour les charges de ML choisissent la déduplication a posteriori. Elles l’exécutent en heures creuses ou lorsque le débit d’entraînement est moins critique. Les performances d’entraînement sont préservées et les gains apparaissent en quelques heures ou quelques jours. La contrepartie : une capacité de pointe un peu supérieure à celle qu’exigerait la déduplication en ligne. La déduplication et la gouvernance des données de ML La déduplication crée des complexités de gouvernance subtiles qu’il faut comprendre avant de la déployer. Lorsque deux jeux de données sont dédupliqués et que vous supprimez ensuite l’un d’eux (parce qu’il n’est plus utile ou que la conformité l’exige), le système de stockage ne peut pas réellement supprimer les données sous-jacentes : elles restent référencées par l’autre jeu de données. Elles ne disparaissent qu’une fois toutes les références supprimées. C’est souvent invisible pour les équipes de ML, d’où des situations surprenantes. Une data scientist supprime un jeu de données contenant des informations personnelles identifiables (PII) pour satisfaire aux exigences de confidentialité. Sans qu’elle le sache, des points de contrôle de modèles entraînés sur ce jeu de données référencent toujours les blocs dédupliqués et sont conservés indéfiniment. Votre équipe conformité, en préparant un audit de confidentialité, découvre que ces données personnelles existent toujours techniquement. Pire, il est difficile de retrouver quels jeux de données référencent les données supprimées : la couche de déduplication est généralement opaque pour les outils de gouvernance. Pour l’éviter, définissez des politiques de gouvernance claires pour les données dédupliquées. Documentez les jeux de données partagés par déduplication. Lorsqu’un jeu de données à supprimer est dédupliqué avec d’autres, faites remonter la question à votre équipe de gouvernance avant la suppression. Certaines organisations mettent en place un mécanisme de « gel de déduplication » : les données destinées à la suppression sont isolées de la déduplication jusqu’à l’accord de la gouvernance. Les compromis entre déduplication matérielle et logicielle La déduplication peut être mise en œuvre à plusieurs niveaux : dans votre système de stockage objet (s’il la prend en charge), dans votre logiciel de sauvegarde (de nombreuses plateformes la proposent pour les points de contrôle) ou au moyen d’appliances dédiées. La déduplication matérielle, sur des appliances dédiées, offre d’excellents taux et de bonnes performances, mais implique un investissement important et une dépendance au fournisseur. Ces systèmes sont souvent facturés au téraoctet, ce qui les rend coûteux pour les déploiements de ML à grande échelle. La déduplication logicielle, sur du matériel standard, offre plus de flexibilité pour un coût moindre. Si votre système de stockage objet prend en charge nativement la déduplication (c’est le cas de certains systèmes compatibles S3), vous en profitez sans infrastructure supplémentaire. Sinon, exécutez la déduplication comme un service logiciel sur vos ressources de calcul existantes, avec des analyses périodiques du stockage. L’investissement est moindre, mais la gestion opérationnelle plus exigeante. Planifier la capacité de manière réaliste avec la déduplication Pour planifier la capacité de stockage des charges de ML avec déduplication, retenez des taux prudents dans vos calculs. Si vous attendez un taux de 3:1, planifiez sur la base de 2:1 et gardez la capacité supplémentaire comme marge. En production, les taux restent souvent en deçà des maximums théoriques en raison de la variabilité des données, des changements de configuration et des données fondamentalement non redondantes. Exemple : vous concevez un système d’entraînement qui conserve 500 points de contrôle d’un grand modèle de langage. Sans déduplication, il faut 500 × 100 Go = 50 To. Avec un taux réaliste de 30:1, vous utiliserez peut-être 1,5 To. Mais prévoyez 2 à 3 To pour tenir compte des artefacts intermédiaires, des journaux et d’une déduplication imparfaite. Vous disposerez ainsi d’une marge, et le stockage ne deviendra pas un goulot d’étranglement. Comprendre comment la déduplication interagit avec le stockage hiérarchisé pour l’IA (en anglais) aide à optimiser les niveaux chauds et froids tout en préservant les performances du pipeline. Surveillez les taux de déduplication réels en production et ajustez vos plans de capacité en conséquence. La plupart des systèmes de stockage modernes fournissent des métriques détaillées : espace économisé, taux par jeu de données, tendances dans le temps. Utilisez ces données pour valider vos hypothèses et affiner votre planification. Conclusion : la déduplication, un outil de stockage stratégique pour le ML La déduplication n’est pas une solution universelle aux coûts de stockage du ML, mais c’est un outil puissant pour certaines charges, en particulier les points de contrôle de modèles et les artefacts d’entraînement. En connaissant les taux de déduplication réalistes et en choisissant le bon moment (a posteriori pour la plupart des charges de ML), vous réduisez sensiblement votre empreinte de stockage tout en préservant la gouvernance des données et la reproductibilité qu’exigent les pratiques modernes de ML. Voir aussi le stockage hiérarchisé pour l’IA (en anglais). Les organisations qui réussissent leurs déploiements de ML à grande échelle traitent l’architecture de stockage comme un problème d’ingénierie de premier plan. Cela passe par un déploiement réfléchi de la déduplication là où elle apporte de la valeur, associé à une planification de la capacité et à une gouvernance rigoureuses. Si vous surprovisionnez votre stockage pour éviter la complexité de la déduplication, ou si vous rencontrez des problèmes de gouvernance, revoyez votre architecture. Le bénéfice, en coûts d’investissement réduits et en simplicité opérationnelle, est considérable. Pour aller plus loin Le stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais) Stockage chaud ou stockage froid Le coût total de possession du stockage de données (en anglais) Pipelines de données d’IA : architecture, étapes et bonnes pratiques Big data, analytique et stockage objet (en anglais) Augmenter le stockage tout en réduisant les coûts (en anglais)
