从「建好」到「用好」，企业级智算平台借助专有云 ABC Stack 的 GPU 提效服务，应对大模型业务挑战，唤醒 AI 算力，加速 AI 原生业务的落地。

　　当企业的私有化智算平台项目上线一段时间后，用户普遍会反馈 GPU 效能相关的问题：

　　将全部资源分配给各个业务部门后，集群全部 GPU 资源的平均利用率在 30% 左右。这个指标处于什么水Kaiyun平台官方平，是否充分发挥 GPU 效能？

　　大模型训练的时候，我们会请技术专家排查 GPU 集群故障问题，有时居然要 2~3 个小时才能搞定，这个时间这么长，还能缩短吗？

　　新平台按照最高的硬件进行配置，但是常有业务线反馈，相比过去的老集群，智算平台上的任务速度并没有明显提升，这是为什么呢？

　　先说结论。根据对不同的企业级智算平台类项目实践的总结：在平台落地后就处于 GPU 更优效能的状态，这是几乎不可能的。

　　这些问题的出现和解决，正好体现了企业级智算平台和客户大模型业务落地磨合的过程。

　　这些问题的原因，有一部分来自于智算平台从无到有，再到大规模 AI 业务落地过程中，智算平台管理部门在不同阶段，关注的目标和业务运行环境的变化所致：

　　在 POC 阶段，通常是用若干个典型任务做功能、性能和稳定性测试。这些测试可以提前规划，可控性更大。整个过程关注的是平台自身能力的评估。

　　在大规模生产落地阶段平台开始承载所有部门的业务，需要考量的维度更加复杂，比如资源如何分配满足不同业务需要，平台如何正确使用确保业务能够高效运行等。

　　另外一部分原因，可能占更大比例，则是因为企业级客户，在过去已经习惯「小模型」和「老平台」后，面对「新平台」运行「大模型」中，需要有一段学习和适应的时间。

　　基于百度在大规模集群的技术积累和工程实践，在向企业交付智算平台后，专有云 ABC Stack 还为客户提供了一套面向整体 GPU 算力平均利用率、训推任务加速和稳定性等场景的 GPU 提效服务。

　　每个业务部门都期望能够获得/储备更多的 GPU 资源加速自己的 AI 任务速度，也可以免去申请更多资源的时间。不过，智算平台管理部门的目标稍有不同，会更多聚焦于在全局资源有限的情况下，能够实时按需分配资源，覆盖全部业务，使得资源利用效率最大化。

　　为了在「各个部门的业务效率」和「集团整体资源利用率」之间达到平衡，智算平台管理部门需要深入分析不同部门的业务模型，统计过往的任务类型和 GPU 资源使用量等情况，以便找到合适的资源分配策略。

　　比如，将过去统一把全部资源分发给业务部门的模式，变成把其中一部分资源作为保底资源分发给业务部门，剩余资源作为所有部门的共享按需调度的模式。其中，本周期内各个部门的保底资源额度，可以按照「上一个周期的统计数据」进行预测，适当进行缩减或者扩大。当通过监控数据发现资源总量不足时，及时进行扩容。

　　传统车企 A 的自动驾驶平台，将智算平台的全部 GPU 资源固定划分给车辆视觉、雷达感知、数据处理、BEV 等 9 类业务。全部业务上线 个月后，整体 GPU 平均利用率在 30% 附近波动。

　　为探索 GPU 利用率是否有提升空间，车企 A 联合专有云 ABC Stack 共同对各个业务在过去 2 个月的使用情况进行了详尽的调研，发现全部的节点中：

　　20% 节点的 GPU 利用率长期不足 1%，这说明这些 GPU 资源几乎被浪费了；

　　20% 节点的 GPU 利用率较高，且多次超过 80%。这说明在未来这些资源有一定的超负荷风险；

　　另有 30% 的节点的 GPU 利用率大幅波动。这说明这些 GPU 存在一定的弹性调度空间。

　　因此，智算平台管理部门将预设的「整体资源按业务部门固定分配」管理方式，调整为「整体资源按调度方式灵活分配：保底 + 共享」的管理方式。

　　针对各个业务设置保底 GPU 资源，然后将未划分的 GPU 算力纳入集团公共资源池中，供各个业务方按需调用。同时，为了能够更好地管理资源，适应业务变化，车企 A 成立了 GPU 资源管理专委会，每两周对资源使用情况进行汇总分析，动态调整保底 GPU 资源，监控整体 GPU 资源水位。

　　通过以上资源管理措施的调整，车企 A 的 GPU 整体平均利用率从 30% 提升到了 45%。

　　在小规模 GPU 场景下，通常只需要关注硬件异常引发的任务中断，快速替换故障节点并重新拉起训练任务进行故障恢复，就能解决大部分的问题。在千卡的大模型场景中，有很多问题并不会直接反映出硬件异常，例如训练进程 hang 死、训练降速、loss 跑飞（loss 值为 NaN/Inf）等等，这类问题可能跟用户代码、训练框架、硬件故障、操作系统、网络、存储都有关系。

