企业官网建设流程全解析

一百万个芯片塞进一个集群，听起来像是PPT上的数字游戏，但谷歌这次把TPU互联架构推到100万芯片规模，实际上是把AI基础设施的竞争从“单卡算力赛道”拉到了“系统级工程赛道”。我做大规模训练平台这些年，最大的感受是：越往上走，单颗芯片的性能越不重要，芯片和芯片之间怎么协作、整栋数据中心拿什么供电，才是真正决定你能跑多大模型的两块天花板。

这篇文章不是谷歌官方公告的复述，而是站在一个长期跟训练集群打交道的人的角度，聊聊这100万芯片互联背后的技术逻辑，以及为什么电力问题会成为比互联架构更棘手的存在。无论你是做算法、做平台，还是负责采购算力、规划机房，这篇都能给你一些平时文档里读不到的视角。

1. 一百万芯片互联，谷歌真正想解决的问题

1.1 从4096颗到100万颗：数字背后的演进节奏

很多朋友看到“100万芯片”第一反应是“哇，土豪”。但你得理解谷歌走过这条路用了多久。TPU v4时代，单个Pod是4096颗芯片；到TPU v5p，一个Pod的规模扩展到8960颗，这已经是一个相当庞大的计算域。现在突然说架构上能支持100万颗，中间差了不止两个数量级。

这个跨度不是简单堆机器就能实现的。4096颗芯片和100万颗芯片，难点完全不在数量本身，而是连接关系。你有一万人要开会，和小会议室里坐十个人，用的根本是两套方法论。小规模可以直接“所有人喊所有人”，大规模就必须设计分层、分区、有路径规划的信息传递机制。谷歌这次真正的突破不在“又造了多快的芯片”，而在“如何让100万颗芯片在逻辑上像一个整体一样工作”。

还有一个关键点：这是“架构支持”，不是“已经搭好了100万芯片集群”。对这个区分我特别敏感，行业里经常把架构设计能力和实际落地能力混为一谈。但反过来看，敢把架构支持百万级规模这件事拿出来说，说明谷歌至少在拓扑设计、通信协议、调度系统上已经过了仿真和验证阶段，不是纯嘴炮。

1.2 互联架构才是算力的“决定开关”

我在很多场合说过一个观点：评估一块AI芯片好不好用，先不要看它的峰值算力，而是先看它怎么跟别人通信。做深度学习训练的人都有体会，单机四卡跑小模型，卡与卡之间互相等消息的时间几乎可以忽略；但当你把模型撑到千亿参数，把集群扩到几百上千张卡时，你会发现卡越加，加速比越不理想。原因就是通信瓶颈。

谷歌的TPU互联一直走的是自研路线，不依赖通用的InfiniBand或RoCE网络，而是用自己的ICI（Interchip Interconnect）和光路交换（OCS）技术。这套体系最厉害的地方在于，它可以让芯片之间的通信不经过传统意义上的“网卡-交换机”路径，而是直接在芯片间建立高速通道。对大规模训练来说，这相当于给你的并行计算开了一条专用高速公路。

所以这次“支持100万芯片规模”的核心价值，不在芯片本身，而是在这条“高速公路”的规划能力：你怎么布线、怎么换道、怎么绕开拥堵，才能让100万个节点不互相踩踏。理解了这一点，你才能看懂后续章节里那些拓扑和带宽计算是怎么回事。

2. 拆解TPU互联：拓扑、光交换和那笔带宽账

2.1 从Pod到SuperPod的层级结构

理解TPU互联架构，绕不开“Pod”这个概念。你可以把Pod想象成一个“巨型机箱”，里面装着几千颗TPU芯片，通过高带宽的ICI总线以某种拓扑结构连接起来。TPU v4的一个Pod是4096颗芯片，v5p的单个Pod能做到8960颗。这些Pod内部通常采用三维环面（3D Torus）拓扑，也就是说每一颗芯片都能向X、Y、Z三个方向与相邻芯片通信，形成密集的网格。

为什么要用环面而不是星型？核心考虑是带宽和布线成本。星型拓扑中心节点压力太大，10000颗芯片接到一个中心上，这个中心本身就会变成瓶颈；而环面拓扑让通信尽量发生在相邻节点之间，消息走的路程短，所需的物理线路也少，扩展性更强。

Pod再往上走，就是SuperPod甚至更大的计算域。连接多个Pod之间的通信，靠的就不再是芯片间的高速总线，而是光交换设备。这里有一个很关键的概念是“可重配置拓扑”：传统的网络里，交换机之间的连接是固定的，A到B永远走同一条路；但谷歌的光路交换（OCS）系统允许你动态调整光路，让拓扑随着工作负载的变化而改变。

