Comment Veriff a réduit le temps de déploiement de 80% en utilisant les points de terminaison multi-modèles d’Amazon SageMaker

Comment Veriff a réduit de 80% le temps de déploiement en utilisant les points de terminaison multi-modèles d'Amazon SageMaker

Veriff est une plateforme de vérification d’identité qui collabore avec des organisations innovantes axées sur la croissance, notamment des pionniers dans les services financiers, la FinTech, la crypto-monnaie, le jeu, la mobilité et les places de marché en ligne. Ils fournissent une technologie avancée qui associe l’automatisation alimentée par l’IA à un retour d’informations humaines, à des connaissances approfondies et à une expertise.

Veriff propose une infrastructure éprouvée qui permet à ses clients d’avoir confiance en l’identité et aux attributs personnels de leurs utilisateurs tout au long de leur parcours client. Veriff est une entreprise de confiance pour des clients tels que Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot et Wise.

En tant que solution alimentée par l’IA, Veriff a besoin de créer et d’exécuter des dizaines de modèles d’apprentissage automatique (ML) de manière rentable. Ces modèles vont des modèles légers basés sur les arbres aux modèles informatiques de vision par apprentissage profond, qui doivent fonctionner sur des GPU pour atteindre une faible latence et améliorer l’expérience utilisateur. Veriff ajoute également actuellement davantage de produits à son offre, en visant une solution hyper-personnalisée pour ses clients. Le fait de servir différents modèles à différents clients nécessite une solution d’approvisionnement de modèles évolutive.

• New York City présente son plan d’action sur l’IA
• Des chercheurs de CMU et de Google DeepMind présentent AlignProp une approche d’intelligence artificielle basée sur la rétropopagation directe pour affiner les modèles de diffusion texte-image pour une fonction de récompense souhaitée.
• Créez votre application d’intelligence artificielle Full-stack avec ReactPy

Dans cet article, nous vous montrons comment Veriff a normalisé son flux de déploiement de modèles en utilisant Amazon SageMaker, ce qui réduit les coûts et le temps de développement.

Défis d’infrastructure et de développement

L’architecture en arrière-plan de Veriff est basée sur un modèle de microservices, avec des services fonctionnant sur différents clusters Kubernetes hébergés sur l’infrastructure AWS. Cette approche était initialement utilisée pour tous les services de l’entreprise, y compris les microservices qui exécutent des modèles d’apprentissage automatique de vision par ordinateur coûteux.

Certains de ces modèles nécessitaient un déploiement sur des instances GPU. Consciente du coût relativement élevé des types d’instances avec GPU, Veriff a développé une solution personnalisée sur Kubernetes pour partager les ressources d’un GPU donné entre les différentes réplicas de service. Un seul GPU a généralement suffisamment de mémoire VRAM pour stocker plusieurs modèles de vision par ordinateur de Veriff en mémoire.

Bien que cette solution ait permis de réduire les coûts liés aux GPU, elle a aussi entraîné une contrainte : les scientifiques des données devaient indiquer à l’avance la quantité de mémoire GPU requise par leur modèle. De plus, l’équipe DevOps était chargée de la provision manuelle des instances GPU en fonction des schémas de demande. Cela entraînait une surcharge opérationnelle et une surprovision d’instances, ce qui se traduisait par un profil de coûts sous-optimal.

En plus de la fourniture de GPU, cette configuration nécessitait également que les scientifiques des données construisent un wrapper API REST pour chaque modèle, nécessaire pour fournir une interface générique aux autres services de l’entreprise, ainsi que pour encapsuler la prétraitement et le post-traitement des données des modèles. Ces APIs devaient être de qualité de production, ce qui rendait difficile la mise en production des modèles pour les scientifiques des données.

L’équipe de la plateforme de science des données de Veriff a recherché des alternatives à cette approche. L’objectif principal était de soutenir les scientifiques des données de l’entreprise dans une meilleure transition de la recherche à la production en leur fournissant des pipelines de déploiement plus simples. L’objectif secondaire était de réduire les coûts opérationnels de provisionnement des instances GPU.

Aperçu de la solution

Veriff avait besoin d’une nouvelle solution qui résolvait deux problèmes :

• Permettre de construire facilement des wrappers API REST autour des modèles ML
• Permettre de gérer de manière optimale et, si possible, automatique la capacité des instances GPU provisionnées

