公众号记得加星标⭐️，第一时间看推送不会错过。

来源 ：内容 编译自nextplatform 。

每两年晶体管数量增加一倍，从而将晶体管价格降低一半，因为可以在给定面积上塞入两倍的晶体管，这在 CMOS 芯片时代改变了计算方式并推动了它的发展。

但摩尔定律的数学意义还在于此。每次略微提高功率预算，就能将设备性能每年提升 40%。对于计算引擎而言，这意味着每年的升级频率足以满足大多数公司事务性和分析性工作负载的增长需求。而对于那些需要更多性能的公司，对称多处理 (SMP) 和非均匀内存访问 (NUMA) 集群技术可以使多个设备看起来像一个大设备——我们称之为“纵向扩展”。

随着 20 世纪 90 年代末 Web 2.0 互联网时代的到来，一台机器即使配备了 SMP 或 NUMA，这种所谓的通过共享内存扩展来提高计算能力的做法也显得力不从心。（有趣的是，巧合的是，当时超级计算中奇特的联邦 NUMA 配置（如今我们可以使用现成的 PCI-Express 交换机轻松构建）也不足以支持传统的 HPC 仿真和建模工作负载，但其规模要大得多，对于企业和像谷歌这样尚未进入超大规模的网络公司来说成本太高。）因此，在这两种情况下，在具有数百到数千个节点的分布式计算集群之间进行扩展很快成为让机器同时完成更多工作或在更短时间内完成相同工作的唯一方法。

此时，网络真正成为了计算机。从那时起，网络就一直是瓶颈，在 GenAI 时代更是雪上加霜。售价 3 万、4 万或 5 万美元的 GPU 的计算能力可能只达到了 25% 到 35%，因为它们需要在 AI 集群中等待每次 AI 训练迭代，与其他 GPU 交换数据。

我们正处于谷歌人工智能和基础设施副总裁兼总经理阿明·瓦达特 (Amin Vahdat) 在本周的 Hot Interconnects 32 会议开幕主题演讲中所说的分布式计算的第五个时代，而 GenAI 工作负载所需的性能巨大飞跃意味着计算行业必须再次重新思考网络、网络和工作的方式。

在我们深入探讨分布式计算第五个时代对其网络的需求之前，Vahdat 认为以下是第五个时代：

您会在上表中注意到，随着计算技术的每一个新时代的到来，用于运行应用程序的计算机之间的交互时间都会下降一个数量级，从 20 世纪 80 年代中期结束的 FTP/Email/Telnet 时代的 100 毫秒到当前机器学习/以数据为中心的计算时代的 10 微秒，正如 Vahdat 所说，我们也可以将其简化为“数据智能”。

随着容量更大的计算和存储进入市场，计算和存储容量也随之增长，利用网络并加大驱动力，形成良性循环和恶性循环。

Vahdat 在主题演讲中表示：“从 2000 年到 2020 年，通过整个社区的大量工作，我们实现了固定成本效率提高约 1,000 倍的目标。”这意味着，假设到2020年左右，你的计算能力或存储容量将提升1000倍，而价格与2000年相同。我们所能想象的事情也随之发生了巨大变化。这为人工智能时代奠定了基础。我的意思是，我们最终拥有了足够的数据和计算能力，可以想象定期进行大规模计算，用于训练或服务于新一代模型。因此，需求仍在持续增长，虽然我们花了20年时间才实现上一次1000倍的效率提升，但我们必须以更快的速度实现下一个1000倍的效率提升。我认为这将是我们工作的关键。

这是一个加速计算的时代，计算需求的速度不断加快，这是很有道理的。

“我们在上一个时代看到的是快速增长，但实际上，在过去几年里，我们看到的是对计算的需求几乎是无限的，年增长率高达10倍，”Vahdat解释道。

“而伴随计算需求而来的是相应的网络需求。”

Vahdat 表示，在 GenAI 时代，计算需求每年增加 10 倍是件很难的事，因为即使你可以通过组合使用更大的芯片（或小芯片复合体）并降低数值精度来将计算引擎的性能提高 2 倍或 3 倍，你仍然需要再增加 3.3 倍到 5 倍才能达到 10 倍，这意味着无论如何，分布式计算系统中的端点数量都必须持续增长。

