如何基于AIGC技术快速开发应用，助力企业创新？原创

2023-10-302023-10-30 18:19:38播放1.4K

在 AIGC 时代，企业数字化转型离不开 AI 的支持，但实际应用中，技术门槛、安全风险等问题让很多企业望而却步。企业该如何基于AIGC技术快速开发应用，享受科技红利呢？本次直播以大模型、向量数据库、云函数、文件存储等技术为核心，详解解决方案及实践案例，助您实现快速开发，降低成本，助力企业创新升级！

视频文本

温馨提示：文本由机器自动转译，部分词句存在误差，以视频为准

00:05
各位线上的朋友们大家好，欢迎参加腾讯云中小企业在线学堂系列直播活动，我是本次会议的主持人张小平。中小企业在线学堂围绕中小企业业务需求，聚焦企业经营管理、应用工具、技术创新、安全底座四大需求场景，推出系列直播课程，全面助力中小企业数字化升级。在AIGC时代，企业数字化转型离不开AI的支持，但实际应用中，技术门槛、安全风险等问题让很多企业望而却步。企业该如何基于AIGC技术快速的开发应用，享受科技红利呢？本次直播以大模型向量数据库、云函数、文件存储等技术为核心，详细的解决方案及实践案例助您实现降本增效的快速开发，助力企业创新升级。
01:02
在会议过程中，如果您有任何的疑问，欢迎您在问答区进行提问，我们的嘉宾会在最后qna环节为您解答。您可以通过聊天窗口发表您的建议和意见，期待您的反馈。首先有请今天的第一位分享嘉宾，百川智能技术专家高雨晨。高老师长期从事NLP与AI核心产品的产研工作，具备丰富的人工智能与大模型企业场景落地应用的实践经验。今天高老师分享的主题是百川大模型，打造AI时代的超级底座，有请。好，谢谢主持人，呃，大家下午好。呃，感谢这个腾讯云的邀请，来到今天这个呃场合，给大家做这次的一个分享，那今天我分享的题目呢，是百川大模型啊，打造A时代的超级底座啊，我是我来自我叫高雨辰，来自百川智能。
02:05
呃，大家知道去年年底的时候，我们AI推出了其GBT，可以说是一个跨时代的这么这么样一个产品啊，呃。在这个去年年底到今年上半年这段时间呢，可以说是呃这个非常热非常热的这么一个方向啊嗯同时呢，互联网业互联网互联网互联网的业界内有很多这个大佬啊，也都是发表了这个呃呃很多著名的一些言论，比方说这个嗯在今年的GTC大会上啊，我们的这个英伟达的黄教主啊啊当众宣布我们的这个AI的iPhone时刻已经到来啊，并且随后呢，呃腾讯的Pony也宣布了说嗯本来以为这是一个十年不遇的一个互联网里十年不遇的一个机会啊，没想到其实是一个百年不遇的一个机会，呃这像大家所呃讨论的很多人认为呢，这是这个移动互联网时代以来啊最为伟大的一个发明啊呃啊甚至有人呢，会认为这个大模型已经是宣布了这个第四次工，这个工业革命的一个开启。
03:11
啊呃，不管怎么说呢，呃，我们大家很有幸呢，能够诞生在这样一个年代，能够呃在见证这样一个现象级的产品的诞生，啊呃能够在这个这个阶段去做一些相关的一些事情。那么在这个一些嗯，著名的人物里边，有一位是我们的这个王小川川总啊，也是百川智能的CEO和创始人。那么呃，川总呢，可能大家很多人也比较熟悉了啊，在座相信大家应该应该很多人用都用过这个搜狗输入法哈，那么川总有很多的头衔，比方说呃，搜狗的创始人兼CEO啊啊，比方说IOI啊，这个国际信息学奥林匹克的一个金牌啊，比方说是清华大学天工智能计算研究院联系院长啊，比方说这个清华大学的计算机系博士啊等等啊这样一些头衔，那么川总也是在今年四暂啊呃。
04:09
这个官宣加入这个AG的事业，同时呢，同时呢，在4月10号成立了百川智能，我们这家公司啊，一家非常新的一家公司，嗯。但是我们其实发发展的这个脚步还非常的快哈，呃百川在6月15号就发布了，呃这个百川7B啊，当时是在拉马旺，在呃一个这个呃不可商用，不可商用的情况下，我们首先推出的一个开源可商用的一个版本百川7B啊呃并且随后呢，在7月11号发布了百分13B，呃目前也是gib，呃gihab和这个哈face上，特别是哈face上这个下载量包括热度最高的一个呃这个千亿级别的呃百亿级别的模型之一。呃，并且在8月8号我们发布了百川53B的一个模型，这是一个我们首款必源模型啊呃，大家可以在我们的平台上进行一个体验，在八月三八月31号呢，我们啊更是首批通过这个呃备案的大模型，成为了第一批通过备案的这个大模型公司啊，目前一共有八家啊，北京五家，上海三家，那么百川智能作为一个成立了仅仅四个多月的公司，就成为了第一批拿到这个备案的公司哈。
05:19
嗯，在9月6号的以后，在九月9月6号的时候，我们的发布了我们的百川二的一个产品啊，对于我们的7B13B的这个开源模型进行了一次全面的升级，呃，并且在9月25号，我们发布了百百川二的53B的一个版本啊，嗯，同时同时开启了这个呃官方的API。跟这个O是完全对标的。嗯，这是我们目前发展的一个这个呃状况哈。嗯，并且在年底的时候呢，我们会这个发布，我们对对标咱们目前GBT，也就是OA的比较最先进的一些模型啊，我们我们的期望是在年底能够全面超越GBT3.5，嗯，我这两天看到一个非常有意思的评论，一个一个评测啊，就具体是哪个就不说了，它有两条。
06:07
这个结论性的这个话我觉得还是很有很很客观的一个说法，第一个说法是说，呃，国内的目前这些所有的大模型，不管是开源的还是闭源的，不管是大厂还是小厂的啊，呃，可以说是都比较啊，非常接近3.5的水平了啊啊这是第一个结论，那第二个结论呢，是目前没有发现任何国内模型能够有超越或者对标GPT4啊这样一个模型的这么一个。呃，现象啊，目前没有发现有这样一个这个能够对标TPT的一个产品啊，呃，这两个点我觉得还是非常有意思的，嗯。所以百川呢，也是我们比较客观的说，希望能够在年底去超越gpt3.5啊，呃，同时呢，我们希望能够在这个打造了一个比较强的这个底座以后啊，我们去这个推出在平台上的一些超级应用，基于我们这个超级底座啊，去做这个超级的一个应用，所以呢，总体来说呢，我们百川的百川镇的这家公司的一个目标啊，还是去呃这里去打造中国的一个最好最好的一个大模型底座啊，这是我们对公司的一个使命。
07:14
嗯。整体的这个战略方向呢，我们还是分开源和B元两条线一起去走，那么在开源这这部分呢，我们呃，刚才也说了，我们推出了7B和3B的啊，一代和二代的版本啊，我们也是会坚持的走开源这条啊，我们希望能够跟这个广大的开源的啊爱好者，开发者在一起去打造好中国这样一个开源的一个生态环境啊，呃，也就是说呢，我们会不停的去更新的，我们这样的一个7B13B，甚至不不排除这个更大尺寸模型的可能啊，不停的去更新咱们这个呃开源的模型啊，让大家能能够能够随时用上最好的这个中文的开源模型。啊，同时呢，我们也会在也预告一下吧，我们会在这个季度去推出咱们的这个，呃，这个长窗口的一个版本，大家非常关注的一个版本，呃呃，我们即将推出的这个长窗口版本，是一个非常有一个非常高精度的一个长窗口，大家可以期待一下。
08:13
那么在碧园这一块呢，嗯，我目前有这个百川的一代和二代的53B的一个模型啊，呃，目前也是这个在这个，呃。呃，各个各个领域的这个性能还是非常的优秀啊，并且在年底会推出我们的千亿千亿级参数的一个模型啊，希望能够去全面超越gpt3.5。好，呃，刚才有提到百川的使命是去打造一个这个中国的，呃，为这个中国的用户去打造一个呃，强大的一个模型的一个底座哈。那么。有一个底座，其实是其实是一个基础嘛，那么呃，最终呢，我们其实是希望能够利用这个强大的底座啊，不管是GBT啊，还是百川，还是这个呃拉玛啊，呃，或者说我利用一些这个纹身图的一些模型，呃去创去基于这些模型的底座去创造一些呃超级应用，那么目前来看呢，我们可能觉得超级应用分成三个部分，第一部分是生产力提升的一些应用啊，比方说这个new病啊，新型的搜索模式啊，比方说这个gihab的compel。
09:24
啊，这种新型的协同办公的一种模式。那第二种人智能助理，智能助理呢，比方说嗯，Check t PT本身其实就是一种智能助理啊，大家可以经常去问他一些问理啊，问他一些就代码的问题啊，甚至是一些生活中的一些问题啊，都是能得到一个非常好的一个回答，包括像auTo G BT这样的一些概念呢，啊，更加能够去丰富大家的一些，开阔大家一些思路啊，可能让大家觉得这钢铁侠的那个Java斯这样的一些呃，原型可能都呃就是都不遥远哈。那第三方面呢，我们。啊，觉得这个在泛娱乐方面也可能会带去诞生一些超级应用，比方说是mid journey去做一些这个纹身图啊，包括这个character的AI去做一些这个，呃，拟人化啊，做一些这个。
10:09
呃，虚拟人，呃，甚至是呃，包括像斯坦福小镇这样一些这个呃，类似agent多agent的这样一些场景啊，其实都是非常具有想象的空间。啊，只有那么我们也是希望通过这个底座能够去打造一些超级的应用来去真正去创造一些价值啊。呃，那百川二呢，我们目前这个是完全啊，我们7B13B是完全的开源啊，并且能能够在这个，呃，这个各个各个榜单上，其实不管是通用领域还是在垂直领域啊，我们都能取得一个比较这个搜查的一个效果。啊，那至至于53B呢，53B我们是一个闭源的模型，那么我们通过这个高质量的数据体系啊，包括这个搜索增强这两大技术，能够去极大的降低这个模型的呃幻呃模型的这个幻觉。去提高咱们一个这个回答的准确率。
11:05
嗯。在这个百川呢，其实是我们这个大模型领域里边第一家去提出搜索加大模型的这么一家公司，那现在其实越来越多的呃，用户包括个人也意识到这一点啊，其实呢，我们很早就提出这样一个概念，叫做搜索加大模型才是完整的艺术家啊，这个事情怎么理解呢？我们可以从呃这样几个角度去理解，首先呢，就是说嗯。大家大家用其他gpt过程中，其实发现了很多的问题啊，比方说这个最大的是一个幻觉问题，他会他会乱说啊，要么就是这个时效性的问题，因为它的数训年数据仅仅截止到2021年9月啊，再有呢，就是说私有数据的问题，其gpt没有办法去获取一些这用户的私有数据啊，包括这个数据的安全性问题，都是有，都是这个。呃，都是比较难以继续解决的。那么。
12:00
在这个方面呢，我们去结合去结合搜索啊，包括这个啊，我们今天会提到向量数据库这样一些概念呢，能够去极大极大的解呃解决大模型这方面所碰到的一些问题啊，这样能够去更加精准啊，更加实时性，呃，更加强的去呃做一些这个问题的回答啊呃，减少幻觉这样的现象的一个产生，这是第一方面，那第二方面呢，这个大模型的能够这个搜索本身啊嗯，它的这个是一个比较复杂的技术，呃，技术体系，那这里面呢，很多的这个子模块啊，包括很多的功能点，其实是可以用模型直接用大模型去做的啊，这样其实能取得一个比较好的效果，比方说这个意图识别啊，呃，这个实体抽取啊，包括这个。呃呃，金牌等等这样一些关键性的步骤，如果用大模型去做呢，其实能够既简单又高效啊，效果可能也不错。嗯，另一方面呢，这个。大模型，呃，大家知道搜索的结果其实是呃，可以抽象的认为它是一个这个经过高高量加工的一些段落啊，呃或者是一些结构，这个非结构化的一些文本，那么通通过大模型呢，去理解这些文本啊，包括去做一些内容的一个推理和生成，这样能够回答做出一个非常呃这个人性化，并且这个准确的一些呃问题的一些答案啊，而不是简简单单的给你返回几个搜索的结果啊，这是一种新一代的一个搜索的方式，那么大模型可以去这样去解决一个搜索的一个问题。
13:31
嗯，那么百，那么总总体来看咱们的这个路线图啊，就是说百川一方面呢啊，我们去呃打造我们最适合这个，呃，就中国领域啊，最好的大语言模型，呃，大家知道众所周知的原因吧，呃，呃中国呢，是没有，是格力于这个恰GBT的这样一个生态之外的啊，当然这个不是单方面的原因啊，就是呃，美国人也不会想让我们用嘛。那么在这个时候呢，其实是中国是非常需要有，呃，中国自己本土的大模型的公司，包括自己本土的一些大模型的啊，这个是呃不言而喻，那么在这里方这几方面呢，呃呃需要几个特殊的点，比方说我们需要中文的语调的训练。
14:16
啊，比方说我们需要这个内容的生成，需要有具呃符符合这个呃社会主义价值观啊，包括我们这个呃符合中国的一些隐私数据的一个使用规范啊，那么这些只有我们中国自己打造大模型才能去啊，创造出这种符合国情的这么一个呃模型的底座。那么有了这个底座呢，我们就可以结合啊，比方说搜索增强，刚才提到这样一些对话增强等等这样一些技术啊，来够去打造这样一个超级应用，那么能够去，那么这样一套完整的架构搭起来以后呢，我们就可以解决大模型的一些本身的一些问题啊，包括其GBT目前碰到一些很多痛点，其实都可以去很好的去解决。啊，比方说幻觉问题啊，比方说体验的问题啊，包括这个本地化的一些问题啊，隐私的一些问题都是可以去啊得到一个很好的解决。
15:08
呃，那么呃将模型去做一个这个落地啊，我们呃，这是我们整体的一个方案哈，呃，当然这是一个比较比较一个呃笼统的一个表述，那么首最底层呢，我们可以看到是一个模型层啊，大家可以选择最适合自己资源的一个模型，呃配搜索增强和安全增强的一些组件。那么再往上呢，我们会有这个，呃，自己的数据管理和微调的平台，那么这一块呢，我们去。呃，通过这个呃用户的私有的数据是微调，让模型能够理解，呃这个用户的一个业务数据的一些这个呃要素，这样能够去呃定制化一些用户的一些场景下的一些模型啊，这是第一块，呃做这个微调，那第二块也是非常重要的一块，呃就是这个做这rag，包括就企业知识库，也就是向量数据库啊，这样的概念为什么能够最近这么火的原因啊，呃，我们呢，结合腾讯云的向量数据库也去打造了这样一套知识企业知识库，包括rig的一个平台，这样能够去结合用户的一些私有的数据。
16:13
啊去呃，融合到大模型里面去做一个这样一个这个交互，那这样呢，能够非常非常好的去解决，例呃，例如说幻觉问题啊，包括时效性的问题啊，包括这个数据私有化的一些问题啊。啊行，呃，我今天的分享就到这里。好，谢谢大家。谢谢高老师的精彩分享，想和讲师交流问题的朋友请在问答区留言。接下来有请到的是腾讯云数据库产品经理陈一竹。陈老师作为腾讯云向向量数据库产品经理，毕业于中国科学院自动化研究所，我们有请陈老师带来腾讯云向量数据库AG时代大模型的黄金搭档主题演讲。同时请观众朋友们注意，本次直播结束后，将取消腾讯云向量数据库内测，无需申请直接使用，欢迎大家体验。
17:09
更多产品的信息，有请陈老师为大家详细介绍。感谢主持人。大家好，我是腾讯销量数据库的产品经理陈一竹，那今天我分享的一个主题是我们腾讯销量数据库A时代大模型的一个黄金搭档。那其实现在的话呢，我们也经常听到，就AI的各个行业里面，或者和AI相关的一些上下游的行业里面，我们经常在提一个词就是A时代，那在这个通用人工智能A时代之前呢，我们的一些AI模型，它的一个应用呢，其实还停留在我们这个人工智能三阶段的第一阶段，狭义人工智能这个时期。那在这个时期里面的，我们每我们每一个这样的一个AI任务，其实都需要有一个特定的这样一个AI模型来去执行，比如说执行文本翻译的这个模型呢，是没有办法直接用到文章的一个摘要提取，或者说是人脸识别这些更多的一个场景下的。
18:13
那在我们现在这个情况下，有了chat jpt，然后有了一系列拉马这样的一个模型，包括我们国内也涌现出来了像百川这样一些通用人工智能时代的一些大模型之后，我们在不同领域的一个任务呢，都可以用一个交互式的对话形态，并且呢，也可以用一个通用的这样一个大模型来进行完成，不管说我们是要做一个代码段的生成，还是做一个智能问答，或者说我们希望借助大模型的能力帮我们去做一个摘要提取，那其实我们交互的对象呢，都是这样一个独立的统一的这样一个模型的一个对象，所以整体呢，从生产力还有我们的一个交互形态上，其实相对于我们上一个阶段呢，是有非常大的一个质的一个提升的。那这里的话呢，是国外的一个风投公司整理的一个，就是今年来各个生城市AI平台，它按照流量的一个排行榜，那这里也是截取了TOP30的一个结果，其实可以看到啊，除了像gpt这些大模型本身的厂商之外，那这个生成是AI的榜单里面也涌现出了很多基于大模型去打造的这样一些创新型的一个应用。
19:20
就比如说像BTF，还有一些做一些图片的一个生生成增强，或者说是视频生成之类的一些软件都出现了，在都出现在了这个榜单之中。那在这些把大模型应用到具体的一个行业，行业领域的这些这些实际的应用来说呢，它背后其实主导的一个框架呢，还是这种RG的一个框架，它在发挥大模型这些推理和问答的能力的同时呢，通过这个rag知识检索增强的这样一个引导。把大模型更好的应用到我们下游不同的这样一个任务中去。
20:01
那可以看到这一页的话，其实就是我们这个RG框架，它最核心的一个流程线，那这里面的话呢，其实有两个非常核心的一个要素，一个的话呢，就是我们去做计算的这样一个大模型的一个模块，那另外一个的话呢，就是在这之前我们去做知识检索，做做这种检索增强的这样一个啊，数据存储的一个外挂知识库的模块。那在这个流程中，我们直接和大模型交互到底有什么区别呢？其实主要的话呢，就是在我们直接和大模型提问交互之前，会多了一个这样一个检索增强的一个步骤，那在这里面的话呢，其实就像我们去考试之前要去先查阅资料，翻开一些以往的试卷一样，那在这个步骤呢，我们也会给大模型去外挂一个知识库，把我们需要的一些企业的私域知识，或者说我们这个行业特定的一些领域信息存到我们这样的一个外部知识库里面。这样子我们在有问题过来的时候呢，我们可以先从这个外部知识库中去检索，检索出和我们这个问题上下文相关的这样一些补充信息，那再把问题和这些补充信息一起交给大模型，让他去给我们整合一个更符合我们语义要求，并且是更准确这样的一个答案。
21:18
那在这个里面的话呢，其实不管是大模型的处理，还是说我们非结构化数据的一个啊，特征提取的一个形式，其实都离不开向量这样的一个表示方式，那在这里这个外挂知识库呢，其实。很多场景下都需要用销量数据库来去充当这样的一个角色，所以我们也说在这个RG大模型应用的一个时代，每一个垂直领域的这样一个RG应用，其实都很需要一个销量数据库来做这方面的一个存储机的一个支撑。那其实像刚刚展示的那个RG，它核心的一个思路的一个框架，它的一个应用方案呢，是非清晰的。
22:01
那这个场景的话呢，也是我们销量数据库主要面，主要面向的一个场景，就是帮助大模型和大模型一起配合着去做这种知识检索这方面的一个任务。那就比如说我们在去做一个现在可能最主流的一个场景，就是构建知识库的这个任务中。其实我们可以看到啊。把我们的这些原始数据提炼到知识库，其实看上去在reg的框架下呢，是一个非常简单的一个任务，但是实际操作过程中，我们在一步一步去构建这个知识库的过程中，其实各个环节可能都会有很大的一个信息的一个损失，导致我们最终构建的这个知识库的效果并没有我们想象中我们预期的那么好。那首先的话，我们可以看一下我们这个整体的一个流程。首先其实对于我们企业或者说是个人用户来说，我们有很多原始的这样一些知识信息，它都是以一些长文本，一些PDF这种dock文件存储的，那这些文件呢，它一方面呢是数据量非常大，另一方面的话呢，它的一个组织结构呢，也都完全是这种非结构化的这样一个数据，那在这里的话呢，我们其实首先是要对它进行一个文档的一个拆分，把它拆分成我们更好去量化，更好去向量化表示，并且存储的这样一些数据，那在这个拆分的过程中呢，如果说我们在去对一个文本进行分段的时候，把句子从中间截断了，或者说们在去分割的时候丢失了上下文的这样一些指代关系，导致我们的下文没有主语了，那其实这些情况都会导致我们在拆分的这个过程中，丢失很多的一个原始信息量，如果说我们在这一步做的不好的话，可能光是信息量的一个损失就会达到20%以上。
23:45
那在我们完成这个拆分之后，我们要把这样拆分好的文本段去进行量化，那在这一步我们选择的模型，以及它这个模型本身和我们场景的这个适配程度，也决定了我们在这一步到底有多少的信息能够被继续的。
24:01
提炼保存下来。那再往后我们得到一个一个的向量化数据，然后要把它存到向量数据库中，进行一个入库存储的时候，这个时候如如何去构建合适于我们这个场景的向量索引，并且去设定合适这个场景，它的一个索引参数也决定了我们存在这些信息到时候能不能被高效准确的检索出来。那这个的话呢，其实就是我们做知识提取，然后去最终入库的这样一个流程，那在查询的过程中，其实也会有一定的一个信息丢失，就比如说我们一个问题过来了，对于不同的用户来说，我们的提问风格和提问的习惯其实也是不一样的，这就导致我们提出的问题，它的一个质量其实也是参差不齐的，那包括像我们现在在用一些啊搜索系统去做，去用这些浏览器搜索的时候，如果说我们提出的问题啊，我们的表述各方面就是不是很符合。我们这个场景就是。非常凝练准确的这样一些语言的话，可能我们从这个搜索系统拿到的结果也不是我们想要的，那在向量数据库这个rig场景中呢，其实也会有这个问题，如果说我们问的这些问题，他没有去做query增强，没有去提炼这里面的一些核心信息，那我们直接在向量数据库中去进行检索，这个过程中呢，也会一定的这样一些匹配信息的一个丢失。
25:22
所以整体来看，可能从我们原始文档中，比如说我们有100%的一个信息量，那到整个流程下来，最终可能我们能获取到能继续召回的这些信息就只剩50%了，所以在这个过程中，各个环节的一个配合，怎么样去弥补我们上下文。各个环节，他们之间的一个信息的一个丢失，其实都是非常重要的。那接下来的话呢，就介绍一下我们腾讯销量数据库。首先的话，腾讯云销量数据库呢，是我们腾讯集团内部自研的这样一款分布式企业级的一个销量数据库，它的内核的话呢，其实是源自于我们腾讯内部一九年就已经上线的这样一个向量检索引擎，叫做欧拉玛，那目前的话呢，我们这个向量检索引擎欧拉玛也已经服务了我们腾讯集团内部40多个线上的一个业务，包括像览器搜索这些社交线推搜索场景中，还有像游戏这种智能问答AI的场景中，都有非常广泛的一个线上的一个应用，所以整体在成熟度和稳定性方面呢，都是经过线上非常严苛的一个流量考验的。
26:39
然后目前的话呢，我们这个欧拉玛向量检索引擎，在内部每天也会承接到1600亿次这样的一个检索请求量。那另外在检索能力这块的话呢，我们腾讯销量数据库也是支持现在我们各个场景中经常会用到的这样一些检索方式，比如说这种KV的精确查询，还有基于量的一些相似性检索，还有就是在相似性检索的同时呢，也支持根据一些字段去进行混合检索，那这些的话呢，其实也是我们不管是推荐搜索还是AI场景中主要会用到的一些产品能力。
27:16
那另外的话呢，在整个架构方面，我们腾讯云数据库呢，底层也是分布式可扩展的一个架构，它的弹性扩展能力呢，也是非常强的，所以我们单实力的话呢，是最高能够支持到百万级别的一个QS。那另外的话呢，我们向量数据库这儿还有一个非常核心的指标，就是单索引它的一个向量规模。那这个指标的话呢，其实就决定了，如果我去用销量数据库做这样的一个外挂知识库，这个知识库它最大能够扩充到多大的一个量级。那目前的话呢，我们是支持10亿级的这样一个单索引向的规模，并且呢，在这个量级下，如果我们对这个知识库去进行检索请求，各方面性能和延迟都是能够满足我们业务的一个要求的。
28:00
那最后呢，在商量数据库这些本身的存储和检索服务之上，我们还进一步的去提供了一个一站式的一个AI套件方案，那这个方案的话呢，就会更面向于文档检索这个知识库构建R的一个场景，那在这个方案里面，我们也会把这个文档的一个分割，还有这些。和AI相关的内容呢，直接集成到我们销量数据这个一体化的AI套件方案里面来，来进一步降低我们业务接入量数据库接入知识库的这样一个门槛。那另外呢，我们腾讯销量数据库在性能和成本这里呢，其实我们也是和业界一些专门的销量数据产品，以及一些插件式的这样一些啊，就是传统关系型，或者说是一些向量数据，一些传统关系型数据库，它的向量检索插件去进行了一个广泛的一个对比。其实可以看到这边是我们不同实力，它的一个最大QS的一个性能对比。
29:03
最左边的话，这一条都是我们腾讯销量数据库的一个数据，右边这些呢，就是我们类比的市面上的一些其他同类型的一个产品，其实可以看到不管在768维度下，还是128维度下，我们腾讯向量数据库呢，相较于其他产品都有非常明显的这样一个性能的一个优势，那在128维下呢，其实这个性能优势的话呢，会扩大到三倍以上，甚至相较于一些插件式的产品呢，我们在性能上会有接近十倍的这样一个提升。那这个其实也是因为我们腾讯向量数据库在一开始设计的时候，整个技术架构呢，都是面向专门面向向量检索这个场景去搭建的，我们这个欧拉玛内核呢，它最初也是为了服务我们社交线一些搜索推荐场景中去做这样向量检索的一个应用，所以在这里的话呢，我们才能看到我们向量数腾讯云向量数据库相较于其他产品有这么大的一个性能方面的一个领先优势。那另外在成本方面呢，其实这块也可以非常直观的看到，我们腾讯线上数据库相较于其他产品，在整体的一个成本性价比方面也都是有非常领先，非常领先的这样一个水平，性价比也是非常高的这样一款产品。
30:19
那最后的话，其实刚刚也有提到，在整个RG的这样一个框架下，我们腾讯向量数据其实在这块也是做了一些探索，我们也是希望从向量数据库的这个视角出发，配合着我们能做的一些底层改造，去推出一套完整的就是面向这个R生态的一个AI套件。那在这个里面呢，我们希望实现的是一种端到端的这样一个呃，文档检索的一个体验，那对于用户来说，只需要去上传一些文本的一个文件，那平那在检索的时候也是我们只需要根据自然语言来和整个数据库系统去进行交互，像中间的一些文档的一个预处理啊，还有后续的一些量化，这些步骤呢，就由平台去自动化的通过这个AI套件的能力来进行完成。
31:07
那这个里面的话呢，我们可以看一下，我们内部再去做这个AI套件的时候，有几个核心的一个处理。首先的话呢，在文件上传之后，我们首先会对文件去做一个预处理，那这里的话呢，就会对文档去做一些分词和分段，并且呢，也会对文档一些比较重要的结构信息去进行一些提取和解，比如说这个。这段文本，它所属的一些章节的信息，还有一些页码，或者说是页眉、页脚这样一些比较关键的信息，我们都会在预处理的一个阶段呢，通过一些工程的手段去进行一个去进行一个拆分记录。那再往后我们对这个文档进行分段，好之后呢，我们就会通过em模型生成它对应的一个向量化表示。那在后续我们去构建索引的时候呢，我们也会构建多路的这样一个索引，来提升它整个的一个检索效果，那在这里除了我们基于向量构建的这一向量索引之外，我们还会基于文档预处理阶段拆分出来的一些关键的一些词的信息，去构建一个基于词的一个索引。
32:14
那这两个索引方式的一个构建呢？在我们后续整个知识库构建好之后，在我们对它去进行一个提问检索的时候，我们也是会通过这种词和向量的一个多路召回方式来返回出我们最终的一个结果。那其实整个这样的一个形态，我们目前自己测试下来，比我们不去做更多的一个预处理工程化的一个操作，以及我们不去做向量这块的一些核心的一个索引方式的一个改造，相比于这套原始方案来说，我们整个的方案在召回率这块呢，会有30%以上的这样一个性能提升。那后续的话，其实我们也可以看到，这里面还有很多相当于是非常定制化的一个点，可能不同业务对这块的要求都是不一样的，就比如说在文档预处理的这个阶段，我们怎么样去分词，分词的时候有没有一些专有名词是需要帮业务去保留下来的，像这些东西呢，我们后续也会以可视化调优的这种方式开放给用户去自己进行配置。
33:14
把一，就比如说我们之前可能只能留下来50%的信息量，那通过我们这个AI套件，我们做到了百分之七十八十，那后面的话呢，我们用户就可通过自己去调整这些更定制化，更细节的参数，把整个AI套件知识检索的召回率提高到90%以上。这个的话呢，其实就是我们AI套件的一个整体方案，以及我们后续大致的一个演进路线，我们还是希望开放更多的一个定制化能力出来，然后让用户去自己在我们的这一套底座上打造自己专属的这样一个知识库服务。那最后呢，其实我们看到像我们整个AI行业大模型，还有我们销量数据，其实目前都是处于这样一个快速发展的一个阶段，我们目前呢，也都是站在这个通用人工智能时代A的一个门口，那后面的话呢，我们也是希望能够做好大模型配套的这样一个存储基座，然后也和行业和更多的应用一起去拥抱后面可能会出现的我们更好的一些变化。
34:20
那最后的话呢，我们腾讯销量数据今天呢，也是正式开启了全面公测，那各位在线的观众如果说感兴趣的话呢，也可以来我们腾讯销量数据库的平台体验一下我们线上的一个产品能力。那以上就是我今天的分享内容，感谢大家。谢谢老师的精彩分享，想和讲师交流问题的朋友请在问答区留言，接下来有请到的是腾讯云函数产品负责人何世友。可老师现任腾讯云产品中心产品负责人，曾担任艾塞尔CTO与知晓云的负责人。欢迎何老师带来企业级云原生serve深度融合fan和容器生态，加速推动AG创新落地的主题分享。
35:10
诶哈喽，大家好，哎，欢迎大家参加今天的中小在中小企业的在线课堂的这个分享啊，也很荣幸在这里为大家带来啊。就是原生思维的进展，那前面两位老师呢，分别讲了大模型的进展和这个相链数据库的进展，也就是意味着如果咱们要去做AI的AIGC相关的创业或者新项目的一个开发的话，我们已经有了引擎和配套的数据存储相关的这个大脑啊，那缺的就还是下面这一个了，就是跑在什么样的底座上，提供什么样的一个算力的供给，算力的调度这样的能力，那就是今天我要讲的内容。那基本上可以讲呢，在过去的十年发展，服务了很多很多的企业，很多很多的应用啊，基本上事实上所的这个底座呢，刚好是非常非常适合I这个，呃，这个领域，或者说这个这个问题问场景。
36:10
呃，这个场景的具体的问题拆解呢，我们会放在后面来讲，我先说一下，就是本身这一条，呃，这种新的这种技术架构，它发展的这十年里边取得的一些成绩和临新的挑战，包括我们为IC打造的一些新的特性。那今天这一场，呃，内容呢，会分为三个部分，那首先我们会介绍一下斯维莱斯在过去十年里边这个开发方式已经发展的怎么样了，第二呢，就是呃。到当前这个呃时间点，那他服务了这么多的呃应用的上线哈，那他接下来面临的在企业场景里，大规模的应用场景里边遇到的挑战的一些分是I持调度支持。
37:00
一发就是云的形态的发展呢，它会分为三个部分。嗯。就是从1.0~2.0，再到3.0，那到今天呢，我们恰好是站在了中间的这条线，就是2.0，这个阶段就是我们以K为大的底座，统一了整个运维的界面，就是KS帮你去提供了一种云上的操作系统，那它底下呢，是无数个虚拟机，无数个操作系统。那这些呢，会由K来做一个统一调度，由呃这个运维同学或者说这个同学去把一些资源配起来，然后去对接到业务同学的开发的这个服务的上线啊，大概这样的一个调节过程，但这个过程始终还是有一点啊，中间过的阶段就是始终大家还想着是说我开发完一个东西可以马上上线上服务是吧，把这个中间的运维能够节省些，这是所做的一些贡献啊。
38:04
那再往上去呢，大家会认为说开发的工作是不是也可以把多数的这种重复开发，或者说一些偏业务的这样的一个需求转转和表达的这样的一个开发过程给省掉，直接来到这个代码，甚至是I agent这样的一个技术呢？那接下来我们会看到啊，它确实是在这个了，而且也取得了一定的效果。那我们讲一讲2.0目前的一个状态啊。那2.0呢，主要落地的一个产品呢，就是fast function service云函数，那函数呢，它提供的是呃，按量计费，一种超低运维成本，就是基本上是免运维的，就是你只要写你的代码，然后把代码发布上去，它就可以自动的跑起来了。然后在这个过程中呢，它会提供非常好的弹性伸缩的能力，以及非常好的这种超高并发的支撑能力，就是你的代码可能它会同时承载10万并发10万S，那这个平台也会帮你去调度资源，去支持到这一点，不需要你做任何的这样一个加减这样动，这是整个产品所带来的好处，那也因此呢，它在过去十年里面啊，取得了非常非常好的成绩啊，那首先从开发者规模上呢，腾讯云，因为我们有微信生态，有小程序啊，所以我们获得了非常非常多的这样一个端端的开发者的群体，我们呃有全球最大的200万的开发者的群体，呃，在用我们的这个服务来做他们的产品发布的上线服务了，呃，数十亿的这样的一个用户，然后每天的量也是非常非常大的，那同时呢，因为已经过了十年啊，所以各方面的，呃事情呢，他从之前是一个实践是吧，大家都在写代码发布上线做这个事，现在呢，已经来到了一个标准化的时代的，就是当企，就是企业要开始去用平台。
39:45
去做一些事，那他就需要一些这个整个架构的一些规范化，整个架构的一些标准化，行业的标准化，那围绕这一块我们也做了很多工作。包括一呢，是我们在这些评测中也是取得非常好的成绩，第二呢，就是我们在国呢，也是在二一年的新联合推出了fast的国内的一个标准，也是，呃，也是取得了这个标准的第一家认证啊。
40:13
那说说完过去十年里面这个发展和成绩啊，我们再来聊一聊，接下来就是当前这个现象哈，就是企业在在规我们应用它的时候会遇到哪些问题，那企业呢，他和开发者有点不一样的什么呢？开发者呢，他的视角里边就是做需求的转和代码的编写和发布，所以他关心的就是说，哎，我怎么去把这个需求，呃翻译成代码，然后把它代码发布成一个服务上线，然后保证这个服务的可靠性，稳定性去支撑，呃需要去支撑的这样的一个流量，对吧，100QPS 1000QS 1万QPS，这是开发者的视角去关心的，但是企业视角会更复杂，因为企业是个组织，他组织里面有无数个业务团队，里面有各个的开发者，所以他是一个更庞大一点的视角，所以他会关心更多的事情，比如说他会关心财务预算。啊，就是整个的这个研发团队的这种预算，采购的这种资源的采购的预算，包括啊，像呃，管理的中间管理的这个流程的这种这种视角，比如说他需要去做这样的一个管控。
41:12
需要去做这个研发流程的这种效率管理啊，权限的管理，以及风险的管理。然后以及说整个。呃。哎，不好意思。以及整个这种过程中，那他需要可能需要对呃呃底座的这种安全可控，合规等等这些，包括可能每个企业它的流程都是不一样的，业务也是不一样的，所以他需要对呃呃呃底层用到的技术去做一些。嗯。哎，不好意思，刚刚文档这块做了一个刷新啊，以及需要做更多的定制化动作，而另外呢，以当一个企业发展足够大的时候，它会有更多的，呃，从之前的可能单一个语就可以满足他要求，到他接下来要去做跨，要做混合云甚至下云等等这些啊，都是一个企业所会经历的一个非常客观自然的一个发展规律，那在这个基础上呢，它就会需要它所采用的这种技术架构啊，能够满足它各个阶段中的这一些需求。
42:15
这是和开发者有一个非常典型的区别的，而在过去十年里是围绕开发者群体打造的一种产品，所以它是缺少企业使用视角，而另外一点我们也看到哈，就是开发者。不管是一个个人开发者，还是企业里面的开发者，他都是开发者，他的视角是没有变的，就是在他的视角里面，他始终所关心的就说我怎么去快速的把我的代码写完发布上线，对吧，保证它可靠性，这个是一个开发者所关心的所有的事情，所以即使是企业里边的开发者，他依然是非常非常需要一个化的这种平台去帮助他去，呃，只关心业务逻辑，不关心说底下的运维机器等这些。我们面临的问题就是说我们过去十年里边服务了200万开发者，那为他们提供了非常好的这样的一个交付体验，但是在企业这边的企业有更多宏观一点的这种挑战和需求啊，所以我们去满足，那我但而而另外一点我们也看得到，只要我们满足了企业这个诉求，那企业这边的开发者同样是受益，所以带着这样的一个想法呢，我们就推出了新的这种语言生啊一种新的形态，他简单的翻译成一句话就是我们做了两个改动吧，第一个就是。
43:28
我们把sless就是函数这个产品呢，从之前的纯的公有云的形态，把它变成了一种可以跑在企业自己的K8次集群中的一种组件，让他可以随着企业的自己的基础设施，不管你是一个混合的架构还是一个私有的架构，它都可以把这种开发体验通过这样的一个插拔式的形态给带到企业内部去服务于企业内部的开发者。那架构上呢，我们做了两块的一个改动，新的改动一就是的这种运行的过程，我们成为K里的一种workload。
44:05
当然它比普通的K8LOAD也要强大很多，它有自我的运维的能力，自我调度的能力，提供了非常庞非常强大的这种自运维的能力啊，它可以省掉很多运维工程师的这种这种经历和时间，同时为里边的开发者呢也提供了非常好的这样的一个开发体验啊，这是第一个是呃这个运行层面，它可以使用到可以跑在企业自己的呃基础上，那在呃数的这种使层，也就是开发者的这种使用层面，哈提的能力是我们让他兼容了K的CPIBAC这些权益体系和这种呃使用的这种流程，所以它可以被呃团队呢去把它包裹，基于这种中台体系里，可以企业的流流运维流起来，就不破坏企业原本的那个研发流流程体系啊，满足企业的诉求。
45:00
所以在产品能力上呢，我们从呃之前为开发者打造的一系列的这种工具站保持保持它不变，同时呢，我们为技术中台团队，也就是运维团队提供了更多的这样的一个功能的支支撑，比如说我们推这个K8的apic权限，满足他在这种中台体系的搭建权限的收敛这一块的诉求，同时呢，在基础设施上呢，我们也推了这个K8的这种呃资源池的管控能力，使得说呃呃函数在端跑的时候呢，可以受到它的这个资源所位的整体管控，可以满足企业的这种采购啊，这种呃成本预算管控的这种诉求，同时呢，在企业的这种可观测和可定制上的，我们也通过这种运维的工具，也是一并满足了，它可以通过或者说呃，一些统一的这种服务理的能力去把函数也管理起来，从函数之前的一个全头管黑盒的这样的一个状态，变成企业里面的一个白盒状态。那基于这个大的基础之上呢，我们也推了一个非常新型的一种混合资源的一个模式哈，就是前面说到的，就说哎，我们把函数变从公有云变到了一个可以跑在企业自己的一个自己的资源池里的一种模式，对吧？但这个模式呢，始终是有个问题的，第一个问是什么呢？是企业自己的开发集群的资源始终是有限的，对吧？企业不可能说很多钱去买多机器放在里面，它始终是说我满足我这个日常所需就好了，但是一个企业只要它还在发展对吧，它有新的业务，那这个业务就会始终会有这种波风波谷，就有很多的可能来一波流量的，做一个活动，做个运营活动马上卖爆了，对吧？这种是时有发生的，但是企业呢，在传统的运维模式下的，这个也是非常大挑战的，就是他需要提前好几天去备很多资源去加在里面去，会产生很多很多浪费，但是也不一定估得准对吧，你因为你的活动好与坏，这个很难评判嘛，就是很有可能就是你备了100台机器，然后瞬间来了一个要上万的机才能支撑的，这你就搞不定对吧，所以这就。
46:56
说企业自己的资源池的这种模式呢，可以满足企业的管控啊，采购等等这一系列的企业管理诉求，但是在应对业务的这种商量诉求的时候呢，它始终还是有瓶颈的，那我们就推了一个混合增持的模式，可以可以解决这个问题，他怎么解决呢？因为函数呢，它是一种免运维自我调度的一种架构哈，所以它是可以感知到它所在的资源池的供给情况的。
47:21
所以我们就推了一个叫做混合资源，怎么做呢？就是当你函数和你的K8集群绑定之后啊，它优先可以使用你自己的这个K8句型里面的资源，但是一旦他发现。进来的流量请求，你这个资源池无法满足的时候呢，它就会自动的把把这个请求路由回这个公有云弹性资源池里面去，用公有云的弹性资源去满足这个请求的执行和响应。这就使得说，诶，你企业是可以被自己的一个池子来满日常所需，但同时呢，你可以借助这种弹性的官员资源池啊，去满足业务的这种呃，日常的这种时的这种呃溢出的这种算力的需求，这样就可以达到一种成本和这样的一个业务的可靠性，就是业务的可用性的一个一个双重保障。
48:12
啊，这是第一个点，第二个点呢，就是说现在很多在K群的这个企业都会在尝试做。就是因为在线业务它始终是波峰波谷的嘛，我被比如上千台上万台机器是吧，它始终会有一个冗余和浪费。但是为了保证它可靠性的，又不可能说缩减很多，所以始终要解决，就是说我怎么去把这个浪费降低一点，对吧，这个我相信也是很多这个运维团队啊，背一个年度的KPIO啊，那传统的这种这些呢，有一个然的缺陷就是很业需要业务团队去配合，你去告诉你说，哎，我这个业务这个这个服务是吧，他能不能够被抽取资源，以及说他能不能用这种抽取出来的这个不稳定资源，这个很难做，而因为是个生，就是动的调度这样的一种方式，包括它本身每一个。
49:05
在创建的时候，它是指定了规格，指定了超时时间等等这些的，所以对于函数来讲呢，它非常非常适合于这样的一个不稳定资源池上的一种运维，因为他可以非常灵活的调度嘛，当他发现你这个抽取资源不稳定的时候，他会些在他会马上把这个任务调度回一个稳定的资源里面去跑，所以他可以灵活的在你集群里在线抽出来的这种。呃，闲置资源就是不稳定资源和稳定资源就是云上的稳定资源之间去做一个灵活的调度调配，因此呢，就可以很好的解决这样在离线步中的这样的一个呃难题吧，也就可以成为一种新的这样的落地形态啊，我们也是借助它来落地的，很多业务后面会讲到，那我们首先小结一下，就是新的这种产品模式呢，它为企业和企业里面的运维团队，企业里面的业务开发团队啊，都带来了非常非常好的价值。那我们讲两个案例啊，第一个就是在腾讯云内部啊，我们内部有一个技术中台的一个这样的一个形态，服务于内部的开发同学啊，我们也是在里面引入了这样的一个新的这种的这样的一个呃，插件插拔式的这样的一个开发体验吧，推出了一个叫任务中心这样的一个形态，它基于原本的K大盘里边作为一种新形态的load去让开发者呢，可以借助函数去做它的快速的代码编写，代码的上线啊，有非常好的这样的一个维的和这样的一个自动的这样种体验哈。
50:32
啊，也是啊，签了很多的业务上来，表现的也非常好。啊，同时呢，因为这种这种集成呢，也是兼容了，原本啊，就是内部的这种研发体系的这种统一的，像那个啊权限管控啊，库塔呀，审批流啊这些，所以呢也是。这块也是提升比较大，是满足了腾讯一个企业企业的这种这种要求，同时呢，一些定时任务就是job job这种的场景中呢，它也表现的更加优越，因为它的这种启动速度啊，以及它的这种可靠性保障更好一些。
51:08
然后有个实的上线业务啊，就是有一个视频转码审核的一个业务，它因为它是审核的，就转码转的是这种C上的视频，所以所以它是一个典型的C端业务，有非常明显的不波谷，然后呢，他又要求说一个视频上传过来，我要在三分钟里面把它整个完成掉，超过三分钟就算失败了，所以它有一个典型的端端端延迟。呃，这个待会在场景也些是的，要指定时间里边去完成所有的事情，然后同时呢，这个请求本身呢，又是一个极其力的一个过程，所以它就是一个非常非常大的挑战啊，那原本的这个这个业务它的一个架构是什么，他是用了一个虚拟机啊，用了10万盒机器去撑它，那很典型的两个问题嘛，第一个就是说太浪费了，对吧，因为10万核机器就就是为了保证它波封的时候的业务的需求，然后到了半夜的时候，其实基本上可能就几千几千盒这个就够了，就浪费了九万多盒，非常非常浪费，然后同时呢，他播峰的时候还是难免会出现一些堆积和失败。
52:14
因为业务的商量情况其实不不受我们管控嘛，对吧，就是用户多了自然就会上涨，所以他始终会出现这种浪费和失败的这样的一个叠加问题，而切新的方案。那业务呢，是从他原本的一个另外一个业务的K8群中去抽取资源哈，抽的也是个在线累集的那个资源，大概能抽个2万盒左右的样子，然后再用函数这边的这种化的这个弹性的的6万核的资源把它堆起来，那这样呢，基本上就可以实现几个很很好的效果吧，第一个就是说原本那个业务的在线集群呢，它通过这种抽取再复用，其实其实是是实现了一个利用率的提升的，从原来原来的45%提升到65%，这是非常大的一个提升。第二呢，就是说他通过这样的一个混合资源池的方案呢，也把它原本的那种波峰浪，呃，波峰堆积失败的问题彻底解决掉了，就是因为它非常灵活的能够马上补上去，把这个任务堆积的事情给解决掉，然后同时呢，就是他播谷的时候，基本上没什么浪费了，因为弹性的这种呃，供人的资源池，基本上他不用的时候就会给别的业务去用去了，没有没有占用的情况，然后在线业务呢，他在播在在的时候抽取的时也也也不存在浪费嘛，因为本身。
53:28
的。所以新的这种架构呢，为传统的这种业务啊，带来非常非常的收益，同时解决了开发者和企业的这种难题，那我们就可以看一下它在A场景再场景配套的这种销量数据库搭配起来，把自己的业务代码也写好了。当你要发布上线了，你会遇到的问题是什么呢？目前问题还蛮典型的，就是大家也都知道，就是说GP卡始终供应是不足的哈，美国也一直在对咱们去做一个禁售，所以高端的八呀，A8不仅仅是的问题啊，是买不到的问题啊，就资源非常的稀缺，然后即使是来到T4卡呀，十卡这些啊，以及30904090这些消费卡啊，就说便宜一点，但是没有便宜太多是吧，也很贵，所以就变成了什么呢？变成了一个算力极其紧缺又极其昂贵，那当一个极其紧缺极其昂贵的这种资源。
54:27
变为一种常用资源的时候，那事实上我们的应用发布，我们的应用的上线哈，其实都。要先去找什么，找一种集约型资源嘛，对吧，就是你你可以找个平台去灵活的给你供货，你不需要去花高价钱购一堆放那里，因为你预先采购它必然预面临的就是传统的预尾难题嘛，就是要不浪费，要不不够是吧。所以需要一种量费的这样的一个平台，以及说一个能够供就你的流量上涨的时候，能够你活供更多货的这样的一个平台。
55:04
所以刚好是非常非常满足这个场景的，就是。他在这样的一种资源紧缺的情况下，可以为小的创新型的业务哈，在孵化期能够平稳的度过，就是你一开始的时候也不需要太多嘛，这个平台可以帮你去的供货，你不需要提前很多钱去锁定一些资源啊，这个是采购价和这种啊资源供给的一个层面的一个难题。是的，是有一些问题在决中，比说G拉的种速度很明显C对吧，10G样的个启动起载模是个G个，还是挺挺难挺难的，所以这个时候就需要结合一些。
56:05
啊，混合架构来解决这个问题，后面会讲到这一点啊。然后第三，呃，然后另外一个就说开发过程其实也会面临一些问题，就是因为新这个还是个很新的场景，加上呢，它是一个在线业务，对吧，你提供出来的其实是供这个C用户去用的，所以它是一个在线业，同时呢，它又是一个对算力算力的消耗比较大的业务，就是你的一次会画，其实它可能就需要消耗一张卡半张卡。所以就是一个重计算业务，重计算的在线业务，所以它和传统的我们做那种web service是吧，一个在线的外部服务它不一样，在线的外部服务呢，它是一个。啊，轻计算的场景就是它可能是个重IO的场景，它里面对CPU的消耗不是很大，所以事实上我们很多时候啊，都只用一台机器去称一个上千S够了，因为这时候一机器CP么够IO颈，而而新的这种景呢，带来了这样的一个开发挑战的一个难题哈，那这个地方呢，我们也是接触平台的能力哈，去支持说你只要把它打包成一个传统的定向，然后发布上来，那他就可以帮你去，呃解决这样的一个算力的供给和中间的这种运维调度的能力。
57:22
嗯。那刚刚说到的就是普通的一个推理的场景，对吧，当你把模型准备好了，你发布成一个应用了，那你大概可以借助这样的个平台去完成你的呃扩存容你的按量付费去取得一个效果和成本的一个双收益，而我们还要看到一个问题，就是说接下来啊，有很多，因为国内有很多家在自己搞这种大模型的嘛，目前呢，其实他们的模型大多数也已经出来了，发了几个版本了，对吧，像刚百川也发布了他的53B以及7B和13B的这样的一个开源模型，我相信很多公司啊，他已经入这样的一个底模，就是他发布啊这种开源模型去做了自己的微调，然后做了自己的这种上线了，那这中间呢，会及到个什么问题呢？就接下来随I的呀，很这种问。
58:10
就是可能有些模型，比如说我是三，它是的，对吧，它不会说像开源的，它布是一个模型文件社区里面，然后你拿来自己用就好了，它会涉及到一个商业交付的问题，就说这种模型呢，它往往是不能够开源出去的，它不能够直接给你，但是他给你，他需要给你提供服务，对吧？那它会提供什么样的服务呢？很有可能提供的是一种啊，你提供一个推接和微调接口，然后你提供自己数据，提自己的其他的一些数据等等这些吧，然后去过这样的个中间交互，去在它的模型上做这样的微调，以及最终的推理的服务的提供，在这中间会涉及到一个双双向可信的问题，就是53B这个模型是不能够给你去拿到的。不能泄露。同时呢，你也不希望说你的这个数据被百川拿到是吧，所以就涉及到中间的这样一个交互，那这里面呢，我们也在预言一种新的交互方式，就是通过一种双向可信的这样的一个托管交付，就是提供一个中间的一种平台，然后让这种平台可以使得说你的数据归你所有，模型数据归模型提供方所有，然后在中间呢，可以在这个环境里边，双方可以去达成这样的一个数据的交换和这种最终的服务的提供。
59:26
然后里边呢，也可以助平台的能力呢，去提供这样的一个性的供给啊，能够现前页种平约性。嗯。前面说到就说整个大的面上哈，我们提供了平台的能力，同时呢，我们也是提供了一个呃，为开发者吧，提供了一个很好用的开发者和中型企业啊，提供了一个很好用的这种开用的的这样的应用啊，就是比如说第一个我们提供这个一个托管，就是我们发布成了一个应用模板，在目前在呃腾讯云的控制台上可以直接看到，可以直接去用啊，目前是一个全开放的一个一个一个一个状态了。
60:11
然后也是有上万个开发者已经用上了，也已经开发出了很多的这种产品，已经上线去使用去了，那它的使用方式呢，非常简单，就是你只需要去点两下去把它创建成就可，你可想用，你就可以创建出来一个自己的了，你可以有自己的有自己的API了，然后就可以集成到自己的这个业务中，或者是把它交付给自己的设计师团队去用去了，然后在这个里边呢，其实呃，创建完之后啊，就是设计师用的时候呢，他不用关心说底下到底有几张卡。然后以及说它的模型文件，以及它的插件，这些要怎么去管理，要怎么去运维，这都不需要，这个应用已经帮你搞定了，你所需要关心的就是说，呃，你的业务要怎么去。你的业务要怎么去去对接它，要怎么去集成它就好了，然后它的使用方式，使用过程呢，也是集成，也是利用了很多这个原本的这一优势哈，按量计费啊，免运维啊这些包括GPU调度哈，我们在底层也是做了很多调度层面的一个支持，所以只要你的业务药哈，基本上都可以供给的上。
61:19
OK，然后呃，这个是C辐的，像那个拉相关这些我们也在推进中，那如果你有需要呢，可以随时找我们，然后我们可以来支持你的这种的这种创新业务的上线，能够让你享受到这种的这样的一个整体的体验啊，能够帮助你真正的在低成本的这种前提下去完成你的业务创新。那对于企业来讲哈，就是当他真的要上量了，对吧，首先要保障就是业务的可用性嘛，就是虽然说你的平台可以提供很好的弹性的这种资源供给，但是始终是弹性的嘛。而且现在GP整体是不足的是吧，你也没保证说我一个地域的，我今天要100，你真的我出来也难以需要做一个打对吧，我需要先个几十卡锁定的，就是我我要用的，然后呢，再把溢出的一些流量转成这种在线的弹性的，所以呢，我们也是借助前面说到的啊，混资源的这样的一个型的构去把这一个问题解决，就是在新的这个模式下呢，你可以去把数T群去做一个融合啊，然后在TK群里面呢，去固化你的一些这个自己的卡，然后用函数呢来供给一个弹性的CPU的卡来满足你业务诉求。
62:33
啊，基于这个呢，可以很好的满足你的业务的需求和整体的成本的下降。那以就是今天的呃，要介绍的这种平台，I景提这样的一个能力支。啊，感谢大家。好的，谢谢老师的精彩分享，想和讲师交流问题的朋友可以在问答区留言，接下来有请到的是今天最后一位分享嘉宾，腾讯云文件存储的产品专家杨飞。
63:03
杨老师相验讯C和丰富的产品化经验，聚焦于AI、自动驾驶、hpc、大数据、存算分离场景等高性能的计算场景，有丰富的业务实战经验。欢迎杨老师带来腾讯云文件存储cfs大模型训练数据底座的主题分享。嗯，好的，我共享一下屏幕。嗯，那个我现在这个屏幕是可以的吗？那个那个主持人。可以您继续好行，呃就是呃很高兴有这次机会跟大家去分享一下，就是呃腾讯文件存储在这个大模型训练这一块的一些实践和我们所看到的一些经验的情况，然后本次分享的话，主要是分为三个部分，然后这是三个部分的话，它会呃根据它不同的阶段去做一个就是啊交替式的一个讲解，就是我们会先介绍一下整体就是大们训练相关的设计的一些主要阶段，然后每个阶段它对应这个挑战，以及我们在这个呃挑战下的话，我们所提供的整体的解决方案，然后呃因为呃前面几位就是讲师讲的就主要是就是更偏上层一些的一些方案，那么其实我们呃在这种AJ时代下的话，其实呃，大模型的话是这个一切的一个基础，那么我们腾讯文件存储的话，它主要是啊，提供的这个方案是解决在大模型这样海量数据训练的时候，那么我们在提做在存储这一块的S层能够提供什么样的整体的方案，然后是。
64:51
去加速这一大模型的快速的训练，以及它相关后续版本的一些迭代。然后呃，我们当前其实看到的这个大模训列的话，主要分为这么五个阶段，然后其中这个呃，Models service的话，它其实并不是完全的必要的一个阶段，但是其他的这几个阶段，基本上啊，只要去做大模式训练的话，或多或少都会有一些，然后第一个这那个什么阶段的话，其实啊，尽管一部分厂商它可能会有一些自己的一些数据，但大部分的整个训练的阶段的话，其实还会依赖一些公网的一些数据集，就包括从互联网直接采集的一些数据集和一些啊过去可能已经整理好的一些啊，这种标准的那个那个数据的话，其实都是可能作为它的一个样本中的一部分，所以说第一部分的话，可能是会涉及到一些在公网上去做相关的一些数据爬虫的一个处理，那么那么这里的话，其实呃，就是我们更推荐的用户就是使用云上的服务去做相关的一些操作，因为整个云上它的这个可用区其实是非常多的，呃，就是我们在那个，呃，国内和国外的话都有对应的这样的一。
65:56
一些机房，那么它都有比较充足的这个过网带宽去提供给用户，去做相关的一些数据爬重的这样的一个处理，这个是他我们看到就是数据采集这里的一个情况，这里的话整体没有什么太高的一些要求，就是一个基本的一个爬虫的一个过程，然后第二部分的话，其实就是说是当你把数据采集上来之后的话，那么你可能会涉及到一些数据清洗的一个动作，因为你的这个呃，训练的数据样本的这个质量的高低的话，将直接呃决定于你后续的这个大模型，它整体的一个表现的一个效果，如果你的样本的这样的一个质量特别低的话，都是这种废话的话，其实你整个大模型训练出来的效果也不会特别好，也不能够达到用户的需求，所以说那么在这个阶段的话，其实就会对已经采集上的数据做一些清洗，那通常会使用到一些啊，Map reduce的这种方式去做清洗，比如说驱虫啊，或者说是把部分的一些不太好的关键词去做一些过滤，或者说一些更复杂的一些清理方式，但总之的话，基本上都会是通过这种大数据的方式。
66:56
去做相关的清洗。然后。你然后第三个阶段的话，就是当你把数据清洗完之后的话，那么你可能会涉及到这样的一个数据训练的一个阶段，那么这个数据训练的阶段的话，就是啊，会涉及到这个你样本数据读取以及你在啊，比如说几千台机器在训练的时候，如果你有出现中断的话，那么你需要把这个切后呢，及时的去做相关的一些啊写入，然后去保证你将当你的训练出现异常的时候的话，你能快速的回滚到上一个状态，那么呃，你写完切碰之后的话，其实你后面还涉及到就是说如果你出问题之后，你怎么样非常快的把这个切后能能够恢复到你的机器上去，就是回到一上一个这个时间节点的这个时间状态，然后继续去训练，那么你说如何写的话，其实都会有比较高的这个要求，然后第四个点的话，那个就说是呃部分厂商的话，就像呃，无论是百川还是国内的一些其他的一些做啊大模型的这样的一些厂商的话啊，他们有的会直接通过这种API的方式，就是类似于这种啊GP的方式，就是我暴露一个直接给用户。
67:59
能够使用的这个接口，让他能够去啊提问啊，或或者说是提出一些就是这种pro的这些情况，然后然后又通过这个大模型再去返回它的结果，那么除了这个之外的话，其实还有一些，呃，就是厂商的话，他可能会考虑就是说我做的是一个基座的模型，那么我基座的这个模型的话，我希望把它能够啊推广到一些更多的一些更垂直领域的一些细分行业里面，那他可能会去把它这个基座模型提供给一些，比如说垂直领域的，比如说啊金融呀，或者说是医疗啊，或说能源的这些行业，在他们这个细分的领域上提供一些特殊的数据，就是跟这个垂直领域的厂商去做结合，把这个机座模型在这个垂直领域里面能够得到一个调整和调优的一个情况，然后让这些啊，垂直领域的这些对。
68:48
就是大模型底层训练不是特别清楚，或者说是不是那么擅长的这些，呃，厂商能够快速的呃得到这样的一一种就是大模型在他们这个领域上使用的这个能力，那么这个是我们说的models service，然后然后这的话，其实对存储也会提提出一些挑战，那因为这个其实不是特别多的话，就是本次的分享就不会啊用特别多的时间去讲这个model s service里面的一些细节的一些需求情况，那么去呃当呃这个数训练完，或者说这个models service提供完之后的话，其实到最后一个阶段就是呃基本上就是说像类似于这种呃gpt的这种方式，就说我们把这个大模型已经训练完了，那么我需要把这个模型去能够啊，把它的整个已经训练好的这个模型做成镜像去息发到我的这个推理服务节点上，然后对外去提供这样的一些推理的服务，然后这个里面的话就会涉及到就是我怎么样快速的能把这些镜像能够分发下来，同时的话，用户上传的数据的话。
69:48
什么样的能够比较高效的存储下来，然后这个是我们看到的整个大模型训练的这么五个主要的阶段，那么那么接下来的话，我会快速的在那个，呃，每个阶段都讲一下这里面的一些关键的需求的情况。
70:02
就是第一个的话，就是说是在数据清洗，因为就是刚才讲的，就说整个呃，基本上目前我们看到的一些数据清洗的阶段，就就是会去做数据清洗的厂商的话，它都会用这种大数据的生态去做相关数据清洗，那么我们这里的话，其实呃在传统存储里面，可能呃文件存储它本身能够提供这种呃就是呃。这种HDS相关的一些接口的插件，那然后呃，过去在云上的话，当前主要是使用对象为主，那么我们是啊，嗯，在这个并行文件存储的这个啊，产品下的话，我们也是能够提供这样的能力，主要就是帮助用户，在这种就是啊，大部渲的时候，它涉及到数据的啊。流转，比如说它后面才会涉及到用GP机器去读取，那么你在前面的话，你最理想的方案就是把整个数据都统一在一个一的资源池里面去访问，那么它这里数据流转的这个开销就会是最低的，那么我们是在呃公有云的这个，并且文件存储的这个基础上的话，是能够无缝的对接到公云的大数据的生态，但是说你如果说要自己去自建那个呃海的话，其实这个也是都可以去做无缝的对接的，它起到效果的话，就是说我们这个数据你一旦采集进来，那么你可以直接从文件存储上去做相关的一些呃，Map reduce的任务，然后去清洗完之后，然后再把数据存到文件特试里面，这样的话它就达到了一个从像分离的一个效果，然后同时你数据也不需要去额外的流动，比如说你采集的时候，你先采集到本地硬盘，然后再挪到对象参数里面，然后再做分析，然后再挪回来，这这样整体的其实时间上的一个开销和就是呃，操作上面的复杂度还是会比较高的。
71:47
所以说这个的话，其实就是我们在这个数据清洗上能够提供的这个能力，然后我们呃，实测的情况下来说的话，就是我们在map这种任务并发的这个读写的情况下的话，其实都是可以把我们高清文件存储这里带宽都啊完整的打满的，就是我们实测的话是能够到达啊100GB以上的带宽，无论是读还是写。
72:08
这个是在数据清洗阶段的一个能力的情况，然后然后第二的话，就是在数据训练的一个情况，就是我们呃当前看到的就是大完全训练的话，其实呃，它是主在在训练里面的一个比较细分的一个情况下来说的话，它主要有这么几个情况，就是我们如果是首先从计算的这个角度来看的话，它其实简单讲就是一个训练阶段接着一个训练阶段，然后在不同的训练阶段之间的话，为了保证你的这个训练任务中断之后，你能够有一个能够回滚的这样的一个就是。有一个回滚的数据的话呢，其实他会去做这个切point的一个保存，那么这个保存的话，在切的时候的话，其实它并不能够去做训练，那么其实呃，从整个计算的这个情况来看的话，就是你尽可能的去降低你切破的写入的时间，那么你整个在。
73:00
呃，GPU的这个利用率上，就时间上的利用率来说的话，你就能够比较呃更高的这个比例能够用于你实际的训练的一个情况，但是你如果说是完，就是把这切碰的这个呃频率调的特别低的话，那么你一旦出现这样的一个，无论是掉卡，还是你软件的bug或者什么其他的原因导致你训练中断了，那么这个情况下对你整个的损失也是很大，所以说目前来说呃业内的一个主要处理方案就是说尽量还是保证在四个小时左右，你至少是需要写入一次切的，然后尽可能的通过这种高性能存储的这种写入技术，去保证这个切写入时间尽可能短。这样的话就是能够在保证频率一定的情况下，你仍然能够呃比较高效或或者高利用率的去使用你整个H800GPU的这样的一个资源，这个是在计算视角上去看的，那么在存储的话，就其实就是说你呃我们整个在呃他文系统里面的话，其实呃它整个切控写入的话，都是能够支持这种基于缓存的异步写入，也就说它整个切控写入的话，第一步会先落到H800GPU机器的这个内存里面，然后同时呃服务端就是我们的在客户端上的话，会异步的去把这里的内就是在内存里面写入切碰的话去刷入到后端文件系统里面，就是我们会看到，就是说是当它的呃切碰零写入完，就是再假如在这里是切碰零写入的话，那其实它会在你下一个训练阶段的时候，就是会异步的把这个已经写入完成的切破零的话，去异步的刷到后端，这样的话就是尽可能的去，呃，把你整个时间都能够复用起来，然后的同时的话就是你在异步写切POINT0的时候的话，你当训能。
74:38
的时候，你会涉及到一些样本的读取，那么这个的话会贯穿在整个训练的一个阶段，然后但说因为我们当前看到就是大模型，整个训练的话，它主要的时间开销还是在计算上，也说简单讲就是它的数据其实并不是呃消耗的特别快，因为它计算的耗时比较长，有比如说我单位时间能够训练完成的这个，呃投的数量其实并没有那么多，所以说我们当前看到像这种啊。
75:07
这种这种训练样本的这个读取的话，其实它整个在存储性能上的开销不是特别大，比较大的还是说是我怎么样能够在尽可能短的时间内把这个切能够完整的写入到。分机系统后端，然后让训练从一个阶段进入到下一个阶段，然后然后这个是我们呃一些云上已经有的一些用户，他在这种几千卡规模情况下的话，它整个使用我们高层并行文件存储做切的呃，写入的时候，它的这个带宽的情况，以及他实际在做样本读取的时候，它的一个带宽的情况，就是我们可以看见，就是说基本上的以单台机器为例的话，它其实整个读取样本的带宽反而是非常低的，就是差不多只十兆的一个水平，你如果是一个呃一四千卡的机器的话，4000卡的规模的话，对应的话就是500台机器，500台机器每台机器十几20兆的话，其实它整个的带宽也就是五到十个G的一个状况，那么它整个的压力是比较低的，那么我们现在看到的主要的一个啊，带宽压力，主要是在说它这种。
76:08
大几百台机器，比如说以四为例的话，它就是有500台机器，在这一个训练阶段快要完成的时候的话，那其实。他去做这个切换的保存的时候，就会有500台机器并发的去写入这样的一个比较大的一个切换的文件，那么这个时候的话，它反而带来的整个带宽压力会比较高，然后我们看到的话，基本上就是这样80个G大B左右的一个状况。然后然后在，然后在这里个可能可以单独再提一下，就是我们当前看到的话，就是切换的话，呃，基本上以175B这种模型为例的话，基本就是在两到三个T的一个状况，然后我们当前是能够做到在一分钟以内，就是啊业务就可以把这个情况写完，然后进入到下一个训练阶段，那么你整个在这个呃前方以上的一个写入的时间开销的话，就会占比会非常低，相当于是这是呃四乘以60就是240分钟，然后加一就是241分钟里面只有一分钟是没有在。
77:07
计算的，比如说你的整个利用率是二百四除以241，这样的话，其实已经到达啊，可能百分之九九十九以上了，对这个是呃，我们看到这个情况，但是说我们在实际上在支持到这样的一个呃快速写入的背后的话，其实会有非常多的这样的一个技术能力去做支持，然后首先是讲一下我们在这里啊条例化的一个能力，就是说我们整个呃，因为大模型切构写入的话，基本上都是大文件为主，基本上是G比级以上的大文件，那么我们一个全分布式的文件系统的话，就是如何去处理这种高并发的，就是呃，海南大文件的一个写入的时候，其实这个调料号技术就会比较关键，那么我们是。呃，有这种渐进式的这个条代化，就是会根据你实际的文件大小去分配它的一个化数量，然后你的文件越大的话，它能够分配的条例化的这个数量就会越多，然后它越多的话，其实你整个在后端服务的时候，它就越不容易出现这种单点的瓶颈，因为你如果说你的文件都集中在某部分节点上的话，那这个后端服务节点如果出现一些瓶颈，或者说是啊有一些热点的情况，那么这里对业务侧直接的反应就是它写入速度变慢了，或者读取速变慢了，那么我们通过这种调件化技术的话，尽可能把它的这个批量写入，然文件能够分散在我们多个节点上的话，那它整个的这个热点效应就会就是出现这种热点的情况就比较少。
78:30
或者说是我们在呃已经呃成熟应用的这样的一些，呃，就是厂商的实际使用情况来看的话，他们就是基本上不会碰见这个热点的这个问题，然后对于用户业务，就是整个写入速度是非常平非常快，也是非常稳定的。这个是在我们这个呃处理大模型上的，就是大文件上的一些技术，那么呃，除了处理大文件上的技术的话，其实我们还有一个比较有优势的地方，就是说我们整个客户端，它是一个专有的客户端，然后这个客端主要是解决了传统这种NFS网络客户端，它这个单链接的问题，主要是解放了，就是你当一个客户端写入海南大文件的时候的话，它的这个单客户端的这个写入速度的问题，然后我们这里的话就就是一个客户端，因为我们H800的这种机器的话，它整个的硬件配置都是非常高的，就是它呃网络的网卡是100G小B每秒的，然后呃，整个CPU核心数如果是算上超线程也是100个核以上的。
79:30
要不在。这个情况下的话，就是说，如果说你在用传统客户端的情况，你很有可能会出现你单客户端出现这个瓶颈的问题，那么我们用这个专这个专用客户端的话，其实就能够比较好的解决你单客户端出现瓶颈的这个问题，能够使得你的呃实际大文件写入的速度可以把你整个网卡打满。这个是我们在呃专客户端上的一个优势，然后除此之外就是刚才有讲到，就是我们在整个呃写入的时候的话，它并不是直直接完整的都透传到后端上，因为比如说你要呃很快的写入你这个数据的话，其实你要求后端的能力就会非常非常高，比如说你要一分钟写完1000个G的话，那你其实你需要的带宽就是1000G除以60，那么就是差不多是在啊15G大B每秒，但你如果说是你需望5T的时候，呃五个T数据你需要在一分钟写完的话，你需要再再翻五倍，那这个的话，整个的呃对后端的性能压力就会比较高，然后你。
80:30
就是我们当前看到很多用户，他其实呃，实际在大模型存储的时候，它数据量并不是特别多，那么你一共就是在这种呃，1200T甚至更少的这样的终端情况下，你要提供这么高的带宽能力的话，其实呃从实际的物理层面上是不太能够支持的，就是我们在云上可以提供就是更高性能存储，但是对应用户来说的话，它就需要支付更多的费用，那么他如果说利用这个缓存的技术的话，就是我可以实现让他先写到缓存里面。然后在异步的下刷到后面，那么你其实对后端的这个带宽能力要求就不会有那么夸张，然后同时也能够保证你的这个数据写入是非常快的，比如说一分钟之内我就能够写完，因为原因就是它大部分其实都是在写入到客户端缓存，就写内存的这个速度是啊，肯定没有什么瓶颈的，那么你写完之后的话，那其实后面的一步去下刷就是能够实现这种啊。
81:21
这种就是比较高性价比的一个方案吧，然后这个是我们在大模型，就是大文件写入切就是切换大文件写入的时候，它整个的一个主要技术优势，然后呃，这个是我们在那个一些，呃，就是线上的一些实际的一个情况的一个截图就是呃，这个是从8月21号到9月18号，它写带宽的一个峰值，它是峰值大概是在30兆，这个这个三兆的话，因为它单位是KB，然后就转弯单位的话，它其实是30个G大B每秒的一个带宽，那么它读带宽，它其实到了就是峰值有啊将近呃85个G大B吧。
82:00
然后这里读读带，读带宽和写带宽的这个差异的一个原因，就是我们写的时候用了这种异步缓存加速的这个能力，就是让他写入带宽的峰值是有一个降低的一个情况，然后能够让他写的更快。然后读带宽，因为它实际上在做切碰的这样的一个回滚的时候的话，就是它会呃嗯，你因为大部分的时候你在读切换的时候，这个切换的并不是呃，就是它已经是完整的下发到呃服端了，那其实在缓存上其实就不会命中到你就基本上都会完整的从后端去捞，所以说你会看到它并发去读，这样切的时候的话，它整个带宽会远高于这样的一个写带宽的情况。然后在然后在这里的话就是我们呃，实际上能够达到效果，就说是在呃用户配置的这个整个后端服务带宽不是特别高的情况下的话，它基本上也可以实现这种在一分钟以内完成这个2TB切控的这个写入，然后去大幅的降低它监控写入时间，进而去提升它整个GPU的这个利用率。
83:00
这个是在就是模型训练的时候的话，它的一个一个效果，然后这个是我们啊在原数据上的一个优化，那就是我们在就是刚才写说到那个写切锋的时候的话，它一方面是大文件，另一方面的话，它其实本质上会有非常多的节点在同一时间去并发的写入，那么它其实对原数据的这个能力也会有比比较高的一个要求，那么我们后端也是使用这种完整的就是啊全代化的一个分布式的一个。原数据服务，然后它能够实现的效果就是当用户去并发的访问某一个目录下的多个文件，无论是创建还是open，它其实都会有比较高的这个性能，这样的话就是在他写切换的时候的话，就不会出现这个原数据的一个性能瓶颈。然后这个是我们呃目前在这个呃现网上看到就是基本上相对比较多的一个用户的话，就是有576个客户，然后每个客户端都是八卡，然后它其实在实际写入的时候的话，基本上就是嗯，每张GPU的话，它都会对应啊，可能四到八个线程去写它的这个切point，那其实对应这个并发度的话，基本上就是可以说是上万个并发去同时写入了，那么我们这里的整个性能表现是非常优秀的。
84:12
然后呃，训练完之后的话，它后面就是一个推理的一个阶段，就是主要是说你模型训练完之后，我把这个模型可能做一些压缩之后，然后需要把它分发到多个推理的节点上，然后再去给用户提供这样的一个推理的就是服务，然后同时的话，就是这中间生成的数据的话，它又会作为下一次可能训练的一些样本，再去做这样的训练，就这样就会形成一个啊，就是类似于循环的一个动作，就不断的去迭代它这个模型。那么在这个推理阶段的话，就是它主主要就是呃，涉及到一个情况，就是说是如果说我的一个模型新写入之后。我要把它能够分发到多个推理的节点上的话，那其实它就会涉及到啊，我怎么样去管理，我这样在写入的时候，这个如果这个文件还没有完整的下刷到服务端后端的时候，我另外一个服务器去读的时候，怎么样能够保证它能够读到最新的数据，那么我们是提供这样的一个，就是啊强抑制的一个一个文件系统，它能够保证就是通过这种分布式锁的服务，能够保证任何一个服务器节点在任何一个时间点所读到的数据都是最新的，就没有这样的脏毒和换堵的情况，就保证它的这个数据是完全一致的，这样的话，它整个在呃模型快速迭代的时候的话，就能够解决这样的一个快速分发的一个问题，就因为你如果说不是强一致的，你很有可能你A服务器更新完你的模型之后，你要把这个你想把这个更新完的服这个这个模型去分发到呃，BCDEFG，对于其他的特定服务器上的时候，就会发现，咦，我怎么。
85:46
那我怎么去调动他去就是啊去去分发的时候会发现我怎么发现没有这个文件，或者我拉了一个老的文件，那其实这个对用户来说就是不能接受的，那么我们是在这种呃存储底层去实现了这个强一致性，就是业务的用户层，就是用户的业务层，不需要做任何的代码层面上的改造，就可以实现这种强一致的这个这个服务的情况。
86:08
然后这个是我们在那个呃，就是在推理时候的话，其实呃就是刚才讲的就是先是解决这个换读的问题，然后第二个的话就说是因为呃，我们整个就是在训练的时候，就是刚才提到就说实际上它在读数据的时候，它带宽并不是很高，这个是我们在呃某一个用户在过去一段时间的一个读带宽的情况，就是这里有比较尖的一个地方，是说是他出现了这个啊，比如说训练的时候异常，他要把切做回滚的时候，它会有并发的拉取这个切碰的这样的一个时间点，像这些这些毛刺其实都是他去拉切碰的时候造成的比较高的这个堵带宽，那么除去这种巅峰的时候的话，它其实长时间的一个读带宽水平都是非常低的。然后这个对应的话，就是它的训练的时候，读取训练样本的时候的这个数据，那么在这个时候的话，如果说我们把推理的服务去加上你，只要你在推理的分发的时候，它的带宽不和你的这个recovery的时候重叠，其实它就能够比较好的复用这里空闲的这样的一个读带宽的一个能力，这样的话就能够起到一个呃降本，同时也提高资源利用率的一个状况。
87:16
然后这个就是我本次分享的全部内容，就是感谢各位的时间。好的，谢谢杨老师的精彩分享。下面我们进入到qna环节，请老师为我们解答观众的提问。第一个问题，嗯，文档拆分的时候，哪种具体技术方案会比较好，能够保证拆分出来的内容是比较聚合的，并且文档分段的时候是直接按自然段来分，还是会根据内容关联聚合的程度来分？这个问题有请陈老师为我们解答。呃，老师您开一下麦克风，听不到您的声音，诶好啊，这个问题的话，因为其实我们现在腾讯线上数据库这边，我们自己也在做AI套件的方案，我们也有去做一些文档拆分，那目前从我们自己就是测试验证的结果来看啊，这里首先我们拆的时候呢，还是第一个原则是要按整句来拆，我们要保留我们拆分后的结果，在语义上面，它是一个完整的这样一个表达，不要从句子的中间，就比如说固定长度这种固定窗口，它其实可能会从句子中间去破坏我们整个的一个语义结构的。
88:30
所以这是第一点，就是我们还是建议按整距去来拆，然后另外的话呢，嗯，我们拆分的这个长度，其实因为一些模型它也有最大的一个数的限制，那在这里的话，我们测下来就是整个的拆分长度，我们每一个拆出来的段保持在200~400个，就是中文汉字这样的一个长度内，目前看就是转化，包括后续整个方案效果是最好的，就是这是我们线上自己拆的一些经验，但当然的话，对于我们不同的业务场景，就比如说如果我们的这个文本类型不一样，如果是我们是文言文的话，那其实可能还会有更加定制化的，我们业务需要去自己测试一下的一些啊实际的经验，嗯，这两个问题大概是这样。
89:13
好的，谢谢陈老师的回答，本次的问答环节到此结束，感谢四位老师带来的精彩分享，时间过得很快，本期活动也进入到了尾声，再次感谢大家的参与，关注我们，下期活动再见。

展开

我来说两句

0 条评论

登录后参与评论

作者

用户9763495

如何基于AIGC技术快速开发应用，助力企业创新？原创

我来说两句

作者

相关推荐

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