Architecture

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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érimentations, tout en conservant la même architecture de serveur et les mêmes API. TensorFlow Serving fournit 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 :

Servables

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 Servable peut inclure n'importe quoi, d'un seul fragment d'une table de recherche à un modèle unique à 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 servables typiques incluent les éléments 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 toute la durée de vie d'une seule instance de serveur. Cela permet de charger de nouvelles configurations d'algorithmes, des pondérations et d'autres données au fil du temps. Les versions permettent de charger simultanément plusieurs versions d'un servable, ce qui permet un déploiement et une expérimentation progressifs. Au moment de la diffusion, 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 de plusieurs servables. Un modèle appris par machine 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

Une servable peut aussi correspondre à une fraction d'un modèle. Par exemple, une grande table de recherche peut être partagée entre plusieurs instances de TensorFlow Serving.

Chargeurs

Les chargeurs gèrent le cycle de vie d'un servable. 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 chargeurs standardisent les API pour charger et décharger un servable.

Sources

Les sources sont des modules de plugin qui trouvent et fournissent des servables. Chaque source fournit zéro ou plusieurs flux utilisables. Pour chaque flux utilisable, une source fournit une instance de chargeur pour chaque version qu'elle rend disponible pour être chargée. (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 peuvent 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 souhaitées

Les versions aspirées représentent l'ensemble des versions utilisables qui doivent être chargées et prêtes. Les sources communiquent cet ensemble de versions exploitables pour un seul flux exploitable à la fois. Lorsqu'une source donne une nouvelle liste de versions aspirées au gestionnaire, elle remplace la liste précédente pour ce flux utilisable. Le gestionnaire 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 gestionnaires gèrent le cycle de vie complet des Servables, notamment :

  • chargement des servables
  • servir Servables
  • déchargement des servables

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 aspiré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 pour décharger jusqu'à ce qu'une version plus récente finisse de se charger, selon une politique garantissant qu'au moins une version est chargée à tout moment.

Les gestionnaires de service TensorFlow fournissent une interface simple et étroite -- GetServableHandle() -- permettant aux clients d'accéder aux instances de service chargées.

Cœur

À l'aide des API TensorFlow Serving standard, TensorFlow Serving Core gère les aspects suivants des servables :

  • cycle de la vie
  • métrique

TensorFlow Serving Core traite les servables et les chargeurs comme des objets opaques.

La vie d'un serviteur

diagramme d'architecture de service tf

D'une manière générale:

  1. Les sources créent des chargeurs pour les versions utilisables.
  2. Les chargeurs sont envoyés en tant que versions souhaitées au gestionnaire, qui les charge et les sert aux demandes des clients.

Plus en détail:

  1. 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.
  2. La source utilise un rappel pour informer le gestionnaire de la version aspirée.
  3. Le gestionnaire applique la politique de version configurée pour déterminer la prochaine action à entreprendre, qui peut être de décharger une version précédemment chargée ou de charger la nouvelle version.
  4. Si le Manager détermine qu'il est sûr, il donne au Loader les ressources nécessaires et dit au Loader de charger la nouvelle version.
  5. Les clients demandent au gestionnaire 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, supposons 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.

  1. La source détecte une nouvelle version des poids du modèle. Il crée un Loader qui contient un pointeur vers les données du modèle sur le disque.
  2. La source informe le gestionnaire dynamique de la version aspirée.
  3. Le gestionnaire dynamique applique la politique de version et décide de charger la nouvelle version.
  4. Le Dynamic Manager indique au Loader qu'il y a suffisamment de mémoire. Le Loader instancie le graphique TensorFlow avec les nouvelles pondérations.
  5. 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 stratégies de version spécifient la séquence de chargement et de déchargement de la version dans un seul flux utilisable.

TensorFlow Serving inclut deux règles qui s'adaptent à la plupart des cas d'utilisation connus. Il s'agit de la politique de préservation de la disponibilité (évitez de ne laisser aucune version chargée ; chargez généralement une nouvelle version avant de décharger l'ancienne) et de la politique de préservation des ressources (évitez d'avoir deux versions chargées simultanément, nécessitant ainsi le double de ressources ; déchargez une ancienne version avant de charger un nouveau). Pour une utilisation simple de TensorFlow Serving où la disponibilité de service d'un modèle est importante et le coût des ressources faible, 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 la gestion des versions sur plusieurs instances de serveur, la stratégie de préservation des ressources nécessite le moins de ressources (pas de mémoire tampon supplémentaire pour le chargement de nouvelles versions).

La 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 pour encapsuler 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 l'ajout d'algorithmes et de backends de données. TensorFlow est l'un de ces algorithmes backend. Par exemple, vous implémenteriez un nouveau chargeur afin de charger, de fournir un 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 demandes en une seule demande peut réduire considérablement le coût d'exécution de l'inférence, en particulier en présence d'accélérateurs matériels tels que les GPU. TensorFlow Serving inclut un widget de traitement par lots des requêtes qui permet aux clients de regrouper facilement leurs inférences spécifiques au type dans les requêtes en requêtes par lots que les systèmes d'algorithmes peuvent traiter plus efficacement. Consultez le Guide de mise en lot pour plus d'informations.