这就是为什么我们看到少数AI模型构建者已经构建了拥有10万或20万个端点的系统，并且许多人正在谈论未来一两年内拥有100万个XPU的集群。这并非容量集群（借用HPC领域的一个术语，指的是一台机器上以共享方式调度数千个工作负载），而是真正的能力集群，旨在在整个机器上运行单个工作负载。因为它必须如此。

对人类知识总量进行切分和切片，并创建一个巨大的知识图谱，将查询输入其中，以强制基于该知识做出具有统计意义的响应，这是一项艰巨的任务。

好消息是，即使 AI 工作负载需求巨大，它们也是可预测的。以下图表展示了训练 Gemini 模型时的突发流量，分别以 30 秒、5 秒和 100 毫秒为间隔进行分析：

在 5 秒的时间尺度上，主机网络的带宽波动看起来像是波涛汹涌的波浪，但并不太剧烈；而在 30 秒的时间尺度上，一切看起来都很平稳。但这并不能准确描述正在发生的事情。看看 100 毫秒蓝线的剧烈波动。加速器只是在那里等待了一段时间，然后在其他时间疯狂地吸收数据。

但再说一遍，看看这种可预测性。如果某件事能够如此规律地预测，那么它就可以被管理，更重要的是，它可以被调度。这就是第五个时代网络的秘密，事实上，这也是超级以太网联盟致力于为以太网网络提供AI/HPC变体的目标之一。

“现在，你越来越多地拥有完整的网络，数以万计的服务器，可能每次只运行一个应用程序，从计算到通信的各个阶段非常复杂，”Vahdat 说。“没有统计多路复用器。只有一个应用程序，并且该应用程序是紧密同步的。换句话说，计算通常需要所有服务器之间的通信，我们讨论的是可能超过 10,000 台服务器之间的通信，这意味着通信必须高度同步，这打破了我们多年来的一些基本假设。”

以下是 Vahdat 在演讲中提出的关于 AI 工作负载及其网络的新假设：

1、以毫秒为粒度的同步、周期性线速突发持续数十秒

2、延迟敏感（内存屏障）和带宽密集型

3、可预测性：对于同步工作负载，最坏情况（100 %的）延迟不仅会影响性能，还决定了性能

4、工作负载需要近乎完美的基础设施（任何崩溃都会导致整个作业停止运行）

5、单租户工作负载和同步高速突发，跨工作负载的统计复用没有任何好处，因为只有一个

6、加速器效率至关重要，网络是系统范围性能、可预测性和可靠性的最关键推动因素

Vahdat 表示，未来的网络必须提供海量突发带宽、低延迟、超低抖动以及极高的可靠性。这很简单，对吧？

这个第五个纪元网络有很多秘密——请放心，谷歌可能不会将其硬件设计和协议规范贡献给开放计算，也不会将其软件贡献给 Linux 基金会——但重要的是谷歌的 Firefly 网络时钟同步、Swift 拥塞控制、Falcon 硬件传输和落后者检测（需要更好的代号），用于识别和隔离网络堆栈和人工智能系统中的计算节点中的硬故障和软故障。

在所有这些技术中，Firefly 或许是最重要的。其核心在于：即使网络负载会发生变化，在可预测的情况下，如果能够对流量的各个方面进行调度，就能管理好所有流量，从而避免造成拥塞。要做到这一点，实际上需要一个时钟来同步网络上的数据流，其周期要远快于网络延迟。（显然，即使有这样的调度，网络上仍然会存在一些拥塞，否则谷歌就不需要 Firefly 网络时钟和流量调度了。）

这款新的数据中心节拍器将于 9 月初在葡萄牙举行的 SIGCOMM 2025 会议上在一篇名为Firefly：数据中心的可扩展、超精确时钟同步的论文中亮相。谷歌大约从 2010 年起就在数据中心中使用原子钟，当时它正在测试其 Spanner 全球分布式数据库，该数据库在其覆盖全球的 Colossus 文件系统上运行。无论是当时还是现在，有了 Firefly，通用云都是必需的，因为正如 Vahdat 在 HOTI 2025 上的演讲中所说，“你无法安排你没有计时的事情。”FireFly 实际上就是整个数据中心所有事物的节拍器，它提供了一个覆盖整个系统的 10 纳秒以下的时钟同步结构。

