TPU Pod集群：AI算力之城的地铁网络

CH-18-01-027·约 20 分钟·AI硬件与算力·更新 2026-08-12

想象你在为一座未来之城——“炼芯城”——设计交通网络。这座城里没有汽车，所有人和货物都靠地铁运输。每座地铁站就是一颗AI计算芯片，整座城市的智能都依赖车站之间快速交换信息。当城市从几十座站扩展到上千座站时，地铁线路怎么铺、信号怎么传、列车怎么调度，决定了城市是否能保持高速运转。 TPU Pod集群正是这样一座“AI算力之城”。Google把数千颗TPU芯片像地铁站一样布置在一个三维环状互联网络中，让任意两颗芯片之间都能以微秒级延迟传递数据。本文带你走遍这座城：从它的整体规划（集群架构）、地铁网络（3D Torus拓扑）、信号系统（通信延迟），到客流盘查（集合通信）、城市扩张（扩展效率）、运营调度（并行策略），最后看看高峰期如何疏堵（通信优化）以及如何把繁忙的部门安排在隔壁（拓扑感知调度）。

岗位关联

掌握TPU Pod的拓扑与通信机制，是设计千亿级大模型分布式训练方案的必修课。理解它，你就能明白为何某些并行策略在GPU集群上有效、在TPU上却需要重新设计。

可视化演示
集群架构：一座算力超级行政区
3D Torus拓扑：三维循环的地铁网
通信延迟：专属信号隧道
集合通信：全城客流盘查
扩展效率：城市增长的数学
并行策略：繁忙线路的调度
通信优化：高峰期的疏堵术
拓扑感知调度：亲和的同事们
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示TPU Pod集群核心：3D Torus互联拓扑结构、Ring/Tree AllReduce集合通信模式、并行策略与近线性扩展效率分析。

本节配有交互动效（进入视口后自动加载，约 3KB）。

3D Torus互联拓扑 TPU节点以3D Torus网格连接，每个节点与6个邻居（上下左右前后）直连 ICI专用互联协议实现微秒级延迟，带宽远超以太网 Topology: 3D Torus, Degree=6, Diameter=O(n^(1/3)) 3D Torus拓扑支撑大规模TPU集群高效通信

集群架构：一座算力超级行政区

炼芯城的规划者们很快发现，把地铁站做成一个个独立的“孤岛”是行不通的——必须把成千上万座车站编入一个高度协同的超级行政区。在TPU的世界里，这个超级行政区就叫Pod。一个TPU Pod是Google设计的最小可独立调度的大规模算力单元，它由数百到数千颗TPU芯片通过专用网络紧密互连而成。

TPU v3 Pod包含1024颗TPU v3核心，TPU v4 Pod则把规模提升到了4096颗核心。这些核心被组织在若干机架中：机架是物理安装与布线的独立单元，每个机架安装一定数量的TPU板卡，机架之间再通过高速光缆连接，最终统一接入一台主机。主机负责将训练程序编译为可在整个Pod上运行的指令，并统一调度资源。

Pod的核心数量直接决定了集群的峰值算力。如果每颗TPU的峰值算力为F，Pod包含N颗核心，那么整体算力就是N乘以F。以v3 Pod为例，其峰值算力超过100 PFLOPS——每秒十亿亿次浮点运算——足以支撑数千亿参数模型的训练。这样的规模，让“一台机器训练一个超大模型”成为可能。

就像超级行政区把城市分成街区、街区再落到具体站点，Pod形成了“集群—机架—核心”的清晰层次。有了这份蓝图，我们就要去铺地铁线路了。

\displaystyle N_{\text{Pod}} = R \times K

公式说明：Pod的核心总数等于机架数量乘以每个机架内的核心数，这是衡量Pod规模的第一个等式。

