AI Platform Prediction : Concepts relatifs aux conteneurs personnalisés

Ce document traite de l'inférence de modèles de machine learning (ML) sur Google Cloud à l'aide de conteneurs personnalisés dans AI Platform Prediction.

AI Platform Prediction est la plate-forme de diffusion de modèles de ML gérée de Google Cloud. En tant que service géré, la plate-forme gère la configuration, la maintenance et la gestion de l'infrastructure. AI Platform Prediction est compatible avec l'inférence à l'aide de processeurs ou de GPU. Elle offre un éventail de formes de nœuds n1-standard dans Compute Engine, ce qui vous permet de personnaliser l'unité d'échelle pour l'adapter à vos exigences.

Le service AI Platform Prediction simplifie la diffusion de modèle en vous demandant simplement de spécifier l'emplacement de stockage de vos artefacts de modèle. Toutefois, cette simplicité réduit la flexibilité. Par exemple, vous ne pouvez diffuser que des frameworks intégrés au service. Grâce aux conteneurs personnalisés, AI Platform Prediction réduit le niveau d'abstraction de sorte que vous pouvez choisir le framework, le serveur de modèles, le prétraitement et le post-traitement dont vous avez besoin.

Ce document fait partie d'une série destinée aux ingénieurs et architectes ML qui conçoivent, créent et gèrent une plate-forme d'inférence de modèle très performante sur Google Cloud :

Ce document traite des choix d'inférence de modèle axés sur les conteneurs personnalisés dans AI Platform Prediction. Le document associé se concentre sur l'intégration de Triton Inference Server avec des conteneurs personnalisés dans AI Platform Prediction.

Quand utiliser des conteneurs personnalisés avec AI Platform Prediction ?

Google Cloud propose plusieurs options d'inférence de modèles de ML. Pour vous aider à choisir la plate-forme la mieux adaptée à vos besoins de prédiction, le tableau suivant propose des choix courants en fonction des exigences :

Besoins de prédiction AI Platform Prediction Basic Conteneurs personnalisés AI Platform Prediction Google Kubernetes Engine (GKE) Dataflow (utilisé comme pipeline de prédiction)
Service de prédiction de modèle géré Oui Oui Non Oui
Prédiction synchrone à faible latence Oui Oui Oui Non
Analyse de flux asynchrone Non Non Non Oui
Prédiction par lot Oui Oui Selon le serveur de modèles Oui
Compatibilité avec les frameworks TensorFlow, scikit-learn, XGBoost Aucun, conteneurisé par l'utilisateur Aucun, conteneurisé par l'utilisateur Chargé par l'utilisateur
Compatibilité avec les serveurs de modèles tiers Non Conteneurisé par l'utilisateur Conteneurisé par l'utilisateur Non applicable
Le type de machine de nœud choisi mls1 et n1-standard n1-standard Tout type compatible avec GKE Tout type compatible avec Dataflow
Compatibilité avec les GPU Oui Oui Oui Oui
Traitement personnalisé extérieur au serveur de modèles Routines de prédiction personnalisées Oui Oui Non applicable

Les sections suivantes fournissent plus de détails pour vous aider à évaluer les options dont vous disposez.

Activation

Il est important de réfléchir à la façon dont un modèle est consommé une fois diffusé. Les applications telles que les risques de transaction et la diffusion d'annonces effectuent généralement des appels vers la prédiction en ligne synchrone et sont sensibles à la latence. Les prédictions et les recommandations de valeur vie client (CLV) sont généralement traitées plus efficacement sous forme de lots volumineux et périodiques. Les cas d'utilisation de maintenance prédictive diffusent généralement la télémétrie de manière asynchrone. Dans ce cas, vous utilisez un modèle pour identifier les conditions d'échec, et le consommateur des prédictions peut être une application d'agrégation qui n'est pas l'émetteur de la télémétrie. Le choix d'une plate-forme de diffusion dépend de la manière dont votre modèle est consommé.

Compatibilité de calcul

AI Platform Prediction Basic est compatible avec les types de machines mls1 et n1-standard, tandis que les conteneurs personnalisés d'AI Platform Prediction acceptent les types de machines n1-standard. Pour des performances optimales, il est recommandé d'utiliser uniquement les types de machines n1-standard.