通过对每一件小事进行定时和调度，网络“从一个随机延迟的源头转变为一个确定性、可靠的网络结构”，正如Vahdat在演讲中详细描述的那样。每一次数据传输都经过精心设计，而且由于“所有到所有”的通信模式非常有规律（如上所示），这并不像听起来那么荒谬。网络从被动地尽力投递数据包转变为“主动的、完美调度的网络”。

Firefly 可以在 10 纳秒内同步网络接口卡 (NIC)，这些卡将承担未来网络中的所有繁重任务，而不会增加主机系统和交换机的负担。此外，它还能在 1 毫秒内将 NIC 同步到世界标准时间 (UTC)。Vahdat 表示，这使得 AI 集体操作的调度时间能够达到数十纳秒。而在此之前，在基于博通“Tomahawk Ultra” StrataXGC 交换机 ASIC等芯片的高端以太网交换机中，端口间的传输速度需要数百纳秒，而早期的 Tomahawk 交换机则要远超这一速度。

除了使 AI 训练更好地发挥作用（我们假设 AI 推理也是如此）之外，使用 Firefly 同步和网络调度意味着集群中 XPU 的空闲时间将是一个已知的、可预测的、并且比其他情况下更低的数量，这反过来意味着每年在全球销售的数千亿美元的 GPU 系统可以带来比现在更多的价值，而这些系统只是坐在那里等待数据。

Google 开发的 Swift 拥塞控制技术比 Firefly 更古老，这也是它存在的原因。这种拥塞控制方法在 SIGCOMM 2020 的一篇名为《Swift：延迟对于数据中心拥塞控制来说简单有效》的论文中被披露。Swift运行在网卡和主机服务器上，其基本原理是发出“稍等”的指令，而以太网通常不会这样做，以此来应对网络拥塞。（或许它应该被称为“Waitaminit”？）

Vahdat 在演讲中解释道，Swift 的作用是维护网络和主机上所有排队信息的细粒度信息，并调整网络数据发送速率，以达到网络中低级排队的目标水平。这样做的最终结果是，运行 Swift 拥塞控制的以太网网络可以处理突发流量，例如 AI 和 HPC 的全对全通信以及大规模 incast，同时仍然能够以低延迟、高网络利用率和几乎零数据包丢失率传输数据。

这就带来了 Falcon 协议以及谷歌和英特尔所称的智能处理单元（IPU）以及我们大多数人所称的数据处理单元（DPU）。

Google 一直在协议方面投入大量精力，以优化数据在各种网络上的打包和传输方式。例如，我们早在 2022 年 10 月就向您介绍了Aquila 协议及其非常具体的小型集群用例。Google 在 2019 年的一篇名为《Snap：一种主机网络的微内核方法》的论文中披露了一种使用更广泛的主机网络系统 Snap ，该论文概述了一种源自 Linux 的网络操作系统，其模块在用户空间中编码；其中一个模块是 Pony Express，这是一个数据平面引擎，对于 Snap 来说，它是传输层，包括流量控制、拥塞控制和其他功能。据我们所知，Snap 和 Pony Express 自 2016 年左右就已部署在 Google 的主机网络中。

最近，通过转向与英特尔联合开发的更智能的 DPU（特别是我们在此处讨论的“Mount Evans” IPU），谷歌为该设备开发了一个名为 Falcon 的新传输层，这是第五个时代网络的另一个元素。

Vahdat 解释道：“将 Falcon 视为可靠、低延迟 NIC 传输的硬件实现，它是否会在极高的性能水平、低尾部延迟和大规模应用带宽方面不断追求。”

