いまMLKitカスタムモデル(TF Lite)は使えるのか
この記事はTensorFlow Advent Calendar 2018の23日目がぽっかり空いたので、ねじ込む予定が別の方が滑り込んでしまったので、作成した記事が宙に浮いてしまい、空いていた22日に今日が23日にもかかわらず押し込んだ記事です。
つまりTF Advent Calendar2018の22日目の記事です。
ビデオ判定が導入された昨今のスポーツ界では完全にアウトなやつですが、まぁいいよね。
おはこんばんちわ、カブク合宿ブログ担当<sup>1</sup>の足立です。
先日、Google Developers ML Summitというイベントで「モバイル開発者の為のTensorFlow」という発表をさせていただきました。
TensorFlowをエッジ環境で動作させるTensorFlow Lite(以下TF Lite)の仕組みとその実装方法が主な説明です。
TF Liteの仕組み(量子化などの最適化を含む)により機械学習モデルを削減でき、性能も向上させられるという内容です。
この資料ではオフィシャルで公開されているデータを元に説明しましたが、エンジニアにとって大事なのは実際のデータ。
ということで、現時点(2018年末)でのモバイル端末で、TF Liteがどれぐらい使い物になるのかを検証してみました。
より実践的な評価となるよう、Google Cloud NEXT '18 San FranciscoのAI in motion<sup>3</sup>というロボットゲーム展示で使ったObject Detectionを活用したAndroidアプリで評価します。
評価環境
端末
「まえ」と比較することで「いま使えるのか」を評価します。
+ Google Pixel2<sup>2</sup>: Qualcomm Snapdragon 835 / Adreno 540 / Hexagon 682
+ Google Pixel3: Qualcomm Snapdragon 845 / Adreno 630 / Hexagon 685
※いずのOSもAndroid 9.0
評価プログラム
- 機械学習モデル: MoblieNet_V2_1.0_224のObject Detection
※INT8で量子化しています - SDK
- AAR: TensorFlow Lite AAR
- MLKit: Firebase ML Model Interpreter 15.0
※MLKitはカスタムモデル(TF Lite)をローカルに配置して実行
AARの評価方法は以下の通り。
long start = System.currentTimeMillis();
tflite.runForMultipleInputsOutputs(inputs, outputs);
long end = Systen.currentTimeMillis();
Log.d(TAG, (end - start));
MLKitは以下のようにして評価。
long start = System.currentTimeMillis();
mInterpreter.run(inputs, options)
.addOnSuccessListener(
new OnSuccessListener<>() {
public void onSuccess(FirebaseModelOutputs result) {
long end = Systen.currentTimeMillis();
Log.d(TAG, (end - start));
}
});
図1. 実際にObject Detectionしている画面
評価結果
各端末・SDKでObject Detectionをそれぞれ10回を実施した平均の性能を表に示します。
端末 | SDK | Performance |
---|---|---|
Pixel2 | AAR | 87ms |
Pixel2 | MLKit | 104ms |
Pixel3 | AAR | 46ms |
Pixel3 | MLKit | 50ms |
Pixel2よりPixel3の性能が大幅に向上。
Pixel2ではAARに比べてMLKitは約20%の性能劣化。
Pixel3ではAARに比べてMLKitは約10%の性能劣化。
考察
Pixel2に比べてPixel3は性能が約2倍。AI性能が3倍というハードの進化はどうやら伊達じゃないらしい。
AARに比べてMLKitがいずれも性能劣化しているが、これはAndroid SDKデザインに沿ってMLKitが非同期になっている点が大きいと考えられる。
Android SDKはMainスレッド(UIを司るスレッド)をできるだけ止めないよう、あらゆる処理を非同期化するように推奨されている。
非同期SDKも多く準備されており、”Androidらしいプログラム”は適切に非同期処理が組み込まれている。
AARはJNI丸出しの実行方式で"Androidらしくない"代わりに高い性能を得られていると考えられる。
Pixel2に比べてPixel3のほうがMLKitの性能劣化が少ないのはCPUクロック数がPixel3の方が高いなどハードスペック差が効いていそう。
結論
2018年のフラッグシップAndroid端末はPixel3と同じSnapdragon 845(Snapdragon使っていない端末も沢山ありますが…)。
このハイエンド端末で約20fpsでObject Detectionを実行できることが分かった。
これは概ね「使える」性能だと言って良いと思う。
ただ、動体などを扱う場合はその移動速度によってはまだ厳しいかもしれない。
一年前のフラッグシップ端末(Snapdragon 835相当)では約10fpsであり、この場合は動体がかなり厳しかった<sup>4</sup>ことを考えると、いよいよ使える時代が来たと言っても良さそう。
すでに次世代プロセッサのSnapdragon 855が発表されており、2019年のハイエンド端末にはコレが搭載されることは間違いない。
Snapdragon 845にくらべて2倍のAI性能と謳われているため、2019年はモバイル端末上で機械学習モデルを「十分使える」レベルで動かせる年になりそう<sup>5</sup>。
おわりに
Advent Calendarに穴が空いているとはいえ、一日遅れで押し込んでしまって本当に良かったのかなぁ…。
弊社カブクではエッジ環境やクラウド環境で機械学習をプロダクション適用したいというエンジニアや実課題に機械学習(もしくは他の手法)を適用してみたいという機械学習エンジニアを募集しています。
おまけ
MLKitカスタムモデルのSDKは今のところ非同期APIだけしか提供されていない。
Cloud NEXTのAI in motionではObject Detectionで環境認識して、各ロボット(エージェント)の行動をDQNで決定するため、2つのモデルを動かす必要があった。
こういった複数モデルをシーケンシャルに実行する必要がある場合、非同期callbackがネストしてツラい。
ネストしないようクラスを分けてホゲホゲみたいな話も分かる。分かるよ。でもそうじゃない。
アッチの世界とコッチの世界を行ったり来たりさせたくないんですよ。
当然、性能もモデル実行数に比例して悪くなるし。
今年一年、良い子にしていたのでMLKitのSDKに同期APIをください。
あだむ
注釈
- カブクでは年2回、春と秋に有志で一泊二日の合宿をしています。2016秋、2017春、2017秋、2018春
- Pixel2は技適が通っていないので電波暗室か通信許可のある諸外国で評価を実施してくれよな!約束だぞ!
- カブクが技術協力させてもらったブース。Google Cloud NEXT '18 Tokyoも同じブース展示をしましたが、技適の問題で技適の通ってる端末を使ったが、性能が一段劣化してツラミ成分が2割増。
- Google Cloud NEXT '18 San FranciscoではPixel2を使っていた。動くロボットをObject Detectionする必要があり、性能が追いつかずロボットの動きが速すぎると衝突判定などで判定ミスがありゲーム性を損ねるシーンが何回もあった。さらにデモのため端末画面をVysorというソフトでTVディスプレイにキャストする必要があり、これが性能を15〜20%ほど劣化させツラかった。
- Raspberry PiにEdge TPUをUSB接続してObject Detetionを実効するデモでは、6ms(166fps!)で物体認識できていたのでエッジ環境での機械学習の導入は意外と近い未来かもしれない。
その他の記事
Other Articles
関連職種
Recruit