Une version abrégée de cet article est parue sur The New Stack le 19 mars 2024.

En intelligence artificielle d’entreprise, il existe deux principaux types de modèles : discriminants et génératifs. Les modèles discriminants sont utilisés pour classer ou prédire les données, tandis que les modèles génératifs sont utilisés pour créer de nouvelles données. Même si l’IA générative a dominé l’actualité ces derniers temps, les organisations continuent de recourir aux deux types d’IA. L'IA discriminante reste toujours une initiative importante pour les organisations qui souhaitent fonctionner plus efficacement et rechercher des sources de revenus supplémentaires. Ces différents types d’IA ont beaucoup en commun, mais en même temps, il existe des différences significatives qui doivent être prises en compte lors de la construction de votre infrastructure de données d’IA.

Les organisations ne devraient pas créer une infrastructure dédiée à l’IA et à l’IA uniquement tout en laissant les charges de travail telles que la Business Intelligence, l’Analyse de données et la Science des données se débrouiller seules. Il est possible de créer une infrastructure de données complète qui prend en charge tous les besoins de l'organisation : Business Intelligence, Data Analytics, Data Science, IA discriminante et IA générative.

Dans un autre article, nous avons présenté une architecture de référence pour un datalake moderne capable de répondre aux besoins de business intelligence, d'analyse de données, de science des données et d'IA/ML. Passons en revue l'architecture de référence moderne de Datalake et soulignons les capacités dont elle dispose pour prendre en charge les charges de travail IA/ML.

Le lac de données moderne

Commençons par définir un Datalake moderne car celui-ci servira de base à notre architecture de référence. Cette architecture n'est pas « recyclée », elle reflète plutôt les premiers principes d'ingénierie qui sont largement applicables. Un Datalake moderne est constitué à moitié de Data Warehouse et à moitié de Data Lake et utilise le stockage d'objets pour tout. L’utilisation du stockage objet pour un Data Lake est parfaitement logique, car le stockage objet est destiné aux données non structurées, ce qu’un Data Lake est censé stocker. Cependant, utiliser le stockage objet pour un entrepôt de données peut sembler étrange, mais un entrepôt de données construit de cette manière représente la prochaine génération d'entrepôts de données. Ceci est rendu possible par les spécifications Open Table Format (OTF) créées par Netflix, Uber et Databricks, qui facilitent l'utilisation du stockage d'objets dans un entrepôt de données.

Les OTF sont Apache Iceberg, Apache Hudi et Delta Lake. Ils ont été rédigés respectivement par Netflix, Uber et Databricks - car il n'existait aucun produit sur le marché capable de répondre à leurs besoins en données. Essentiellement, ce qu'ils font tous (de différentes manières) est de définir un entrepôt de données qui peut être construit sur le stockage d'objets (MinIO). Le stockage objet offre une combinaison de capacité évolutive et de hautes performances que d'autres solutions de stockage ne peuvent pas offrir. Puisqu'il s'agit de spécifications modernes, elles disposent de fonctionnalités avancées que les entrepôts de données à l'ancienne n'ont pas, telles que l'évolution des partitions, l'évolution des schémas et le branchement sans copie. Enfin, puisque l'entrepôt de données est construit avec le stockage d'objets, vous pouvez utiliser ce même magasin d'objets pour les données non structurées telles que les images, les fichiers vidéo, les fichiers audio et les documents.

Les données non structurées sont généralement stockées dans ce que l'industrie appelle un lac de données. L’utilisation d’un magasin d’objets comme base de votre lac de données et de votre entrepôt de données permet d’obtenir une solution capable de contenir toutes vos données. Le stockage structuré réside dans l'entrepôt de données basé sur OTF et le stockage non structuré réside dans le Data Lake. La même instance de MinIO pourrait être utilisée pour les deux.

Chez MinIO, nous appelons cette combinaison d'un entrepôt de données basé sur OTF et d'un lac de données le Datalake moderne, et nous le considérons comme la base de toutes vos charges de travail IA/ML. C'est là que les données sont collectées, stockées, traitées et transformées. Les modèles de formation utilisant l’IA discriminante (apprentissage supervisé, non supervisé et par renforcement) nécessitent souvent une solution de stockage capable de gérer des données structurées pouvant vivre dans l’entrepôt de données. En revanche, si vous formez des Large Language Models (LLM), vous devez gérer des données ou des documents non structurés sous leur forme brute et traitée dans le Data Lake.

