ロードマップでわかる！当世プロセッサー事情 第685回

メモリーと演算ユニットをほぼ一体化したUntether AIのrunAI200とBoqueria　AIプロセッサーの昨今

　Untether AIはもうすっかり取り上げていたつもりだったので、まだだったことに少し焦っている。Untether AIは2018年にトロントで創業されたスタートアップ企業である。

　創業者はMartin Snelgrove博士(初代CEO、現在はCTO)とDarrick Wiebe氏(もともとはソフトウェアの設計者だが、現在のポジションはHead of Technical Marketing)、Raymond Chik博士(現在はコンサルタントだが、一時期はVP, Engineeringも兼業していた。本業(?)は起業家兼エンジェル)の3人である。スタートアップといってももう総額で1億5200万ドルの投資を受けており、この業界(?)では結構な老舗だったりする。

画像はUntether AIの商品ページより

　同社が最初の製品であるrunAI200を発表したのはLinley Fall Processor Conference 2020の最終日(10月29日)である。アーキテクチャーはNear-Memory Computingである。Near-Memoryというのは一応メモリーと演算素子は別々に実装されるが、ただし物理的には極めて近い位置にあることを指す。

　アーキテクチャーをNear-Memory Computingにした動機が下の画像だ。要するに従来型のアーキテクチャーでは、消費電力の大半がデータの移動に費やされるためだ。

消費電力の大半がデータの移動に費やされる話はIn-Memory Computingなどでも煩雑に出てきているので別に目新しいわけではない。そして「お説ごもっとも」でもある

　これをカバーするために大量のキャッシュを搭載したり、あるいはインテルの“An 8-core RISC-V Processor with Compute near Last Level Cache in Intel 4 CMOS”のように、LLC(Last Level Cache)の中に演算ユニットをブッこんでみたりといろいろ工夫をするわけだが、Untether AIは素直にSRAMと演算ユニット(PE:Processing Element)を密に配置するという、ある意味素直な実装になった。

　その最初の製品がrunAI200である。素直な実装にした理由はやはりプロセス周りで冒険する必要がなかったことにつきる。TSMCの16nmで、普通にロジックICとして製造しながら8TOPS/Wを実現するとなると、こうした工夫は欠かせないことになる。

runAI200の概要。これで8TOPS/Wを実現できたというのだから、大したものである。とはいえトランジスタは184億個だからすさまじい。200MBものSRAMを搭載すれば当然とも言える

　そのrunAI200の内部構造が下の画像だ。511個SRAMベースのメモリーバンクが内蔵され、個々のメモリーバンクの中にPEが512個(!)搭載される格好になる。

runAI200の内部構造。メモリーバンクが511個と中途半端なのは、残り1つ分をPCIe Gen4 x16 I/Fが占有しているためと思われる

　メモリーバンク間はRow方向とColumn方向で別々にインターコネクトが配されており、それとは別にPCIeコントローラーにつながるバスが別途用意されるという、なかなか複雑な構成だ。

　個々のPEはメモリーからデータを読み取る格好だが、個々の活性化の閾値(Activation)はA Regから取り込むことになる。このA Regは、Row方向のインターコネクトからデータを取り込む格好だ。

F Registerはアドレス格納用。Zero Detectは疎行列の検出を行ない、不要なデータ移動を排除することで消費電力を半減できるとしている

　この結果として、1bit分の演算の消費電力は、従来型と比較して6分の1に削減できたとする。

演算そのものは当然減らないが、それ以外を最小化できたということだ。またDRAMアクセスに起因する消費は当然0になる

　511個あるメモリーバンクの中身が下の画像だ。376BytesのSRAMアレイ2つに1つのPEが挟まれている格好だ。このアレイ×2＋PEが横に64個、縦に8個並んで合計512個という計算になる。SRAMの総容量はバンクあたり376KBになる計算だ。

右上には“385KB pitch-matched to PEs”とあるが、これは376×2×512＝385024Bytesになる(つまり1KB＝1000Bytes換算)という話で、1KB＝1024Bytes換算なら376KBになる

　理屈はわかるが、個々のSRAMアレイ、幅4Bytesなのは32bitデータの格納を意識したものだろうが、縦方向94個というのはどこから出てきたのか興味あるところだ。Processing Elementは全体で連動する形で64×8の2D SIMD演算が可能らしい。このPEの制御などは、左端のRISC Processorで行なうようになっている。

　そのRISC Processorの詳細が下の画像だ。一応汎用プロセッサーとしての体は成しており、演算もオフロード可能であるが、最大の目的はPEの制御であって、またPEの結果を加算するRow ALUも搭載されているというやや独特のものである。

計算でいえばPEは0～31まであるはずで、右下の“Access to PE0:2 activation registers”はPE0:31でないとおかしい気もする

　ちなみにPE自身の説明はないが、これだけバラまけるということはそれほど複雑な実装にはなっていないはずで、おそらく畳み込み演算に特化した形と思われる。一応データ型はFP32とINT8の両対応となっている。

ASCII倶楽部