Ce didacticiel vous montre comment utiliser les composants TensorFlow Serving pour exporter un modèle TensorFlow formé et utiliser le serveur tensorflow_model_server standard pour le servir. Si vous êtes déjà familier avec tensorflow service, et vous voulez en savoir plus sur la façon dont fonctionnent les internes du serveur, consultez le tensorflow service tutoriel avancé .
Ce didacticiel utilise un modèle de régression Softmax simple qui classe les chiffres manuscrits. Il est très similaire à celui présenté dans le tutoriel tensorflow sur la classification d'image en utilisant l'ensemble de données MNIST mode .
Le code de ce tutoriel se compose de deux parties :
Un fichier Python, mnist_saved_model.py , que les trains et les exportations du modèle.
Un ModelServer binaire qui peut être soit installé à l' aide Apt, ou préparés à partir d' un fichier de C ( de main.cc ). Les tensorflow service découvre ModelServer nouveaux modèles exportés et gère un GRPC service pour les servir.
Avant de commencer, d' abord installer Docker .
Entraîner et exporter le modèle TensorFlow
Pour la phase d'apprentissage, le graphe de tensorflow est lancé en session tensorflow sess
, avec le tenseur d'entrée (image) en tant que x
et tenseur de sortie (score Softmax) sous la forme y
.
Ensuite , nous utilisons de tensorflow module SavedModelBuilder pour exporter le modèle. SavedModelBuilder
enregistre un « instantané » du modèle formé pour un stockage fiable afin qu'il puisse être chargé plus tard pour l' inférence.
Pour plus de détails sur le format SavedModel, s'il vous plaît consulter la documentation à SavedModel README.md .
De mnist_saved_model.py , voici un court extrait de code pour illustrer le processus général de l' enregistrement d' un modèle sur le disque.
export_path_base = sys.argv[-1]
export_path = os.path.join(
tf.compat.as_bytes(export_path_base),
tf.compat.as_bytes(str(FLAGS.model_version)))
print('Exporting trained model to', export_path)
builder = tf.saved_model.builder.SavedModelBuilder(export_path)
builder.add_meta_graph_and_variables(
sess, [tf.compat.v1.saved_model.tag_constants.SERVING],
signature_def_map={
'predict_images':
prediction_signature,
tf.compat.v1.saved_model.signature_constants
.DEFAULT_SERVING_SIGNATURE_DEF_KEY:
classification_signature,
},
main_op=tf.compat.v1.tables_initializer(),
strip_default_attrs=True)
builder.save()
SavedModelBuilder.__init__
prend l'argument suivant:
-
export_path
est le chemin du répertoire d'exportation.
SavedModelBuilder
va créer le répertoire si elle n'existe pas. Dans l'exemple, nous concaténons l'argument de ligne de commande et FLAGS.model_version
pour obtenir le répertoire d'exportation. FLAGS.model_version
spécifie la version du modèle. Vous devez spécifier une valeur entière supérieure lors de l'exportation d'une version plus récente du même modèle. Chaque version sera exportée vers un sous-répertoire différent sous le chemin donné.
Vous pouvez ajouter des méta graphique et les variables au constructeur en utilisant SavedModelBuilder.add_meta_graph_and_variables()
avec les arguments suivants:
sess
est la session de tensorflow qui détient le modèle formé vous exportez.tags
est l'ensemble des balises avec lequel enregistrer le graphique méta. Dans ce cas, puisque nous avons l' intention d'utiliser le graphique dans le service, nous utilisons leserve
balise de constantes de balise SavedModel prédéfinies. Pour plus de détails, consultez tag_constants.py et documentation de l' API tensorflow connexes .signature_def_map
spécifie la carte de clé fournie par l' utilisateur pour une signature à un tensorflow :: SignatureDef à ajouter au graphique méta. La signature spécifie le type de modèle en cours d'exportation et les tenseurs d'entrée/sortie auxquels se lier lors de l'exécution de l'inférence.La clé de signature spéciale
serving_default
spécifie la valeur par défaut au service signature. La clé de def de signature de service par défaut, ainsi que d'autres constantes liées aux signatures, sont définies dans le cadre des constantes de signature SavedModel. Pour plus de détails, consultez signature_constants.py et documentation de l' API tensorflow connexes .De plus, pour defs aider à construire la signature facilement, l'API SavedModel fournit utils def signature .. Plus précisément, dans l'original mnist_saved_model.py fichier, nous utilisons
signature_def_utils.build_signature_def()
pour construirepredict_signature
etclassification_signature
.À titre d'exemple de la façon dont
predict_signature
est défini, l'util prend les arguments suivants:inputs={'images': tensor_info_x}
spécifie l'info tenseur d'entrée.outputs={'scores': tensor_info_y}
spécifie les scores d' info tenseur.method_name
est la méthode utilisée pour l'inférence. Pour toute demande de prévision, il doit être réglé surtensorflow/serving/predict
. Pour les autres noms de méthode, voir signature_constants.py et documentation de l' API tensorflow connexes .
Notez que tensor_info_x
et tensor_info_y
ont la structure de tensorflow::TensorInfo
buffer protocole défini ici . Pour construire facilement tenseurs infos, l'API tensorflow SavedModel fournit également utils.py , avec la documentation connexe API tensorflow .
Notez également que les images
et les scores
sont les noms d'alias de tenseur. Ils peuvent être tout ce que vous voulez chaînes uniques, et ils deviendront les noms logiques du tenseur x
et y
que vous faites référence à des tenseurs de liaison lors de l' envoi des demandes de prédiction plus tard.
Par exemple, si x
se réfère au tenseur avec le nom « long_tensor_name_foo » et y
fait référence au tenseur avec le nom « generated_tensor_name_bar », builder
enregistre tenseur nom logique réel mappage nom ( « images » -> « long_tensor_name_foo ») et ( 'scores ' -> 'generated_tensor_name_bar'). Cela permet à l'utilisateur de se référer à ces tenseurs avec leurs noms logiques lors de l'exécution de l'inférence.
Exécutons-le !
Tout d'abord, si vous ne l'avez pas encore fait, clonez ce dépôt sur votre machine locale :
git clone https://github.com/tensorflow/serving.git
cd serving
Effacez le répertoire d'exportation s'il existe déjà :
rm -rf /tmp/mnist
Entraînons maintenant le modèle :
tools/run_in_docker.sh python tensorflow_serving/example/mnist_saved_model.py \
/tmp/mnist
Cela devrait donner une sortie qui ressemble à :
Training model...
...
Done training!
Exporting trained model to models/mnist
Done exporting!
Jetons maintenant un œil au répertoire d'exportation.
$ ls /tmp/mnist
1
Comme mentionné ci-dessus, un sous-répertoire sera créé pour exporter chaque version du modèle. FLAGS.model_version
a la valeur par défaut de 1, donc le sous-répertoire correspondant 1
est créé.
$ ls /tmp/mnist/1
saved_model.pb variables
Chaque sous-répertoire de version contient les fichiers suivants :
saved_model.pb
est le tensorflow sérialisé :: SavedModel. Il comprend une ou plusieurs définitions de graphe du modèle, ainsi que des métadonnées du modèle telles que des signatures.les
variables
sont des fichiers qui contiennent les variables sérialisés des graphiques.
Avec cela, votre modèle TensorFlow est exporté et prêt à être chargé !
Charger le modèle exporté avec TensorFlow ModelServer standard
Utilisez une image de diffusion Docker pour charger facilement le modèle à diffuser :
docker run -p 8500:8500 \
--mount type=bind,source=/tmp/mnist,target=/models/mnist \
-e MODEL_NAME=mnist -t tensorflow/serving &
Tester le serveur
Nous pouvons utiliser le fourni mnist_client utilitaire pour tester le serveur. Le client télécharge les données de test MNIST, les envoie sous forme de requêtes au serveur et calcule le taux d'erreur d'inférence.
tools/run_in_docker.sh python tensorflow_serving/example/mnist_client.py \
--num_tests=1000 --server=127.0.0.1:8500
Cela devrait sortir quelque chose comme
...
Inference error rate: 11.13%
Nous nous attendons à une précision d'environ 90 % pour le modèle Softmax formé et nous obtenons un taux d'erreur d'inférence de 11 % pour les 1000 premières images de test. Cela confirme que le serveur charge et exécute le modèle entraîné avec succès !