Source : Architecture de référence Datalake moderne

Cet article se concentre sur les domaines de l'architecture de référence moderne Datalake pour l'IA/ML qui prennent en charge les différentes charges de travail AI/ML. Ces domaines fonctionnels sont répertoriés ci-dessous. Une représentation visuelle du Datalake moderne est présentée ci-dessus. Les couches dans lesquelles ces domaines fonctionnels peuvent être trouvés ont été mises en évidence.

• IA discriminante

  
  

  • Stockage des données non structurées

  • Stockage des données semi-structurées

  • Branchement sans copie dans l'entrepôt de données

    
    

• IA générative

  
  

  • Construire un corpus personnalisé avec une base de données vectorielles

  • Construire un pipeline de documents

  • Génération augmentée de récupération (RAG)

  • Affiner les grands modèles de langage

  • Mesurer la précision du LLM

    
    

• Opérations d'apprentissage automatique

  
  

Cet article examine également l’état actuel des GPU et leur impact sur votre infrastructure de données IA. Nous examinerons également quelques scénarios qui illustrent comment construire votre infrastructure et comment ne pas construire votre infrastructure. Enfin, cet article présente quelques recommandations pour créer votre propre infrastructure de données IA.

• L'état actuel des GPU

  
  

  • Le problème du GPU affamé

  • Surcharger le stockage d’objets

    
    

• Une histoire de deux organisations

• Un plan pour construire votre infrastructure de données IA

IA discriminante

Les modèles d’IA discriminants nécessitent des données de tous types pour la formation. Les modèles de classification d'images et de reconnaissance vocale utiliseront des données non structurées sous forme d'images et de fichiers audio. D’autre part, les modèles de détection des fraudes et de diagnostic médical font des prédictions basées sur des données structurées. Examinons les options disponibles dans le Datalake moderne pour stocker et manipuler les données nécessaires à l'IA discriminante.

Stockage des données non structurées

