ZD至顶网网络频道 07月05日 综合消息:如今网络领域的主要争议话题之一是,是将网络功能加载到 CPU 上更合适,还是将这些功能卸载到互连硬件上更为理想。
Mellanox公司市场部副总裁Gilad Shainer
加载(Onloading)互连技术更易于实现,但问题在于对 CPU 利用率的影响由于CPU必须管理和执行网络操作,因此采用加载互连技术会降低其对应用程序的可用性——而这却是 CPU 的主要用途。
另一方面,卸载(Offloading)技术寻求克服 CPU 的性能瓶颈,主要方式是对在群集内移动的数据执行各种网络功能以及复杂的通信操作,如协同操作和数据聚集操作。当今数据分布范围广,在等待数据到达 CPU 处进行分析时就会产生性能瓶颈。相反,使用从 CPU 卸载这些功能的智能网络设备,就可在网络中的数据所在的位置进行操作。这一技术还有附加的优势:增加 CPU 对于计算功能的可用性,从而提升系统的整体效率。
CPU 利用率的问题是这两种技术选项之间的争论焦点。然而,计算 CPU 利用率的方式以及用于测试的基准会带来误导性很强的结果。
例如,常见错误是使用公共延迟测试或消息速率测试确定 CPU 利用率;然而,这些测试通常需要 CPU 频繁查找数据(即轮询内存中的数据),这就使得CPU看起来像是处于 100% 利用率,而实际上它完全没有工作。使用此类测试确定 CPU 利用率会产生虚假的结果。因为现实中,CPU 并不会频繁检查数据。
那么,测量 CPU 利用率的正确方式究竟是什么?在理想条件下,可使用数据带宽测试或不借助数据轮询的其他测试确定CPU利用率。或者,如果使用消息速率测试,则必须将此测试配置为避免陷入数据轮询循环,这样才能产生真实的结果。最终,最佳的选择是将实际执行的CPU指令数与测试持续期间可能已执行的 CPU 指令数进行比较。这样会得出准确的 CPU利用率百分比。
我们需要考虑的另一个重要因素是正在测量的开销类型。例如,如果测试设计为测量网络协议对 CPU利用率的影响,则应该仅测试在两台服务器之间传输的数据,而不包括额外的开销,如位于软件层中的MPI。如果目标是测量软件框架的开销,如MPI,则应使用MPI测试,但在此案例中,必须使用具备适当卸载功能的正确MPI(如果存在的话)。并不是所有的 MPI 都支持各种基于硬件的卸载,因此知晓测试的条件非常重要。
现在我们已了解如何精确地测量CPU利用率,那么剩下的问题就是:“哪种技术更为合适,卸载还是加载?”
我们在多台服务器之间进行了多次数据吞吐量测试,这些服务器分别通过EDR InfiniBand 和专有的Omni-Path 连接在一起。这些测试包括在测量 CPU 利用率时以每个互连支持的最大数据速率(大约 100 Gb/s)发送/接收传输的数据(参见表 1)。在数据速率为100 Gb/s的情况下,InfiniBand的 CPU 利用率仅为 0.8%,而为了执行相同的任务,Omni-Path的 CPU 利用率需要达到 59%。因此,在使用InfiniBand 时,CPU 对于应用程序的可用性是 99.2%;而在使用Omni-Path 时,仅有 40.4%的 CPU 周期可提供给应用程序。此外,我们在每种情况下都测量了 CPU 频率,因为 CPU 在不需要全速执行时会降低其频率以实现节能。在使用InfiniBand 时,CPU 频率能够降到其正常频率的 59%以实现节能。而在使用Omni-Path 时,CPU 全速执行,因此无法实现节能。
表 1 —— CPU 利用率比较:InfiniBand vs. Omni-Path
我们采用Intel 的Performance Counter Monitor 工具集检查 CPU 状态。该工具提供一组更丰富的测量方式来确定详细的系统状态。利用此工具,我们发现Omni-Path 的速度实际上未达到 100 Gb/s,而是稍低,为 95 Gb/s。AFREQ 状态报告在测试期间动态设置的 CPU 频率。我们还能够查看每个不同互连协议使用的迭代次数和活动周期数(参见表 2)。
表 2 —— Intel Performance Counter Monitor 工具统计数据对比
此外,在协同设计架构内的智能设备上部署InfiniBand 时,该产品还可通过卸载 MPI 操作来进一步减少 CPU 的开销。当然,为完成此次计算,测试必须确定在基准中包括软件层,这样才能获得准确的现实结果。我们计划未来进一步在不同的应用程序层面上执行多种测试,以证明InfiniBand的重大优势。
InfiniBand采用卸载技术,以降低 CPU 的负载,而最终的测试结果也正如我们所预料。如果其他测试结果与此处所示不同,则有必要调查测试环境,以更好地理解如何获得正确的结果。这些结果很有可能产生误导,无法准确反映现实的情况。(文/Mellanox公司市场部副总裁Gilad Shainer)
好文章,需要你的鼓励
许多组织在实施 AI 代理时过于狭隘地关注单一决策模型,陷入了"一刀切"决策框架的误区。然而,人类决策远非统一,而是复杂、动态且依赖于具体情境的。如果要将 AI 代理有效整合到组织中,就需要考虑多样化的决策过程,以确保有效实施,避免无意中设定一个低标准的决策模式。
Google 近期加快了 AI 模型的发布节奏,推出了业界领先的 Gemini 2.5 Pro 和 Gemini 2.0 Flash。然而,公司尚未发布这些新模型的安全报告,引发了对透明度的担忧。Google 表示正在权衡快速迭代和获取反馈的方式,承诺未来会发布更多文档,但专家认为这种做法可能会树立不良先例。
AI视频生成公司Runway宣布完成3.08亿美元融资,由General Atlantic领投,估值超30亿美元。公司刚发布新一代视频生成模型Gen-4,可生成长达10秒的视频片段。Runway计划利用新资金加强AI开发,重点提升训练数据集质量和扩展扩散模型与大语言模型能力。
亚马逊推出Nova Act AI代理SDK,这是一个用于构建可自主完成网络任务的AI代理的开发工具包。它由亚马逊自研的Nova大语言模型驱动,采用细粒度任务分解和直接浏览器操作等方法,旨在提高AI代理的可靠性。该SDK开源,但仅支持亚马逊Nova模型。这标志着亚马逊在AI代理领域向OpenAI、微软等竞争对手发起挑战。