今天的分享是百度智能云在 23 年夏季推出的「云智公开课 --- AI 大底座系列」第 8 期，也是本次活动的最后一期。前面 7 期的内容，我的同事对大模型场景涉及到的各个模块，从网络、计算、存储、向量数据库、AI 框架、LMOps 等维度，为大家做了一个全景的展示，分享了百度智能云在这些领域的技术积累和项目实践。
本次我的分享主题在技术上算是对前面内容的综合，将围绕百舸在大模型训练过程的稳定性设计和加速实践展开，包括以下 3 个部分：
- 大模型时代的**百舸异构**计算平台；
- 大模型训练稳定性实践；
- 大模型训推加速实践。
1. 大模型时代的百舸异构计算平台
下图列举了众多国产大模型，里面有通用的大模型，也有面向行业的垂类大模型，「百模大战」可见一斑。
为什么会在短期内出现这么多的大模型呢？这和大模型新的训练范式以及开源模型生态快速发展有极大关系。我列举了三种大模型的训练方式，从上往下看，成本由低到高变化。
首先是高效参数调优，也就是基于一个已有的通用大模型，使用少量有标注的数据，调整部分模型参数，得到符合面向特定场景的模型，具体的细分方法包括 Prefix-tuning，Prompt-tuning，LoRA 等。在第 7 期的公开课中已经给大家做了较为详细的介绍。
其次是 SFT 指令微调，也就是使用少量或者中量的有标注数据，对通用大模型做全量参数的调整。由于市面上有比较多的像 Llama、GLM 等优秀的开源大模型以及像百度文心系列商业大模型，所以很多客户会选择这种方案来构建自己的行业大模型。
另外一种就是从零到一的预训练，基于大量无标注数据来训练自己的通用大模型，像 GPT-4，Llama 等。当然对于一些公司来说，严格意义上也不算从零到一，一方面有比较多的论文可以参考模型结构，另一方面也可以基于已有的开源模型权重做 Post-pretrain。
无论是哪种训练模式都需要健壮可靠的异构计算基础设施。
大模型对异构计算基础设施的新挑战，主要在稳定，高效和敏捷等三个方面。
稳定性是大模型训练自带约束。基于一些公开数据，像 GPT-4 这类千亿级别的大模型需要数万张 GPU 并行训练，当然还有配套的分布式存储和高速网络，这么复杂的系统可以平稳运行本身就是一个挑战，同时如何在故障发生时能快速精准定位，可以更快速的恢复，都是需要解决的核心问题。
同时，因为大模型训练要消耗极大的算力资源，所以每一分效率的提升都会带来真金白银的回报，包括如何进行并行计算，如何更好利用显存，如何提升节点间的通信能力，这也是大模型基础设施需要考虑的问题。
大模型参数多计算量大，听起来似乎和敏捷并没有太大关联，但是基于刚才介绍的大模型训练新范式，一方面模型本身的设计成本更低，另外一方面整个行业都在高速迭代中，所以需要基础设施具备快速构建能力，同时有比较低的学习成本，可以快速和开源生态对接，利用开源生态已有的能力。
针对大模型的这些挑战，此次专门为大家来分享一下百度智能云的 AI 基础设施平台------百舸平台的最新进展和实践。
百舸平台是百度智能云面向 AI 计算提供的基础设施产品，已经迭代了多个版本，最早是面向生命科学、自动驾驶和智算中心场景提供的 AI 基础设施解决方案。
之前百舸平台的架构介绍，我们更多的是从解决方案的视角进行展示，包括 AI 计算、AI 存储、AI 加速、AI 容器等 4 个核心组件。这次我们从产品视角来看下，从下向上百舸分为基础设施、云原生 AI 套件，配套服务和控制面 4 层：
- 基础设施包括了高性能计算节点，可以支持英伟达 A800、H800 这类高性能 GPU，同时也支持百度自有的昆仑芯片。存储方面提供对象存储 BOS、并行文件存储 PFS，同时也提供了本地的 NVME SSD，支持模型调试、训练、推理等全场景存储需求。存储在大模型场景的加速方案，我们在本次云智公开课的第 3 期给大家做了比较全面的介绍。高性能网络方面我们提供了高性能的 RDMA 网络、支撑业务高速访问和隔离的 VPC 网络，这部分在我们的第 1 期也给大家做了详细介绍。
- 云原生 AI 套件，基于 K8s 内核提供了面向 AI 场景多方面的能力，其中 AI 基础组件提供了高速网络、存储的插件支持，以及异构调度、拓扑感知能力等。AI 编排调度模块支持 Pytorch、PaddlePaddle 等丰富的 AI 训练框架，同时提供了 AI 任务编排和工作流管理。稳定性&容错模块提供了丰富的故障感知和容错能力。训练&推理加速模块 AIAK 针对大模型场景提供了训推加速能力，也就是 AI 加速套件，后面会展开介绍。
- 同时为了让 AI 任务顺利执行，百舸融合了 Prometheus 监控，镜像、日志、账号等配套服务产品。
- 同时在控制面提供了控制台、OpenAPI、SDK 和命令行工具，便于用户使用和与自有的 AI 平台集成。
面向万卡级别的超大规模训练，需要有比较多的前置工作来构建集群，里面包括了规划选型、计算、网络、存储的配置，运行库、框架、云原生组件的配置，还有监控告警和用户权限配置，为了达到集群效率最优，每一步都需要有比较细节的配置和考量。
基于以往的经验，一个真正生产级别的万卡集群需要专业的基础架构同学数天甚至数周来完成搭建和调试。
这个效率显然无法满足大模型的快速发展需求，很多算法工程师对于底层硬件、 K8s 等概念并不了解，而且也无需了解，所以我们把百舸平台进行了升级，屏蔽了无需用户关注的底层概念，打通产品间的安装配置流程，可以一站式小时级完成大模型的基础平台构建，大幅地解放了生产力。
开源大模型的发展，为大模型开发提供了更多的软件基础设施，例如 Hugging Face，提供了大量的开源数据集，预训练模型等资源，在实际模型开发过程中，有比较多的工程性问题。
百舸平台为客户提供了丰富的开源加速工具，例如 EleutherAI 是一个开源的语言模型数据集，大概有 800G+ 数据量，通常需要几十小时的下载时间。我们提供的数据集下载加速功能，采用了专门的下载通道可以将这个过程缩短到分钟级，同时提供数据的预处理和数据转储功能，帮助用户投递到并行文件存储 PFS 等高速存储来进一步加速计算。
我们知道一个模型包括模型结构代码和模型权重参数两部分，通常情况下开源模型的权重参数会开放出来，但是模型结构代码没有直接开放或者训练效果不理想，给前面提到的 Post-pretrain 和 SFT 带来了一定的不便。
基于这个需求，我们参考开源论文对这部分代码进行了重写和并行切分优化并保证精度对齐，同时也提供了最佳实践文档帮助大家更快地开始模型训练。
针对训练出来的模型我们也提供了一键部署工具和 Playground 帮助大家更好的调试模型。
这里展示了在用户提交作业时，我们预置的一系列的开源大模型训练模板，支持了像 Llama、GLM 等主流开源大模型，这个列表将会持续更新，目前已经支持了最新的 Llama 2 模型。
根据用户的选择，可以自动适配对应模型的结构代码、调优后的训练超参、并行策略、环境变量和推荐资源配置。用户可以自行下载或者通过平台提供的工具来加速下载模型权重文件，并且进行模型权重转换和切分。
2. 大模型训练稳定性实践
稳定性是一个系统工程，我们衡量一个系统稳定性能力通常用四个指标：
- 平均故障时间 MTBF 要求我们有较为丰富的检测工具和巡检机制，同时在系统交付的同时就可以保障基础设施的健壮性；
- MTTD 和 MTTI 指的是我们的故障感知能力，一个是发现故障的时间，一个是确定故障定位的时间，要求我们在第一时间能感知到问题，并且能确定问题根因并找到解法；
- MTTR 指的是修复时间，我们一般来说预防、检查胜于治疗，其实前面两个能力建设好以后故障的修复基本是水到渠成，当然也要处理好故障隔离修复和重调度等一系列问题。
由于大模型训练是一种大规模离线型计算，所以实际上这些稳定性指标最终支撑的还是训练成本，所以稳定性建设的一个隐含约束就是训练的性能和成本不能显著衰退，不然就会舍本逐末。
基于上述的考虑，百舸平台在环境检测，故障感知和容错等三个层面做了很多优化。
在环境检查方面，百舸支持了单机硬件、软件和加速库、网络性能、系统组件等多个维度的检查，很多的训练任务都可以通过这些检查来提前预防。在进行环境交付时，任务启动前都提供了相应的检测能力，同时也提供了自动巡检和自助诊断工具。
故障感知层，我们针对任务退出，任务假死和运行慢几种常见故障场景建设感知能力。尤其是后两种故障，有比较大的隐蔽性。百舸平台基于百度内部大量的最佳实践制定了指标体系，可以及时的发现问题，同时我们也提供了多个维度的资源状态大盘和日志管理和优化机制。故障智能分析可以基于故障报错信息给予初步的分析和排障建议。
容错是做好稳定性建设的最后一道关。百舸平台提供了自动容错能力，可以自动实现故障隔离，重调度和任务拉起，同时提供故障节点热修复或者换机修复等方式。CKPT 是模型训练最基础的容错机制，我们提供了 CKPT 的管理以及 CKPT 的写入加速，这部分稍后会展开介绍。
下面我们一起来看一下百舸平台上的几个稳定性核心能力。
首先是 NCCL 测试工具，NCCL tests 是一个检测节点间通信性能的测试工具，用户可以选择需要测试的通信类型、GPU 数量和目标资源池展开测试。我们可以通过和基准性能指标做比对，发现大多数的硬件故障带来的通信问题，并通过二分查找法定位故障点。
智能故障分析是我们结合大模型能力做的一次尝试。很多时候系统的报错信息易读性比较差，一般需要专业的同学来参考多方面的信息定位排查。百舸平台引入了大模型能力、LongChain 机制和向量数据库，可以基于集群的配置信息、监控信息，报错日志以及长时间积累的排查经验来帮助用户对典型的故障进行分析。这个功能目前还在内测阶段，已具备基于常见的日志和报错信息来判断故障的可能原因，给出进一步排查思路。如果已有匹配的 FAQ 也可以直接给出修复建议，更多的能力还在持续建设中。
在任务容错场景，我们提供了较为方便的使用方式。在提交训练任务时，我们可以选择开启容错训练，并配置自动重启次数。当训练任务故障时，我们会根据配置首先尝试本地重启，并在多次尝试失败后隔离故障节点，将任务调度到健康的节点上重新启动，同时拉取最近的 CKPT 继续未完成的训练。
除了自动的容错，我们也支持让用户手动来决策故障处理方案。在任务提交时，用户可以配置任务状态告警，侦测任务的状态变化，发送给对应的告警人。除了任务状态，我们也提供了针对任务的 loss 值的监控和告警，避免因模型结构、数据、超参数等配置错误导致的训练空跑。
在第 3 期的分享中为大家介绍了 CKPT 的存储加速相关原理，这里我们先快速回顾一下：
Checkpoint 是训练容错恢复的基础，多数训练框架均提供了原生的 CKPT 机制。原理也比较简单，在模型训练过程中为正在训练的模型打一个 checkpoint，也就是将显存里面的模型权重数据写到远端存储，这样在故障发生时可以回退到当时的训练状态，避免重训。
由于写 CKPT 和训练计算不能并行开展，且经过了显存到内存、内存到本地磁盘再到对象存储 BOS 多个写入路径，每次写 CKPT 的开销都比较大，导致大家会谨慎控制 CKPT 的频率，这就导致故障重启时往往会回退比较多的时间。这是我们最左边第一张图想表达的内容。
数据湖存储加速 RapidFS 可以利用本地内存和磁盘作为对象存储 BOS 的缓存层，这样 CKPT 的写入和对象存储 BOS 的上传可以异步操作。这样针对大模型训练可以实现分钟级 CKPT，有效地缩短训练任务的等待时间，让用户敢于使用 CKPT 机制。在一些大模型训练中，通常每小时会打一个 CKPT，这样算下来，仍然有10%左右的训练时间浪费。这就是我们中间第二张图表达的内容。
那么还有没有更好的办法呢？
大模型训练是一种离线计算，对故障和训练结果的丢失有一定容忍度，所以我们有了一个更为激进的策略，一方面训练框架直接把内存当成持久化存储，CKPT 写入内存成功后马上继续训练。另一方面，我们改进了之前 CKPT 单点写入的机制，让每个节点都可以分布式写入远端存储。最后，为了优化远端存储的效率，采用并行文件存储 PFS 可以进一步加速内存数据的落盘。通过这种机制，我们可以做到秒级 CKPT，最大程度上降低了容错带来的计算时间浪费。
3. 大模型训推加速实践
首先介绍一下 AIAK。AIAK 是百度智能云面向 AI 计算推出的 AI 加速套件，和百舸平台深度融合，可以有效的提升模型训练效率和推理效率。AIAK 在之前的版本中就提供了梯度通信 Hook、分布式通信策略优化、高性能通信库等训练优化工具以及多框架多引擎加速，高性能算子库等推理加速能力。当然，这些能力在大模型场景下会不同程度上的复用。
面向大模型场景，我们提供了更多新的工具，主要是面向典型开源大模型的训练和推理的加速镜像以及配套的工具。接下来我展开介绍一下。
首先是模型训练加速，我们衡量一个模型训练的性能指标主要是训练吞吐，也就是每秒可以处理的 token 数量。这个指标受三个因素影响，分别为单卡训练吞吐、 GPU 卡数和多卡训练加速比。由于目前主流训练框架对多卡训练支持都比较好，同时 GPU 卡数是一个自变量，所以我们重点讨论单卡训练吞吐和多卡加速比。
理想情况下 GPU 单卡的所有计算单元 100% 的时间片都要计算，同时在扩展 GPU 数量时可以获得 100% 线性加速效果。但在大模型的实际训练过程中，多种模型并行策略会带来较多的时间「气泡」，也就是并行训练中部分计算单元的空等，同时节点的通信机制和物理链路的限制也会影响线性加速能力。
我们可以从硬件和软件两个层面来做优化，硬件优化包括了高性能异构芯片、高性能存储系统，以及和机内机间的高速网络。在软件层面我们通过算子融合、模型并行策略的调整和合理的调整重计算机制，优化单卡计算效率。这里其实有一个隐含约束，所有的优化都要考虑计算精度不退化同时超大的模型参数不会撑爆宝贵的显存资源，另外我们也通过优化并行通信和链路开销进一步提升多卡线性加速能力。
Megatron 是很多开发人员都在用的大模型并行训练框架，具有良好的性能优化基础。我们针对 Megatron 做了很多大多数模型优化工作。在产品上，AIAK Training 提供了大模型加速镜像，在 Megatron 框架上重构了开源模型的训练代码，加入了前面提到过的加速策略。我们做了全面的测试，保障可以和开源模型精度对齐，快速展开训练。
为了兼容其他的训练框架，我们也提供了模型转换和切分工具，一方面可以使用我们的加速镜像来对其他框架的基础模型做再训练或 SFT，同时也可以通过这些工具来实现多机训练的权重拆分。
从实测效果来看，使用 AIAK-Training 可以提升开源大模型 20% 左右的训练效果，尤其是针对大参数量的模型，性能优化效果更好。
大模型推理一般情况下是在线服务，除了要优化性能外也要考虑用户体验，所以我们优化推理性能的目标可以概括为在保障首 token 延迟可控的基础上做到吞吐最大化。
我们知道，GPU 是可以并行处理推理请求的。通过批量地执行推理任务，可以有效提升 GPU 吞吐。在大模型场景下有个特殊的挑战就是输出不定长的问题，也就是我们问模型一句话，得到的答案长度是不确定的，同时请求处理时间从小模型的几十毫秒变为秒级别，这使得我们之前很多的优化策略失效或者低效。
从单卡的视角来看，并行执行的一组推理请求需要处理完成后才会返回。由于输出是不定长的，导致一些短输出的请求出现空等状态，据统计至少浪费 30% 的算力。另外，由于推理请求是顺序到达的，后续的请求也要等到前一组请求完成后才能进入队列，也增加了单位请求的排队时间和响应时间。
从整个集群的视角，通常推理的 API 网关会轮询地向每个节点分发请求，同样因为每个请求的处理时长不一致，容易导致出现节点间的负载不均。
针对这些问题，我们引入了动态 batch 的机制。
首先，把上下文处理过程和内容生成环节拆分开，不再统一调度。其次，通过动态槽位控制机制重新组合这些计算请求，尽量填满计算单元的时间片。同时也将多个流之间的调度方式拆散，每个流都可以独立的动态组装计算任务。
由于这种动态机制和模型结构有比较大的关联，我们对一些主流的大模型都进行了适配，经过实测，模型吞吐和平均请求延迟都有 40% 以上的提升。
针对节点间负载不均的问题，我们引入了分布式队列和 pull 模型。所有业务侧的请求先入队列，每个推理实例基于自己的真实负载拉取请求，处理失败的请求可以重入队列重新处理，保障输出结果。
通过这种方式，可以有效地避免产生热点实例并降低请求的排队时间，这个方案在百度内部已经规模化落地，可以提升一倍以上的推理吞吐。
在产品上，百舸平台提供了大模型推理加速镜像，集成了一系列的推理加速机制，支持主流的开源模型，同时内置了 Triton 高效推理引擎，支持 KerverV2 版本的协议兼容，可以更好的和生态打通。
百舸平台提供了大模型的部署工具，包括了完整的异步推理服务和模型权重转换工具，让推理更加高效。还提供了一些模型调试工具，帮助用户快速体验加速效果。右面是我们的一些实测数据，在保障首 token 延迟可控的前提下，使用 AIAK-Inference 的推理加速方案，主流大模型的吞吐均可提升 1-2 倍，大幅降低了推理成本。
后续我们将继续把百度内部的模型训推加速能力和成本优化能力产品化，希望大家持续关注。
以上就是今天分享的全部内容。