این آموزش به شما نشان می دهد که چگونه از اجزای TensorFlow Serving برای ساختن استاندارد TensorFlow ModelServer استفاده کنید که به صورت پویا نسخه های جدید یک مدل آموزش دیده TensorFlow را کشف و ارائه می کند. اگر شما فقط می خواهید به استفاده از سرور استاندارد برای خدمت به مدل های خود را، و TensorFlow خدمت آموزش های اساسی .

این آموزش از مدل رگرسیون سافت مکس ساده معرفی شده در آموزش TensorFlow برای طبقه بندی تصاویر دست نویس (MNIST data) استفاده می کند. اگر شما نمی دانید که چه TensorFlow یا MNIST است، ببینید MNIST برای ML مبتدی آموزش.

کد این آموزش شامل دو بخش است:

• پایتون فایل mnist_saved_model.py که قطار و صادرات نسخه های متعدد از این مدل است.

• یک فایل C ++ main.cc است که استاندارد TensorFlow ModelServer که کشف جدید مدل صادر و اجرا می شود یک gRPC خدمات برای خدمت به آنها.

این آموزش مراحل زیر را طی می کند:

1. آموزش و صادرات یک مدل TensorFlow.
2. مدیریت مدل نسخه با TensorFlow خدمت ServerCore .
3. بچینگ پلانت با استفاده از پیکربندی SavedModelBundleSourceAdapterConfig .
4. درخواست با TensorFlow خدمت خدمت ServerCore .
5. سرویس را اجرا و تست کنید.

قبل از شروع، اول نصب کارگر بارانداز

آموزش و صادرات مدل TensorFlow

ابتدا، اگر هنوز این کار را نکرده اید، این مخزن را در ماشین محلی خود شبیه سازی کنید:

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

اگر دایرکتوری صادرات از قبل وجود دارد پاک کنید:

rm -rf /tmp/models

آموزش (با 100 تکرار) و صادرات نسخه اول مدل:

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

آموزش (با 2000 تکرار) و صادرات نسخه دوم مدل:

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 ، آموزش و صادرات است به همان شیوه آن را در است انجام TensorFlow خدمت آموزش های اساسی . برای اهداف نمایشی، شما عمداً تکرارهای آموزشی را برای اجرای اول شماره گیری می کنید و آن را به عنوان v1 صادر می کنید، در حالی که به طور معمول برای اجرای دوم آموزش می دهید و آن را به عنوان v2 به همان دایرکتوری والد صادر می کنید - همانطور که انتظار داریم دومی به آن برسد. دقت طبقه بندی بهتر به دلیل آموزش فشرده تر. شما باید ببینید که آموزش داده ها برای هر آموزشی اجرا در خود /tmp/mnist دایرکتوری:

$ ls /tmp/mnist
1  2

ServerCore

حال تصور کنید v1 و v2 مدل به صورت پویا در زمان اجرا تولید می‌شوند، زمانی که الگوریتم‌های جدید در حال آزمایش هستند، یا زمانی که مدل با یک مجموعه داده جدید آموزش داده می‌شود. در یک محیط تولید، ممکن است بخواهید سروری بسازید که بتواند از عرضه تدریجی پشتیبانی کند، که در آن نسخه 2 را می توان در حین ارائه نسخه 1 کشف، بارگذاری، آزمایش، نظارت یا برگرداند. از طرف دیگر، ممکن است بخواهید v1 را قبل از آوردن v2 از بین ببرید. TensorFlow Serving از هر دو گزینه پشتیبانی می کند - در حالی که یکی برای حفظ در دسترس بودن در طول انتقال خوب است، دیگری برای به حداقل رساندن استفاده از منابع خوب است (مثلا RAM).

TensorFlow خدمت Manager کند که دقیقا. چرخه عمر کامل مدل های TensorFlow از جمله بارگیری، سرویس دهی و تخلیه آنها و همچنین انتقال نسخه را کنترل می کند. در این آموزش، شما سرور خود را در بالای یک TensorFlow خدمت ساخت ServerCore ، که در داخل کاری ادامه داده اند AspiredVersionsManager .

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() طول می کشد یک ServerCore :: پارامتر گزینه. در اینجا چند گزینه متداول استفاده می شود:

