最近我大量使用 TPU，發現它們與 GPU 的設計理念非常不同，感覺很有趣。

TPU 的主要優勢在于其可擴展性。這是通過硬件層面（例如能效方面和模塊化）與軟件層面（例如 XLA compiler）的協同設計實現的。

1.背景信息

簡單介紹一下 TPU，它是谷歌的專用集成電路（ASIC），其設計聚焦于兩大要素：極高的矩陣運算（matmul）吞吐量和能源效率。

它們的起源可追溯到 2006 年的谷歌。當時，他們正在評估是采用 GPU、FPGA 還是定制的 ASIC。當時，只有少數應用需要使用專用硬件，他們判斷通過從大型數據中心調配多余的 CPU 算力即可滿足這些需求。但這一情況在 2013 年發生了變化，當時谷歌的語音搜索功能運行在神經網絡上，而內部預測認為，如果該功能發展起來，將需要遠超以往的算力。

時至今日，TPU 已為谷歌的大多數人工智能服務提供算力支撐。當然，也包括 Gemini 或 Veo 的訓練和推理，也包括他們的推薦模型。

讓我們從底層開始，深入了解一下 TPU 的內部構造。

2.單個 TPU 芯片內部的架構層級

下文圖示均以 TPUv4 為例，但其整體布局基本也適用于最新一代 TPU（如 TPUv6p “Trillium”。TPUv7 “Ironwood” 的細節截至 2025 年 6 月尚未公布）。

單顆 TPUv4 芯片的結構如下：

TPU Single Chip + TensorCore

每顆芯片內含兩個 TPU TensorCore，負責所有計算。（注：面向推理的專用 TPU 僅有一個 TensorCore）。兩個 TensorCore 共享同一份內存：CMEM（128 MiB）和 HBM（32 GiB）。

而在每個 TensorCore 內部，都有計算單元和較小的內存緩沖區：

1）矩陣乘法單元 (MXU)

• 這是 TensorCore 的核心部件，是一個 128x128 的脈動陣列（systolic array）。

脈動陣列的原理稍后說明。

2）向量單元（VPU）

• 負責執行通用的逐元素操作（例如 ReLU、點加/點乘、歸約操作）

3）向量內存（VMEM；32 MiB）

• 內存緩沖區。HBM 中的數據需先復制到 VMEM，TensorCore 才能開始計算。

4）標量單元 + 標量內存（SMEM；10 MiB）

• 用于調度 VPU 和 MXU 的執行指令。
• 負責管理控制流、標量運算和內存地址生成。

如果你使用的是英偉達（NVIDIA）GPU，那么一些初步觀察結果可能會讓你大吃一驚：

1）TPU 的片上內存單元（CMEM、VMEM、SMEM）遠大于 GPU 的 L1/L2 緩存。

2）TPU 的 HBM 容量卻遠小于 GPU 的 HBM。

3）負責計算的"核心"（cores）數量明顯更少。

這與 GPU 架構完全相反 —— GPU 擁有較小的 L1/L2 緩存（以 H100 為例，分別為 256KB 和 50MB）、更大的 HBM（H100 為 80GB）以及數以萬計的計算核心（cores）。

在我們進一步討論之前，需明確的是，TPU 與 GPU 同樣具備極高的吞吐量。單顆 TPU v5p 芯片可達 500 TFLOPs/sec，由 8960 顆芯片組成的完整 pod 集群可實現約 4.45 ExaFLOPs/sec。而最新的 "Ironwood" TPUv7 每個 pod（9216 顆芯片）據稱可達 42.5 ExaFLOPS/sec。

要理解 TPU 如何實現這種性能，我們需要深入探究其設計理念。

3.TPU 的設計理念

TPU 通過兩大技術支柱和一個核心前提實現了驚人的吞吐量與能源效率：systolic array（脈動陣列） + pipelining（流水線）、Ahead-of-Time (AoT) compilation（預先編譯），以及假設絕大多數運算都可通過適配 systolic array（脈動陣列）的方式表達。幸運的是，在現代深度學習（DL）領域，計算的大部分都是矩陣運算，而這些運算都適合使用 systolic array（脈動陣列）。

3.1 TPU 設計選擇之一：Systolic Array + Pipelining

問：什么是 Systolic Array？