N_Pod（Pod核心总数）表示整个TPU Pod集群中TPU核心的总数量，例如TPU v3 Pod的N_Pod等于1024。
$N_{\text{Pod}}$
R（机架数量）Pod由若干机架组成，机架是物理安装与布线的独立单元。
$R$
K（每机架核心数）单个机架内实际安装的TPU芯片数量，受板卡设计与散热能力约束。
$K$
乘号连接（整体规模计算）机架数乘以每机架核心数，得到Pod的完整核心规模。
$R \times K$

3D Torus拓扑：三维循环的地铁网

炼芯城的地铁网络怎么布局？如果每座车站都只连到城市中心，中心一旦拥堵全城瘫痪。设计师们选择了一种巧妙的方案：让每座车站直接连接上、下、左、右、前、后六个方向的车站，并把最外圈像贪吃蛇一样首尾相衔——这就是一座三维环绕的“地铁迷宫”。

这个布局在计算机体系结构中被称为3D Torus拓扑。TPU Pod把N颗核心排列成x、y、z三个方向的三维网格，并且每个维度都首尾相接成环。每颗TPU恰好有6个直接邻居：x方向两个、y方向两个、z方向两个。相邻节点的物理连线极短，因此一跳通信的延迟极低。

3D Torus的度数（每个节点的邻居数）恒为6，不随Pod规模增大而变化。它的网络直径——任意两点间最远的最短跳数——随着每一维的长度S缓慢增长，具体为三倍的一维环直径。这意味着从Pod的一角到对角，最多只需跨过约1.5倍的边长总步数，通信成本远低于树状网络。

如同地铁把全城车站编织成立体巨网，3D Torus让消息能以极短路径在任意两站之间传递。接下来我们走进信号系统，看看消息在这张网上跑得有多快。

\displaystyle d_{\text{node}} = 2 \times D = 2 \times 3 = 6

公式说明：3D Torus中每个节点的度数为两倍维度数，代入D=3得到6个邻居。

d_node（节点度数）每个TPU节点直接连接的邻居数量，决定了消息能向多少个方向传递。
$d_{\text{node}}$
D（维度数）3D Torus在三个独立方向上都有连接，因此D等于3。
$D = 3$
2倍关系（每个维度双向邻接）每个维度上每个节点都有前后两个邻居，所以度数等于两倍的维度数。
$2 \times D$
代入计算（得出6）将D=3代入，得到每个节点连接6个邻居。
$2 \times 3 = 6$

通信延迟：专属信号隧道

炼芯城的地铁最自豪的是它的信号系统：列车没有红绿灯，信号在专属隧道内以接近物理极限的速度传播，穿越整座城市不过几个微秒。这就是TPU的秘密武器——专用芯片互联ICI。

TPU Pod的通信不经过PCIe总线，也不走以太网，而是使用名为ICI（Inter-Chip Interconnect）的专用协议直接连接TPU芯片。在TPU v3 Pod中，ICI的双向带宽达到约448 GB/s，相邻节点一跳的通信延迟约为2微秒（µs）。作为对比，数据中心网络中的跨机架通信延迟通常在几十微秒以上，而Pod内通信把这一数字压低了一个数量级。

在3D Torus中，消息从源节点到目的节点经过若干跳，每跳由IC Router转发。总延迟近似等于跳数乘以单跳延迟。跳数由源和目的在Torus上的坐标差决定，而微秒级的单跳延迟让即便跨越几十跳的通信也远快于其他互联方案。这种物理特性，使AllReduce等需要全集群频繁交换数据的集合操作能够高效执行。

信号在专属隧道中飞驰，让每一站都能与世界同步。这种微秒级的物理优势，为接下来要讲的“全城客流盘查”——集合通信——铺好了跑道。

\displaystyle L_{\text{total}} = H \times l_{\text{hop}}

公式说明：端到端总延迟等于消息经过的跳数乘以单跳延迟，是估算Torus通信延迟的基本公式。

