Creez et deployez vos modeles de Machine Learning avec Amazon SageMaker

Transcript

Bonjour à tous, bienvenue dans cette nouvelle série de webinaires consacrés à l'IA et au machine learning. Je suis Julien Simon, évangéliste pour l'IA et le machine learning chez AWS, et je suis très heureux de vous retrouver pour un nouveau webinaire en français. Aujourd'hui, nous allons parler des différents services de machine learning qui sont disponibles sur AWS pour vous aider à construire, à entraîner et à déployer vos modèles, avec un focus particulier sur Amazon SageMaker, et je ferai d'ailleurs quelques démos avec SageMaker. Allons-y. Pour les auditeurs qui ne seraient pas forcément familiers du machine learning, prenons juste une minute ou deux pour repositionner ce qu'est le machine learning et à quoi ressemble un cycle typique de projet de machine learning. Bien sûr, tout commence par un problème business, une question à laquelle vous voulez répondre. Par exemple, je veux savoir si une transaction est frauduleuse ou pas. Je veux savoir si ce client sera encore client dans 30 jours. Je veux distinguer les différents types d'objets présents dans des images, etc. Donc on commence par se poser une question et ensuite on va essayer de définir le problème en tant que problème de machine learning. Et pour ça, on va probablement interviewer des experts humains et leur demander comment ils résolvent ce type de problème, avec quelles informations, avec quelles données. Sur la base de ces interviews, on va commencer à définir un ensemble de sources de données, d'informations, qu'il va nous falloir collecter pour progressivement bâtir des modèles. On va récolter ces informations, peut-être certaines sont déjà présentes dans les systèmes de l'entreprise, peut-être qu'il faut se mettre à les capturer, à les loguer, et puis ensuite on va les intégrer, on va mettre tout ça au même endroit, et bien sûr on va passer beaucoup de temps à les préparer, les nettoyer. Pour ceux d'entre vous qui font déjà du machine learning, je suis à peu près sûr que au moins la moitié de votre temps est passé sur cette simple étape. Et ensuite, une fois que les données sont devenues un jeu de données, on va pouvoir commencer à le visualiser, à l'analyser, à essayer de comprendre à quoi ressemblent les données, les différentes colonnes s'il s'agit de données structurées. Et puis sur la base de ce jeu de données, on va faire du feature engineering. Ça c'est vraiment le domaine de la data science, on va essayer de construire des variables plus expressives que celles qui sont présentes dans le jeu de données initiales, des variables qui vont nous aider à entraîner des modèles efficacement. Et puis bien sûr, ensuite on entraîne le modèle et là on va itérer beaucoup, on va essayer différents algos, différentes combinaisons de paramètres en essayant d'atteindre un modèle le plus précis possible et on l'évaluera avec un autre jeu de données qu'on a mis de côté spécifiquement pour l'évaluation et le test de la qualité du modèle. Si le modèle a la qualité requise, très bien, on va pouvoir le déployer, mais probablement au début il n'a pas la qualité requise, donc on va itérer. Peut-être qu'il nous faut d'autres points de données, peut-être qu'il nous faut faire encore un peu de nettoyage, sans doute faut-il retravailler les features, peut-être qu'on peut essayer un nouvel algo, etc. Donc cette boucle itérative est importante, c'est celle-là qui va vous permettre d'arriver éventuellement à un modèle de qualité que vous voudrez ensuite déployer en production. Là, les vrais sujets commencent, puisque là on quitte l'environnement expérimental pour aller dans l'environnement de production et bien sûr il faut se poser toutes les questions de disponibilité, de sécurité, de qualité, de scaling, etc. Et puis régulièrement réentraîner les modèles sur la base de nouvelles données pour garder un modèle frais et des prédictions pertinentes. Voilà très rapidement à quoi ressemble le cycle de machine learning. Parlons un petit peu des différents services qui sont disponibles sur AWS. On va rebalayer rapidement ce cycle en voyant quels sont les services qui peuvent vous aider. Le premier service, la première grosse étape, c'est construire le jeu de données et dans certains cas, en particulier quand on travaille avec des données non structurées, des images, du texte, etc., il y a un gros travail d'annotation, c'est-à-dire que lorsqu'on va faire de l'apprentissage supervisé, évidemment le dataset seul ne suffit pas, il nous faut aussi annoter ce dataset, il faut qu'on ait des labels nous indiquant par exemple à quelle classe correspond une image ou est-ce que oui ou non cette transaction est frauduleuse, pour qu'ensuite le modèle puisse apprendre sur la base de ce jeu de données annotées et en extraire les motifs, les informations qui sont pertinentes. Pour aider nos clients à faire ce travail d'annotation qui est particulièrement long et coûteux, quand les jeux de données sont complexes, voici un exemple d'annotation d'images, c'est ce qu'on appelle de la segmentation, où on assigne chaque pixel à une instance bien précise, soit un véhicule, soit la végétation, etc. On doit faire ça image par image pour des milliers d'heures de vidéos, vous imaginez bien que ce genre de travail est particulièrement lourd. Donc on a créé un service, enfin un module au sein de SageMaker qui s'appelle SageMaker Ground Truth qui va vous permettre d'annoter rapidement et à coût maîtrisé vos jeux de données. Ground Truth contient des outils graphiques qui vont vous permettre d'annoter vos données et il va vous permettre ensuite de distribuer le travail d'annotation à soit des utilisateurs au sein de votre société, soit à des partenaires validés par Amazon qui vont annoter vos données, soit à Amazon Mechanical Turk, qui est un service d'Amazon qui permet de distribuer des tâches à plus de 500 000 travailleurs. On peut aussi automatiquement, au fur et à mesure de l'annotation, entraîner un modèle de machine learning afin que le grand truth lui-même apprenne à annoter automatiquement vos images ou votre texte, vos données, sur la base d'annotations faites par les humains. Donc les humains commencent et puis le modèle monte en précision et à partir d'un certain moment il va se mettre à annoter tout seul. Ça permet de gagner énormément de temps et d'économiser de l'argent. Ensuite, pour toute la phase de préparation et de nettoyage, vous trouvez sur AWS un ensemble de services data big data comme GLU qui est notre ETL ou EMR qui est le Hadoop Managé, etc., qui vont vous permettre de construire vos jobs de nettoyage et d'agrégation de données. Ce sont des services qui existent depuis un moment, qui sont sans doute bien connus maintenant, et ils vont s'intégrer efficacement dans le processus de machine learning. Et puis pour la suite, pour tout ce qui est vraiment, on va dire, entraînement, déploiement, vous avez plusieurs options. Vous pouvez évidemment tout faire à la main sur EC2, créer vos instances, les gérer, etc. Vous pouvez utiliser les services de containers, donc ECS ou EKS, donc le Kubernetes Managé, ou pourquoi pas Batch, pour déployer des tâches d'entraînement et ensuite déployer vos modèles pour servir des prédictions. Tout ça, évidemment, fonctionne, mais nécessite pas mal de travail d'intégration. Pour simplifier un peu ce travail, on vous fournit un outil qui est vraiment essentiel si vous voulez travailler directement sur EC2, qui est la Deep Learning AMI, une image de serveur virtuel préconfigurée, préinstallée avec l'ensemble des frameworks de Machine Learning et Deep Learning Open Source. Il vous suffit de démarrer cette AMI sur une instance EC2 et de vous connecter au serveur et de vous mettre à travailler. Ça vous évite l'installation et l'optimisation de tous ces frameworks qui prend elle aussi un certain temps. Pour les amateurs de containers, il y a 2-3 mois maintenant, on a lancé également les Deep Learning Containers qui sont disponibles pour TensorFlow et MXNet, qui sont exactement ce que le nom indique, à savoir finalement des containers préinstallés, préconfigurés par AWS pour l'entraînement et la prédiction sur TensorFlow et MXNet. Et donc vous pouvez les déployer super facilement sur ECS, EKS et vos propres clusters Docker. Tout ça vraiment toujours dans le même objectif, que vous n'ayez pas à installer et configurer vos propres environnements. Mais bien sûr, le travail sur EC2, ECS, EKS est tout à fait possible, mais pour aller un cran plus loin dans la simplification et la scalabilité, nous avons lancé il y a un peu moins de deux ans maintenant un service spécifiquement de machine learning qui s'appelle Amazon SageMaker. L'objectif de SageMaker c'est de vous permettre d'aller de l'expérimentation jusqu'à la production scalable en utilisant le même service, les mêmes API et surtout en n'ayant jamais à gérer le moindre serveur. Comme vous allez le voir dans les démos, l'infrastructure d'entraînement, l'infrastructure de prédiction est complètement gérée et on va se contenter de dire donne-moi tel nombre d'instances pour l'entraînement et tel nombre d'instances pour le déploiement et SageMaker va de A à Z gérer cette infrastructure, ce qui va nous permettre de nous concentrer sur le machine learning à 100%, ce qui n'aurait pas été le cas avec EC2, ECS ou EKS où on aurait quand même encore géré pas mal d'infrastructures. Sans parler de certaines fonctionnalités de SageMaker de haut niveau pour le machine learning dont je dirai deux mots tout à l'heure. SageMaker est un service qui a beaucoup de succès, qui a été adopté par tout type d'entreprise, des startups, des grandes entreprises dans à peu près tous les secteurs, le retail, les télécoms, les services financiers, la santé, etc. Donc manifestement, il correspond bien aux attentes de tous ces différents clients. Pour bien comprendre sur quelle partie du spectre du cycle interne SageMaker, voilà les étapes. SageMaker va vous permettre de commencer à expérimenter, à visualiser, à définir vos notebooks et à utiliser vos propres librairies Python, vos librairies favorites pour les stats, la visualisation, etc. C'est ce que j'utiliserai dans ma démo. On a ce qu'on appelle des instances de notebooks, qui sont là aussi des instances complètement managées, préinstallées avec Jupyter, etc., qui vont nous permettre en deux minutes de commencer à travailler. Et puis ensuite, tout le cycle entraînement-déploiement va être complètement couvert par SageMaker et ses API. Parlons de cette API justement. L'API de SageMaker, c'est un SDK spécifique en Python, qu'on appelle le SDK SageMaker. C'est un SDK de haut niveau. Quand je dis de haut niveau, ce que je veux dire par là, c'est que vous allez travailler avec des objets vraiment de machine learning. Donc là, on ne va pas du tout se soucier d'infrastructures, on ne va pas travailler avec des VPC, des instances EC2 et que sais-je. On va travailler avec des algos, des jobs de training, des jobs de déploiement, des objets de modèles, etc. L'objectif est toujours le même, c'est de vous permettre rapidement de vous concentrer vraiment à 100% sur le processus de machine learning et d'arriver rapidement à des modèles déployables en production. On a également un SDK pour Spark qui est disponible en Python, et dans ce cas-là, j'en parlerai pas aujourd'hui, n'hésitez pas à nous poser des questions, on va essayer de répondre au maximum de questions. Donc si vous utilisez Spark aujourd'hui et que vous êtes curieux sur pourquoi intégrer Spark et SageMaker, n'hésitez pas à nous poser des questions, j'ai fait d'autres webinaires sur ce sujet, je pourrais vous donner les références. Bien sûr, on a aussi des API pour le service lui-même comme pour tous les services AWS, EC2, S3, etc., qui sont disponibles soit sur la ligne de commande soit dans les SDK des différents langages Python, Node.js, C++, etc. Mais de mon point de vue, ces API là sont plutôt pour du scripting, de l'automatisation, etc. Elles ont évidemment leur utilité pour la production, mais en ce qui concerne l'expérimentation et le processus de machine learning à proprement parler, je vous recommande très fortement le SDK SageMaker, vous allez voir, il est assez simple. Lorsqu'on entraîne des modèles sur SageMaker, on a trois options. La première option, c'est d'utiliser des algorithmes sur étagère. On en a 17 aujourd'hui. Je vous montrerai la liste dans un instant. On va trouver les problèmes classiques de machine learning, la régression linéaire, le clustering, K-means, et des K&N, etc. Mais aussi des algos de Deep Learning. L'avantage d'utiliser ces algos, c'est qu'évidemment on n'a pas à coder du tout de Machine Learning. Donc si vous êtes un développeur et que vous débutez sur ce sujet, c'est un très bon point de départ puisque vous allez simplement vous contenter de sélectionner un algorithme, vous allez le paramétrer simplement et puis vous allez entraîner votre job. On va faire une démo dans deux minutes. Donc pas besoin de coder du Machine Learning, pas d'infrastructures à gérer, du training distribué préconfiguré, donc si vous avez besoin de 10 instances, 20 instances, 30 instances, parce que vous avez un gros jeu de données, il n'y aura pas d'efforts supplémentaires à faire. Et puis on a un feature qui s'appelle Pipe Mode, qui permet de streamer directement depuis S3 des gros jeux de données vers les instances de training. Ce qui permet évidemment de ne plus avoir de limites sur la taille du jeu de données. Si vous avez 100 teraoctets de données ou un pétaoctet de données, vous n'aurez pas à les copier, ce qui serait impossible évidemment, vers les instances qui vont faire le training. Vous allez pouvoir streamer et finalement vous entraîner vos modèles sur autant de données que nécessaire. La deuxième option, c'est d'utiliser des frameworks intégrés et là on va retrouver nos librairies favorites de machine learning et deep learning donc scikit-learn, TensorFlow, PyTorch, etc. Et là donc elles sont préinstallées, préconfigurées, tout ce que vous avez besoin de faire c'est d'amener votre code, donc amener votre code TensorFlow, scikit-learn, faire deux ou trois petites modifs extrêmement minimes, je vous montrerai ça tout à l'heure, pour les intégrer sur SageMaker et puis vous pourrez entraîner votre job. Elles sont intégrées sous forme de containers sur SageMaker et les containers sont open source, vous les trouverez sur GitHub, donc si vous voulez voir exactement comment on a configuré ces containers pour telle ou telle librairie, si vous voulez les réutiliser, les modifier, etc., vous pouvez tout à fait le faire. Toujours pareil, pas de travail d'infrastructure, training distribué et pipe mode également disponible. Puis la dernière option, c'est l'option custom où vous pouvez amener ce que vous voulez. Donc si vous utilisez un autre langage, un autre environnement pour entraîner ou déployer vos modèles, que ce soit R ou C++, votre code maison, pas de problème. Vous pouvez construire votre propre container et l'utiliser pour l'entraînement et la prédiction sur SageMaker. Pas de difficultés particulières. Voilà la liste des algos, avec un code couleur tout à fait compliqué, avec en orange les algorithmes pour l'apprentissage supervisé et en jaune les algorithmes non supervisés. Donc comme je disais tout à l'heure, on voit les problèmes classiques, les algos statistiques classiques, des choses moins classiques comme Deep AR, qui est un algo inventé par Amazon pour la gestion des technologies, ou Blazing Text, un autre algo inventé par Amazon pour calculer des vecteurs de mots sur GPU. Et puis on trouve quelques algos de Deep Learning pour la classification, la détection, la segmentation. Donc une fois de plus, tout ça est sur étagère, vous trouverez toutes les infos dans le guide de développeurs de SageMaker et vous pouvez les utiliser assez facilement. Et puis une fois que vous avez entraîné vos modèles, vous allez pouvoir les déployer simplement et littéralement en une ligne de code. Alors on va faire une petite démo, histoire de concrétiser tout ça. Je vais sauter dans mon notebook. Voici une instance de notebook que j'ai créée en deux minutes sur SageMaker, en quelques clics, vous trouverez ça dans la console, super simple. Et ici, ce que je voudrais faire, c'est entraîner un modèle de classification sur un jeu de données qui s'appelle Caltech 256. Il faudrait peut-être que je vous montre rapidement Caltech 256, on va le trouver. Alors Caltech, c'est un jeu de données avec 256 classes. Un peu de tout. Et il a la particularité d'avoir peu d'images par classe. Si je veux, regardons les comètes. Combien on a d'images pour cette classe ? On en a une petite centaine. Et en fait, on a environ 15 000 images pour les 256 classes. Donc vous voyez qu'en moyenne, ça fait, allez, on va dire 80 images par classe. Donc c'est peu, si vous avez déjà creusé un petit peu le sujet. On dit toujours, pour entraîner un modèle de classification d'images, il faut au moins entre 500 et 1000 images par classe, en fonction de la complexité de ces images. Donc ici, manifestement, prenons les chapeaux de cow-boy, pourquoi pas, manifestement, on n'a pas assez d'images du tout. On a ici encore une petite centaine d'images, et il y a certaines classes qui sont vraiment assez peu riches en images. Donc le but, c'est malgré tout d'arriver à entraîner un modèle. Dans la liste des algos que je vous ai montrée, il y a un algo de classification d'image. On va l'utiliser. La première chose à faire, c'est évidemment d'importer le SDK SageMaker. Donc ici, une fois de plus, je le fais sur une instance de notebook, mais vous pourriez tout à fait faire ça localement sur votre machine. Et vous pourriez le faire dans un notebook ou vous pourriez le faire en dehors d'un notebook. C'est du Python tout à fait standard. Donc j'importe ce SDK, je récupère un bucket S3 puisque c'est là que je vais devoir mettre mes données d'entraînement et c'est là que je vais récupérer le modèle qui a été entraîné. Donc je récupère un bucket, c'est tout simple. Ensuite, je vais sélectionner l'algo de classification d'image et j'ai dit tout à l'heure que tout ça a été basé sur des containers Docker, mais une fois de plus il n'y a pas besoin de savoir ça, sauf si vous voulez construire le vôtre. Donc ici je me contente de demander à SageMaker, donne-moi le nom du container qui implémente l'algo de classification d'image dans la région où je me trouve. Et donc je récupère ça, donc ici mon notebook tourne en US East One, donc je vois que je récupère le nom du container qui implémente cet algo dans la région U.S. East 1. Ce container est hébergé dans Amazon ECR qui est le service de registries Docker dans AWS. Donc très simple. Ensuite, je vais télécharger mon dataset. Évidemment, je l'ai déjà fait plein de fois. Il est déjà découpé en ordinateurs d'entraînement et validation. Vous voyez qu'en fait, l'ensemble des images d'entraînement et l'ensemble des images de validation ont été regroupées dans un seul fichier, ce qui est bien pratique. Ça évite d'avoir à télécharger et déplacer des milliers d'images avec tous les risques d'erreur. Et ce format de fichier s'appelle Record.io. C'est un format enregistrement qui est simple à déplacer et qui a aussi l'avantage d'être simple à découper si jamais il fallait faire de l'entraînement distribué et répartir les images entre différentes instances. Donc c'est un bon format à utiliser. TensorFlow a la même chose, ça s'appelle TF Record. Ici, j'utilise un algo sur étagère et ces algos sont implémentés avec MXNet. MXNet utilise Record I.O. Mais voilà, TF Record et Record I.O. c'est la même chose. Très bien. Donc je le télécharge sur mon instance de notebook, ici j'ai pas de nettoyage de données, j'ai pas d'agrégation, j'ai pas de choses comme ça, j'ai pas de TL à faire, c'est un dataset standard propre, donc je vais pouvoir l'uploader directement dans S3 et donc je vois ici que c'est très bien, j'ai dans ce préfixe S3 là mon dataset de training et dans ce préfixe-là, j'ai mon dataset de validation. Et j'écrirai mon modèle à cet endroit-là. Je définis juste quelques variables, je vérifie que les fichiers sont là, et c'est bon. Maintenant, il ne me reste plus qu'à configurer mon job. Donc ici, j'utilise un objet qui est important dans le SDK SageMaker, qui s'appelle l'estimator. Et donc, c'est l'objet qui va me permettre de configurer le job de training pour tous les algos existants. Donc le premier paramètre, sans surprise, c'est le nom du container qui implémente l'algo. Et puis ensuite, grosso modo, je me dis juste, donne-moi une instance P3 16XL, c'est-à-dire une instance GPU, P3, c'est la famille EC2 qui fournit les instances GPU basées sur le Nvidia, et 16XL, donc c'est la plus grosse instance disponible dans SageMaker, qui contient 4 GPU de ce type. Donc une grosse instance que je vais utiliser à la demande pour entraîner mon modèle. Et une fois le modèle entraîné, on le sauvera là. C'est tout. Vous voyez, en termes d'infrastructure, on ne s'est pas fait mal à la tête, pas de subnet, pas de VPC, pas de clé SSH, pas d'internet gateway, pas de tout ça. On se contente de dire voilà ce que je veux pour entraîner mon modèle. Ensuite, on va positionner quelques paramètres pour l'algo. Là, vous trouvez tous les paramètres évidemment dans le guide SageMaker. Ici, on utilise donc un algo de deep learning pour la classification. Il est basé sur une architecture de type ResNet qui est un classifieur d'images efficace. On peut choisir la profondeur du réseau. Ici j'ai choisi 18 couches, c'est la plus petite taille disponible pour aller vite. Je vais utiliser un modèle préentraîné puisque souvenez-vous qu'on a peu d'images, donc pas du tout suffisamment d'images pour entraîner à partir de zéro. Donc on va faire ce qu'on appelle du transfer learning, c'est-à-dire qu'on va réutiliser un modèle qui a été entraîné sur des millions d'images similaires, venant d'autres classes, mais suffisamment similaires pour que cet apprentissage soit pertinent, et on va se contenter de réentraîner ce modèle juste un petit peu sur notre propre jeu de données. Donc c'est quelque part une spécialisation d'un modèle préentraîné sur un nouveau dataset. On donne la forme des images, donc ces images couleurs, 3 canaux, 224, 224, le nombre de classes, donc 256, plus une classe poubelle, appelons-la comme ça, qui est une bonne pratique qui permet de, en ajoutant des images complètement aléatoires et complètement bidons, de forcer le modèle à travailler un petit peu plus dur lors de l'apprentissage. Le nombre d'échantillons, donc un peu plus de 15 000. La taille de batch pour l'apprentissage, 128 pourquoi pas, c'est une bonne valeur par défaut. Le learning rate 0.01. On va faire un peu d'augmentation de données, donc on va demander à l'algo de générer en plus des images existantes, enfin sur la base des images existantes, de générer des images transformées, donc qui vont être un petit peu déformées, aux couleurs modifiées, etc. Ça permet automatiquement de générer des échantillons supplémentaires et ça permet là aussi de rendre le modèle plus résistant. Et puis on va juste entraîner pour 20 époques, on va passer le dataset 20 fois à travers l'algo, ce qui est peu, mais il faut être plus on fait du transfer learning donc on n'a pas besoin d'entraîner pendant des jours et des jours. Si on entraînait à partir de zéro on entraînerait peut-être pour 200 époques, 300 époques voire plus pour atteindre une bonne précision. Voilà c'est tout. Il y a plein d'autres paramètres mais on peut laisser les valeurs par défaut et si on ne sait pas quoi mettre autant laisser les valeurs par défaut. Ensuite on va juste définir précisément que notre jeu d'entraînement est donc sur ce préfixe S3. On veut le copier sur l'instance de training. Ici, on n'utilise pas le pipe mode. Le jeu de données fait un peu plus de 300 mégas, donc on n'a pas de problème à le copier directement sur les instances. Et il est au format Record I.O. Donc ce format de type enregistrement qui nous permet d'avoir tout le jeu de données en un seul fichier. Donc on fait ça pour le jeu de training, on fait ça pour le jeu de validation, voilà. Et puis on va passer donc ces deux jeux de données au training lui-même. Et donc le training lui-même ne nécessite qu'un appel. Et donc une fois qu'on lance ce training, eh bien il va se dérouler. Donc on va créer l'instance P3, on va envoyer le container de classification d'image sur cette instance, on va copier les données et puis on va entraîner. Et alors si juste cette fois, on jette un oeil à la console, on va voir ce logiciel. Voilà, donc il a duré 13 minutes. On voit tous les paramètres qu'on a passés. On voit le... Là, je n'ai pas affiché le log dans le notebook, mais on voit le log. On pourrait voir le log dans le notebook et bien sûr, on peut le voir dans CloudWatch. Voilà. Donc là, je vois le log dans le notebook. D'ailleurs, c'est sûrement là que vous avez envie de le lire, plus que dans le notebook. Surtout si vous avez des jobs qui tournent automatiquement, programmatiquement. Vous avez envie de les faire tourner et puis d'aller récupérer le log. Donc on voit, on a bien entraîné 20 époques. Et on a une précision de 77% sur le jeu de validation. Ce n'est pas extraordinaire, mais je n'ai pas particulièrement cherché à battre de record, c'est juste une petite démo rapide. Et donc je vois que ce job a duré 13 minutes. Et donc ce que je paye ici, c'est 13 minutes d'instance P3 16XL. Et cette instance se termine automatiquement une fois que le job est terminé, donc vous ne risquez pas de payer, de laisser de l'infrastructure et de payer pour cette infrastructure alors qu'elle ne fait rien. Pour moi c'est un des gros avantages de SageMaker par rapport à EC2, ECS, EKS, même EMR, c'est que ça démarre à la demande et ça se termine automatiquement. Et on paye juste pour ça, rien, pas d'infrastructure qui tourne et qui ne fait rien. Donc ensuite en une ligne de code je peux déployer mon modèle donc il me suffit d'appeler l'API deploy du SDK et de même comme tout à l'heure de dire tiens déploie sur une instance c5.2xl qui est une instance CPU qui suffira bien pour prédire sur ce modèle. Et donc si je regarde ensuite dans la console de SageMaker, je vais voir que j'ai un endpoint qui tourne et donc je vois ici l'URL de ce endpoint. Donc c'est un endpoint HTTPS qui s'appuie sur une instance C5 de XL complètement managée. Si j'avais demandé 10 instances, j'aurais une URL appuyée par 10 serveurs, load balancé, multi AZ, etc. Et on peut aussi configurer l'auto scaling si on souhaite adapter l'infrastructure à la charge. On n'est pas obligé de déployer sur un endpoint, on peut aussi faire une transformation, on peut aussi faire de la prédiction en mode batch, où là, on ne va pas créer de endpoint, on va se contenter de prédire un jeu de données qui est dans S3, et puis vous récupérez vos prédictions dans S3. Vous pourriez aussi récupérer le modèle si je retourne sur mon training job, on pourrait aussi se dire, tiens, j'ai envie de récupérer le modèle et j'ai envie de le charger sur ma machine, j'ai envie de le tester, etc. Le modèle, il est dans S3. Si j'ouvre la console S3, je vais voir l'artefact. C'est un fichier TAR compressé à l'intérieur duquel je vais trouver mon modèle. Si je télécharge ce truc-là et que je l'extraie, j'ai un modèle ici MXNet que je peux tout à fait utiliser sur mon laptop ou sur un serveur on-premise si j'ai vraiment envie de faire ça. Donc vraiment, c'est un service qui est hyper modulaire, vous utilisez ce que vous voulez, vous voulez les notebook instances très bien, vous ne les voulez pas très bien, vous voulez entraîner sur SageMaker, faites ça, vous récupérez le modèle dans S3, vous voulez le déployer sur SageMaker, parfait c'est une ligne de code, vous voulez le récupérer et le mettre sur votre machine il n'y a pas de problème non plus. Voilà, vous avez la liberté de faire ça. Alors on va essayer quand même de prédire donc on va récupérer une petite image alors ici je récupère une image qui est dans le dataset de départ donc elle devrait fonctionner donc c'est un bouddha qui est une des classes et si donc je charge cette image en tant que byte array, que je mets le bon type de contenu, donc X images, et que j'appelle l'API predict sur mon endpoint, en passant l'image, je vois que je récupère des prédictions et que, OK, pas de problème, c'est bien Bouddha. Donc ici, cette API predict, elle fait simplement un HTTP post de l'image sur le endpoint. Une fois de plus, ici on expérimente, on utilise le SDK mais vous pouvez utiliser n'importe quel langage ou n'importe quel outil à partir du moment où vous postez au bon format sur le bon endpoint, vous allez récupérer vos prédictions. Ok alors on va essayer une autre image juste pour voir. Donc là cette fois c'est pas une image du dataset. Ok, un gentil chimpanzé, qui est là aussi une classe, je crois qu'on l'a aperçu tout à l'heure. Ok, bon ben là on voit, pareil, pas de problème, c'est bien un chimpanzé. Et puis une fois qu'on a fini, on pourrait se dire, ok j'ai terminé, je veux effacer mon endpoint, voilà, paf, et c'est terminé, donc l'instance C5 va disparaître, on arrête de payer pour ce endpoint, et puis si on veut le redéployer plus tard, on le redéploie plus tard. Donc vous voyez finalement, voilà le workflow typique sur SageMaker. Je récupère des données, probablement je les nettoie un petit peu quand même, parce que dans la vraie vie, les choses sont plus compliquées qu'ici. Je les mets dans S3, je sélectionne un algo, je configure mon estimator, j'indique combien d'infrastructures je veux, je mets mes paramètres, je définis rapidement les propriétés du dataset, j'entraîne, je déploie, soit en HTTPS, soit en batch, et puis ensuite je prédis. Est-ce qu'on a écrit une ligne de machine learning ici ? Non. Et combien de lignes de Python on a écrit ? 20, 30. Quand je dis un SDK de haut niveau, c'est ça que je veux dire, c'est qu'on va droit au but, on se concentre sur les données, on se concentre sur le modèle, on ne passe pas un instant à travailler sur l'infrastructure, et on peut itérer rapidement sur son modèle et sur la précision du modèle. Voilà un premier exemple, et ça marchera à peu près de la même façon pour tous les algos built-in. Si on descend un petit peu d'un cran, j'ai dit tout à l'heure que cette partie d'optimisation et de déploiement était compliquée. Et on a lancé deux autres modules au sein de SageMaker, qui s'appelle NEO et Elastic Inference, qui vont vous permettre d'optimiser à la fois les performances et le coût de vos déploiements. Donc jetons un oeil à ça et puis après on fera une petite démo. On veut avoir des prédictions plus rapides, et dans certains cas, sur des environnements contraints, comme dans le monde embarqué, on est obligé de le faire pour obtenir des performances satisfaisantes. Donc NEO, c'est deux choses, c'est un compilateur, donc vous allez pouvoir prendre votre modèle, TensorFlow, MXNet, PyTorch et quelques autres. Vous allez pouvoir le compiler pour une cible précise, donc aujourd'hui on supporte les plateformes ARM, Intel et Nvidia, on a d'autres plateformes en cours de développement. Et vous allez ensuite récupérer ce modèle compilé et avec le runtime de NEO, donc il y a un runtime très très léger qui va vous économiser l'installation de TensorFlow, MXNet, etc. sur le device en question, avec ce runtime vous allez charger le modèle et vous allez prédire. L'ensemble du compilateur et du runtime sont open source donc si jamais vous voulez adapter NEO sur votre propre plateforme vous pouvez tout à fait le faire. Alors voilà un exemple tout simple pour un Raspberry Pi. Ici, j'ai un modèle que j'ai entraîné, que j'ai mis dans S3. C'est un modèle MXNet, c'est un modèle de classification d'image. J'ai envie de le compiler pour le Raspberry Pi et j'ai envie que le résultat soit stocké là dans S3. Je dis tout ça. Voilà mon modèle, voilà le format d'entrée du modèle, voilà son framework, voilà où il faut le copier et voilà pourquoi il faut l'optimiser. Ensuite un seul appel d'API, create compilation job, sur la base du fichier de config compile moi ce modèle. Cette API est d'ailleurs gratuite, vous pouvez compiler vos modèles à zéro coût. Ensuite je récupère dans S3 le modèle compilé et je l'extrais. Je vois que j'ai le modèle initial, c'est un modèle ici MXNet, le fichier params qui contient les poids, le fichier JSON qui contient la définition du modèle, et puis un objet natif, une librairie native qui contient les opérateurs de machine learning compilés pour la cible ici, compilée pour le Raspberry Pi. Et ensuite sur le Raspberry Pi, en utilisant le runtime, tout ce que j'ai à faire, c'est de charger mon modèle compilé et puis de prédire. Alors en termes de performance, j'ai fait évidemment le test, c'est un vrai test. Si j'utilise mon modèle MXNet de départ, j'arrive à prédire une image sur mon Pi, c'est l'ancien Pi, ce n'est pas le tout dernier. J'arrive à prédire en 6-7 secondes, une fois le modèle compilé, je prédis en une seconde. C'est quand même extrêmement significatif. Alors je ne promets pas que vous allez faire x6 ou x7 sur toutes les combinaisons de modèles et de plateformes. En tout cas, ici, j'ai eu un speed-up super intéressant. Et le deuxième service dont je vais vous parler, que je vais vous montrer, c'est Elastic Inference. Le but ici, c'est de vous donner un choix intermédiaire entre déployer sur des instances GPU super puissantes, mais avec un certain coût, et déployer sur des instances CPU qui sont plus économiques mais qui vous donnent peut-être pas le niveau de performance requis. Donc si vous avez des très gros modèles, bien sûr vous allez déployer sur le GPU, vous allez les utiliser à 100% et le prix sera justifié, mais parfois on a des modèles qui sont un peu trop lents sur CPU et qui n'utilisent pas entièrement l'instance GPU. Et donc on déploie quand même sur GPU mais on a le sentiment qu'on n'en fait pas le meilleur usage. Et donc Elastic Inference, c'est simplement la capacité à utiliser des fractions de GPU qui viennent en trois tailles donc medium, large, xlarge donc une fraction de GPU qu'on va pouvoir attacher à n'importe quelle instance EC2 ou n'importe quelle instance SageMaker. Et donc vous allez pouvoir ajuster votre rapport coût performance avec soit du SageMaker CPU tout seul, soit du CPU accéléré par une fraction de GPU, soit carrément avec des instances GPU. Donc là, ça vous donne un choix supplémentaire pour trouver exactement le bon rapport coût-performance. Alors, jetons un petit œil à ça pour finir. Et ici, je vais vous montrer au passage comment utiliser Keras, qui est une librairie de deep learning, et comment l'intégrer sur SageMaker. On va faire plusieurs choses en même temps. Ici, ce que je veux faire, c'est apprendre ce dataset qui s'appelle Fashion MNIST, qui est un remplacement d'EMNIST, dont on est tous fatigués, les chiffres de 0 à 9, on a envie de passer à autre chose. C'est le même nombre de classes, on a 10 classes, c'est le même nombre d'exemples, 69 000, la même taille d'image etc. C'est un dataset qui a été créé par Zalando mais qui est complètement compatible avec MNIST mais qui est plus difficile à apprendre parce que vous voyez qu'ici on travaille avec des objets un petit peu plus complexes. Donc allons-y, lançons-nous. Donc le SDK SageMaker, on va télécharger le dataset Fashion MNIST. Ici il y a une API dans Keras qui permet facilement de faire ça, je le télécharge localement sur mon notebook instance ici. Je n'ai pas besoin de faire de traitement de données, le dataset est propre, bien organisé donc je peux l'uploader directement sur S3 comme tout à l'heure donc j'ai un préfixe pour le training, un préfixe pour la validation. Ok, alors évidemment il va me falloir un bout de code Keras, le voilà donc c'est on va le regarder rapidement donc c'est qu'est-ce qu'on fait ? On charge le dataset, on fait juste une normalisation rapide des images et puis ensuite on définit un réseau à convolution assez simple avec deux blocs de convolution, un bloc de classification connecté à la fin. Voilà, on compile le modèle, on l'entraîne, on l'évalue et on le sauve. On le sauve au format TensorFlow Serving parce que c'est grâce à ça qu'on va pouvoir le déployer sur SageMaker. Et puis, on lui passe quelques paramètres, parce qu'on a envie de paramétrer, et c'est ce que je vous disais tout à l'heure, la seule modif que vous avez à faire pour intégrer votre code, alors que ce soit TensorFlow, MXNet, Keras, etc., sur SageMaker, c'est d'être capable de lire ces quatre variables d'environnement qui vous indiquent combien de GPU sont disponibles, où sauver le modèle entraîné, où est le dataset de training et où est le dataset de validation. C'est une fonctionnalité de SageMaker qui s'appelle le script mode. Regardez bien ça dans la doc. Et en fait, si vous êtes capable d'ajouter ces quatre lignes de code et de récupérer ces quatre variables d'environnement, eh bien votre code va fonctionner sur SageMaker. C'est aussi simple que ça. Donc il n'y a vraiment pas de modification lourde à faire, il n'y a pas de réécriture pour intégrer votre code sur SageMaker. La première étape qu'on pourrait avoir envie de faire, c'est déjà de vérifier ça, c'est de vérifier que le code fonctionne bien sur SageMaker. Ici, on va utiliser l'objet TensorFlow qui est un estimateur spécialisé pour TensorFlow. Ici, évidemment, on n'a pas besoin de dire qu'on veut le container TensorFlow. On va passer le code que vous venez de voir en paramètres. On va dire qu'on veut entraîner localement. Ici on va entraîner localement sur l'instance de notebook mais vous pourriez entraîner localement sur votre machine. Ça va nous permettre de tester rapidement que ce code fonctionne au sein de SageMaker. On ne va pas créer une instance managée donc on gagne du temps et on économise le coût de cette instance. Pour vérifier rapidement que tout fonctionne bien, c'est une très bonne solution. Donc on dit local ou local GPU si on avait un GPU sur la machine. Donc on indique bien qu'on veut faire du script mode et puis on va juste entraîner pour une époque parce qu'ici on veut juste vérifier que ça marche. On ne cherche pas à atteindre une grosse précision. Donc ici ce qui va se passer c'est que je vais récupérer sur ma machine le container TensorFlow et je vais entraîner pour une époque donc ça va vite, ça va durer deux minutes parce que j'ai pas de GPU. Bon j'ai une précision quelconque mais c'est pas le but. Voilà et puis ça se termine. Donc ici je sais que ce code marche dans l'environnement TensorFlow. Donc le mode local, ce qu'on appelle le mode local, c'est vraiment une bonne technique pour expérimenter rapidement. Et puis ensuite, j'ai envie maintenant d'entraîner sur une vraie instance. Donc au lieu d'utiliser le mode local maintenant, je veux dire, on entraîne sur P3 de XL. Donc il y a une instance avec un seul GPU, toujours avec script mode, et puis en passant quelques hyperparamètres, 20 époques, etc. Donc j'entraîne. Donc ça va durer un peu plus longtemps. On voit tout le long. Log, allons tout en bas, ok, donc là j'ai 92 et quelques pourcents de précision, le job, l'entraînement a duré 115 secondes, donc une fois de plus je paye pour 115 secondes d'instance, P3 2XL, elle se termine automatiquement, ensuite je déploie mon modèle et vous voyez qu'ici je le déploie avec Elastic Inference, donc au lieu de déployer sur une instance P2 qui me coûterait 1,36$ et dont je ne fais pas bon usage parce qu'ici c'est un tout petit modèle et je ne vais certainement pas utiliser mon instance GPU à 100%, je me déploie sur la combinaison C5 Large et un accélérateur Medium qui vont me donner à peu près les mêmes performances que P2 XL mais 80% moins cher. Donc Elastic Inference, c'est vraiment un mécanisme d'optimisation des coûts lorsque vous n'avez pas besoin d'une instance GPU complète vous pouvez vous satisfaire d'un accélérateur et économiser énormément d'argent là si on le ramène au coût d'une instance par mois vous allez économiser un peu moins de 800 dollars par mois si cette instance est allumée 24 heures sur 24 pendant un mois donc 800 dollars par instance ça vaut la peine. Et puis comme tout à l'heure, je peux prédire, donc je vais récupérer quelques images dans mon dataset, appeler predict sur mon endpoint, allons-y, voilà, et je vois les images avec leur classe et la classe prédite, 3, 7, 7, 4, 5, voilà, ça marche pas mal. Voilà, ok, là on a une petite erreur, on n'a que 92% de précision, donc de temps en temps on doit avoir une petite erreur. Donc voilà à la fois comment utiliser votre propre code, et ça marcherait pareil avec PyTorch, Scikit-learn, etc. Voilà comment utiliser le script mode, qui vous permet facilement d'intégrer votre code, et voilà comment utiliser Elastic Inference, quand vous voulez une solution intermédiaire entre le CPU et une instance GPU complète. Voilà ce que je voulais vous montrer. Alors comment commencer ? Quelques ressources. Alors évidemment, SageMaker fait partie du free tier. Donc vous pouvez créer votre compte et utiliser SageMaker gratuitement pendant 12 mois jusqu'à un certain niveau d'usage. Si vous êtes curieux des différents services de machine learning dont j'ai parlé et beaucoup d'autres, vous les trouverez tous sur ml.aws. Et bien sûr, on a une page dédiée pour SageMaker avec la doc, les réseaux, références clients, les cas d'usage, les prix, etc. Le SDK Python que j'ai utilisé est sur GitHub, le SDK Spark dont je n'ai pas parlé est lui aussi sur GitHub. On a aussi une vaste collection d'exemples de notebooks, il doit y en avoir au moins bien plus d'une centaine maintenant, qui sont sur GitHub et que vous pouvez utiliser pour découvrir tous les algos sur étagère, tous les modes de deep learning, etc. Si vous voulez un workshop détaillé, vous trouverez donc ce workshop ent 321 sur GitLab, c'est un workshop que j'ai fait à re:Invent l'année dernière qui prévoyait trois ou quatre heures et vous allez creuser assez profondément sur ces sujets, on fait aussi de l'optimisation d'hyperparamètres, enfin on va loin, on aborde un peu d'autres sujets que j'ai pas eu le temps de couvrir aujourd'hui. Et enfin, si le sujet vous intéresse, n'hésitez pas à me suivre sur Medium, j'ai pas mal d'articles sur SageMaker et également pas mal de notebooks disponibles sur GitLab. Voilà, n'hésitez pas une fois de plus à nous envoyer toutes vos questions, on essaiera de répondre au maximum. Je vous remercie beaucoup de m'avoir écouté, j'espère que vous avez trouvé ce webinaire utile et si vous voulez rester en contact, vous pouvez également me suivre sur Twitter, pour être au courant de toute l'actualité et AI ML d'AWS et être au courant de tous nos prochains événements. Voilà, merci encore, je vous souhaite une bonne fin de journée et restez connectés pour les autres webinaires. Merci beaucoup.