TPU論文の翻訳（１）
データセンター内での
Tensor Processing Unitのパフォーマンス解析
Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh Bhatia, Nan Boden, Al Borchers, Rick Boyle, Pierre-luc Cantin, Clifford Chao, Chris Clark, Jeremy Coriell, Mike Daley, Matt Dau, Jeffrey Dean, Ben Gelb, Tara Vazir Ghaemmaghami, Rajendra Gottipati, William Gulland, Robert Hagmann, C. Richard Ho, Doug Hogberg, John Hu, Robert Hundt, Dan Hurt, Julian Ibarz, Aaron Jaffey, Alek Jaworski, Alexander Kaplan, Harshit Khaitan, Andy Koch, Naveen Kumar, Steve Lacy, James Laudon, James Law, Diemthu Le, Chris Leary, Zhuyuan Liu, Kyle Lucke, Alan Lundin, Gordon MacKean, Adriana Maggiore, Maire Mahony, Kieran Miller, Rahul Nagarajan, Ravi Narayanaswami, Ray Ni, Kathy Nix, Thomas Norrie, Mark Omernick, Narayana Penukonda, Andy Phelps, Jonathan Ross, Matt Ross, Amir Salek, Emad Samadiani, Chris Severn, Gregory Sizikov, Matthew Snelham, Jed Souter, Dan Steinberg, Andy Swing, Mercedes Tan, Gregory Thorson, Bo Tian, Horia Toma, Erick Tuttle, Vijay Vasudevan, Richard Walter, Walter Wang, Eric Wilcox, and Doe Hyun Yoon
Google, Inc., Mountain View, CA USA
Email: {jouppi, cliffy, nishantpatil, davidpatterson} @google.com
To appear at the 44th International Symposium on Computer Architecture (ISCA), Toronto, Canada, June 26, 2017.
要旨
多くのシステム設計者は、コスト・エネルギー・パフォーマンスの主要な改善は、その領域に固有のハードウェアからもたらされなければならないと信じている。
この論文では、Tensor Processing Unit（TPU）と呼ばれるカスタムASICを評価する。このチップは、2015年以降、データセンターに配備され、ニューラルネットワーク（NN）の推論のフェーズを加速している。TPUの心臓部は、65TeraOps /秒（TOPS）のピーク・スループットを提供する65,536個の 8ビットMAC行列乗算ユニットと、ソフトウェアで管理される大きな(28MiB)チップ上のメモリーである。
CPUやGPUでは、時間に応じて変化する様々な最適化（キャッシュ、out-of-order実行、マルチ・スレッディング、マルチ・プロセッシング、プリフェッチなど）の機能を持っている。それらは、平均的なスループットを、レイテンシーの保障以上に重視するものだ。一方、TPUで採用された決定論的実行モデルは、我々のNNアプリケーションの99パーセントに相当する部分の、応答時間に対する要請に適している。
前述のような機能をTPUが持っていないことは、無数のMACと巨大なメモリがあるにもかかわらず、TPUが比較的小さく低電力である理由を説明する。
TPUを、同じデータセンター内に配置された最新のサーバクラスのIntel Haswell CPUとNvidia K80 GPUとを比較しよう。作業負荷としては、高レベルのTensorFlowフレームワークで書かれた、当社のデータセンターのNN推論に対する要求の95％を占める実動NNアプリケーション（MLP、CNN、およびLSTM）を使用した。
一部のアプリケーションでは使用率は低いにもかかわらず、TPUは現行のGPUまたはCPUに比べ平均で約15〜30倍高速で、TOPS /ワットは約30〜80倍高い。さらに、GPUのGDDR5メモリをTPUで使用すると、TOPSが3倍になり、TOPS /ワットがGPUの70倍近く、CPUの200倍になる。
キーワード：DNN, MLP, CNN, RNN, LSTM, neural network, domain-specific architecture, accelerator
1. ニューラル・ネットワーク入門
クラウド上の巨大なデータと無数のコンピュータとの相乗効果が、機械学習のルネッサンスを可能にしてきた。
特に、ディープ・ニューラル・ネットワーク（DNN）は、従来のアプローチに比べて、音声認識における単語誤り率を30％低下させ、この20年間で最大の成果を上げるなど、画期的な進歩をもたらした[Dea16]。 2011年以来の画像認識コンテストでは、エラー率を26％から3.5％に減らし[Kri12] [Sze15] [He16]、碁 では [Sil16]、人間のチャンピオンを打ち破った。
ニューラルネットワーク（NN）は、脳に似た機能の実現を目標とし、入力の重みづけられた和を非線形関数（max（0、value)）など）に適用するという、単純な人工ニューロンに基づいている。
これらの人工ニューロンは層に集められ、1つの層の出力はシーケンス内の次の層の入力になる。 DNNが「深い」というのは、この層が少数ではなく、もっと多いというところから来ている。クラウド上の大規模なデータが、追加の層や大規模の層からなる、より高度なレベルのパターンやコンセプトを捉えるためのより正確なモデルを構築することを可能にし、GPUがそれを開発する計算パワーを提供している。
現在、次の3種類のNNがよく使われている。
- マルチ・レイヤ・パーセプトロン（MLP）：それぞれの新しい層は、先行する層からのすべての出力（フルコネクトの）の重み付けられた和の非線形関数であり、重みを再利用する。
- 畳み込みニューラルネットワーク（Connolutional Neural Networks、CNN）：各後続層は、空間的に近くにある前の層からの出力の部分集合の、重みづけられた和の非線形関数の集合であり、重みも再利用される。
- リカレントニューラルネットワーク（RNN）：各後続層は、出力の重み付けされた和と前の状態の非線形関数の集合である。最も一般的なRNNはLong Short-Term Memory（LSTM）である。 LSTMの特徴は、次の層へ状態を渡すとき、何を忘れ、何を渡すべきかを決定することにある。重みは、時間のステップごとに再利用される。
それらは、通常、TensorFlow [Aba16]で書かれているが、そのコードは驚くほど短く、わずか100〜1500行である。我々のベンチマークは、ホストサーバー上で動作する大規模なアプリケーション、C ++なら、数千から数百万行のコードになる可能性がある大規模なアプリの小さな部分である。アプリケーションは、典型的には、ユーザーにサービスとして提供されており、その応答時間は厳しく制限されている。
それぞれのモデルには5M〜100Mの重みが必要で（表1の9番目の欄）、そのアクセスに多くの時間とエネルギーを必要とする。アクセスのコストを償却するために、推論や訓練中には、バッチを通じて、独立したサンプルの同じ重みが再利用され、それがパフォーマンスが向上させている。
- 推論アプリケーションは、多くの場合、ユーザーに直接利用されるため、通常、スループットより応答時間を重視する。
- レイテンシの制限の結果として、K80 GPUは推論のために多くは利用されておらず、それは、Haswell CPUより少し速いだけである。
- より小型で低消費電力のチップがあるにもかかわらず、TPUはK80 GPUの25倍のMACと3.5倍のオンチップメモリを備えている。
- TPUは、K80 GPUやHaswell CPUよりも推論で約15倍〜30倍高速である。
- 6つのNNアプリのうち4つは、TPUでメモリ帯域幅が制限されている。 TPUがK80 GPUと同じメモリシステムを持つように改訂された場合、TPUは、GPUとCPUより約30〜50倍高速となる。
- TPUの性能/ワットは現在の製品の30〜80倍である。 K80メモリを搭載した改訂版のTPUは70〜200倍優れたものになるだろう。
- ほとんどのアーキテクトはCNNを加速するが、それは、データセンター・ワークロードのわずか5％を占めているだけである。
表１
表1. TPUの作業負荷の95％を表す6つのNNアプリケーション（NNタイプごとに2つ）。列は、NN名・コード行数・ NNの型と層の数（FCはフルコネクト、Convはコンボリューション、Vectorは自明、PoolはTPU上で非線形にサイズを縮小するプーリング）。最後の列は、2016年7月にTPU上にデプロイされたアプリケーションのパーセント。DNNの1つはRankBrain [ Cla15]; LSTMの1つはGNM Translate [Wu16]のサブセット。1つのCNNはインセプションであり、もう1つはDeepMind AlphaGo [Sil16] [Jou15]である。
2. TPUの起源、アークテクチャー、実装
2006年の初めには、我々は、GoogleのデータセンターにGPU、FPGA、またはカスタムASICを導入することの議論を始めていた。我々は、特別なハードウェア上で実行できるアプリケーションで、大規模データセンターの余剰の能力を使用して、自由に仮想的に実行できるものは、ほとんどないと結論づけた。自由に実行するのは、難しいのだ。
ただ、こうした議論は、2013年には変更されることになった。この時、DNNが普及すれば、Googleデータセンターへの計算要求が倍増する可能性があり、この要求を従来のCPUで満たすには非常に高価になるだろうという予測を行なった。こうして、推論のためのカスタムASICを迅速に作成するという、最重要プロジェクトを開始した（訓練のために市販のGPUを購入した）。
目標はTPUで全推論モデルを実行して、ホストCPUとのやり取りを減らし、2013年の NNに必要なものではなく、2015年以降のNNのニーズに十分に柔軟に対応することだった。図1にTPUのブロック図を示す。
図１
図1. TPUブロック図。主な計算部分は、右上の黄色の行列乗算ユニット。その入力は青色のWeight FIFOと青色のUnified Buffer（UB）で、その出力は青色のAccumulators（Acc）。黄色のActivation Unitは、UBに向かうAcc上の非線形関数を実行する。
TPU命令は、ホストからPCIe Gen3x16バスを介して命令バッファに送られる。内部ブロックは、通常、256バイト幅のパスで接続される。
右上隅から始まる行列乗算ユニットはTPUの中心である。これには、符号付きまたは符号なし整数の8ビット乗算と加算を実行できる256x256 MACが含まれている。 16ビットの結果は、行列ユニットの下にある4MiBの32ビットアキュムレーターに集められる。 4MiBは4096を表し、256要素の32ビットアキュムレータ行列ユニットである。これは、クロックサイクルごとに256要素の部分和を1つ生成する。
1バイトあたりの演算がピーク性能（第4章の図の、屋根状のグラフのトップ）では、1350に達する必要があることに、まず注目して4096を選んだ。これを2048までに丸めて、それを複製して、コンパイラーが、ピーク時にはダブルバッファリングを使用できるようにした。
8ビットの重みと16ビットの活性化関数の組み合わせを使用する場合（またはその逆の場合）、行列ユニットは、半分のスピードで計算し、両方が16ビットの場合は1/4のスピードで計算する。
行列ユニットは、クロックサイクルごとに256個の値を読み書きし、行列の乗算または畳み込みのいずれかを実行できる。行列ユニットは、1つの64KiBの重みのタイルと、（タイルをシフトするのに要する256サイクルを隠す）ダブルバッファリングのための1つのタイルを保持する。
このユニットは密な行列用に設計されている。製品配備に要する時間の理由から、疎な行列に対するアーキテクチャサポートは省略されている。 疎な行列演算のサポートは、将来の設計においてもっとも重要なものとみなされるだろう。
ウェイトFIFOは4タイルの深さを持つ。中間結果は24 MiBの内蔵ユニファイド・バッファーで保持される。このバッファーは行列ユニットへの入力として使用できる。プログラマブルDMAコントローラは、CPUホストメモリとユニファイドバッファとの間でデータを転送する。
図2は、TPUダイのフロアプランを示している。 24 MiB ユニファイド・バッファーは、ダイのほぼ3分の1を占め、行列乗算ユニットは1/4を占める。それで、データパスはダイのほぼ3分の2を占めることになる。 24 MiBサイズは、部分的には、ダイ上の行列ユニットのピッチと一致するように選択され、コンパイラを簡素化するために短い開発スケジュールが与えられた（セクション7を参照）。コントロールはわずか2％である。
図２
図2 TPUダイのフロアプラン。色付けは、図１に従っている。ライト（ブルー）データバッファはダイの37％、ライト（黄）は30％、ミディアム（グリーン）I / Oは10％、ダーク（赤）コントロールはちょうど2％。 コントロール部分は、CPUやGPUより大きい（設計がはるかに難しい）。
図3に、プリント回路上のTPUを示す。TPUは、SATAディスクのように、既存のサーバーに挿入される。
図３
図3. TPUプリント回路基板。スロットに挿入することができる。
- Read_Host_Memory命令は、CPUホストメモリからユニファイドバッファ（UB）にデータを読み込む。
- Read_Weights命令は、ウェイトメモリからウェイトFIFOへと行列ユニットへの入力として読み込む。
- MatrixMultiply / Convolve命令を使用すると、行列ユニットは、ユニファイドバッファからアキュムレータへの行列乗算またはコンボリューションを実行する。行列操作は、可変サイズのB * 256の大きさの入力を取り、それを256×256の定数の重みの入力で乗算し、B個のパイプラインサイクルを完了して、B * 256の大きさの出力を生成する。
- Activate命令は、ReLU、Sigmoidなどのオプションを使用して、人工ニューロンの非線形関数を実行する。その入力はアキュムレーターで、その出力はユニファイドバッファーである。また、非線形関数ロジックに接続されているため、ダイ上の専用ハードウェアを使用してコンボリューションに必要なプーリング演算を実行することもできる。
- Write_Host_Memory命令は、ユニファイドバッファーからCPUホストメモリにデータを書き込む。
その他の命令は、他のホストメモリの読み書き、コンフィグの設定、同期の2つのバージョン、ホストへの割り込み、デバッグタグ、nop、および停止である。
CISC の行列乗算命令は12バイトで、そのうち3バイトはユニファイドバッファのアドレスで、 2バイトははアキュムレータアドレスで、 4バイトは長さ（畳み込みの場合は2次元の）である。残りはオペコードとフラグに当てられている。
TPUマイクロアーキテクチャの哲学は、行列ユニットをビジー状態に保つことである。これらのCISC命令には4ステージ・パイプラインが使用され、各命令は別々のステージで実行される。 MatrixMultiply命令で実行をオーバーラップさせることによって、他の命令の実行を隠す計画であった。この目的のために、Read_Weights命令は、アドレスを送信した後で、ウェイトがウェイトメモリからフェッチされる前に完了できるという点で、アクセスと実行を分離するという哲学[Smi82]に従っている。入力のアクティベート、あるいは、ウェイトデータが準備できていない場合には、行列ユニットは停止する。
ステージごとに1クロックサイクルの従来のRISCパイプラインとは異なり、CISC命令は何千ものクロックサイクルでステーションを占有することができるため、パイプラインのオーバーラップ図は明確ではない。興味深いケースは、次の層の行列乗算を開始する前に、1つのネットワーク層のアクティベーションが完了する必要がある場合に発生する。行列ユニットには、「遅延スロット」があって、行列ユニットが、安全にユニファイド・バッファから読み込む前に、そこで明示的な同期を待つ。
大きなSRAMは、算術演算よりもはるかに多くの電力を使用するので、行列ユニットは、ユニバーサル・バッファ[Kun80] [Ram91] [Ovt15b]の読み書きを減らしてエネルギーを節約するために、シストリック実行を使用する。
図4は、データが左から流れ、重みが上からロードされることを示している。与えられた256要素の積和演算は、対角線に沿って行列を移動する。重みはプリロードされ、新しいブロックの最初のデータの進行に沿って有効になる。制御とデータは、256個の入力が一度に読み取られ、256のアキュムレータのそれぞれの1つの位置を即時に更新するという錯覚を与えるのだが、パイプライン化されている。正確さの観点からは、ソフトウェアは行列ユニットのシトリック特性を認識していないのだが、性能のために、ユニットのレイテンシは気にかけている。
図４
図4.乗算ユニットのシトリックデータフロー。サーバ内のSATAディスク用のソフトウェアは、PCIe Gen3 x16を使用している。各256B入力が一度に読み取られるという錯覚を与え、256個のアキュムレーターRAMのそれぞれの1つの場所を即座に更新する。
GPUと同様に、TPUスタックはユーザスペース・ドライバとカーネル・ドライバに分割されている。カーネル・ドライバは軽量で、メモリ管理と割り込みのみを処理する。それは長期的な安定性のために設計されている。
ユーザースペース・ドライバーは頻繁に変更され、TPUの実行を設定および制御し、データをTPU用の順序に再フォーマットし、API呼び出しをTPU命令に変換し、アプリケーション・バイナリに変換する。
ユーザースペース・ドライバーは、最初に評価されたときにモデルをコンパイルし、プログラムイメージをキャッシングし、重みのイメージをTPUの重みメモリに書き込む。 2番目以降の評価は最高速度で実行される。
TPUはほとんどのモデルを入力から出力まで完全に実行し、TPUの計算時間とI / O時間の比を最大化する。計算は、一度に1つのレイヤーで行われることが多く、重複して実行されるため、行列乗算ユニットでクリティカルパス以外の演算を隠すことができる。
3. CPU, GPUとTPU プラットフォーム
表1の6つの製品版のアプリケーションが、この論文のワークロードである。上記のように、これらの6つは、GoogleのデータセンターでのTPU使用の95％を代表している。皮肉なことに、AlexNetやVGGのようなポピュラーな小さなDNNを導入して測定することは、製品版のマシンでは困難である。しかし、我々のCNNの1つは、広く使用されているInception V2から派生している。
ベンチマークプラットフォームは、2015年にTPUが導入された時点で利用可能だったサーバクラスのコンピュータである。この制限は、内部SRAMと同じように、TPUのような外部DRAMメモリも、少なくともSECDED保護機構を含む必要があることを意味した。こうして、NVIDIA Maxwell GPUなどのいくつかの選択肢は覗かれた。当社がそれらを購入して配備するためには、それらはきちんと構成されたマシンでなければならず、ベンチマークを勝ち取るためだけに組み立てられた不恰好なものであってはならなかった。
表2に我々の選択肢を示す。従来のCPUサーバーは、インテルの18コア、デュアルソケットのHaswellプロセッサーに代表されている。このプラットフォームは、GPUまたはTPUのホストサーバでもある。 HaswellはIntel 22nmプロセスで製造された。 CPUとGPUはともに非常に大きなダイである：約600 mm2！
NNアプリのデータセンターではほとんど発生しないため、2.3 GHzのCPUクロックレートには、ターボモードが含まれていない。
Haswellは、NNアプリでよく使用されるAVX命令をプログラムが使用するかどうかによって、クロック速度が異なる。ターボモードの高いクロックレート（AVXを回避するプログラム用）は、すべてのコアを使用しない場合に発生する。このように、ターボモードがデータセンターではまれにしか起きない別の理由は、アプリで通常はすべてのコアを使用することに加えて、アイドル状態のコアを埋めるために他のデータセンタージョブを実行できるからである。
GPUアクセラレータはNvidia K80である。各K80カードには2つのダイがあり、内部メモリとDRAMにSECDEDがある。 Nvidiaによれば、「K80 Acceleratorは、より少数のより強力なサーバーでアプリケーションのパフォーマンスを提供することで、データセンターのコストを大幅に削減する」[Nvi16] NNの研究者は2015年には、K80を頻繁に使用していた。2016年9月に始まった、新しいクラウドベースのGPUサービスを提供するチップにK80は、選ばれた[Bar16]。
最大8台のK80ダイを、このサーバの4枚のカードに取り付けることができる。これが、我々のベンチマークの設定である。
K80は、クロックレートを875MHzにあげるブーストモードを提供している。 HaswellのTurboモードはハードウェアによって制御されるため、チップ温度が大幅に上昇する前に短いバーストでしか動作しない。しかし、K80のブーストモードはソフトウェアドライバ[Nvi15]で制御されているため、少なくとも数百ミリ秒持続する。したがって、K80の電源と冷却は、基本的に常にブーストモードで実行されているかのように設定する必要がある。そうしないと、チップが熱くなりすぎる可能性がある。
このプラットフォームでは、ブーストモードを有効にするとK80カードの数を減らす必要があり、所有コストに悪い影響が出る。こういう理由で、ブーストモードは無効になっている。この制限により、ピーク帯域幅とTOPSが減少することになる（表2のキャプションを参照）。 ８章では、ブーストモードを有効にした場合を検証する。
GPUアクセラレータはNvidia K80である。各K80カードには2つのダイがあり、内部メモリとDRAMにSECDEDがある。 Nvidiaによれば、「K80 Acceleratorは、より少数のより強力なサーバーでアプリケーションのパフォーマンスを提供することで、データセンターのコストを大幅に削減する」[Nvi16] NNの研究者は2015年には、K80を頻繁に使用していた。2016年9月に始まった、新しいクラウドベースのGPUサービスを提供するチップにK80は、選ばれた[Bar16]。
最大8台のK80ダイを、このサーバの4枚のカードに取り付けることができる。これが、我々のベンチマークの設定である。
K80は、クロックレートを875MHzにあげるブーストモードを提供している。 HaswellのTurboモードはハードウェアによって制御されるため、チップ温度が大幅に上昇する前に短いバーストでしか動作しない。しかし、K80のブーストモードはソフトウェアドライバ[Nvi15]で制御されているため、少なくとも数百ミリ秒持続する。したがって、K80の電源と冷却は、基本的に常にブーストモードで実行されているかのように設定する必要がある。そうしないと、チップが熱くなりすぎる可能性がある。
このプラットフォームでは、ブーストモードを有効にするとK80カードの数を減らす必要があり、所有コストに悪い影響が出る。こういう理由で、ブーストモードは無効になっている。この制限により、ピーク帯域幅とTOPSが減少することになる（表2のキャプションを参照）。 ８章では、ブーストモードを有効にした場合を検証する。
ベンチマークされたサーバ1台あたりのダイ数は2〜8の間で変化するため、通常、1ダイあたりの標準化された結果（図5-8、図10-11、表3,4、および6）を示している。ただ、システム全体での結果を示す場合もある（図9）。この区別がはっきりしていることを願う。
表２
表2. ベンチマークされたサーバーは、Haswell CPU、K80 GPU、およびTPUsを使用した。 Haswellは18個のコアを持ち、K80は13個のSMXプロセッサを持っている。
図10は電力を測定したものである。低消費電力のTPUにより、ハイパワーGPUよりもラック・レベルの密度が向上している。 TPUの8 GiB DRAMは、ウェイトメモリである。 GPUブーストモードは使用されていない（8章）。 SECDECなしでブーストモードを使用すると、K80帯域幅が240から160に減少する。ブーストモードなしだと、シングルダイ対デュアルダイのパフォーマンスは、K80ピークトップで8.7から2.8に減少する。 （* TPUダイはHaswellダイサイズの半分以下。）
4. パフォーマンス： ルーフライン、レスポンス・タイム、 スループット
このシンプルなビジュアルモデルは完璧ではないが、パフォーマンスのボトルネックの原因についての洞察を提供する。モデルの背後にある仮定は、アプリケーションがオンチップ・キャッシュに収まらないため、計算が制限されているか、メモリの帯域幅が制限されているかということである。
HPCの場合、Y軸は1秒あたりの浮動小数点演算のパフォーマンスである。ピークの計算速度は屋根の「平らな」部分を形成する。 X軸は、アクセスされるDRAMバイトごとに浮動小数点演算として測定される動作の頻度である。
メモリ帯域幅は1秒あたりのバイト数で、（FLOPS /秒）/（FLOPS / Byte）= Bytes / secであるため、屋根の「斜め」の部分になる。十分な操作の強度がなければ、プログラムはメモリ帯域幅に束縛されており、屋根の傾いた部分の下に住んでいることになる。
図５
図5. TPU（ダイ）ルーフライン。取り出したウェイトメモリのバイトあたり1350回の操作では、分水嶺は、はるかに右側にある。
NNアプリケーションが量子化されるとき、TPUにルーフライン・モデルを使用するために、最初に浮動小数点演算を整数演算に置き換える。ウェイトは通常NNアプリケーション用のオンチップ・メモリに収まらないため、第2の変更点は、読取りウェイトのバイトごとに操作強度を整数操作に再定義する（表1の10番目の列を参照）。
図5は、ログ・ログ・スケール上の単一のTPUダイのルーフライン・モデルを示す。 TPUはルーフラインの長い「傾いた」部分を持っている。ここでは、操作の強度とは、パフォーマンスが計算のピークではなく、メモリー帯域幅によって制限されることを意味している。
6つのアプリケーションのうち5つが天井に頭を出している。MLPとLSTMはメモリにバインドされていて、CNNは計算にバインドされている。非常に高い操作強度にもかかわらず、CNN1はわずか14.1TOPで動作し、CNN0は86TOPで動作する。
表3は、TPUの動作を部分的に可視化するパフォーマンス・カウンタに基づいて、CNN1で何が起こったかを説明している。 TPUは、CNN1（列7、行1）の行列操作を実行するサイクルに、半分以下を費やしている。
これらの各動作サイクルでは、CNN1のいくつかの層が浅いフィーチャ深度を有するため、65,536MACの約半分しか有用な重みを保持していない。サイクルの約35％は、メモリからマトリックスユニットにロードされるウェイトを待つのに費やされている。
これは、わずか32の動作強度で動作する4つの完全に接続されたレイヤーで発生する（セクション8の最後の「誤謬」を参照のこと）。これで、行列関連のカウンターで説明されていないサイクルの約19％を残す。 TPU上では重複して実行されているため、これらのサイクルを正確に把握することはできないのだが、サイクルの23％にはパイプラインのRAW依存性があり、1％はPCIeバス上の入力に時間を費やしている。
表３
表3. ハードウェア・パフォーマンス・カウンタに基づくNNワークロードのTPUパフォーマンスを制限する要因。 行1,4,5および6は合計100％であり、マトリックス単位の活性の測定値に基づく。行2と3は、アクティブ・サイクルで有効な重みを保持するマトリックス・ユニットの64Kの重みをさらに細分化している。我々のカウンターでは、行列ユニットが行6でアイドル状態になっている時間を正確に説明することはできない。行7および8は、RAWパイプライン・ハザードおよびPCIe入力ストールを含む2つの理由によるカウンタを示している。行9（TOPS）は実動コードの測定値に基づいており、他の行はパフォーマンスカウンタの測定値に基づいているため、完全に一貫しているわけではない。ホストサーバーのオーバーヘッドはここでは除外されている。 MLPとLSTMはメモリ帯域幅に制限があるが、CNNは制限されていない。テキスト本文で、CNN1の結果を説明する。
図６
図6. インテル・ハスウェルのCPU（ダイ）屋根の分水嶺は13操作/バイトで、図５よりもはるかに左側に残っている。 LSTM0とMLP1は、Haswellの方がK80よりも高速だが、他のDNNでは逆である。
図７
図6と図7は、1つのHaswellダイと1つのK80ダイの屋根を示している。 6つのNNアプリケーションは、一般に、図5のTPUよりも天井の下にある。応答時間が理由である。これらのNNアプリケーションの多くは、エンドユーザ向けのサービスの一部である。研究者は、応答時間のわずかな増加が顧客にサービスを利用しなくなることを証明している[Sch09]。したがって、訓練は、応答時間のデッドラインが厳しくない可能性があるのだがが、推論は、通常は、応答時間に厳しい。つまり、推論はスループットよりもレイテンシを優先する[Pat04]。
表4は、アプリケーション開発者が要求していた、HaswellのMLP0とK80 [Dea13]の99％パーセンタイル応答時間制限の影響を示している。応答時間制限が緩和された場合、MLP0で達成可能な最高のスループットのそれぞれ42％と37％で動作する（1秒あたりの推論数と7 msのレイテンシには、サーバホスト時間とアクセラレータ時間が含まれる）。したがって、CPUとGPUのスループットは非常に高いものの、応答時間制限を満たさない場合は無駄になる。
これらの境界もTPUに影響するが、表4の80％ではMLP0の最高スループットに非常に近い値で動作している。シングルスレッドのTPUには、99％パーセンタイルのケースではなく平均的なケースを改善するための、トランジスターとエネルギーを消費する洗練されたマイクロアーキテクチャーを持っていない。それは次のようなものを含んでいるのだが、キャッシュ、分岐予測、投機的プリフェッチ、アドレス統合、マルチスレッディング、コンテクストの切り替え、そうした機能は、TPUにはない。
最小主義は、ドメイン・スペシフィックなプロセッサにとっては美徳である。
表3は、TPUのパフォーマンスを示しているが、ホストサーバーの時間を考慮していない。ホスト側の時間は、アプリケーションのホスト共有部分を実行する時間と、TPUと通信する時間とに分けられる。表5は2番目の部分を示しているのだが、最初の部分を示すのは難しい。
キューイングは、理論的には、入力キューが長いとスループットが向上する。これは、コンピュータが決してアイドル状態にならないようにして、応答時間が長くすることを保証するからである。したがって、ほとんどのアプリケーションでは、入力キューが空のままである。ただし、ああ、TPUがアイドル状態にあるのは、CPUがアプリケーションの一部を実行するのを待っているか、CPUが空の入力キューによってアイドル状態になっている場合である。
表6の一番下の行は、2つのアクセラレータとCPUのホストサーバーオーバーヘッドを含む、ダイの相対的な推論性能のを示している。最後の一つ前の列は、6つのNNアプリケーションの相対的性能の幾何平均を示した。これは、K80ダイがHaswellダイの1.1倍の速度であること、TPUダイが14.5倍高速であること、TPU GPUダイの13.2倍の速さであることを示している。図8は相対速度を視覚的に示している。
実際に実行されるプログラムの組み合わせがわからないときは、システム設計者は幾何平均を使用することを想起してほしい[Hen 18]。しかし、この研究では、我々は組み合わせを知っている（表1）。実際の組み合わせを使用した表6の最後の欄の加重平均は、GPUを1.9倍に、TPUを29.2倍に増加させるため、TPUのダイはGPUのダイの15.3倍になる。
表４
表4. バッチサイズとしてのMLP0の99％応答時間およびダイのスループット（IPS）は、MLP0に応じて異なる。許容可能な最長レイテンシは7ミリ秒である。 GPUとTPUの最大MLP0スループットは、ホストサーバーのオーバーヘッドによって制限されている。バッチサイズが大きいほどスループットは向上するが、本文で説明されているように、応答時間が長く限界を超えると、CPUとGPUは、効率の低い、小さなバッチサイズを使わなければいけなくなる（16対200）。
表5. ホストCPUがTPUと相互作用する時間（TPUパフォーマンスカウンターからの）TPU実行時間のパーセントで表される時間。この分数は、CPUとTPUがPCIeバスを介して通信している時間であり、CPUがアプリケーションの一部を実行しているがTPUとやり取りしていない時間は含まれていない。本文で説明しているように、TPUで、CPUがアイドルであるか、あるいは、アプリケーションで作業しているかを測定することは難しい。
表５
表5. ホストCPUがTPUと相互作用する時間（TPUパフォーマンスカウンターからの）TPU実行時間のパーセントで表される時間。この分数は、CPUとTPUがPCIeバスを介して通信している時間であり、CPUがアプリケーションの一部を実行しているがTPUとやり取りしていない時間は含まれていない。本文で説明しているように、TPUで、CPUがアイドルであるか、あるいは、アプリケーションで作業しているかを測定することは難しい。
表６
表6. NNワークロードのCPUに対するK80 GPUダイとTPUダイパフォーマンスの幾何平均（GM）と加重平均(WM)（表1の6つのアプリの実際の組み合わせを使用している）。 GPUとTPUの相対的なパフォーマンスには、ホストサーバーのオーバーヘッドが含まれている。 MLPとCNNはTPU上で良好に動作する。表4は、TPUがより大きなバッチサイズを持ち、時間制限を満たし、1バイト当たりの処理（表1）を増加させることができること、または同等の動作あたりのメモリアクセスを削減できることを説明している。また、CNNはその性質上、重みの再利用がより大きく、したがってバイト当たりの操作がより高い。従って、TPUのより低いメモリ帯域幅は、CNN性能を著しく損なうことはない。
図８
5. コスト・パフォーマンス, TCO, パフォーマンス/ワット
ただし、電力はTCOと相関があり、サーバーごとにワットを公開できるため、この論文では、パフォーマンス/ TCOの代わりとしてパフォーマンス/ワットを使用する。この章では、単一のダイではなく、サーバー全体を比較する。表2は、「ベンチマークされたサーバー」を列にリストしている。
総パフォーマンス/ワットの場合、K80サーバーは、Haswellの1.2 - 2.1X である。インクリメンタル性能/ワットの場合、Haswellサーバの電力を省略すると、K80サーバは1.7〜2.9Xとなる。
TPUサーバはHaswellよりも総性能/ワットが17〜34倍優れているため、TPUサーバはK80サーバの14〜16倍の性能/ワットになる。カスタムASICに対するGoogleの検証では、相対増分性能/ワットは、TPUを41〜83とし、TPUをGPUの性能/ワットの25〜29倍に上げる。
図９
コメント
コメントを投稿