【開催報告&資料公開】ML@Loft #10 Edge Deep Learning

こんにちは、AWS ソリューションアーキテクトの辻です。2020年初となる第10回目の ML@Loft は1月に Deep Learning フレームワークと推論をテーマに開催しました。
ML@Loft は機械学習のお悩み相談イベントで、目黒の AWS Loft Tokyo で2019年4月より毎月開催しています。AWS をお使いのお客様がサービスの中に機械学習を取り入れて開発・運用していく際のお悩みを相談できる場が欲しい、ということで始まったコミュニティイベントです。登壇者（相談役）が自己紹介を兼ねた10分ほどの Lighting Talk (LT) を順番に行った後、テーブルに分かれて具体的な相談・ディスカッションを行う、という二部構成で開催されています。過去の様子は登壇者のスライド付きで AWS Startup ブログにまとまっています。

毎回登壇者の希望をもとにテーマを決めており、第10回となる今回のテーマは「Edge」です。今回登壇・相談役をお願いしたのは中村 晃一 氏（Idein株式会社 代表取締役）、小橋 昭文 氏（キャディ株式会社）、浜地 慎一郎 氏（株式会社Preferred Networks）、大瀧 隆太 氏（株式会社ソラコム）の四名です。当日の流れに沿って内容を振り返りたいと思います。

LT セッション

前半の LT セッションでは登壇者の方々から、ご自身の ML x Edge に対する思いや技術について発表いただきました。

「エッジDLデバイスの選定において考慮すること」中村 晃一 氏（Idein株式会社）

推論用のエッジデバイスに銀の弾丸はありません。技術的・ビジネス的に自組織に適したデバイスを様々な側面から評価し、選定する必要があります。Idein 株式会社代表取締役の中村さんからはエッジデバイスの選定においての考慮することついての発表です。

エッジデバイスの選定は、考慮すべきが多く難しいタスクです。しかしその難しさがありながら、機械学習、とりわけ DL (Deep Learning) のモデルをエッジで推論させたいという声は多くあります。要望が多い理由の1つとして、エッジ・クラウド間の通信負荷が挙げられます。DL だと入力データとして画像や音声データが多いため、クラウドや自社データセンターに送る通信負荷が非常に高くなってしまいます。台数が増えていくにつれて、この負荷がさらに大きくなっていきます。たとえ、通信負荷に耐えられとしても、サーバ側でリクエストに答えるためには、スケールアウトやスケールアップが必要になり、コストがかかってしまいます。そのため、PoC 程度ならばサーバ推論で行い、実運用ではエッジ推論に移行する場合も多くあります。

エッジで推論させるための困難として中村さんは2点挙げていました。1つ目がエンジニアのスキルセットの違い、2つ目がデバイスの選択が多いことです。

1つ目のポイント「エンジニアのスキルセット」について見ていきます。エッジデバイスが提供する主な機能は「DL モデルの推論」です。エンジニアは DL モデリングができるスキルセットが求められます。このようなエンジニアと組み込み系のエンジニアはスキルセットは大きく乖離しています。前者は Python や Docker などを扱うことが多いのに対し、後者は C/C++ やハードウェアの知識を扱います。両方できるエンジニア、またはそれぞれができるエンジニアを両方雇用するのは、リソースが限られているスタートアップでは困難です。そのため、機械学習エンジニアが組み込みに関わらざるを得ないのが現実になっています。PoC を通したにも関わらず、本番に移る際に組み込みができずに案件をロストする、という状況は避けねばなりません。Idein さんがこの課題に対して提供しているのが、エッジ用のモデルを出力するコンパイラです。エンドユーザーはサーバで学習したモデルをコンパイラに投げるだけで、エッジ用に最適化されたモデルを手に入れることができます。

