TensorFlow Dev Summit, comme si vous y étiez (1/2)

Le 15 février 2017 à Mountain View s’est tenu le tout premier TensorFlow Dev Summit. Au programme de cette conférence, la sortie de la version 1.0 de TensorFlow, mais aussi de nombreuses présentations sur les optimisations internes propres à TensorFlow, les différentes API ainsi que de nombreux cas d’usage.

Si vous avez raté cet évènement, pas de panique, les vidéos sont déjà en ligne ! Nous les avons visionnées pour vous et vous proposons dans cet article un résumé des principales informations à retenir de cette conférence qui a été suivie par le monde entier en Live Streaming.

Nous allons couvrir la conférence en deux articles : un premier sur les présentations relatives aux avancées techniques de TensorFlow, et un deuxième sur les cas d’application.

La Keynote d’ouverture (Jeff Dean, Rajat Monga et Megan Kacholia)

Dans cette Keynote d’ouverture du TensorFlow Summit 2017, Jeff Dean, Rajat Monga et Megan Kacholia nous parlent de l’évolution que TensorFlow a connu ces dernières années. De sa naissance à la sortie de la très attendue version 1.0, cette keynote nous présente le passé, le présent et le futur de TensorFlow ainsi que certains des nombreux projets qu’il a permis de réaliser.

De DistBelief à la naissance de TensorFlow

TensorFlow a une histoire, une histoire qui a commencé il y a maintenant 5 ans. A l’origine, en 2012, la multi-nationale de Mountain View a commencé le développement d’un premier Framework de Deep Learning appellé DistBelief. Celui-ci a reçu un premier accueil plutôt favorable, mais a vite souffert de lacunes concernant principalement sa mise à l’échelle sur les architectures GPU et son manque de flexibilité sur les projets orientés purement recherche en Deep Learning.

Malgré l’abandon de DistBelief, les premières fondations de TensorFlow ont été créées. Le code a ensuite rapidement été repris, réusiné et rendu plus robuste. Le but de ce développement était de garder les avantages de DistBelief tout en répondant aux inconvénients de celui-ci. Trois projets supplémentaires se sont également greffés au développement afin de faire naitre TensorFlow :

• Une mise à l’échelle robuste sur de nombreuses architectures (CPU, GPU, TCU…) ainsi que sur plusieurs supports (iOS, Android, Raspberry Pi…)
• Des APIs multi-utilisateurs (Python, C++, Java, Go…)
• Le TensorBoard, une interface de monitoring graphique de TensorFlow (plus de détails dans le slot « Hands-on Tensorboard » animé par Dandelion Mane).

À toute allure :  du lancement en open-source à la version 1.0

Depuis l’annonce du lancement open-source de TensorFlow, ce dernier a connu une accélération fulgurante, tant au niveau des contributeurs GitHub (>500 pour la version 1.0), que de l’intéressement de la communauté StackOverflow ou des grandes universités américaines. Cela s’est bien sûr traduit par des progrès rapides sur le projet :

Ces progrès réalisés mènent aujourd’hui à la release de TensorFlow en version 1.0. C’est une release majeure en terme de développement. Cette version souhaite répondre à trois points-clés :

• Des vitesses de traitement améliorées sur de nombreuses architectures CPU/GPU.
• Des API haut niveau (plus de détails dans le slot « TensorFlow High-level API » animé par Martin Wicke).
• Des API stables pour l’utilisation en production.

Et maintenant : TensorFlow en production, où en est-on?

Avec les progrès obtenus sur les temps de calcul et la stabilité des APIs, de nombreux cas d’utilisation commencent à être réalisés, tant chez Google que dans d’autres entreprises. Chez Google, on notera entre autres le « Show and Tell », cas d’utilisation réalisé par Google Research. Ce projet consiste en la création de la description d’images par un réseau de neurones. Ci-dessous, quelques exemples réalisés par la machine :

D’autres applications, notamment dans le domaine de la santé, ont également été réalisées. Retrouvez-les dans la deuxième partie de l’article !

XLA: TensorFlow, compiled ! (Chris Leary and Todd Wang)

« We can compile TensorFlow ! », telle est l’introduction de Chris Leary dans sa présentation sur XLA (Accelerated Linear Algebra). Le projet est même open source et avec de la documentation déjà prête. XLA est un composant alpha de TensorFlow, mais a rapidement été open sourcé pour obtenir une contribution de la communauté.

TensorFlow est flexible, expressif, extensible, grâce au fait qu’il soit interprété, dynamique, stateful et modulable. Le défi de l’équipe ayant développé XLA est de garder toutes ces belles caractéristiques tout en rajoutant plus de vitesse. La solution : la compilation Just In Time. L’objectif est de prendre un graphe TensorFlow en entrée et d’en sortir des assembly optimisés et spécialisés pour ce graphe. Il est alors possible de builder des programmes au runtime, d’avoir une overhead compilation faible et de prendre en compte les dimensions des variables (le batch size par exemple) le plus tard possible. De nombreuses opportunités s’offrent à nous avec la compilation, comme par exemple le fait de pouvoir transformer des modèles en des exécutables ainsi que de diminuer leur taille drastiquement.

