True ML Talks #13 - Plateforme de machine learning @ Cookpad

Nous sommes de retour avec un autre épisode de True ML Talks. Dans ce document, nous allons approfondir l'architecture ML de Cookpad, l'une des plus grandes plateformes de services de recettes au monde. Nous aborderons également les défis liés à la création d'une plate-forme d'apprentissage automatique performante et la manière dont ils utilisent le serveur d'inférence Nvidia Triton pour exécuter des modèles.
Nous discutons avec José Navarro

Jose est l'ingénieur principal de la plateforme ML chez Cookpad. Il essaie d'aider les ingénieurs en apprentissage automatique et tous les praticiens du ML à fournir des systèmes ML rapidement et de manière fiable.

📌

Nos conversations avec Jose porteront sur les aspects suivants :
- Structure des équipes ML @ Cookpad
- Infrastructure ML basée sur GPU
- Déploiement automatique de modèles sur Cookpad
- Intégration et configuration du Feature Store pour l'inférence en ligne
- Gestion des sources de données et des fonctionnalités lors des expériences sur les modèles
- Utilisation des flux de travail Argo pour recycler les modèles ML
- Le serveur d'inférence Triton de Nvidia et ses avantages
- Intégration du registre de modèles MLflow au serveur d'inférence Triton
- Tirer parti des LLM et de l'IA de génération en génération sur Cookpad
- Adapter l'architecture MLOps à vos besoins

Regardez l'épisode complet ci-dessous :

Structure des équipes ML @ Cookpad

1. Ingénieurs en apprentissage automatique : L'équipe principale de ML est composée d'ingénieurs spécialisés à la fois en apprentissage automatique et en génie logiciel. Ils sont responsables du développement, de la formation et du déploiement de modèles d'apprentissage automatique, en collaborant étroitement avec les équipes produits.
2. Équipe de la plateforme : L'équipe de la plateforme soutient les ingénieurs ML en gérant l'infrastructure sous-jacente, y compris les clusters Kubernetes. Ils garantissent l'évolutivité, la fiabilité et les performances des systèmes de machine learning. En outre, ils développent et gèrent des outils et des cadres internes pour rationaliser le processus de développement du ML.

Infrastructure ML basée sur GPU

1. Infrastructure basée sur le cloud : Cookpad exploite son infrastructure de machine learning dans le cloud, principalement à l'aide d'AWS, avec certaines ressources dans GCP. L'infrastructure est conçue pour répondre à l'ampleur et aux exigences de la base d'utilisateurs mondiale de Cookpad.
2. Traitement des données et extraction de fonctionnalités : Le contenu et les actions générés par les utilisateurs sont ingérés via Kafka et traités dans un service de streaming. Les fonctionnalités sont calculées et stockées dans la boutique de fonctionnalités Amazon SageMaker, Amazon Redshift faisant office d'entrepôt de données.
3. Architecture de microservices et couche d'inférence : La plateforme ML de Cookpad repose sur une architecture de microservices déployée sur Kubernetes. Le prétraitement s'effectue dans les microservices et le serveur d'inférence Nvidia est utilisé pour l'inférence ML.
4. Plateforme d'expérimentation ML Engineer : Cookpad fournit une plate-forme d'expérimentation pour les ingénieurs en machine learning, y compris des serveurs Jupyter pour l'exploration des données et la formation de modèles. MLflow est utilisé pour le suivi des expériences et le registre des modèles.
5. Déploiement et automatisation des modèles : Les ingénieurs ML enregistrent les modèles dans MLflow, et les processus d'automatisation gèrent la transformation et le déploiement des modèles sur le serveur d'inférence Nvidia (Triton).
6. Cas d'utilisation gourmands en ressources GPU : L'infrastructure GPU de Cookpad prend en charge différents modèles, notamment des modèles multilingues et des intégrateurs d'images. Les modèles multilingues utilisent de grands réseaux de neurones, tandis que les intégrateurs d'images nécessitent beaucoup de temps de calcul. Les modèles sont déployés sur des GPU par défaut à l'aide du serveur d'inférence Nvidia Triton.

