Configuration du service Tensorflow

Dans ce guide, nous passerons en revue les nombreux points de configuration de Tensorflow Serving.

Aperçu

Bien que la plupart des configurations concernent le Model Server, il existe de nombreuses façons de spécifier le comportement de Tensorflow Serving :

Configuration du serveur modèle

Le moyen le plus simple de servir un modèle est de fournir les indicateurs --model_name et --model_base_path (ou de définir la variable d'environnement MODEL_NAME si vous utilisez Docker). Cependant, si vous souhaitez servir plusieurs modèles ou configurer des options telles que la fréquence d'interrogation pour les nouvelles versions, vous pouvez le faire en écrivant un fichier de configuration Model Server.

Vous pouvez fournir ce fichier de configuration à l'aide de l'indicateur --model_config_file et demander à Tensorflow Serving de rechercher périodiquement les versions mises à jour de ce fichier de configuration au chemin spécifié en définissant l'indicateur --model_config_file_poll_wait_seconds .

Exemple utilisant Docker :

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

Rechargement de la configuration du serveur modèle

Il existe deux manières de recharger la configuration du Model Server :

  • En définissant l'indicateur --model_config_file_poll_wait_seconds pour demander au serveur de rechercher périodiquement un nouveau fichier de configuration dans --model_config_file filepath.

  • En émettant des appels RPC HandleReloadConfigRequest au serveur et en fournissant une nouvelle configuration de Model Server par programme.

Veuillez noter que chaque fois que le serveur chargera le nouveau fichier de configuration, il agira pour réaliser le contenu de la nouvelle configuration spécifiée et uniquement la nouvelle configuration spécifiée. Cela signifie que si le modèle A était présent dans le premier fichier de configuration, qui est remplacé par un fichier contenant uniquement le modèle B, le serveur chargera le modèle B et déchargera le modèle A.

Détails de configuration du serveur modèle

Le fichier de configuration Model Server fourni doit être un tampon de protocole ModelServerConfig .

Pour tous les cas d'utilisation, sauf les plus avancés, vous souhaiterez utiliser l'option ModelConfigList, qui est une liste de tampons de protocole ModelConfig . Voici un exemple de base, avant de plonger dans les options avancées ci-dessous.

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

Configuration d'un modèle

Chaque ModelConfig spécifie un modèle à servir, y compris son nom et le chemin où le serveur de modèles doit rechercher les versions du modèle à servir, comme le montre l'exemple ci-dessus. Par défaut, le serveur servira la version avec le numéro de version le plus grand. Cette valeur par défaut peut être remplacée en modifiant le champ model_version_policy.

Servir une version spécifique d'un modèle

Pour servir une version spécifique du modèle, plutôt que de toujours passer à celle avec le numéro de version le plus grand, définissez model_version_policy sur « spécifique » et fournissez le numéro de version que vous souhaitez servir. Par exemple, pour épingler la version 42 comme version à diffuser :

model_version_policy {
  specific {
    versions: 42
  }
}

Cette option est utile pour revenir à une version connue, dans le cas où un problème est découvert avec la ou les dernières versions.

Servir plusieurs versions d'un modèle

Pour servir plusieurs versions du modèle simultanément, par exemple pour permettre la mise en ligne d'une nouvelle version provisoire avec une tranche de trafic, définissez model_version_policy sur "spécifique" et fournissez plusieurs numéros de version. Par exemple, pour servir les versions 42 et 43 :

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

Attribution d'étiquettes de chaîne aux versions de modèle, pour simplifier Canary et la restauration

Il est parfois utile d'ajouter un niveau d'indirection aux versions de modèle. Au lieu de faire savoir à tous vos clients qu'ils doivent interroger la version 42, vous pouvez attribuer un alias tel que « stable » à la version actuellement celle que les clients doivent interroger. Si vous souhaitez rediriger une tranche de trafic vers une version provisoire du modèle Canary, vous pouvez utiliser un deuxième alias « canary ».

Vous pouvez configurer ces alias ou étiquettes de version de modèle, comme suit :

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

Dans l'exemple ci-dessus, vous diffusez les versions 42 et 43 et associez l'étiquette "stable" à la version 42 et l'étiquette "canary" à la version 43. Vous pouvez demander à vos clients de diriger les requêtes vers l'une des options "stable" ou "canary". (peut-être basé sur le hachage de l'ID utilisateur) en utilisant le champ version_label du tampon de protocole ModelSpec , et avancez l'étiquette sur le serveur sans en informer les clients. Une fois que vous avez terminé la version 43 de Canary et que vous êtes prêt à la promouvoir en version stable, vous pouvez mettre à jour la configuration vers :

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

Si vous devez ensuite effectuer une restauration, vous pouvez revenir à l'ancienne configuration dont la version 42 est "stable". Sinon, vous pouvez avancer en déchargeant la version 42 et en chargeant la nouvelle version 44 lorsqu'elle est prête, puis en avançant l'étiquette Canary à 44, et ainsi de suite.

Veuillez noter que les étiquettes ne peuvent être attribuées qu'aux versions de modèles déjà chargées et disponibles pour la diffusion. Une fois qu'une version de modèle est disponible, on peut recharger la configuration du modèle à la volée pour lui attribuer une étiquette. Ceci peut être réalisé à l'aide d'un RPC HandleReloadConfigRequest ou si le serveur est configuré pour interroger périodiquement le système de fichiers pour le fichier de configuration, comme décrit ci-dessus .

Si vous souhaitez attribuer une étiquette à une version qui n'est pas encore chargée (par exemple en fournissant à la fois la version du modèle et l'étiquette au démarrage), vous devez alors définir l'indicateur --allow_version_labels_for_unavailable_models sur true, ce qui permet aux nouvelles étiquettes d'être être attribué aux versions de modèle qui ne sont pas encore chargées.

Veuillez noter que cela s'applique uniquement aux nouvelles étiquettes de version (c'est-à-dire celles qui ne sont actuellement attribuées à aucune version). Cela permet de garantir que lors des échanges de versions, le serveur n'attribue pas prématurément l'étiquette à la nouvelle version, abandonnant ainsi toutes les requêtes destinées à cette étiquette pendant le chargement de la nouvelle version.

