إنشاء وحدة تكتشف مسارات جديدة قابلة للعرض

يشرح هذا المستند كيفية توسيع خدمة TensorFlow لمراقبة أنظمة التخزين المختلفة لاكتشاف (إصدارات) نماذج أو بيانات جديدة للخدمة. على وجه الخصوص، يغطي كيفية إنشاء واستخدام وحدة تراقب مسار نظام التخزين لظهور مسارات فرعية جديدة، حيث يمثل كل مسار فرعي إصدارًا جديدًا قابلاً للعرض للتحميل. يُطلق على هذا النوع من الوحدات اسم Source<StoragePath> ، لأنه يُصدر كائنات من النوع StoragePath (مُحدد string ). يمكن تكوينه باستخدام SourceAdapter الذي يقوم بإنشاء Loader قابلة للعرض من مسار محدد يكتشفه المصدر.

أولا، ملاحظة حول العمومية

ليس من الضروري استخدام المسارات كمقابض للبيانات القابلة للعرض؛ إنه يوضح فقط طريقة واحدة لاستيعاب العناصر القابلة للعرض في النظام. حتى إذا لم تقم بيئتك بتغليف البيانات القابلة للعرض في المسارات، فإن هذا المستند سوف يطلعك على التجريدات الأساسية. لديك خيار إنشاء وحدات Source<T> و SourceAdapter<T1, T2> للأنواع التي تناسب بيئتك (مثل RPC أو رسائل النشر/الفرعية، وسجلات قاعدة البيانات)، أو ببساطة إنشاء Source<std::unique_ptr<Loader>> الذي يُصدر أدوات التحميل القابلة للعرض مباشرة.

بالطبع، أيًا كان نوع البيانات التي يرسلها مصدرك (سواء كانت مسارات POSIX، أو مسارات Google Cloud Storage، أو مقابض RPC)، يجب أن تكون هناك وحدة (وحدات) مصاحبة قادرة على تحميل العناصر القابلة للخدمة بناءً على ذلك. تسمى هذه الوحدات SourceAdapters . يتم وصف إنشاء واحد مخصص في المستند المخصص للعرض . يأتي TensorFlow Serving مزودًا بواحدة لإنشاء جلسات TensorFlow بناءً على المسارات في أنظمة الملفات التي يدعمها TensorFlow. يمكن إضافة دعم لأنظمة ملفات إضافية إلى TensorFlow عن طريق توسيع تجريد RandomAccessFile ( tensorflow/core/public/env.h ).

يركز هذا المستند على إنشاء مصدر يصدر مسارات في نظام ملفات يدعمه TensorFlow. وينتهي بشرح كيفية استخدام المصدر الخاص بك جنبًا إلى جنب مع الوحدات الموجودة مسبقًا لخدمة نماذج TensorFlow.

إنشاء المصدر الخاص بك

لدينا تطبيق مرجعي لـ Source<StoragePath> ، يسمى FileSystemStoragePathSource (في sources/storage_path/file_system_storage_path_source* ). يقوم FileSystemStoragePathSource بمراقبة مسار نظام ملفات معين، ومراقبة الدلائل الفرعية الرقمية، والإبلاغ عن أحدثها باعتباره الإصدار الذي يطمح إلى تحميله. يستعرض هذا المستند الجوانب البارزة في FileSystemStoragePathSource . قد تجد أنه من المناسب عمل نسخة من FileSystemStoragePathSource ثم تعديلها لتناسب احتياجاتك.

أولاً، يقوم FileSystemStoragePathSource بتنفيذ Source<StoragePath> API، وهو تخصص لواجهة برمجة التطبيقات Source<T> مع T منضم إلى StoragePath . تتكون واجهة برمجة التطبيقات (API) من أسلوب واحد SetAspiredVersionsCallback() ، والذي يوفر إغلاقًا يمكن للمصدر استدعاءه لإبلاغه بأنه يريد تحميل مجموعة معينة من الإصدارات القابلة للعرض.