• ModelServerConfig که مدل های مشخص به لود شود. مدل ها یا از طریق اعلام model_config_list ، که اعلام یک لیست استاتیک از مدل ها، و یا از طریق custom_model_config است، که به راه های سفارشی به اعلام یک لیست از مدل های که ممکن است در زمان اجرا به روز تعریف می کند.
• PlatformConfigMap که از نام پلت فرم (مانند نقشه های tensorflow ) به PlatformConfig ، استفاده شده است که برای ایجاد SourceAdapter . SourceAdapter سازگار StoragePath (مسیر که در آن یک نسخه مدل کشف شده است) به مدل Loader (بارهای نسخه مدل را از مسیر ذخیره سازی و فراهم می کند واسط انتقال حالت به Manager ). اگر PlatformConfig شامل SavedModelBundleSourceAdapterConfig ، یک SavedModelBundleSourceAdapter ایجاد خواهد شد، که بعدا توضیح خواهم داد.

SavedModelBundle یک جزء کلیدی از تعمیر و نگهداری TensorFlow است. این نشان دهنده یک مدل TensorFlow لود شده از یک مسیر داده و همان فراهم می کند Session::Run رابط به عنوان TensorFlow به استنتاج اجرا. SavedModelBundleSourceAdapter سازگار مسیر ذخیره سازی به Loader<SavedModelBundle> به طوری که طول عمر مدل را می توان با مدیریت Manager . لطفا توجه داشته باشید که SavedModelBundle جانشین منسوخ شده است SessionBundle . کاربران را تشویق به استفاده از SavedModelBundle به عنوان پشتیبانی برای SessionBundle به زودی حذف خواهد شد.

با این همه، ServerCore داخلی کند به شرح زیر:

• تمثل FileSystemStoragePathSource که مسیرهای صادرات مدل مانیتور در اعلام model_config_list .
• تمثل SourceAdapter با استفاده از PlatformConfigMap با پلت فرم مدل در اعلام model_config_list و متصل FileSystemStoragePathSource به آن است. به این ترتیب، هر زمان که نسخه مدل جدید است که در مسیر صادرات را کشف کرد، SavedModelBundleSourceAdapter آن سازگار به یک Loader<SavedModelBundle> .
• تمثل یک پیادهسازی خاص از Manager به نام AspiredVersionsManager که مدیریت همه مانند Loader موارد ایجاد شده توسط SavedModelBundleSourceAdapter . ServerCore صادرات Manager رابط را با تفویض تماس به AspiredVersionsManager .

هر زمان که یک نسخه جدید در دسترس است، این AspiredVersionsManager بارهای نسخه جدید، و تحت به طور پیش فرض بارگیری نشود رفتار خود یکی از قدیمی. اگر می‌خواهید سفارشی‌سازی را شروع کنید، تشویق می‌شوید اجزایی را که در داخل ایجاد می‌کند و نحوه پیکربندی آنها را درک کنید.

شایان ذکر است که TensorFlow Serving از ابتدا بسیار انعطاف پذیر و قابل توسعه طراحی شده است. شما می توانید از پلاگین های مختلف به رفتار سیستم سفارشی ساخت، در حالی که با استفاده از اجزای اصلی عمومی مانند ServerCore و AspiredVersionsManager . به عنوان مثال، می‌توانید یک افزونه منبع داده بسازید که به جای ذخیره‌سازی محلی، فضای ذخیره‌سازی ابری را نظارت می‌کند، یا می‌توانید یک پلاگین خط‌مشی نسخه بسازید که انتقال نسخه را به روشی متفاوت انجام می‌دهد - در واقع، حتی می‌توانید یک پلاگین مدل سفارشی بسازید که خدمت می‌کند. مدل های غیر تنسورفلو این موضوعات خارج از محدوده این آموزش هستند. با این حال، شما می توانید به مراجعه منبع سفارشی و سفارشی servable آموزش برای اطلاعات بیشتر.

دسته بندی

یکی دیگر از ویژگی های معمولی سرور که در محیط تولید می خواهیم، ​​دسته بندی است. شتاب‌دهنده‌های سخت‌افزاری مدرن (GPU و غیره) که برای انجام استنتاج یادگیری ماشین استفاده می‌شوند، معمولاً زمانی که درخواست‌های استنتاج در دسته‌های بزرگ اجرا می‌شوند، بهترین بازده محاسباتی را به دست می‌آورند.

دوز مصالح می توان در با ارائه مناسب تبدیل SessionBundleConfig هنگام ایجاد SavedModelBundleSourceAdapter . در این مورد ما مجموعه BatchingParameters با مقادیر پیش فرض تقریبا. دسته‌بندی را می‌توان با تنظیم مقادیر زمان‌بندی سفارشی، batch_size و غیره به‌خوبی تنظیم کرد. برای جزئیات بیشتر، مراجعه شود به BatchingParameters .

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;

به محض رسیدن به دسته ای کامل، درخواست استنتاج داخلی به یک درخواست واحد بزرگ (تانسور)، و با هم ادغام شدند tensorflow::Session::Run() فراخوانی می شود (که جایی است که افزایش بهره وری واقعی بر روی GPU ها می آید از).