2つ目のポイント「デバイスの選択肢の多さ」について、まずはどのようなプロセッサが選択可能か見ていきます。例えば NVIDIA Jetson ファミリーは CUDA が動作し、学習時の CUDA コードがそのまま使用したい場合によく選択されます。ARM もエッジデバイスのプロセッサとしてよく選択されます。スマートフォンやタブレットで利用される ARM Cortex A 系 や マイコン用の ARM Cortex M 系が多いでしょう。Intel の PC で使用されることが多い x86-64 アーキテクチャのプロセッサ、FPGA、AI 専用チップも選択肢となります。
学習時のアクセラレータならば悩まず GPU を選択すれば済みますが、エッジでの推論時はそのようにはいきません。それはエッジデバイスで考慮する点が多いためです。列挙すると、価格、サイズ、性能、I/O、ハードウェアセキュリティ、リアルタイム性能、熱耐久性、振動耐久性、防水耐久性、ハードウェアメーカーの保証、ソフトウェアのエコシステム、技適などの法に関する事項、などがあります。これらの多くはトレードオフの関係になるため、どんな条件でも最高のデバイス、というものは存在しません。選定基準は、もちろん、ビジネス上の要件によって決定されます。
例として、車載向けデバイスの場合は、価格が大事になります。DL の推論機能は（今現在）自動車本来の機能の付加価値です。自動車に求められる直接的な機能が大きく変化しないのであれば、より高価なものは購入されないでしょう。他にも消費電力、耐久性も犠牲にすることはできません。また品質保証も求められます。車載向けの場合、多くの場合は、性能をいくらか犠牲にして価格を抑えることが多いです。
他の例として、AI カメラの場合を考えてみます。AI カメラでは売り切りかサブスクリプションによって要求されるものが異なります。売り切りの場合、耐久性が優先度の上位にきます。これはハードウェアに対して高い付加価値をつける必要があるためです。購入したハードウェアがすぐ故障しては信用が失われてしまいます。一方でサブスクリプションの場合はハードウェアの交換を継続的に行えるため、耐久性の優先度は下がります。デバイスを活用したサービスでビジネスを回すため、社内の開発スピードに影響するソフトウェアのエコシステムなどが重要になります。

Idein さんの場合はどのようなポイントを重視したのでしょうか。重視したポイントを理解するためには、まずビジネスモデルを理解する必要があります。Idein さんの主なビジネスは Actcast と呼ばれる IoT のプラットフォームサービスです。エッジデバイスで動作するソフトウェアをパートナーが出品し、エンドユーザーが契約して使用します。このビジネスはプラットフォームビジネスのため、パートナー数、ユーザ数、アプリケーション数、デバイス数、などが多ければ多いほどサービス価値は向上します。またデバイスはインターネットに繋がることを前提としています。これらの特徴から逆算します。Idein さんが重視したのは、購入しやすくするための価格、各国で使えるための法への準拠、そして通信モジュール、です。
Idein さんでは、これらのポイントから Raspberry Pi をエッジデバイスとして扱うことを決めました。エコシステムと知名度は圧倒的と言って良いでしょう。またユーザ数も多いです。スタートアップとして認知度を高めるというマーケティング目的としても Raspberry Pi に決めたそうです。

エッジDLデバイスの選定において考慮すること ML@Loft

「消費電力を意識したアルゴリズム開発」小橋 昭文 氏（キャディ株式会社）

制約の多いエッジデバイスは、その制約によってユーザの体験を損なわないよう様々な技術が活用されています。キャディ株式会社の小橋氏からはエッジデバイスで使われている技術について紹介です。小橋さんは大学・大学院在学中から電子回路などの組み込みデバイスに関わってきました。現職のキャディ株式会社では機械加工などのものづくりと、形状解析に使用するアルゴリズム開発などをされています。

エッジデバイスの制約は、プロセッサの制約に依る部分が大きいです。まずはエッジに限らない一般的なプロセッサについて考えていきます。プロセッサの性能を向上させるため、過去何十年間クロック周波数は上昇し続けました。しかし、ここ数年周波数の上昇は頭打ちとなりました。代わりにプロセッサあたりのコア数を増加させることで性能向上を達成しています。このあたりの話は有名ですね (例えばヘネパタとかに詳しく書かれています)。クロック周波数が頭打ちになった主な理由として、消費電力と熱の問題があります。この2つの問題はエッジデバイスで対処すべき大きな課題となります。プロセッサを作る上で、消費電力と熱を抑えるために使われている技術を4つ紹介します。

1つ目に紹介するのは、プロセッサの一部の電力供給を切ってしまう方法です。スマートフォンのカメラを例に考えてみます。カメラをつけっぱなしにする人はなかなかいないと思います。全体を通して使っていない時間の方が長いのに、その機能を常に使える状態にするのは賢くありません。なので実際に利用するとき以外は、関連するハードウェアの電力供給は切ってしまった方がいいでしょう。技術的にはこの方法は Power Gating と呼ばれています。他の例として、USB ポートに何も刺さっていなければ、関係するハードウェアを切る、などがあります。

