Posted by
佐藤一憲, Staff Developer Advocate, Google Cloud
Cliff Young, Software Engineer, Google Brain
David Patterson, Distinguished Engineer, Google Brain

Google 検索、ストリートビュー、Google フォト、そしてGoogle 翻訳。これらのサービスに共通するのは、いずれもニューラルネットワーク(NN)の計算処理の高速化のために Google の第一世代の Tensor Processing Unit (TPU) が用いられている点です。

 
Google の Tensor Processing Unit (TPU) が搭載された回路基板(左)と、
Google データセンターに導入された TPU(右)

Google の第一世代 TPU は、昨年の Google I/O で初めて紹介され、今年 4 月にはその性能やアーキテクチャについて詳細に解説した論文が公開されました。TPU は、一般的な CPU や GPU を用いて NN の計算処理を行う場合と比較して、15 〜 30 倍の性能と、30 〜 80 倍の電力性能比を提供します。この大幅な性能改善のおかげで、Google の数多くのサービスにおいて最新の NN を大規模かつ低いコストで提供可能となっています。

本記事では、この Google の TPU の内部で用いられているテクノロジーを掘り下げ、このケタ違いの性能がどのようにして実現されているのか解説します。


TPU が生まれるまで

NN 専用の ASIC(特定用途向け LSI)を Google 自ら開発しよう、というアイディアは、2006 年のころから議論されていました。しかし議論が本格化したのは 2013 年のことです。Google データセンター内での NN 利用が爆発的に拡大し、このままでは当時の全データセンターの 2 倍に相当する計算能力がまもなく必要となることが判明したからです。

通常、ASIC をゼロから開発するには数年の期間を要します。しかし TPU の場合は、デジタル回路の設計に始まり、検証、製作、そしてデータセンターへの導入までわずか 15 か月で完了しています。TPU プロジェクトの技術リーダーを担当した Norm Jouppi(MIPSプロセッサの主任アーキテクトとしても知られる)は、当時の慌ただしさをこう振り返ります。

「TPU の開発はおそろしいスピードで進んで行きました。最初は回路設計エンジニア、その後は検証エンジニアと、エンジニアの採用とチップ開発を並行して進めていく忙しさです。しかし最初にできあがったチップ(ファーストシリコン)はまったく何の問題もなく動きました」
First in-depth look at Google's TPU architecture, The Next Platform より)

TPU は 28nm プロセスで製造され、700MHz クロック、消費電力 40W の ASIC です。Google の既存のサーバーにできるだけ早く導入するため、SATA ハードディスク スロットにそのまま収まるアクセラレータカードの上に ASIC を搭載しました。サーバー本体との間は PCIe Gen3 x16 バスで接続され、12.5 GB/s の実効帯域で通信が可能です。


ニューラルネットワークの推論演算

TPU の設計思想を理解するために、まずは NN の動作にはどのような計算が必要とされるのかを見てみましょう。

TensorFlow Playground で二重らせん問題を解く(ここをクリックして試せます)
この TensorFlow Playground の例では、NN を学習させることで、画面右の平面上にある個々の点がブルーとオレンジのどちらのグループに属するか識別できるようになります(このデモについて詳しくはこの記事を見てください)。

こうして学習させた NN を実際に使い、データを分類したり未知の値を推測したりすることを推論(inference)と呼びます。推論では、NN に含まれる個々のニューロンについて以下の計算処理を行います。

  • 入力データ x と、ニューロン間の接続の強弱を表すパラメータ w の間の乗算(multiply)
  • 乗算結果を加算(add)ニューロンの状態をひとつの値に集約する
  • ReLUSigmoidtanh などの活性化関数(activation function)を適用し、ニューロンのふるまいをコントロールする
Calculations_in_Neural_Network (3).gif
ニューラルネットワークの推論では、入力データにパラメータをかけ合わせ、
その合計に活性化関数を適用する
例えば、上手のように 3 つの入力値と 2 つのニューロンからなる全結合型の単層 NN の場合、合計で 6 回の掛け算を入力とパラメータの間で行い、その結果を合計して 2 つの出力を得ます。この乗算と加算は、行列積(matrix multiplication)として表すことができます。その結果が活性化関数に渡される流れです。より複雑な構造の NN の場合でも、この行列積が計算処理でもっとも負荷の高い部分となります。

