Configuração de serviço do Tensorflow

Neste guia, abordaremos os vários pontos de configuração do Tensorflow Serving.

Visão geral

Embora a maioria das configurações esteja relacionada ao Model Server, há muitas maneiras de especificar o comportamento do Tensorflow Serving:

Configuração do servidor de modelo

A maneira mais fácil para servir um modelo é fornecer os --model_name e --model_base_path bandeiras (ou definir o MODEL_NAME variável de ambiente se estiver usando Docker). No entanto, se você quiser atender a vários modelos ou configurar opções como frequência de pesquisa para novas versões, poderá fazê-lo escrevendo um arquivo de configuração do Model Server.

Você pode fornecer este arquivo de configuração usando o --model_config_file bandeira e instruir Tensorflow Servindo periodicamente pesquisa para as versões atualizadas deste arquivo de configuração para o caminho specifed definindo o --model_config_file_poll_wait_seconds bandeira.

Exemplo usando o 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

Recarregando a configuração do Model Server

Há duas maneiras de recarregar a configuração do Model Server:

  • Ao definir o --model_config_file_poll_wait_seconds bandeira para instruir o servidor para verificar periodicamente para um novo arquivo de configuração em --model_config_file filepath.

  • Emitindo HandleReloadConfigRequest chamadas RPC para o servidor e fornecimento de uma nova configuração modelo de servidor por meio de programação.

Por favor note que cada vez que o servidor carrega o novo arquivo de configuração, ele vai agir para perceber o conteúdo da nova configuração especificada e somente a nova configuração especificada. Isso significa que se o modelo A estava presente no primeiro arquivo de configuração, que é substituído por um arquivo que contém apenas o modelo B, o servidor carregará o modelo B e descarregará o modelo A.

Detalhes de configuração do servidor de modelo

O arquivo de configuração modelo de servidor fornecido deve ser ModelServerConfig buffer de protocolo .

Para todos, mas a maioria dos casos de uso avançados, você vai querer usar a opção ModelConfigList, que é uma lista de ModelConfig buffers de protocolo. Aqui está um exemplo básico, antes de mergulharmos nas opções avançadas abaixo.

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'
  }
}

Configurando um modelo

Cada ModelConfig especifica um modelo a ser servido, incluindo seu nome e o caminho onde o Model Server deve procurar as versões do modelo a servir, conforme visto no exemplo acima. Por padrão, o servidor servirá a versão com o maior número de versão. Esse padrão pode ser substituído alterando o campo model_version_policy.

Servindo uma versão específica de um modelo

Para veicular uma versão específica do modelo, em vez de sempre fazer a transição para aquela com o maior número de versão, defina model_version_policy como "específico" e forneça o número da versão que deseja veicular. Por exemplo, para fixar a versão 42 como aquela a ser veiculada:

model_version_policy {
  specific {
    versions: 42
  }
}

Esta opção é útil para reverter para uma versão válida, caso um problema seja descoberto com a(s) versão(ões) mais recente(s).

Servindo várias versões de um modelo

Para servir várias versões do modelo simultaneamente, por exemplo, para habilitar uma nova versão provisória com uma fatia de tráfego, defina model_version_policy como "específico" e forneça vários números de versão. Por exemplo, para servir as versões 42 e 43:

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

Atribuindo rótulos de string a versões de modelo, para simplificar Canary e Rollback

Às vezes, é útil adicionar um nível de indireção às versões do modelo. Em vez de informar a todos os seus clientes que eles devem consultar a versão 42, você pode atribuir um alias como "stable" para a versão que os clientes devem consultar no momento. Se você quiser redirecionar uma fatia do tráfego para uma versão provisória do modelo canário, poderá usar um segundo alias "canário".

Você pode configurar esses aliases de versão do modelo ou rótulos, assim:

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

No exemplo acima, você está servindo as versões 42 e 43 e associando o rótulo "estável" à versão 42 e o rótulo "canário" à versão 43. Você pode fazer com que seus clientes direcionem consultas para um "estável" ou "canário" (talvez com base em hash da ID de usuário) usando o campo version_label do ModelSpec buffer de protocolo, e avançar a etiqueta no servidor sem notificar os clientes. Assim que terminar de canaryar a versão 43 e estiver pronto para promovê-la para estável, você pode atualizar a configuração para:

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