L_total（总延迟）消息从源TPU到目标TPU的端到端时间，单位通常为微秒。
$L_{\text{total}}$
H（跳数）消息经过的中间TPU节点数量，由源和目的在Torus上的位置决定。
$H$
l_hop（单跳延迟）相邻两个TPU之间传输一次所需的时间，v3 Pod约2微秒。
$l_{\text{hop}}$
乘积关系（延迟累计）每一跳延迟累加，跳数越多总延迟越大。
$H \times l_{\text{hop}}$

集合通信：全城客流盘查

炼芯城每天深夜都要做一次全城客流盘查：每座车站统计当日进出站人数，然后所有车站必须拿到全城总数据。如果每座站都建一条直达中央的数据管道，中央很快就会瘫掉；更聪明的做法是让数据沿着环线接力传递——每站先汇总一部分，最后所有人共享完整结果。

这个“客流盘查”在分布式训练中就是AllReduce集合通信。每颗TPU完成本地前向与反向计算后，持有各自的梯度张量。AllReduce的目标是让所有节点都拿到所有梯度的总和或均值。最简单的星形方式（先汇聚到0号节点再广播）会产生严重的单点瓶颈；Ring AllReduce则巧妙利用了Torus上的环形路径。

Ring AllReduce分为两步：Reduce-Scatter阶段，环上每个节点把自己的梯度切成n份（n为节点数），把第i份发给下一个同伴，同时接收上一个同伴传来的数据并做累加；All-Gather阶段，把累加后的分片沿环继续扩散，最终每颗TPU都拿到完整的全局梯度。整个过程每个节点只发送和接收约两倍的“均匀份额”数据，通信负载完全均衡。

当1024座车站用接力而非放射状的方式完成盘查，效率提升了一个量级。理解了AllReduce，我们才能分析Pod的扩展效率为何能逼近线性。

\displaystyle \text{Comm}_{\text{ring}} = 2 \times \frac{n-1}{n} \times M

公式说明：Ring AllReduce中每个节点需要传输的数据量约等于两倍的均匀分片总量，随节点数n增大趋近于2M。

Comm_ring（单节点通信总量）Ring AllReduce中每个TPU节点收发数据的总字节数。
$\text{Comm}_{\text{ring}}$
M（梯度总大小）一次迭代中所有张量梯度的字节总数。
$M$
(n-1)/n（分片因子）每节点只处理全部数据的n等份中的n-1份，剩余一份由环上相邻节点承担。
$\frac{n-1}{n}$
乘以2（两个阶段）Reduce-Scatter与All-Gather两个阶段各传输一次相同量级的数据。
$2 \times \frac{n-1}{n} \times M$

扩展效率：城市增长的数学

如果炼芯城的地铁从1024座站扩到4096座站，城市的算力是不是也翻四倍？理想情况下是的，但新增的线路也会带来额外的协调成本——就像新设的车站需要参与客流盘查，增大了同步的负担。

在分布式训练中，扩展效率E定义为加速比S(p)与进程数p的比值，理想情况下E=100%（算力翻倍、时间减半）。TPU Pod能在数千颗核心上保持接近90%以上的扩展效率，主要得益于3D Torus的低通信开销和ICI的高带宽。但随着p增大，AllReduce等集合通信的总通信量增加，通信时间占比上升，扩展效率会缓慢下降。

设每一步迭代中通信时间与计算时间的比值为α，那么考虑通信开销后的扩展效率可以近似表示为分母为1加α(p-1)的形式。当α很小（例如0.01）时，即使p达到4096，效率依然能保持在98%附近；而当α较大时，效率会随规模明显下跌。这正是TPU Pod的通信设计如此重要的原因——把α压到极低，才能在超大规模下维持近线性扩展。

城市规模扩大后，每座站的平均协调成本略有上升，但炼芯城通过精巧的拓扑将“内耗”压到极限。要真正逼近线性扩展，还需要为千座车站设计聪明的运营策略。

