تكوين خدمة Tensorflow

في هذا الدليل، سنتناول نقاط التكوين العديدة لخدمة Tensorflow.

ملخص

على الرغم من أن معظم التكوينات تتعلق بالخادم النموذجي، إلا أن هناك طرقًا عديدة لتحديد سلوك خدمة Tensorflow:

• تكوين خادم النموذج : حدد أسماء النماذج والمسارات وسياسة الإصدار والتسميات وتكوين التسجيل والمزيد
• تكوين المراقبة : تمكين وتكوين مراقبة بروميثيوس
• تكوين الدفعات : تمكين الدفعات وتكوين معلماتها
• متنوعات الأعلام : عدد من المتفرقات. الإشارات التي يمكن توفيرها لضبط سلوك نشر خدمة Tensorflow

تكوين الخادم النموذجي

أسهل طريقة لخدمة نموذج هي توفير علامتي --model_name و --model_base_path (أو تعيين متغير البيئة MODEL_NAME في حالة استخدام Docker). ومع ذلك، إذا كنت ترغب في تقديم نماذج متعددة، أو تكوين خيارات مثل تكرار الاستقصاء للإصدارات الجديدة، فيمكنك القيام بذلك عن طريق كتابة ملف تكوين Model Server.

يمكنك توفير ملف التكوين هذا باستخدام علامة --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 Server:

• من خلال تعيين علامة --model_config_file_poll_wait_seconds لتوجيه الخادم للتحقق بشكل دوري من وجود ملف تكوين جديد في --model_config_file filepath.

• عن طريق إصدار مكالمات HandleReloadConfigRequest RPC إلى الخادم وتوفير تكوين Model Server جديد برمجيًا.

يرجى ملاحظة أنه في كل مرة يقوم الخادم بتحميل ملف التكوين الجديد، فإنه سيعمل على إدراك محتوى التكوين المحدد الجديد والتكوين المحدد الجديد فقط . وهذا يعني أنه إذا كان النموذج A موجودًا في ملف التكوين الأول، والذي تم استبداله بملف يحتوي على النموذج B فقط، فسيقوم الخادم بتحميل النموذج B وإلغاء تحميل النموذج A.

تفاصيل تكوين الخادم النموذجي

يجب أن يكون ملف تكوين Model Server المقدم عبارة عن مخزن مؤقت لبروتوكول 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 على "محدد" وقم بتوفير رقم الإصدار الذي ترغب في عرضه. على سبيل المثال، لتثبيت الإصدار 42 باعتباره الإصدار الذي سيتم عرضه:

model_version_policy {
  specific {
    versions: 42
  }
}

يعد هذا الخيار مفيدًا للرجوع إلى إصدار معروف، في حالة اكتشاف مشكلة في الإصدار (الإصدارات) الأحدث.

خدمة إصدارات متعددة من النموذج

لخدمة إصدارات متعددة من النموذج في وقت واحد، على سبيل المثال لتمكين إصدار جديد مؤقت مع شريحة من حركة المرور، قم بتعيين model_version_policy على "محدد" وقم بتوفير أرقام إصدارات متعددة. على سبيل المثال، لخدمة الإصدارين 42 و43:

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

تعيين تسميات سلسلة لإصدارات النموذج، لتبسيط الكناري والتراجع

في بعض الأحيان يكون من المفيد إضافة مستوى من المراوغة إلى إصدارات النماذج. بدلاً من السماح لجميع عملائك بمعرفة أنه يجب عليهم الاستعلام عن الإصدار 42، يمكنك تعيين اسم مستعار مثل "مستقر" لأي إصدار حاليًا يجب على العملاء الاستعلام عنه. إذا كنت تريد إعادة توجيه شريحة من حركة المرور إلى إصدار نموذج كناري مؤقت، فيمكنك استخدام اسم مستعار ثانٍ "كناري".

يمكنك تكوين هذه الأسماء المستعارة أو التسميات لإصدار النموذج، كما يلي:

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

في المثال أعلاه، أنت تقدم الإصدارين 42 و43، وتربط التصنيف "ثابت" بالإصدار 42 والتسمية "canary" بالإصدار 43. يمكنك مطالبة عملائك بتوجيه الاستعلامات إلى أحد "الإصدارات الثابتة" أو "canary" (ربما يعتمد على تجزئة معرف المستخدم) باستخدام حقل version_label الخاص بالمخزن المؤقت لبروتوكول ModelSpec ، وقم بتحريك التسمية على الخادم دون إخطار العملاء. بمجرد الانتهاء من إصدار Canarying الإصدار 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 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 الخاص بك لسحب المقاييس من Model Server عن طريق تمرير قيم --rest_api_port و path .

يقوم Tensorflow Serving بجمع جميع المقاييس التي تم التقاطها بواسطة العرض بالإضافة إلى Tensorflow الأساسي.

تكوين الخلطة

يتمتع Model Server بالقدرة على تجميع الطلبات في مجموعة متنوعة من الإعدادات لتحقيق إنتاجية أفضل. تتم جدولة هذه الدفعة عالميًا لجميع النماذج وإصدارات النماذج الموجودة على الخادم لضمان أفضل استخدام ممكن للموارد الأساسية بغض النظر عن عدد النماذج أو إصدارات النماذج التي يتم تقديمها حاليًا بواسطة الخادم ( مزيد من التفاصيل ). يمكنك تمكين هذا السلوك عن طريق تعيين علامة --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
• --rest_api_port : منفذ للاستماع إلى HTTP/REST API
• --rest_api_timeout_in_ms : انتهاء مهلة مكالمات HTTP/REST API
• --file_system_poll_wait_seconds : الفترة التي يستقصي فيها الخادم نظام الملفات عن إصدارات النماذج الجديدة في مسار model_base_path الخاص بكل نموذج
• --enable_model_warmup : تمكين عملية إحماء النموذج باستخدام PredictionLogs المقدمة من المستخدم في دليل الأصول.extra/
• --mixed_precision=bfloat16 : تمكين الدقة المختلطة التلقائية لـ BF16