پیکربندی سرویس تنسورفلو

در این راهنما، ما به نقاط پیکربندی متعددی برای سرویس Tensorflow خواهیم پرداخت.

بررسی اجمالی

در حالی که بیشتر تنظیمات مربوط به سرور مدل است، راه‌های زیادی برای مشخص کردن رفتار Tensorflow Serving وجود دارد:

• پیکربندی سرور مدل : نام مدل، مسیرها، خط‌مشی نسخه و برچسب‌ها، پیکربندی ورود به سیستم و موارد دیگر را مشخص کنید
• پیکربندی مانیتورینگ : مانیتورینگ Prometheus را فعال و پیکربندی کنید
• Batching Configuration : دسته بندی را فعال کرده و پارامترهای آن را پیکربندی کنید
• متفرقه پرچم ها : تعدادی متفرقه. پرچم هایی که می توانند برای تنظیم دقیق رفتار استقرار سرویس Tensorflow ارائه شوند

پیکربندی سرور مدل

ساده‌ترین راه برای ارائه یک مدل، ارائه پرچم‌های --model_name و --model_base_path (یا تنظیم متغیر محیطی MODEL_NAME در صورت استفاده از Docker) است. با این حال، اگر می خواهید چندین مدل را ارائه دهید، یا گزینه هایی مانند فرکانس نظرسنجی را برای نسخه های جدید پیکربندی کنید، می توانید این کار را با نوشتن یک فایل پیکربندی سرور مدل انجام دهید.

شما می توانید این فایل پیکربندی را با استفاده از پرچم --model_config_file ارائه دهید و به Tensorflow Serving دستور دهید تا به صورت دوره ای نسخه های به روز شده این فایل پیکربندی را در مسیر مشخص شده با تنظیم پرچم --model_config_file_poll_wait_seconds نظرسنجی کند.

مثال با استفاده از 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

بارگذاری مجدد پیکربندی سرور مدل

دو راه برای بارگیری مجدد پیکربندی سرور مدل وجود دارد:

• با تنظیم پرچم --model_config_file_poll_wait_seconds به سرور دستور می دهد تا به صورت دوره ای یک فایل پیکربندی جدید را در مسیر --model_config_file بررسی کند.

• با صدور HandleReloadConfigRequest فراخوانی RPC به سرور و ارائه یک پیکربندی سرور مدل جدید به صورت برنامه ای.

لطفاً توجه داشته باشید که هر بار که سرور فایل پیکربندی جدید را بارگذاری می کند، محتوای پیکربندی مشخص شده جدید و فقط پیکربندی مشخص شده جدید را درک می کند. این به این معنی است که اگر مدل A در اولین فایل کانفیگ وجود داشته باشد، که با فایلی که فقط حاوی مدل B است جایگزین شود، سرور مدل B را بارگیری می کند و مدل A را تخلیه می کند.

جزئیات پیکربندی سرور مدل

فایل پیکربندی مدل سرور ارائه شده باید یک بافر پروتکل ModelServerConfig باشد.

برای همه موارد به جز پیشرفته ترین موارد استفاده، می خواهید از گزینه ModelConfigList استفاده کنید که لیستی از بافرهای پروتکل ModelConfig است. در اینجا یک مثال اساسی وجود دارد، قبل از اینکه به گزینه های پیشرفته زیر شیرجه بزنیم.

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

پیکربندی یک مدل

همانطور که در مثال بالا مشاهده می شود، هر ModelConfig یک مدل را مشخص می کند که باید ارائه شود، از جمله نام آن و مسیری که سرور مدل باید به دنبال نسخه هایی از مدل برای ارائه خدمات باشد. به‌طور پیش‌فرض، سرور نسخه‌ای را با بیشترین شماره نسخه ارائه می‌کند. این پیش فرض را می توان با تغییر فیلد model_version_policy لغو کرد.

ارائه یک نسخه خاص از یک مدل

