Tensorflow Hizmet Yapılandırması

Bu kılavuzda Tensorflow Hizmetine yönelik çok sayıda yapılandırma noktasının üzerinden geçeceğiz.

Genel Bakış

Çoğu konfigürasyon Model Sunucuyla ilgili olsa da Tensorflow Sunumunun davranışını belirtmenin birçok yolu vardır:

Model Sunucu Yapılandırması

Bir modeli sunmanın en kolay yolu --model_name ve --model_base_path bayraklarını sağlamak (veya Docker kullanılıyorsa MODEL_NAME ortam değişkenini ayarlamaktır). Ancak birden fazla model sunmak veya yeni sürümler için yoklama sıklığı gibi seçenekleri yapılandırmak istiyorsanız bunu bir Model Sunucusu yapılandırma dosyası yazarak yapabilirsiniz.

Bu yapılandırma dosyasını --model_config_file işaretini kullanarak sağlayabilir ve --model_config_file_poll_wait_seconds işaretini ayarlayarak Tensorflow Hizmetine bu yapılandırma dosyasının güncellenmiş sürümlerini belirtilen yolda periyodik olarak yoklaması talimatını verebilirsiniz.

Docker'ı kullanan örnek:

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

Model Sunucu Yapılandırmasını Yeniden Yükleme

Model Sunucu yapılandırmasını yeniden yüklemenin iki yolu vardır:

  • --model_config_file_poll_wait_seconds bayrağını ayarlayarak, sunucuya --model_config_file dosya yolunda yeni bir yapılandırma dosyasını periyodik olarak kontrol etmesi talimatını verin.

  • Sunucuya HandleReloadConfigRequest RPC çağrıları düzenleyerek ve program aracılığıyla yeni bir Model Sunucu yapılandırması sağlayarak.

Lütfen, sunucunun yeni yapılandırma dosyasını her yüklediğinde, yeni belirtilen yapılandırmanın içeriğini ve yalnızca yeni belirtilen yapılandırmayı gerçekleştirmek üzere hareket edeceğini unutmayın. Bu, yalnızca model B'yi içeren bir dosyayla değiştirilen ilk yapılandırma dosyasında model A mevcutsa, sunucunun B modelini yükleyeceği ve A modelini kaldıracağı anlamına gelir.

Model Sunucu Yapılandırma Ayrıntıları

Sağlanan Model Sunucusu yapılandırma dosyası bir ModelServerConfig protokol arabelleği olmalıdır.

En gelişmiş kullanım durumları dışındaki tüm durumlar için, ModelConfig protokol arabelleklerinin bir listesi olan ModelConfigList seçeneğini kullanmak isteyeceksiniz. Aşağıdaki gelişmiş seçeneklere dalmadan önce temel bir örneği burada bulabilirsiniz.

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

Bir Modeli Yapılandırma

Her ModelConfig, yukarıdaki örnekte görüldüğü gibi, adı ve Model Sunucusunun hizmet verilecek model sürümlerini araması gereken yol da dahil olmak üzere, hizmet verilecek bir modeli belirtir. Varsayılan olarak sunucu, en büyük sürüm numarasına sahip sürümü sunacaktır. Bu varsayılan model_version_policy alanı değiştirilerek geçersiz kılınabilir.

Bir Modelin Belirli Bir Versiyonunu Sunmak

Her zaman en büyük sürüm numarasına geçmek yerine modelin belirli bir sürümünü sunmak için model_version_policy'yi "özel" olarak ayarlayın ve sunmak istediğiniz sürüm numarasını belirtin. Örneğin, sürüm 42'yi sunulacak sürüm olarak sabitlemek için:

model_version_policy {
  specific {
    versions: 42
  }
}

Bu seçenek, en son sürüm(ler)de bir sorun tespit edilmesi durumunda, iyi bilinen bir sürüme geri dönmek için kullanışlıdır.

Bir Modelin Birden Fazla Versiyonunu Sunmak

Modelin birden çok sürümünü aynı anda sunmak için (örneğin, bir trafik dilimiyle geçici yeni bir sürümün oluşturulmasını etkinleştirmek için), model_version_policy'yi "özel" olarak ayarlayın ve birden çok sürüm numarası sağlayın. Örneğin, 42 ve 43 sürümlerini sunmak için:

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

Canary ve Geri Alma İşlemlerini Basitleştirmek İçin Model Sürümlerine Dize Etiketleri Atama

Bazen model versiyonlarına bir düzeyde dolaylılık eklemek faydalı olabilir. Tüm istemcilerinize sürüm 42'yi sorgulamaları gerektiğini bildirmek yerine, istemcilerin şu anda sorgulaması gereken sürüm olan sürüme "kararlı" gibi bir takma ad atayabilirsiniz. Trafiğin bir dilimini geçici bir kanarya modeli sürümüne yönlendirmek istiyorsanız ikinci bir takma ad olan "kanarya" kullanabilirsiniz.

Bu model sürümü takma adlarını veya etiketlerini şu şekilde yapılandırabilirsiniz:

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

Yukarıdaki örnekte, 42 ve 43 sürümlerini sunuyorsunuz ve "kararlı" etiketini 42 sürümüyle ve "kanarya" etiketini 43 sürümüyle ilişkilendiriyorsunuz. Müşterilerinizin sorgularını "kararlı" veya "kanarya" etiketlerinden birine yönlendirmesini sağlayabilirsiniz. (belki de kullanıcı kimliğinin karma işlemine tabi tutulmasına dayanarak) ModelSpec protokol arabelleğinin version_label alanını kullanın ve istemcilere bildirimde bulunmadan etiketi sunucuda iletin. Sürüm 43'ü kanaryalamayı tamamladığınızda ve onu kararlı hale getirmeye hazır olduğunuzda, yapılandırmayı şu şekilde güncelleyebilirsiniz:

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

