neoxia
Published in

neoxia

PyTorch vs. TensorFlow

Qui triomphera dans le duel des frameworks phares du deep learning ?

PyTorch et TensorFlow sont aujourd’hui les deux frameworks de deep learning les plus utilisés. TensorFlow a été développé par l’équipe de Google Brain et a été publié sous licence Apache en novembre 2015. PyTorch est un framework plus récent, publié sous licence BSD en octobre 2016 et principalement développé par FAIR (Facebook AI Research). Soutenus par ces géants de la tech, ces deux frameworks évoluent constamment, si bien qu’il s’avère difficile de se tenir informé des nouveautés et spécificités techniques. Si la question de “PyTorch ou TensorFlow ?” se pose depuis la sortie de PyTorch, sa réponse ne s’est pas clarifiée pour autant. Faut-il privilégier l’un d’eux ? Quelles sont les différences entre ces deux frameworks phares du deep learning ?

Des origines techniques très différentes

Ces deux frameworks ont à l’origine été conçus avec des approches techniques très différentes, la principale différence étant la définition du graphe de calcul. PyTorch est connu pour sa définition de graphe dynamique, c’est-à-dire que le graphe est défini au runtime. Cela a notamment l’avantage de permettre au graphe de changer d’une itération de calcul à une autre, ce qui est par exemple particulièrement pratique quand la taille des données en entrée/sortie ou les étapes de calcul varient. La création du graphe de calcul au runtime donne aussi une vision des variables étape par étape et permet donc l’utilisation des outils de debugging qui nous sont familiers, comme pdb ou un debugger d’IDE. Cette souplesse s’accompagne généralement d’une perte d’efficacité, car le graphe est créé à chaque itération et certaines optimisations ne sont pas possibles.

TensorFlow a initialement été développé autour d’un graphe de calcul statique, qui est défini entièrement et une seule fois, avant d’effectuer les calculs. Un graphe statique permet notamment de meilleures optimisations de calculs et une représentation du modèle indépendante du code. Cette représentation permet une mise en production bien plus simple, surtout dans des environnements sans dépendance Python. Mais les graphes statiques sont aussi synonymes de rigidité et d’opacité, limitant l’expérimentation et rendant le debugging compliqué, nécessitant l’utilisation du debugger TensorFlow, tfdbg.

Aujourd’hui, PyTorch et TensorFlow ont beaucoup évolué. Comme nous le verrons par la suite, le développement de TensorFlow 2 et PyTorch 1 a tendance à faire converger ces deux frameworks. Pourtant, ils ne peuvent se défaire totalement de leur passé, qui a largement influencé leurs communautés qui restent encore assez distinctes, d’une part par leur taille mais aussi par les utilisations qui sont faites de ces deux solutions.

Pour ce qui est de la taille des communautés respectives, Google Trends donne un bon ordre de grandeur de leur évolution.

TensorFlow en rouge, PyTorch en bleu

Depuis sa sortie en 2017, PyTorch a gagné petit à petit en popularité. Cette montée en puissance s’est faite au détriment de TensorFlow qui a atteint un pic de popularité en 2018. Mais TensorFlow reste aujourd’hui plus recherché sur Google Search que PyTorch et d’autres métriques, comme le nombre de questions sur Stack Overflow ou le nombre d’articles Medium mentionnant ces frameworks, témoignent de l’importante communauté qui s’est constituée autour de TensorFlow.

Mais cette domination de TensorFlow ne concerne pas tous les domaines. Les principaux utilisateurs de frameworks de deep learning travaillent soit dans l’industrie, soit dans la recherche, et si TensorFlow domine dans le premier, c’est loin d’être le cas dans le second. Depuis sa sortie, la progression de PyTorch s’est principalement faite grâce au domaine de la recherche. Son importante flexibilité par rapport à TensorFlow et la facilité du debugging en sont des atouts considérables. L’évolution du nombre d’articles arXiv, une archive de prépublications électroniques d’articles scientifiques, mentionnant chaque framework montre que PyTorch a très vite rattrapé son retard dans ce domaine, allant même jusqu’à dépasser TensorFlow dans les premiers mois de 2020.

Cette croissance est plus évidente encore en regardant la proportion d’articles utilisant PyTorch ou TensorFlow dans les plus grandes conférences de recherche en statistiques et machine learning.

Source : https://chillee.github.io/pytorch-vs-tensorflow/

