AWS Startup ブログ

【開催報告】ML@Loft #4 (Edge)

こんにちは、スタートアップソリューションアーキテクトの針原 (Twitter: @_hariby) です。7月19日に AWS Loft Tokyo で開催された機械学習のコミュニティイベント ML@Loft の第4回では Edge Deep Learning をはじめとした技術についての話が盛り上がりました。興味はあったけど予定が合わなかった、という方のために内容をまとめたいと思います。

ML@Loft は機械学習のお悩み相談イベントで、目黒の AWS Loft Tokyo で2019年4月より毎月開催されています。もともとは AWS をお使いのお客さまが、サービスの中に機械学習を取り入れて開発・運用していく際のお悩を気軽に相談できる場が欲しい、ということで始まったイベントです。登壇者 (相談役) が自己紹介を兼ねた10分ほどの Lightning Talk を順番に行った後、テーブルに分かれて具体的な相談・ディスカッションを行う、という二部構成で開催されています。過去の様子は登壇者のスライド付きでブログにまとまっています [#1(MLOps), #2(MLOps), #3(Recommendation)]。

毎回参加者の希望をもとにテーマを決めていて、第4回目となる今回のテーマは Edge Deep Learning、すなわち電力供給が限られていたり、非力なプロセッサーしかない環境を前提とした機械学習について話しあう会となりました。今回登壇をお願いした4名は、加藤 倫弘 氏 (株式会社ディー・エヌ・エー)、竹村 幸尚 氏 (インテル株式会社)、 三好 健文 氏 (わさらぼ合同会社 / 株式会社イーツリーズ・ジャパン)、岡田 真太郎 氏 (株式会社Preferred Networks)、といった、エッジでの機械学習に深い知見と経験のある方々です。

LT セッション

それではセッションの内容を振り返ってみましょう。それぞれスライドも公開されているのでチェックしてみて下さい。

「エッジxクラウドの機械学習システムを、どう考えて開発しているか」加藤 倫弘 氏 (株式会社ディー・エヌ・エー; Twitter: @_tkato_)

ドライブレコーダー上で Deep Learning の推論を行い、安全運転に役立てるというようなサービスを構築されている加藤さんから、エッジを含む ML 開発における課題について。エッジに乗せる前提のモデルを設計し、クラウドで学習させ、エッジにデプロイされてきた経験をお話し頂きました。まずエッジでのリソースの制約という課題に対しては、モデル自体の軽量化、Deep Learning フレームワークの選定、実装するプログラミング言語の選定、クラウドに送る前にどこまでをエッジでやるか、といった観点でのアプローチが考えられます。
課題1: モデルの軽量化には様々な手段がありまずが、日々多くの論文で様々な手法が提案される中でどれを使えばいいか、論文で報告されているような精度を保ったモデルの軽量化を達成するにはどうすればいいか、試行錯誤を続けられています (過去の登壇資料などスライドにリンクがあります)。軽量化の手法には色々ありますが、元々軽量なネットワークをベースに Channel Pruning [1] により軽量化する手法が流行っているそうです。実装は Distiller (PyTorch), ChainerPruner (Chainer, PyTorch) など。精度向上のためにはモデルだけでなくデータやタスクの工夫も重要とのことです。学習からデバイスでの検証までの試行錯誤を効率化するためのツールとして Amazon SageMaker Neo にも⾔及されました [2]。
課題2: エッジで動かす際にも速く動くフレームワークを選ぶ必要があります。バックエンドの実装を見てどういうターゲットデバイス向けに最適化されているかなどを確認します。もちろんエッジで動かすことを見据えて、使いたい Operator がサポートされているフレームワークを選ぶ必要があります。
課題3: デバイスの都合で Python が使えず C/C++ などの実装が要求される場合もあり、基本方針としては Python で研究開発しその後 C/C++ や Rust へ移植しているそうです。移植のしやすさから xtensor (C++) や ndarray (Rust) といったライブラリを活用しているそうです。
課題4: デバイスを含んだ ML パイプラインは複雑度が増し、テストが難しいという課題があります。 テストを効率良く実装して大規模に実施するために、エッジ実装は Python でラップしてテストしやすくし、AWS CodeBuild などを用いてクラウド側でテストをされているそうです。

[1] https://www.slideshare.net/ren4yu/ss-149196060/20; Yihui He, Xiangyu Zhang, Jian Sun, The IEEE International Conference on Computer Vision (ICCV), 2017, pp. 1389-1397; 補足: Channel Pruning は各層のチャネル数を減らして CNN を軽量化する手法。チャネル選択 (NP-hard) をこの論文では LASSO (L1 正則化) に緩和して行う。選ばれたチャネルからフィルターの重みをアップデート (再構成する際の二乗誤差を最小化)、アップデートされた重みを元にチャネルを選択し直す、を交互に繰り返す。これにより VGG-16 (Channel Pruning とテンソル分解), ResNet などに対してわずか0.3%, 1.4%の精度劣化でそれぞれ5倍, 2倍の高速化を実現。
[2] https://aws.amazon.com/jp/blogs/news/amazon-sagemaker-fes-3/

「FPGAを用いたEdge AIの現状」竹村 幸尚 氏 (インテル株式会社)

資料: FPGAを用いたEdge AIの現状

続いて竹村さんからは FPGA をはじめとした Edge AI の現状やその選択肢についてご紹介頂きました。Intel は低コストからハイエンドまで FPGA のラインナップを提供しています。日本では低コストな FPGA を使った機械学習のニーズも多いですが、実際はリソースの制約からミドルクラスの Intel Arria 10 FPGA がよく使われるそうです。エッジ推論のためには Intel OpenVINO というモデル最適化のためのツールキットが提供されています。OpenVINO を使うと一つの推論コードを様々な Intel デバイス上で実行することができます。OpenVINO の中には OpenCV, OpenVX といったライブラリの他に、Deep Learning Deployment Toolkit と呼ばれるものが実装されており、モデル最適化・推論エンジンが含まれています。Caffe, TensorFlow, MXNet, ONNX のモデルを入力として、モデルオプティマイザーが中間表現を作り、それを各ターゲットデバイス (CPU/GPU/FPGA/Myriad) 向けに最適化します。また、よく使われるデバイスとして Intel Arria 10 のボードを搭載した TANK というものを監視カメラソリューションとともに紹介して頂きました。OpenVINO 以外の例として、LeapMind株式会社による Terasic DE10-Nano (Intel Cyclone V SoC を搭載) の例や、分電盤に Intel Cyclone V を乗せて AWS の IoT サービスと繋げる例 [3] を紹介して頂きました。

[3] https://aws.amazon.com/blogs/apn/creating-energy-iot-solutions-using-intel-soc-fpga-devices-and-aws-services/

「エッジデバイスの実利用環境を考慮した機械学習システム構築のあれこれ」三好 健文 氏 (わさらぼ合同会社 / 株式会社イーツリーズ・ジャパン)

資料: Misc for edge_devices_with_fpga

三好さんからは実利用環境におけるエッジデバイスの制約・課題、特にバッテリー・計算資源についてと FPGA がそれらをどう解決するかについて話して頂きました。一口にエッジで推論と言っても様々なデバイスがあります。SoC (RISC-V + KPU + uPython) で顔認識、SeeDot + Arduino IDE や FPGA で手書き文字認識など色々な事例を見せて頂きました。エッジで機械学習はこのように色々できますが、実際はエッジ側で完結することも少なくそれらがクラウドにつながる構成が多くなります。電源管理・計算資源不足など色々課題はありますが、キーワードは FPGA です。
話題1: エッジで機械学習というと多くの場合推論だけですが、予めクラウド側でモデルの学習が必要で、そのためにはデータを収集することが必要です。すると必然的にエッジとクラウドの通信が発生します。エッジ側ではビット・バイトレベルでのデータ表現・圧縮を行いたい一方、クラウド側では簡単にデータを扱いたいという要求が出てきます。例えば多くのデバイスを扱うためクラウド側でデバイスごとの処理が必要な状況で、C 言語などで分岐させる代わりにデバイスごとの命令をメモリから読んで演算を行うアーキテクチャを FPGA 上に構成するとスループットが稼げる場合がある、という話を紹介して頂きました [4]。
話題2: 組み込み向けの電源としては必要な時に必要な電力が供給できれば良いですが、電源管理が問題となります。そこで待機電力が少なく、電源 On ですぐ起動する FPGA を使うことが選択肢として上がってきます。太陽光パネルやバッテリー/電気二重層キャパシタ [5] により電源供給を行うエッジ FPGA デバイスをスポーツアクティビティ支援 (選手がどこを走ってるかトラッキング) から試されているそうです。なおリチウムイオン電池は放電容量 (放電時間) がある一定の値を超えると急激に電圧が降下するため [6]、エッジデバイスの電源として用いる際は注意が必要です。
話題3: FPGA というと必ずしもハードウェア記述言語 (VHDL, Verilog HDL など) を書かないといけないわけではなく、手軽に FPGA を始めるために今なら Python, Scala, C++, Java, Go, Rust などで開発が可能で、サーバーとの連携も簡単になっています。Amazon EC2 F1 インスタンスだと SDAccel (Xilinx が提供する IDE) で C/C++ での開発が可能で、Host CPU から OpenCL で FPGA を簡単に呼び出すことも可能です。また Java で FPGA が書ける Synthesijer というコンパイラも開発されています。
まとめると、エッジデバイスで機械学習をする場合には、(推論以外はクラウドを使うことになると思うので) サービス全体の設計が必要。実際にデバイスの面倒はどこまで見ればいいのか、FPGA やりたいけど何から始めればいいのか、は後半のディスカッションタイムで。

[4] https://www.ieice.org/ken/paper/20190131D1JV/
[5] https://jp.rs-online.com/web/generalDisplay.html?id=ideas-and-advice/electric-double-layer-capacitors-guide
[6] http://www.baysun.net/ionbattery_story/lithium10.html

「エッジ推論の前にやること」岡田 真太郎 氏 (株式会社Preferred Networks)

資料: エッジ推論の前にやること

PFN 岡田さんからは、エッジ推論を考えるにあたってまず一番はじめに考えることについて話をして頂きました。エッジ推論の速度を決定する3つの要素: モデル・入力画像サイズ・デバイスについてです。
入力画像サイズは縦横それぞれ0.7倍するだけで同じモデルでも計算量が半分になります。非常にシンプルな話ですが、それって精度が犠牲になるのでは？という疑問が起こるかもしれません。しかし、逆にどういう精度・速度が要件として必要か案外明確ではないケースが多いので、そもそもどれくらいの精度・速度が必要かという要件を明確にしてからエッジ推論を始めるようにしましょう、というのが重要なメッセージでした。
一般に、精度と速度はトレードオフの関係にあります。例えば、目標とする精度・速度のどちらも達成するモデルが NVIDIA の GPU で動いていたとしても、デバイスを変えると速度が落ちる場合があります。その際は入力画像のサイズを小さくすれば精度を犠牲にしてでも速度を向上させることができるので、それで済めばそれで目的は達成です。
ではモデルの修正が必要な場合はどうすれば良いでしょう。推論速度を上げるには、モデルごとの Forward Propagation にかかる計算量 (基本的には掛け算の総量) を把握する必要があります。なお Chainer でニューラルネットを記述している場合には chainer_computational_cost というツールで計算量を算出できます。例として ChainerCV に入っているインスタンスセグメンテーションの Mask R-CNN (MaskRCNNFPNResNet50) では Convolution がモデル全体の計算量の多くを、特にたった2つの Convolution がモデル全体の 1/3 の計算量を占めることが分かります。ここで Convolution 層の計算量は、入出力チャネル数 N とカーネルサイズ k 、それから入出力特徴マップサイズ (H, W) を用いて N^2 k^2 H W と表せます。入力画像サイズを減らす以外に入出力チャネル数をそれぞれ0.7倍にできると計算量が半分になり、今回の例だと全体で約25%の削減が可能となります。
さて、デバイスに関して NVIDIA GPU は計算量が多いなら効率 (計算量 / 秒) が良い、Intel GPU が割と速い、Qualcomm の Snapdragon は GPU / DSP が使える (ただし int8 の量子化が必須で精度が保てるかはモデル次第) だそうです。フレームワークはそれぞれハードウェアメーカーが出しているもの (NVIDIA: TensorRT, Intel: OpenVINO, Qualcomm: SNPE) を使うと最も性能が引き出せ、オペレーター間を埋める必要があれば、Menoh, Chainer compiler を使うと良い、とのことでした。

ディスカッション

LT 登壇者が各テーブルに分かれ、25分 x 2枠で以下のような内容が話されました。

  • テストどうしてる？
    • 一番単純な学習が回れば OK にしている。モデルの評価観点では COCOeval を拡張して使っていたりする。
  • サーバーとエッジってそんなに違う？
    • 全然違う。エッジ側のプラットフォームごとにフレームワークを分けている。
  • セキュリティ上の理由でクラウドに映像を送りたくない場合どうしたら良いのか？
    • エッジ推論で
  • 高位合成や DL コンパイラの発達で FPGA が簡単に使えるようになったということ？
    • 現在は OpenCL で FPGA を書くことができるが、実際問題としてはデバイスを知らないと効率的なものを書くのは難しい。
    • FPGA へ実装するには FPGA 用のデザインパターンを知っておく必要がある。Compiler の最適化ではどうにもならないことが多い。
  • FPGA で ML が強いワークロードは？
    • LSTM など。Compute-intensive なワークロードは GPU が有利な一方、自然言語処理系はメモリ要件が重要。
  • デバイス選定が肝だと思うが、実案件で選ぶには相当な知識が必要？
    • 実際、デバイス選定よりもまず何をやったらいいかわかっていないお客さんのほうが多い。
  • デバイス観点でエッジ環境でよく出てくる問題は？
    • 電源装置屋から見て、ML の世界はとっつきにくい印象がある。ソフトウェアが注目されているが、電源含めてシステムをみていかないとなかなかエッジ製品として成り立たせるのは難しい。
    • ファンがついてると屋外で使ったときにホコリが溜まって良くない。デバイスの選定は性能だけでなくて他の要素も考慮が必要。

などなど、多くのディスカッションが行われました。ご登壇・ご参加頂いた皆様、改めてありがとうございます。Edge の回の次は、自然言語処理をテーマに8月27日に開催されました。もう終わってしまいましたがイベント概要はこちら [ML@Loft #5 (NLP)]。

このブログの著者

針原 佳貴 (Yoshitaka Haribara)

スタートアップ担当のソリューションアーキテクトです。博士 (情報理工学)。