アーキテクチャ

TensorFlow Serving は、実稼働環境向けに設計された、機械学習モデル用の柔軟で高性能なサービス提供システムです。 TensorFlow Serving を使用すると、同じサーバー アーキテクチャと API を維持しながら、新しいアルゴリズムと実験を簡単にデプロイできます。 TensorFlow Serving は、TensorFlow モデルとのすぐに使える統合を提供しますが、他のタイプのモデルを提供するように簡単に拡張できます。

主要な概念

TensorFlow Serving のアーキテクチャを理解するには、次の重要な概念を理解する必要があります。

サーバブル

Serable はTensorFlow Serving の中心的な抽象化です。 Servable は、クライアントが計算 (検索や推論など) を実行するために使用する基礎となるオブジェクトです。

Serable のサイズと粒度は柔軟です。単一の Servable には、ルックアップ テーブルの単一のシャードから単一のモデル、推論モデルのタプルまで、あらゆるものが含まれる場合があります。 Serables は任意のタイプとインターフェイスにすることができ、次のような柔軟性と将来の改善が可能になります。

  • ストリーミング結果
  • 実験的な API
  • 非同期動作モード

Servable は独自のライフサイクルを管理しません。

典型的なサーバブルには次のようなものがあります。

  • TensorFlow SavedModelBundle ( tensorflow::Session )
  • 埋め込みまたは語彙検索用のルックアップ テーブル

提供可能なバージョン

TensorFlow Serving は、単一サーバー インスタンスの存続期間中、サーバブルの 1 つ以上のバージョンを処理できます。これにより、新しいアルゴリズム構成、重み、およびその他のデータを時間の経過とともにロードできるようになります。バージョンにより、サーブブルの複数のバージョンを同時にロードできるようになり、段階的なロールアウトと実験がサポートされます。サービス提供時に、クライアントは特定のモデルの最新バージョンまたは特定のバージョン ID を要求できます。

サービス可能なストリーム

サーバブル ストリームは、バージョン番号の昇順に並べ替えられた、サーバブルのバージョンのシーケンスです。

モデル

TensorFlow Serving は、モデルを1 つ以上のサーバブルとして表します。機械学習モデルには、1 つ以上のアルゴリズム (学習された重みを含む) とルックアップ テーブルまたは埋め込みテーブルが含まれる場合があります。

複合モデルは次のいずれかとして表すことができます。

  • 複数の独立したサーバブル
  • 単一複合サービス可能

サーバブルはモデルの一部に対応する場合もあります。たとえば、大規模なルックアップ テーブルを多くの TensorFlow Serving インスタンスにわたってシャード化できます。

ローダー

ローダーはサーブブルのライフサイクルを管理します。ローダー API は、関連する特定の学習アルゴリズム、データ、または製品のユースケースから独立した共通のインフラストラクチャを可能にします。具体的には、ローダーはサーブブルをロードおよびアンロードするための API を標準化します。

情報源

ソースは、サーバブルを検索して提供するプラグイン モジュールです。各ソースは、0 個以上の提供可能なストリームを提供します。 Source は、提供可能なストリームごとに、ロードできるようにするバージョンごとに 1 つの Loader インスタンスを提供します。 (Source は実際には 0 個以上の SourceAdapter とチェーンされており、チェーンの最後の項目が L​​oader を発行します。)

TensorFlow Serving の Source 用インターフェイスは、任意のストレージ システムからサーバブルを検出できます。 TensorFlow Serving には、共通の参照ソース実装が含まれています。たとえば、ソースは RPC などのメカニズムにアクセスし、ファイル システムをポーリングできます。

ソースは、複数のサーバブルまたはバージョン間で共有される状態を維持できます。これは、バージョン間のデルタ (差分) 更新を使用するサーブブルに役立ちます。

目指すバージョン

希望のバージョンは、ロードして準備が完了している必要がある提供可能なバージョンのセットを表します。ソースは、一度に 1 つのサービス可能ストリームに対して、このサービス可能バージョンのセットを通信します。ソースが希望するバージョンの新しいリストをマネージャーに渡すと、そのリストはその提供可能なストリームの以前のリストに置き換わります。マネージャーは、以前にロードされ、リストに表示されなくなったバージョンをアンロードします。

バージョンの読み込みが実際にどのように機能するかを確認するには、高度なチュートリアルを参照してください。

マネージャー

マネージャーは、 Servables のライフサイクル全体を処理します。これには以下が含まれます。

  • サーバブルのロード
  • サービスの提供
  • サーバブルのアンロード

マネージャーはソースをリッスンし、すべてのバージョンを追跡します。マネージャーはソースのリクエストに応えようとしますが、必要なリソースが利用できない場合など、目的のバージョンのロードを拒否する場合があります。管理者は「アンロード」を延期することもできます。たとえば、マネージャーは、常に少なくとも 1 つのバージョンがロードされることを保証するポリシーに基づいて、新しいバージョンのロードが完了するまでアンロードを待機することがあります。