On comprend pourquoi, historiquement, l’industrie a eu une préférence pour TensorFlow. Ce framework a été construit avec l’objectif de satisfaire les besoins de mise en production. Le graphe peut facilement être utilisé dans un environnement où Python n’est pas utilisable ; l’inférence est rapide ; TensorFlow Lite permet d’exécuter des modèles sur appareils mobiles, embarqués et IoT ; et TensorFlow Serving permet la mise en production de systèmes d’inférence complexes et offre de nombreuses fonctionnalités. Au contraire, les chercheur·ses préfèrent un framework simple, souple et où l’expérimentation est plus aisée. Ils/elles ont rarement de soucis d’efficacité et n’utilisent que rarement des environnements de production. PyTorch est donc un meilleur candidat, bien plus “pythonique”, avec une API plus naturelle et plus facile à débugger.

Une convergence récente des frameworks

Avec la sortie de PyTorch 1 en octobre 2018 et TensorFlow 2 en septembre 2019, les deux frameworks essaient de rattraper le retard qu’ils ont l’un par rapport à l’autre.

PyTorch 1 cherche à faciliter la mise en production grâce à un compilateur JIT (“juste-à-temps”) torch.jit qui propose, à travers les modes tracing et scripting, deux méthodes d’export et d’optimisation de modèles vers une représentation indépendante de Python appelée TorchScript. Cette représentation donne accès aux avantages d’un graphe statique, et permet donc l’optimisation du graphe et de l’exportation dans un environnement sans dépendance Python. PyTorch propose maintenant TorchServe (qui résulte d’une collaboration entre Facebook et Amazon Web Services) pour la mise en production de systèmes d’inférence complexes, et PyTorch Mobile pour un déploiement sur mobile.

De son côté, TensorFlow 2 passe en eager mode par défaut, qui est un mode de définition de graphe dynamique. Ce mode apporte la même flexibilité que PyTorch, mais possède bien sûr les mêmes désavantages. Une transformation du code en eager mode vers une représentation de graphe statique peut se faire avec tf.function et Autograph, à la manière du compilateur JIT PyTorch.

Quelles différences subsistent ?

Si les frameworks se ressemblent de plus en plus et continuent de converger, des différences persistent entre TensorFlow et PyTorch au-delà des différences d’API qui sont plus de l’ordre de la préférence.

TensorFlow possède un excellent outil de visualisation, TensorBoard. Il permet de visualiser les données mais aussi l’évolution des variables et même une représentation du graphe de calcul. C’est un outil très facile à prendre en main et très utile, à tel point que l’équipe de PyTorch a développé le module torch.utils.tensorboard permettant d’utiliser TensorBoard dans PyTorch. L’utilisation de TensorBoard est toujours mieux intégrée dans TensorFlow, mais est donc désormais possible dans PyTorch.

Pour ce qui est de la mise en production, les outils PyTorch sont bien plus récents et donc encore en phase expérimentale, et risquent donc d’être moins stables que les outils TensorFlow qui existent depuis plusieurs années. PyTorch garde toujours l’avantage d’une intégration native d’ONNX (Open Neural Network Exchange), né d’une collaboration entre Facebook et Microsoft, rejoints ensuite par de nombreux grands acteurs de la tech (IBM, Huawei, Intel, AMD et d’autres) — mais pas Google. Ce format, qui facilite le transfert de modèle d’un framework vers un autre, peut être utilisé avec TensorFlow avec un convertisseur spécifique, mais n’est pas intégré nativement à TensorFlow.

Mais finalement, PyTorch ou TensorFlow ?

La réponse à la question “PyTorch ou TensorFlow ?” n’a donc pas de réponse évidente. La concurrence des deux frameworks est source d’innovation technique, mais aussi de convergence. Si l’un a l’avantage d’une communauté puissante, l’autre est aujourd’hui privilégié par la communauté de chercheur·ses dont une partie travaillera probablement dans l’industrie dans les années à venir, voulant peut-être continuer à utiliser leur framework favori. Des différences peuvent aussi exister sur des aspects très spécifiques, et les circonstances d’un projet ou la reprise de code existant peuvent favoriser l’un d’eux. Mais en dehors de ces cas particuliers, la réponse est peut-être simplement de choisir le framework avec lequel on préfère travailler. Chez Neoxia, nous avons jusqu’ici privilégié TensorFlow pour nos projets de deep learning, notamment pour son excellente intégration dans Google Cloud Platform. Mais nous nous assurons de garder nos connaissances à jour.

Quid, finalement, du choix à faire si l’on débute entièrement en deep learning ? La présence dans votre entourage d’une personne expérimentée pourra être la clé de votre décision : en complément des communautés Stack Overflow, leur aide se révèlera précieuse pour débugger vos modèles et améliorer vos programmes, et rendra sans doute votre apprentissage bien plus agréable !

--

--

--

The 360 cloud company! https://www.neoxia.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Owain Biddulph

Owain Biddulph

More from Medium

Self Assessment

‘Magic’

Letter from DWE.Oracle #1

The Midnight Library: A Life Lesson for Young-Adulthood