答：Systolic Array 是一種硬件設計架構，由相互連接的處理單元（PE）網格組成。每個 PE 執行少量運算（例如乘法和累加運算），并將結果傳遞給相鄰 PE。

image.png

這種設計的好處是，數據一旦輸入 systolic array（脈動陣列），便無需額外的控制邏輯來處理數據。此外，當脈動陣列的規模足夠大時，除輸入輸出外再無內存讀寫操作。

由于脈動陣列的剛性結構設計（rigid organization），其僅能處理具有固定數據流模式的操作，但幸運的是，矩陣乘法和卷積運算（convolutions）恰好完美適配這種架構范式。

不僅如此，pipelining（流水線技術）顯然有機會將計算與數據移動重疊執行。下圖展示了 TPU 架構上 pipelined pointwise operation （通過流水線技術，加速 pointwise operation（逐點操作） 的執行過程。）的示意圖。

圖片

Pipelined Pointwise Operation (from "How to Scale Your Model" [4])

旁注：Systolic Arrays（脈動陣列）的局限性 —— 稀疏性

我們可以看到，脈動陣列（systolic arrays）非常喜歡稠密矩陣（dense matrices）（即每個 PE 幾乎每個時鐘周期都處于活躍狀態）。然而，其劣勢是，相同規模的稀疏矩陣（sparse matrices）無法獲得性能提升 —— 即使對于零值元素（zero-valued elements），PE 仍需執行相同數量的計算周期（cycles），導致資源浪費。

如若深度學習（DL）領域更傾向于采用更不規則的稀疏性（例如 MoE 架構），應對脈動陣列的這一系統性局限將變得愈發重要。

3.2 TPU 設計選擇之二：預先（AoT）編譯 + 減少對緩存的依賴

本節將回答 TPU 如何通過軟硬件協同設計（TPU + XLA 編譯器）來避免使用緩存，從而實現高能效。

首先，請記住傳統緩存是為了處理不可預測的內存訪問模式而設計的。一個應用程序的內存訪問模式（memory access patterns），可能與另一個應用程序大相徑庭。從本質上講，緩存允許硬件靈活地適應各種應用場景。這也是 GPU（相較于 TPU）靈活性極高的一個重要原因。

然而，緩存訪問（以及一般意義上的內存訪問）會消耗大量能源。下面是對芯片（45納米，0.9V；[18]）上各類操作的能耗粗略估計。這里的主要啟示是，內存的訪問和控制占用了大部分的能耗，而算術操作本身的能耗占比則小得多。

image.png

但是，如果你的應用非常特殊，而且其計算和內存訪問模式具有很高的可預測性呢？

舉個極端的例子，如果我們的編譯器能提前確定所有需要的內存訪問，那么硬件僅需一個暫存器作為緩沖區就足以滿足需求，根本不需要緩存。

這正是 TPU 的設計理念所追求的，也是 TPU 使用 XLA 編譯器設計以實現這一目標的根本原因。XLA 編譯器通過提前分析計算圖來生成優化過的程序。

問：但 JAX 在 TPU 上也運行良好，它們使用 @jit 嗎？

TPU 上的 JAX+XLA 實際處于 JIT 與 AOT 的混合模式，因此容易產生混淆。當首次調用 JAX 中被 @jit 修飾的函數時，JAX 會進行代碼追蹤并生成靜態計算圖。然后將其傳遞給 XLA 編譯器，在那里被轉化為適用于 TPU 的完全靜態二進制文件。在最后的轉化階段，編譯器會實施針對 TPU 的優化（例如，最大限度地減少內存訪問），使整個過程適合 TPU。

但有一點需要注意：當輸入張量的形狀（shape）發生變化時，已編譯的 JIT 函數需重新編譯并緩存。這就是為什么 JAX 在處理動態填充（dynamic padding）或長度隨輸入變化的 for 循環層時表現不佳。

當然，這種方案雖有優勢，卻也存在明顯的局限。它缺乏靈活性，而對編譯器的重度依賴猶如一把雙刃劍。

那么，Google 為何仍要堅持這種設計理念？

TPU 及其能源效率（TPUv4）

前文的能耗示意圖并不能精確反映 TPU 的實際情況，此處是 TPUv4 的能耗細目。注意，TPUv4 采用 7nm 工藝，表中 45nm 的數據僅用于對比（[3], [16]）。

image.png

單次操作能耗對比（TPUv4, 7 nm）