XLA est un projet récent, et toutes les opérations de TensorFlow ne sont pas encore compilables par design. Son objectif est de décomposer de manière statique les opérations de TensorFlow en des opérations mathématiques primitives, tout en gardant les performances d’un développement de cette macro opération en C++.

Todd Wang présente ensuite les différents composants du projet XLA

• /TensorFlow/compiler/xla: Le compilateur. A partir du moment où il est possible de représenter le graphe TensorFlow en un graphe XLA, il devient très simple de le compiler.
• /TensorFlow/compiler/tf2xla: Module chargé de convertir TensorFlow en XLA. Certaines opérations, comme le add, sont très simplement représentables. Pour les opérations plus complexes, comme le softmax, la convertion se fait en plusieurs sous parties primitives. Tous les kernels ne sont cependant pas encore implémentés.

• /TensorFlow/compiler/jit: Module pour la compilation Just In Time. Permet de transformer des sous-ensembles d’un graphe si certaines parties du graphe ne sont pas compilables.
• /TensorFlow/compiler/aot: Module pour la compilation Ahead Of Time. Permet de transformer en binaire un graphe qui est compilable en entier via le module tfcompile

Tout n’est pas encore parfait, comme le montrent les quelques études comparatives de performance présentées montrant que certaines opérations ne sont pas exécutées plus rapidement via XLA (notamment sur CPU), mais de nombreuses améliorations sont déjà observables.

Hands-on TensorBoard (Dandelion Mane)

Les réseaux de neurones sont parfois vus comme de grosses boîtes noires difficilement interprétables et ajustables. TensorBoard est là pour éclairer le tout et aider le développeur dans son utilisation de TensorFlow.

À travers un exemple simple sur la classification de chiffres écrits à la main (dataset MNIST), Dandelion Mane explique comment utiliser TensorBoard pour optimiser la recherche d’éventuelles erreurs et visualiser l’évolution de l’entraînement. Pour visualiser le graphe créé, il suffit d’ajouter dans le code un FileWriter, qui est une classe permettant d’écrire de la donnée depuis TensorFlow vers le disque. L’ouverture de TensorBoard se fait alors via la commande suivante :

[bash]tensorboard –logdir /tmp/your_logs_repo[/bash]

Dandelion présente ensuite des moyens de ré-organiser son code afin de mieux visualiser le graphe et de distinguer les grandes phases de sa construction. Cela passe par l’ajout de name scopes via des blocs with dans le code, ainsi que des node names, c’est-à-dire des dénominations des différentes opérations composant le graphe. Il est ensuite possible d’ajouter du code pour créer des summary, qui sont des opérations TensorFlow qui renvoient des protocol buffers contenant de la donnée résumée. On peut ainsi observer des scalaires, des images, de l’audio et des histogrammes.

TensorBoard est aussi un excellent outil pour optimiser la recherche d’hyperparamètres tels que le learning rate et l’architecture du modèle. Il suffit alors de lancer plusieurs entraînements du réseau de neurones représentant plusieurs combinaisons de paramètres, et d’écrire pour chacun les résumés dans un sous-répertoire différent. En lançant TensorBoard sur le répertoire parent, il devient alors très simple de visualiser les courbes d’accuracy de tous les modèles en même temps, et même de filtrer les noms par des regex.

Dernière visualisation montrée, la partie Embedding Visualizer, qui permet d’utiliser des représentations latentes des données (des couches intermédiaires en général) pour faire de la visualisation en 2 ou 3 dimensions (via une PCA ou un T-SNE). Cela permet de visualiser rapidement comment sont regroupées les différentes catégories, de voir si elles se distinguent bien ou si au contraire certaines catégories s’entremêlent.

Dandelion termine la présentation par nous exposer les futures implémentations pour TensorBoard : l’intégration du TensorFlow Debugger, l’incorporation de visualisations spécifiques par domaine d’activité et la possibilité d’utilisation à l’échelle d’une organisation.

Les slides et le code de la présentation se trouvent sur la page GitHub associée.

TensorFlow High-Level API (Martin Wicke)

Depuis sa création, TensorFlow est une bibliothèque de calcul mathématique à l’échelle du vecteur et de la matrice. Le fait d’avoir une API bas niveau offre de nombreux avantages à TensorFlow, notamment en termes de flexibilité, d’extensibilité et de maintenabilité (une multiplication matricielle restera toujours une multiplication matricielle). Cependant, on ne peut pas tout avoir avec ce type d’API, notamment le fait qu’il n’est pas possible de proposer des algorithmes clé en main ou d’autres abstractions plus haut niveau, comme le proposent d’autres bibliothèques.

