前不久，马斯克旗下的xAI122天建成十万卡集群，也让外界意识到算力集群对AI的重要性。（雷峰网(公众号：雷峰网)雷峰网雷峰网）
之前坊间还流传一句话：服务器集群的规模越大，其训练出来的人工智能表现就越出色。
在这波浪潮之下，全球科技巨头纷纷投入巨资建设高性能AI计算集群，以提升AI算法的效率和能力。谷歌推出了其AI Platform，依托多模态生成式AI模型Gemini，大幅提升了在文本、图像、音频和视频处理上的能力。微软的Azure AI Compute Cluster整合了最新AI技术，为开发者提供了从数据处理到模型训练的全方位支持。（添加微信Who123start，解锁独家科技内幕和行业趣闻）
作为国内最早推出大模型之一的百度，也展现出其强大的创新能力。11月6日，在百度智能云举办的百舸媒体沙龙，深入探讨“十万卡集群”的技术创新、实施过程及其对AI行业的推动作用，并邀请百度杰出系统架构师、百度AI计算部负责人王雁鹏在现场做了分享和交流。
以下是媒体与三位嘉宾在会上的对谈实录，雷峰网在不改变原意的情况下做了编辑和调整：
Q：百舸的客户群是哪些？重点的行业客户是否之前有一些成功案例可以来分享？
A：我们的客户主要分为两类。一类是大模型创企，他们需要万卡规模的计算能力，因而对快速建设和成本控制有较高的需求。这类客户虽然数量较少，但其需求非常明确；
另一类是典型的互联网客户，他们的需求规模通常在千卡到5000卡之间。这些客户包括教育行业的公司。
这些互联网客户的主要需求是利用他们大量的自有数据进行后期训练（Post Train），以适应各种场景和优化，从而构建他们的数据飞轮。目前，这些训练需求依然是我们的主要业务，而推理需求相对较少。这也解释了为什么业界对AI算力落地效果仍存疑虑。预计在今年或明年，算力需求仍将以训练为主，而推理和SFT（小规模微调）的长尾客户将会增多，但总体资源需求仍低于头部客户。
Q：百舸客户的主要需求和痛点是什么？我们是如何解决的？
A：各类客户的需求其实有很多共通之处，我们可以一层层来分析。
1. 基础设施层面：这些客户首先需要一个强大的网络硬件互联架构。企业在尝试自行搭建大规模集群时，常常会遇到网络上的难题。我们的任务是为他们提供更好的网络硬件互联架构，使他们能够成功搭建一个大规模的计算集群。
2. 系统稳定性：没有经验的客户在自行搭建系统时，常会遇到有效训练时间过低的问题。这些稳定性问题是客户面临的第二大难题，我们需要帮助他们提高系统的可靠性和有效训练时间。
3. 加速框架：在提供加速框架方面，我们帮助客户优化并行策略，提升性能。通过更好的框架，我们能显著提升计算速度，解决加速问题。
4. 资源利用率：客户购买大量资源后，需要有效利用这些资源。他们可能既有推理任务又有训练任务，最初可能是为训练任务购买资源，但随后也需要利用这些资源进行推理。我们通过任务混合部署，提升资源利用率，确保资源能够被高效利用。
Q：您刚才花很大篇幅讲跨地域网络问题，能否举例说明实际效果？
A: 跨网络问题主要涉及两个方面：一是当进行十万卡规模的部署时，确实需要跨地域的支持；二是我们云服务的能力。举例来说，我们可以在云上两个机房同时部署计算任务，但客户在使用时完全感知不到差异。例如，即使客户使用的是5000卡的规模，我们在不同地点分配资源，但使用体验依然一致，这是我们的一大优势。
Q：面对不同客户需求，如1000到5000卡的规模，如何确保任务级别的混合调度的效率提升？
A: 混合调度我们已经做了许多工作，实质上是通过混合集群实现不同特征的工作负载的混合。
例如，推理任务有波峰波谷，波峰时使用的资源更多，波谷时使用较少；而训练任务则需要固定数量的计算卡（如1000卡），如果资源不足，比如仅有990卡，任务将无法运行。
为了解决这些问题，我们提供了一个非常灵活的队列机制，将业务视为虚拟队列，并配置优先级策略。这些队列根据实际情况动态调整资源分配，当资源不再需要时，可以被其他队列的任务抢占，从而提高资源利用率。此外，我们的框架能够自动重新分配并行策略。例如，一个需要1000卡的任务，在资源不足时（如仅有900卡），能够调整并行策略以继续运行，从而确保任务的连续性和有效性。
Q： 请详细聊一下Checkpoint环节，大家有不同的策略，可能有些效果更好，有些则影响训练有效时间和成本，我们在这方面是怎么做的？
A： 原来的Checkpoint策略是隔一段时间创建一个Checkpoint，在故障发生后恢复。但是，这种方法的缺点是，如果每小时创建一次Checkpoint，出现故障时通常会浪费一半的时间，即30分钟。因此，我们希望Checkpoint越密集越好，但这也带来新的问题。
最初的Checkpoint策略需要停止训练，将数据写入存储，这会耗费大量时间，因为存储带宽有限。当时停下来写Checkpoint需要几分钟，这显然无法接受，尤其在Checkpoint频繁时。
第一阶段：改进为异步Checkpoint，训练过程不中断，先将数据复制到内存，然后异步写入存储。这样可以缩短Checkpoint时间，从原来的两小时一次缩短到每30分钟一次。但依然存在瓶颈，如存储带宽限制。
第二阶段：引入触发式Checkpoint。在正常情况下不创建Checkpoint，只有在故障发生时才创建。很多GPU故障不会导致数据丢失，可以在故障点恢复数据并存储。这种方法在大多数情况下有效（95%以上），仅在传统Checkpoint保留的情况下无回退和浪费。
正在生成分享图...
nebula