> [!abstract] 概要(abstract の日本語訳) > 多くのアーキテクトは、コスト・エネルギー性能の大幅な改善が今後はドメイン固有ハードウェアからしか得られないと考えている。本論文は、2015年からデータセンターに配備され、ニューラルネットワーク(NN)の推論フェーズを加速するカスタムASIC——Tensor Processing Unit(TPU)と呼ぶ——を評価する。TPUの中核は65,536個の8ビットMACからなる行列乗算ユニットであり、ピークスループット92 TeraOps/秒(TOPS)と大容量(28 MiB)のソフトウェア管理オンチップメモリを持つ。TPUの決定的実行モデルは、平均スループットを保証レイテンシより優先するCPU・GPUの時間変動型最適化よりも、我々のNNアプリケーションが要求する99パーセンタイル応答時間要件によく適合する。この種の機構を持たないことが、多数のMACと大容量メモリを持ちながらTPUが比較的小さく低電力である理由を説明する。我々はTPUを、同じデータセンターに同時期配備されたサーバークラスのIntel Haswell CPUおよびNvidia K80 GPUと比較する。高水準のTensorFlowフレームワークで書かれた我々のワークロードは、データセンターのNN推論需要の95%を占める本番NNアプリケーション(MLP・CNN・LSTM)を用いる。一部アプリケーションで利用率が低いにもかかわらず、TPUは同時期のGPUまたはCPUより平均して約15~30倍高速であり、TOPS/Wattは約30~80倍高い。さらに、TPUにGPUのGDDR5メモリを用いれば達成TOPSは3倍になり、TOPS/WattはGPU比ほぼ70倍・CPU比200倍まで上がる。 ## 論文情報 - タイトル: In-Datacenter Performance Analysis of a Tensor Processing Unit - 著者: Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson ほか73名([[Google]], Inc., Mountain View, CA) - 媒体: ISCA '17(44th International Symposium on Computer Architecture), 2017年6月24-28日, Toronto, ON, Canada - URL: https://doi.org/10.1145/3079856.3080246(同一内容の arXiv 版: https://arxiv.org/abs/1704.04760) - 概要: Google初のカスタムASIC DSAである TPU v1(推論専用第1世代)の内部構成・性能・電力効率を、本番6週間の推論ワークロード実測に基づき、同時期のIntel Haswell CPU・NVIDIA K80 GPUと比較して報告する一次資料。 ## 問題設定 2013年、音声検索を1日3分利用するユーザーが増えるという試算が、データセンターの計算需要をDNNの推論だけで倍増させ、従来型CPUでは非常に高コストになると示された。これを受けて、推論専用のカスタムASICを短期間で作る高優先度プロジェクトが始まり、目標は GPU比10倍のコスト性能改善に置かれた。この要求のもと、TPUは設計・検証・製造・データセンター配備までを15か月で完了した。ホストCPUと密結合させると配備が遅れるリスクがあるため、TPUはGPUと同様にPCIe I/Oバス上のコプロセッサとして設計され、ハードウェア設計とデバッグを簡素化するためTPU自身が命令をフェッチせず、ホストサーバーが命令を送出する。この点でTPUはGPUよりもFPU(浮動小数点コプロセッサ)に近い。目標はTPU単体で推論モデル全体を実行してホストCPUとの対話を減らし、2013年当時のNN要求だけでなく2015年以降のNN要求にも合う柔軟性を持たせることだった。 ## 提案手法 ### アーキテクチャ TPU(図1)の主要ブロックは以下のとおり。 **Figure 1: TPUブロック図** ![[_attachments/isca2017-tpu/fig01-block-diagram.png]] (Figure 1. 主要計算ブロックは黄色のMatrix Multiply Unitであり、入力は青のWeight FIFOとUnified Buffer、出力は青のAccumulators。黄色のActivation Unitが非線形関数をAccumulatorsに適用し、結果はUnified Bufferへ戻る。Source: Figure 1.) - **Matrix Multiply Unit**: 256×256(65,536個)の8ビット整数MACからなり、符号付き/符号なし整数の乗加算を実行する。1サイクルに256要素の部分和を1本生成し、行列乗算または畳み込みを実行できる。8ビット重み・16ビット活性化(またはその逆)混在時は半速、両方16ビットなら4分の1速で動作する。密行列専用に設計され、時間制約のためスパース対応は見送られた。 - **Accumulators**: 4 MiB(4096個×256要素×32ビット)。演算強度を最大化するroofline ridge point(~1350)の目標から2048に切り上げ、コンパイラがダブルバッファリングできるようさらに倍にして4096個とした。 - **Unified Buffer**: 24 MiBのオンチップSRAM。中間活性化値を保持し、Matrix Multiply Unitへの入力になる。ダイの約1/3を占め、Matrix Multiply Unit側のピッチに合わせて選定された。 - **Weight Memory**: 8 GiBのオフチップDRAM(重みは読み出し専用)。オンチップのWeight FIFO(4タイル深さ)経由でMatrix Multiply Unitへ供給される。 - 28 nmプロセス、700 MHz、ダイサイズはHaswellサーバーCPU(662 mm²)の半分未満。図2のフロアプランでは、データパス(Unified Buffer+Matrix Multiply Unit)がダイの約67%、I/Oが10%、制御はわずか2%(CPUやGPUでは制御がずっと大きく複雑)。 **Figure 2: TPUダイのフロアプラン** ![[_attachments/isca2017-tpu/fig02-floorplan.png]] (Figure 2. Unified Buffer(96K×256×8b = 24 MiB)がダイの29%、Matrix Multiply Unit(256×256×8b = 64K MAC)が24%、Accumulators(4K×256×32b = 4 MiB)が6%、Activation Pipelineが6%、Control 2%、PCIe Interface 3%、DRAM port(ddr3)各3%、Host Interf. 2%、Misc. I/O 1%。Source: Figure 2.) **Figure 3: TPUプリント基板** ![[_attachments/isca2017-tpu/fig03-pcb-photo.png]] (Figure 3. サーバーのSATAディスク用スロットに挿入できる基板形状。Source: Figure 3.) ### 命令セットと実行モデル TPU命令はPCIe Gen3 x16バス経由でホストから命令バッファへ送られ、CISCの伝統に従いrepeatフィールドを持つ。命令あたりの平均CPIは典型10~20。主要命令は5つ: Read_Host_Memory(ホストメモリ→Unified Buffer)、Read_Weights(Weight Memory→Weight FIFO)、MatrixMultiply/Convolve(Unified Buffer→Accumulatorsへの行列乗算/畳み込み)、Activate(Accumulators上の非線形関数、ReLU/Sigmoid等、畳み込み用プーリングも実行)、Write_Host_Memory(Unified Buffer→ホストメモリ)。CISC の MatrixMultiply 命令は12バイト(Unified Bufferアドレス3バイト、accumulatorアドレス2バイト、長さ4バイト、残りがopcode/flags)。4段パイプラインで各CISC命令が1段を占有し、Read_Weightsはdecoupled-access/executeの発想でアドレス送出後に即完了できる(重みフェッチの完了を待たない)。 行列演算はSRAM読み書きの電力コストを抑えるためsystolic(シストリック)実行を用いる(図4)。データは左から流れ込み、重みは上からロードされ、256要素の乗加算がダイアゴナルな波として行列を伝播する。ソフトウェアからはこのsystolicな性質は不可視(正しさの観点)だが、性能上はユニットのレイテンシへの配慮が必要になる。 **Figure 4: Matrix Multiply Unitのシストリックデータフロー** ![[_attachments/isca2017-tpu/fig04-systolic-dataflow.png]] (Figure 4. Controlからデータが逐次的にレジスタ列へシフト投入され(左)、Data(データ)とPartial Sums(部分和)が格子内を斜めの波として伝播し、下端のアキュムレータへ蓄積されてDoneに至る。Source: Figure 4.) TPUソフトウェアスタックはCPU/GPU向けと互換に作られ、User Space DriverとKernel Driver(メモリ管理・割り込みのみを担う軽量・長期安定志向)に分かれる。TensorFlowで書かれたアプリケーションはGPU/TPU両対応のAPIにコンパイルされる。User Space Driverはモデル初回評価時にプログラムをコンパイルしてキャッシュし、重みイメージをTPUのWeight Memoryへ書き込む。2回目以降はフルスピードで実行される。 ## 実験設定 Table 1(6種の代表推論アプリケーション、TPU用途の95%を占める)と Table 2(ベンチマーク3プラットフォーム)を転記する。 **Table 1. 6種のNNアプリケーション(NN種別ごとに2種)** | 名称 | LOC | FC | Conv | Vector | Pool | 非線形関数 | 重み数 | TPU Ops/Weight Byte | Batch Size | 2016年7月時点のTPU配備割合 | |---|---|---|---|---|---|---|---|---|---|---| | MLP0 | 100 | 5 | - | - | - | ReLU | 20M | 200 | 200 | 61%(MLP合計) | | MLP1 | 1000 | 4 | - | - | - | ReLU | 5M | 168 | 168 | (MLP0/1合算61%) | | LSTM0 | 1000 | - | - | 24 | 34 | sigmoid, tanh | 52M | 64 | 64 | 29%(LSTM合計) | | LSTM1 | 1500 | - | - | 37 | 19 | sigmoid, tanh | 34M | 96 | 96 | (LSTM0/1合算29%) | | CNN0 | 1000 | - | 16 | - | - | ReLU | 8M | 2888 | 8 | 5%(CNN合計) | | CNN1 | 1000 | 4 | 72 | - | 13 | ReLU | 100M | 1750 | 32 | (CNN0/1合算5%) | 一つのMLPはRankBrain、一つのLSTMはGoogle Neural Machine Translationのサブセット、一つのCNNはInception V2、他方のCNNはDeepMind AlphaGoに由来する。 **Table 2. ベンチマーク対象サーバー(die単位の値)** | プラットフォーム | ダイ面積 | プロセス | クロック | Idle TDP | Busy TDP | TOPS/s(8b) | GB/s帯域 | オンチップメモリ | ダイ数 | DRAM容量 | サーバーTDP(Idle/Busy) | |---|---|---|---|---|---|---|---|---|---|---|---| | Haswell E5-2699 v3 | 662 mm² | 22 nm | 2300 MHz | 41W | 145W | 2.6(FP) | 51 | 51 MiB | 2 | 256 GiB | 159W / 455W(TDP504W) | | NVIDIA K80(2ダイ/カード) | 561 mm² | 28 nm | 560 MHz | 25W | 98W | 2.8(FP) | 160 | 8 MiB | 8 | 256 GiB(host)+12 GiB×8 | 357W / 991W(TDP1838W) | | TPU | <331 mm²(*) | 28 nm | 700 MHz | 28W | 40W | 92 | 34 | 28 MiB | 4 | 256 GiB(host)+8 GiB×4 | 290W / 384W(TDP861W) | (*TPUダイはHaswellダイの半分未満。SECDEDとBoost mode無効によりK80の広告値240→160 GB/s、8.7→2.8 TOPS/sへ低下。) ## 実験結果 ### Roofline分析 図5~8はRooflineモデル(演算強度=weightバイトあたりの整数演算数)による性能上限分析。 **Figure 5: TPU(die)のRoofline** ![[_attachments/isca2017-tpu/fig05-tpu-roofline.png]] (Figure 5. Ridge pointは1350 MAC/weightバイトと非常に右寄り。2 LSTMと2 MLPはメモリバウンドでスロープ部の下に位置し、2 CNN(CNN0=86.0、CNN1=14.1 TOPS/s)は計算バウンドでCeiling付近に到達する。Source: Figure 5.) **Figure 6: Haswell CPU(die)のRoofline** / **Figure 7: NVIDIA K80 GPU(die)のRoofline** ![[_attachments/isca2017-tpu/fig06-haswell-roofline.png]] (Figure 6. Ridge pointは13 MAC/byteとTPUよりずっと左寄り。LSTM0・MLP1はK80より速いが他はK80が速い。応答時間制約がDNN性能を制限する(Table 4)。Source: Figure 6.) ![[_attachments/isca2017-tpu/fig07-k80-roofline.png]] (Figure 7. Ridge pointは9 MAC/weightバイト。応答時間キャップにより6アプリともRooflineから大きく下に外れる。Source: Figure 7.) **Figure 8: 図5-7を統合したLog-Logグラフ** ![[_attachments/isca2017-tpu/fig08-combined-roofline.png]] (Figure 8. 星がTPU、三角がK80、丸がHaswellの計測点。全TPU星印が他2つのRooflineと同等以上の高さに位置する。Source: Figure 8.) **Table 3. TPU性能を制限する要因(性能カウンタ実測)** | 項目 | MLP0 | MLP1 | LSTM0 | LSTM1 | CNN0 | CNN1 | 平均 | |---|---|---|---|---|---|---|---| | Array active cycles | 12.7% | 10.6% | 8.2% | 10.5% | 78.2% | 46.2% | 28% | | Useful MACs(peak比) | 12.5% | 9.4% | 8.2% | 6.3% | 78.2% | 22.5% | 23% | | Unused MACs | 0.3% | 1.2% | 0.0% | 4.2% | 0.0% | 23.7% | 5% | | Weight stall cycles | 53.9% | 44.2% | 58.1% | 62.1% | 0.0% | 28.1% | 43% | | Weight shift cycles | 15.9% | 13.4% | 15.8% | 17.1% | 0.0% | 7.0% | 12% | | Non-matrix cycles | 17.5% | 31.9% | 17.9% | 10.3% | 21.8% | 18.7% | 20% | | RAW stalls | 3.3% | 8.4% | 14.6% | 10.6% | 3.5% | 22.8% | 11% | | Input data stalls | 6.1% | 8.8% | 5.1% | 2.4% | 3.4% | 0.6% | 4% | | TeraOps/sec(92 Peak) | 12.3 | 9.7 | 3.7 | 2.8 | 86.0 | 14.1 | 21.4 | CNN1(89層)は高い演算強度にもかかわらず14.1 TOPSしか出せない。半分弱の時間しか行列演算を実行できず(浅い層のため64Kの半分程度のMACのみが有効な重みを保持)、約35%は4つの全結合層(演算強度32)の重みロード待ち、残り約19%のうち23%がRAWパイプラインハザード、1%がPCIe入力待ち。 ### 応答時間とスループット **Table 4. MLP0の99パーセンタイル応答時間とdieあたりスループット(IPS)** | Type | Batch | 99%応答時間 | IPS | 最大IPS比 | |---|---|---|---|---| | CPU | 16 | 7.2 ms | 5,482 | 42% | | CPU | 64 | 21.3 ms | 13,194 | 100% | | GPU | 16 | 6.7 ms | 13,461 | 37% | | GPU | 64 | 8.3 ms | 36,465 | 100% | | TPU | 200 | 7.0 ms | 225,000 | 80% | | TPU | 250 | 10.0 ms | 280,000 | 100% | 7 ms制限下でCPU/GPUは応答時間制約により小さいバッチ(16)しか使えず最大スループットの37~42%に留まるが、TPUはバッチ200で最大IPSの80%に達する。応答時間制約がないときの理想比でCPU/GPUは2.3~2.7倍遅くなるが、TPUの決定的実行モデルではその低下はわずか1.2倍。 **Table 5. ホストCPUがTPUと対話する時間(TPU実行時間比、%)** | MLP0 | MLP1 | LSTM0 | LSTM1 | CNN0 | CNN1 | |---|---|---|---|---|---| | 21% | 76% | 11% | 20% | 51% | 14% | **Table 6. K80とTPUのHaswell比相対性能(die単位、ホストサーバーオーバーヘッド込み)** | | MLP0 | MLP1 | LSTM0 | LSTM1 | CNN0 | CNN1 | GM | WM | |---|---|---|---|---|---|---|---|---| | GPU | 2.5 | 0.3 | 0.4 | 1.2 | 1.6 | 2.7 | 1.1 | 1.9 | | TPU | 41.0 | 18.5 | 3.5 | 1.2 | 40.3 | 71.0 | 14.5 | 29.2 | | Ratio(TPU/GPU) | 16.7 | 60.0 | 8.0 | 1.0 | 25.4 | 26.3 | 13.2 | 15.3 | 実際のワークロード比(Table 1)による加重平均(WM)では GPU 1.9倍・TPU 29.2倍となり、TPU dieはGPU dieの15.3倍高速となる。 ### 電力効率と電力比例性 **Figure 9: 性能/Watt(TDP)の相対比較** / **Figure 10: CNN0のWatts/die(利用率0~100%)** ![[_attachments/isca2017-tpu/fig09-perf-per-watt.png]] (Figure 9. Total(ホストCPU電力込み)GM/WMおよびIncremental(ホストCPU電力除外)GM/WMの4指標について、GPU/CPU・TPU/CPU・TPU/GPU・TPU'/CPU・TPU'/GPUの比を示す。Total Perf./Watt WM: TPU/CPU=34, TPU/GPU=16。Incremental Perf./Watt WM: TPU/CPU=83, TPU/GPU=29。TPU'(GDDR5換装の仮想設計)ではIncremental WMがCPU比196・GPU比68まで上がる。Source: Figure 9.) ![[_attachments/isca2017-tpu/fig10-watts-per-die-utilization.png]] (Figure 10. TPUは最も電力が低い(40W/die)が電力比例性は最も乏しく、10%負荷時でも100%負荷時の88%の電力を消費する。Haswellは10%負荷で56%、K80は66%。Source: Figure 10.) TPUサーバー全体では、total-performance/WattでHaswell比17~34倍・K80比14~16倍、incremental-performance/Watt(ホストCPU電力を除く、これが同社のカスタムASIC投資の正当化根拠)ではHaswell比41~83倍・K80比25~29倍に達する。 ### 代替設計の感度分析 **Figure 11: TPU性能感度(0.25x~4xスケール、加重平均)** ![[_attachments/isca2017-tpu/fig11-sensitivity-analysis.png]] (Figure 11. メモリ帯域幅(memory)の4倍化が平均性能を3.16倍に改善する効果が最大。クロック周波数単独(clock)やアキュムレータ増設付きクロック(clock+)はほぼ効果なし。Matrix Unitを512×512へ拡大(matrix, matrix+)するとタイル化の内部フラグメンテーションにより性能はわずかに悪化する。Source: Figure 11.) **Table 7. TPU性能モデルとハードウェア性能カウンタのクロックサイクル差** | MLP0 | MLP1 | LSTM0 | LSTM1 | CNN0 | CNN1 | |---|---|---|---|---|---| | 6.8% | 10.9% | 7.7% | 5.4% | 8.2% | 11.2% | 平均誤差8%(モデルとカウンタの差)。 **Table 8. 24 MiB Unified Bufferのうち各NNアプリケーションが使用した最大MiB** | MLP0 | MLP1 | LSTM0 | LSTM1 | CNN0 | CNN1 | |---|---|---|---|---|---| | 11.0 | 2.3 | 4.8 | 4.5 | 1.5 | 13.9 | 新しいストレージアロケータの改良により14 MiBで十分と判明したが、配備最初の18か月はソフトウェア開発中のため24 MiBの全容量を使っていた。 仮想設計TPU'(K80相当のGDDR5メモリへ換装、クロックも1050 MHzへ向上)は、ホストサーバー時間を含めてもGM 1.9倍・WM 3.2倍の性能を得られると推定される。GDDR5化はダイ面積を約10%増やすが、Unified Bufferを14 MiBへ縮小すれば約10%を相殺できる。GDDR5化はTPUシステム電力予算を861Wから約900Wへ増やす。 ## 考察 - **Fallacy: NN推論はスループットも応答時間と同じくらい重視される** — 開発者の実測では応答時間要件が予想より厳しく、逆にLSTM1の応答時間制限は2014年10ms→ポート後7msに短縮された。 - **Fallacy: K80 GPUアーキテクチャは推論に良く適合する** — GPUは高スループット・高帯域アーキテクチャであり、K80がHaswellよりわずかに速い程度でTPUよりずっと遅い理由を説明する。 - **Pitfall: アーキテクトが重要なNNタスクを見落としている** — ISCA 2016論文の15%がNN加速器を扱ったが、そのうち9本がCNNのみを対象とした一方、CNNはデータセンターNNワークロードの5%に過ぎない。 - **Pitfall: IPS(Inferences Per Second)はNNハードウェアの不正確な要約性能指標である** — TPUはMLP1を360,000 IPS、CNN1をわずか4,700 IPSで実行し、IPSは75倍もばらつく。 - **Fallacy: Boost mode を使えばK80結果はもっと良くなる** — LSTM1で計測した結果、Boost modeはクロックを1.6倍(560→875 MHz)上げ性能を1.4倍改善するが電力も1.3倍上がり、性能/Watt改善は1.1倍に留まる。 - **Pitfall: NNハードウェア向け性能カウンタは後付けである** — TPUは106個の性能カウンタを持つが、まだ足りないと述べる。 - **Fallacy: 2年間のソフトウェアチューニング後は、TPU性能改善の唯一の道はハードウェアアップグレードである** — CNN1は開発者とコンパイラの工夫(4つの全結合層向けバッチを32→128へ集約)でなお改善余地がある。 - **Pitfall: ドメイン固有アーキテクチャ設計で計算機アーキテクチャの歴史を無視している** — systolic array・decoupled-access/execute・CISC命令という3つの重要な設計要素は1980年代前半に遡る。 ## 新規性・関連研究 CNAPS・Synapse-1・SPERT-II/T0・DianNaoファミリー(DianNao/DaDianNao/PuDianNao/ShiDianNao)・Convolution Engineなど25年に及ぶカスタムNN ASICの系譜が挙げられる。Microsoft Catapultとの比較では、Catapult(28-nm Stratix V FPGA、200 MHz、3,926個の18ビットMAC、5 MiBオンチップメモリ、11 GB/s帯域、25W)に対しTPU(700 MHz、65,536個の8ビットMAC、28 MiB、34 GB/s、40W)は40~70倍速い(アップルとオレンジの比較である点は著者自身が留保)。最大の違いは、Catapultが低レベルVerilogでの長いプログラムを要するのに対し、TPUは高レベルTensorFlowの短いプログラムで再プログラム可能な点であり、再プログラム性がソフトウェア(TPU)由来かファームウェア(FPGA)由来かという違いとして位置づけられる。 ## 結論(数値まとめ) TPU dieはK80 GPU dieの32ビット浮動小数点データパス比で、8ビット整数systolic行列乗算器により25倍のMAC数(65,536個 対 2,496個)と3.5倍のオンチップメモリ(28 MiB 対 8 MiB)を、K80の半分未満の電力で搭載する。TPUはTensorFlowで書かれた短いプログラムをK80 GPU dieの15倍速く実行し、性能/Wattは29倍優位、Haswell CPU die比では性能29倍・性能/Watt 83倍。GPUメモリ相当への換装だけで性能は2~3倍、性能/Watt優位はK80比ほぼ70倍・Haswell比200倍まで拡大すると推定される。 ## 強み / 弱点・課題 **強み**: - 2015年から本番稼働する実機TPUの、6週間に及ぶ実ワークロード計測に基づく一次データであり、Rooflineモデル・性能カウンタ・電力比例性まで多面的に定量化している。 - 性能モデルによる感度分析(図11)で、メモリ帯域幅・クロック・Matrix Unit規模という設計変数の効果を分離して評価し、次世代設計への具体的な指針(GDDR5化)を示す。 - fallacy/pitfall形式による自己批判的な議論が、IPSの誤用やベンチマーク比較の落とし穴など、他のNNアクセラレータ評価にも一般化できる教訓を提供する。 **弱点・課題(著者ら自身が示唆)**: - 評価対象はGoogle社内の非公開production workloadに限定され、外部で再現可能な公開ベンチマークではない(Fathomベンチマークとの相違を認めつつ、Fathom側のCPU/GPU設定がサーバークラスでない点を指摘して比較の限界を論じる)。 - TPU自身は短い開発期間(15か月)のため電力比例性やスパース対応など多くの省電力・性能機能が省かれており、著者らもそれを明示的な制約として認めている。 - 価格情報(TCO算出の核心)は企業間交渉に依存するため公開されておらず、性能/Wattを代理指標として使う限界がある。 ## 本論文とTPUv4の関係 本論文が報告するTPU v1は2015年配備の**推論専用**第1世代ASICであり、単体die・PCIeコプロセッサとして動作する。これに対し[[TPUv4]]は2020年から本番稼働する**訓練用**第3世代の4096ノード規模3Dトーラス型スーパーコンピュータであり、[[Palomar Optical Circuit Switch]]によるICIファブリックの動的再構成を核心とする([[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。両論文は「Googleがドメイン固有ハードウェアを自社データセンター規模で垂直統合的に設計・運用する」という設計思想を共有するが、対象フェーズ(推論 対 訓練)・スケール(単体die 対 4096チップ)・アーキテクチャ上の主課題(Rooflineボトルネック分析 対 光回線交換による耐障害性)が大きく異なり、単純な性能数値の比較はできない。 ## 関連 - entity: [[Google TPU]](TPU v1の一次ソースとして本 source が新たに参照される) / [[Google]] / [[TensorFlow]] / [[Norman P. Jouppi]] / [[David A. Patterson]] / [[Jeffrey Dean]] - concept: [[ドメイン固有アーキテクチャ]] / [[AIアクセラレータ]] - 関連 source(異世代TPU、混同注意): [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]] ## 出典 - Jouppi, N.P., Young, C., Patil, N., Patterson, D., et al. 2017. In-Datacenter Performance Analysis of a Tensor Processing Unit. Proc. ISCA '17. https://doi.org/10.1145/3079856.3080246 - 図表: [[.raw/papers/isca2017-tpu.pdf]](Figure 1-11, Table 1-8 全件を本文中に転記・再掲)