2つ目に紹介するのは、電源のオンとオフを高速に切り替えることで、合計の消費電力を減らす方法です。アイデアは単純でつけっぱなしにしておくと消費電力が高いので、切ればよい、ということです。技術的には Duty Cycling と呼ばれています。例としてはスマートフォンの明るさ調整などがこの技術を使用しています。

3つ目に紹介するのは、Clock Gating という方法です。デジタル回路でよく登場する方法です。プロセッサの各モジュールはクロックに反応し、処理をします。しかし処理が必要なくても、クロックへの反応をするだけでも電力を消費してしまいます。Clock Gating では必要になるまでひたすらこのクロックの0と1の変化を無視し続けるという方法です。

4つ目に紹介するのは、周波数を電力効率に合わせて調整する方法です。例えば、定格以上に周波数を上げること（いわゆるオーバークロック）で性能を向上できることは一般的に知られています。しかし消費電力の観点から見ると、この方法は効率を完全に無視しています。周波数を一定の傾きで上げていくにつれ、定格以上では、消費電力が指数関数的に上がっていってしいます。消費電力がシビアなエッジでは、サーバ、デスクトップ、ラップトップなどと比べ、より電力効率に重きが置かれ、性能を犠牲にして周波数が高くならないよう設定されています。

エッジでは、上で紹介した技術などを用いて消費電力・熱と性能のバランスをとります。小橋さんがその中でもとくに強調していたのが、I/O Block 中は低電力モードになるようにすることと、可能な限りハードウェアに処理をオフロードすることです。前者は I/O を待っている間はクロック周波数を上げる意味がないため、後者は（基本的に）ソフトウェアと比べハードウェアによる処理が圧倒的に電力効率が良いためである。ハードウェアにより処理が実際に電力効率が良いことは、機械学習専用のプロセッサを例に確認することができます。これらのプロセッサはハードウェアが機械学習（とくに深層学習）の計算に最適化されています。当然、汎用的な CPU や GPU などと比べ性能は高いです。そして同様に電力効率という観点でもより良い数値を達成します。

まとめとして、「At the edge, hardware is king」という言葉を紹介されました。ビジネスモデルの正しさ、という議論は置いておくと、消費電力・性能などの技術的なトレードオフで最も優秀なのはハードウェアによる作りこみです。

「chainer-compiler のその後」浜地 慎一郎 氏（株式会社Preferred Networks）

サーバで動作するソフトウェアがそのままエッジで動作するという保証はありません。それは開発における基本的な言語である Python も例外ではありません。浜地さんからは深層学習の計算の高速化・エッジでのデプロイの簡略化を目的に開発されている chainer-compiler のご紹介です。

chainer-compiler は PFN さんの社内で使われてるツールであり、開発のきっかけは深層学習の計算の高速化でした。深層学習は決まった計算が繰り返されるため、計算グラフの構築と最適化を一反復分することで、効率的に全体を高速化することができます。chainer-compiler によって以下の機能を実現できます。

• 計算グラフの構築と最適化による計算の高速化
• Python の実行コードを編集なしで利用
• Python のオーバーヘッドの完全除去
• Python がインストールできない環境での実行とデプロイの簡易化

これらの機能は Chainer から利用されること想定していましたが、ご存知のとおり、Chainer はメンテナンスフェーズになり、PFN さん社内で使用するフレームワークも PyTorch に移行することが決まりました。この移行によって、インターフェイスが Chainer から PyTorch に変更されました。加えてランタイムも独自実装の libchainerx から PyTorch 内部の C/C++ の実装である libtorch に変更されました。

計算グラフの構築には ONNX を利用しています。Chainer から PyTorch への移行は開発チーム外部の要因でしたが、PyTorch が ONNX との相性が良いことなど、移行のメリットも多くありました。フロントエンドやバックエンドは変更されましたが、開発における哲学というものは変わっていません。Chainer そのものにも通ずる哲学を簡単に紹介します。

• Python コードの再実装は必要ない：深層学習であるあるの NHWC の問題などを避けるため、C++ のコーディングができない人でも扱えるようにするため
• Python と同じだけの柔軟性：動的な行列サイズや型を扱え、さらに自動微分の機能も加えるため
• すべて自分たちで実装しようとしない：開発能力はあっても開発コストはかかるため、他のフレームワークを賢く使う

