Projet AI : déploiement des modèles sur GCP

Kais Arbi
neoxia
Published in
6 min readOct 15, 2020

Vous avez entraîné vos modèles sur des machines puissantes avec plusieurs GPUs ? Vous avez fait des tests et obtenu un modèle avec la précision attendue ? Il est temps de déployer ce modèle en production afin d’en tirer tous les bénéfices attendus.

Pourtant, dans le monde de la data science et du machine learning, nombreux sont les modèles qui n’arrivent jamais jusqu’à cette étape cruciale: le déploiement en production. Le manque de précision des modèles, ou d’expertise sur l’industrialisation de ces derniers (surtout les plus complexes), sont des raisons qui freinent cette mise en production. Souvent, ces projets finissent par être abandonnés et leurs modèles restent cantonnés au stade de proof of concept (POC).

“No machine learning model is valuable, unless it’s deployed to production.” — Luigi Patruno

Chez Neoxia, nos projets finissent souvent par être déployés au sein des architectures cloud de nos clients. En plus de l’exploration des données, de l’extraction des informations utiles et de la création des modèles, nos data scientists full stack doivent donc aussi être en capacité de les mettre en production.

Une de nos missions récentes consistait à prédire la quantité de gaz consommée à tous les postes du réseau du gestionnaire de gaz français Teréga, ces prévisions devant être générées toutes les heures pour prédire les 48 prochaines heures. Une fois l’exploration finie et que le modèle répond au besoin en termes de précision, il faut l’industrialiser.

Dans cet article, nous allons nous intéresser à cette partie du projet : l’industrialisation du modèle.

Un pipeline “schédulé” et 100 % cloud

Notre déploiement de modèles prédictifs pour ce projet a été entièrement réalisée dans Google Cloud Platform (GCP). Il peut être résumé par les étapes suivantes :

  1. Création des services GCP nécessaires grâce à Terraform
  2. Dépôt des modèles dans des buckets Cloud Storage
  3. Déploiement d’un script Airflow pour automatiser l’exécution du pipeline
  4. Appels API aux modèles déployés sur AI Platform
  5. Stockage des résultats dans BigQuery

Étape 1 : création des services GCP nécessaires grâce à Terraform

Le but de “terraformer” une architecture est donc de pouvoir automatiser la création des ressources nécessaire pour le déploiement d’un modèle. Cela permettra de reproduire facilement et avec précision les services nécessaires à la mise en production d’un modèle, sans devoir passer par une création manuelle des services cloud. Afin d’héberger les modèles sur GCP, nous aurons besoin a minima de trois types de ressources.

AI Platform

AI Platform permet d’héberger dans le cloud votre modèle ML entrainé afin de lui envoyer des requêtes API pour générer des prédictions. Une fois satisfait de la précision de votre modèle, vous pouvez l’exporter dans un format sérialisé. En fonction des librairies utilisées pour développer le modèle, vous exportez votre modèle en format Pickle pour les modèles scikit-learn ou SavedModel pour TensorFlow. Vous devez ensuite créer une ressource de modèle sur AI Platform et la pointer vers le bucket Cloud Storage où sera déposé le modèle. Terraform s’occupera alors de créer un modèle sur AI Platform basé sur le bucket correspondant.

Cloud Storage

Cloud Storage vous permet de stocker en ligne des fichiers/objets. Vos modèles seront ainsi stockés dans des “buckets” créés via Terraform, et vers lesquels pointeront les modèles créés dans AI Platform. Les buckets conserveront toutes les versions des modèles ; mais seule la dernière sera utilisée pour générer les prédictions.

Cloud Function

Cloud Function assure le déclenchement d’une fonction d’être déclenchée une fois le modèle déposé dans le bucket. Elle permet d’exécuter un code fourni pour créer une nouvelle version du modèle déposé sur GCS. Cette nouvelle version sera configurée comme la version par défaut du modèle, afin de garantir l’utilisation de la dernière version développée par les data scientists.