上方的柱狀圖展示了具體數值，但需注意，現代芯片采用的是 HBM3 內存，其能耗遠低于本圖表中顯示的 DDR3/4 DRAM。盡管如此，該圖仍表明內存操作的能耗仍高出計算操作數個數量級。

這恰與 scaling laws 形成呼應：我們非常樂意通過增加浮點運算量（FLOPS）來換取更少的內存操作。因此減少內存操作能帶來雙重優化收益——不僅提升程序運行速度，還可顯著降低能耗。

4.TPU 的多芯片互聯層級結構

現在升級到更高層級，觀察 TPU 在多芯片環境中的運作方式。

4.1 托盤層級（即"板卡"；含4個芯片）

image.png

單塊 TPU 托盤包含 4 個 TPU 芯片或 8 個 TensorCore（簡稱"核心"）。每塊托盤配備獨立 CPU 主機（注：推理型 TPU 的每個主機可訪問 2 塊托盤，因其每芯片僅含 1 個核心）。

主機（Host） ? 芯片（Chip）的連接采用 PCIe 接口，但芯片（Chip）?芯片（Chip）之間通過 Inter-Core Interconnect（ICI）連接，該接口具備更高帶寬。

不過 ICI 連接還可進一步擴展至多塊托盤。為此，我們需要繼續提升到機架層級（Rack level）。

4.2 機架層級（4x4x4 芯片）

TPU 最令人興奮的特性在于其可擴展性，這一點從機架層級開始顯現。

一個 TPU 機架包含 64 個 TPU 芯片，通過 4x4x4 三維環面網絡互聯。如果您看過谷歌的 TPU 宣傳資料（如下圖），這張圖展示的是 8 個 TPU 機架的集群。

單次操作能耗對比（TPUv4, 7 nm）

但在深入討論機架之前，我們需要澄清幾個容易混淆的術語：機架（Rack）、Pod 和切片（Slice）的區別。

問：TPU 機架、TPU Pod 和 TPU 切片有何不同？

不同谷歌資料對這些術語的使用存在差異，有時甚至混用"TPU Pod"和"TPU Slice"。本文采用谷歌 TPU 論文和 GCP 官方文檔的定義（[3][7][9]）：

1）TPU 機架（Rack）

• 包含 64 塊芯片的物理單元，也稱為“立方體（cube）”。

2）TPU Pod

• 通過 ICI 和光纖連接的 TPU 最大單元。
• 又稱"Superpod"或"Full Pod"。例如 TPUv4 的 TPU Pod 包含 4096 塊芯片（或 64 個機架）。

3）TPU 切片（Slice）

• 介于 4 塊芯片到 Superpod 規模之間的任何 TPU 配置組合。

主要區別在于，TPU 機架和 TPU Pod 是物理計量單位，而 TPU 切片是抽象計量單位。當然，TPU 切片的設置涉及重要的物理拓撲約束，但現階段我們暫不展開討論。

現在，我們將聚焦物理計量單位：TPU 機架和 TPU Pod。這是因為，理解 TPU 系統的物理連接方式，能更深入地掌握其設計哲學。

現在回到 TPUv4 機架的具體結構：

單個 TPU 機架通過 ICI 和 OCS（Optical Circuit Switching）技術連接 64 個芯片。實質上，我們通過組合多個托盤（trays）來構建一個 64 芯片的完整系統。這種"將小型單元組裝成超級計算機"的設計理念將持續貫穿后續層級。

下圖展示了 TPUv4 單個機架的拓撲結構。它采用 4x4x4 三維環面網絡，其中每個節點都代表一塊芯片，藍色箭頭表示 ICI 鏈路，而各個面上的連接線則代表 OCS（根據文獻 [7] 重繪）。

使用 OCS 的 TPU 單機架架構

然而，這張圖表引出了兩個關鍵問題：為何 OCS 僅應用于環面結構的表面？換句話說 —— 使用 OCS 的核心優勢是什么？共有三大核心優勢，我們將在后文再詳述另外兩點。

OCS 的優勢 #1：環繞連接 (Wraparound)

通過環形拓撲優化節點間的通信效率。

OCS 還承擔特定 TPU 配置的環繞連接功能。該設計將兩節點間的跳數從最壞情況下 N-1 跳降至每軸 (N-1)/2 跳，因為每條軸均形成一個環形（一維環面拓撲）。