Les données non structurées résideront dans le Data Lake, où elles pourront être utilisées pour la formation et les tests de modèles. Les ensembles d'entraînement pouvant tenir en mémoire peuvent être chargés avant l'entraînement (avant le début de votre boucle d'époque). Cependant, si votre ensemble d'entraînement est volumineux et ne rentre pas dans la mémoire, vous devrez charger une liste d'objets avant l'entraînement et récupérer les objets réels lors du traitement de chaque lot dans votre boucle d'époque. Cela pourrait mettre à rude épreuve votre Data Lake si vous ne construisez pas votre Data Lake à l’aide d’un réseau haut débit et de lecteurs de disque haut débit. Si vous entraînez des modèles avec des données qui ne peuvent pas tenir en mémoire, envisagez de créer votre Data Lake avec un réseau de 100 Go et des disques NVMe.

Stockage des données semi-structurées

Quelques options sont disponibles dans Modern Datalake pour stocker des fichiers semi-structurés tels que des fichiers Parquet, des fichiers AVRO, des fichiers JSON et même des fichiers CSV. La chose la plus simple à faire est de les stocker dans votre Data Lake et de les charger de la même manière que vous chargez des objets non structurés. Si les données de ces fichiers semi-structurés ne sont pas nécessaires aux autres charges de travail prises en charge par Modern Datalake (Business Intelligence, Data Analytics et Data Science), alors c'est la meilleure option.

Une autre option consiste à charger ces fichiers dans votre entrepôt de données, où d'autres charges de travail peuvent les utiliser. Lorsque les données sont chargées dans votre Data Warehouse, vous pouvez utiliser Branchement sans copie pour effectuer des expériences avec vos données.

Branchement sans copie dans l'entrepôt de données

L'ingénierie des fonctionnalités est une technique permettant d'améliorer les ensembles de données utilisés pour entraîner un modèle. Une fonctionnalité très astucieuse que possèdent les entrepôts de données basés sur OTF est le branchement sans copie. Cela permet aux données d'être ramifiées de la même manière que le code peut être ramifié dans un référentiel Git. Comme son nom l'indique, cette fonctionnalité ne fait pas de copie des données. Elle utilise plutôt la couche de métadonnées du format de table ouverte utilisée pour implémenter l'entrepôt de données pour créer l'apparence d'une copie unique des données. Les data scientists peuvent expérimenter avec une branche : si leurs expériences réussissent, ils peuvent alors fusionner leur branche dans la branche principale pour que d'autres data scientists puissent l'utiliser. Si l’expérience échoue, la branche peut être supprimée.

IA générative

Tous les modèles, qu'il s'agisse de petits modèles construits avec Scikit-Learn, de réseaux neuronaux personnalisés construits avec PyTorch ou TensorFlow, ou de grands modèles linguistiques basés sur l'architecture Transformer, nécessitent des nombres comme entrées et produisent des nombres comme sorties. Ce simple fait impose quelques exigences supplémentaires à votre infrastructure IA/ML si vous êtes intéressé par l'IA générative, où les mots doivent être transformés en nombres (ou vecteurs, comme nous le verrons). Une solution d'IA générative devient encore plus compliquée si vous souhaitez utiliser des documents privés contenant les connaissances exclusives de votre entreprise pour améliorer les réponses produites par les LLM. Cette amélioration pourrait prendre la forme d'une génération augmentée de récupération ou d'un réglage fin LLM.

Cette section abordera toutes ces techniques (transformation de mots en chiffres, RAG et réglage fin) et leur impact sur l'infrastructure de l'IA. Commençons par expliquer comment créer un corpus personnalisé et où il doit résider.

Création d'un corpus personnalisé avec une base de données vectorielles

Si vous êtes sérieux au sujet de l'IA générative, votre corpus personnalisé doit définir votre organisation. Il doit contenir des documents contenant des connaissances que personne d'autre ne possède et ne contenir que des informations véridiques et exactes. De plus, votre corpus personnalisé doit être construit avec une base de données vectorielles. Une base de données vectorielles indexe, stocke et donne accès à vos documents ainsi qu'à leurs intégrations vectorielles, qui sont les représentations numériques de vos documents. (Cela résout le problème du nombre décrit ci-dessus.)

Les bases de données vectorielles facilitent la recherche sémantique. La façon dont cela est réalisé nécessite beaucoup de connaissances mathématiques et est compliquée. Cependant, la recherche sémantique est conceptuellement facile à comprendre. Supposons que vous souhaitiez rechercher tous les documents traitant de tout ce qui concerne « l'intelligence artificielle ». Pour ce faire, sur une base de données conventionnelle, vous devrez rechercher toutes les abréviations, synonymes et termes associés possibles au terme « intelligence artificielle ». Votre requête ressemblerait à ceci :

 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...

Non seulement la recherche manuelle de similarité est ardue et sujette aux erreurs, mais la recherche elle-même est très lente. Une base de données vectorielle peut prendre une requête comme ci-dessous et exécuter la requête plus rapidement et avec une plus grande précision. La possibilité d'exécuter des requêtes sémantiques rapidement et avec précision est importante si vous souhaitez utiliser la génération augmentée par récupération.

 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }

Une autre considération importante pour votre corpus personnalisé est la sécurité. L'accès aux documents doit respecter les restrictions d'accès aux documents originaux. (Il serait regrettable qu'un stagiaire puisse accéder aux résultats financiers du directeur financier qui n'ont pas encore été publiés à Wall Street.) Dans votre base de données vectorielles, vous devez configurer une autorisation pour correspondre aux niveaux d'accès du contenu original. Cela peut être fait en intégrant votre base de données Vector à la solution de gestion des identités et des accès de votre organisation.

À la base, les bases de données vectorielles stockent des données non structurées. Par conséquent, ils doivent utiliser votre Data Lake comme solution de stockage.

Construire un pipeline de documents

