Bina Standardı TensorFlow ModelServer

Bu eğitim, eğitilmiş bir TensorFlow modelinin yeni sürümlerini dinamik olarak keşfeden ve sunan standart TensorFlow ModelServer'ı oluşturmak için TensorFlow Serving bileşenlerini nasıl kullanacağınızı gösterir. Modellerinize hizmet vermek için yalnızca standart sunucuyu kullanmak istiyorsanız TensorFlow Serving temel eğitimine bakın.

Bu öğretici, el yazısı görüntü (MNIST verileri) sınıflandırması için TensorFlow eğitiminde tanıtılan basit Softmax Regresyon modelini kullanır. TensorFlow veya MNIST'in ne olduğunu bilmiyorsanız ML'ye Yeni Başlayanlar İçin MNIST eğitimine bakın.

Bu eğitimin kodu iki bölümden oluşur:

  • Modelin birden çok sürümünü eğiten ve dışa aktaran bir Python dosyası mnist_saved_model.py .

  • Dışa aktarılan yeni modelleri keşfeden ve bunları sunmak için bir gRPC hizmetini çalıştıran standart TensorFlow ModelServer olan bir C++ dosyası main.cc.

Bu eğitimde aşağıdaki görevler adım adım gerçekleştirilmektedir:

  1. Bir TensorFlow modelini eğitin ve dışarı aktarın.
  2. TensorFlow Serving ServerCore ile model sürüm oluşturmayı yönetin.
  3. SavedModelBundleSourceAdapterConfig kullanarak toplu işlemi yapılandırın.
  4. İsteği TensorFlow Serving ServerCore ile sunun.
  5. Hizmeti çalıştırın ve test edin.

Başlamadan önce ilk olarak Docker'ı yükleyin

TensorFlow Modelini eğitme ve dışa aktarma

İlk olarak, henüz yapmadıysanız bu depoyu yerel makinenize kopyalayın:

git clone https://github.com/tensorflow/serving.git
cd serving

Zaten mevcutsa, dışa aktarma dizinini temizleyin:

rm -rf /tmp/models

Modelin ilk sürümünü eğitin (100 yinelemeyle) ve dışa aktarın:

tools/run_in_docker.sh python tensorflow_serving/example/mnist_saved_model.py \
  --training_iteration=100 --model_version=1 /tmp/mnist

Modelin ikinci versiyonunu eğitin (2000 yinelemeyle) ve dışa aktarın:

tools/run_in_docker.sh python tensorflow_serving/example/mnist_saved_model.py \
  --training_iteration=2000 --model_version=2 /tmp/mnist

mnist_saved_model.py görebileceğiniz gibi, eğitim ve dışa aktarma, TensorFlow Serving temel eğitimindekiyle aynı şekilde yapılır. Gösterim amacıyla, kasıtlı olarak ilk çalıştırma için eğitim yinelemelerini azaltıyor ve v1 olarak dışa aktarıyorsunuz, ikinci çalıştırma için normal şekilde eğitiyor ve aynı ana dizine v2 olarak aktarıyorsunuz - ikincisinin başarmasını beklediğimiz gibi Daha yoğun eğitim nedeniyle daha iyi sınıflandırma doğruluğu. /tmp/mnist dizininizde her eğitim çalıştırması için eğitim verilerini görmelisiniz:

$ ls /tmp/mnist
1  2

Sunucu Çekirdeği

Şimdi, yeni algoritmalar denenirken veya model yeni bir veri kümesiyle eğitilirken, modelin v1 ve v2'sinin çalışma zamanında dinamik olarak oluşturulduğunu hayal edin. Bir üretim ortamında, v1'i sunarken v2'nin keşfedilebileceği, yüklenebileceği, denenebileceği, izlenebileceği veya geri döndürülebileceği, kademeli dağıtımı destekleyebilecek bir sunucu oluşturmak isteyebilirsiniz. Alternatif olarak, v2'yi başlatmadan önce v1'i yıkmak isteyebilirsiniz. TensorFlow Serving her iki seçeneği de destekler; biri geçiş sırasında kullanılabilirliği korumak için iyidir, diğeri ise kaynak kullanımını (örn. RAM) en aza indirmek için iyidir.

