TensorFlow Serving è un sistema di servizio flessibile e ad alte prestazioni per modelli di machine learning, progettato per ambienti di produzione. TensorFlow Serving semplifica l'implementazione di nuovi algoritmi ed esperimenti, mantenendo la stessa architettura server e API. TensorFlow Serving fornisce un'integrazione immediata 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:
Servibili
I servi sono l'astrazione centrale in TensorFlow Serving. I servi sono gli oggetti sottostanti che i client utilizzano per eseguire calcoli (ad esempio, una ricerca o un'inferenza).
La dimensione e la granularità di un Servable sono flessibili. Un singolo Servible potrebbe includere qualsiasi cosa, da un singolo frammento di una tabella di ricerca a un singolo modello a una tupla di modelli di inferenza. I servable possono essere di qualsiasi tipo e interfaccia, consentendo flessibilità e miglioramenti futuri come:
- risultati in streaming
- API sperimentali
- modalità di funzionamento asincrone
I servible non gestiscono il proprio ciclo di vita.
I servizi tipici includono quanto segue:
- un TensorFlow SavedModelBundle (
tensorflow::Session) - una tabella di ricerca per l'incorporamento o la ricerca del vocabolario
Versioni utilizzabili
TensorFlow Serving può gestire una o più versioni di un servitore nel corso della durata di una singola istanza del server. Ciò consente di caricare nel tempo nuove configurazioni di algoritmi, pesi e altri dati. Le versioni consentono di caricare contemporaneamente più di una versione di un server, supportando l'implementazione e la sperimentazione graduali. Al momento del servizio, i clienti possono richiedere la versione più recente o un ID versione specifico, per un modello particolare.
Flussi servibili
Un flusso servibile è la sequenza di versioni di un servibile, ordinate in base al numero di versione crescente.
Modelli
TensorFlow Serving rappresenta un modello come uno o più servizi. Un modello di apprendimento automatico può includere uno o più algoritmi (inclusi i pesi appresi) e tabelle di ricerca o incorporamento.
È possibile rappresentare un modello composito come segue:
- più servi indipendenti
- singolo servitore composito
Un servibile può anche corrispondere ad una frazione di un modello. Ad esempio, una tabella di ricerca di grandi dimensioni potrebbe essere suddivisa in molte istanze di TensorFlow Serving.
Caricatori
I caricatori gestiscono il ciclo di vita di un servibile. L'API Loader abilita un'infrastruttura comune indipendente da specifici algoritmi di apprendimento, dati o casi d'uso del prodotto coinvolti. Nello specifico, i caricatori standardizzano le API per caricare e scaricare un servibile.
Fonti
Le sorgenti sono moduli plugin che trovano e forniscono servable. Ciascuna sorgente fornisce zero o più flussi servibili. Per ogni flusso servibile, un'origine fornisce un'istanza del caricatore per ogni versione che rende disponibile per il caricamento. (Una sorgente è effettivamente concatenata insieme a zero o più SourceAdapter e l'ultimo elemento della catena emette i caricatori.)
L'interfaccia di TensorFlow Serving per le sorgenti può rilevare servable da sistemi di archiviazione arbitrari. TensorFlow Serving include implementazioni di origine di riferimento comuni. Ad esempio, le origini possono accedere a meccanismi come RPC e interrogare un file system.
Le origini possono mantenere lo stato condiviso tra più servizi o versioni. Ciò è utile per i server che utilizzano aggiornamenti delta (diff) tra le versioni.
Versioni aspirate
Le versioni a cui si aspira rappresentano l'insieme di versioni utilizzabili che dovrebbero essere caricate e pronte. Le origini comunicano questo insieme di versioni gestibili per un singolo flusso gestibile alla volta. Quando una Sorgente fornisce al Gestore un nuovo elenco di versioni a cui aspira, 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 nella pratica il caricamento della versione.
Manager
I manager gestiscono l'intero ciclo di vita dei Servable, tra cui:
- caricamento dei servi
- servire i servi
- scarico dei servi
I manager ascoltano le fonti e tengono traccia di tutte le versioni. Il Gestore tenta di soddisfare le richieste delle Sorgenti, ma può rifiutarsi di caricare una versione ambita se, ad esempio, le risorse richieste non sono disponibili. I gestori possono anche posticipare uno "scarico". Ad esempio, un Manager può attendere lo scaricamento finché non termina il caricamento di una versione più recente, in base a una politica volta a garantire che almeno una versione venga caricata in ogni momento.
I gestori di servizi TensorFlow forniscono un'interfaccia semplice e ristretta, GetServableHandle() , per consentire ai client di accedere alle istanze gestibili caricate.
Nucleo
Utilizzando gli API TensorFlow Serving standard, TensorFlow Serving Core gestisce i seguenti aspetti dei servable:
- ciclo vitale
- metrica
TensorFlow Serving Core tratta i servable e i caricatori come oggetti opachi.
Vita da servitore
Ampiamente parlando:
- Le origini creano caricatori per versioni utilizzabili.
- I caricatori vengono inviati come versioni aspirate al Manager, che li carica e li serve in base alle richieste del cliente.
Più in dettaglio:
- Un plugin Source crea un Loader per una versione specifica. Il Loader contiene tutti i metadati necessari per caricare il Servable.
- La Sorgente utilizza un callback per notificare al Gestore la Versione Aspirata.
- Il Manager applica la policy di versione configurata per determinare l'azione successiva da intraprendere, che potrebbe essere quella di scaricare una versione caricata in precedenza o caricare la nuova versione.
- Se il Manager determina che è sicuro, fornisce al Loader le risorse richieste e dice al Loader di caricare la nuova versione.
- I client chiedono al Manager il Servable, specificando esplicitamente una versione o semplicemente richiedendo la versione più recente. Il Manager restituisce un handle per il Servable.
Ad esempio, supponiamo che una Source rappresenti un grafico TensorFlow con pesi del modello aggiornati frequentemente. I pesi vengono memorizzati in un file su disco.
- La Sorgente rileva una nuova versione dei pesi del modello. Crea un caricatore che contiene un puntatore ai dati del modello su disco.
- La Sorgente notifica al Gestore Dinamico la Versione Aspirata.
- Il Gestore Dinamico applica la Policy di Versione e decide di caricare la nuova versione.
- Il Dynamic Manager dice al Loader che c'è abbastanza memoria. Il Loader crea un'istanza del grafico TensorFlow con i nuovi pesi.
- Un client richiede un handle per l'ultima versione del modello e il Dynamic Manager restituisce un handle per la nuova versione del Servable.
Estensibilità
TensorFlow Serving fornisce diversi punti di estensione in cui puoi aggiungere nuove funzionalità.
Politica di versione
Le policy di versione specificano la sequenza di caricamento e scaricamento della versione all'interno di un singolo flusso gestibile.
TensorFlow Serving include due policy che soddisfano i casi d'uso più conosciuti. Si tratta della politica di conservazione della disponibilità (evitare di lasciare zero versioni caricate; in genere caricare una nuova versione prima di scaricare quella vecchia) e della politica di conservazione delle risorse (evitare di caricare due versioni contemporaneamente, richiedendo così il doppio delle risorse; scaricare una vecchia versione prima di caricare uno nuovo). Per un utilizzo semplice di TensorFlow Serving in cui la disponibilità di servizio di un modello è importante e i costi delle risorse sono bassi, la policy di conservazione della disponibilità garantirà che la nuova versione sia caricata e pronta prima di scaricare quella vecchia. Per un utilizzo sofisticato di TensorFlow Serving, ad esempio la gestione di versioni su più istanze del server, la policy di conservazione delle risorse richiede il minor numero di risorse (nessun buffer aggiuntivo per il caricamento di nuove versioni).
Fonte
Le nuove fonti 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 di polling attorno a una fonte semplice. Le origini sono strettamente correlate ai caricatori per algoritmi specifici e servable 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, potresti implementare un nuovo caricatore per caricare, fornire accesso e scaricare un'istanza di un nuovo tipo di modello di machine learning utilizzabile. Prevediamo la creazione di caricatori per tabelle di ricerca e algoritmi aggiuntivi.
Consulta il documento Servibile personalizzato per sapere come creare un servibile personalizzato.
Dosatore
L'unione 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 di richieste che consente ai client di raggruppare facilmente le inferenze specifiche del tipo tra richieste in richieste batch che i sistemi di algoritmi possono elaborare in modo più efficiente. Per ulteriori informazioni consultare la Guida all'invio in batch .