Daha sonra bir geri alma işlemi yapmanız gerekirse, sürüm 42'nin "kararlı" olduğu eski yapılandırmaya geri dönebilirsiniz. Aksi takdirde, sürüm 42'yi boşaltıp hazır olduğunda yeni sürüm 44'ü yükleyerek ve ardından kanarya etiketini 44'e ilerleterek vb. ile ilerleyebilirsiniz.

Etiketlerin yalnızca önceden yüklenmiş ve sunulmaya hazır model sürümlerine atanabileceğini lütfen unutmayın. Bir model sürümü mevcut olduğunda, ona bir etiket atamak için model yapılandırması anında yeniden yüklenebilir. Bu, bir HandleReloadConfigRequest RPC kullanılarak veya sunucu, yukarıda açıklandığı gibi, yapılandırma dosyası için dosya sistemini periyodik olarak yoklayacak şekilde ayarlanmışsa gerçekleştirilebilir.

Henüz yüklenmemiş bir sürüme etiket atamak istiyorsanız (örneğin, başlangıç ​​sırasında hem model sürümünü hem de etiketi sağlayarak), --allow_version_labels_for_unavailable_models bayrağını true olarak ayarlamanız gerekir; bu, yeni etiketlerin yüklenmesine olanak tanır. henüz yüklenmemiş model versiyonlarına atanabilir.

Bunun yalnızca yeni sürüm etiketleri (yani şu anda bir sürüme atanmamış olanlar) için geçerli olduğunu lütfen unutmayın. Bu, sürüm değişimleri sırasında sunucunun etiketi yeni sürüme zamanından önce atamamasını ve böylece yeni sürüm yüklenirken bu etikete yönelik tüm isteklerin iptal edilmesini sağlamak içindir.

Bu güvenlik kontrolüne uymak için, halihazırda kullanımda olan bir sürüm etiketini yeniden atıyorsanız, bunu yalnızca önceden yüklenmiş sürümlere atamanız gerekir. Örneğin, bir etiketi N sürümüne işaret etmekten N+1 sürümüne taşımak istiyorsanız, önce N ve N+1 sürümünü içeren bir yapılandırma gönderebilir ve ardından N+1 sürümünü (etiket) içeren bir yapılandırma gönderebilirsiniz. N+1'i işaret ediyor ve N sürümü yok.

REST Kullanımı

Çıkarım istekleri yapmak için REST API yüzeyini kullanıyorsanız

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

istek yolunuzu bu şekilde yapılandırarak bir etiket kullanarak bir sürüm talep etmeniz yeterlidir

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

Sürüm etiketinin, alfasayısal karakterlerden ve alt çizgilerden (ör. [a-zA-Z0-9_]+ ) oluşan bir dizi Word karakteriyle sınırlı olduğunu unutmayın.

İzleme Yapılandırması

MonitoringConfig protokol arabelleğini içeren bir dosyayı belirtmek için --monitoring_config_file bayrağını kullanarak sunucuya bir izleme yapılandırması sağlayabilirsiniz. İşte bir örnek:

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

Yukarıdaki izleme URL'sinden metrikleri okumak için öncelikle --rest_api_port bayrağını ayarlayarak HTTP sunucusunu etkinleştirmeniz gerekir. Daha sonra Prometheus Sunucunuzu, --rest_api_port ve path değerlerini ileterek Model Sunucusundan metrikleri çekecek şekilde yapılandırabilirsiniz.

Tensorflow Sunumu, Sunum tarafından yakalanan tüm ölçümlerin yanı sıra temel Tensorflow'u da toplar.

Toplu Yapılandırma

Model Sunucusu, daha iyi verim elde etmek için çeşitli ayarlardaki istekleri toplu olarak işleme yeteneğine sahiptir. Bu toplu işlemin zamanlaması, sunucu tarafından şu anda kaç model veya model sürümü sunuluyor olursa olsun, temel kaynakların mümkün olan en iyi şekilde kullanılmasını sağlamak amacıyla sunucudaki tüm modeller ve model sürümleri için genel olarak yapılır ( daha fazla ayrıntı ). Bu davranışı --enable_batching bayrağını ayarlayarak etkinleştirebilir ve --batching_parameters_file bayrağına bir yapılandırma ileterek bunu kontrol edebilirsiniz.

Örnek toplu işlem parametreleri dosyası:

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

Ayrıntılı bir tartışma için lütfen toplu işlem kılavuzuna bakın ve parametrelerin nasıl ayarlanacağını anlamak için parametrelerle ilgili bölüme bakın.

Çeşitli Bayraklar

Kılavuzda şu ana kadar ele alınan bayraklara ek olarak, burada birkaç önemli bayrak daha listeliyoruz. Tam liste için lütfen kaynak koduna bakın.

  • --port : gRPC API'si için dinlenilecek bağlantı noktası
  • --rest_api_port : HTTP/REST API'si için dinlenilecek bağlantı noktası
  • --rest_api_timeout_in_ms : HTTP/REST API çağrıları için zaman aşımı
  • --file_system_poll_wait_seconds : Sunucunun, her modelin ilgili model_base_path'inde yeni model sürümleri için dosya sistemini yokladığı dönem
  • --enable_model_warmup : asset.extra/ dizininde kullanıcı tarafından sağlanan PredictionLogs'u kullanarak modelin ısınmasını etkinleştirir
  • --mixed_precision=bfloat16 : BF16 Otomatik Karışık Hassasiyeti etkinleştirir