AI Infra 现状:一边追求 10 万卡 GPU 集群,一边用网络榨取算力

借此机会,InfoQ 独家专访了腾讯云副总裁兼腾讯云网络总经理王亚晨,探讨了腾讯在改革算力互联方式方面的思考。

作者 | Tina

云行业进入了生成式 AI 时代,除模型算法外,头部企业纷纷将大量精力投入到解决算力和互联问题上。然而,如果没有网络支持,计算的篇章就无法开启。

7 月 1 日,腾讯宣布其自研星脉高性能计算网络全面升级,升级后的星脉 2.0 支持超 10 万卡大规模组网。借此机会,InfoQ 独家专访了腾讯云副总裁兼腾讯云网络总经理王亚晨,探讨了腾讯在改革算力互联方式方面的思考。

将整个数据中心变成一个“大芯片”?

前几天,百年风投机构 BVP 发布了一份云计算现状报告,副标题直接使用了这样一句话:“传统云已死,AI 云长存!(The Legacy Cloud is dead , long live AI Cloud!)”他们承认传统云仍然有重大发展机遇,但更震惊于 AI 带来技术变革加速,现如今我们已经很难找到一家不做 AI 的云计算企业了。该报告特别指出,“这是一场关键的‘地盘争夺战’,决定了未来几年哪些大型科技公司将在云和计算市场占据主导地位。”

AI 大模型靠的是大力出奇迹,注定了训练它的基础设施跟传统云不一样。

由于 AI 的大流行,数据中心也开始从以 CPU 计算为中心到以 GPU 计算为中心。在 CPU 环境中,大规模并行计算的任务可以被分割得很零散,以微信为例,虽然它也是一个庞大的业务,但它的任务是零散且琐碎的。每个用户和每个进程的任务都是不同的,因此可以将任务分散处理。然而,大模型不同,它依赖于强大的计算能力,通常使用 GPU 通过不同的模型或通信方式来处理同一个任务。大模型很难将任务分割得如此零散,希望开发下一代基础模型的企业就不得不投入越来越大的集群来对应挑战。

AI Infra 现状:一边追求 10 万卡 GPU 集群,一边用网络榨取算力

集群规模不断上涨,从千卡到万卡,再到十万卡,据王亚晨的描述,“去年大家都在谈论实现万卡集群,只在理论上讲如何实现十万卡。今年的情况有所不同,现在大家实际上已经在实践十万卡集群了。”

投入数以万计的 GPU,再通过网络将它们“粘合”起来,导致服务器的带宽接入比以前的服务器大了几十倍,网络设计也需要对应带宽的变化。以往云厂家的主流服务器通常以 100GB 带宽接入,而运营商的接入带宽可能更低。然而,两年前刚推出的 GPU 服务器带宽就达到了 800G 或 1.6T,甚至现在已经达到 3.2T。

大模型的训练和推理使得 GPU 卡之间的数据交换量非常大,因此要求数据中心的网络还要具备强大的处理能力。CPU 时代,通常情况下网络带宽利用率在 30% 到 40% 左右,不会让网络跑满,因为需要应对流量突发情况,比如春节或其他用户高峰情况。而当我们将 GPU 服务器做成一个很大的集群后,不再像以前那样以虚拟化单点运算为主,而是大量 GPU 服务器来共同处理一个任务。那么,对于 GPU 来说,由于当前的 AI 业务模型相对单一,尤其在大规模训练时,带宽利用率需要达到 90% 甚至更高,将带宽尽量撑满,GPU 一直忙着才能让训练效率更高。所以需要在硬件和网络协议各方面做出改变。

这些资源投入、物理设施和相关技术的巨大变化,使得大多数企业无法参与到竞争中来,王亚晨表示,“不是所有厂家都有能力卷大资源模型。”

由此可见,科技界并没有换人掌舵,反而成为云计算老将们的新战场。