Si vous maîtrisez la gestion d'une plate-forme de prédiction au niveau de l'infrastructure et que vos applications sont sans état et conçues pour gérer les nouvelles tentatives en cas de perte de requêtes, vous pouvez utiliser GKE avec des nœuds préemptifs. Les nœuds préemptifs peuvent vous aider à réduire vos coûts de calcul. Cependant, vous devez savoir que les nœuds préemptifs ne durent que 24 heures au maximum. Si vous prévoyez d'utiliser des nœuds préemptifs en production, vous ne devez déployer que des charges de travail tolérantes à l'extinction de nœuds. Les tâches hors connexion, redémarrables et dotées de points de contrôle sont idéales pour les nœuds préemptifs.

Serveurs de modèles tiers

Si vous avez besoin d'un serveur de modèles personnalisé tel que Triton Inference Server ou Facebook TochServe, choisissez une plate-forme de prédiction capable de diffuser directement à partir d'un conteneur ou de charger des serveurs de modèles personnalisés.

Compatibilité avec les frameworks

AI Platform Prediction Basic est un service de prédiction géré qui est directement compatible avec TensorFlow, XGBoost et scikit-learn. Nous vous recommandons d'utiliser AI Platform Prediction Basic si les frameworks et versions de frameworks compatibles peuvent diffuser directement votre modèle.

Prétraitement et post-traitement des données

Lorsque vous déployez un modèle pour la prédiction, la forme des données est rarement identique à celle des données utilisées pour entraîner le modèle. Cette dynamique, appelée décalage entraînement/diffusion, nécessite un prétraitement de vos données avant que le modèle ne puisse traiter les requêtes de prédiction. Les résultats prédits sont également couramment utilisés après application d'un post-traitement. Si possible, nous vous recommandons d'incorporer les opérations de traitement à votre modèle. Les frameworks, tels que TensorFlow, vous permettent d'ajouter des opérations au graphe de diffusion, ce qui permet non seulement de simplifier votre environnement, mais aussi d'augmenter ses performances, car vous réduisez les sauts.

Il est toutefois possible que vous ne puissiez pas intégrer certaines étapes de traitement au graphe du modèle. Par exemple, vous utilisez peut-être un prétraitement avec XGBoost, ou votre prétraitement est un modèle entraîné dans PyTorch, mais votre classificateur est un modèle entraîné dans TensorFlow. Bien que les routines de prédiction personnalisées dans AI Platform Prediction vous permettent d'injecter ce type de code de prétraitement, nous vous recommandons d'utiliser plutôt des conteneurs personnalisés pour des raisons de performances. Les routines de prédiction personnalisées n'ajoutent pas seulement un saut supplémentaire, le nœud supplémentaire correspond aussi au type mls1 qui est moins performant.

Architecture des conteneurs personnalisés dans AI Platform Prediction

Le schéma suivant illustre les principaux composants des conteneurs personnalisés dans AI Platform Prediction :

Composants principaux, y compris l'image du conteneur, tout code de post-traitement ou de prétraitement, le modèle et l'emplacement de stockage du modèle

Les sections suivantes expliquent les concepts importants illustrés dans le diagramme précédent.

Image de base

Vous fournissez une image de conteneur personnalisé (A) qui est une image de base d'un serveur de modèles ou une image dérivée de l'image de base d'un serveur de modèles. Dans l'exemple fourni sur la page AI Platform Prediction : configuration directe du serveur de modèles pour NVIDIA Triton Inference Server, le serveur de modèles est Triton Inference Server.

Code de prétraitement et de post-traitement

Si un code spécial (B) est requis (par exemple pour personnaliser le routage ou un traitement), vous utilisez un nouveau Dockerfile pour intégrer les artefacts au conteneur. Le code de prétraitement écoute les requêtes entrantes, applique le prétraitement, puis transmet la requête prétraitée au serveur de modèles. Tout code de post-traitement doit être exécuté et renvoyer les résultats au client.

Emplacement de stockage du modèle

Pour choisir l'emplacement où le modèle est conservé, deux options s'offrent à vous :

  • Spécifiez le chemin d'accès aux artefacts de modèle dans Cloud Storage. Si votre serveur de modèles peut lire directement à partir de Cloud Storage, cette option (C) est préférable. Elle vous permet de déployer une nouvelle version de modèle sans avoir à créer un nouveau conteneur.
  • Copiez les artefacts de modèle directement dans le conteneur. Cette option (D) est destinée aux serveurs de modèles qui ne peuvent pas lire directement à partir de Cloud Storage. Cette option nécessite un nouveau conteneur chaque fois que vous déployez une nouvelle version de modèle.

