مكون خط أنابيب InfraValidator TFX

InfraValidator هو مكون TFX يستخدم كطبقة تحذير مبكر قبل دفع النموذج إلى الإنتاج. جاء اسم مدقق "infra" من حقيقة أنه يتم التحقق من صحة النموذج في النموذج الفعلي الذي يخدم "البنية التحتية". إذا مقيم هو لضمان أداء النموذج، InfraValidator هو ضمان هذا النموذج هو ميكانيكيا غرامة، ويمنع نماذج سيئة من يتم دفعها.

كيف يعمل؟

يأخذ InfraValidator النموذج ، ويطلق خادم نموذج معبأ بالرمل مع النموذج ، ويرى ما إذا كان يمكن تحميله بنجاح والاستعلام عنه اختياريًا. سيتم إنشاء نتيجة التحقق من صحة التحتية في blessing الانتاج في نفس الطريقة كما مقيم يفعل.

يركز InfraValidator على التوافق بين ثنائي نموذج الخادم (على سبيل المثال TensorFlow خدمة ) ونموذج لنشر. على الرغم من اسم مدقق "التحتية"، فمن مسؤولية المستخدم لتكوين بيئة بشكل صحيح، والأشعة تحت المصادقة فقط يتفاعل مع نموذج الخادم في بيئة تكوين المستخدم لمعرفة ما اذا كان يعمل بشكل جيد. سيضمن تكوين هذه البيئة بشكل صحيح أن نجاح أو فشل التحقق من صحة البنية التحتية سيكون مؤشراً على ما إذا كان النموذج سيكون قابلاً للخدمة في بيئة خدمة الإنتاج. وهذا يعني بعضًا مما يلي على سبيل المثال لا الحصر:

  1. يستخدم InfraValidator نفس النموذج الثنائي للخادم الذي سيتم استخدامه في الإنتاج. هذا هو المستوى الأدنى الذي يجب أن تتقارب فيه بيئة التحقق من صحة البنية التحتية.
  2. يستخدم InfraValidator نفس الموارد (مثل كمية التخصيص ونوع وحدة المعالجة المركزية والذاكرة والمسرعات) التي سيتم استخدامها في الإنتاج.
  3. يستخدم InfraValidator نفس تكوين خادم النموذج الذي سيتم استخدامه في الإنتاج.

اعتمادًا على الموقف ، يمكن للمستخدمين اختيار الدرجة التي يجب أن تكون بها InfraValidator متطابقة مع بيئة الإنتاج. من الناحية الفنية ، يمكن التحقق من صحة النموذج في بيئة Docker المحلية ثم تقديمه في بيئة مختلفة تمامًا (مثل مجموعة Kubernetes) دون مشكلة. ومع ذلك ، لن يتحقق InfraValidator من هذا الاختلاف.

وضعية التشغيل

اعتمادًا على التكوين ، يتم إجراء التحقق من صحة البنية التحتية في أحد الأوضاع التالية:

  • LOAD_ONLY الوضع: التحقق ما إذا تم تحميل النموذج بنجاح في البنية التحتية التي تخدم أو لا. أو
  • LOAD_AND_QUERY الوضع: LOAD_ONLY الوضع بالإضافة إلى إرسال بعض طلبات عينة للتحقق مما إذا النموذج هو قادرة على خدمة الاستدلالات. InfraValidator لا يهتم بأن التوقع كان صحيحًا أم لا. يهم فقط ما إذا كان الطلب ناجحًا أم لا.

كيف يمكنني استخدامه؟

عادةً ما يتم تعريف InfraValidator بجانب مكون المقيم ، ويتم تغذية مخرجاته إلى دافع. إذا فشل InfraValidator ، فلن يتم دفع النموذج.

evaluator = Evaluator(
    model=trainer.outputs['model'],
    examples=example_gen.outputs['examples'],
    baseline_model=model_resolver.outputs['model'],
    eval_config=tfx.proto.EvalConfig(...)
)

infra_validator = InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=tfx.proto.ServingSpec(...)
)

pusher = Pusher(
    model=trainer.outputs['model'],
    model_blessing=evaluator.outputs['blessing'],
    infra_blessing=infra_validator.outputs['blessing'],
    push_destination=tfx.proto.PushDestination(...)
)

تكوين مكون InfraValidator.

هناك ثلاثة أنواع من البروتوس لتكوين InfraValidator.

ServingSpec

ServingSpec هو الأكثر التكوين حاسم لInfraValidator. تحدد:

  • ما هو نوع من نموذج الخادم إلى المدى
  • حيث لتشغيله

بالنسبة لأنواع الخوادم النموذجية (تسمى خدمة ثنائية) نحن ندعم

منصات الخدمة التالية مدعومة حاليًا:

  • عامل ميناء محلي (يجب تثبيت Docker مسبقًا)
  • Kubernetes (دعم محدود لـ KubeflowDagRunner فقط)

