如果把 AI 训练比作健身塑形，GPU 就像健身房里那位什么都会的全能教练——有氧、拉伸、力量训练都能带；而 TPU 则是只为“深度学习”这一个目标量身定制的顶级私教：动作编排、器械选择、训练节奏全都围绕神经网络设计，专业到极致。但你不可能为了几周的训练就去买下一整套私教团队，于是 Cloud TPU 出现了——它像一个“按秒计费的云端健身房”：扫码进店（创建实例），练几分钟算几分钟钱（按秒计费），练完不必锁门（释放即停费），甚至可以把整支私教团队同时请来（TPU Pod）带你的模型完成百亿参数的大工程。这篇文章就用这套“云端私教课”的故事，带你从零认识 Cloud TPU 的服务模型、计费方式、实例创建、分布式训练与性能调优，让你知道什么时候该掏这张“会员卡”，什么时候该用别的器械。

岗位关联

对 AI 从业者而言，Cloud TPU 是规模化训练绕不开的算力选项之一。理解它的选型逻辑、计费模式与调优手段，能直接帮你降低训练成本、提升迭代速度，并在与 GPU 集群的对比中做出更清醒的工程决策。

目录
  1. 可视化演示
  2. 服务模型：像健身房 App 一样随开随用
  3. 芯片规格：私教的硬功底决定训练上限
  4. 计费方式：闸机按秒跳表，练多久收多久
  5. 实例创建：从扫码开卡到训练跑通
  6. 分布式训练：私教团队带训大模型的接力赛
  7. 性能调优：把每个动作编排成最优序列
  8. 使用限制：哪些课这门健身房教不了
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Cloud TPU核心：脉动阵列矩阵乘法计算引擎(C=A×B)、TPU v2-v5版本算力演进对比、云服务弹性配置流程（API→VM→TPU→训练→释放）,三模式交互演示。

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

脉动阵列：TPU核心计算引擎 矩阵A从左向右流动，B从上向下流动 每个PE执行乘加运算，部分和累积输出 C = A × B (Systolic Array) 脉动架构实现高计算密度与高能效。

服务模型：像健身房 App 一样随开随用

想象你走进一家按秒计费的智能健身房：扫码开门、选器械、开练、练完走人，全程没有销售纠缠，也没有年卡绑架。Cloud TPU 的服务模型就是这套逻辑——你不是“买”一台超级计算机，而是通过 GCP 的云端 API 随时“预约”一组 TPU 芯片，用完即刻释放，账单一秒都不多算。对开发者来说，这意味着以前需要数月采购周期的高性能算力，现在几分钟就能出现在训练脚本里。

这套服务模型的核心是“按需创建”与“弹性释放”的组合拳。你可以像开健身课一样为一个实验创建若干个 TPU 实例，训练结束把实例删除，底层资源立刻归还给云端池子。云端 API 承担了所有调度工作：芯片分配、网络配置、驱动安装、健康检查通通自动化，用户拿到的是一个已经能跑 JAX 或 PyTorch 的“开箱即用”环境。

从工程视角看，服务模型解决的是算力供需错配。训练和推理任务的负载天然波动——上午压测、晚上低峰，按需模式让你只为实际使用的算力付费。这个模式的效果可以用算力利用率来衡量：

比起自建机房动辄 20% 的闲置率，云端健身房的自助模式把“器械吃灰”的浪费压到了最低。对 AI 团队来说，这意味着可以把预算从“买器械”挪到“请更好的教练”——也就是采购更高级的 TPU 版本去跑更大的模型。

R=TeffTtotal\displaystyle R=\frac{T_{\text{eff}}}{T_{\text{total}}}
它是“你真正用来训练的机器时间”占“租用总时间”的比例。云端按需模式把闲置时间压缩到趋近于零，利用率自然被拉高。
  1. 有效时间\(T_{\text{eff}}\) 表示芯片真正执行计算的时间，比如前向传播和反向传播占据的时长。
    TeffT_{\text{eff}}
  2. 总租用时间\(T_{\text{total}}\) 表示从创建到释放实例的全部时间，包含启动等待和排队停顿。
    TtotalT_{\text{total}}
  3. 取比值用有效时间除以总时间，得到的 \(R\) 越接近 1，说明钱都花在了刀刃上。
    TeffTtotal\frac{T_{\text{eff}}}{T_{\text{total}}}