我举个好懂的例子：白天你在做稠密模型的训练，大量通信发生在同一排机柜内；晚上你要跑一个专家并行（Mixture of Experts）的模型，通信模式变成跨区域的All-to-All。固定拓扑的网络要么为最坏情况配备资源，要么就得忍受高峰期拥堵。而光路交换的做法类似“动态调车道”——哪个方向流量大，就把更多光路指向哪里。

2.2 光路交换：百万级集群里最关键的“换道”动作

谷歌在TPU架构里引入光路交换，本质上是把网络从“静态管线”改成了“动态调度”。从公开资料来看，TPU v4的Pod里就已经有光路交换设备参与互联，它的任务是在不同计算阶段重新配置光通路。这种方案的好处有两个：一是让网络利用率大幅提升，二是减少了电信号长距离传输的损耗。

到了100万芯片规模，光路交换几乎是必然选择。想象一下，如果100万颗芯片全部靠铜缆连接，光是线缆的重量和布线的难度就是灾难级的；铜缆传输距离短、容易受干扰，机柜间距离稍微拉长信号质量就断崖式下跌。光连接则能覆盖更长距离，同时单根光纤的带宽潜力远大于铜缆。

但对做系统的人来说，光纤带来的挑战也不少：光模块的故障率、光纤端面的清洁问题、连接器的损耗一致性……这些都是百万级集群运维时躲不开的细节。我有一次调试集群，发现某个机柜内训练速度异常慢，查了半天才发现是一根光纤端面脏了，插入损耗高了几个dB。这种问题在小规模集群可能只是性能抖动，到了十万百万卡规模，可能就是每天都要处理的日常。

2.3 一笔简单的带宽账：为什么需要光

聊到这里，不妨算一笔实在的账。以TPU v4为例，它的芯片间互联带宽大约在1.2Tbps左右，到了v5p，公开资料显示的芯片间带宽继续往上翻了几倍。单看这个数字你可能没概念，对比一下：目前主流数据中心的服务器网卡是25Gbps到100Gbps，InfiniBand NDR能到400Gbps，而TPU的芯片间互联已经是以“Tbps”为单位了。

为什么要给芯片配这么高的带宽？我拿大模型训练中的张量并行来举例。假设把一个7680维的Transformer层切到64张卡上，每一步前向和反向计算都需要做至少一轮All-reduce，把所有卡上的部分结果合并成完整的张量。这个操作的通信量跟模型宽度成正比，跟并行维度无关。也就是说，你的模型越大，每一次通信的数据量就越大；芯片越快，等待通信的时间占比就越离谱。

所以TPU的ICI带宽一上来就是Tbps级别，是为了保证在处理超大模型时，通信时间仍然能控制在计算时间的很小比例内。这也解释了为什么百万芯片互联必须依赖光技术：只有光通信能够在可接受的功耗和物理空间内，提供足够的总带宽——百万颗芯片如果每颗带宽1.2Tbps，理论总带宽是1200 exabits/s。这个数字用铜缆根本做不出来。

3. 大规模训练里，真正卡脖子的往往是通信

3.1 通信占比：算得过来但与你想的不同

我做训练平台这些年，见过太多团队先盯着芯片峰值算力做预估，结果集群一落地，实际吞吐只有理论值的五六成。问题基本都出在通信上。大模型训练有各种并行策略：数据并行、张量并行、流水线并行、专家并行，每一种都会引入不同模式的通信开销。到了百亿以上参数规模，通信时间占总训练时间的比例通常会到20%到40%，长序列场景下更高。

这里有个反直觉的点：很多人以为GPU卡加多了，每张卡分到的计算量线性减少，训练应该线性加速。但通信量并不会按卡数均分。拿数据并行来说，每N张卡同步梯度时，All-reduce的数据总量跟模型参数量有关，跟你用了多少张卡关系不大。这意味着卡越多，每张卡平摊的通信量反而可能变大，导致加速比上升曲线越来越平。我在实际操作中见过最典型的案例：batch从128扩到512，理论上加速4倍，实际上只能跑出3.1倍左右，越往大扩越不划算。

谷歌做百万芯片互联，本质上就是跟这个“规模诅咒”硬刚。它要把通信开销压到足够低，低到100万颗芯片仍然能跑出看起来“线性扩展”的效果。这对拓扑结构、通信调度、带宽分配的考验，比单纯堆算力大得多。

3.2 规模诅咒：100万芯片效率如何不被通信吃掉

如果你把100万颗芯片想象成一个小城市，通信就是这座城市的交通系统。芯片是居民，模型训练是他们的协作任务。居民越多，城市越大，大家要交流的东西不会变少，只会因为距离变远而变得更难。光有高带宽还不够，还得有好的“交通规划”。