\displaystyle E_p = \frac{1}{1 + \alpha (p-1)} \times 100\%

公式说明：扩展效率由通信占比α和节点数p共同决定，通信开销越低、规模越小时效率越接近100%。

E_p（扩展效率）p个节点相对单节点的实际加速与理想加速之比，以百分比表示。
$E_p$
α（通信占比）每一步迭代中通信时间与计算时间的比值，衡量通信开销的大小。
$\alpha$
(p-1)（规模效应）通信开销随节点数增加而线性放大，p越大通信比例越高。
$(p-1)$
整体表达式（效率计算）分母大于1，因此E_p总小于100%，体现分布式计算中的固有开销。
$\frac{1}{1 + \alpha (p-1)} \times 100\%$

并行策略：繁忙线路的调度

炼芯城的地铁运营有几套方案：方案A，把全城列车按线路均匀分配到各座车站，每站独立应对自己的客流；方案B，一条长线路由多座车站接力分段运营，每站只负责该段上的某个岗位。聪明的调度者会把两种方案混合起来。

这就是数据并行与模型并行的核心思想。数据并行中，每颗TPU持有一份完整的模型副本，处理不同的数据切片，每步迭代后通过AllReduce同步梯度。模型并行中，大模型被按层或按张量切分到不同TPU上，每颗芯片只负责模型的一部分，层与层之间通过激活值传递衔接。

在TPU Pod中，数据并行是最常见的模式，因为Pod的集合通信效率极高。但当模型大到单颗TPU装不下时（例如千亿参数模型），就必须使用模型并行或混合并行（数据并行与模型并行结合）。每一步迭代的总时间等于计算时间加通信时间：数据并行的瓶颈在AllReduce的梯度同步，模型并行的瓶颈在相邻层的激活传递。工程师需要根据模型结构、显存容量与Torus拓扑特征选择最优的组合配比。

就像地铁运营者决定哪些线路各自独立、哪些线路跨站协作，AI工程师需要为每个算子选择最合适的并行维度。接下来，看看调度者如何压减高峰期的通信拥堵。

\displaystyle T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}}

公式说明：单步迭代时间由计算时间和通信时间组成，优化训练吞吐的核心就是同时压缩这两项。

T_total（单步迭代时间）一次完整的梯度更新（前向计算、反向传播、梯度通信）总耗时。
$T_{\text{total}}$
T_compute（计算时间）TPU上执行矩阵乘法、激活函数等计算占用的时间。
$T_{\text{compute}}$
T_comm（通信时间）AllReduce或层间激活传递在互联网络上占用的时间。
$T_{\text{comm}}$
加法关系（时间构成）计算与通信可能部分重叠（见通信优化一节），理想情况下T_total会小于两者之和。
$T_{\text{compute}} + T_{\text{comm}}$

通信优化：高峰期的疏堵术

炼芯城的高峰期，列车上挤满了“乘客”——梯度数据。调度员想出一个妙招：把非关键的数据压缩后再运送，同时让列车在到站前就开始为下一站做准备，把通信和计算重叠起来。

通信优化的三大法宝是：梯度压缩、通信计算重叠与拓扑感知分配。梯度压缩通过量化、稀疏化和低秩分解减少AllReduce的数据量，例如把32位浮点梯度量化为8位甚至更低，通信量可以降到原来的四分之一甚至更少。通信计算重叠则是在反向传播计算某一层梯度时，提前启动已经完成部分的AllReduce，让计算引擎和通信引擎同时工作。

设压缩率为r，原始通信量为Comm，优化后的通信量Comm'等于r乘以Comm。当r降到0.25时，原本占单步时间40%的通信开销可能降到10%以内，训练吞吐大幅提升。现代量化方案配合误差补偿机制，可以把精度损失控制在可忽略的范围——这就像把乘客换乘时的冗余动作砍掉，但保证每个人都能到达正确目的地。

