TensorFlow Serving est un système de service flexible et hautes performances pour les modèles d'apprentissage automatique, conçu pour les environnements de production. TensorFlow Serving facilite le déploiement de nouveaux algorithmes et expériences, tout en conservant la même architecture de serveur et les mêmes API. TensorFlow Serving offre une intégration prête à l'emploi avec les modèles TensorFlow, mais peut être facilement étendu pour servir d'autres types de modèles.
Concepts clés
Pour comprendre l'architecture de TensorFlow Serving, vous devez comprendre les concepts clés suivants :
Services
Les servables sont l'abstraction centrale de TensorFlow Serving. Les servables sont les objets sous-jacents que les clients utilisent pour effectuer des calculs (par exemple, une recherche ou une inférence).
La taille et la granularité d’un Servable sont flexibles. Un seul serveur peut inclure n'importe quoi, depuis un seul fragment d'une table de recherche jusqu'à un seul modèle en passant par un tuple de modèles d'inférence. Les servables peuvent être de n'importe quel type et interface, permettant une flexibilité et des améliorations futures telles que :
- résultats en streaming
- API expérimentales
- modes de fonctionnement asynchrones
Les servables ne gèrent pas leur propre cycle de vie.
Les services typiques sont les suivants :
- un TensorFlow SavedModelBundle (
tensorflow::Session) - une table de recherche pour l'intégration ou les recherches de vocabulaire
Versions utilisables
TensorFlow Serving peut gérer une ou plusieurs versions d'un serveur pendant la durée de vie d'une seule instance de serveur. Cela permet de charger de nouvelles configurations d’algorithmes, pondérations et autres données au fil du temps. Les versions permettent de charger simultanément plusieurs versions d'un serveur, prenant ainsi en charge un déploiement et une expérimentation progressifs. Au moment du service, les clients peuvent demander soit la dernière version, soit un identifiant de version spécifique, pour un modèle particulier.
Flux utilisables
Un flux servable est la séquence de versions d'un servable, triées par numéros de version croissants.
Des modèles
TensorFlow Serving représente un modèle sous la forme d'un ou plusieurs servables. Un modèle appris automatiquement peut inclure un ou plusieurs algorithmes (y compris des poids appris) et des tables de recherche ou d'intégration.
Vous pouvez représenter un modèle composite comme suit :
- plusieurs servables indépendants
- composite unique utilisable
Un servable peut également correspondre à une fraction d'un modèle. Par exemple, une grande table de recherche pourrait être partagée entre de nombreuses instances TensorFlow Serving.
Chargeurs
Les chargeurs gèrent le cycle de vie d'un service. L'API Loader permet une infrastructure commune indépendante des algorithmes d'apprentissage spécifiques, des données ou des cas d'utilisation de produits impliqués. Plus précisément, les Loaders standardisent les API de chargement et de déchargement d'un servable.
Sources
Les sources sont des modules plug-in qui recherchent et fournissent des servables. Chaque source fournit zéro ou plusieurs flux utilisables. Pour chaque flux utilisable, une source fournit une instance de Loader pour chaque version qu'elle met à disposition pour le chargement. (Une source est en fait chaînée avec zéro ou plusieurs SourceAdapters, et le dernier élément de la chaîne émet les Loaders.)
L'interface de TensorFlow Serving pour les sources peut découvrir des servables à partir de systèmes de stockage arbitraires. TensorFlow Serving inclut des implémentations de source de référence communes. Par exemple, les sources peuvent accéder à des mécanismes tels que RPC et interroger un système de fichiers.
Les sources peuvent conserver un état partagé entre plusieurs servables ou versions. Ceci est utile pour les servables qui utilisent des mises à jour delta (diff) entre les versions.
Versions aspirées
Les versions aspirées représentent l'ensemble des versions servables qui doivent être chargées et prêtes. Les sources communiquent cet ensemble de versions diffusables pour un seul flux diffusable à la fois. Lorsqu'une source donne une nouvelle liste de versions souhaitées au gestionnaire, elle remplace la liste précédente pour ce flux utilisable. Le Manager décharge toutes les versions précédemment chargées qui n'apparaissent plus dans la liste.
Consultez le didacticiel avancé pour voir comment fonctionne le chargement de version en pratique.
Gestionnaires
Les responsables gèrent le cycle de vie complet des Servables, notamment :
- chargement des services
- servir des servants
- déchargement des serveurs
Les gestionnaires écoutent les sources et suivent toutes les versions. Le gestionnaire essaie de répondre aux demandes des sources, mais peut refuser de charger une version souhaitée si, par exemple, les ressources requises ne sont pas disponibles. Les gestionnaires peuvent également reporter un « déchargement ». Par exemple, un gestionnaire peut attendre le déchargement jusqu'à la fin du chargement d'une version plus récente, sur la base d'une politique garantissant qu'au moins une version est chargée à tout moment.
Les gestionnaires de serveurs TensorFlow fournissent une interface simple et étroite ( GetServableHandle() ) permettant aux clients d'accéder aux instances servables chargées.
Cœur
À l'aide des API TensorFlow Serving standard, TensorFlow Serving Core gère les aspects suivants des servables :
- cycle de vie
- métrique
TensorFlow Serving Core traite les servables et les chargeurs comme des objets opaques.
La vie d'un serviteur
D'une manière générale:
- Les sources créent des chargeurs pour les versions utilisables.
- Les chargeurs sont envoyés en tant que versions aspirées au gestionnaire, qui les charge et les sert aux demandes des clients.
Plus en détail:
- Un plugin Source crée un Loader pour une version spécifique. Le Loader contient toutes les métadonnées dont il a besoin pour charger le Servable.
- La source utilise un rappel pour informer le gestionnaire de la version souhaitée.
- Le gestionnaire applique la stratégie de version configurée pour déterminer la prochaine action à entreprendre, qui peut consister à décharger une version précédemment chargée ou à charger la nouvelle version.
- Si le gestionnaire détermine que c'est sûr, il donne au chargeur les ressources requises et demande au chargeur de charger la nouvelle version.
- Les clients demandent au Manager le Servable, soit en spécifiant explicitement une version, soit en demandant simplement la dernière version. Le Manager renvoie un handle pour le Servable.
Par exemple, disons qu'une source représente un graphique TensorFlow avec des pondérations de modèle fréquemment mises à jour. Les poids sont stockés dans un fichier sur disque.
- La Source détecte une nouvelle version des poids du modèle. Il crée un chargeur qui contient un pointeur vers les données du modèle sur le disque.
- La Source informe le Dynamic Manager de la Version Aspirée.
- Le Dynamic Manager applique la Politique de Version et décide de charger la nouvelle version.
- Le Dynamic Manager indique au Loader qu'il y a suffisamment de mémoire. Le Loader instancie le graphique TensorFlow avec les nouveaux poids.
- Un client demande un handle vers la dernière version du modèle et Dynamic Manager renvoie un handle vers la nouvelle version du Servable.
Extensibilité
TensorFlow Serving fournit plusieurs points d'extension où vous pouvez ajouter de nouvelles fonctionnalités.
Politique de version
Les politiques de version spécifient la séquence de chargement et de déchargement des versions au sein d'un seul flux utilisable.
TensorFlow Serving comprend deux politiques qui s'adaptent à la plupart des cas d'utilisation connus. Il s'agit de la politique de préservation de la disponibilité (éviter de laisser zéro version chargée ; charger généralement une nouvelle version avant de décharger une ancienne) et de la politique de préservation des ressources (éviter d'avoir deux versions chargées simultanément, nécessitant ainsi le double des ressources ; décharger une ancienne version avant de charger un nouveau). Pour une utilisation simple de TensorFlow Serving où la disponibilité du service d'un modèle est importante et les coûts de ressources faibles, la politique de préservation de la disponibilité garantira que la nouvelle version est chargée et prête avant de décharger l'ancienne. Pour une utilisation sophistiquée de TensorFlow Serving, par exemple pour gérer des versions sur plusieurs instances de serveur, la politique de préservation des ressources nécessite le moins de ressources (pas de tampon supplémentaire pour le chargement de nouvelles versions).
Source
Les nouvelles sources pourraient prendre en charge de nouveaux systèmes de fichiers, offres cloud et backends d'algorithmes. TensorFlow Serving fournit des éléments de base communs pour faciliter et accélérer la création de nouvelles sources. Par exemple, TensorFlow Serving inclut un utilitaire permettant d'envelopper le comportement d'interrogation autour d'une source simple. Les sources sont étroitement liées aux chargeurs pour des algorithmes spécifiques et des servables d'hébergement de données.
Consultez le document Source personnalisée pour en savoir plus sur la création d'une source personnalisée.
Chargeurs
Les chargeurs sont le point d'extension pour ajouter des algorithmes et des backends de données. TensorFlow est l'un de ces backends d'algorithme. Par exemple, vous implémenterez un nouveau Loader afin de charger, de fournir l’accès et de décharger une instance d’un nouveau type de modèle d’apprentissage automatique utilisable. Nous prévoyons de créer des chargeurs pour les tables de recherche et des algorithmes supplémentaires.
Consultez le document Servable personnalisé pour savoir comment créer un servable personnalisé.
Doseur
Le regroupement de plusieurs requêtes en une seule requête peut réduire considérablement le coût d’inférence, en particulier en présence d’accélérateurs matériels tels que les GPU. TensorFlow Serving comprend un widget de traitement par lots de requêtes qui permet aux clients de regrouper facilement leurs inférences spécifiques au type à travers les requêtes en requêtes par lots que les systèmes algorithmiques peuvent traiter plus efficacement. Consultez le Guide de mise en lots pour plus d'informations.