Konfiguracja obsługi Tensorflow

W tym przewodniku omówimy liczne punkty konfiguracji udostępniania Tensorflow.

Przegląd

Chociaż większość konfiguracji odnosi się do serwera modelu, istnieje wiele sposobów określenia zachowania udostępniania Tensorflow:

Konfiguracja serwera modelowego

Najłatwiejszym sposobem udostępnienia modelu jest podanie flag --model_name i --model_base_path (lub ustawienie zmiennej środowiskowej MODEL_NAME , jeśli używany jest Docker). Jeśli jednak chcesz obsługiwać wiele modeli lub skonfigurować opcje, takie jak częstotliwość odpytywania dla nowych wersji, możesz to zrobić, pisząc plik konfiguracyjny serwera modelu.

Możesz dostarczyć ten plik konfiguracyjny przy użyciu flagi --model_config_file i poinstruować Tensorflow Serving, aby okresowo sondował zaktualizowane wersje tego pliku konfiguracyjnego w określonej ścieżce, ustawiając flagę --model_config_file_poll_wait_seconds .

Przykład użycia Dockera:

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

Ponowne ładowanie konfiguracji serwera modelu

Istnieją dwa sposoby ponownego załadowania konfiguracji serwera modelu:

  • Ustawiając flagę --model_config_file_poll_wait_seconds , aby poinstruować serwer, aby okresowo sprawdzał dostępność nowego pliku konfiguracyjnego w ścieżce pliku --model_config_file .

  • Wydając wywołania RPC HandleReloadConfigRequest do serwera i programowo dostarczając nową konfigurację serwera Model Server.

Należy pamiętać, że za każdym razem, gdy serwer ładuje nowy plik konfiguracyjny, będzie realizował zawartość nowej określonej konfiguracji i tylko nową określoną konfigurację. Oznacza to, że jeśli model A był obecny w pierwszym pliku konfiguracyjnym, który zostanie zastąpiony plikiem zawierającym tylko model B, serwer załaduje model B i zwolni model A.

Szczegóły konfiguracji serwera modelowego

Dostarczony plik konfiguracyjny serwera Model Server musi być buforem protokołu ModelServerConfig .

We wszystkich przypadkach z wyjątkiem najbardziej zaawansowanych warto użyć opcji ModelConfigList, która jest listą buforów protokołu ModelConfig . Oto podstawowy przykład, zanim zagłębimy się w opcje zaawansowane poniżej.

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

Konfiguracja jednego modelu

Każdy ModelConfig określa jeden model do obsłużenia, łącznie z jego nazwą i ścieżką, gdzie Serwer Modelu powinien szukać wersji modelu do obsłużenia, jak widać w powyższym przykładzie. Domyślnie serwer będzie udostępniał wersję o największym numerze wersji. To ustawienie domyślne można zastąpić, zmieniając pole model_version_policy.

Udostępnianie określonej wersji modelu

Aby udostępnić konkretną wersję modelu, zamiast zawsze przechodzić do wersji o największym numerze wersji, ustaw model_version_policy na „specyficzny” i podaj numer wersji, którą chcesz udostępnić. Na przykład, aby przypiąć wersję 42 jako tę, która będzie obsługiwana:

model_version_policy {
  specific {
    versions: 42
  }
}

Ta opcja jest przydatna do przywrócenia znanej, dobrej wersji w przypadku wykrycia problemu z najnowszymi wersjami.

Udostępnianie wielu wersji modelu

Aby jednocześnie udostępniać wiele wersji modelu, np. aby umożliwić przesyłanie wstępnej nowej wersji z fragmentem ruchu, ustaw model_version_policy na „specyficzny” i podaj wiele numerów wersji. Na przykład, aby obsłużyć wersje 42 i 43:

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

Przypisywanie etykiet ciągów do wersji modelu, aby uprościć Canary i wycofanie zmian

Czasami pomocne jest dodanie poziomu pośredniego do wersji modelu. Zamiast informować wszystkich klientów, że powinni odpytywać wersję 42, możesz przypisać alias, taki jak „stabilny”, do dowolnej wersji, o którą klienci powinni się aktualnie pytać. Jeśli chcesz przekierować część ruchu do wstępnej wersji modelu Canary, możesz użyć drugiego aliasu „canary”.

Możesz skonfigurować aliasy lub etykiety wersji modelu w następujący sposób:

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

W powyższym przykładzie udostępniasz wersje 42 i 43 oraz kojarzysz etykietę „stable” z wersją 42 i etykietę „canary” z wersją 43. Możesz poprosić swoich klientów o kierowanie zapytań do jednej z wersji „stable” lub „canary” (być może w oparciu o hashowanie identyfikatora użytkownika) przy użyciu pola Version_label bufora protokołu ModelSpec i przesuń etykietę do przodu na serwerze bez powiadamiania klientów. Kiedy już skończysz udostępnianie wersji 43 i będziesz gotowy do promowania jej do wersji stabilnej, możesz zaktualizować konfigurację do:

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