Malheureusement, la plupart des organisations ne disposent pas d’un référentiel unique contenant des documents clairs et précis. Au lieu de cela, les documents sont répartis dans toute l’organisation sur différents portails d’équipe dans de nombreux formats. Par conséquent, la première étape de la création d'un corpus personnalisé consiste à créer un pipeline qui prend uniquement les documents dont l'utilisation avec Generative AI a été approuvée et à les placer dans votre base de données vectorielles. Pour les grandes organisations mondiales, cela pourrait potentiellement être la tâche la plus difficile d’une solution d’IA générative. Il est courant que les équipes disposent d’une documentation sous forme de brouillon sur leurs portails. Il peut également y avoir des documents qui sont des réflexions aléatoires sur ce qui pourrait arriver. Ces documents ne doivent pas faire partie d'un corpus personnalisé car ils ne représentent pas avec précision l'entreprise. Malheureusement, le filtrage de ces documents sera un effort manuel.

Un pipeline de documents doit également convertir les documents en texte. Heureusement, quelques bibliothèques open source peuvent le faire pour de nombreux formats de documents courants. De plus, un pipeline de documents doit diviser les documents en petits segments avant de les enregistrer dans la base de données vectorielles. Cela est dû aux limitations de la taille des invites lorsque ces documents sont utilisés pour la génération augmentée de récupération, qui seront abordées dans une section ultérieure.

Affiner les grands modèles de langage

Lorsque nous affinons un grand modèle de langage, nous l'entraînons un peu plus avec les informations du corpus personnalisé. Cela pourrait être un bon moyen d'obtenir un LLM spécifique à un domaine. Bien que cette option nécessite un calcul pour effectuer un réglage précis par rapport à votre corpus personnalisé, elle n'est pas aussi intensive que la formation d'un modèle à partir de zéro et peut être réalisée dans un laps de temps modeste.

Si votre domaine comprend des termes introuvables dans l'usage quotidien, un réglage fin peut améliorer la qualité des réponses du LLM. Par exemple, les projets qui utilisent des documents issus de la recherche médicale, de la recherche environnementale et de tout ce qui touche aux sciences naturelles peuvent bénéficier d'un ajustement précis. Le réglage fin prend la langue vernaculaire très spécifique trouvée dans vos documents et les intègre dans les paramètres paramétriques du modèle. Les avantages et les inconvénients du réglage fin doivent être compris avant de décider de cette approche.

Désavantages

• Le réglage précis nécessitera des ressources de calcul.

• L’explicabilité n’est pas possible.

• Vous devrez périodiquement affiner les ajustements avec de nouvelles données à mesure que votre corpus évolue.

• Les hallucinations sont une préoccupation.

• La sécurité au niveau des documents est impossible.

  
  

Avantages

• Le LLM possède des connaissances issues de votre corpus personnalisé via un réglage fin.

• Le flux d'inférence est moins compliqué que RAG.

  
  

Bien que le réglage fin soit un bon moyen d'enseigner à un LLM le langage de votre entreprise, cela dilue les données puisque la plupart des LLM contiennent des milliards de paramètres, et vos données seront réparties sur tous ces paramètres. Le plus gros inconvénient du réglage fin est que l’autorisation au niveau du document est impossible. Une fois qu'un document est utilisé pour le réglage fin, ses informations deviennent une partie du modèle. Il n'est pas possible de restreindre ces informations en fonction des niveaux d'autorisation de l'utilisateur.

Examinons une technique qui combine vos données personnalisées et vos données paramétriques au moment de l'inférence.

Génération augmentée de récupération (RAG)

La génération augmentée de récupération (RAG) est une technique qui commence par la question posée : elle utilise une base de données vectorielle pour marier les questions avec des données supplémentaires, puis transmet la question et les données à un LLM pour la création de contenu. Avec RAG, aucune formation n'est nécessaire car nous formons le LLM en lui envoyant des extraits de texte pertinents issus de notre corpus de documents de qualité.

Cela fonctionne comme ceci en utilisant une tâche de réponse à des questions : un utilisateur pose une question dans l'interface utilisateur de votre application. Votre application prendra la question - en particulier les mots qu'elle contient - et, à l'aide d'une base de données vectorielles, recherchera dans votre corpus de documents de qualité des extraits de texte contextuellement pertinents. Ces extraits et la question originale sont envoyés au LLM. L'ensemble de ce package - question plus extraits (contexte) est connu sous le nom d'invite. Le LLM utilisera ces informations pour générer votre réponse. Cela peut sembler idiot - si vous connaissez déjà la réponse (les extraits), pourquoi s'embêter avec le LLM ? N'oubliez pas que cela se produit en temps réel et que l'objectif est de générer du texte, quelque chose que vous pouvez copier et coller dans votre recherche. Vous avez besoin du LLM pour créer le texte qui intègre les informations de votre corpus personnalisé.