谷歌的解法从公开架构来看有几层：第一层是芯片间的ICI高速互联，负责小范围内的密集通信；第二层是光路交换，负责大范围内的拓扑重配置；第三层是编排调度系统，负责决定每个任务跑在哪些芯片上，让通信尽量发生在物理位置相近的芯片之间。

这套逻辑放到我们自己搭建的集群上也一样适用。你不需要做到百万卡，只要有几十上百张卡，就应该认真考虑通信组网和任务放置策略。很多团队拿裸机GPU直接暴力组网，结果就是偶尔出现莫名其妙的性能下降。我之前排查过一个案例：两台计算节点连在同一台TOR交换机上，但跑分布式任务时性能特别差，最后定位发现是两者分属不同的网络命名空间，跨网关绕了一大圈。这种问题在日常集群里太常见了。

所以我的建议是：在小规模阶段就把通信架构规划好，不要等项目大了再重构。网络规划和芯片采购应该同步进行，而不是等卡到了再想怎么连。

4. 电力：比芯片互联更硬的“物理天花板”

4.1 先算一笔功耗账：100万芯片意味着什么

谷歌把芯片互联做到百万级规模，技术层面当然值得惊叹，但真正让基础设施团队睡不着觉的是电。我们算一笔最粗糙的账：目前一颗AI训练芯片的典型功耗在200W到700W之间，取个中间值400W，100万颗芯片单纯计算负载就是400MW。这个数字什么概念？一台普通的核电机组装机容量大约1000MW，也就是说，一百万颗芯片满载运行，相当于小半个核电站要专门给你供电。

而且这还只是芯片本身。芯片装在服务器里，服务器有主板、内存、网卡、散热风扇，功耗还要上一层；服务器再放进机柜，还需要交换设备、存储设备、冗余电源模块；整套系统运行还要制冷，把芯片发出的热量带走，制冷系统的功耗往往是IT负载的三分之一到一半。把这些全部加上，PUE按数据中心行业比较优秀的1.2算，整个数据中心的电力需求就到480MW甚至更高。

我为什么一直说电力是AI基建真正的瓶颈？因为芯片和互联技术可以用研发突破，但电力涉及电网基础设施、发电能力、变电站建设、当地能源结构，每一个环节的建设周期都是以“年”为单位的。谷歌这种体量的公司还能靠自建电厂、和能源公司长协供电子合同来对冲，普通企业连一个园区级算力中心的电力报装都能拖上大半年。

4.2 供电链路：从电网到芯片中间的“隐形损耗”

芯片设计者和算法工程师很少关心一个细节：你插上电源插头那一刻，电从电网到芯片这条路上，每一步都在损耗。高压电网传输损耗相对低，但进入数据中心后要经过变压器降压、UPS或HVDC整流、机柜内配电单元、服务器电源模块，最后到CPU/GPU的供电电路。一级一级转换下来，总效率能做到90%就算很不错的系统了，也就是说有10%左右的电在路途中变成热量浪费掉。

这还只是常规情况。有些老旧数据中心供电架构设计不合理，比如用大功率UPS带高负载，效率曲线掉得厉害，实际损耗会更高。我做基础设施评估时，会专门看整条供电链路的效率，因为这部分谁都看不见，但每个月电费单上的数字很诚实。

更棘手的是电力架空和功率密度。高密度AI机柜和传统机柜的功率密度完全不是一个量级。传统机柜可能一个柜子3～5kW就够，AI训练机柜动辄30～80kW。这意味着同样的建筑面积，电力需求翻了几倍，原有的母线、断路器、空调送风能力全部要推倒重来。很多机房建的时候根本没考虑过这种密度，等GPU进场才发现连电都带不动，只能闲置一部分设备，或者降频运行。这就是我反复强调的：电力预算必须在选机房之前锁定，而不是等设备到货再想办法。

4.3 散热和PUE：不止是“电费”问题

电力消耗的另一个大头是散热。400MW的IT负载，转换成热量就是400MW的热功率，这些热量必须带走，否则芯片分分钟过热降频甚至烧毁。传统的风冷方案在单机柜5kW时代绰绰有余，到了30kW以上高密度机柜，风冷基本失效，必须上液冷。

液冷的技术路线又分冷板式和浸没式。冷板式相对成熟，是在芯片上方加一个冷头，冷却液通过冷头把热量带走；浸没式更彻底，直接把服务器泡在绝缘冷却液里。我们做大规模训练的机房，冷板式液冷是目前的主流选择，因为对现有设施改动相对小，维护也更方便。