C’est pourquoi TensorFlow intègre dès la version 1.0 une API plus haut niveau permettant des itérations plus rapides, une intégration automatique des bonnes pratiques et de la mise à l’échelle, ainsi qu’un processus de déploiement simplifié pour exporter un modèle vers d’autres services.

Plusieurs couches sont intégrées ou en cours d’intégration par-dessus le front-end Python :

• Layers: Permet de construire plus facilement des modèles avec une ligne de code par couche. Toutes les bonnes pratiques sont encodées pour nous (notamment la notion de scope pour s’y retrouver dans TensorBoard).
• Estimator: Abstraction permettant l’encapsulation des opérations d’entraînement, d’évaluation et de prédiction via des méthodes fit(), evaluate() et predict(). Ces dénominations ne sont pas sans rappeler le fonctionnement de la librairie Python scikit-learn. Une dernière méthode, export_savedmodel(), permet la sauvegarde et l’utilisation du modèle via TensorFlow Serving.
• Canned Estimators: Modèles classiques déjà implémentés pour l’utilisateur. On retrouvera par exemple le LinearRegression ou le DNNRegressor (DNN: Deep Neural Network), avec à chaque fois en point commun un argument feature_columns.

Pour terminer, Martin nous donne la roadmap du développement de cette API haut niveau. Il faut ainsi s’attendre à retrouver layers dans la version 1.0, estimator dans la 1.1 et canned estimators dans la 1.2. Les version de TensorFlow sont en général espacées de 6 à 8 semaines.

Distributed TensorFlow (Derek Murray)

Derek Murray nous donne une introduction à l’entraînement distribué de modèles en TensorFlow, via l’utilisation de plusieurs CPU et GPU en parallèle.

Même en n’utilisant qu’une seule machine, il est possible de tirer bénéfice des CPU et GPU de cette dernière. Il est notamment classique d’instancier les variables du modèle sur le CPU, et de laisser toutes les opérations mathématiques au GPU, le tout en le spécifiant simplement dans la définition des variables et des opérations. Lorsque l’on passe à l’échelle sur plusieurs machines, une manière similaire de procéder est envisageable. Il faut alors définir un ou plusieurs Parameter Servers (typiquement des CPU) responsables du stockage des variables et des opérations d’update, ainsi que des Worker tasks (typiquement des GPU) pour le pre-processing, le calcul des fonctions de coût et la back-propagation. Plusieurs stratégies s’offrent alors à nous en fonction de la complexité du graphe à créer :

• In-graph replication : Le programme est simplement copié sur les différents clients. Les variables sont définies sur un CPU, et les itérations pour l’entraînement sont tour à tour effectuées sur un GPU différent. Cette technique fonctionne bien tant qu’il y a un nombre restreint de répliques.

• Between-graph replication : C’est la méthode pour entraîner des graphes beaucoup plus gros, notamment dans Cloud ML. Le but est de lancer un programme plus petit sur chaque instance, qui font la même chose. Chaque répliqua place ses variables dans la même Parameter Server Task (PS Task). Ainsi, les variables sont mises à jour globalement via tous les workers en parallèle. Cette manière de faire fonctionne car dès lors que deux clients qui créent des variables avec les mêmes noms sur le même device cible partagent le même back-end pour ce device. Ainsi, les itérations suivantes sur un même worker vont se faire à partir des variables mises à jour globalement et non pas juste localement.

On peut aussi parfois vouloir placer les variables du graphe à différents endroits et non pas dans une seule PS task. Il est possible pour cela de passer non pas un String mais une fonction dans tf.device() pour gérer le choix du placement d’une variable. On peut alors avoir une politique de placement aléatoire ou bien via du load balancing afin de gérer le fait que les variables n’ont pas la même taille. D’autres types de variables sont simplement trop larges pour les stocker à un seul et même endroit (typiquement les embeddings dans les modèles de texte). Il est alors possible de partitionner la variable sur plusieurs devices.

Concernant la gestion des Sessions et des Servers, il faut utiliser un ClusterSpec pourla variable sur plusieurs devices spécifier à TensorFlow les machines sur lesquelles on veut faire les calculs. Cela correspond simplement à un dictionnaire qui matche le nom des jobs avec la liste des adresses réseaux disponibles. Tout cela peut être automatisé via l’utilisation de Kubernetes ou Mesos. Les Servers doivent systématiquement être utilisés pour sauvegarder des checkpoints du modèle sur disque.