Modèle

AI Platform Prediction utilise un paradigme d'architecture basé sur des modèles et des versions de modèle, où le modèle est un regroupement logique de versions de modèle. Une utilisation courante de ce paradigme est l'entraînement continu. Dans ce cas, les applications conçues pour un modèle particulier utilisent ce modèle, mais adoptent les nouvelles versions du modèle à mesure que le modèle est réentraîné au fil du temps.

Version de modèle

Une version de modèle dans AI Platform Prediction est une instance d'un modèle entraîné avec un ensemble de données, une configuration et des hyperparamètres spécifiques. Dans AI Platform Prediction, les versions de modèle sont traitées comme étant immuables. Si vous devez mettre à jour un modèle (par exemple, si vous avez réentraîné le modèle avec un nouvel ensemble de données), vous devez créer une nouvelle version du modèle, puis la déployer. Les versions de modèle permettent de simplifier les déploiements Canary. Comme les versions de modèle existent au sein d'un modèle, vous devez créer ce modèle avant de créer des versions.

Conteneur personnalisé

Un conteneur personnalisé (E) est une instance de la version de modèle. Créez le conteneur personnalisé à partir de l'image de conteneur personnalisé.

Client d'inférence

Une fois que vous avez configuré le serveur de modèles, le client d'inférence (F) communique avec AI Platform Prediction.

Modèles de conteneurs personnalisés

Dans cette série, nous faisons référence à deux modèles généraux d'architecture pour les conteneurs personnalisés : le modèle de serveur de modèle direct et le modèle de serveur de modèle avec écouteur. Le modèle avec écouteur peut inclure un prétraitement et un post-traitement personnalisés. Pour vous aider à choisir le modèle de diffusion de modèle qui répond le mieux à vos besoins, le tableau suivant décrit quelques cas d'utilisation gérés par chaque modèle :

Besoins de prédiction Serveur de modèles direct Serveur de modèles avec écouteur
Déploiement simplifié Oui Non
Latence la plus faible possible Oui Dépend du traitement
Compatible avec un seul modèle Oui Oui
Pile à plusieurs modèles Non Oui
Prétraitement et post-traitement complexes, externes au serveur de modèles Non Oui
Options de routage personnalisables ou multiples Non Oui

Les sections suivantes décrivent les deux modèles de conteneur.

Serveur de modèles direct

Le modèle de serveur de modèles direct offre un accès direct au serveur de modèles depuis AI Platform sans connexion intermédiaire, comme le montre le schéma suivant :

Le serveur de modèles est stocké dans un conteneur personnalisé et est accessible directement.

Ce modèle est utile lorsque vous avez besoin des éléments suivants :

  • Une seule route de prédiction. Selon le serveur de modèles, la prise en charge de plusieurs modèles peut nécessiter plusieurs routes. Si vous ne diffusez qu'un seul modèle, ou si vous pouvez gérer votre serveur de modèles à l'aide d'une même route de prédiction, le modèle de serveur direct constitue le meilleur choix. Ce modèle est généralement le plus simple à configurer.
  • Une latence faible. La communication directe entre AI Platform et le serveur de modèles élimine tout retard potentiel causé par un intermédiaire.
  • La capacité à encapsuler le prétraitement et le post-traitement dans le modèle. Les frameworks tels que TensorFlow vous permettent d'ajouter au graphe de calcul des opérations de prétraitement et de post-traitement. En général, cette approche constitue le moyen le plus performant de gérer le prétraitement et le post-traitement, car vous minimisez le marshalling de mémoire entre les processus. Certains serveurs de modèles, tels que Triton Inference Server, proposent une modélisation d'ensemble, où la sortie d'un modèle peut devenir l'entrée d'un autre modèle. Cette fonctionnalité permet le prétraitement en amont et le post-traitement en aval au sein du serveur de modèles.

Serveur de modèles avec écouteur

Dans ce modèle, vous configurez un écouteur entre AI Platform et le serveur de modèles, comme le montre le schéma suivant :

Un conteneur personnalisé stocke le serveur de modèles ainsi qu'un écouteur contenant tout code de prétraitement ou de post-traitement.

