网络定义算力时代：Google TPU v8双芯片架构评测
时至今日，AI算力已悄然跨越了摩尔定律的传统边界。一个关键转变正在发生：计算本身不再是大模型发展的唯一瓶颈，真正卡脖子的，变成了网络。
那个曾经被视为数据中心“管道”的基础设施，如今已经跃升为决定AI超算性能的核心变量。在2026年的Google Cloud Next大会上，第八代TPU的发布，带来的不仅仅是芯片层面的换代，更配套推出了一套名为Virgo的兆级数据中心网络。从芯片之上的互联，到整个数据中心的拓扑结构，这次是一次全栈式的重构。这件事的意义在于：AI基础设施正式迈入了“网络定义算力”的新阶段。
一、双芯片架构：为不同工作负载量身定制
Google打破了TPU系列长期以来“一芯多用”的设计传统。这一次，他们首次同时推出了两款芯片：为训练优化的TPU 8T，和为推理优化的TPU 8I。两者在内存架构上，做出了截然不同的取舍。
TPU 8I推理芯片的设计相当有碘伏性。它搭载了384MB的SRAM，这个容量是TPU 8T的三倍。这个决策直指大语言模型推理的核心矛盾：低延迟解码。通过将权重和KV缓存尽可能放在最快的SRAM中，Google大幅减少了对高延迟HBM的访问次数，以此换来更高的token吞吐量。同时，它还配备了288GB的HBM，满足长上下文推理对大容量内存的需求。
相比之下，TPU 8T训练芯片只有216GB HBM。这个看起来有点“反常识”的设计，背后其实是对两种工作负载差异的深刻理解：训练任务可以通过横向堆叠更多芯片来获得集群总内存的提升；但推理任务要的是最大化单芯片的内存层级效率，避免因跨芯片通信引入不可接受的延迟。
值得一提的是，两款芯片都采用了Google自研的Arm架构Axion CPU作为头节点。这个选择，彻底解决了传统x86 CPU在数据预处理和任务编排上可能出现的瓶颈。Axion CPU提供了充足的计算余量，能高效处理复杂的数据预处理工作，确保TPU始终处于满负荷运行状态，本质上是在解决“算力饥饿”的问题。
二、从Jupiter到Virgo：数据中心网络的代际跃迁
在TPU v8之前，Google数据中心的核心网络是2015年推出的Jupiter网络。它基于传统的Clos（叶-脊）架构，通过多层交换机实现互联。这种架构在互联网时代表现出色，能很好地处理异步、分布式的网络流量；但面对AI训练那种同步通信模式，就显得力不从心了。
Clos架构的致命问题在于网络跳数太多。在典型的三层Clos架构里，一个TPU要和另一个机架的TPU通信，得经过叶交换机、脊交换机、超级脊交换机，再逐层返回。这个过程需要多次光电转换和数据包处理，不仅延迟高，还会产生严重的“尾延迟”——整个训练任务的速度由最慢的那个节点决定，任何一个通信链路的延迟都会拖垮整个集群。此外，传统电交换机的端口数量有限（低radix），必须通过堆叠多层交换机来扩展规模，进一步加剧了网络的复杂度。
为了解决这些问题，Google推出了专为AI设计的Virgo兆级网络。这可以说是十年一遇的数据中心网络架构变革。Virgo网络最核心的创新，在于全面采用光交换（OCS）技术。
OCS的原理听起来很简单，但效果极其高效：它通过调整微镜的角度，直接把光信号从一个端口反射到另一个端口，全程不需要光电转换和数据包处理。这就好比用镜子反射阳光。目前主流的OCS交换机已经能做到300×300的端口规模，未来也许还能扩展到2000×1000。这种超高radix特性，使得Virgo网络能够将传统的三层Clos架构直接压缩为两层。
架构简化带来的性能提升是惊人的：Virgo网络的总聚合带宽达到了47Pbps，是上一代Jupiter网络（13.1Pbps）的近四倍。更重要的是，它能将13.4万个TPU连接成一个单一的逻辑计算单元，真正实现了“园区即计算机”的愿景。同时，Google在Virgo网络里内置了海量的遥测功能，可以实时监控每一条链路的状态，快速定位和隔离故障，确保集群的有效吞吐量（Goodput）维持在极高水准。
也不是说Virgo就完全取代了Jupiter。Google采用了分层设计的思路：把计算与存储互联、互联网接入等前端流量继续交给Jupiter网络处理；而将TPU之间的后端通信——这个最关键的部分——交给Virgo网络，实现资源的最优配置。
三、双拓扑并行：为训练和推理量身定制的Scale-Up网络
如果说Virgo网络解决了跨机架的Scale-Out通信问题，那么TPU v8在Scale-Up（芯片间互联）层面的创新，同样具有革命意义。Google首次为训练和推理采用了完全不同的网络拓扑：用于TPU 8T的3D Torus拓扑，和用于TPU 8I的Board Fly拓扑。
3D Torus：适合训练的密集邻居通信
3D Torus是TPU系列沿用多年的经典拓扑。它的结构可以形象地类比为一个魔方：每个小方块代表一个TPU，相邻的TPU通过铜缆直接连接，而魔方同一行或列的两端则通过光纤连接形成环形。这种拓扑很适合AI训练的通信模式，因为训练过程中每个TPU主要和相邻的TPU进行频繁的数据交换，3D Torus能以最低的延迟满足这种密集的邻居通信需求。
不过，3D Torus有一个固有的缺陷：最大通信跳数会随着拓扑规模的扩大而线性增加。比如在Google常用的8×8×16 3D Torus拓扑里，从一个边缘TPU到位于拓扑中心的TPU，需要经过16跳，这会带来明显的延迟。对于训练任务来说，因为所有TPU都处于活跃状态，且通信模式相对固定，这种延迟是可以接受的。但对于推理任务，尤其是混合专家（MoE）模型的推理，情况就完全不同了。
Board Fly：为MoE推理优化的低延迟拓扑
混合专家模型的推理，通信模式完全不一样：对于每个输入token，只有少数几个专家（TPU）会被激活，而且激活的专家是随机分布的。这意味着通信不再是相邻TPU之间的固定模式，而是任意两个TPU之间的随机通信。在这种情况下，3D Torus的高最大跳数，就会导致严重的延迟问题。
为了解决这个问题，Google为TPU 8I设计了全新的Board Fly拓扑。它的核心思路是通过分层设计和OCS技术，把最大通信跳数大幅降下来。Board Fly拓扑采用三级层次结构：
- 板级：每块PCB板上集成4个TPU，通过PCB电走线实现全连接，延迟最低。
- 组级：将8块这样的板放入一个机架，通过有源电缆（AEC）采用Dragonfly拓扑互联，形成一个“组”。
- Pod级：将36个组通过OCS交换全连接，形成一个完整的Pod，总共包含36×8×4=1152个TPU芯片。
Dragonfly拓扑是超级计算领域早已验证的高效互联技术。它的特点是在局部采用全连接，全局通过高radix交换机实现一跳可达。通过先将TPU集成到板上，再以板为单位进行Dragonfly互联，Board Fly拓扑将TPU 8I Pod内的最大通信跳数，从3D Torus的16跳降低到了7跳，延迟减少了50%以上。这完美适配了MoE推理的随机通信模式。
四、关键技术支撑：TPU Direct与CAE
为了进一步消除通信瓶颈，Google还引入了两项关键技术：TPU Direct和Collectives Acceleration Engine（CAE）。
TPU Direct本质上是针对TPU优化的远程直接内存访问（RDMA）技术。在传统架构中，一个TPU要访问另一个TPU的内存，必须经过双方的主机CPU进行多次握手和数据拷贝。这不仅增加了延迟，还占用了宝贵的CPU资源。TPU Direct允许TPU通过网络接口直接访问其他TPU的HBM内存，完全绕过主机CPU，大幅提升了内存访问的速度和效率。
CAE则是集成在每个TPU芯片上的专用翻跟斗，专门负责处理All-Reduce、All-Gather、All-to-All这些通信密集型的集合操作。这些操作在AI训练和推理中占据了大量时间，传统上由TPU的计算核心来处理，会占用大量算力资源。CAE把这些操作卸载到专用硬件上，让TPU的张量核心能专注于矩阵乘法等核心计算任务，进一步提升了整个系统的效率。
五、结语：工作负载驱动的全栈协同设计
Google TPU v8的发布，标志着AI基础设施发展中的一个重要转折点：从过去追求单一芯片的峰值算力，转向追求从芯片到数据中心的全栈协同优化。通过将训练和推理拆分，为不同的工作负载量身定制芯片架构、内存层级、互联拓扑，乃至整个数据中心网络，实现了极致的性能和效率。
这次变革带来的核心启示是：在AI时代，没有“一刀切”的基础设施解决方案。未来，随着世界模型、智能体等新型工作负载的出现，我们很可能会看到更多针对性的架构创新。而光电路交换、RDMA、专用通信翻跟斗等技术，将毫无悬念地成为下一代AI超算的标配，推动人工智能向着更大规模、更高效率的方向不断前进。