隨著規模的進一步擴大，這種影響變得更加重要，因為降低芯片間的通信延遲對于高度并行化的實現至關重要。

附注：并非所有 TPU 都采用 3D 環面拓撲

注意，早期 TPU（如 TPUv2/v3）及推理專用 TPU（如 TPUv5e/v6e）使用 2D 環面拓撲而非下文所述的 3D 環面。不過 TPUv7"Ironwood" 雖定位為推理芯片，但其拓撲疑似 3D 環面（注：僅根據官方宣傳材料推測）。

2D環面拓撲示意圖

4.3 Full Pod 層級（又稱 "Superpod"；TPUv4 為 4096 塊芯片）

正如我們通過互聯多個芯片構建 TPU 機架，我們也可連接多個機架組成大型 Superpod。

Superpod 特指僅通過 ICI 和 OCS 互聯的最大 TPU 集群規模。雖然存在 multi-pod 層級，但這種層級需依賴更慢速的連接方式，后續將展開說明。

芯片數量會因版本不同而變化，但 TPUv4 的芯片數量為 4096（即 64 個 4x4x4 芯片的機架）。最新的 TPUv7 "Ironwood" 則高達 9216 塊芯片。

下圖展示了 TPUv4 的一個 Superpod：

TPUv4 Superpod 架構（64 個機架）

請注意，每個立方體（即 TPU 機架）是如何通過 OCS 相互連接的，這種設計也支持在 Pod 內靈活劃分 TPU 切片。

采用 OCS 的 TPU 切片

我們可在 Pod 內申請 TPU 子集，即 TPU 切片。但即使所需芯片數(N)相同，也存在多種拓撲結構可供選擇。

例如，若總共需要 512 塊芯片，可選擇立方體(8x8x8)、條狀拓撲(4x4x32)或矩形拓撲(4x8x16)。選擇切片的拓撲結構本身就是一個超參數。

所選拓撲結構直接影響節點間通信帶寬，進而影響各類并行策略的性能表現。

以立方體結構（如8x8x8）為例，它特別適合需要全連接通信的并行計算模式，比如數據并行或張量并行，因為這種拓撲結構能提供最高的二分帶寬（bisection bandwidth）。而條狀結構（如4x4x32）則更適用于流水線計算，這種布局可以讓順序排列的計算層之間實現更快速的數據傳輸（前提是單個計算層能夠適配 4x4 芯片的子切片配置）。

典型 TPU 拓撲示例

當然，最優拓撲取決于具體模型結構，其尋優過程本身即是一門學問。TPUv4 論文[9]實測表明，拓撲優化可大大提升吞吐量（注：我不確定第一行指的是哪種 LLM 架構，因為沒有具體說明）。

不同拓撲結構的吞吐量優化對比

前文闡述了 TPU 切片，但另有一項重要的特性有助于提高 TPU 的運行穩定性。

借助 OCS 技術，這些切片無需占據物理連續的機架空間。這正是 OCS 的第二大優勢 —— 可能也是其最大優勢，但我們此前尚未展開討論。

OCS 的優勢 #2：可重新配置的非連續多節點切片

需注意，這不同于將多個節點硬連在一起來模擬非連續切片。由于 OCS 采用光交換技術而非硬連線架構，跨節點間的物理線纜數量大幅減少，從而支持更大規模的集群擴展（即可構建超大規模 TPU Pod）。

這樣就可以進行靈活的節點規模配置。例如，假設我們想在單個 Pod 上運行三個任務。雖然傳統的調度方式不允許這樣做，但 OCS 連接允許我們抽象出節點的物理位置，使整個 Pod 可視為一個"節點資源池"（根據參考文獻[6]重繪）。

單任務可將 Pod 內機架視為"節點資源池"

此舉不僅提高了 Pod 的利用率，而且能在節點出現故障的情況下簡化維護流程。谷歌將其描述為"故障節點的影響范圍很小"。但尚不確定其液冷系統在部分節點停機時如何運作。

最后，這種靈活的 OCS 還有項延伸應用：我們還可以改變 TPU 切片的拓撲結構（例如將規則環面調整為扭曲環面）。

OCS 的優勢 #3：扭曲環面拓撲

此前我們通過改變固定芯片數量下的 (x,y,z) 維度來實現不同的 TPU 切片拓撲結構。本節則聚焦固定維度配置，通過改變布線方式構造新型拓撲。