では、実運用環境ではどれくらいの量の行列積が必要とされるのでしょうか。2016 年 7 月、Google では実運用サービスで利用されるおもな 6 種類の NN アプリケーションについて、それらのパラメータの数を集計しました。以下の表にその結果がまとめられています。

NN の種類NN の層の数パラメータの数導入規模
MLP0520M61%
MLP145M
LSTM05852M29%
LSTM15634M
CNN0168M5%
CNN189100M
(MLP: Multi Layer Perceptron, LSTM: Long Short-Term Memory, CNN: Convolutional Neural Network)

この表にある通り、個々の NN には 500 万〜 1 億個のパラメータが含まれます。NN を用いて推論を 1 回実行するには、これらのパラメータと入力データの間で乗算と加算を繰り返し、さらに活性化関数を適用する必要があります。

つまり NN を使おうとするたびに、数 100 万〜数 1000 万回の演算を繰り返さなくてはなりません。そこで TPU では、この膨大な演算を一般的な 32-bit や 16-bit の浮動小数点演算として CPU や GPU で実行する代わりに、よりサイズが小さくて高速な整数演算で置き換える量子化(quantization)と呼ばれる手法を導入しました。これにより、NN の推論に必要とされるメモリと計算資源を大幅に節約できます。


ニューラルネットワークの量子化

例えば外出中に雨が降り出したら、それが小雨なのか本降りなのかは気になりますが、「毎秒いくつの雨粒が地表に届いているか」まで気にする人はいません。これと同じように、NN の推論も実は 32-bit や 16-bit といった計算精度を必要としないケースが大半です。ちょっとした工夫により、8-bit の整数演算でも十分な推論精度を得られます。

NN の量子化は、あらかじめ設定した最大値と最小値の間の値を 8-bit 整数で表し、パラメータのサイズを圧縮する手法です。より詳しくは、How to Quantize Neural Networks with TensorFlow で解説されています。
Screen Shot 2017-04-22 at 3.32.22 PM.png
TensorFlow での量子化サポート
この量子化を用いることで、NN の推論に必要な計算コストを大幅に下げられます。特にスマートフォンや組み込みシステムでの NN 導入には重要な技術です。例えば、広く使われている画像認識 NN モデルである  Inception モデルの場合、もともと 91 MB あるパラメータのサイズを、量子化によって 1/4 の 23 MBまで縮小できます。

メモリサイズだけではありません。浮動小数点演算を整数演算で置き換えることで、デジタル回路のサイズと電力消費を大幅に抑えられます。例えば、一般的な GPU は数 1000 個の 32-bit 浮動小数点乗算器を搭載する一方で、 TPU は 65,536 個の 8-bit 整数乗算器を搭載しています。つまり、推論精度のわずかな違いを許容するだけで 25 倍を超える数の乗算器を載せられるのです。


RISC と CISC と TPU の命令セット

TPU のもうひとつの重要な設計目標が、プログラマブルであることです。TPU は、どれか特定種類の NN のみ動かせるよう設計されているわけではありません。様々に異なる種類の NN モデルの計算処理を高速化できる柔軟性を備えています。

現代の多くの CPU は、 Reduced Instruction Set Computer (RISC) と呼ばれる設計思想に多大な影響を受けています。RISC CPU では、数多くのアプリケーションで共通して用いられる少数の簡単な命令(ロード、ストア、加算、乗算など)を命令セットとして定義し、それらをできるだけ高速に実行すべく CPU を設計します。一方、TPU では Complex Instruction Set Computer (CISC) と呼ばれる設計思想のもとで命令セットが定義されています。CISC では、より複雑な処理(乗算と加算を多数繰り返すなど)を個々の命令で実行できます。以下は、TPU のブロック図です。
Screen Shot 2017-04-07 at 7.48.29 AM.png
TPU Block Diagram
TPU には、おもな計算リソースとして以下の要素が配置されています。

  • Matrix Multiplier Unit (MXU):行列演算用の 65,536 個の 8-bit 積和演算器
  • Unified Buffer (UB): 24MB SRAM レジスタ
  • Activation Unit (AU): ハードウェアで実装された活性化関数

