Arm MLプロセッサ、明らかになったその中身：モバイル機器でのエッジAI向け（4/5 ページ）

2018年8月に開催された「Hot Chips 30」では、Armの「ML Processor（MLプロセッサ）」の中身が明らかになった。その詳細を解説する。

[大原雄介，EE Times Japan]

Programmable Layer Engine（PLE）について

　次にProgrammable/flexibilityことProgrammable Layer Engine（PLE）について。

　Convolutionの場合、畳み込み演算についてはそれほどバリエーションが無いというか、データサイズあるいは重みのサイズがいろいろある、という以上の話にはならないのだが、CNNでは他にNon-linearityとかPoolingといった処理も必要とされ、こちらはまだConvolutionほどに決まった処理となっていない（図13）。そこでここを完全にProgrammableにしてしまいました、という話である。具体的には、内部にArmの汎用プロセッサ（Hot Chipsにおける説明では、"Arm M-class CPU"だそうだ）にVector Engineを組み合わせるという、なんかどこかで聞いたような構成になった（図14）。

図13（左）：最近だとNon-LinearはReLU(Rectified Linear Unit)が、PoolingはMax PoolingかAverage Poolingを使うのが流行であるようだが、1年先も同じだという保証がないのが怖いところ／図14：確か某社のLarrabeeとかいうコード名のプロセッサが、汎用コアにVector Processorを組み合わせていたような……。ちなみにVector Engineがどの程度の命令をサポートしているのかも現段階では不明。さすがにtanh(x)とかsigmoid(x)を搭載したりはしていないと思うのだが 出典：Arm（クリックで拡大）

　恐らく、このM-classコアそのものは単なる実行制御だけに利用され、数値演算そのものはVector Engineの側に置かれていると思われる。ここがボトルネックになったらシャレにならないので、MAC EngineのAccumulatorsと同じく同時128演算が可能（ただしデータ幅は8bit）で、それこそNon-Linearity向けにMax（0,x）とかPooling向けにMax/Avg/etc...のいくつかの命令を搭載する程度と思われる。ちなみに倍速動作させれば同時64演算でも足りるわけで、実際にどういうインプリメントになっているのかは不明である。

　なおVector命令に関しては、Armは2016年にSVE（Scalable Vector Extention）命令を発表しているが、さすがにこれを実装しているとは思い難い。

　若干似た部分もあるかもしれないが、基本的には別物だろう。ちなみに先ほど図5のキャプションでも書いたが、このレベルでは汎用CPUによる制御ができるので、それこそループとか条件分岐も（理論上は）可能である。ただConvolutionの処理そのものは、DSPというかアクセラレータ的に行われてしまっており、ここの制御そのものは不可能である。ただその出力を使う使わないといったレベルでの条件分岐は次の図15を見る限り、一応可能な模様だ。

　図15がそのPLEのデータ入出力である。

図15　ここでVector Engineが16lane構成であることが分かった。問題は1Laneがどの程度の演算を1cycleに行えるか、である 出典：Arm（クリックで拡大）

　MAC Engineの出力はそのままVector Register Fileに書き込まれ、同時にCPUに割り込みが飛ぶので、そのISRか何かでVectorエンジンに対して演算処理を掛けるという形だ。処理結果はいったんVector Registerに書き戻され、ここから内部のμDMA経由で、SRAMのOFMs領域に書き出されるという形だ。ただVector Register FileからLoad/Storeユニット経由でPLEのSRAMに値を保持し、これをCPUから参照することも可能な模様で、なので値を見て条件分岐も一応は可能だろう。ただパフォーマンスを考えるとあまり現実的ではない気がする。"The majority of operators are performed by a 16-lane vector engine"とあるように、このプロセッサは本当にISRの中でVectorエンジンに処理をさせる以外の仕事がほとんどなさそうである。

　最後にBandwidth reduction mechanismsについて。図16は消費電力の内訳であるが、確かに全体の中で一番大きいのはMLプロセッサの消費電力ではあるが、DRAMの消費電力もばかにならないとする。これに対する解決策が、特徴マップの圧縮、重みの圧縮、それとTilingである。まず特徴マップの圧縮（図17）。

図16（左）：実際にはMobile SoCに組み込まれる前提だから、Weight DDR Powerはあまり考えなくて良い気もするのだが／図17：8×8 blockということなので、これは入力特徴マップ（それも画像入力に近い部分）と思われる。具体的な圧縮方式は不明（まさか今更ランレングス圧縮ではないとは思うが） 出典：Arm（クリックで拡大）

　これは実際に統計データをとってみると、値が0のケースが非常に多い（それもブロック丸ごと0、が少なくない）ため、これを8x8ブロック単位で可逆圧縮することで、最大3.3倍の帯域削減が可能になったとする。これがどのレベルで行われているのかがはっきり示されていないのだが、DMAでML Procssorの外部からロードするときにこの圧縮が使われ、SRAMには伸長した形で展開されるものと思われる。次が重みの圧縮であるが、そもそもコンパイラがNetworkを変換する時点で無駄な層をそぎ落とし（Pruning）するとともに、こちらも可逆圧縮によってサイズを圧縮するとしている（図18）。

　最後がTiling（図19）であるが、例えば右図のように4種類の処理が並行して行われるようなケースでは、SRAMの利用効率向上とDRAMのアクセスを最小にするような形でのスケジューリングを行うようにする、という話である。例えばまずAvg Pooling→1x1 Convを先行していったんDRAMに書き出し、次にまた元データから1x1 Convを掛けてDRAMに再び書き出し、なんてやり方をしていると非常に効率が悪い。このあたりをうまくスケジュールする、という話である。

図18（左）：ただPruningは別に珍しい技法ではないと思うのだが。こちらはMLプロセッサというよりは、コンパイラ側の作業／図19：余談であるが、2段目の3×3 Conv(96)が行き先をなくしているのは単に図形作成ミスで、実際はFilter concatに渡される（元論文ではきちんとつながっている） 出典：Arm（クリックで拡大）

　ちなみに最後になるが、今回説明された16 Compute Engine/8 DP per MACといった数値、あるいはMLプロセッサの数はスケーラビリティがあるとされる（図20）。今回はあくまで3TOps/1GHzがターゲットであるが、より高い性能が必要なら構成を変更できる、として説明は締めくくられた。

図20　まぁ実際Control Unitをちょっと拡張すればCompute Engineの数は増やせるだろう。問題はむしろDMA Engineの帯域の方ではないかと思う 出典：Arm（クリックで拡大）