随着人工智能技术的快速发展，银行作为金融行业的重要组成部分，正面临前所未有的数字化转型机遇。智能客服作为提升客户体验、优化服务流程的关键环节，其背后的大模型微调与分布式并行集群架构设计显得尤为重要。
在银行数据量的激增和业务复杂度的提升的背景下，单节点计算已无法满足高效处理和实时响应的需求。分布式并行集群架构应运而生，它通过巧妙地将任务拆解并合理分配给众多节点同步执行，如同一台强大的引擎，大幅提升计算效率与吞吐量，让智能客服系统的响应速度与处理能力实现质的飞跃。如何设计好分布式并行集群架构是一个系统性的工作，要对大模型任务充分理解，还需要综合计算、存储和网络等基础设施多维度考量，任何一方都不能成为短板。
为了帮助银行AI架构师、大模型项目负责人能更好地应对客服场景大模型微调训练阶段IT架构设计的挑战，twt社区在6月2日组织主题为“面向智能客服等场景，银行大模型微调训练阶段如何设计百亿级/千亿级参数大模型分布式并行集群架构？”线上封闭式赋能活动，邀请到社区大模型课题专家组银行用户专家、华为存储专家进行深入解读和分享。
本文对本次赋能活动达成的共识及对核心议题的精华探讨整理如下，希望能为更多同行提供参考。
通过本次深入交流，与会嘉宾在四个方面达成共识，具体情况如下：
1、分布式并行计算架构方面：
1）要平衡计算资源与通信开销，可通过选择合适并行模式、避免全网数据同步、设置多同步主节点等方式，避免出现计算资源和数据通信的瓶颈。2）在模型并行和数据并行模式选择上要基于大模型规模，规模大考虑模型并行结合流水线并行，规模小用数据并行。
2、优化资源分配策略方面：
1）应用调度上可以通过时间窗口的调度来优化资源使用，利用闲置资源的白天时间进行推理，晚上对数据进行预处理来提升资源利用率。2）模型优化上通过模型压缩、优化、知识蒸馏等方法减少计算需求。3）提升硬件配置，采用全闪盘存储、针对 AI 优化的文件存储、高速网络等方式提升算力资源利用率。4）在缺少GPU资源的时候，利用已有的闲散CPU资源来做训练，尤其是在推理环节，但是要注意错峰使用。
3、分布式并行架构存储需求方面：
1）拥有分布式并行能力；2）支持多生态GPU；3）高性能，注重小文件高速读取、保存checkpoint大文件写性能和加载checkpoint读性能
4、RAG和微调的差异方面：
1）索引增强生成适用于知识更新频繁、快速精准获取信息的场景；2）微调适用于数据量大、结果精度要求高的场景，二者可以协作使用；3）在算力和成本有限时索引增强生成更合适。4）可利用开源社区资源对 RAG 技术使用进行优化。
本次活动邀请了某股份制银行的刘远圳担任本次活动的主持人，某股份制银行大数据研发部主管范容老师担任分享嘉宾，华为数据存储产品线AI存储总经理严浩老师担任本次活动的分享专家，某股份制银行数据产品中心总监苟志龙老师担任活动的互动嘉宾，共有20多位银行同行参与了活动。
银行用户专家范老师的分享内容分为三个部分，第一个部分是银行大模型的应用价值，介绍了大模型的应用模式、应用策略、应用场景和应用挑战；第二个部分是以客服场景为例，银行如何落地大语言模型？介绍了客服场景的应用范式和应用案例；第三部分是大语言模型中并行分布式集群架构的一些建设的关键点，从计算资源、存储资源、网络资源、监控管理、网络优化等方面介绍了分布式集群的建设关键点。为同业提供了非常有价值的参考。
华为严浩老师分享了《银行大模型数据存储基础设施建设方案分享》，深入浅出介绍了华为在相关领域的前沿技术和创新实践。华为AI ready的数据基础设施方案为银行业提供了从数据预处理、模型训练到推理应用的全方位支持。通过高性能存储、分布式并行、智能分级存储等技术手段，有效解决了银行大模型在数据存储与处理方面面临的种种挑战。同时，华为方案还充分考虑了金融行业对数据安全可靠性及实时性的高要求。
互动交流环节中，
参会用户积极提出了自己在大模型应用落地中并行集群架构性能优化和系统资源利用率等方面的难点问题，与会的专家老师相应给出了技术解答和参考建议。精彩问答节选如下：
议题一：分布式并行计算架构如何整体设计和优化提高集群性能和算力资源利用率？
1、在当前银行内部CPU资源充足GPU资源短期的背景下，如何利用当前银行内部零散非分布式CPU计算资源高效部署大模型以提高大模型回复速度？
1）在应用的调度方面，白天的时候用计算资源做一些应用的推理，晚上的时候做一些数据的预处理。通过调度任务给资源使用的时间分解开来，提升资源利用效率。
2）在模型的优化方面，要做模型的压缩和量化。目前来说，尤其在知识检索、智能搜索这方面，并不需要参数量特别大的模型，而且它的知识范围可以进行压缩。因为不需要去解决回答，比如说今天天气怎么样，或者你的心情怎么样，例如这些的问题。基于这样的一些场景，可以做模型的剪枝，减少模型的参数量，包括做模型的量化，减少计算存储的要求。也可以运用知识蒸馏的过程，通过训练较小的模型来模仿大模型的行为，来保证精度的同时减少企业计算的需求。
1) CPU可以用来训练和推理，只不过是现在主流厂商的软件框架支撑还不够好。一些开源社区在推行轻量级的模型框架，在缺少GPU资源的时候，利用已有的闲散的CPU资源来做训练，尤其是在推理推理环节。
2）对于闲散CPU的资源要错峰，因为银行业服务器很多，但白天整体的调用量和资源的使用率很高。这个结合今天聚焦的智能客服场景，我特别想借此呼吁的一点，因为现在都在谈业绩融合，twt的论坛其实我们谈论很多方案方法、小技巧，很多时候是忽略了业务背景的。从民生的角度看，其实我们在道法术器的术器这个层面没有做到极致，很多场景目前在做研发和试点性的应用时，更多靠道法的层面去推动。所以需要明确一下场景的目标是什么？当目标明确了之后，再确定需要的方法、资源和相关的技术，再去理清短板到底在哪里。有时候我们一个不合理的需求的认知，在转换成方案的过程中，如果转换到了需要借用大力出奇迹的方向上，那这个路可能就走不通了。但是这个问题在做需求理解和确认方案设计的时候换另一种思路是不是就可以解决？其实现在银行业数字化转型过程中，有不低于60%的项目方案是采用了一种惯性思维来做，采用了一种比较笨的方式来推，所以项目的效果并不好。但在方案设计的时候，如果有经验比较丰富的跨界复合型人才，方案就不会那么设计，最后效果会更好。所以针对农行提出的要求，如果GPU资源确实不足，CPU可以用开源社区提供的一些方案去尝试。另外要理清整体的应用场景的现实需求，通过现实需求做场景化的方案设计，再来合理利用CPU资源。
3）涉及到多模型的流水线的调度。因为今天的议题非常宏大，里面涉及到很多环节，最重要的是涉及到资源管理和灵活调度的问题，在民生的现实经验上来说，会做任务调度的优化，一开始是凭借经验，从一年前也开始在做积极学习驱动的模型调度的优化。从结果来看，效果是不错的。所以基于流水线的调度，当资源成为瓶颈的时候，它的智能化的应用也可以很好的提升效能。因为我们没有遇到这么现实的问题，所以可能没有确实的实践经验，只能从理论层面做一些假设性的思考。
1）采用全闪盘存储，从存储层方面提升算力的资源利用率，通过提升存储性能，提升算力资源利用率。
2）采用针对AI做优化的文件存储。AI出来之后呢，大家都在研究分布式并行的文件系统，本质上的原因就是原来的OBS性能不行，需要提升存储的性能。提升了存储性能，减少了算力的等待，从而提升资源利用率。
3）采用以存代算，AI在训练还是在推理的过程中都存在着一些重复的计算。怎么通过CPU的内存或者外置存储把一些计算中间过程保存下来，不用反复去重复计算，就可以提升算力资源利用率。
4）减少数据的搬迁，做好统一的算力集群规划，降低数据管理复杂度，减少调度降低算力等待的浪费。
2、分布式架构中节点数量与算力提升的拐点问题，这种集群节点数量多，节点通讯开销大，到一定规模后通讯会消耗很大算力，集群整体表现算力无提升反而往下走，针对这个情况如何应对？
1）因为这次交流涉及到的内容很多，如果用一条线穿，它应该分成几个方面，一是围绕着智能客服的场景，整个计算架构如何选择如何优化？二是架构定了之后，计算资源需要什么样的资源？计算资源在讯推过程中如何分配和调度的问题。三是计算性能是否可以通过算法，包含迅推的算法、网络通讯协议的调整等等，去调整整体性能。如果不是基于固定的型号，而是基于消费级的显卡构建一个庞大的计算资源池，整体ROI会受很多因素的影响，包含单张卡整体的算力，存储，网络通讯。因为每张卡都不一样，针对每张卡能够组成的一个计算池，能够一起协作，计算，训练，推理，背后也会有定制化针对性的调整。
2）理论上这个拐点应该存在，但现实拐点很难预测，也没有企业可以给出现实的经验。所以针对这个问题，我能给到一些原则性的建议：如果这个成为现实的约束，要聚焦的是场景，目前场景应用目标是什么？大概设计多大数据量？设计多大算力的消耗？尽可能把非标的消费级显卡切成小块的资源池，而不是构建大的算力池，这样可以把很多问题做到简化。有些问题大而化小之后，它还能够基于一些经验数据驱动做测算。这样问题是有解的。如果把不同的消费级的显卡丢到一个池子里，整体ROI会非常低。这是我跟一些小企业在交流过程中实际的感受。你刚才提的现实痛点，其实他们也会遇到。这个仅供参考，也是没有实践过的。
3、训练和推理对存储需求的侧重点有哪些不同，规划上有哪些不一样?另外，在存储和存储网络规划上，如何基于大模型的不同建设阶段做演进？
1）训练环节对存储的诉求主要是三个，第一个是训练数据集的小文件高速读取能力；第二个就是在训练过程中保存checkpoint对大文件写的性能要好，由于集群规模导致的故障率上升，需要缩短保存的周期；第三个是checkpoint的加载性能，需要将checkpoint并发的加载到各个训练的节点，对于存储读的性能要求更高。
2）推理环节对存储的诉求主要是三个，第一个是外挂知识库存储，类似向量数据库。当这个向量数据库的规模到了上亿条，对存储性能要求很高。第二个是推理的长序列，并发的推量数量增多的情况下，在显存里存放不下，就会把它持久化保存到存储上。第三个是推理的结果数据也要保存起来，形成一个反馈的机制，能够提升大模型的训练质量。
4、分布式计算架构可以在哪些方面进行性能优化策略设计？分布式计算架构基于硬件加速可以考虑的性能优化策略？
分布式架构的性能优化也涉及到多个方面，从硬件配置到软件的架构设计再到任务的调度和负载均衡，有几个还比较关键的优化策略。
1）硬件配置的优化策略，选择使用高性能服务器，在使用分布式架构的情况下，也不能忽略单个服务器的计算能力，尤其在训练和推理的过程中，CPU或SSD存储方面的选择还是要有一定的要求，它们对于模型的性能还是有一定影响的。
2）尽可能的部署高带宽的网络。
3）数据分片以及模型压缩，尽可能的通过这种方式降低计算的复杂度。
4）优化任务的调度，通过自动和人工结合的方式对资源进行实时监控，优化任务的调度来合理分配计算资源，提升效率。
议题二：异构GPU资源情况下，如何优化提高系统资源利用率？
大模型落地时，检索增强生成和微调分别对数据和算力等方面的比对，现在用微调比较多，索引增强生成相对来说少一些，想比较一下这两种技术对所需的这个数据和算力开销等方面的差异？
1）首先RAG的优势在于灵活性，可以通过更新知识库快速适应新的信息，比如对于制度、操作规程这些场景要频繁更新，这就需要它的灵活性。另外RAG有一定的可解释性，检索内容可以作为生成结果的依据，比如柜员在操作的时候，可以作为显示的依据看到制度原文出入在哪里，会知道操作是这样做的，制度是这么写的，增强一定的可解释性和可信度。它的劣势在于庞大的知识库检索可能会带来一定延迟包括影响性能，另外将检索到的信息与生成的模型融合需要一定的设计，所以要确保生成结果的连贯性和准确性也会有困难。
2）微调的优势在于高精度，通过微调可以将大模型的性能优化到特定的领域，取得高精度的结果，生成的结果和语义风格上具有一致性。目前在微调方面用的比较多的在监管发文领域，监管历史以来的发文和外部比较正式的公文，这样内部在公文写作的规范性上或规范格式上会有很大的好处。但是它也有劣势，需要一定量的标注，获取成本比较高，本身算力要求也比较高。
3）总结来说，数据方面：RAG需要比较大的知识库来覆盖，对数据质量有一定的要求；微调也需要一定的标注的数据。算力方面：RAG检索部分依赖CPU和IO，生成部分依赖GPU；微调前期投入比较大，对GPU算力进行微调。适用场景方面：RAG适用于知识更新比较频繁，而且对检索结果要求比较高的场景，比如实时的问答和客户支持；微调适用于数据量大，比较稳定的场景，比如专业领域的文本生成、内部的公文写作以及翻译。
1）这两项技术随着时间的推进互补性很强，基本一个场景目标明确下来通常会择其一。DIKW金字塔模型把整体的数据智能分成了数据、信息、知识和智慧，现在数字化转型进入到关键攻坚阶段是慢慢的从下层往上层移，报表标签更多聚焦于下面的数据和信息层，机器学习模型和机器学习模型驱动的智能策略的更迭聚焦于知识和智慧层。
2）RAG更适用于快速精准获取信息，并且要溯源的时候这个场景。RAG通过知识库来提供精准的信息，但并不能提供在某一个垂域下的知识，甚至是推理能力。我们传统所用的基座大模型整体的广义知识，推理能力很强，但是并不具备金融行业固定场景下的推理能力。所以当我们去让他去写一篇文章的时候，会发现这时候他写的东西看似话有道理，但是对我们的帮助并不大，他没什么思考能力。所以RAG更多应用于针对产品库数据库的检索，如何从繁杂的信息库里面快速获取相关的信息，以辅助开展下一步的工作，目前来说至少现阶段更倾向于这一侧。
3）微调在智能客服、风控类的辅助场景的实践经验中，首先需要数据的标注工作以及后端对齐性的工作，这需要形成人机协作并且强绑定的协同过程。虽然成本很高，但未来这个模型具备一定的基础性的知识以及一定的逻辑推理能力，甚至会给予超出预期效果的东西，对我们实际的工作场景的用处非常大。
4）在具体场景中是使用微调还是RAG？如果稍严谨一点，他俩其实是太极图的概念，你中有我，我中有你，所以他们是互补关系。在场景聚焦之后，会有一个侧重点，主要构筑解决目标场景下核心能力的是依赖于微调还是依赖于RAG，更多情况下，他们是互相协作的关系。
如有任何问题，可
点击文末阅读原文
，到社区原文下评论交流
觉得本文有用，请
转发
或点击
“在看”
，让更多同行看到
