随着金融行业的蓬勃发展，客户数量快速增长，金融行业涉及的业务领域不断拓展。在此背景下，AI技术在金融公司的各类交易、业务处理、客户服务等众多场景中将得到更加广泛深入的应用，比如量化交易、极速交易、精准推荐、人脸识别、视频质检、智能客服等等。金融行业在大模型的应用方面已经取得了显著的发展，重塑了金融圈的基础设施、技术能力、数据生态和业务场景，但是也面临着诸多的调整，例如训练与推理方面存在算力利用率不足，数据安全、个性化服务、数据幻觉及多模型，全周期的管理等问题。
社区近期组织了“金融行业大模型落地应用场景及如何提高算力资源利用率”同行探讨，邀请了社区多位技术专家一同参与线上交流，本文选取交流精华：8个议题及同行共识，进行了梳理总结，希望能够为更多金融同行及各行业相关从业者提供参考。
主笔嘉宾：董生 某大型银行 数据库架构师从事数据挖掘与数据设计领域工作，对交易、会计核算、大数据应用分析,LLM有深入研究，先后为多个大型项目设计高效稳定的数据架构和制定数据规范和标准，提供从设计到运维容灾一整套的数据解决方案。在LLM领域，对架构设计、训练优化、模型微调、应用部署等方面熟悉，持续致力于实践LLM应用的落地与赋能。答疑嘉宾：仙守 苏宁易购 算法工程师lidhrandom PAT 工程师RoderickLi 某证券公司 算法工程师allanrong 浙商银行 主管互动嘉宾：cpc1989 某保险公司 系统架构师jinhaibo 昆仑银行 技术专家
1、如何在基于大模型的智能客服应用中解决客户个性化需求多样性 ？
@lidhrandom PAT 工程师：
首先我们要讨论的是，个性化大模型服务是否真的是一个问题呢？一年半前ChatGPT火爆的一个重大原因就是各大媒体都认可大模型已经实现了个性化，而一年半后的今天我们却回到了解决客户个性化需求多样性问题的讨论上，令人大跌眼镜。
对此我们认为，一年半前媒体报道的“个性化”，其底层技术原理在于大模型对问答历史上下文的记忆，这和今天智能客服所想要达到的“个性化”相比是有一定差距的。事实上，个性化推荐在电商领域早已得到深入研究，相关技术落地应用已经很久。相信大家都有这样的经历：在微信上聊到某种商品后点开京东就会被推荐相关商品。作为智能客服，其个性化能力可以参考这一套打法，拓展对话历史上下文的来源，充分复用业务应用已有的个性化能力API，将相关信息隐式地加入对话上文，即可有效提升个性化程度 。
@仙守 苏宁易购 算法工程师：
大模型的出现，给很多传统不能解决的问题带来了不少的曙光，因为大模型具有一定的智能性，也就是我们认为的更好的语义理解能力。其实千人千面在推荐系统中本身就是一个持久的话题，他们就是：1）记住每个用户的历史访问，历史订单，鼠标等轨迹来进行首次的猜测。2）通过spark、hive等进行用户感兴趣商品的召回、然后进行粗排、精排、重排、业务干预等实现的。
那么对于智能客服来说，也同样可以借鉴：1）搞个数据库，把用户历史访问，历史行为轨迹都记下来。2）基于用户当前的需求，先通过大模型简单的意图识别召回一堆知识库啊或者什么的。3）让大模型进行排序，给出基于这个用户的历史行为轨迹，这个用户通常最感兴趣的解决方向是什么。
要是题目问的是每个用户来客服想解决不同的问题，比如这个人想问怎么贷款，那个人想问怎么办卡。那就还是知识库的维护+RAG进行当前用户意图的数据召回+agent的tool调用。
@Jillme 某银行 数据库架构师：
1.结合先进的知识增强技术例如RAG和个人知识库，以生成针对用户独特需求的个性化输出。这种方法特别针对处理情境化查询建议，即在搜索建议的基础上，考虑用户历史问题和当前问题的上文内容。
2.智能客服面临的问题是如何让LLM理解用户的专业领域并生成个性化的建议，而非通用答案。可以考虑引入个人知识库策略来增强模型。然后利用LLM在给定的上下文查询建议任务中，利用搜索的历史日志中的实体个人信息，以用户已知知识为导向生成更精确和动态的建议。
3.分别建立用户过去的查询习惯和浏览行为模型集合，和用户独特的兴趣和专业知识模型集合。例如当用户频繁询问与“某个主题”相关的关键词，表明他们对该领域有显著兴趣。历史模型集合通过时间戳记录用户的行为，展示了一个用户逐步获取知识的过程。比如可以从索引擎日志中提取数据，包括用户提问和点击的页面。作为用户行为的反映的直接证据，同时保持了隐私（因为主要依赖公开数据），避免了大规模存储和隐私保护的挑战。另外虽然都有时间戳，但是分析用户全面互动历史时，不能仅依赖时间，还需要参考客户独特的兴趣和专业知识，从而更深入地聚合和理解用户的专业兴趣。这样既能处理单一客户提问，又能防止混淆，同时减少了处理复杂网页文本的负担。
4.减少知识幻觉。提高数据质量，扩大数据规模。增强检索功能也可以显著降低知识幻觉。建立个性化的人设信息和知识信息，组装为数据，在多个任务中统一学习，实现多任务学习。最后还要有可干预和可运营的对话链路。
以上内容，通俗的说就是：
1.通过对用户历史数据的深入学习，能够准确理解用户的偏好、习惯以及需求
2.能够基于对话的上下文来调整回答的策略。
3.通过对用户情绪的识别和理解，满足用户的情感需求。
4.不断学习和优化，以提供更加精准的个性化服务。
2、金融行业要求合规，大模型怎么保证合规性？
@RoderickLi 某证券公司 算法工程师：
1.流程合规性：2023年8月15日 ，国家互联网信息办公室等七部门联合发布的《生成式人工智能服务管理暂行办法》明确划分不同业务场景之下不同主体的合规义务，同时明确必须对AIGC生成的内容进行标记。2024年6月12日，国家互联网信息办公室发布了《关于第六批深度合成服务算法备案的信息公告》。因此，金融公司在正式对外提供大模型服务之前应完成深度合成服务算法备案以确保流程合规。
2.内容准确性：大模型的幻觉问题致使其可能会生成一些与现实世界的事实不一致、虚构或逻辑上不通顺的内容，即“一本正经的胡说八道”。金融领域对内容的准确性要求非常高，如果大模型做出虚假的、误导性的陈述，可能会造成严重的后果。同时，用户可能存在通过提示工程等方法恶意引导大模型生成不符合合规要求的内容。为此，金融公司在提供大模型服务时应对用户问题进行过滤，同时在强合规业务场景中人工对大模型生成的内容进行复核不可避免。
3.数据安全性：大模型在训练、推理等环节有数据泄露的风险（包括公司内部的商业机密、用户的个人隐私数据等）。此外，在某些金融场景中的跨境数据流通问题也较为敏感。因此，大部分金融公司会采用本地化部署大模型的方式，同时建立完善的数据管理和治理机制，确保高质量、有合规授权的数据，以有组织的方式投入到大模型的开发和部署过程中，从而保障数据安全性，避免触及合规红线。
@仙守 苏宁易购 算法工程师：
首先，任何一个大模型只要对外提供服务，那么就一定要进行备案，备案过程中就会涉及到如何让大模型合法合规的要求，至于金融行业是否在这基础上新增了更多行业大模型的合规要求，针对备案这部分，可以说几句：
1）自己从0开始训练大模型 这需要保证数据集的合法合规性，国标的GB_T 35273-2020 《 信息安全技术 个人信息安全规范》和tc260-003 《生成式人工智能服务安全基本要求》中都涉及到了不少的信息。2）基于开源的模型进行sft大模型 这个你不能用那些国外的，而且需要取得开源方的授权，数据也必须符合前面2个国标 3）直接调用别人的api 这个有对方的背书，相对合规性更好点。
上述三种都同步需要前置的处理和后置的处理：1）前置：安全内容审查，比如关键字字库，同步加上大模型判断。2）后置：大模型输出的内容也必须符合法律法规，也可以关键字字库、大模型判断、传统分类模型判断。
至于所谓可解释性和透明性，可以让大模型输出一步一步的思考过程，然后将最后结果输出到特定区域，然后提取特定区域，并将整个思考过程落日志进行后续审计。
3.如何保障基于大模型的智能客服系统运行稳定性？
@lidhrandom PAT 工程师：
基于大模型构建的智能客服应用其服务形式本质上和当前市面上的大模型问答机器人没有什么区别，只是有一定的领域特定性。这一类应用比较著名的例如百度的文心、阿里的通义、字节的豆包，在工程上都是非常成熟的了，但是其背后的技术原理确实没有太多报道。而最近引起全社会上下广泛关注的月之暗面Kimi却公开了所使用的大模型服务架构Mooncake。
Mooncake架构中，分布式KVCache池是关键，通过类似梅克尔树的技术对KVCache进行哈希，大大减少大模型所需计算量，在Kimi实际业务中提升了75%的请求吞吐量。
在推理阶段，vLLM及其Page Attention技术无疑已经成为行业标准解决方案，同样通过分块提升对已有KVCache的命中率，提升解码阶段的响应速度。
大模型本身的响应速度和吞吐量提升，剩下的就是在传统Web服务上已经成熟应用的K8s全家桶技术，二者结合即可为大模型服务的高可用性保驾护航。
@仙守 苏宁易购 算法工程师：
这是个工程问题，大模型其实看使用的规模是多大，不同规模有不同的方法。但是终究逃脱不了“多活”的概念，也就是你只搞个单点，那一定遇到问题。这个工程问题，k8s等都有成熟的方案，并不是大模型出现才伴随的问题。
1）本身就有主备的，最简单的，搞个nginx进行反向代理，这个大模型节点不通，那个总会通
2）只有单点的，那就需要这个点出现问题，另外的机器上就能立马拉起个新的服务，这个借助k8s还是挺方便的。
而且我们需要注意的是，大模型如果你的模型选的不是很大，比如chatgml6b，或者是qwen14b但是经过了gptq等等量化的，单机一块卡就能部署一个模型，一机8卡下，本身就有足够的冗余。
而且客服并不是商品推荐那种极具考验实时的场景，你一个模型失败了，延迟个大几百ms甚至几秒，也无伤大雅。再搞个转圈动画表示后台在思考，或者搞个排队机制，tps立马就降下来了。
@Jillme 某银行 数据库架构师：
系统运行的稳定性，可以分为3个方面保障。
1.硬件层面上：
选择高性能的服务器硬件，如多核CPU、特别是高性能GPU以及高速内存，以满足大模型推理的需求。通过强大的并行处理能力、高吞吐量能力，满足模型训练和推理稳定需要。
硬件维护：定期升级和扩容硬件。
硬件规划：合理的评估算力，不同场景采用不同的评估方式，例如在训练阶段，根据显卡的单算力，和训练数据大小，模型参数规模，训练Epoch次数的计算出需要的GPU数量。推理阶段，则可能需要考虑输入输出数据，模型参数规模的大小评估所需的GPU数量。根据估算出的数量，有针对性的采购。
2.模型层面上：
总的来说就是对模型进行优化。对推理模型进行优化，减少计算复杂度和内存占用，提高推理速度。使用不同的模型压缩技术(如剪枝、量化等)，以减少模型大小和推理时间。
推理性能受到显存带宽，服务吞吐量受到推理batch_size的限制的更多。
在推理引擎层，我们可以通过使用如KernelFusion、KV-Cache、FlashAttention、TP+PP、PagedAttention等技术对计算性能进行优化。
在服务层，为了优化服务吞吐、提升资源利用率，组batch策略是其中比较重要的，我们一般可以使用Dynamic-Batching技术，通过设定最大batch_size，极限等待时间max_queue_time提供利用率、或者使用Continous-Batching技术重新组织和处理batch数据。此外，还可以针对特定场景的采用例如流式、交互式及持续生成，以及长序列推理等优化技术。
在模型量化方面，采用Weight-Only、int8、int4以及KV-Cache量化等方案。
3.应用部署层面上：
使用负载均衡技术将请求分发到多个服务器，避免单一服务器过载；采用冗余部署策略，确保关键组件（如数据库、存储等）有备份，避免单点故障。
4、如何在智能客服应用中保持大模型对金融领域知识回答的准确性，应该建立什么样的机制和流程进行保障？
@allanrong 浙商银行 主管 ：
除了技术方面的工作，其实应该重点建立一个回答准确性保障机制：
1.人工审核：对大模型生成的回答进行人工审核，尤其是涉及复杂或关键问题。
2.专家审核：建立专家审核团队，对专业性较强的回答进行二次审核。
3.用户评价：允许用户对回答进行评价，收集反馈意见，及时改进。
4.问题纠错：提供纠错机制，用户可以提交错误或不满意的回答，帮助模型优化。
@lidhrandom PAT 工程师：
除了大家都提到的RAG架构和幻觉解决以外，我还想指出Agent在这一类业务中的关键作用。实际上这里往往也只需要一些最简单的Agent，通过对数据库的实时查询来保障相关数据的准确性。更进一步地，如果涉及的查询超过本系统所能触达的数据库权限，但可以在互联网上获取答案（例如年报数据一类的），可以引入在线查询Agent。实际上现在各大大模型问答应用都已经结合了互联网在线查询结果，也是十分成熟的解决方案了。
@Jillme 某银行 数据库架构师：
数据管理机制：
1.数据来源需要是经过确认的正确的，例如金融领域的智能客服，训练的数据来源，最好采集来自监管机构发布的政策文件、大型金融机构的研究报告和单位内部的法律法规和一些经过验证和发表的报表数据或者标准的客服回复知识库。
2.数据需要有清洗和筛选的机制，将历史时间长的，例如5年前的信息进行清理。将已经废弃的，例如XXXX规章内标识的YYYY规章从即日起废弃。这些都需要有专职和计划性的规划。
3.建立数据打标机制，将客服问题标记为 服务态度、XX业务流程、欺诈等标记，并明确使用的场景或者问题类型。
模型训练优化机制：
1.持续训练，定期更新数据，以反映最新的知识和行业动态，对模型进行重新训练。
2.通过试验不同的超参数组合，找到最优的模型配置，提高回复的准确性。
3.使用多种评估指标，如准确率、召回率、F1 值等，对模型进行客观评估，比如通过对比智能客服的回答与专业客服主管的意见，来验证回答的准确性。
4.使用RAG检索增强生成，提升回复的正确性和时效性，或者在一些专业性领域，提供特定的专业性的回复。
管理机制：
1.建立人工审核机制，对智能客服的重要回复进行人工审核，确保其专业性和准确性。
2.培训专业人员，对参与智能客服项目的人员进行专业知识培训，提高他们对相关领域的理解。也是增强RLHF。
3.跨部门协作，技术与业务人员共同优化回复策略，提升专业性，准确性。
@仙守 苏宁易购 算法工程师：
这个问题可以进一步扩展到如何保证垂域领域知识回答的准确性：
第一步，首推是模型的三件套，pt，sft rlhf，然后进行持续不断地这么干，搞个金融领域的top1。
第二步，就是rag+agent，也就是将领域知识做成rag和部分术语可以通过tool调用搜索引擎等获取知识，统一填充到prompt中，进行上下文的补全。
第三步，工程上的：辅助大模型进行整个对话的判断，比如用户对回答是否满意啊，等等来判断当前与用户沟通的大模型是否回答的符合用户意图。
第四步，人上的：将前后的都进行落日志，然后进行审计，进行周期性判断当前大模型怎么样，要不要升级改造。
而且客服并不是商品推荐那种极具考验实时的场景，你一个模型失败了，延迟个大几百ms甚至几秒，也无伤大雅。再搞个转圈动画表示后台在思考，或者搞个排队机制，tps立马就降下来了。
5、如何在基于大模型的智能客服应用中解决大模型语境理解局限？
@allanrong 浙商银行 主管：
除了技术方面的工作，其实应该重点建立一个回答准确性保障机制：
1.人工审核：对大模型生成的回答进行人工审核，尤其是涉及复杂或关键问题。
2.专家审核：建立专家审核团队，对专业性较强的回答进行二次审核。
3.用户评价：允许用户对回答进行评价，收集反馈意见，及时改进。
4.问题纠错：提供纠错机制，用户可以提交错误或不满意的回答，帮助模型优化。
@lidhrandom PAT 工程师：
近期微软开源的GraphRAG不失为一个值得尝试的开源框架。该框架已经应用在微软的Copilot（在Windows11操作系统中可以体验）项目中，其实用性得到大量用户的广泛验证。其技术方案主要利用知识图谱技术，相较于一般RAG中基于向量相似度检索的泛用性和准确性都大大提升，根据用户输入从整个知识库中检索相关信息，在用户语境之外行成补充，从而提升回答的准确性。
@Jillme 某银行 数据库架构师：
1.数据增强：通过数据增强技术，增强LLM在NLP场景中的表现。
2.改进模型架构：例如采用Transformer-XL，允许模型处理超出固定长度的序列，通过循环机制记忆长距离依赖。或者Longformer 允许模型处理更长的文本。
3.引入或优化自注意力机制，使模型能够更好地捕捉文本中的上下文信息，从而提升语言理解的准确率。例如比如Longformer模型中的局部窗口内密集注意力和跨窗口的稀疏注意力，可以减少计算量并保持对长距离依赖的捕捉。或者通过构建多尺度的注意力模式，模型可以同时捕捉局部和全局的上下文信息。
4.使用正则化技术，例如Dropout，通过随机丢弃一部分神经元的输出，迫使模型学习到更鲁棒的特征表示，从而提高对上下文的理解。L1/L2正则化，通过在损失函数中添加权重的L1或L2范数，限制模型权重的大小，防止模型对某些特征过度依赖，增强模型对上下文的泛化能力。噪声注入：在训练数据中引入噪声（如随机扰动或数据遮挡），迫使模型在有噪声的情况下学习，增强其对上下文的鲁棒性。
5.优化训练策略，例如多任务学习。
6.对模型的预测置信度进行校准，在处理不确定性较高的长上下文时更加谨慎。
@仙守 苏宁易购 算法工程师：
理解为如下2种情况：
1）用户输入信息量过大，信息分散杂乱，导致大模型理解失误。
2）用户输入信息量过小，大模型无法根据上下文理解客户的意图。
针对1），一般可以考虑外加一个前置辅助大模型，由前置辅助大模型负责提炼意图，输出一步一步的思考过程，并最后输出意图结果，然后将这个结果塞给和顾客交流的大模型，从而提升理解能力。
针对2），大模型应用不能离开业务，在一些业务术语选择上，当比如用户问“咨询卡业务”，可以提供一些相近的业务，例如“1）办卡；2）销卡；3）问年费”等等选项给用户选，将所谓的填空题变成选择题。解决其中容易混淆的那些部分。
6、在行内已经有语音、IM等多种客服系统下，如何应用大模型技术对已有系统进行升级改造？
@lidhrandom PAT 工程师：
这里重点介绍一下语音客服与大模型的结合。传统的语音客服基本上离不开ASR和TTS这两个环节，实质上还是将语音转化为文本，在文本数据上进行语义理解等任务。然而，我们都知道语音具备语速、语气等关键属性，这些属性在ASR时丢失，对于客服服务感知用户情绪是非常可惜的。现阶段多模态大模型发展迅速，语音数据向量化形成语音模态下的token的技术不断完善，多模态大模型省去了ASR和TTS带来的信息损失，在客服服务上将能够给用户带来更好的体验。
@仙守 苏宁易购 算法工程师：
针对于现有的客服系统，可以：
1）原有知识库作为rag，增强检索。
2）大模型进行该领域的sft，提升回答的风格和术语等理解
3）通过增加agent的tool去捞取一些比如需要信息检索的事情，统一给大模型做与顾客的回复。
7、大模型幻觉零容忍有什么好的解决办法？
@lidhrandom PAT 工程师：
关于大模型幻觉零容忍问题，我十分认同其他答主指出的现状，我们只能不断向着大模型零幻觉这一目标前进，并不能找到一种保证零幻觉的万灵药。实际上这也是可信大模型这一研究领域下的关键问题之一。针对可信大模型，最近的研究成果—联邦可信大模型。相信在这研究成果的支持下，大模型应用服务可以向着零幻觉的目标大步前进，道路是曲折的，但前景是光明的。
解决大模型幻觉问题一方面是提高门槛，让大模型对不确定的问题避而不答，但更重要的是需要正确的信息输入作为引导。在这方面的开源框架比较被业界认可的是微软出品的GraphRAG框架，它是传统RAG的改进版，引入了知识图谱技术。它通过三元组抽取和子图召回，提供高质量的上下文，以减轻模型幻觉，经过微软大厂验证，效果有保障。
@仙守 苏宁易购 算法工程师：
关于幻觉的定义，以及一些常见的方法相信网上都有不少，个人将其分为：
1）需要动模型的，不管是增加数据清洗，还是模型本身训练中的一些技巧，比如RLHF等等
2）不需要动模型的
刚好最近的工作就涉及到如何解决幻觉，但是个人不是很赞同“零容忍”这个词，毕竟就和测试领域中的名言：“我测出问题，只能证明这有这个问题，但是没法证明他没问题”，你没法穷尽所有可能，所以怎么敢保证零容忍呢。
话说回来，因为工期和成本问题，我还是倾向于第二种，不需要动模型的。
1）首先当然是RAG，这可是万金油，把自己领域的数据做成rag，以此来对抗大模型自己训练集中的知识。但是这远远不够，大模型我发现不止有内在幻觉（说自己训练集中的知识），想通过rag解决这个问题，结果又来个外在幻觉（你给他的rag数据，他都能出错，还有张冠李戴，太严重了，一旦用户问到rag捞取没现成答案的，他就给你加工一下）。
2）更好的prompt，这里面技巧真的说不完，研究不完，这里有个小技巧就是：
2.1）你得一步一步的教他怎么做事；
2.2）千万不要给他总结性的话，他理解不了，最好写成那种if else形式的；
2.3）必须来个角色扮演或者来个玩游戏，这样你给他限定一种环境或者游戏规则，他才不会完全发散到自己内在的知识库（训练集中的知识），比如他会说：“实际中是xxx，但是因为受限于游戏规则，我只能认为yyy”，而这里的yyy反而是你需要的结果；
2.4）遣词造句很重要，我发现 你要是说“不要”，感觉这个“要”字是不是也有一定的概率，所以最好写成“不”，减少文字歧义性（你是不觉得，但是大模型终究就是个attention）。
3）来个前置和后置大模型：
3.1）前置大模型先基于用户对话历史和当前用户的话去分析，并给出一些策略，你把这些策略塞到大模型prompt中，而且前置大模型已经不是对话大模型了，你让他输出思考过程，一步一步的，让他认真思考。
3.2）后置大模型，你把对话大模型所有的素材都输入进去，让这个大模型去判断到底是不是符合事实，也开启一步一步的思考，如果不对，提炼出问题点，然后塞给对话大模型，让对话大模型重新思考。把思考后的结果再真的吐给用户看。
上面就是最近和大模型幻觉斗智斗勇的经验，希望对大家有帮助。
8、在算力资源有限的情况下，如何提升并发推理性能？
在算力资源有限的情况下，提升并发推理性能可以通过多种方法实现，涵盖硬件优化、软件优化、模型优化和系统架构调整等方面。以下是一些常见的方法和策略：
1.模型优化
模型压缩
量化：将模型参数从32位浮点数减少到16位或8位整数，显著减少模型的大小和计算量。
剪枝：移除不重要的神经元或连接，减少模型复杂度。
知识蒸馏：使用一个大型模型（教师模型）训练一个较小的模型（学生模型），在保证精度的前提下提高推理速度。
高效模型架构
使用轻量级模型架构，如MobileNet、EfficientNet、TinyBERT等，这些架构设计时已经考虑了高效推理的需求。
2.硬件优化
利用硬件加速器
GPU：使用适当数量的GPU进行并行推理，可以显著提高性能。
TPU：如果可用，Tensor Processing Unit (TPU) 可以大幅提升推理性能。
FPGA：现场可编程门阵列（FPGA）可用于加速特定类型的计算任务。
ASIC：专用集成电路（ASIC）如Google的Edge TPU，可以用于低功耗高效推理。
混合精度计算
利用半精度（FP16）进行计算，减少计算时间和内存占用，同时利用硬件支持的混合精度计算来维持精度。
3.软件优化
并行计算
多线程：使用多线程技术在单个处理器上并行执行多个推理任务。
多进程：利用多进程技术在多个处理器上并行执行推理任务。
批量处理
将多个推理请求批量处理，通过一次性计算多个输入来提高计算效率。
高效推理框架
使用高效的推理框架，如TensorRT、ONNX Runtime、OpenVINO等，这些框架提供了多种优化技术以提高推理性能。
4.系统架构优化
负载均衡
使用负载均衡技术将推理请求分配到不同的计算节点上，避免单一节点过载。
缓存机制
实施推理结果缓存，对于重复性高的请求，可以直接返回缓存结果，减少计算需求。
弹性扩展
利用云计算的弹性扩展能力，根据需求动态调整算力资源。
5.其他策略
延迟容忍度
分析推理任务的延迟要求，对于延迟容忍度高的任务，可以在负载较低的时段进行处理。
模型分片
将大型模型分解为多个小模型，在不同设备上并行执行推理任务，然后合并结果。
示例方案
1.量化模型与TensorRT优化：
首先将模型量化为INT8，然后使用TensorRT对量化后的模型进行优化。
部署在GPU上，通过TensorRT的批处理和多线程支持，提高并发性能。
2.使用ONNX Runtime和混合精度计算：
将模型转换为ONNX格式，然后使用ONNX Runtime进行推理。
启用混合精度计算，使用FP16进行推理，同时利用ONNX Runtime的批处理功能。
3.负载均衡与缓存机制结合：
部署多个推理服务实例，通过负载均衡器将请求分发到不同实例。
实现推理结果缓存，对于高频请求直接返回缓存结果，减少重复计算。
通过综合运用这些方法和策略，可以在算力资源有限的情况下显著提升并发推理性能，满足实际应用需求。
同业共识
本次活动聚焦于加快落地大模型场景的建设及提高算力资源利用率的难点痛点问题逐个深入分析，总结来看包括了解决计算资源分配管理、系统运行稳定性、提高准确性方法、合规满足个性化需求和数据保护等5个关键问题：
1、计算资源分配管理
大模型在实际建设和应用过程中，对资源使用的需求是非常高的，特别是对GPU的使用，为此，一般采用软硬件结合的资源分配管理提提高利用率。例如模型量化、模型融合与权重平均、异步处理和多线程、系统资源调度、使用高效的推理引擎、硬件升级等策略，在保障性能的同时，有效管理和减少计算资源的使用。
此外建立统一管理平台，通过解决算法与硬件的匹配问题，实现异构的算力资源统一管理，也是未来的发展趋势。但是在建立异构算力资源管理时候，也需注意数据安全的保护。例如通过异构算力资源抽象，为上层应用提供统一的接口和客户端，屏蔽底层算力的差异性，同时确保数据在可管可控的可信计算环境下安全有效进行处理。
2、系统运行稳定性
系统运行稳定性。是大模型应用的基础，需要关注硬件、软件、和模型三者的方向上采取措施保障稳定性。
在硬件层面，通常使用高性能计算资源，提供足够的计算能力，确保模型训练和推理的速度和效率和选择可扩展的硬件架构和适当冗余的设计，对关键的硬件进行热备份，以防止单点故障和在主设备异常后，可以无缝切换。除此之外，最重要的是建立对硬件的监控，及早发现及早维护。
软件层面：例如使用容器化技术（如Docker）和编排工具（如Kubernetes）提高应用的可移植性和可扩展性。进行持续集成和持续部署（CI/CD）。管理好软件版本和测试工作，确保所有功能项的兼容性和安全性
模型层面：主要从模型鲁棒性、模型泛化能力、模型压缩和加速、模型更新策略、模型解释性、多模型集成能力和模型安全性等方面入手。设计时候，增强模型对输入噪声和异常值具有较强抵抗力，通过适当的训练和正则化技术提高模型的泛化能力，减少过拟合。使用模型剪枝、量化和知识蒸馏等技术减小模型大小，提高推理速度。实施有效的模型更新策略，如在线学习或增量学习，以适应新数据。使用模型融合技术，结合多个模型的优势，提高整体性能和稳定性。
3、提高准确性
大模型的准确性关系着用户的信任和使用者的经营决策，在开发和应用大模型时，需要高度重视模型的准确性问题，并采取有效的措施来不断提高其准确性。
训练时候，通过预训练、监督微调、基于人类反馈的强化学习辅助准确的数据和在训练过程中提高回复的准确性。这个过程中，注意的是解决大模型遗忘的问题，通过数据重放或者弹性权重整合，选择合适的模型是常用的解决之道。
实际应用中，增强对上下文的理解，Prompt优化、引入外部知识库来有效的减少模型的幻觉，提高回复的准确性。
4、满足个性化需求
大模型技术的不断发展，需要与实际应用相结合，才能发挥出真正的价值。个性化应用将越来越普遍，成为企业实现价值的重要手段。在实际的建设运营中需要找到一种平衡，既要关注大模型的准确效果，又要考虑用户的个性化需求和体验。
实际的应用中，要考虑首先深入了解客户需求，构建模型过程中，通过选择合适的训练方法，和后续微调优化，反馈建立”个性化”的模型，使用AGENT和RAG等手段，将多源知识融合，并保持不断的优化和迭代，实现满足行业个性化的需求。
5、合规和数据保护
合规和数据保护是大模型应用中必须关注的事情。保护隐私和数据安全不仅仅是技术要求，更是对个人权利和社会发展的必然需求。在大模型的应用中，数据是非常重要的，同时也是最容易被攻击和泄露的，数据安全保护和用户隐私保护是至关重要的，需要采取多种措施给予保护。
在实际的建设运营中，需要采用技术措施和管理措施结合的方式，从管理制度，差分隐私、联邦学习、隐私增强技术到用户控制权、数据加密和访问控制等，来保障隐私和数据的安全性。只有在数据安全和隐私保护方面做得足够好，才能更好地发挥大模型的应用效果。
难点总结：
综上内容，落地大模型场景的建设及提高算力资源利用率不乏成熟的实施方案和解决措施，但行业的差异、业务场景的不同，部署建设模式及管理规则、企业战略的不同，在实际建设运营过程中还需要经过充分的调研论证，必要的验证论证，细化的实施方案，才能达到预期的目标和效果。
