Flask + Tensorflow + Keras で モデルからのpredictが動作しない問題

機械学習ライブラリを使ったPredictなAPI開発

WebサービスでAIを活用する場合、多くはmicroservices的にVPC内にAPIを独立してデプロイし、インターナルに利用することが増えてきた。ことChainerやTensorflowといった機械学習系のライブラリは、その歴史的背景や数学ライブラリからPythonと相性がよいため、必然的にPythonのWAFを選択することになる。

pythonでmicroservicesなAPIでのWAF

PythonでWebアプリケーションを開発するには、WAFとしてDjango,Flaskの二大巨頭が台頭しているが、概ねシンプルな推論のAPI開発にDjangoは大して冗長であって、Flask辺りがつかっていて小気味良い。

マルチスレッドにおけるモデルデータの参照問題

Tensorflowにしろ、Chainerにしろ、APIでの推論は、機械学習の成果として得られるモデルの読み込みが必要になる。
Tensorflow + Keras では、 サーバ起動時に事前にモデルをメモリに展開し、グラフを構築しておく。リクエスト時にはそれを利用する形になる。

この時、マルチスレッドで動作していると、構築されたグラフのスレッドとは別のスレッドでリクエストを受け付けることになるので、グラフをスレッド間で共有する必要がある

global thread:

        self.model = load_model(model_path)
        self.model._make_predict_function()
        self.graph = tf.get_default_graph()

another thread:

        with self.graph.as_default():
            labels = self.model.predict(data)

• see also : https://github.com/fchollet/keras/issues/2397

サーバレスアーキテクチャにおけるTensorflowの利用

昨今流行りのサーバレスであるが、GCP Cloudfunctionはそもそもnodejsしか使えないので除外、 AWS Lambdaが選択肢となる。

Tensorflowガンガン肥大していくが、学習はともかく認識時に必要最低限のモジュールだけを切り出したい

— ふわこ (@yurfuwa ) 2017年11月8日

このようなニーズがある。しかしAWS Lambdaには 50MB制限というのがあり、ひとつのLambda関数においての容量制限が厳しい。

ServerlessでTensorflowやろうと躍起になってたんですが、tensorflowどころかnumpyやらscipyやらが既に重すぎてaws lambdaで死ぬし、.soをstripしたり.pyc消しても焼け石に水だった

— ふわこ (@yurfuwa ) 2017年10月26日

素直にサーバーレスは諦めて、GCP AppEngineあたりで手を打つのが打倒っぽい。
AWSさん、なんとかなりませんか、これ。

Comments

[yurfuwa]

アプリ層の推論ユースからPyTorchを見ると、鯖で学習済みモデルの展開を含めた起動が高速な利点はあります。Tensorflowはともかく起動がもたつく上に、推論ユースでは使わないモジュールが多すぎるので切り出したい。 t.co/F9agOi4rsP

— ゆるふわ (@yurfuwa ) February 27, 2018