Thành phần đường ống InfraValidator TFX

InfraValidator là thành phần TFX được sử dụng làm lớp cảnh báo sớm trước khi đưa mô hình vào sản xuất. Trình xác nhận tên "infra" xuất phát từ thực tế là nó đang xác thực mô hình trong mô hình thực tế phục vụ "cơ sở hạ tầng". Nếu Người đánh giá đảm bảo hiệu suất của mô hình thì InfraValidator sẽ đảm bảo mô hình hoạt động tốt về mặt cơ học và ngăn không cho các mô hình xấu bị đẩy lên.

Nó hoạt động như thế nào?

InfraValidator lấy mô hình, khởi chạy máy chủ mô hình đóng hộp cát cùng với mô hình đó và xem liệu nó có thể được tải thành công và truy vấn tùy chọn hay không. Kết quả xác thực cơ sở hạ tầng sẽ được tạo trong đầu ra blessing giống như cách mà Người đánh giá thực hiện.

InfraValidator tập trung vào khả năng tương thích giữa hệ nhị phân của máy chủ mô hình (ví dụ: TensorFlow Serve ) và mô hình cần triển khai. Mặc dù có tên là trình xác thực "hạ tầng", nhưng người dùng có trách nhiệm định cấu hình môi trường một cách chính xác và trình xác thực cơ sở hạ tầng chỉ tương tác với máy chủ mô hình trong môi trường do người dùng định cấu hình để xem liệu nó có hoạt động tốt hay không. Việc định cấu hình môi trường này một cách chính xác sẽ đảm bảo rằng việc xác thực cơ sở hạ tầng đạt hay không thành công sẽ là dấu hiệu cho biết liệu mô hình có thể phục vụ được trong môi trường phân phối sản xuất hay không. Điều này ngụ ý một số, nhưng không giới hạn, những điều sau:

  1. InfraValidator đang sử dụng cùng một tệp nhị phân máy chủ mô hình như sẽ được sử dụng trong sản xuất. Đây là mức tối thiểu mà môi trường xác thực cơ sở hạ tầng phải hội tụ.
  2. InfraValidator đang sử dụng cùng các tài nguyên (ví dụ: số lượng và loại phân bổ CPU, bộ nhớ và bộ tăng tốc) như sẽ được sử dụng trong sản xuất.
  3. InfraValidator đang sử dụng cấu hình máy chủ mô hình tương tự như sẽ được sử dụng trong sản xuất.

Tùy thuộc vào tình huống, người dùng có thể chọn mức độ InfraValidator phải giống với môi trường sản xuất. Về mặt kỹ thuật, một mô hình có thể được xác thực cơ sở hạ tầng trong môi trường Docker cục bộ và sau đó được phân phối trong một môi trường hoàn toàn khác (ví dụ: cụm Kubernetes) mà không gặp vấn đề gì. Tuy nhiên, InfraValidator sẽ không kiểm tra sự khác biệt này.

Chế độ hoạt động

Tùy thuộc vào cấu hình, xác thực hồng ngoại được thực hiện ở một trong các chế độ sau:

  • Chế độ LOAD_ONLY : kiểm tra xem mô hình đã được tải thành công trong cơ sở hạ tầng phục vụ hay chưa. HOẶC
  • Chế độ LOAD_AND_QUERY : Chế độ LOAD_ONLY cộng với việc gửi một số yêu cầu mẫu để kiểm tra xem mô hình có khả năng phục vụ suy luận hay không. InfraValidator không quan tâm dự đoán có đúng hay không. Chỉ có yêu cầu có thành công hay không là vấn đề.

Làm cách nào để sử dụng nó?

Thông thường InfraValidator được xác định bên cạnh thành phần Evaluator và đầu ra của nó được cung cấp cho Pusher. Nếu InfraValidator không thành công, mô hình sẽ không được đẩy.

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(...)
)

Định cấu hình thành phần InfraValidator.

Có ba loại proto để định cấu hình InfraValidator.

ServingSpec

ServingSpec là cấu hình quan trọng nhất cho InfraValidator. Nó định nghĩa:

  • nên chạy loại máy chủ mô hình nào
  • chạy nó ở đâu

Đối với các loại máy chủ mô hình (được gọi là phục vụ nhị phân) chúng tôi hỗ trợ

Các nền tảng phục vụ sau hiện được hỗ trợ:

  • Local Docker (Docker nên được cài đặt trước)
  • Kubernetes (chỉ hỗ trợ giới hạn cho KubeflowDagRunner)

Lựa chọn phục vụ nền tảng nhị phân và phục vụ được thực hiện bằng cách chỉ định khối oneof của ServingSpec . Ví dụ: để sử dụng nhị phân TensorFlow Serve chạy trên cụm Kubernetes, phải đặt trường tensorflow_serving và kubernetes .

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

Để định cấu hình thêm ServingSpec , vui lòng xem định nghĩa protobuf .

ValidationSpec

Cấu hình tùy chọn để điều chỉnh tiêu chí hoặc quy trình xác thực cơ sở hạ tầng.

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
    )
)

Tất cả các trường ValidationSpec đều có giá trị mặc định hợp lý. Kiểm tra chi tiết hơn từ định nghĩa protobuf .

RequestSpec

Cấu hình tùy chọn để chỉ định cách xây dựng các yêu cầu mẫu khi chạy xác thực cơ sở hạ tầng ở chế độ LOAD_AND_QUERY . Để sử dụng chế độ LOAD_AND_QUERY , cần phải chỉ định cả thuộc tính thực thi request_spec cũng như kênh đầu vào examples trong định nghĩa thành phần.

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.
    )
)

Tạo một SavingModel với quá trình khởi động

(Từ phiên bản 0.30.0)

Vì InfraValidator xác thực mô hình bằng các yêu cầu thực nên nó có thể dễ dàng sử dụng lại các yêu cầu xác thực này làm yêu cầu khởi động của SavingModel. InfraValidator cung cấp tùy chọn ( RequestSpec.make_warmup ) để xuất SavingModel khi khởi động.

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

Sau đó, tạo phẩm InfraBlessing đầu ra sẽ chứa một SavingModel đã được khởi động và cũng có thể được Pusher đẩy lên, giống như tạo tác Model .

Hạn chế

InfraValidator hiện tại chưa hoàn thiện và có một số hạn chế.

  • Chỉ có thể xác thực định dạng mô hình TensorFlow SavingModel .
  • Khi chạy TFX trên Kubernetes, quy trình phải được KubeflowDagRunner thực thi bên trong Quy trình Kubeflow. Máy chủ mô hình sẽ được khởi chạy trong cùng cụm Kubernetes và vùng tên mà Kubeflow đang sử dụng.
  • InfraValidator chủ yếu tập trung vào việc triển khai TensorFlow Serve và mặc dù vẫn hữu ích nhưng nó kém chính xác hơn khi triển khai TensorFlow Lite và TensorFlow.js hoặc các khung suy luận khác.

  • Có hỗ trợ hạn chế ở chế độ LOAD_AND_QUERY cho chữ ký phương thức Dự đoán (là phương thức có thể xuất duy nhất trong TensorFlow 2). InfraValidator yêu cầu chữ ký Dự đoán để sử dụng tf.Example được tuần tự hóa làm đầu vào duy nhất.

    @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'))
})
    • Hãy xem mã mẫu ví dụ Penguin để xem chữ ký này tương tác với các thành phần khác trong TFX như thế nào.