TPU では、これらの MXU、UB、および AU による計算の流れを指示する手段として、NN 推論専用の高レベル命令を十数個用意しています。以下に、そのうちおもな命令 5 つを示します。

TPU 命令機能
Read_Host_Memoryメモリからのデータ読み込み
Read_Weightsメモリからのパラメータ読み込み
MatrixMultiply/Convolveデータとパラメータ間の乗算と畳込み、および結果の加算
Activate活性化関数の適用
Write_Host_Memoryメモリへの結果の書き込み

この TPU 命令セットは、先に説明したような入力データとパラメータ間の乗算と活性化関数の適用など、 NN の推論に必要な計算処理に特化した命令セットとして定義されています。

この TPU のアーキテクチャについて、Norm は以下のように説明しています。

「全結合 NNや畳み込み NN などいろいろな種類がありますが、要するに NN の計算とは様々なサイズの行列演算の集まりです。たくさんの乗算と加算の結果を活性化関数へと流し込むことで、たくさんの線形演算の積み重ねから非線形なふるまいを得る。これが NN の本質であり、TPU のアーキテクチャはそれをハードウェアで表現したものです」(First in-depth look at Google's TPU architecture, the Next Platform より)

つまり TPU は、NN 計算のエッセンスとなるロジックをハードウェアで実装し、あらゆる NN モデルを表現できるプログラミング能力を備えています。また TPU のプログラミング環境として、Google では TensorFlow グラフからの API コールを TPU 命令へ変換するコンパイラとソフトウェア スタックを開発しました。

Screen Shot 2017-04-28 at 6.35.24 PM.png
TensorFlow から TPU を呼び出すソフトウェア スタック

Matrix Multiplier Unit による大規模並列処理

一般的な RISC CPU は、数値の乗算や加算といった単純な演算のための命令セットを備えます。こうしたプロセッサは、個々の命令ごとに単一の演算(スカラ値の演算)を実行するため、スカラ プロセッサ(scalar processor)も呼ばれます。

現代の CPU はギガヘルツ単位のクロックで動作するとはいえ、大規模な行列演算をスカラ プロセッサによる繰り返し処理でこなすにはとても長い時間がかかってしまいます。そこでそうした行列演算に対しては、たくさんのデータを同時並列に演算するベクタ プロセッサ(vector processor)がよく用いられます。CPU がサポートする SSEAVX などは、そうしたベクタ 演算命令セットの例です。また GPU が備える SM(streaming multiprocessors)も、1 つの GPUチップ上に数 1000 個のSMを並べることで、実質的にベクタ プロセッサとして動作します。これらのベクタ プロセッサを使えば、クロック サイクルごとに数 1000 回の演算を同時実行できます。

Screen Shot 2017-04-15 at 11.44.06 AM.png

一方 TPU は、クロック サイクルごとに数 10 万回の演算が可能なマトリックス プロセッサ(matrix processor/行列プロセッサ)として設計されています。これを文書印刷で例えるなら、一文字ずつタイプするのか、一行ずつ印字するのか、一ページずつ印刷するのかの違いに相当します。



マトリックス プロセッサによる行列演算は、
文字単位や行単位ではなくページ単位で文章を印刷するようなもの

TPU の心臓部、シストリック アレイ

この大規模マトリックス プロセッサを実装する方法として、TPU では CPU や GPU とはまったく方法論の異なるアーキテクチャ、シストリック アレイを採用しています。

CPU は汎用コンピュータであり、あらゆる種類の情報処理をこなせるよう設計されています。その汎用性を得るために、プログラムコードの命令にもとづいて ALU (Arithmetic Logic Units/演算装置)行った乗算や加算、論理積などの演算結果は、レジスタに逐一保存するという設計になっています。レジスタ上のデータに対して、プログラムコードが読み書きや演算を行いながら一連の処理を進める流れです。

これらレジスタ・ALU・プログラムコードの 3 つは、あらゆる用途に使えるという CPU の汎用性を実現する上で欠かせない構成要素であるものの、同時に CPU の電力消費と回路規模をぐんと押し上げる原因にもなっています。
Screen Shot 2017-04-27 at 11.38.05 PM.png
CPU や GPU では演算ごとにレジスタ読み書きが発生し、電力を消費する。
シストリック アレイでは多数の ALU 間を直接結ぶため、レジスタ読み書きは 1 回で済む
一方、TPU に備わるマトリックスプロセッサ MXU では、個々の ALU からの演算結果をレジスタに書き戻さず、次の演算の入力としてそのまま隣の ALU に渡すため、レジスタの読み書きは発生しません。MXU は NN の行列積と加算のためだけに設計されているので、多数の ALU を数珠つなぎにした非常にシンプルな回路構成を取ることができ、きわめて高い電力効率と演算速度を実現しています。
Systolic_Array_for_Neural_Network_1.gif
シストリック アレイによる入力データ(ベクタ)とパラメータ行列間の乗算
シストリック アレイのシストリックとは「心臓」を意味しており、あたかも心臓が血液を運ぶような動きでデータが演算器を流れるためそうした名前が付いています。MXU で用いられているシストリック アレイは、あらゆる種類の数値演算で高い性能を発揮できるわけではありません。これは設計上のトレードオフで、レジスタやプログラムコードがもたらす汎用性を制限する代わりに、もっとも高い電力効率と実装密度で行列積を計算するという目的に特化して設計されています。

Systolic_Array_for_Neural_Network_2.gif
シストリック アレイによる入力データ(行列)とパラメータ行列間の乗算
MXU のシストリック アレイは、256 x 256 = 65,536 個の ALU を備えます。つまり、8-bit 整数による乗算と加算をクロックの 1 サイクルごとに 65,536 回分いちどに実行できます。TPU は 700 MHz クロックで動作するので、700 MHz x 65,356 = 46 x 1012 回の乗算と加算を 1 秒間に実行します(92 Teraops per second)。

TPU の Matrix Multiplier Unit (MXU)
では、CPU、GPU、TPU とで、1 サイクルあたりの演算回数を比較してみましょう。


1 サイクルあたりの演算回数
CPU1〜2 回
CPU(ベクタ演算拡張)数 10 回
GPU数万回
TPU10 数万回(最大 12.8 万回)

ベクタープロセッサを搭載しない一般的な RISC CPU の場合、1 命令あたりの演算回数は 1 〜 2 回程度に留まります。一方、GPU では 1 命令あたり数 1000 回の演算が可能。TPU では、例えば MatrixMultiply 命令の実行時には、1 サイクルあたり 10 数万回(最大 12.8 万回)の演算をこなします。

この莫大な規模の行列演算のあいだ、個々の演算結果は 64,535 個の ALU 間で直接渡されるので、レジスタの読み書きは発生しません。これにより、電力効率と演算スループットの劇的な向上が可能になります。この CISC ベースのマトリックス プロセッサ設計により、TPU は一般的な CPU に比べて 83 倍、GPU と比べて 29 倍というケタ違いの電力性能比を達成しています。

Screen Shot 2017-05-10 at 8.35.37 AM.png
一般的な CPU や GPU と比較した TPU の電力性能比
(ログスケール、差分、加重平均)

「7 ms」のためのミニマル設計

NN の推論専用プロセッサをゼロから開発することで得られる最大のメリットのひとつは、「ミニマリスト」設計に徹せることです。TPU の論文から以下に引用します。

「CPU や GPU は、現代の汎用プロセッサに必要とされる様々な機能を実装する複雑なアーキテクチャを備えます。例えば、キャッシュ、分岐予測、アウトオブオーダー実行、マルチスレッド、投機プリフェッチ、アドレス計算、コンテキスト スイッチ等々。これらの機構のために多くのトランジスタと電力が費やされていますが、いずれもプロセッサの平均性能を改善するだけで、99パーセンタイルの性能(=性能のばらつきの低さ)の改善にはあまり寄与しません。TPU はシングルスレッド動作の特定用途向けプロセッサであり、これらの機構をすべて廃したミニマルな設計による多大なメリットが得られます」(8ページ)

CPU や GPU などの汎用プロセッサは、ありとあらゆるアプリケーションを相手に一定の性能を出す必要があります。そのため、上述のような多岐にわたる性能改善の機構が組み込まれて来ました。その副作用として、これらの汎用プロセッサでは、一定のレイテンシ制約のもとにNN の推論のスループットを上げることがとても困難です。

一方、TPU は NN の推論というひとつの処理のために徹底してミニマルかつ予測可能な設計がなされています。それを表す例として、TPU チップのレイアウトを見てみましょう。

Screen Shot 2017-04-06 at 8.31.40 PM.png
TPU チップのレイアウト
黄色 = 演算、 = データ、 = I/O、 = 制御)
これを CPU や GPU のレイアウトと比べると、赤で示される制御ロジック部分がぐんと小さいことに気づくはずです。汎用プロセッサでは、上述の複雑な機構のために制御ロジックが肥大化していますが、TPU の場合、制御ロジックの占める割合はチップ全体の 2 % に過ぎません。