C'est plus compliqué qu'un réglage fin. Cependant, l'autorisation de l'utilisateur peut être mise en œuvre puisque les documents (ou extraits de documents) sont sélectionnés dans la base de données vectorielles au moment de l'inférence. Les informations contenues dans les documents ne font jamais partie des paramètres paramétriques du modèle. Les avantages et les inconvénients de RAG sont répertoriés ci-dessous.

Désavantages

• Le flux d’inférence est plus compliqué.

  
  

Avantages

• Le LLM possède une connaissance directe de votre corpus personnalisé.
• L’explicabilité est possible.
• Aucun réglage fin n’est nécessaire.
• Les hallucinations sont considérablement réduites et peuvent être contrôlées en examinant les résultats des requêtes de la base de données vectorielles.
• L'autorisation peut être mise en œuvre.

Opérations d'apprentissage automatique (MLOps)

Pour mieux comprendre l'importance du MLOps, il est utile de comparer la création de modèles au développement d'applications conventionnel. Le développement d'applications conventionnel, comme la mise en œuvre d'un nouveau microservice qui ajoute une nouvelle fonctionnalité à une application, commence par la révision d'une spécification. Toute nouvelle structure de données ou toute modification apportée aux structures de données existantes est conçue en premier. La conception des données ne doit pas changer une fois le codage commencé. Le service est ensuite mis en œuvre et le codage constitue l’activité principale de ce processus. Les tests unitaires et les tests de bout en bout sont également codés. Ces tests prouvent que le code n'est pas défectueux et implémente correctement la spécification. Ils peuvent être exécutés automatiquement par un pipeline CI/CD avant de déployer l'intégralité de l'application.

Créer un modèle et le former est différent. Une compréhension des données brutes et des prévisions nécessaires constitue la première étape. Les ingénieurs ML doivent écrire du code pour implémenter leurs réseaux de neurones ou mettre en place un algorithme, mais le codage n'est pas l'activité dominante. L'expérimentation répétée est l'activité principale. Au cours de l’expérimentation, la conception des données, la conception du modèle et les paramètres utilisés changeront tous. Après chaque expérience, des métriques sont créées qui montrent les performances du modèle lors de son entraînement. Des métriques sont également générées pour les performances du modèle par rapport à un ensemble de validation et un ensemble de test. Ces métriques sont utilisées pour prouver la qualité du modèle. Une fois qu'un modèle est prêt à être incorporé dans une application, il doit être empaqueté et déployé.

MLOps, abréviation de Machine Learning Operations, est un ensemble de pratiques et d'outils visant à répondre à ces différences. Le suivi des expériences et la collaboration sont les fonctionnalités les plus associées aux MLOP, mais les outils MLOP les plus modernes du secteur aujourd'hui peuvent faire bien plus. Par exemple, ils peuvent fournir un environnement d'exécution pour vos expériences, et ils peuvent empaqueter et déployer des modèles une fois qu'ils sont prêts à être intégrés dans une application. Vous trouverez ci-dessous un surensemble de fonctionnalités trouvées dans les outils MLOps aujourd'hui. Cette liste comprend également d'autres éléments à prendre en compte, tels que le support et l'intégration des données.

1. Support d'un acteur majeur - Les techniques et fonctionnalités MLOps évoluent constamment. Vous souhaitez un outil soutenu par un acteur majeur, garantissant qu’il est en constante évolution et amélioration.

   
   

2. Intégration Datalake moderne – Les expériences génèrent de nombreuses données structurées et non structurées. Idéalement, cela pourrait être stocké dans le Data Warehouse et le Data Lake. Cependant, de nombreux outils MLOps existaient avant les formats Open Table qui ont donné naissance au Modern Datalake, de sorte que la plupart auront une solution distincte pour leurs données structurées.

   
   

3. Suivi des expériences – Gardez une trace des ensembles de données, des modèles, des hyperparamètres et des métriques de chaque expérience. Le suivi des expériences devrait également faciliter la répétabilité.

   
   

