AWS EarthCube Deep learning demarrer avec MXNet et Tensorflow en 10 minutes

Transcript

Bonjour à tous. Merci de participer à cette session. Je m'appelle Julien, je fais partie de l'équipe d'évangélistes techniques d'AWS et je me concentre sur l'IA et le machine learning. Aujourd'hui, je suis accompagné par Renaud, qui est là, et qui nous parlera tout à l'heure de comment EarthCube utilise le deep learning sur AWS. Merci. Je pense qu'à ce stade de la journée, vous avez déjà vu cette présentation et en tout cas ce slide plusieurs fois. C'est l'ensemble des services d'IA et de Machine Learning d'AWS qui sont organisés en trois couches : une couche de haut niveau avec des services d'API qui ne nécessitent aucun entraînement. Vous vous contentez de les appeler, de passer vos données et, dans la plupart des cas, en temps réel, vous recevez une réponse. Donc pour de l'analyse d'images, du text-to-speech, du speech-to-text, etc. Mais bien sûr, lorsqu'on a envie d'entraîner ses propres modèles avec son propre jeu de données, d'amener son propre code de deep learning en particulier, il faut descendre d'un niveau et travailler dans cette couche intermédiaire qui est organisée autour d'un service qui s'appelle Amazon SageMaker, qui est un service de machine learning managé. Ce service va vous permettre d'entraîner aussi bien des algos sur étagère que votre propre code de deep learning, sans jamais avoir à vous occuper du moindre serveur. C'est là qu'on va travailler aujourd'hui. Et bien sûr, si vous avez envie ou besoin de gérer vos propres instances, EC2, et de contrôler exactement la façon dont l'infrastructure se comporte, vous pouvez aussi travailler au niveau le plus bas avec des instances EC2 et différents outils dont on va un peu parler. Le premier point qui est important, c'est que même si on va parler de TensorFlow et de MXNet, on est vraiment complètement agnostique vis-à-vis de ces frameworks. On n'a pas de préférence particulière et on s'assure que nos clients puissent utiliser n'importe lequel de ces frameworks dans les meilleures conditions possibles. Donc on les optimise, on en parlera un peu tout à l'heure, pour que vous ayez la meilleure performance et le meilleur rapport coût-performance avec ces différents services. Et puis bien sûr, on vous laisse le choix, le choix est essentiel pour vous, soit d'utiliser ces frameworks de manière managée, donc avec un service comme SageMaker, soit de tout faire tourner vous-même, comme je disais tout à l'heure, d'utiliser des instances EC2 et de gérer exactement la façon dont l'infrastructure d'entraînement ou l'infrastructure de prédiction est construite. Nous, on n'a pas de préférence, on travaille sur tous ces angles en même temps. Si vous voulez utiliser de l'infrastructure managée, si vous voulez vraiment concentrer 100% de vos efforts sur du machine learning, le service Amazon SageMaker est sans doute celui qui vous plaira le plus. C'est un service qui vous permet sans rupture de passer de l'expérimentation à l'entraînement, au déploiement, à n'importe quelle échelle, sans jamais avoir à gérer la moindre infrastructure. Donc 100% de votre énergie et de votre temps est passé sur la construction du modèle, le choix des paramètres, l'optimisation du modèle, et vous laissez SageMaker piloter, gérer complètement l'infrastructure. C'est un service qui est utilisé par de nombreux clients aujourd'hui, et on trouve aussi bien des startups que des grands comptes. Je peux vous donner l'exemple d'Intuit. Intuit, c'est une société qui fournit des services financiers à ses clients. Ils ont utilisé SageMaker pour créer un modèle qui va analyser les relevés bancaires des entreprises et marquer des dépenses qui sont déductibles et qui n'auraient peut-être pas été identifiées par la société. Et en moyenne, avec cette fonctionnalité assez simple, ils font économiser plus de 4000 dollars par mois à chacun de leurs clients. Voilà un exemple d'utilisation de machine learning avec SageMaker. Si vous voulez construire vous-même votre infrastructure d'entraînement et de prédiction, vous avez un ensemble d'instances EC2 à votre disposition. Et on a aussi construit une AMI, donc une image machine, le fichier qui nous sert à construire les machines virtuelles EC2, et ce qu'on appelle la Deep Learning AMI. Cette Deep Learning AMI regroupe la plupart des librairies de Machine Learning et Deep Learning Open Source dont vous aurez besoin. Donc toute cette liste-là, plus les drivers NVIDIA pour les instances GPU, et encore d'autres outils. L'idée est vraiment de vous mettre à disposition une AMI que vous pouvez démarrer en quelques clics et qui vous permet de travailler sans avoir à commencer à installer toutes ces différentes librairies et à perdre du temps avec ça. Et il y a littéralement quelques jours, on vient d'annoncer un peu la même chose mais sous forme de containers. C'est ce qu'on appelle les Deep Learning Containers. Ils sont disponibles pour l'instant pour TensorFlow et MXNet, et PyTorch va arriver rapidement. Donc pareil, des containers pré-construits, pré-optimisés que vous pouvez exécuter sur les différents environnements de containers qui sont disponibles sur AWS ou sur EC2 si vous voulez gérer Docker vous-même. Quelques mots sur TensorFlow. TensorFlow est un projet open source, c'est une librairie de machine learning au sens large. La plupart des gens s'en servent pour du deep learning. Son API principale est en Python, même si aujourd'hui elle ajoute progressivement du support pour d'autres langages. Quand je parle de support expérimental, simplement pour préciser que l'API en fonction des langages n'est pas forcément complète ou pas forcément complètement testée. Donc en fonction du langage que vous voulez tester, vous pouvez avoir soit toutes les fonctionnalités, soit une partie des fonctionnalités. L'API la mieux supportée, évidemment, est Python. Ce qui est intéressant dans TensorFlow, c'est qu'on a un ensemble d'objets qui nous permettent rapidement de construire des architectures neuronales de tout type. Donc on a envie de faire des réseaux classiques, full et connected, ou des réseaux à convolution ou des réseaux récurrents, on a tout ça prêt et donc on n'a pas besoin d'aller écrire énormément de code pour concevoir tout ça. On peut aussi exécuter le processus d'entraînement de deux façons : soit de manière symbolique, c'est-à-dire on définit tout le réseau neuronal, on l'optimise et ensuite on l'entraîne, mais on l'entraîne un peu en boîte noire, ce qui veut dire que le diagnostic est compliqué, mais on a de bonnes performances. Ou alors, depuis quelques versions, on peut utiliser le mode impératif où là, on va pouvoir, pendant le processus d'entraînement, inspecter le réseau, mettre des breakpoints si on a envie, modifier le réseau dans certaines architectures innovantes, on peut avoir envie de faire ça. Et on paye une petite pénalité de performance. Donc on peut combiner les deux, on peut utiliser le mode impératif lorsqu'on expérimente et le mode symbolique lorsqu'on fait de la production. Et puis, on a évidemment Keras, qui est une API de haut niveau, qui a été rajoutée au-dessus de TensorFlow et d'autres back-ends, et qui rend encore plus simple la construction, l'entraînement de modèles. C'est sans doute aujourd'hui la librairie la plus accessible et la plus populaire pour apprendre le deep learning. Donc on a beaucoup, beaucoup de clients qui font du TensorFlow sur AWS, peut-être parce qu'il y a 80%, 85% des workloads TensorFlow dans le cloud qui tournent sur AWS. Donc on a été un peu surpris quand on a découvert ce chiffre, et donc on a jugé qu'évidemment ça nous donnait une espèce de responsabilité à ce que TensorFlow tourne le mieux possible sur AWS. Voilà un exemple d'optimisation qui est menée par nos équipes. Ici, on a pris une architecture de deep learning, qui s'appelle ResNet 50, qui est un modèle de classification d'images. On l'a entraîné sur un gros dataset qui s'appelle ImageNet. Et on a comparé la version TensorFlow de base, non optimisée, celle que vous pouvez trouver partout, et notre version. On s'est rendu compte sur la même instance, donc ici une instance C5, basée sur les derniers Intel Skylake, que notre version était 11 fois plus rapide. Ça c'est un benchmark qui a à peu près 6 mois, et donc on continue à faire ce travail de fond sur les frameworks, pour s'assurer qu'il fonctionne au mieux sur les différents types d'instances qui sont disponibles sur AWS. On a aussi travaillé sur les instances GPU. On a des gros clients, des clients qui utilisent des centaines de GPU, et on s'est rendu compte que la version standard de TensorFlow ne scalait pas linéairement avec 256 GPU, ce qui veut dire concrètement que lorsqu'on double le nombre de GPU utilisé sur un entraînement, et bien à partir d'un certain moment, on n'a plus ce facteur d'accélération x2, donc la courbe d'accélération s'aplatit et c'est embêtant parce que ça veut dire qu'une grosse partie des GPU qui sont utilisés ici ne servent à peu près à rien et donc c'est une dépense inutile. Donc on a réglé ce problème, on a remodifié le code GPU de TensorFlow. Donc maintenant, la version que vous utilisez, que ce soit sur SageMaker, sur la Deep Learning AMI ou sur les Deep Learning Containers, elle va scaler quasiment idéalement jusqu'à 256 GPU. Donc cette fois, si on double le nombre de GPU, on a quasiment jusqu'à 256 GPU le temps de training qui est divisé par deux. Donc concrètement, ça veut dire qu'un ResNet 50 entraîné sur ImageNet, donc des millions d'images, on va passer de 30 minutes à 14 minutes. Et quand on a des clients, Renaud vous l'expliquera tout à l'heure, quand on a des clients dont les temps d'entraînement sont en semaine, vous vous rendez compte que ce genre d'optimisation est très significatif. Un petit mot rapide sur MXNet. MXNet est une autre librairie de deep learning. Elle a l'avantage d'être implémentée nativement en C++, et donc son API native est en C++. Ce qui veut dire que, par défaut, par construction, elle est vraiment extrêmement rapide. Elle aussi, elle a tout un tas d'objets et d'API qui vous permettent de construire tout type d'architecture. Elle supporte davantage de langages, mais de manière un peu plus couvrante que TensorFlow. Donc évidemment, c'est plus, mais aussi Python, Scala, Clojure, Air, Julia, Perl. Si quelqu'un fait du deep learning en Perl, ça m'intéresse, j'aimerais savoir ce que vous faites. Et on a aussi Java, mais alors uniquement pour l'inférence, uniquement pour la prédiction, parce qu'évidemment il y a beaucoup d'applications Java qui ont envie d'embarquer un modèle prédictif et donc de l'invoquer en Java localement dans le code. Et là aussi, on a cette distinction entre API symbolique et API impérative. L'API impérative de MXNet s'appelle Gluon, je vous la montrerai tout à l'heure. Elle est en Python à 100%. Un des avantages de Gluon, c'est que Gluon inclut des toolkits, qui s'appellent GluonCV et GluonNLP, pour la vision artificielle et le traitement du langage naturel, et un grand nombre de modèles préentraînés que vous pouvez vraiment utiliser en quelques lignes de code. Je vous montrerai un exemple tout à l'heure de segmentation vraiment en 3-4 lignes de code, vous verrez c'est pas mal du tout. Donc ça vous permet là aussi d'aller vite et de réutiliser des modèles sans avoir nécessairement à réentraîner quoi que ce soit. Donc on a aussi pas mal de clients sur MXNet, ce qu'ils apprécient dans MXNet par rapport à d'autres librairies, c'est notamment ces fameux toolkits Gluon qui leur permettent de construire des modèles rapidement. La compatibilité avec ONNX, ONNX est un format d'échange de modèles entre librairies. Donc vous pouvez prendre un modèle qui a été entraîné avec PyTorch par exemple et exporter au format ONNX et le charger directement dans MXNet sans avoir à le redéfinir, à le réentraîner. MXNet peut aussi être utilisé comme back-end pour Keras, par défaut la plupart des gens utilisent TensorFlow, mais MXNet a aussi été intégré en tant que back-end Keras, et on constate une accélération assez notable lorsque l'on passe de l'un à l'autre. Il y a d'autres features techniques, le scaling de MXNet qui était linéaire quasiment depuis le début, et d'autres fonctionnalités qui font que pour le déploiement de code avec des langages comme Java ou le serveur de modèles, etc., le déploiement de modèles se fait de manière assez simple. Je vais passer la parole à Renaud, merci beaucoup d'être avec nous aujourd'hui, qui va nous expliquer comment EarthCube processe des images de taille assez notable sur AWS. Merci beaucoup. Applaudissements Bonjour, merci Julien de m'avoir donné l'opportunité de parler ici. Je vais vous expliquer un peu comment on utilise AWS chez EarthCube et aussi comment on a progressé, c'est-à-dire du début où on va utiliser des instances de manière assez simple et puis le futur, qu'est-ce qu'on envisage sur les services éventuellement managés. Avant de parler de tout ça, je vais peut-être vous parler de ce qu'on fait. EarthCube, finalement, c'est assez simple. Ce qu'on cherche à faire, c'est résoudre ce problème. Donc, voilà, excusez-moi. Nous, on va essayer de résoudre ce problème. Quand on parle de surveillance, quand on parle de recueil d'informations sur le terrain pour voir comment se comporte une infrastructure, comment se comporte une ville, comment se comporte un aéroport, on recueille beaucoup d'informations, de plus en plus d'informations, sauf qu'en fait, on ne les traite pas tous, on n'en traite qu'au 5%. C'est le fameux mur de données dont tout le monde parle et qui est particulièrement vrai quand on fait la surveillance de sites, quand on va regarder des infrastructures, des villes, de l'environnement, des sites d'intérêt stratégique. C'est encore plus particulièrement vrai quand on parle d'imagerie, puisqu'on a une explosion du volume d'images satellites, du volume d'images aériennes, et avec aujourd'hui, pas une explosion de nombre de gens pour regarder les images. Imaginez-vous, vous avez tous regardé Google Maps, imaginez-vous le travail d'un analyste image, que ce soit dans le gouvernement ou un analyste civil, ce qu'il va faire c'est qu'il va prendre une image qui fait l'équivalent de la taille de Paris et on va lui demander de compter toutes les voitures dedans. Vous prenez Google Maps, vous tapez tout Paris, même un tramuros, et vous comptez toutes les voitures. Vous voyez que c'est quand même très très très painful et que ça prend un temps fou. Et donc aujourd'hui, si on regarde toutes les cancellations, si on regarde tous les producteurs, il y a des dizaines, des centaines d'images par jour qui tombent, et donc qui sont des milliers même on peut dire des fois, et qui sont principalement non utilisés. Donc notre but va être d'utiliser l'intelligence artificielle pour résoudre ce problème. En particulier pour ce qu'on appelle la surveillance de sites stratégiques. Donc stratégique ça va être soit pour des gouvernements, donc des sites qui ont une grande valeur stratégique, soit pour des industriels, donc typiquement par exemple si on est Total, ça va être des pipelines, soit pour éventuellement de l'environnement. Et donc aujourd'hui, notre produit utilise l'intelligence artificielle pour avoir un service qu'on appelle de géant intelligence, de géant formation qui va permettre de surveiller des sites et d'avoir des alertes quand il se passe quelque chose de manière complètement automatique. Donc on a cette liste de sites, ici un aéroport, on voit que sur cet aéroport on peut cliquer sur l'aéroport et puis on peut voir une évolution du nombre d'avions, par type d'avion, par aussi par sous-zone dans l'aéroport et ainsi envoyer des alertes, et puis après on peut voir aussi les paramètres de ces zones, les paramètres de cet aéroport et comment étaient paramétrées les alertes. Puis après bien sûr on peut aller voir sur la carte, visualiser nous-mêmes l'image, visualiser les différentes zones de l'aéroport avec les différents alertes liés. Donc par exemple si on sait qu'il y a tel avion qui va arriver en telle zone de maintenance, ça veut dire que cet avion est inopérant. Ça peut vouloir dire pour la personne qui surveille cet avion ou qui va avoir une idée de l'activité de l'aéroport que cet avion est inopérant. On a ici des hélicoptères qu'on va détecter. On fait exactement pareil avec des véhicules, des avions, des bateaux, des routes. On va aussi faire de la cartographie, etc. Tout ce qui va être de surveiller des ascenseurs un peu critique. C'est l'intelligence artificielle qui nous permet de faire ça, qui nous permet de détecter ici donc ici on a un avion qui est dans une certaine zone qui veut dire quelque chose pour le client à la fin et il va pouvoir ainsi en tirer de l'information de manière complètement automatique. Et donc ensuite on utilise ça en faisant du deep learning sur TensorFlow sur AWS. La première question, c'est pourquoi faire du deep learning ? Parce que même sur TensorFlow, même sur AWS, que le deep learning en particulier sur des images satellites, on va le voir, c'est compliqué. Donc pourquoi ? Parce que vous voyez, une image satellite, ça ressemble à ça. Donc ce que vous voyez au centre, en fait, c'est des véhicules. Et ça, c'est une image de pas mauvaise qualité, en fait. Et donc on a des reflets sur les pare-brises, on a des occultations avec de l'ombre, on a des voitures qui sont cachées par des bâtiments. Et nous, ce qu'on détecte, ce qui est en violet, ce sont les véhicules. On veut savoir quels sont les véhicules, quelle est la densité de véhicules ici. C'est une tâche qui est très compliquée, c'est même très compliquée pour un humain. Les humains qui font ça, ils ont des taux de détection qui peuvent varier de 10%, 15% si l'image est de mauvaise qualité, s'il y a du vent de sable, s'il y a des perturbations atmosphériques. C'est une tâche très compliquée. Aujourd'hui, il n'y a que le deep learning qui permet de faire ça. On a tous entendu que les réseaux de neurones, l'intelligence artificielle, ce n'est pas neuf. C'est vrai. Ça date de quelques années déjà. Par contre, les révolutions qui ont permis les réseaux convolutionnels, les rétropropagations et l'apprentissage profond, permettent vraiment de débloquer en vision artificielle toute une série d'applications qui n'étaient absolument pas faisables avant. Sans le deep learning, ce genre d'applications, ce genre d'images n'existent pas. Ensuite, pourquoi TensorFlow ? C'est flexible, en particulier non utilisé avec Keras, et donc ça permet de tuner, de recoder ses propres réseaux. On va en parler un peu après, puisque nous, on n'est pas capable, avec les réseaux sur étagère, d'avoir les performances qu'on veut. On est obligé de tout tuner, de repartir from scratch, de des fois faire du transfert, mais des fois repartir avec des réseaux complètement blancs, et donc de réapprendre des réseaux custom. Et ensuite, AWS, c'est assez simple, vous en avez entendu parler. Quand on commence une startup, alors aujourd'hui on est une trentaine, on est assez content, mais quand on a commencé à 3-4, on ne veut surtout pas s'embêter avec le stockage, le compute, le scaling. Et encore maintenant, on ne veut surtout pas s'en occuper. Il y a des gens, c'est leur métier, c'est AWS, ils font ça beaucoup mieux que nous, ils hébergent des services qui sont utiles, ils ont beaucoup plus de savoir-faire technique que nous. Donc ils permettent de nous focaliser sur nos savoir-faire, qui est comment servir le métier. Un petit mot sur la technologie. Je le disais, c'est compliqué de faire de l'intelligence artificielle sur l'image satellite. Les images sont grosses, les clients ont besoin, c'est des gens, on ne va pas les voir avec 90% de performance. En dessous de 95% ils ne nous parlent pas, que ce soit des gouvernements ou des gens qui font de la surveillance d'assets critiques. Ils ont besoin de beaucoup de performance. Les données, on peut aller prendre des données, un coup en France, un coup en Finlande, un coup en Australie, un coup au Moyen-Orient, avec un coup c'est de la neige, un coup il y a du vent de sable, un coup c'est de la forêt. Donc on a vraiment des satellites qui vont faire de 30 cm à 1 m de résolution. Donc on a besoin de choses assez complexes par rapport à d'autres personnes. Donc nous on va utiliser beaucoup de la segmentation et de la détection d'objets, des choses qui sont assez intensifiées, avec des architectures implémentées sur Keras, mais qui sont à chaque fois custom. C'est-à-dire qu'on a déployé nos propres architectures basées sur des papiers, par exemple basées sur des retinanettes ou sur des lunettes, et qu'on a tweaked et rendu customisable grâce à des fichiers de configuration assez simples. On travaille beaucoup en R&D sur des sujets comme l'ensemble link, comme des réseaux larges, donc les Resnex, comme des capsules, des réseaux bayésiens, pour justement débloquer certaines applications de performance. Et aujourd'hui, on n'utilise quasiment aucun réseau sur étagère. C'est-à-dire qu'on prend le segnet de base, il ne marche pas chez nous, tout simplement. Un truc qu'on utilise beaucoup aujourd'hui en production dans nos architectures qui a permis de débloquer beaucoup d'applications, c'est de mettre du PSP, du spatial pyramide pooling, et rajouter des couches ResNet et des SkipConnections un peu partout. Ça nous a permis de prendre en compte les contextes spatiaux liés aux images satellites qui permettent de dire que l'imagerie satellite, elle sait qu'elle va pouvoir prendre en compte, le réseau va pouvoir prendre en compte le contexte spatial de l'image, qu'il y ait une route, sur une route il y a plus de chances d'avoir des voitures, sur la mer il y a plus de chances d'avoir des bateaux, etc. Et grâce à ce fine tuning, on va pouvoir prendre ça en compte. Et même au niveau des loss, on va aller chercher des loss custom, que ce soit au niveau de... Par exemple, le premier truc qu'on a fait, c'est faire des loss biaisées. Puisque par exemple, si on fait de la détection d'images, on a un milliard de pixels, il y a 200 bateaux dessus, 99,9% des pixels de l'image ne sont pas des bateaux. Donc si on fait tourner un réseau de base comme ça, il va détecter tout en non-bateau et on aura 99,9%. Et en fait, en pratique, les performances seront mauvaises. Donc on va aussi développer nos propres loss, nos propres fonctions d'optimisation. Qu'est-ce qu'on a construit sur AWS, du coup, pour permettre ce genre de choses ? Donc la première chose, vous avez déjà dû l'entendre, la première chose qu'on a construite à scale, c'est le labeling. C'est comment labelliser des données avec comment faire des datasets. Aujourd'hui, on a labellisé plus de 1,5 million d'objets sur des images satellites. Pour ça, on a travaillé avec une entreprise qui fait du labelling, qui s'appelle Ingedata. On a travaillé à une plateforme hébergée sur AWS, qui nous a permis que les gens d'Ingedata labellisent directement sur notre plateforme qui est hébergée par AWS. Quand ils vont labelliser des images, ça va directement être disponible dans notre data lake sur S3. Et du coup, quand un data scientist veut gérer un dataset, cette image est déjà disponible. Ça ne paraît rien, mais en fait, quand on labellise 10 000 observables par jour, s'envoyer des fichiers par FTP avec le versionning, correction de dataset, etc., c'est l'enfer. Donc ça, c'est une des premières choses qu'on a déployées qui nous a permis vraiment de passer à l'art industriel. C'est-à-dire cette labellisation d'objets en masse. Cette labellisation est formative. À DataScienty, chez nous, il a un petit outil qui lui permet de générer des datasets, donc de partir d'une image satellite, un dataset sur lequel il peut entraîner son algo. Et s'il vient lundi et s'il vient le mardi, il y aura eu des labellisations qui sont faites, et donc quand il générera son dataset, il y aura plus d'images disponibles. Tous les jours, il y a des images qui s'empilent. Au niveau du training et de l'inférence aussi, déjà, on utilise beaucoup les AMI. On a pris l'AMI AWS, qu'on a un peu customisé à notre goût, mais qui permet d'avoir à chaque fois quelque chose de standardisé. Donc, quand on fait du training ou de l'inférence, on spin toujours la même AMI. On a des trainings qui sont potentiellement des fois assez computer-intensifs. Donc, des fois, on va dire plus de 1000 images, une image satellite, ça peut faire jusqu'à 4 milliards de pixels. Et donc, des fois, on peut utiliser juste 1000 images. Donc ça peut prendre 2-3 semaines, 4 semaines sur une P3-8X qui va être avec 4 GPU P100. Et donc on utilise ces instances pour faire du training, pour faire de l'inférence et pour déployer nos algos. Ce qui est intéressant, c'est qu'au début, quand on a commencé, on utilisait juste des petites instances EC2 pour faire un peu d'inférence, etc. Et plus ça va, aussi plus la zoologie d'instances GPU commence à s'étoffer. Avec de plus en plus de types d'instances, on va pouvoir aussi, en fonction des cas d'usage, optimiser pour le coup. Et finalement, ça je vais en parler juste dans le slide d'après, c'est qu'on utilise aussi S3 pour faire du versionning et faire du déploiement de nos containers avec une petite tâche qui s'appelle Celery. Donc on n'utilise pas encore SageMaker, on en parlera un peu, mais ça permet vraiment de développer une fois qu'un algo est terminé, on appuie sur un bouton, ça spin up des instances sur AWS, ça va chercher tout ce qu'il faut, etc., et ça permet de déployer le container. Donc comment on le fait exactement ? C'est comme ça. Du coup, on a sur Amazon des poids et une architecture qui sont versionnés. Donc l'architecture du réseau, les poids sont sur AWS. Quelque chose qu'on met sur GitHub qui est un fichier de configuration pour la prédiction. Et on a aussi un docker qui est aussi hébergé sur un registre sur S3 qui est ce qu'on appelle le predict, qui est la fonction qui permet de prédire. Et une fois que le data scientist est content, il appuie sur un bouton, donc ça pool ses poids sur S3, ça commit le config.yml, ça va déclencher une instance EC2, qui va aller chercher justement sur S3, ces architectures, ces configs.yml, ce docker, repackager tout ça dans un autre docker, et ça va être ainsi disponible pour n'importe quelle instance de prédiction chez nous. Et c'est exactement pareil quand on lance un job, on est encore sur des systèmes comme ça, où on a une tâche, on va lancer un job, ça va spinner une instance EC2, une AMI EC2 standard de chez nous, pouler le docker associé, lancer la prédiction, sauver les résultats sur S3, killer l'instance, et voilà. Et donc un peu comme ça, ça nous permet de prédire et d'avoir ces fameuses prédictions sur des images satellites qui nous permettent de tourner en production. Ça fait maintenant trois ans qu'on a commencé, on est parti de petites instances EC2 et on a de plus en plus managé certains process. Au début on utilisait EC2, on utilisait AWS juste pour du stockage et du bare metal. On utilisait EC2, on se connectait en SSH, etc. Et on stockait nos choses comme si c'était un gros disque dur sur S3. Et plus ça va, plus on est en train d'intégrer les choses. Mais à la fin, pour ceux qui font du deep, ils le savent très bien, on peut être super intelligents sur cette architecture, avoir des gens qui ont fait le MVA polytechnique ou des super écoles, à la fin, plus il y a de données, meilleures sont les algos. C'est la conclusion du deep learning, on va dire, c'est qu'en général, more data beat clever algorithm. Et plus de données, c'est plus d'infrastructures, c'est-à-dire que dès qu'on commence à avoir beaucoup de données, c'est changer entre data scientists, entre les gens qui labellisent et les gens qui stockent, entre la production et les data scientists, s'échanger les modèles, s'échanger les données, s'échanger les vérités terrain, ça devient un enfer. Et donc, plus de données, ça demande plus d'infra. Donc à chaque fois qu'on va augmenter nos données, augmenter nos data sets, augmenter nos trainings, on va s'intégrer de plus en plus sur le cloud. Et ça, si l'infrastructure n'est pas scalable, notre conclusion et ma conclusion profonde, c'est que sans infrastructures scalable cloud, il n'y a pas d'intelligence artificielle. On peut avoir tous les algos qu'on veut, si on est sur un notebook qui tourne en local, ça ne fera jamais qu'un beau prototype. Il faut labelliser, entraîner, déployer, versionner. Si on n'utilise pas une infra scalable et du cloud pour faire ça, pour nous, il n'y a pas d'intelligence artificielle, surtout pour une startup. Parce que le coût de déployer ça on-premise sur des propres serveurs est absolument... Il faut plusieurs millions d'euros pour avoir le moindre chose. Donc pour nous, c'est vraiment quelque chose qui nous a permis de travailler absolument à une vitesse qui était inimaginable dix ans avant, on va dire. Ce qu'il faut savoir aussi, c'est qu'on est dans des domaines, nous, de gouvernement, un peu de défense, des infrastructures critiques, qui sont des fois réticents au cloud. Ce qu'il faut savoir, c'est qu'on aime bien dire qu'il y a des gens dans notre domaine qui utilisent le cloud. La NGA, qui est la plus grande agence de renseignement géospatial américain, est en train de passer tout sur AWS. AWS a sorti son service de Ground Station qui permet, quand des satellites prennent des images, qu'elles soient directement téléchargées. Donc nous on est persuadé que le cloud c'est indispensable pour scaler les applications comme les nôtres sur vraiment une grande échelle. En particulier chez les clients aussi, sur leurs propres données. Et pour finir, au niveau de nos next steps, on a commencé avec des petites instances, on a commencé à faire du bare metal, puis après, on s'est de plus en plus intégrés. On a commencé à tester Amazon SageMaker, que ce soit par une formation aussi sur notre temps libre, avec des choses qui sont assez sympas. Nous, on reste avec... On a encore ces contraintes, qu'on a des trainings qui sont extrêmement longs, donc qui peuvent être extrêmement coûteux sur le cloud. Donc on est très partant d'abstraire le training avec des instances qui peuvent être des fois managées, des fois en spot, des fois avoir cette flexibilité du cloud pour optimiser les coûts. Puisque les GPU, tout le monde le sait, ça coûte cher. Et ensuite, MXNet, ce qu'on a vu sur MXNet nous donne pas mal envie, que ce soit avec Keras ou ce que soit en vanilla, en particulier par les temps de training, parce que comme on le disait, nous si on passe un training de 15 jours à 7 jours, ça nous fait gagner plusieurs milliers d'euros en fait, rien que sur un seul training. Donc c'est vraiment quelque chose qu'on va essayer de scaler dans le futur et continuer à le faire sur des infrastructures en s'intégrant de plus en plus dans les infrastructures AWS. Donc voilà, merci. Je laisse Julien reprendre la main. Et puis si vous avez des questions, on a un stand et puis n'hésitez pas à venir nous voir. Bravo. Merci beaucoup. Super. Bon, c'est pas mal, franchement, les images à 4 milliards de pixels, ça me plaît bien, ça. Ça me plaît bien. Bon, il faut un peu de stockage, mais ça tombe bien. Alors, pour finir, je voudrais justement vous parler un peu de comment utiliser TensorFlow et MXNet sur SageMaker, et puis on fera une ou deux démos rapides. Le mode script vous permet d'exécuter le même code que sur votre machine locale sur SageMaker, sans modification. Le training distribué, l'utilisation de plusieurs instances pour un même job, est configuré automatiquement. Vous pouvez streamer vos datasets depuis S3 vers les instances de training, ce qu'on appelle le pipe mode, pour des datasets de taille infinie. TensorBoard est disponible pour visualiser vos courbes d'entraînement et vérifier vos métriques. Keras est parfaitement supporté, et c'est la même chose pour MXNet, avec des containers, le mode local, le mode script, et l'optimisation des performances. Nous allons faire une petite démo. Je suis désolé, j'ai des petites images pour des démos avec des temps acceptables, mais c'est quand même intéressant. Je vais vous montrer comment utiliser le même code Keras avec les back-ends TensorFlow et MXNet. La seule nuance est la façon dont on sauve le modèle, car on sauve un modèle MXNet dans un cas et un modèle TensorFlow dans l'autre. Je vais entraîner un modèle de classification d'images sur le dataset Fashion MNIST, conçu par Zalando, qui est un remplacement pour MNIST. Il contient 60 000 images en noir et blanc, réparties en 10 catégories. Je travaille dans un notebook SageMaker, je vais importer le SDK, télécharger mon dataset, et l'uploader sur S3. Mon dataset d'entraînement et de validation est propre, donc je n'ai pas besoin de pré-processing. J'ai mon script, qui est très standard. Le script doit accepter quelques paramètres, notamment l'emplacement pour sauver le modèle, et d'autres paramètres simples que je vais chercher dans des variables d'environnement. Une fois que le code est écrit de cette façon, il peut être facilement utilisé sur SageMaker. Je charge le dataset, fais une petite normalisation, construis un réseau de convolution simple, compile le modèle, applique de la data augmentation, l'entraîne, affiche les performances, et le sauve. Je sauve un modèle prêt à être servi par TensorFlow Serving. Ce script fonctionne sur un laptop, et si je l'exécute dans le shell de Jupyter, il s'exécute. Je l'entraîne juste pour une époque pour tester. Pour une époque, le réseau s'entraîne correctement, comme sur un laptop. Pour tester ce code dans l'environnement TensorFlow de SageMaker, je vais utiliser le mode local. J'utilise l'objet TensorFlow du SDK SageMaker, je passe mon script sans modification, et je lui dis de l'entraîner sur l'instance locale. Je l'entraîne pour une époque pour vérifier. Cela me permet de vérifier que le code s'exécute correctement dans le container TensorFlow. Pour entraîner à l'échelle, je change simplement le type d'instance, en passant d'une instance locale à une P3 avec un GPU Nvidia. Je crée cette instance, charge le container TensorFlow, injecte mes paramètres, etc. Je peux entraîner plus longtemps, et je paie seulement pour les 355 secondes d'utilisation de la P3. Je n'ai pas besoin d'acheter des GPU coûteux. Je peux avoir ce dont j'ai besoin à la demande et payer à la seconde. J'obtiens une précision d'environ 86%, sans optimisation. Je peux déployer ce modèle en une ligne de code sur une instance C5. SageMaker crée l'instance, charge le container et le modèle, et crée un endpoint HTTPS pour des prédictions. J'ai une vraie URL que je peux invoquer depuis n'importe quelle application. Je peux aussi appeler l'API predict du SDK pour faire des prédictions. Je prends 10 images du dataset, les poste sur l'endpoint, et compare les prédictions avec la réalité. Les prédictions sont correctes, sans erreur. Avec le SDK SageMaker, je peux passer rapidement de l'expérimentation à l'entraînement et au déploiement, à toute échelle. Pour essayer un autre back-end, comme MXNet, je change simplement la façon de sauver le modèle et une ligne dans un fichier de configuration de Keras. Je peux entraîner de la même façon, avec des performances similaires. Je peux déployer et prédire de la même manière. Une fois que j'ai fini, je peux effacer les endpoints pour cesser de payer. Avec SageMaker, on va très vite de l'expérimentation au déploiement, quelle que soit l'échelle. J'ai mentionné Gluon, qui est un des toolkits inclus dans GluonCV pour Computer Vision et Gluon NLP pour Natural Language Processing. Je vais vous montrer comment utiliser GluonCV. Je vais le faire directement dans le notebook, sans utiliser SageMaker. J'importe MXNet et Gluon, et décide d'utiliser le GPU. Je télécharge un modèle pré-entraîné de la collection de modèles de GluonCV, une architecture Mask-RCNN entraînée sur le dataset COCO. Je récupère une image depuis Internet, l'affiche, et l'applique un pré-traitement similaire à celui des images du dataset COCO. Je passe l'image à travers le réseau et récupère des classes, des scores, des bounding box, et des masques. Je peux afficher les 10 scores les plus élevés. J'ai deux instances détectées à quasiment 100%. Je filtre les résultats pour ne garder que les masques et les bounding box détectés à 99%. On voit la segmentation et les bounding box des objets détectés. En dix lignes de Python, on télécharge un modèle pré-entraîné et l'utilise pour la détection et la segmentation. Si ces modèles correspondent à vos problèmes, vous pouvez les utiliser avec peu de code. Si vous avez besoin de faire du transfer learning, vous pouvez réentraîner ces modèles sur vos propres classes d'objets. Voilà, c'est GluonCV, un des toolkits disponibles autour de Gluon. Si vous voulez démarrer, voici les bonnes ressources : le free tier de SageMaker, les pages de services, le SDK SageMaker sur GitHub, les exemples, et mon blog sur Medium et mes notebooks sur GitLab. Merci beaucoup. Je vous remercie, Renaud, de nous avoir rejoints aujourd'hui. C'est un cas d'usage impressionnant. Si vous voulez rester en contact, n'hésitez pas à me contacter sur Twitter. Si vous avez des questions ou des projets sympas à partager, c'est avec plaisir. N'oubliez pas de noter la session, votre feedback est important. Je vous souhaite une très bonne fin de journée et à l'année prochaine au Summit. J'espère vous revoir à d'autres événements. Merci beaucoup et à bientôt.