典型案例如下：將常規條狀環面改造為扭曲條狀環面。

扭曲環面拓撲結構能加速扭曲二維平面上的芯片之間的通信，該特性對提升全局通信效率尤其有用。

下文將深入分析其具體應用場景。

使用扭曲環面加速訓練

理論上，扭曲環面對張量并行（TP）的加速效益最大，因為每層涉及多次 all-gather 和 reduce-scatter 操作。對數據并行（DP）也有適度提升，因為每個訓練步需執行 all-reduce 操作，但發生頻率較低。

想象一下，假設我們訓練一個標準的僅解碼器架構的 Transformer 模型，并采用多種并行策略來加速訓練。下面我們將看到兩種場景：

場景 #1：4x4x16 拓撲結構（TP+PP；共 256 塊芯片）

設定 z 軸為流水線(PP)維度，二維 TP 維度為 4x4。本質上，假設第 k 層位于 z=k 平面，且每層分片至 16 塊芯片。若未明確繪制，默認采用 OCS 最近鄰連接。

TP+PP 的 4x4x16 拓撲架構

通過在每個 z=k 平面實施 2D 環面扭曲，可加速 TP 層內芯片通信。由于 PP 層主要依靠點對點通信，因此沒有必要沿 PP 層扭曲。

注：實際應用中，扭曲環面在芯片數＞4x4 時效益顯著。本示例使用 4x4 僅出于可視化的目的。

場景 #2：16x4x16 拓撲（DP+TP+PP；共 1024 塊芯片）

作為延伸方案，我們在前一場景基礎上增加 DP 維度（x 軸 4 個實例），即沿 x 軸部署 4 組場景 #1 的模型。

DP+TP+PP 的 16x4x16 拓撲架構

請注意，扭曲環面僅應用于每個 DP 模型內的每個 TP 維度（即對每個 z=k 平面實施 4x4 二維扭曲，k 取值 1…16）。DP 維度僅維持基礎的環繞連接，使每行構成長度為 16 的水平環。

你可能已經發現還有一種拓撲結構方案（如 8x8x16，即 2x2 DP 維度），但這會混合 DP 與 TP 維度 —— 這就變得更加復雜了。具體來說，我們還不清楚如何在 y 軸構建 OCS 環繞連接的同時兼容各 TP 維度的扭曲環面？

4.4 Multi-Pod 層級（即"Multislice"；TPUv4 支持 4096+ 塊芯片）

image.png

TPU 層次結構的最終層級是 Multi-pod 架構。此時可將多個 Pod 視為一臺大型機器，但 Pod 之間的通信需通過數據中心網絡（DCN） 進行 —— 其帶寬低于 ICI。

通過 DCN 互聯的雙 Pod 架構 [1]

PaLM 模型即采用此方案進行訓練。在 6144 個 TPUv4 芯片（2 個 Pod）上耗時 56 天完成。下圖是 6 個 Pod 中的 TPU 任務分配情況：綠色為 PaLM 任務，紅色為空閑狀態，其余為其他任務。注意每個方格代表一個 4x4x4 的 TPU 芯片立方體。

PaLM 訓練過程中的 TPU Pod 利用率 [6]

實現這一架構已屬不易，但更關鍵的是開發者體驗設計，具體來說，就是要關注：如何實現模型擴展過程中系統/硬件層面的最大程度抽象化？

谷歌的解決方案是：由 XLA 編譯器在大規模計算場景下協調芯片間的通信。研究人員只需配置相關參數（如 DP、FSDP、TP 等并行維度及切片數量），XLA 編譯器即會根據當前 TPU 拓撲結構自動插入分層集合通信操作（Xu et al, 2021: GSPMD [2]）。我們的目標是在盡可能少修改代碼的情況下實現大規模訓練。

例如，谷歌博客[1]展示了跨多 TPU 切片的 all-reduce 操作分解流程：

XLA 實現的跨 Pod All-Reduce 規約操作

這表明 XLA 編譯器可以同時處理切片內與切片間的集合通信操作。

舉個具體例子，在訓練模型時，TPU 的拓撲結構可能如下所示。激活值的通信在切片內通過 ICI 進行，而梯度的通信則需跨切片通過 DCN 完成（即在 DCN 的 DP 維度上）[1]。

TPU data movement visualized