集群算力瓶颈:“网络迭代速度没有算力增长速度快”

OpenAI 的 Jared Kaplan 在 2020 年首次提出了 Scaling Law,他指出模型大小和计算之间存在缩放关系。不少追随者认为,加以更多 GPU,投入更多数据,就能得到更好的智能。大量的计算意味着需要更大的计算集群,但实践中大家发现这并不简单。

第一个瓶颈是能耗,建设 10 万卡 GPU 集群大概需要 120 兆瓦甚至更多电力功耗。3.2 万卡曾被视为数据中心 GPU 数量的上限,一个说法是这是因为电网无法跟上 AI 发展带来的能源需求激增。

另外一个瓶颈是行业里运营手段需要提升。当你利用数万张 GPU,连续几十天不停地运行同一个任务时,可靠性和稳定性就成了重中之重。GPU 整个规模上去之后,GPU 故障率是逐渐上升的。

更重要的是,网络通信效率亟待提升。网络丢包、拥塞、时延都会导致集群利用率下降,有数据表明,1% 的丢包,GPU 利用率会下降 50%。所以,就算物理上建起来了一个 4 万、5 万、10 万的集群,但是真正能够带多大规模任务跑起来也需要逐步摸索和提升。怎么能够减少故障率,快速发现故障的同时能够让它快速恢复,让训练中断时间越短越好,这是确保大规模训练任务顺利进行的关键。

之前 Meta 也有过一个统计,在 AI 训练中网络通信时长占比平均占据了 35% 的时间(最高时 57%),一个直观的解释是:这等于花费数百万或数十亿美元购买的 GPU 有 35% 的时间是无所事事的。

AI Infra 现状:一边追求 10 万卡 GPU 集群,一边用网络榨取算力

这些年来,GPU 的迭代速度非常快,算力增长迅速。“网络迭代速度没有算力增长速度快,如何在网络速度相对滞后于 GPU 算力发展的情况下,确保 GPU 性能不降低,或者至少保持较强的发展势头,成为未来云基础设施在组网层面面临的一个重大挑战。”

AI Infra 现状:一边追求 10 万卡 GPU 集群,一边用网络榨取算力

为了能够把集群里 GPU 的性能发挥极致,腾讯这两年在网络里面,网络协议、网络软件、端网协同等各方面做了很多技术创新。

十万卡集群的网络技术壁垒,自研高性能网络

英伟达的网络连接主要有两种,实现卡间互联的 NVLinks,实现服务器间互联的 Infiniband。

InfiniBand 在 AI 训练低延迟网络领域拥有霸主地位,基于英伟达自己的一套协议,配合 GPU 运算特点自成一套体系。

虽然从以太网技术本身来讲,想超过 Infiniband 很难,但 infiniband 体系封闭,成本高昂。

早在两年前,腾讯就着手自研高性能网络。在大模型兴起之前,腾讯在广告场景中通过软件优化进行 AI 训练和推理时发现,以太网的性能可以达到与 Infiniband 相当的水平。

另外,InfiniBand 成本也比以太网技术高很多。在 HPC 和超大规模 AI 云市场中,网络占集群成本的 20% 或更多的情况并不少见。外媒 Nextplatform 根据英伟达的数据算了一笔账,如果你有 10 亿美元,那差不多需要分配 4 亿美元购买 16,000 个 H100 GPU ,还要再花 1 亿美元购买 Nvidia 的 InfiniBand 网络将它们全部连接在一起,剩下的 5 亿美元用于建设数据中心,并在四年内运营、供电和冷却。相比之下,用以太网来建设的成本基本不会超过以上金额的 10%。

“基于这几个因素,我们才敢在大模型出现时,选择以太网,并通过自研的方式来解决网络问题。”

如何用以太网技术解决拥塞问题,尤其是在拥塞时不丢包,这是星脉团队首先要解决的问题。