通过压缩与重叠，炼芯城在高峰期依然保持顺畅的客流交换。不过，即使全城网络优化到极致，如果任务被随意安置在错误的车站，长距离奔波仍会拖慢一切。

\displaystyle \text{Comm}' = r \times \text{Comm}

公式说明：梯度压缩后的通信量等于压缩比乘以原始通信量，压缩比越小节省的通信越多。

Comm'（优化后通信量）采用压缩等措施后每轮AllReduce的实际传输数据量。
$\text{Comm}'$
r（压缩比）压缩后的数据大小与原始数据大小的比值，例如8位量化约为0.25。
$r$
Comm（原始通信量）未优化前的梯度数据大小，通常与模型参数量正相关。
$\text{Comm}$
乘法关系（节省幅度）压缩比越小通信节省越多，但需要权衡压缩带来的精度影响。
$r \times \text{Comm}$

拓扑感知调度：亲和的同事们

当两个列车任务需要频繁协作时，炼芯城的调度员会把它们安排到相邻车站——这就是“亲和原则”。若把需要大量通信的服务一个放城东、一个放城西，即使地铁再快，长距离的奔波也会浪费大量时间。

在TPU Pod上训练模型时，XLA编译器与任务调度器需要把计算图（节点是算子）映射到物理TPU上，这个过程称为拓扑感知调度。它利用Torus的坐标信息，让通信量大的算子对应的TPU尽量靠近，减少跳数。这就像是把经常开会的部门安排在同一层楼，而不是隔着一整座园区。

拓扑感知调度的目标是最小化通信代价函数C：对所有存在通信的算子对，把通信量乘以它们在Torus上的最短跳数再求和。通过将计算图的高流量边映射到短距离位置，平均跳数可以下降30%以上，集合通信耗时显著缩短。Google的TPU编译器在编译阶段就会做这种图放置优化，配合任务调度器把数据并行副本放置到不同的Torus区域，避免互相干扰。

仿佛把频繁协作的地铁线路规划在同一条走廊内，炼芯城通过拓扑感知调度把通信拉近到物理极限。从蓝图、线路、信号到调度，这座AI算力之城终于全面运转起来了。

\displaystyle C = \sum_{i,j} w_{ij} \times d_{ij}

公式说明：拓扑感知调度把通信代价定义为所有算子对的通信量与物理距离的加权和，目标是最小化这个值。

C（总通信代价）整个计算图在Torus上执行时产生的加权通信成本，越小越好。
$C$
w_ij（通信权重）算子i和j之间需要传递的数据量，来自模型结构和并行策略。
$w_{ij}$
d_ij（物理距离）TPU i和TPU j在3D Torus中的最短跳数，由拓扑坐标决定。
$d_{ij}$
加权求和（总体累加）对所有存在通信的算子对求和，让大流量靠近、小流量拉远。
$\sum_{i,j} w_{ij} \times d_{ij}$

AI 应用场景

大规模大语言模型预训练

阶段：模型训练（分布式训练）

解决的问题：千亿参数模型的训练中，梯度同步的通信开销极大。传统GPU集群依赖InfiniBand或以太网，跨节点带宽有限、延迟较高；TPU Pod利用3D Torus拓扑和ICI互联，让AllReduce通信量趋近于最小的2倍梯度大小，通信延迟保持在微秒级，使数据并行与模型并行的混合策略能够高效执行。

具体案例：Google训练PaLM（5400亿参数）时使用数千颗TPU v4芯片组成多个Pod，在Pod内部通过ICI快速同步梯度，在Pod间通过数据中心网络协同，完成了超大规模的长时间预训练任务。

超大规模推荐系统训练

阶段：训练与在线更新

解决的问题：推荐系统的Embedding表巨大且稀疏，传统参数服务器架构的通信模式复杂、容易产生瓶颈。TPU Pod的拓扑感知调度可以把Embedding分片放在相邻TPU上，降低跨芯片通信距离，让AllGather等稀疏特征聚合操作更高效。

