TinyML as-a-Service、エッジ機械学習の課題

Available in English 日本語

まずはじめに Ericsson ResearchにおけるTinyML as-a-Serviceプロジェクトは 現在、組み込みIoTエッジにおける機械学習(ML)の可能性を制限する 課題について述べます。 このTinyMLシリーズの第二回において、 技術的および非技術的な課題の詳細をみていきます。でははじめましょう

 コネクテッドカーロジスティクス

Senior Researcher IoT

Experienced Researcher IoT technologies

Senior Researcher IoT

Contributor (+1)

Experienced Researcher IoT technologies

本記事はIoTエッジにおけるTinyMLシリーズの第二回です。 既存のクラウドにおける機械学習や組み込み「Embedded」に対して TinyMLがどのように位置するものか理解するために 前回のTinyML as-a-Serviceのイントロダクションの記事を参照してください。

TinyMLは超低消費電力マイクロコントローラー上でML推論を行うという、新しく 出始めたコンセプトであり、またそのコミュニティを意味することもあります。 TinyMLaaSはベンダーがマイクロコントローラー上でTinyMLを走らせることでAI ビジネスの開始を助けます。

本記事では機械学習を組み込みIoTに適用する際の課題を紹介します。 更にこれらの課題は組み込みデバイス自体のの限られた機能からの制約だけではなく IoT ML デプロイがネットワーク・エッジのリソースに制限されることも含みます。

以上の課題をまとめると以下のように言えるでしょう。

  1. エッジコンピューティングは万能ではない。
  2. Webと組み込みシステムの構成要素の違い。
  3. 機械学習エコシステムは多大でリソースを多く使います。 組み込みIoTで実行可能な機械学習とは?

以下にそれぞれの課題を詳細にみていきます。

なぜエッジコンピューティングは万能ではないか?

エッジコンピューティングは 計算能力およびネットワーク接続の観点から高性能なサービスを展開することを保証します。

エッジ・ノード群はエンド・デバイスに近いということで ミッションクリティカルなレイテンシー条件を満たします。 エッジ・ノード群のもつ増強されたハードウェアとソフトウェアは エッジ・ノード上のより複雑化し多くのリソースを必要とするサービスの実行も可能にします。

というわけで、ここでのポイントは、 エッジコンピューティングのパラダイムがまだ解決しきれていない問題とは何か、そしてどのようにその問題が機械学習をIoTやエッジへの適用を妨げるか、 ということになります。

五つの分野に注目してみていきたいと思います(注:いくつかの分野は先進的なエッジコンピューティングが解決しつつあ るかもしれませんが、まだ一般的に普及していません)。

  • プライバシー: データセキュリテイとユーザープライバシーは 頻発する公的データ漏洩ニュースによりさらに近年、多大な注目を集めています。 政府は 例えば新しい規制や、既存のセキュリティとプライバシー法律の強化を通して そういったプライバシー問題の解決に乗り出しました。 わかりやすい例は、EUで2018年に施行されたGDPRです。これらのより厳しい規制に関わらず 多くのデータ保持者は警戒心を強めています。 たびたび第三者であるクラウド、エッジサービスのプロバイダーが 自分たちのデータを蓄積し管理することが不本意であることを示しています。 簡単に言えば、 自分たちの生成するデータを保持するために 物理的オンプレミス境界を設定するエンドユーザーからの増加する要求からわかります。 これはデータが全エコシステムの重要要素である機械学習に大変関係しています。 幅広い業種において、 この問題を解決するための「federated learning」といった、いくつかの手法が定義されました。 エリクソンはセキュリティとプライバシーの重要性を理解し、 幅広い関連事項において活動しています。 TinyMLaaSも 機密情報処理をIoTデバイス上に制限することで データをオンプレミスに保持することで 同様の方針を取っています。
  • ネットワーク帯域: 高密度かつ大量のIoTエンドデバイス(様々な異種のタスク実行用のデバイス)が存在する状況において 当然、これらのデバイスが生成する生データは非常に大量です。 一方、これらのデバイスの大多数は低帯域インターフェース(例えばNB-IoTかCat-M1)を備えていると思われます。 この限られた転送性能のため、オンプレミスにてデータを前処理する必要があると言えます。 なぜならエッジへオフロードするデータ量を削減するため、 また同様に結果としてネットワーク性能の低減を伴うエンドデバイスとエッジ間のネットワークのボトルネックを避けるためでもあります。

  • ネットワーク遅延: 高性能サービスを届けるための 限界遅延コミュニケーションを保証する能力は 新しいモバイルネットワークの重要なデザイン要件です。 このサイトではすでに 5Gがどのように重要な低遅延IoTアプリケーションに必要か 超高信頼低遅延コミュニケーションを保証するか といったいくつかの記事を掲載しています。 さらに 大量で重要なマシンタイプ・コミュニケーションのユースケースで ミリ秒の遅延を保証しながら エッジネットワークが重要な役割を果していることを強調しておきます。 TinyMLaaSの狙いはさらなる遅延短縮のために MLタスク(推論)実行をデバイス自身へ持っていくことです。 ほぼゼロ遅延が望ましく、私たちのアプローチで可能ですが ネットワーク・エッジのサポートや残りのモバイルネットワークから 切り離すことはできないということは重要です。

  • 信頼性: 地方や海上で制限された、もしくはまったくコネクティビティがないような セルラーの受信が保証されないシナリオにおいて、クラウドやエッジはエンドデバイスの計算能力や接続能力を拡張することができません。 その結果、 TinyMLaasが処理しようとする 以前はエッジかクラウドで実行されてたような特定のML処理をその場で実行できることは間違いなく有利です。

  • エネルギー効率:よく知られているように 特に高確率でIoTデバイスがバッテリー駆動であるとこと考えれば、 IoTネットワークの一つの設計要件はエネルギー効率です。しかしながら、 無視されがちですが 実際には非常に影響を及ぼすさらなるエネルギー効率の特徴があります。 これは次の事実に関連しています。 あるケースでは ネットワーク転送はローカルでの計算処理よりもエネルギーを消費するということです。 この要素とほとんどのIoTデバイスがバッテリー駆動であることを考えて、 エッジとクラウドにおけるデータ転送、ML処理とともに 、TinyMLaaSは IoTデバイス上のローカルでの計算処理を可能にするように設計されています。