برای ارائه یک نسخه خاص از مدل، به جای اینکه همیشه به نسخه ای با بیشترین شماره نسخه منتقل شوید، model_version_policy را روی "specific" تنظیم کنید و شماره نسخه ای را که می خواهید ارائه کنید ارائه دهید. به عنوان مثال، برای پین کردن نسخه 42 به عنوان نسخه مورد نظر:

model_version_policy {
  specific {
    versions: 42
  }
}

این گزینه برای بازگشت به یک نسخه خوب مفید است، در صورتی که مشکلی در آخرین نسخه (ها) کشف شود.

ارائه چندین نسخه از یک مدل

برای ارائه چندین نسخه از مدل به طور همزمان، به عنوان مثال برای فعال کردن قناری یک نسخه آزمایشی جدید با تکه‌ای از ترافیک، model_version_policy را روی "specific" تنظیم کنید و چندین شماره نسخه را ارائه دهید. به عنوان مثال، برای ارائه نسخه های 42 و 43:

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

تخصیص برچسب‌های رشته‌ای به نسخه‌های مدل، برای ساده‌سازی Canary و Rollback

گاهی اوقات اضافه کردن سطحی از غیر جهت به نسخه های مدل مفید است. به جای اینکه به همه مشتریان خود بفهمانید که باید نسخه 42 را پرس و جو کنند، می توانید نام مستعاری مانند "stable" را به هر نسخه ای که در حال حاضر مشتری باید درخواست کند اختصاص دهید. اگر می‌خواهید بخشی از ترافیک را به نسخه آزمایشی مدل قناری هدایت کنید، می‌توانید از نام مستعار دوم «قناری» استفاده کنید.

می توانید این نام های مستعار نسخه مدل یا برچسب ها را مانند این پیکربندی کنید:

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

در مثال بالا، شما نسخه‌های 42 و 43 را ارائه می‌دهید و برچسب "پایدار" را با نسخه 42 و برچسب "قناری" را با نسخه 43 مرتبط می‌کنید. (شاید بر اساس هش کردن شناسه کاربر) با استفاده از فیلد version_label از بافر پروتکل ModelSpec ، و بدون اطلاع مشتریان، برچسب را روی سرور به جلو ببرید. هنگامی که نسخه 43 قناری را به پایان رساندید و آماده ارتقای آن به حالت پایدار هستید، می توانید پیکربندی را به این موارد به روز کنید:

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

اگر متعاقباً نیاز به بازگشت مجدد داشتید، می توانید به پیکربندی قدیمی که دارای نسخه 42 به عنوان "پایدار" است، برگردید. در غیر این صورت می توانید با تخلیه ورژن 42 و لود کردن ورژن جدید 44 زمانی که آماده شد و سپس لیبل قناری را تا 44 و ... به جلو مارش کنید.

لطفاً توجه داشته باشید که برچسب‌ها را فقط می‌توان به نسخه‌های مدلی اختصاص داد که قبلاً بارگیری شده‌اند و برای ارائه در دسترس هستند. هنگامی که یک نسخه مدل در دسترس است، می توانید پیکربندی مدل را دوباره بارگیری کنید تا یک برچسب به آن اختصاص دهید. این را می توان با استفاده از HandleReloadConfigRequest RPC یا اگر سرور طوری تنظیم شده باشد که به طور دوره ای سیستم فایل را برای فایل پیکربندی نظرسنجی کند، همانطور که در بالا توضیح داده شد.

اگر می‌خواهید برچسبی را به نسخه‌ای که هنوز بارگذاری نشده است اختصاص دهید (مثلاً با ارائه نسخه مدل و برچسب در زمان راه‌اندازی)، باید پرچم --allow_version_labels_for_unavailable_models را روی true تنظیم کنید، که به برچسب‌های جدید اجازه می‌دهد تا به نسخه های مدلی که هنوز بارگذاری نشده اند اختصاص داده شود.

لطفاً توجه داشته باشید که این فقط برای برچسب‌های نسخه جدید (یعنی برچسب‌هایی که در حال حاضر به نسخه‌ای اختصاص داده نشده‌اند) اعمال می‌شود. این کار برای اطمینان از این است که در طول تعویض نسخه، سرور برچسب را زودتر از موعد به نسخه جدید اختصاص نمی دهد، در نتیجه تمام درخواست هایی که برای آن برچسب در نظر گرفته شده است در حالی که نسخه جدید بارگذاری می شود حذف می شود.