大規模な ALU シストリック アレイやオンチップ メモリを搭載しながらも、TPU のチップは一般的な CPU や GPU に比べておよそ半分の大きさに過ぎません。LSI チップは、小さければ小さいほどより多くの数をシリコンウェハーから切り出せ、不良品の減少により歩留まりも上がります。その製造コストは面積のおよそ 8 倍に比例して減少するため、TPU のチップは格段に低いコストで製造されています。

また TPU では、NN の推論を一回実行するために必要な時間をきわめて正確に見積もることができます。よって、厳しいレイテンシ制約の下でも、チップ性能の理論上限に近いスループットをほぼすべての推論処理で得られます。例えば、前述した Google における NN アプリケーションのひとつ MLP0 では 7 ms というレイテンシ制限があり、これ以上の時間を推論のために割くことはできません。その制約下では、CPU や GPU と比べて TPU は 15 〜 30 倍のスループットを達成できます。

Screen Shot 2017-04-09 at 4.16.04 PM.png
7 ms レイテンシ制約下でのスループット(ログスケール)
(99th% response with MLP0: CPU = 7.2 ms, GPU = 6.7 ms, TPU = 7.0 ms)
Google では、NN の推論を数多くのエンドユーザー向けサービスに用いています。これらのサービスのレスポンスが伸びれば、ユーザーはすぐさまサービスを使わなくなるでしょう。そのため MLP0 アプリケーションでは、ユーザーエクスペリエンスを一定に維持するため、99 パーセンタイルのレスポンスについて推論のレイテンシが 7 ms を下回るよう厳格に制限されています。