4. Facilitez la collaboration : permettez aux membres de l'équipe de visualiser les résultats de toutes les expériences menées par tous les ingénieurs ML.

   
   

5. Conditionnement du modèle : Emballez le modèle de manière à ce qu'il soit accessible à partir d'autres environnements de programmation.

   
   

6. Model Serving - Déploiement de modèles dans les environnements formels d'une organisation. Vous n’en aurez pas besoin si vous avez trouvé un moyen d’incorporer vos modèles dans un pipeline CI/CD existant.

   
   

7. Registre des modèles : conservez toutes les versions de tous les modèles.

   
   

8. Fonctions sans serveur : certains outils fournissent des fonctionnalités qui permettent d'annoter le code de telle manière qu'une fonction ou un modèle puisse être déployé en tant que service conteneurisé pour exécuter des expériences dans un cluster.

   
   

9. Capacités du pipeline de données - Certains outils MLOps visent à fournir des capacités complètes de bout en bout et disposent de fonctionnalités qui vous permettent de créer des pipelines pour récupérer et stocker vos données brutes. Vous n’en aurez pas besoin si vous disposez déjà d’un pipeline de données.

   
   

10. Capacités du pipeline de formation : la possibilité d'orchestrer vos fonctions sans serveur dans un graphique acyclique dirigé. Permet également la planification et l'exécution de pipelines de formation.

L'impact des GPU sur votre infrastructure de données IA

Une chaîne est aussi solide que son maillon le plus faible – et votre infrastructure IA/ML est aussi rapide que votre composant le plus lent. Si vous entraînez des modèles de machine learning avec des GPU, votre maillon faible peut être votre solution de stockage. Le résultat est ce que nous appelons le « problème de GPU affamé ». Le problème du GPU Starving se produit lorsque votre réseau ou votre solution de stockage ne peut pas transmettre les données d'entraînement à votre logique d'entraînement assez rapidement pour utiliser pleinement vos GPU. Les symptômes sont assez évidents. Si vous surveillez vos GPU, vous remarquerez qu’ils ne sont jamais près d’être pleinement utilisés. Si vous avez instrumenté votre code de formation, vous remarquerez que le temps total de formation est dominé par les IO.

Malheureusement, il y a de mauvaises nouvelles pour ceux qui sont aux prises avec ce problème. Les GPU deviennent plus rapides. Examinons l'état actuel des GPU et quelques progrès réalisés avec eux pour comprendre comment ce problème ne fera qu'empirer dans les années à venir.

L'état actuel des GPU

Les GPU deviennent plus rapides. Non seulement les performances brutes s’améliorent, mais la mémoire et la bande passante augmentent également. Jetons un coup d'œil à ces trois caractéristiques des GPU les plus récents de Nvidia : A100 , le H100 et le H200 .

Quelques observations comparatives sur les statistiques ci-dessus méritent d’être rappelées. Premièrement, le H100 et le H200 ont les mêmes performances (1 979 TFLOPS), soit 3,17 fois supérieures à celles de l'A100. Le H100 a deux fois plus de mémoire que l'A100 et la bande passante mémoire a augmenté d'une quantité similaire - ce qui est logique sinon le GPU s'affamerait. Le H200 peut gérer 141 Go de mémoire et sa bande passante mémoire a également augmenté proportionnellement par rapport aux autres GPU.

Examinons chacune de ces statistiques plus en détail et discutons de ce qu'elles signifient pour l'apprentissage automatique.

Performances - Un téraflop (TFLOP) correspond à un billion (10 ^ 12) d'opérations à virgule flottante par seconde. C'est un 1 suivi de 12 zéros (1 000 000 000 000). Il est difficile d'assimiler les TFLOP à la demande d'E/S en gigaoctets, car les opérations en virgule flottante qui se produisent lors de la formation du modèle impliquent des mathématiques tensorielles simples ainsi que des dérivées premières par rapport à la fonction de perte (alias gradients). Toutefois, des comparaisons relatives sont possibles. En regardant les statistiques ci-dessus, nous constatons que le H100 et le H200, qui fonctionnent tous deux à 1 979 TFLOPS, sont trois fois plus rapides – consommant potentiellement des données 3 fois plus rapidement si tout le reste peut suivre.