TensorFlow Hizmet Manager tam olarak bunu yapar. TensorFlow modellerinin yükleme, sunma ve boşaltmanın yanı sıra sürüm geçişleri de dahil olmak üzere tüm yaşam döngüsünü yönetir. Bu öğreticide sunucunuzu, AspiredVersionsManager dahili olarak saran TensorFlow Serving ServerCore üzerine kuracaksınız.

int main(int argc, char** argv) {
  ...

  ServerCore::Options options;
  options.model_server_config = model_server_config;
  options.servable_state_monitor_creator = &CreateServableStateMonitor;
  options.custom_model_config_loader = &LoadCustomModelConfig;

  ::google::protobuf::Any source_adapter_config;
  SavedModelBundleSourceAdapterConfig
      saved_model_bundle_source_adapter_config;
  source_adapter_config.PackFrom(saved_model_bundle_source_adapter_config);
  (*(*options.platform_config_map.mutable_platform_configs())
      [kTensorFlowModelPlatform].mutable_source_adapter_config()) =
      source_adapter_config;

  std::unique_ptr<ServerCore> core;
  TF_CHECK_OK(ServerCore::Create(options, &core));
  RunServer(port, std::move(core));

  return 0;
}

ServerCore::Create() bir ServerCore::Options parametresini alır. İşte yaygın olarak kullanılan birkaç seçenek:

  • Yüklenecek modelleri belirten ModelServerConfig . Modeller, statik bir model listesi bildiren model_config_list aracılığıyla veya çalışma zamanında güncellenebilecek modellerin listesini bildirmenin özel bir yolunu tanımlayan custom_model_config aracılığıyla bildirilir.
  • Platformun adından ( tensorflow gibi) SourceAdapter oluşturmak için kullanılan PlatformConfig eşlenen PlatformConfigMap . SourceAdapter StoragePath (bir model sürümünün keşfedildiği yol) model Loader uyarlar (model sürümünü depolama yolundan yükler ve Manager durum geçiş arayüzleri sağlar). PlatformConfig , SavedModelBundleSourceAdapterConfig içeriyorsa, daha sonra açıklayacağımız bir SavedModelBundleSourceAdapter oluşturulacaktır.

SavedModelBundle TensorFlow Sunumunun önemli bir bileşenidir. Belirli bir yoldan yüklenen bir TensorFlow modelini temsil eder ve çıkarımı çalıştırmak için TensorFlow ile aynı Session::Run arayüzünü sağlar. SavedModelBundleSourceAdapter depolama yolunu Loader<SavedModelBundle> a uyarlayarak model ömrünün Manager tarafından yönetilebilmesini sağlar. Lütfen SavedModelBundle kullanımdan kaldırılan SessionBundle halefi olduğunu unutmayın. SessionBundle desteği yakında kaldırılacağından kullanıcıların SavedModelBundle kullanmaları önerilir.

Tüm bunlarla birlikte ServerCore dahili olarak şunları yapar:

  • model_config_list içinde bildirilen model dışarı aktarma yollarını izleyen bir FileSystemStoragePathSource örneğini oluşturur.
  • model_config_list bildirilen model platformuyla PlatformConfigMap kullanarak bir SourceAdapter örneğini oluşturur ve FileSystemStoragePathSource buna bağlar. Bu şekilde, dışa aktarma yolu altında yeni bir model sürümü keşfedildiğinde, SavedModelBundleSourceAdapter bunu Loader<SavedModelBundle> öğesine uyarlar.
  • SavedModelBundleSourceAdapter tarafından oluşturulan tüm Loader örneklerini yöneten AspiredVersionsManager adlı özel bir Manager uygulamasını başlatır. ServerCore çağrıları AspiredVersionsManager devrederek Manager arayüzünü dışa aktarır.

