听说，现在已经有人在搞十万卡集群了！
什么概念呢？100000张GPU或者AI加速卡攒在一起，组团干活，提供“核弹级”算力。
这么顶，真有必要吗？必须有，业界大佬都在这么干！
只因AGI太火爆，引发了算力“军备竞赛”，十万卡集群已经成为业界顶尖大模型公司的标配，xAI、Meta、OpenAI都在搞！
即便大家如此激进，算力瓶颈仍然拖了大模型迭代的后腿。
坊间传闻，GPT5迟迟不能发布的原因之一，就是算力不足。
而国内的头部大模型厂商，也都在互相较劲，紧锣密鼓地筹建十万卡集群…
总之，趋势在那里摆着，算力基础设施必须要跟上，“不搞就会落后，落后就要挨揍”！
“十万卡”集群，有多难搞？
首先，你懂的，家里确实要有矿！
一台8卡服务器，十万卡就是12500台服务器，这就是250亿了。
所以，十万卡集群，都是巨头或者拿到巨额投资的公司在搞。
但是，对于国内企业来说，光“家里有矿”还不够，第一道技术坎就把大家卡住了。
这道坎就是：十万卡规模的智算中心，必须要跨地域部署。
为什么要把一个好好的数据中心拆散，让他们跨地域呢？
首先，十万卡集群，是妥妥的超级电老虎，一天的耗电量，高达300万度，相当于北京东城区居民一天的电量。
单一物理数据中心，很难满足这种用电需求。
同时，这样的超标电老虎，会对所在区域的电网造成冲击，超出电网的配电限制。
不止如此，十万张卡，光服务器机房的面积就超过10万平方米。
相当于14个足球场那么大，这还不包括其他数据中心配套设施，不做特殊规划，根本放不下。
所以，能耗和空间的制约，让这种超标集群，不得不跨楼、跨园区部署，考虑到电力供给，甚至要跨城市组网。
大家都知道，在单个物理数据中心操控调度海量算力卡，就已经很难了，要考虑传输性能、稳定性、故障恢复、各种并行策略等等。
一旦跨了地域，难度更是飙升了无数倍↓
比如，受电力、配网、空间等限制，在实际部署中，集群不得不分布在两个相距100KM的数据中心…
但IB和RoCE等无损网络的原始设计，就不是为这样的跨地域、超长距、高延迟场景服务的，它们受不了这种“没苦硬吃”的工作。
以前，在单一数据中心内部，网络链路的设计通常都是按照1:1收敛的，全网无阻塞，所有GPU流量不冲突，满足训练时各种并行策略对带宽和时延的要求。
现在，跨地域部署之后，两个数据中心间互联带宽，充其量也就几百个T，看着不少，摊到每个节点、每块GPU，那就是独木桥。
有效带宽容量差了几十上百倍，调度稍有不慎，就会“塞车”。
这100公里的距离，会带来额外500μs的延迟，相当于数据中心本地网络的100倍（约5μs）。
IB/RoCE的网卡、交换机、重传机制、拥塞控制机制都是按照10μs级别时延来设计的，面对500μs这种超纲问题，结果完全不可控。
而且，模型并行算法，在常规设计中也只考虑了网络低时延、带宽最大化的场景，这种长距的高延迟甚至都超过了一次矩阵计算的时间。
距离产生美，也产生了麻烦。
很难想象吧，这点距离，几乎成了国内十万卡集群无法跨越的鸿沟，简直Mission Impossible了。
跨地域“十万卡”，有人搞定了
真的要一别两宽吗？不！
最新消息，百度百舸团队给出了自己的解决方案，让跨地域构建“十万卡集群”成为可能。
百度百舸具体是怎么干的呢？
一、先夯实基本功，把本地万卡+集群玩到飞起，储备跨地域组网能力。
❶网络性能升级
本地大规模集群都搞不好的话，想搞跨地域那就是空谈，百度智能云在原有万卡集群网络的基础上，对自研网络交换机进行升级。
升级后，整张高性能网络具备了更为智能的动态负载均衡能力，彻底消除哈希冲突和网络拥塞。
即便面对十万卡产生的海量数据冲击，也可以轻松应对，提供无阻塞、低延迟转发。
❷平滑可扩展的架构设计
十万卡并非一蹴而就，即便本地数据中心五万张卡，那也可能是从千卡、万卡、两万卡…逐步升级起来的。
百度高性能网络在架构设计上，支持Pod级别的按需平滑扩容，建好的部分，可以立即投入使用，建一批投产一批，工期时间短，扩容无压力。
❸提升整体稳定性
十万卡集群相比万卡集群，在设备故障率不变的情况下，训练任务故障率会极速增长，这将给系统稳定性带来极大挑战。
百度百舸4.0内置了一套自动化容错机制，致力于训练任务永不中断。
比如，单网卡故障，任务会流量切换到同机网卡继续传输数据，网络故障修复后，任务自动回切。
比如，单节点故障，该节点全部数据可通过内存和网络导入到备用机器中继续训练任务。
同时，针对无法自动化恢复的错误，百舸4.0提供了更加快速的「感知－定位－重启－恢复」服务。
怎么个快法？
首先，百度自研的集合通信库BCCL，内置了错误感知的专用观察方法和故障定位的专用能力，将错误感知从传统的10+分钟缩短到秒级，并且秒级锁定故障节点。
故障定位后，接下来就是快速任务重启和断点恢复，百度百舸平台提供分级恢复策略，根据任务类型，用最省事、最快的方法恢复任务。
接下来，还记得我们前面说的“Graph重建”吗？
重启的任务直接通过RDMA从重建节点的内容中获取Checkpoint，原地继续下一步的计算，重启时间从过去10+分钟缩短到分钟级。
这么说吧，百度百舸通过上述这一系列操作（性能提速、可扩展架构、稳定性设计），不仅提升了万卡级集群的能力，也为挑战十万卡集群打好了底子。
接下来，就是十万卡的大场面了↓
二、集中火力，攻克跨地域集群难点。
❶物理设施层“加班整活”
RDMA网络对丢包和拥塞是“零容忍”的，但是，从数据中心内部可以肆意狂奔的“阳关道”，到数据中心之间路窄车多的“独木桥”，堵车在所难免。
为此，百度百舸团队专门设计了一套无拥塞网络机制，借助流量工程的思路进行流量调度。
简单讲，就是在数据中心互联出口部署自研的流量控制器，根据训练任务的模型特征，将需要跨地域的训练任务流量均匀地调度到出口链路上，避免拥塞。
长距离的高延时问题，会让传统的拥塞控制不灵。
针对这种“基因型BUG”，百度百舸的方案是通过自研交换机代答，来缩短端侧感知拥塞的响应时间，降低高延时的负面影响。
❷集合通信链路层“持续优化”
百度自研的集合通信库BCCL，可以根据不同的网络时延场景，动态调整Buffer大小。
比如跨区域高时延场景，增加Buffer大小，在不产生拥塞的同时将链路打满，让网络吞吐量发挥到极致。
同时，在模型训练中，要让所有的GPU工作量都饱和，没人闲着摸鱼，效率才能最大化。
这依赖于网络传输和GPU之间的默契配合，它们就像流水线工人一样丝滑默契。
但是跨域集群的高时延，会让原来GPU和网络之间的那种默契配合被打乱节奏，导致GPU闲置摸鱼，训练效率下降。
百度集合通信库BCCL通过优化Channel算力排布，在借助大Buffer将网络能力打满的基础上，成功让GPU满负荷运转，高效率的流水线又开起来了。
在这里，BCCL对算力的排布优化主要包括两个层面↓
第一是增加Channel数量，提升GPU中参与通信的SM资源量，并在一条链路上实现多Channel并发传输，让集合通信性能跑满。
第二是优化Channel结构，根据底层链路特征（时延、带宽），进行合理分组，尽量避免或者减少使用性能差异大的链路做强同步通信。
vs
❸计算框架层“卷到极致”
在GPU计算时代，即便是单一数据中心内部，整个端到端链路也存在不同能力的连接方式，比如NVLink、PCIe、RDMA网络等等，各自的带宽和延迟差异明显。
如今，再跨地域，又额外增加了长距离RDMA这种差异化链路。
因此，必须要根据网络拓扑制定更为合适的并行策略，让计算和网络进一步深度融合，才能让计算效率最大化。
百度百舸的计算框架层能够比较不同流量类型对各种链路的容忍度，然后对训练任务作出并行策略调整，从而卷出了最优的集合通信性能来承载最佳模型训练性能。
❹长距传输“无损保护倒换”
跨区的传输线路相比数据中心内部脆弱了许多，比如城市施工挖断了光纤。
一条光纤被挖断，就可能影响几十个400G端口（每条光纤可承载数十T带宽）。
传统高可用保护方案会导致大量机器的50ms丢包，从而造成训练进度受损，非常影响客户体验。
为此，百度百舸团队设计了传输无损保护倒换方案，通过线路侧双活、支路侧缓存并行检测的手段，实现无损倒换，数据不丢失、不重传，训练业务0中断。
好了，十万卡集群因为距离产生的难关，都被百度百舸逐一搞定了，距离不再是问题。
那么这就万事俱备了吗？不！还差好几万张卡呢。
国内的情况你懂的，成套的一万张卡都很难凑齐，更不用说十万张卡。
怎么办呢，只能一云多芯，最终组成多芯混合的十万卡集群。
本来跨区域就够难了，再加上混合多芯，真是难上加难。
但你大可放心，“多芯”难题，百度百舸早就搞定了，上一期我们就介绍过，传送门在这里：《不是GPU买不起，而是多芯混合更有性价比》。
还有如何搭建多芯混合集群动画，大家可以一起复习
百度预判了趋势，早早为⼗万卡集群做好了一切准备：距离不是问题、多芯混合不是问题，稳定性持续加码…
实测数据显示，在百度百舸4.0的加持之下，100KM以内跨地域范围内训练性能单⼀训练任务，性能折损低于4%，混合多芯集群相对单芯集群，训练效能损耗低于5%！
热门跟贴