به منظور مطابقت با این بررسی ایمنی، در صورت تخصیص مجدد برچسب نسخه در حال استفاده، باید آن را فقط به نسخه های بارگذاری شده از قبل اختصاص دهید. به عنوان مثال، اگر می‌خواهید برچسبی را از اشاره به نسخه N به نسخه N+1 منتقل کنید، می‌توانید ابتدا یک پیکربندی حاوی نسخه N و N+1 ارسال کنید و سپس پیکربندی حاوی نسخه N+1، برچسب را ارسال کنید. اشاره به N+1 و بدون نسخه N.

استفاده REST

اگر از سطح REST API برای درخواست استنتاج به جای استفاده استفاده می کنید

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

به سادگی با استفاده از یک برچسب با ساختاردهی مسیر درخواست خود، یک نسخه را درخواست کنید

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

توجه داشته باشید که برچسب نسخه محدود به دنباله ای از کاراکترهای Word است که از نویسه های الفبای اعداد و زیرخط تشکیل شده است (یعنی [a-zA-Z0-9_]+ ).

پیکربندی مانیتورینگ

شما می توانید با استفاده از پرچم --monitoring_config_file برای تعیین فایلی حاوی بافر پروتکل MonitoringConfig پیکربندی نظارتی را به سرور ارائه دهید. در اینجا یک مثال است:

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

برای خواندن معیارها از URL نظارتی بالا، ابتدا باید سرور HTTP را با تنظیم پرچم --rest_api_port فعال کنید. سپس می‌توانید سرور Prometheus خود را به گونه‌ای پیکربندی کنید که با ارسال مقادیر --rest_api_port و path معیارها را از سرور مدل استخراج کند.

Tensorflow Serving تمام معیارهایی را که توسط Serving و همچنین Tensorflow هسته گرفته شده است جمع آوری می کند.

پیکربندی دسته ای

مدل سرور این توانایی را دارد که درخواست‌ها را در تنظیمات مختلف دسته‌بندی کند تا توان عملیاتی بهتری را دریافت کند. زمان‌بندی برای این دسته‌بندی به‌صورت جهانی برای همه مدل‌ها و نسخه‌های مدل روی سرور انجام می‌شود تا از بهترین استفاده ممکن از منابع اصلی بدون توجه به تعداد مدل‌ها یا نسخه‌های مدل در حال حاضر توسط سرور اطمینان حاصل شود ( جزئیات بیشتر ). می‌توانید این رفتار را با تنظیم پرچم --enable_batching فعال کنید و با ارسال یک پیکربندی به پرچم --batching_parameters_file آن را کنترل کنید.

نمونه فایل پارامترهای دسته بندی:

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

لطفاً برای بحث عمیق به راهنمای بچینگ مراجعه کنید و برای درک نحوه تنظیم پارامترها به بخش پارامترها مراجعه کنید.

پرچم های متفرقه

علاوه بر پرچم‌هایی که تاکنون در راهنما پوشش داده شده است، در اینجا چند مورد قابل توجه دیگر را فهرست می‌کنیم. برای فهرست کامل، لطفاً به کد منبع مراجعه کنید.

• --port : پورتی برای گوش دادن به gRPC API
• --rest_api_port : پورتی برای گوش دادن به HTTP/REST API
• --rest_api_timeout_in_ms : مهلت زمانی برای تماس‌های HTTP/REST API
• --file_system_poll_wait_seconds : دوره ای که سرور سیستم فایل را برای نسخه های مدل جدید در مدل_base_path مربوطه هر مدل نظرسنجی می کند.
• --enable_model_warmup : گرم کردن مدل را با استفاده از PredictionLogs ارائه شده توسط کاربر در فهرست assets.extra/ فعال می کند
• --mixed_precision=bfloat16 : BF16 Automatic Mixed Precision را فعال می کند