# Google TPU v8 网络架构大师课中文翻译
> 原视频：Masterclass on Google's TPU v8 Networking
> 文字稿来源：YouTube 自动字幕清洗
> 发布日期：2026-04-24
> 对话双方：Austin Lyons（Chip Strategy / Semi Doped 主持人）× Vikram "Vik" Sekar（Vik's Newsletter / Semi Doped 联合主持人）
> 时长：约 47 分钟
简介
Vik: 现在的限制因素不再是计算，而是支撑当今所有计算的底层网络。这才是需要解决的瓶颈，也是 Google 的创新目前所解决的问题。
Austin: 大家好，欢迎收听新一期的 Semi Doped 播客。我是 Chip Strategy 的 Austin Lyons，和我在一起的是来自 Vic's Newsletter 的 Vikram Sekar。今天，我们将探讨关于 Google、TPU(张量处理单元)、网络和芯片的所有内容。
Austin: 还有，Vik 会尝试共享他的屏幕。所以，如果你正在听这期播客，你可能会想去 YouTube 上观看。
Vik: 是的。这是我们第一次尝试分享视频，因为最近 Google 宣布的全新 TPU 架构以及他们在训练和推理上的不同处理方式，不仅在芯片端（我们稍后会讲），而且在网络端都有很多进展。谈论芯片很容易，比如“你看，这块芯片有这么大的 RAM，有这么高的浮点运算能力。” 但如果不看图，就很难讲清楚网络。
Austin: 嗯。
Vik: 所以我在 Google 幻灯片上贴了一些图片，我会分享出来。这比较粗糙，它不是那种经过严格剪辑或非常专业的视频......或许有一天我们会做到那样吧。不管怎样，我觉得展示一些图片还是很有用的，所以如果可以的话，一定要去 YouTube 上观看。
为两种工作负载设计的两款 TPU
Austin: 是的，我很兴奋。我觉得里面有很多东西可以学。我来为听众们铺垫一下背景。Google 在昨天的 Google Cloud Next 2026 大会上发表了主题演讲，并宣布了下一代 TPU。当然，多数听众可能已经听说的最令人兴奋的事情是，这次发布的不是一款 TPU，而是两款。在 TPU v8 中，有用于训练的 8T 芯片，以及用于推理的 8I 芯片。这很有意思，因为从历史上看，很长一段时间以来 TPU 只有一款芯片。V1 是纯推理芯片，然后 V2 是训练兼服务（serving），V3、V4 也是训练兼服务。后来他们分出了能效版和性能版。V6 又回到了一款芯片。V7 也是一款芯片，但被大力宣传为推理芯片。但现在我们有了专门的训练芯片（或者说训练系统，稍后会讲到），以及专门的推理芯片。
HBM、SRAM 与 Axion CPU
Vik: 也许我应该立刻指出那个显而易见的事实。TPU 8I 有 384 MB 的 SRAM(静态随机存取内存)，几乎是用于训练的 8T 的三倍。这让人觉得：“什么？但这确实很有道理。为什么不放 SRAM 呢？” Nvidia(英伟达) 现在整合到其平台中的 Groq LPU 基本上全是 SRAM，既然如此，为什么不现在就在 TPU 8I 中这么做呢？把尽可能多的 SRAM 放进去，这样你就可以直接从 SRAM 获得低延迟的推理。获得高吞吐量，生成 token 也会更快。所以，放入更多的 SRAM 显然是个非常合理的做法。这是一个很好的决定，在我们看到了追求快速解码的趋势之后，这已经是显而易见的了。
Austin: 对，对。这与我和 Matrox 的 Rainer Pope 交谈时提到的相吻合。他谈到了他们如何将权重放在 SRAM 中，将 KV 缓存放在 HBM(高带宽内存) 中，这些架构决策是为了同时获得极快的解码速度和所需的完整上下文。所以我们看到 Google 朝着这个方向发展，在推理芯片上使用了三倍的 SRAM，同时也配备了 288 GB 的 HBM。
我还要指出一个我觉得很有意思的地方，那就是训练芯片的 HBM 更少，只有 216 GB。顺便说一句，听众和观众朋友们，Google 有关于这些芯片的非常棒的技术博客，里面讲了很多。所以他们有谈到为什么要做出这些权衡。但我认为这很有趣，因为我的脑海里立刻闪现出一个想法：“对于训练来说，如果需要较少的 HBM，某种程度上你可以这样理解——为什么要为你不需要的 HBM 支付额外的费用呢？” 例如，如果有人只卖一种像 GPU 那样的芯片，说：“嘿，这一款搞定一切，既能训练，也能推理。” 你就可以反驳说：“你看 Google 是怎么做的，也许我是在为训练芯片上昂贵但实际上可能根本用不到的 HBM 多花冤枉钱？”
Vik: 是的，我当时也在想为什么训练芯片的 HBM 更低。我认为推理部分现在显然非常消耗内存，以至于你想要放入尽可能多、速度尽可能快的内存层，因为在更高的内存吞吐量下，解码和推理的速度会快得多，因此推理芯片基本上已经达到了极致。在当前的环境和场景下，它已经使用了你能放进去的最好的内存。这就是你所能做到的极限。那为什么训练芯片中的 HBM 会更低呢？我想如果内存不够，你总是可以把更多的芯片组合在一起。你只需添加更多的 GPU，集群的总 GPU 内存就会变大。所以我猜这就是解决方案。但在推理中，只有将每一层都拉满才有意义。你记得 Nvidia 的那种内存分层吗？最上面是 SRAM......他们实际上没有提到 SRAM，它本来应该在的，但它应该像第 0 层（tier 0），而 HBM 是第 1 层，DRAM 是第 2 层。这实际上是一种将最快内存最大化的努力。
Austin: 有道理，是的。好的。还有什么是比较有趣的？这两款芯片都使用了 Axion(Google 自研 Arm CPU)，也就是 Google 基于 Arm 定制的 CPU 作为头节点 CPU。我想这里有一段引用，我来读一下。
发布博客中写道：“TPU 引入了两个截然不同的系统，TPU 8T 和 8I。这些新系统是 Google Cloud AI 超级计算机的关键组件。” 这又是一个有趣的营销名称。当然，这也暗示了如今这已经是整整一个数据中心的概念了，你不能只在芯片层面去思考。“一种整合的超级计算架构，它结合了硬件、软件和网络，以驱动完整的 AI 生命周期。虽然两个系统都共享 Google AI 堆栈的核心 DNA 并支持完整的 AI 生命周期，但每一个都是为了解决不同的瓶颈而构建的，并优化了关键开发阶段的效率。此外，通过在我们第八代 TPU 系统中整合基于 Arm 的 Axion CPU 头节点，我们消除了由数据准备延迟引起的主机瓶颈。Axion 提供了计算余量来处理复杂的数据预处理和编排，从而使 TPU 保持充足的数据供给，不会停滞。” 所以，他们真的将这些 CPU 定位为“喂养” TPU 的设备。
Vik: 是的，这才是最重要的。绝不能让 GPU 闲置。
Austin: 是的，没错。
Vik: 这也指出，Arm 是任何 x86 CPU 的非常有竞争力的替代品。就架构中的指令集架构（ISA）而言，绝对不能被排除在外。所以我认为它们现在是平分秋色了。正如我们在之前的节目中提到的，最好的 CPU 就是你能弄到手的那个。谁能交付最多的芯片，他们就会让它发挥作用，无论是 Arm 还是 x86。这就是现在的游戏规则。
为什么网络是新的瓶颈
Austin: 好的。现在，我们来谈谈网络。我们应该从哪里开始呢？我注意到他们有一张很好的小表格，上面显示 8T 使用了 3D torus(3D 环面拓扑) 网络拓扑，但 8I 使用了 Boardfly 拓扑。这很有趣，因为现在我们不仅开始为不同的工作负载制造不同的 SKU，而且我们开始为不同的工作负载使用不同的网络拓扑。这非常有趣。所以，请带我们了解一下。
Vik: 是的。就我们刚才谈到的芯片本身而言，它们很酷。它们是好芯片。有 HBM，有 SRAM。从某种意义上说，这些都是常规配置。我认为这里真正的创新，也是 Google 数据中心网络未来实施方式的巨大结构性转变——这是一个十年一遇的重大改变。我会解释那是什么，但为此我需要先解释以前是什么样的。
扩展 AI 的基本假设和需求是要认识到：限制因素不再是计算，而是支撑当今所有计算的底层网络。这才是需要解决的瓶颈，也是 Google 的创新现在所解决的问题。Google 在某种意义上重新构想了数据中心。在接下来的讨论中，我们会详细分析为什么会这样，因为他们有分别用于训练和推理的不同芯片，也有分别用于训练和推理的不同网络架构，我们会谈谈其中的原因。
最有趣的是，许多这类网络正在向光学方向发展。你会听到我经常谈论 OCS(光路交换)，它代表光路交换（Optical Circuit Switching）。我想在最开始就解释一下这是什么，这样当我谈论网络时频繁提到这个词，大家就能明白它到底是什么。
光路交换是一种将光从交换机的一个端口重定向到另一个端口的方法，这样你就可以连接这边的 GPU 或者那边的 GPU，在这里则是 TPU。而且你完全在光学领域中完成它。这个想法非常简单。就像举起一面镜子，反射从窗户进来的阳光。你可以将它指向墙上或某处的不同位置。这完全就是 OCS 背后的核心概念。为什么要将光学转换为电子学，并像所有的 Tomahawk 交换机那样进行硅数据包交换呢？保持光的形式就好了。你已经处于光学领域了。保持光的形式。这就是光路交换。
你可以简单地通过改变光照射到不同端口的方式，将一个端口连接到另一个端口。这就是 OCS。因此，这正在成为当今 Google 建立其网络的底层基板。我将解释网络的各个部分是做什么的。
Virgo：在光学上重建横向扩展
Vik: 我们要谈论的第一件事就是 Google 所谓的 Virgo 网络解决方案。他们之前的网络叫 Jupiter，是 2015 年的产物。在当时，这是业界第一个达到拍比特（petabit）级别的网络。在那之前从来没有人见过这种规模的网络，非常出色。因为它主要是为互联网时代建立的，那是当时驱动一切的力量。数据中心依赖于 Clos network(Clos 网络)，基本上就是有一些机架，然后可以有不同层级的网络交换机。这时候我得试着用一张图片了，因为我正好有一张 Clos 网络的图片。希望它能展示出来。
Austin: 在他调出图片的时候，为听众们拼写一下，Clos 拼作 c-l-o-s。你们听的时候可能不知道。如果你想自己在 Google 上搜的话。
Vik: 是的，所以 c-l-o-s Clos 网络。它看起来大概是这样的。基本上，有这些机架，然后第一层称为叶交换机（leaf switch），机架与它们连接。接着下一层被称为脊交换机（spine switch）。在这个之上还有另一层叫做超级脊交换机（super spine switch）。那么，最终的结果就是，如果你必须从一个机架进入另一个机架，或者从一个 GPU 进入另一个 GPU，在不同的 Pod 之间通信。如果你在 YouTube 上看这张图，你会看到有两个 Pod。基本上，你必须经过大量的网络跳跃（hops）。想一想，你必须从机架中的 GPU 连接到叶交换机。从叶交换机上升一层到脊交换机。从脊交换机再到超级脊交换机。然后你被切换到正确的超级脊交换机，接着你还得顺着层级结构一路返回下来。
这跳数太多了。当你需要从数据中心一端的 GPU 连接到另一端的 GPU 时，跳数太多了。这就是整个问题的核心，这就是为什么它在 AI 时代行不通的原因。
Austin: 这种设计在云服务器和 Web 应用时代绝对是合理的，也很有意义。你要在这个地方访问一个数据库，在那个地方调用一个 API，但你不需要每一个叶节点都和所有其他的叶节点通信，也不需要为了做到这一点而大费周章地向上跳然后再向下跳。
Vik: 是的，这有时候会发生，而且延迟在某种程度上是不确定的。延迟该是多少就是多少，但问题是训练网络不喜欢这样。AI 不喜欢随机的延迟之类的东西。我认为还有另一个非常重要的原因。这个 Clos 网络有如此多的跳数，你需要如此多的网络交换机层级，是因为每个交换机没有足够的端口。在网络术语中，这被称为 high-radix switch(高基数交换机) 中的交换机基数（switch radix）。当你听说一台交换机没有足够的端口时，这说明它是一台低基数交换机。当你使用低基数交换机时，你需要通过在顶部添加层级来倍增端口的数量。这就是你需要这么多层级的原因。
现在，那个问题改变了，我们有了真正的高基数交换机，我们稍后会讲这是为什么。过去所有的通信都是在 Google 的 Jupiter 网络数据中心中通过他们称为 Orion 的软件层管理的。随着这个互联网时代的发展，在 2022 年左右，Google 将光路交换引入了数据中心，因为它实际上具有很大的交换机基数。如果你去看看 Lumentum 的 OCS 交换机，甚至 Coherent 的，你会发现它们有大概 300 乘 300 的端口。这实际上是非常多的交换机端口，是高基数交换机。所以这些也转向了光学。
现在它不再进行硅交换了。当他们开始做光交换时，他们也开始做波分复用（WDM），这意味着他们发送多个波长。所有这些都增加了带宽。所以在 2022 年左右，它的速度达到了大约 6 拍比特每秒（petabits/s）。一个 peta 是 1000 tera。所以我们说的是大概 6000 terabits 每秒（Tbps）。那是 2022 年的数据。
然后他们转向了更快的网络速度，比如 400 gig 网络。使其达到了惊人的 13.1 petabits/s。那是 13100 Tbps。这非常庞大。记住 13.1 petabits 这个数字，因为等会儿我讲 Virgo 时，我会告诉你它的数字，你会发现那是多么惊人。对吧？从 2015 年到 2023 年，它增长了 13 倍。这相当酷，对吧？他们一直在非常快速地发展它。它很棒，它在互联网、YouTube 视频、网络搜索方面表现出色。
Vik: 但是，当 AI 出现时，当你训练一个拥有高度同步流量的万亿参数模型时，互联网不是那样运作的。互联网就像，Austin 在他的时区查看，而我在我的时区上失去互联网连接。也许会因为大家都在某个特定时间观看体育赛事而出现流量激增。但那些往往是区域性的。本质上这是一种异步的活动。绝大部分情况下，互联网是异步的。
AI 不喜欢这样。当所有数据同时命中 AI 时，延迟会变得疯狂，而且它总是受限于群体中最慢的那只鹿。最高延迟是引发问题的根源，这就是所谓的长尾延迟（tail latency）。最高延迟才是限制因素。
所以，这就是 Jupiter 网络。这就是直到 Google 改变一切之前的世界现状。
Austin: 是的。所以他们有一个网络，它更适合以前那种不可预测的云网络时代。顺便说一句，并不是整个网络上就只跑着一个像 AI 训练这样的大型任务。关键在于协调。所有的机器都在为一个大型任务做出贡献。显然 Jupiter 网络不是为那个时代设计的。它是高度分布式的，无数的任务在同时运行。即使流量存在某种模式，它也是高度分布式的。
然后说到你关于训练的观点，它不仅都是协调好的，而且其协调方式还存在这种长尾延迟的概念——每个人都必须完成工作并更新给其他人。如果有一个落后者，整辆巴士就得等那一个落后者。
Vik: 是的，这正是他们在博客文章中使用的词。所以，落后者很糟糕。
Austin: 是的。
Vik: 是的。好吧，那我们现在来谈谈被称为 Virgo 的新网络。他们称之为 Virgo 兆级规模（megascale）网络。听起来很高级。它确实是一个兆级规模的网络，你会明白为什么。Virgo 基本上是为 AI 设计的。他们看着网络觉得：“不行，这套互联网时代的东西不再管用了。我们需要重新设计它，让它真正发挥作用。”
这里最大的改变是，他们根据网络的实际作用重新构想了网络的每个部分。这就是为什么，我们又需要一张他们博客上的图片。如果你在 YouTube 上看的话我会放出来，这会很有帮助，但我也会尽力在没有视觉辅助的情况下去解释它。
本质上发生的情况是，他们的网络堆栈有三层，第一层是 scale-up(纵向扩展)。我们会稍微单独讲一下纵向扩展，这就是纵向扩展网络。这是在 Pod 内部的网络，也就是 Pod 连接的方式。
Virgo 互连结构本身发生在 scale-out(横向扩展)（也称为后端网络）中。这就是东西向连接发生的地方，你连接了数据中心里所有的机架。让这些 TPU 作为一个大型 AI 超级计算机运行。那就是整个横向扩展网络。然后你有了......
Austin: 为听众稍微补充一点细节。在纵向扩展中，你试图让所有的 TPU 作为一个整体运行，并且它们共享内存。所以这就像内存一致性。它们都以极快的延迟进行通信，感觉就像它们所有的 HBM 都是共享的一样。然后在横向扩展方面，从训练的角度来看，我们仍然试图构建一台巨大的训练计算机，但在横向扩展网络上的所有东西并没有共享内存。现在它们作为一个庞大协调的系统在对话，但没有那么紧密耦合。
我知道，一提到 GPU，大家就会觉得，机架内是纵向扩展，跨机架就是横向扩展。在大多数情况下是这样的，尽管你也可以在相邻的机架之间进行纵向扩展。但 TPU 有点与众不同，因为即使在它们的纵向扩展域中，它们也有成百上千个 TPU，远不止一个机架。我理解得对吗？
Vik: 是的，实际上 TPU 能扩展到几千个。但在内存一致性方面，有一些改进我接下来会提到。而且那非常......
Austin: 喔！喔！
Vik: 这结合了内存之间的延迟实际上也可以如何被减少。这就是这里的创新之处。实际上这几乎让我要解释这个网络部分的最后一部分，那就是前端网络（front end network）。前端网络仅仅是计算和存储，或者连接到互联网。这不是什么花哨的网络。所以你可以在这里使用 Jupiter 网络。你可以使用像叶脊拓扑（leaf spine topology）这种我们谈到过的 Clos 网络。那没关系。没必要重新发明网络堆栈的每一个部分。只重新发明所需的部分，对吧？它的基本样貌就是这样。
所以，Virgo 网络才是我们现在应该谈论的。他们将它完全折叠成了一个两层网络。因为他们有这些高基数交换机，顺便说一下它们全都是 OCS。如果他们使用的是 Lumentum 的 OCS，我觉得有 300 乘 300 个端口。OCS 的未来将扩展到 2000 乘 1000 个端口。你可以想象你甚至可以进一步扁平化网络。不管如何，我不知道 Coherent 是否也是 Google 的 OCS 供应商。有些事情我并不清楚。但不管怎样，所有这些技术都存在于这些公司中，并且在这些数据中心中有可行的用途。
OCS 以前是可选的，但现在它已成为 Google 数据中心网络方法中不可或缺的一部分。因为 OCS 拥有这么多的端口，你可以简单地通过两层连接它的方式，意味着你不需要所有的那些跳数。你可以只跨越两个网络层，从一个 TPU 连接到另一个 TPU。这让它变得非常非常快。
不仅如此，因为你拥有这些高基数交换机，你可以连接 1000......我这边的数字是多少来着？134,000 个 TPU，让它们在数据中心作为一个整体运行。这太疯狂了。这很不可思议。所以，他们称之为“园区即计算机”（campus as a computer）。这太疯狂了。
Austin: 是的，听起来很对。整个园区就是一台计算机。你正盯着一整台计算机看。
Vik: 没错。你想知道这整个网络现在的总带宽是多少吗？之前是多少来着？大概 13 petabits 左右？我不知道。
Austin: 你刚才叫我们记住的，我没记住。
Vik: 是的，13.1 petabits/s。那现在呢？现在是 47 petabits/s。
Austin: 哇哦。哇哦。
Vik: 差不多是 4 倍。它是以前 4 倍的速度。所以，一个原因在于它完全是光学的。在后端网络中真的没有基于硅的交换了。他们重新架构了一堆东西来实现这一点。这真的令人惊叹。而且现在你知道，当你把 134,000 个芯片放在一个“园区即计算机”里时，东西总是会坏的。所以他们内置了大量的遥测技术，以便不断监控这些东西，并保持它们的高有效输出。有效输出就是指那些实际在正常运作的内容。它不仅仅是吞吐量（throughput）。当你谈论吞吐量时，它只是说，CPU 能够产生浮点运算，但它真的生成了足够多的 token，或者完成了它应该做的事情吗？
Austin: 当然，有可能没有。现在的 goodput 术语就是用来表示实际有效工作的吞吐量。是的。这很好。
确实很好
Austin: 确实很好。是的，这不仅是理论上的最大值，也是实际应用中的表现。
Vik: 是的。现在，我得快速提一下你刚才提到的内存问题。他们现在推出了一个叫 TPU Direct 的技术。它基本上就是远程直接内存访问（RDMA）。
Vik: RDMA 作为一种技术已经存在一段时间了，在 Nvidia 的生态中，它也被称为 GPU Direct。所以，我想 TPU Direct 算是这个概念的一种演进。不过这个想法相当简单，说实话，这并不是什么惊天动地的创新。它已经存在很久了。所以并不新鲜，只是现在被应用到了 TPU 上。它的原理是，以前如果 TPU 1 需要访问 TPU 2 的内存，它必须通过主机 CPU。
Vik: 它必须通过相邻 TPU 的主机 CPU。然后主机 CPU 会与 DRAM 交互，与网卡（network interface card）交互，经过网络栈，它们之间会有一系列对话。比如，“你想访问内存吗？好的。你想怎么访问？” CPU 会参与所有这些过程。然后它会去告诉目标 TPU 的 CPU：“这家伙想访问你的内存，你允许我这么做吗？” 目标 CPU 就会说：“可以，没问题。我们开始吧，把这事办了。” 最后你才能访问到目标 TPU 的 HBM。
Austin: 所以，就像你说的，要实现内存一致性（memory coherency）需要经过太多次握手协议。这中间有太多的中间人。
Vik: 没错。就像经理们把公司搞砸了一样。所以他们决定：“把它们去掉吧。直接去掉。”
Vik: 让我们把中间人赶走，把主机 CPU 从这幅图景中移除。这就是所谓的远程直接内存访问。所以，TPU 1 会直接通过网络接口与 TPU 2 对话，不需要 CPU 参与。GPU 也是这么做的。GPU Direct 也已经存在了，Nvidia 也是这么做的。
Vik: 这极大地加快了速度。所以，速度和延迟都有显著的改善。刚才讲的这些都是关于横向扩展（scale-out）的。这就是目前 TPU Direct 的情况。接下来，我们应该谈谈纵向扩展（scale-up）了。
3D torus 魔方拓扑：用于训练的纵向扩展 (scale-up)
Vik: 因为在 TPU v8 中，纵向扩展网络有两种不同的风格。第一种是 3D torus（3D 环面拓扑）方法，大家对这个应该很熟悉了，如果你在看 YouTube 的话，屏幕上就有这张图。然后现在他们还有一种叫 Boardfly 的架构。你听说过这些吗？
Austin: 我记得听说过 torus 拓扑，好像是在 SemiAnalysis 上看到的。我不知道这张图是不是来自 SemiAnalysis？
Vik: 对，这张图就是来自 SemiAnalysis。
Austin: 好的，太完美了。他们画了一些很好的图表来展示它的工作原理。这在历史上是 TPU 进行纵向扩展的方式吗？通过 torus？
Vik: 我要用语言尽量简短地解释一个复杂的 3D 图像。
Austin: 好的。
Vik: 如果你只是在听播客而没有看视频，请仔细听。请在脑海中想象一个魔方（Rubik's Cube）。
Austin: 谢谢。我正想说魔方呢。我刚才真想说魔方。抱歉，我打断你了。
Vik: 没事，这很完美。这是一个非常大的魔方。不过你可以把它想成普通的 3x3 魔方，没关系。3x3x3。
Vik: 魔方有它内部的各个面。你其实看不到魔方内部的面。假设所有这些面都用线缆连接在一起。这里我们把魔方中每一个可以移动的小方块看作是一个 TPU。这些 TPU 像魔方一样，在立方体内部相互连接。
Vik: 内部的面在魔方内部四周都用铜缆连接。可以说每个面都用铜与其他面相连。但现在，你还需要把同一行外侧的面，以及同一列外侧的面连接起来。这就形成了一个 torus。而这部分是通过光学技术来实现的。
Vik: 因为很明显，要连接同一行或同一列但在魔方相对两端的外侧面，距离更长，必须用光学设备来连接。这就是 3D torus 的工作原理。不过，当它用于推理时，其实会遇到问题。在训练中，这没什么问题。所有这些 TPU 一起协同工作，这很好。但是在魔方中，任意两个 TPU 之间通信最远的距离——你应该仔细想想这个问题。
Vik: 其实是从魔方的边缘开始算。想象一个最外侧的边缘。如果你认为最远的边缘是魔方的另一端，那就错了。因为你总是可以使用外部的光缆到达另一端。所以那并不是最难到达的地方。在 3D torus 中，最难到达的位置是 torus 的中心。
Vik: 魔方的中心是最难到达的，在 3D torus 中需要最多的跳数（hops）。如果你想从魔方非常非常边缘的地方到达中心，你需要在一个维度上跳一半的距离，在另一个维度上跳一半，然后在第三个维度上再跳一半。这样你才能到达中心。
Austin: 嗯哼。
Vik: 所以，当你有一个 4x4x8 的魔方时——我想屏幕上展示的就是这个。
Vik: 这是 TPU v7 的配置。当你有一个 4x4x8 的架构时，你会在一个方向上跳两跳，在另一个方向上跳两跳，在第三个方向上跳四跳。所以你需要 2 + 2 也就是 4，再加 4 就是 8。在这个架构中需要 8 跳。
Vik: 你可以这样计算任何 3D torus 拓扑，它不一定是 4x4x8。也可以是 8x8x16，这意味着你需要 4 + 4 等于 8，加上另一个 16 的一半也就是 8。总共需要 16 跳。如果你看 Google 的博客，他们举的就是这个例子。他们使用了一个 8x8x16 的拓扑，这意味着从魔方上的一个点到最远的点（即中心位置），最多需要 16 跳。
Austin: 让我在这里快速插一句并回顾一下，因为我们讲得非常深，我想确保所有人都能跟上。
Austin: 刚才我们讨论的是横向扩展，大致就是将 pod 相互连接；而现在我们讨论的是将单个 TPU 相互连接。我们不想使用 Clos 网络，因为如果你在训练中有这些相邻的 TPU，并且运行密集的模型，那么邻居之间就会互相通信。想象一下网络中的不同层，你只想让 GPU 1 与 GPU 2 通信，或者 TPU 3 与 TPU 4 通信。所以它们会频繁地与邻居对话。我们不希望出现为了和邻居通信还要向上跳跃再向下跳跃的情况。传统的训练布局方式是：“我们如何将尽可能多的 TPU 密集排列，让尽可能多的邻居相互靠近，以便我们能轻易地用铜缆把它们连接起来？” 所以，Vik 带来的这张魔方图展示了：在三维空间中连接它们实际上是非常理想的。如果我在左下角，把那当作我的小方块或 TPU，我的右边有一个 TPU（称之为 X 轴），左边有一个 TPU（称之为 Y 轴），正上方还有一个 TPU（称之为 Z 轴）。所以我有很多离我非常近的邻居。
Austin: 而且 Vik 刚才也指出了，如果我在那个左下角，想要连接我所在的 X 轴上的任何其他人，只需要经过一个邻居、两个邻居或三个邻居，或者你可以用光缆将我从一端直接连接到另一端。所以，与邻居的邻居对话实际上很容易。但是最难对话的是正中间的那个，因为我必须在各个维度（X、Y 和 Z）上穿过邻居才能到达那里。好了，交回给你。
Vik: 谢谢。这个总结很好，因为这非常重要。
Vik: 这就是 3D torus。在 8x8x16 的架构中，我向你展示了在每个方向上如何需要走完一半的跳数。听众可能会想暂停一下，思考：“他在说什么？多少跳？” 但是，这个网络设计是件非常严肃的事情。不管怎样，Google 博客文档里提到的是 16 跳。16 跳是很多的。
Vik: 这对于训练来说是一个很好的架构。因为所有这些 TPU 都在时刻互相通信。但在推理中，这就不是一个好架构了。为什么呢？因为不是所有的 TPU 都时刻处于激活状态。
Vik: 当你运行一个混合专家（MoE）模型时，只有一部分 TPU 会被激活，这取决于哪些参数被调用。因此，所有的 TPU 不会始终一起工作。而且它们确实需要经过更多的跳数。你希望将这种逐跳延迟降到最低，因为否则它会增加推理时间并影响性能。你肯定不希望这样。所以问题是，在基于 MoE 模型进行推理的世界里，你该如何为 3D torus 进行架构设计？
Boardfly：用于 MoE 推理的纵向扩展 (scale-up)
Vik: 这就是为什么我们引入了 Boardfly 的概念。
Austin: 让我为听众快速梳理一下。对于训练，我们需要所有这种邻居到邻居的通信。而 Vik 的意思是，当你运行混合专家模型时，并不一定会发生所有这些邻居到邻居的通信，因为这可能是：“对于这个 token，我需要那边那个编号 21 的专家；而对于另一个 token，我需要那边那个编号 4 的专家。” 所以它每次的通信模式是不一样的，不仅仅是邻居对邻居、层对层。
Austin: 现在的路由（routing）问题，实际上让我想起了我们之前讨论过的非确定性（non-deterministic）时代。所有这些都是为了说明，训练的通信模式与推理的通信模式是不同的。这就引出了一个观点：为什么不专门针对工作负载（在这种情况下是 MoE）设计互连网络呢？顺便说一下，如果你去听 Rainer Pope 的演讲，他其实也谈到了他们是如何思考这个问题的，即专门为 MoE 设计互连网络。好的，Vik，你继续。
Vik: 太棒了。
Vik: 这是一个很好的背景补充。我们需要它。我们需要经常停下来思考，并在心里默念网络到底是什么。这是学习网络知识的唯一方法。你必须大声说出来。所以，暂停一下视频，把我们目前讲过的内容大声复述一遍。
Vik: 好的。所以最终我们走向了 Boardfly 架构。这并不是一个颠覆性的全新发明，而是对现有理念的一种修改。Boardfly 方法的根本目的在于减少跳数。还记得我告诉过你 8x8x16 架构有 16 跳吗？现在，我们希望把这个数字降下来。
Vik: Boardfly 拓扑允许你做到这一点。它的工作原理是：你有一个电路板。在一个电路板上，基本上有四个 TPU。每当你搜索 TPU v8 时，你都会看到这种图片：一块带有四个 TPU 的电路板。它们是通过 PCB 连接的。
Vik: 所以这里用的是铜连接。这里没有光学设备。就是一块带有铜连接的 PCB 电路板。这就是铜连接。现在，你把八块这样的电路板放进一个机架（rack）里。然后用有源电缆（AEC）把它们全部连接起来。
Vik: 你看，纵向扩展仍然在使用有源电缆。所以并不是说所有的东西都变成了光学设备，铜缆已经死掉了。不是的。AEC 仍被用来连接这八块电路板。现在这就叫做一个组（group）。
Vik: 这些电路板之间的连接方式被称为蜻蜓拓扑（dragonfly）。这种架构从超级计算机时代起就已经存在了。同样，这已经存在几十年了。在今天看来，这并不是什么极具革命性的想法。在当时是，但今天不是了。
Austin: 让我分享一个小小的冷知识。
Austin: 我在 Google 上搜索时发现了这个。我一直等着想告诉你。我以前还没跟你说过。我当时在查 dragonfly，发现有一篇 2008 年的计算机架构论文介绍了 dragonfly 网络。论文的作者有来自西北大学的 John Keen，来自斯坦福大学的 William Dally（你可能也知道他叫 Bill Dally，他现在在 Nvidia，是 Nvidia 研究部门的主管，顺便说一句，这大概是世界上最酷的工作之一了）。还有一位作者是来自 Cray 公司的 Steve Scott，当然了，Cray 超级计算机有很多历史渊源。
Austin: 也许有些人不知道，Cray 公司位于威斯康星州的 Chippewa Falls，那是一个只有一万四千人的小镇。真是有点疯狂（crazy），有点 Cray。这篇 2008 年论文的最后一位作者是 Dennis Abts。我不确定他姓氏怎么发音，A-B-T-S。他当时在 Google 工作。
Austin: 后来他去了 Groq，是 Groq 早期的工程师，大概从 2017 年开始，可能负责了他们所有的网络设计工作。之后他又去了 Nvidia。从那以后他就一直在 Nvidia。所以，当我看到那篇论文时，我就觉得：“哇，这些都是 Nvidia 网络领域的大佬啊。” 看到这一切竟然能追溯到 2008 年的他们，感觉太不可思议了。好了，交还给你继续。我只是觉得这挺酷的。
Vik: 非常棒。这是一个很棒的冷知识。我还想补充一点，关于 Dennis Abts 在 Groq 工作然后去了 Nvidia 等等，如果你看看 Groq 是如何架构他们的机架级解决方案的，那也是 dragonfly 架构。他们不连接电路板，他们以 dragonfly 的配置连接各个独立的 LPU。
Vik: 顺便说一句，Groq 就是这么做的。
Austin: 我明白了。懂了。是啊，因为这依然可以减少跳数。即使它们没有在电路板上连接，它仍然将跳数从 16 跳降到了一个更低的数字。
Vik: 是的，完全正确。这就叫 Boardfly，因为你不是在用 dragonfly 配置来连接像 GPU 这样的单体芯片，而是在用 dragonfly 配置连接带有四个 TPU 的电路板。所以它被称为 Boardfly。这仍然是 AEC。下一级是把所有这些组连接在一起。
Vik: 记住，我们一块电路板上有四个 TPU，一个机架里有八块电路板，这也可以被称为一个组。然后在一个 pod 中有 36 个相互连接的组。如果你把 36 个组 * 8 块电路板 * 4 个 TPU 乘起来，你会得到 1,152 颗芯片。这 36 个组全部通过光路交换机（OCS）连接。你再次看到，OCS 是 Google 所有网络构建的底层基础。这说明了这项技术现在有多么重要。
Austin: 是的，是的。所以，在 Virgo 中的所有这些横向扩展，全是基于 OCS——
Vik: Virgo，是的，这全是因为它是一个高基数交换机（high-radix switch），它将两层连接起来，把所有这些东西连接成分层结构。
Austin: 好的，所以所有的横向扩展都是 OCS，然后电路板上的纵向扩展是 PCB 线路，一个组内相邻的电路板通过 AEC 连接，但组与组之间是通过 OCS 连接的。
Vik: OCS，全光网络，是的。所以光学技术是所有这些网络的主要驱动力，这一切都由 OCS 支撑。那么，这样做的好处是什么呢？
Vik: 为什么要弄这些东西？我保证这节课很快就会结束。但是我觉得这真的很令人着迷。好的，让我给你展示几张更多的图片，如果你在看 YouTube 的话。Boardfly 架构展示了到底是如何使跳数最小化的。只有图片才能展示给你看，因为你可以做的是，在一个机架内从一块电路板到另一块电路板，你会在机架内跳几次，然后你通过 OCS 进行一次大跳跃，到达一个不同的组，然后在那里再跳几次。最终，你大概在六或七跳内就能到达目的地。
Vik: 所以，通过为纵向扩展架构出一种 Boardfly 网络方案，你的跳数从 16 跳一路降到了 7 跳。这是件了不起的事。通过这种巧妙的连接方式，延迟下降了超过 50%。你看，这就是为什么数据中心的网络对其提供的性能至关重要。这是决定性的，对吧？
Vik: 我能讲的也就这么多了。这相当硬核。
Austin: 是啊。这一期非常技术化，我知道。
Vik: 但基本上总结一下，有两个重大的发明。
万物皆可工作负载定制 (Workload-specific everything)
Vik: 一个是横向扩展网络，几乎全是 OCS。然后是纵向扩展网络的重新架构，从 TPU 经典的 3D torus 转变为针对推理优化的 Boardfly 拓扑。好了，这就是我的长篇大论。
Austin: 非常好。谢谢你，Vik 教授。是的，提醒一下大家，我们为什么要花一整期时间来讨论 Google 发布的这些东西，因为我们再次看到了巨大的转变：从一个处理所有任务的芯片，转变为训练和推理两种芯片；但这不仅仅是两款芯片的问题，而是两种纵向扩展网络——用于训练、为了支持邻居之间密集通信的 3D torus，以及用于 MoE 推理纵向扩展的 Boardfly 架构。这再次证明了很多人一直以来的观点：这里不再是“一招鲜吃遍天”了，无论是对芯片还是网络来说，甚至连数据中心，整个数据中心都在围绕着工作负载进行架构设计。
Austin: 因此，无论你是这个领域的初创公司，还是在关注光通信技术，这都是我们从 Google 身上看到的一个巨大转变。当然，这也会带来很多有趣的问题，比如：我们会开始看到其他厂商（比如拥有 Trainium 的 AWS）也做出这种级别的网络创新吗？他们会坚持为自己的云环境设计架构的老路，还是会开始设计专门针对 MoE 推理定制的数据中心呢？哪怕这意味着他们必须改变在 Web 服务器 API 时代的思维方式。
Vik: 是啊，这很有趣，对吧？现在，训练和推理已经明显分化为两个不同的阵营。它们有不同的芯片，不同的网络解决方案。
Vik: 我不知道接下来会是什么。会有不同的电源解决方案吗？会根据风向选择不同的地点吗？这是一种极致的协同设计（extreme co-design）。这确实有影响，风向也是有影响的。
Austin: 这绝对是极致的协同设计。当然，还有价值百万美元的问题，我相信我们迟早会绕回到这些问题上：永远就只有这两种架构吗？还是会有其他的工作负载需要略微不同的设计？对于推理，这也是一种“一招鲜吃遍天”的解决方案吗？能适用于所有的推理工作负载吗，无论是世界模型（world models）还是单纯的文本推理？
Vik: 是的。也许未来我们会建立针对智能体推理（agentic inference）的数据中心。
Vik: 肯定会有人发现智能体工作负载需要一种不同的基础设施。
Austin: 我很高兴你提到了这一点。因为我还是想了解更多关于 CPU 在这种通信和网络拓扑中所处的位置。显然，他们提到了用 Axion CPU 来为 TPU 输送数据。但是，其他那些运行在 CPU 和虚拟机上的智能体呢？我知道它们很多是长时间运行的，延迟并不重要，但那些对延迟敏感的任务呢？它们会以某种方式进入这个网络拓扑吗？我不知道。
Austin: 快来告诉我们，教教我。这里有太多东西要学了。这仅仅触及了皮毛。我们甚至还没谈到我在他们的核心中看到的其他东西——CAE，即集合加速引擎（collectives acceleration engine）。
Vik: 是的，是的，我甚至都不知道那是什么。我还没来得及去了解它。
Austin: 我们以后得跟进一下。我稍微读了一点资料，听起来它确实与网络有关，听起来像是把一些通信任务卸载（offloading）到了特定的加速器上。我在这里做了一点笔记，CAE，即集合加速引擎——每个 TPU 都有两个 Tensor Core 和一个位于小芯片裸片（chiplet die）上的 CAE，而 CAE 负责卸载所有的 All-Reduce、All-Gather、All-to-All 类型的集合通信（collectives）。这是一个针对特定工作负载的加速器。它有点像 Nvidia 的 SHARP。这其实和 DPU 的作用有点类似，那就是如何让 GPU 尽可能多地执行矩阵乘法，让 CPU 不要碍事，省下资源去处理消息传递或为 TPU 提供数据；同时尽可能地把网络相关的任务放到专门针对网络优化的硅片上。
Austin: 这简直就是“一路龟到底”（turtles all the way down），对每一个环节都在做优化。
Vik: 确实如此。好了，这些信息对于任何人来说都太多了。我想我们不得不把这一集剪成 16 个片段。我不知道，这简直就像是一门关于 OCS 和 Google 网络的完整课程。
Austin: 是的，在 Google 昨天发布公告之后，希望大家喜欢 Vik 教授几乎实时的这堂讲座。感谢收听。今天就到这里。如果你喜欢 Semi-Doped 播客，你首先应该做的就是告诉你的朋友们。当我们看到大家分享我们的视频时，我们会非常开心。非常感谢大家的口口相传。
Austin: 如果你还没有订阅，请订阅我们的时事通讯（newsletters）。我相信 Vik 和我会就这个话题写出更深入的文章。是的，谢谢大家，我们下周见。