Étape 2 : dépôt des modèles dans des buckets Cloud Storage

Le dépôt des modèles dans les buckets créées par Terraform permettra donc la création d’une nouvelle version des modèles dans AI Platform. Tout cela se fait d’une manière automatique via la Cloud Function. La nouvelle version devient donc celle par défaut, mais on conservera également l’historique des versions déployées, afin de pouvoir revenir à une version donnée en cas de besoin.

Étape 3 : déploiement d’un script Airflow pour automatiser l’exécution du pipeline

Afin de pouvoir générer des prédictions chaque heure, nous avons utilisé l’outil open source Airflow (précédemment décrit par notre lead data dans un autre article), permettant d’orchestrer des workflows, et de créer, planifier et surveiller vos pipelines à travers des scripts nommés DAGs (Directed Acyclic Graphs). Cloud Composer est la version managée d’Airflow proposée par Google.

Notre orchestrateur Airflow va collecter les données de plusieurs sources et faire les différentes opérations et transformations afin de reproduire le pipeline de transformation appliquée aux données pour entraîner les modèles. Ces transformations vont permettre, en fin de DAG, d’obtenir des inputs acceptés par les modèles précédemment déployés sur AI Platform.

Nos principales sources de données pour ce projet étaient BigQuery (permettant de récupérer des données via des requêtes SQL) et BigTable (NoSQL).

Étape 4 : appels API aux modèles déployés sur AI Platform

AI Platform fournit une API permettant d’appeler les modèles déployés dans le cloud. Ces prédictions peuvent se faire de deux façons : online prediction et batch prediction.

Le mode batch prediction est utile pour des prédictions en masse : la procédure va allumer des machines qui vont traiter les prédictions de façon asynchrone et déposer les résultats dans un bucket Google Cloud Storage.

Au contraire, le mode online prediction permet de solliciter les modèles d’une façon quasi instantanée. Il est recommandé en cas de d’une faible volumétrie de donnée et afin d’optimiser la latence.

Dans cette industrialisation, nous nous sommes contentés de faire des online predictions, couplées à un système de batch qui envoie aux modèles le volume maximal de données supportées au sein d’une même requête de prédiction. Cela nous a permis de réduire la latence et de contourner la limite de taille maximale.

Étape 5 : stockage des résultats dans BigQuery

Les prédictions renvoyées par les modèles d’AI Platform sont finalement traitées et formatées pour suivre le schéma d’une table BigQuery où Terega souhaite stocker les résultats.

L’identifiant du poste à prédire, la date de génération des prédictions, le nom du modèle qui a généré les prédictions, un indicateur sur l’heure prédite et la plage horaire de la volumétrie de gaz à prédire, et bien évidemment le volume de consommation du poste, sont insérés dans cette table. Ces étapes permettent d’alimenter la table de stockage des prévisions chaque heure par les prédictions des consommations de gaz des différents postes de Teréga.

Conclusion

Dans cette expérience de mise en production de modèles deep learning, et plus particulièrement de modèles LSTMs, le plus gros verrou a été de reproduire fidèlement le pipeline de collecte, de traitement, et de pre-processing des données utilisées lors du développement des modèles originaux. Elle impliquait plusieurs sources de données et des transformations de données complexes, avec des observations temporelles en trois dimensions, tout en respectant l’ordre des posts à prédire. Tandis que ce pipeline était en “one-shot” lors du cycle du développement, une fois en production et pour être capable de fournir des prédictions, elle doit s’exécuter toutes les heures. Pour dépasser cette complexité, il est impératif de rationaliser ce pipeline en la découpant en des sous-tâches pour assurer la cohérence de l’entrée et de la sortie de chaque sous-partie.

La complexité de l’industrialisation d’un modèle de machine learning ou de deep learning ne doit jamais être négligée. Pour dépasser l’étape du POC, la mise en production représente le “premier jour” dans la vie d’un modèle et dans certains cas, on pourra même considérer cette étape comme un véritable projet à part !

Références : Machine learning workflow | AI Platform

--

--