Finalement, l’équipe de la plateforme d’apprentissage automatique s’est orientée vers la décision d’utiliser les points de terminaison multi-modèles de Sagemaker (MMEs). Cette décision était motivée par le support de MME pour le Triton Inference Server de NVIDIA (un serveur axé sur l’apprentissage automatique qui facilite la création de modèles en tant qu’API REST ; Veriff expérimentait déjà Triton), ainsi que sa capacité à gérer nativement le dimensionnement automatique des instances GPU via des politiques de dimensionnement automatique simples.

Deux MMEs ont été créés chez Veriff, un pour le staging et un pour la production. Cette approche leur permet d’exécuter des étapes de test dans un environnement de staging sans affecter les modèles de production.

SageMaker MMEs

SageMaker est un service entièrement géré qui offre aux développeurs et aux scientifiques des données la possibilité de créer, former et déployer rapidement des modèles ML. Les MME SageMaker offrent une solution évolutive et rentable pour le déploiement d’un grand nombre de modèles pour l’inférence en temps réel. Les MME utilisent un conteneur de service partagé et une flotte de ressources pouvant utiliser des instances accélérées telles que des GPUs pour héberger tous vos modèles. Cela réduit les coûts d’hébergement en maximisant l’utilisation des points de terminaison par rapport à l’utilisation de points de terminaison de modèle unique. Cela réduit également les frais généraux de déploiement car SageMaker gère le chargement et le déchargement des modèles en mémoire et les met à l’échelle en fonction des schémas de trafic des points de terminaison. De plus, tous les points de terminaison en temps réel de SageMaker bénéficient de fonctionnalités intégrées de gestion et de surveillance des modèles, telles que l’inclusion de variantes d’ombre, redimensionnement automatique et une intégration native avec Amazon CloudWatch (pour plus d’informations, voir les métriques CloudWatch pour les déploiements de points de terminaison multi-modèles).

Modèles Triton ensemble personnalisés

Veriff a décidé d’utiliser Triton Inference Server pour plusieurs raisons :

• Il permet aux scientifiques de données de créer des APIs REST à partir de modèles en organisant les fichiers d’artefacts de modèle dans un format de répertoire standard (sans solution de code)
• Il est compatible avec tous les principaux frameworks d’IA (PyTorch, Tensorflow, XGBoost, et plus encore)
• Il offre des optimisations spécifiques à l’apprentissage automatique au niveau bas et au niveau du serveur, telles que le groupage dynamique des requêtes

Utiliser Triton permet aux scientifiques de données de déployer des modèles facilement car ils n’ont besoin de construire que des dépôts de modèles formatés au lieu d’écrire du code pour construire des APIs REST (Triton prend également en charge des modèles Python si une logique d’inférence personnalisée est requise). Cela réduit le temps de déploiement des modèles et permet aux scientifiques de données de se concentrer davantage sur la construction de modèles au lieu de les déployer.

Une autre caractéristique importante de Triton est qu’il permet de construire des ensembles de modèles, qui sont des groupes de modèles enchaînés. Ces ensembles peuvent être exécutés comme s’il s’agissait d’un seul modèle Triton. Veriff utilise actuellement cette fonctionnalité pour déployer une logique de prétraitement et de post-traitement avec chaque modèle ML en utilisant des modèles Python (comme mentionné précédemment), garantissant ainsi l’absence de divergences dans les données d’entrée ou de sortie du modèle lorsqu’il est utilisé en production.

Voici à quoi ressemble typiquement un dépôt de modèles Triton pour cette charge de travail :

Le fichier model.py contient le code de prétraitement et de post-traitement. Les poids du modèle entraîné se trouvent dans le répertoire screen_detection_inferencer, sous la version 1 du modèle (dans cet exemple, le modèle est au format ONNX, mais il peut également être au format TensorFlow, PyTorch ou autre). La définition du modèle ensemble se trouve dans le répertoire screen_detection_pipeline, où les entrées et les sorties entre les étapes sont mappées dans un fichier de configuration.

Les dépendances supplémentaires nécessaires pour exécuter les modèles Python sont détaillées dans un fichier requirements.txt, et doivent être conda-packées pour construire un environnement Conda (python_env.tar.gz). Pour plus d’informations, consultez Gestion du runtime Python et des bibliothèques. De plus, les fichiers de configuration des étapes Python doivent pointer vers python_env.tar.gz en utilisant la directive EXECUTION_ENV_PATH.

Le dossier modèle doit ensuite être compressé en format TAR et renommé en utilisant model_version.txt. Enfin, le fichier résultant <nom_du_modèle>_<version_du_modèle>.tar.gz est copié dans le Amazon Simple Storage Service (Amazon S3) relié à l’ MME, permettant à SageMaker de détecter et de servir le modèle.

Versionnement des modèles et déploiement continu