ويجري اختيار خدمة ثنائي وخدمة منصة طريق تحديد oneof كتلة من ServingSpec . على سبيل المثال لاستخدام TensorFlow خدمة تشغيل ثنائي على الكتلة Kubernetes، tensorflow_serving و kubernetes يجب تعيين المجال.

infra_validator=InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=tfx.proto.ServingSpec(
        tensorflow_serving=tfx.proto.TensorFlowServing(
            tags=['latest']
        ),
        kubernetes=tfx.proto.KubernetesConfig()
    )
)

لمزيد من تكوين ServingSpec ، يرجى مراجعة تعريف protobuf .

ValidationSpec

تكوين اختياري لضبط معايير التحقق من صحة البنية التحتية أو سير العمل.

infra_validator=InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=tfx.proto.ServingSpec(...),
    validation_spec=tfx.proto.ValidationSpec(
        # How much time to wait for model to load before automatically making
        # validation fail.
        max_loading_time_seconds=60,
        # How many times to retry if infra validation fails.
        num_tries=3
    )
)

جميع حقول ValidationSpec لها قيمة افتراضية سليمة. تحقق المزيد من التفاصيل من تعريف protobuf .

RequestSpec

التكوين اختياري لتحديد كيفية بناء نموذج الطلبات عند تشغيل التحقق من صحة التحتية في LOAD_AND_QUERY واسطة. من أجل استخدام LOAD_AND_QUERY الوضع، هو مطلوب منها لتحديد كل request_spec خصائص التنفيذ وكذلك examples قناة الإدخال في تعريف المكون.

infra_validator = InfraValidator(
    model=trainer.outputs['model'],
    # This is the source for the data that will be used to build a request.
    examples=example_gen.outputs['examples'],
    serving_spec=tfx.proto.ServingSpec(
        # Depending on what kind of model server you're using, RequestSpec
        # should specify the compatible one.
        tensorflow_serving=tfx.proto.TensorFlowServing(tags=['latest']),
        local_docker=tfx.proto.LocalDockerConfig(),
    ),
    request_spec=tfx.proto.RequestSpec(
        # InfraValidator will look at how "classification" signature is defined
        # in the model, and automatically convert some samples from `examples`
        # artifact to prediction RPC requests.
        tensorflow_serving=tfx.proto.TensorFlowServingRequestSpec(
            signature_names=['classification']
        ),
        num_examples=10  # How many requests to make.
    )
)

إنتاج SavedModel مع الإحماء

(من الإصدار 0.30.0)

منذ نموذج InfraValidator بالتحقق من صحة مع طلبات الحقيقية، فإنه يمكن إعادة استخدامها بسهولة هذه الطلبات المصادقة و طلبات الودية من SavedModel. يوفر InfraValidator خيار ( RequestSpec.make_warmup ) لتصدير SavedModel مع الودية.

infra_validator = InfraValidator(
    ...,
    request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)

ثم خرج InfraBlessing سيحتوي قطعة أثرية من SavedModel مع الودية، ويمكن أيضا أن تكون دفعت من قبل مروج المخدرات ، تماما مثل Model قطعة أثرية.

محددات

InfraValidator الحالي لم يكتمل بعد ، ولديه بعض القيود.

  • فقط TensorFlow SavedModel شكل نموذج يمكن التحقق من صحة.
  • عند تشغيل TFX على Kubernetes، ينبغي تنفيذ خط أنابيب من KubeflowDagRunner داخل Kubeflow خطوط الأنابيب. سيتم إطلاق خادم النموذج في نفس مجموعة Kubernetes ومساحة الاسم التي يستخدمها Kubeflow.
  • وتركز في المقام الأول على InfraValidator الانتشار في TensorFlow خدمة ، وبينما لا يزال هو مفيد أقل دقة لنشر ل TensorFlow ايت و TensorFlow.js ، أو الأطر الاستدلال الأخرى.

  • هناك دعم محدود على LOAD_AND_QUERY وضع ل توقع توقيع الأسلوب (الذي هو طريقة للتصدير فقط في TensorFlow 2). InfraValidator يتطلب توقيع توقع أن تستهلك تسلسل tf.Example كإدخال الوحيد.

    @tf.function
def parse_and_run(serialized_example):
  features = tf.io.parse_example(serialized_example, FEATURES)
  return model(features)

model.save('path/to/save', signatures={
  # This exports "Predict" method signature under name "serving_default".
  'serving_default': parse_and_run.get_concrete_function(
      tf.TensorSpec(shape=[None], dtype=tf.string, name='examples'))
})
    • تحقق من و البطريق المثال نموذج التعليمات البرمجية لنرى كيف هذا التوقيع يتفاعل مع العناصر الأخرى في TFX.