ホーム » 「TensorFlow Deploy」タグがついた投稿

タグアーカイブ: TensorFlow Deploy

TensorFlow : Deploy : S3 上の TensorFlow

TensorFlow : Deploy : S3 上の TensorFlow (翻訳/解説)
翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 11/22/2018 (v1.12.0)

* 本ページは、TensorFlow の本家サイトの Deploy – TensorFlow on S3 を翻訳した上で
適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

TensorFlow は S3 からのデータの読み込み / S3 へのデータの書き出しをサポートします。S3 はオブジェクト・ストレージ API で近くに偏在し、分散訓練のように複数のアクターによりデータがアクセスされなければならない状況で役立ちます。

このドキュメントは必要なセットアップを教え導いて、利用方法上の例を提供します。

 

Configuration

貴方の TensorFlow プログラムで S3 上のデータを読み書きするとき、その挙動は各種の環境の変数により制御できます :

  • AWS_REGION: デフォルトでは、S3 のために regional エンドポイントが使用され、リージョンは AWS_REGION により制御されます。AWS_REGION が指定されない場合には、us-east-1 が使用されます。
  • S3_ENDPOINT: エンドポイントは指定された S3_ENDPOINT で明示的にオーバーライド可能です。
  • S3_USE_HTTPS: S3_USE_HTTPS=0 でない限りは、デフォルトでは S3 へのアクセスに HTTPS が使用されます。
  • S3_VERIFY_SSL: HTTPS が使用される場合、SSL verification は S3_VERIFY_SSL=0 で無効にされます。

パブリックにアクセス可能ではないバケットのオブジェクトを読み書きするためには、AWS credentials が次の方法の一つを通して提供されなければなりません :

  • credentials をローカルシステムの AWS credentials profile ファイルに設定します、Linux, macOS あるいは Unix 上の ~/.aws/credentials か、Windows の C:\Users\USERNAME\.aws\credentials に位置します。
  • AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY 環境変数を設定します。
  • TensorFlow が EC2 インスタンス上で配備される場合、IAM ロールを指定してから EC2 インスタンスにそのロールへのアクセスを与えます。

 

Example セットアップ

上の情報を使用して、次の環境変数を設定することにより TensorFlow を S3 エンドポイントと通信するために configure できます :

AWS_ACCESS_KEY_ID=XXXXX                 # Credentials only needed if connecting to a private endpoint
AWS_SECRET_ACCESS_KEY=XXXXX
AWS_REGION=us-east-1                    # Region for the S3 bucket, this is not always needed. Default is us-east-1.
S3_ENDPOINT=s3.us-east-1.amazonaws.com  # The S3 API Endpoint to connect to. This is specified in a HOST:PORT format.
S3_USE_HTTPS=1                          # Whether or not to use HTTPS. Disable with 0.
S3_VERIFY_SSL=1                         # If HTTPS is used, controls if SSL should be enabled. Disable with 0.

 

使用方法

ひとたびセットアップが完了すれば、TensorFlow は様々な方法で S3 と相互作用できます。Tensorflow IO 関数があるところであればどこでも、S3 url が使用可能です。

 

スモークテスト

セットアップをテストするためには、stat a file :

from tensorflow.python.lib.io import file_io
print file_io.stat('s3://bucketname/path/')

これに類似の出力を見るはずです :

<tensorflow.python.pywrap_tensorflow_internal.FileStatistics; proxy of <Swig Object of type 'tensorflow::FileStatistics *' at 0x10c2171b0> >

 

データを読む

データを読むとき、読み書きするために使用しているファイルパスを S3 パスに変更します。例えば :

filenames = ["s3://bucketname/path/to/file1.tfrecord",
             "s3://bucketname/path/to/file2.tfrecord"]
dataset = tf.data.TFRecordDataset(filenames)

 

Tensorflow ツール

Tensorboard やモデル serving のような、多くの TensorFlow ツールもまた引数として S3 URL を取れます :

tensorboard --logdir s3://bucketname/path/to/model/
tensorflow_model_server --port=9000 --model_name=model --model_base_path=s3://bucketname/path/to/model/export/

これは総てのデータ要求について S3 を使用して end-to-end ワークフローを可能にします。

 

S3 エンドポイント実装

S3 は Amazon により創案されましたが、その S3 API は人気が広まり複数の実装を持ちます。次の実装が基本的な互換性テストを合格しています :

 

以上


TensorFlow : Deploy : TensorFlow Serving と Kubernetes で Inception モデルをサービス提供する

TensorFlow : Deploy : TensorFlow Serving と Kubernetes で Inception モデルをサービス提供する (翻訳)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 09/09/2017

* 本ページは、TensorFlow 本家サイトの Deploy : TensorFlow Serving – Serving Inception Model with TensorFlow Serving and Kubernetes を翻訳した上で適宜、補足説明したものです:

* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

このチュートリアルでは、Docker コンテナで動作する TensorFlow Serving コンポーネントを TensorFlow Inception モデルをサービス提供するためにどのように使用するかそして serving クラスタを Kubernetes でどのように配備するかを示します。

TensorFlow Serving についてより学習するためには、TensorFlow Serving 基本チュートリアルTensorFlow Serving 上級チュートリアル を推奨します。

TensorFlow Inception モデルについてより学習するためには、Inception in TensorFlow を推奨します。

  • パート 0 は配備のための TensorFlow Serving Docker イメージをどのように作成するかを示します。
  • パート 1 はローカル・コンテナでイメージをどのように実行するかを示します。
  • パート 2 は Kubernetes でどのように配備するかを示します。

 

パート 0: Docker イメージを作成する

TensorFlow Serving Docker イメージを構築することについての詳細は Using TensorFlow Serving via Docker を参照してください。

コンテナを実行する

Dockerfile.devel を使用してベースイメージ $USER/tensorflow-serving-devel を構築します。そしてビルド・イメージを使用してコンテナをローカルでスタートさせます。

$ docker build --pull -t $USER/tensorflow-serving-devel -f tensorflow_serving/tools/docker/Dockerfile.devel .
$ docker run --name=inception_container -it $USER/tensorflow-serving-devel

コンテナで TensorFlow Serving を clone、configure そしてビルドする

Note: 後述のすべての bazel ビルド・コマンドは標準的な -c opt フラグを使用します。ビルドをさらに最適化するためには、ここの手順 を参照してください。

実行中のコンテナ内で、clone して configure して、そして TensorFlow Serving サンプル・コードをビルドします。

root@c97d8e820ced:/# git clone --recurse-submodules https://github.com/tensorflow/serving
root@c97d8e820ced:/# cd serving/tensorflow
root@c97d8e820ced:/serving/tensorflow# ./configure
root@c97d8e820ced:/serving# cd ..
root@c97d8e820ced:/serving# bazel build -c opt tensorflow_serving/example/...

次に TensorFlow ModelServer を ここの手順 を使用して apt-get でインストールするか、以下を使用して ModelServer バイナリをビルドします :

root@c97d8e820ced:/serving# bazel build -c opt tensorflow_serving/model_servers:tensorflow_model_server

このチュートリアルの残りでは貴方が ModelServer をローカルでコンパイルしたことを仮定します、その場合はそれを実行するためにコマンドは bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server です。けれどももし apt-get を使用して ModelServer をインストールした場合には、単にそのコマンドを tensorflow_model_server で置き換えてください。

コンテナで Inception モデルをエクスポートする

実行中のコンテナで、リリースされた Inception モデル訓練チェックポイント を使用して inception モデルをエクスポートするために inception_saved_model.py を実行します。ゼロから訓練する代わりに、推論グラフをリストアしてそれを直接エクスポートするために良く訓練された variable の容易に利用可能なチェックポイントを使用します。

root@c97d8e820ced:/serving# curl -O http://download.tensorflow.org/models/image/imagenet/inception-v3-2016-03-01.tar.gz
root@c97d8e820ced:/serving# tar xzf inception-v3-2016-03-01.tar.gz
root@c97d8e820ced:/serving# ls inception-v3
README.txt  checkpoint  model.ckpt-157585
root@c97d8e820ced:/serving# bazel-bin/tensorflow_serving/example/inception_saved_model --checkpoint_dir=inception-v3 --output_dir=inception-export
Successfully loaded model from inception-v3/model.ckpt-157585 at step=157585.
Successfully exported model to inception-export
root@c97d8e820ced:/serving# ls inception-export
1
root@c97d8e820ced:/serving# [Ctrl-p] + [Ctrl-q]

配備のためにイメージを Commit

上の手順の最後で (コンテナを) 停止する代わりにコンテナからデタッチしていることに注意してください、何故ならば Kubernetes 配備のために総ての変更を新しいイメージ $USER/inception_serving に commit したいからです。

$ docker commit inception_container $USER/inception_serving
$ docker stop inception_container

 

パート 1: ローカル Docker コンテナ内で実行する

ビルドしたイメージを使用して serving ワークフローをローカルでテストしましょう。

$ docker run -it $USER/inception_serving

サーバをスタートする

コンテナで gRPC tensorflow_model_server を実行する。

root@f07eec53fd95:/# cd serving
root@f07eec53fd95:/serving# bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server --port=9000 --model_name=inception --model_base_path=inception-export &> inception_log &
[1] 45

