简介：本文从硬件架构、互联拓扑、训练与推理成本结构等维度，对TPU与GPU两类AI算力方案进行系统对比。文章不局限于纸面峰值性能，而是结合MFU、Prefill与Decode场景差异、互联假设与运维成本，帮助技术负责人和架构师理解两类方案的本质分歧，并给出基于场景的选型判断框架。
在AI基础设施选型中，TPU与GPU的讨论长期存在一个误区：将两类芯片简化为“谁的峰值算力更高”或“谁的显存带宽更大”。实际上，当训练集群规模扩展到数千卡乃至万卡以上，推理负载进一步分化为Prefill与Decode两种截然不同的资源消耗模式后，单纯比较单芯片规格已经无法支撑真实的TCO判断。
近期有分析机构对Google TPU最新一代产品进行了深度拆解，试图从硬件规格、互联拓扑与TCO模型三个层面建立系统性的对比框架。这份拆解的贡献在于：它把3D Torus加光电路交换的设计哲学，以及TPU与主流GPU在训练、推理场景下的成本结构差异，推到了可计算的层面。但其结论存在若干需要审慎对待的前提假设。
本文基于该分析框架，结合训练、Prefill、Decode三类场景的再拆解，对TCO效率路线进行重新梳理。核心结论可以概括为三点：第一，TCO的“最优解”高度依赖场景，不存在适用于所有负载的单一答案；第二，TPU的3D Torus互联与GPU的交换式全互联之间的本质分歧，不在于谁更快，而在于对流量形态的假设；第三，TPU在训练场景建立的成本护城河，在最新一代产品中正在被显著削弱。
TPU方案的核心设计取向是“领域专用”。从硬件角度看，其计算单元、片上存储与互联拓扑都围绕大规模、规则化、可预测的深度学习负载进行裁剪。TPU在训练集群中通常采用3D Torus拓扑，相邻芯片之间通过直接链路连接，形成三维环面结构。对于跨机架乃至跨集群的长距离连接，则通过光电路交换实现动态配线，从而在物理层面对通信路径进行重配置。
这种设计的隐含假设是：通信模式是可以预先编排的。当训练任务的数据并行、模型并行、流水线并行的切分方式在编译期确定后，TPU的编译器可以针对特定通信模式优化路由，减少拥塞和非必要的数据搬运。换句话说，TPU的硬件架构和软件栈是强耦合的，性能收益来自软硬件协同设计带来的编排效率。
GPU方案的演进路径则更接近“通用加速平台”。其单芯片架构在不断强化张量计算能力的同时，保留了更宽的编程模型兼容性。在互联层面，主流GPU集群通常采用交换式全互联架构，通过高带宽交换芯片将大量GPU节点组织成非阻塞或低阻塞的Fat-tree拓扑。在这种架构下，任意两个GPU之间的通信不需要依赖固定的物理邻接关系，交换层负责数据包的转发。
这种设计的隐含假设是：通信流量形态是不确定的，可能随着负载类型、并行策略和模型结构的变化而显著变化。因此，用交换网络的全互联能力来换取对任意通信模式的容忍度，比针对特定模式做深度优化更具通用性。
尽管TPU与GPU在设计哲学上分道扬镳，但从系统层面看，两者仍存在若干共同目标与基础能力。
第一，都在解决同一类核心问题：大规模张量运算的算力密度与数据供给效率。 无论TPU还是GPU，训练大语言模型和多模态模型的核心瓶颈都是：如何在可接受的功耗和成本范围内，维持计算单元的高利用率，同时保证数据从存储到计算单元之间的供给不成为瓶颈。
第二，都依赖大规模互联来突破单芯片算力上限。 当模型参数规模超过单芯片存储能力后，任何方案都必须通过多芯片协作来分摊计算与存储压力。TPU的3D Torus和GPU的Fat-tree，本质上都是对这一问题的不同回答。
第三，都需要软件栈深度参与性能优化。 TPU依赖编译器对计算图进行静态分析和通信编排，GPU方案同样需要针对并行策略、显存分配、通信与计算重叠进行精细调优。两者的实际MFU表现，往往取决于软件优化的成熟度，而非单纯由硬件决定。
第四，都在推理场景面临Prefill与Decode的分化。 无论哪类芯片，Prefill阶段通常受算力约束，需要尽可能高的计算吞吐；Decode阶段则受存储带宽约束，每生成一个token都需要读取模型权重。这种负载分化对硬件架构提出了截然不同的需求。
TPU的3D Torus加OCS架构，其优势在于局部通信。当训练负载的通信模式在编译期已知且具有空间局部性时，相邻芯片之间可以直接通过Torus链路完成数据交换，避免经过交换层带来的额外延迟和拥塞。对于万卡规模的规则化训练任务，这种设计能够维持较高的MFU。
但其劣势同样明显：对于不规则流量，例如MoE模型中专家路由导致的动态All-to-All通信，Torus拓扑的固定邻接关系可能造成绕路和拥塞。TPU软件栈中的大量优化，本质上是在通过调度和路由选择来弥补拓扑结构对不规则流量的天然劣势。
GPU的Fat-tree交换网络则相反。它不假设通信模式是规则的还是动态的，任何芯片之间的数据交换都经过交换层。在流量形态规整时，这种设计可能引入额外的交换延迟；但在流量形态高度动态时，全互联能力避免了固定拓扑的绕路开销。两种架构的根本差异，可以总结为：TPU用静态拓扑换取规则负载下的效率峰值，GPU用动态交换换取未知负载下的稳定表现。
在训练场景的TCO对比中，MFU是一个关键变量。有分析假设TPU的MFU比GPU高约5到10个百分点，并据此得出TPU在训练成本上领先45%到56%的结论。但这一假设需要审慎对待。
公开的FP8精度下MFU数据仍然有限。虽然TPU在BF16精度下表现出较高的稳定性，但在FP8这种对硬件与软件协同要求更高的精度下，两种方案的实际MFU差距尚未被充分验证。与此同时，已有团队在BF16精度下将主流GPU的MFU优化到与TPU接近的水平，说明GPU方案的MFU差距并非不可弥合，关键在于软件优化的投入程度。
这意味着，训练TCO对比中的“TPU优势”，很大程度上建立在一个尚未被充分证实的MFU差值之上。如果差距缩小到5个百分点以内，基于当前硬件采购与运维成本模型，训练TCO的对比结论可能发生实质性变化。
推理场景的TCO画像与训练存在显著差异。在Prefill阶段，系统需要一次性处理大量的输入token，此时算力密度是核心约束。有分析指出，支持FP4精度的GPU方案在Prefill阶段的成本效率可以反超TPU约35%到50%。这一差距的来源在于：FP4在保持可接受精度的前提下，有效翻倍了计算吞吐，而TPU当前方案在低精度算力上的优势并不明显。
在Decode阶段，理论分析通常强调HBM带宽的重要性，并据此认为TPU的高带宽设计具有优势。但实际测试表明，Decode阶段的性价比差距远没有纸面带宽数字显示的那么大。原因在于：Decode阶段的实际吞吐还受到批处理效率、调度策略、KV Cache管理方式和尾延迟要求等因素的影响，单纯比较带宽峰值无法准确反映真实成本。
TPU方案的一个显著特点是软硬件强耦合。这种设计在负载规整时可以带来显著的效率收益，但也意味着：一旦负载类型偏离预设模式，性能可能出现非线性下降。对于需要频繁试验新模型结构、新并行策略的团队而言，这种约束可能拖慢迭代效率。
GPU方案由于生态的通用性，在框架兼容性、开发工具丰富度和人才储备方面具有明显优势。相应的代价是：要达到较高的MFU，需要投入更多的性能调优工作。两种方案的运维复杂度结构不同：TPU的运维负担集中在如何让负载适配架构，GPU的运维负担集中在如何让架构适配负载。
| 对比维度 | TPU方案 | GPU方案 |
|---|---|---|
| 单芯片设计取向 | 领域专用，软硬件强耦合 | 通用加速，编程模型兼容性更宽 |
| 互联拓扑 | 3D Torus + 光电路交换 | 交换式全互联 / Fat-tree |
| 核心架构假设 | 通信模式可预测、可编排 | 流量形态不确定，需容忍动态通信 |
| 训练场景优势 | 规则化万卡训练负载下MFU较高 | 灵活实验、MoE等不规则负载下更稳健 |
| 推理Prefill优势 | 相对有限，低精度算力优势不显著 | FP4等低精度下算力领先明显 |
| 推理Decode优势 | 理论带宽占优，但实际差距小于纸面 | 调度与批处理效率可能抵消带宽差距 |
| 软件调优重点 | 让负载适配架构，优化通信编排 | 让架构适配负载，优化并行策略与内存管理 |
| 迭代灵活性 | 受限于拓扑假设，非规则负载存在瓶颈 | 更适合频繁变更并行策略与模型结构的场景 |
| 运维成本结构 | 架构适配成本高，但稳定负载下运维干预较少 | 调优投入大，但生态工具链更成熟 |
对于参数规模固定、并行策略在较长时间内保持稳定、通信模式可提前规划的万卡级训练任务，TPU的3D Torus加OCS架构能够发挥编排优势。这类负载下，通信路径的确定性强，Torus拓扑的局部通信效率可以转化为实际的MFU收益。如果团队自身不频繁更改模型结构或并行切分方式，TPU方案在训练阶段的TCO具有竞争力。
对于需要高频尝试不同模型结构、并行策略和序列长度的研发团队，或采用MoE架构导致动态All-to-All通信频繁出现的场景，GPU的交换式全互联架构更具适应性。在这类负载下，通信模式的不可预测性会显著削弱TPU拓扑的编排收益，而Fat-tree的全互联能力避免了固定拓扑带来的绕路和拥塞风险。
当推理任务以离线批处理为主，对单请求延迟不敏感，且输入序列长度相对均匀时，训练阶段的TCO逻辑可以部分延续到推理场景。此时需要重点评估的是：在特定批大小和序列长度下，两种方案的实际MFU和存储带宽利用率。由于Decode阶段的实际性价比差距可能小于纸面带宽差异，建议基于真实负载进行基准测试后再做判断。
对于在线推理场景，尾延迟、首token延迟和系统稳定性往往比单位算力成本更关键。当Prefill阶段占据较大比例且输入序列较长时，GPU方案凭借低精度算力优势可能提供更低的单请求成本和更好的延迟表现。Decode阶段的实际表现则更多取决于调度策略和批处理优化，而非单纯由硬件带宽决定。
选型的核心原则是：先定义负载的流量形态和时间敏感度，再倒推架构匹配度，最后计算TCO。
具体而言，可以按以下步骤评估：
第一步，判断通信模式的可预测性。 如果模型结构、并行策略和训练框架在可预见的时间内保持稳定，且团队有能力针对特定拓扑进行编译优化，则TPU方案的Torus架构收益可以被有效释放。如果负载处于快速迭代期，或采用了动态路由、稀疏激活等特性，则GPU方案的交换式架构提供了更大的容错空间。
第二步，区分训练与推理的成本结构。 训练场景需要关注MFU假设的可靠性，不能仅依赖供应商提供的峰值数据，应基于自身负载进行小规模基准测试。推理场景需要分别测量Prefill和Decode的实际表现，避免用单一指标代替整体TCO。
第三步，评估软件调优能力的可获得性。 TPU方案对编译器优化和通信编排的依赖度更高，如果团队缺乏这方面的深度能力，实际性能可能显著低于理论值。GPU方案的调优门槛相对较低，且生态工具更丰富，但达到高水平MFU同样需要持续投入。
第四步，考虑长期演进与锁定风险。 架构选择一旦确定，后续的模型结构调整、精度策略变更和集群扩展都会受到既有拓扑的约束。需要评估未来两到三年内负载形态变化的可能性，避免针对当前负载过度优化而导致后续迁移成本过高。
如果团队正在考虑从一种方案迁移到另一种方案，需要注意以下问题：
模型精度适配。 不同方案对FP8、FP4等低精度格式的支持程度不同，迁移前需要验证模型在目标精度下的收敛性和推理质量，不能假设精度降低不会影响业务指标。
并行策略重配置。 TPU和GPU的互联拓扑差异意味着，原有的数据并行、模型并行、流水线并行的切分比例和通信调度策略可能无法直接复用。迁移后需要重新进行并行策略搜索和通信优化。
软件栈兼容性。 训练框架、推理引擎和部署脚本可能依赖特定硬件平台的特性接口。在迁移前需要对代码依赖进行梳理，评估改写工作量和回归测试成本。
监控与调优工具替换。 不同方案的性能监控指标、日志格式和调优工具链存在差异，运维团队需要重新建立性能基线和故障排查流程。
成本结构变化。 迁移不仅涉及硬件采购成本和软件改造投入，还包括团队学习成本、调优周期内的效率损失和可能的业务中断风险。TCO计算应覆盖迁移全周期，而非仅比较稳态运行成本。
TPU与GPU的对比，本质上是对两种技术哲学的权衡：前者用领域专用和确定性编排追求规则负载下的效率峰值，后者用通用性和全互联架构换取对多样化负载的适应能力。在训练场景中，TPU的TCO优势建立在对MFU差值的乐观假设之上；在推理场景中，GPU凭借低精度算力在Prefill阶段展现出明确的成本效率反转；而Decode阶段的实际差距则远小于理论带宽数字所暗示的水平。
因此，没有普遍适用的AI算力最优解。技术负责人在做架构选型时，需要将问题从“哪个芯片更好”转换为“当前以及未来十八个月的负载流量形态是什么”“对延迟敏感度有多高”“团队具备怎样的软件调优能力和迁移预算”。只有将这三个问题回答清楚，TCO的计算才具备实际指导意义。随着低精度训练与推理技术的持续演进，以及互联拓扑的进一步分化，这一对比框架仍需要持续更新，但“场景决定架构匹配度”的基本判断逻辑不会改变。