但液冷不是装上就完事。冷却液的流量、温度、水质、微生物控制都是日常运维的细节，随便哪一环出问题都能让一个机柜的算力归零。更要命的是，如果液冷系统设计冗余不够，冷却液循环泵一断电，几秒钟内芯片温度就会失控。这个风险在规划设计阶段就要考虑进去。我经历过一次冷却泵故障，虽然系统有备用泵自动切换，但切换瞬间的压力波动还是让部分节点触发了保护性降频，整批任务白白积压了半小时的进度。

在更宏观的层面，制冷带来的不仅是电费，还有水的消耗。很多大型数据中心用蒸发冷却塔，对水资源的需求巨大。电力、水、土地，这些都是AI基建的硬约束，只是在宣传PPT里很少有人提。

5. AI基建规划者容易踩的坑与几条经验

5.1 电力预算永远排在第一位

我见过太多算力规划翻车案例，几乎无一例外都是“先定GPU规模，再找机房”。等你把几千张卡的需求谈妥了，才发现没有哪个机房能提供足够的电力容量，最后要么分期进场，要么降低功率墙，要么换城市重新找资源。每一步都是时间和金钱的浪费。

正确的顺序应该是：先确定你未来12到18个月的训练负载预期，折算成IT功耗，再加上制冷和供电损耗，得到总电力需求；拿着这个数字去找有相应电力条件的机房，看它的市电引入、柴发冗余、PDU分布是否满足需求；最后才谈服务器上架方案。做AI基建的人必须习惯“算力问题最后都会被电力问题绑架”这个现实。

根据我个人的经验，电力容量的规划至少要预留20%-30%的余量，别卡着峰值算。AI业务增长的特点是突然的、非线性的，上一个模型——项目还在验证阶段，下一个月可能就要上生产集群了。这时候有余量就能快速扩容，没余量只能从头排队等供电增容。

5.2 网络设计与功耗规划要一起做

我在调研时看到很多热搜词提到“网关放在汇聚”、“汇聚跟核心是同VLAN互联还是三层IP互联”这类问题。这恰恰说明，真正做网络规划的人已经在纠结具体的组网细节了。我的态度是：组网方案必须和功耗规划、冷却方案一起纳入总体设计，不能单独拎出来事后补。

关于汇聚和核心之间用二层还是三层，我的建议是大规模AI集群尽量用三层路由组网，把二层广播域拆小，这样故障恢复更快，扩展性也更稳。倒不是说二层不行，而是在几百个机柜、几千台服务器互联时，二层网络的广播风暴和MAC表压力会急剧上升，出了问题牵连面太广。几百张卡的小集群用二层简单省事，再往上走就要考虑三层。

但你得注意，方案怎么定不是纯技术问题，还取决于运维团队的能力。三层组网对运维人员要求更高，配置错误带来的排障难度也更大。如果团队对BGP、OSPF这些不熟，硬上三层反而会害了自己。我见过一个团队强行上三层，结果路由配置错误导致跨网段完全不通，最后回退到二层才恢复正常。技术选型要考虑团队实际情况，这是过来人才会说的大实话。

5.3 算力利用率才是真正该盯的指标

最后聊一个很多团队不好意思谈的话题：花大价钱买回来的AI集群，真正的利用率是多少。我做基础设施评估时会看一个指标叫MFU（Model FLOPs Utilization，模型算力利用率），就是实际训练速度和理论峰值速度的比例。很多号称“大规模”的集群，MFU做到40%-50%就算不错了，能稳定在60%以上都属于神仙操作。

问题出在哪？除了通信瓶颈之外，还有任务调度、数据加载、代码效率等一系列因素。很多团队买了顶级芯片，却用着低效的数据读取链路，GPU大部分时间在等数据从磁盘或网络传过来。上次帮一个项目调优，发现它的训练性能卡在数据加载上，数据管道的吞吐只有GPU消费能力的十分之一，GPU空转率接近50%。这种问题不用换卡，把数据流水线修好，吞吐直接翻倍。

所以我建议团队真正应该盯的指标不是“买了多少张卡”，而是“我的卡每天真正在算的时间有多久”。在这个基础上再决定是否扩容、是否优化网络、是否需要上更大规模集群。谷歌百万芯片互联看着很远，但它的思维方法跟小集群优化一模一样：先把系统级瓶颈找出来，再用工程手段解决它。

我自己的体会是，做AI基础设施的人，不能只抬头看工艺制程和模型架构，还要低头算清楚电表、光纤和散热器。算力这行当，最终拼的不是谁手里芯片多，而是谁能让每一度电、每一根光纤都物尽其用。如果你正在规划自己的集群，不妨先把电力和网络这两本账认认真真算清楚，这会让你后面少走很多弯路。