Webと組み込みの技術的差異

まったく違う特徴

図1

Webと組み込みはまったく違う特徴を持ちます。 上記の図1は ハードウェア、ソフトウェアの両方の観点から定量的および定性的比較で この違いを示しています。 Webサービスは強力なCPU、高いメモリーとストレージ容量に基づいています。 ソフトウェアの観点から Webテクノロジーは 豊富な洗練されたOSと複雑なソフトウェア・ツールを選択し恩恵を受けるように 設計することができます。

一方、組み込みシステムは 汎用のコンシューマー向けCPUと比較すると非常に非力なMCUとCPUという制限された機能に 基づいています。 メモリーとストレージにおいても同様です。 500KBのSRAM、1-4MBのフラッシュメモリーは高価なリソースと考えられます。 Linuxベースのシステムを組み込みにという試行は様々なされましたが、 多数の32bit MCUのデバイスはRTOS向けの容量しかもたず、 それよりも複雑なディストリビューションには合いませんでした。

つまりLinuxが動く限りシステム開発は簡単になります。 理由はソフトウェアの移植が簡単だからです。 Webサポートとコンテナといった軽量仮想化技術を使用することで 更に高度なプラットフォーム非依存なソフトウェアの移植が可能となります。 Linux環境でありされすば、 開発者は労せず基本的に同じソフトウェア機能をリリースすることができます。 これがクラウドとエッジで起こっていることです。

MCU上でLinuxとコンテナ仮想化が使えないとうことが、 現在のデプロイの最大の制限であり最大の課題の一つです。 実際、明白なことに 典型的な「クラウド~エッジ~組み込み機器」の構成において 組み込み技術と対比してクラウドとエッジ・サービスは 根本的に違うハードウェアとソフトウェア技術で開発されデプロイされ容易に管理できます。

TinyMLaaSは全く異なる(かつ軽量な)ソフトウェア・ソリューションを利用することで この問題に取り組んでいます。

MLエコシステムは大きくてリソースが必要です。どのようなMLタスクがIoTで実行可能でしょうか?

機械学習のエコシステムは大きくリソース需要が高い。

図2

前章において Webと組み込みの技術的差異が IoTデバイス上でのMLタスクの実行にそれとなく多大な影響を及ぼすのを概観しました。ここでどのようにしてWeb、エッジ、組み込みにおいて ML専用ハードウェア/ソフトウェアの有無という点で 大きな技術的ギャップが存在しているかを解析します。

ハードウェアの観点からほとんどのコンピューターの歴史上、 たった少しの汎用用途のプロセッサーしか存在しませんでした。 近年、絶え間なく続くAIの成長は 既存のGPU向けMLタスクの最適化へ続きました。 同様にもっぱら特定のML演算向けに設計されたASICといった 新しい専用ハードウェアの形態へも続きました。 これら全ての新しいデバイスの共通点はエッジで使用されるということです。 事実、これらのクレジットカードサイズのデバイスはエッジで動作するように設計されました。

この記事の冒頭部分で、この新しいデバイスの例(Edge TPU、 Jetson Nano、 Movidius)を紹介しました。 近いうちにより多くのハードウェア製造業者がML専用ハードウェアの設計製造に投資すると予見しています。 しかしながら現時点で明白なのは、組み込み同様ではなかったということです。

ML専用ハードウェアがないことで 一貫したクラウドから組み込みに向けてのMLデプロイができませんでした。 多くの場合、 ソフトウェアはハードウェアの欠如を補う助けとなります。しかし ハードウェアで見た限界はソフトウェアツールの開発でも同様です。 今日Webでは たくさんのMLアプリケーション・ソフトウェアがあります。 世界中の熱心な開発者のマージ作業を可能にする様々なオープンソース活動のおかげで それらの利用は一定に成長しています。 その結果はもっと効果的で洗練され、そしてニッチなアプリケーションです。 しかし、そういったアプリケーションの移植性は簡単ではありません。 大きなランタイムとPythonのような高級言語の利用が理由です。

TinyMLaaSの根拠はクラウド/エッジと組み込みの間の壁を破るということです。しかし、Webやエンタープライズと同様のMLエクスペリエンスを期待することは現実的ではありません。 サイズというのは無視できない問題です。 ML推論実行だけはIoTデバイス上で実行可能と予見することができます。 図2に示されている整備されたリソース豊富なデータの処理とトレーニングといった、他のすべての面倒なMLタスクはおいていってもいいでしょう。

もっと読む

次回の記事では TinyML as-a-Serviceを特徴づける様々な機能を一覧し、 TinyML as-a-Serviceのコンセプトの下にある 技術的アプローチを紹介します。

しばしの間、もしお読みでなければ、 私たちの前回の記事をお読みになることをお薦めします。

IoTには一貫した機械学習のエクスペリエンスが必要です。TinyMLaaSは 潜在的なテクノロジーの機会を押し広げながら 一貫した機械学習のエクスペリエンスを可能にする ソリューションとなる可能性があります。 乞うご期待。

The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.