早期业界没有其他标杆,只能参照英伟达的 Benchmark。以此为基准,腾讯将星脉 1.0 在网络指标上提升至与 Infiniband 相同的水平,并努力做到更优。

Benchmark 里面有几个关键数据,第一个是训练过程中的通信时长占比,7%、8% 是目前业界较为领先的水平。而星脉团队将星脉的通信时长占比做到了 6%,这实际远低于 10% 的业界水平。

另一个很关键的是网络负载率,星脉优化到 90%,与 IB 网络(Infiniband)持平,相较于标准以太网提升 60%。

除了组网技术,更大的壁垒则转向了端网协同能力和运营能力上。这些壁垒,在自研以太网基础上,显然更灵活更容易实现。

星脉本身有一套自研协议。通过高性能通信库 TCCL,星脉能看到网络拓扑,能知道什么路径最短。路径最短,拥塞也会变少,丢包概率也会降低。通过自研端云协同协议 TiTa,星脉可以在网络拥塞的时候,将流量做调度,不会产生丢包,也能让网络负载跑得更均匀。

以前是依靠软件库与网络的配合,星脉进一步的在网卡层面与整个网络形成一个闭环的控制能力,这样可以实现更好的拥塞控制算法。

而快速定位和解决问题的运营能力,也能够在基础设施层面形成另一个非常强的差异化。星脉可以快速感知网络质量,定位因网络问题导致的训练中断等问题,故障时间在整个训练时间中的占比已经降到了一个相对较低的水平。

如今,这一决策被证明是正确的。英伟达最近也推出了自家的以太网解决方案,搭配网卡使用,其思路与腾讯的星脉 2.0 不谋而合。

行业里实际也已经有了不少使用以太网的企业,比如 Meta 的训练 Llama 3 的集群,一半使用的是 Infiniband,一半是以太网,并且他们宣称以太网集群的性能不比 Infiniband 差。

国内腾讯和阿里则都是纯以太网。这些企业也都加入了 Linux 基金会发起的超级以太网联盟 UEC(Ultra Ethernet Consortium),到今年 3 月总共有 55 家公司参与,共同为 AI 发展构建完整的基于以太网的通信堆栈架构。

从星脉 1.0 到星脉 2.0 的进阶:在工程上支持 10 万卡

腾讯最早于 2022 年就开始做星脉研发,当时主要是用于广告大模型训练。这个时间点比 OpenAI 推出 chatGPT 还要早上半年。也正是因为有了技术储备,所以能在初期快速构建起星脉 1.0,并将带宽利用率做到 90%,做到无丢包,保证算力不损失,另外还达到了极低时延的要求。

在这个背景下,星脉 1.0 实现了单个服务器 3.2T 的接入带宽,业界第一次提出多轨道大规模组网,让集群组网规模更大。同时打造了初步的运营系统平台,主要解决了应用系统中的网络上监控和故障修复问题。

星脉 2.0 则希望在工程上实际支持 10 万卡,实现训练推理一体化,进一步去解决推理的成本效率问题。

AI Infra 现状:一边追求 10 万卡 GPU 集群,一边用网络榨取算力

在硬件层面,星脉 2.0 引入了自研交换机、自研光模块、自研网卡三套新的硬件。其中,网络交换芯片由 25.6T 升级到 51.2T, 这样对应的整个组网规模就会翻倍。

另一个重要方面是星脉 2.0 首次在业内采用了自研的 400G 单口硅光芯片。这一创新的最大特点在于显著降低了能耗、模块能耗以及成本。

为了解决 10 万卡集群的性能瓶颈问题,需要实现端和网的协同。因此,除了商业网卡,星脉也首次引入了自研的算力网卡,与自研的软件系统相结合,大幅提升整体性能。

拓扑架构设计层面,星脉 2.0 延续了多轨道设计,并且每个节点的容量都升级了,这样就足够支持到十万卡的集群规模的组网。同时未来也能满足 SORA 这种模型架构需要的在网计算(也叫算力卸载)能力。