はじめに紹介したように chainer-compiler はモデルのエッジ実行の簡略化も開発理由の1つです。エッジでの実行に最適化するためには汎用的なツールを使用するよりも各エッジデバイスを販売・提供しているベンダーが開発しているツールを使った方がいいでしょう。Intel OpenVINO, NVIDIA TensorRT などがあてはまります。これらのツールは非常に細かいチューニングがされているため、ハードウェアの性能はフルに活かすことができます。chainer-compiler もこれらのツールに丸投げできるように計算グラフの構築を工夫しています。ツールに丸投げできない部分は libtorch を使って実装している形です。

chainer-compiler は実行時に Python を必要としません。これはエッジで大きなメリットになります。具体的に chainer-compiler で吐かれるモデルは ChxVM IR と ChxVM runtime だけあれば実行が可能です。つまり実行時にランタイムだけが要求される形です。このようなツールは他にも多数あり、代表的なのは TensorFlow Lite, TorchScript, TVM, MLIR, ONNX runtime などです。浜地さんチームは、これらのツールではハードウェアの性能を出し切ることが難しいという調査のもと自前で実装することに踏み切ったそうです。同じような文脈として、ベンダーツールをそのまま使っても良いのでは？という疑問もあります。先ほど述べた OpenVINO, TensorRT, nGraph などがこれにあたります。ChxVM runtime も API としてサブグラフをこれらのベンダーツールに丸投げしています。そのまま使用していない理由は、動的次元が扱えなかったりや独自拡張を要求することがあるためでした。

chainer-compiler を使った例を 2 つ紹介します。1つ目が CUDA で書かれた複雑なモデルを変換した例です。TensorRT でサポートしていない Ops を使用し、推論時にも微分を必要とするモデルでした。変換後は Chainer の実装よりも4倍程度高速化ができました。2つ目が複数のモデルを複数のデバイスで速度評価した例です。複数デバイスのベンチマークはベンダーごとの実装が必要など、一元的に測ることが困難です。chainer-compiler を利用して1つの枠組みでベンチマークをとることが可能になります。ベンチマーク結果はスライドにあります。ベンダーごとに傾向があり、興味深い結果になっています。

「エッジとクラウド間の通信・認証のハマりどころ」大瀧 隆太 氏（株式会社ソラコム）

エッジデバイスがどことも通信することなくサービスを成り立たせることは困難です。ほとんどの場合、クラウドやオンプレミスと通信して、1つのサービスが成立します。株式会社ソラコムの大瀧さんからはエッジとクラウドが通信する際の注意点についての紹介です。

はじめに、エッジで推論する場合のエッジ・クラウド間でどのようなデータが通信されるか整理します。エッジからクラウドへの通信には推論結果やデバイスの状態が流れます。ここで得られたデータはデータの蓄積・分析などに利用します。逆にクラウドからエッジへの通信にはモデルや更新プログラムが流れます。このような通信がある状況でどのような悩みがあって、どのように解決できるのか見ていきます。

1つ目の悩みは通信環境の整備が大変なことです。多くのエッジデバイスは Wi-Fi モジュールが組み込まれており、それを利用して通信しています。そのためデバイスの近くに無線LANルーターが設置されています。簡単そうに聞こえますが、現実では調整や運用がかなり大変です。とくに店舗や製造現場などに設置する場合は障壁が高くなります。大瀧さんの実体験として、小売店舗で客層分析をしようと思った際に、現場との調整と業者との調整が必要でした。このようにルーターの設置には各所との調整が求められ、設置に至るまで少なくとも二週間程度、長い時には数ヶ月かかることになります。開通を完了しても終わりではありません。設置後にデバイスでテストし、その後にやっと実運用が始められます。これらの悩みの解決策としてソラコムでは 3G/LTE 回線の利用を提案しています。

エッジデバイスを LTE につなげるパターンは2つあります。1つ目がデバイスが LTE ルータを介して、クラウドと通信する方法。2つ目が各デバイスに LTE のドングルを接続し、それぞれが別々にクラウドと通信する方法です。ハードウェアの管理の「層」が減るという意味で後者の方が構成は簡単になります。ただし、ドングルを接続できるかどうかがデバイスに依存するため制約は強くなります。

LTE を通してエッジデバイスがクラウドに接続し問題なくサービスを提供できるようになりました。しかし使用していれば、なにかしら故障は発生します。ハードウェアの致命的な故障でない場合は、リモートからログインして調査をしたいところです。例えば、リモートから SSH などができればベストです。Public IP が割り振られておらず、同じ Privarte ネットワーク内にいないので、straightforward な方法では実現できません。これを実現する方法としてソラコムでは SORACOM Napter というサービスを提供しています。

