大模型训练稳定性思考和实践

本文涉及的产品
轻量应用服务器 2vCPU 4GiB,适用于搭建Web应用/小程序
轻量应用服务器 2vCPU 4GiB,适用于搭建容器环境
轻量应用服务器 2vCPU 4GiB,适用于网站搭建
简介: 本次分享由阿里云智能集团高级技术专家张彭城主讲,聚焦大模型训练的稳定性问题。主要内容分为三部分:1) 大模型训练稳定性的关键挑战,包括大规模同步任务中的故障率高和恢复成本大;2) 阿里云大模型训练稳定性系统的介绍,涵盖健康检测、实时可观测系统及自愈系统;3) 实践分享,探讨集群网络故障定位与修复、性能优化等实际问题的解决方案。通过这些措施,确保大模型训练的高效与稳定。

本次分享的主题是大模型训练稳定性思考和实践,由阿里云智能集团高级技术专家张彭城分享。

 

本次分享关于稳定性话题,稳定性是一个原始问题,对于大模型训练,稳定性是一个非常关键的基础,没有这个基础,各种的性能优化调度是没有任何意义的


本次分享主要有三个部分第一个部分是大模型训练稳定性关键挑战,第二个部分是阿里云大模型训练稳定性系统介绍,三个部分是大模型系统稳定性关键问题实践分享。

 

一、大模型训练稳定性关键挑战

第一个挑战是首先模型训练一般在万卡以上,这个万卡情况下的训练任务又具有同步性特点,所以一个节点挂会导致整个任务部挂,或者它性能被拖慢。其次是GPU光模块故障率都很高,任务规模越大,故障率越高。Llama3.1平均3.1h中断一次。最后是恢复成本很高。下面是LIama 3.1 54天故障数据图,绿色的部分正常训练,两个绿色部分的间部分是任务中断,要回到上一个check point,定位故障节点,把任务重新拉起,所以成本是非常高的。


第二个挑战是故障定位是非常复杂的,第一个原因是训练任务具有同步性特点任何一个节点出现问题,所有节点都会跟着一起表现异常无法快速分辨出哪个节点是故障根节点。第二个原因是技术是比较复杂。从底层服务器硬件到网络,到软件框架用户代码任何一个技术栈都有可能导致任务失败,或者任务性能下降下面是比较常见的问题,从GPU、Nvlinkg、Pcie网络的组网交换机存储业务都有可能出现问题。所以在一个复杂系统里面性能性能下降,很难定位出问题

 

二、阿里云大模型训练稳定性系统介绍

下面解决这些挑战第一点在交付前做健康检测,确保交付的节点和集群网络都是健康的,在运行中肯定会出现故障,需要构建一个实时可观测系统,通过这系统快速发现故障,在此之上还需要一个故障自愈系统,和pass层的学习平台配合,让任务可以快速的迁移恢复,这个是整体一个架构


面分别对这几个系统做一个简单的介绍第一个就是健康检测系统。

健康检测系统主要分成两部分,第一个是单机的检测,包括硬件的检测软件的检测以及一些关键配置检测,也包括GPU的一些矩阵层的计算,以及一些内集合通信检测,除了单一检测以外,因为一个训练是一个集群性的业务还需要一些集群的检测,比如网络连通性的检测RDMA网络性能检测,以及集群集合通信检测,除此之外可能需要存储IO路径E2E检测模型E2E检测。


有些友商不仅把它作为一个交付前的检测,还把它做成一个故障定位的工具,我们的观点是要用这个去做故障定位,因为很多的检测是有损的,做检测必须要把任务停掉把所有检测跑一遍,可能是时级或者十分钟级别的损耗。


这个东西只作为一个交付前的检测,不要作为一个故障定位手段,需要构建一个Runtime的监控系统,通过Runtime的监控定位故障这个监控是数据越多越能定位到问题把各种各样数据全采一遍,肯定是能定位出问题,但是数据采集的越多,这个存储的成本就很高,第二个是有数据是有损采集,比如任务层面的trace信息是需要侵入的,或者对性能是有损的