サーバに問い合わせる

inception_client.py でサーバに問い合わせます。クライアントはコマンドライン・パラメータで指定された画像を ImageNet カテゴリの人間に読める説明への分類のために gRPC を通してサーバに送ります。

root@f07eec53fd95:/serving# bazel-bin/tensorflow_serving/example/inception_client --server=localhost:9000 --image=/path/to/my_cat_image.jpg
outputs {
  key: "classes"
  value {
    dtype: DT_STRING
    tensor_shape {
      dim {
        size: 1
      }
      dim {
        size: 5
      }
    }
    string_val: "tiger cat"
    string_val: "Egyptian cat"
    string_val: "tabby, tabby cat"
    string_val: "lynx, catamount"
    string_val: "Cardigan, Cardigan Welsh corgi"
  }
}
outputs {
  key: "scores"
  value {
    dtype: DT_FLOAT
    tensor_shape {
      dim {
        size: 1
      }
      dim {
        size: 5
      }
    }
    float_val: 9.5486907959
    float_val: 8.52025032043
    float_val: 8.05995368958
    float_val: 4.30645561218
    float_val: 3.93207240105
  }
}

root@f07eec53fd95:/serving# exit

 
動きました!サーバは貴方の猫の画像を成功的に分類しました。

 

パート 2: Kubernetes 内で配備する

このセクションでは Google Cloud Platform において Kubernetes で serving クラスタを配備するためにパート 0 でビルドしたコンテナ・イメージを使用します。

GCloud プロジェクト・ログイン

ここでは貴方が tensorflow-serving という名前の gcloud project を作成してログインしていることを仮定しています。

$ gcloud auth login --project tensorflow-serving

コンテナ・クラスタを作成する

最初にサービス配備のために Google Container Engine クラスタを作成します。

