乾坤线指标：捕捉涨停潜力的技术分析与实战应用
2026/9/11 19:42:36
摘要：本文深入解析Google自研TPU（张量处理器）的完整历程，从2011年Google Brain项目启动、2013年算力经济账的算起，到TPU v1到Ironwood、TPU 8t/8i的代际演进。文章揭示TPU并非为了挑战GPU，而是围绕AI Workload进行专用计算与系统级优化的战略选择，并探讨其对今天大模型时代AI芯片、算力基础设施和TCO的深刻启示。
今天谈AI算力，GPU几乎是绕不开的话题。但一个有意思的问题是：既然GPU已经能够很好地运行AI，Google为什么十几年前还要投入大量资源，自己研发TPU（Tensor Processing Unit，张量处理器）？这背后其实是一笔关于AI算力成本、数据中心功耗与规模化效率的长期账。
要理解TPU的起源，得先回到Google与机器学习、深度学习的发展历史。本文将从Google的算力困境出发，梳理TPU从一颗专用芯片走向完整AI计算系统的演进路径，并分析其对今天AI芯片产业和大模型算力基础设施的启示。
一、Google为什么做TPU？先从一笔“算力账”说起
2000年代，机器学习已经逐渐成为Google核心业务背后的重要技术。
从搜索排序、在线广告，到图像识别、语音识别和翻译，随着Google业务规模不断扩大，机器学习开始进入越来越多的产品。
真正改变Google算力需求的，是随后兴起的深度学习（Deep Learning）。
2011年前后，Google Brain项目启动。
Andrew Ng、Jeff Dean等人在Google内部推动大规模深度学习研究。他们想验证一个当时还相当激进的问题：如果把神经网络、数据规模和计算规模同时放大，会发生什么？
很快，他们发现，效果确实会变好。2012年，Google Brain团队利用约1.6万个CPU核心训练了一个大规模神经网络，并通过大量YouTube视频数据进行无监督学习。后来广为人知的“猫脸识别”实验，让外界直观地看到：当数据、模型和计算规模同时扩大，神经网络可以学习出过去很难通过人工规则定义的特征。
但更重要的变化发生在实验室之外。深度学习开始进入Google的真实业务。语音识别就是其中最典型的场景之一。
模型效果越来越好，但另一个问题也越来越突出：AI效果上去了，算力账单也跟着上去了。
2013年前后，Google内部算了那笔后来被反复提及的“经济账”。
如果数亿用户每天只使用3分钟语音搜索，而背后的语音识别全面采用深度神经网络，仅新增的计算需求，就可能让Google需要大幅扩张数据中心基础设施。
这件事改变了Google看待AI的方式。
此前，深度学习更多还是一个模型问题：怎么让模型效果更好？但当AI真正进入Search、Voice、Translate等亿级用户产品之后，它同时变成了一个基础设施问题：
这么大的AI Workload，到底应该用什么计算架构来承载？
如果只是偶尔跑几个模型，直接使用CPU或GPU当然最方便。但Google面对的已经不是“偶尔运行AI”，而是数以亿计的用户持续触发大量结构相似的神经网络计算。
深度神经网络中存在大量重复的矩阵乘法和张量计算（Tensor Computation）。于是Google开始思考：既然未来大量AI Workload都在反复执行这些计算，为什么不直接为它们设计一颗专用芯片？
TPU（Tensor Processing Unit，张量处理器）的故事由此开始。
Google研发TPU最初并不是为了“挑战GPU”。它面对的是一个更现实的问题：
如何在有限的数据中心空间、功耗和成本预算里，支撑快速增长的AI计算需求？
所以从一开始，TPU算的就是一笔基础设施经济账。
不是因为CPU和GPU不能跑AI，而是当AI Workload大到Google这个规模以后，“能不能跑”已经不是最重要的问题，“能不能高效、经济地规模化运行”才是。
二、TPU要解决的：如何让AI算得更有效率？
如果一颗芯片从一开始就不是为了“什么都能算”，而是为了高效运行神经网络，它还能不能重新设计？TPU的答案是：可以。
这也是理解TPU和专用AI芯片的一条重要逻辑：不是追求所有任务都能做，而是在目标Workload足够明确的情况下，把最重要的任务做得更高效。
因此，理解TPU不能只看“峰值算力有多高”。更应该看的是：面对真实AI模型，有多少理论算力最终能够转化成有效算力？
而这件事很快就不再只与芯片有关。数据怎么流动、内存怎么访问、芯片之间怎么通信、软件如何把模型映射到硬件……都会影响最终效率。
这也推动TPU从一颗专用AI芯片，逐渐走向一套完整的AI计算系统。
三、从TPU v1到今天：从Chip走向System
Google在2013年前后正式启动TPU项目。
2015年，第一代TPU（TPU v1）已经开始在Google内部投入使用，主要承担搜索、语音、翻译等业务中的神经网络推理。
v1首先验证了一件事：当AI Workload足够大、计算模式相对稳定时，围绕特定计算设计专用芯片，这条路是可以跑通的。
但Google很快遇到了下一个问题：
推理可以高效运行了，越来越复杂的模型怎么训练？
2017年，第二代TPU（TPU v2）面世。v2不仅把TPU从推理扩展到了训练，还有一个更值得关注的变化：Google开始从集群的角度设计TPU。与TPU v2同时出现的，还有TPU Pod。
Google通过定制高速互联，将64个第二代TPU设备连接起来，组成一套可以共同训练大型机器学习模型的系统，整体算力达到11.5 PFLOPS。当时Google直接把它称为一台“机器学习超级计算机”。
从这里开始，Google面对的问题逐渐从：“一颗芯片怎么把AI算得更快？”。变成：“怎么让很多颗芯片像一台机器一样，高效完成一个更大的AI任务？”
此后的TPU基本延续了这条路线。我们正好也来看下谷歌TPU的代际变化。
Google TPU代际 | 核心矛盾 | 解决方案 | 标志进展 |
TPU v1（2015） | 深度学习推理规模迅速增长，数据中心算力/功耗成本压力上升 | 面向神经网络矩阵乘法设计专用ASIC，聚焦推理效率 | 支撑搜索、翻译等亿级业务 |
TPU v2 (2017) | 模型没法训练，单颗芯片能力不足 | 引入训练能力 + Pod互联 | 64颗TPU设备组成约11.5 PFLOPS的机器学习超级计算机；TPU从Chip走向System |
TPU v3 (2018) | 模型持续变大，训练计算密度和散热压力进一步提高 | 提升计算性能，并强化Pod级扩展与液冷能力 | TPU Pod成为更成熟的大规模训练基础设施；Cloud TPU开始更广泛开放给外部开发者 |
TPU v4（2021） | 大模型进入数十亿/万亿参数时代，系统扩展效率和芯间通信成为关键瓶颈 | 4096颗芯片组成Pod，引入自研光路交换（OCS）等高速互联技术 | 单个TPU v4系统进入ExaFLOPS级ML计算，系统扩展性能相比v3出现大幅跃升；互联正式成为TPU核心竞争力之一 |
TPU v5e（2023） | 生成式AI不仅要训练，更要低成本规模化推理；客户开始更关注TCO | 针对训练+推理做更高性价比设计，支持灵活Pod/VM形态 | 相较v4，LLM训练和推理的**Performance/$**明显提升；TPU开始从“性能优先”走向“性能+经济性” |
TPU v5p（2023） | 百亿/千亿参数模型训练规模进一步放大，单个Pod需要承载更大的模型和更高带宽 | 8,960颗芯片+更高带宽ICI+3D Torus互联，并强化HBM | 单Pod达到8,960颗芯片，成为当时Google最强、最可扩展TPU；AI Hypercomputer体系同步推出 |
Trillium （2024） | 基础模型训练与推理同时增长，能效、HBM和互联继续成为约束 | 大幅提高单芯片性能，翻倍HBM容量/带宽和ICI带宽，并强化SparseCore | 单芯片峰值性能较v5e提升4.7倍，能效提高67%；可通过Multislice扩展到数万颗芯片，进一步走向building-scale supercomputer |
Ironwood （2025） | AI从训练进一步走向大规模推理、Reasoning和RL；推理基础设施成为新瓶颈 | 面向训练、推理和Reasoning做系统级优化，强化液冷、HBM和超大规模Pod | 单Pod9,216颗芯片、42.5 ExaFLOPS；Google开始更明确把TPU定位为大规模AI推理/Reasoning基础设施 |
TPU 8t / 8i | 同一种TPU难以同时把超大规模预训练和低时延推理都做到最优；Agent时代Workload进一步分化 | 首次采用两种不同架构：8t专攻训练，8i专攻推理/后训练/RL | 8t单Superpod可扩展到9,600颗TPU、约2PB共享HBM；8i单Pod 1,152颗，强调低延迟和Performance。 |
所以从v1到今天，TPU的演进并不只是Chip越来越快。更像是先围绕AI Workload造了一颗专用芯片，然后又围绕它，逐渐造出了一台越来越大的“AI计算机”。
演进路线：Chip → Memory → Interconnect → Network → Software → Cluster
AI算力的竞争单位，也由单颗Chip逐渐走向整个System。
四、Google的TPU故事，对今天意味着什么？
如果只把TPU理解成Google的一款自研AI芯片，其实会错过这个故事更值得关注的部分。
过去十多年，TPU的演进实际上对应着AI计算问题的一次次变化：
最开始，要解决的是有没有足够的算力；
后来，要解决一颗芯片能不能算得更高效；
模型继续扩大，又变成成百上千颗芯片能不能高效协同；
到了今天，问题进一步变成：整个计算系统能不能以更低的成本，持续提供更多有效算力？
所以今天讨论AI芯片，只比较单颗芯片的峰值FLOPS已经越来越不够。芯片效率、HBM、互联、集群扩展、软件栈、能耗乃至TCO，最终都会影响真实AI Workload的运行效率。
而大模型，又把这个问题进一步放大了。
模型越来越大、Token数量越来越多、集群规模越来越大，训练和推理正在成为一笔越来越昂贵的基础设施账单。
于是整个行业又开始面对Google十多年前曾经面对过的那个问题：
当一种AI Workload足够庞大，我们究竟应该一直让Workload适应已有的计算架构，还是让计算架构开始围绕Workload重新设计？
这也是TPU故事今天依然值得研究的原因。
它并不是一个突然出现、为了“替代GPU”而存在的概念。
它背后代表的是另一种计算思路：
当Workload规模足够大，围绕Workload进行专用计算和系统级优化的价值就会越来越高。
十多年前，Google因为搜索、语音、翻译等业务开始计算这笔账。
今天，大模型让更多公司重新开始计算这笔账。
Google，只是更早开始的人。