Jeśli później zajdzie potrzeba wycofania zmian, możesz powrócić do starej konfiguracji, która ma wersję 42 jako „stabilną”. W przeciwnym razie możesz iść dalej, wyładowując wersję 42 i ładując nową wersję 44, gdy będzie gotowa, a następnie przesuwając etykietę kanarkową do 44 i tak dalej.

Należy pamiętać, że etykiety można przypisać tylko do wersji modelu, które są już załadowane i dostępne do udostępnienia. Gdy wersja modelu będzie dostępna, można na bieżąco załadować konfigurację modelu, aby przypisać do niej etykietę. Można to osiągnąć za pomocą wywołania RPC HandleReloadConfigRequest lub jeśli serwer jest skonfigurowany tak, aby okresowo odpytywał system plików w poszukiwaniu pliku konfiguracyjnego, jak opisano powyżej .

Jeśli chcesz przypisać etykietę do wersji, która nie jest jeszcze załadowana (np. podając zarówno wersję modelu, jak i etykietę podczas uruchamiania), musisz ustawić flagę --allow_version_labels_for_unavailable_models na wartość true, co pozwala nowym etykietom być przypisane do wersji modelu, które nie są jeszcze załadowane.

Należy pamiętać, że dotyczy to tylko etykiet nowych wersji (tj. etykiet, które nie są aktualnie przypisane do żadnej wersji). Ma to na celu zapewnienie, że podczas zamiany wersji serwer nie przypisze przedwcześnie etykiety do nowej wersji, odrzucając w ten sposób wszystkie żądania przeznaczone dla tej etykiety podczas ładowania nowej wersji.

Aby zachować zgodność z tą kontrolą bezpieczeństwa, w przypadku ponownego przypisania już używanej etykiety wersji należy przypisać ją tylko do już załadowanych wersji. Na przykład, jeśli chcesz przenieść etykietę z wersji N do wersji N+1, możesz najpierw przesłać konfigurację zawierającą wersję N i N+1, a następnie przesłać konfigurację zawierającą wersję N+1, etykietę wskazując na N+1 i brak wersji N.

Użycie REST

Jeśli używasz powierzchni interfejsu API REST do wykonywania żądań wnioskowania, zamiast używać

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

po prostu poproś o wersję, korzystając z etykiety, konstruując ścieżkę żądania w ten sposób

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

Należy pamiętać, że etykieta wersji jest ograniczona do sekwencji znaków programu Word składającej się ze znaków alfanumerycznych i podkreśleń (tj. [a-zA-Z0-9_]+ ).

Konfiguracja monitorowania

Można udostępnić serwerowi konfigurację monitorowania, używając flagi --monitoring_config_file w celu określenia pliku zawierającego bufor protokołu MonitoringConfig . Oto przykład:

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

Aby odczytać metryki z powyższego monitorującego adresu URL, należy najpierw włączyć serwer HTTP, ustawiając flagę --rest_api_port . Następnie możesz skonfigurować serwer Prometheus tak, aby pobierał metryki z serwera Model Server, przekazując mu wartości --rest_api_port i path .

Tensorflow Serving zbiera wszystkie metryki przechwytywane przez Serving, a także podstawowy Tensorflow.

Konfiguracja wsadowa

Model Server ma możliwość grupowania żądań w różnych ustawieniach w celu uzyskania lepszej przepustowości. Planowanie tego grupowania odbywa się globalnie dla wszystkich modeli i wersji modeli na serwerze, aby zapewnić najlepsze możliwe wykorzystanie podstawowych zasobów, niezależnie od tego, ile modeli lub wersji modeli jest obecnie obsługiwanych przez serwer ( więcej szczegółów ). Możesz włączyć to zachowanie, ustawiając flagę --enable_batching i kontrolować je, przekazując konfigurację do flagi --batching_parameters_file .

Przykładowy plik parametrów wsadowych:

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

Szczegółowe omówienie można znaleźć w przewodniku dozowania oraz w sekcji dotyczącej parametrów, aby dowiedzieć się, jak ustawić parametry.

Różne flagi

Oprócz flag omówionych dotychczas w przewodniku, tutaj wymienimy kilka innych godnych uwagi. Pełną listę można znaleźć w kodzie źródłowym .

  • --port : Port do nasłuchiwania interfejsu API gRPC
  • --rest_api_port : Port do nasłuchiwania API HTTP/REST
  • --rest_api_timeout_in_ms : Limit czasu dla wywołań API HTTP/REST
  • --file_system_poll_wait_seconds : Okres, przez jaki serwer odpytuje system plików w poszukiwaniu nowych wersji modelu w odpowiedniej ścieżce_podstawowej_modelu każdego modelu
  • --enable_model_warmup : Włącza rozgrzewanie modelu przy użyciu dostarczonych przez użytkownika dzienników prognoz w katalogu Assets.extra/
  • --mixed_precision=bfloat16 : Włącza automatyczną mieszaną precyzję BF16