Configurazione del servizio Tensorflow

In questa guida esamineremo i numerosi punti di configurazione per Tensorflow Serving.

Panoramica

Sebbene la maggior parte delle configurazioni si riferisca al Model Server, esistono molti modi per specificare il comportamento di Tensorflow Serving:

Configurazione del server modello

Il modo più semplice per servire un modello è fornire i flag --model_name e --model_base_path (o impostare la variabile di ambiente MODEL_NAME se si utilizza Docker). Tuttavia, se desideri servire più modelli o configurare opzioni come la frequenza di polling per le nuove versioni, puoi farlo scrivendo un file di configurazione Model Server.

Puoi fornire questo file di configurazione utilizzando il flag --model_config_file e indicare a Tensorflow Serving di eseguire periodicamente il polling per le versioni aggiornate di questo file di configurazione nel percorso specificato impostando il flag --model_config_file_poll_wait_seconds .

Esempio utilizzando Docker: 

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

Ricaricamento della configurazione del Model Server

Esistono due modi per ricaricare la configurazione del Model Server:

  • Impostando il flag --model_config_file_poll_wait_seconds per indicare al server di verificare periodicamente la presenza di un nuovo file di configurazione in --model_config_file filepath.

  • Emettendo chiamate RPC HandleReloadConfigRequest al server e fornendo una nuova configurazione Model Server a livello di codice.

Tieni presente che ogni volta che il server carica il nuovo file di configurazione, agirà per realizzare il contenuto della nuova configurazione specificata e solo la nuova configurazione specificata. Ciò significa che se il modello A era presente nel primo file di configurazione, che viene sostituito con un file che contiene solo il modello B, il server caricherà il modello B e scaricherà il modello A.

Dettagli di configurazione del server modello

Il file di configurazione Model Server fornito deve essere un buffer del protocollo ModelServerConfig .

Per tutti i casi d'uso tranne quelli più avanzati, ti consigliamo di utilizzare l'opzione ModelConfigList, che è un elenco di buffer del protocollo ModelConfig . Ecco un esempio di base, prima di immergerci nelle opzioni avanzate di seguito. 

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

Configurazione di un modello

Ogni ModelConfig specifica un modello da servire, incluso il nome e il percorso in cui il Model Server deve cercare le versioni del modello da servire, come mostrato nell'esempio precedente. Per impostazione predefinita, il server servirà la versione con il numero di versione più grande. Questa impostazione predefinita può essere sostituita modificando il campo model_version_policy.

Servire una versione specifica di un modello

Per servire una versione specifica del modello, anziché passare sempre a quella con il numero di versione più grande, imposta model_version_policy su "specific" e fornisci il numero di versione che desideri servire. Ad esempio, per fissare la versione 42 come quella da servire:

model_version_policy {
  specific {
    versions: 42
  }
}

Questa opzione è utile per ripristinare una versione valida, nel caso in cui venga rilevato un problema con le versioni più recenti.

Servire più versioni di un modello

Per servire più versioni del modello contemporaneamente, ad esempio per abilitare il canarying di una nuova versione provvisoria con una fetta di traffico, imposta model_version_policy su "specific" e fornisci più numeri di versione. Ad esempio, per servire le versioni 42 e 43: 

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

Assegnazione di etichette di stringa alle versioni del modello, per semplificare Canary e Rollback

A volte è utile aggiungere un livello di riferimento indiretto alle versioni del modello. Invece di far sapere a tutti i tuoi client che dovrebbero eseguire query sulla versione 42, puoi assegnare un alias come "stable" a qualunque versione sia attualmente quella su cui i client dovrebbero eseguire query. Se desideri reindirizzare una parte del traffico a una versione provvisoria del modello canary, puoi utilizzare un secondo alias "canary".

Puoi configurare questi alias o etichette della versione del modello, in questo modo:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

Nell'esempio sopra, stai servendo le versioni 42 e 43 e associ l'etichetta "stable" alla versione 42 e l'etichetta "canary" alla versione 43. Puoi chiedere ai tuoi clienti di indirizzare le query a uno tra "stable" o "canary" (magari basato sull'hashing dell'ID utente) utilizzando il campo version_label del buffer del protocollo ModelSpec e sposta l'etichetta sul server senza avvisare i client. Una volta terminato il canarying della versione 43 e sei pronto a promuoverla a stabile, puoi aggiornare la configurazione a:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

