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 Modelo

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

Você pode fornecer esse arquivo de configuração usando o sinalizador --model_config_file e instruir o Tensorflow Serving a pesquisar periodicamente versões atualizadas desse arquivo de configuração no caminho especificado, definindo o sinalizador --model_config_file_poll_wait_seconds .

Exemplo usando 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 sinalizador --model_config_file_poll_wait_seconds para instruir o servidor a verificar periodicamente se há um novo arquivo de configuração no caminho do arquivo --model_config_file .

  • Ao emitir chamadas RPC HandleReloadConfigRequest para o servidor e fornecer uma nova configuração do Model Server programaticamente.

Observe que cada vez que o servidor carregar o novo arquivo de configuração, ele atuará para realizar o conteúdo da nova configuração especificada e apenas 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 Model Server

O arquivo de configuração do Model Server fornecido deve ser um buffer de protocolo ModelServerConfig .

Para todos os casos de uso, exceto os mais avançados, você desejará usar a opção ModelConfigList, que é uma lista de buffers de protocolo ModelConfig . 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 ser servido, conforme visto no exemplo acima. Por padrão, o servidor servirá a versão com o maior número de versão. Este padrão pode ser substituído alterando o campo model_version_policy.

Servindo uma versão específica de um modelo

Para servir 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 você gostaria de servir. 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 seja descoberto um problema com a(s) versão(ões) mais recente(s).

Servindo múltiplas versões de um modelo

Para servir várias versões do modelo simultaneamente, por exemplo, para permitir o canarying de 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 canário e reversão

À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 deveriam consultar a versão 42, você pode atribuir um alias como "estável" a qualquer versão que os clientes devam consultar no momento. Se quiser redirecionar uma fatia do tráfego para uma versão provisória do modelo canário, você poderá usar um segundo alias "canário".

Você pode configurar esses aliases ou rótulos de versão do modelo, 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 "estável" ou "canário" (talvez com base no hash do ID do usuário) usando o campo version_label do buffer do protocolo ModelSpec e avance o rótulo no servidor sem notificar os clientes. Quando terminar de fazer o canary da 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 posteriormente você precisar realizar uma reversão, poderá reverter para a configuração antiga que tem 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.

Observe que os rótulos só podem ser atribuídos a versões de modelo que já estão carregadas e disponíveis para veiculação. Assim que uma versão do modelo estiver disponível, pode-se recarregar a configuração do modelo rapidamente para atribuir um rótulo a ela. Isso pode ser conseguido usando um RPC HandleReloadConfigRequest ou se o servidor estiver configurado para pesquisar periodicamente o sistema de arquivos em busca do arquivo de configuração, conforme descrito acima .

Se você quiser atribuir um rótulo a uma versão que ainda não foi carregada (por exemplo, fornecendo a versão do modelo e o rótulo no momento da inicialização), você deve definir o sinalizador --allow_version_labels_for_unavailable_models como verdadeiro, o que permite que novos rótulos sejam ser atribuído a versões de modelo que ainda não foram carregadas.

Observe que isso se aplica apenas a rótulos de novas versões (ou seja, aqueles não atribuídos a uma versão atualmente). Isto é para garantir que durante as trocas de versão, o servidor não atribua prematuramente o rótulo à nova versão, eliminando 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 um rótulo de versão já em uso, você deverá atribuí-lo apenas a versões já carregadas. Por exemplo, se você quiser mover um rótulo que aponta para a versão N para a versão N+1, você pode primeiro enviar uma configuração contendo as versões N e N+1 e, em seguida, enviar 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>

simplesmente solicite uma versão usando um rótulo estruturando o caminho da solicitação da seguinte forma

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

Observe que o rótulo da versão é restrito a uma sequência de caracteres do Word, composta por caracteres alfanuméricos e sublinhados (ou seja [a-zA-Z0-9_]+ ).

Configuração de monitoramento

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

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

Para ler as métricas do URL de monitoramento acima, primeiro você precisa habilitar o servidor HTTP definindo o sinalizador --rest_api_port . Você pode então configurar seu servidor Prometheus para extrair métricas do Model Server, passando-lhe 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 agrupar solicitações em diversas configurações para obter melhor rendimento. O agendamento deste lote é feito globalmente para todos os modelos e versões de modelos no servidor para garantir a melhor utilização possível dos recursos subjacentes, independentemente de quantos modelos ou versões de modelos estão atualmente sendo servidos pelo servidor ( mais detalhes ). Você pode ativar esse comportamento definindo o sinalizador --enable_batching e controlá-lo passando uma configuração para o sinalizador --batching_parameters_file .

Arquivo de parâmetros de lote de exemplo:

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

Consulte o guia de lote para uma discussão aprofundada e consulte a seção sobre parâmetros para entender como defini-los.

Bandeiras Diversas

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

  • --port : porta para escutar a API gRPC
  • --rest_api_port : Porta para escutar API HTTP/REST
  • --rest_api_timeout_in_ms : Tempo limite para chamadas de API HTTP/REST
  • --file_system_poll_wait_seconds : O período com o qual o servidor pesquisa o sistema de arquivos em busca de novas versões de modelo no respectivo model_base_path de cada modelo
  • --enable_model_warmup : permite o aquecimento do modelo usando PredictionLogs fornecidos pelo usuário no diretório assets.extra/
  • --mixed_precision=bfloat16 : Habilita Precisão Mista Automática BF16