Mémoire GPU - Également connue sous le nom de RAM vidéo ou RAM graphique. La mémoire GPU est distincte de la mémoire principale (RAM) du système et est spécifiquement conçue pour gérer les tâches de traitement graphique intensives effectuées par la carte graphique. La mémoire GPU dicte la taille du lot lors de la formation des modèles. Dans le passé, la taille des lots diminuait lorsque la logique d’entraînement passait d’un CPU à un GPU. Cependant, à mesure que la mémoire GPU rattrape la mémoire CPU en termes de capacité, la taille du lot utilisée pour l'entraînement GPU augmentera. Lorsque les performances et la capacité de mémoire augmentent en même temps, il en résulte des requêtes plus volumineuses dans lesquelles chaque gigaoctet de données d'entraînement est traité plus rapidement.

Bande passante mémoire – Considérez la bande passante mémoire du GPU comme « l’autoroute » qui relie la mémoire et les cœurs de calcul. Il détermine la quantité de données pouvant être transférées par unité de temps. Tout comme une autoroute plus large permet à plus de voitures de passer dans un laps de temps donné, une bande passante mémoire plus élevée permet de déplacer davantage de données entre la mémoire et le GPU. Comme vous pouvez le constater, les concepteurs de ces GPU ont augmenté la bande passante mémoire pour chaque nouvelle version proportionnellement à la mémoire ; par conséquent, le bus de données interne de la puce ne constituera pas un goulot d'étranglement.

Boostez le stockage d’objets pour la formation de modèles

Si vous rencontrez le problème du GPU Starving, envisagez d'utiliser un réseau de 100 Go et des disques NVMe. UN référence récente l'utilisation de MinIO avec une telle configuration a permis d'atteindre 325 Gio/s sur les GET et 165 Gio/s sur les PUT avec seulement 32 nœuds de SSD NVMe disponibles dans le commerce.

À mesure que le monde informatique a évolué et que le prix de la DRAM a chuté nous constatons que les configurations de serveur sont souvent livrées avec 500 Go ou plus de DRAM. Lorsque vous avez affaire à des déploiements plus importants, même ceux dotés de disques NVMe ultra-denses, le nombre de serveurs, multiplié par la DRAM sur ces serveurs, peut rapidement s'additionner - souvent jusqu'à plusieurs To par instance. Ce pool DRAM peut être configuré comme un pool de mémoire partagé distribué et est idéal pour les charges de travail qui exigent des IOPS et des performances de débit massives. En conséquence, nous avons créé MinIO Cache pour permettre à nos clients Enterprise et Enterprise Lite de configurer leur infrastructure pour tirer parti de ce pool de mémoire partagée afin d'améliorer encore les performances des charges de travail d'IA de base - comme la formation GPU - tout en conservant simultanément une persistance totale.

Une histoire de deux organisations

En guise d'expérience de réflexion finale, racontons l'histoire de deux organisations qui adoptent des approches très différentes dans leur parcours IA/ML. L'organisation n°1 a une culture d'« améliorations itératives ». Ils croient que toutes les grandes initiatives peuvent être décomposées en projets plus petits et plus gérables. Ces petits projets sont ensuite programmés de telle manière que chacun s'appuie sur les résultats du projet précédent pour résoudre des problèmes de plus en plus complexes. Ils aiment aussi ces petits projets organisés de telle sorte que chacun apporte de la valeur à l'entreprise. Ils ont constaté que les projets qui visent uniquement à améliorer l'infrastructure ou à moderniser les logiciels sans apporter de nouvelles fonctionnalités à l'entreprise ne sont pas très populaires auprès des dirigeants qui contrôlent les budgets. Par conséquent, ils ont appris que demander des appareils de stockage et des clusters de calcul sophistiqués pour une preuve de concept d’IA générative n’est pas le meilleur moyen d’orchestrer les améliorations de l’infrastructure et les nouvelles fonctionnalités logicielles. Au lieu de cela, ils commenceront modestement avec des produits d'infrastructure qui peuvent évoluer à mesure de leur croissance - et ils commenceront avec des modèles d'IA simples afin de pouvoir mettre en place leurs outils MLOP et comprendre comment travailler avec les équipes DevOps et les pipelines CI/CD existants.