芯片规格：私教的硬功底决定训练上限

私教好不好，要看他的专业功底；TPU 强不强，则要看芯片规格。Cloud TPU 的“肌肉”体现在三个维度：峰值算力、内存带宽、以及为张量运算专门设计的电路结构。当前主流选项是 TPU v4 和 v5 系列——v4 主打大模型预训练的高吞吐，v5e 则在推理和中小规模训练上做到了更好的性价比平衡，类似健身房里的“力量区专用器械”和“综合功能训练架”的分工。

TPU 芯片与 GPU 最本质的区别，在于它是“单晶圆级的矩阵乘法专精选手”。深度学习的主要计算是矩阵乘法和卷积，TPU 把这些运算做成了硬连线指令，省去了 GPU 上复杂的通用渲染管线开销。这意味着同等功耗下，TPU 的稠密矩阵吞吐可以远超同代 GPU。多块 TPU 通过高速互联组成集群时，峰值算力按芯片数近乎线性增长：

选私教不能只看“肌肉围度”，还要看他的“临场应变”——对 TPU 而言就是内存带宽。v4 系列在高带宽内存（HBM）上的设计，保证了参数和梯度在芯片间快速流转，不至于让计算单元饿肚子。因此，当你的模型是大规模 Transformer 这类访存密集任务时，TPU 的内存带宽优势会直接反映在更短的 step 时间上。

Fpod=Nchip×Fchip×η\displaystyle F_{\text{pod}} = N_{\text{chip}} \times F_{\text{chip}} \times \eta
它表示 Pod 集群的有效算力等于芯片数量 × 单芯片峰值 × 效率因子。\(\eta\) 受通信开销与负载均衡影响，通常介于 0.3 到 0.8 之间。
  1. 芯片数\(N_{\text{chip}}\) 是集群中 TPU 核心的总数，比如一个 v4-32 Pod 就是 32 块芯片。
    NchipN_{\text{chip}}
  2. 单芯片峰值\(F_{\text{chip}}\) 表示单个 TPU 在稠密矩阵运算上的理论峰值，比如 TPU v4 单芯片达到数百 TFLOPS。
    FchipF_{\text{chip}}
  3. 效率因子\(\eta\) 是实际折扣系数，因为跨芯片通信、访存墙和调度不均都会吃掉一部分算力。
    η\eta
  4. 相乘得到有效算力三者相乘得到集群实际能发挥出的算力，这是预估训练吞吐量的基础。
    Nchip×Fchip×ηN_{\text{chip}} \times F_{\text{chip}} \times \eta

计费方式：闸机按秒跳表，练多久收多久

健身房的闸机在你扫码进门的瞬间开始跳表，出门即停——Cloud TPU 计费模式正是如此，最小计费粒度不是小时而是秒。这种设计彻底改变了算力消费习惯：GPU 云主机按小时收费时，你会下意识把任务凑满一小时；而 TPU 按秒计费后，你可以在实验完成后立刻释放实例，闲置浪费几乎归零。而这背后是三种计费模式并行：按需付费、抢占式实例和承诺使用折扣。

按需付费适合任务节奏不确定的场景，随开随停但单价最高；抢占式实例像“限时体验课”——价格极低但随时可能被更高优先级的任务挤掉，适合容错的科研实验；承诺使用折扣则类似健身房的年卡，你预先承诺使用量（比如一年 1000 芯片小时），换取 40%-70% 的折扣，适合训练计划稳定的团队。总费用的公式实际上非常简单：

正因为计费粒度细到秒，成本控制的策略也跟着精细化。一个常见的省钱套路是：大批量实验用抢占式实例试错，模型定型后再用承诺使用折扣跑正式训练。这也提醒我们，Cloud TPU 省钱的前提是“用完即释放”的纪律——如果创建了实例却忘记删除，闸机就会在你离开后继续跳表，直到余额见底。

C=(psec⁡×trun)×Nchip\displaystyle C = \left( p_{\sec} \times t_{\text{run}} \right) \times N_{\text{chip}}
总花费 = 每芯片每秒单价 × 运行秒数 × 芯片数量。三者的乘积把“用多少、用多久、用几块”全部量化成账单。
  1. 每秒单价\(p_{\sec}\) 是每颗 TPU 芯片每秒钟的价格，由芯片型号和计费模式决定，按需最贵、抢占式最便宜。
    psec⁡p_{\sec}
  2. 运行秒数\(t_{\text{run}}\) 是实例从创建到释放的实际存活时间，精确到秒，重启和排队不算使用时长。
    trunt_{\text{run}}
  3. 芯片数量乘以 \(N_{\text{chip}}\) 是因为账单按资源总量计费，用 8 颗芯片跑一小时就是单颗的 8 倍。
    NchipN_{\text{chip}}