$ gcloud container clusters create inception-serving-cluster --num-nodes 5
Creating cluster inception-serving-cluster...done.
Created [https://container.googleapis.com/v1/projects/tensorflow-serving/zones/us-central1-f/clusters/inception-serving-cluster].
kubeconfig entry generated for inception-serving-cluster.
NAME                       ZONE           MASTER_VERSION  MASTER_IP        MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
inception-serving-cluster  us-central1-f  1.1.8           104.197.163.119  n1-standard-1  1.1.8         5          RUNNING

 
gcloud container コマンドのためのデフォルト・クラスタを設定して kubectl にクラスタ credentials を渡します。

$ gcloud config set container/cluster inception-serving-cluster
$ gcloud container clusters get-credentials inception-serving-cluster
Fetching cluster endpoint and auth data.
kubeconfig entry generated for inception-serving-cluster.

Docker イメージをアップロードする

さて私たちのイメージを Google Cloud Platform 上でそれを実行できるように Google Container Registry に push しましょう。

最初に Container Registry フォーマットとプロジェクト名を使用して $USER/inception_serving イメージにタグ付けします、

$ docker tag $USER/inception_serving gcr.io/tensorflow-serving/inception

次にイメージをレジストリに push します。

$ gcloud docker -- push gcr.io/tensorflow-serving/inception

Kubernetes Deployment とサービスを作成する

配備は、Kubernetes Deployment で制御される inception_inference サーバの3つのレプリカから成ります。レプリカは Kubernetes サービス により External ロードバランサと共に外部的に晒されます。

サンプル Kubernetes config inception_k8s.yaml を使用してそれらを作成します。

$ kubectl create -f tensorflow_serving/example/inception_k8s.yaml
deployment "inception-deployment" created
service "inception-service" created

deployment と pods のステータスを見るためには :

$ kubectl get deployments
NAME                    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
inception-deployment    3         3         3            3           5s
$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
inception-deployment-bbcbc   1/1       Running   0          10s
inception-deployment-cj6l2   1/1       Running   0          10s
inception-deployment-t1uep   1/1       Running   0          10s

サービスのステータスを見るためには :

$ kubectl get services
NAME                    CLUSTER-IP       EXTERNAL-IP       PORT(S)     AGE
inception-service       10.239.240.227   104.155.184.157   9000/TCP    1m

総てがアップして実行中になるにはしばらくかかります。

$ kubectl describe service inception-service
Name:           inception-service
Namespace:      default
Labels:         run=inception-service
Selector:       run=inception-service
Type:           LoadBalancer
IP:         10.239.240.227
LoadBalancer Ingress:   104.155.184.157
Port:           <unset> 9000/TCP
NodePort:       <unset> 30334/TCP
Endpoints:      <none>
Session Affinity:   None
Events:
  FirstSeen LastSeen    Count   From            SubobjectPath   Type        Reason      Message
  --------- --------    -----   ----            -------------   --------    ------      -------
  1m        1m      1   {service-controller }           Normal      CreatingLoadBalancer    Creating load balancer
  1m        1m      1   {service-controller }           Normal      CreatedLoadBalancer Created load balancer

サービス外部 IP アドレスは LoadBalancer Ingress のすぐ次にリストされています。

モデルを問い合わせる

今、ローカルホストから (サービスの) 外部アドレスのサービスを問い合わせることができます。

$ bazel-bin/tensorflow_serving/example/inception_client --server=104.155.184.157:9000 --image=/path/to/my_cat_image.jpg
outputs {
  key: "classes"
  value {
    dtype: DT_STRING
    tensor_shape {
      dim {
        size: 1
      }
      dim {
        size: 5
      }
    }
    string_val: "tiger cat"
    string_val: "Egyptian cat"
    string_val: "tabby, tabby cat"
    string_val: "lynx, catamount"
    string_val: "Cardigan, Cardigan Welsh corgi"
  }
}
outputs {
  key: "scores"
  value {
    dtype: DT_FLOAT
    tensor_shape {
      dim {
        size: 1
      }
      dim {
        size: 5
      }
    }
    float_val: 9.5486907959
    float_val: 8.52025032043
    float_val: 8.05995368958
    float_val: 4.30645561218
    float_val: 3.93207240105
  }
}

 
Kubernetes のサービスとしてサーブする Inception モデルを成功的に配備しました!

 
以上


TensorFlow : Deploy : TensorFlow Serving : 標準的な TensorFlow ModelServer を構築する

TensorFlow : Deploy : TensorFlow Serving : 標準的な TensorFlow ModelServer を構築する (翻訳)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 09/07/2017

* 本ページは、TensorFlow 本家サイトの Deploy : TensorFlow Serving – Building Standard TensorFlow ModelServer を翻訳した上で適宜、補足説明したものです:

* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

このチュートリアルは、訓練された TensorFlow モデルの新しいバージョンを動的に探索してサーブする、標準的な TensorFlow ModelServer をビルドするために TensorFlow コンポーネントをどのように使用するかを示します。もし貴方のモデルをサーブするために標準的なサーバを使用したいだけであるならば、TensorFlow Serving 基本チュートリアル を見てください。

このチュートリアルは、手書き画像 (MNIST データ) 分類のための TensorFlow チュートリアルで紹介された単純な Softmax 回帰モデルを使用します。もし貴方が TensorFlow または MNIST が何であるか知らないのであれば、ML 初心者向けの MNIST を見てください。

このチュートリアルのためのコードは2つのパートから成ります :

  • Python ファイル、mnist_saved_model.py これはモデルの複数のバージョンを訓練してエクスポートします。
  • C++ ファイル main.cc、これは標準的な TensorFlow ModelServer で新しいエクスポートされたモデルを探索してそれらをサーブ (サービス提供) するために gRPC サービスを実行します。

このチュートリアルは次のタスクを通して進みます :

  1. TensorFlow モデルを訓練してエクスポートする。
  2. TensorFlow Serving ServerCore でモデル・バージョニングを管理する。
  3. SessionBundleSourceAdapterConfig を使用してバッチ処理を構成する。
  4. TensorFlow Serving ServerCore でリクエストにサーブする。
  5. サービスを実行してテストする。

始める前に、(インストール) 要件 は完了しておいてください。

Note: 後述のすべての bazel ビルド・コマンドは標準的な -c opt フラグを使用します。ビルドをさらに最適化するためには、ここの手順 を参照してください。

 

TensorFlow モデルを訓練してエクスポートする

export ディレクトリが既に存在しているならばクリアします :

$>rm -rf /tmp/mnist_model

モデルの最初のバージョンを (100 反復で) 訓練してエクスポートする :

$>bazel build -c opt //tensorflow_serving/example:mnist_saved_model
$>bazel-bin/tensorflow_serving/example/mnist_saved_model --training_iteration=100 --model_version=1 /tmp/mnist_model

 
モデルの2番目のバージョンを (2000 反復で) 訓練してエクスポートする :

$>bazel-bin/tensorflow_serving/example/mnist_saved_model --training_iteration=2000 --model_version=2 /tmp/mnist_model

 
mnist_saved_model.py で見れるように、訓練とエクスポートは TensorFlow Serving 基本チュートリアルにおけるものと同じように行なわれます。デモ目的では、最初の実行のために訓練反復を意図的に抑えて v1 としてエクスポートして、その一方で2番目の実行のために通常のようにそれを訓練して同じ親ディレクトリに v2 としてエクスポートします — より徹底した訓練で後者により良い分類精度を獲得することを期待しますので。mnist_model ディレクトリで各訓練実行のための訓練データを見るでしょう :

$>ls /tmp/mnist_model
1  2

 

ServerCore

さて新しいアルゴリズムが実験されている時、あるいはモデルが新しいデータセットで訓練されている時、モデルの v1 と v2 が実行時に動的に生成されることを想像してください。本番環境では、段階的なロールアウトをサポート可能なサーバをビルドすることを望むかもしれません、そこでは v1 をサーブする一方で v2 が探索され、ロードされ、実験され、モニターされ、あるいは元に戻されます。あるいは、v2 を持ってくる前に v1 を取り壊すことを望むかもしれません。TensorFlow Serving は両方のオプションをサポートします — 一つは移行 (transition) 時の可用性を維持するのに良く、他方はリソース使用 (e.g. RAM) を最小化するのに良いです。

TensorFlow Serving Manager は正確にそれを行ないます。それは、それらのロード、サービングそしてアンロード、更にはバージョン移行を含む TensorFlow モデルの完全なライフサイクルを処理します。このチュートリアルでは、内部的には AspiredVersionsManager をラップする、TensorFlow Serving ServerCore の上に貴方のサーバを構築します。

int main(int argc, char** argv) {
  ...

  ServerCore::Options options;
  options.model_server_config = model_server_config;
  options.servable_state_monitor_creator = &CreateServableStateMonitor;
  options.custom_model_config_loader = &LoadCustomModelConfig;

  ::google::protobuf::Any source_adapter_config;
  SavedModelBundleSourceAdapterConfig
      saved_model_bundle_source_adapter_config;
  source_adapter_config.PackFrom(saved_model_bundle_source_adapter_config);
  (*(*options.platform_config_map.mutable_platform_configs())
      [kTensorFlowModelPlatform].mutable_source_adapter_config()) =
      source_adapter_config;

  std::unique_ptr<ServerCore> core;
  TF_CHECK_OK(ServerCore::Create(options, &core));
  RunServer(port, std::move(core));

  return 0;
}

ServerCore::Create() は ServerCore::Options パラメータを取ります。ここに2、3の一般に使用されるオプションがあります :

  • ModelServerConfig はロードされるモデルを指定します。モデルは、モデルの静的リストを宣言する model_config_list を通してか、実行時に更新されるかもしれないモデルのリストを宣言する custom_model_config を通して宣言されます。
  • PlatformConfigMap、これは (tensorflow のような) プラットフォームの名前から PlatformConfig へマップします、これは SourceAdapter を作成するために使用されます。SourceAdapter は StoragePath (モデル・バージョンが探索されるパス) をモデル Loader (モデル・バージョンをストレージ・パスからロードして Manager に状態移行 (= state transition) インターフェイスを提供する) に適合させます。PlatformConfig が SavedModelBundleSourceAdapterConfig を含むのであれば、SavedModelBundleSourceAdapter が作成され、これは後で説明されます。

SavedModelBundle は TensorFlow Serving の基本的なコンポーネントです。それは与えられたパスからロードされた TensorFlow モデルを表してそして TensorFlow が推論を実行するのと同じ Session::Run インターフェイスを提供します。SavedModelBundleSourceAdapter はストレージ・パスを Loader に適合させることによってモデル・ライフタイムは Manger に管理されます。SavedModelBundle は deprecated な SessionBundle の後継であることに注意してください。ユーザは SavedModelBundle を使用することが推奨されます、何故ならば SessionBundle のサポートは間もなく取り除かれますので。

これら総てとともに、ServerCore は内部的には以下を行ないます :

  • FileSystemStoragePathSource をインスタンス化します、これは model_config_list で宣言されたモデル export パスをモニタします。
  • model_config_list で宣言されたモデル・プラットフォームを持つ PlatformConfigMap を使用して SourceAdapter をインスタンス化して、FileSystemStoragePathSource をそれに接続します。このように、export パス下で新しいモデル・バージョンが探索された時はいつでも、SavedModelBundleSourceAdapter はそれを Loader に適合させます。
  • AspiredVersionsManager と呼ばれる Manager の特定の実装をインスタンス化します、これは SavedModelBundleSourceAdapter により作成された総てのそのような Loader インスタンスを管理します。ServerCore は Manager インターフェイスを呼び出しを AspiredVersionsManager に委任することによりエクスポートします。

新しいバージョンが利用可能なときはいつでも、この AspiredVersionsManager は新しいバージョンをロードし、そしてそのデフォルトの挙動では古いものをアンロードします。もし貴方がカスタマイズを始めることを望むのであれば、それが内部的に作成するコンポーネントとそれをどのように構成するかを理解することが奨励されます。

TensorFlow Serving は非常に柔軟で拡張性があるように最初から設計されていることに言及することは価値があるでしょう。ServerCore と AspiredVersionsManager のような一般的なコア・コンポーネントを活用する一方で、システムの挙動をカスタマイズするために様々なプラグインをビルドできます。例えば、ローカル・ストレージの代わりにクラウド・ストレージをモニタする data source プラグインをビルドできますし、あるいは異なる方法でバージョン移行を行なう version policy プラグインをビルドすることもできるでしょう — 実際に、non-TensorFlow モデルをサーブする custom model プラグインをビルドすることさえできるでしょう。これらのトピックはこのチュートリアルの範囲外です。けれども、更なる情報のために custom sourcecustom servable チュートリアルを参照可能です。

 

バッチ処理

本番環境で望むもう一つの典型的なサーバ特徴はバッチ処理です。機械学習の推論を行なうために使用される現代的なハードウェア・アクセラレータ (GPU, etc.) は推論リクエストが巨大なバッチで実行されるときに通常はベストな計算効率を達成します。SavedModelBundleSourceAdapter を作成するときに適切な SessionBundleConfig を提供することによりバッチ処理は有効になります。このケースでは BatchingParameters を殆どデフォルト値で設定します。バッチ処理は custom timeout, batch_size, etc. 値を設定することで微調整できます。詳細は、BatchingParameters を参照してください (訳注: リンクなし)。

SessionBundleConfig session_bundle_config;
// Batching config
if (enable_batching) {
  BatchingParameters* batching_parameters =
      session_bundle_config.mutable_batching_parameters();
  batching_parameters->mutable_thread_pool_name()->set_value(
      "model_server_batch_threads");
}
*saved_model_bundle_source_adapter_config.mutable_legacy_config() =
    session_bundle_config;

バッチ全体に到達した時、推論リクエストは内部的に単一の巨大なリクエスト (テンソル) にマージされ、tensorflow::Session::Run() が呼び起こされます (これは GPU 上の実際の効率上の有益が由来する場所です)。

 

Manager でサーブする

上述したように、TensorFlow Serving Manager は任意の機械学習システムにより生成されるモデルのロード、サーブ、アンロードとバージョン移行を処理する一般的なコンポーネントとして設計されています。その API は次の基本的な概念を中心として構築されています :

  • Servable: Servable は、クライアント・リクエストにサーブすることに使用できる任意の Opaque (型) オブジェクトです。servable のサイズと粒度 (= granularity) は柔軟で、単一の servable は単一の機械学習されたモデルへの検索テーブルの単一のシャードからモデルのタプルまで任意のものを含むかもしれません。servable は任意の型とインターフェイスを取ることができます。
  • Servable Version: Servable はバージョン化され TensorFlow Serving Manager は servable の一つまたはそれ以上の version を管理できます。バージョニングは servable の一つのバージョン以上が同時にロードされることを許可し、段階的なロールアウトと実験をサポートします。
  • Servable Stream: servable stream は、増加する version 番号を持つ、servable の version のシークエンスです。
  • Model: 機械学習されたモデルは一つまたはそれ以上の servable で表されます。servable のサンプルは :
    • TensorFlow session またはそれ回りの SavedModelBundle のような、ラッパー。
    • 他の種類の機械学習されたモデル。
    • 語彙検索テーブル。
    • 埋め込み検索テーブル。

    合成モデル (= composite model) は複数の独立した servable として、または単一の合成 servable として表されます。servable はまた、例えば多くの Manager インスタンスに渡るシャードされた巨大な検索ケーブルを持つ、モデルの断片にも相当するかもしれません。

これら総てをこのチュートリアルのコンテクストに集約するために :

  • TensorFlow モデルは一つの種類の servable で表されます — SavedModelBundle です。SavedModelBundle は内部的には、どのようなグラフが session にロードされるかそして推論のためにそれをどのように実行するかについての何某かの metadata を伴う tensorflow:Session から成ります。
  • TensorFlow エクスポートのストリームを含むファイルシステム・ディレクトリが、それぞれは名前がバージョン番号であるそれ自身のサブディレクトリ内にあります。外側のディレクトリは、サーブされる TensorFlow モデルのための servable stream のシリアライズ化された表現として考えることができます。各エクスポートはロード可能な servable に相当します。
  • AspiredVersionsManager は export stream をモニタし、総ての SavedModelBundle servable のライフサイクルを動的に管理します。

それから TensorflowPredictImpl::Predict は丁度 :

  • manager から (ServerCore を通して) SavedModelBundle をリクエストする。
  • PredictRequest の論理テンソル名を実際のテンソル名にマップして値をテンソルにバインドするために generic signatures を使用する。
  • 推論を実行する。

 

サーバをテストして実行する

エクスポート (されたモデル) の最初のバージョンをモニタされるフォルダーにコピーしてそしてサーバをスタートします。

$>mkdir /tmp/monitored
$>cp -r /tmp/mnist_model/1 /tmp/monitored
$>bazel build -c opt //tensorflow_serving/model_servers:tensorflow_model_server
$>bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server --enable_batching --port=9000 --model_name=mnist --model_base_path=/tmp/monitored

 
サーバは毎秒 “Aspiring version for servable …” というログ・メッセージを吐きます、これはそれがエクスポート (されたモデル) を見つけて、その存続を追跡中であることを意味します。–concurrency=10 とともに実行します。これはサーバに同時リクエストを送りそしてバッチ処理ロジックのトリガーとなります。

$>bazel build -c opt //tensorflow_serving/example:mnist_client
$>bazel-bin/tensorflow_serving/example/mnist_client --num_tests=1000 --server=localhost:9000 --concurrency=10
...
Inference error rate: 13.1%

 
それからエクスポート (されたモデル) の2番目のバージョンをモニタされるフォルダにコピーしてテストを再実行します :

$>cp -r /tmp/mnist_model/2 /tmp/monitored
$>bazel-bin/tensorflow_serving/example/mnist_client --num_tests=1000 --server=localhost:9000 --concurrency=10
...
Inference error rate: 9.5%

 
これは貴方のサーバが自動的に新しいバージョンを探索してそれを serving のために使用していることを確かなものとします!

 
以上



TensorFlow : Deploy : TensorFlow Serving : TensorFlow モデルをサーブする

TensorFlow : Deploy : TensorFlow Serving : TensorFlow モデルをサーブする (翻訳)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 09/04/2017

* 本ページは、TensorFlow 本家サイトの Deploy : TensorFlow Serving – Serving a TensorFlow Model を翻訳した上で
適宜、補足説明したものです:

* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

このチュートリアルは、訓練された TensorFlow モデルをエクスポートするために TensorFlow Serving コンポーネントをどのように使用するか、そしてそれをサーブするために標準的な tensorflow_model_server をどのように使用するかを貴方に示します。もし貴方が TensorFlow Serving に既に精通していてサーバ内部がどのように動作するかについてより知りたいのであれば、TensorFlow Serving advanced tutorial を見てください。

このチュートリアルは、手書き画像 (MNIST データ) 分類のための TensorFlow チュートリアルで紹介された単純な Softmax 回帰モデルを使用します。もし貴方が TensorFlow または MNIST が何であるか知らないのであれば、ML 初心者向けの MNIST を見てください。

このチュートリアルのためのコードは2つのパートから成ります :

  • Python ファイル、mnist_saved_model.py これはモデルを訓練してエクスポートします。
  • ModelServer バイナリ、これは apt-get を使用してインストールされるか、C++ ファイル (main.cc) からコンパイルされます。TensorFlow Serving ModelServer は新しいエクスポートされたモデルを見つけてそれをサーブするために gRPC サービスを実行します。

始める前に、(インストール) 要件 は完了しておいてください。

Note: 後述のすべての bazel ビルド・コマンドは標準的な -c opt フラグを使用します。ビルドをさらに最適化するためには、ここの手順 を参照してください。

 

TensorFlow モデルを訓練してエクスポートする

mnist_saved_model.py で見れるように、訓練は ML 初心者向けの MNIST チュートリアル内と同じ方法で行われます。TensorFlow グラフは、x としての入力テンソル (画像) と y としての出力テンソル (Softmax score) とともに、TensorFlow session sess で launch されます。

それからモデルをエクスポートするために TensorFlow の SavedModelBuilder モジュール を使用します。SavedModelBuilder は訓練したモデルの “スナップショット” を信頼性のあるストレージに保存し、それは後で推論のためにロードできます。

SavedModel フォーマットの詳細については、SavedModel README.md のドキュメントを見てください。

mnist_saved_model.py から、次は、モデルをディスクに保存する一般的なプロセスを示すための短いコード・スニペットです。

from tensorflow.python.saved_model import builder as saved_model_builder
...
export_path_base = sys.argv[-1]
export_path = os.path.join(
      compat.as_bytes(export_path_base),
      compat.as_bytes(str(FLAGS.model_version)))
print 'Exporting trained model to', export_path
builder = saved_model_builder.SavedModelBuilder(export_path)
builder.add_meta_graph_and_variables(
      sess, [tag_constants.SERVING],
      signature_def_map={
           'predict_images':
               prediction_signature,
           signature_constants.DEFAULT_SERVING_SIGNATURE_DEF_KEY:
               classification_signature,
      },
      legacy_init_op=legacy_init_op)
builder.save()

SavedModelBuilder.__init__ は次の引数を取ります :

  • export_path は export ディレクトリのパス。

SavedModelBuilder はディレクトリが存在しない場合はそれを作成します。例えば、export ディレクトリを得るためにコマンドライン引数と FLAGS.model_version を連結し FLAGS.model_version はモデルのバージョンを指定します。同じモデルのより新しいバージョンをエクスポートする時はより大きい整数値を指定するべきです。各バージョンは与えられたパス下の異なるサブディレクトリにエクスポートされます。

次の引数で SavedModelBuilder.add_meta_graph_and_variables() を使用して meta graph と variable をビルダーに追加できます :

  • sess は TensorFlow session で、エクスポートしている訓練モデルを保持しています。
  • tags はタグのセットで、それと共に meta graph を保存します。この場合は、グラフを serving で利用しようとしていますから、事前定義された SavedModel tag constants から serve tag を使用します。より詳細は、tag_constants.py関連する TensorFlow API 文書 を見てください。
  • signature_def_map は、meta graph に追加するための tensorflow::SignatureDef への signature のためのユーザ提供キーのマップを指定します。signature はどのタイプのモデルがエクスポートされるか、そして推論を実行するときにバインドする入力/出力テンソルを指定します。

特別な signature key serving_default は default serving signature を指定します。default serving signature def key は、signature に関連する他の constant と一緒に SavedModel signature constants の一部として定義されています。より詳細は、signature_constants.py関連する TensorFlow 1.0 API 文書 を見てください。

更に、signature defs を簡単にビルドすることを助けるために、SavedModel API は signature def utils を提供しています。特に、上掲の mnist_saved_model.py コード・スニペット内では、predict_signature と classification_signature をビルドするために signature_def_utils.build_signature_def() を使用しています。

predict_signature がどのように定義されるかのためのサンプルとして、util は次の引数を取ります :

  • inputs={‘images’: tensor_info_x} は入力テンソル info を指定します。
  • outputs={‘scores’: tensor_info_y} は score テンソル info を指定します。
  • method_name は推論のために使用されるメソッドです。予想リクエストのためには、それは tensorflow/serving/predict に設定されるべきです。他のメソッド名については、signature_constants.py と 関連する TensorFlow 1.0 API 文書 を見てください。

tensor_info_x と tensor_info_y は ここ で定義されている tensorflow::TensorInfo protocol buffer の構造を持つことに注意してください。テンソル info を簡単にビルドするために、TensorFlow SavedModel API はまた utils.py関連する TensorFlow 1.0 API 文書 とともに提供しています。

また、images と scores がテンソル・エイリアス名であることにも注意してください。それらはどのような一意の文字列を望んでも良く、そしてそれらは、予想リクエストを後で送る時のテンソル・バインディングのために参照するテンソル x と y の論理名になるでしょう。

例えば、もし x が名前 ‘long_tensor_name_foo’ のテンソルを参照して y が名前 ‘generated_tensor_name_bar’ のテンソルを参照する場合、builder はテンソル論理名を実際の名前マッピング (‘images’ -> ‘long_tensor_name_foo’) と (‘scores’ -> ‘generated_tensor_name_bar’) にストアします。推論を実行するとき、これはユーザにこれらのテンソルを論理名で参照することを可能にします。

Note: 上の記述に加えて、signature def 構造に関係する文書とそれをどのようにセットアップするかについては ここ で見つけられます。

 
Let’s run it!

export ディレクトリが既に存在しているならばクリアします :

$>rm -rf /tmp/mnist_model

tensorflow と tensorflow-serving-api PIP パッケージをインストールしたいのであれば、単純な python コマンドを使用してすべての Python コード (export と client) を実行できます。PIP パッケージをインストールするためには、ここの手順 をフォローしてください。それらのパッケージをインストールすることなしに必要な依存をビルドしてすべてのコードを実行するために Bazel を使用することもまた可能です。codelab の残りは Bazel と PIP オプションのための手順を持ちます。

Bazel:

$>bazel build -c opt //tensorflow_serving/example:mnist_saved_model
$>bazel-bin/tensorflow_serving/example/mnist_saved_model /tmp/mnist_model
Training model...

...

Done training!
Exporting trained model to /tmp/mnist_model
Done exporting!

あるいは tensorflow-serving-api をインストールしているならば、次を実行できます :

python tensorflow_serving/example/mnist_saved_model.py /tmp/mnist_model

さて export ディレクトリを見てみましょう。

$>ls /tmp/mnist_model
1

上で述べたように、モデルの各バージョンをエクスポートするためにサブディレクトリが作成されます。FLAGS.model_version は 1 のデフォルト値を持ちますので、従って相当するサブディレクトリ 1 が作成されます。

$>ls /tmp/mnist_model/1
saved_model.pb variables

各バージョンのサブディレクトリは次のファイルを含みます :

  • saved_model.pb はシリアライズされた tensorflow::SavedModel です。それはモデルの一つまたそれ以上のグラフ定義を、更には signature のようなモデルの metadata も含みます。
  • variables はグラフのシリアライズされた variable を保持するファイルです。

それによって、貴方の TensorFlow モデルはエクスポートされてロードされる準備が整います!

 

エクスポートされたモデルを標準的な TensorFlow ModelServer でロードする

ローカルでコンパイルされた ModelServer を使用したい場合には、次を実行します :

$>bazel build -c opt //tensorflow_serving/model_servers:tensorflow_model_server
$>bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server --port=9000 --model_name=mnist --model_base_path=/tmp/mnist_model/

 
コンパイルをスキップして apt-get を使用してインストールすることを好む場合には、ここの手順 を追ってください。それから次のコマンドでサーバを実行します :

tensorflow_model_server --port=9000 --model_name=mnist --model_base_path=/tmp/mnist_model/

 

Server をテストする

サーバをテストするためには提供されている mnist_client ユティリティが使用できます。クライアントは MNIST テストデータをダウンロードし、それらをサーバにリクエストとして送り、そして推論エラー率を計算します。

それを Bazel で実行するには :

$>bazel build -c opt //tensorflow_serving/example:mnist_client
$>bazel-bin/tensorflow_serving/example/mnist_client --num_tests=1000 --server=localhost:9000
...
Inference error rate: 10.5%

 
あるいは PIP パッケージをインストールした場合には、以下を実行します :

python tensorflow_serving/example/mnist_client.py --num_tests=1000 --server=localhost:9000

訓練された Softmax モデルに対して 91% 精度を期待します、そして最初の 1000 テスト画像に対して 10.5% 推論エラー率を得ます。これはサーバが訓練されたモデルを成功的にロードして実行することを確かめます!

 
以上


TensorFlow : Deploy : TensorFlow Serving : インストール

TensorFlow : Deploy : TensorFlow Serving: インストール (翻訳)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 09/01/2017

* 本ページは、TensorFlow 本家サイトの Deploy : TensorFlow Serving – Installation を翻訳した上で
適宜、補足説明したものです:

* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

要件

TensorFlow Serving をコンパイルして使用するためには、幾つかの要件をセットアップする必要があります。

Bazel (ソースコードをコンパイルする場合のみ)

TensorFlow Serving は Bazel 0.45 またはそれ以上を要求します。Bazel インストレーション手順は ここ で見つかります。

Bazel のための要件を満たす場合、それらの手順は次のステップから成ります :

  1. 関連したバイナリを ここ からダウンロードします。bazel-0.4.5-installer-linux-x86_64.sh をダウンロードしたとします。貴方は次を実行するでしょう :
    cd ~/Downloads
    chmod +x bazel-0.4.5-installer-linux-x86_64.sh
    ./bazel-0.4.5-installer-linux-x86_64.sh --user
    
  2. 環境をセットアップします。これを ~/.bashrc に置きます。
    export PATH="$PATH:$HOME/bin"
    

gRPC

チュートリアルは RPC フレームワークとして gRPC (1.0.0 またはそれ以上) を使用します。インストール手順は ここ で見つかります。

パッケージ

TensorFlow Serving 依存をインストールするためには、次を実行します :

sudo apt-get update && sudo apt-get install -y \
        build-essential \
        curl \
        libcurl3-dev \
        git \
        libfreetype6-dev \
        libpng12-dev \
        libzmq3-dev \
        pkg-config \
        python-dev \
        python-numpy \
        python-pip \
        software-properties-common \
        swig \
        zip \
        zlib1g-dev

TensorFlow Serving Python API PIP パッケージ

Bazel をインストールする必要なく Python クライアントコードを実行するためには、以下を利用して tensorflow-serving-api PIP パッケージをインストールすることができます :

pip install tensorflow-serving-api

 

apt-get を使用してインストールする

利用可能なバイナリ

TensorFlow Serving ModelServer バイナリは2つの変形 (= variant) で利用可能です :

tensorflow-model-server: 完全に最適化されたサーバで、SSE4 と AVX 命令のような幾つかのプラットフォームに特化されたコンパイラ最適化を使用しています。これは多くのユーザに好まれるオプションでしょう、しかしある(種の)より古いマシンでは動作しないかもしれません。

tensorflow-model-server-universal: 基本的な最適化でコンパイルされていますが、プラットフォームに特化された命令セットは含みませんので、世の中のすべてのマシンでないにしても殆どの上で動作するはずです。貴方のために tensorflow-model-server が動作しないのであればこれを使用してください。バイナリ名が両方のパッケージについて同じですので、既に tensorflow-model-server をインストールしているならば、次を使用して最初にそれをアンインストールするべきです。

sudo apt-get remove tensorflow-model-server

ModelServer をインストールする

  1. パッケージ・ソースとして TensorFlow Serving ディストリビューション URI を追加する (ワンタイム・セットアップ)
    echo "deb [arch=amd64] http://storage.googleapis.com/tensorflow-serving-apt stable tensorflow-model-server tensorflow-model-server-universal" | sudo tee /etc/apt/sources.list.d/tensorflow-serving.list
    
    curl https://storage.googleapis.com/tensorflow-serving-apt/tensorflow-serving.release.pub.gpg | sudo apt-key add -
    
  2. TensorFlow ModelServer をインストールして更新する
    sudo apt-get update && sudo apt-get install tensorflow-model-server
    

一度インストールされれば、バイナリはコマンド tensorflow_model_server を使用して起動されます。

tensorflow-model-server のより新しいバージョンへは次でアップグレードできます :

sudo apt-get upgrade tensorflow-model-server

Note: 上のコマンドにおいて、もし貴方のプロセッサが AVX 命令をサポートしてないのであれば、tensorflow-model-server を tensorflow-model-server-universal で置き換えてください。

 

ソースからインストールする

TensorFlow Serving レポジトリを clone する

git clone --recurse-submodules https://github.com/tensorflow/serving
cd serving

–recurse-submodules は TensorFlow, gRPC, そして TensorFlow Serving が依存する他のライブラリを取得するために必要です。これらの手順は TensorFlow Serving の最新の master ブランチをインストールすることに注意してください。(release ブランチのような) 特定のブランチをインストールすることを望む場合には、git clone コマンドに -b を渡してください。

要件をインストールする

全ての依存をインストールするためには上述の要件セクションに追随してください。TensorFlow を configure するためには、以下を実行します

cd tensorflow
./configure
cd ..

TensorFlow のセットアップやその依存の問題にぶつかったならば TensorFlow インストール手順 を調べてください。

ビルド

TensorFlow Serving はビルドに Bazel を使用します。個々のターゲットや全体のソースツリーをビルドするためには Bazel コマンドを使用します。

全体のツリーをビルドするためには、以下を実行します :

bazel build -c opt tensorflow_serving/...

バイナリは bazel-bin ディレクトリに置かれ、次のようなコマンドを使用して実行できます :

bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server

インストールをテストするためには、以下を実行します :

bazel test -c opt tensorflow_serving/...

TensorFlow Serving を実行するより掘り下げたサンプルについては basic tutorialadvanced tutorial を見てください。

最適化されたビルド

幾つかのプラットフォームに特化した命令セット (e.g. AVX) を使用してコンパイルすることができます、これは本質的にパフォーマンスを改善できます。このドキュメントで ‘bazel build’ を見る場所ではどこでも、フラグ -c opt –copt=-msse4.1 –copt=-msse4.2 –copt=-mavx –copt=-mavx2 –copt=-mfma –copt=-O3 (あるいはこれらのフラグの幾つかのサブセット) を追加することができます。例えば :

bazel build -c opt --copt=-msse4.1 --copt=-msse4.2 --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=-O3 tensorflow_serving/...

Note: これらの命令セットはすべてのマシン上で利用可能ではありません、特により古いプロセッサでは。そのためすべてのフラグでは動作しないかもしれません。それらのあるサブセットを試すか、基本的な ‘-c opt’ だけに戻すこともできます。

継続的インテグレーション・ビルド

TensorFlow ci_build インフラを使用した継続的インテグレーション・ビルドは docker を利用した単純化された開発を貴方に提供します。貴方の必要なものすべては git と docker です。すべての他の依存を手動でインストールする必要はありません。

git clone --recursive https://github.com/tensorflow/serving
cd serving
CI_TENSORFLOW_SUBMODULE_PATH=tensorflow tensorflow/tensorflow/tools/ci_build/ci_build.sh CPU bazel test //tensorflow_serving/...

Note: serving ディレクトリはコンテナ内にマップされます。貴方は docker コンテナの外側で (貴方のお気に入りのエディタで) 開発が可能でそしてこのビルドを実行する時、それは貴方の変更と一緒にビルドするでしょう。

 
以上


TensorFlow : Deploy : TensorFlow Serving : アーキテクチャ概要

TensorFlow : Deploy : TensorFlow Serving: アーキテクチャ概要 (翻訳)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 08/31/2017

* 本ページは、TensorFlow の本家サイトの Deploy : TensorFlow Serving – Architecture Overview を翻訳した上で
適宜、補足説明したものです:

* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

TensorFlow Serving は機械学習モデルのための柔軟で、高パフォーマンスなサービング・システムで、本番環境 (= production environments) のためにデザインされています。TensorFlow Serving は同じサーバ・アーキテクチャと API を保持したまま、新しいアルゴリズムと実験を配備することを簡単にします。TensorFlow Serving は TensorFlow モデルとの独創的な統合を提供しますが、他のタイプのモデルをサーブするために簡単に拡張できます。

 

キー・コンセプト

TensorFlow Serving のアーキテクチャを理解するためには、以下ののキー・コンセプトを理解する必要があります :

Servable

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

Servable のサイズや粒度 (= granularity) は柔軟です。単一の Servable は、単一のモデルへの検索テーブルの単一のシャードから推論モデルのタプルまで任意のものを含むかもしれません。

Servable は任意の型とインターフェイスから成ることができ、柔軟性と以下のような将来的な改良を可能にします :

  • ストリーミングの結果
  • 実験的な API
  • 演算の非同期モデル

Servable はそれら自身のライフサイクルは管理しません。

典型的な servable は次を含みます :

  • TensorFlow SavedModelBundle (tensorflow::Session)
  • embedding や語彙検索のための検索テーブル

Servable Version

TensorFlow Serving は、単一のサーバ・インスタンスの生存時間 (= lifetime) に渡り一つまたはそれ以上の servable の version を扱うことができます。これは新たなアルゴリズムの configuration、重み、そして他のデータが時間をかけてロードされることを可能にします。version は servable の一つ以上のバージョンが同時にロードされることを可能にし、段階的な (= gradual) ロールアウトと実験をサポートします。serving 時には、クライアントは特定のモデルに対して、最新バージョンか特定のバージョン id をリクエストできます。

Servable Stream

servable stream は servable の version のシークエンスで、増加する version ナンバーによりソートされます。

Model

TensorFlow Serving は model を一つまたはそれ以上の servable として表します。機械学習されたモデルは一つまたはそれ以上の (学習された重みを含む) アルゴリズムと検索または embedding テーブルを含みます。

composite model (合成モデル) は次のどちらかとして表すことができます :

  • 複数の独立した servable
  • 単一の composite servable

servable はまたモデルの断片 (= fraction) にも相当するかもしれません。例えば、巨大な検索テーブルは多くの TensorFlow Serving インスタンスに渡りシャードされるでしょう。

Loader

Loader は servable のライフサイクルを管理します。Loader API は特定の学習アルゴリズム、データまたは付随する製品ユースケースからは独立な共通インフラを可能にします。特に、Loader は servable をロードとアンロードするための API を標準化します。

Source

Source は servable を開始するプラグイン・モジュールです; 各 Source はゼロまたはそれ以上の servable stream を開始します。各 stream に対して、Source はロードすることを望んだ各 version のために一つの Loader を供給します。(正確に言えば、Source は実際にはゼロまたはそれ以上の SourceAdapter と一緒に連鎖していて、鎖の最後のアイテムが Loader を発行します。)

Source のための TensorFlow Serving のインターフェイスは単純で限定的ですので、ロードするための servable を探索するためには任意のストレージ・システムを貴方に使用させます。Source は RPC のような他のメカニズムにアクセスするかもしれません。TensorFlow Serving は共通のリファレンス Source 実装を含みます。例えば、TensorFlow Serving はファイルシステムをポーリングできます。

差分更新 (= delta update) を効率的に受け取るモデルのような特別なケースのために、Source は複数の servable または version に渡り共有される状態を保持することができます。

Aspired Version

Aspired version はロードされて準備されるべき servable version のセットを表します。Source は、単一の servable stream のための servable version のこのセットと同時に通信します。Source が Manager に aspired version の新しいリストを与えたとき、それはその servable stream のための以前のリストに取って替わります。Manager はもはやリストに現れない以前にロードされた version をアンロードします。

version ローディングが実際にどのように動作するかを見るためには advanced tutorial を参照してください。

Manager

Manager は Servable の完全ライフサイクルを処理し、以下を含みます :

  • Servable をロードする
  • Servable をサーブする
  • Servable をアンロードする

Manager は Source をリスンして全ての version を追跡します。Manager は Source のリクエストを実行しようとしますが、必要となるリソースが利用可能でない場合には aspired version のロードを拒否するかもしれません。Manager はまた “アンロード” を延期するかもしれません。例えば、少なくとも一つの version が常にロードされていることを保証するというポリシーをベースに、Manager は新しい vesion のロードが完了するまでアンロードを待つかもしれません。

TensorFlow Serving Manager は単純で、限定的なインターフェイス — GetServableHandle() — をロードされた servable インスタンスにアクセスするためにクライアントに提供します。

Core

TensorFlow Serving Core は (標準 TensorFlow Serving API を通して) servable の以下の局面を管理します :

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

TensorFlow Serving Core は servable と loader を opaque オブジェクトとして扱います。

 

Servable のライフ

大雑把に言えば :

  1. Source が Servable Version のために Loader を作成する。
  2. Loader は Aspired Version として Manager に送られ、これはそれらをクライアント要求にロードしてサーブします。

より詳細には :

  1. Source プラグインが特定の version のための Loader を作成します。Loader は Servable をロードするために必要などのようなメタデータも含みます。
  2. Source は Manager に Aspired Version を通知するためにコールバックを使用します。
  3. Manager は取るべき次のアクションを決定するために設定された Version Policy を適用します、これは以前にロードされた version のアンロードあるいは新しい version のロードかもしれません。
  4. Manager が安全であると決定した場合、それは Loader に必要なリソースを与え、Loader に新しい version をロードするように伝えます。
  5. クライアントは Manager に Servable を要求します、version を明示的に指定するか最新 version を単に要求するかです。

例えば、Source が頻繁に更新されるモデル重みを持つ TensorFlow グラフを表すとします。重みはディスクのファイルにストアされます。

  1. Source はモデル重みの新しい version を検出します。それはディスクのモデル・データへのポインタを含む Loader を作成します。
  2. Source は Dynamic Manager に Aspired Version を通知します。
  3. Dynamic Manager は Version Policy を適用して新しい version を決定します。
  4. Dynamic Manager は Loader に十分なメモリがあることを伝えます。Loader は TensorFlow グラフを新しい重みでインスタンス化します。
  5. クライアントはモデルの最新 version へのハンドルを要求し、そして Dynamic Manager は Servable の新しい version へのハンドルを返します。

 

拡張性

TensorFlow Serving は幾つかの拡張ポイントを提供します、そこでは貴方は新しい機能を追加することができます。

Version Policy

Version Policy は、単一の servable stream 内の version ローディングとアンローディングのシークエンスを指定します。

TensorFlow Serving は最も良く知られたユースケースに適合する2つの policy を含みます。これらは Availability Preserving Policy (version が一つもロードされないことを回避するため; 典型的には古いものをアンロードする前に新しい version をロードします) 、そして Resource Preserving Policy (2つの version が同時にロードされ、2倍のリソースが必要となることを回避します; 新しいものをロードする前に古い vesion をアンロードします) です。model の serving 可用性が重要でリソースが低コストであるTensorFlow Serving の単純な使用のために、 Availability Preserving Policy は、古いものをアンロードする前に新しい version がロードされて準備できていることを保証します。TensorFlow Serving の洗練された使用のためには、例えば複数のサーバ・インスタンスに渡る version を管理する時、 Resource Preserving Policy は最小のリソースを要求します(新しい version をロードするための余分なバッファなし)。

Source

新しい Source は新しいファイルシステム、クラウド製品 (= offerings) そしてアルゴリズム・バックエンドをサポートできます。TensorFlow Serving は新しい source を簡単に速く作成するために幾つかの共通のビルディング・ブロックを提供します。例えば、TensorFlow Serving は単純な source まわりのポーリング挙動ををラップするユティリティを含みます。Source は特定のアルゴリズムとデータ・ホスティング servable のための Loader に密接に関係しています。

詳しくはカスタム Source をどのように作成するかについての Custom Source 文書を見てください。

Loaders

Loader はアルゴリズムとデータ・バックエンドのための拡張ポイントです。TensorFlow はそのようなアルゴリズム・バックエンドの一つです。例えば、貴方は新しいタイプの servable 機械学習モデルのインスタンスをロードし、それへのアクセスを提供し、そしてアンロードするための新しい Loader を実装するでしょう。私たちは検索テーブルと追加アルゴリズムのための Loader を作成することを予期します。

カスタム servable をどのように作成するかを学習するためには Custom Servable 文書を見てください。

Batcher

複数のリクエストの単一のリクエストへのバッチングは本質的に推論の実行のコストを減少させることができます、特に GPU のようなハードウェア・アクセラレータが存在する場合です。TensorFlow Serving はリクエスト・バッチング・ウイジェットを含み、これはクライアントに、リクエストに渡る type-specific 推論を (アルゴリズム・システムがより効率的に扱える)バッチ・リクエストに簡単にバッチ化させます。更なる情報のためには Batching Guide を見てください。

 

Next Steps

TensorFlow Serving を始めるには、Basic Tutorial にトライしてください。

 
以上

TensorFlow : Deploy : Hadoop 上で TensorFlow をどのように実行するか

TensorFlow : Deploy : Hadoop 上で TensorFlow をどのように実行するか (翻訳/解説)
翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 03/30/2017

* 本ページは、TensorFlow の本家サイトの Deploy – How to run TensorFlow on Hadoop を翻訳した上で
適宜、補足説明したものです:
    https://www.tensorflow.org/deploy/hadoop
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

このドキュメントは Hadoop 上でどのように TensorFlow を実行するかを説明しています。様々なクラスタ・マネージャで実行することに記述は拡張されますが、当面は HDFS 上での実行についてのみ記述されます。

 

HDFS

貴方が データを読む について慣れ親しんでいることを前提にしています。

TensorFlow で HDFS を使用するためには、データを読み書きするために使用するファイルパスを HDFS パスに変更します。例えば :

filename_queue = tf.train.string_input_producer([
    "hdfs://namenode:8020/path/to/file1.csv",
    "hdfs://namenode:8020/path/to/file2.csv",
])

HDFS 構成ファイルで指定されたネーム・ノードを使用することを望むのであれば、ファイル・プレフィックスを hdfs://default/ に変更します。

TensorFlow プログラムを launch する時には、次の環境変数が設定されなければなりません :

  • JAVA_HOME: java インストールの位置。
  • HADOOP_HDFS_HOME: HDFS インストールの位置。以下を実行することでも環境変数を設定可能です :
    shell source ${HADOOP_HOME}/libexec/hadoop-config.sh
    
  • LD_LIBRARY_PATH: libjvm.so へのパス、そしてもし(貴方の)Hadoop ディストリビューションが libhdfs.so を $HADOOP_HDFS_HOME/lib/native にインストールしていない場合にオプションで libhdfs.so へのパスを含めるためです。Linux では :
    shell export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/jre/lib/amd64/server
    
  • CLASSPATH: TensorFlow プログラムを実行するに先立って Hadoop jars が追加されなければなりません。
    “${HADOOP_HOME}/libexec/hadoop-config.sh” で CLASSPATH を設定するだけでは不十分です。libhdfs ドキュメントに記載されているように Globs は拡張されなければなりません :

    shell CLASSPATH=$($HADOOP_HDFS_HOME}/bin/hadoop classpath --glob) python your_script.py 
    

    古いバージョンの Hadoop/libhdfs (older than 2.6.0) のためには、classpath ワイルドカードを手動で拡張する必要があります。より詳細は、HADOOP-10903 を参照してください。