在软件层面,TCCL 从路径规划变为了自适应性能加速,并打通了异构并行计算中的卡间互联网络,从而能够将 NVLinks 以及星脉两种网络在同一个任务中用起来:当机内带宽不足时,可以将外部带宽用起来,利用外部带宽弥补内部卡间互联速率的不足,同时也能够感知两种网络拓扑的使用状态,这种方式能让通信性能提升约 30%。

TiTa 在 1.0 阶段,拥塞发生后才会进行调整,而在 2.0 阶段,通过主动干预速度以避免发生拥塞。通过协议和硬件的端到端配合,可以有效地控制传输速率,使得网络从可能会产生拥塞但不会丢包,转变为根本不会产生拥塞的网络。目前来看,这种端网结合也是业界非常重要的发展方向。通过这种方式,能将通信性能再提升 30%,集群训练时长降低 10%。

另外,星脉 2.0 的运营系统也进行了升级,引入了仿真系统的概念。在训练过程中,在 GPU 训练中某个卡出了问题,或运算效率突然变慢,是经常出现的问题。尤其是变慢的这种情况下,服务器是不会没有报故障的,因为节点失速并不是故障。新的运营系统可以通过仿真模拟,再结合实际训练过程中产生的日志进行对比,就能知道到底这次训练中哪些 GPU 它到底是失速了,还是有故障节点了,然后快速找出这些节点,进行干预。在实践中,运营系统的升级能将训练问题定位时长从数小时缩短到 10 分钟内。

如今星脉在整个系统的层面上也形成了自己的独特优势,包括 GPU 拓扑感知能力、网络仿真系统能快速定位慢失速节点的能力。

现在这个技术体系不仅能十万卡集群的真正跑起来,还能做到更精细化运营,整体网络通信效率比上一代提升 60%,让大模型训练效率提升 20%。这意味着,如果原来训练中某个计算结果的同步需要花 100 秒完成,现在只需要 40 秒;原来需要花 50 天训练的模型,只需要花 40 天。

实现“算力供需平衡”的愿景

星脉网络作为底层技术支撑了腾讯混元大模型训练。今年,混元大模型的参数规模更是突破了万亿级别,而企业微信、腾讯会议及腾讯文档等都部署了生成式 AI 功能。过程中遇到各种问题,比如训练中断,星脉网络都能凭借强大的技术和稳定的性能,轻松应对。

现在,基础大模型还在卷,还在发展,GPT5 也将很快发布。各种应用也开始出现,这些都需要大量算力。大家希望未来算力要像电力一样无处不在,但现在算力短缺是整个人工智能行业面临的一道难题。

为应对算力紧缺,OpenAI 今年还出台计划,打算耗资 1150 亿美元,打造星际之门(Stargate)来支持大模型的发展。只是,除了不断扩张数据中心数量和规模之外,我们也应该有足够的技术去“榨取”已有 GPU 资源中的算力。

“我觉得未来算力供需要达到相对变化的平衡,很重要一点是能够提升 GPU 算力调度和利用率来缓解相应压力。我们也在讲算力网络,算力网络本身来讲就想让我们的算力调度能力以及算力利用率能够长的更好。”

“我们一直有一个愿景,希望算力网络能为大家提供服务,让大家‘用得更快,用得更好,用得更稳’。用得更快指的是算力调度、建设交付和供应响应更快,让大家能够第一时间获取所需资源。用得更好则是指性能更佳,体现在 GPU 利用率、网络各种指标和负载率等方面,性能达到最佳。用得更稳是指运营质量高,不出问题,或在出问题时能够快速定位和恢复,让运营更稳定。”

原文链接:AI Infra 现状:一边追求 10 万卡 GPU 集群,一边用网络榨取算力_生成式 AI_Tina_InfoQ精选文章

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/83514.html

(0)

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信