　　我们需要更系统的方法，来实现感知异常、诊断定位及故障恢复。通过对训练进程、节点状态、网络流量和计算负载等多维度数据的监控与分析，快速识别异常行为，然后进行自动恢复，最终生成详细的故障报告，缩短「感知–定位–重启–恢复」整个流程时间，提升有效训练时长。

　　互联网企业 Z 经历了从小模型升级到大模型业务的转变。在小模型场景已经积累了足够的专家经验处理各类故障问题。在切换至大模型场景后，没有第一时间进行平台稳定性的建设，在故障感知、定位和恢复中投入了大量的人力成本，造成了资源的严重浪费。

　　借助百度百舸平台的稳定性&容错能力， 互联网企业 Z 在大模型训练任务中实现了显性故障和隐形故障的及时感知、精准定Kaiyun平台官方位、故障隔离和自动恢复，平均故障恢复时间从 3 小时缩短到 20 分钟，任务有效训练时长大幅提升，确保了大规模训练任务的持续稳定运行。

　　大模型训练任务的效率，不仅仅和集群中 GPU 的性能和数量相关，还需要将计算、网络、存储各类资源进行合理配置，使得他们能够将任务各个环节进行无缝衔接，充分发挥整个平台的能力。

　　一个完整的业务流程，从数据采集开始，再到将预处理好的数据送入 GPU 进行训练，经过多轮迭代后，将最终结果写入存储完成训练。整个业务流程步骤非常多，每个环节的提速都能缩短大模型训练任务的时间。

　　尤其各类面向大规模 GPU 集群的全新高性能组件（并行文件存储 PFS、RDMA、模型训推加速库等）的引入，对于习惯了小模型业务场景，刚接触大模型和 GPU 集群的企业用户来说，如何才能用好这些能力加速模型任务呢？

　　为了全面地提升任务运行效率，需要对大模型训练过程中的各个环节进行梳理，给出理想的系统配置和关键指标，然后与智算平台的硬件配置和期望指标对比，以便找到潜在的优化点。

　　传统能源企业 H 使用并行文件存储 PFS 提速从对象存储 BOS 到 GPU 的数据加载流程。运行一段时间后，业务部门发现模型训练速度虽有提升，但似乎离预期还有不小距离。

　　专有云 ABC Stack 对客户的整个数据流转过程和相应配置参数进行了梳理和分析，发现客户将 PFS 的工作模式设置为「仅加载元数据」，即仅将对象存储 BOS 的元数据进行了加速，导致在任务中未能充分发挥 PFS 的性能。

　　传统能源企业 H 的业务团队在将 PFS 的工作模式从「仅加载元数据」修改为「加载完整数据」后，任务训练速度提升了近 40 倍。

　　互金企业 Y 将多机多卡的 AI 模型训练任务部署至拥有 RDMA 网卡的新 GPU 集群进行训练。但经过一段时间，发现新集群的训练速度，与未配置 RDMA 的老平台相比，并没有预期成比例提升。

　　专有云 ABC Stack 与客户深入沟通后发现，性能未达预期的原因在于 RDMA 未被正确配置。互金企业 Y 此前主要运行小模型训练任务，并不需要使用 RDMA。所以在大规模 GPU 集群的使用过程中，直接将老平台的使用经验复制过来，没有将 NCCL 中 RDMA 相关的环境变量配置到容器中。

　　互金企业 Y 在使能了 RDMA 网卡节点后，数据加载性能和 GPU 多卡训练性能明显提升，任务训练效率对比提高约 2 倍。

　　在自动驾驶业务场景中，会经历「模型选型 - 模型训练 - 模型上车」等几个步骤，研发团队需要在不同模型中做实验选出最合适的模型，并完成模型训练，最后部署在量产车上。所以模型训练的速度越快，量产车获得最新 AI 能力的速度就越快，客户的体验就越好。

　　在与专有云 ABC Stack 的交流中，传统车企 C 了解到百度百舸的模型算法团队针对各类主流的自动驾驶模型都进行了极致优化，相比开源版本性能有大幅度提升，均已在 AI 加速套件 AIAK 中上线。

　　车企 C 的智算平台升级了最新的 AIAK 加速库，使得工程团队可以从 AIAK 中直接调用经过优化的模型，吞吐量最高提升 400% ，缩短 80% 的训练时间。

　　当然，不止于上文提到的方法，GPU 效能的提高涉及到方方面面，比如合理划分故障域、为新的 AI 加速芯片开发监控指标、部署合适的任务资源调度策略、编写适用于大模型平台的管理手册等。

　　从「过去几块 GPU 跑小模型，业务逐步智能化」到「现在 GPU 集群跑大模型，业务全面智能化」业务场景的转变，这给企业的智算平台高效能运行带来了挑战。同时，由于 AI 原生应用、大模型、基础设施平台等相关技术正在快速演进，AI 算力提效将是一个长期存在的课题。

　　凭借着百度百舸 4.0 在大模型基础设施方向的领先技术，以及在不同企业级智算平台项目中积累的丰富经验，专有云 ABC Stack 将帮助企业成功应对最新的大模型业务挑战，「建好」和「用好」智算平台，加速 AI 原生业务的落地。