Afin de respecter ce contrôle de sécurité, si vous réattribuez une étiquette de version déjà utilisée, vous devez l'attribuer uniquement aux versions déjà chargées. Par exemple, si vous souhaitez déplacer une étiquette pointant vers la version N vers la version N+1, vous pouvez d'abord soumettre une configuration contenant les versions N et N+1, puis soumettre une configuration contenant la version N+1, l'étiquette pointant vers N+1 et pas de version N.

Utilisation REST

Si vous utilisez la surface de l'API REST pour effectuer des requêtes d'inférence, au lieu d'utiliser

/v1/models/<model name>/versions/<version number>

demandez simplement une version à l'aide d'un label en structurant votre chemin de requête comme ceci

/v1/models/<model name>/labels/<version label> .

Notez que l'étiquette de version est limitée à une séquence de caractères Word, composée de caractères alphanumériques et de traits de soulignement (c'est-à-dire [a-zA-Z0-9_]+ ).

Configuration de surveillance

Vous pouvez fournir une configuration de surveillance au serveur en utilisant l'indicateur --monitoring_config_file pour spécifier un fichier contenant un tampon de protocole MonitoringConfig . Voici un exemple :

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

Pour lire les métriques de l'URL de surveillance ci-dessus, vous devez d'abord activer le serveur HTTP en définissant l'indicateur --rest_api_port . Vous pouvez ensuite configurer votre serveur Prometheus pour extraire les métriques de Model Server en lui transmettant les valeurs de --rest_api_port et path .

Tensorflow Serving collecte toutes les métriques capturées par Serving ainsi que par Tensorflow principal.

Configuration par lots

Model Server a la capacité de regrouper les requêtes dans divers paramètres afin d'obtenir un meilleur débit. La planification de ce traitement par lots est effectuée globalement pour tous les modèles et versions de modèles sur le serveur afin de garantir la meilleure utilisation possible des ressources sous-jacentes, quel que soit le nombre de modèles ou de versions de modèles actuellement servis par le serveur ( plus de détails ). Vous pouvez activer ce comportement en définissant l'indicateur --enable_batching et le contrôler en passant une configuration à l'indicateur --batching_parameters_file .

Exemple de fichier de paramètres de traitement par lots :

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

Veuillez vous référer au guide de traitement par lots pour une discussion approfondie et à la section sur les paramètres pour comprendre comment définir les paramètres.

Divers Drapeaux

En plus des drapeaux abordés jusqu’à présent dans le guide, nous en énumérons ici quelques autres notables. Pour une liste complète, veuillez vous référer au code source .

  • --port : Port sur lequel écouter l'API gRPC
  • --rest_api_port : Port sur lequel écouter l'API HTTP/REST
  • --rest_api_timeout_in_ms : Délai d'expiration pour les appels API HTTP/REST
  • --file_system_poll_wait_seconds : La période avec laquelle le serveur interroge le système de fichiers pour les nouvelles versions de modèle au model_base_path respectif de chaque modèle
  • --enable_model_warmup : Active le préchauffage du modèle à l'aide des PredictionLogs fournis par l'utilisateur dans le répertoire assets.extra/
  • --mixed_precision=bfloat16 : Active la précision mixte automatique BF16