Hadoop クラスタがセキュア・モードにあれば、次の環境変数が設定されなければなりません :

  • KERB_TICKET_CACHE_PATH: Kerberos チケット・キャッシュファイルのパス。例えば :
    shell export KERB_TICKET_CACHE_PATH=/tmp/krb5cc_10002
    

分散 TensorFlow を実行する場合には、全てのワーカーは環境変数が設定され Hadoop がインストールされていなければなりません。

 

以上


TensorFlow : Deploy : 分散 TensorFlow

TensorFlow : Deploy : 分散 TensorFlow(翻訳/解説)
翻訳 : (株)クラスキャット セールスインフォメーション
更新日時 : 09/16/2017
作成日時 : 04/16/2016

* 本ページは、TensorFlow 本家サイトの Deploy : Distributed TensorFlow を翻訳した上で
適宜、補足説明したものです:

* (obsolete) 本ページは、TensorFlow 本家サイトの以下のページを翻訳した上で適宜、補足説明したものです:
    https://www.tensorflow.org/versions/r0.8/how_tos/distributed/index.html
* サンプルコードの動作確認はしておりますが、適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 
本文

この文書は TensorFlow サーバのクラスタをどのように作成し、そのクラスタに渡って計算グラフをどのように分散するかを示します。TensorFlow プログラムを書く 基本コンセプト に慣れていることを想定しています。

 