يستخدم FileSystemStoragePathSource رد الاتصال للإصدارات الطموحة بطريقة بسيطة جدًا: فهو يقوم بفحص نظام الملفات بشكل دوري (بعمل ls بشكل أساسي)، وإذا عثر على مسار واحد أو أكثر يشبه الإصدارات القابلة للعرض، فإنه يحدد أي منها هو الإصدار الأحدث ويستدعي رد الاتصال بقائمة بالحجم الأول تحتوي على هذا الإصدار فقط (ضمن التكوين الافتراضي). لذلك، في أي وقت يطلب FileSystemStoragePathSource تحميل خادم واحد على الأكثر، ويستفيد تنفيذه من قصور رد الاتصال ليظل عديم الحالة (ليس هناك أي ضرر في استدعاء رد الاتصال بشكل متكرر بنفس الوسائط).

يحتوي FileSystemStoragePathSource على مصنع تهيئة ثابت (طريقة Create() )، والذي يتلقى رسالة بروتوكول التكوين. تتضمن رسالة التكوين تفاصيل مثل المسار الأساسي للمراقبة والفاصل الزمني للمراقبة. ويتضمن أيضًا اسم الدفق القابل للعرض الذي سيتم إرساله. (قد تستخرج الأساليب البديلة اسم الدفق القابل للعرض من المسار الأساسي، لإصدار تدفقات متعددة قابلة للعرض بناءً على مراقبة تسلسل هرمي أعمق للدليل؛ وهذه المتغيرات خارج نطاق التنفيذ المرجعي.)

يتكون الجزء الأكبر من التنفيذ من مؤشر ترابط يقوم بفحص نظام الملفات بشكل دوري، إلى جانب بعض المنطق لتحديد وفرز أي مسارات فرعية رقمية يكتشفها. يتم تشغيل مؤشر الترابط داخل SetAspiredVersionsCallback() (وليس في Create() ) لأن هذه هي النقطة التي يجب أن "يبدأ" المصدر عندها ويعرف مكان إرسال طلبات الإصدار المنشود.

استخدام المصدر الخاص بك لتحميل جلسات TensorFlow

من المحتمل أنك تريد استخدام وحدة المصدر الجديدة الخاصة بك بالتزامن مع SavedModelBundleSourceAdapter ( servables/tensorflow/saved_model_bundle_source_adapter* )، والتي ستفسر كل مسار يصدره مصدرك كتصدير TensorFlow، وتحويل كل مسار إلى أداة تحميل لـ TensorFlow SavedModelBundle القابل للخدمة. من المحتمل أن تقوم بتوصيل محول SavedModelBundle بـ AspiredVersionsManager ، الذي يعتني بتحميل العناصر القابلة للعرض وتقديمها فعليًا. يوجد مثال جيد لتسلسل هذه الأنواع الثلاثة من الوحدات معًا للحصول على مكتبة خادم عاملة في servables/tensorflow/simple_servers.cc . فيما يلي شرح تفصيلي لتدفق التعليمات البرمجية الرئيسية (مع معالجة الأخطاء السيئة؛ يجب أن تكون التعليمات البرمجية الحقيقية أكثر حذراً):

أولاً، قم بإنشاء مدير:

std::unique_ptr<AspiredVersionsManager> manager = ...;

بعد ذلك، قم بإنشاء محول مصدر SavedModelBundle وقم بتوصيله بالمدير:

std::unique_ptr<SavedModelBundleSourceAdapter> bundle_adapter;
SavedModelBundleSourceAdapterConfig config;
// ... populate 'config' with TensorFlow options.
TF_CHECK_OK(SavedModelBundleSourceAdapter::Create(config, &bundle_adapter));
ConnectSourceToTarget(bundle_adapter.get(), manager.get());

وأخيرًا، قم بإنشاء مصدر المسار الخاص بك وقم بتوصيله بمحول SavedModelBundle :

auto your_source = new YourPathSource(...);
ConnectSourceToTarget(your_source, bundle_adapter.get());

تقوم وظيفة ConnectSourceToTarget() (المحددة في core/target.h ) باستدعاء SetAspiredVersionsCallback() فقط لتوصيل Source<T> إلى Target<T> ( Target هو وحدة تلتقط طلبات الإصدار المنشود، أي محول أو مدير ).