Path: blob/master/site/ja/tfx/guide/infra_validator.md
25118 views
InfraValidator TFX パイプラインコンポーネント
InfraValidator は、モデルを本番にプッシュする前の早期警告レイヤーとして使用される TFX コンポーネントです。"Infra" Validator の名前は、実際のモデルをサービングする「インフラストラクチャ」でモデルを検証することに由来しています。Evaluator がモデルのパフォーマンスを保証するものであるならば、InfraValidator はモデルが機械的に優良であることを保証し、不良モデルがプッシュされないようにします。
仕組み
InfraValidator はモデルを取り、サンドボックス化されたモデルサーバーをそのモデルで起動して、正常に読み込めるのか、またオプションとしてクエリできるのかどうかを確認します。インフラ検証の結果は blessing
出力に生成されます。これは Evaluator と同じ仕組みです。
InfraValidator はモデルサーバーのバイナリー(TensorFlow Serving など)とデプロイするモデルの互換性に焦点を当てています。「インフラ」バリデーターという名前ではありますが、環境を正しく構成するのはユーザーの責任であり、インフラバリデーターはユーザーが構成した環境にあるモデルサーバーと対話して、正しく動作するかどうかを確認するだけです。この環境を正しく構成しておけば、インフラ検証の合格または不合格に基づいて、モデルを本番サービング環境にサービングできるかどうかを知ることができます。これは次のようなことを示しますが、ここに記載されていることがすべてではありません。
InfraValidator は本番で使用されるモデルサーバーバイナリーと同じバイナリーを使用している。これは、インフラ検証の環境が収束するための最低レベルです。
InfraValidator は、本番で使用されるリソースと同じリソース(CPU の割り当て量と種類、メモリ、アクセラレータなど)を使用している。
InfraValidator は本番で使用されるモデルサーバー構成と同じ構成を使用している
状況によって、InfraValidator がどの程度本番環境と同等であるかをユーザーが選択できます。厳密には、モデルはローカルの Docker 環境でインフラ検証した後で、まったく異なる環境(Kubernetes クラスタなど)に問題なく配布することができますが、InfraValidator はこの違いに関してはチェックしていないということになります。
操作モード
構成に応じて、次のいずれかのモードでインフラ検証を行えます。
LOAD_ONLY
モード: モデルがサービングインフラストラクチャに正常に読み込まれたかどうかをチェックします。またはLOAD_AND_QUERY
モード:LOAD_ONLY
モードのチェックに加え、サンプルリクエストを送信して、モデルが推論を提供できるかどうかをチェックします。InfraValidator は予測が正しいかどうかはチェックしません。リクエストが正常に送信されたかどうかのみをチェックします。
使用方法
通常、InfraValidator は Evaluator コンポーネントの次の定義され、その出力は Pusher にフィードされます。InfraValidator が失敗した場合、そのモデルはプッシュされません。
InfraValidator コンポーネントを構成する
InfraValidator の構成には、3 種類の protos を使用できます。
ServingSpec
ServingSpec
は InfraValidator の最も重要な構成で、次のことを定義します。
実行するモデルサーバーの種類
実行する場所
次のモデルサーバーの種類(サービングバイナリー)がサポートされています。
注意: InfraValidator では、モデルの互換性に影響を及ぼすことなくモデルサーバーのバージョンをアップグレードするために、同じサーバータイプの複数のバージョンを指定することができます。たとえば、tensorflow/serving
画像を 2.1.0
と latest
バージョンの両方でテストすることができるため、モデルが最新の tensorflow/serving
バージョンとも互換することを保証することができます。
現在、次のサービングプラットフォームがサポートされています。
ローカルの Docker(Docker が事前にインストールされている必要があります)
Kubernetes(KubeflowDagRunner のみ制限サポート)
サービングバイナリーとサービングプラットフォームの選択は、oneof
ブロックという ServingSpec
で指定します。たとえば、Kubernetes クラスタで実行している TensorFlow Serving バイナリーを使用するには、tensorflow_serving
と kubernetes
フィールドが設定されている必要があります。
さらに ServingSpec
を構成するには、protobuf の定義をご覧ください。
ValidationSpec
インフラ検証の基準またはワークフローを調整するためのオプションの構成です。
すべての ValidationSpec フィールドには適切なデフォルト値があります。詳細は、protobuf 定義をご覧ください。
RequestSpec
インフラ検証を LOAD_AND_QUERY
モードで実行している場合のサンプルリクエストの構築方法を指定するためのオプションの構成です。LOAD_AND_QUERY
モードを使用するには、request_spec
実行プロパティと examples
入力チャネルの両方がコンポーネントの定義に指定されている必要があります。
ウォームアップで SavedModel を生成する
(バージョン 0.30.0 以降)
InfraValidator は実際のリクエストでモデルを検証するため、これらの検証リクエストを SavedModel のウォームアップリクエストとして簡単に再利用することができます。InfraValidator にはウォームアップで SavedModel をエクスポートするオプション(RequestSpec.make_warmup
)が用意されています。
そして、出力 InfraBlessing
アーティファクトにはウォームアップによる SavedModel が含まれているため、Pusher で、Model
アーティファクトと同様にプッシュすることもできます。
制限事項
現在の InfraValidator は未完全であるため、次のような制限があります。
TensorFlow SavedModel モデル形式のみを検証できます。
Kubernetes で TFX を実行している場合、パイプラインは Kuberflow パイプライン内で
KubeflowDagRunner
によって実行される必要があります。モデルサーバーは Kuberflow が使用しているのと同じ Kubernetes Kurasuta と名前空間で起動します。InfraValidator は TensorFlow Serving にデプロイすることを主な焦点としているため、TensorFlow Lite と TensorFlow.js、またはその他の推論フレームワークへのデプロイでは役に立つとはいえ、精度に劣ります。
LOAD_AND_QUERY
モードのサポートは Predict メソッドシグネチャ(TensorFlow 2 でのみエクスポート可能なメソッド)において制限されています。InfraValidator ではシリアル化されたtf.Example
を唯一の入力として消費するために Predict シグネチャが必要となります。このシグネチャが TFX のほかのコンポーネントとどのように対話するかについては、Penguin の例のサンプルコードをご覧ください。