实例创建：从扫码开卡到训练跑通

在云端健身房练一次完整的力量训练，流程大致是：打开 App 预约时段、工作人员审核训练方案、到店扫码开卡、器械启动、训练结束结账离场。Cloud TPU 的实例创建完全对应这条链路。第一步是“预约”，即在 GCP 控制台或通过 API 申请 TPU 资源——你要指定芯片版本（v4 还是 v5e）、芯片数量、运行区域和软件框架镜像。

第二步是“审核”，GCP 会根据你的项目配额历史和使用需求审批资源。配额不是无限的——它像一个健身房对会员“同时可预约课程数”的上限，新项目默认配额往往只有几个芯片，需要提交工单说明训练规模后才会提升。第三步才是真正的“扫码开卡”，系统创建实例并完成初始化：加载操作系统、挂载存储、配置网络、启动 JAX 或 PyTorch 运行时，几分钟后你就能通过 SSH 连上去开始训练。

在创建之前，你需要先回答一个关键问题：这个任务需要算力估算是多少？这决定了你要申请几颗芯片：

实例创建完成后，生命周期管理就是常态工作了。训练中途断点续训要保留实例还是释放重建？实验结束立即执行删除命令，还是留着跑下一次调参？这些决策直接影响成本和可用性。惯例是：把 TPU 实例视为“一次性的训练沙箱”，代码、数据、模型权重都保存在持久化存储里，TPU 本身随时可弃——这样心态，才能把弹性释放的妙处用到极致。

Nchip=WopsFchip×ttarget×η\displaystyle N_{\text{chip}}=\frac{W_{\text{ops}}}{F_{\text{chip}}\times t_{\text{target}}\times \eta}
所需芯片数 = 总计算量 ÷（单芯片算力 × 目标时间 × 效率因子）。用它能快速判断一个训练任务该配多大的 TPU 实例。
  1. 总计算量\(W_{\text{ops}}\) 是训练总浮点运算次数，由参数量、数据量和训练轮数决定，单位是 FLOPs。
    WopsW_{\text{ops}}
  2. 单芯片算力\(F_{\text{chip}}\) 是单颗 TPU 的峰值 FLOPs 每秒，作为估算的基准值。
    FchipF_{\text{chip}}
  3. 目标时长\(t_{\text{target}}\) 是你期望的训练完成时间，比如计划 3 天跑完，就换算成秒。
    ttargett_{\text{target}}
  4. 折算效率除以 \(\eta\) 是因为现实训练不可能达到理论峰值，留出余量才能避免任务跑不完。
    η\eta

分布式训练：私教团队带训大模型的接力赛

当模型大到单颗芯片放不下时，你需要的不再是一个私教，而是一支私教团队——TPU Pod 正是为此而生。它是多颗 TPU 通过超高速专用互联组成的紧耦合集群，传输带宽远高于普通数据中心网络，仿佛私教们戴着无线耳麦随时同步动作。两个主流深度学习框架 JAX 和 PyTorch 都原生支持 Cloud TPU，前者通过 jax.devices() 一行代码感知所有 TPU 设备，后者则通过 XLA 后端完成类似的无缝对接。

分布式训练最常见的是数据并行：每个芯片持有完整模型副本，但读取不同的数据切片，算完梯度后做全局同步。想象一支私教团队给十个学员同时开小灶，每个私教用同一套教案教不同的学员，每教完一小节就聚在一起交换心得（梯度同步），保证所有学员的进度一致。这里的加速比不可能是完美的线性，因为通信开销会随芯片数增长：

在 Pod 级的训练中，TPU 的互联拓扑是天然为 AllReduce 设计的，这让大规模 Transformer 预训练的效率远超同规模 GPU 集群。但要注意：Pod 不是简单地“多卡拼一台机器”，它的调度、分片策略和对数据管线的要求都更复杂。用 JAX 的 pmap 或 PyTorch 的 FSDP 把模型并行地铺到整支团队上，是发挥 Pod 优势的必修课。

