Comment scaler une IA ?
Comment faire en sorte qu'un modèle de machine learning (ML) passe sans encombre l'étape du déploiement quel que soit le contexte (cloud, edge ou IoT) ? Comment le mettre également en capacité d'encaisser les pics de trafic ? Historiquement, les data scientists ont tendance à éluder ces questions, laissant aux data ingénieurs le soin de les gérer. Résultats : des projets vont droit dans le mur, incapables de passer le cap de la mise en production. Avec le temps et l'expérience, les équipes s'adaptent. Et les fournisseurs de solutions d'IA aussi. Face à la problématique du scaling, une méthode commence désormais à se dessiner assez clairement.
1. Choisir une plateforme
Certains data scientits puristes sont tentés de programmer leur modèle de à A à Z en Python, en utilisant des notebooks et une architecture open source type Kubernetes. "C'est une erreur. Les retours d'expérience montrent qu'un projet sera beaucoup plus rapide en optant pour une plateforme du marché", explique Didier Gaultier, directeur data science & AI chez Business & Decision (groupe Orange). "Dans certains cas, le temps de mise en œuvre sur des projets de plusieurs centaines de jours/homme peut être divisé par quatre."
En matière de plateforme d'IA, on a l'embarra du choix. Côté fournisseurs de cloud, Amazon, Google et Microsoft proposent respectivement SageMaker, Vertex et Azure ML. Quant aux offres des pures player comme Snowflake et Databricks, elles viennent se poser sur les infrastructures de chacun de ces IaaS. Pour finir, Alteryx et Knime se positionnent comme des plateformes d'IA portables quel que soit le cloud (privé ou public). Principal avantage ? Toutes ces solutions intègrent les briques nécessaires au déploiement : gestion des pipelines de données, monitoring, gestion du réapprentissage des modèles... Jusqu'au dimensionnement automatique des ressources machines (autoscaling) et les déploiements sur des appareils IoT dans le cas des cloud providers.
2. Adopter une approche MLOps
Pièce maîtresse de l'industrialisation du machine learning, le MLOps vise à concevoir des modèles d'IA adaptés à leur déploiement en production. Le français DataiKu et l'américain DataRobot se positionnent sur ce segment. C'est aussi le cas de la solution open source MLFlow, ainsi que de Kubeflow, la non moins célèbre brique de Google conçue pour déployer du ML sur une infrastructure Kubernetes (lire l'article : Comparatif MLOps : Dataiku et DataRobot face aux alternatives open source).
Dans la logique du DevOps, le MLOps ambitionne de casser les murs entre data scientists et data ingénieurs. L'enjeu ? Prendre en considération les contraintes de mise en production dès la phase de création des modèles. A l'instar du DevOps pour les applications, le MLOps doit aboutir à la mise en place de pipelines d'intégration et de livraison continues (CI/CD). Ces derniers ayant pour vocation d'automatiser et de monitorer tout le cycle de vie des modèles, des phases de test de non régression jusqu'au déploiement de ces derniers avec toutes leurs bibliothèques associées.
3. Se doter d'un feature store
Brique centrale du MLOps, le feature store consolide les workflows de machine learning, qu'ils soient dédiés à l'apprentissage ou aux résultats de terrain (inférence), autour d'un pipeline d'attributs et de variables prédictives (features) de référence. "Plus votre feature store sera optimisé, plus vos modèles seront simples. Vous aboutirez ainsi de facto à des réseaux de neurones qui compteront moins de neurones, voire des modèles plus simples type forêt aléatoire, boosting de gradient ou bagging. Ce qui demandera moins de ressources pour l'entrainement et le réentrainement, des étapes par définition très consommatrices en capacité de calcul, mais aussi pour le déploiement", détaille Didier Gaultier.
Eviter de passer par les réseaux de neurones permet également de rendre les résultats plus facilement explicables tout en réduisant les risques de biais inhérents aux modèles complexes.
4. Opter pour une mode d'inférence adapté
Lors de la mise en production, on pourra opter pour deux modes d'exécution : traiter les prédictions en temps réel (online inference) ou bien les regrouper et les exécuter par lots (batch inference). "La première solution contribue à réduire la puissance machine nécessaire, mais au détriment du temps de réponse qui sera plus long", concède Julien Salinas, fondateur et CTO chez NLP Cloud. Cependant, le batch ne sera pas adapté pour toute les applications, en particulier s'il s'agit de motoriser un assistant intelligent pour lequel les réactions attendues sont censées être instantanées.
"En revanche pour la génération de texte ou le résumé de document, les utilisateurs sont en général prêts à attendre quelques minutes. Ce qui peut permettre de passer par un traitement par lots", reconnait Julien Salinas.
5. Optimiser la taille du modèle
Les réseaux de neurones resteront souvent un point de passage obligé pour le traitement automatique du langage ou la reconnaissance d'image. Plusieurs techniques permettront de réduire leur taille et donc d'optimiser leur performance d'exécution. C'est le cas du pruning par exemple, qui consiste à supprimer des nœuds du réseau, dont le poids est faible ou nul. Ou encore de la quantisation en virgule flottant, qui permet d'encoder les nœuds sur un nombre de bits moins élevé, par exemple sur 8 bits au lieu de 32 ou 64 bits. Ce qui contribue, au final, à alléger la charge de calcul. Deux méthodes notamment utilisées pour les déploiements sur des appareils de faibles capacités (IoT)
"Pour les grands réseaux comme GPT-3 qui compte 175 milliards de paramètres, on pourra opter pour des modèles distillés", poursuit Julien Salinas. Grâce à cette méthode, Hugging Face est parvenu à réduire de 40% les 110 millions de paramètres de BERT, le modèle de NLP de Google. Baptisée DistilBERT, la déclinaison développée par la start-up française se veut 60% plus rapide tout en préservant 95% de la performance en termes de précision. "Mais il n'est pas forcément utile d'opter pour un gros réseau de neurones généraliste. Dans la plupart des cas, mieux vaudra partir sur un modèle spécialisé sur une tâche et beaucoup plus petit, par exemple pour la classification de texte ", reconnait Julien Salinas.
6. Définir la bonne architecture
Pour encaisser d'importants volumes de trafic, il sera nécessaire de répliquer l'application sur des grappes de serveurs. Ici, la méthode est la même que pour un site web traditionnel. On pourra par exemple déployer Kubernetes associé à la brique Kubeflow. "Les feature store pourront être portés sur la même architecture pour gérer les données entrantes, que ce soit en batch ou en temps réel", souligne Didier Gaultier chez Business & Decision. Pour les gros modèles, ce scaling vertical pourra être doublé d'un scaling horizontal. Une méthode qui consiste à découper le modèle pour le répartir sur de multiples GPU.
Enfin, dans le cas de l'IA factory d'un grand groupe, une architecture Kubernetes peut être amenée à gérer des centaines de modèles tournant en parallèle, à destinations de multiples business unit. Avec à la clé la nécessité de redéployer un modèle immédiatement en cas de plantage. "Dans un tel contexte, mieux vaut sous-traiter le monitoring à un éditeur, qui jouera le rôle de tiers de confiance", recommande Julien Salinas.