以下のグラフは、Google の 6 つの NN アプリケーションにおいて、一定のレイテンシ制約下での性能(1 秒あたりの推論数)を CPU、GPU、として TPU 間で比べたものです。もっとも差の大きい CNN1 アプリケーションのケースでは、TPU は CPU 比で 71 倍の性能を記録しています。


Screen Shot 2017-04-07 at 9.53.57 AM.png
6 種類の NN アプリケーションにおける
CPU、GPU、および TPU の性能比較(ログスケール)

ニューラルネットのためのアーキテクチャ

この記事では、TPU の卓越した性能のカギが「NN の推論処理への徹底した特化」にあることを解説しました。パラメータの量子化をはじめ、CISC 命令セット、マトリックス プロセッサ、そしてミニマルな設計など、これらすべてが NN のためのアーキテクチャとして統合されています。Google は、NN によるコンピューティングのパラダイム シフトにおいて、TPU が重要な役割を担うと確信しています。そして今後数年にわたって、スマートで速く、低コストな各種サービスを TPU が支えていくと期待しています。


謝辞

この記事の執筆に際して、深い洞察とアドバイスを提供していただいた Zak Stone、Brennan Saeta、夏谷実さん、そして Alexandra Barrettに感謝を表します。


わずか 12 か月で 1 万を超えるコミットを受け、TensorFlow は大幅なパフォーマンス向上分散訓練サポートの追加iOS および Raspberry Pi への対応、広く使われているビッグデータ インフラストラクチャへのインテグレーションを実現してきました。