Hello 分散 (distributed) TensorFlow!

このチュートリアルではあなたが TensorFlow nightly build を使用していることを想定しています。ローカル・サーバを次のように開始して使用することであなたのインストールをテストすることができます :

# TensorFlow サーバを単一プロセス「クラスタ」として開始します。
$ python
>>> import tensorflow as tf
>>> c = tf.constant("Hello, 分散 TensorFlow!")
>>> server = tf.train.Server.create_local_server()
>>> sess = tf.Session(server.target)  # サーバ上でセッションを作成します。
>>> sess.run(c)
'Hello, 分散 TensorFlow!'

tf.train.Server.create_local_server() (訳注: リンク切れ) メソッドは、in-process サーバで、単一プロセス・クラスタを作成します。

 

クラスタを作成する

TensorFlow「クラスタ」は、TensorFlow グラフの分散実行に参加する「タスク」の集合です。各タスクは TensorFlow「サーバ」と関係し、これはセッションを作成するために使用可能な「マスター」、そしてグラフにおける演算を実行する「ワーカー」を含みます。クラスタは一つまたはそれ以上の「ジョブ」にも分割されます、そこでは各ジョブは一つまたはそれ以上のタスクを含みます。

クラスタを作成するためには、クラスタ内でタスク毎に TensorFlow サーバ一つを開始します。各タスクは典型的には異なるマシン上実行されますが、同じマシンで複数のタスクを実行することもできます(e.g. 異なる GPU デバイスを制御するため等)。各タスクでは、次を行ないます :

  • tf.train.ClusterSpec を作成します、これはクラスタの全てのタスクを記述します。これは各タスクで同じであるべきです。
  • tf.train.Server を作成します、コンストラクタには tf.train.ClusterSpec を渡して、ジョブ名とタスク・インデックスでローカル・タスクを識別します。