Falcon 及其相关技术由谷歌在超大规模计算平台 Meta Platforms、微软以及英伟达的帮助下开发，因为正如 Vahdat 简洁且或许是善意地指出的那样，基于融合以太网的 RDMA“更适合小众用例，而非通用数据中心”。我们对 Falcon 了解不多，但一篇名为《Falcon：一种可靠的低延迟硬件传输》的论文也将在下个月的 SIGCOMM 2025 上发表，我们将持续关注。Falcon 似乎将实现 Swift 基于延迟的拥塞控制等功能。Falcon 的目标是提供比 Pony Express 传输每秒 10 倍的操作速度，并将尾部延迟降至 Pony Express 传输的十分之一。从 Vahdat 展示的早期测试来看，这一目标似乎已经实现：

第一个实现 Falcon 硬件传输层的硬件是与英特尔联合设计的 Mount Evans E2100，它拥有 16 个 Arm Neoverse N1 内核和 48 GB 内存，并带有两个 100 Gb/秒的端口。

谷歌即将获得的这套网络虚拟化方案配备了专用硬件，用于其自主研发的“Andromeda”带外网络虚拟化堆栈。我们早在 2017 年 11 月就曾向大家介绍过该堆栈，并在当年晚些时候与 Vahdat 的问答中进行了详细阐述。该网络虚拟化方案还运行谷歌自主研发的 RDMA 实现，并配备电路，支持虚拟机实时迁移、NVM-Express 闪存虚拟化以及动态数据压缩和加密。Vahdat 暗示，带宽分别为 400 Gb/秒和 800 Gb/秒的 Mount Evans 版本（可能根据谷歌的需求提供双端口和单端口版本）即将推出。

据我们所知，英特尔在这方面做得非常正确，并希望生产出一款能够进入主流市场的 DPU。

对于谷歌而言，Falcon 传输意味着其网卡的中位延迟和尾部延迟都接近理想吞吐量，并且“有效吞吐量”在最大链路速度下达到饱和。随着队列对数的增加，它的延迟与 Nvidia ConnectX-7 大致相同，但在 3,000 到 4,000 QPs 左右时，CX-7 的延迟峰值略高于 Mount Evans 设备的 3 倍。

这使得落后者检测成为 Vahdat 在 HOTI 2025 上谈到的网络第五个时代的最后一部分。

“我们拥有强大的机制，不仅能够检测硬故障，还能检测可能发生的、越来越棘手的软故障或掉队故障，”Vahdat 说道。“假设某个节点宕机了，或者某个网络链路断了。它的速度可能很慢——可能是其他节点的 1/2，也可能是 1/4，无论出于何种原因。也可能是误码率上升了，也可能是 PCI-Express 出了问题。有上百种情况都可能出错，但实际上并不会造成硬故障。如何快速地定位、检测并移除或修复该元素？”

这并非小事。但请记住，在AI工作负载中，与HPC工作负载一样，当一个节点宕机时，整个训练运行或模拟都会停止或运行缓慢。（这就是为什么检查点计算对于AI和HPC工作负载同样重要。）

Vahdat 没有时间详细介绍落后者检测 (Straggler Detection)，但他表示，该公司为查找数据中心集群故障而设计的系统，其流程原本可能需要谷歌最聪明的团队耗费数天时间进行手动调试，而现在只需几分钟即可完成自动分类。我们很想知道在这个系统中部署了多少人工智能技术来维持其正常运行。其核心在于，谷歌从网络中的所有网卡、交换机和主机获取遥测数据，并创建所有这些设备的实时通信图。当发生故障时，谷歌会找到所有受影响的设备，并找出如何在图上从这些设备上游进行查找，从而快速找到行为异常并导致问题的罪魁祸首设备。它通过查找根本原因落后者（即速度缓慢且未等待任何其他节点的节点）来实现这一点。

就是这样。或者更准确地说，除非超级以太网联盟、开放计算项目和其他组织将所有这些想法付诸实践，否则你不会实现它。

https://www.nextplatform.com/2025/08/21/google-is-already-using-the-future-ai-network-you-might-get-in-2028/

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

今天是《半导体行业观察》为您分享的第4133期内容，欢迎关注。

加星标⭐️第一时间看推送，小号防走丢

求推荐