Déploiement automatique de modèles sur Cookpad

1. Jupyter Hub pour l'expérimentation : Les ingénieurs ML de Cookpad ont accès à un environnement Jupyter Hub géré dans lequel ils peuvent mener leurs expériences. L'équipe prend en charge différents noyaux au sein de Jupyter Hub à des fins d'expérimentation.
2. Publication de modèles dans MLflow : Une fois que l'ingénieur ML a développé un modèle et obtenu des résultats satisfaisants, il peut publier le modèle sur MLflow, qui sert de registre de modèles et de plateforme de suivi des expériences.
3. Automatisation de bout en bout : Cookpad a mis en place un pipeline automatisé de bout en bout pour le déploiement de modèles. Le pipeline d'automatisation prend le relais du registre de modèles MLflow et déplace le modèle de manière fluide tout au long du processus de déploiement.
4. Frameworks backend pris en charge : Le pipeline d'automatisation de Cookpad prend en charge un sous-ensemble de frameworks backend, notamment PyTorch, TensorFlow et ONNX. Ces frameworks sont utilisés pour optimiser et déployer efficacement les modèles.
5. Par défaut, PyTorch et TensorFlow sont les suivants : Bien que Cookpad prenne en charge plusieurs frameworks backend, l'équipe a tendance à utiliser par défaut PyTorch et TensorFlow pour le développement et le déploiement de modèles en raison de leur utilisation généralisée et de leur compatibilité avec l'infrastructure.

📌

Déploiement automatique de modèles avec MLflow et support backend :
Lorsqu'un ingénieur en apprentissage automatique fait des expériences chez Cookpad, il a accès à un hub Jupyter géré où il peut exécuter ses expériences et utiliser différents noyaux. Une fois qu'ils ont développé un modèle, ils le publient sur MLflow, qui sert de registre de modèles. À partir de là, le processus est entièrement automatisé.
Le pipeline d'automatisation de Cookpad prend en charge une liste de backends compatibles à la fois avec MLflow et le serveur d'inférence Triton. Les backends pris en charge incluent PyTorch, TensorFlow, Onnx et d'autres. Le pipeline d'automatisation gère le déploiement des modèles enregistrés, en tirant parti du backend approprié en fonction de la compatibilité. Les choix par défaut pour le déploiement sont généralement PyTorch ou TensorFlow, Onnx étant utilisé pour optimiser certains réseaux de neurones.

Intégration et configuration du Feature Store pour l'inférence en ligne

Chez Cookpad, les data scientists utilisent le magasin de fonctionnalités à la fois pour des expériences et pour des inférences en ligne. Au cours de l'expérimentation, ils ont un accès hors ligne pour interroger les fonctionnalités existantes pour l'entraînement des modèles. Lors de l'exploration de nouvelles fonctionnalités, les données sont extraites de l'entrepôt de données, transformées et utilisées pour créer de nouvelles fonctionnalités. Une fois satisfaits des performances du modèle, les data scientists créent simplement un nouveau groupe de fonctionnalités dans le magasin de fonctionnalités via le schéma du référentiel.

Les données circulent de l'entrepôt de données vers le magasin de fonctionnalités via Kafka, ce qui permet la diffusion en continu des fonctionnalités nouvellement créées. Pour permettre l'inférence en ligne, les data scientists étendent le service de streaming pour prendre en compte les événements pertinents et effectuer des transformations. Lors de l'enregistrement du modèle, les data scientists spécifient la construction du modèle et les caractéristiques utilisées, et le code de transformation est configuré pour récupérer des caractéristiques spécifiques par leur nom.

Cette intégration entre le magasin de fonctionnalités, l'entrepôt de données et le service de streaming garantit une intégration fluide des fonctionnalités dans le processus d'inférence en ligne, offrant une flexibilité pour les ajustements et les mises à jour en cas de besoin.