Se você precisar executar uma reversão posteriormente, poderá reverter para a configuração antiga que possui a versão 42 como "estável". Caso contrário, você pode avançar descarregando a versão 42 e carregando a nova versão 44 quando estiver pronta e, em seguida, avançando o rótulo canário para 44 e assim por diante.

Por favor, note que os rótulos só pode ser atribuído a versões de modelos que já estão carregados e disponíveis para servir. Uma vez que uma versão do modelo está disponível, pode-se recarregar a configuração do modelo em tempo real para atribuir um rótulo a ele. Isto pode ser conseguido usando um HandleReloadConfigRequest RPC ou se o servidor está configurado para consultar periodicamente o sistema de arquivos para o arquivo de configuração, como descrito acima .

Se você gostaria de atribuir um rótulo para uma versão que ainda não está carregado (por ex., Fornecendo tanto a versão do modelo e o rótulo no momento da inicialização), então você deve definir o --allow_version_labels_for_unavailable_models bandeira para true, que permite que novos rótulos para ser atribuído a versões de modelo que ainda não foram carregadas.

Observe que isso se aplica apenas a novos rótulos de versão (ou seja, aqueles não atribuídos a uma versão atualmente). Isso é para garantir que durante as trocas de versão, o servidor não atribua prematuramente o rótulo à nova versão, descartando assim todas as solicitações destinadas a esse rótulo enquanto a nova versão está sendo carregada.

Para cumprir esta verificação de segurança, ao reatribuir uma etiqueta de versão já em uso, você deve atribuí-la apenas às versões já carregadas. Por exemplo, se você quiser mover um rótulo da versão N para a versão N+1, primeiro envie uma configuração contendo a versão N e N+1 e, em seguida, envie uma configuração que contenha a versão N+1, o rótulo apontando para N+1 e nenhuma versão N.

Uso REST

Se você estiver usando a superfície da API REST para fazer solicitações de inferência, em vez de usar

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

basta solicitar uma versão usando um rótulo estruturando seu caminho de solicitação assim

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

Note-se que etiqueta versão é restrita a uma sequência de caracteres da palavra, composto por caracteres e sublinhados alphanumeral (isto é, [a-zA-Z0-9_]+ ).

Configuração de monitoramento

Você pode fornecer uma configuração de monitoramento para o servidor usando o --monitoring_config_file bandeira para especificar um arquivo contendo uma MonitoringConfig buffer de protocolo. Aqui está um exemplo:

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

Para ler métricas do acima monitoramento URL, você primeiro precisa ativar o servidor HTTP, definindo o --rest_api_port bandeira. Em seguida, você pode configurar seu Prometheus Server para métricas puxar modelo de servidor, passando-os valores de --rest_api_port e path .

O Tensorflow Serving coleta todas as métricas capturadas pelo Serving, bem como pelo Tensorflow principal.

Configuração de lote

O Model Server tem a capacidade de processar solicitações em lote em uma variedade de configurações para obter um melhor rendimento. O agendamento para esta dosagem é feito globalmente para todos os modelos e versões do modelo no servidor para assegurar a melhor utilização possível dos recursos subjacentes, não importa quantas modelos ou versões do modelo estão atualmente sendo servido pelo servidor ( mais detalhes ). Você pode habilitar esse comportamento, definindo o --enable_batching bandeira e controlá-lo por meio de um config para o --batching_parameters_file bandeira.

Exemplo de arquivo de parâmetros de lote:

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

Consulte o guia de dosagem para uma discussão aprofundada e consulte a seção sobre parâmetros para entender como para definir os parâmetros.

Sinalizadores diversos

Além das bandeiras abordadas até agora no guia, aqui listamos algumas outras notáveis. Para uma lista completa, consulte o código-fonte .

  • --port : Porto para escutar para gRPC API
  • --rest_api_port : Porto para escutar para HTTP / REST API
  • --rest_api_timeout_in_ms : tempo de espera para chamadas de API HTTP / REST
  • --file_system_poll_wait_seconds : O período com o qual as pesquisas de servidores do sistema de arquivos para novas versões do modelo no respectivo model_base_path de cada modelo
  • --enable_model_warmup : Permite modelo warmup usando PredictionLogs fornecidos pelo usuário em assets.extra / diretório