クラスタを記述するために tf.train.ClusterSpec を作成する

tf.train.ClusterSpec コンストラクション

利用可能なタスク
tf.train.ClusterSpec({“local”: [“localhost:2222”, “localhost:2223”]})
/job:local/task:0
/job:local/task:1
tf.train.ClusterSpec({
    "worker": [
        "worker0.example.com:2222", 
        "worker1.example.com:2222",
        "worker2.example.com:2222"
    ],
    "ps": [
        "ps0.example.com:2222",
        "ps1.example.com:2222"
    ]})
/job:worker/task:0
/job:worker/task:1
/job:worker/task:2
/job:ps/task:0
/job:ps/task:1

各タスクで tf.train.Server インスタンスを作成する

tf.train.Server オブジェクトはローカル・デバイスの集合、tf.train.ClusterSpec における他のタスクへの接続 (connections) の集合、そして分散計算を遂行するためにこれらを使用できる「セッション・ターゲット」を含みます。各サーバは特定の名前のジョブのメンバーで、そのジョブ内のタスクインデックスを持ちます。サーバはクラスタにおける任意の他のサーバと通信可能です

例えば、 localhost:2222 と localhost:2223 上で動作する2つのサーバによるクラスタを起動するためには、ローカルマシン上で次のスニペットを2つの異なるプロセスで実行します :