具体案例：YouTube的推荐模型在TPU v4 Pod上训练，利用Pod内微秒级通信对海量稀疏特征进行聚合，显著缩短了每日模型的训练和更新周期。

Python 演示

python59 行

"""TPU Pod 的 3D Torus 拓扑与 Ring AllReduce 通信模拟"""  class Torus3D:    """模拟 TPU Pod 的 3D Torus 环状互联拓扑"""     def __init__(self, dim_x=4, dim_y=4, dim_z=4):        self.dims = (dim_x, dim_y, dim_z)        self.nodes = []        for x in range(dim_x):            for y in range(dim_y):                for z in range(dim_z):                    self.nodes.append((x, y, z))        self.node_count = len(self.nodes)     def hop_distance(self, a, b):        """两个节点之间的最短跳数(环状取较小方向)"""        total = 0        for i in range(3):            diff = abs(a[i] - b[i])            total += min(diff, self.dims[i] - diff)        return total     def distance_stats(self):        """统计所有节点对的最短跳数分布"""        from collections import Counter        counter = Counter()        for i, a in enumerate(self.nodes):            for b in self.nodes[i + 1:]:                counter[self.hop_distance(a, b)] += 1        return counter  def ring_allreduce_comm(tensor_bytes, node_count):    """Ring AllReduce 单节点通信量 = 2 * (n-1) / n * 张量大小"""    per_node = tensor_bytes * (node_count - 1) / node_count    return 2 * per_node  def star_allreduce_comm(tensor_bytes, node_count):    """星形 AllReduce 中心节点通信量 = 2 * (n-1) * 张量大小"""    return 2 * (node_count - 1) * tensor_bytes  if __name__ == "__main__":    t = Torus3D(4, 4, 4)    stats = t.distance_stats()    pairs = t.node_count * (t.node_count - 1) // 2    avg_hops = sum(h * c for h, c in stats.items()) / pairs    print("[拓扑] 节点数:", t.node_count)    print("[拓扑] 平均最短跳数: %.2f" % avg_hops)     grad_bytes = 1_000_000    ring = ring_allreduce_comm(grad_bytes, t.node_count)    star = star_allreduce_comm(grad_bytes, t.node_count)    print("[通信] Ring AllReduce 单节点通信量: %.2f MB" % (ring / 1e6))    print("[通信] 星形 AllReduce 中心节点通信量: %.2f MB" % (star / 1e6))    print("[对比] Ring 是星形的 %.1f 分之一, 节省 %.1f%%" % (        star / ring, (1 - ring / star) * 100))

目的：构建一个4×4×4的3D Torus拓扑，计算平均最短跳数，并对比Ring AllReduce与星形AllReduce的通信量差距。

class Torus3D:定义一个TPU Pod的3D Torus拓扑类，存储各维度和全部节点坐标。
self.nodes.append((x, y, z))用三重循环枚举x、y、z三个维度上所有坐标，生成全部节点。
def hop_distance计算两节点间最短跳数，min(diff, self.dims[i] - diff) 考虑环状回绕。
counter[self.hop_distance(a, b)] += 1统计所有节点对的距离分布，用于计算平均跳数。
ring_allreduce_comm按照公式 2×(n-1)/n×M 计算Ring AllReduce中每个节点的通信量。
star_allreduce_comm计算星形AllReduce中中心节点的通信量，用于对比。
avg_hops = sum(...) / pairs用总跳数除以节点对数得到整个Torus的平均最短跳数。
print("[对比] ...")输出Ring相比星形的效率优势，直观展示拓扑感知通信的价值。

常见误区

误区TPU Pod不就是一个用高速网络连起来的GPU集群吗？芯片从NVIDIA换成Google自家的，训练方法完全一样。