Se successivamente è necessario eseguire un rollback, è possibile ripristinare la vecchia configurazione con la versione 42 come "stabile". Altrimenti, puoi andare avanti scaricando la versione 42 e caricando la nuova versione 44 quando è pronta, quindi facendo avanzare l'etichetta canary alla 44 e così via.

Tieni presente che le etichette possono essere assegnate solo alle versioni del modello già caricate e disponibili per la pubblicazione. Una volta che la versione del modello è disponibile, è possibile ricaricare al volo la configurazione del modello per assegnargli un'etichetta. Ciò può essere ottenuto utilizzando una RPC HandleReloadConfigRequest o se il server è configurato per interrogare periodicamente il filesystem per il file di configurazione, come descritto sopra .

Se desideri assegnare un'etichetta a una versione non ancora caricata (ad esempio fornendo sia la versione del modello che l'etichetta all'avvio) allora devi impostare il flag --allow_version_labels_for_unavailable_models su true, che consente alle nuove etichette di essere assegnato alle versioni del modello non ancora caricate.

Tieni presente che ciò si applica solo alle etichette delle nuove versioni (ovvero quelle non assegnate a una versione attualmente). Questo per garantire che durante gli scambi di versione, il server non assegni prematuramente l'etichetta alla nuova versione, eliminando così tutte le richieste destinate a quell'etichetta mentre la nuova versione viene caricata.

Per rispettare questo controllo di sicurezza, se si riassegna un'etichetta di versione già in uso, è necessario assegnarla solo alle versioni già caricate. Ad esempio, se desideri spostare un'etichetta dal puntamento alla versione N alla versione N+1, puoi prima inviare una configurazione contenente la versione N e N+1, quindi inviare una configurazione che contiene la versione N+1, l'etichetta che punta a N+1 e nessuna versione N.

Utilizzo RESTO

Se stai utilizzando la superficie dell'API REST per effettuare richieste di inferenza, invece di utilizzare

/v1/models/<model name>/versions/<version number>

richiedi semplicemente una versione utilizzando un'etichetta strutturando il percorso della richiesta in questo modo

/v1/models/<model name>/labels/<version label> .

Tieni presente che l'etichetta della versione è limitata a una sequenza di caratteri Word, composta da caratteri alfanumerici e trattini bassi (ad esempio [a-zA-Z0-9_]+ ).

Monitoraggio della configurazione

È possibile fornire una configurazione di monitoraggio al server utilizzando il flag --monitoring_config_file per specificare un file contenente un buffer del protocollo MonitoringConfig . Ecco un esempio:

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

Per leggere i parametri dall'URL di monitoraggio riportato sopra, devi prima abilitare il server HTTP impostando il flag --rest_api_port . È quindi possibile configurare Prometheus Server per estrarre i parametri da Model Server passandogli i valori di --rest_api_port e path .

Tensorflow Serving raccoglie tutte le metriche acquisite da Serving e da Tensorflow principale.

Configurazione del batch

Model Server ha la capacità di raggruppare le richieste in una varietà di impostazioni per ottenere un throughput migliore. La pianificazione per questo batch viene eseguita a livello globale per tutti i modelli e le versioni del modello sul server per garantire il miglior utilizzo possibile delle risorse sottostanti, indipendentemente dal numero di modelli o versioni del modello attualmente serviti dal server ( maggiori dettagli ). Puoi abilitare questo comportamento impostando il flag --enable_batching e controllarlo passando una configurazione al flag --batching_parameters_file .

Esempio di file dei parametri di batching:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

Si prega di fare riferimento alla guida al batching per una trattazione approfondita e fare riferimento alla sezione sui parametri per capire come impostare i parametri.

Bandiere varie

Oltre alle bandiere trattate finora nella guida, qui ne elenchiamo alcune altre degne di nota. Per un elenco completo, fare riferimento al codice sorgente .

  • --port : porta su cui ascoltare l'API gRPC
  • --rest_api_port : porta su cui ascoltare l'API HTTP/REST
  • --rest_api_timeout_in_ms : timeout per le chiamate API HTTP/REST
  • --file_system_poll_wait_seconds : il periodo con cui il server interroga il filesystem per le nuove versioni del modello nel rispettivo model_base_path di ciascun modello
  • --enable_model_warmup : abilita il riscaldamento del modello utilizzando i PredictionLog forniti dall'utente nella directory asset.extra/
  • --mixed_precision=bfloat16 : abilita la precisione mista automatica BF16