现在的策略是对于基础设施层的监控基本上是Runtime全部采集部分是业务无损的,对于需要任务层的一些监控是有损的,比如集合通信框架trace信息是有损的,这部分是按需开启的,比如出现故障时候开,或者每几百迭代会开启。其次基础设施层监控和任务层监控一定要给联动起来


因为如果只去看基础设施层监控会发现很多故障,就是可能会有很多的告警,但是告警不一定真正的会影响业务性能业务运行,所以需要把两个有机结合起来,才会有一个更高的定位效率。


基于这个可观的系统之上就是自愈系统。自愈系统分三部分,第一部分是把laas层的故障上报AI Pass平台,比如说GPU故障内存的故障网线网卡的故障平台会把这些节点进行隔离,把任务重新再拉起来。


第二部分是AI Pass平台检测所有任务的日志,会发现里面有各种报错,比如ECC errorCuda error,它会把节点给做隔离,经过第一步第二步之后,可能大部分故障定位上,但是还有一部分故障没有报错在这种情况下,构建C4D系统专门去检测这种疑难杂症的Hang行和Slow问题

 

三、大模型系统稳定性关键问题实践分享

下面讲解集群任务相关的,这个故障的定位和稳定性的实践。第一个问题是除了GPU故障以外,可能遇到最多的故障就是网络的link故障,现在这种集群工作比较大,功模块比较多,故障率非常高,首先阿里是一个双上联的网络架构,意味一个网卡是连到两台交换机上,一根链路中断以后,这个任务是不会断的,它可能性能是会受损,也是跟这个模型和通信占比有关,现在很多的模型跨界通信都是被计算给flap掉了,在大多数情况下,断网线对性能没有太大影响。断网线就不需要把任务全部停掉,可以在线进行热维修


第二个问题是交换机升级,单上联的交换机几乎是没法升级的,要把所有的机器全部迁移走升级,这个成本是非常非常高的。双上联基本上解锁交换机在线升级能力,基于双上联架构就可以使能网线热维修能力,这个能力实际上是把端侧和网的所有的链路的监控全部汇聚到一起。


因为很多故障看一侧看不出来,要把两边数据都汇到一起,比如CRC这种故障是单边首先要把端和网全部汇聚到一起,基于此来做各种策略阈值设置以及告警和维修策略,要防止机房换线换错,还要做各种容错校验机制,防止它犯错。这个实践下来发现链路故障大概是60%link down,20%link flapping,20%rx error。基于此热维修系统基本上95%的网线故障都是可以基于热维修去修复的。


还有一些情况是网线断了对性能有影响,可以跟机器学习平台做联动,可以设置,比如客户认为网线故障会造成性能影响,就可以说网线故障推送给客户做一个私域第二个问题就是集群网络故障如何定位,第一点首先高性能网络是一个端网融合的技术,它有需要网卡和交换机深度的配合,所以整个监控系统的设计也是基于端网协同,把端侧的所有的网络相关通信指标和网测指标做一个聚合,然后进一步跟任务信息进行聚合,因为发现一个任务通信其实是有规律的,任务信息进行结合后,定位效率又进一步提升


例如发现通信的任务级的监控出现异常,可以自动化的关联到对应的任务,对应的网络集群也出现了对应的异常,然后就可以定位到故障对应,以及我们会有一些维修策略第二个是网络在训练过程中是一个burst,比如这个dp的通信基本上是在200到300毫秒,tppp可能是在毫秒级别甚至微秒级别。通过秒级监控基本上看不到峰值。


所以在网络监控里面需要更高的精度,比如这个线上主流的毫秒级监控,毫秒监控可以很清楚的看到这一次迭代通信行为,比如reduce scatter和gather整个通信行为,以及能很精确的看到某一个dp group没有打满。在一个很粗的力度网络监控上是根本发现不了性能问题。所以要定位性能问题就需要更高精度网络监控。


在dp做overlap以后,它pp的通信是由以前的串行通信变成并行通信,就是以前pp通信之后做dp通信,但是现在发现其实ppdp是同时在通信,它就会有影响,因为ppdp通信都是找同一张网卡,所以在网卡上监控没法发现他们互相影响,所以就在交换机上做微秒级别的流级别监控,这样就很容易观察到pp和dp的通信在交换机上互相有影响。


