Architettura

TensorFlow Serving è un sistema di pubblicazione flessibile e ad alte prestazioni per modelli di machine learning, progettato per ambienti di produzione. TensorFlow Serving semplifica la distribuzione di nuovi algoritmi ed esperimenti, mantenendo la stessa architettura del server e le stesse API. TensorFlow Serving fornisce un'integrazione pronta all'uso con i modelli TensorFlow, ma può essere facilmente esteso per servire altri tipi di modelli.

Concetti chiave

Per comprendere l'architettura di TensorFlow Serving, è necessario comprendere i seguenti concetti chiave:

Servi

I servi sono l'astrazione centrale in TensorFlow Serving. I server sono gli oggetti sottostanti che i client utilizzano per eseguire il calcolo (ad esempio, una ricerca o un'inferenza).

La dimensione e la granularità di un Servibile è flessibile. Un singolo server può includere qualsiasi cosa, da un singolo shard di una tabella di ricerca a un singolo modello a una tupla di modelli di inferenza. I server possono essere di qualsiasi tipo e interfaccia, consentendo flessibilità e miglioramenti futuri come:

  • risultati in streaming
  • API sperimentali
  • modalità di funzionamento asincrone

I server non gestiscono il proprio ciclo di vita.

I servizi tipici includono quanto segue:

  • un TensorFlow SavedModelBundle ( tensorflow::Session )
  • una tabella di ricerca per incorporare o ricerche di vocabolario

Versioni utilizzabili

TensorFlow Serving può gestire una o più versioni di un server per tutta la durata di una singola istanza del server. Ciò consente di caricare nel tempo nuove configurazioni dell'algoritmo, pesi e altri dati. Le versioni consentono di caricare più di una versione di un server contemporaneamente, supportando l'implementazione graduale e la sperimentazione. Al momento della pubblicazione, i clienti possono richiedere l'ultima versione o un ID versione specifico, per un particolare modello.

Stream servibili

Un flusso servibile è la sequenza di versioni di un server servibile, ordinate per numeri di versione crescenti.

Modelli

TensorFlow Serving rappresenta un modello come uno o più server. Un modello appreso dalla macchina può includere uno o più algoritmi (inclusi i pesi appresi) e tabelle di ricerca o incorporamento.

È possibile rappresentare un modello composito come uno dei seguenti:

  • più server indipendenti
  • singolo servitore composito

Un servable può anche corrispondere a una frazione di un modello. Ad esempio, una tabella di ricerca di grandi dimensioni potrebbe essere partizionata su molte istanze di TensorFlow Serving.

Caricatori

I caricatori gestiscono il ciclo di vita di un servizio. L'API Loader abilita un'infrastruttura comune indipendente da specifici algoritmi di apprendimento, dati o casi d'uso del prodotto coinvolti. In particolare, i caricatori standardizzano le API per il caricamento e lo scaricamento di un server.

Fonti