# In task 0:
cluster = tf.train.ClusterSpec({"local": ["localhost:2222", "localhost:2223"]})
server = tf.train.Server(cluster, job_name="local", task_index=0)

# In task 1:
cluster = tf.train.ClusterSpec({"local": ["localhost:2222", "localhost:2223"]})
server = tf.train.Server(cluster, job_name="local", task_index=1)

[Note] これらのクラスタ仕様を手動で指定するのは長く退屈なものです、特に大規模クラスタに対しては。私たちはプログラミング的にタスクを起動するためのツールについてワークしています、e.g. Kubernetes のようなクラスタ・マネージャを使用します。サポートを望む特定のクラスタ・マネージャがある場合には、GitHub issue をあげてください。

 

モデルで分散デバイスを指定する

特定のプロセスに演算を配置するためには、ops を CPU か GPU で実行するかを指定するのに使用されるのと同じ tf.device() 関数をが使用できます。例えば :

with tf.device("/job:ps/task:0"):
  weights_1 = tf.Variable(...)
  biases_1 = tf.Variable(...)

with tf.device("/job:ps/task:1"):
  weights_2 = tf.Variable(...)
  biases_2 = tf.Variable(...)

with tf.device("/job:worker/task:7"):
  input, labels = ...
  layer_1 = tf.nn.relu(tf.matmul(input, weights_1) + biases_1)
  logits = tf.nn.relu(tf.matmul(layer_1, weights_2) + biases_2)
  # ...
  train_op = ...

with tf.Session("grpc://worker7.example.com:2222") as sess:
  for _ in range(10000):
    sess.run(train_op)

上の例では、変数は ps ジョブの2つのタスク上に作成され、そしてモデルの数値計算部はワーカー・ジョブで作成されます。TensorFlow はジョブ間に適当なデータ転送を挿入します(forward pass のためには ps からワーカーに、そして勾配の適用のためにはワーカーから ps に)。

 

レプリケーションされた (Replicated) 訓練