エッジデバイス一般的に言えることとして、認証の課題があります。これが2つ目の悩みです。例えば AWS の API は access key と secret key で認証されます。AWS IoT に限ると X.509 証明書で認証されます。これらのデータはエッジデバイスに初期インストールします。この認証情報の運用はセキュリティインシデントになりかねないため気を遣って行う必要があります。外部への製造委託などをする場合に情報漏えいの懸念があるでしょう。ソラコムでは LTE の SIM カードに対して認証を行うことでコピーによる流出を防いでいます。

エッジとクラウド間の 通信/認証のハマりどころ / ML@Loft #10 Edge

RT ディスカッション

イベントの後半はラウンドテーブルでのディスカッションです。4つのテーブルに分かれて、4人の登壇者が相談役としてそれぞれのテーブルにつき、お悩み相談という形でディスカッションを行いました。

• Raspberry Pi 4 系を使うのはどうか？
  • Raspberry Pi 3 と比べて消費電力の視点で厳しい
  • なので、3 系を推奨している
• エッジのセキュリティはどのように担保している？盗まれた場合など
  • まず前提としてファイルシステムは暗号化している
  • 鍵をどうするかという問題が発生する
  • 最適解はないので、例えばビジネス上の設計を変えることで盗まれても大丈夫にする方法などもある
• どのようなモデルをエッジ用に変換することが多い？
  • 基本は画像系
  • 人物検知や動物 (ペット) の検知
  • 交通量解析などもある
• Actcast のサービス詳細が知りたい、具体的にどのようなことをしているか
  • 前処理、推論、後処理、すべてをエッジで実行するアプリケーションを配布している
  • マニフェストと呼ばれる、デバイス・モデルの指定などが記述された JSON ファイルを置くと、最適化されたモデルが返ってくる
  • Idein 社側で C と Python のインターフェイスも提供している
• 半導体は七年先のことを考えて設計する
  • 開発期間が長いので先のことを考えないとすぐに時代遅れになる
• ハードウェアとソフトウェアは文化が全然違う
  • ハードウェアは不具合があっても直せない、できてから不具合が発覚したらソフトウェアでなんとかすることも多い
• ハードウェアの界隈は経験値がものをいうところもあり、新規参入のハードルが高め
  • 最近はハードウェアの人も高位合成などでソフトウェアを触る機会も増えている
• スマホゲーム業界から見ると、iOS がクラウドに対応してくれると助かる
• 消費電力を下げるための工夫について詳しく聞きたい
  • 実際にどのくらい減っているかよりも、ユーザの使い勝手や電池が減っている感じみたいなことが重要
  • ユーザの使い勝手によって、消費電力を抑えるための周波数制御などアプリケーションごとに結構精巧に制御している
  • OS 側では管理しきれないところがあり、例えばどのキャリアを利用しているかによって変える場合もある
• ONNX を起点に、そこから一歩動かして終わりにしたい。
• コンパイラでモデル変換すると表現力が落ちる場合があると思う。あるオペレーションが対応してないという風になると、アルゴリズムを変えるしかない？
  • モデルコンパイラとしては基本対応できるところだけやる、という立ち位置。レッドオーシャンには入らない。
• どのくらいの頻度でクラウドにデータを送信するのが良い？
  • 目的によって頻度は異なる、必要な部分だけ送るのか、どうかよく現場で問題になる
• エッジ ML 案件はどこの業界が多い？
  • 観測範囲だと小売や製造が多い
• デバイスに付いているのセンサーでタイムスタンプが異なる場合があり、それによって分析ができないことがある。エッジで同期する仕組みはあるのか？
  • 機器同士が同期をとることは現状難しいと思う。
• 5G になると、通信容量が増えて (容量あたりの) 値段が安くなってりするのか？
  • なるとは思うが、まだどうなるかわからない。無線部分は通信容量が増えるが、既存の有線部分は変化しない。無線を使った P2P の通信は増えると思う。

ご登壇・ご参加頂いた皆様、改めてありがとうございました。今後しばらく ML@Loft はオンラインでの開催を予定しています。引き続きお気軽にご参加ください。

このブログの著者

辻 陽平 (Yohei Tsuji)

AWS のソリューションアーキテクト（機械学習・HPC担当）です。好きなサービスは Amazon SageMaker と AWS CDK です。