S(N)=N1+(N−1)×α\displaystyle S(N)=\frac{N}{1+(N-1)\times \alpha}
加速比 = 芯片数 ÷（1 + （芯片数-1） × 通信开销比例）。\(\alpha\) 越接近 0，扩展效率越高。
  1. 芯片数\(N\) 是参与并行训练的芯片总数，Pod 规模越大 \(N\) 越大。
    NN
  2. 通信开销比例\(\alpha\) 是每次梯度同步耗掉的额外时间占计算时间的比例，取决于互联带宽和数据量。
    α\alpha
  3. 分母修正\(1+(N-1)\times \alpha\) 表示随着芯片变多，通信叠加的耗时也在长，这就是加速比衰减的根源。
    1+(N−1)×α1+(N-1)\times \alpha
  4. 整体比值分子 \(N\) 是理想线性加速，分母是对现实的折扣，二者相除得到真实加速比。
    N1+(N−1)×α\frac{N}{1+(N-1)\times \alpha}

性能调优：把每个动作编排成最优序列

私教的价值不只是会示范动作，更在于能针对你的体能把整套训练流程编排到最优——先热身、再力量、后有氧，组间休息精确到秒。Cloud TPU 的 XLA 编译器承担的正是“编排”职责：它把 PyTorch / JAX 写的高级计算图，编译成针对 TPU 硬件特性优化的底层指令序列，自动完成算子融合、内存复用和循环变换。数据管线则是“送水送毛巾的补给线”——如果数据加载跟不上芯片的计算速度，再强的算力也会原地等水喝。

性能调优的核心思路，是看清时间到底花在哪里。一个训练 step 的总耗时可以拆成计算时间和访存/通信时间，XLA 优化的本质就是压缩后者：

在实操层面，调优路径通常有四步：第一，用 xla_flags 开启自动优化并把 HLO 计算图打印出来看冗不冗余；第二，用 tf.data 或 JAX 的异步数据加载把数据管线与计算管线下游重叠；第三，针对 Pod 规模调 batch size，让矩阵形状匹配 TPU 的脉动阵列尺寸；第四，用 Cloud TPU 自带的 profiling 工具定位“计算空转”的区间。经过这四步，很多模型的训练吞吐能直接翻倍，相当于没加钱就换了个更会编排的私教。

t′=tcompute+r×tmemory\displaystyle t' = t_{\text{compute}} + r \times t_{\text{memory}}
优化后的 step 时间 = 纯计算时间 + 打折后的访存时间。\(r\) 越小，说明编译器把数据搬运优化得越狠。
  1. 纯计算时间\(t_{\text{compute}}\) 是矩阵乘法等运算真正占用芯片的时间，这部分几乎无法压缩。
    tcomputet_{\text{compute}}
  2. 访存时间\(t_{\text{memory}}\) 是数据在内存和计算单元之间搬运的时间，常成为瓶颈。
    tmemoryt_{\text{memory}}
  3. 压缩系数\(r\) 是 XLA 优化后的访存缩减率，算子融合能把多次搬运合成一次，让 \(r\) 降到 0.3 以下。
    r×tmemoryr \times t_{\text{memory}}

使用限制：哪些课这门健身房教不了

再好的私教也有不擅长带的项目，Cloud TPU 同样有明确的使用边界。首先是区域限制：TPU 的物理资源只部署在 GCP 的部分区域（如 us-central1、europe-west4），且热门芯片版本常有排队等待，像热门私教的档期一样需要提前预约。其次是生态绑定：TPU 的加速引擎深度依赖 XLA 编译器，如果你的模型结构在 XLA 中不支持，性能会断崖下跌，这说明不是所有代码都能无痛搬上 TPU。

TPU 与 GPU 的选型之争，是工程团队最常纠结的问题。GPU 生态成熟、算子覆盖全、调试工具丰富，就像全能教练什么课都能带；TPU 则在超大矩阵的稠密计算上性能碾压、低成本高吞吐，是专精大模型预训练的“金牌私教”。用性价比公式来量化选择：

最终的选型建议可以浓缩成三条：如果你的任务是大规模 Transformer 预训练、框架已经切换到 JAX 或 PyTorch+XLA，且训练计划稳定——闭眼选 Cloud TPU；如果模型结构频繁迭代、涉及大量自定义算子，GPU 集群的更灵活；如果只是做短平快的实验，抢占式 TPU 是最具性价比的“临时体验课”。认清边界，才能真正享受这门云端私教课带来的加速红利。