Enfin, Derek parle de la tolérance aux pannes et des différents cas de figure que l’on peut rencontrer, pour conclure sur le fait que l’API haut niveau sortie avec la version 1.0 propose des intégrations out-of-the-box pour les tâches distribuées, ce qui facilite grandement les développements. On peut ainsi customiser jusqu’au moindre détail l’installation ou bien définir des modèles en quelques lignes de code sans se préoccuper de la distribution.

Serving Models in Production with TensorFlow Serving (Noah Fiedel)

Le Serving en Data Science correspond à la manière dont est appliqué un modèle de Machine Learning en production une fois qu’il a été entraîné. Le monde du Machine Learning est encore relativement loin des processus de build et d’intégration continue que l’on trouve dans le développement logiciel « classique ». Il y a encore énormément de questions qui restent aujourd’hui sans réponse claire, notamment sur la manière de ré-entraîner un modèle en production. La manière la plus commune aujourd’hui pour faire du Serving est via un serveur RCP (Remote Procedure Call).

Les objectifs pour faire appel à des modèles de Machine Learning via un serveur sont nombreux: Faible latence, possibilité d’utiliser plusieurs modèles dans un seul et même process, déploiement de plusieurs versions d’un même modèle au cours du temps, etc.

Dans cet objectif, Noah Fiedel introduit TensorFlow Serving, le décrivant comme un système de Serving de modèles de Machine Learning haute performance, fait pour les environnements de production. TensorFlow Serving offre une intégration out-of-the-box des modèles fait via TensorFlow, mais peut très bien être étendu à d’autres types de modèles et données. Le système se base sur quelques concepts clés:

• Servables : Les objets sous-jacents utilisés par les clients pour effectuer les calculs (une inférence par exemple)
• Loaders : Gèrent le cycle de vie du Servable. Ils permettent de standardiser le chargement des Servables
• Sources : Chaque Source provient de zéro, un ou plusieurs Servables

Tout est résumé dans l’image ci-après : la Source crée des Loaders pour des versions de Servables, qui sont envoyés en tant que « version désirée » (Aspired Versions) au Manager, qui les charge et les met à disposition des requêtes du client.

Beaucoup d’améliorations sont encore à l’étude, mais TensorFlow Serving se présente déjà comme une solution sérieuse pour la mise à disposition d’algorithmes de Machine Learning dans des environnements de production .

ML Toolkit (Ashish Agarwal)

Nous l’avons vu précédemment, TensorFlow est une API bas niveau. Les intégrations plus haut niveau ont été introduites en version 1.0, mais il manque encore des algorithmes de Machine Learning clé en main. Ashish nous présente les travaux faits dans ce sens via un ML Toolkit.

TensorFlow propose maintenant des implémentations de quelques-uns des algorithmes de Machine Learning les plus utilisés, tels que la Régression Linéaire / Logistique, le K-Means, les SVM, la factorisation matricielle, les Random Forest, ainsi que de nombreuses architectures de réseaux de neurones (DNN, RNN, LSTM, Wide & Deep…). Pour chaque algorithme, quelques implémentations et stratégies sont déjà disponibles, et d’autres sont en cours de développement.

Tous ces algorithmes sont exposés via une API appelée Estimators, largement inspirée du fonctionnement de scikit-learn. Bien que les utilisations soient similaires, c’est bien un moteur TensorFlow que l’on retrouve derrière, avec à chaque fois la création d’un graphe pour l’entraînement. Cependant, l’objectif n’est pas de créer des boites noires inaccessibles. Pour chaque algorithmes, les utilisateurs peuvent tout à fait inspecter les implémentations ainsi que les graphes et les étendre pour d’autres usages (comme concaténer deux modèles via tf.group()).

Enfin, pour rappel, ces implémentations permettent de l’exécution distribuée, ce qui donne une réelle plus value aux implémentations en TensorFlow. Quelques études comparatives de performance ont été réalisées pour tester la mise à l’échelle et les performances de ces implémentations. Sur une simple machine, la vitesse et la qualité des modèles est similaire à scikit-learn. La réelle plus value vient donc de la capacité à distribuer l’implémentation jusqu’à plusieurs milliers de machines. Les performances vont même bien au-delà des précédentes implémentations distribuées en Map-Reduce.

L’objectif derrière toutes ces implémentations est de combiner la facilité d’utilisation de scikit-learn avec les performances de TensorFlow pour en faire la solution la plus complète possible pour le Machine Learning (et pas uniquement le Deep Learning).

Conclusion

Énormément de nouveautés ont été présentées dans cette conférence, notamment avec la nouvelle version 1.0 de TensorFlow. Entre les optimisations internes pour rendre TensorFlow compilable jusqu’à la nouvelle API de plus haut niveau, tous les niveaux ont été touchés via cette nouvelle release. L’objectif de toucher le public le plus large possible est largement atteint.

Dans le prochain article, nous reviendrons sur les différents Use Cases pratiques qui ont été présentés durant cette conférence.