5.實物圖示對照解析

結合硬件實拍圖理解架構圖會更直觀，以下為綜合解析。

若看過谷歌 TPU 宣傳資料，可能見過下圖：

8 個 TPU 機架（TPUv4）

此圖為 8 個 TPU Pods 的集群，每個單元即前述的 4x4x4 三維環面架構。一個 Pod 中的每一行有 2 個托盤，這意味著每一行有 8 個 TPU 芯片。

單塊 TPUv4 托盤實拍圖：

image.png

請注意，圖中簡化為只有一個 PCIe 端口，但實際托盤上有 4 個 PCIe 端口（在左側） —— 每個 TPU 一個。

單芯片結構圖：

TPUv4 芯片：中央是 ASIC + 4 組 HBM 內存堆棧

中央區域為 ASIC 芯片，周圍 4 個區塊為 HBM 內存堆棧。因 TPUv4 內含 2 個 TensorCore，故配置 4 組 HBM 內存堆棧。

未找到 TPUv4 芯片平面圖，此處展示結構近似的 TPUv4i（推理芯片），其僅含 1 個TensorCore[3]：

可見 CMEM（芯片內存）在 TPUv4i 的布局中占據了相當大的空間。

References

[1] Google Blog: TPU Multi-Slice Training（https://cloud.google.com/blog/products/compute/using-cloud-tpu-multislice-to-scale-ai-workloads）

[2] Xu, et al. "GSPMD: General and Scalable Parallelizaton for ML Computation Graphs"（https://arxiv.org/pdf/2105.04663）

[3] Jouppi et al. "Ten Lessons From Three Generations Shaped Google's TPUv4i"（https://gwern.net/doc/ai/scaling/hardware/2021-jouppi.pdf）

[4] How to Scale Your Model - TPUs（https://jax-ml.github.io/scaling-book/tpus/）

[5] Domain Specific Architectures for AI Inference - TPUs（https://fleetwood.dev/posts/domain-specific-architectures#google-tpu）

[6] HotChips 2023: TPUv4（https://hc2023.hotchips.org/assets/program/conference/day2/ML+training/HC2023.Session5.ML_Training.Google.Norm_Jouppi.Andy_Swing.Final_2023-08-25.pdf）

[7] Google Cloud Docs: TPUv4（https://cloud.google.com/tpu/docs/v4）

[8] Jouppi et al. "In-Datacenter Performance Analysis of a Tensor Processing Unit" -- TPU origins paper（https://arxiv.org/abs/1704.04760）

[9] Jouppi et al. "TPU v4"-- TPUv4 paper（https://arxiv.org/abs/2304.01433）

[10] PaLM training video（https://www.youtube.com/watch?v=0yPFBxkOKRY）

[11] HotChips 2021: "Challenges in large scale training of Giant Transformers on Google TPU machines"（https://hc33.hotchips.org/assets/program/tutorials/HC2021.Google.Sameer+Kumar.pdf）

[12] HotChips 2020: "Exploring Limits of ML Training on Google TPUs"（https://hc32.hotchips.org/assets/program/tutorials/HC2020.Google.SameerKumarDehaoChen.v02.pdf）

[13] Google Blog: Ironwood（https://blog.google/products/google-cloud/ironwood-tpu-age-of-inference/）

[14] HotChips 2019: "Cloud TPU: Codesigning Architecture and Infrastructure"（https://old.hotchips.org/hc31/HC31_T3_Cloud_TPU_Codesign.pdf）

[15] ETH Zurich's Comp Arch Lecture 28: Systolic Array Architectures（https://www.youtube.com/watch?v=XkgtANeDrm8）

[16] Patterson presentation: "A Decade of Machine Learning Accelerators: Lessons Learned and Carbon Footprint"（https://www.cs.ucla.edu/wp-content/uploads/cs/PATTERSON-10-Lessons-4-TPU-gens-CO2e-45-minutes.pdf）

[17] Camara et al. "Twisted Torus Topologies for Enhanced Interconnection Networks."（https://personales.unican.es/vallejoe/Publications/C%C3%A1mara+-+TPDS'10+-+Twisted+Torus+Topologies+for+Enhanced+Interconnection+Networks.pdf）

[18] Horowitz article: "Computing's Energy Problem(and what we can do about it)"（https://gwern.net/doc/cs/hardware/2014-horowitz-2.pdf）