通过这种更高精度的微秒级别的监控(dp的通信是微秒级别),可以发现细粒度的性能问题,下面分享一则数据,统计线上阿里内部的万卡level,它的整个训练过程中的稳定性数据这个任务中断的时间就是在1%以内,在正常情况下,它的主要开销就是任务重启,比如每一次要十几分钟并且每天断两次,可能就是大概1%以内的性能的损失,统计另外一个数据就是性能的损失,发现性能的损失大概是在0.6%左右,来源于每隔几百个迭代,做一次框架trace,有时候也会超过这个值。引起这个性能抖动超出预期或者任务中断时间超出预期,都是因为这两个问题,一个是任务Hang住,一个是任务性能slow,这两个问题是目前稳定性遇到最严重最麻烦最难搞两个问题


下面解决这个问题,首先训练任务集合通信是同步的所以就可以利用集合通信的同步的特点,把集合通信的所有日志采集出来,在中心做一个诊断,很容易发现哪一个节点出现的问题,比如图中每个rank都是按照计算通信顺序,有一个rank就发现它计算后就没通信。因为它Hang行计算,所以通过统计集中通信数量,很容易定位出来哪个节点Hang住,其次slow其实也是同样的原理,就是这个时间会更长一点,说明计算变慢了,这是一个很好的思路


这个方法的好处是它不需要去适配模型框架,它是个通用的,因为它只需要你去替换集收通信动态库,这个是没有侵入的并且对性能性能是没有任何影响的,大量的客户都在使用这个方法去定位性能问题或者Hang问题另外一个问题就是其实他很多问题不一定是某个硬件出问题,他可能代码出问题,或者不是现在出现的问题,我们在通讯库的基础上又增加了一些扩大,对python更加细致的采集,现在的问题是数据量太大,就是G级别,核心要做是把这个东西给搞成一个比较小的数据,才能把它统一汇聚到一个中心节上去做定位。


所以这里面做了一个特征提取,把关键的特征提取出来,最后放到中心化的去做一个这个诊断,这个分析报告是如下示意图,这两个能力在这个产品上都是可以用


最后就是关于未来的一个展望我觉得未来这个十万卡集群的稳定性可能和万卡不是一个level。可以想象一下,十万卡集群大概一个小时可能挂一次现有的一些技术体系不一定能支撑。比如现在异步的check point这是第一个问题


第二个问题就是一个任务中断其实不是硬件出故障,任务立刻就中断,它其实是有个时间会Hang,这个时间其实是很大的占比,所以我们现在也在想办法,怎么把这个Hang的时间检测出第一时间就已经挂了,提前从任务退出那这里面就有个trade off,比如现在把时间调短data loader可能本来时间就可能需要个几分钟,但可能就因为data loader Hang住,所以这里面有很多功能要做,第二个是重启的初始化时间。


怎么把初始化时间能给它干到一分钟以内,这个也是一个很关键要探索的点,现在很多这个业界现在也在搞这个方向,比如集合通信,集合通信初始化时间比较长,好消息是看到最新版本上面也是做很多优化。最后一点是热迁移,因为现在整个训练任务一个节点挂了,整个任务就挂了,然后全部拉集如果十万卡level节点挂,十万卡全部重启令人很崩溃。所以怎么挂掉的节点信息和参数之类的信息到另外的节点通过一个新的communicator把它建起来到communicate组里面。我觉得这是未来重要的探索方向,目前是已经跑通demo,但是这个东西可能跟上面的框架模型有很大的耦合度,所以现在没有生产

 

 