Le sorgenti sono moduli plug-in che trovano e forniscono servizi utilizzabili. Ciascuna sorgente fornisce zero o più flussi utilizzabili. Per ogni flusso servibile, un'origine fornisce un'istanza del programma di caricamento per ogni versione che rende disponibile per il caricamento. (Una sorgente è effettivamente concatenata insieme a zero o più SourceAdapters e l'ultimo elemento della catena emette i caricatori.)

L'interfaccia di TensorFlow Serving per Sources può rilevare i server da sistemi di storage arbitrari. TensorFlow Serving include implementazioni di origine di riferimento comuni. Ad esempio, le sorgenti possono accedere a meccanismi come RPC e possono eseguire il polling di un file system.

Le origini possono mantenere lo stato condiviso tra più server o versioni. Ciò è utile per i server che utilizzano gli aggiornamenti delta (diff) tra le versioni.

Versioni aspirate

Le versioni aspirate rappresentano l'insieme delle versioni utilizzabili che dovrebbero essere caricate e pronte. Le origini comunicano questo set di versioni servibili per un singolo flusso servibile alla volta. Quando una Sorgente fornisce un nuovo elenco di versioni aspirate al Manager, sostituisce l'elenco precedente per quel flusso servibile. Il Manager scarica tutte le versioni caricate in precedenza che non compaiono più nell'elenco.

Consulta il tutorial avanzato per vedere come funziona in pratica il caricamento della versione.

Gestori

I gestori gestiscono l'intero ciclo di vita dei servizi, inclusi:

  • caricamento dei servizi
  • servire Servi
  • scarico dei Servi

I gestori ascoltano le sorgenti e tengono traccia di tutte le versioni. Il Gestore cerca di soddisfare le richieste delle Sorgenti, ma può rifiutarsi di caricare una versione aspirata se, ad esempio, le risorse richieste non sono disponibili. I gestori possono anche posticipare uno "scarico". Ad esempio, un Manager può attendere lo scaricamento fino al termine del caricamento di una versione più recente, in base a una politica per garantire che almeno una versione venga caricata in ogni momento.

TensorFlow Serving Manager fornisce un'interfaccia semplice e ristretta, GetServableHandle() , per consentire ai client di accedere alle istanze servibili caricate.

Nucleo

Utilizzando le API standard di TensorFlow Serving, TensorFlow Serving Core gestisce i seguenti aspetti dei server:

  • ciclo vitale
  • metrica

TensorFlow Serving Core tratta i server e i caricatori come oggetti opachi.

Vita di un servitore

diagramma di architettura al servizio di tf

Ampiamente parlando:

  1. Le sorgenti creano caricatori per le versioni servibili.
  2. I caricatori vengono inviati come versioni aspirate al Manager, che li carica e li serve alle richieste dei clienti.

Più in dettaglio:

  1. Un plug-in Source crea un Loader per una versione specifica. Il caricatore contiene tutti i metadati necessari per caricare il server.
  2. The Source utilizza un callback per notificare al Manager la versione aspirata.
  3. Il Manager applica la policy della versione configurata per determinare l'azione successiva da intraprendere, che potrebbe essere scaricare una versione caricata in precedenza o caricare la nuova versione.
  4. Se il Manager determina che è sicuro, fornisce al Loader le risorse necessarie e dice al Loader di caricare la nuova versione.
  5. I clienti chiedono al Gestore il Servible, specificando esplicitamente una versione o semplicemente richiedendo l'ultima versione. Il Manager restituisce un handle per il server.

Ad esempio, supponiamo che una sorgente rappresenti un grafico TensorFlow con pesi del modello aggiornati di frequente. I pesi sono memorizzati in un file su disco.

  1. La sorgente rileva una nuova versione dei pesi del modello. Crea un Loader che contiene un puntatore ai dati del modello su disco.
  2. La Sorgente notifica al Gestore Dinamico della Versione Aspirata.
  3. Il Dynamic Manager applica la Policy della versione e decide di caricare la nuova versione.
  4. Il Dynamic Manager dice al Loader che c'è abbastanza memoria. Il Loader istanzia il grafico TensorFlow con i nuovi pesi.
  5. Un client richiede un handle all'ultima versione del modello e Dynamic Manager restituisce un handle alla nuova versione del server.

Estensibilità

TensorFlow Serving fornisce diversi punti di estensione in cui è possibile aggiungere nuove funzionalità.

Politica di versione

I criteri di versione specificano la sequenza di caricamento e scaricamento della versione all'interno di un singolo flusso servibile.

TensorFlow Serving include due criteri che soddisfano i casi d'uso più noti. Si tratta della politica di conservazione della disponibilità (evitare di lasciare zero versioni caricate; in genere caricare una nuova versione prima di scaricarne una vecchia) e della politica di conservazione delle risorse (evitare di caricare due versioni contemporaneamente, richiedendo quindi il doppio delle risorse; scaricare una versione precedente prima di caricare uno nuovo). Per un semplice utilizzo di TensorFlow Serving in cui la disponibilità del servizio di un modello è importante e il costo delle risorse basso, la politica di conservazione della disponibilità assicurerà che la nuova versione sia caricata e pronta prima di scaricare quella precedente. Per un utilizzo sofisticato di TensorFlow Serving, ad esempio la gestione delle versioni su più istanze del server, la politica di conservazione delle risorse richiede il minor numero di risorse (nessun buffer aggiuntivo per il caricamento di nuove versioni).

Fonte

Nuove sorgenti potrebbero supportare nuovi filesystem, offerte cloud e backend di algoritmi. TensorFlow Serving fornisce alcuni elementi costitutivi comuni per rendere facile e veloce la creazione di nuove fonti. Ad esempio, TensorFlow Serving include un'utilità per avvolgere il comportamento del polling attorno a una semplice fonte. Le origini sono strettamente correlate ai caricatori per algoritmi specifici e servizi di hosting di dati.

Consulta il documento Sorgente personalizzata per ulteriori informazioni su come creare una Sorgente personalizzata.

Caricatori

I caricatori sono il punto di estensione per l'aggiunta di algoritmi e backend di dati. TensorFlow è uno di questi backend di algoritmi. Ad esempio, implementeresti un nuovo programma di caricamento per caricare, fornire accesso e scaricare un'istanza di un nuovo tipo di modello di machine learning utilizzabile. Prevediamo di creare caricatori per tabelle di ricerca e algoritmi aggiuntivi.

Consulta il documento Pubblicabile personalizzato per informazioni su come creare un servizio personalizzato.

Dosatore

Il raggruppamento di più richieste in un'unica richiesta può ridurre significativamente il costo dell'esecuzione dell'inferenza, soprattutto in presenza di acceleratori hardware come le GPU. TensorFlow Serving include un widget di batch delle richieste che consente ai clienti di raggruppare facilmente le inferenze specifiche del tipo tra le richieste in richieste batch che i sistemi di algoritmi possono elaborare in modo più efficiente. Per ulteriori informazioni, vedere la Guida al dosaggio.