Deep learning : 5 raisons de choisir PyTorch (1e Partie)

Il ne fait aucun doute que PyTorch est à la mode, et encore plus depuis la sortie des dernières versions 1.3 et 1.4 qui offrent un tas d'améliorations de performance, sans compter un support plus convivial pour les développeurs de plateformes mobiles. Mais pourquoi choisir PyTorch plutôt que d'autres frameworks comme MXNet, Chainer ou TensorFlow ? Voilà cinq raisons qui plaident en faveur de PyTorch.

Mais pour commencer, et pour ne pas fâcher les utilisateurs de TensorFlow, il faut dire qu’il y a aussi de nombreuses raisons de choisir TensorFlow plutôt que PyTorch, surtout si vous ciblez les plateformes mobiles ou web. En clair, il ne s’agit pas ici de montrer que « TensorFlow est nul » et que « PyTorch est génial », mais de présenter divers aspects de PyTorch qui, ensemble, justifient la préférence pour ce framework. Mais encore une fois, TensorFlow reste formidable à sa manière. Alors, pas d’emballement !

PyTorch, c’est du Python

L'une des principales raisons pour lesquelles les gens choisissent PyTorch, c’est que le code est assez simple à comprendre. Le framework est conçu et assemblé pour fonctionner avec Python. Les modèles et les couches sont des classes Python, tout comme le reste : optimiseurs, chargeurs de données, fonctions de perte, transformations, etc. Grâce au mode d'exécution rapide de PyTorch, différent du graphe d'exécution statique de TensorFlow traditionnel (oui, TensorFlow 2.0 offre une exécution rapide, mais il est parfois un peu maladroit), il est très facile de raisonner sur les classes PyTorch personnalisées, et l’on peut se lancer dans le débogage avec TensorBoard ou des techniques Python standard, depuis les instructions print() jusqu'à la génération de Flame Graph à partir d'échantillons de traces d’appel ou track trace.

Tout cela rend l’environnement très accueillant pour ceux qui débarquent dans l’apprentissage profond après avoir utilisé d’autres frameworks de data science comme Pandas ou Scikit-learn. PyTorch a également l'avantage d’une API stable, car il n'a subi qu'un seul changement majeur depuis les premières versions jusqu'à la version 1.3 (à savoir le passage des variables aux tenseurs). Même s’il faut sans aucun doute mettre cela au crédit de son jeune âge, la grande majorité du code PyTorch que l’on rencontre dans la nature est reconnaissable et compréhensible, quelle que soit la version pour laquelle il a été écrit.

PyTorch est livré prêt à l'emploi

Si la philosophie « prêt à l’emploi » n'est certainement pas exclusive à PyTorch, il est particulièrement facile de démarrer avec le framework. En utilisant PyTorch Hub, on peut obtenir un modèle ResNet-50 pré-entrainé avec une seule ligne de code :

model = torch.hub.load('pytorch/vision', 'resnet50', pretrained=True)

Et PyTorch Hub est unifié à travers les domaines, ce qui en fait un guichet unique pour les architectures permettant de travailler aussi bien avec du texte et de l'audio qu'avec de la vision. Comme on pourrait s’y attendre, en plus des modèles, PyTorch est livré avec un grand nombre de fonctions de perte et d'optimiseurs, mais il offre aussi des solutions simples pour charger les données et enchaîner les transformations intégrées. Il est également assez simple de construire ses propres chargeurs ou transformateurs. Comme tout est en Python, il suffit de mettre en place une interface de classe standard. Cependant, petite mise en garde s'impose : la plupart des fonctions fournies avec PyTorch ont été conçues de manière à résoudre des problèmes de vision (que l'on trouve dans le paquet torchvision), et certaines des fonctions de support texte et audio sont plus rudimentaires. Mais, heureusement, dans les versions post-1.0, les paquets torchtext et torchaudio ont été considérablement améliorés.

PyTorch est très utilisé dans la recherche

PyTorch est le paradis des chercheurs. On peut le constater en lisant les articles présentés lors de toutes les grandes conférences sur le deep learning. Si PyTorch a connu une croissance rapide en 2018, en 2019, il est devenu le framework de prédilection de la Conference on Computer Vision and Pattern Recognition (CVPR), la conférence scientifique annuelle de l'IEEE en reconnaissance des formes et vision par ordinateur, de la Conférence internationale sur les représentations en apprentissage (International Conference on Learning Representation - ICLR) » et du CILM, pour ne citer que celles-là. Cette adhésion sans réserve est certainement liée à la première raison mentionnée ci-dessus : PyTorch, c’est du Python.

Il est beaucoup plus facile d’expérimenter de nouveaux concepts quand les nouveaux composants personnalisés que l’on peut créer sont une sous-classe simple et stable d'une classe Python standard. Et cette flexibilité signifie que si l’on veut écrire une couche qui envoie des informations de paramètres à TensorBoard, à ElasticSearch, ou à un bucket Amazon S3…, on peut le faire. Vous voulez extraire des données de bibliothèques ésotériques et les utiliser en ligne avec de l’apprentissage en réseau ou essayer une boucle d’apprentissage bizarre ? PyTorch ne vous en empêchera pas.

Un léger handicap de PyTorch concerne l'absence de chemin clair menant de la recherche à la production. En effet, TensorFlow domine toujours en matière de mise en production, quelle que soit l'importance du travail de recherche réalisé avec PyTorch. Mais depuis PyTorch 1.3 et l'extension de TorchScript, il est plus facile d'utiliser les annotations Python qui s’appuient le moteur JIT pour compiler le code de recherche dans une représentation graphique, avec les accélérations qui en résultent et l'exportation facile vers un runtime C++. Et désormais, l'intégration de PyTorch avec Seldon Core et Kubeflow est supportée, ce qui permet des déploiements en production sur Kubernetes presque (pas tout à fait) aussi simples qu'avec TensorFlow.