خدمت با مدیر

همانطور که در بالا ذکر شد، TensorFlow خدمت Manager طراحی شده است که یک جزء کلی است که می بارگذاری، خدمت، تخلیه و مجدد از نسخه گذار از مدل های تولید شده توسط سیستم های یادگیری ماشین دلخواه را اداره کند. API های آن بر اساس مفاهیم کلیدی زیر ساخته شده اند:

• Servable: Servable هر شی مات است که می تواند مورد استفاده قرار گیرد برای خدمت به درخواست مشتری می باشد. اندازه و دانه بندی یک قابل ارائه انعطاف پذیر است، به طوری که یک قابل خدمت رسانی ممکن است شامل هر چیزی باشد، از یک تکه جدول جستجو گرفته تا یک مدل منفرد یادگیری ماشینی تا چندین مدل. یک سرویس پذیر می تواند از هر نوع و رابطی باشد.

• Servable نسخه: Servables می شود، version و TensorFlow خدمت Manager توانید یک یا چند نسخه از یک servable را مدیریت کند. نسخه‌سازی اجازه می‌دهد تا بیش از یک نسخه از یک سرویس‌دهی به طور همزمان بارگذاری شود، که از عرضه تدریجی و آزمایش پشتیبانی می‌کند.

• Servable جریان: جریان servable دنباله ای از نسخه از یک servable است، با افزایش تعداد نسخه.

• مدل: مدل ماشین دست است یک یا چند servables ارائه شده است. نمونه هایی از سرویس پذیرها عبارتند از:

  • جلسه TensorFlow یا لفافه در اطراف آنها، مانند SavedModelBundle .
  • انواع دیگر مدل های یادگیری ماشینی.
  • جداول جستجوی واژگان
  • جاسازی جداول جستجو

  یک مدل کامپوزیت را می‌توان به‌عنوان چندین سرویس‌پذیر مستقل یا به‌عنوان یک سرویس‌پذیر ترکیبی منفرد نشان داد. servable نیز ممکن است به کمتر از یک مدل با یک جدول مراجعه بزرگ sharded در بسیاری از مطابقت دارد، برای مثال Manager نمونه.

برای قرار دادن همه اینها در چارچوب این آموزش:

• - مدل های TensorFlow توسط یک نوع از servable نشان SavedModelBundle . SavedModelBundle داخلی شامل یک tensorflow:Session با برخی از ابرداده در مورد چه گراف به جلسه لود و چگونه آن را اجرا استنباط جفت می شود.

• یک دایرکتوری سیستم فایل حاوی جریانی از صادرات TensorFlow وجود دارد که هر کدام در زیر شاخه خود هستند که نام آن شماره نسخه است. دایرکتوری بیرونی را می توان به عنوان نمایش سریالی جریان قابل سرویس برای مدل TensorFlow در نظر گرفت. هر صادرات مربوط به یک سرویس قابل بارگیری است.

• AspiredVersionsManager نظارت جریان صادرات، و مدیریت چرخه عمر از همه SavedModelBundle servables به صورت پویا.

TensorflowPredictImpl::Predict پس از آن فقط:

• درخواست SavedModelBundle از مدیر (از طریق ServerCore).
• با استفاده از generic signatures به نقشه نام تانسور منطقی در PredictRequest به نام تانسور واقعی و ارزش اتصال به تانسورها.
• استنتاج را اجرا می کند.

سرور را تست و اجرا کنید

اولین نسخه صادرات را در پوشه نظارت شده کپی کنید:

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

سپس سرور را راه اندازی کنید:

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 &

سرور در هر ثانیه پیام‌های گزارشی را منتشر می‌کند که می‌گویند "نسخه مشتاق برای سرویس‌دهی ..."، که به این معنی است که صادرات را پیدا کرده است و ادامه حیات آن را دنبال می‌کند.

بیایید اجرا مشتری با --concurrency=10 . این درخواست‌های همزمان را به سرور ارسال می‌کند و در نتیجه منطق دسته‌بندی شما را فعال می‌کند.

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

که نتیجه آن خروجی به شکل زیر است:

...
Inference error rate: 13.1%

سپس نسخه دوم صادرات را در پوشه نظارت شده کپی می کنیم و دوباره تست را اجرا می کنیم:

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

که نتیجه آن خروجی به شکل زیر است:

...
Inference error rate: 9.5%

این تأیید می کند که سرور شما به طور خودکار نسخه جدید را پیدا کرده و از آن برای سرویس دهی استفاده می کند!