また、私たち Google は GoRustHaskell から TensorFlow へのアクセス手段を提供するとともに、最新のアート イメージ分類モデルをリリースし、さらには GitHubStack OverflowTensorFlow メーリング リストで膨大な数の質問にお答えしてきました。

TensorFlow は Google において、大規模な本番機能から探索的研究までのありとあらゆるものをサポートしています。

たとえば、私たちは最近、TensorFlow(および TensorFlow 専用のハードウェア アクセラレータである TPU : Tensor Processing Unit)を使用して、Google Translate の大幅な改良版をリリースしました。

一方、Magenta と呼ばれるプロジェクトでは、メロディーを作り出せる新しい強化学習ベースのモデルを開発しました。先ごろ Google Brain チームを訪れたある大学院生は、イメージに美術スタイルを自動的に与えることができる TensorFlow モデルを作りました。

DeepMind は、すべての研究用のエンジンとして TensorFlow を使うことを決定しました。同社は最近、生の波形データに基づいて音声や音楽を生成する魅力的なモデルを作り出しています。

私たち Google が特にすばらしいと考えているのは、TensorFlow を活用する動きが世界中の人々の間に広がりつつあることです。以下はその一例です。
  • オーストラリアの海洋生物学者たちは、絶滅の危機に瀕しているマナティー科の生態に関する理解を深めるため、TensorFlow を使って数万枚の高解像度写真からマナティーを見つけ出す作業を進めています。
  • 日本のある先進的なキュウリ農家は、大きさ、形、その他の特徴に基づいてキュウリを仕分けするモデルを TensorFlow で開発しています。
  • 放射線医たちは、医療用スキャナの画像からパーキンソン病の兆候を見つけるために TensorFlow を使っています。
  • サンフランシスコのベイエリアで働くデータ サイエンティストたちは、TensorFlow と Raspberry Pi を組み合わせてカルトレインの運行状況を追跡しています
私たちはこれまで、研究プロジェクトから本番システムまでの、Raspberry Pi のような最も小さいデバイスから GPU / TPU を満載したサーバー ファームに至るあらゆる規模のハードウェアに TensorFlow が対応できるようにしてきました。

しかし、TensorFlow は単なる 1 つのオープンソース プロジェクト以上の存在になっています。そのため、私たちは関連ソフトウェアと機械学習モデルのオープンソース エコシステムを全力で強化していきます。
  • TensorFlow Serving プロジェクトは、本番システムで TensorFlow モデルをサービングするプロセスを単純化します。
  • TensorFlow の “Wide and Deep” モデルは、古くから使われている線形モデルとディープ ニューラル ネットワークを結合させます。
  • クラウド環境で TensorFlow を使いたい人のために、マネージド サービスとして TensorFlow を提供する Cloud Machine LearningGoogle Cloud Platform に加わりました。
さらに、TensorFlow のモデル リポジトリはコミュニティの貢献によって成長を続けており、GitHub だけで TensorFlow 関係のリポジトリが 3,000 以上も作られています

TensorFlow コミュニティに参加するには、私たちの新しい Twitter アカウント(@tensorflow)をフォローするか、GitHub のプロジェクトに参加するか、Stack Overflow の Q&A で質問するか、コミュニティのディスカッション リストに参加してください。

私たちは、最先端プロジェクトや意欲的な研究、急成長を遂げているスタートアップ、学習用プロジェクトなどで TensorFlow を使用しているすべての人々に大変感謝しています。

また、コードベースに直接貢献していただいた方には特別な感謝の気持ちを捧げたいと思います。これからも世界中の機械学習コミュニティの協力を仰ぎながら、TensorFlow をより良いものにしていく所存です。


* この投稿は米国時間 11 月 9 日、TensorFlow の Product Manager である Zak Stone と、TensorFlow team によって投稿されたもの(投稿はこちら)の抄訳です。

- Posted by Zak Stone, Product Manager for TensorFlow, on behalf of the TensorFlow team