Sources de données et gestion des fonctionnalités lors des expériences sur les modèles

Lors des expériences sur des modèles, les data scientists de Cookpad disposent de deux options pour l'approvisionnement des données. Si les fonctionnalités requises sont déjà disponibles dans le magasin de fonctionnalités, ils peuvent directement l'interroger hors ligne. Cependant, lorsqu'ils explorent de nouvelles fonctionnalités, ils accèdent à l'entrepôt de données, extraient les données et créent les transformations nécessaires pour entraîner les modèles.

L'intégration de nouvelles fonctionnalités dans le magasin de fonctionnalités est simple. Les data scientists soumettent une pull request (PR) contenant les détails du schéma de la fonctionnalité, et l'automatisation gère la création du groupe de fonctionnalités à l'aide d'appels AWS. Les données utilisées dans l'entrepôt de données sont diffusées via Kafka pour permettre l'inférence en ligne avec les fonctionnalités nouvellement créées. Le service de streaming existant est étendu pour consommer des événements et appliquer des transformations, garantissant ainsi le flux de fonctionnalités en streaming vers le magasin de fonctionnalités.

Pour gérer la configuration des fonctionnalités, les data scientists incluent des informations pertinentes lors de l'enregistrement du modèle dans MLflow. Le code de transformation accède directement au magasin de fonctionnalités et, par le biais de la configuration, les data scientists spécifient les noms de fonctionnalités requis. Cette flexibilité permet de modifier facilement les configurations des fonctionnalités selon les besoins.

Utilisation des flux de travail Argo pour recycler les modèles ML

Le processus d'intégration des pipelines de recyclage dans l'architecture est actuellement en cours chez Cookpad. Bien que l'accent ait été mis sur l'itération rapide grâce à de nouvelles fonctionnalités de machine learning, la mise en œuvre de pipelines de recyclage matures qui remplacent ou recyclent les modèles sur une base quotidienne ou hebdomadaire est toujours en cours de développement. Les systèmes de recommandation de Cookpad n'en sont qu'à leurs débuts, et l'approche itérative permet une expérimentation rapide et le remplacement des modèles par des tests AB.

Bien qu'il soit possible de créer des pipelines reproductibles à l'aide d'Argo Workflows, Cookpad reconnaît qu'ils n'en sont qu'aux premiers stades de cette mise en œuvre. Il ne s'agit pas encore d'une solution idéale, et la reproductibilité des pipelines est un défi qu'ils relèvent activement.

Commencer par des expériences plus petites et plus simples et automatiser les composants critiques du pipeline permet de mettre en place une architecture bien pensée. Cookpad a donné la priorité à l'automatisation de l'inférence, reconnaissant son importance, et prévoit de se concentrer sur le recyclage des pipelines à l'avenir. Cette approche organisée et progressive de la création de la plateforme constitue une expérience d'apprentissage précieuse pour le public, car elle met en évidence l'efficacité de la méthodologie.

Tenter de construire un système de bout en bout dès le départ entraîne souvent des composants inutiles ou mal adaptés. Il suggère d'explorer des alternatives à Argo Workflows pour des pipelines reproductibles, comme l'utilisation d'un wrapper Python ou d'un outil différent qui correspond mieux à la familiarité des ingénieurs en apprentissage automatique avec les manifestes Kubernetes et qui correspond parfaitement à leurs pratiques de CI/CD.

Le serveur d'inférence Triton de Nvidia et ses avantages

