Cela fait maintenant plusieurs années que l’on entend parler de la multitude de frameworks pour construire et entraîner des modèles de Machine Learning (scikit-learn, TensorFlow, Keras, statsmodel, etc.). Cependant, dans de nombreux projet ayant vocation d’aller en production, un autre aspect est bien moins mentionné : le serving des modèles.
De quoi parle-t-on exactement ?
Le serving d’un modèle de Machine Learning correspond à la phase de mise à disposition de ce dernier, une fois entraîné, à un système tierce qui va l’utiliser pour produire un résultat. Nous nous situons donc à la croisée des chemins entre l’entraînement des modèles et leur utilisation dans des applications.
L’ennui, c’est que bien souvent, les Data Scientists utilisent leurs propres outils et frameworks pour entraîner leurs modèles, alors que les développeurs chargés de leur exploitation en production possèdent des outils bien différents. Il faut donc trouver un terrain d’entente pour favoriser la bonne communication entre les deux mondes.
Au final, on se rend compte qu’il y a deux phases distinctes dans cette problématique :
- l’export des modèles dans un format cible, c’est-à-dire son format de sauvegarde / sérialisation, qui peut être dépendant ou non du framework utilisé pour l’entraînement
- le serving du modèle sérialisé à proprement parler, c’est à dire sa mise à disposition pour un système tierce.
Au fur et à mesure des années et de l’augmentation des cas d’usage du Machine Learning, ainsi que du nombre de frameworks disponibles, beaucoup de grandes entreprises se sont mises à construire leurs propres plateformes de serving et de gestion de modèles. C’est le cas d’Uber avec sa plateforme interne Michelangelo, de Google avec TFX (TensorFlow eXtended) et de Facebook avec FBLearner Flow.
Ces plateformes vont au-delà du simple serving de modèles, elles sont créées pour couvrir l’intégralité du cycle de vie des modèles de Machine Learning : gestion de la donnée, entraînement de modèles, évaluation de performances, déploiement de modèles, prédictions et monitoring.
Et nous que pouvons-nous faire pour mettre à disposition proprement nos modèles à nos applications ? L’une des manières de faire les plus simples est d’exposer une donnée ou un modèle avec une API REST via l’utilisation de librairies comme Flask. Bien que cette solution puisse convenir pour certains Use Cases comme des applications internes où l’environnement technique reste le même de bout en bout, elle est en général insuffisante pour passer à l’échelle en termes d’utilisation ou de respect de contraintes de production.
Heureusement pour nous, il existe de plus en plus d’outils à notre disposition pour gérer le serving de modèles de Machine Learning, mais aussi des propositions de formats de sérialisation permettant de standardiser l’utilisation de ces modèles, indépendamment du framework utilisé pour l’entraînement, afin de dissocier complètement ces deux phases.
Deux écoles pour exporter son modèle
Utiliser le format de sérialisation standard du framework utilisé pour l’entraînement
Chaque framework de Machine Learning propose un ou plusieurs moyens d’exporter les modèles entraînés. Citons par exemple :
- pickle pour scikit-learn
- protobuf pour TensorFlow
- HDF5 pour Keras
- parquet pour Spark (API DataFrame)
Dans de nombreux cas de figure, le choix est fait de développer une API pour chaque framework utilisé, et donc chaque format de stockage, laissant libre cours aux Data Scientists d’utiliser l’outil de leur choix pour le développement et l’entraînement de leurs modèles.
Cette manière de faire est probablement l’une des plus communément utilisées aujourd’hui, dans la mesure où le nombre de frameworks utilisés reste en général restreint. Cela permet aussi de rester flexible en termes d’utilisation finale de ce modèle (batch vs streaming). C’est aussi la seule solution s’offrant à nous dans un cas particulier où l’entraînement et la prédiction se font à la volée (le modèle se met à jour au fur et à mesure de l’arrivée de la donnée, c’est ce qu’on appelle du online learning).
Utiliser un format intermédiaire pour la sérialisation
Une autre tendance qui prend de l’ampleur est de trouver un format de sérialisation des modèles qui soit indépendant des frameworks utilisés pour l’entraînement, permettant leur utilisation dans n’importe quel contexte et n’importe quelle application. Cela va souvent être le cas lorsque le système utilisant le modèle a pour contrainte de tourner sur une JVM alors que le modèle a été entraîné sur une infrastructure différente (en local avec du Python par exemple).
C’est l’approche préconisée dans le livre publié par Lightbend « Serving Machine Learning Models » pour des utilisations dans des contextes de temps réel.
Certains formats commencent à faire leur apparition pour proposer cette représentation intermédiaire des informations et ainsi se libérer de la dépendance à un framework ou un outil. En voici deux exemples :
- PMML (Predictive Model Markup Language) : un format de sérialisation de modèles basé sur du XML. Ce format permet de sérialiser à la fois le modèle et les transformations de la donnée en amont (normalisation, discrétisation, aggrégations, etc.).
- PFA (Portable Format for Analytics) : un format de sérialisation de modèles basé sur du JSON, et se veut être un format plus flexible que PMML.
[Source : http://dmg.org/pfa/docs/motivation/]
Tous les types de modèles ne sont cependant pas encore exportables dans ces formats, et tous les frameworks ne possèdent pas encore des convertisseurs vers ces formats.
Un autre format, ONNX, a été créé par Facebook et Microsoft pour permettre une plus grande interopérabilité entre les frameworks pour les modèles de Deep Learning. Parmi les frameworks aujourd’hui supportés, on retrouve PyTorch, CNTK, MXNet, Caffe2, ainsi que des convertisseurs pour TensorFlow entre autres.
Frameworks proposant des solutions de bout en bout
Afin de pouvoir mettre en place du serving de modèles, certains frameworks et plateformes proposent des solutions d’utilisation de ces modèles de bout en bout, de leur entraînement à leur déploiement.
TensorFlow Serving
TensorFlow Serving est l’outil utilisé en production chez Google pour le serving de leurs modèles. Cette brique a récemment été rendue open-source afin de permettre aux utilisateurs d’aller un cran plus loin dans l’utilisation de leurs modèles TensorFlow, bien qu’elle puisse aussi être utilisée pour d’autres frameworks.
Sérialisation de pipelines complètes avec Spark
Le serving de modèles, voir même de pipelines complètes, en Spark a été grandement simplifié avec l’API basée sur les DataFrames de Spark ML. A partir de la version 2.0 de Spark, tous les modèles et pipelines sont sérialisables au format parquet, et réutilisables à souhait dans des jobs Spark en mode batch, ou bien via l’utilisation de Spark Streaming.
Model Server pour MXNet
Les équipes de développement d’AWS ont récemment rendu open-source un model server pour le framework de Deep Learning MXNet ainsi que pour Gluon, le framework haut niveau basé entre autres sur MXNet. Ce model server est livré sous forme d’image Docker, et offre l’avantage de pouvoir packager du code pour le Feature Engineering pour qu’il soit utilisé côté serveur.
Autres
Les exemples précédents n’étaient qu’un échantillon. D’autres outils existent, notamment pour des problématiques de Deep Learning. Citons par exemple :
- DeepDetect : Outil de serving open source pour le Deep Learning intégrant du Caffe, TensorFlow et MXNet
- TensorRT : Outil de serving proposé par NVidia, intégrant du TensorFlow, PyTorch, MXNet, Caffe et CNTK
Et bien entendu, il ne faut pas oublier les services managés qui proposent toute une panoplie d’outils pour gérer le cycle de vie de vos modèles. On peut penser à Amazon SageMaker et à Google Cloud ML.
Plateformes indépendantes du framework utilisé pour l’entraînement
Au-delà des plateformes propriétaires, certains outils open-source permettent de gérer le cycle de vie de ses modèles, et donc la partie serving de ces derniers. C’est le cas de clipper.ai qui propose un outil simple pour faire du serving des prédictions avec une faible latence. Il peut simplement s’utiliser avec des gestionnaires de conteneurs tels que Docker ou Kubernetes.
D’autres outils comme MLeap, ou plus récemment MLFlow ont récemment fait leur apparition, s’inscrivant dans cette volonté de rendre open-source des plateformes complètes de Machine Learning, gérant leur cycle de vie complet. Ces outils sont à surveiller, et peuvent constituer l’avenir de la gestion des projets de Data Science.
Trouver la solution adaptée à ses besoins
On se doute bien que tout n’est pas noir ou blanc.
L’idée principale à retenir et à appliquer est la suivante : laisser à chacun la possibilité de travailler sur les outils sur lesquels il peut exprimer pleinement son travail.
En ce qui concerne l’export et le serving de modèles, cela revient à établir un « contrat d’interface » (un format d’échange donc) entre le modèle sauvegardé et son utilisation par un système tierce.
Le choix d’une solution plutôt que d’une autre va aussi être conditionnée par l’utilisation cible du modèle. Les déploiements et les besoins seront en effet différents si l’utilisation du modèle se fait par batch ou bien dans des applications temps réel. Quelques exemples (liste non exhaustive) sont donnés dans le schéma ci-dessous.
Références
- The rise of model servers (Medium)
- Introducing MLFlow, an open-source Machine Learning Platform (DataBricks)
- Déploiement continu de modèles de Machine learning (XebiCon 17)
- Serving Machine Learning Models (LightBend)