TensorFlow Serving Manager は、ロードされたサーブブル インスタンスにクライアントがアクセスするための、シンプルで狭いインターフェイスGetServableHandle()を提供します。

芯

TensorFlow Serving Core は、標準の TensorFlow Serving API を使用して、サーバブルの次の側面を管理します。

  • ライフサイクル
  • メトリクス

TensorFlow Serving Core は、サーバブルとローダーを不透明なオブジェクトとして扱います。

奉仕者の人生

tf サービング アーキテクチャ図

大まかに言って：

  1. ソースは、提供可能なバージョンのローダーを作成します。
  2. ローダーは、Aspired Version として Manager に送信され、Manager はローダーをロードしてクライアントのリクエストに対応します。

さらに詳細に：

  1. Source プラグインは、特定のバージョンのローダーを作成します。ローダーには、Servable をロードするために必要なメタデータがすべて含まれています。
  2. Source はコールバックを使用して、Manager に希望のバージョンを通知します。
  3. マネージャーは、構成されたバージョン ポリシーを適用して、次に実行するアクション (以前にロードされたバージョンをアンロードするか、新しいバージョンをロードするかなど) を決定します。
  4. Manager が安全であると判断した場合、Loader に必要なリソースを与え、新しいバージョンをロードするように指示します。
  5. クライアントは、明示的にバージョンを指定するか、単に最新バージョンを要求することで、マネージャーに Servable を要求します。 Manager は Serable のハンドルを返します。

たとえば、ソースが頻繁に更新されるモデルの重みを含む TensorFlow グラフを表すとします。重みはディスク上のファイルに保存されます。

  1. ソースはモデルの重みの新しいバージョンを検出します。ディスク上のモデル データへのポインターを含むローダーを作成します。
  2. ソースは、ダイナミック マネージャーに希望のバージョンを通知します。
  3. ダイナミック マネージャーはバージョン ポリシーを適用し、新しいバージョンをロードすることを決定します。
  4. ダイナミック マネージャーは、ローダーに十分なメモリがあることを伝えます。ローダーは、新しい重みを使用して TensorFlow グラフをインスタンス化します。
  5. クライアントがモデルの最新バージョンへのハンドルをリクエストすると、Dynamic Manager は Servable の新しいバージョンへのハンドルを返します。

拡張性

TensorFlow Serving は、新しい機能を追加できるいくつかの拡張ポイントを提供します。

バージョンポリシー

バージョン ポリシーは、単一のサービス可能ストリーム内でのバージョンのロードとアンロードのシーケンスを指定します。

TensorFlow Serving には、ほとんどの既知のユースケースに対応する 2 つのポリシーが含まれています。これらは、可用性維持ポリシー (ゼロのバージョンをロードしたままにすることを避けます。通常は、古いバージョンをアンロードする前に新しいバージョンをロードします) とリソース保持ポリシー (2 つのバージョンを同時にロードすることを回避し、リソースが 2 倍必要になります。ロードする前に古いバージョンをアンロードします) です。新しいもの）。モデルの提供可用性が重要であり、リソース コストが低い TensorFlow Serving の単純な使用の場合、可用性維持ポリシーは、古いバージョンをアンロードする前に、新しいバージョンがロードされ、準備ができていることを確認します。 TensorFlow Serving の高度な使用法 (複数のサーバー インスタンスにわたるバージョンの管理など) の場合、リソース保持ポリシーは最小限のリソースを必要とします (新しいバージョンをロードするための追加のバッファーは不要)。

ソース

新しいソースは、新しいファイルシステム、クラウド製品、アルゴリズム バックエンドをサポートする可能性があります。 TensorFlow Serving は、新しいソースを簡単かつ迅速に作成できるようにするためのいくつかの共通の構成要素を提供します。たとえば、TensorFlow Serving には、ポーリング動作を単純なソースにラップするユーティリティが含まれています。ソースは、特定のアルゴリズムおよびデータ ホスティング サーバブルのローダーと密接に関連しています。

カスタム ソースの作成方法の詳細については、カスタム ソースのドキュメントを参照してください。

ローダー

ローダーは、アルゴリズムとデータ バックエンドを追加するための拡張ポイントです。 TensorFlow は、そのようなアルゴリズム バックエンドの 1 つです。たとえば、新しいタイプの提供可能な機械学習モデルのインスタンスをロードし、アクセスを提供し、アンロードするために、新しいローダーを実装します。ルックアップ テーブルと追加のアルゴリズム用のローダーを作成する予定です。

カスタム サーバブルの作成方法については、カスタム サーバブルのドキュメントを参照してください。

バッチャー

複数のリクエストを 1 つのリクエストにバッチ処理すると、特に GPU などのハードウェア アクセラレータが存在する場合に、推論の実行コストを大幅に削減できます。 TensorFlow Serving には、クライアントが複数のリクエストにわたるタイプ固有の推論を、アルゴリズム システムがより効率的に処理できるバッチ リクエストに簡単にバッチ処理できるリクエスト バッチ ウィジェットが含まれています。詳細については、 「バッチ処理ガイド」を参照してください。