E=Fpod×η×TC\displaystyle E=\frac{F_{\text{pod}}\times \eta \times T}{C}
单位成本能换到的计算量 = 有效算力 × 运行时长 ÷ 总成本。\(E\) 越高，这笔算力投资越划算。
  1. 有效算力\(F_{\text{pod}}\times \eta\) 是集群实际发挥的算力，对应前面讨论的峰值折扣。
    Fpod×ηF_{\text{pod}}\times \eta
  2. 运行时长乘以 \(T\) 得到在总运行时间内完成的总浮点运算量。
    TT
  3. 总成本除以 \(C\) 得到每花一美元换来的计算量，\(E\) 就是算力性价比的终极指标。
    Fpod×η×TC\frac{F_{\text{pod}}\times \eta \times T}{C}

AI 应用场景

大语言模型的分布式预训练

阶段：模型训练与调优

解决的问题：百亿甚至千亿参数的大语言模型，单机能装但训练时间长得不可接受；自建 GPU 集群采购周期以月计，且扩展性受制于机房电力与互联带宽。Cloud TPU Pod 以高速互联的紧耦合算力组，把传统需数月的预训练压缩到数周。

具体案例：某研究团队用 32 个 TPU v4 芯片组成的 Pod，配合基于 JAX 开发的 GPT 风格模型训练框架，把 130 亿参数模型的预训练周期从 3 个月缩短到 3 周。他们在创建 Pod 时通过 GCP API 一次性申请全部资源，训练期间按秒计费，实验结束立即释放。

科研实验的批量弹性算力

阶段：实验管理与成本优化

解决的问题：科研机构往往有大量参数扫描、消融实验等短时任务，任务间负载波动大，用按小时计费的 GPU 会浪费大量预算。抢占式 TPU 实例以远低于按需价的价格提供算力，实验脚本自动重试即可容错。

具体案例：某 NLP 实验室用 Python 脚本向 GCP 批量创建 30 个抢占式 v5e 实例，每个实例运行一组超参数组合，基于 JAX 的并行训练程序自动完成 check-point 上传；被抢占的实例在恢复后从断点续跑。一个月下来，承担同等实验量的开销比自建 GPU 服务器低约 60%。

Python 演示

python69 行
"""模拟 Cloud TPU 生命周期管理：按秒计费 + 弹性释放"""import time  class TPUCluster:    """一个极简的 Cloud TPU 集群模拟器"""     def __init__(self, price_per_chip_hour, chips, version):        self.chips = chips        self.version = version        self.price = price_per_chip_hour / 3600.0  # 换算成每秒每芯片价格        self.instances = {}        self._seq = 0     def create(self, name, mode="on-demand"):        """创建一个按需或抢占式实例"""        self._seq += 1        inst = {            "id": self._seq,            "name": name,            "mode": mode,            "uptime": 0.0,            "cost": 0.0,            "running": True,        }        self.instances[name] = inst        return name     def tick(self, seconds=1.0):        """模拟时间流逝，为所有运行中的实例累计费用"""        for inst in self.instances.values():            if not inst["running"]:                continue            inst["uptime"] += seconds            inst["cost"] += seconds * self.price * self.chips     def release(self, name):        """释放实例，返回该实例累计费用"""        inst = self.instances[name]        inst["running"] = False        return inst["cost"]     def summary(self):        """打印集群中每个实例的当前状态"""        for inst in self.instances.values():            state = "运行中" if inst["running"] else "已释放"            print(                f"[{inst['name']}] {state} | 模式={inst['mode']} | "                f"运行 {inst['uptime']:.1f}s | 费用 ${inst['cost']:.4f}"            )  def main():    # 模拟一个 8 芯片 TPU v4 实例，按需价格约 3.22 美元/芯片/小时    cluster = TPUCluster(price_per_chip_hour=3.22, chips=8, version="v4")     cluster.create("transformer-pretrain")    cluster.create("grid-scan", mode="preemptible")     cluster.tick(30)                      # 训练第一批数据    cost_a = cluster.release("transformer-pretrain")  # 主干任务释放    cluster.tick(60)                      # 抢占式实验继续跑     cluster.summary()    print(f"释放 transformer-pretrain 时已花费: ${cost_a:.4f}")  if __name__ == "__main__":    main()
目的：演示 Cloud TPU 的核心用法——按需创建、按秒计费、随时释放。TPUCluster 类模拟了实例管理、费用累计和释放结算流程。
  1. self.price = price_per_chip_hour / 3600.0把每小时单价换算成每秒单价，串起了按秒计费的核心逻辑。
  2. inst["uptime"] += seconds记录每块芯片的累计运行时长，这是账单计算的基础。
  3. inst["cost"] += seconds * self.price * self.chips费用 = 秒数 × 每秒单价 × 芯片数，和上文的计费公式完全对应。
  4. cluster.create("grid-scan", mode="preemptible")创建一个抢占式实例，模拟低价但可能被回收的任务场景。
  5. cluster.release("transformer-pretrain")释放实例后，它的费用冻结在释放时刻——这就是“练完即走、停止计费”的代码表达。