正解TPU Pod的本质区别在于专用ICI互联与3D Torus拓扑。GPU集群通常依赖PCIe/NVLink加InfiniBand或以太网，拓扑多为树状或胖树；TPU的ICI是芯片直连的专用协议，3D Torus让通信跳数少、延迟低。这直接影响并行策略设计——GPU上常见的参数服务器架构在TPU Pod上就显得低效，因为Torus更适合Ring风格的集合通信。

为何常见：绝大多数AI从业者先接触GPU生态，容易把已有经验直接套到TPU上，忽略了底层互联架构的差异。

误区Torus听起来像全连接网络，每颗TPU都有直达其他所有TPU的线路，所以通信应该没有瓶颈。

正解3D Torus每个节点只有6个直接邻居，消息需要逐跳转发。优点是每个节点只连少量邻居，布线成本低、扩展性好；缺点是跳数随规模增长。TPU Pod之所以仍能保持微秒级延迟，是因为Pod内跳数少（直径小）且每跳延迟极低，而非全连接。

为何常见：从“高速互联”的宣传中容易推断出全连接，忽略了物理布线的现实约束。

误区AllReduce不就是把梯度加起来再广播吗？只要能算就行，网络拓扑影响不大。

正解AllReduce的性能直接取决于底层物理拓扑。Ring AllReduce的设计正是为了匹配环状/环形拓扑：数据沿环接力传递，负载均衡、无单点瓶颈。如果节点被随机放置在Torus上而不考虑拓扑，跳数增加，AllReduce耗时显著上升。这就是为什么TPU Pod的3D Torus必须配合拓扑感知调度一起使用。

为何常见：教材通常把AllReduce画成抽象的星形或全连接图，忽略了物理网络的实现细节。

误区TPU显存那么大，直接把整个模型放进每颗TPU做数据并行就够了，模型并行太麻烦。

正解模型规模增长远超单颗TPU的显存容量。千亿参数模型的参数和中间激活无法全部放进一颗TPU的HBM，必须使用模型并行将模型切分到多颗TPU；同时为了吞吐又会叠加数据并行。TPU Pod同时支持两种模式，选择依据是模型大小与拓扑通信特征，而不是“显存够不够大”。

为何常见：初学者常用的模型不大，数据并行够用，容易形成“大模型也放得下”的惯性思维。

误区梯度量化等压缩技术肯定会让模型精度大幅下降，所以不能用于TPU训练。

正解现代量化方案（如8位梯度量化、TopK稀疏化）配合误差补偿机制，能把精度损失控制在可忽略范围。Google在TPU生产训练中广泛使用这类优化，换来的是通信时间大幅下降、吞吐提升。精度与通信的权衡要通过实验验证，不能想当然。

为何常见：对压缩算法过于保守，缺少对误差补偿等纠偏机制的了解。

面试题

Q1. 在3D Torus拓扑中，每个TPU节点直接连接的邻居数量是？

单选题 · easy

A.3个
B.4个
C.6个← 正确答案
D.8个

答案：C。3D Torus在x、y、z三个维度上每个方向都有前后两个邻居，度数为2×3=6。选项A、B漏掉了部分维度，D则高估了连接数，把对角线邻居也算进去了。

Q2. TPU v3 Pod大约包含多少颗TPU核心？

单选题 · easy

A.256颗
B.1024颗← 正确答案
C.2048颗
D.4096颗

答案：B。TPU v3 Pod由1024颗TPU v3核心组成，而4096颗是TPU v4 Pod的规模。如果把Pod想象成炼芯城的“超级行政区”，v3是第一批建成的千站城区。

Q3. TPU Pod中ICI互联的相邻节点单跳延迟量级是？

单选题 · easy

A.纳秒级
B.微秒级← 正确答案
C.毫秒级
D.秒级

答案：B。ICI专用互联的单跳延迟约为2微秒，属于微秒级。它比原子操作（纳秒）慢，但比数据中心网络（毫秒级）快得多，是TPU Pod实现近线性扩展的物理基础。

