Simplifiez et accelerer le Machine Learning avec Amazon Sagemaker AWS Summit Paris 2018

Transcript

Merci d'être toujours là. Il y a sûrement plein de choses à faire à Paris, à part être assis dans une salle du Palais des Congrès. J'ai quelques idées, mais manifestement, vous voulez parler de machine learning, donc vous êtes dans la bonne salle. Ce matin, j'ai fait une introduction très générale sur les différents services de machine learning disponibles sur AWS. Pour ceux d'entre vous qui étaient là, nous avons rapidement parlé d'une couche appelée les services plateformes, dont SageMaker fait partie. Juste pour repositionner la discussion, certes, les services de haut niveau comme Polly Recognition sont très intéressants et simples à utiliser, mais ils fonctionnent bien sur des problèmes généraux. Si vous voulez reconnaître des objets de la vie de tous les jours, Recognition marche très bien. Si vous voulez reconnaître des pièces automobiles, faire de l'imagerie médicale, traiter des images satellites, etc., il s'agit de problèmes assez spécialisés et Recognition ne fonctionnera pas. Vous devrez entraîner votre propre modèle. De même, si vous voulez construire un modèle de traduction automatique avec une paire de langages non supportée par Amazon Translate, vous pourrez le faire avec un service comme SageMaker. La différence entre les services de haut niveau et un service comme SageMaker est la capacité à travailler avec son propre jeu de données, à définir son modèle, à choisir ses algorithmes et paramètres, sans être englué dans l'infrastructure. Comme je l'ai expliqué ce matin, quand on se lance dans le machine learning, on doit franchir un certain nombre d'obstacles, certains inévitables et inhérents au projet, comme la collecte et la préparation des données. Au fur et à mesure du projet, on doit aussi affronter le choix de l'algorithme, la construction d'infrastructures pour entraîner ces modèles, le choix des hyperparamètres, le déploiement du modèle en production, etc. Ce sont des étapes indispensables, mais pas toutes à forte valeur ajoutée pour votre projet. Il faut le faire, alors on le fait, mais sincèrement, si on avait le choix, on préférerait passer son temps sur la partie machine learning. L'objectif d'un service comme SageMaker est précisément de vous déblayer le terrain et de vous permettre de passer le maximum de temps sur la compréhension des données, la construction du modèle et le déploiement simple du modèle pour l'intégrer dans vos applications, tout en vous débarrassant du reste et en le rendant aussi simple et transparent que possible. On le verra dans les exemples que nous allons utiliser dans quelques minutes. La première étape importante quand on travaille avec des données est d'avoir un environnement de développement et d'expérimentation. Si on est tout seul ou si on est une petite équipe, ce n'est pas vraiment un problème. On peut travailler sur sa machine, se construire une machine de dev puissante, s'acheter des GPU, etc. On peut aussi travailler sur des instances EC2 avec peu de temps passé à la configuration. Le problème survient dès qu'on passe à l'échelle, que ce soit une échelle humaine, c'est-à-dire si votre équipe passe à 50 data scientists ou 50 développeurs machine learning, la discussion devient compliquée. Se construire une machine de développement à 20 000, 30 000 euros avec des GPU, multipliée par 50, devient vite un problème. Poser la question à votre patron, vous verrez, ça sera un problème. Il y a un deuxième axe de scalabilité qui est la volumétrie des données. Si vous travaillez avec de petits datasets, sur une machine avec un GPU, ça va. Mais à l'échelle, vous êtes vite confronté à des limites. Construire son propre serveur et le mettre dans le placard peut fonctionner un temps, mais ça s'arrête vite. La première brique de SageMaker est de vous fournir très simplement des notebook instances, des instances préinstallées contenant Jupyter, d'où leur nom, et des environnements préinstallés comme TensorFlow, MXNet, Python, etc., pour que vous ayez une machine prête à fonctionner en un clic ou un appel d'API, sans avoir à gérer ou installer grand-chose. La deuxième brique que nous vous fournissons est un ensemble d'algorithmes intégrés, les fameux built-in algos, qui sont au nombre de 12 ou 13 aujourd'hui. Ce sont des algorithmes qui permettent de résoudre les problèmes classiques du machine learning, comme la classification, le clustering, la régression linéaire, la réduction de dimension, etc. Ces algorithmes ont été implémentés par Amazon, à part XGBoost qui est une implémentation open source. Ils sont également utilisés en interne pour nos propres besoins, avec un niveau de scalabilité correct. Vous pouvez les sélectionner, ajouter votre jeu de données, vos paramètres, et entraîner. Pour des gens ou des équipes qui n'ont pas le temps, ni l'envie, ni les compétences de coder des algorithmes de machine learning, c'est une solution intéressante. Pour des gens plus avancés, qui ont déjà développé du code MXNet, TensorFlow, etc., nous fournissons également des environnements préinstallés. Vous pouvez apporter votre script TensorFlow et l'exécuter sur SageMaker. Il y a aussi d'autres librairies comme PyTorch, Keras, etc., ou votre propre code maison, que vous pouvez également apporter sur SageMaker. Quelle que soit votre approche, que vous vouliez prendre un algo sur étagère, apporter du code TensorFlow ou MXNet, ou apporter n'importe quel code de machine learning, vous pourrez le faire sur SageMaker. La deuxième étape est la construction du modèle, qui comprend l'entraînement et l'optimisation des paramètres de training. L'entraînement lui-même ne pourrait pas être plus simple. Vous verrez le code tout à l'heure. C'est marqué « one click training » parce que les gens qui font les slides cliquent dans la console, mais c'est plutôt « one API call training ». On fait un appel d'API et on démarre un cluster de training complètement géré par SageMaker. Tout ce qu'on lui dit, c'est « Donne-moi 10 instances C5, X-large ». Il déploie ce qui doit être déployé, fait l'entraînement distribué et configuré, sauve le modèle dans S3, éteint les instances, et vous payez juste pour le temps de training. Vous pouvez créer à la demande des flottes d'instances qui vont faire le training, se terminer, sans aucune gestion de votre part. L'optimisation des hyperparamètres, qui a été en preview pendant un moment, est maintenant live. C'est la capacité, en exécutant un petit nombre de jobs automatiquement et en analysant les résultats, de vous recommander les paramètres optimaux pour votre job de training. Au lieu de faire ce qu'on fait tous depuis des années, comme augmenter un peu le learning rate, puis le diminuer, etc., on a un mécanisme de machine learning pour optimiser les jobs de machine learning. C'est un peu récursif, mais ça marche bien. La dernière étape est le déploiement, qui est paradoxalement la plus compliquée, en tout cas dans mon expérience passée. Tant qu'on est dans l'entraînement, on est dans sa sandbox, dans son environnement de data science, dev, test, et tout va bien parce qu'il n'y a pas d'enjeu de production. Dès qu'on déploie un modèle dans une application web pour servir des prédictions, on n'est plus dans le monde du machine learning, mais dans celui du web, de la prod, des ops, avec tous les problèmes qui vont avec, comme la disponibilité, la sécurité, la redondance, le monitoring, le redéploiement, etc. Vous pensiez peut-être que vous aviez signé pour un job de machine learning, mais vous vous retrouvez à faire du DevOps. L'idée ici est de vous permettre, avec un appel d'API, de déployer votre modèle sur une flotte de serveurs web avec une application web déjà existante, hébergée derrière un endpoint HTTP que vous pouvez utiliser pour faire vos prédictions. Pour vous permettre de dormir la nuit et de profiter des week-ends et des fêtes d'anniversaire, nous avons aussi de l'autoscaling. Cette flotte va croître et décroître au fil du trafic sans que vous ayez à recevoir des alertes SMS à 2h du matin. Sous le capot, ça marche avec Docker. Il y a trois catégories de gens : ceux qui disent « C'est quoi Docker ? » (pas grave, allez sur Docker.com, faites le tutoriel, une heure et vous êtes bon), ceux qui disent « Ah super, c'est du Docker ! », et ceux qui disent « Ah mince, Docker ! ». La bonne nouvelle, c'est que dans la grande majorité des cas, il n'y a vraiment pas besoin de savoir que c'est Docker qui est sous le capot. Seulement si vous voulez apporter votre propre algo ou votre propre code spécifique. Là, je vous montrerai plus tard comment le faire, et vous verrez que c'est assez simple. Le principe est que nous avons une collection de containers pré-construits, avec les algos built-in, l'environnement MXNet, l'environnement TensorFlow, etc., hébergés dans ECR. ECR est notre repository Docker au sein d'AWS, dans lequel tout ça est installé. Quand nous commencerons à coder des jobs sur SageMaker, ce que nous écrirons est ce qu'on appelle du helper code, parce que ce n'est pas vraiment du code de machine learning, mais plutôt du code qui va télécharger le dataset, sélectionner le bon container de training dans ECR, mettre les paramètres, etc., et dire ok, entraîne. Ce code est assez court, vous verrez, la plupart des notebooks sont assez simples et courts, parce que le machine learning, dans la majorité des cas, est déjà écrit par Amazon. Lorsque vous exécuterez ce code, SageMaker créera le nombre d'instances que vous lui avez demandé, mettra le bon container Docker sur ces instances, le fera pointer sur votre dataset dans S3, tout ça va tourner, et à la fin, vous aurez un modèle que vous sauvegarderez dans S3, éteindrez le cluster de training, et vous paierez juste pour le temps écoulé. Si vous voulez déployer, vous écrivez un tout petit peu de code pour déployer le modèle que vous venez d'entraîner, et idem, vous l'exécutez, et SageMaker créera votre flotte de prédictions, déployera le bon container, le modèle, créera l'endpoint HTTP, et vous pourrez l'invoker via vos applications pour servir des prédictions. Ce workflow est le fil conducteur que nous aurons dans tous les notebooks. Le code que nous écrivons est plutôt du code d'orchestration que du code de machine learning. Bien sûr, si vous voulez apporter votre propre code et l'injecter dans un container TensorFlow, vous pouvez le faire, vous pourrez apporter votre code TensorFlow, et nous verrons un exemple. Mais lorsqu'on travaille avec ces containers préconstruits, on n'écrit pas beaucoup de code. Voilà un peu l'architecture, et le point clé, bien sûr, est que tout passe par S3. Les données doivent être dans S3, et c'est dans S3 que vous irez récupérer votre modèle. Vous pouvez faire tout ce cycle, c'est-à-dire expérimenter sur la notebook instance, déclencher un training, déployer un modèle, etc. Ou vous pouvez découper le problème. Par exemple, si vous n'avez pas envie d'utiliser les notebook instances parce que vous avez vos serveurs de dev chez vous, vous pouvez travailler sur vos propres serveurs, déclencher des trainings dans AWS, etc. Si vous avez déjà un modèle entraîné et que vous voulez juste le déployer sur AWS, vous pouvez l'importer dans SageMaker et le déployer comme expliqué. Vous pouvez aussi entraîner un modèle dans SageMaker et le récupérer dans S3 pour le déployer sur vos machines, ne serait-ce que pour le tester dans votre environnement de test. Ce n'est pas une autoroute sans sortie, vous entrez où vous voulez, vous sortez où vous voulez. Si ça vous simplifie la vie de faire tout le chemin, c'est très bien. Si vous voulez rentrer à un endroit précis ou sortir à un endroit précis, c'est aussi bien. L'essentiel est que ça vous simplifie la vie. Quelques autres features récentes. Un feedback que nous avons eu très vite des clients est que pour les environnements TensorFlow et MXNet, ils disent : « C'est bien, mais nous travaillons déjà avec TensorFlow et MXNet, et nous n'avons pas envie d'être obligés d'utiliser SageMaker tout le temps. Nous voulons pouvoir utiliser exactement le même container que vous pour faire des tests localement, pour être sûr qu'il n'y a pas de rupture entre l'environnement de dev et l'environnement de prod. » Nous avons donc open sourcé ces deux containers. Vous pouvez les construire, les utiliser localement sur vos machines, sur la notebook instance, pour faire de l'expérimentation sans avoir à déclencher une flotte de training dans SageMaker. Cela simplifie un peu la vie et fait une petite économie, car si vous travaillez sur vos machines, vous ne payez pas de training SageMaker. Nous pouvons aussi, comme je l'ai dit, apporter son propre container. Nous avons un repo GitHub qui montre comment faire ça. Je vous montrerai des exemples plus tard. L'idée est que le travail à faire est vraiment l'intégration entre votre code et SageMaker. Il faut que SageMaker ait un point d'entrée précis à invoquer dans votre code, qu'il puisse récupérer les paramètres, etc. Nous vous fournissons un peu de glue pour faire tout ça de manière simple. Vous verrez l'exemple plus tard, il est assez simple. Nous avons parlé d'infrastructure ce matin, c'est vraiment un point essentiel. Sur les notebook instances, nous avons plusieurs tailles, mais gardez à l'esprit que la notebook instance sert vraiment à expérimenter, pas à faire le training à proprement parler, ni la prédiction. Vous pouvez avoir une notebook instance T2, prendre une très petite instance parce qu'elle va essentiellement appeler le SDK SageMaker. Pour vos flottes de training et de prédiction, nous recommandons deux familles d'instances : la C5, la dernière génération Intel avec l'architecture Skylake et le jeu d'instructions AVX512, qui permet un parallélisme hardware sur l'algèbre linéaire et les multiplications de matrices, que nous faisons beaucoup en machine learning et deep learning. Vous avez une accélération avec les C5 qui est vraiment spectaculaire et qui peut même vous dissuader d'utiliser des GPU dans certains cas. La famille P3, la dernière famille GPU avec les Nvidia V100, de 1 à 8, offre une puissance spectaculaire, même pour un seul GPU, beaucoup plus puissant que la génération précédente, P2. Vous pouvez en avoir jusqu'à 8, donc un nombre de cœurs phénoménal, une puissance phénoménale. Mon conseil est de vérifier le prix. La P3 16 XL coûte environ 33 dollars de l'heure en on-demand. Faites du spot aussi. Même avec la plus petite P3, j'ai eu un speed-up incroyable par rapport au P2 sans rien changer à mon code. Ce sont vraiment des machines de guerre, mais n'oubliez pas d'essayer les C5 sur des datasets de taille moyenne, qui ne sont pas forcément des méga datasets d'images ou de vidéos. Vous pouvez avoir des temps de training et de prédiction parfaitement acceptables sur ces C5, à un coût plus intéressant. Un exemple de client est Digital Globe, une société qui opère des satellites d'imagerie autour de la Terre. Ils ont plus de 100 pétabytes de stockage. Ils sont le premier client de Snowmobile, un camion rempli de baies de stockage qui peut contenir jusqu'à 100 pétabytes. Ils l'ont utilisé pour transporter leurs données vers S3. Ils utilisent énormément SageMaker, car ils ont besoin de faire des analyses à l'échelle d'images satellites. Par exemple, ils offrent des services d'imagerie aux entreprises, organisations, et gouvernements. Ils font de l'analyse à l'échelle d'images satellites, comme compter les avions sur un tarmac, identifier le type des avions, etc. Quand on a 100 pétabytes de stockage dans AWS, on essaie d'optimiser sa facture. Ils se sont dit qu'il était exagéré de tout garder dans S3, car certaines images sont très fréquemment accédées et d'autres pas du tout. Ils ont construit un modèle avec SageMaker et l'aide de notre ML Lab pour prédire si une image doit rester dans S3 ou être mise dans Glacier, notre service d'archivage. Ils estiment qu'ils vont économiser environ 50% de leur facture S3 sur un projet récent. C'est un projet de machine learning très rentable. C'est intéressant de voir ce double usage, à la fois métier et interne pour l'optimisation et la rationalisation de l'infrastructure. Beaucoup de gens pourraient s'en inspirer. Bon, assez parlé, passons aux démos. Nous allons commencer avec un premier algo, K-Means, un algorithme de clustering. K-Means est un algorithme auquel vous donnez un ensemble d'échantillons, et il les groupe en 5, 10, 100 groupes, etc. Il regarde les features et essaie de regrouper les échantillons de manière intelligente. Nous allons aller lentement sur celui-là, puis j'accélérerai, et vous crierez si ça va trop vite. Comme c'est le premier, nous allons y aller doucement. Voici un notebook Jupyter. Je suis sur une notebook instance que j'ai créée dans SageMaker. Tous ces notebooks sont disponibles sur GitHub, vous aurez l'URL à la fin. J'ai besoin de créer un bucket dans S3 où je vais télécharger mes données, sauver mon modèle, etc. C'est le seul truc qu'il faut modifier dans les notebooks. Je vais essayer de clusteriser un dataset que tout le monde connaît, MNIST. C'est un dataset d'images de chiffres manuscrits entre 0 et 9. Le but est de regrouper les 0, 1, 2, 3, etc. Nous allons essayer de regrouper ces images avec K-Means en 10 groupes. La première étape est de télécharger le dataset. Nous téléchargeons MNIST depuis Internet. Il n'est pas tout à fait au format images ici, mais en format sérialisation Python, car je vais les traiter comme des vecteurs. Les images ont été aplaties pour former des vecteurs à une seule dimension. J'ai donc 60 000 vecteurs, et chaque élément des vecteurs est la valeur des pixels des différentes images. On peut inspecter un vecteur donné, l'afficher sous forme d'image, et on voit que c'est un 3. C'est un 3 moche, mais c'est un 3. À ce stade, j'ai mon dataset. J'ai 60 000 ou 70 000 images, donc 70 000 échantillons, 70 000 vecteurs qui représentent mes images aplaties. Il faut que je définisse où je vais les mettre dans S3, où je vais stocker mon modèle, etc. On définit tout cela avec du Python. On sélectionne l'objet K-Means du SDK SageMaker, on lui dit de faire le training sur deux instances de type C4-8XL, de stocker le modèle à l'endroit défini, de prendre les données à l'endroit défini, et de faire dix clusters. C'est tout ce qu'il y a à faire pour configurer un job de clustering avec K-Means en training distribué sur deux instances. Ensuite, on fait fit, et ça déclenche le training. Il n'y a pas une ligne de machine learning dans cette histoire. On sélectionne un algo, on passe les données, on passe les paramètres, et on entraîne. On voit le log de training, qui se termine après 4 minutes 23, et vous payez 4 minutes 23, car c'est facturé à la seconde. À ce stade, vous avez votre modèle dans S3. Si vous voulez le récupérer et le déployer sur votre laptop, il est facile à récupérer. C'est un modèle MXNet. Si on veut continuer et déployer, le cauchemar de développer une application web, la déployer sur vos serveurs, gérer le load balancing, la sécurité, etc., se résume maintenant à une ligne de code où on dit de déployer le modèle sur une M4XLarge. Ça prend 5 minutes 17, et vous avez un endpoint HTTP sur lequel vous pouvez poster vos données et récupérer vos prédictions. Dans la console SageMaker, on voit l'URL HTTP de ce service. On peut aussi l'appeler avec le SDK SageMaker, en faisant un HTTP post sur l'endpoint pour prédire des valeurs. L'objection à ce stade est que vous pouvez faire ça sur Scikit-learn en cinq lignes. Absolument, vous pouvez le faire sur Scikit-learn en cinq lignes, mais la différence est que si j'avais besoin de faire ça sur un pétaoctet de données, j'aurais mon pétaoctet de données dans S3, et au lieu de prendre deux instances, j'en prendrais 100, et ça marcherait pareil. Je n'aurais pas à me soucier du scaling de mon infrastructure. Sur des petits datasets, des petites échelles, je peux le faire sur mon Mac, mais à grande échelle, les vrais problèmes commencent. Ici, si vous voulez scaler, le seul truc que vous allez scaler, c'est ça. Vous lui dites, allez, hop, 100, et si vos limites AWS le permettent, c'est parti. C'est assez sympa, à mon avis. Une fois déployé, on peut faire des prédictions, afficher les clusters, etc. Voilà un premier exemple. Tous les built-in algos fonctionnent de cette façon. Vous choisissez un container, vous dites où sont vos données, vous positionnez les paramètres pour le job, vous sélectionnez l'infrastructure dont vous avez besoin, vous appelez « fit », ça entraîne, vous récupérez le modèle, vous appelez « deploy », ça déploie. Pas plus compliqué que ça. Deuxième exemple. Si vous faites du vrai machine learning avec TensorFlow, vous avez déjà votre code, comment on fait ? Nous allons voir comment. Nous allons toujours travailler avec MNIST, mais cette fois, nous utiliserons un script TensorFlow pour faire une vraie classification d'images avec un réseau à convolution dans les dix catégories de 0 à 9. Ça commence toujours de la même façon. Il faut télécharger le dataset. Je le télécharge sur ma notebook instance, puis je le mets dans S3, car il faut que ça soit dans S3. En pratique, vos données seraient déjà dans S3, car vous faites déjà des choses sur AWS. Et puis après, vous prenez votre script Python ici, de TensorFlow. Si vous faites déjà du TensorFlow, ça va vous parler. Ok ? Défini un réseau à convolution qui sait classifier les images, il n'est pas très compliqué. Et ce code-là, il marcherait sur votre machine, il marcherait sur votre laptop. Les seules modifs qu'il faut faire, c'est qu'il faut que la fonction qui fait l'entraînement ait un nom conventionnel, défini par SageMaker, parce qu'il faut que SageMaker sache comment invoquer cette fonction, il faut qu'elle s'appelle modèle FN, quelle est cette tête-là, etc. C'est ça qui va permettre à SageMaker de savoir ce qu'il faut appeler, c'est ça qui va lui permettre de vous passer les hyperparamètres que vous aurez positionnés, etc. C'est juste un nom conventionnel pour que SageMaker sache comment appeler ce code-là. Le deuxième truc, c'est si vous voulez vous servir du même code pour faire du training et de la prédiction, il faut gérer ce genre de choses-là, en disant dans quel mode on est. Si le même code peut être invoqué par SageMaker pour faire du training ou de la prédiction, il faut qu'il y ait un petit flag qui vous dise quel est le code qu'il faut exécuter. Si vous avez des codes séparés, vous pouvez utiliser vos codes séparés. Le résumé de cette histoire, c'est qu'en gros, vous prenez votre code TensorFlow standard, vous faites juste cette petite adaptation pour que SageMaker sache ce qu'il faut appeler, et ensuite c'est parti. Et alors à quel point c'est compliqué de faire du training distribué avec TensorFlow sur SageMaker ? C'est compliqué comme ça. Vous utilisez l'objet TensorFlow du SDK SageMaker. Votre script qu'on vient de voir, ça devient un paramètre. Vous choisissez l'infrastructure sur laquelle vous l'entraînez, vous appelez fit, bam, c'est parti. Donc, pas très compliqué à mon avis. Le training log, qui est aussi disponible dans CloudWatch Logs, bien sûr, ce SDK SageMaker, vous allez l'utiliser sur les instances notebook, mais vous allez l'utiliser dans du vrai code Python de production, il n'y a pas toujours quelqu'un qui va cliquer dans un notebook, vous allez exécuter du code automatiquement aussi. Donc ce log, il est dans CloudWatch Logs, vous pouvez le récupérer. Il est streamé dans CloudWatch Logs au fil du training. Tout ça, ça se termine. Youpi, job complete. SageMaker arrête les instances, vous arrêtez de payer. Le déploiement, non, pas trop compliqué. On fait deploy avec le nombre de serveurs qu'on veut et c'est parti. Et là, une fois de plus, on a un endpoint HTTPS qu'on peut invoquer et sur lequel on peut faire des prédictions, comparer au label et vérifier que ça marche bien. Donc vous voyez, l'effort d'intégration d'un code externe est assez faible. Alors, par souci d'équité, on va regarder rapidement la même chose avec MXNet, autre librairie open source de deep learning. Ici, on ne va pas faire de la classification d'images, on va faire de l'analyse de sentiments sur un dataset qui est un dataset assez simple de critique de film. C'est simple, c'est une ligne par critique et puis elle est positive ou négative. Donc, Same player shoot again, on download le dataset, on le met dans S3, on amène son script MXNet. Alors pareil, il faut qu'on ait un prototype, une signature de fonction de training bien définie, parce que c'est ça qui vous permet de récupérer les hyperparamètres, etc. C'est vraiment l'interface entre SageMaker et votre code. Tout le reste est absolument identique. Ça, c'est du code un peu plus compliqué, on ne va pas le regarder. Comment est-ce qu'on l'exécute ? Pareil, cette fois, l'objet s'appelle MXNet, il ne s'appelle pas TensorFlow. On passe le script en paramètres, on dit combien on veut d'infra, on passe des hyperparamètres spécifiques à votre script, c'est ça qui va être passé à votre fonction de training, on appelle fit et c'est parti. Pareil, training log, et puis après on peut prédire, on prend des avis sur des films d'une ligne, on les passe au modèle, on prédit, un c'est positive, 0, c'est négatif. Donc, vous voyez, le ticket d'entrée de SageMaker pour du code déjà écrit, il est vraiment, vraiment faible. Ce n'est pas une réécriture, c'est les mêmes API, c'est le TensorFlow standard, c'est le MXNet standard. Vous adaptez juste l'interface de votre code à celle de SageMaker pour qu'il puisse l'invoquer correctement. Ok, ça marche. Allez, on respire. Ça va ? Personne n'est bleu encore ? Veillez sur votre voisin, s'il s'écroule, levez la main. On est tous des amis ici. Alors généralement, à ce stade, quelqu'un me dit « Non mais d'accord, mais moi je ne fais ni du TensorFlow, ni du MXNet, ni des algos built-in. » Non, j'ai mon code ou j'ai une autre librairie. Alors comment on fait ? Alors j'ai deux exemples, je pense qu'on a le temps de faire les deux. J'ai un exemple avec Keras et j'ai un exemple avec PyTorch, comme ça personne ne sera frustré. Qui utilise Keras ? C'est toujours intéressant de faire un sondage. Qui utilise PyTorch ? Ah c'est Keras qui a la vente aujourd'hui. C'est intéressant, ok. Alors Keras c'est une autre librairie, librairie de deep learning, qui est une librairie d'assez haut niveau et qui a l'intérêt de pouvoir être utilisée avec différents back-ends, comme TensorFlow, comme Theano, qui est sans doute un peu moins utilisée maintenant, et comme MXNet. Et nous, on aime bien l'utiliser avec MXNet parce que c'est notre librairie préférée et il se trouve qu'elle a tendance à être beaucoup plus rapide que les autres, donc c'est un avantage. Donc ici, on va construire un container, on va construire notre propre container Docker, qu'on va pousser dans ECR et qu'on va utiliser sur SageMaker. Alors on va le faire avec MXNet, on va regarder PyTorch, il n'y a pas beaucoup de différence, mais en gros vous pourriez le faire avec n'importe quoi, c'est-à-dire même si vous avez du code custom C++ que votre boîte a développé depuis dix ans, ça marche. Vous n'êtes pas obligé d'utiliser Python et vous n'êtes pas obligé d'utiliser une librairie open source. N'importe quel code peut s'inscrire dans ce schéma. Alors, qui dit container dit Dockerfile. Alors, les gens qui ne connaissent pas Docker, pas de soucis. Vous allez voir, c'est vachement simple. Donc, ce fichier, il va me permettre de construire le container que je vais exécuter sur SageMaker. Donc le point de départ ici, ça va être une image Ubuntu qui existe, parce que je n'ai pas envie de réinventer la roue. Donc je pars d'une image Ubuntu, je mets à jour les packages, j'installe quelques dépendances pour MXNet, je m'assure d'avoir un Python 3 à jour, etc. Ensuite, je prends mon code, qui va être mon code Keras ici, qui est vraiment le tuto MNIST de Keras. Je le copie à l'intérieur du container et je le copie avec un nom conventionnel qui est train. C'est ce nom de script que SageMaker va chercher à invoquer. Je le rends exécutable. Je copie le fichier de configuration de Keras pour lui dire s'il te plaît, utilise MXNet comme back-end. Ensuite, j'installe MXNet, j'installe Keras, je nettoie un peu les cochonneries pour avoir un container pas trop gros, et c'est tout. Donc ça, ça construit mon container. Alors vous voyez qu'il s'appelle dockerfile.cpu, parce que là c'est la version MXNet qui tourne sur CPU. Si je voulais la version qui tourne sur GPU, je l'ai fait aussi. La différence c'est que cette fois je pars d'une image d'NVIDIA, histoire d'avoir toutes les librairies et tous les drivers. En gros je fais la même chose, et j'installe la version de MXNet qui supportent CUDA 9, qui est la dernière version de CUDA. Elle supporte aussi le CPU. L'avantage d'avoir deux containers, c'est que le container CPU est nettement plus petit. De mémoire, il doit faire à peu près 1 giga, quelque chose. Celui-là, il fait 2 gigas, 3. C'est un peu plus lourd et il n'y a pas de raison d'utiliser ce container-là si on n'en a pas vraiment besoin. Ensuite, on va créer un repository dans ECR, c'est là qu'il va falloir que je pousse mes containers. Donc là j'utilise... C'est un peu plus bas, pardon. J'utilise la ligne de commande AWS pour créer un repository s'il n'existe pas. Je me connecte à ce repository. Je construis mon container. Ça ne prend même pas une minute. Et après je le pousse. Et là, Ça, c'est des commandes Docker standards. Ça va prendre le container que je viens de construire sur ma notebook instance et ça va le pousser dans ECR. Ce container a un script qui s'appelle train, qui est au bon endroit et qui va faire le boulot. C'est tout ce que SageMaker demande. Une fois qu'on a fait ça, une fois qu'on a fait ce container, c'est business as usual, comme on dit en bon français. Je vais mettre MNIST dans S3. Et je ne vais pas utiliser un objet MXNet, je ne vais pas utiliser un objet TensorFlow, parce que là, c'est mon propre container. Donc j'utilise un autre objet du SDK qui s'appelle estimator, et qui est, on va dire, l'objet générique, qui va me permettre de spécifier le nom du container que je viens de pousser dans ECR. Donc c'est là que je dis, voilà, tu prends le mien. Le reste, c'est pareil, le nom de data, le chemin, etc. Donc je passe mes hyperparamètres. Dans mon code Keras, j'ai rajouté quelques lignes pour aller récupérer ces paramètres. C'est toujours pareil, il y a un petit peu d'adaptation entre votre code et SageMaker, mais franchement, ça fait pas mal à la tête. Et puis après, je lance le training. Et je vois quoi ? Je vois Keras qui démarre avec le back-end MXNet. Je vois que j'ai bien récupéré mes hyperparamètres. Si vous êtes familier de Keras, vous allez reconnaître le log Keras. Sa machine, voilà. On arrive à la fin. 99,17% d'accuracy, c'est pas mal. Je sauve mon modèle, donc il est dans S3, c'est un modèle Keras, tout ce qu'il y a de plus normal. Et je le vois ici, je peux le lister, je peux le récupérer, le réimporter sur ma machine. Donc vous voyez, il n'y a vraiment pas de difficulté à utiliser une autre librairie ou même un code complètement spécifique. A partir du moment où vous respectez les quelques conventions, il n'y a pas de gros problème. PyTorch, j'ai dit que je le montrais, je le montre, c'est la même chose. Là, j'ai un unique Dockerfile, j'ai une seule version qui fait CPU, GPU. Vous voyez que c'est vraiment la même chose, j'ai été fainéant, j'ai vraiment fait du copier-coller. Je crois que la seule chose que j'ai changé, c'est... Effectivement, j'installe PyTorch et TorchVision, mais tout le reste est absolument identique. Vous voyez, ça montre que le processus n'est pas du tout spécifique. Je crée un repository, je construis mon image, je pousse mon image, et c'est reparti pour un tour. Je mets MNIST dans S3 pour la millionième fois. Ce call-là, je crois qu'il est strictement identique. J'utilise l'estimator, cette fois. Une fois de plus, je passe le nom de l'image que je viens de pousser, l'image PyTorch, et puis c'est parti pour un tour, je traîne, et là, ceux qui connaissent PyTorch vont reconnaître le log PyTorch. Ça a duré 178 secondes, donc je paye pour ça, et à la fin, j'ai mon modèle PyTorch en S3, qui est un modèle standard et que je peux utiliser. Donc on peut tout amener sur SageMaker, pas de difficultés. Un dernier, quand même. Alors il y a un autre SDK dans SageMaker qui est un SDK Spark. Tout ce que je vous ai montré là, c'est avec le SDK SageMaker qui est un SDK Python que vous pouvez utiliser sur les Notebook Instance ou sur vos machines, etc. Mais si vous utilisez Spark, il y a des gens qui utilisent Spark dans la salle ? Ah, c'est bien ! En Python ? Ah là, vous me décevez. Il y a des Scala. Il ne faut pas que je dise des bêtises. Il est fan de Scala dans la salle. Vous allez voir un peu de Scala quand même. L'avantage de combiner Spark et SageMaker, c'est que vous avez un peu le meilleur des deux mondes. Je m'explique. Spark, c'est une machine à trier, à agréger, à nettoyer les données. Et ça sait faire ça super rapidement par rapport à Hadoop, que j'espère tous oublier. Donc, probablement dans votre chaîne, dans votre workflow de machine learning, vous allez chercher des données dans un back-end, ça peut être S3, ça peut être RDS, ça peut être Hive, vous avez sûrement plein de sources de données, vous allez piocher des données, et puis il faut les normaliser, les nettoyer, rajouter les valeurs manquantes, enfin bref, il y a beaucoup de travail de préparation, et il se trouve qu'il y a beaucoup de gens qui aiment faire ça sur Spark. Bon, très bien, donc on crée un cluster EMR, j'en ai un là, on crée un cluster EMR, il ne fout rien, mais enfin bon, c'est pas grave, il a vaguement travaillé tout à l'heure, oui un petit peu quand même ? On crée un cluster EMR avec Spark et puis on fait tout ça. Et il se trouve que dans Spark, il y a une très bonne librairie de machine learning qui s'appelle Spark ML Lib, qui a une belle collection d'algorithmes, etc. qui est un super truc. Mais il n'est pas dit que vous ayez besoin du même type d'instance pour faire le nettoyage, l'ETL, etc. et le training. Imaginez que vous prépariez des données d'imagerie, etc. Vous pouvez faire ça avec des C5, ça marchera très bien. Mais pour entraîner votre modèle de deep learning, sûrement vous avez besoin de GPU. Alors vous pourriez vous dire, je vais faire un cluster Spark avec des instances GPU, on a le droit de faire ça, c'est supporté. Oui, mais alors du coup, ce n'est pas forcément les meilleures instances pour faire de l'ETL et de l'IO. Vous voyez ce que je veux dire ? Donc, plutôt que de courir après ce problème, vous séparez les sujets, vous gardez un cluster pour faire de l'ETL avec le meilleur type d'instance, le bon sizing, etc. Et puis, quand vous en avez besoin, vous démarrez du training, voire même de la prédiction sur SageMaker avec le bon type d'instance. Donc vous séparez ces problèmes-là et vous scalez séparément, ce qui est toujours une bonne pratique, de séparer les problèmes et de les scaler séparément. Alors, on va voir comment ça peut se passer. Ici, je suis sur mon cluster EMR et j'utilise un autre notebook qui s'appelle Zeppelin. Et ici, on fait du Python, mais vous verrez que le prochain exemple est en ce cas-là. Donc, vous ne serez pas fâchés. Donc, j'importe le SDK. Je définis deux, trois trucs. Alors ici, on va utiliser XGBoost, qui est un classifieur open source. On va classifier MNIST avec ce classifiant. Et on va le faire sur SageMaker. Pour l'instant, je travaille sur mon cluster Spark. Je télécharge sur mon cluster Spark depuis S3, je télécharge Mnist. Et si c'était un jeu de données un peu plus compliqué qu'Mnist, c'est là que vous auriez envie de faire de l'ETL, de l'agrégation, etc., en utilisant tous les super mécanismes qui permettent de faire ça dans Spark. Ici, j'ai juste à est chargé. Regardez-moi ça si ce n'est pas magnifique. Vous faites ça, vous créez un estimateur SageMaker basé sur XGBoost, vous lui passez en une fois l'infra de training et l'infra de prédiction. Vous positionnez deux trois paramètres, donc MultisoftMax pour lui dire on veut faire du multiclasse, ici on veut classer en dix classes. Il y a dix classes et vous appelez fit et ça, ça va démarrer, vous demandez à SageMaker de démarrer ici une instance M4XLarge pour le training. Donc ça, ça va marcher comme on a vu tout à l'heure, c'est SageMaker qui va gérer cette instance. Elle va faire le training, elle va retourner, elle va le déployer, ici on fait tourne une fois, donc elle va faire le training, elle va le déployer à nouveau sur une autre M4XL. Donc vous récupérez ce modèle-là dans Spark sans aucune autre forme de procès. Il n'y a pas de conversion de données, il n'y a pas de plomberie. Vous appelez fit et vous récupérez le modèle. Et puis ensuite, avec ce modèle-là, vous prédisez. Vous transformez les données comme vous le feriez dans Spark normalement et vous récupérez vos prédictions. Donc vous utilisez SageMaker comme fournisseur de training et de prédiction, une fois de plus, en spécialisant vos instances. Et en n'étant pas obligé de surdimensionner un cluster Spark parce que vous allez faire du training ou de la prédiction avec. Donc, une fois de plus, on a des problèmes orthogonaux et on les traite de manière orthogonale. Un dernier dernier, avant que je me sauve, et que votre tête explose, Dans Spark ML Lib, il y a un super mécanisme qui s'appelle les pipelines. Les pipelines, ça permet de définir des étapes, des étapes de traitement que vous combinez. C'est un pipeline. Et on peut avoir dans ce pipeline un mélange d'étapes Spark et d'étapes SageMaker. Donc ici, on va faire deux choses. On va utiliser un algorithme qui s'appelle PCA, qui est un algorithme qui réduit le nombre de features. Vous partez d'un très grand nombre de features et vous lui dites non, non, calcule-moi un plus petit nombre de features. Ça permet d'avoir des temps de training réduits, d'éliminer les features redondants, etc. Donc un algorithme qui s'appelle PCA et qui existe dans Spark ML Lib. Donc c'est celui que j'utilise. Donc je lui dis, ok, voilà, tu me crées une étape PCA, voilà la colonne que tu dois analyser, voilà la colonne que tu dois produire, et donc tu dois me construire 50 nouveaux features à partir des features initiaux. Et puis sur ça, je vais utiliser K-Means, notre algo de clustering qu'on a vu tout à l'heure, et je vais le faire sur SageMaker. Donc on définit une étape sur SageMaker, où on dit, tu prends le SageMaker estimator, voilà les nouvelles features que tu dois clusteriser, donc ceux qui ont été produits par PCA, et puis tu vas faire ça, tu vas faire le training sur une P2 et tu vas faire le déploiement sur une C4, tu me construis dix clusters, etc. Donc tu pars de 50 features, tu me fais dix clusters. Vous construisez le pipeline ici, on combine d'abord PCA puis K-Means, on fait fit et tout ça, ça tourne tout seul. Et le passage de données entre Spark et SageMaker, tout ça se fait complètement automatiquement. Vous n'avez jamais de conversion de données à faire. Et à la fin, vous pouvez prédire. Et donc, on voit les features originaux d'MNIST, les features calculées par PCA, et puis ensuite, la clusterisation faite par K-Means. Ignorons les détails. Je voulais vraiment vous montrer ça. Parce que pour les utilisateurs de Spark, c'est à mon avis un cas d'usage super intéressant, de dire je sépare la partie ETL, préparation de données, de la partie machine learning. Et à mon avis, je fais des économies en faisant ça, parce que je vais pouvoir réduire la taille de mon cluster Spark, et je vais pouvoir choisir le type d'instance qui est vraiment adapté à l'ETL, et sans être pollué entre guillemets, par des objectifs de machine learning. Voilà, j'en ai fini. Quelques liens pour aller plus loin. Donc la page SageMaker sur le site AWS. À peu près tous les exemples que je vous ai montrés sont sur le GitHub AWS. Il y en a plein d'autres, je vous incite à aller les voir. Le SDK Python que j'ai utilisé au début, le SDK Spark que j'ai utilisé à l'instant, Et puis mon blog sur Medium avec pas mal d'articles, machine learning, deep learning, SageMaker, des exemples supplémentaires. Pas mal de vidéos sur YouTube aussi si vous voulez continuer à creuser. Et puis quelques-uns des exemples que je vous ai montrés sont sur mon propre repository qui est désormais sur GitLab. Et donc, à chaque fois que je dis ça, j'ai des tweets haineux, alors c'est pas grave, j'assure. Et si vous voulez rester en contact, n'hésitez pas. Si vous avez des questions, la meilleure solution pour me contacter, c'est certainement Twitter. Et je suis évidemment ravi de me connecter sur LinkedIn. Voilà, merci beaucoup et bonne fin de journée.