常见误区

误区认为 Cloud TPU 就是一块更快的 GPU，任何模型买来就能跑，而且一定比 GPU 快好几倍。

正解TPU 是“专精一门课的金牌私教”——它把全部硬件资源都押在张量运算上，只有模型的计算图能顺畅映射到它的脉动阵列上时才有性能优势。如果模型里有大量 XLA 不支持的动态 shape 或自定义算子，代码可能根本编译不过去，或者性能断崖下跌。

为何常见：厂商宣传材料都强调峰值算力数字，容易让人误以为算力高就等于通用性强，忽略了编译器与硬件协同的约束。

误区既然按秒计费、价格细分，那创建了 TPU 就让它开着，反正用完再删也不贵。

正解按秒计费的精确性是双刃剑：它让“秒级释放”成为省钱武器，但也意味着闲置一秒就扣一秒的钱。8 块芯片的 v4 实例闲置一天，浪费的金额相当于 200 多节私教课的费用。云厂商计费从来只有“用多少付多少”，没有“不用不付”的豁免。

为何常见：人们习惯了按小时计费时“多用多赚”的补偿心理，忽略了按秒模式下账单同样随秒数线性累积。

误区认为 TPU Pod 和一台 8 卡 GPU 服务器没什么区别，不就是 32 块芯片插在一起嘛，任务直接跑就好了。

正解Pod 的算力来自极低延迟的高速互联拓扑，通信带宽比普通数据中心网络高一个数量级。但要发挥这种硬件能力，必须让训练框架感知拓扑，合理配置数据并行、张量并行和梯度同步策略。否则通信模式不匹配，Pod 的加速比会从接近线性跌到惨不忍睹。

为何常见：从“单机多卡”迁移到“Pod 集群”时，人们习惯性地沿用单机多卡的并行模式，低估了跨主机互联对并行策略的重新约束。

误区认为 batch size、学习率、数据预取等调优参数，从 GPU 搬到 TPU 上同样适用，顶多微调一下。

正解TPU 的矩阵单元形状、内存层级和 XLA 编译策略和 GPU 差异巨大。比如 TPU 对 batch size 的整除性极其敏感，非对齐的矩阵形状会导致算力利用率腰斩；数据管线如果不做异步预取，芯片会在等待数据中空转大半时间。调优必须回到 profiling 工具上重新校准。

为何常见：两者都叫“加速器”，且在框架层面 API 相似，让人误以为底层性能特征也相似——实际是“同样叫深蹲，但杠铃路径和发力节奏完全不同”。

面试题

Q1. Cloud TPU 的最小计费粒度是多少？

单选题 · easy

  • A.按小时计费，不足一小时按一小时算
  • B.按秒计费，释放即停止记时← 正确答案
  • C.按分钟计费，向上取整到分钟
  • D.按天计费，每天零点结算

答案：B。Cloud TPU 的核心卖点就是按秒计费，创建后每秒都在累计费用，释放后立刻停止计费。按小时或按天是传统云主机的模式，无法体现 TPU 弹性释放的优势。

Q2. 以下哪些深度学习框架可以直接运行在 Cloud TPU 上？

多选题 · mid

  • A.JAX 框架← 正确答案
  • B.PyTorch 框架← 正确答案
  • C.纯 C 语言
  • D.虚拟化指令

答案：AB。JAX 是 Google 官方主推 TPU 的框架，jax.devices() 可直接感知 TPU；PyTorch 通过 XLA 后端也支持 TPU 训练。纯 C 语言和虚拟化指令不属于深度学习框架，无法直接驱动 TPU。