Yeni bir sürüm mevcut olduğunda, bu AspiredVersionsManager yeni sürümü yükler ve varsayılan davranışıyla eski sürümü kaldırır. Özelleştirmeye başlamak istiyorsanız dahili olarak oluşturulan bileşenleri ve bunların nasıl yapılandırılacağını anlamanız önerilir.

TensorFlow Serving'in sıfırdan çok esnek ve genişletilebilir olacak şekilde tasarlandığını belirtmekte fayda var. ServerCore ve AspiredVersionsManager gibi genel çekirdek bileşenlerden yararlanırken sistem davranışını özelleştirmek için çeşitli eklentiler oluşturabilirsiniz. Örneğin, yerel depolama yerine bulut depolamayı izleyen bir veri kaynağı eklentisi oluşturabilirsiniz veya sürüm geçişini farklı bir şekilde yapan bir sürüm politikası eklentisi oluşturabilirsiniz; hatta, hizmet veren özel bir model eklentisi bile oluşturabilirsiniz. TensorFlow olmayan modeller. Bu konular bu eğitimin kapsamı dışındadır. Ancak daha fazla bilgi için özel kaynağa ve özel yayınlanabilir eğitimlere başvurabilirsiniz.

harmanlama

Üretim ortamında istediğimiz bir diğer tipik sunucu özelliği de toplu işlemdir. Makine öğrenimi çıkarımı yapmak için kullanılan modern donanım hızlandırıcıları (GPU'lar vb.), çıkarım istekleri büyük gruplar halinde çalıştırıldığında genellikle en iyi hesaplama verimliliğine ulaşır.

Toplu işlem, SavedModelBundleSourceAdapter oluşturulurken uygun SessionBundleConfig sağlanarak açılabilir. Bu durumda BatchingParameters hemen hemen varsayılan değerlerle ayarladık. Toplu işleme, özel zaman aşımı, toplu_boyut vb. değerler ayarlanarak ince ayar yapılabilir. Ayrıntılar için lütfen BatchingParameters bakın.

SessionBundleConfig session_bundle_config;
// Batching config
if (enable_batching) {
  BatchingParameters* batching_parameters =
      session_bundle_config.mutable_batching_parameters();
  batching_parameters->mutable_thread_pool_name()->set_value(
      "model_server_batch_threads");
}
*saved_model_bundle_source_adapter_config.mutable_legacy_config() =
    session_bundle_config;

Tam topluluğa ulaşıldığında, çıkarım istekleri dahili olarak tek bir büyük istekte (tensör) birleştirilir ve tensorflow::Session::Run() çağrılır (GPU'lardaki gerçek verimlilik kazancının geldiği yer burasıdır).

Yöneticiyle birlikte servis yapın

Yukarıda belirtildiği gibi TensorFlow Serving Manager , isteğe bağlı makine öğrenimi sistemleri tarafından oluşturulan modellerin yüklenmesini, sunulmasını, boşaltılmasını ve sürüm geçişini gerçekleştirebilecek genel bir bileşen olacak şekilde tasarlanmıştır. API'leri aşağıdaki temel kavramlar etrafında oluşturulmuştur:

  • Sunulabilir : Sunulabilir, istemci isteklerine hizmet etmek için kullanılabilecek herhangi bir opak nesnedir. Bir sunulabilir öğenin boyutu ve ayrıntı düzeyi esnektir; öyle ki, tek bir yayınlanabilir öğe, arama tablosunun tek bir parçasından, makine tarafından öğrenilen tek bir modele ve bir grup modele kadar her şeyi içerebilir. Hizmet verilebilir herhangi bir türde ve arayüzde olabilir.

  • Sunulabilir Sürüm : Sunulabilir dosyalar sürümlendirilmiştir ve TensorFlow Serving Manager bir sunulabilirin bir veya daha fazla sürümünü yönetebilir. Sürüm oluşturma, bir yayınlanabilir sürümün birden fazla sürümünün aynı anda yüklenmesine olanak tanıyarak kademeli kullanıma sunma ve denemeyi destekler.

  • Sunulabilir Akış : Sunulabilir bir akış, artan sürüm numaralarıyla birlikte sunulabilir sürümlerin dizisidir.

  • Model : Makine tarafından öğrenilen bir model, bir veya daha fazla sunulabilir öğeyle temsil edilir. Hizmet verilebilir örnekler:

    • TensorFlow oturumu veya bunların etrafındaki SavedModelBundle gibi sarmalayıcılar.
    • Diğer türdeki makine öğrenimli modeller.
    • Kelime arama tabloları.
    • Arama tablolarını yerleştirme.

    Bileşik bir model, birden fazla bağımsız hizmet verilebilir veya tek bir bileşik hizmet verilebilir olarak temsil edilebilir. Sunulabilir bir model aynı zamanda bir Modelin bir kısmına da karşılık gelebilir; örneğin birçok Manager örneğine bölünmüş büyük bir arama tablosuyla.

Tüm bunları bu eğitimin bağlamına koymak için:

  • TensorFlow modelleri bir tür sunulabilir olan SavedModelBundle ile temsil edilir. SavedModelBundle dahili olarak, oturuma hangi grafiğin yüklendiği ve çıkarım için nasıl çalıştırılacağı hakkında bazı meta verilerle eşleştirilmiş bir tensorflow:Session oluşur.

  • Her biri kendi alt dizininde bulunan ve adı sürüm numarası olan TensorFlow dışa aktarma akışını içeren bir dosya sistemi dizini vardır. Dış dizin, sunulan TensorFlow modeli için sunulabilir akışın serileştirilmiş temsili olarak düşünülebilir. Her dışa aktarma, yüklenebilecek bir hizmet dosyasına karşılık gelir.

  • AspiredVersionsManager dışa aktarma akışını izler ve tüm SavedModelBundle sunulabilir öğelerinin yaşam döngüsünü dinamik olarak yönetir.

TensorflowPredictImpl::Predict sonra sadece:

  • Yöneticiden SavedModelBundle ister (ServerCore aracılığıyla).
  • PredictRequest mantıksal tensör adlarını gerçek tensör adlarıyla eşlemek ve değerleri tensörlere bağlamak için generic signatures kullanır.
  • Çıkarımı çalıştırır.

Sunucuyu test edin ve çalıştırın

Dışa aktarmanın ilk sürümünü izlenen klasöre kopyalayın:

mkdir /tmp/monitored
cp -r /tmp/mnist/1 /tmp/monitored

Daha sonra sunucuyu başlatın:

docker run -p 8500:8500 \
  --mount type=bind,source=/tmp/monitored,target=/models/mnist \
  -t --entrypoint=tensorflow_model_server tensorflow/serving --enable_batching \
  --port=8500 --model_name=mnist --model_base_path=/models/mnist &

Sunucu her saniyede bir "Sunulabilir sürüm için istekte bulunuluyor..." yazan günlük iletileri yayınlayacaktır; bu, dışa aktarmayı bulduğu ve devam eden varlığını takip ettiği anlamına gelir.

İstemciyi --concurrency=10 ile çalıştıralım. Bu, sunucuya eşzamanlı istekler gönderecek ve böylece toplu işlem mantığınızı tetikleyecektir. 

tools/run_in_docker.sh python tensorflow_serving/example/mnist_client.py \
  --num_tests=1000 --server=127.0.0.1:8500 --concurrency=10

Bu, şuna benzeyen bir çıktıyla sonuçlanır: 

...
Inference error rate: 13.1%

Daha sonra dışa aktarmanın ikinci versiyonunu izlenen klasöre kopyalayıp testi yeniden çalıştırıyoruz: 

cp -r /tmp/mnist/2 /tmp/monitored
tools/run_in_docker.sh python tensorflow_serving/example/mnist_client.py \
  --num_tests=1000 --server=127.0.0.1:8500 --concurrency=10

Bu, şuna benzeyen bir çıktıyla sonuçlanır: 

...
Inference error rate: 9.5%

Bu, sunucunuzun yeni sürümü otomatik olarak keşfettiğini ve bunu sunum için kullandığını doğrular!