Q4. 以下关于Ring AllReduce的描述，哪些是正确的？

多选题 · mid

A.依赖中心节点汇聚数据
B.通信量与节点数完全无关
C.分为Reduce-Scatter和All-Gather两步← 正确答案
D.各节点的通信负载非常均衡← 正确答案

答案：CD。Ring AllReduce不依赖中心节点（A错），而是沿环接力传递；单节点通信量公式为2×(n-1)/n×M，随n增大趋近2M，并非完全无关（B错）。它分为Reduce-Scatter和All-Gather两阶段（C对），每个节点数据量相同（D对），这正是它优于星形方案的关键。

Q5. 在3D Torus拓扑中，网络直径（任意两点间最大最短跳数）随每维长度S的增长呈现什么规律？

单选题 · mid

A.线性增长← 正确答案
B.对数增长
C.平方增长
D.保持不增长

答案：A。3D Torus的直径约为3×floor(S/2)，与每维长度S成正比，因此是线性增长。相比全连接（直径恒为1但布线成本高），Torus用线性增长的跳数换来了极低的物理布线成本和超低的单跳延迟。

Q6. 在TPU Pod上进行大模型训练时，以下哪些手段可以降低通信开销？

多选题 · mid

A.梯度量化压缩← 正确答案
B.通信计算重叠← 正确答案
C.增大Batch Size
D.拓扑感知的任务放置← 正确答案

答案：ABD。梯度量化直接降低通信量（A对），通信计算重叠让通信与计算并行从而隐藏开销（B对），拓扑感知放置缩短通信跳数（D对）。增大Batch Size虽能减少每步的相对通信频率，但不会从根本上降低通信数据量。

Q7. 一个4×4×4的3D Torus（共64个TPU节点）中，任意两个节点之间的平均最短跳数大约是多少？

单选题 · hard

A.约1.5跳
B.约2.4跳
C.约4跳← 正确答案
D.约6跳

答案：C。一维4节点环上相邻对距离为1（共4对）、对角对距离为2（共2对），平均一维距离约为1.33跳。三维Torus的平均距离等于三个维度平均距离之和，约4跳。这远小于树状网络中的跨层距离，体现了Torus的通信优势。

Q8. 当节点数n=64、梯度大小M=1GB时，Ring AllReduce中每个节点的平均传输数据量约为多少？

单选题 · hard

A.约1GB
B.约1.97GB← 正确答案
C.约63GB
D.约126GB

答案：B。代入公式Comm=2×(n-1)/n×M，即2×(63/64)×1≈1.97GB。选项C和D是星形AllReduce中中心节点的通信量量级，数值过大；选项A忽略了两个阶段的翻倍效应。

Q9. 在TPU Pod上训练千亿参数模型时，关于并行策略与通信的叙述，哪些是正确的？

多选题 · extreme

A.数据并行后需AllReduce同步← 正确答案
B.模型并行按层切分模型← 正确答案
C.混合并行结合二者策略← 正确答案
D.TPU Pod只支持数据并行

答案：ABC。数据并行每步迭代后通过AllReduce同步梯度（A对）；模型并行按层或张量把模型切分到多颗TPU（B对）；混合并行同时利用两种并行以兼顾容量与吞吐（C对）。TPU Pod同时支持数据并行和模型并行，D错误。设计思路就像炼芯城既安排独立线路，也安排跨站接力。

Q10. 以下哪项是TPU Pod实现近线性扩展的关键原因？

单选题 · easy

A.更高的CPU主频
B.专用ICI互联与Torus拓扑← 正确答案
C.更大的显存容量
D.更高的默认时钟

答案：B。近线性扩展的关键在于通信开销极低，而这来自两个设计：ICI专用芯片互联提供微秒级单跳延迟，3D Torus拓扑让任意节点间跳数随规模缓慢增长。CPU主频、显存容量和时钟频率都只是单点性能指标，无法解释数千颗芯片的高效协同。