Q3. TPU 芯片最初为哪种运算做了专门优化？

单选题 · easy

  • A.图形渲染与光线追踪
  • B.深度学习张量运算← 正确答案
  • C.关系型数据库查询
  • D.网页静态资源加载

答案：B。TPU 从第一代起就专注于深度学习的核心运算——大规模矩阵乘法与卷积。而 GPU 的通用并行架构包含图形渲染能力，需要额外单元做兼容，这也是 TPU 在稠密矩阵上更高效的原因。

Q4. 抢占式 TPU 实例的主要特点是什么？

单选题 · mid

  • A.价格更低但可能被系统回收← 正确答案
  • B.价格更高但性能翻倍
  • C.只能运行推理任务不能训练
  • D.完全不计费仅限体验

答案：A。抢占式实例以显著折扣提供算力，本质是云端把空闲资源出租，遇到高优先级需求会被抢占回收。它适合容错任务，而非不能运行训练或零计费。

Q5. TPU Pod 相比单块 TPU 的核心优势是什么？

单选题 · mid

  • A.芯片主频自动翻倍提高单卡性能
  • B.通过高速互联将多块芯片组成紧耦合集群← 正确答案
  • C.可以脱离编译器直接运行任意代码
  • D.内置数据存储空间自动扩展

答案：B。TPU Pod 的价值在于专用高速互联把大量 TPU 芯片变成一个整体，支持数据并行和张量并行。主频翻倍、脱离编译、内置存储都不是 Pod 的本质特征。

Q6. 释放 Cloud TPU 实例后会发生什么？

单选题 · easy

  • A.费用立刻停止，资源归还云端← 正确答案
  • B.继续计费直到次日零点
  • C.实例自动保存并原址重启
  • D.数据自动迁移到 GPU 实例

答案：A。释放操作等价于健身房训练结束离开门店——闸机停止计费，器械归还给下一位用户。实例销毁后其本地磁盘数据也消失，需要靠持久化存储保存模型权重。

Q7. 以下哪些是提升 Cloud TPU 训练性能的有效手段？

多选题 · hard

  • A.开启 XLA 编译优化算子融合← 正确答案
  • B.使用异步数据加载重叠管线← 正确答案
  • C.在训练循环里增加日志刷新
  • D.调整 batch size 匹配脉动阵列← 正确答案

答案：ABD。XLA 编译（A）融合算子减少访存，异步数据加载（B）避免芯片空转，batch size 对齐（D）提高矩阵单元利用率。C 选项的日志刷新会增加 IO 阻塞，反而拖慢训练。

Q8. 相比自建 GPU 集群，Cloud TPU 的优势有哪些？

多选题 · mid

  • A.无需机房运维与硬件采购← 正确答案
  • B.资源弹性伸缩按需使用← 正确答案
  • C.自动兼容所有计算框架
  • D.按秒计费无闲置浪费← 正确答案

答案：ABD。云服务免去运维与采购（A），弹性伸缩（B）和按秒计费（D）是云原生的核心收益。C 错误——TPU 依赖 XLA 编译生态，并非所有框架和算子都兼容。

Q9. 一块 TPU v4 单芯片峰值算力 275 TFLOPS，用 4 块芯片组成集群训练，实测效率因子为 0.6，该集群的有效算力是多少？

单选题 · hard

  • A.660 TFLOPS← 正确答案
  • B.1100 TFLOPS
  • C.275 TFLOPS
  • D.137.5 TFLOPS

答案：A。按公式 F_pod = N_chip × F_chip × η 计算：4 × 275 × 0.6 = 660 TFLOPS。1100 是忽略效率因子的理论值，275 是单芯片峰值，137.5 是仅取一半效率的错误算法。

Q10. 以下哪种任务最能发挥 Cloud TPU v5e 的优势？

单选题 · extreme

  • A.大量小矩阵的 CPU 推理服务
  • B.超大 batch 的 Transformer 预训练← 正确答案
  • C.IO 密集的短事务数据查询
  • D.低精度图形渲染管线

答案：B。TPU v5e 被定位为高效训练与推理的中坚型号，超大 batch 的 Transformer 预训练正是稠密张量运算和高内存带宽的典型场景。小矩阵 CPU 服务、IO 查询和图形渲染分别属于 CPU、存储和 GPU 的领域。