Ce modèle est utile lorsque vous avez besoin de gérer les éléments suivants :

  • Routage complexe ou pile à plusieurs modèles. Certains serveurs de modèles acceptent d'héberger plusieurs modèles dans la même instance et nécessitent des routes distinctes pour accéder aux modèles. Pour effectuer un multiplexage via la route de prédiction, il est généralement nécessaire d'employer un écouteur, les informations de destination de la route étant intégrées ailleurs (par exemple dans l'en-tête).
  • Prétraitement et post-traitement complexes. Certains frameworks qui ne vous permettent pas d'intégrer la logique de prétraitement ou de post-traitement nécessitent de réaliser un traitement en dehors du processus d'inférence. Il se peut également, dans certains cas, qu'une étape de prétraitement doive effectuer un appel externe à un autre service. Ces modèles deviennent alors difficiles ou impossibles à inclure dans un graphe.
  • La conversion de format d'inférence. Pour assurer la compatibilité avec les différents formats sur plusieurs serveurs de modèle, vous pouvez utiliser un écouteur pour convertir le format.

Il est important de comprendre que l'écouteur est un intermédiaire entre le serveur de modèles et AI Platform, ce qui ajoute donc une latence au processus. L'impact de cette latence est plus élevé sur un modèle léger que sur un modèle lourd. Par exemple, si le temps d'inférence pour un modèle de deep learning lourd est de 50 millisecondes (ms) et que vous ajoutez 20 ms de prétraitement, ces 20 ms représentent une augmentation de 40 %. Si vous ajoutez les mêmes 20 ms à un temps d'inférence de 10 ms pour un modèle XGBoost léger, cela représente alors une augmentation de 200 %.

Planifier un modèle et une version de modèle

AI Platform Prediction organise les artefacts du modèle suivant une hiérarchie projet-modèle-version. Par exemple, une entreprise peut disposer de plusieurs projets Google Cloud. Chaque projet peut comporter plusieurs modèles. Chaque modèle peut avoir une ou plusieurs versions de modèle. Cette structure se présente comme suit :

  • Exemple d'organisation
    • Projet SalesOps
      • Modèle CustomerPropensity
        • Version de modèle v20201131
        • Version de modèle v20201107
        • Version de modèle v20201009

Pour en savoir plus sur les modèles et les versions de modèle, consultez la page Présentation de la prédiction.

Avant de pouvoir créer une version de modèle, vous devez créer un modèle. Voici le format de la requête REST permettant de créer un modèle :

POST -d "{'name': 'MODEL_NAME'}" \
    ENDPOINT/projects/PROJECT_ID/models/

Cette requête contient les valeurs suivantes :

  • MODEL_NAME : nom du modèle que vous créez (par exemple, buyer_recommendation)
  • ENDPOINT : service AI Platform à l'adresse https://ml.googleapis.com/v1
  • PROJECT_ID : projet Google Cloud dans lequel vous souhaitez créer ce modèle

Vous pouvez créer des versions de modèle ultérieures dans ce modèle à l'aide de la requête POST suivante :

POST -d @version_spec.json \
    ENDPOINT/projects/PROJECT_ID/models/MODEL_NAME/versions

Pour en savoir plus, consultez les commandes REST dans la documentation de référence sur AI Platform Prediction.

Voici un exemple de fichier version_spec.json pour Triton Inference Server :

{
  "name": "v3",
  "deployment_uri": "gs://model-artifacts-source-location",
  "container": {
    "image": "gcr.io/my_project/triton:20.06",
    "args": ["tritonserver",
             "--model-repository=$AIP_STORAGE_URI"
    ],
    "env": [
    ],
    "ports": [
      { "containerPort": 8000 }
    ]
  },
  "routes": {
    "predict": "/v2/models/$AIP_MODEL_NAME/infer",
    "health": "/v2/models/$AIP_MODEL_NAME"
  },
  "machine_type": "n1-standard4",
  "acceleratorConfig": {
    "count":1,
    "type":"nvidia-tesla-t4"
  },
  "autoScale": {
    "minNodes":1
  }
}

Le tableau suivant décrit les éléments de la spécification JSON précédente :

Élément (* = obligatoire) Description
name* Nom de la version du modèle
deployment_uri Emplacement des modèles dans Cloud Storage. Lorsqu'une version de modèle est créée, AI Platform copie les artefacts de cet emplacement et les met à disposition via la variable d'environnement AIP_STORAGE_URI.
container:image* Chemin d'accès à l'image du conteneur
container:args Commande et arguments utilisés au démarrage du conteneur
container:env Variables d'environnement Ces variables d'environnement fournies par l'utilisateur sont mises à la disposition du conteneur au moment de l'exécution.
container:ports* Port réseau utilisé par AI Platform pour communiquer avec les conteneurs. Si aucun port n'est spécifié, le port est défini par défaut sur 8080.
routes:predict

Les routes de point de terminaison du conteneur utilisées par AI Platform pour transférer les requêtes de prédiction vers le conteneur. Si elles sont absentes, les routes de point de terminaison par défaut correspondent à :

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME:predict

routes:health

La route de point de terminaison du conteneur utilisée par AI Platform pour vérifier l'état du conteneur de la version du modèle. Ce n'est qu'après une réponse réussie (un code d'état HTTP 200 du conteneur avec HTTP GET) que le trafic est dirigé vers cette instance de la version de modèle. Si cet élément n'est pas spécifié, la route de point de terminaison par défaut est la suivante :

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME

machine_type* Type de machine virtuelle pour le nœud d'inférence
acceleratorConfig:Count Si un GPU est requis, il s'agit du nombre de GPU pour chaque nœud.
acceleratorConfig:Type Si un GPU est requis, il s'agit du type de GPU.
autoScale:minNodes Nombre minimal de nœuds en mode autoscaling. Cet élément ne peut pas être utilisé avec l'élément manualScale.
manualScale:nodes Nombre de nœuds en mode de scaling manuel. Cet élément ne peut pas être utilisé avec l'élément autoScale.

Les variables d'environnement portant le préfixe AIP_ dans spec.json n'existent qu'après la création du conteneur de la version de modèle. Dans l'exemple de fichier version_spec.json précédent, tenez compte des éléments suivants :

  • $AIP_STORAGE_URI. Lorsque vous créez une version de modèle, AI Platform copie les artefacts du modèle à partir de deployment_uri. Lorsque le conteneur se connecte, il recherche les éléments de modèle dans $AIP_STORAGE_URI. Dans l'exemple, nous définissons l'option du dépôt de modèles Triton Inference Server en tant que --model-repository=$AIP_STORAGE_URI.
  • $AIP_MODEL_NAME. Les serveurs de modèles tels que Triton Inference Server et TorchServe acceptent plusieurs modèles simultanément et s'attendent à ce que le chemin du point de terminaison de requête spécifie le modèle sur lequel exécuter l'inférence pour la requête. La valeur de cet environnement est dérivée de ${MODEL_NAME} lors de la création de la version de modèle.

Le tableau suivant décrit certaines variables d'environnement AIP_ courantes disponibles pour le conteneur :

Variable d'environnement Description
AIP_PROJECT_NUMBER Numéro du projet dans lequel un modèle est créé.
AIP_MODEL_NAME Nom du modèle dans lequel les versions de modèle sont créées. Le nom est tiré de la valeur ${MODEL_NAME} de la commande POST que vous utilisez pour créer le modèle.
AIP_VERSION_NAME Nom d'une version de modèle Le nom de la version de modèle est tiré de la valeur name de la spécification JSON précédente que vous utilisez pour créer le modèle.
AIP_HTTP_PORT Port cible de l'écouteur dans le conteneur personnalisé avec lequel AI Platform communique. L'écouteur peut être le serveur de modèles lui-même ou un intermédiaire (par exemple, un prétraitement de données en amont du serveur de modèles). Ce port provient de container:ports dans la spécification JSON précédente.
AIP_PREDICT_ROUTE Route vers laquelle AI Platform transfère les requêtes de prédiction lors de la communication avec le conteneur personnalisé. Ce port est tiré de routes:predict dans la spécification JSON précédente.
AIP_HEALTH_ROUTE Route utilisée par AI Platform pour vérifier l'état d'un conteneur personnalisé. Cette route est tirée de routes:health dans la spécification JSON précédente.
AIP_STORAGE_URI Emplacement vers lequel les éléments du modèle sont copiés à partir de la valeur deployment_uri figurant dans la spécification JSON précédente. Cette variable d'environnement définit où le serveur de modèle recherche les artefacts du modèle.

Étape suivante