1. Décision d'utiliser le serveur d'inférence Triton : Cookpad a choisi Triton Inference Server pour relever les défis liés à l'exécution de l'inférence sur les GPU de Kubernetes, en optimisant les coûts et les performances tout en tenant compte de l'équilibre entre les coûts et la valeur commerciale.
2. Avantages du serveur d'inférence Triton : Triton Inference Server permet d'optimiser les coûts en agrégeant les modèles, en partageant les ressources GPU et en acheminant intelligemment les demandes afin de réduire les coûts. Il améliore les performances par défaut en déployant des modèles sur des GPU, ce qui permet une inférence plus rapide. Il améliore l'expérience utilisateur des ingénieurs ML en simplifiant le déploiement grâce à une ligne de configuration unique et à une extraction et à un chargement fluides des modèles.

En tirant parti du serveur d'inférence Triton de Nvidia, Cookpad permet d'optimiser les coûts, d'améliorer les performances d'inférence des modèles et de simplifier le déploiement pour les ingénieurs ML.

Intégration du registre de modèles MLflow au serveur d'inférence Triton

Cookpad a intégré le registre de modèles MLflow et le serveur d'inférence Triton pour rationaliser le déploiement de modèles à grande échelle. Voici comment ils y sont parvenus :

1. Stockage du modèle MLflow : Lorsqu'un modèle est enregistré dans MLflow, il est stocké dans un compartiment S3 avec une structure de dossiers spécifique basée sur les conventions de MLflow. Le modèle peut être au format TensorFlow ou PyTorch, chacun ayant sa propre structure.
2. Structure du modèle de Triton : Triton Inference Server attend une structure de dossiers différente pour le chargement des modèles, y compris des fichiers de configuration. Ce désalignement nécessite quelques ajustements pour déplacer un modèle de MLflow vers Triton.
3. Déploiement du Sidecar : Cookpad a développé un composant sidecar déployé parallèlement à Triton Inference Server. Ce petit conteneur Python interroge l'API MLflow toutes les minutes pour identifier les modèles nouvellement enregistrés. Il interroge également l'API Triton pour vérifier quels modèles sont actuellement chargés.
4. Consolidation du modèle : Lors de la détection d'un nouveau modèle dans MLflow qui n'est pas présent dans Triton, le sidecar récupère le fichier de modèle depuis le compartiment S3. Il effectue les mouvements de fichiers nécessaires et garantit que la structure des dossiers correspond aux attentes de Triton.
5. Modèles de chargement : Le side-car place ensuite les fichiers du modèle dans le dossier approprié du volume de Triton et appelle l'API Triton pour charger le modèle. Le modèle est chargé de manière fluide dans Triton Inference Server sans nécessiter de redémarrage du serveur ou d'intervention manuelle.

En tirant parti de cette intégration, Cookpad permet un déploiement efficace des modèles de MLflow vers Triton Inference Server, ce qui permet une évolutivité et des mises à jour faciles sans perturber les opérations d'inférence en cours.

Tirer parti des LLM et de l'IA de génération en génération chez Cookpad

Cookpad explore activement les cas d'utilisation et les applications potentiels des modèles linguistiques (LLM) et de la technologie d'IA générative (Gen AI) au sein de sa plateforme. Bien que des implémentations spécifiques soient encore en phase d'exploration, voici quelques domaines dans lesquels Cookpad envisage de tirer parti de ces avancées :

1. Simplifier la création de recettes : Cookpad vise à réduire les obstacles qui empêchent les utilisateurs de créer des recettes en tirant parti des LLM. Par exemple, les utilisateurs peuvent utiliser les applications de reconnaissance vocale de leur smartphone pour dicter des instructions de recette pendant la cuisson. Les transcriptions sont ensuite transmises par LLM pour générer un texte de recette formaté, réduisant ainsi l'effort requis pour documenter les recettes de manière précise et efficace.
2. Reconnaissance intelligente des ingrédients : Cookpad envisage d'intégrer les fonctionnalités Gen AI pour permettre aux utilisateurs de prendre une photo des ingrédients de leur réfrigérateur ou de leur garde-manger et de demander des suggestions de recettes. Le système d'IA identifierait les ingrédients reconnus et fournirait des recommandations de recettes à l'aide du système de recherche de Cookpad.
3. Assistance et personnalisation des recettes : À l'aide de LLM, Cookpad prévoit de développer des fonctionnalités offrant une assistance et une personnalisation des recettes. Par exemple, les utilisateurs peuvent demander des substitutions ou des modifications d'ingrédients en fonction de leurs préférences ou des ingrédients disponibles. Le système basé sur LLM fournirait des suggestions alternatives et rationaliserait le processus de cuisson.