相关实践学习
在云上部署ChatGLM2-6B大模型(GPU版)
ChatGLM2-6B是由智谱AI及清华KEG实验室于2023年6月发布的中英双语对话开源大模型。通过本实验,可以学习如何配置AIGC开发环境,如何部署ChatGLM2-6B大模型。
相关文章
|
9天前
|
人工智能 自然语言处理 搜索推荐
携多项成果亮相云栖大会,探索大模型在云通信中的创新应用与全球实践
2025云栖大会云通信分论坛聚焦大模型与云通信融合,阿里云发布智能联络中心2.0与Chat App AI助理,携手伙伴推动通信智能化升级。
|
2月前
|
机器学习/深度学习 人工智能 算法
GSPO:Qwen让大模型强化学习训练告别崩溃,解决序列级强化学习中的稳定性问题
这是7月份的一篇论文,Qwen团队提出的群组序列策略优化算法及其在大规模语言模型强化学习训练中的技术突破
699 0
GSPO:Qwen让大模型强化学习训练告别崩溃,解决序列级强化学习中的稳定性问题
|
2月前
|
机器学习/深度学习 自然语言处理 API
query改写:大模型应用测试离不开的实践
queryrewrite 是一个用于大模型应用测试的 Python 库,专注于查询(query)的改写与验证。它支持多种改写方法,包括大型语言模型(LLM)、词汇表替换和同义词替换,同时提供多种验证方法如 ROUGE-L、BLEU、帕累托最优和LLM语义相似度,以确保改写后的查询在语义上保持一致。该项目特别优化了对中文文本的处理,涵盖分词和相似度计算。用户可通过 pip 安装,并支持扩展不同的 LLM 模型,如 OpenAI、Ollama 等。
477 87
query改写:大模型应用测试离不开的实践
|
3月前
|
机器学习/深度学习 人工智能 测试技术
【ICML2025】大模型后训练性能4倍提升!阿里云PAI团队研究成果ChunkFlow中选
近日,阿里云 PAI 团队、通义实验室与中国科学院大学前沿交叉科学学院合作在机器学习顶级会议 ICML 2025 上发表论文 Efficient Long Context Fine-tuning with Chunk Flow。ChunkFlow 作为阿里云在变长和超长序列数据集上高效训练解决方案,针对处理变长和超长序列数据的性能问题,提出了以 Chunk 为中心的训练机制,支撑 Qwen 全系列模型的长序列续训练和微调任务,在阿里云内部的大量的业务上带来2倍以上的端到端性能收益,大大降低了训练消耗的 GPU 卡时。
|
2月前
|
JSON 自然语言处理 算法
大模型应用测试必备技能:问题对生成实践
本文介绍了利用LangChain的QAGenerationChain从文本生成问题-答案对(QA pairs)的方法,旨在解决LLM应用开发中测试数据生成的格式不统一、库版本过时、模型输出异常及代码可维护性差等问题。文中提供了完整的代码实现,并对生成结果进行了有效性评估,包括语义相似度检查、关键词匹配和重复性检测,确保生成的QA对质量可靠,适用于知识库测试与评估。
287 86
|
14天前
|
机器学习/深度学习 算法 数据可视化
从零开始训练推理模型:GRPO+Unsloth改造Qwen实战指南
推理型大语言模型兴起,通过先思考再作答提升性能。本文介绍GRPO等强化学习算法,详解其原理并动手用Qwen2.5-3B训练推理模型,展示训练前后效果对比,揭示思维链生成的实现路径。
135 1
从零开始训练推理模型:GRPO+Unsloth改造Qwen实战指南
|
3月前
|
机器学习/深度学习 数据采集 人工智能
微调之后还能做什么?大模型后训练全链路技术解析
本文探讨了后训练的重要性、方法以及最新进展。文章将包含理论分析与实际操作指南,适合希望深入了解并应用这些技术的开发者。
539 18
微调之后还能做什么?大模型后训练全链路技术解析
|
18天前
|
机器学习/深度学习 数据采集 安全
万字解析从根本解决大模型幻觉问题,附企业级实践解决方案
本文深入探讨大语言模型中的幻觉(Hallucination)问题,分析其成因、分类及企业级解决方案。内容涵盖幻觉的定义、典型表现与业务风险,解析其在预训练、微调、对齐与推理阶段的成因,并介绍RAG、幻觉检测技术及多模态验证工具。最后分享在客服、广告等场景的落地实践与效果,助力构建更可靠的大模型应用。
184 0