Comme la section précédente l’a montré, la création d’un référentiel de modèles Triton est simple. Cependant, l’exécution de toutes les étapes nécessaires pour le déployer est fastidieuse et sujette aux erreurs, si elle est exécutée manuellement. Pour pallier à cela, Veriff a créé un monorépertoire contenant tous les modèles à déployer sur les MME, où les scientifiques des données collaborent selon une approche similaire à Gitflow. Ce monorépertoire possède les fonctionnalités suivantes :

• Il est géré à l’aide de Pants.
• Des outils de qualité du code tels que Black et MyPy sont appliqués à l’aide de Pants.
• Des tests unitaires sont définis pour chaque modèle, vérifiant que la sortie du modèle est la sortie attendue pour une entrée de modèle donnée.
• Les poids des modèles sont stockés aux côtés des référentiels de modèles. Ces poids peuvent être de gros fichiers binaires, il est donc utilisé DVC pour les synchroniser avec Git de manière versionnée.

Ce monorépertoire est intégré à un outil d’intégration continue (CI). Pour chaque nouvelle poussée sur le référentiel ou chaque nouveau modèle, les étapes suivantes sont exécutées :

1. Passer le contrôle de qualité du code.
2. Télécharger les poids du modèle.
3. Créer l’environnement Conda.
4. Démarrer un serveur Triton en utilisant l’environnement Conda et l’utiliser pour traiter les requêtes définies dans les tests unitaires.
5. Créer le fichier TAR final du modèle (<nom_du_modèle>_<version_du_modèle>.tar.gz).

Ces étapes veillent à ce que les modèles possèdent la qualité requise pour le déploiement, ainsi pour chaque poussée sur une branche de référentiel, le fichier TAR résultant est copié (dans une autre étape CI) dans le seau S3 de mise en scène. Lorsque des poussées sont effectuées sur la branche principale, le fichier de modèle est copié dans le seau S3 de production. Le diagramme suivant représente ce système de CI/CD.

Avantages de coût et de vitesse de déploiement

L’utilisation des MME permet à Veriff d’utiliser une approche de monorépertoire pour déployer des modèles en production. En résumé, le nouveau flux de travail de déploiement des modèles de Veriff se compose des étapes suivantes :

1. Créer une branche dans le monorépertoire avec le nouveau modèle ou la nouvelle version du modèle.
2. Définir et exécuter les tests unitaires sur une machine de développement.
3. Pousser la branche lorsque le modèle est prêt à être testé dans l’environnement de mise en scène.
4. Fusionner la branche principale lorsque le modèle est prêt à être utilisé en production.

Avec cette nouvelle solution en place, le déploiement d’un modèle chez Veriff fait partie intégrante du processus de développement. Le temps de développement des nouveaux modèles est passé de 10 jours en moyenne à seulement 2 jours.

Les fonctionnalités de provisionnement d’infrastructure gérée et de mise à l’échelle automatique de SageMaker ont apporté des avantages supplémentaires à Veriff. Ils utilisent la métrique CloudWatch InvocationsPerInstance pour ajuster l’échelle en fonction des habitudes de trafic, économisant ainsi sur les coûts sans sacrifier la fiabilité. Pour définir la valeur seuil de la métrique, ils ont effectué des tests de charge sur le point de terminaison de mise en scène pour trouver le meilleur compromis entre la latence et les coûts.

Après le déploiement de sept modèles de production sur les MME et l’analyse des dépenses, Veriff a rapporté une réduction des coûts de 75 % pour la diffusion des modèles GPU par rapport à la solution initiale basée sur Kubernetes. Les coûts opérationnels ont également diminué, car le fardeau de la mise en provision manuelle des instances a été levé des ingénieurs DevOps de l’entreprise.

Conclusion

Dans cet article, nous avons examiné pourquoi Veriff a choisi les MME de Sagemaker plutôt que le déploiement de modèles auto-géré sur Kubernetes. SageMaker prend en charge les tâches lourdes et indifférenciées, permettant à Veriff de réduire le temps de développement des modèles, d’augmenter l’efficacité de l’ingénierie et de réduire considérablement les coûts pour l’inférence en temps réel tout en maintenant les performances nécessaires pour les opérations critiques de leur entreprise. Enfin, nous avons présenté le pipeline simple mais efficace de déploiement de modèles de Veriff et son mécanisme de versioning des modèles, pouvant être utilisés comme une implémentation de référence de la combinaison des meilleures pratiques de développement logiciel et des MME de SageMaker. Vous pouvez trouver des exemples de code sur l’hébergement de plusieurs modèles en utilisant les MME de SageMaker sur GitHub.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!