Lors du développement et de la mise en œuvre de ces cas d'utilisation, Cookpad donne la priorité à la confidentialité et à la conformité des données des utilisateurs.

Nous devons suivre ce processus et nous assurer qu'ils sont conformes aux normes de sécurité.

Adapter l'architecture MLOps à vos besoins

Lorsqu'il s'agit de créer une pile d'inférence en temps réel avec MLOps, il n'existe pas d'approche universelle. Jose Navarro souligne l'importance d'adapter l'architecture en fonction des exigences spécifiques et du niveau de maturité de la pratique d'apprentissage automatique (ML) au sein d'une entreprise. Voici quelques informations clés concernant les composants essentiels d'une architecture MLOps :

1. Comprendre la maturité : L'état actuel de la mise en œuvre du ML joue un rôle crucial dans la détermination des composants indispensables. Si une entreprise n'en est qu'à ses débuts et met fortement l'accent sur l'expérimentation et la fourniture de modèles, l'accent peut être mis sur la fourniture du modèle et la création de la couche d'inférence. D'autre part, pour les entreprises dont les modèles ML sont déjà en production et essentiels à l'activité, les pipelines reproductibles, les magasins de fonctionnalités et l'observabilité des modèles deviennent des éléments essentiels.
2. Éviter les complications excessives : Jose suggère d'éviter la tendance à ajouter des outils ou des composants inutiles à la pile MLOps. Il est plutôt important de se concentrer sur la simplification et la résolution de problèmes par la soustraction. En supprimant les éléments non essentiels ou en simplifiant le problème, les entreprises peuvent souvent trouver une solution plus rapidement. Cette approche permet aux équipes de donner la priorité à la création de valeur et à l'évaluation de l'impact de leurs initiatives de machine learning avant d'investir du temps dans des outils complexes.
3. Adoption d'outils agiles : Plutôt que de suivre une liste prédéterminée d'éléments indispensables, Jose recommande d'introduire des outils selon les besoins. Commencez par identifier les principaux défis et exigences, puis introduisez progressivement des outils qui répondent à ces besoins spécifiques. Par exemple, au lieu de consacrer beaucoup de temps à la recherche et à l'intégration d'un magasin de fonctionnalités, envisagez de créer un magasin clé-valeur rapide avec un service tel que DynamoDB pour démarrer le projet et évaluer sa valeur. Cette approche itérative permet de valider plus rapidement les initiatives de machine learning tout en minimisant la complexité inutile.

Lisez nos précédents articles de la série True ML Talks :

‍

True ML Talks #11 - LLMs, LLMops and Generative AI

Deep dive into LLMs, LLMops, Generative AI and ChatGPT. We talk with Micheal, CTO at GreenHouse about the trends in the Machne Learning Space.

TrueFoundry Blog TrueFoundry

Continuez à regarder le TrueML série youtube et en lisant le TrueML série de blogs.

True Foundry est un PaaS de déploiement de machine learning sur Kubernetes destiné à accélérer les flux de travail des développeurs tout en leur offrant une flexibilité totale dans les tests et le déploiement de modèles, tout en garantissant une sécurité et un contrôle complets à l'équipe Infra. Grâce à notre plateforme, nous permettons aux équipes de machine learning de déployer et surveiller des modèles en 15 minutes avec une fiabilité à 100 %, une évolutivité et la possibilité de revenir en arrière en quelques secondes, ce qui leur permet de réduire les coûts et de mettre les modèles en production plus rapidement, ce qui permet de réaliser une véritable valeur commerciale.