L'organisation n°2 a une culture « Objets brillants ». Lorsqu’une idée la plus récente entre dans l’industrie, elle s’attaque d’abord au défi le plus important pour démontrer sa puissance technique. Ils ont constaté que ces projets sont très visibles tant en interne qu'en externe. Si quelque chose tombe en panne, les gens intelligents peuvent toujours le réparer.

L'organisation n°1 a structuré son premier projet en développant une partie de son infrastructure de données d'IA tout en travaillant sur un modèle de recommandation pour son principal site de commerce électronique. Le modèle de recommandation était relativement simple à former. Il s'agit d'un modèle discriminant qui utilise des ensembles de données déjà existants sur un partage de fichiers. Cependant, à la fin de ce projet, l'équipe avait également construit un petit Datalake moderne (mais évolutif), implémenté des outils MLOP et mis en place certaines bonnes pratiques pour la formation et le déploiement de modèles. Même si le modèle n’est pas compliqué, il ajoute quand même beaucoup d’efficacité à leur site. Ils ont utilisé ces résultats positifs pour obtenir un financement pour leur prochain projet, qui sera une solution d’IA générative.

L'organisation n°2 a créé un chatbot pour son site de commerce électronique qui répond aux questions des clients sur les produits. Les modèles en grand langage sont assez compliqués - l'équipe n'était pas familiarisée avec la génération augmentée de réglage fin ou de récupération - donc tous les cycles d'ingénieur de ce projet étaient axés sur l'avancement rapide d'une courbe d'apprentissage abrupte. Une fois le modèle terminé, il a produit des résultats corrects – rien de spectaculaire. Malheureusement, il a dû être chargé manuellement dans les environnements de pré-production et de production, car aucun outil MLOps n'était en place pour le déployer. Cela a provoqué quelques frictions avec l’équipe DevOps. Le modèle lui-même présentait également quelques problèmes de stabilité en production. Le cluster dans lequel il s'exécutait ne disposait pas de suffisamment de calcul pour une charge de travail d'IA générative. Il y a eu quelques appels de gravité 1, qui ont abouti à une amélioration d'urgence du cluster afin que le LLM ne tombe pas en panne dans des conditions de trafic intense. Après le projet, une rétrospective a déterminé qu'ils devaient augmenter leur infrastructure s'ils voulaient réussir avec l'IA.

Un plan pour créer votre infrastructure de données IA/ML

La nouvelle ci-dessus est un simple récit de deux circonstances extrêmes. La création de modèles d’IA (à la fois discriminatifs et génératifs) est très différente du développement de logiciels conventionnel. Cela doit être pris en compte lors de la mise en file d’attente d’un effort AI/ML. Le graphique ci-dessous est une représentation visuelle de l’histoire racontée dans la section précédente. Il s’agit d’une comparaison côte à côte de l’approche AI Data Infrastructure First par rapport à l’approche Model First. Comme l’a montré l’histoire ci-dessus, chacune des briques ci-dessous pour l’approche infrastructure d’abord ne doit pas nécessairement être un projet autonome. Les organisations doivent rechercher des moyens créatifs de mettre en œuvre l'IA pendant la construction de leur infrastructure - cela peut être fait en comprenant toutes les possibilités de l'IA, en commençant simplement, puis en sélectionnant des projets d'IA de complexité croissante.

Conclusion

Cet article décrit notre expérience de collaboration avec des entreprises pour construire une architecture de référence Datalake moderne pour l'IA/ML. Il identifie les composants essentiels, les éléments constitutifs clés et les compromis des différentes approches d’IA. L’élément fondamental est un lac de données moderne construit au-dessus d’un magasin d’objets. Le magasin d'objets doit être capable de fournir des performances à grande échelle, soit des centaines de pétaoctets et souvent des exaoctets.

En suivant cette architecture de référence, nous prévoyons que l'utilisateur sera en mesure de créer une infrastructure de données flexible et extensible qui, bien que ciblée sur l'IA et le ML, sera également performante sur toutes les charges de travail OLAP. Pour obtenir des recommandations spécifiques sur les composants, n'hésitez pas à me contacter à [email protected] .