エンドポイントAI時代のCortex-MとNPU

英Armは2月10日、Arm v8.1-Mを実装した「Cortex-M55」と、Cortex-M55と組み合わせて動作するNPUとなる「Ethos-U55」を発表した。これに先駆け、アームの中島理志氏(Photo01)より両製品の概略について説明があったので、この説明を基にご紹介したい。

  • Cortex-M55

    Photo01:アーム 応用技術部 ディレクターの中島理志氏

さて、Armの新しいAIに関する世界観がこちら(Photo02)。

  • Cortex-M55

    Photo02:Endpoint AIという言い方はあまり馴染みがない。というか、Armが今回提唱し始めたというべきか

従来、AIといえば学習と推論をクラウド側で行っていたが、一部の学習と推論をもう少しエンドポイントに近いデバイスで行いたい、ということでIoTのエッジに持ってこようという動きが活発になっている。こうした動きに向けて例えばAWSのGreengrassやAzure IoT Edgeといったものが広く利用され始めているが、Armは今回そのエッジの先にあるエンドポイントにも推論が実装される時代を見据え、これを「エンドポイントAI(Endpoint AI)」と称している。このエンドポイントAIに向けて今回投入されるのが、Cortex-M55とEthos-U55である(Photo03)。

  • Cortex-M55

    Photo03:この480倍という数字は色々誤解を招きそう、というかそもそも数字の根拠が未だに不明である。まぁマーケティング的な数字だ

Cortex-M55とはどのようなコアなのか？

それぞれの製品を簡単に説明すると、Cortex-M55はAI時代に対応したMCUコア、Ethos-U55はCortex-Mグレードのプロセッサと協働するNPUということになる(Photo04)。

  • Cortex-M55

    Photo04:480倍の根拠はこれにあるのだが、「何で掛け算するのか？」について明確な回答は無かった(後述)

さて、まずCortex-M55であるが、こちらはArm初のHeliumサポートとなるArm v8.1-MベースMCUである(Photo05)。

  • Cortex-M55

    Photo05:右図でグレーの要素は全てオプション扱いであり、実装されるかどうかはCortex-M55のライセンスを取得したベンダー任せとなる

Arm v8.1-MとHeliumについては以前の記事でご紹介させていただいたので今回は説明を割愛するが、Heliumそのものはオプション扱いである。

Cortex-M55のCPUパイプラインそのものはCortex-M33と同じくSingle Issue/In-Orderの構成となっているが、多少マイクロアーキテクチャの改良などもあるので同一周波数比で「Cortex-M33と比べて10～20%程度高速」(中島氏)程度である。性能差があるのはDSP/Heliumであり、まずDSPではCortex-M33比で5倍という性能になっているので、以前の記事で説明した際のMACユニットが4つ、という構成になっていると思われる。

これだけだと4倍にしかならないが、ここに「Low Overhead Branch Extension」を組み合わせて最大5倍程度のピーク性能が出せる、というあたりだろう。

一方MLに関してはHeliumを利用し、128bitレジスタに8bit Integerの値を16個入れて処理するというシナリオを想定しており、ここから15倍という数字が出てきたようだ。

気になるのはエリアサイズであるが、CPUコアそのもので言えばCortex-M55とCortex-M33は同一プロセスならほぼ同等程度。そしてHeliumの実装にはほぼ同程度のエリアサイズが必要だそうで、なのでフルセットのCortex-M55はほぼ2倍のエリアサイズに膨れ上がることになる。

Ethos-U55はどのようなNPUなのか？

一方のEthos-U55であるが、こちらは32～256ユニットのMAC(どこまで入れるか、はカスタマイズ可能)ユニットを搭載しており、Cortex-M33比で言えば最大32倍の処理性能が実現される(Phoot06)。

  • Cortex-M55

    Photo06:ちなみに圧縮されるのはネットワークのウェイトのみで、データについては圧縮対象外。これについては、「実際に試してみたところ、(ネットワークの)ウェイトを圧縮する方が効果的だった」(中島氏)との事だった

ただし、以前の記事でも書いたが、ArmのNPUはローカルに大量のSRAM(Ethos-N77で4MB、N37/N57が1MB)を抱え、これを活用することで外部メモリとのトラフィックを減らし効率を上げるという仕組みであった。これをMCU向けとなるEthos-U55で同じことをすると、エリアサイズがMCUとして許容範囲外になる可能性が高い。そこで、ネットワークの重みに関しては圧縮して格納する仕組みとすることでメモリ利用量を減らす配慮がなされている。

ちなみにEthos-U55はCortex-M55だけでなく、Cortex-M4/M7/M33と組み合わせる事も可能である。逆にCortex-M0/M0+/M3/M23は対象外である。これはEthos-U55を利用するために内部的にDSP命令を利用している関係で、DSP命令が利用できるMCUコアのみがサポート対象、という話であった。逆に言えば、Cortex-M55であってもDSP拡張を実装しておかないと、Ethos-U55を組み合わせる事は出来ないという話である。

ただ、Ethos-U55はやはり結構大きいようだ。中島氏によれば、最小構成の32MACの状況で、大体エリアサイズはCortex-M33と同じくらいだそうで、ということは最大構成だと8倍。これにCortex-M55+Heliumを組み合わせると、Cortex-M33の10倍くらいのエリアサイズになる計算である。Cortex-M33は、例えばDialogのSmartBond DA1469xだと55nmプロセス、NXPのLPC552xが40nmプロセスを利用しており、大体このあたりが主なターゲット(Cortex-M33発表時のターゲットはTSMCの55ULPだった)であるが、Cortex-M55とかEthos-U55は28nmかそれ以下が現実的なターゲットになりそうである。