「データ並列性 (data parallelism)」と呼ばれる、一般的な訓練構成 (configuration) は同じモデルをデータ上の異なるミニ・バッチで訓練する、ワーカー・ジョブの複数のタスクを含み、ps ジョブにおける一つまたは複数のタスクにホストされる共有パラメータを更新します。全てのタスクは典型的には異なるマシン上で実行されます。TensorFlow でこの構造を指定するには多くの方法あり、レプリケーション・モデル (replicated model) を指定するワークを単純にするライブラリを構築しています。可能なアプローチは次のようなものです :

  • グラフ内 (In-graph) レプリケーション。このアプローチでは、クライアントは、(/job:ps に固定された tf.Variable ノードの) パラメータのワンセットを含む 単一の tf.Graph を構築します; そしてモデルの数値計算部の複数のコピーは、それぞれ /job:worker の異なるタスクに固定されます。
  • グラフ間 (Between-graph) レプリケーション。このアプローチでは、各 /job:worker タスクに対して分離したクライアントがあり、典型的にはワーカータスクとしての同じプロセス内にあります。各クライアントはパラメータを含む同様のグラフを構築します。(パラメータは同じように /job:ps に固定されてそれらを同じタスクに決定論的にマップするために tf.train.replica_device_setter() (訳注: リンク切れ) を使用します); そしてモデルの数値計算部の一つのコピーは、/job:worker のローカルタスクに固定されます。
  • 非同期 (Asynchronous) 訓練。このアプローチでは、グラフの各レプリカは、連携なし (w/o coordination) に実行される独立的な訓練ループを持ちます。上のリプリケーション形式の両者と互換性があります。
  • 同期 (Synchronous) 訓練。このアプローチでは、全てのレプリカは 現在のパラメータについて同じ値を読み、並列に勾配を計算し、そしてそれらを一緒に適用します。これは in-graph リプリケーションと互換で(e.g. CIFAR-10 マルチ-GPU トレーナー 内のように勾配平均を使用)、そして between-graph レプリケーションと互換です(e.g. tf.train.SyncReplicasOptimizer を使用)。

まとめ: サンプル・トレーナー・プログラム

次のコードは分散トレーナー・プログラムのスケルトンを示し、between-graph リプリケーションと非同期訓練を実装しています。これはパラメータ・サーバとワーカー・タスクのためのコードを含みます。

import tensorflow as tf

# tf.train.ClusterSpec を定義するためのフラグ
tf.app.flags.DEFINE_string("ps_hosts", "",
                           "Comma-separated list of hostname:port pairs")
tf.app.flags.DEFINE_string("worker_hosts", "",
                           "Comma-separated list of hostname:port pairs")

# tf.train.Server を定義するためのフラグ
tf.app.flags.DEFINE_string("job_name", "", "One of 'ps', 'worker'")
tf.app.flags.DEFINE_integer("task_index", 0, "Index of task within the job")

FLAGS = tf.app.flags.FLAGS


def main(_):
  ps_hosts = FLAGS.ps_hosts.split(",")
  worker_hosts = FLAGS.worker_hosts(",")

  # パラメータ・サーバとワーカー・ホストからクラスタを作成します。
  cluster = tf.train.ClusterSpec({"ps": ps_hosts, "worker": worker_hosts})
  
  # ローカル・タスクのためのサーバを作成して開始します。
  server = tf.train.Server(cluster,
                           job_name=FLAGS.job_name,
                           task_index=FLAGS.task_index)

  if FLAGS.job_name == "ps":
    server.join()
  elif FLAGS.job_name == "worker":

    # デフォルトで ops をローカル・ワーカーに割り当てます。
    with tf.device(tf.train.replica_device_setter(
        worker_device="/job:worker/task:%d" % FLAGS.task_index,
        cluster=cluster)):

      # モデルを構築します...
      loss = ...
      global_step = tf.Variable(0)

      train_op = tf.train.AdagradOptimizer(0.01).minimize(
          loss, global_step=global_step)

      saver = tf.train.Saver()
      summary_op = tf.merge_all_summaries()
      init_op = tf.initialize_all_variables()

    # 「スーパーバイザ」を作成します、これは訓練プロセスを監視します。
    sv = tf.train.Supervisor(is_chief=(FLAGS.task_index == 0),
                             logdir="/tmp/train_logs",
                             init_op=init_op,
                             summary_op=summary_op,
                             saver=saver,
                             global_step=global_step,
                             save_model_secs=600)

    # スーパーバイザはセッション初期化をケアしてチェックポイントから復旧します。
    sess = sv.prepare_or_wait_for_session(server.target)

    # 入力パイプラインに対してキュー・ランナーを開始します(もしあれば)。
    sv.start_queue_runners(sess)

    # スーパーバイザがシャットダウンするまでロープします(あるいは 1000000 ステップが完了するまで)。
    step = 0
    while not sv.should_stop() and step < 1000000:
      # 訓練ステップを非同期に実行します。
      # *同期* 訓練をどのように遂行するかについての追加の詳細情報は `tf.train.SyncReplicasOptimizer` を参照。
      _, step = sess.run([train_op, global_step])


if __name__ == "__main__":
  tf.app.run()

2つのパラメータ・サーバと2つのワーカーでトレーナーを開始するには、次のコマンドラインを使用します(スクリプトは trainer.py とします) :

# On ps0.example.com:
$ python trainer.py \
     --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
     --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
     --job_name=ps --task_index=0
# On ps1.example.com:
$ python trainer.py \
     --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
     --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
     --job_name=ps --task_index=1
# On worker0.example.com:
$ python trainer.py \
     --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
     --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
     --job_name=worker --task_index=0
# On worker1.example.com:
$ python trainer.py \
     --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
     --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
     --job_name=worker --task_index=1
 

用語集

[クライアント]
クライアントは典型的には、TensorFlow グラフを構築してクラスタと相互作用するために `tensorflow::Session` をコンストラクトするプログラムです。クライアントは典型的には Python または C++ で書かれます。単一のクライアント・プロセスは複数の TensorFlow サーバと直接的に相互作用可能です(上の「リプリケーション訓練」を参照)、そして単一のサーバは複数のクライアントにサービスが提供できます。

[クラスタ]
TensorFlow クラスタは一つまたはそれ以上の「ジョブ」から成り、それぞれは一つまたはそれ以上の「タスク」のリストに分割されます。クラスタは典型的には、多くのマシンを並列に使用してニューラルネットワークを訓練するような、特定の高位レベルの目的に貢献 (dedicated) します。クラスタは `tf.train.ClusterSpec` オブジェクトで定義されます。

[ジョブ]
ジョブは、典型的には共通の目的のためにサービスを提供する、「タスク」のリストから成ります。例えば、`ps` (「パラメータ・サーバ (parameter server)」)と命名されるジョブは典型的には変数をストアして更新するホスト・ノードです; 一方、`worker` と命名されるジョブは典型的には数値計算タスクを遂行するホスト・ステートレス・ノードです。ジョブのタスクは典型的には異なるマシン上で実行されます。ジョブのセットの役割は柔軟です: 例えば、ある `worker` はある状態を維持するかもしれません。

[マスター・サービス]
RPC サービスで、分散デバイスのセットへのリモート・アクセスを提供し、セッション・ターゲットとして動作します。マスター・サービスは tensorflow::Session インターフェイスを実装し、そして一つまたはそれ以上の「ワーカー・サービス」に渡るワークをコーディネートする責任があります。全ての TensorFlow サーバはマスター・サービスを実装します。

[タスク]
タスクは特定の TensorFlow サーバに該当し、そして典型的には単一のプロセスに該当します。タスクは特定の「ジョブ」に属してジョブのタスクリストのインデックスで識別されます。

[TensorFlow サーバ]
tf.train.Server インスタンスを実行するプロセスで、クラスタのメンバーで、そして「マスター・サービス」と「ワーカー・サービス」をエクスポートします。

[ワーカー・サービス]
RPC サービスで、ローカルデバイスを使用して TensorFlow グラフの一部を実行します。ワーカー・サービスは worker_service.proto を実行します。全ての TensorFlow サーバはワーカー・サービスを実装します。

 

以上

AI導入支援 #2 ウェビナー

スモールスタートを可能としたAI導入支援   Vol.2
[無料 WEB セミナー] [詳細]
「画像認識 AI PoC スターターパック」の紹介
既に AI 技術を実ビジネスで活用し、成果を上げている日本企業も多く存在しており、競争優位なビジネスを展開しております。
しかしながら AI を導入したくとも PoC (概念実証) だけでも高額な費用がかかり取組めていない企業も少なくないようです。A I導入時には欠かせない PoC を手軽にしかも短期間で認知度を確認可能とするサービの紹介と共に、AI 技術の特性と具体的な導入プロセスに加え運用時のポイントについても解説いたします。
日時:2021年10月13日(水)
会場:WEBセミナー
共催:クラスキャット、日本FLOW(株)
後援:働き方改革推進コンソーシアム
参加費: 無料 (事前登録制)
人工知能開発支援
◆ クラスキャットは 人工知能研究開発支援 サービスを提供しています :
  • テクニカルコンサルティングサービス
  • 実証実験 (プロトタイプ構築)
  • アプリケーションへの実装
  • 人工知能研修サービス
◆ お問合せ先 ◆
(株)クラスキャット
セールス・インフォメーション
E-Mail:sales-info@classcat.com