はじめに

今は2020年8月なのですが、コロナ禍だし、暑いし、経済状況最悪で暇だし、良いことないですね。

暇になったので、1年ぶりにkaggleをやってみました。

Landmark Retrievalという建物の画像検索コンペに出たところ、そのコンペの提出形式がTensorFlowのSavedModel形式でした。

私はTensorFlow案件をけっこうやってきたので抵抗はなかったのですが、この制約が原因となったのか、あまりこのコンペの参加者は多くなかったようです。

kaggleの提出形式としては賛否両論あると思いますが、実務ではとても便利な形式だと私は思っています。

それなのにもし実務でも敬遠されているとしたらもったいないと思い、この記事ではSavedModelの便利さについて紹介してみます。

ちゃんとした使い方は公式リファレンスを当たってもらうとして、概念やsaved_model_cliの活用方法をお伝えするのを主眼に置いています。

このモデルに画像を入力するとエラーが出ちゃったんだけどどうすればいいの？入力サイズを教えて？あ、あとフォーマットはuint8でいいんだっけ？
今設計を考えているんだけど、このSavedModelの出力ってどういう形式なんだっけ？

これに毎回回答するのも大変だし、モデルのreadmeに毎回過不足なく必要な情報を残しておくのを人力に頼ると記入漏れなどのミスが起きそうで嫌ですよね。

そんなときに便利なのがsaved_model_cliです。

saved_model_cliについて

saved_model_cliとは、TensorFlowが公式でサポートしている、SavedModelの中身をチェックするためのcliツールです。

TensorFlowをインストールする際に自動でついてきているので、実はTensorFlowが入っている環境下であればすぐに使うことができます。

色々使い方はあるのですが、最も単純な使い方だけ説明します。

saved_model_cli show --dir <SavedModelのパス> --all

とコマンドを打つと、以下のようなモデルについての情報が出力されます。(これは前述kaggleコンペの私のモデルの情報です)

signature_def['serving_default']:
  The given SavedModel SignatureDef contains the following input(s):
    inputs['ts_image'] tensor_info:
        dtype: DT_UINT8
        shape: (-1, -1, 3)
        name: serving_default_ts_image:0
  The given SavedModel SignatureDef contains the following output(s):
    outputs['global_descriptor'] tensor_info:
        dtype: DT_FLOAT
        shape: (1536)
        name: StatefulPartitionedCall:0
  Method name is: tensorflow/serving/predict
…

これにより、以下のような情報がわかります。

入力
- 入力はひとつ
- 入力画像のshapeが(-1, -1, 3)
- データ型はuint8
出力
- 出力もひとつ
- 出力ベクトルのshapeが(1536)
- データ型はfloat

メリット

イントロの気持ちに戻ってみてください。

他のエンジニアからモデルについての質問が多く、生産性が下がっている状態です。

そんな時は、モデルについての情報を毎回他のエンジニアに伝えるのではなく、saved_model_cliの存在を教えて、「その情報はsaved_model_cliを叩けばわかりますよ」と返すのはいかがでしょうか。

私は前の現場でそのような形でsaved_model_cliを広めまくっていたのですが、段々と浸透してくると不要なやり取りが減り、組織としてハッピーになったと思っています。

この生産性向上が最大のメリットと感じています。

また、readmeを毎回モデル作成時に書く運用でも理論上はOKなのですが、readmeを更新し忘れてしまうとモデルの説明とモデルに齟齬が生まれ、余計なコストがかかってしまいます。

簡単に・確実にモデルの中身をチェックできるという意味でも、SavedModel + saved_model_cliのメリットは大きいです。

TensorFlow Servingで簡単にデプロイできる

TensorFlow Servingとは、SavedModelを指定して起動するとそのモデルをAPI化してくれるシステムです。

以下のような特長があります。

パフォーマンスが優れている
http / grpc両対応
モデルのバージョニングができる

このTensorFlow Servingを活用することにより、SavedModelを簡単にデプロイすることができます。

SavedModel + TensorFlow Servingで手軽に高機能のデプロイが実現できるところも、また大きなメリットと感じています。

SavedModel使い方リンク集

ここまでで世の中にまとまっていない情報は大体書ききったので、後は先人の記事に任せてみます。

official

Using the SavedModel format | TensorFlow Core

Serving a TensorFlow Model | TFX

unofficial

SavedModelについてのまとめ - Qiita

TensorFlow2.0時代のTensorFlow Serving向けモデル出力 | AI tech studio

TensorFlow Servingで機械学習モデルをプロダクション環境で運用する - freee Developers Blog

おわりに

ここまで紹介したように、SavedModelはかなり運用に向いている形式であると感じています。

TensorFlowで学習したモデルをデプロイする時は、有力な選択肢として考えるとよいのではないかと思います。

余談ですが、TensorFlow-SavedModel-Tensorflow Servingの関係は、PyTorch-ONNX-ONNX Runtime Serverの関係と似ています。

個人的にモデル作成しやすいのはPyTorchなのでこちらも魅力的に思っています。

しかし、Tensorflow→SavedModelの変換は(個人的な経験では)100%成功するのに対し、PyTorch→ONNXの変換はまだ完全にうまくは行かないという認識です。

そのためモデルの精度要件が緩めで運用の要件が厳しめだったらTensorFlowを採用するのもアリかな、と思っています。

ここらへんの私の考えに甘さがある場合、コメントにてご指摘いただければ嬉しいです。以上です。

生き抜くぜ21世紀

統計？機械学習？っぽいことを書く

TensorFlowのSavedModelの便利さを紹介する

はじめに

目次

SavedModelとは

SavedModelの何が便利なのか

学習環境と推論環境でのソースコードの二重管理が防げる

saved_model_cliを活用することで、ネットワークのin/outを楽に・確実に確認することができる

イントロ