2023 年深度行业分析研究报告 正文目录正文目录 小马智行：致力于打造适应各种车辆类型及场景的“虚拟司机”小马智行：致力于打造适应各种车辆类型及场景的“虚拟司机”.3 Robotaxi：在中国四大一.

0人已浏览 2023-12-22 26页 5星级

2023年第 2 期未来就业报告人工智能对工作的影响目录内容提要越来越多的职场人士开始探索和申请 AI 相关职位职场中的生成式 AI：带来跨教育、跨世代、跨性别和跨行业的机遇高管和员工对 AI 持兴奋与焦虑双重情绪领英如何提供帮助方法和致谢关于生成式人工智能（GAI）在教育、代际和性别方面的情况：我们正处于工作所需技能快速而持续变化的时期。来自领英 Economic Graph ResearchInstitute 的洞察表明，超过一半的领英会员的工作可能会受到 AI 的颠覆或增强。到 2030年，我们工作所需的技能将有望发生高达 65%的变化。此外，拥有高级学位、Z世代（Gen Z）以及女性职场人士可能会比其他职场人士更快地看到其工作的变化。我们相信，AI 有潜力帮助重置和重建教育和就业体系，使工作者更公平地为职场做好准备，并更客观地匹配和评估机会。领英的 AI 辅助产品将为会员和客户创造更多价值：尽管长期以来我们的产品和平台中一直嵌入了 AI，但我们仍在不断开发新的方式，以期在这个快速变化的环境中，将 GAI 的力量服务于职场人士。我们通过 AI 辅助的职位描述和新 AI 辅助的 Recruiter 2024，帮助招聘人员更轻松地工作。同样，对求职者也是如此，我们希望在求职过程中提供更有效的帮助。我们正在测试为高级订阅用户提供新的基于 AI 的洞察和建议，助其更轻松、高效地获取知识、技能和洞察，从而更容易找到合适的工作。在领英，我们正在开发能够帮助职场人士和企业充分享受 AI带来的成效、并为全球员工创造新机遇的产品。职场人士和全球商业领袖正在探讨人工智能（AI）如何改变工作，并纷纷通过领英深化他们对此的理解并分享学习经验。因此，我们发布了第二份未来就业报告：人工智能对工作的影响。该报告是在 2023 年 8 月发布的第一份报告的基础上撰写而成的，旨在为那些希望了解 AI 如何发展并影响自身、企业和职业的职场人士和商业领袖提供资源。该报告基于领英上超过 10 亿职场人士和 6700 万公司的世界级员工，提供了市场洞察，涵盖三个主要方面：职场人士对人工智能（AI）的看法和态度：在过去的一年里，AI 迅速成为文化和商业潮流的一部分。在领英，我们看到围绕 AI 的讨论增加了 70，并且全球会员档案中的术语“ChatGPT”、“Prompt Engineering”、“Prompt Crafting”、“Microsoft Copilot”和“Generative Artificial Intelligence”等方面也显著增加。对生成式 AI（GAI）的看法更多趋向于乐观，74 的高管认为 GAI 将使他们的员工受益，全球 47 的职场人士认为将通过 AI 更快获取知识和洞察力，来推动其职业发展。此外，公司正在投资于 AI 人才；自 2022 年 12 月以来，拥有“AI 主管”职位的公司数量已经以两位数增长。内容提要3随着 AI 在职场中的发展，我们将定期提供最新数据和研精覃思的观点，分享 AI 及其驱动的技术（如 Microsoft 365 for Copilot）如何在工作领域中应用和发展。工作将如何不再仅仅由职称来定义，而是由一系列技能和任务组成。作为全球最大的职业社交网络，领英具有独特的地位，能够帮助全球职场人士充分利用这一机会，不仅塑造新时代，而且从中受益。越来越多的职场人士开始探索和申请 AI相关职位推动全球 AI 话题的因素包括:性别:1男性:58%女性:31%其他/未知:11%代际：千禧一代:45%Z世代:26%X世代:21%潮一代:4%热门行业:专业服务:29%科技:17%教育:9%职业:行政人员:18%工程师:15%在这份报告中，我们研究了 2022 年 12 月至 2023 年 9 月期间平台上的全球数据。自 GAI 开始流行以来，领英平台上围绕 AI 的话题在全球范围内增加了 70%。这一点意义重大，尤其是与近期其他开创性的科技相比，如 2021 年 11 月围绕加密货币的话题达到顶峰（增长了 19%），以及 2021 年 10 月首次达到顶峰时增长了 5%的增强现实和虚拟现实。虽然 AI和 GAI 技术对许多人来说仍是新鲜事物，但这些话题已成为不同性别、代际、职业和行业的热门话题。1.虽然我们承认性别是一个范围，但由于数据的限制，我们的分析仅限于男性和女性的二元分类。6术语表AI人才:从事 AI相关工作或至少掌握一项 AI技能的人才。AI技能:领英的技能分类法中有 41,000种技能，其中 121种被视为 AI技能，包括机器学习、自然语言处理和深度学习。AI工作和 AI相关工作：在职位名称中包含 AI或机器学习的职位，以及/或作为所需技能一部分的职位。在本报告中，我们使用“AI 工作“一词来指代技术性工作（如机器学习工程师）。与 AI 相关工作“指的是职称中包含 AI或要求具备 AI技能的非技术性工作（例如：掌握如何使用 AI产品的销售人员）。AI 素养：了解如何将 AI工具用于商业目的。AI 职位申请份额增长平均对 AI 及其相关工作的浏览量正在上升AI 职位浏览量的增长平均来源:领英Economic Graph Research Institute美国7在领英平台上，AI话题激增的同时，我们也看到会员对 AI工作的兴趣也在增加。从 2022年 12月到 2023年 9月，在七个主要经济体（澳大利亚、巴西、法国、德国、印度、英国和美国）中，AI及其相关职位（职称中包含 AI 或机器学习和/或需要 AI 技能的职位）的浏览量增长了 12%。对 AI 及其相关职位的申请也出现了类似的增长，同期全球增长了 11%。对 AI的兴趣自 2022年 12月以来，美国的 AI 职位浏览量和申请量分别增长了 21%和 19%。Share ofgrowth0%5 %!%7%6%4%6%5%巴西英国澳大利亚法国德国印度Joseph Baker .3rdGenerative Artificial IntelligenceMessageNatalie Eliott .3rdChatGPT,Prompt CraftingMessage8在过去两年中，领英上提及 AI 或 GAI 的招聘信息比未提及此类信息的招聘信息的申请增长高出 17%。来源:领英2023 GlobalTalentTrends我们已经了解了人们对 AI 的兴趣是如何提升的，接下来就来分析一下领英平台上 AI 职位的发布情况。目前，每 1,000 名从事 AI 工作或至少掌握一项 AI 技能的领英会员中，就有 17 人被视为 AI 人才。我们相信，随着企业将 AI 工作岗位纳入其组织，这一数字还将继续攀升。AI 工作越来越普遍。自 2022 年 11 月以来，提及 GPT 或 ChatGPT 的英文招聘信息增加了 21 倍。自 2023 年 1 月以来，领英平台上提及 GAI 及其产品（包括 GAI 产品）的次数逐月增加了 60%，例如：Copilot for Microsoft 365.9国家行业澳大利亚1.专业服务2.行政和支持服务3.政府管理4.制造业5.零售业巴西1.专业服务2.技术、信息和媒体3.行政与支持服务4.制造业5.金融服务法国1.专业服务2.行政与支持服务3.制造业4.金融服务5.政府管理德国1.专业服务2.行政与支持服务3.制造业4.技术、信息和媒体5.金融服务印度1.专业服务2.技术、信息和媒体3.金融服务4.行政与支持服务5.制造业英国1.行政与支持服务2.专业服务3.技术、信息和媒体4.制造业5.金融服务美国1.专业服务2.行政与支持服务3.零售业4.制造业5.技术、信息和媒体自 2022 年 12 月以来 AI 相关职位需求量最大的行业来源:领英Economic Graph Research Institute在我们分析的七个国家中，专业服务、金融和制造业是对具备 AI 技能和 AI 素养的人才需求最大的行业。企业希望招聘具备 AI 技能的专业人才，包括技术和非技术岗位。尽管自 2022 年 12 月以来，软件工程师、数据科学家和机器学习工程师等技术岗位对 AI 技能的需求稳步上升，但企业越来越希望将具备 AI 素养的专业人才纳入供应链专家、可持续发展经理和销售经理等非技术岗位。随着越来越多的公司在其工作流程中采用 AI，AI 人才和技能在全球经济体中的扩散将继续增加。虽然许多 AI 工作都需要机器学习、深度学习和数据结构等 AI 技能，但其中大多数职位都需要 AI 和非 AI 技能（人际技能和数字技能）的组合。人际技能包括沟通、领导和组织技能。在一些非英语国家，英语熟练程度是从事 AI 和/或 AI 相关工作的关键技能。然而，随着 AI 技能在非英语国家的不断普及，我们可能会看到 AI 驱动的新工具和新技术不断增加。平衡 AI 技能与人际交往技能对职业发展至关重要。除了硬技能之外，拥有一种或多种人际交往技能（沟通、团队合作、解决问题或领导力）的技术专业人员的晋升速度要比只有硬技能的员工快 13%以上。澳大利亚1.通信2.员工福利3.分析技能1.机器学习2.模式识别3.数据结构巴西1.英语（语言）2.分析能力3.Microsoft Excel1.数据结构2.机器学习3.模式识别法国1.组织技能2.高精度3.英语（语言）1.机器学习2.深度学习3.模式识别德国1.英语（语言）2.沟通3.分析能力1.机器学习2.模式识别3.数据结构印度1.沟通2.分析能力3.销售1.数据结构2.机器学习3.自然语言处理（NLP）英国1.沟通2.员工福利3.分析技能1.机器学习2.数据结构3.自然语言处理（NLP）美国1.沟通2.员工福利3.领导能力1.机器学习2.数据结构3.自然语言处理（NLP）”自 2022 年 12 月以来，AI 及其相关职位发布中最紧缺的技能非 AI 技能（人与数字化）)国家AI 技能10对人际技能的需求是对 AI 技能的补充，这表明，在专业人员需要学习 AI 技能的同时，继续磨练人际技能也应该是一个优先事项。随着工作顺应 AI 的融入而发生变化，成为技能和任务的集合体，员工们的工作效率会更高，花在重复性工作上的时间会更少，这使得领导力和创造力等独特的人际技能变得更加宝贵。如果专业人员将 AI 技能与人的技能结合起来，他们将在就业市场上保持竞争力，因为就业市场将越来越重视 AI 无法复制的技能。在全球范围内，设有“AI 主管“职位的公司数量在过去 5 年里增加了两倍多，自 2022 年 12 月以来增长了 13%。“历史上，工作都是由职称来定义的。但聪明的公司意识到需要开始将工作定义为一系列技能和任务，而不仅仅是职称。然后开始思考随着 AI 的不断进步，这些任务会发生怎样的变化，以及我们需要哪些新技能才能取得成功。Ryan Roslansky,CEO,领英Talent Connect,2023 年 10 月 3 日职场中的生成式 AI：带来跨教育、跨世代、跨性别和跨行业的机遇“技术拐点，比如我们目前正在经历的 GAI 拐点，往往会随着时间的推移在整个经济体中得到广泛采用和影响。在出现与这些新兴技术直接相关的新工作岗位之前，最直接的影响可能是改变那些将继续存在但必须考虑到 AI 发展的角色。Karin Kimbrough,领英首席经济学家我们知道，在全球经济中，超过半数（55%）的领英会员的工作将因 GAI 的兴起而发生一定程度的变化，但我们也知道，一些专业人士受到的影响将比其他专业人士更大。GAI 对全球领英会员技能的预期影响12正如在领英平台上看到的那样，我们已经进入了一个由职称定义的工作向由技能和任务集合定义的工作快速、持续变化的时期。领英经济图谱研究所（Economic Graph Research Institute）的洞察表明：今天，全球 55%的领英会员将被 GAI 所增强或颠覆，到 2030 年，我们的工作所需的技能组合将平均改变 65%。例如，客户服务代表可能需要了解如何使用 AI 工具快速起草对客户咨询的回复，从而腾出时间处理其他重要任务。”术语表增强型：这些工作的核心技能包括大量可通过 GAI复制的技能和人际技能。例如，数据分析师利用 GAI自动计算和阐释指标，从而能够将时间集中在人际技能上，如跨职能参与和利益相关者管理。颠覆型：这些工作的核心技能包括很大一部分可以重复的技能，例如，语言翻译人员的技能从开始翻译转变为审查和认证机器生成的翻译，或者专攻特定的法律或文学领域。不受影响：这些工作的核心技能中，GAI 可以复制的技能所占比例相对较小。例如，房地产经纪人可以利用 GAI撰写房源描述，但他们的核心关系管理技能与 GAI 无关。颠覆型 47%增强型 8%不受影响 45%来源:领英 Economic Graph Research Institute跨教育领域的 GAIGlobal Exposure Education0%Pu0%拥有学士和研究生学位的职场人士受 GAI 的颠覆型影响最大13来源:领英 Economic Graph Research Institute增强型颠覆型不受影响曝光比例副学士学位学士学位研究生学位高中或以下文凭过去，拥有一个学位就足以让职场人士在职业生涯中游刃有余，但现在情况已不再如此。随着新 GAI 技术的引入和所需技能的快速变化，职场人士必须在整个职业生涯中不断更新自己的技能。在全球范围内，拥有学士学位和研究生学位的专业人士受到的干扰程度（分别为 55%和 52%），略高于拥有高中文凭和副学士学位的专业人士（分别为 50%和 47%），这表明他们可能面临相对更紧迫的任务，需要通过采用 AI 工具来调整自己的技能。这并不意味着高级学位将不再有价值，但培养 AI 素养最终将惠及所有职场人士，并为他们创造新的发展机会。Share of Exposure60 %0%增强Z 世代和千禧一代的工作最有可能受到 GAI 的颠覆型影响由于四舍五入，总和可能不等于 100%。来源:领英Economic Graph Research Institute颠覆不受影响14跨代际的 GAI领英研究表明，AI 的初步兴起将对几代职场人士产生不同的影响，而 Z 世代最有可能看到 AI 影响他们工作中的某些任务。这很可能是因为目前 GAI 技术可以复制的许多技能，例如：记笔记、会议总结、日程安排和研究等行政任务，这往往是职业生涯早期阶段的职场人士的任务。虽然与其他几代人相比，Z 世代职场人士可能会认为其工作受到的干扰最大，但作为数字原住民，他们是最接近 AI 的一代人。Z 世代对技术的驾轻就熟以及快速采用新工具的能力，很可能会超过他们在职业生涯早期所面临的更大影响。AI 的崛起可能会提高他们的工作效率，使他们能够发展基本的人际交往技能，并减少花在行政任务上的时间，这使他们能够将时间花在更有意义的工作上，从而帮助其提升自己的职业生涯。按代际划分的曝光1946-1964(潮一代)1965-1980(Gen X)1981-1996(千禧一代)1997-2012(Gen Z)增强型颠覆型不受影响500 %0%由于四舍五入，总和可能不等于 100%。来源:领英Economic Graph Research Institute领英报告显示，女性的工作更有可能受到 GAI 的颠覆型影响Share of Exposure15增强型颠覆型不受影响跨性别的 GAI全球一半以上的女性（55%）和男性（54%）的工作将被 GAI 颠覆或增强。虽然对女性的影响略高，但这很可能是因为女性从事的职业过多，而这些职业目前更依赖于某些 GAI 技术可以部分复制的技能，如医疗行政助理、办公室经理和法律助理。随着对 AI 技能和 AI 素养需求的提升，对人际技能的需求也在水涨船高。随着 AI 越来越深入我们的工作流程，沟通和灵活性等技能将变得更加宝贵。最近的一项调查发现，92%的美国职场人士认为，人际技能比以往任何时候都更加重要。这为女性创造了一个特殊的机会；研究表明，女性往往擅长沟通、换位思考、组织意识和技术技能等人际交往技能。随着公司越来越多地寻找能够将人际技能与 AI素养和 AI 工具相结合的人才，女性可能会有更多的机会。按性别划分的曝光男性女性“过去，我们都认为职业道路是线性的，现在我们认识到，职业道路也可以是一条充满支点的斜线。AI 只会加速 这一趋势。Ryan Roslansky,CEO,领英Redefining Work,2023年8月15日”全球 55%的领英会员的工作将因 GAI 的兴起而发生一定程度的变化。16跨行业的 GAI与增强现实、虚拟现实和区块链等其他最新技术相比，GAI 对劳动力的变革性影响可能会远远超出技术行业。我们已经看到大多数行业都在聘用 AI 专业人才，我们预计，随着 AI 和GAI产品（如 Copilot forMicrosoft 365 和其他产品）的力量不断扩散，各行各业都将开始将 AI 技能融入各自的员工队伍。领英数据表明，在全球范围内，技术、信息和媒体（71%）、零售（71%）、批发（68%）、金融服务（66%）和专业服务（64%）等行业的职场人士最有可能看到他们的角色被 GAI 所颠覆或增强。因此，这些行业的专业人士很可能引领 AI 素养的采用，并磨练他们的人际技能。各行各业广泛采用 GAI 产品的一个积极因素是，它可能会为更多行业的职场人士创造更大的工作流动性。掌握 AI 知识的职场人士会发现，他们的知识和技能将变得更容易转移，从而加速我们已经看到的职场人士角色转换的趋势。“GAI 对劳动力的变革性影响将远远超出技术行业。几乎每个行业都会受到一定程度的影响，其中最明显的是零售、批发、金融服务和专业服务。随着职场人士不断掌握 AI 技能，这些技能的可转移性将越来越强，这将打开职场人士流动的大门，并加速职场人士转换角色和行业的趋势。Karin Kimbrough,领英首席经济学家32)641 6)6%3%6%5%4%9%7%8%6%8%5IRVIWeVQXUHPSSc%GAI 对全球各行业领英会员技能的预期影响20%来源:领英Economic Graph Research InstituteGlobal Exposure by Industry41DCABC2v%0%住宿和膳食服务行政与支持服务建筑业消费者服务教育娱乐业金融服务政府行政部门医院和医疗保健制造业石油、天然气和采矿业专业服务房地产和设备租赁零售业技术、信息与媒体运输、物流和供应链公用事业批发曝光比例不受影响颠覆型增强型高管和员工对 AI 持兴奋与焦虑双重情绪New data fromthe MicrosoftWorkTrend Indexshowstheproductivitygains from generativeAItoolslike MicrosoftCopilot are real.Early usersof 来自 Microsoft Work Trend Index 的新数据显示，像 Microsoft Copilot 这样的 GAI 工具带来的生产力增益是真实的。使用 Copilotfor Microsoft365的早期用户，一旦尝试，就不想再回到没有它的工作方式：77%的用户表示他们不想放弃使用 Copilot。另一项研究显示，总体而言，Copilot 用户在搜索、撰写和总结等一系列任务中快了 29%。52H%最近的领英调查显示，全球 52%的千禧一代和 48%的 Z 世代相信 AI 将通过提供更快的获取知识和洞见的途径来推动他们的职业发展，从而使其在工作中更加自信。美国高管认为 GAI 将使员工受益的第一方式是“消除枯燥重复的任务”，而“提高生产力”则紧随其后，位列第二。千禧一代Z 世代19随着更多的 AI 辅助技术推出，比如 MicrosoftCopilot for Dynamics 365，这是一套由 AI 驱动的业务应用程序，帮助组织优化运营、销售、客户服务和营销等方面。高管们正在意识到这些技术在业务中的好处和用途。领英 Executive Confidence Index显示，截至 2023 年 9 月，74%的美国高管认为 GAI 至少有一种方式会使他们的员工受益。代际：职场对 AI 的态度对 AI 讨论的增加引入了各种态度和期望，当我们按代际来分析这些情绪时，就会发现存在显著的差异。值得注意的是，对于 AI 的兴奋情绪在 Z 世代和千禧一代中特别高，他们相信 AI 将帮助他们在职业生涯中取得进展。20国家Z 世代学习AI 技能的意愿是X 世代的X 倍英国2.0 x印度1.3x加拿大1.3x澳大利亚1.2x美国1.1x意大利1.1x巴西0.9x西班牙0.8x.Z 世代和千禧一代对 AI 有着更强烈的信心，认为它将推动其职业发展，并更愿意参与”AI 将如何影响其工作”的讨论。考虑到他们更容易受到 AI 辅助技术颠覆的情况，Z世代对 AI 的兴奋和兴趣是令人振奋的。来源:领英 Market Research-Workforce Confidence Index(WCI)survey,June 2023尽管与其他代际相比，Z 世代职场人士对学习 AI 技能的兴趣很高，但他们接受的 AI 培训和资源却少于资历更老的同行。随着 AI 日益融入劳动力结构，现在就采取措施尝试 AI 并掌握新技能，将对 Z 世代职场人士和公司大有裨益。“我们还将看到雇主成为教育者，通过入职培训、学徒制度和学院，实施培训以雇佣以适应不断变化的职位，以及通过提升技能和任务轮岗制度实施培训以晋升，使员工进入新的职能，甚至可能是新的职业。Ryan Roslansky,CEO,Redefining Work,2023 年 8 月 15 日”2134%全球女性40%全球男性性别：职场人士对 AI 的看法在全球范围内，男性和女性对未来 AI 可能带来的工作变化感到同样的压力（39%），在这些看法中，三分之二的职场人士认为，在未来一年内，AI 将改变他们的工作方式。但是，根据领英最近的一项调查，女性称在 AI 方面比男性同行经验更少、意识更低，整体对 AI 的兴趣也较低。在全球范围内，男性比女性更有兴趣学习 AI 技能。此外，在采用 AI 技能的压力方面也存在不匹配。在美国，近三分之二（64%）的男性表示他们担心自己对 AI 的了解不够，而只有 45%的女性表示担忧。全球范围内，40%的男性表示他们已经开始尝试使用 AI工具，而全球范围内仅有 34%的女性表示有同样的情况。在美国，52%的男性表示他们已经开始尝试使用 AI工具，相比之下，只有 31%的女性表示有同样的情况。国家意大利男性学习 AI 技能的意愿是女性的 X 倍英国西班牙巴西法国加拿大荷兰美国德国澳大利亚日本印度1.8x1.8x1.7x1.6x1.6x1.5x1.5x1.5x1.4x1.4x1.3x1.1x来源:领英 Market Research-Workforce Confidence Index(WCI)survey,June 2023对 AI 的这种情感交织创造了许多机会，让雇主关注提供平等获取 AI 知识资源的途径，并确保所有员工都在发展正确的技能（包括人际技能和 AI 技能），以驾驭塑造未来工作的变革。领英如何提供帮助职场人士、招聘经理和 B2B 客户都可以利用 领英全新的 GAI 工具在过去的 20 年中，我们不断演进，以满足领英平台上的 10 亿职场人士和 6700 万家公司的需求，适应不断变化的职场环境。现在，我们正在经历另一个变革时刻，GAI 有可能推动全球经济的发展，创造全新的角色，改变我们的工作和工作方式。随着工作所需的技能不断变化，我们有责任为职场人士提供相应的工具和知识，使他们能够在日常工作中探索和接受这些新技术。25AI 是我们产品开发的核心在领英，AI 已经融入我们的平台和会员、客户使用的产品中。我们的努力基于 Responsible AI Principles：公平性、包容性、信任、透明度、责任和经济机会，并与 MicrosoftResponsible AI Standard 保持一致。它们指导着我们的工作，以及如何将 AI 融入我们的每一个产品中。“对于我们的工程团队，AI 就像氧气一样，它驱动我们构建的每一个产品和提供的每一种体验与此同时，我们对待使用 AI 的方式与我们对待任何其他新工具或技术的方式相同，首先回到我们的使命和愿景。这指导我们在构建工具和技术时，注重为我们的会员和客户提供价值。”MohakShroff,领英工程高级副总裁AI 领英-ItsAllAbout Foundations,2023 年 3 月 8 日尽管对于我们来说 AI 并不新鲜，但我们正在借助 GAI 的力量重新构想会员和客户产品，以实现以下目标：帮助他们更有效地连接到机会展示他们的专业知识和技能获取完成工作所需的知识找到雇主和求职者之间的合适匹配节省时间并提高生产力更快速地连接买家和卖家无论您是一名职场人士想要了解如何在当前职业中使用 AI、一位求职者寻找下一个职业机会、一位招聘人员想要发现并联系世界上最优秀的人才，还是一位 B2B 职场人士试图接触和吸引新的受众，领英始终在开发和发布 GAI 工具，帮助您发挥最佳能力。26以下是领英如何利用 GAI 为其会员和客户提供服务的方式：对于招聘者：对于人才招聘领导者来说，迅速找到合格的候选人是首要任务。但是找到理想的候选人需要耗费大量时间和精力，可能需要数小时的布尔检索、电子邮件和后续消息。我们知道 AI 可以帮助处理其中的一些任务。全球 80%的人力资源专业人士相信在未来五年内，AI 将成为协助他们工作的工具。因此，我们正在推出 Recruiter 2024，这是我们的新一代 AI辅助招聘体验，将使招聘变得更加简便高效，使人才领导者能够专注于他们工作中最具战略性和人本关怀的方面。鉴于到 2030 年我们工作所需技能预计将惊人地改变 65%，我们正在帮助组织为其团队提供专业知识，通过 LinkedIn Learning 中的 AI 辅助教练培养具有实际意义的技能。这项新功能将根据每位学员的职称、职业目标和技能，为他们提供实时建议和量身定制的个性化内容推荐。27对于营销人员和销售人员：对于 B2B 营销人员来说，创建能够触及并影响正确购买委员会的广告活动并非易事，尤其在资源有限的情况下。创建广告活动通常需要花费大量时间，从开发创意到确定定位、投放和出价策略。我们知道 84%的营销人员相信 AI 将在他们的工作中提供支持，而在广告活动创建过程中节省时间是一个很好的入手点。因此，我们正在试行“Accelerate”，这是一个由 AI 驱动的新型自动化 B2B 营销广告活动创建体验。在短短五分钟内，Accelerate 将推荐一项端到端的广告活动，并提供自动优化，以通过引人入胜的创意触达正确的 B2B 受众。在启动广告活动之前，您可以对其进行调整和微调。Accelerate 建立在我们其他 AI 功能的基础上，例如自动投放，它已经将每次转化的成本降低了 47%，Predictive Audiences 将每次销售线索的成本降低了 21%。对于销售专业人员，GAI 可以实现新的工作方式，提升了人际关系技能的重要性，帮助 B2B 销售比以往任何时候都更加人性化。我们正在重新构想销售专业人士如何使用 Sales Navigator，通过两个新的 GAI 功能的试点：AI-assisted search 和 Account IQ，使账户研究和潜在客户开发更加有效。通过 AI 辅助搜索，其中包括一个新的 GAI 界面，使销售专业人员能够更高效地使用我们现有的搜索功能，通过输入非正式、对话式语言的搜索提示，销售专业人员可以更好地找到他们寻找的潜在客户类型。我们还推出了 Account IQ，它利用 GAI 从不同来源收集关键信息，并在 Sales Navigator 中直接创建一个易于理解的摘要，帮助销售专业人员轻松进行账户研究的繁重工作。28对于高级订阅用户：高级订阅用户可以获取有价值的资源和工具，帮助他们更快地实现目标，并且我们增加了更多利用 GAI 增强这些的方式。要生动地展示您的专业优势和独特能力通常是一项困难的任务。现在，通过为个人资料提供个性化写作建议的功能，我们独特的 AI 工具从会员个人资料中提取内容，为其技能和经验提供一个初步的亮点草稿，帮助更快地打造更强大的个人资料。正如往常一样，我们鼓励会员在发布之前编辑生成的内容。最近，我们还新增了一种解决空白页面问题的新方法，帮助我们的会员通过具有个性化写作建议的 AI 更好地向招聘经理展示自己的优势。这个功能从领英个人资料和职位描述中提取信息，创建一条初步的个性化消息，节省您寻找工作所需的时间。我们还在为高级订阅用户测试新的基于 AI 的总结和建议，帮助他们保持信息更新、提升技能，并更轻松高效地找到合适的工作。例如，订阅用户将能够在动态中看到个性化的主要摘要，这些摘要可能展示机会，并提供关于如何利用信息帮助职业成长的建议。在职位发布中，基于 AI的建议将帮助会员更好地评估工作的潜在匹配度，了解公司更多信息，并提供建议，以脱颖而出。联系领英，获取全球化人才解决方案借助 AI 产品和工具高效引才29随着对 AI 技能需求的增加，与之相匹配的人际技能也变得越发重要。LinkedIn Learning 提供数千门课程，培养诸如时间管理、灵活性和领导力等关键的人际技能。截至 2023 年 12 月 15 日，领英免费提供 LinkedIn Learning 上最受欢迎的 AI 课程，包括如何使用 GAI 工具进行研究和写作面向商业领袖的 GAI等。2023 年 6 月，微软和领英推出了首个 GAI 专业证书，将在 2025 年之前免费提供，确保广泛获取必要的技能和知识，以便将这一技术无缝融入未来的工作中。这些课程是专为职场人士和商业领袖设计的。它们不仅提供知识、提升 AI 素养，还帮助所有学员配备在 AI 时代获得成功所需的工具。对于专业人士和业务领导者来说，AI 给他们带来了许多兴奋和担忧，而这是可以理解的。这是一个充满变革的激动人心的时刻，我们只是刚刚开始探索 AI 的潜力。随着 AI 和工作的交汇不断成形，职场人士和业务领导者可以依靠领英，为其提供知识和资源，帮助他们始终站在发展前沿，并获取机会。方法和致谢31AI 技能领英会员在其领英个人资料上自我报告其技能。目前，领英识别了超过 41,000 个独特的标准化技能。这些技能已由领英的分类学家进行编码和分类，分为 249 个技能组，这些技能组是数据集中表示的技能组。我们追踪 121 个 AI 技能，构成 AI 技能组的前几个技能包括机器学习、自然语言处理、数据结构、AI、计算机视觉、图像处理、深度学习、TensorFlow、Pandas（软件）和 OpenCV 等。AI 人才其职位包括 AI 或在其个人资料上至少有一个 AI 技能的会员。AI 工作及其相关工作其职称包含 AI 或机器学习，或其所需技能中包含 AI 或机器学习的工作。在这份报告中，我们使用术语“AI工作”指的是技术工作（例如：机器学习工程师），而“与AI相关的工作”指的是非技术工作（例如：了解如何使用 AI 产品的销售人员）。AI 及其相关工作的浏览量这一指标基于领英平台上的求职者，在 2022 年 12 月至 2023 年 9 月的行为计算，将其与前一年同期进行比较。AI 话题领英的研究人员在全球范围内对平台上的帖子进行了分析，时间跨度为 2022 年 12 月至 2023 年 9 月，与前一年的同期进行了比较，分为三个步骤。首先，识别了包含多种语言（包括英语、德语、法语、西班牙语和葡萄牙语）中的 AI 相关关键词（“AI”、“人工智能”和“机器学习”）的帖子；其次，计算了 AI 相关帖子占所有帖子的百分比；第三，计算了年度增长率。结果集中在澳大利亚、巴西、法国、德国、印度、美国和英国。他们按选定的会员特征进行分割，例如性别、代际、行业和主要职业。在个人资料中的 GAI 关键词领英研究人员进行了全球分析，研究了会员在 2023 年 12 月至 2023 年 9月之间向其个人资料中添加的关键词和标题。分析中包括的关键词和术语 有“ChatGPT”、“Prompt Engineering”、“Prompt Crafting”、“Generative Artificial Intelligence”、“BardAI”、“LaMBDA AI”、“MS365Copilot”和“Microsoft Copilot”。联系领英，获取全球化人才解决方案借助 AI 产品和工具高效引才32生成式人工智能（GAI）对劳动力的影响领英的研究人员将 GAI 工具与技能嵌入和匹配技术相结合，识别出 GAI可复制技能和 GAI 互补技能，并利用技能基因组将其映射到职业中。通过这种方式，领英上的每个职业都根据这一度量的中位数被分类为受 GAI 增强、颠覆或不受影响。然后将这些职业进一步映射到领英会员及其在不同国家的选择特征上，以估算在每个类别内落入各组的会员份额。有关更详细的方法，请参阅为生成式 AI 培养人才。本报告中显示的结果反映了以下国家的平均水平：阿根廷、澳大利亚、奥地利、比利时、巴西、保加利亚、加拿大、智利、哥斯达黎加、克罗地亚、捷克共和国、丹麦、爱沙尼亚、芬兰、法国、德国、希腊、匈牙利、冰岛、印度、印度尼西亚、爱尔兰、以色列、意大利、日本、拉脱维亚、立陶宛、卢森堡、墨西哥、荷兰、新西兰、挪威、波兰、葡萄牙、罗马尼亚、沙特阿拉伯、新加坡、斯洛伐克、斯洛文尼亚、南非、韩国、西班牙、瑞典、瑞士、土耳其、阿拉伯联合酋长国、英国、美国和乌拉圭。领英的 Workforce Confidence Index(WCI)每两周通过电子邮件向会员分发在线调查。每一轮大约有 10,000 名来自美国、加拿大、巴西、英国、法国、德国、西班牙、意大利、荷兰、印度、澳大利亚和日本的会员参与。会员被随机抽样，并必须选择参与研究。学生、居家伴侣和退休人员被排除在分析之外，以确保我们能够准确代表目前在职场活跃的人群。我们在 2023 年 3 月 11 日至 6 月 2 日期间询问会员有关他们对 AI 的看法。为了按性别查看数据，我们要求会员自行选择为“女性”、“男性”、开放式回答或“不愿透露”。我们对数据进行汇总分析，并始终尊重会员隐私。数据按参与度加权，以确保公平反映平台上的各种活动水平。结果代表了通过领英会员视角看到的世界；未考虑领英会员与整体市场人口之间的差异。联系领英，获取全球化人才解决方案借助 AI 产品和工具高效引才33领英的 Executive Confidence Index(ECI)每季度由大约 5,000 名领英会员（副总裁级别或以上）参与的在线调查。最近一轮调查进行于 2023 年 9 月 6 日至 18 日。会员被随机抽样，并必须选择参与研究。我们以总体数据进行分析，并始终尊重会员的隐私。为了确保在平台上对高管的公平代表性，数据按照资深度和行业进行加权。结果代表了通过领英会员视角看到的世界；未考虑领英会员与整体市场人口之间的差异。领英 人才洞察有关导致晋升技能的分析考察了在 2019 年 7 月 1 日至 2023 年 6 月 30日期间，将技能明确添加到其个人资料并在全职雇佣下在内部获得晋升的领英员工的聚合和匿名数据。根据领英分类法的定义，软技能主要影响个人的行为、思维或知识，而硬技能主要影响对象，包括专业领域知识和技术知识。晋升所需的时间由员工当前职位和晋升职位之间的开始日期差异来衡量。AI 消费者研究由 Censuswide 进行的研究，基于 2023 年 8 月 23 日至 8 月 31 日期间在英国、美国、加拿大、澳大利亚、新加坡、印度、法国、德国、巴西、西班牙、沙特阿拉伯、荷兰、意大利、印度尼西亚、菲律宾、马来西亚、阿联酋和日本的 29,937 名专业人士（包括1,574名营销专业人士），年龄在 16岁及以上。Censuswide 基于 ESOMAR 原则，遵循并雇佣了市场研究协会的成员。AI 负责人职务领英的研究人员根据包含关键词“AI”、“人工智能”或“机器学习”以及关键词“负责人”或领英标准化的高级别职务“总监”、“副总裁”、“首席”等的职称识别会员。这一指标的增长是从 2022 年 12 月到 2023年 9 月计算的，与前一年同期相比。20 年前不存在的职业领英的研究人员将领英 2023 年兴起的职业榜单中的 25 个职业与 O*NET2000 年的分类法进行比较，可以通过名称或职位描述进行匹配。O*NET是美国职业信息的主要来源，由美国劳工部赞助开发的数据库，包含数百个职业定义，并在学术研究中被广泛使用。联系领英，获取全球化人才解决方案借助 AI 产品和工具高效引才致谢在此特别鸣谢领英经济学家、数据科学家、市场研究团队以及所有为此报告做出贡献的人：Karin Kimbrough,首席经济学家 Mar Carpanelli,高级数据科学家Allison Lewis,市场研究联系领英，获取全球化人才解决方案借助 AI 产品和工具高效引才

0人已浏览 2023-12-21 34页 5星级

前言前言2在工业自动化早已实现的今天，汽车、3C等制造工厂的自动化流水线随处可见，生命科学行业的生产力却仿佛还停留在上个世纪的手工时代，生命科学行业迫切需要一场工业革命，实验室自动化的变革迎来曙光。本报告中，DeepTech重点关注在生命科学场景应用的实验室自动化技术，通过桌面调研和专家访谈的方式，探讨实验室自动化的发展现状、限制因素、产品形态、应用场景、终端用户、商业模式、未来发展前景等问题。关键结论关键结论 中国实验室自动化的兴起：生命科学上游行业国产替代的需求叠加工业自动化的人才供给 限制自动化发展的因素主要包括投资回报率不足、产品难以满足需求、需求非标准化、市场教育不够充分等 产业链：从商业模式看，中游的实验室自动化厂商可大致分为产品商、系统集成商和细分场景应用商，目前国内自动化领域融资排名位居前列的公司为系统集成商 核心竞争要素：产品商比拼性价比、系统集成商比拼掌握的核心设备数量和控制系统、细分场景应用商比拼客户数量 商业化路径：技术-产品-应用场景（实验环节）-终端用户 产品形态：硬件领域液体工作站和机械臂整合系统是主流，软件领域与国外差距大 应用场景：分子和细胞层面的实验环节自动化相对成熟，动物层面实验自动化仍是空白 终端用户：目前兼具刚需和支付能力的生命科学类实验室集中在大型CRO、药企、平台类合成生物公司、部分进行高通量药物筛选和合成生物学研究的科研机构、疾控中心、质监药监等部门，以及部分政府支持的标杆实验室项目；具有高通量筛选需求的药物研发和合成生物学公司是近期可以较快商业化的发力方向 市场规模：目前生命科学类实验室的自动化市场规模在百亿级人民币（不包含医学检验场景和主流仪器设备）规模化应用：挖掘标杆客户是打通商业化闭环的关键一步 微流控芯片技术是微量反应体系高通量实验室自动化的发展趋势 合成生物学、抗体开发等多个领域亟待微流控技术赋能生命科学行业迫切需要一场工业革命，实验室自动化的生命科学行业迫切需要一场工业革命，实验室自动化的变革变革即将带来曙光即将带来曙光3随着多组学时代的到来，生命科学逐渐发展为大数据科学，许多新的信号通路、转录因子、药物分子的发现依赖于高通量筛选。但目前生命科学的生产效率已不能满足生物学家的需求，组学时代重复、繁琐、高强度实验操作使科研人员疲惫不堪，384孔板“人工高通量”，既费时费力又容易出错。生命科学行业迫切需要一场工业革命，实验室自动化的变革即将为生命科学行业带来曙光。实验室自动化（Lab Automation），是指利用现代技术和设备来自动化实验室的各种操作和流程，解放人力、简化实验流程、智能设计实验、降低人为误差，以及提高实验通量、速度、准确性和可重复性等。实验室自动化包括样品处理、仪器操作、数据采集和分析等方面。实验室自动化的实现需要依靠各种自动化设备和软件，如自动进样器、液体处理系统、机器人系统、温度控制系统、自动化分析仪器、数据处理软件等。这些设备和软件可以协同工作，完成实验室中的各种任务，从而实现实验室的自动化。图1丨利物浦大学的智能机器人化学家（来源：A mobile robotic chemist，Nature）实验室自动化的核心技术来源于工业自动化实验室自动化的核心技术来源于工业自动化4传感器与机器视觉：通过使用传感器感知物理量，例如温度、压力、湿度、位置等，实现实验的自动化控制和数据采集。机器视觉技术可以通过相机、光学和图像处理等手段实现对实验过程的监控和控制，例如自动化液体控制系统、自动化温度控制系统、自动化测量系统等PLC或PCB技术与流程控制：PLC（可编程逻辑控制器）或PCB（印制电路板）是工业自动化中常用的控制设备，可以通过编程实现自动控制实验流程，如样品处理和分配、反应控制、液体注入、分装和封口等机器人/机械臂技术：常见机器人的形态可以是三轴XYZ坐标机器人、多关节机械臂或者人形机器人，自由度主要在3-6之间，也可以是一种递送机构，如轨道、磁悬浮、AGV小车（AUTOMATED GUIDED VEHICLE）等，可以实现实验室样品处理、液体处理、设备操作，搬运操作数据处理与人工智能：通过计算机对采集的实验数据并进行处理和分析，以提高数据的准确性和分析效率。例如，使用实时数据采集系统、数据分析软件和数据库等工具来进行数据采集、处理和管理。人工智能可用于分析和预测实验结果，优化实验流程和提高实验效率，帮助实验员做出更准确的决策自动化实验设备的集成：使用实验室自动化控制系统来统一管理仪器和设备，将自动化实验设备进行集成，以实现实验的全自动化控制和数据处理工业自动化于20世纪60年代就已发展出现代综合自动化工厂的雏形，在制造工业中出现了许多自动生产线。而实验室自动化是在工业自动化的基础上发展起来的，迁移到生命科学领域有其通用性，无外乎要做一些视觉、判断和反馈，以及信息的通讯和采集，从而让整个任务执行可以有序完成。但也有其特殊性，即要更好地适应客户对于生物技术的一些特殊需求，例如避免溶液试剂的浪费、实现耗材的大通量处理、根据耗材形态做材料选型等。实验室自动化的实验室自动化的底层底层技术路线主要包括以下几个方面：技术路线主要包括以下几个方面：国外实验室自动化已发展国外实验室自动化已发展4040多年，机械臂和工作站率先多年，机械臂和工作站率先出现出现5图3丨Beckman公司 Biomek1000（来源：公开资料）1980年，Zymark公司开发出Pi系统，具有单轴的机械臂，能够以圆周方式完成实验，故命名为Pi，是最早的实验室自动化机械臂系统。该设备成功销售了2000多台。1986年，Beckman开发出最早的移液工作站商业化原型Biomek1000，由垂直机械臂、移液工具、洗板机单元、Masterflex泵、定位平台和附件组成。图2丨Zymark公司Pi系统（来源：公开资料）1961年，Eppendorf公司研究出活塞吸液，并在1976年申请专利，是实验室最常用的移液枪早期原型，代表着实验室自动化领域的诞生。1980s-1990s，工作站在与机械臂的论战中胜出。在实验室自动化发展的早期，美国曾出现过关于自动化用机械臂还是工作站的论战。工作站最早出现的也是最核心的产品就是移液工作站。工作站在设计之初只完成一些少量任务，但高度可靠，而机械臂优势在于更加灵活。在实践中，人们发现自动自动化的首要原则就是简化实验过程化的首要原则就是简化实验过程。在早期时候，如果让机械臂自动化进行一些复杂的手工操作的时候并不会让实验更有效率，因此工作站在论战中获胜。随后成立的随后成立的BeckmanBeckman、HamiltonHamilton、TecanTecan，都是以移液工作站为核心的整合方式都是以移液工作站为核心的整合方式。1983-2003年，实验室机器人与自动化国际研讨会ISLAR每年举办，推动了实验室自动化领域的发展。1996年，实验室自动化协会ALA成立，并在2010年与生物分子科学协会SBS合并为实验室自动化和高通量筛选协会SLAS，其出版了两本实验室自动化领域的学术期刊SLAS technology和SLAS discovery，并制定了用于药筛的微孔板的标准。根据自动化的程度和规模，实验室自动化可分为四个阶段：单一设备形式的自动化、工作站形式的自动化、流水线形式的自动化和智能化形式的自动化。它们并非纯粹的全面替代演进关系，而是根据成本需求、通量需求，研究和临床需求的客户情况，匹配不同产品形式。实验室自动化整体是从辅助人到替代人的方向发展，最终理想是达到无人值守的“黑灯实验室”。不同的实验室场景处在自动化的不同阶段不同的实验室场景处在自动化的不同阶段62 2.0 0阶段：工作站阶段：工作站一台设备集成了多种功能，可以在一个批次内处理一定数量的样品，批次内可以无人值守，批次之间需要人工操作。例如液体处理工作站，将多个样品前处理环节集成在一起，进行加样、混匀、稀释、转移等操作，是实验中最为基础且最为频繁的实验操作。目前部分高通目前部分高通量实验室采用工作站形式自动化量实验室采用工作站形式自动化。3 3.0 0阶段：阶段：TTATTA与与TLATLATTA完整任务目标自动化与TLA全实验室自动化，结合前端样品处理和后端检测形成全流程自动化，设备与设备之间自动传输数据和样品，类似工业自动化的模式。这种形式目前使用最多的是这种形式目前使用最多的是医学检验医学检验场景场景，如如医院检验科和第三医院检验科和第三方检测实验室方检测实验室（ICL），常见生化检测自动化流水线、免疫检测自动化流水线、血液检测自动化流水线、微生物检测自动化流水线等。4 4.0 0阶段：智能阶段：智能化化在全实验室自动化基础上，加入人工智能，可代替部分脑力劳动，具有机器学习、自动判断、自我决策能力。多用在研究型实验室领域，擅长解决多品种、小批量、多批次、高时效的检测需求，进行实验室智能化操作和管理，可进行样品前处理、分析检测和实验数据的处理等所有实验室的操作，并可以循环往复地进行。目前目前利物浦大学利物浦大学、伊利诺伊利诺伊大学伊大学、G Ginkgoinkgo BioworksBioworks等已有案等已有案例例应用应用。1 1.0 0阶段：单一阶段：单一设备设备一个自动化设备往往只有一两种分析检测或者样品处理的功能，需要人来操作使用。例如，自动配液、自动称量等操作以及混悬仪、离心机、细胞培养箱、PCR仪、质谱仪等仪器设备。目前大部目前大部分实验室仍处在这一阶段分实验室仍处在这一阶段。2000年-2010年间，中国实验室自动化领域开始出现，奥美泰克在2004年成立；2016年左右实验室自动化开始加速发展，多家初创公司成立；2020年，新冠疫情成为行业发展的催化剂，疫情催生了大量核酸样品的检测需求，同时病毒的高传染性和致病性对涉及样本处理、检验检测、样本存储的全流程自动化提出了直接的需求，进一步释放了自动化的空间，多家公司在2021年-2022年获得融资。需求端：国产替代是生命科学上游行业的长期需求需求端：国产替代是生命科学上游行业的长期需求生命科学上游行业包含仪器设备、试剂耗材等，具有很高的技术壁垒，存在大量“卡脖子”环节，赛默飞、丹纳赫、安捷伦、PE等巨头占据国内市场主导地位。生命科学上游高度依赖进口的问题已得到国务院、工信部、自然科学基金委等部门的高度重视，国产替代成为成为政策引导的主要方向。供给端：实验室自动化供给端：实验室自动化适合适合中国中国的工业自动化的工业自动化人才结构人才结构国内的自动化技术在工业3C、汽车等领域已相对成熟，做相应非标产线的自动化人才非常多，在制造业市场逐渐饱和之时，大量人才从汽车和3C产线，转到实验室自动化，因此天然擅长在流程端将仪器和线性自动化流程进行整合。相比来说，高端仪器所需的精密材料精密材料、传感器技术国内欠缺传感器技术国内欠缺，仪器领域的国产替代仍有很长的路要走，而实验室自动化更适合中国目前的工业自动化人才结构。中国中国实验室自动化的实验室自动化的兴起：兴起：生命科学上游行业国产生命科学上游行业国产替代的需求叠加替代的需求叠加工业工业自动化的人才供给自动化的人才供给7 2016年8月，国务院发布十三五国家科技创新规划，提出加强生物产业发展及生命科学研究核心关键装备研发，提升我国生物技术前沿领域原创水平，抢占国际生物技术竞争制高点。2021年3月19日，为落实“十四五”期间国家科技创新有关部署安排，国家重点研发计划启动实施“基础科研条件与重大科学仪器设备研发”等重点专项及“揭榜挂帅”榜单。围绕国家基础研究与科技创新重大战略需求，以关键核心部件国产化为突破口，切实提升我国科学仪器自主创新能力和装备水平，促进产业升级发展，支撑创新驱动发展战略实施。限制自动化发展的因素主要包括投资回报率不足、产品难限制自动化发展的因素主要包括投资回报率不足、产品难以满足需求、需求非标准化、市场教育不够充分等以满足需求、需求非标准化、市场教育不够充分等8中国医学检验的自动化程度最高中国医学检验的自动化程度最高，其他场景的实验室自动化水平仍然较低其他场景的实验室自动化水平仍然较低医学检验的实验流程固定，需求标准化，样本量大，同时预算充足。目前国内实验室自动化应用程度最高的是医院检验科，已经处在3.0的流水线阶段，以生化免疫流水线为主，达到采血后上样、前处理、检测、结果报告和后续样品存储等全检验过程自动化，极大程度地简化了工作流程，加强了质量管理，降低了人为误差和生物污染率。进口四大家罗氏、雅培、西门子、贝克曼占据了70%以上的中国市场，占据三甲医院的高端市场，国产厂商与目前逐步从二级以下医院开始国产替代。大多数实验室自动化的程度还停留在单一设备阶段大多数实验室自动化的程度还停留在单一设备阶段，只有药企只有药企、疾控中心疾控中心、合成生合成生物学公司等场景的少数实验室实现了工作站形式的自动化物学公司等场景的少数实验室实现了工作站形式的自动化。对于大多数普通实验室来说，前端的样品处理方面，自动化程度相对而言依然非常低，需要消耗大量的人工，以及不可避免许多重复性繁琐性的工作。目前限制自动化发展的目前限制自动化发展的因素包括长期因素和短期因素因素包括长期因素和短期因素总体来说科研用户的需求更零散，人力成本低，而企业用户的用人成本高，需求相对标准化，更适合开展自动化，但是在合规性等方面的要求更高，需要更加定制化的开发，国内厂商大多达不到要求，而进口厂商大多只提供标准化的产品，不提供定制化服务。具体来说，限制自动化发展的因素包括以下几点：（1 1）长期因素：人力成本低使得投资回报率不足长期因素：人力成本低使得投资回报率不足据受访者透露据受访者透露，多项目整合的流水线多项目整合的流水线TLATLA一般一般10001000万以上万以上，单项目的单项目的TTATTA一般在一千一般在一千万以内万以内，一个一个工作站工作站的价格的价格一般一般在在万之间万之间。对于高校和研究机构来说，学生的人力成本很低，从投资回报率角度看并没有动力使用自动化设备，这个现状短期内难以改变。而对于企业来说，缩减成本开支尤为重要，需要算一笔经济账，完成自动化改造后在单位空间、人力支出所带来的收益需远高于传统方式，扣除购置收入，依然可以有显著的投资收益，才会有进行自动化改造的动力。据核算，目前采用了自动化方式的企业节约的人力成本，平均在三年左右可以覆盖设备的投入。9（2 2）长期因素：自动化长期因素：自动化产品产品在部分领域还无法满足需求在部分领域还无法满足需求液体处理是自动化液体处理是自动化相对成熟的产品相对成熟的产品，市场上国内外厂商都已经推出了一些标准化的自动移液系统。但是这类设备一般只集中在移液配液方面，针对液体的综合性处理的功能不够，针对生物领域的96孔板操作较多，而对于像384孔板、1536孔板等更精细样品的操作则相对较少。而固体处理方面固体处理方面定制性高定制性高，价格昂贵价格昂贵，购买力不足购买力不足。由于不同固体颗粒的粘性、静电作用力、密度、外形、大小等理化性质不均一，因此针对不同的固体都要开发特定的操作设备，即使进口产品也会有性价比或者稳定性方面的问题。目前基本是通过人工操作完成，在样本量比较大的情况下，导致操作繁琐，急需自动化的称量设备。如果与后续样品溶解转移相结合的话，就还需要称量校准和样品处理的集成。另外，在化学合成领域自动化程度也相对较低，合成涉及的样品条件比较复杂，需要更加复杂的集成能力。软件的合规性难以满足需求软件的合规性难以满足需求。以微生物检测为例，对于各种菌落，检测方法以及对环境的要求都不一样，而且做微生物检测的客户都需要做一些数据完整性的分析，对软件的要求非常高，目前国产软件难以通过CSV（药企换计算机需要的验证）的验证或者GMP的要求。做软件的合规，至少需要三五年的时间来打磨。虽然对于事业单位来说合规性并不需要这么高，但是对于企业来说，目前国产软件难以满足其需求。（3 3）长期因素：客户需求非标准化长期因素：客户需求非标准化实现自动化的前提是要先实现流程的标准化和模块化实现自动化的前提是要先实现流程的标准化和模块化。但由于生物和化学实验的复杂性，目前的实验室自动化还只能解决少部分的重复劳动，尤其是研发端，需求相对复杂多变，对于自动化来说，很难做到柔性很高。曾有研究机构购置了自动化设备，并针对自身的需求进行调校开发，但是由于后期调整了研究方向，原有的设备不再适用，后来自己聘用工程师重新调校，但没有达到要求，最终导致自动化设备闲置。（4 4）短期因素：市场教育不够充分）短期因素：市场教育不够充分国内的实验室自动化领域起步较晚，很多实验室研究人员对实验室自动化的产品种类和功能缺乏了解和信任，对自动化优势的了解不全面，同时对自身实验的哪些环节可以进行模块化标准化，可以进行自动化改造也不清楚。限制自动化发展的因素主要包括投资回报率不足、产品难限制自动化发展的因素主要包括投资回报率不足、产品难以满足需求、需求非标准化、市场教育不够充分等以满足需求、需求非标准化、市场教育不够充分等实验人员的传统认知是实验室自动化设备可以提高效率，实际上除了提高效率以外，实验室自动化还可以大大提高实验的准确性和通量，节省了花在繁琐实验室流程上的时间，使研究人员能够专注于科学本身，投入到更高价值的任务，而不是高重复性的实验操作，例如样品制备、样本转移、样本记录、常规管理等。具体来说实验室自动化的优势具有以下几个方面：可重复性可重复性可重复性一直是实验室的主要关注点。但实验结果，尤其是生物实验，面临着可重复性方面的广泛挑战。Nature对1576名科研人员针对“科研试验的可重复性”主题所做的在线网络调查，超过70%的科研人员无法成功重复别人的实验，有超过一半的科研人员在重复自己曾经的实验时遭遇失败。由于生物体的个体差异，生物、医疗领域的实验可重复性低于物理、化学领域。自动化可以有效减少由于实验人员操作带来的误差和污染，从而提高结果质量。例如，在研究环境中，实验室自动化可以实现更高的实验数据采集率，增加结果量，并使用更广泛的对照，从而增加结果可重复的可能性。然后可以通过设置平行实验组来建立可重复的数据。此外，自动化还可以减少实验人员样品前处理流程的操作错误，例如错误标记或放错样品，或选择错误的培养基。实验室自动化让实验人员专注于科学研究本身而非重复实验室自动化让实验人员专注于科学研究本身而非重复性实验操作性实验操作10图4丨不同领域实验的可重复性（来源：1,500 scientists lift the lid on reproducibility）数据准确性数据准确性数据准确性是实验室可以通过实验室自动化提高的方面之一。自动化设备可以检测两种化合物之间的细微差别。提高数据的可靠性和一致性。例如，在微生物实验室中，尿液样本的一致自动平板条纹可以更准确地区分潜在病原体和污染微生物群。自动化不仅可以确保结果更可靠，还可以提高数据评估的准确性。自动化还可以结合机器学习算法，提高对数据的处理分析能力。例如，对显微镜成像和革兰式染色结果分析的自动化可以改进常见血流病原体的手动分类，自动超声心动图分析可以高精度地对一系列病理进行分类。可追溯性可追溯性可追溯性是实验室自动化的另一个重要优势。将测试结果相互比较以及与标准进行比较的能力对于科研型实验室和临床诊断实验室都至关重要。可追溯性的另一个重要方面是数据来源，即描述数据历史和来源的能力。在科研型实验室中，可追溯性对于将研究结果转化为临床至关重要。而在临床实验室中，将计量可追溯性纳入2012年发布的ISO 15189标准更加突出了这一概念的重要性。在根据临床实验室的检测结果来遵循临床指南的建议去采取医疗措施的情况下，数据的可追溯性能够有效降低患者受到医疗伤害的风险。实验室自动化使得实验室对样品的处理带有有足够的文档记录和准确性，对于数据监管链条的形成有很大帮助。效率效率在各种形态和规模的实验室中，自动化设备比手动操作具有更高的效率，在重复性任务上节省的时间可以花在分析实验结果、进行实验规划规划和其他更有价值的工作上。实验室自动化还可以通过更高的分液精度来减少使用的试剂和培养基的数量，从而提高效率。实验室工作流程自动化还可以延长实验室的运转时间。例如在微生物实验室中，自动涂板系统可以每天24小时处理标本并接种培养皿。安全安全在一些实验室中，存在处理危险化学品和设备的流程。这些流程的自动化可以降低研究人员和技术人员的安全风险。实验室自动化程度的提高还降低了与感染性生物样本，如新冠、埃博拉病毒接触的风险，也避免了实验室工作人员的重复性劳损。11实验室自动化让实验人员专注于科学研究本身而非重复实验室自动化让实验人员专注于科学研究本身而非重复性实验操作性实验操作12实验室自动化产业链实验室自动化产业链代表公司代表公司进口厂商进口厂商国产厂商国产厂商上游上游关键零部件岛津、英腾、博世、霍尼韦尔鼎智科技、绿的谐波、鸣志电器、汇川技术仪器设备赛默飞、岛津、安捷伦、罗氏聚光科技、皖仪科技、禾信仪器、莱伯泰科中游：标中游：标准化产品准化产品工作站Hamilton、Tecan、Beckman、PerkinElmer奥美泰克、耐优生物、中析机器人/机械臂Brooks、电装、史陶比尔慧灵机器人、遨博机器人、节卡机器人医疗检验流水线罗氏、西门子、Beckman、雅培新产业、安图生物、迈瑞医疗中游：系中游：系统集成商统集成商生命科学自动化多场景综合解决方案赛默飞、Biosero、PerkinElmer、Beckman汇像科技、奔曜科技、晶泰科技、镁伽科技、海尔生物医疗、玄刃科技中游：细中游：细分场景解分场景解决方案决方案核酸分析、蛋白分析的样品前处理自动化Illumina、10Genomics、BD Biosciences华大智造、诺和致源、墨卓生物、谱育科技生物样本自动化低温存储赛默飞、SPT Labtech基点生物、艾尔温、原能生物细胞培养自动化康宁、RORZE-ReMed曼森生物、英诺维尔、礼达先导、华龛生物微流控芯片高通量筛选Berkeley Lights、Gingko Bioworks、Amyris、Transcriptics天木生物、墨卓生物自动化软件赛默飞、PerkinElmer、Biosero青软智控、明度智慧表1丨实验室自动化的产业链（来源：DeepTech）企业图谱：从商业模式看，中游的实验室自动化厂商可企业图谱：从商业模式看，中游的实验室自动化厂商可大致分为产品商、系统集成商和细分场景应用商，目前大致分为产品商、系统集成商和细分场景应用商，目前国内自动化领域主要的创业公司属于系统集成商国内自动化领域主要的创业公司属于系统集成商核心竞争要素：产品商比拼性价比，系统集成商比拼掌核心竞争要素：产品商比拼性价比，系统集成商比拼掌握的核心设备多少，细分场景应用商比拼客户群体数量握的核心设备多少，细分场景应用商比拼客户群体数量13（1）实验室自动化上游包括提供检测仪器设备、零部件，以及框架、密封、防火、电控系统的厂商。其中如加样针、光栅、传感器、色谱柱、真空泵等很多核心零部件，尚未实现国产化，处于被“卡脖子”的状态，未来在供应链方面可能会面临挑战。目前国产厂商在整合系统时，通常核心零部件和高端仪器不得不选择进口产品，而低端的框架、密封、防火、电控系统选择国产产品。（2）中游厂商从商业模式上大致可分为三类。第一类是产品商产品商。他们针对标准化的需求，提供样品处理工作站、机械臂、流水线等某种特定的标准化产品。这类厂商专注于打磨技术和产品打磨技术和产品，进行仪器的同质化标准化进行仪器的同质化标准化竞争竞争，比拼性能参数比拼性能参数、价格价格、应用应用、服务服务。第二类是系统集成商系统集成商。他们针对客户的非标准化的需求，集成元件、仪器、工作站、机器人、微流控、软件等技术进行定制化的开发，提供综合性解决方案，目前国内实目前国内实验室自动化领域多数创业公司验室自动化领域多数创业公司，如汇像科技、镁伽科技、奔曜科技、晶泰科技等属于这一类。他们提供多个生命科学实验室场景的解决方案，如合成生物学、微生物、分子生物学、细胞生物学、多组学等等。对于集成系统来说对于集成系统来说，掌握更多核心设备的掌握更多核心设备的厂商厂商更有话语权和定价权更有话语权和定价权。第三类是细分场景应用商细分场景应用商。他们定位介于前两者之间，既有做产品的基因，也需要根据客户需求进行定制化开发，针对某些特定细分场景提供自动化解决方案。通常基于下游产品已经积累的很大客户群体，向上游场景开发自动化应用，因此下游场景客户因此下游场景客户群体数量大的厂商会更占据优势群体数量大的厂商会更占据优势。图5丨精密玻璃注射器、加样针、高效液相色谱柱和通用移液器吸头（来源：Hamilton官网）核心竞争要素：产品商比拼性价比，系统集成商比拼掌核心竞争要素：产品商比拼性价比，系统集成商比拼掌握的核心设备多少，细分场景应用商比拼客户群体数量握的核心设备多少，细分场景应用商比拼客户群体数量14例如华大智造是国产NGS测序仪的龙头，并提供NGS测序相关服务，积累了大量用户，而进行NGS测序，需要对其样品进行统一的“DNA片段化、末端修复、3末端加A、接头连接、PCR富集、文库质检、浓度定量”测序样品前处理和建库流程，产生了大量自动化需求，因此华大智造开发了自动化样本前处理系统，拓展了实验室自动化相关业务。NGS测序服务商诺禾致源目前也在仿照华大智造的模式，开展NGS样品建库自动化业务。类似的逻辑还有聚光科技的子公司谱育科技，专注做质谱仪和色谱仪，也在开展质谱色谱检测的样本前处理自动化，墨卓生物提供单细胞测序服务，以及上游样品自动化建库产品。此外，曼森生物在做微生物发酵的生物反应器的基础上，拓展菌种高通量筛选的实验室自动化业务，英诺维尔、华龛生物做细胞培养自动化，基点生物、艾尔温做生物样本自动化低温存储，青软智控、明度智慧等公司做自动化相关软件，管理实验室的“人机料法环”，确保合规性和数据安全。另外还有一类比较新的场景是在药物筛选和合成生物学领域，利用微流控芯片技术而非传统的自动化技术来做高通量自动化细胞的培养和分选。目前这个领域国内的进行商业化的公司还比较少，代表研究团队包括清华大学的邢新会和张翀教授课题组，目前邢新会教授已参与成立了天木生物对外承接高通量筛选业务，而张翀教授参与成立的聚树生物也已搭建了一套高通量自动化筛选平台。墨卓生物的抗体发现平台（单B细胞分选平台）也是其中重要力量，可用作抗体药物筛选以及合成生物学的酶进化等领域。在一些非高端技术领域在一些非高端技术领域，如自动化移液工作站如自动化移液工作站、生物样本存储等生物样本存储等，国产品牌相对进国产品牌相对进口来说具有价格和售后服务的优势口来说具有价格和售后服务的优势，未来有望率先实现国产替代未来有望率先实现国产替代。（3）实验室自动化行业的下游是终端应用场景，研究型用户主要包括高校和科研机构、CRO公司、合成生物学公司和药企，检验检测型用户包括医院、第三方检测中心、疾控中心、海关等。商业化路径：技术商业化路径：技术-产品产品-应用场景（实验环节）应用场景（实验环节）-终端用户终端用户15产产品品形形态态机器人系统可进行样品处理、液体处理、设备操作、微孔板操作工作站分配和操作液体（如试剂、溶剂和样品）的过程自动化微孔板读板机自动执行微孔板的读数和清洗过程，通常用于高通量筛选分析生物样本系统生物样本的自动低温存储和检索自动显微镜系统自动完成在显微镜下对样品进行成像和分析的过程软件管理实验流程和实验室数据，包括样品跟踪、工作流程管理、数据分析和耗材管理等集成系统将多种类型的实验室设备集成到一个连贯且简化的工作流程中，从而实现完全自动化的实验多组学样品前处理SNP基因分型核酸提取纯化NGS文库构建酶联免疫分析蛋白组学前处理代谢组学前处理等细胞生物学细胞培养杂交瘤细胞筛选细胞株筛选等微生物学微生物检测培养基分装菌落挑选菌种分离等合成生物学菌种酶文库筛选菌种鉴定和保存分子克隆基因编辑等应应用用场场景景高校和科研机构药企、CRO公司医院、第三方检验实验室海关、疾控中心、企业质检部门等合成生物学公司研发研发检验检测检验检测多种自动化产品整合起来应用于不同的、可自动化的实验环节分子实验分子实验细胞实验细胞实验图6丨实验室自动化企业的商业化路径（来源：DeepTech）终终端端用用户户产品形态：产品形态：目前目前硬件领域硬件领域液体工作站和机械臂整合系统液体工作站和机械臂整合系统是主流是主流，软件领域与国外差距大，软件领域与国外差距大16中国实验室自动化厂商大部分在2016-2020年成立，目前产品初具雏形，仍需要足够的时间继续打磨产品，在运行稳定性、功能完备性、系统开放性等实际的交付和使用体验上与沉淀了几十年的进口厂商仍有一定差距。中国硬件技术相对成熟，在软件领域仍与进口厂商有较大差距。国产厂商优势在于国产替代的政策导向、价格优势（价格约为进口自动化设备的一半）和售后服务（工程师可随时上门），目前更多扮演着客户方案规划咨询和行业领路人的角色，交付落地仍需要厂商在人才结构和管理标准化上努力。硬件领域：液体工作站和机械臂硬件领域：液体工作站和机械臂整合系统整合系统是主流产品是主流产品液体工作站和机械臂是最早出现的也是目前比较主流的实验室自动化产品，欧美日占据领先地位。目前基于液体的处理是最主流的产品，以梯度稀释、液体合并等功能为核心可以将样品的前处理环节串联起来，广泛应用于生物工程、DNA质粒纯化、药物筛选、ELISA酶免反应、PCR前处理、DNA测序前处理、临床检验样品处理、血站系统高通量样品分析，以及各种实验室检测前处理等环节。目前液体处理从单通道到384通道，从毫升级别到纳升级别，市场需求与技术的成熟度达到了相对匹配。常见的应用如qPCR样品处理、方法筛选、NGS建库等，已经有了较长时间的应用基础，液体处理的技术已经能做到一些企业的合规性要求，目前国内实验室自动化创业的公司也多数集中在液体处理工作站基础上进行整合和应用开发。虽然有不少国产厂商提供自动化移液工作站，但在实际使用中，代替移液枪使用没有问题，但由于稳定性和开放性的原因还不能很好的集成到整套自动化流程中。在机械臂方面，国内的机械臂设计死角比较多，在功能完备性和灵活性上不能完全满足需求。图7丨全自动移液工作站（来源：中析官网）产品形态：产品形态：目前目前硬件领域硬件领域液体工作站和机械臂整合系统液体工作站和机械臂整合系统是主流是主流，软件领域与国外差距大，软件领域与国外差距大17软件领域与国外差距较大软件领域与国外差距较大实验室的自动化不仅仅是在操作流程方面，还包括样本流和信息流，除了要完成对实验仪器的操作，更要对实验仪器产生的结果或实验流程的数据结果进行整合处理。国内与国外厂商的核心差距在于软件方面，难以满足对各种流程控制的精准性和系统的开放、调度能力和稳定性要求。精准精准性性：既需要时间上样本流、信息流、操作流的精确配合，也需要空间上控制机器以极高精准度在生物实验的微小体系中精准完成动作。开放性开放性：一套自动化设备通常由多家公司提供，生态十分庞大，中控系统需要兼容各种软件，处理设备接口和数据接口，对开放性、调度能力和稳定性有很高要求。以赛默飞的LIMS软件为例，其能够实现工作流程自动化，管理样品和数据，并可根据选择的供应商的仪器和软件集成，其预构建的工作流程可根据需求变化配置和增强。图8丨LIMS软件（来源：赛默飞世尔科技官网）生物样本生物样本系统：产品的性能和渗透率有待提高系统：产品的性能和渗透率有待提高自动化生物样本系统涉及样本存储库、转运与配套设施、自动化降温和复苏设备、智慧管理软件等。以干细胞低温储存库为例，国产样本库的密闭性、温差控制、断电解决方案这几个关键性能参数离进口产品还有明显差距。图9丨蜂巢式-196气相液氮存储设备（来源：原能生物官网）应用场景：分子和细胞层面的实验环节自动化相对比较应用场景：分子和细胞层面的实验环节自动化相对比较成熟，动物层面实验的自动化仍是空白成熟，动物层面实验的自动化仍是空白18虽然从产品角度看，国内大部分厂商与进口厂商差距较大，但是国内镁伽科技、奔曜科技、汇像科技等大部分自动化初创公司是系统集成商，他们可以针对实验环节或者某些场景提供定制化解决方案，综合价格、性能、渠道等因素来选择国产或者进口产品来集成系统。目前来说大部分具有标准化流程、高重复性的实验环节已经有自动化解决方案。分子层面实验环节以标准化的样品前处理为主分子层面实验环节以标准化的样品前处理为主，适合做标准化的产品适合做标准化的产品在多组学分析样品的前处理方面，从基因组、转录组、蛋白组、代谢组等不同组学层次来看，由于NGS测序服务和疫情核酸检测的需求带动，在基因组和转录组的核酸提取纯化、NGS文库构建等产品应用已经成熟，未来随着生命科学研究、药企的靶点发现、合成生物学公司的酶学改造和代谢物检测等下游应用场景进一步拓展，相关蛋白组学、代谢组学检测需求提高，其样品前处理的市场也会打开天花板，促进相关产品进一步发展成熟。细胞层面实验环节涉及各种流程性实验细胞层面实验环节涉及各种流程性实验，适合做定制化整合系统适合做定制化整合系统在细胞生物学、微生物学、合成生物学方面，目前针对分子克隆、细胞培养、基因编辑、微生物检测等可标准化的实验环节已经有自动化解决方案。这些实验环节在下游终端客户的分布相对比较零散和交叉，如抗体药企会用到基因编辑、细胞株的筛选和细胞培养，疾控中心主要用到微生物的检测，合成生物学公司用到菌种酶文库筛选、菌种鉴定和保存、分子克隆、基因编辑等。适合以系统整合、定制化开发的方式来进行自动化改造，同时这些企业和事业单位对合规性也有较高的要求。动物层面实验环节动物个体差异大动物层面实验环节动物个体差异大，适合做人机结合的辅助性实验系统适合做人机结合的辅助性实验系统以上的实验环节的自动化集中在分子和细胞层面，但是对于动物层面的实验环节，目前仍是空白。以小鼠为例，在饲养、实验取样、加药处理等实验环节，需要剪爪、尾静脉采血、眼球取血、腹腔注射、大脑核团的指定区域注射、取卵和移植等大量重复性人工操作。对于活体动物的操作，一方面在不麻醉的情况下难以控制和定位，需要比较好的固定手段，另一方面动物个体的差异性也对自动化设备的灵活性提出了更高要求。未来可能出现类似手术机器人等辅助实验人员操作的自动化产品形态。终端用户：具有高通量筛选需求的药物研发和合成生物终端用户：具有高通量筛选需求的药物研发和合成生物学公司是近期可以较快商业化的发力方向学公司是近期可以较快商业化的发力方向19从终端用户看，实验室自动化最快能够落地的方向在于实验流程标准化的检验检测和实验流程标准化的检验检测和科研端的高通量筛选需求科研端的高通量筛选需求。在检验检测用户中，医院基本已经完成了自动化流水线的布局，国产替代是其主要逻辑，而疾控中心、企业质检药监部门、海关、司法鉴定中心等检验检测单位还有很大的机会点。在科研用户中，药物分子筛选、菌株筛选等高通量筛选会率先应用自动化技术，如上海药物所已建立了药物筛选的自动化平台，深圳先进院在搭建合成生物学自动化大设施，利物浦大学研究团队2019年发明的AI机器人化学家，也是应用在催化剂的高通量筛选中2022年初它首次通过高通量筛选自主发现了一种高活性的催化剂。因此，不考虑医学检验场景，目前兼具刚需和支付能力的生命科学类实验室主要集中在多组学测序服务公司多组学测序服务公司、大型大型CROCRO、药企药企、平台类合成生物学公司平台类合成生物学公司、部分进行高通量部分进行高通量药物筛选和合成生物学研究的科研机构药物筛选和合成生物学研究的科研机构、疾控中心疾控中心、质监药监等部门质监药监等部门以及部分政府以及部分政府买单的标杆实验室项目等买单的标杆实验室项目等。目前国内这些兼具刚需和支付能力的生命科学类实验室的数量在1000-2000个，按照单个实验室平均花费1000万人民币来预估测算，市场市场规模规模在在百百亿人民币以上亿人民币以上（此外，国内非生命科学的实验室也有非常多，拿世界五百强企业和事业单位来说，国内的实验室有支付能力的在5000个以上）。但因市场还在发展早期、缺乏典型的标杆案例，规模化应用无从谈起，市场规模的计算目前还只是一个数字。对自动化厂商来说，多去跑几家客户，打开市场才是实际。对于企业用户应用自动化，需要先得到法律法规、行业专家或者是相关第三方的认可，因此自动化厂商打造完产品和应用场景解决方案后，找到标杆客户是打通商业闭环的最后一步。只有在事业单位、科研机构以及大型企业先适用，通过标杆客户和案例来打磨和推广产品，才会带动实验室自动化的规模化应用。在具有高通量药物筛选需求的药企和在具有高通量药物筛选需求的药企和CROCRO企业中已有实企业中已有实验室自动化应用案例验室自动化应用案例20晶泰科技与礼来签署药物发现合作晶泰科技与礼来签署药物发现合作，以以AI AI 实验机器人驱动首创新药研发实验机器人驱动首创新药研发2023年5月31日，晶泰科技与礼来宣布签署一项2.5亿美元的协议，实现在AI小分子新药方面的合作。晶泰科技将利用AI药物研发平台“干实验室”与自动化机器人“湿实验室”结合的技术优势，从头设计候选化合物，综合评分最高的分子将在由数百台机器人工作站组成的自动化实验室中被合成出来，经过一系列生物化学，细胞，药理药代等测试验证其活性和成药性，而计算数据和实验数据会快速反馈给其算法平台，形成AI算法与真实实验的DMTA（设计-智造-测试-分析）闭环，为礼来从头设计并交付具有竞争力的候选化合物。镁伽科技与义翘神州达成深度战略合作镁伽科技与义翘神州达成深度战略合作2023年4月18日，镁伽科技与国内蛋白、抗体研发生产商义翘神州签署战略合作协议，双方将针对打造新一代智能化、自动化实验平台展开合作。此次交付的全自动质粒构建系统是基于镁伽全自动分子实验平台与义翘神州应用场景相结合开发的分子克隆平台，实现质粒构建实验中PCR扩增、连接、转化、克隆挑选等各项操作的全流程自动化，满负荷运行情况下，预计可节省人工90%，并可帮助综合提升实验室产能,满足义翘神州对于分子构建的高通量需求。汇像科技交付为英矽智能搭建的汇像科技交付为英矽智能搭建的“AI AI 机器人全自动化实验室机器人全自动化实验室”2022年12月29日，由AI制药公司英矽智能在苏州BioBAY举行启动仪式，正式交付历经6个月建成的由AI辅助决策的全自动化机器人实验室。该智能机器人实验室涵盖一套由汇像科技定制研发的、可实现多种功能岛的独立运行和串联、并对整体实验流程进行时序优化和智能控制的自动化解决方案，聚焦靶点发现、化合物筛选、个性化药物开发和转化医学研究等领域。汇像科技提供的实验室自动化解决方案，可实现细胞培养、核酸分子鉴定、高通量药物筛选、高通量NGS测序前样本建库、蛋白纯化和鉴定、LCMS质谱样本前处理等应用方向的智能化操作，打造真正的无人化实验室。在具有高通量细胞株筛选需求的合成生物学研发机构中已在具有高通量细胞株筛选需求的合成生物学研发机构中已有实验室自动化应用案例有实验室自动化应用案例21深圳合成生物学创新研究院的深圳合成生物学创新研究院的“合成生物研究重大科技基础设施合成生物研究重大科技基础设施”（大设施大设施）“合成生物研究重大科技基础设施”是深圳市光明区科学城建设优先启动和布局的重点项目之一，由深圳市政府投资建设，中国科学院深圳先进技术研究院为建设牵头单位，司同研究员作为总工艺师，华大生命科学研究院、深圳第二人民医院参与建设。“大设施”重点建设内容包括设计学习平台、合成测试平台、用户检测平台三大平台。设计学习平台利用生物信息、数理模型、生物合成大数据及人工智能等手段，针对特定科学需求，提供实验方案，并生成合成测试平台的可执行指令。软件工具及数据库以自主研发为主。合成测试平台主要由大片段DNA、噬菌体、细菌、酵母等系统组成，将通过搭建自动化模块，作为“功能岛”执行特定功能，并根据需求实现各类“生产线”的柔性化集成；关键技术装备研制遵循红蓝军路线，兼顾自主创新与吸收国外先进技术。用户检测平台整合蛋白质与代谢产物分析、底盘细胞放大培养、高级成像三大检测系统，对合成产物进行多模态跨尺度的全方位测试。“大设施”旨在建设一个针对人工生命体智能化设计及自动化铸造的基础大平台，基于智能化、自动化及高通量设备，搭建用于生物元器件、复杂网络、人工细胞等多维度合成生物的合成、组装、植入、激活与测试的合成生物研究装置，结合设计软件与机器学习的深度研发，快速、低成本、多循环地完成“设计构建测试学习”的闭环，实现人工生命体理性设计合成。浙江大学生物与分子智造研究院的浙江大学生物与分子智造研究院的“合成生物学自动化科学装置合成生物学自动化科学装置”（iBioFoundryiBioFoundry）合成生物学自动化科学装置是浙江大学生物与分子智造研究院的重点建设内容之一。该装置在中央软件控制下通过轨道式机械臂整合包括自动化移液操作、生物样品存储、细胞培养和生化测试等的各种实验设备，实现合成生物学研究中从样本智能存取、DNA元件组装、细胞筛选及培养到产物检测的全流程自动化操作，达到高通量实验的标准化和高效率目标，可将人工细胞构建效率提高两个数量级以上。未来在未来在微量反应体系微量反应体系的的高通量实验室自动化高通量实验室自动化进程中，进程中，微流控芯片技术微流控芯片技术的进步和应用的进步和应用是是重要的发展趋势重要的发展趋势22微流控芯片可在微纳尺度进行自动化实验微流控芯片可在微纳尺度进行自动化实验微流控芯片（Microfluidics），又称“芯片实验室”（lab-on-a-chip），可以把生物、化学、医学分析过程的样品制备、反应、分离、检测等基本操作单元集成到一块微米尺度的芯片上，自动完成分析全过程。微流控芯片是微流控技术的下游应用单元，通过微型电子机械系统（MEMS）技术，微流控芯片能够在固体芯片表面构建微型生物化学分析系统，快速、准确地实现对核酸、蛋白质、细胞及其他特定对象的处理和检测，在芯片上的微米级的流道内部实现常规实验的自动化。目前微流控芯片在生命科学领域已经得到了广泛的应用，如POCT分子诊断、生物化学和免疫学检测、单细胞多组学分析、药物筛选、单B细胞筛选、菌株定向进化等。图10丨单细胞建库的流程图（来源：墨卓生物）微流控芯片具有缩短反应时间微流控芯片具有缩短反应时间、提高反应通量提高反应通量、降低反应消耗的优势降低反应消耗的优势单细胞测序技术（single cell sequencing）是指在单个细胞水平上，对基因组、转录组、表观组进行高通量测序分析的一项新技术，它能够弥补传统高通量测序的局限性，揭示单个细胞的基因结构和基因表达状态，反映细胞间的异质性。最早的单细胞测序技术，通过分离出单个细胞，独立构建其测序文库，并进行测序，代表技术包括：主要运用于细胞样品的流式细胞仪技术（Luorescence Activated Cell Sorting,FACS）以及主要运用于组织切片样品的荧光捕获显微切割（Laser Capturemicrodissection,LCM）等。这类方法简单直接，但也存在显而易见的共通缺陷：低通量，高成本当所测单细胞数量较低时，研究结果不足以反映问题；而随着所测数量增长，测序的成本也随之呈线性提升。哈佛大学大卫韦兹教授通过微流控技术，在2015年发表了inDrop和Drop-Seq两种方法，单细胞转录组测序取得了重大突破，它们结合了微流体和核苷酸条形码进行回顾性鉴定，这些方法能够对数千个细胞进行平行分析，用于多种测序方法。微流控技术的使用，使单细胞测序的成本从每个细胞数千元降低到数元，时间加速了超百倍。23基于微流控芯片的自动化需求仍未被充分满足基于微流控芯片的自动化需求仍未被充分满足，多步法微流控技术是微流控自动化多步法微流控技术是微流控自动化大规模大规模应用应用的瓶颈的瓶颈。当前主流的微流控技术是一步法，而实际上部分实验的复杂性导致了一步法微流控技术无法满足需求。目前复杂步骤的微流控技术仅有少量公司能够产业化，例如中国已有公司在液滴微流控技术基础上进行创新，首创四步法的微流控芯片操控技术，可对微液滴进行生成、注射、分选、融合操作，在芯片上自动完成步骤更加复杂的实验，如微生物单细胞测序的建库实验等，实现了移液工作站的功能。液滴融合液滴融合:两个平行液滴通过压力和特殊的流道设计进行融合液滴微注射液滴微注射:向制好的液滴添加成分以发生二次反应液滴分选液滴分选:荧光信号识别并进行液滴分选图11丨液滴注射、分选、融合技术（来源：墨卓生物）未来在未来在微量反应体系微量反应体系的的高通量实验室自动化高通量实验室自动化进程中，进程中，微流控芯片技术微流控芯片技术的进步和应用的进步和应用是是重要的发展趋势重要的发展趋势24高通量单细胞微生物基因组学是高通量单细胞微生物基因组学是多步法微流控技术多步法微流控技术的典型案例的典型案例郑文山博士和David Weitz教授合作在Science上发表了“Microbe-seq”方法学突破，基于四步法液滴微流控操作技术和定制开发的生物信息学分析手段，不需要培养即可从复杂微生物群落中获取成千上万个单细胞微生物的基因组信息，并组装出高质量的菌株水平基因组，从而能够在不损失分辨率或广泛物种适用性的基础上探究微生物群落的基因组。该方法可用于具有复杂微生物群落的样本，如粪便、土壤和海洋等，在微生态研究中具有极大的市场应用潜力，开创了单细胞微生物组学的新时代。图12丨单细胞微生物组测序技术（来源：High-throughput,single-microbe genomics with strain resolution,applied to a human gut microbiome，Science）微流控芯片的应用受限于传感器技术微流控芯片的应用受限于传感器技术除了多步法微流控技术之外，微流控芯片的应用还受限于传感器技术。目前比较成熟的传感器是基于荧光标记，来进行待测物检测和细胞的分选。受限于传感器技术，部分实验室流程不适合用微流控芯片来进行自动化。目前学术界正在开发能够检测赖氨酸、谷氨酸等相应小分子的传感器，未来随着传感器技术的发展，微流控芯片将会在实验室自动化领域拓展更大的应用空间。未来在未来在微量反应体系微量反应体系的的高通量实验室自动化高通量实验室自动化进程中，进程中，微流控芯片技术微流控芯片技术的进步和应用的进步和应用是是重要的发展趋势重要的发展趋势合成生物学、抗体开发合成生物学、抗体开发等等实验室自动化需求迫切的实验室自动化需求迫切的领域领域，也也亟待微流控技术赋能亟待微流控技术赋能25合成生物学的合成生物学的DBTLDBTL循环需要构建工程化平台以满足高通量实验需求循环需要构建工程化平台以满足高通量实验需求合成生物学需要高通量的造物能力。利用各种生物元件对底盘细胞基因组进行改造的元件工程、线路工程、基因组工程以及后续的代谢工程等，都对下游产物的量产至关重要。通过基因扩增、DNA重组、质粒构建、细胞培养、诱导表达、单克隆筛选、产物鉴定等一系列技术进行研发、测试、生产工作，实现DBTL（设计-构建-测试-学习）循环，经工程化的海量试错，优化工艺流程，最终完成工程化平台的建设。在DBTL循环中的大规模构建完成后，测试成为一个限速步骤。例如一个100个氨基酸的蛋白，有20的100次方种可能，而测试每一个样品需要30分钟，一周最多测几百个，以这个速度永远是测不完的。生命的高度复杂性使其类似于黑箱，很多时候都需要高通量的方式先求解，再通过逆向工程去研究原理。当下合成生物学领域火热的“生物铸造厂（BioFoundry）”，以及SDL实验室（self-driving laboratoy）等全自动无人化实验室相关概念，正是为了满足高通量的实验需求，将机械自动化与微流控芯片自动化相结合，而建设成的大型工程化平台。图13丨合成生物学的DBTL（设计-构建-测试-学习）循环（来源：Artificial intelligence:a solution to involution of designbuildtestlearn cycle）微流控技术亦可用于高通量微流控技术亦可用于高通量抗体筛选抗体筛选，提升筛选提升筛选效率效率抗体开发市场广阔，广泛应用于诊断试剂以及抗体药物等制造领域，如IVD抗原检测以及抗体药物筛选。自1986年第一个鼠源单克隆抗体药物OKT3上市以来，FDA共批准了超过100款抗体药物，每年批准的抗体药物约占据批准新药的1/5。据医疗数据开放平台Insight发布的2022年全球药品销售额TOP100的数据显示，在销售额排名的前10种药品中，4种为抗体药（其中3种为单克隆抗体）。此外，2022年全球单抗药物市场规模超2000亿美元，国内市场扩大至890亿，这表明单克隆抗体市场规模巨大，开发意义重大。传统抗体筛选方法周期长达数月、筛选效率低。高通量且高效的抗体筛选能够加速提高抗体开发的成功率。在抗体开发过程中，杂交瘤技术、噬菌体/酵母展示技术是抗体筛选的主要方法，然而，这两种方法都具有周期长（2-3个月）、效率低（如杂交瘤技术中，高效融合效率仅有1/1000）的特点，限制了抗体筛选的速度。因此抗体筛选效率低是抗体研发的痛点，迫切需要高效筛选平台出现。据调研，目前85%以上的抗体研发用户都希望提升抗体筛选效率，并表示如果出现较好的筛选平台，愿意取代杂交瘤等传统技术。单B细胞分选平台攻克传统技术局限性，通过识别液滴中的荧光信号，利用介电泳使液滴偏转到不同流道，从而实现高效分选，具有通量高（通量可达105-106）且筛选周期短（从数月缩短至1天）的特点，直接对单B细胞或分泌抗体进行分析，可广泛应用于抗体筛选、酶的定向进化、细胞系开发等领域。26图14丨单B细胞分选结合VDJ测序流程（来源：墨卓生物）合成生物学、抗体开发合成生物学、抗体开发等等实验室自动化需求迫切的实验室自动化需求迫切的领域领域，也也亟待微流控技术赋能亟待微流控技术赋能芯片自动化芯片自动化与机械自动化的结合与机械自动化的结合或或是实验室自动化的是实验室自动化的终极形态终极形态27芯片自动化与机械自动化技术形成高效互补芯片自动化与机械自动化技术形成高效互补目前使用液体处理机器人工作站来自动化合成生物学实验的流程正在蓬勃发展，例如Ginkgo Bioworks或Amyris等公司使用这些工作站将其发现过程自动化，有些公司甚至对外提供自动化服务。典型的分子生物学过程，如通过电穿孔进行细胞转化、菌落挑选、平板培养和生长，在液体处理工作站和其他仪器中虽然可行，但在全自动实验室方面存在限制，很难以全自动实验室所需的无缝方式将它们连接在一起。液滴微流控技术通过将细胞和试剂封装在液滴中并对其进行精确操作，可以实现无缝集成。微流控平台已经被用于生物反应的小型化，包括DNA合成和组装、转化、无细胞表达，以及荧光和质谱法进行表型筛选。通过将这些功能与嵌入在半导体芯片上的新型分子传感器、光学激活微小传感器、通过荧光纳米钻石监测自由基、通过光遗传学调节代谢或通过光操纵细胞等新技术相结合，可以实现在单细胞尺度上，对细胞进行分选、培养等操作。来自生物反应器的微流控采样还可以实现细胞在其环境中细胞的实时传感和成像，实现连续的数据采集。技术技术机械臂、工作站自动化机械臂、工作站自动化微流控芯片自动化微流控芯片自动化优势优势相应传感器技术比较成熟可进行单细胞水平的分选和培养，实验通量高、成本低、时间短适合场景适合场景线性实验流程高通量反应体系具体实验具体实验环节环节多组学样品前处理、质粒构建、分子克隆、文库的构建和设计、菌落挑选、基因编辑等细胞培养、药物筛选、单细胞分析建库、菌株定向进化、筛选、传代、备份等表2丨机械自动化与微流控芯片自动化的对比（来源：DeepTech）28结合可行性、成本、技术成熟度等方面综合考虑，目前例如聚树生物、中科欣扬等合成生物学公司自动化改造的策略是，能够用微流控技术来自动化实验流程的就采用微流控技术，否则采用工作站、机械臂等机械自动化平台。通过将超高通量的微流控“小设施”与自动化机械臂的“大设施”相结合，更高效深入的进行基因-表型数据挖掘和菌株优化。“小设施”可无缝衔接现有自动化系统，建立超高通量CHO 微生物底盘工程生物学蛋白生产平台，实现更高效的合成生物开发流程。超高通量液滴微流控筛选技术：拥有不同尺寸微液滴(皮升/纳升/微)操控平台，快速实现单细胞微液滴的生成、培养及分选。高性能合成生物传感技术：基于原创的合成生物传感器构建和性能调试平台，开发了一系列具有自主知识产权的生物传感器，用于检测小分子代谢物和重组蛋白的浓度，其中后者更是具有通用性这一显著优势，已成功应用于若干重要工业菌株的高通量选育。图15丨液滴微流控与自动化技术平台（来源：聚树生物）基于液滴微流控技术的基于液滴微流控技术的“小设施小设施”平台平台基于自动化机械臂的基于自动化机械臂的“大设施大设施”平台平台筛选通量为106-107/天，相比传统孔板筛选体系速率提高1万倍，试剂消耗量下降100万倍，菌株优化可达40批次/年，每批次可获得高产菌株1020株；CHO哺乳动物细胞株或重组蛋白产品年研发20批次/年，每批次可获得高产细胞株为25株；重组蛋白产量高达30 g/L。可进行自动化分子克隆和菌株性能测试评价，测试通量为3000/天。DREM CellDREM Cell10106 6/天天MISS CellMISS Cell10103 3/天天EVOL CellEVOL Cell10102 2/天天流式细胞仪流式细胞仪10108 8/天天分子克隆分子克隆500/500/天天菌株筛选和表型检测菌株筛选和表型检测3000/3000/天天芯片自动化芯片自动化与机械自动化的结合与机械自动化的结合或或是实验室自动化的是实验室自动化的终极形态终极形态AcknowledgementAcknowledgement感谢以下接受访谈并对报告内容提供观点支持的专家（排名不分先后）：国家认监委数字化标准工作组专家杨治国墨卓生物资深科学家徐云飞中科欣扬高级科学家陈永丽浙江中控高级工程师王容楠大连奥凯机电总经理王晓东AboutAbout thethe ReportReport生命科学行业迫切需要一场工业革命，实验室自动化的变革即将到来。本报告重点关注在生命科学场景应用的实验室自动化技术，通过桌面调研和专家访谈等方式，探讨实验室自动化的发展现状、限制因素、产品形态、应用场景、终端用户、商业模式、未来发展前景等问题。AboutAbout UsUsDeepTech 成立于 2016 年，是一家专注新兴科技的资源赋能与服务机构，以科学、技术、人才为核心，聚焦全球新兴科技要素的自由链接，为产业、政府、高校、科研院所、资本等科技生态的关键角色提供服务，通过科技数据与咨询、出版与影响力、科创资本实验室三大业务板块，推动科学与技术的创新进程。PleasePlease useuse thethe followingfollowing toto referencereference thethe reportreport 2023实验室自动化行业研究报告,2023.DeepTech 2023 Insights.China.DeepTech 202327DisclaimerDisclaimer本报告由 DeepTech 发布，其版权归属北京演绎科技有限公司（DeepTech），DeepTech 对此报告拥有唯一著作权和解释权。没有经过 DeepTech 的书面许可，任何组织和个人不得以任何形式复制、传播等。任何未经授权使用本报告的相关商业行为，DeepTech 将依据中华人民共和国相关法律、法规追究其法律责任。本报告所载数据和观点仅反映 DeepTech 于发出此报告日期当日的判断。DeepTech对报告所载信息的准确性、完整性或可靠性做尽最大努力的追求，但不作任何保证，以官方/公司公告为准。在任何情况下，本报告中的信息或表述均不构成任何投资等建议，本公司对该报告的数据和观点不承担法律责任。不同时期，DeepTech 可能会发布其它与本报告所载资料、结论不一致的报告。同时 DeepTech 对本报告所载信息，可在不发出通知的情形下做出修改，请读者自行关注。FindFind OutOut MoreMorehttps:/https:/ContactContact UsUM： 86 OfficeOffice北京市朝阳区亮马河大厦2栋17层上海市徐汇区淮海中路1325号瑞丽大厦7层浙江省杭州市余杭区仓前街道梦想小镇创业大街8幢B座广东省深圳市南山区云科技大厦7楼28DeepTech 2022

0人已浏览 2023-12-21 31页 5星级

Intel+ISV+OEM，重塑AI PC生态系统证券分析师：杨海晏 A0230518070003袁航 A0230521100002刘洋 A0230513050006研究支持：李天奇A02305220. 

0人已浏览 2023-12-21 24页 5星级

 AIGCAIGC专题报告：专题报告：站在当前时点，怎么看站在当前时点，怎么看AIGCAIGC板块投资逻辑板块投资逻辑评级：推荐(维持)证券研究报告2023年12月19日海外陈梦竹(证券分析师)S请务必.

0人已浏览 2023-12-21 32页 5星级

生成式人工智能的风险和机遇管理2023年10月管理层指南管理层指南 治理为治理为先先中国内地和香港地区搭建可信赖的人工智能搭建可信赖的人工智能坚持负责任的人工智能目录引言 2企业面临的风险 4生成式人工智能对企业的影响 5识别生成式人工智能的应用场景 6管理新增和加剧的风险 8董事会和董事成员可采取的措施 10高级管理层可采取的措施 11底线 13普华永道风险及控制服务部门的服务 14联系我们了解更多信息 151生成式人工智能的风险和机遇管理2022年11月，我们迎来了一场真正的革命。一夜之间，即便是仅会使用聊天软件的网民都感受到了人工智能的魔力。在短短一周内，便有上百万用户通过ChatGPT撰写短文、编写计算机代码、创作艺术、把长文精炼为更有文采、更简洁的短文。与此同时，一些心怀不轨的群体则试图利用生成式人工智能编写恶意软件、散播更具迷惑性的钓鱼邮件和伪造更逼真的虚假身份。这似乎预示着大规模欺诈、隐私泄露、虚假信息和网络攻击正向我们袭来。在ChatGPT亮相仅数月后，生成式人工智能便深入地融入我们的生活和业务。活跃消费用户增长之快前所未有。从OpenAI的GPT3到GPT4，人工智能的功能实现了飞跃，在代码编写和中级专业写作方面的成绩显著。各大科技公司也不甘落后，纷纷推出/更新竞争产品；创业公司发布了定制应用程序的模型；包括普华永道在内的各大公司已宣布大规模投资自家的“CompanyGPT”，以供内部使用和对外提供新服务。但担忧也随之而来，有人告诫“具有人类竞争智能的人工智能系统可以对社会和人类构成深远的风险”，社会大众和行业专家对此都深感忧虑。该项技术的头部供应商也承认存在类似风险。引言2生成式人工智能的风险和机遇管理公司是否会冒险以信任换速度？公司是否会冒险以信任换速度？风险管理关乎成败。如果公司希望成功实施生成式人工智能计划并取得竞争优势，则需要评估该技术可能给全公司带来的风险。为此，公司需要一套风险管理框架，以便更好地抓住机遇。针对生成式人工智能，采用以风险为导向的方法将确保公司在数字化道路上，始终符合监管机构、消费者和其他利益相关者的期望。公司只有在采用生成式人工智能的同时建立信任，才能快速、充分地利用这项改变世界的技术带来的红利。企业正在投资包括人工智能在内的新兴技术。（资料来源：普华永道，2023年）中国受访者认为，产品和服务采用人工智能的利大于弊（资料来源：益普索，2022年）员工认为，加速采用人工智能有助于事业发展（资料来源：益普索，2022年）只有只有46%中国内地及中国内地及68%中国香港中国香港78H%3生成式人工智能的风险和机遇管理企业面临的风险生成式人工智能是人工智能家族中的一个强大分支，对企业具有颠覆性影响。它能够支持企业运营的几乎所有方面（包括客户服务、软件开发和数据分析）实现自动化和提升。借助人工智能，公司能针对不同客户定制个性化互动，改善互动方式，从而提升客户关系。人工智能可以自动完成批量任务，例如处理保险索赔和沟通或执行某些软件开发任务。通过人工智能，团队能更轻松地了解非结构化数据，包括合同、发票、客户反馈、保单、保险理赔员告知单、绩效评估、医疗记录等。员工生产力可以大幅提升。根据OpenAI的估计，每10名员工中约有8名*可通过生成式人工智能自动完成其至少10%的工作任务，而这仅仅是起步。生成式人工智能工具可以自动完成例行任务，使员工得以解放，从而投身更具创造性的工作，或以更创新、更全面的方式理解复杂主题和任务，提升批判性思维。随着技术需求的持续增长，生成式人工智能的功能也在不断进步。仅仅不到四个月，人工智能语言系统就在复杂度和功能性两方面取得了显着进步，发展劲头势不可挡。公司想要搭上人工智能的快车，实现持续发展，则需尽早招募风险专业人员。如此方能树立公司信心，顺利实施和推进生成式人工智能项目。公司的风险管理人员必须管理好新增和加剧的风险，以及在业务、法律和监管方面的一系列挑战。白宫、美国国会、美国联邦贸易委员会、中国国家互联网信息办公室和欧盟相继采取行动，对生成式人工智能进行监管。与此同时，针对生成式人工智能违反数据保护法，在未经同意的情况下，收集、使用和披露个人信息的行为，部分国家（意大利、加拿大、西班牙、法国、德国）展开了调查，以此响应社会各界的不满或担忧。随着生成式人工智能技术日益普及，中国国家互联网信息办公室（网信办）、国家发展和改革委员会（发改委）、教育部、科学技术部（科技部）、工业和信息化部（工信部）、公安部和国家广播电视总局（广电总局）于2023年7月10日联合发布了生成式人工智能服务管理暂行办法，并于2023年8月15日生效。2023年10月18日，中央网信办更进一步发布全球人工智能治理倡议。习主席在中共中央政治局会议上指出，“要重视通用人工智能发展，营造创新生态，重视防范风险”。*资料来源于美国某项研究4生成式人工智能的风险和机遇管理企业在涉足生成式人工智能时需重点关注以下方面。职能转型：重构运营职能转型：重构运营。为快速获得投资回报，部署生成式人工智能的“最佳着力点”很明确，即于运营各方面（例如营销、财务、供应链和税务合规）全面部署，以实现自动化和提升。凭借生成式人工智能，公司可最大限度地利用现有资源、强化决策能力、提升客户和员工体验。生成式人工智能可以优化数据集和文档集的整理，简化人工研究工作，还可用于起草财务、风险和合规性报告、定制个性化客户服务方案、识别人工报告中违规点。然而，为确保结果可靠，企业应依托负责任的人工智能框架施加强有力的监管。负责任的人工智能：建立信任和管理风险负责任的人工智能：建立信任和管理风险。企业想要通过生成式人工智能实现彻底革新，信任是首要前提。这需要企业负责任地使用人工智能，制定精细的实施方案，确保使用过程中的诚信和道德标准。通过整合技术、流程和技能，负责任的人工智能框架可以解决生成式人工智能的相关风险，例如网络威胁、隐私问题、法律影响、性能问题、偏见和知识产权风险。为了有效实施负责任的人工智能，最好的方法是将信任融入设计，从起步阶段便将信任纳入公司体系，并根据经验教训不断完善。员工：培养技能员工：培养技能，适应新工作方式适应新工作方式。生成式人工智能可以为知识型员工赋能，助力员工在更短的时间内取得更大的成果。然而，为了充分利用人工智能的潜力，公司应当为员工提供必要的技能培训，适应新工具和新工作方式。企业必须深谙运用之道，切勿因生成式人工智能看似简单而掉以轻心。随着人工智能的采用，新的岗位也将应运而生，如提示工程师和模型专家。这些人才的组合好比“人工智能工厂”，为企业人工智能系统的实施和维护提供支持。云和数据：奠定增长基础云和数据：奠定增长基础。生成式人工智能可挖掘非结构化数据的潜力，以此支持决策优化、收入增长和业务扩展。在推进数据和应用程序现代化时，公司应当充分考虑生成式人工智能，进而从根本上改变云应用的构建和运作方式。新商业模式：数据货币化和行业重塑新商业模式：数据货币化和行业重塑。如果企业能自主地将非结构化数据转换为可实现的构想或新软件代码、产品、服务，或为每位客户提供真正意义上的定制体验，未来将会如何？生成式人工智能提供了这种可能，它既能建立新商业模式，也能颠覆基本价值链。企业在利用生成式人工智能提升运营效率的同时，不妨思考这项技术在近期将如何实现公司业务和所在行业的颠覆。生成式人工智能对企业的影响5生成式人工智能的风险和机遇管理生成式人工智能生成式人工智能优异的工作表现对员工的优异的工作表现对员工的益处益处生成技术可生成全新的文本、代码、图像、音频、视频等。团队和员工个人每天产出何种类型的团队和员工个人每天产出何种类型的内容内容？行业行业任务类型任务类型生成式人工智能可在企业运营的大多数方面（从客户服务到软件开发和数据分析）实现自动化和提升。企业可以从以下角度识别应用场景。识别生成式人工智能的应用场景自上而下自上而下自下而上自下而上生成式人工智能生成式人工智能在各在各行业和行业和业务职能方面的用途业务职能方面的用途生成式人工智能技术能够解决不同行业（例如医疗保健、科学研究和金融）的众多问题。哪些生成式人工智能技术可用于哪些生成式人工智能技术可用于企业企业所在所在的行业的行业？生成功能如何助力生成功能如何助力企业企业立于不败立于不败之地之地？业务职能业务职能生成式人工智能技术可用于研发、营销、销售、客户支持、运营、法律和后台流程。生成式应用程序如何提供尽善尽美生成式应用程序如何提供尽善尽美的服务的服务？某些类别的任务（如汇总、转换和问答）最适合生成模型的技术机制。这些功能如何融入这些功能如何融入企业企业的业务流程的业务流程？输出数据形式输出数据形式6生成式人工智能的风险和机遇管理企业的IT和风险专业人员可以帮助企业加速实施负责任的生成式人工智能。他们可以确保生成式人工智能的隐私保护到位、公平（不良偏见得到有效管理）、有效可靠、负责透明、可解释和可说明。换言之，即是赢得信任。7生成式人工智能的风险和机遇管理数据风险错误信息传播、知识产权或合同问题（因未经批准使用数据），或因采用低质量数据训练生成式人工智能模型而产生的误导性和有害内容。模型和偏见风险在语言模型开发时，违反道德和负责任的人工智能原则，导致输出歧视性或不公平的内容。提示或输入风险向人工智能模型提供粗浅提示或问题而生成的误导性、不准确或不良回答。用户风险用户在不知情的情况下采纳错误信息和其他不良内容而导致的意外后果。例如，用户可能会将人工智能产生的虚假信息（即错误或荒谬的回答）当作事实。因生成式人工智能的使用情况不同，公司还可能面临其他风险，尤其是在公司计划创建与基础模型关联的专有模型并添加专有或第三方数据的情况下。公司的风险专业人员有助于获取各利益相关方对生成式人工智能的信任。因此，他们应将信任融入设计，以信任为价值主张，而非一味追求速度，以此赢得客户、投资者、业务合作伙伴、员工和社会的认可。风险领域专家应考虑隐私、网络安全、合规、第三方管理、法律义务、知识产权方面的全部风险，并相互协作管理好整体企业风险。同时，公司应与人才/人力资源负责人合作，制定各级培训计划，让每位员工熟知生成式人工智能的风险与回报。安排经验丰富的人员检查生成式人工智能输出的“初稿”。监控员工表现，防止随时间推移出现“技能萎缩”、自满、质量下降的情况。各种成熟的框架为设计和部署值得信任的人工智能应用程序提供了良好开端，其中包括香港政府资讯科技总监办公室（OGCIO）发布的人工智能道德框架、香港个人资料私隐专员公署（PCPD）发布的开发及使用人工智能道德标准指引、中国银行保险监督管理委员会发布的关于银行业保险业数字化转型的指导意见以及IS0/IEC 23053:2022 使用机器学习（ML）的人工智能（AI）系统框架。管理新增和加剧的风险我们认为，公司需要了解和管理该技术的以下四大固有风险：8生成式人工智能的风险和机遇管理打造值得信任的人工智能的关键治理要素生成式人工智能所带来的关键风险以及风险管理人员可采取的措施，请参阅后续各章节。关键输入项和依赖关系多元包容的团队领导层参与员工队伍和技能规划政策和程序明确风险管理框架风险容忍度明确第三方风险管理岗位和职责清晰对于公司而言，制定有效的人工智能治理策略至关重要。除风险管理专业人员外，公司内外部人员均可能影响公司负责任地使用生成式人工智能的能力，包括数据科学家、数据工程师、数据提供方、领域专家、社会与文化分析师、多样性、公平性、包容性与可接取性、社区影响领域的专家、用户体验设计师、治理专家、系统出资人、产品经理、第三方实体、评估人员以及法律和隐私保护专业人员。2.模型验证采用以风险为导向的测试方法，包括设计评估指标和验收标准。数据安全有效性和可靠性安全性和稳健性透明度和问责制可说明性和可解释性隐私保护公平（有害偏见管理）性能和商业价值3.模型管理在生产环境中人工智能模型部署、操作和监控的关键控制。性能监控（即漂移）效益管理变更和发布管理问题管理配置和版本管理人工监督培训和技能提升反馈机制1.模型设计和开发人工智能模型规划、设计、采购和/或开发流程的关键控制。法务与监管合规性影响分析和风险评估战略调整和业务关怀模型设计、方法和假设范围和要求明确限制、防范措施和超驰控制方案分析培训数据9生成式人工智能的风险和机遇管理首先，董事会要提高董事对人工智能和生成式人工智能的认识，利用管理层和外部资源，紧跟技术发展潮流，与时俱进，了解新的用例、商业模式的变化、相关风险并坚持负责任的实施原则。董事需要从业务角度考虑人工智能和生成式人工智能技术及其使用董事需要从业务角度考虑人工智能和生成式人工智能技术及其使用。董事会行使监督职能，负责向管理层提出问题（本报告中分享了一些可供借鉴的示例），并适时向管理层提出质疑。董事会应考虑采用人工智能和生成式人工智能是否需要额外的技能，或是否依赖管理层或第三方。董事会和董事成员可采取的措施复核人工智能复核人工智能的应用成本和效益董事会应当与管理层讨论应用人工智能的总体效益和成本。从效益角度出发，企业需要重新构想完成工作的方式，包括员工的工作方式、与客户的互动方式、销售的产品和竞争方式。管理层希望营造一种鼓励员工学习新技能、激励员工快速创新以抓住新机遇的上海品茶，因此，公司可能需要投入成本，为全体员工提供人工智能和生成式人工智能应用方面的知识和技能培训。考虑考虑与利益相关方的沟通董事会还应考虑公司如何向内外部利益相关方讲好人工智能故事；管理层注重战略变革，以期在当今瞬息万变的商业环境中保持适应能力和竞争力确保采取防范措施以保护员工、客户、制定制定问责治理模型公司需要建立问责治理模型，首先要明确公司内部人工智能治理的责任。有效的治理模型使公司能够评估与特定技术和单个用例相关的独特效益和风险权衡。监督监督人工智能监管计划以衡量项目成果管理层需要确定人工智能的发展方向及优先使用场景。当公司确定了这一发展道路，可能需要进行大规模的数字化转型，同时需要大量投资。为实现公司转型而进行重大投资时，董事会应了解人工智能的数字化转型战略和计划，以及如何与业务战略保持一致。10生成式人工智能的风险和机遇管理首席数据官：首席数据官：确保数据准确无误，数据已清洗，不偏倚某些人群、年龄组等。首席合规官：首席合规官：确定数据的使用满足当地健康记录法规和隐私法的合规性义务，例如：健康保险法、个人健康档案法、老年护理法和当地非健康个人隐私保护法规。首席产品官：首席产品官：配合采取隐私保护融入设计的方法，并让用户了解其输入信息将如何被使用，哪些数据将被保留。首席技术官：首席技术官：为该使用场景设计一个专用实例，避免无意中将数据与其他运行中的生成式人工智能工具混用。首席法务官首席法务官/首席法律顾问：首席法律顾问：负责合规性，特别是遵守健康和数据相关法律，对知识产权和数据、与过失建议相关的风险进行潜在法律分析，与生成式人工智能平台协商合同条文，确保将患者数据与人工智能模型的公共实例分离。示例示例1：风险开发生成式人工智能医疗咨询聊天机器人所带来的机遇与风险某医疗服务提供商考虑使用生成式人工智能提供医疗建议，以此代替临床工作人员为患者远程提供健康咨询服务。提供商收集多年的患者数据、症状、诊断和治疗方法，用于训练模型。监管事务首席数据官首席风险官首席法务官/首席法律顾问首席文化官首席信息安全官首席产品官首席技术官高级管理层可采取的措施我们提供了如下两个示例，其中高管及其团队可协作管理风险，同时企业也可以通过有效的治理强化风险管理。11生成式人工智能的风险和机遇管理首席信息安全官：首席信息安全官：将该应用程序和数据存储区确定为“一级核心资产”，并按照数据的最高敏感级别提供充分的保护。内部审计：内部审计：围绕拟实施的系统和模型制定审计风险评估计划，考虑各地区健康记录法规和隐私法的法律和合规风险。例如：健康保险法、个人健康档案法、老年护理法和当地的非健康个人隐私保护法，并对系统和模型的可靠性和性能进行评估。首席风险官：首席风险官：与首席合规官协商制定政策、培训、测试和控制措施，以确认人工智能生成的医疗建议准确且符合国家医疗委员会的标准。一家银行考虑使用生成式人工智能自动化流程对交易对手信用评估中的所有交易对手进行年度信用检查，并根据市场事件和其他触发因素对高风险客户进行季度检查。示例示例2：高效验证信用分析并树立风险意识首席数据官：首席数据官：确保数据准确无误，数据已清洗，并且不存在对某些群体的固有偏见。设置专用沙盒测试用例以支持产品。首席合规官：首席合规官：更新流程图和合规材料，展示如何使用该技术达成决策，并证明其符合隐私法、隐私（信用报告）法则、竞争与消费者法案和反歧视法等相关法律。监管事务：监管事务：更新报告规程。首席产品官：首席产品官：呼吁采用隐私保护融入设计的方法，让最终用户了解他们提供的数据将如何被使用，哪些数据将被保留。首席法务官首席法务官/首席法律顾问：首席法律顾问：与信贷机构和其他数据供应商协商合同条款，允许将其数据用于生成式人工智能，并与生成式人工智能平台协商，保证客户数据不会与其他实例混用或用于训练其他实例。首席财务官首席财务官/财务总监：财务总监：确保内部控制环境以及相关风险和控制框架足以解决人工智能应用带来的潜在影响，提高财务报告流程完整性控制的设计和运行有效性，并符合国际财务报告准则或萨班斯法案404等法律法规要求。首席信息安全官：首席信息安全官：将该应用程序和数据存储区确定为“一级核心资产”，并按照数据的最高敏感级别为其提供保护。12生成式人工智能的风险和机遇管理底线生成式人工智能的合理应用能够为公司节省时间和成本，优化产品和服务质量，甚至提高声誉。但该方法应以人为主导、科技为辅助，切勿颠倒了主次。公司想要从这一突破性技术中获得切实的最大收益，必须从其整体利益出发，管理好应用人工智能技术带来的诸多风险。同时也需要利益相关方集思广益，全面考量引入生成式人工智能解决方案带来的影响和问题。实现风险与创新回报的平衡将有助于树立公司信誉并赢得竞争优势。最终，生成式人工智能的进步取决于公司员工。提升员工技能，使员工了解使用生成式人工智能作为辅助或指导工具的局限性，以便员工充分利用其潜能。在制定企业风险防范措施的基础上，赋能员工运用自身经验，对生成式人工智能模型的输出结果进行批判性评估。每一位有判断力的用户都是信任的守护者。如果企业对生成式人工智能风险有深刻理解，懂得如何设计、衡量和管理可信赖的人工智能系统，将更快地推进人工智能转型，更容易发现高价值的使用场景。13生成式人工智能的风险和机遇管理理解理解普华永道风险及控制服务部门的服务我们的风险及控制服务部汇集了数据科学、工程、数据道德、数字法律、风险和治理领域的专家，可与公司所在行业的专家携手，协助公司以负责任的方式加快生成式人工智能的实施步伐，并能够助力公司在建立人工智能信任的发展道路上迈出关键一步。“理解、建立、加速和保证”是我们助力企业部署人工智能的方法论，该方法论以我们25年的技术和数据治理领导者经验、屡获殊荣的人工智能咨询服务和全球技术联盟生态系统为基础。理解公司应对人工智能机遇和风险的基准线和准备情况。建立安全、快速地采用人工智能所需的基础。加速创意构想、探索和原型设计。推广适用的构思并监测其有效性和安全性。审查公司现有的人工智能框架、平台、模型和实施措施，帮助公司建立并维护在利益相关方群体中的信任。创意构思和策略制定使用场景探索与选择数据成熟度审查风险及控制审查人工智能治理模型负责任的人工智能数据平台实施生成式人工智能概念验证部署控制实施数据可观察性托管服务建立建立保证保证加速加速14生成式人工智能的风险和机遇管理联系我们了解更多信息 2023普华永道。版权所有。普华永道系指中国内地与香港成员机构，有时也指普华永道网络。各成员机构均为各自独立的法律实体。更多详情请浏览

0人已浏览 2023-12-20 16页 5星级

证证券研究券研究报报告告本报告仅供华金证券客户中的专业投资者参考本报告仅供华金证券客户中的专业投资者参考请请仔仔细细阅阅读读在在本本报报告告尾部尾部的的重重要要法法律律声声明明AI浪潮下的浪潮下的网络. 

0人已浏览 2023-12-19 49页 5星级

中国中国AIGCAIGC数据标注产业数据标注产业全景报告全景报告Panoramic ReportPanoramic Report ofof Generative AI Data LabelingGenerative AI Data Labeling IndustryIndustry inin China China 2023.11杨净量位智库 QbitAI Insights序序 数据标注，正迎来关键时刻。作为AI认识世界的起点，数据标注本质上是将现实世界信息结构化、数字化，充分发挥数据信息的价值。模型时代到来，AIGC众多垂直场景落地，以及通智能、具智能等前沿领域探索，与质量、专业化的场景数据密不可分，数据标注从劳动密集型加速朝着知识密集型转型，业壁垒进步提。作为底层基础服务，数据标注贯穿模型全命周期（训练测试、评估验证和应迭代）。，牵涉关键Know-how，更多模型公司/AI企业选择建标注团队和管线；另，上下游合作关系将更为紧密和耦合，专业数据服务提供商更多机会将在垂直领域，帮助企业完成私有化部署。机遇与挑战并存。合成数据作为新衍赛道，潜在市场空间巨。与此同时，数据标注标准难以统、数据处理流程尚未规范，学历多领域多专业成为标注才的硬指标。模型时代下的数据标注!#!$!%录录AIGC数据标注四变化AIGC数据标注三影响因素数据标注产业竞争格局/市场规模数据标注代表玩家案例集!&模型时代下的数据标注!数据标注是AI认识世界的起点n 本：词性标注、分类标注、情绪标注、命名实体识别、语义标注、意图标注等；n 图像：图像分类、语义分割、实例分割、拉框、OCR转写等；n 频：语识别、声纹识别、语转写等；n 视频：标跟踪、为识别等；n 3D点云数据标注是将原始数据进加处理，如分类、拉框、注释、标记等操作转换成机器可识别信息的过程。国内数据标注商，义称之为基础数据服务提供商，通常需要完成数据集结构/流程设计、数据处理、数据质检等作，为下游客提供通数据集、定制化服务、数据闭环具链等。这也是本次AIGC数据标注全景报告的研究对象。根据原始数据类型原始数据类型以及训练任务训练任务划分：般数据处理流程：原始数据数据清洗模型训练测试/验证数据标注数据质检数据标注中的定律定律通常在一个AI项目中，数据准备工作需要80%时长，模型训练和部署仅占20%。模型时代下的数据标注海天瑞声是国内唯家AI数据上市公司，今年2以来股价受ChatGPT热潮曾度狂飙，截1110股价较年初上涨59.75%。上市公司股价狂飙，创业公司融资加速上市公司股价狂飙，创业公司融资加速模型数据解决案多处开花，以站式、定制化服务为主模型数据解决案多处开花，以站式、定制化服务为主围绕模型开发全命周期（包括预训练、监督微调、RLHF、红队测试、基准测试等），专业数据服务商、模型企业、AI公司等各都拿出相关数据解决案，部分以站式、定制化服务为主。云测数据：向垂直业模型数据解决案 星尘数据：星尘COSMO模型数据字塔解决案 澳鹏Appen：AI聊天反馈和基准测试两解决案 引擎：（涵盖数据服务模块）百度：个模型数据标注基地模型范式涌数据标注，动化标注槛幅降低模型范式涌数据标注，动化标注槛幅降低以SAM模型为代表的图像分割模型开源；GPT-4、GPT-4V为代表的模型也被验证在本、图像领域标注具有可性，并衍出专做数据标注的模型，幅降低动化标注槛。国内不少数据服务商进相关模型研发，部分产品已经发布：海天瑞声：数据产垂直模型（研发阶段）曼孚科技：动驾驶数据标注视觉模型（已完成研发）猫数据：动驾驶模型AutopilotGPT（发布）商汤：明眸SenseAnnotation动化数据标注平台（发布）标科技：烘焙师模型Baker-GPT（发布）创业代表公司融资情况星尘数据22年125000万A轮标科技23年4超亿元B2轮整数智能23年6数千万Pre A轮柏川数据23年7千万元天使轮曼孚科技23年9数千万B轮恺望数据23年4战略融资23年9数千万Pre A轮智能驾驶新感知范式，智能驾驶新感知范式，BEV TransformerBEV Transformer是机遇也是挑战是机遇也是挑战作为最具代表性应场景，智能驾驶迎来新感知范式：以BEV Transformer为代表的四维感知替代掉2D CNN为代表的维感知案，给数据服务商带来更多机遇与挑战，包括不限于标注场景难度、数据量产能要求等。前国内部分商给出了数据闭环具链和解决案等。（图源：特斯拉）AIGC重塑数据标注量位智库认为，数据标注正迎来重新洗牌的关键时刻，有四关键趋势：1 1、数据标注要求从客观到主观，很难建统标准、数据标注要求从客观到主观，很难建统标准模型的开发范式决定了模型数据标注对然语要求要求很，包括排序、改写、多轮对话、评估等操作，难以依靠客观的评价体系，如准确率、效率等。本科以上多领域多专业开始成为标注才的硬指标，标注也随着模型全命周期更为细分，如AI训练师、模型精调师、指令程师等。模型Know-how涉及到数据处理流程的设计，模型公司/AI企业开始建数据标注团队和数据处理管线，甚对外输出服务，产业链重新洗牌。量位智库预计，国内AI基础数据服务市场规模将达百亿规模，约占全球市场10%份额。其中合成数据作为衍出来的新赛道，存在巨市场空间，增速超40%。2 2、学历多领域才成刚需，缺或达百万、学历多领域才成刚需，缺或达百万3 3、产业链重构，模型公司、产业链重构，模型公司/AI/AI企业涌企业涌4 4、国内百亿级市场规模，合成数据增速最、国内百亿级市场规模，合成数据增速最AIGC数据标注四变化!#需求变化：与业场景强相关，高质量数据需求长期且持续模型时代的到来，正加速推动智能开发从以模型为中朝着以数据为中的向转变。质量数据服务需求贯穿模型全命周期。前模型技术路径已经完整清晰，训练流程主要分为三个阶段：预训练模型监督微调SFT强化学习RLHF次预训练*实际训练过程中，部分垂直领域大模型需用小规模语料进行二次预训练操作数据处理流程设计涉及模型Know-how，直接决定模型性能好坏。尤其后两个阶段需要专业成数据或对数据进改写或排序，最终形成符合类标准（如专业逻辑、核价值观等）质量数据。后随着模型持续地实时更新迭代、朝着多垂直领域落地，尤其通智能、具智能等相关探索，如何快速扩展到更多真实边缘场景，质量场景数据也将成为刚需。除此之外，实时保障输出内容的安全合规，也远以往更受重视。从训练、迭代到应落地，数据服务贯穿模型全命周期。泛认知，模型是以数据为中的产物。数据数量和质量很程度决定着模型能的上限。n 以模型为中：迭代模型，数据相对固定。n 以数据为中：关注数据本，模型成为了数据的容器。企业端客需要期且持续的数据服务，产业链上下游供应关系远以往更为紧密和耦合。（图源：OpenAI官）（图源：Data-centric AI:Perspectives and Challenges）处理流程侧变化：标准从客观到主观，学历多领域成才硬指标传统数据标注模型数据标注领域划分按不同领域或任务划分按不同阶段划分具体实操拉框、描点、转写等操作排序、改写、成等操作标注要求偏客观偏主观评价指标准确率 效率难以对标准解决案具/平台标注 类质检专业培训、定期开会对等举措才要求专科为主本科以上，多领域专业才标注按职能划分标注员、质检员、管理员按阶段划分AI训练师、模型精调师、指令程师、红队测试军团等。覆盖区域主要集中在三四线城市重新打散例如，百度在海专为模型建设的数据标注基地，本科例100%，培训专业才已达1000。未来五年，数据标注相关专业才缺将达百万量级。数据标注从劳动密集朝着知识密集型转变。业务变化：合成数据成新衍赛道，潜在市场空间巨合成数据的优势&特点1、降本增效降低数据获取成本，成数据带质量标注，缓解“数据荒”问题。2、数据可定制应可扩展性强，灵活度，可覆盖更多边缘、尾场景。3、隐私安全天然规避掉数据隐私安全合规的问题。数据增强动驾驶机器融物医药业模型验证可解释AI具智能AR/VR应场景企业案例群核科技Coohom Cloud（群核云）作为前为数不多提供室内场景数据服务的代表商，能针对不同应场景合成2D、3D数据集，客覆盖全球，服务多家海内外科技巨头公司，并于英特尔在产研等开源性项上进深度合作。所谓合成数据，即是AI成数据真实产，能够替代真实数据来训练、测试和验证模型。前主要在动驾驶、机器、物医药等领域应。英伟达Meta亚逊等全球科技巨头均有相关布局（投资、收购等）。OpenAI CEO Sam Altman曾放：未来所有数据都将变成合成数据。量位智库预计，合成数据将成为未来增速最快赛道，年增率可达45%。（图源：官）供应链变化：重新洗牌，模型公司/AI企业涌硬件硬件/云服务商、资源商云服务商、资源商基础数据服务提供商基础数据服务提供商数据需求数据需求（AI企业、传统企业、政企机构、科研机构等）百度智能云引擎阿云华为云腾讯云综合招聘平台专业数据服务提供商模型公司/AI企业中团队群核科技海天瑞声云测数据星尘数据曼孚科技标科技猫数据倍赛科技整数智能晴数智慧数据堂博登智能37度数据景联科技科乐园百度智能云引擎商汤科技京东阿云毫末智模型公司/AI企业建数据处理管线，对外输出模型数据解决案，传统产业链重新洗牌。部分商还具备云服务能，同数据服务打包输出，更易建起客之间的碑和信任，具备竞争优势。京东云澳鹏中国恺望数据卓印智能未有科技云数据朗势科技柏川数据冰数据AIGC数据标注三影响因素!$三影响因素：以技术 场景聚合的轮效应数据标注作为AI底层服务，最本质是为客降本增效。持续迭代技术能的企业将有机会脱颖出，包括不限于以下点：n 数据闭环具链的智能化平n 对模型/算法Know-how的理解n 数据程化能、数据基础设施建设n 业Know-how*质量场景数据*能够根据客需求，快速找到并利与场景最为贴合的资源。n 数据标注仍具备轮效应；n 新创业公司局槛进步提；n 专业数据服务商更多机会将在垂类场景，帮助企业完成私有化部署；n 对外输出数据服务的模型公司/AI企业也存在竞争优势。业务量增业务量增获客容易获客容易获得碑渠道 AIGC数据处理能越强获客越容易获客越容易标注经验标注经验越丰富越丰富可扩展性灵活性更强获得碑技术 场景看技术能看技术能看场景资源看场景资源三看轮效应三看轮效应场景专业才（领域专家、深度等）传统数据标注轮AIGC赋能数据标注轮产业竞争格局/市场规模!%市场竞争格局数据标注业传统依靠渠道、等形成的低成本竞争优势将被重塑，数据需求将更看重数据质量、场景多样性和可扩展性。基于以上原因，量位智库将从数据基础设施、场景资源两个来分析前的业内玩家分布及现状。数据基础设施质量场景资源大模型相关数据解决方案大模型数据资源/标注团队我国数据标注业企业竞争格局我国数据标注业企业竞争格局代表公司：海天瑞声数据堂澳鹏中国晴数智慧未有科技37度数据景联科技包括中众包团队，模型/应层公司建数据管线等第象限：有技术有场景的明星公司第象限：有技术有场景的明星公司该象限存在两种情况：第种是模型层公司本有模型技术范式以及场景落地经验积累，可快速输出数据解决案，与云服务打包输出建信任；第种则是主要以技术驱动的明星企业，部分拥有数据闭环具链，再结合年来业经验，在模型浪潮下易受到企业睐。第四象限：场景壁垒更为深厚的业玩家第四象限：场景壁垒更为深厚的业玩家该象限着更为深厚的业数据壁垒，可为下游提供质量数据集或拥有模型数据标注团队，以海天瑞声为例，不仅是LIama2的唯中国伙伴，还发布超规模中多轮对话数据集DOTS-NLP-216，合作企业超810家，覆盖全球近200个主要语种及，有近20年业深耕。第象限：有强技术撑的创业新势第象限：有强技术撑的创业新势该象限主要聚焦在近两年创的创业公司，主要以动驾驶场景作为切点，再覆盖到AIGC及其他领域。他们饱受资本市场认可，以恺望数据为例，年半时间就是完成了三轮融资。1324代表公司整数智能恺望数据柏川数据博登智能卓印智能代表公司：百度群核科技星尘数据云测数据猫数据曼孚科技倍赛科技重新洗牌（2023-2025年）标注（2017年前）平台/具标注（2017-2022年）知识密集（2025年后）以训练任务、算法模型为导向；简单图像标注为主。以动驾驶为代表的场景爆发；标注法满数据需求，动化标注兴起；量AI数据初创公司开始涌现。数据质量驱动；产业链重新洗牌，更多企业参与数据标注，供应合作关系紧密；创业槛提。机协同关系进步耦合，更多承担关键决策；市场竞争格局趋于稳定。国内基础数据服务百亿市场规模n【标注】关键节点：2007年，李团队启动ImageNet，借助亚逊众包平台完成图像分类和标注来训练机器学习算法。数据标注从此拉开序幕。n【平台/具标注】关键节点：2017年，以数据驱动的深度学习成为业共识，动驾驶爆发，国内外初创公司涌现，数据标注迎来庞的市场需求。n【重新洗牌】关键节点：2023年，以ChatGPT为代表的模型涌现，更质量、专业化的数据标注成为刚需。n【知识密集】关键节点：垂直模型落地加速，数据处理范式、标准基本确定。未来机器将满部分标注需求，将承担关键决策任务。需求推算：作为AI底层基础服务，始终依托于智能的发展，约占智能市场份额10%左右。前模型垂直领域落地仍处于探索阶段。典型样本：海天瑞声市占率达12.9%，上半年营收去年同期增翻番。国内国内AIAI基础数据服务市场规模基础数据服务市场规模单位：亿元05003003502023E2028E2030E数据标注代表玩家案例集!&百度智能云百度智能云数据众包，依托百度10余年AI数据经验、产品技术能和国内产值规模领先的单体数据标注基地，具备数据“采、标、存、管、训”体化的服务能，根据特定领域、特定场景的客需求与委托，可提供数据采集、标注、加等处理服务，为客交付标准化、结构化的服务成果。当前，百度智能云升级模型数据服务能，在海市建设全国个专业模型数据标注基地，专业模型数据标注师达数百，员本科率达100%。模型能评估体系评估流程与具Copilot辅助评估员定向募集与准盲评、拟合多轮审验洞察与优化可视报表与案例分析优化提案与服务持应能问答创作对话代码基础语处理通能指令约束满上下记忆跨语处理学习能SFTIn-Context-Learning专业公正效模型评估服务：全评价应表现，洞察短板，牵引优化类反馈标注服务交付：代表类偏好的打分排序数据模型数据标注产线模型数据产Copilot赋能数据接资源调度数据分发数据标注数据交付质量审核规则增强学习动分类智能标注动质检 模型标注服务：员、具、质控、研发多管下，保证质效指令数据标注服务交付：输提和输出的质量监督数据运营能专业化数据咨询 安全标注案标注资源各领域众包专家 专职基地群核科技Coohom Cloud（群核云）是群核科技（酷家乐）推出的，向室内智能体认知和图形智能的AI训练合成数据平台。基于真实三维场景数据资源以及AIGC技术的驱动，提供丰富的2D/3D数据集，针对智能机器、智能、元宇宙、智能房产、动驾驶等领域，为AI模型以及仿真器研究提供丰富的训练资源，让智能体更智能。应产品室外机导航机器机器厨房机械臂清洁机器态兼容仿软件：Isaac Sim、UE、Gazebo、Unity 等数据格式：USD/UE/SDF/OBJ/HM3D/PCD/COCO/VOC/NYU40标签/定义超性价成本降低10倍场景确定后，数据集规模越，单图成本越低效率提升10倍GPU集群并发渲染，可合成20w组数据/体验提升10倍可视化交互具，实现所即所得质量提升10倍像素级精准标注合作成功案例与伙伴论n InteriorNet BMVC 2018n Structured3D ECCV 2020n MINERVAS CGF 2022校&企业nnn 英特尔 科沃斯 追觅 美的 等业智能机器智能元宇宙智能房产动驾驶技术应数字孪视觉感知三维重建内容成决策与控制SLAM解决案提供以虚拟仿真合成数据集为中的站式服务成本数字化优劣对真实数据仿真数据为主成本采集耗时久/标注错误多成本昂/侵犯隐私：次性数据集 项制算为主成本低算为主成本低复杂场景标注成本低/持难度采集完美实验/格式统/多样性丰富有：复性数据集有：复性数据集 基于任务基于任务的灵活修改的灵活修改数据集作为AI训练的核要素，其规模和质量与算法效果，效率密切相关3DMAXMAYASketchUpREVITUNREALUnityBlenderOmniverse海量素材库3333亿亿渲染图 均成4040万万套设计案2 2.7 7亿亿个3D家居商空商品模型，字典级标签体系3D数据格式转换数据增强引擎场景创作与增强虚拟仿真世界KoolAI渲染引擎AI引擎交互引擎规则引擎（质检）分布式云计算服务器集群CAD空间设计家装设计具商空设计具全景设计具智能设计格快搭具CAE仿真模拟照明仿真声学仿真WiFi仿真流体学仿真机器物理仿真基础设施星尘星尘COSMOCOSMO模型数据字塔解决案模型数据字塔解决案核产品：核产品：RosettaRosetta平台平台3.03.0星尘数据模型业应业模型平台具服务基础数据服务模型评测服务医疗问诊写作助智能客服法律助融助辅助编程辅助设计医疗模型传媒模型法律模型融模型教育模型数据标注平台数据管理系统知识库问答管理系统模型管理系统数据采集数据存储数据清洗数据清洗数据增强数据审核数据安全数据分析数据管理动化评测评测评测报告评测榜单3 3层：企业私有化部署数据层：企业私有化部署数据2 2层：专有能数据层：专有能数据1 1层：通能数据层：通能数据0 0层：公共数据层：公共数据四层数据结构，加速语模型构建可持万以上同时在线标注，数据年处理量过亿，可提供先进的AI算法辅助标注具和项管理具，可持图像、点云、本、语、多模态等各类型100 种主流采集和标注场景，前平台动化平达到60%以上，数据质量达到99.9%。星尘数据成于2017年5，2023年1宣布完成5000万A轮融资。通过动化标注技术、数据策略专家服务和数据闭环系统，服务动驾驶（50 头部客）、模型、智能家居、智慧城市、智能机器、智慧医疗、智慧教育、智能零售、智能遥感、智慧融等众多数据场景。持续预训练持续预训练下游任务微调下游任务微调灰度发布联调灰度发布联调垂直业知识机协作优化基准评测定向垂直场景的数据服务能场景化数据采集能持续订阅服务能基于数据要求清洗分类能基于下游任务微调的机耦合标注能多轮对话图排序4D叠帧OCR预识别视频转写Prompt编写章判断基于定向垂直领域员测试特定领域专家池场景化服务能系统集成持特定数据回流处理适于新代AI程化数据处理平台向垂直业模型向垂直业模型AIAI数据解决案数据解决案云测数据云测数据是Testin云测旗下AI训练数据服务品牌，以质量、场景化的AI训练数据服务为基础，持续为智能驾驶、智慧城市、智能家居、智慧融等众多领域提供通数据集、数据标注平台&数据管理具、数据采集/数据标注等服务。适于新代AI程化数据处理作台数据回流数据推送数据池数据推送功能模块数据标签数据可视化版本管理数据统计数据清洗数据标注数据质检数据推送任务创建*通过标准API接口与其他业务集成处理数据应待处理数据猫数据猫数据成于2014年，专业提供动驾驶、计算机视觉、智能语、然语理解数据采集标注服务，具备数据标注、数据采集、内容审核等能。针对AIGC类业务，猫数据2016年推出标注平台1.0版本，前已执1000 项，标注2000 。点云例：AutopilotGPT是基于Transformer的百亿参数模型，可识别图、点云类型。持多传感器数据类型，可进标检测、标追踪、标分割、驶区域识别。只需上传图（通格式均可）、点云pcd格式，就可动识别结果。AIGC数据标注流程质量保障：引模型，交叉验证对评测结果。评测数据标注员A输出结果标注员B输出结果模型输出结果结果是否致输出结果是否真实数据仿真数据动标注模型DAM模块标注结果数据集识别能对数据集A数据集B数据集CDAMDAMDAMwithoutDAMwithoutDAMwithoutDAM动驾驶模型动驾驶模型AutopilotGPTAutopilotGPTAutopilotGPT意图恺望数据恺望数据成于2022年2，团队成员来字节跳动、阿巴巴、Uber、Momenta、奔驰等头部企业。公司致于打造AI数据动化平台，并为企、动驾驶公司以及智能等跨产业企业提供站式AI数据解决案，前客数已超百余家。提供合规数据、质量数据、效率的稳定规模数据。n“3D辅助标注”具平台：可在2D中标记后反投影到3D中找到标注物。n“4D-BEV数据拼接与标注”具链：可持数据流并作业、可同时持200万同时标注，前已在企应。n“5KW点云”具平台：可在8G内存电脑上运的5千万点云数据。n“6数据态闭环解决案”：供应商态、业态、知识库态、具态、前沿技术态、专家科研态。通过校合作储备及培训有批校学标注员，通过共建产融实训基地的形式为业迅速提供量稳定且优质的数据标注服务，同时运AI具辅助管理、基地化管理、专业化级才培养等式，获得最优和最优效的平衡，降本增效表现领先业。前恺望数据学院已培训50所学校，培养超过1500名学为恺望提供数据标注服务，计划今年年底将超过2000规模。n2022年9，千万级天使轮战略融资，投资包括韬资本、三集团和溪天使汇，于加速建设数据快充站以及团队完善，持续为汽产业的智能化，提供数字化、站式的数据解决案。n2023年4，新轮战略融资，投资为Plug and Play、韬资本，探索出海路径，并继续投到产品迭代升级当中。n2023年9，数千万元Pre-A轮融资，由亚盛投资领投，清智资本跟投。本轮融资资将于动化产线和具链的持续研发和迭代。核能创新技术与平台模式动化AI数据产线效率运营融资历程恺望数据学院“3456”数据服务具包我国值得关注的数据标注业代表机构TOP20基于数据基础设施建设、模型/AI技术理解以及业深耕和其他因素，量位智库评选我国值得关注的20家数据标注机构。百度智能云海天瑞声云测数据星尘数据猫数据群核科技恺望数据曼孚科技晴数智慧倍赛科技引擎整数智能商汤科技博登智能标科技37度数据数据堂未有科技景联科技澳鹏中国*排名不分先后微信号：Qbitbot020量位智库助关于量位智库：关于量位智库：量位旗下科技创新产业链接平台。致于提供前沿科技和技术创新领域产学研体系化研究。向前沿AI&计算机，物计算，量技术及健康医疗等领域最新技术创新进展，提供系统化报告和认知。通过媒体、社群和线下活动，基于专题技术报道及报告、专项交流会等形式，帮助决策者更早掌握创新向。关于量位：关于量位：量位（QbitAI），专注智能领域及前沿科技领域的产业服务平台。全订阅超过500万，在今头条、知乎、百家号及各科技信息平台量位排名均为科技领域TOP10，内容每天可覆盖数百万智能、科技领域从业者。

0人已浏览 2023-12-18 26页 5星级

 2023 年深度行业分析研究报告 目目 录录 一、一、AI 有望明显拉动算力基础设施投资有望明显拉动算力基础设施投资.1 1.1ChatGPT 爆红引发了人们对于人工智能发展的高度关注.1 1.2 人. 

0人已浏览 2023-12-18 92页 5星级

2 0 2 3 年深度行业分析研究报告目录301 华为算力编年史02 AI硬件自主可控势在必行03 投资建议:梳理算力相关受益厂商04 风险提示01华为算力编年史41.1 国产芯片之光华为海思5资料来.

0人已浏览 2023-12-18 62页 5星级

中国信息通信研究院知识产权与创新发展中心 2023年12月(20232023 年年)人工智能知识产权法律问题人工智能知识产权法律问题研究报告研究报告 版权声明版权声明本报告本报告版权属于版权属于中国信息通信研究院中国信息通信研究院，并受法律保护，并受法律保护。转载、摘编或利用转载、摘编或利用其他其他方式使用方式使用本报告的文字或观点，应本报告的文字或观点，应注注明明“来源：来源：中国信息通信研究院”中国信息通信研究院”。违反上述声明者，本。违反上述声明者，本院院将追究其相关法律责任。将追究其相关法律责任。前前 言言 随着新一轮科技革命和产业变革的深入发展，人工智能技术正迅速推动人类社会智力创新、经济高质量发展，以及生产生活方式效率的提升。人工智能为全球产业发展提供新动能的同时，也带来了诸多新的问题和挑战。当前人工智能知识产权治理正处于法律研究和规则制定阶段，迫切需要解决全球范围内多方面的问题。一是产业对大模型数据使用量级的快速提升突出了著作权作品合理使用原则问题，尤其在原创作者和大模型企业的著作权使用上存在明显争议。二是人工智能技术生成的作品呈现成倍释放的趋势，给当前著作权归属和适用制度带来冲击，考验着知识产权治理的能力。各方都在积极寻求解决人工智能领域知识产权问题的路径。美国政府加速法律问题研究，产业主体主动承担训练数据和作品的侵权责任；日本通过明晰人工智能数据训练中的合理使用标准，平衡企业和原创作者间的关系；欧盟以促进产业发展的数据挖掘原则为抓手，推进著作权治理向精细化方向发展；中国通过立法和司法协同，探索人工智能知识产权最佳保护模式。各方对于人工智能技术有较大的知识产权风险已经达成共识，知识产权制度必须适应新的现实和新的法律挑战，形成符合产业和各方行为预期的知识产权治理理念和规范。基于新的人工智能发展阶段的知识产权治理理念，需要坚持产业发展优先的原则，秉持共商共建理念，推动输入端和输出端关键规则构建，探索治理主体创新。目目 录录 一、人工智能产业发展概况和知识产权环境.1（一）人工智能产业发展概况.1（二）人工智能产业知识产权环境.3 二、现阶段全球人工智能领域主要知识产权问题.4（一）输入端数据训练的合理使用问题.5（二）输出端内容著作权保护范围问题.8 三、人工智能领域各方知识产权治理相关实践.11（一）美国：政府加速法律研究，产业主体承担责任.11（二）日本：明晰合理使用原则，避免侵犯原著作权.14（三）欧盟：保护企业数据挖掘，推进治理精细水平.15（四）中国：明确尊重知识产权，立法司法协同探索.17（五）小结：各方积极应对挑战，治理路径逐渐清晰.19 四、人工智能知识产权治理展望.21（一）完善治理理念.22（二）健全治理规则.23（三）统筹治理主体.24 表表 目目 录录 表 1 输入端合理使用争议.5 表 2 输出端著作权保护争议.9 表 3 各方应对人工智能著作权问题的保护路径.21 人工智能知识产权法律问题研究报告（2023 年）1 一、人工智能产业发展概况和知识产权环境（一一）人工智能产业发展概况人工智能产业发展概况 人工智能（Artificial Intelligence，简称 AI）被视为引领未来产业发展的战略性新兴技术，正在推动着一场全新的科技变革和产业创新。随着机器学习（machine learning）、计算机视觉（computer vision）、自然语言处理（natural language processing）等领域的快速进展和技术不断完善，人工智能对社会的智力创新和进步、经济的提质增效，以及生产和生活效率的提升都产生了深刻的影响。从发展阶段来看，深度学习技术的快速突破正在驱动人工智能以前所未有的速度逼近通用智能。自 2014 年起，随着以生成式对抗网络（Generative Adversarial Network，简称 GAN）为代表的深度学习算法的提出和迭代更新，人工智能处理单一任务水平大幅提升，专用式人工智能技术逐渐成熟。而 2022 年底美国开放人工智能研究中心（OpenAI）发布的 ChatGPT 则代表了通用式人工智能的技术进化，聚焦于人机交互的封闭环境，人工智能已经能够同时实现多项复杂的任务能力。深度学习在未来仍将持续“大模型 大算力 大数据”的主导路线，逐渐逼近人机交互环境下的有限度通用智能，这也对算力、研发等工程化能力提出更高要求。同时，海量专用小模型正在更深入与行业核心业务能力相结合。在“大模型主导，行业小模型应用落地”两类路线叠加驱动下，人工智能将持续规模化应用，并不断逼近与人、环境交互协同的通用智能。从产业布局看，领军企业持续迭代基础通用大模型，主导力量正人工智能知识产权法律问题研究报告（2023 年）2 在逐步形成。一是，领军企业持续迭代基础通用大模型，完善各类模型能力布局，探索产业服务模式。以 OpenAI 的 GPT-4，谷歌（Google）的 bard，百度文心一言大模型，科大讯飞星火大模型等为代表，大语言模型正在逐步将其能力范围扩大至金融、医疗、能源等领域，探索大模型落地的专业化场景。二是，开源模型技术体系打破闭源模型垄断壁垒。以元宇宙公司（Meta）Llama2 模型，稳定人工智能公司（Stability AI）的稳定扩散模型（stable diffusion），斯坦福大学羊驼（Alpaca）模型等为代表，开源模型已成为部分企业及高校研究机构的发力点，逐步赋能更多开发者和学习者，加速产业整体发展和进步。三是，贴合业务场景的专业大模型纷纷入局。例如上海人工智能实验室开发的全球首个城市级实景三维大模型书生天际，网易游戏伏羲大模型等，创新主体及行业企业紧跟大模型热潮，与自身业务场景结合，提升对外服务能力。从商业化落地来看，人工智能行业主流产品形态是生成式人工智能（AI Generated Content，简称 AIGC）。目前，大模型在日常办公、文本创作、图像视频生成、游戏等领域拥有较大发展潜力，商业化前景相对清晰。在文本生成端，AIGC 已经可以利用自然语言生成技术自动生成文章、小说、新闻摘要、诗歌等文本内容；在图片生成端，图片风格转换、图像修复和补充、生成艺术作品等产品正逐渐落地；在音视频生成端，合成音乐、生成环境音效、视频合成和特效生成等，AIGC 可以提升制作效率。未来，AIGC 能够针对科学发现类的任务，逐步渗透生产力变革。大模型有望作为基础赋能工具，发现更多领域人工智能知识产权法律问题研究报告（2023 年）3 通解，在更多领域实现价值创造和产业升级，如解决数学问题，发现新材料配方，配合药物研发预测药物理化性质等。（二）人工智能产业知识产权环境二）人工智能产业知识产权环境 知识产权问题是企业对于使用生成式人工智能的首要担忧。在德国人工智能内容治理公司 Acrolinx 于 2023 年 8 月对 86 家财富 500 强公司的调查中1，近三分之一的受访者表示，知识产权是使用生成式AI 的最大担忧。而由代码管理公司 Gitlab 对超过 1000 名从业者开展的调查发现2，95%的高级技术主管认为知识产权和隐私保护是使用AIGC 的首要考虑对象，也有 79%的受访者担心人工智能工具会获取知识产权或私人数据。究其根本，还是现有的人工智能技术在著作权、专利权、商标权、反不正当竞争等方面都面临法律挑战。在著作权方面，人工智能应用程序生成文学和艺术作品的能力日益增强，可利用大模型模拟人类思维活动、从事智力成果的生成与传播活动，这对著作权制度一直与人类的创造精神以及对人类创造力表达的尊重、奖励和鼓励立场产生挑战。如算法和模型的训练阶段，人工智能训练数据可能存在输入端的侵权责任问题；而在内容生成阶段，输出端的生成物是否属于著作权法保护范围也备受争议。在专利权方面，一是人工智能应用或算法是否应被视为可专利的计算机程序或软件，以及其可专利客体的审查规则究竟如何细化一直备受关注；二是人工智能本身是否具备法律主体 1 见 https:/ 2 见 https:/ 人工智能知识产权法律问题研究报告（2023 年）4 或专利权人资格。在商标权方面，随着越来越多地使用人工智能进行营销，以及消费者受算法推荐影响，需要重新考虑人工智能推荐算法是否会淡化品牌的商标价值。在反不正当竞争方面，人工智能生成内容模糊了原创性辨识，难以判定内容的真实性，使得自动化生成的内容可以通过虚假宣传或误导消费者，可能会涉嫌不正当竞争行为。从产业关心热点来看，核心问题聚焦在著作权上。一方面，需要著作权法界定输入端的合理使用范围和侵权责任承担。在人工智能数据的输入端，大语言模型需要使用大量语料数据。而开发者和企业在未经允许的情况下，通过算法设计和程序运行的自动化，利用他人著作权作品片段组合成创作物表达，“洗稿”“拼凑”其他作品，可能会构成对他人作品的侵权。此时，需要利用著作权法上的合理使用原则来对相关侵权行为进行合法豁免，也需要著作权法主动厘清现有大模型训练中的侵权责任认定规则。另一方面，需要著作权法明确输出端人工智能创作物的保护范围。人工智能的创作活动可能涉及人类作者和人工智能系统之间的合作或分工。尽管人工智能系统可以协助创作者，但通常需要人类创作者来设置参数、提供指导、进行编辑和选择最终的创意成果。著作权可以保护知识和智力劳动的成果，确保创作者得到应有的认可和回报，因而是明确作品权利归属和保护的合理选择。对于产业链上下游的不同参与主体，著作权法参与了重要的利益分配环节。二、现阶段全球人工智能领域主要知识产权问题 本报告分析主要以著作权问题为主。伴随着人工智能产业的快速人工智能知识产权法律问题研究报告（2023 年）5 发展，产业界各方在知识产权领域展开博弈，有关人工智能生成物的知识产权争议也在快速出现。本报告对国外人工智能知识产权争议和案例进行梳理，内容如下：（一）输入端数据训练的合理使用问题（一）输入端数据训练的合理使用问题 输入端合理使用的争议主体主要为著作权作者和大模型公司。一方为担心其作品被人工智能用于数据训练和学习的原创作者，以美国作家协会、George R.R.Martin、Paul Tremblay、Mona Awad、纽约时报、盖蒂图片等为代表。另一方被诉主体为大模型企业，如 OpenAI、微软、谷歌等。为了提供更好的使用体验，生成式人工智能在生成文字作品时，必须进行大量高质量的语料训练。语料库一般会包括多领域的文本素材，如新闻、学术论文、小说、科技文章、医学文献等，以确保模型具备广泛的知识。企业一般会在使用数据之前进行数据清洗，删除或替换可能涉及著作权的内容，但仍有可能使用特定的受著作权保护内容进行训练。此外，大模型的多模态能力使涉案作品呈现出多样化的特点，如 George R.R.Martin 等诉 OpenAI 案涉及文字作品，Sarah Andersen 等诉中道公司（Midjourney）和盖蒂图片（Getty Images）诉Stability AI公司涉及图片作品，Matthew Butterick诉GitHub案中涉及程序代码等。目前各方对大模型训练中合理使用的标准不尽相同，也因此引发各方主体困扰和争议。表 1 输入端合理使用争议 原告原告/争议争议发起方发起方 被告被告/争议针争议针对方对方 案情案情 程序员兼律师Matthew GitHub,微软,OpenAI Butterick 认为，GitHub Copilot 大模型在生成代码时使用了 GitHub 上开源代码的代码片段，但未经原创作者的许可，构成侵犯著作权。GitHub、微软人工智能知识产权法律问题研究报告（2023 年）6 3 见 https:/ 见 https:/ 见 https:/ 6 见 https:/ Saveri 律师事务所 和 OpenAI 对此表示否认，称 Copilot 在使用 GitHub上的开源代码进行训练时，只会使用公共领域的代码，不会使用任何受著作权保护的代码。案件仍在审理中。此外，Butterick 在其个人网站上称，2022年 11 月，他们起诉了 GitHub；2023 年 1 月，他们起诉了 Stability AI；2023 年 6 月，他们代表 Paul Tremblay 和 Mona Awad 起诉了 OpenAI3。三名插画师，Sarah Andersen,Kelly McKernan,Karla Ortiz 中道公司(Midjourney),DeviantArt,Stability AI 2023 年 1 月，三名插画师 Sarah Andersen,Kelly McKernan,Karla Ortiz 在美国加利福尼亚州北区地方法院起诉了 Midjourney,DeviantArt 和 Stability AI。原告认为，被告使用的训练素材中包含了他们的作品，但这些公司在使用这些素材时并未获得他们的许可，构成侵犯著作权。被告Midjourney、DeviantArt 和 Stability AI 对此表示否认，称他们在使用这些素材时采取了合理的措施来避免侵权。他们表示，他们只会使用公共领域的素材，或者从创作者处获得许可的素材。2023 年 10 月，美国加州北区地方法院法官驳回了其中两位的索赔，只保留了 Andersen 对 Stability AI 的著作权索赔，并驳回了其他权利要求4。盖蒂图片（Getty images）Stability AI 2023 年 2 月，盖蒂图片声称，Stability AI 通过自己的软件系统，未经许可自动爬取盖蒂图片多达 1200万张图像。盖蒂图片认为这些行为构成了著作权侵权，因为它们未经许可就复制和运用了盖蒂图片的图像，此外，盖蒂图片认为 Stability AI 的绘画作品中常常包含盖蒂图片的商标水印，而且作品常常是“低质量，没有吸引力或具有侵犯性的”，其行为淡化了盖蒂图片的商标，损害了其商标价值5。“人类艺术运动”（Human Artistry Campaign）人工智能公司 2023 年 3 月 16 日，美国唱片业协会（RIAA）联合美国独立音乐协会、美国音乐家联合会、美国出版商协会、国际唱片业协会、录音学院等 30 余个社会团体组建了一个音乐人和艺术家联盟，共同发起了“人类艺术运动”，以保证人工智能不会取代或“侵蚀”人类文化和艺术。该组织的目标是“确保人工智能技术以支持人类文化和艺术的方式开发和使用，而不是取代或侵蚀它的方式”，该组织概述了倡导人工智能最佳实践的原则，“强调尊重艺术家、他们的作品和他们的角色；透明度；以及遵守现行法律，包括著作权和知识产权”6。人工智能知识产权法律问题研究报告（2023 年）7 资料整理：中国信息通信研究院 从争议发生的原因来看，一是，权利人海量但授权机制不明晰。首先，人工智能模型训练需要多个来源的数据，如源自互联网、公共数据库、个人创作等。由于人工智能模型训练的范围越来越广，涉及的权利人也越来越多。在文本生成模型的训练中和在图像生成模型的训练中，海量的作品都存在许可成本问题。其次，不同作品的授权机制和价格各不相同。不同的文字、图片、音乐作品中可能包含复杂的独家授权、非独家授权、转授权等类型，授权费用会根据作品的知名度、使用范围、销量、质量等多种指标综合衡量和确定。因此不同的 7 见 https:/www.npr.org/2023/08/16/1194202562/new-york-times-considers-legal-action-against-openai-as-copyright-tensions-swirl 8 见 https:/ 9 见 https:/ Paul Tremblay,Mona Awad OpenAI 2023 年 6 月，畅销书作者 Paul Tremblay 和 Mona Awad 起诉 OpenAI，声称，他们的小说被用来训练人工智能工具。根据向旧金山联邦法院提交的起诉书，OpenAI“依赖于从公共互联网上收集大量文本材料，包括原告的书籍”。Awad 和 Tremblay 还声称，当出现提示时，ChatGPT 会生成他们各自书籍的摘要，这只有在 ChatGPT 对原告的著作权作品进行训练时才有可能。美国作家协会及8000 多名作家 微软、Meta和谷歌等公司 2023 年 6 月，美国作家协会及 8000 多名作家签署了一封公开信，要求公司不要在未经许可或未支付报酬的情况下使用这些作家的作品训练人工智能系统。作家们认为，AIGC 技术的开发和应用可能会侵犯他们的著作权和利益。他们要求人工智能公司在使用他们的作品时获得许可并支付报酬。纽约时报 OpenAI OpenAI 使用 纽约时报 的新闻文章来训练其语言模型，但未与该报进行任何授权或合作，引发了该报的不满7。该报的律师正在考虑是否起诉 OpenAI，以保护与其报道相关的知识产权。此外，纽约时报已经屏蔽了 OpenAI 在网上爬取数据的工具8。George R.R.Martin 等作家 OpenAI 2023 年 9 月，George R.R.Martin 等作家诉称，OpenAI“未经许可批量复制原告的作品”，并将受著作权保护的材料输入大语言模型，输出结果掠夺了相关作者的市场，使作者失去许可机会9。人工智能知识产权法律问题研究报告（2023 年）8 作品会有不同的授权机制。最后，授权机制不明晰导致侵权责任难以确认。由于权利人众多，且授权机制不明晰，因此在人工智能模型训练中获得所有权利人的授权往往是一件困难的事情。即使能够获得部分权利人的授权，也可能存在授权范围不明确、授权期限不明确等问题，从而加剧了模型训练存在的侵权风险。二是，各方对人工智能输入端构成合理使用的法律依据不同。欧盟限定了“文本与数据挖掘机制”。在 2019 年 3 月 26 日最终通过的单一数字市场著作权指令中，欧盟对于合理使用采用了作者默示许可以及选择性退出默示许可的机制，以适应人工智能的数据挖掘需求并实现对于创新的激励。日本选择了“非欣赏性利用模式”。2018年的日本著作权法修订，对合理使用增加了新的豁免条款，“不以欣赏作品原有价值为目的的利用”，即对创作的作品内容本身进行使用，而不是出于欣赏、娱乐、教育或艺术等原有价值的目的。根据人工智能机器学习的目的，其符合“用于信息内容本身的分析，而非欣赏原有文化价值”的定义，因此被包含在合理使用范围内。美国对合理使用的认定标准最为灵活。美国著作权法对合理使用的方式归为四要件，包括使用目的和性质，著作权作品的性质，使用部分占被利用作品的比例，以及作品对潜在市场价值的影响。美国对合理使用抽象的规定模式使得法院在个案中有较大的灵活裁量空间，由此为创业公司和科技公司开拓了较大的发展空间。（二）输出端内容著作权保护范围问题（二）输出端内容著作权保护范围问题 输出端内容著作权保护的争议主体为人工智能用户和著作权登人工智能知识产权法律问题研究报告（2023 年）9 记机构。根据美国著作权法，著作权的登记是对著作权权属、效力及所述事实的初步证据，也是著作权侵权诉讼和主张法定赔偿的前提条件，因此图片登记是相关人获得著作权保护的合理选择。而对于被登记的作品，著作权保护的核心诉求是证明作品的独创性，以及区分保护的主体。一方面，由人工智能生成的作品创造性思维的表达并不明晰，现有著作权法无法解释人工智能是否能够独立创作作品。另一方面，对于人工智能应以何种地位出现在著作权作品中，是否可以作为“作者”存在争议。表 2 输出端著作权保护争议 资料整理：中国信息通信研究院 从争议发生的原因来看，一是，坚持独创性标准是人工智能创作物获得著作权保护的理论障碍。问题集中在对独创性中“创造性思维”原告原告/争议争议发起方发起方 被告被告/争议争议针对方针对方 案情案情 Stephen Thaler 美国著作权局 法院裁定生成式人工智能创造的作品不能登记著作权。2022 年 6 月，原告 Stephen Thaler 使用文生图式人工智能“创造力机器”（Creativity Machine）产出了一张名为天堂入口（A Recent Entrance to Paradise）的图像。他以“创造力机器”为作者向美国著作权局递交了著作权登记申请，并解释称该作品由计算机算法自动生成。著作权局以缺乏人类作者身份、人类并未参与创作该作品等理由驳回申请。在陈述申辩、复议未果后，Stephen 向美国哥伦比亚特区联邦巡回法院提起了诉讼。2023 年 8 月，法院判决生成式人工智能创造的作品不能登记著作权。法院认为，人类作者身份是著作权的基本要求，完全由人工系统生成的、没有人类参与的作品不符合著作权保护的条件。插画家Kristina Kashtanova 美国著作权局 图书作者 Kristina Kashtanova 此前将其创作的漫画书Zarya of the Dawn向美国著作权局提起注册，书中使用了部分由 Midjourney 创作的插图。美国著作权局此前曾接受了这一注册。2023 年 2 月，美国著作权局表示将撤回对 Midjourney 部分的著作权保护，认为由Midjourney 技术生成的图片不属于人类著作成果。人工智能知识产权法律问题研究报告（2023 年）10 和“贡献参与”的要求。一方面，对人工智能的“创造性思维”标准是否应该设置较为苛刻的门槛存在争议。著作权法对作品的独创性要求并不需要极高的创新程度，只需一定程度地与现有作品不同即可。因此，要求人工智能生成的作品具有像爱因斯坦相对论那样的开创性，或者像学位论文一样经过严格的重复率检测显得过于苛刻。另一方面，人工智能生成的作品需要考察创作过程中人类对于最终表达的直接贡献度。在创作意图方面，人工智能并不具备传统意义上人类主动的“创作意图”，被动需要人类的启发和参与，尚不具备完全的独立自主性。因此，人类在人工智能生成中的表达参与，即直接贡献，对于最终生成作品的形态和呈现至关重要。二是，坚持人类主体地位是人工智能创作物获得著作权保护的制度障碍。一方面，在案例中，以美国为代表，坚持著作权法中对人类创作主体的地位。在 Burrow-Giles Lithographic Co.v.Sarony 案中，美国最高法院的意见就体现出，人类创造力始终是著作权保护的必要条件。即使透过新工具或在新媒介上展现创造力，亦无不同。因此，一般将人类认定为著作权归属者。另一方面，目前的法律条文还没有体现出对人工智能创作者主体资格的支持。美国著作权法 102 条认定，“人类作者身份是美国著作权保护的先决条件”。中国著作权法体现出的主体则是“公民、法人或者非法人组织”。在当前的技术水平下，人工智能还不能完全拥有与人类相同的智力和思想，人类智力是通用型的，而人工智能还远未达到通用型人工智能的水平，人们在实际生活中也并不接受人工智能拥有与自然人同样的人格和地位。人工智能知识产权法律问题研究报告（2023 年）11 从现有规定来看，大模型训练全流程不可避免地涉及到知识产权侵权，适应人工智能产业未来发展的知识产权制度如何构建，成为数字经济时代需要回答的重要问题之一。三、人工智能领域各方知识产权治理相关实践（一）美国：政府加速法律研究，产业主体承担责任（一）美国：政府加速法律研究，产业主体承担责任 为了更好地应对人工智能技术带来的挑战，美国政府采取了一系列措施，包括推进人工智能法律立法节奏、增加听证会和意见征询等手段。美国企业为了解决目前业界对于人工智能知识产权的担忧，承诺为商业客户使用人工智能生成内容的著作权侵权承担诉讼和赔偿费用，进一步保障了使用者的权益。在政策制定方面，美国政府加速制度明晰节奏。第一，美总统颁布行政令要求制定人工智能著作权政策10。行政令责成美国商务部11制定内容认证和水印技术指南，以方便标记原创内容，并检测人工智能生成的合成内容。该认证的目标是将人工智能生成的内容与其他人类原创内容区分开来，并可方便验证内容的真实性，用于鉴定数字内容的著作权。同时，行政令指示美国专利商标局和美国著作权局就可能采取的与人工智能著作权有关的政策向总统提出建议，包括对人工智能生成作品的保护范围，以及在大模型训练中如何处理受著作权保护的作品。最后行政令进一步指示国土安全部制定培训、分析和评估计划，以解决与人工智能商业秘密窃取和知识产权侵权风险。10 见 https:/ 11 美国商务部下辖美国专利商标局，负责知识产权有关政策的制定。人工智能知识产权法律问题研究报告（2023 年）12 第二，美国国会举办多场听证会听取人工智能知识产权立法建议。美国参议院司法委员会举办三次人工智能知识产权听证会。一是鼓励保护人工智能生成内容的著作权。专家普遍认为，人工智能生成的内容具有一定的独创性，应受到著作权法的保护。同时，人工智能生成的内容通常是基于大量数据进行训练的，其中可能包含受著作权保护的作品，在确定人工智能生成内容的著作权归属和侵权行为时，需要综合考虑各方面因素。二是明确合理使用原则应适用于人工智能生成领域，肯定了著作权的既定合理使用原则是平衡人工智能领域竞争利益的最佳方式，虽然某些团体要求为使用内容训练人工智能模型付费，但大家都认为人工智能开发者不可能与每个拥有训练人工智能模型的数据著作权利益的权利人进行谈判并获得许可。最后，听证会建议国会加强人工智能领域知识产权立法，建议明确人工智能生成内容的著作权归属规则，帮助创作者有效维权；加强对人工智能生成内容的著作权侵权的执法力度，以保护消费者；制定人工智能监管框架，防止人工智能技术被用于非法目的侵犯隐私权。第三，美国专利商标局加强意见征询，但主流观点认为现有法律已经足够适应当前情况。2019 年 10 月，美国专利商标局12在征询了律师协会、行业协会、学术界和国内外电子、软件、媒体和制药行业后，发表了 人工智能和知识产权政策的公众意见 报告。报告指出，主流观点认为人工智能是工具而非作者，不具备独立的创作意识。根据传统著作权法的有偿工作原则，只有自然人可以成为作者。二是人 12 美国专利商标局隶属于美国商务部，有权就知识产权（IP）政策、保护和执法向美国总统、商务部长和美国政府机构提供建议，其中也包括著作权政策的建议。人工智能知识产权法律问题研究报告（2023 年）13 工智能的独创性争议较大。一些人认为，如果人工智能生成的作品具有充分独创，并且没有人类干预，就应该获得著作权保护，关键问题是确定人工智能系统的所有者或控制人是否应该获得著作权。三是输入端数据训练合理使用原则不够明确。一些评论者认为这可能侵犯著作权，而另一些人认为应该考虑合理使用原则，并提出为著作权人提供补偿。在产业界探索方面，已有企业愿意主动承担知识产权风险。微软承诺为商业客户使用人工智能生成内容的著作权侵权承担诉讼和赔偿费用。2023 年 9 月 7 日，微软宣布为商业客户做出新的副驾驶（Copilot）大模型著作权承诺13。该承诺规定，只要商业用户在使用微软 Copilot 生成内容时，开启了 Copilot 内置的著作权审查和防护机制，在发现侵权行为时，微软将采取措施并向原创作者支付赔偿。如果第三方起诉商业客户使用微软的 Copilot 或其生成的输出侵犯著作权，微软将为客户辩护并支付诉讼导致的任何不利判决或和解金额。该承诺是微软对人工智能生成内容著作权问题的积极回应。微软希望保护原创作者的权益，并促进人工智能技术的健康发展。谷歌承诺若商业客户使用谷歌云的 AIGC 服务，一切训练数据侵权或生成物侵权将由谷歌进行赔偿。2023 年 10 月 12 日，谷歌表示他们将为使用其Duet AI 和 Vertex AI 产品的商业用户提供法律保护，以防他们因侵犯著作权而面临诉讼。这一承诺旨在消除对生成式人工智能可能侵犯著作权规定的担忧14。谷歌表示，它将遵循“双管齐下、行业首创的方 13 见 https:/ 见 https:/ 年）14 法”进行知识产权赔偿。一是输入端训练数据的赔偿，在谷歌使用训练数据创建人工智能大模型的过程中，侵犯第三方知识产权的任何指控，都将由谷歌承担。二是生成物的赔偿，当生成物由客户创建时，谷歌的赔偿义务适用于其生成物侵犯第三方知识产权的指控。以上的赔偿包括诉讼费用及可能产生的著作权费用。谷歌提醒用户，只有在没有故意创建或使用生成物来侵犯他人权利，并且在引用时标明来源的情况下，该赔偿才适用。（二）日本：明晰合理使用原则，避免侵犯原著作权（二）日本：明晰合理使用原则，避免侵犯原著作权 一方面，日本政府明晰了输入端的合理使用标准，明确鼓励数据训练。2018 年，日本对著作权法进行了修订，在第 30 条第 4 款中增加了“不以欣赏作品原有价值为目的的利用”豁免条款，即对创作的作品内容本身进行使用，而不是出于欣赏、娱乐、教育或艺术等原有价值的目的。而大模型的数据训练是针对数据本身的内容进行学习，并不是出于个人本身的价值欣赏目的，符合 著作权法 的规定。这次修改总体上扩大了合理使用的范围，旨在鼓励创新，以适应人工智能和大数据等技术的兴起。自 2023 年以来，日本政府又通过多项措施强调现有的合理使用标准不会动摇。先是在 2023 年 4 月 24 日，日本文部科学大臣永岡桂子在记者会中表示，日本法律不会保护人工智能模型训练集中使用的著作权材料，也即允许人工智能模型训练对于著作权人作品的利用，无论是出于非营利或商业目的，无论是复制还是复制以外的行为。然后在 2023 年 5 月 17 日，日本参议院通过了 indemnification 人工智能知识产权法律问题研究报告（2023 年）15 一项新的著作权法修正案，但未对第 30 条第 4 款进行修改，这表明立法者认为该规定足以适应生成式人工智能等新技术带来的著作权挑战。最后在 2023 年 6 月，日本文化厅与内阁 AI 战略部门在人工智能与著作权法关系解释性文件中明确，在开发和训练阶段，应鼓励开发者创新但不应侵害著作权人正当利益。在将他人的著作权作品用于 AI 开发时，如果“使用行为不是为了侵占他人表达的思想或感受，则可以未经著作权所有者的许可使用受著作权保护的作品”。另一方面，日本政府明确以侵犯原有著作权为目的的数据训练，属于侵权行为。根据 2018 年修订的日本著作权法，在数据训练的限制条件上，使用形式应为作品的“非表达性利用”，即“不是为了表达作品而使用作品”的使用形式。它明确定义了侵权行为：一，行为目的不是对作品文本内容信息的分析和机器内部的加工处理等行为；二，行为旨在向公众传播作品的表达内容。例如，以制作可以感受到原始照片“所表达的本质特征”的图像为目的，从风景照片中提取必要的信息制作数字图像；或者将出售的作品著作权数据库复制，用于人工智能模型训练，属于侵权行为，因为以上行为超过了必要限度，损害著作权人正当权益。如果认定 AI 图像与现有作品相似或基于现有作品创作，著作权人可以申请著作权侵权的损害赔偿或禁令，而侵权人也可能受到刑事处罚。（三）欧盟：保护企业数据挖掘，推进治理精细水平（三）欧盟：保护企业数据挖掘，推进治理精细水平 在加速人工智能产业发展方面，欧盟明确了开发者进行数据挖掘时的合理使用原则。欧盟在 2019 年通过的单一数字市场著作权指人工智能知识产权法律问题研究报告（2023 年）16 令中解决了人工智能输入端数据学习中的侵权责任。其创设了第 3条“以科学研究为目的的文本和数据挖掘”和第 4 条不限制目的的“文本和数据挖掘”合理使用情形，以解决文本与数据挖掘对著作权保护带来的挑战。第 4 条规定的“不限制目的的文本和数据挖掘”情形适用于商业领域中的模型训练活动。这一规定采用了作者默示许可大数据企业将内容用于机器学习，并赋予作者选择自己的作品可以不被用于机器学习的权利。核心是对在“文本和数据挖掘”过程中的“作品复制行为”进行豁免。要求是获取被训练作品和其他内容必须合法，同时著作权人未明确保留文本和数据挖掘的权利。其合理使用的范围广泛，适用于商业领域的模型训练，条件相对宽松，仅要求内容合法获取且著作权人未明确保留文本和数据挖掘的权利，能显著降低模型训练平台的著作权风险。在人工智能产业治理方面，欧盟推进知识产权规则适用的精细化水平。欧盟在人工智能公司的监管和治理上以人工智能法案数字市场法 数字服务法 等为制度保障。2023 年欧洲议会通过的 人工智能法案从保护权利人自由决定权与利益角度出发，要求彻底记录任何用于训练 AI 系统如何生成类似于人类作品的文本、图像、视频和音乐的著作权材料。这将使权利人知道其博客文章、电子书、科学论文或歌曲是否已被用于 ChatGPT 等人工智能模型的训练，然后他们可以决定其作品是否可以被复制并寻求补偿。对于生成式人工智能工具如 ChatGPT，法案尝试按照其潜在风险进行分类，将透明度要求与风险级别挂钩，并实施不同的监管措施，强大计算能力的模型将人工智能知识产权法律问题研究报告（2023 年）17 面临更严格的规定。此外，用于数据训练模型的数据也将受到额外审查，这意味着对于封闭数据源模型的数据合规性要求将更为严格。尽管欧盟在实施这一法案方面可能需要数年时间，但这无疑是一个在人工智能发展和数据使用规范方面值得关注的法律方向。（四）中国：明确尊重知识产权，立法司法协同探索（四）中国：明确尊重知识产权，立法司法协同探索 其一，网信办出台办法明确必须尊重知识产权。国家网信办联合七部门发布的生成式人工智能服务管理暂行办法已施行，其中第四条第三项、第七条第二项要求在使用生成式人工智能的过程中必须尊重知识产权、不得侵害他人依法享有的知识产权。该办法的规定，为规范生成式人工智能服务的知识产权保护提供了法律依据。生成式人工智能服务提供者应当严格遵守该办法的规定，尊重知识产权，保护原创作者的合法权益。其二，司法明晰人工智能知识产权的保护条件。“菲林律师事务所诉百度案”15明确了人类参与AI生成是独创性的必要来源。原告菲林律所利用“威科先行”法律信息库，设置相应的检索条件，由该计算机软件智能生成了关于影视娱乐行业司法数据的分析报告，并在此报告的基础上整理创作了推送文章。被告百度未经菲林律所许可，在删除了涉案文章的署名、引言、检索概况等部分内容后，在其经营的百家号平台上发布被诉侵权文章。2019年5月，北京互联网法院一审宣判此案，判决认定计算机软件智能生成的涉案文章内容不构成作品，但其相关内容亦不能自由使用，百度未经许可使用涉案文章内容构成 15（2018）京 0491 民初 239 号北京菲林律师事务所诉北京百度网讯科技有限公司著作权侵权纠纷一案民事判决书，北京互联网法院，https:/ 人工智能知识产权法律问题研究报告（2023 年）18 侵权。在针对人工智能生成的作品的独创性判定上，法院认为，考察个性化来源时，需要基于数据差异产生的个性化特征，因为差异是由不同的数据选择、软件选择或图形类别选择所致，亦非原告自身智力创作获得，因此不能体现原告的独创性表达，故不具有独创性。“腾讯诉上海盈讯科技案”16明确了企业的参数选择和设置构成独创性参与。腾讯公司自主开发了一套基于数据和算法的智能写作辅助系统，名为“Dreamwriter”，用以满足规模化和个性化的内容业务需求。2018年8月20日，深圳腾讯公司在腾讯证券网站上首次发表了一篇财经报道文章，并在涉案文末尾注明“本文由腾讯机器人Dreamwriter自动撰写”。本案的被告上海盈讯公司未经腾讯公司许可和授权，在文章发表当日在其运营的网站转载了文章。2019年12月，深圳市南山区人民法院法院宣判，判决认为Dreamwriter软件生成的内容构成文字作品。法院并没有打破作品必须是作者的智力创作的一般法律规则，为了证明该人工智能产品构成作品，法院在判决书中强调，本案所涉文章是由原告深圳腾讯公司的首席创作团队成员使用Dreamwriter软件生成的。创作团队在数据输入、触发条件设置、模板选择、语料风格等方面的安排和选择是与涉案文章的具体表达形式直接相关的智力活动，该文章的表达形式是由原告主要创作团队相关人员的个性化安排和选择决定的。因此，涉案作品具有独创性，属于我国著作权法保护的文字作品。也就是说，本案中法院认定的作品并没有完全脱离人类的智力活动，并非完全由人工智能产生的文字内容。它们不是由人工智 16（2019）粤 0305 民初 14010 号深圳市腾讯计算机系统有限公司诉上海盈讯科技有限公司侵害著作权及不正当竞争纠纷案民事判决书，深圳市南山区人民法院 人工智能知识产权法律问题研究报告（2023 年）19 能独立创造的，而只是人类智力活动在人工智能协助下的结果。综合以上的两个案例可以看出，两个案例在独创性判定，作品构成判定、人工智能参与程度、侵权认定依据方面都有不同。在第一个案例中，法院更强调数据和软件选择对独创性判定的影响，认为计算机软件智能生成的文章内容不构成作品，强调差异并非由原告自身智力创作获得而是由人工智能选择获得，侵权认定主要基于百度未经许可使用涉案文章内容而不是基于作品的独创性。而在第二个案例中，法院更注重人类创作团队在智力活动中的直接参与，认定由人工智能生成的内容构成文字作品并受到著作权法保护，强调了原告创作团队在数据输入和语料风格等方面的智力活动使涉案作品是人工智能协助下人类智力活动的结果，认定侵权与作品的独创性密切相关。其三，北京互联网法院一审判决人工智能生成图片应当被认定为作品，受到著作权法保护。2023年11月27日，北京互联网法院针对人工智能生成图片著作权侵权纠纷作出一审判决。原告李某使用AI生成涉案图片后发布于小红书平台；被告系百家号博主，发布文章配图使用了原告该AI生成的图片，原告遂起诉。北互审理后认为，涉案人工智能生成图片（AI绘画图片）具备“独创性”要件，体现了人的独创性智力投入，应当被认定为作品，受到著作权法保护等17。该案被誉为我国AI生成图片相关领域的第一案。（五）小结：各方积极应对挑战，治理路径逐渐清晰（五）小结：各方积极应对挑战，治理路径逐渐清晰 总结来看，人工智能的知识产权问题引起了各方的积极关注和回 17 见微信公众号“知产力”文章，AI 生成图片著作权侵权第一案判决书，2023 年 11 月 29 日，https:/ 人工智能知识产权法律问题研究报告（2023 年）20 应。在输入端数据的合理使用方面，各方普遍认为应该保障作者所享有的著作权，并探索赋予作者一定的主动权，使其能够选择其作品不被用于机器学习。如表 3 所示，这种思路在欧盟人工智能法案和日本著作权法修订案中都得到了体现，即通过法律手段推动对大模型训练数据的合理使用和责任豁免机制的制度设计和法律制定。由于各方的法律体系和文化背景不同，对于著作权的单独授权问题，业界普遍认为不可行。因此，需要寻找能够达成各方共识的合理使用合法性基础，以实现产业发展和保护作者权益的平衡统一。这不仅对于人工智能产业的健康发展具有建设性意义，也有利于促进社会文学艺术的发展和繁荣。在解决人工智能知识产权问题时，需要综合考虑技术发展、市场规则、法律制度等多个方面。各方应该加强沟通协调，共同探讨合理使用人工智能技术的合法性和可行性，以实现人工智能产业和文学艺术的共同发展。在输出端内容的保护方面，如表 3 所示，各方普遍认为现有的著作权法能够合理地保护人工智能生成的内容。只有在人工智能的生成过程中有人类干预，并且满足著作权保护所需的其他条件，才能满足独创性的要求，从而获得著作权保护。由于人工智能目前仍处于发展阶段，考虑到当前的人工智能发展水平和世界各方的审查和保护条件，目前还没有给予人工智能生成物独立的著作权保护手段。因此，在著作权机制的适用方面，应该侧重于作品的文化属性，注重对独创作品的保护，同时支持人工智能创作的发展进步，以顺应著作权法变革的未来趋势。通过平衡人工智能生成物与人类创作作品的权益保护，可人工智能知识产权法律问题研究报告（2023 年）21 以促进人工智能技术的不断创新和进步，同时也有利于文化产业的发展和繁荣。表 3 各方应对人工智能著作权问题的保护路径 资料整理：中国信息通信研究院 四、人工智能知识产权治理展望 人工智能时代，创造性劳动、人机协作的既有范式已在发生转变。人工智能对于内容创作模式的更新本质上即是技术革新对于知识产权既有利益平衡制度的挑战。“十四五”时期，是乘势而上打造人工智能技术知识产权新优势的关键机遇期，与人工智能技术发展水平相国家国家/区域区域 输入数据训练使用方面输入数据训练使用方面 输出内容著作权保护方面输出内容著作权保护方面 美国 举行听证会讨论 根据现行知识产权法律，“合理使用”四要件存在灵活的裁量空间。作品的可著作权性是讨论重点 若用户对于输出内容不具有创造性贡献（投入/干预）和控制，则不应获得著作权保护 人工智能不能成为作者 日本 不是为了侵占权利人表达的思想或感受，不损害著作权人利益，即构成合理使用。用户创造性意图 创造性贡献 创造性表达想法/感受，可以获得著作权保护 适用与现有著作权侵权相同的标准 欧盟 以科学研究为目的的文本和数据挖掘例外“文本和数据挖掘”例外，作者默示许可 选择性退出默示许可 彻底记录任何用于训练 AI 系统如何生成类似于人类作品的文本、图像、视频和音乐的著作权材料（人工智能法案）中国 国家网信办联合七部门发布的生成式人工智能服务管理暂行办法已施行，其中第四条第三项、第七条第二项要求在使用生成式人工智能的过程中必须尊重知识产权、不得侵害他人依法享有的知识产权。人工智能生成内容的形式决定了独创性判断标准的差异，强调人对作品的参与程度。需要进一步判定使用人对人工智能生成物主张权利针对的是思想还是表达 人工智能知识产权法律问题研究报告（2023 年）22 适应的人工智能知识产权治理需要不断构建完善，为人工智能产业高质量发展提供关键支撑。（一）（一）完善完善治理理念治理理念 在治理理念方面，平衡著作权权利人、大模型经营者和社会公共利益的权利要求。人工智能知识产权治理牵涉到多个利益主体，需要综合考虑多方的权利与义务。首先，回应著作权权利人获得合理的报酬和著作权保护的呼声。在前人工智能时代，著作权作者是著作权的主体。在人工智能时代，著作权作者是人工智能创作的源泉。算法生成的内容正逐渐模糊创作的边界，因此需要明确知识产权的归属。通过建立透明的权益分配机制，确保创作者在人工智能创作中获得公正的回报，不仅能够激励创新，也有助于保护著作权权利人的创作积极性。其次，降低大模型经营者的知识产权风险。大模型经营者是科技进步和创新发展技术的主体。只有通过鼓励投入，支持技术进步探索，人工智能大模型才能提高性能和智能化水平，构建一个互利共赢的人工智能生态系统，加速技术进步。因此，治理理念应该坚持鼓励技术发展。同时，大模型经营者作为人工智能技术的关键推动者，应当积极采取措施，建立著作权合规框架和保护机制，确保数据和算法的合法使用，防范知识产权侵权行为，确保在发展过程中对知识产权的尊重，才能化解知识产权风险。最后，促进社会的知识普惠与文化创新的共同繁荣。人工智能的发展不应该仅仅服务于少数人或企业，可以坚持知识普惠的理念，确保人民群众受益于人工智能的应用，最大化人工智能技术对社会的积极影响，促进科技发展造福更广泛的群体。人工智能知识产权法律问题研究报告（2023 年）23 在推动知识共享的同时，利用人工智能强大的创造力，可以创作更多文化作品，创造文化消费场景，提供文化增长新动能，促进文化产业进一步繁荣。（二）（二）健全健全治理规则治理规则 一是主动明晰数据训练的合理使用规则。受人工智能生成物对现有知识产权保护制度的冲击，全球人工智能产业都在进入产业发展和产权保护的二元博弈。从著作权法的发展历程来看，从文字艺术作品到影视作品，其保护的客体和权利内容的范围也随着技术的更新逐渐扩大。针对人工智能对于输入端数据训练的合理使用，应积极主动确立法律配套规则。推动政策引导企业对数据进行合规使用，推动知识产权法律规则完善是必然之举，主动强化现有数据训练法律规则与知识产权法律的对接和融合。因此，当前著作权法更应积极主动跟上技术更新节奏，加入数据训练的著作权豁免条款，可以借鉴日本“非欣赏性原则”中针对机器学习的数据使用豁免，或者学习欧盟从“数据挖掘”角度整体化解知识产权风险，加快相关规范确立的进程。二是加快人工智能生成物保护范围的法律研究。以生成式人工智能对专利、著作权产生的影响为主要对象，深入展开理论研究，讨论人工智能对于权利人保护和网络空间运转产生的影响，利用司法判例、政策制定等路径探索技术和法治的发展阶段和下一步继续发展的方向。研究生成物在法律体系中的地位，制定规则明确生成物的责任，如损害赔偿或者不良影响等。人工智能知识产权法律问题研究报告（2023 年）24（三）统筹治理主体（三）统筹治理主体充分发挥各方主体参与，建立起综合、平衡、适应性强的人工智能知识产权治理体系。一是提高行业组织和标准机构围绕内容生成产业治理的内容质量，制定行业标准，推动行业联合研发著作权合规工具。统一的生成式人工智能标识或者水印可以降低开发成本、产品生产成本和内容风险，确保行业在技术和商业层面能够健康、可持续地发展。二是鼓励企业主体和开发者参与著作权治理流程。企业可以开发知识产权检测和内容可靠性工具，对生成内容采取机器审核、内容分类分级等手段，加强内容的审核和把控，确保内容的真实性、合法性和可靠性。主动对生成物的传播平台加强管理和监督，主动对生成物显著标识，做到合规安全的运营。企业可以通过合同分配人工智能作品的权利和义务，促进产业上下游的参与主体充分参与著作权的利益分配。企业间可以就知识产权使用达成许可和合作协议，共享技术、研发成果，加速产业创新和进步。三是倡导社会公众积极参与，普及人工智能知识产权对社会的影响，确保治理体系符合公众期望，同时尊重隐私和知识产权保护原则。普及人工智能技术常识，让公众更好地了解人工智能技术的本质、应用和发展趋势，更好地理解和使用相关技术和产品。提升公众的科技素养，使公众能够更好地理解和应对科技变革带来的挑战和机遇。通过了解和掌握人工智能技术，公众可以更好地发挥自身的创新能力，将人工智能技术应用到生活和工作中，提高生产力和效率。中国信息通信研究院中国信息通信研究院 知识产权与创新发展中心知识产权与创新发展中心地址：北京市海淀区花园北路地址：北京市海淀区花园北路 52 号号 邮编：邮编：100191 电话：电话： 传真：传真： 网址：网址：

0人已浏览 2023-12-15 30页 5星级

导论今天，能想到的或是想不到的领域，对容器和 Kubernetes 的需求都居高不减，使这项技术正在真正走向无处不在。从 2015 年正式对外提供服务至今，阿里云容器服务产品家族已经成长为企业的云原生应用操作系统，帮助越来越多的客户实现智能化、数字化创新，包括自动驾驶、智能科研、金融科技等众多新兴领域。其覆盖了从公共云、边缘云、到本地数据中心的各个场景。让所有需要云能力的地方，都有统一的容器基础设施。2023 年，阿里云容器产品能力持续受到业界的广泛认可。2023 年 9 月，在权威咨询机构 Gartner 发布的容器管理魔力象限中，由于在公共云、专有云、混合云等环境完善的产品体系，阿里云成为全球领导者，亚洲唯一。在 2022 年4 季度，Forrester 公共云开发与基础设施平台 Q4/22 评测中，阿里云是中国云原生开发者的最佳选择。智算时代已来。正如一个文明社会的科技水平取决于其对能源的利用能力，企业的智能化水平取决于其对算力的利用能力。云计算为智算时代带来无限可能，2023 年云栖大会上，阿里云容器服务宣布了以加速企业构筑现代化应用平台、最大化利用阿里云强大弹性算力为使命，在高效云原生算力、高性能智算应用、智能化运维管理、可信基础设施、分布式云架构 5 大核心方向带来的产品能力全新升级。本书精选 2023 云栖大会中“容器技术与服务”专题分享精华，集合容器服务产品家族最新发布、容器 AI 工程化创新、容器前沿技术与大规模生产实践、典型场景企业案例等方向内容，希望能够帮助您了解如何基于容器技术与服务，拥抱智算时代，为现代化应用构建加速！目录页第一章：容器产品最新发布阿里云 ACK 新升级，打造智算时代的现代化应用平台.6第二章：容器服务典型企业案例云原生场景下月省 10 万元资源成本，这家企业做对了什么.26米哈游大数据云原生实践.45第三章：容器 AI 工程化创新智算时代，基于 ACK 落地云原生 AI.66云原生场景下，AIGC 模型服务的工程挑战和应对.88第四章：容器前沿技术与大模型生产实践阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战.104基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程.123机密计算容器前沿探索与 AI 场景应用.143Koordinator 助力云原生应用性能提升小红书混部技术实践.158轻松搭建基于服务网格的 AI 应用，然后开始玩.176阿里云云原生弹性方案：用弹性解决集群资源利用率难题.212基于 ACK One 实现简单的跨云协同，让业务管理更高效.227阿里云 ACK 新升级，打造智算时代的现代化应用平台6第一章容器产品最新发布阿里云 ACK 新升级，打造智算时代的现代化应用平台6阿里云 ACK 新升级，打造智算时代的现代化应用平台作者：易立，阿里云研究员&容器服务负责人今天，能想到的或是想不到的领域，对容器和 Kubernetes 的需求都居高不减，使这项技术正在真正走向无处不在。在 2023 云栖大会上，阿里云云原生产品线容器服务负责人易立关于容器服务 ACK 在本届亚运会上应用的介绍，让现场观众眼前一亮，“以杭州亚运会为例，作为云原生技术底座，为亚运一站通、亚运钉等众多核心应用提供了高弹性、高可用、异地多中心的架构支持，确保了赛事系统万无一失。”阿里云容器服务 ACK 已经成长为企业的云原生应用操作系统，帮助越来越多的客户实现智能化、数字化创新，包括自动驾驶、智能科研、金融科技等众多新兴领域。其覆盖了从公共云、边缘云、到本地数据中心的各个场景。让所有需要云能力的地方，都有统一的容器基础设施。阿里云 ACK 新升级，打造智算时代的现代化应用平台7在过去一年，阿里云容器产品能力持续受到业界的广泛认可。2023 年 9 月，在权威咨询机构 Gartner 发布的容器管理魔力象限中，由于在公共云、专有云、混合云等环境完善的产品体系，阿里云成为全球领导者，亚洲唯一。在 2022 年 4 季度，Forrester 公共云开发与基础设施平台 Q4/22 评测中，阿里云是中国云原生开发者的最佳选择。智算时代已来，易立介绍了为助力企业构建现代化应用平台，阿里云容器服务在高效云原生算力、高性能智算应用、智能化运维管理、可信基础设施、分布式云架构 5 大核心方向带来的产品能力全新升级。1.新一代云原生算力，提升企业计算效能更大规模：弹性算力池新突破阿里云提供了丰富的弹性算力，包括 Intel/Amd/倚天 Arm 等多 CPU 架构，GPU/RDMA等多种异构加速器，以及按量、Spot、节省计划等多样化的售卖形态。使用 ACK，客户能够最大化利用阿里云整体弹性算力池能力，根据自己的需求灵活选择，增效降本。阿里云 ACK 新升级，打造智算时代的现代化应用平台8ACK 集群支持托管节点池、虚拟节点两种不同的数据面形态：托管节点池，支持任何 ECS 裸金属和虚拟机实例作为 K8s 工作节点，一个工作节点可以运行多个 Pod，全兼容 K8s 语义，兼具灵活性与易用性。虚拟节点，每个 Pod 运行在独立的弹性容器实例 ECI 之中。每个 ECI 实例是一个独立安全沙箱，具备高弹性、强隔离，免运维等特点。阿里云弹性计算基于 CIPU 可以统一生产ECS 裸金属实例、虚拟机实例和弹性容器实例。这意味这 ECI 支持弹性计算丰富的算力类型，具备充足的库存保障。今年 ACK 集群通过与弹性计算调度相互感知，可以更好调度 ECI 实例，支持将 K8s 对集群资源调度能力扩展到整个弹性算力池，确保了 ECS 节点池与虚拟节点的调度统一和能力一致，用户无需修改现有 K8s 应用定义即可最大化使用云资源。越来越多的客户基于 ACK 集群，构建大规模微服务架构应用和大规模数据计算任务。同时为了满足对集群规模增长的诉求，ACK 单集群最大支撑的节点从 10000 提升至 15000，ECI 实例从 20000 提升至 50000 实例。我们的控制面组件会根据数据面规模按需伸缩，保障稳定性。阿里云 ACK 新升级，打造智算时代的现代化应用平台9更优性价比：倚天架构专属优化越来越多的 ACK 客户选择倚天芯片作为新算力选择。客户选择倚天架构实例主要有如下三个原因：高性价比：相比 G7 实例族，Web 应用提升 50%，视频编解码提升 80%，Spark 任务提升 28%。高吞吐：采用 Arm V9 架构，提供独立物理核心，提供更确定性的性能；相比 G7 实例族，Web 应用吞吐提升 22%；Spark TPC-DS Benchmark 速度提升 15%。专属优化：容器镜像服务 ACR 联合基础软件团队、龙蜥社区在制品中心，提供了面向倚天芯片专属优化的基础软件及应用软件镜像。通过基于 AI 和专家知识库的KeenTune 为倚天架构提供专项参数调优。在主流场景中，优化后相比优化前性能提升 30%。为了支持容器应用向倚天架构平滑切换，ACR 提供了多架构镜像构建能力，支持一份源码构建出包含 x86、Arm 架构的应用镜像，同时 ACK 集群可以同时包含 Arm/x86 节点池阿里云 ACK 新升级，打造智算时代的现代化应用平台10或虚拟节点，让客户 K8s 应用在不同 CPU 架构下按需调度，逐步切换。更高弹性：全新发布节点池即时弹性能力最大化利用云的弹性能力是客户对容器产品的重要诉求，易立也带来了 ACK 的一项全新发布：“在阿里云上，容器服务每天有数百万核的算力资源按需扩缩容，帮助客户优化计算成本。今天，我们正式发布 ACK 节点池即时弹性能力”。ACK 节点池即时弹性 Scaler 拥有以下特点：更快的弹性速度：在 100 节点池的规模上，保持平均 45s 的端到端扩容速度，相比社区 Cluster Autoscaler 提升 60%。支持用户定义灵活的规格匹配策略：在社区的 Cluster Autoscaler 中，每个节点池中节点 CPU/Memory 规格是固定的，如需满足不同需求需要创建多个节点池，会带来配置管理复杂性、资源碎片引入的可能，并增加由于库存不足导致弹性稳定性降低的风险。即时弹性 Scaler 支持用户定义灵活的规格匹配策略，不同机型节点规格匹配条件下，系统会根据待调度的 Pending Pod 集合的资源请求和调度约束，及对 ECS 的库存感知，生成优化的装箱结果。这样，只需一个节点池就可以完成对多规格、多可用区阿里云 ACK 新升级，打造智算时代的现代化应用平台11的节点弹性。在降低节点池配置复杂度的同时，减少了资源碎片，提升了弹性的成功率。即时弹性完全兼容现有节点池能力和使用习惯，可以配合托管节点池实现节点的自动化运维。更简运维：ContainerOS 与全托管节点池结合对于 K8s 集群，节点运维是保障系统稳定性与安全的重要日常工作，但是手工操作非常复杂繁琐。ACK 托管节点池支持节点的全生命周期自动运维，包括 CVE 高危漏洞自动修复、节点故障自愈、OS/节点组件自动升级，其中节点自愈成功率 98%；集群节点运维时间减少 90%。ContainerOS 是龙蜥社区发布的面向容器优化的操作系统，采用不可变基础设施理念构建，具备精简、安全、可编程等特点。千节点弹性时间 P90 55s，相比 CentOS 等节点弹性时间降低 50%。ContainerOS 与全托管节点池可以完美结合，进一步优化了节点池的弹性和可运维性，让企业聚焦在自己的自身业务，而非 K8s 基础设施维护。更丰富场景：Serverless 容器为 AI 场景增效降本阿里云 ACK 新升级，打造智算时代的现代化应用平台12对 Serverless Container 的支持是 K8s 演进的重要方向，基于 ECI 的 ACK Serverless在客户场景中得到了广泛的应用。ACK、ECI 不但帮助微博热搜，钉钉会议等在线应用的弹性伸缩，也在助力众多 AI 和大数据客户降本增效。深势科技基于基于 ACK 与 ECI 实现多地域部署 AI 科研平台，免运维，按需创建实验环境，支持大规模 AI 镜像秒级拉取，资源利用率提升 30%。米哈游基于 ACK 与 ECI，统一全球各区服大数据平台架构，单日创建 200 万 以上 ECI实例执行 Spark 计算任务。通过高效利用 ECI Spot 实例，整体资源成本下降 50%。今年 ECI 弹性容器实例有四个重要发布：普惠降本：新增经济型规格，相比当前通用型价格下降 40%，面向成本敏感的Web 应用、计算任务、开发测试等工作负载。此外现有通用型实例价格也将在近期下调，最高下降 15%。极致性能：计划新增性能增强型规格，面对计算密集型业务场景，如科研、高性能计算、游戏，相比现有通用型实例，提供更高性能的算力、更具确定性的性能。弹性加速：ECI 通过对用户负载特征自学习和预测，实现底层资源的预调度，扩容速度阿里云 ACK 新升级，打造智算时代的现代化应用平台13提升至 7000 Pod/min，非常适于大规模数据任务处理场景。此外业界首家支持 GPU驱动版本选择，为 AI 应用提供更多灵活性的同时，冷启动提速 60%。灵活提效：ECI 今年发布了对倚天 Arm、AMD 架构的支持，ACK 也在近期上线了Windows 容器支持，支持更加丰富的企业应用场景。并且发布对细粒度内存规格支持，帮助用户精细化资源适配，消除空闲资源开销。2.云原生智算基础设施，构筑高效现代应用平台全面支持灵骏集群，为大模型训练提效过去一年，AIGC/大语言模型无疑是 AI 领域最重要的进展。随着大模型参数规模、训练数据和上下文长度的增长，训练大模型所消耗的计算量呈现指数级增长。ACK 全面支持阿里云灵骏智算集群，为大规模分布式 AI 应用提供高性能、高效率的 Kubernetes 集群。ACK 提供了对灵骏高性能算力的全面支持，以及批量 AI 任务调度，数据集加速，GPU 可观测与自愈等能力。通过软硬件协同设计与云原生架构优化，ACK 助力 PAI 灵骏智算方案高效利用强大的算力，为 AIGC、自动驾驶、金融、科研等众多智算业务场景提效。阿里云 ACK 新升级，打造智算时代的现代化应用平台14ACK 云原生 AI 套件增强，构筑企业专属 AI 工程化平台。ACK 去年推出云原生 AI 套件，帮助用户基于 Kubernetes 充分利用阿里云上弹性算力，支持弹性训练与推理等场景。在此之上既服务了阿里云 PAI、灵骏智算、通义千问等 AI 平台与服务，也提供对开源 AI 框架和模型的容器化支持。今年，针对大模型场景，AI 套件新增了对开源大模型框架 DeepSpeed，Megatron-LM，TGI 的容器化支持与优化。通过云原生 AI 套件的调度优化与数据访问加速，AI 训练速度提升 20%；大模型推理冷启动速度提升 80%，数据访问效率提升 30%。ACK AI 套件已被广泛应用于众多海内外企业，帮助客户构建自己专属的 AI 平台，显著提升 GPU 资源效率和 AI 工程效率。国产 AI 绘画工具海艺 AI：基于 Fluid 数据集加速和 AIACC 模型优化方案，推理性能提升 2 倍。任意门 Soul：基于 ACK 构建近千卡规模 AI PaaS 平台，开发迭代效率提升 2-5 倍。ACK 集群调度器，面向 AI/大数据负载优化扩展阿里云 ACK 新升级，打造智算时代的现代化应用平台15ACK 集群调度器基于 Koordinator 项目。它是基于阿里巴巴大规模混部实践孵化出的开源 Kubernetes 调度器实现，可以统一、高效地支持微服务、大数据、AI 应用等多样化的工作负载。其中我们针对 AI、大数据负载进行了如下优化和扩展：在全面兼容 Kubernetes 现有调度能力基础上提供批量任务的调度元语，如 GangScheduling，弹性配额、优先级调度等，可以与 Kubeflow，KubeDL 等社区项目无缝集成。支持拓扑感知性能优化，根据 PCIe、NVSwitch，以及 RDMA 网卡等互联链路的拓扑信息，自动选择能够提供最大通信带宽的 GPU 卡组合，有效提升模型训练效率。支持对 GPU 的细粒度资源共享调度，有效提升模型推理场景 GPU 资源利用率。近期我们与小红书在社区合作，将发布 Hadoop Yarn 任务与 Kubernetes 负载混部的能力，进一步提升 Kubernetes 集群的资源效率。相关工作帮助小红书 ACK 集群资源效率提升 10%。我们也在推进 Koordinator 捐赠到 CNCF 基金会，保持项目长期健康的发展，也欢迎大家在社区共建。阿里云 ACK 新升级，打造智算时代的现代化应用平台163.智能自治体系，降低容器运维管理成本ACK AIOps 智能产品助手，加速 K8s 问题定位与解决Kubernetes 自身技术复杂性是阻碍企业客户采用的一个重要因素。一旦 K8s 集群发生故障，对应用、集群、OS、云资源的问题排查，即使对经验丰富的工程师也充满挑战。ACK 全新升级容器 AIOps 套件，通过大模型结合专家系统的方式，让管理员可以通过智能产品助手，使用自然语言与系统进行交互，加速 Kubernetes 问题定位与解决。当问题发生时，AIOps 套件会采集上下文相关的 Kubernetes 对象与云资源的定义，状态与拓扑信息。比如 Deployment，Pod 和关联的节点等。以及相关的可观测信息，如日志，监控，告警等。然后会基于大模型进行数据分析与归集，给出当前问题的可能原因与修复方案。ACK 背后的大模型方案面对云原生开发和运维知识库进行了调优，提升了问题分析的准确度。用户可以进一步利用智能诊断中的专家经验系统，进行根因定位。现有 AIOps 套件包含 200 诊断项，覆盖 Pod，节点，网络等问题场景，可以对网络抖动，内核死锁、资源争抢等问题进行深入排查。除了用户驱动的问题诊断，AIOps 套件也在加强对自动化巡检和异常事件自动化实时处理，为集群稳定性、安全提供更加全面的防阿里云 ACK 新升级，打造智算时代的现代化应用平台17护，防患于未然。ACK FinOps 套件全面升级，精细场景化分析与分摊策略ACK 去年发布了 FinOps 成本管理套件，为企业管理员对 K8s 集群现了成本的“可见，可控，可优化”。在过去的一年中，FinOps 套件支持了不同行业的上百家客户，其中：乾象投资利用 FinOps 套件，优化应用配置，集群资源利用率提升 20%成本节省超过 10万元/月。极氪汽车通过 FinOps 套件实现混合云弹性降本，一年节省了数百万 IT 成本。今年，FinOps 套件全面升级，增加了更多场景化的分析与分摊策略，例如：在 AI 场景，可以基于 GPU 卡、显存等维度进行成本可视化。此外，FinOps 套件还发布了一键资源浪费检查功能，可以快速发现集群中空置的云盘、SLB 等未被使用的资源，让集群的整体资源利用率进一步提升。4.端到端容器安全，为构建可信 AI 应用护航阿里云 ACK 新升级，打造智算时代的现代化应用平台18可信化应用交付增强，ACK 与 ACR 提供 DevSecOps 软件供应链软件供应链安全是企业落地云原生技术的最大关切，Gartner 预计到 2025 年，全球 45%的组织都会遭受过软件供应链攻击。阿里云 ACK 和 ACR 服务提供 DevSecOps 最佳实践，实现了从镜像构建、分发到运行的自动化风险识别、阻断与预防能力。帮助企业构建安全可信的软件供应链。DevSecOps 的实践依赖研发、运维、安全团队的深入协同，今年，我们推出了集群容器安全概览，帮助企业安全管理员更好感知集群配置、应用镜像、容器运行时的安全风险，让供应链流程更加透明高效。通过使用我们的 DevSecOps 供应链安全能力：著名的汽车制造商路特斯每月实现千次安全配置巡检，预防高危风险配置上线；招联金融基于供应链策略治理能力，在每日 CI/CD 流程中实现千次风险镜的拦截阻断，保障金融业务安全。两全其美：Sidecarless 与 Sidecar 模式融合的服务网格新形态阿里云 ACK 新升级，打造智算时代的现代化应用平台19服务网格已经成为云原生应用的网络基础设施。阿里云服务网格 ASM 产品进行了全新的升级，成为业界首个发布托管式 Istio Ambient Mesh 的产品，提供对 Sidecarless 模式与 Sidecar 模式的融合支持。经典服务网格架构采用 Sidecar 模式，需要为每个 Pod 注入 Envoy Proxy Sidecar，实现流量拦截与转发。具备极高的灵活性，然而引入了额外的资源开源，增加了运维复杂性和与建联时延。在 Sidecarless 模式下，L4 代理的能力被移到节点上 CNI 组件中，可选L7 代理独立于应用程序运行。应用程序无需重新部署即可享受服务网格带来的安全加密，流量控制和可观察性等功能。在典型客户场景中,采用 Sidecarless 模型服务网格，可以减少资源开销 60%，简化运维成本 50%，降低时延 40%。托管式 Istio Ambient Mesh 有效地降低服务网格技术复杂度，推动零信任网络技术落地。新推隐私增强型算力，护航可信 AI 应用构建阿里云 ACK 新升级，打造智算时代的现代化应用平台20为解决企业对数据隐私日益关切，阿里云、达摩院操作系统实验室与 Intel 和龙蜥社区一起，推出基于可信执行环境（TEE）的机密计算容器（Confidential Containers，简称 CoCo）在云上的参考架构，结合可信软件供应链、可信数据存储，实现端到端安全可信容器运行环境，帮助企业抵御来自外部应用、云平台，甚至企业内部的安全攻击。ACK 基于阿里云八代 Intel 实例所提供的 Trust Domain Extension TDX 技术，全新推出对机密容器以及机密虚拟机节点池支持。使用 TDX 技术，业务应用无需更改，即可部署到 TEE 之中，极大降低了技术门槛，为金融、医疗、大模型等数据应用，提供隐私增强型算力。阿里云 ACK 新升级，打造智算时代的现代化应用平台21在 AI 时代，模型和数据成为企业核心业务资产。基于机密计算容器，阿里云基础软件、容器、以及英特尔团队提供了可信 AI 应用一个演示方案。在这个示例架构中。应用、AI 模型和微调数据集都被加密存储在云端服务中，在运行时由机密容器在 TEE 中对其进行解密后执行。模型推理与微调过程安全可信，保障数据的机密性与完整性。高性价比，基于 AMX 指令集优化，32 核 CPU 可以实现秒级 Stable Diffusion 出图。低损耗，TDX 带来的性能给损耗可以控制在 3%以内。5.更简单的跨云协同，让业务管理更高效阿里云 ACK 新升级，打造智算时代的现代化应用平台22ACK One Fleet 为不同地域的多个 K8s 集群提供了统一的控制平面，我们可以对公共云集群、边缘云集群和本地数据中心集群，实现统一的集群管理，资源调度、应用交付以及备份恢复能力。智联招聘使用 ACK One 实现混合云负载感知弹性，使用 ECI 5 分钟实现业务数万核扩容。极氪汽车使用 ACK One 统一管理数十个混合云 K8s 集群，提升安全水位和业务连续性，减少 25%的资源用量，运维效率提高 80%。阿里云 ACK 新升级，打造智算时代的现代化应用平台23在模拟仿真、科学计算等大规模数据计算工作流场景中，一个批次的计算可能需要数万，甚至数十万核算力，超出单地域的弹性供给能力，需要依赖跨地域的计算供给。在 IoT 以及医疗等场景中，海量数据分散在不同地域，需要具备就近计算能力。为此，ACK 推出全托管 Argo 工作流集群，具备事件驱动，大规模、免运维、低成本、跨地域等特点。Argo 工作流集群充分利用多 AZ、多地域的弹性算力，自动化利用 ECI Spot，有效降低资源成本。相比自建 Argo 工作流系统，可实现 30%的资源成本节省。集群内建分布式数据缓存，提供更大的聚合读取带宽，数据吞吐相比直接访问提高 15倍。集群提供优化 Argo 引擎，并行计算规模提升 10 倍。泛生子使用全托管 Argo 工作流集群在 12 小时内完成处理数千例肿瘤基因样本的处理，速度提升 50%，成本下降 30%。6.阿里云容器服务 ACK，智算时代云原生基础平台阿里云 ACK 新升级，打造智算时代的现代化应用平台24正如一个文明社会的科技水平取决于其对能源的利用能力，企业的智能化水平取决于其对算力的利用能力。云计算为智算时代带来无限可能，阿里云容器服务以为企业构筑现代化应用平台，最大化利用阿里云强大弹性算力为使命：通过对多样化算力的场景化高效利用，提升计算效能通过弹性与调度，提升资源利用率；通过智能自治，降低运维成本通过最佳实践与技术创新，提供端到端安全、可信运行环境阿里云 ACK 新升级，打造智算时代的现代化应用平台25第二章容器服务典型企业案例云原生场景下月省 10 万元资源成本，这家企业做对了什么26云原生场景下月省 10 万元资源成本，这家企业做对了什么作者：冯诗淳，阿里云技术专家&ACK 成本套件研发负责人相信近期从事基础设施工作的各位，对 IT 成本治理，以及 FinOps 体系的概念已经有了一些认知。在 Google 近 5 年的热度趋势中，FinOps 的趋势也在持续上升。在阿里云的同学与客户实际工作协同中，我们发现成本治理是几乎每位客户都存在的普适需求，特别是各位技术管理者重要的关注点之一。据 FinOps 基金会 2023 年的报告，有 43%、24%、17%的公司，是由 CTO、CIO、CFO 直接指派 FinOps 团队向他汇报，只有 14%的公司处于还未建立体系化的降本增效的 KPI。根据 FinOps 基金会的报告，建设 FinOps 体系 Top 的痛点非常复杂，包括技术方面问题、如何驱动工程师进行优化、如何减少浪费的资源、如何在容器场景做成本报告分析；同时也存在管理等问题，比如如何让团队组织适应 FinOps 体系等等。我们希望阿里云在提供产品功能的同时，也能正确真正地帮助我们的客户落地自己的 FinOps 体系，真正让客户降本增效。云原生场景下月省 10 万元资源成本，这家企业做对了什么27在 2023 年云栖大会现场，我们有幸邀请到某头部科技型量化投资公司的云基础设施负责人，为我们提供基于阿里云容器服务成本套件 ACK FinOps 落地的云原生场景成本治理案例，帮助大家了解在容器场景下的企业成本治理现状、挑战，以及如何结合 ACK 成本套件产品功能构建云原生用户自己的 FinOps 体系。1.容器场景成本治理挑战与实践本次分享的企业是中国领先的以人工智能和机器学习为基础的科技型量化投资公司，使用了大量的 AI、大数据作业来辅助量化交易决策，需要大量弹性的算力的同时，也需要更好的实现成本的控制，通过 Kubernetes 将 AI、大数据、工作流等作业放在一个集群中分时、弹性运行。以该企业为例，业务系统大致分为几类应用部署形态：稳定的系统应用不特定时间的按需任务测试开发环境的应用云原生场景下月省 10 万元资源成本，这家企业做对了什么28这几类应用都会消耗基础计算资源，并产生成本。目前该企业部分业务在使用阿里云容器服务 ACK 集群做容器化部署，通过 Kubernetes 进行量化交易的数据执行与决策，及阿里云 ACK FinOps 套件实现成本的洞察与分摊，经过治理后实现了近 30%资源水位的提升。在企业成本治理的实践过程中，该企业主要遇到规划难、分账难、管理难、优化难这 4方面的挑战。规划难在进行成本治理方面工作时，首先遇到的挑战是按需任务、测试开发环境的容量规划问题。开发、测试应用在容器化部署架构下，实现快速迭代的同时，难以较准确地给出分配的资源量。过度分配资源会导致资源浪费，资源超售过度则会导致稳定性问题。分账难该企业的云基础设施每天为很多的上层应用提供服务，多个容器应用共享一个 K8s 集群。一个计算节点上可能运行多个 Pod，而且 Pod 可以弹性伸缩，在节点间动态迁移。多个业务应用混部在同一个池化的 K8s 集群中，难以把整个集群的账单分摊到应用和人。应用层与资源层计量计费在空间、时间等多个维度都无法做到一一对应，成本治理的复杂性业因此而来。云原生场景下月省 10 万元资源成本，这家企业做对了什么29管理难另外，由于各个应用的使用场景存在很大差别，每当找出闲置浪费的资源后，往往难以“爽快地”马上缩容下线资源，如何在优化资源成本浪费的同时保障业务的稳定性，一直是一个难以回答的问题。优化难容器化后是拥有各种丰富的成本优化手段，但“这样调低 request 资源分配水位后，是否影响业务？”，“现有的 HPA 弹性伸缩策略，是否能在业务真正需求资源时正确工作”，甚至于“我现在要下线的网络、存储资源是不是真的没人使用？”云原生技术中例如弹性、混部、Serverless、超卖等技术都有各自适合的典型场景。如果使用不当，比如弹性配置错误，可能带来意想不到的资源浪费甚至稳定性问题。如何解决分账难题首先要面对分账难问题，理清花费在哪儿是最重要的工作。站在 Infra 团队的视角，一直以来和上层业务、应用层的部门同事的协作工作方式都是：云原生场景下月省 10 万元资源成本，这家企业做对了什么30当新业务需要上线、或老业务需要扩容时，业务部门会申请告诉我们他们“期望”使用多少的容量，为了保证业务稳定性，资源需求往往拍脑袋定义，且业务团队都希望申请冗余远远超过实际预期的资源量。长此以往，集群的水位就会出现大量闲置。由于业务是容器化混合部署的应用在同一集群中，应用的水位分布也往往呈现长尾效应，稳定的大规模应用往往经过重点优化已经有较高的资源利用率，但大量小规模应用使用大量闲置资源。传统部署模型下的资源成本统计方式，是按业务使用的节点维度分析成本，但是在 K8s 场景下，业务使用的资源统一从资源池中调度，业务对资源浪费也隐藏在整个集群、节点的水位中难以发现。要算清这本糊涂账，一定要把成本归因到具体某个业务应用，甚至是具体到某个人，才能推动真正地降本。怎么把成本归因到具体业务，首先需要精细化的监控数据，来看清业务对资源的使用情况。阿里云 ACK 团队可以为企业提供详细的成本、资源观测数据，包括：每天每笔云上资源的真实花销成本账单每个容器部署的资源使用量、使用水位部门、业务、个人这些业务层层级关系，该企业通过按集群的 namespace、不同工作负载、任务通过打特定 label 的方式，最终与具体 K8s 集群中的花费资源成本的 Pod 进行映射。最终通过结合阿里云 ACK 成本洞察数据的方式，可构建多个不同视角的成本资源监控大盘，包括：每天每笔不同云资源账单维度的监控大盘归因到业务应用/个人的监控大盘由此，便于分析发现应用维度的浪费，如形成 Top 浪费的应用报表，进行数据驱动地成本优化推进。云原生场景下月省 10 万元资源成本，这家企业做对了什么31面对成本管理难题Infra 团队在推动降本增效时往往是无力的，更多需要推动跨团队的协作。站在一个业务应用的上线过程来看协同关系，Infra 团队往往职责是接受上层业务层同事的需求，以及保证提供资源，这里的需求关系是从业务层到 Infra 层是至顶向下的。然而 Infra 团队与成本资源花销的距离是最近的，感知是最深切的，所以往往需要由 Infra团队来推动成本治理，构建 FinOps 体系的建设。这里的路径在跨部门的协同关系上反而是至下而上反方向的。Infra 团队就算找到对应的业务团队，推动他们缩容、下架掉闲置的云资源，往往由于没有数据驱动或对降本增效清晰的认识而难以开展工作，最终会导致极其低效的降本增效，白白浪费 Infra 团队工程师们宝贵的时间。我们不妨换个思路拆解一下解决方案。首先需要明确，所有人都需要对降本增效负责，且需要划分清晰的责任范围。以该企业为例，业务协同主要分为三大类角色：云原生场景下月省 10 万元资源成本，这家企业做对了什么32业务应用团队：负责业务应用的具体研发业务平台团队：负责为业务应用提供通用业务能力Infra 团队：为以上团队提供基础设施顺着成本治理的至下而上的路径，该企业划分了成本治理清晰的权责范围，以及通过构建不同视角的成本监控大盘构建统一的数据驱动成本洞察体系。首先对成本资源感知距离最近的 Infra 团队：拿数据说话，驱动业务团队优化。通过集群的 overview 整体视角的监控大盘，从集群、各项云资源、节点等视角，界定确定性的浪费资源，以及通过对各集群资源使用的 breakdown 分析，找到成本问题的症结所在。对于业务平台团队，从业务预算、Quota 层面驱动业务成本优化。每个业务也需要从财务层面做成本治理，这里业务平台团队通过成本洞察的数据，结合财务的预算，形成统一的报表、监控。如预算超标，需要透传分配 Infra 团队根据 breakdown 数据，进行成本分析。业务应用团队，需要选择科学可靠的成本优化手段。作为应用的研发，使用业务平台、Infra平台，他们是对业务、代码最了解的专家，也是需要平衡资源浪费与应用稳定性的最终负责人。在 FinOps 体系中，ACK 成本套件为他们提供应用视角的监控大盘，清晰观测自己应用资源、成本水位的同时，判断收敛后的资源水位是否合理，以及对自身业务变化规律来制定科学的弹性策略以满足动态资源的需求。云原生场景下月省 10 万元资源成本，这家企业做对了什么33如何规划资源&成本有了以上的分账、跨团队协作的解决方案后，我们来看规划难的问题。新业务上线需要规范流程，制定合理的容量规划。而新业务、跑批任务等，经过上线前压测，通过经验值或成本套件资源画像等只能推荐出科学的资源规格配置。针对这个问题，在上线过程可以使用 ACK AHPA 等智能弹性策略来做到动态业务趋势的智能资源调整。每个业务都不应该无限申请成本。把成本、资源归因到个人，同时也需要根据业务量、资源趋势制定财务预算，以及成本 Quota 计划。合理地进行成本控制。部门、业务、个人的成本预算，应按应用使用比例分摊到集群中的应用部署、Pod。该企业的做法主要是通过 namespace、给容器副本打业务 label 的方式进行映射。最终预算与归因到对应业务后的实际成本花费进行比对。成本控制方面也是通过 API 集成 ACK 成本洞察的成本数据后，细粒度到业务应用、个人云原生场景下月省 10 万元资源成本，这家企业做对了什么34来配置的成本超预算报警。寻找稳定和成本间的平衡最后，在真正进行资源优化过程中。平衡稳定性和成本浪费是非常重要的。首先对于浪费发现，存在两部分浪费：首先需要发现确定性的浪费。完全没有使用的网络 SLB、EIP 等资源，长期空闲的节点等，这些可以通过 ACK 限制资源检查找到这些确定性的浪费。第二部分是非常普遍的，应用的资源浪费。虽然平均集群资源利用率经过优化达到了约50%。由于是容器化混合部署的应用在同一集群中，应用的水位分布也往往呈现长尾效应，稳定的大规模应用往往经过重点优化已经有较高的资源利用率，但大量小规模应用使用大量闲置资源，隐藏在整个集群中难以发现。这里可以通过拉取 ACK 成本洞察的Pod 维度的成本资源数据，归因浪费到具体应用/个人后，会使这些应用的碎片化浪费逐个暴露出来。云原生场景下月省 10 万元资源成本，这家企业做对了什么35科学合理的 Quota 设置对 K8s 有经验的使用者，对 K8s 资源分配量(Request)、资源限制(Limit)两个值应该会有深刻的理解。科学地配置工作负载的 Request 量可以帮助进行容量规划控制资源成本，Limit 资源限制则可以实现混部的超卖和保证应用的稳定性。通过统一 K8s 集群上应用的 request、limit 设置规范，通过业务量压测、预估经验值，结合根据历史资源使用量的 ACK 资源画像智能推荐的 request、limit 值，该企业可以做到科学地为各个应用设置合理 Quota，平衡业务稳定性和成本浪费。合理地使用弹性策略HPA 很先进，但激进的 HPA 配置会导致应用不符合预期地扩缩、甚至导致业务稳定性；保守的 HPA 配置可能会导致还是会有大量闲置资源，起不到太多成本节省的效果。云原生技术中例如通过业务指标进行 HPA、CronHPA 等都有各自适合的典型场景。在该企业中也有部分业务应用使用 HPA 策略。首先比较确定性的场景如周期性的业务，使用CronHPA；同时，参考成本、资源监控数据优化阈值，通过 HPA 的历史数据，保证资源的流转效率。在决定 HPA 的指标的选择上，该企业会先区分 CPU 密集型的业务还是内存密集型的业务，根据调度的关键资源指标作为 HPA 的决定值。在一些新的业务，没有能参考的资源指标场景，也在使用 ACK AHPA 智能 HPA 策略，形成动态智能的弹性扩缩。云原生场景下月省 10 万元资源成本，这家企业做对了什么36整个成本治理工作是一个复杂且综合性的事务。经过近一年多，目前在 IT 成本上节省约25%的成本，超过月 10w 的成本节省，部分集群资源利用率从 20%提升至 50%。在整个实践的过程中，该企业也定义了资源流转效率指标，一个业务应用通过弹性扩缩对新资源的使用率，来反映一个应用对资源的浪费程度，资源流转效率越大代表越节约。目前经过IT 成本治理，资源流转效率有了 20%的提升。“我们也希望通过本次分享我们在 IT成本治理方面的工作经验，帮助其他互联网金融客户等云上客户更好地建设 FinOps 体系。”2.阿里云 ACK FinOps 套件助力容器成本数字化治理阿里云 ACK 团队希望提供真正能帮助用户在容器场景构建 FinOps 体系的产品能力。在深入沟通、了解企业对于容器成本治理的需求和问题后，我们总结出通用的三大 FinOps治理流程：成本洞察、成本优化、以及成本控制。云原生场景下月省 10 万元资源成本，这家企业做对了什么37在成本洞察中，ACK FinOp 套件提供多维度视角，帮助用户把集群中业务成本归因到组织和个人。成本洞察能力经过更多客户场景的打磨，推出更科学的分账算法，同时目前支持通过 API 让客户进行二次开发，以及如极氪汽车等多云场景我们支持多云成本适配器，帮助多云、IDC 机器混合等场景下成本治理保持统一。在成本优化中，我们提供资源画像功能，智能推荐应用优化配置，并通过 Koordinator 在离线混部组件进一步提升资源利用率。以及提供 CronHPA、AHPA 等丰富的自动弹性扩缩容策略。并提供智能资源浪费巡检。在成本控制阶段，ACK 将提供成本洞察大盘周报功能，直接抄送成本周报至对应业务团队更能推进团队进行成本优化，并树立 FinOps 建设意识，提供费用趋势预测，帮助刚好地指定业务预算，最终进行成本控制。云原生场景下月省 10 万元资源成本，这家企业做对了什么38看清成本、找出浪费，永远是成本治理的第一步。ACK 成本洞察功能帮助用户构建数据驱动的成本观测能力。ACK 成本洞察功能提供开箱即用的集群成本大盘，实时计算出多维视角的集群应用成本账单，以及提供不同资源配型，如包年包月、抢占式节点的横向比较，以及推荐不同的节省策略。同时，下钻到应用层的应用视角成本大盘，提供对应用浪费资源程度的 Top 排序，清晰明了发现混部隐藏在集群中的应用浪费问题。云原生场景下月省 10 万元资源成本，这家企业做对了什么39Infra 团队和上层应用团队需要按统一的口径进行成本分账。云原生场景架构复杂，不同应用形态也会在混部场景中对调度资源产生影响。ACK FinOps提供独有的云原生容器场景成本分摊与估算模型，通过衡量应用对调度的影响大小，更科学合理地对应用成本进行拆分。多数用户的应用可分为两种场景，如 JAVA、J2EE 部署的应用，多为内存密集型场景，如跑批的分布式计算任务，多为 CPU 密集型场景，此类场景，CPU 或内存、甚至 GPU，会作为集群调度的关键资源，决定应用是否能被调度。此场景我们推荐单资源分摊模型，按关键资源进行分账。如一个典型场景，用户在 ACK 集群的 GPU 节点跑 spark 的跑批任务，GPU 资源是当前最影响调度的资源，所以该应用的成本，应该按当前应用运行时间内占用的 GPU 资源来拆分整个节点的成本。混部场景的用户，作为云原生的深度用户，一个集群中会有内存密集型、CPU 密集型等多种应用混部，此时每种资源都决定调度策略，此时我们推出按资源调度水位计算的权重混合资源分摊模型，此模型计算一个应用应该分摊的成本，是由他所申请资源影响可调度资源的部分决定。ACK 成本洞察可通过混合资源分摊模型，按每个应用对调度的影响，自动计算出合理的应用分账成本。云原生场景下月省 10 万元资源成本，这家企业做对了什么40看清了成本浪费后，云原生容器场景下有复杂的架构体系，如何进行优化往往无从下手。ACK FinOPs 成本套件梳理出 ACK 成本优化路径落地的最佳实践，帮助用户在同步场景选型不同的成本优化方案。如业务应用经常波动的场景，可以通过感知业务的波动，选择自动弹性策略、或通过混部场景的动态资源超卖等提高资源利用率。在不感知业务的情况下，可以检查是否已经是最优的资源配型等。云原生场景下月省 10 万元资源成本，这家企业做对了什么41确定性的浪费是我们首要需要找出来并收敛掉的。真实生产环境中，Infra 团队不敢轻易删除集群里的资源，在此 ACK 成本套件推出闲置资源巡检功能，帮助用户找出集群里确定性的闲置资源。这里通过找到处于未使用状态的资源，但在出账时却被计入本集群的成本的资源。包括 无业务应用使用的 云服务器 ECS、块存储、负载均衡 CLB 和弹性公网 IP的闲置检查。根据 FinOps 基金会的 2023 年报告，对云资源的更大利用率使用，以及如何驱动工程师团队采取优化措施是现在 FinOps 体系中最令人头疼的问题。在容器场景混部、动态的应用环境下，ACK 资源画像功能可以提供基于应用历史数据的智能资源配置推荐功能。千人千面，在容器场景下是一应用一画像。为每个应用智能推荐升降配策略。解决应用刚上线、或应用业务波动大，无法正确容量规划问题。资源画像的核心技术点在于提供同时平衡过冗余时的浪费且保证过度超卖的稳定性的推荐算法。我们的推荐算法主要考虑了以下 3 方面：云原生场景下月省 10 万元资源成本，这家企业做对了什么42使用多种资源维度进行统计，并使用类似分位数的统计方法区分应用突发峰值需求和日常资源需求。使用半衰期华东窗口模型，确保新的数据对算法模型的影响越大，越旧的数据对算法的影响越小。以及考虑了容器运行时状态，参考容器的 OOM 等运行状态，进一步提高推荐值的准确性以及保证稳定性。用户为什么要云原生容器化，除了使用统一标准化的配置方式规范地使用云资源，更大程度也是为了享受集群池化的资源带来的资源利用率提升与系统稳定性的平衡。HPA 弹性伸缩策略是 Kubernetes 技术生态对这一平衡的重要体现。ACK 容器服务提供丰富的 HPA 弹性策略，针对不同的场景。标准的 HPA，主要解决的业务负载压力波动比较大时，需要人工根据监控来不断调整副本数的问题，实现自动扩缩容。云原生场景下月省 10 万元资源成本，这家企业做对了什么43VPA 垂直扩容 Pod 所在的节点，主要解决资源配额（Pod 的 CPU、内存的limit/request）评估不准的问题。非常实用的如上文企业面对的周期性波动的应用场景，使用 CronHPA，定时水平扩缩容。基于可预期的时间，提前规划扩缩容 Pod 数。主要解决在可预期的时间，资源不足的问题。同时我们也提供一些领域垂直的弹性伸缩解决方案，如业务事件驱动的 Keda、以及Serverless 场景支持如灰度发布等场景的 knative 等领域弹性伸缩解决方案。HPA 的配置确实需要根据应用具体场景，如是否波动，来决定具体选择哪种 HPA 解决方案，以及关键指标应该如何选择等。很多同学看到这里就知难而退了，这里有太多的 HPA策略，复杂的场景，难以规划的阈值参数，需要丰富的 K8s 经验。现在 ACK 推出 AHPA智能弹性策略功能，解决这个问题，也让我们窥见了下一个阶段 HPA 弹性策略的新形态。AHPA 通过收集应用 Pod 的历史数据，通过智能的周期检查 预测算法，结合 ACK 专业的 K8s 应用部署经验。通过资源提前预热，解决 HPA 弹出滞后性的问题。云原生场景下月省 10 万元资源成本，这家企业做对了什么44AHPA 自动配置阈值，智能识别业务指标曲线，无需人工干预，自动弹性规划。支持配置弹性降级保护，快速兜底容错。AHPA 使用资源提前预热的方法，根据智能算法提前预测将要发生的弹性对资源的需求，实时调整资源容量。正常客户的 HPA 拉起新的 Pod，需要经历如资源调度、拉取镜像、等待容器启动等耗时过程，AHPA 预热后解决客户弹性之后性的问题。通过历史数据的智能预测，无需人工干预，自动规划弹性策略、阈值，解决阈值配错、不好配的问题；以及 AHPA 与标准 HPA 相比，更合理阈值的配置也解决了弹性的滞后性问题。对突发的业务流量收缩，支持配置弹性降级保护措施，避免过保守的 HPA 策略不能降本增效，过激进的 HPA 策略面对突发情况时会影响业务稳定性。在提升资源使用率的同时，保障业务的稳定性。希望通过我们的分享，能够帮助更多企业了解在容器场景下的企业成本治理现状、挑战，以及如何结合阿里云容器服务 ACK 成本套件产品功能，构建企业自己的云原生 FinOps体系。米哈游大数据云原生实践45米哈游大数据云原生实践作者：米哈游大数据开发近年来，容器、微服务、Kubernetes 等各项云原生技术的日渐成熟，越来越多的公司开始选择拥抱云原生，并开始将 AI、大数据等类型的企业应用部署运行在云原生之上。以Spark 为例，在云上运行 Spark 可以充分享有公共云的弹性资源、运维管控和存储服务等，并且业界也涌现了不少 Spark on Kubernetes 的优秀实践。在刚刚结束的 2023 云栖大会上，米哈游数据平台组大数据技术专家杜安明分享了米哈游大数据架构向云原生化升级过程中的目标、探索和实践，以及如何通过以阿里云容器服务ACK 为底座的 Spark on K8s 架构，获得在弹性计算、成本节约以及存算分离方面的价值。1.背景简介随着米哈游业务的高速发展，大数据离线数据存储量和计算任务量增长迅速，早期的大数据离线架构已不再满足新场景和需求。为了解决原有架构缺乏弹性、运维复杂、资源利用率低等问题，2022 年下半年，我们着手调研将大数据基础架构云原生化，并最终在阿里云上落地了 Spark on K8s OSS-HDFS方案，目前在生产环境上已稳定运行了一年左右的时间，并获得了弹性计算、成本节约以及存算分离这三大收益。1）弹性计算由于游戏业务会进行周期版本更新、开启活动以及新游戏的上线等，对离线计算资源的需求与消耗波动巨大，可能是平时水位的几十上百倍。利用 K8s 集群天然的弹性能力，将Spark 计算任务调度到 K8s 上运行，可以比较轻松的解决这类场景下资源消耗洪峰问题。2）成本节约米哈游大数据云原生实践46依托阿里云容器服务 Kubernetes 版 ACK 集群自身强大的弹性能力，所有计算资源按量申请、用完释放，再加上我们对 Spark 组件的定制改造，以及充分利用 ECI Spot 实例，在承载同等计算任务和资源消耗下，成本节约达 50%。3）存算分离Spark 运行在 K8s 之上，完全使用 K8s 集群的计算资源，而访问的则数据也由 HDFS、OSS 逐步切换到 OSS-HDFS 上，中间 Shuffle 数据的读写采用 Celeborn，整套架构实现了计算和存储的解耦，易于维护和扩展。2.Spark on K8s 架构演进众所周知，Spark 引擎可以支持并运行在多种资源管理器之上，比如 Yarn、K8s、Mesos等。在大数据场景下，目前国内大多公司的 Spark 任务还是运行在 Yarn 集群之上的，Spark 在 2.3 版本首次支持 K8s，并于 2021 年 3 月发布的 Spark3.1 版本才正式 GA。相较于 Yarn，Spark 在 K8s 上起步较晚，尽管在成熟度、稳定性等方面还存在一定的欠缺，但是 Spark on K8s 能够实现弹性计算以及成本节约等非常突出的收益，所以各大公司也都在不断进行尝试和探索，在此过程中，Spark on K8s 的运行架构也在不断的向前迭代演进。1）在离线混部目前，将 Spark 任务运行在 K8s 上，大多公司采用的方案依旧是在线与离线混合部署的方式。架构设计依据的原理是，不同的业务系统会有不同的业务高峰时间。大数据离线业米哈游大数据云原生实践47务系统典型任务高峰期间会是凌晨的 0 点到 9 点钟，而像是各种应用微服务、Web 提供的 BI 系统等，常见的业务高峰期是白天时间，在这个时间以外的其它时间中，可以将业务系统的机器 Node 加入到 Spark 所使用的 K8s NameSpace中。如下图所示，将Spark 与其他在线应用服务等都部署在一套 K8s 集群之上。该架构的优点是可以通过在离线业务的混合部署和错峰运行，来提升机器资源利用率并降低成本，但是缺点也比较明显，即架构实施起来复杂，维护成本比较高，而且难以做到严格的资源隔离，尤其是网络层面的隔离，业务之间不可避免的会产生一定的相互影响，此外，我们认为该方式也不符合云原生的理念和未来发展趋势。2）Spark on K8s OSS-HDFS考虑到在离线混合部署的弊端，我们设计采用了一种新的、也更加符合云原生的实现架构：底层存储采用 OSS-HDFS(JindoFs)，计算集群采用阿里云的容器服务 ACK，Spark 选择功能相对丰富且比较稳定的 3.2.3 版本。米哈游大数据云原生实践48OSS-HDFS 完全兼容了 HDFS 协议，除了具备 OSS 无限容量、支持数据冷热存储等优点以外，还支持了目录原子性、毫秒级 rename 操作，非常适用于离线数仓，可以很好的平替现有 HDFS 和 OSS。阿里云 ACK 集群提供了高性能、可伸缩的容器应用管理服务，可以支持企业级Kubernetes 容器化应用的生命周期管理，ECS 是大家所熟知的阿里云服务器，而弹性容器实例 ECI 是一种 Serverless 容器运行服务，可以按量秒级申请与释放。该架构简单易维护，底层利用 ECI 的弹性能力，Spark 任务可以较为轻松的应对高峰流量，将 Spark 的 Executor 调度在 ECI 节点上运行，可最大程度的实现计算任务弹性与最佳的降本效果，整体架构的示意图如下所示。3.云原生架构设计与实现1）基本原理在阐述具体实现之前，先简要介绍一下 Spark 在 K8s 上运行的基本原理。Pod 在 K8s中是最小的调度单元，Spark 任务的 Driver 和 Executor 都是一个单独 Pod，每个 Pod米哈游大数据云原生实践49都分配了唯一的 IP 地址，Pod 可以包含一个或多个 Container，无论是 Driver 还是Executor 的 JVM 进程，都是在 Container 中进行启动、运行与销毁的。一个 Spark 任务被提交到 K8s 集群之后，首先启动的是 Driver Pod，而后 Driver 会向Apiserver 按需申请 Executor，并由 Executor 去执行具体的 Task，作业完成之后由Driver 负责清理所有的 Executor Pod，以下是这几者关系的简要示意图。2）执行流程下图展示了完整的作业执行流程，用户在完成 Spark 作业开发后，会将任务发布到调度系统上并进行相关运行参数的配置，调度系统定时将任务提交到自研的 Launcher 中间件，并由中间件来调用 spark-k8s-cli，最终由 Cli 将任务提交至 K8s 集群上。任务提交成功之后，Spark Driver Pod 最先启动，并向集群申请分配 Executor Pod，米哈游大数据云原生实践50Executor 在运行具体的 Task 时，会与外部 Hive、Iceberg、OLAP 数据库、OSS-HDFS等诸多大数据组件进行数据的访问与交互，而 Spark Executor 之间的数据 Shuffle 则由CeleBorn 来实现。3）任务提交关于如何将 Spark 任务提交到 K8s 集群上，各个公司的做法不尽相同，下面先简要描述下目前比较常规的做法，然后再介绍目前我们线上所使用的任务提交和管理方式。3.1 使用原生 spark-submit通过 spark-submit 命令直接提交，Spark 原生就支持这种方式，集成起来比较简单，也符合用户的习惯，但是不方便进行作业状态跟踪和管理，无法自动配置 Spark UI 的Service 和 Ingress，任务结束后也无法自动清理资源等，在生产环境中并不适合。3.2 使用 spark-on-k8s-operator这是目前较常用的一种提交作业方式，K8s 集群需要事先安装 spark-operator，客户端通过 kubectl 提交 yaml 文件来运行 Spark 作业。本质上这是对原生方式的扩展，最终提交作业依然是使用 spark-submit 方式，扩展的功能包括：作业管理，Service/Ingress创建与清理，任务监控，Pod 增强等。此种方式可在生产环境中使用，但与大数据调度平台集成性不太好，对于不熟悉 K8s 的用户来说，使用起来复杂度和上手门槛相对较高。米哈游大数据云原生实践513.3 使用 spark-k8s-cli在生产环境上，我们采用 spark-k8s-cli 的方式进行任务的提交。spark-k8s-cli 本质上是一个可执行的文件，基于阿里云 emr-spark-ack 提交工具我们进行了重构、功能增强和深度的定制。spark-k8s-cli 融合 spark-submit 和 spark-operator 两种作业提交方式的优点，使得所有作业都能通过 spark-operator 管理，支持运行交互式 spark-shell 和本地依赖的提交，并且在使用方式上与原生 spark-submit 语法完全一致。在上线使用初期，我们所有任务的 Spark Submit JVM 进程都启动在 Gateway Pod 中，在使用一段时间后，发现该方式稳定性不足，一旦 Gateway Pod 异常，其上的所有正在Spark 任务都将失败，另外 Spark 任务的日志输出也不好管理。鉴于此种情况，我们将spark-k8s-cli 改成了每个任务使用单独一个 Submit Pod 的方式，由 Submit Pod 来申请启动任务的 Driver，Submit Pod 和 Driver Pod 一样都运行在固定的 ECS 节点之上，Submit Pod 之间完全独立，任务结束后 Submit Pod 也会自动释放。spark-k8s-cli 的提交和运行原理如下图所示。米哈游大数据云原生实践52关于 spark-k8s-cli，除了上述基本的任务提交以外，我们还做了其他一些增强和定制化的功能。支持提交任务到同地域多个不同的 K8s 集群上，实现集群之间的负载均衡和故障转移切换实现类似 Yarn 资源不足时的自动排队等待功能（K8s 如果设置了资源 Quota，当Quota 达到上限后，任务会直接失败）增加与 K8s 网络通信等异常处理、创建或启动失败重试等，对偶发的集群抖动、网络异常进行容错支持按照不同部门或业务线，对大规模补数任务进行限流和管控功能内嵌任务提交失败、容器创建或启动失败以及运行超时等告警功能米哈游大数据云原生实践534）日志采集与展示K8s 集群本身并没有像 Yarn 那样提供日志自动聚合和展示的功能，Driver 和 Executor的日志收集需要用户自己来完成。目前比较常见的方案是在各个 K8s Node 上部署 Agent，通过 Agent 把日志采集并落在第三方存储上，比如 ES、SLS 等，但这些方式对于习惯了在 Yarn 页面上点击查看日志的用户和开发者来说，使用起来很不方便，用户不得不跳转到第三方系统上捞取查看日志。为实现 K8s Spark 任务日志的便捷查看，我们对 Spark 代码进行了改造，使 Driver 和Executor 日志最终都输出到 OSS 上，用户可以在 Spark UI 和 Spark Jobhistory 上，直接点击查看日志文件。上图所示为日志的收集和展示原理，Spark 任务在启动时，Driver 和 Executor 都会首先注册一个 Shutdown Hook，当任务结束 JVM 退出时，调用 Hook 方法把完整的日志上传到 OSS 上。此外，想要完整查看日志，还需要对 Spark 的 Job History 相关代码做下改造，需要在History 页面显示 stdout 和 stderr，并在点击日志时，从 OSS 上拉取对应 Driver 或Executor 的日志文件，最终由浏览器渲染查看。另外，对于正在运行中的任务，我们会提供一个 Spark Running Web UI 给用户，任务提米哈游大数据云原生实践54交成功后，spark-operator 会自动生成的 Service 和 Ingress 供用户查看运行详情，此时日志的获取通过访问 K8s 的 api 拉取对应 Pod 的运行日志即可。5）弹性与降本基于 ACK 集群提供的弹性伸缩能力，再加上对 ECI 的充分利用，同等规模量级下的 Spark任务，运行在 K8s 的总成本要明显低于在 Yarn 固定集群上，同时也大大提高了资源利用率。弹性容器实例 ECI 是一种 Serverless 容器运行服务，ECI 和 ECS 最大的不同就在于ECI 是按量秒级计费的，申请与释放速度也是秒级的，所以 ECI 很适合 Spark 这一类负载峰谷明显的计算场景。上图示意了 Spark 任务在 ACK 集群上如何申请和使用 ECI，使用前提是在集群中安装ack-virtual-node 组件，并配置好 Vswitch 等信息，在任务运行时，Executor 被调度到虚拟节点上，并由虚拟节点申请创建和管理 ECI。ECI 分为普通实例和抢占式实例，抢占式实例是一种低成本竞价型实例，默认有 1 小时的保护期，适用于大部分 Spark 批处理场景，超出保护期后，抢占式实例可能被强制回收。米哈游大数据云原生实践55为进一步提升降本效果，充分利用抢占式实例的价格优势，我们对 Spark 进行改造，实现了 ECI 实例类型自动转换的功能。Spark 任务的 Executor Pod 都优先运行在抢占式 ECI 实例上，当发生库存不足或其他原因无法申请创建抢占式实例，则自动切换为使用普通 ECI 实例，保证任务的正常运行。具体实现原理和转换逻辑如下图所示。6）Celeborn由于 K8s 节点的磁盘容量很小，而且节点都是用时申请、用完释放的，无法保存大量的Spark Shuffle 数据。如果对 Executor Pod 挂载云盘，挂载盘的大小难以确定，考虑到数据倾斜等因素，磁盘的使用率也会比较低，使用起来比较复杂。此外，虽然 Spark 社区在 3.2 提供了 Reuse PVC 等功能，但是调研下来觉得功能尚不完备且稳定性不足。为解决 Spark 在 K8s 上数据 Shuffle 的问题，在充分调研和对比多家开源产品后，最终采用了阿里开源的 Celeborn 方案。Celeborn 是一个独立的服务，专门用于保存 Spark的中间 Shuffle 数据，让 Executor 不再依赖本地盘，该服务 K8s 和 Yarn 均可以使用。米哈游大数据云原生实践56Celeborn 采用了 Push Shuffle 的模式，Shuffle 过程为追加写、顺序读，提升数据读写性能和效率。基于开源的 Celeborn 项目，我们内部也做了一些数据网络传输方面的功能增强、Metrics丰富、监控告警完善、Bug 修复等工作，目前已形成了内部稳定版本。7）Kyuubi on K8sKyuubi 是一个分布式和多租户的网关，可以为 Spark、Flink 或 Trino 等提供 SQL 等查询服务。在早期，我们的 Spark Adhoc 查询是发送到 Kyuubi 上执行的。为了解决Yarn 队列资源不足，用户的查询 SQL 无法提交和运行的问题，在 K8s 上我们也支持了Kyuubi Server 的部署运行，当 Yarn 资源不足时，Spark 查询自动切换到 K8s 上运行。鉴于 Yarn 集群规模逐渐缩减，查询资源无法保证，以及保障相同的用户查询体验，目前我们已将所有的 SparkSQL Adhoc 查询提交到 K8s 上执行。为了让用户的 Adhoc 查询也能在 K8s 上畅快运行，我们对 Kyuubi 也做了一些源码改造，包括对 Kyuubi 项目中 docker-image-tool.sh、Deployment.yaml、Dockfile 文件的改写，重定向 Log 到 OSS 上，Spark Operator 管理支持、权限控制、便捷查看任米哈游大数据云原生实践57务运行 UI 等。8）K8s Manager在 Spark on K8s 场景下，尽管 K8s 有集群层面的监控告警，但是还不能完全满足我们的需求。在生产环境中，我们更加关注的是在集群上的 Spark 任务、Pod 状态、资源消耗以及 ECI 等运行情况。利用 K8s 的 Watch 机制，我们实现了自己的监控告警服务 K8sManager，下图所示为该服务的示意图。K8sManager 是内部实现的一个比较轻量的 Spring Boot 服务，实现的功能就是对各个米哈游大数据云原生实践58K8s 集群上的 Pod、Quota、Service、ConfigMap、Ingress、Role 等各类资源信息监听和汇总处理，从而生成自定义的 Metrics 指标，并对指标进行展示和异常告警，其中包括集群 CPU 与 Memory 总使用量、当前运行的 Spark 任务数、Spark 任务内存资源消耗与运行时长 Top 统计、单日 Spark 任务量汇总、集群 Pod 总数、Pod 状态统计、ECI机器型号与可用区分布统计、过期资源监控等等，这里就不一一列举了。9）其他工作9.1 调度任务自动切换在我们的调度系统中，Spark 任务支持配置 Yarn、K8s、Auto 三种执行策略。如果用户任务指明了需要运行使用的资源管理器，则任务只会在 Yarn 或 K8s 上运行，若用户选择了 Auto，则任务具体在哪里执行，取决于当前 Yarn 队列的资源使用率，如下图所示。由于总任务量较大，且 Hive 任务也在不断迁移至 Spark，目前仍然有部分任务运行在Yarn 集群上，但最终的形态所有任务将由 K8s 来托管。9.2 多可用区、多交换机支持Spark 任务运行过程中大量使用 ECI，ECI 创建成功有两个前提条件:1、能够申请到 IP 地址；2、当前可用区有库存。实际上，单个交换机提供的可用 IP 数量有限，单个可用区拥有的抢占式实例的总个数也是有限的，因此在实际生产环境中，无论是使用普通 ECI 还是Spot 类型的 ECI，比较好的实践方式是配置支持多可用区、多交换机。米哈游大数据云原生实践599.3 成本计算由于在 Spark 任务提交时，都已明确指定了每个 Executor 的 Cpu、Memory 等型号信息，在任务结束 SparkContxt 关闭之前，我们可以从任务的中拿到每个 Executor 的实际运行时长，再结合单价，即可计算出 Spark 任务的大致花费。由于 ECI Spot 实例是随着市场和库存量随时变动的，该方式计算出来的单任务成本是一个上限值，主要用于反映趋势。9.4 优化 Spark Operator在上线初期任务量较少时，Spark Operator 服务运行良好，但随着任务不断增多，Operator 处理各类 Event 事件的速度越来越慢，甚至集群出现大量的 ConfigMap、Ingress、Service 等任务运行过程中产生的资源无法及时清理导致堆积的情况，新提交Spark 任务的 Web UI 也无法打开访问。发现问题后，我们调整了 Operator 的协程数量，并实现对 Pod Event 的批量处理、无关事件的过滤、TTL 删除等功能，解决了 Spark Operator 性能不足的问题。9.5 升级 Spark K8s ClientSpark3.2.2 采用 fabric8(Kubernetes Java Client)来访问和操作 K8s 集群中的资源，默认客户端版本为 5.4.1，在此版本中，当任务结束 Executor 集中释放时，Driver 会大量米哈游大数据云原生实践60发送 Delete Pod 的 Api 请求到 K8s Apiserver 上，对集群 Apiserver 和 ETCD 造成较大的压力，Apiserver 的 cpu 会瞬间飙高。目前我们的内部 Spark 版本，已将 kubernetes-client 升级到 6.2.0，支持 pod 的批量删除，解决 Spark 任务集中释放时，由大量的删除 Api 请求操作的集群抖动。3.问题与解决方案在整个 Spark on K8s 的方案设计以及实施过程中，我们也遇到了各种各样的问题、瓶颈和挑战，这里做下简单的介绍，并给出我们的解决方案。1）弹性网卡释放慢弹性网卡释放速度慢的问题，属于 ECI 大规模应用场景下的性能瓶颈，该问题会导致交换机上 IP 的剧烈消耗，最终导致 Spark 任务卡住或提交失败，具体触发原因如下图所示。目前阿里云团队已通过技术升级改造解决，并大幅提升了释放速度和整体性能。2）Watcher 失效Spark 任务在启动 Driver 时，会创建对 Executor 的事件监听器，用于实时获取所有Executor 的运行状态，对于一些长时运行的 Spark 任务，这个监听器往往会由于资源过米哈游大数据云原生实践61期、网络异常等情况而失效，因此在此情况下，需要对 Watcher 进行重置，否则任务可能会跑飞。该问题属于 Spark 的一个 Bug，当前我们内部版本已修复，并将 PR 提供到了 Spark 社区。3）任务卡死如上图所示，Driver 通过 List 和 Watch 两种方式来获取 Executor 的运行状况。Watch采用被动监听机制，但是由于网络等问题可能会发生事件漏接收或漏处理，但这种概率比较低。List 采用主动请求的方式，比如每隔 3 分钟，Driver 可向 Apiserver 请求一次自己任务当前全量 Executor 的信息。由于 List 请求任务所有 Pod 信息，当任务较多时，频繁 List 对 K8s 的 Apiserver 和ETCD 造成较大压力，早期我们关闭了定时 List，只使用 Watch。当 Spark 任务运行异常，比如有很多 Executor OOM 了，有一定概率会导致 Driver Watch 的信息错误，尽管Task 还没有运行完，但是 Driver 却不再申请 Executor 去执行任务，发生任务卡死。对此我们的解决方案如下:在开启 Watch 机制的同时，也开启 List 机制，并将 List 时间间隔拉长，设置每 5 分钟请求一次修改 ExecutorPodsPollingSnapshotSource 相关代码，允许 Apiserver 服务端缓存，从缓存中获取全量 Pod 信息，降低 List 对集群的压力米哈游大数据云原生实践624）Celeborn 读写超时、失败ApacheCeleborn 是阿里开源的一款产品，前身为 RSS(Remote Shuffle Service)。在早期成熟度上还略有欠缺，在对网络延迟、丢包异常处理等方面处理的不够完善，导致线上出现一些有大量 Shuffle 数据的 Spark 任务运行时间很长、甚至任务失败，以下三点是我们针对此问题的解决办法。优化 Celeborn，形成内部版本，完善网络包传输方面的代码调优 Celeborn Master 和 Worker 相关参数，提升 Shuffle 数据的读写性能升级 ECI 底层镜像版本，修复 ECI Linux 内核 Bug5）批量提交任务时，Quota 锁冲突为了防止资源被无限使用，我们对每个 K8s 集群都设置了 Quota 上限。在 K8s 中，Quota 也 是 一 种 资 源，每 一 个Pod 的 申 请 与 释 放 都 会 修 改Quota 的 内 容(Cpu/Memory 值)，当很多任务并发提交时，可能会发生 Quota 锁冲突，从而影响任务Driver 的创建，任务启动失败。应对这种情况导致的任务启动失败，我们修改 Spark Driver Pod 的创建逻辑，增加可配置的重试参数，当检测到 Driver Pod 创建是由于 Quota 锁冲突引起时，进行重试创建。Executor Pod 的创建也可能会由于 Quota 锁冲突而失败，这种情况可以不用处理，Executor 创建失败 Driver 会自动申请创建新的，相当于是自动重试了。米哈游大数据云原生实践636）批量提交任务时，UnknownHost 报错当瞬时批量提交大量任务到集群时，多个 Submit Pod 会同时启动，并向 Terway 组件申请 IP 同时绑定弹性网卡，存在一定概率出现以下情况，即 Pod 已经启动了，弹性网卡也绑定成功但是实际并没有完全就绪，此时该 Pod 的网络通信功能实际还无法正常使用，任务访问 Core DNS 时，请求无法发出去，Spark 任务报错 UnknownHost 并运行失败。该问题我们通过下面这两个措施进行规避和解决：为每台 ECS 节点，都分配一个 Terway Pod开启 Terway 的缓存功能，提前分配好 IP 和弹性网卡，新 Pod 来的直接从缓存池中获取，用完之后归还到缓存池中7）可用区之间网络丢包为保障库存的充足，各 K8s 集群都配置了多可用区，但跨可用区的网络通信要比同可用区之间通信的稳定性略差，即可用区之间就存在一定概率的丢包，表现为任务运行时长不稳定。对 于 跨 可 用 区 存 在 网 络 丢 包 的 现 象，可 尝 试 将ECI 的 调 度 策 略 设 定 为VSwitchOrdered，这样一个任务的所有 Executor 基本都在一个可用区，避免了不同可以区 Executor 之间的通信异常，导致的任务运行时间不稳定的问题。054.总结与展望最后，非常感谢阿里云容器、ECI、EMR 等相关团队的同学，在我们整个技术方案的落地与实际迁移过程中，给予了非常多的宝贵建议和专业的技术支持。目前新的云原生架构已在生产环境上稳定运行了近一年左右的时间，在未来，我们将持续对整体架构进行优化和提升，主要围绕以下几个方面:米哈游大数据云原生实践64持续优化云原生的整体方案，进一步提升系统承载与容灾能力云原生架构升级，更多大数据组件容器化，让整体架构更加彻底的云原生化更加细粒度的资源管理和精准的成本控制米哈游大数据云原生实践65第三章容器 AI 工程化创新智算时代，基于 ACK 落地云原生 AI66智算时代，基于 ACK 落地云原生 AI作者：张凯，阿里云高级技术专家1.背景以 GPT（Generative Pre-trained Transformer）和 Diffusion model 为代表的大语言模型（Large language model，LLM）和生成式人工智能（Generative artificial intelligence，GAI）在过往两年，将人们对 AI 的梦想与期待推向了一个新高峰。这一次，AI 带来的“智能”效果和“涌现”能力，吸引着千行百业都在积极思考如何在业务中利用大模型。即便训练一次千亿参数量模型的成本可能就高达百万美元，依然有很多企业希望拥有自己的专属大模型。今天的云计算已经承载了从业务应用，到数据库、大数据、机器学习和高性能计算等大多数计算负载。面对 LLM 和 GAI 这类对算力和数据都有极高量级需求的新负载，云计算也迎来了“智算”时代。一方面以服务化资源池的方式提供千 GPU 卡，甚至万卡的算力，PB 级存储和单机 Tb 级高性能网络互联，另一方面以云原生标准化交付算力给大模型的生产者和使用者。阿里云云原生容器服务借助容器、Kubernetes、微服务等云原生技术，在阿里云弹性计算、存储、网络和灵骏智算服务基础之上，推出了 ACK 云原生 AI 套件产品和解决方案，帮助企业在“智算”时代，更快、更高效地落地云原生 AI 系统。此次云栖大会的分享共分三部分，介绍云原生 AI 领域的基础知识。首先，解析云原生 AI所遇到的技术提站和应对方案，随后介绍云原生 AI 领域的关键技术与架构细节，最后分享我们在 ACK 的相关经验及工程实践。智算时代，基于 ACK 落地云原生 AI672.大模型带来的技术挑战 AI在计算机视觉、语音、NLP等领域取得突破，已深入影响各行各业 AI服务上云形成趋势 深度学习/AIGC应用广泛采用容器等云原生技术开发探索数据准备模型构建模型训练模型推理调优提效持续发布弹性深度学习的特点 端到端流水线 Raw data in,executable model out 任务长时运行 小时天周 持续迭代优化梯度下降,超参数调优,Prompt工程 消耗大量算力和海量数据人工智能机器学习深度学习(Supervised learning)Generative AIReinforcement learningUnsupervised learning人工智能(AI)发展概述New Future on Cloud近年来，深度学习引领 AI 的再次快速发展，并已成为主流方向。其中涉及到多种技术，包括有监督学习、强化学习、无监督学习等。以深度学习为代表的技术已在计算机视觉、语音识别等领域取得巨大进展，推动了许多行业的创新。通过云化服务的方式，交付 AI 能力也成为一种趋势。总结深度学习任务的特性包括：首先，它是一种端到端的工作流程，旨在从大量原始数据中提取特征，进而创建可执行模型。其次，通常需要长时间的训练，任务运行时间可能以小时，甚至以月为单位。在训练过程中，需反复迭代优化，不断调整参数，以使模型能够更好地接近真实数据特征分布。这会导致算力资源和数据的巨大消耗。智算时代，基于 ACK 落地云原生 AI68工作项原有方式：从底层资源到上层框架，全手动环境搭建安装配置脚本，make，Bazel或者pip安装，容器镜像分布式环境通过SSH登录到每台机器上手工部署GPU资源调度手动管理，静态分配，使用效率不明确数据准备数据存储共享自建存储，手动拷贝训练数据到每台机器上模型开发开发手动安装J upyter，Tensorboard等工具模型训练训练登录每台机器上手工启动、记录、对比实验监控GPU资源监控：登录GPU主机执行nvidia-smi查看，或编写代码调用NVML；训练效果监控：手动启动TensorBoard错误处理缺少容错，手动保存checkpoint、重启任务模型推理模型发布用户需自定义发布流程和系统线上运维用户自建运维系统OS、Nvidia驱动、CUDA、cuDNN等环境配置 NVIDIA Driver 367,370;CUDA Toolkit 7.5,8.0;cuDNN 5.软件的依赖关系 Python,GCC,Bazel 资源分配策略多样 GPU卡型更新频繁 应用要指定单张或多张GPU卡 甚至要使用一张GPU卡的部分资源GPU运维复杂 监控维度多 故障排查难 弹性不灵活数据科学家算法工程师平台运维复杂、多变、低效GPU利用率如何？如何提升GPU资源的ROI？还有多少GPU空闲？我的GPU还正常工作吗？AI工程落地难、效率低以深度学习为代表的AI生产系统面临效率、性能和成本挑战挑战1：GPU集群管理复杂挑战2：深度学习工程效率低理解了深度学习为代表的 AI 工作负载特性后，我们可以发现在实际生产和应用中，AI 和深度学习工程会面临几个主要挑战，尤其是在效率、性能和成本方面。例如，管理 GPU 集群是一项非常复杂的工作。只有少量 GPU 机器时，个人数据科学家或计算工程师可以独立操作和维护。然而，随着 GPU 数量增长到数十台甚至数百台，形成大规模 GPU 集群时，环境一致性、版本依赖性、配置多样性、效率提升以及运维生命周期复杂度等问题将变得尤为突出。许多算法工程师不得不花费大量时间和精力解决 GPU 集群管理和资源分配等基础问题，从而拖延真正用于深度学习模型开发和训练的工作。另一方面，即使解决了 GPU 管理问题，AI 工程效率仍然受到生命周期复杂性的限制。整个流程，从开发环境搭建、数据准备到模型开发、模型训练、优化、可视化控制、错误处理等，直到模型推理上线和运维，每一个环节都可能导致 AI 模型的开发周期延长且效率低下。而且这些环节大多需要手动操作或使用各种脚本串联，开发效率较低，协同难度大。因此，提高 AI 的工程效率是另一个亟待解决的问题。智算时代，基于 ACK 落地云原生 AI69大模型对基础设施带来更多挑战 算力：千卡GPU任务，万卡集群 数据：PB级存储，TB级吞吐 网络：800Gbps3.2Tbps RDMA 训练：分布式，混合并行 推理：模型优化、服务QoS 工程效率：持续快速迭代 资源效率：高利用率、可扩展GPT3：175B参数，单次训练使用45TB数据，近千卡A100/1个月，成本数百万美元。效率规模性能 大模型对基础设施服务能力的挑战是阶跃式的。对“规模、性能、效率”的要求，成为LLM/AIGC快速落地的高门槛。当面对 LLM 和 AIGC 等新领域，AI 对基础设施服务能力提出了更多挑战。主要体现在规模、性能和效率三个方面。在规模上，要训练出具有广泛知识和专业领域理解及推理能力的大语言模型，往往需要高达万卡级别的 GPU 集群和 PB 级的数据存储以及 TB 级的数据吞吐。此外，高性能网络也将达到单机 800Gbps 甚至 3.2Tbps 的 RDMA 互联。在性能方面，随着模型体积和参数量的增长，单张显卡已无法承载完整的模型。因此需要使用多张显卡进行分布式训练，并采用各种混合并行策略进行加速。这些策略包括数据并行、模型并行、流水线并行以及针对语言模型的序列并行等，以及各种复杂的组合策略。在推理阶段，模型需要提供高效且稳定的推理服务，这需要不断优化其性能，并确保服务质量（QoS）得到保证。在此基础上，最重要的目标是提高资源效率和工程效率。一方面，持续提高资源利用效率，并通过弹性扩展资源规模，以应对突发的计算需求。另一方面，要最优化算法人员的工作效率，提高模型迭代速度和质量。因此，资源效率和工程效率成为了最优先考虑的优化目标。智算时代，基于 ACK 落地云原生 AI70更弹性的算力需求更高的稳定性要求更快的创新和迭代交付 Gartner 预测：到2023 年 70%的 AI 应用是基于容器和 Serverless 技术开发。IDC预测：By 2025,Nearly 50%of All Accelerated Infrastructure for Performance-Intensive Computing(AI,HPC,and Big Data Analytics)will Be Cloud Based as These Systems Are Increasingly Integrated with Enterprise Software.从无状态应用，到企业核心应用，到AI/大数据应用基于容器的AI/大数据成为云原生时代的技术趋势AI工程化向云原生架构演进资源管理分散生产流程割裂、效率低团队协作、共享困难传统架构资源池化：弹性、灵活生产流程高效闭环多角色协同，加速迭代云原生架构随着云原生技术和架构发展，我们明显观察到 IT 架构的变化。传统的企业级应用、Web 应用、微服务等领域都在从传统架构转向云原生架构。互联网应用大多是基于容器、Kubernetes，Prometheus 等云原生技术实现的，追求弹性、灵活性以及最佳性价比。同时，通过标准化交付，提升生产流程的高效闭环。在标准 API 和标准架构的指导下，进一步提高多角色之间的协作和迭代效率。同样地，为了获得更多弹性算力供给、更高稳定性保证以及更快的交付，越来越多 AI 和大数据工作负载也运行在云原生架构上。右图清晰地显示了这一趋势：最早是从可水平扩展的无状态应用程序（如 Web 应用、移动后端应用）开始；然后是 NoSQL 数据库、关系数据库、TensorFlow、PyTorch、Spark、Flink 等大数据和典型机器学习的 AI 计算任务。都能够在 Kubernetes 容器集群上大规模运行。三方研究机构的预测，显示出同样的趋势。早在 2019 年，Gartner 就曾预测，到 2023 年，70%的人工智能应用程序将基于云原生等技术进行开发。IDC 的研究则预测，到 2025 年，智算时代，基于 ACK 落地云原生 AI71接近 50%的企业内部的数据密集型或性能密集型计算工作负载都将迁移到基于云的架构上，而基于云的架构正是典型的 Cloud Native 云原生架构。AI等异构工作负载异构资源CPUGPUFPGARDMAVPCOSS统一管理算法和场景框架NPU统一工作流，统一调度NAS充分利用云的资源弹性、异构算力、便捷服务以及容器、自动化、微服务化等云原生技术手段，为AI/ML 提供工程效率高、成本低、可扩展、可复制的端到端解决方案。云原生AI云原生AI的核心场景统一任务流程提升AI工程效率统一任务调度保障规模与性能统一资源管理持续优化利用率此前概述了传统的机器学习、深度学习以及目前流行的 LLM 和 AIGC，带来了一些技术上的挑战，和对基础设施造成的压力。为了应对这些挑战，我们期待借助云原生 AI 来找到解决方案。那么，什么是云原生 AI 呢？云原生 AI 是指利用云计算的弹性资源、异构算力以及容器、自动化、微服务等云原生技术，提升 AI/ML 的工程效率，降低整体成本，提高可扩展性，并实现端到端的解决方案。在这其中，我们尤为注重工程效率、成本效益、可扩展性和可复制性等因素。云原生 AI 最核心的两个应用场景：统一管理异构资源，提升资源利用率。对 IaaS 云服务或者客户 IDC 内各种异构的计算（如 CPU，GPU，NPU，VPU，FPGA，ASIC）、存储（OSS，NAS，CPFS，HDFS）、网络（TCP，RDMA）资源进行抽象，统智算时代，基于 ACK 落地云原生 AI72一管理、运维和分配，通过弹性和软硬协同优化，持续提升资源利用率。通过统一工作流和调度，实现 AI、大数据等多类复杂任务的高效管理。兼容 Tensorflow，Pytorch，Horovod，ONNX，Spark，Flink 等主流或者用户自有的各种计算引擎和运行时，统一运行各类异构工作负载流程，统一管理作业生命周期，统一调度任务工作流，保证任务规模和性能。一方面不断提升运行任务的性价比，另一方面持续改善开发运维体验和工程效率。围绕这两个核心场景，可以扩展出更多用户定制化场景，比如构建符合用户使用习惯的MLOps 流程；或者针对 CV 类（Computer Vision,计算机视觉）AI 服务特点，混合调度 CPU，GPU，VPU（Video Process Unit）支持不同阶段的数据处理流水线；还可以针对大模型预训练和微调场景，扩展支持更高阶的分布式训练框架，配合任务和数据调度策略，以及弹性、容错方案，优化大模型训练任务成本和成功率AI模型生产流水线端到端的AI生产生过程（模型开发-训练-推理）支持TensorFlow,Pytorch,Deepspeed,Horovod,TensorRT,Spark，Flink等开源框架任务级调度策略（Gang,Binpack,Capacity,优先级队列等）1分钟开启执行深度学习任务数据集、模型管理和访问加速标准API和开放架构，便于业务应用集成高效迭代的模型训练和推理发布流水线弹性伸缩训练任务和推理服务，优化资源TCO异构资源管理一键部署CPU/GPU/vGPU/NPU/RDMA集群，统一运维多维度GPU监控、健康检查、告警和自愈自动挂载存储，加速数据访问自动弹性伸缩灵活配置多种GPU调度策略（共享 隔离、优先级、拓扑感知）CPU和加速设备解耦，异构资源池化，资源使用Serverless化资源效率最大化工程效率最大化支持AIGC/LLM等新范式快速迭代持续完善的MLOps，LLMOps，Prompt工程，数据管理等生产流程支持RAG（Retrieval Augmented Generation）架构快速适配各类开源模型的训练（Pretrain，SFT，RLHF，Prompt tuning等），推理和性能优化更高效的资源调度和数据服务，支撑更大规模的模型训练和推理支持Langchain，Langsmith，AI agent等新的AI 应用开发架构支持多环境，多架构下模型适配和优化创新速度最大化可集成各类模型优化方案云原生AI的主要能力智算时代，基于 ACK 落地云原生 AI73接下来探讨支持这些场景，云原生 AI 所需的主要功能。首先，从异构资源管理的角度，需要一键部署和运行的能力，能够统一管理和操作各种类型的异构资源，如 CPU、GPU 以及各种虚拟化的设备和专业存储、网络设备。在运维过程中，需要多维度的异构资源可观测性，包括监控、健康检查、告警、自愈等自动化运维能力。对于“宝贵”的计算资源，如 GPU 和 NPU 等加速器，需要通过各种调度、隔离和共享的方法，最大限度地提高其利用率。在存储和网络方面，通过统一接口和方式供给上层工作负载。在此过程中，我们还将利用云资源的弹性特征，持续提高资源的交付和使用效率。另一个主要能力是能够在分钟级内准备好开发环境和集群测试环境，帮助算法工程师开始执行深度学习任务。把端到端的 AI 生产过程通过相同的编程模型、运维方式进行交付。在整个流水线执行过程中，天然支持主流计算框架，如 TensorFlow、PyTorch、Deepspeed等。对于大规模分布式 AI 任务，提供丰富的任务调度策略，如 Gang scheduling、Capacityscheduling、Topology aware scheduling、优先级队列等。并使用工作流或数据流的方式串联起整个任务流水线。此外，在计算框架与算法层面适配资源弹性能力，提供弹性训练和弹性推理服务，优化任务整体运行成本。除了计算任务优化，还应关注数据使用效率的优化。为此，需要统一的数据集管理、模型管理和访问性能优化等功能，并通过标准 API 和开放式架构使其易于被业务应用程序集成。随着 AI 和 LLM 的不断发展，我们还将面临一些新的挑战和需求。例如，如何快速适应新的开源大模型训练方法（无论是预训练、监督微调还是强化学习），以及如何提高大模型推理性能并确保其质量和稳定性。同时，也需要关注一些前沿技术和创新能力，通过标准化和可编程的方式来集成，不断迭代业务应用，形成 AI 或 LLM 的新应用开发模式和编程模型。智算时代，基于 ACK 落地云原生 AI74例如 AutoGPT、多智能体任务等，这些都是我们需要快速掌握、理解，并应用于应用智能化升级的重要工具。3.云原生 AI 支持大模型生产的关键技术参考实现-阿里云ACK云原生AI套件云原生AI系统架构基础资源层ACK云原生AI套件云原生AI基础设施层AI任务调度增强任务队列GPU共享GPU/RDMA拓扑感知调度GangCapacityKube-queue数据加速FluidAI作业管理弹性训练ElasticTrainingJ ob机器学习平台PAIAI平台/服务Serverless推理Kserve/Triton灵骏集群CPU(x86/arn)OSS/CPFSVPC/RDMA灵骏智能妙鸭通义大模型开源AI能力阿里云提供和支撑的 AI 平台与服务模型加载加速DatasetProcessKubeflowArenaPipelineMLFlowTGIFasterTransformerDeepspeedJ obDeepspeed-Chat任任务务调调度度和和队队列列数数据据&模模型型访访问问加加速速模模型型&Prompt 管管理理大大模模型型训训练练推推理理框框架架支支持持开开源源大大模模型型验验证证云原生AI系统分层架构生态集成云IDC容器平台异构资源管理高性能计算、存储、网络AI任务调度和流水线AI作业生命周期管理AI任务性能优化弹性运维安全工具链、APIAI框架和运行时数据管理模型管理大数据集成SparkRayGPU/NPUQwenBaichuanChatGLMLlamaBloomFalconStableDiffusion高高性性能能智智算算集集群群前述详细分析了云原生 AI 领域的发展历程、现状以及未来趋势，帮助大家更好地理解这一交叉技术领域。后续我们将转向更为具体的技术层面，介绍已经落地并相对成熟的一些云原生 AI 关键技术。首先，介绍整个云原生 AI 的系统架构，这是一个典型的分层架构。最底层是云资源服务或数据中心的线下资源，由容器服务平台进行统一的封装和管理。在这一层之上，又分为几个层面来构建云原生 AI 系统。第一层是高异构资源管理层，包括对 AI 计算、存储和网络资源的统一管理和运维。第二、三层负责 AI 任务的调度和流水线的构建，支持各种计算框架和训练、推理运行时。智算时代，基于 ACK 落地云原生 AI75第四、五层是任务性能优化和 AI 作业生命周期管理。最后一层是通过统一的工具链和标准 API 向上提供所有这些能力，并与内外部生态集成，包括开源模型、数据，私有业务系统或服务，以及第三方生态系统。在整个系统中，弹性、运维和安全贯穿于各个层面。此外，我们还注重数据、模型和实验等各种制品的统一管理，以及安全性和隐私性的保障。在阿里云的容器服务（ACK）之上，我们提供了云原生 AI 套件的产品，以此作为上述系统架构的一种参考实现。帮助大家更容易理解云原生 AI 系统分层架构的构建方式以及每层的关键技术点。右图展示了基于 ACK 的云原生 AI 套件产品的系统架构。每个方块代表一层的关键技术组件，整个架构是可以组件化拼装、交付和扩展的。用户可以通过组件插拔组合的方式来定制自己的云原生 AI 平台。1.统一管理异构资源集群节点视角监控指标：GPU duty cycleGPU memory usageGPU TemperaturePower usageTotal/allocated GPU应用视角监控指标：GPU duty cycleGPU memory usageAllocated GPU应用实例伸缩资源节点伸缩GPU多维度监控，使用和健康状况一目了然内置NPD，自动检测和告警设备异常自动弹性伸缩，自定义伸缩指标和策略支持GPU竞价实例，ECI弹性容器实例将RDMA网络资源作为K8s集群资源调度和管理支持Nvidia NCCL，GPUDirect over RDMA，加速分布式AI训练KubeletRDMADevice PluginTerwayCNIeth0RDMA SwitchVSwitchgpu0RDMA NIC(HCA)Podmlx5_0eth0gpu0gpu0NCCLWorker NodeWorker NodeRDMA NIC(HCA)PodPodmlx5_0mlx5_0eth0eth0gpu0gpu0100/200GbpsGPUOps云原生AI关键技术KubernetesECSSpot InstanceGPUEBM(Bare metal)Virtual NodeHPAPodPodPodPodPodVPACron HPAPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodPodECIECIECIECI智算时代，基于 ACK 落地云原生 AI76KubeletGPUShareDevice PluginTerwayCNIPod0Pod1Pod3Pod4gpu0gpu0gpu1gpu1gpu0Worker Nodegpu0gpu1gpu2gpu3gpu0Pod2gpu0NvidiaContainer RuntimeGPUShare Scheduler自动发现多GPU卡/服务器/机架之间的通信链路，包括Nvidia P2P/NVLink，PCI-e，RDMA调度器自动选择最大带宽的通信链路，实现分布式训练加速支持Gang/Binpack分配策略，最大化利用率，同时避免资源碎片GPU Sharing&IsolationGPU&RDMA Topology aware云原生AI关键技术2.持续提升GPU利用率业界首款K8s GPU共享调度方案，应用代码零侵入支持所有Nvidia GPU型号的自定义显存、算力共享，结合cGPU技术支持显存，算力和错误隔离，同时避免虚拟化开销GPU利用率提升100%以上https:/ GPU、NPU）进行统一运维、多维度监控和健康检查，并具备自动异常发现和告警功能。此外，还需要追求性价比、弹性交付能力和自动弹性伸缩能力，充分利用云计算的价格优势和技术优势。其次，使用阿里云提供的竞价实例、按需服务等弹性资源，以降低成本并提高性价比。在高性能网络方面，采用 KBS 集群统一调度和管理 RDMA 和 GPU 等高性能设备，进行资源抽象与运维屏蔽，实现网络与计算的高效协同工作。再次，我们需要对 Nvidia GPU 进行全方位精细化支持，包括对 NVIDIA Direct 和 NCCL的支持，以及针对多 GPU 设备场景的网络拓扑感知调度策略，优化通信效率，加速分布式训练。在 GPU 资源利用率优化方面，提供 GPU 共享调度方案，使得多个容器可以在同一张 GPU卡上共享显存和算力，显著提升 GPU 利用率。同时，我们还将结合 阿里云 cGPU 技术实现轻量级设备资源隔离化，确保显存、算力和错误隔离，并最大限度地节省虚拟化开销。智算时代，基于 ACK 落地云原生 AI77通过以上关键技术点提供坚实的基础支撑，不断优化高性能资源的成本效益，最终提升整体训练效率。ACK SchedulerBatch Scheduler pluginsK8s scheduler frameworkAPIServerpodpodpodpodpodGPUNPURDMAFPGApodpodASICJ obApplicationKube-Queue支持10多种任务调度策略插图加边框防止大作业挤占小作业防止资源浪费和死锁2 GPU1 GPU1 GPU2 GPU2 GPU2 GPU1 GPU1 GPU1 GPU1 GPU2 GPU2 GPU防止小作业饿死大作业有效避免资源碎片提升GPU资源利用率资源定向分配给特定任务任务原地升级，资源保持提升调度结果确定性assumePodPodPodPodPodPodPodassumebindloopbindnodesScheduledassumed PodPodqueuemin=3,replicas=4J obmin=3,replicas=4Permitted J ob SchedulingMin:GPU 100Max:GPU 100rootroot.aroot.broot.croot.b.1root.b.2root.c.1Min:GPU 20Max:GPU 40Min:GPU 50Max:GPU 80Min:GPU 30Max:GPU 50Min:GPU 30Max:GPU 50Min:GPU 20Max:GPU 40Min:GPU 30Max:GPU 50Namespace1Namespace2Namespace3Namespace4Namespace5Namespace6多租户配额动态借、还。有效利用集群资源多级结构，灵活对应企业组织架构完全兼容Yarn设计提升资源利用率多租户配额定向资源调度Kube-QueueKube-Scheduler云原生AI关键技术3.高效调度AI任务https:/ Queue,Fair,Topology等复杂场景，扩展K8s满足大规模AI/大数据/HPC任务调度有效解决资源碎片浪费、作业挤占、租户公平性、动态负载感知、数据亲和性、资源预留等分布式系统资源分配难题与社区共推Batch工作组，定义Batch J ob，Queue等Spec上升到 AI 任务调度层。如果我们理解 AI 或大数据作业的特征，就会发现它们不是简单、独立的多副本组合，而是相互依赖、有拓扑关联的批量任务。然而，Kubernetes 原生调度器支持批量任务的能力相对缺乏，例如复杂的任务调度与抢占、资源额度分配、优先级管理和调度性能优化。Kubernetes 调度器框架已经发展成一个可插拔式的体系结构，允许我们通过 Plug-ins 进行扩展，以实现更复杂的任务级调度能力。ACK 团队已经在 Kubernetes 调度器中贡献了多个 Plug-ins，如 gang scheduling、弹性容量调度、优先级队列、公平调度、拓扑感知调度等，以最大化满足复杂的训练或推理任务的整体调度效率和成功率。这些调度能力可以有效解决复杂任务编排和不合理的资源分配导致的资源浪费，以及不同租户作业之间的资源争抢等问题。此外，我们也扩展了数据亲和性的调度策略，让数据与计算更加紧密耦合，减少数据传输的带宽压力和延迟。阿里云还在 Kubernetes 社区推动成立 Batch Job 工作组，致力于制定标准规范，定义标智算时代，基于 ACK 落地云原生 AI78准 API，以便能够高效结合这些复杂的任务管理和调度功能。同时，我们将一些主要的批量调度或任务级别调度策略插件贡献给上游开源社区，并已被众多社区用户使用。例如Open AI 在其高达 7500 节点的模型训练集群中使用了 Co-scheduling 调度功能。总的来说，在调度方面，仍有许多更复杂、更高级的功能需要继续加强，如租户间的公平性、虚拟配额管理、任务级抢占等。这些能力将通过 ACK 云原生 AI 套件持续提供给用户和社区。云原生AI关键技术4.弹性伸缩分布式AI训练自动发现、适配训练节点数变化，触发计算和通信链路调整支持手动/自动扩、缩容训练任务，支持容错支持竞价实例，便于GPU利旧，大幅节省AI训练成本提升集群利用率，减小节点故障影响，显著减少作业启动等待时间支持CV/NLP/推荐类模型，兼容Horovod Elastic API,Elastic Torch，Tensorflow，DLRover等框架ETOperatorhttps:/ K8S 任务管理和调度、Pytorch、Horovod 等计算框架，实现对常见的 CV模型、NLP 模型和推荐类模型的支持，使训练任务可以使用从几张 GPU 卡动态扩展到几十张、上百张 GPU 卡，同时也可以反向缩容。确保任务在整个过程中不中断，并保持收敛性智算时代，基于 ACK 落地云原生 AI79能。弹性训练的收益会相对明显，尤其是在使用竞价实例的场景下。虽然竞价实例的优势在于可以用较低的价格获取 GPU 或其他高性能计算资源，但也存在每小时就会回收的风险。如果运行中的任务无法在此时间段内结束，则可能会面临缩容问题。我们可以结合弹性训练和弹性推理等能力，充分利用像 spot instance 和 ECI 这样的高性价比资源。同时，由于大模型训练任务（如 175B 参数级别的 GPT3）需要近千张 GPU 卡并训练近一个月的时间。任何一张 GPU 卡都可能出现故障，这会导致任务失败，造成极大的损失和资源浪费。可以结合弹性训练的能力，构建容错场景，即使部分资源失效或计算任务出错，整体任务仍然可以通过缩容形式继续进行训练，以最大化容错。并确保计算资源的投入和计算过程都不会被浪费。这是一种非常有趣且富有挑战的技术问题，即如何利用云的弹性资源来适应算法和计算过程的弹性伸缩。PodNASCSIPodOSSCSINode2Node1HDFSOSSDatasetPodPodPodVPC分布式缓存 混合云 多数据源加速 版本 ACLK8s的存储视角Fluid的数据使用视角IDC/8630.5616556.227529.7322159248.6421422.340817.258200.030000400005000060000700008 GPUs32 GPUs64 GPUs128 GPUsimages/secondFluid vs OSSFS(20Gb/s)ossfs(cache on)Fluid128GPU50%云原生AI关键技术5.1 Fluid弹性数据集编排与加速训练Fluid Dataset管理计算任务使用数据的生命周期，使不同存储源的数据在K8s中可管理、可加速、可编排调度。克服存算分离架构带来的数据访问延迟显著加速AI等数据密集计算30%以上，减小远程I/O带宽压力适配公有云、私有云、混合云，多存储类型，多数据源统一管理缓存数据访问控制、数据感知调度、缓存自动弹性伸缩CNCF Sandbox项目 https:/ ACK 落地云原生 AI80我们之前提到了任务调度和如何更好地使用弹性资源。其中，计算效率最大化和减少数据读取的时间是非常关键的问题。云计算中，存储和计算分离是一种常见架构，它可以提供更大的灵活性，但也带来了远程访问延迟和带宽限制的问题。为了解决这些问题，我们通过开源项目 Fluid，结合分布式缓存技术，将数据缓存能力内置到数据集对象中，并将其作为有生命周期的对象进行管理。这样，数据集可以根据应用程序的需求进行缓存数据的亲和性调度，最大程度地减少远程数据访问延迟。还能够在自定义监控的情况下，进行缓存数据的自动弹性伸缩，缓解高并发计算任务访问远程存储的聚合带宽压力。Fluid 弹性数据集编排和加速项目已经在 ACK 云原生 AI 套件中有相应的产品实现，一些功能子集也已开源至 CNCF 社区，目前正在积极向孵化阶段推进。通过分布式缓存加速技术，我们可以显著提高分布式训练的效率，如右下角所示的ResNet-50 训练效果示例。当我们不断增加 GPU 卡的数量时，如果不使用缓存加速，性能加速比并趋于平坦（蓝色线条），不会得到很好的提升。而通过 Fliud 的弹性分布式缓存加速后，随着 GPU 资源的增加，训练性能加速比基本保持线性增长（绿色线条），大幅度地提高了 GPU 计算效率。云原生AI关键技术270.9388.889.1112.841.456.40500300350400450Llama-30BFalcon-40BLLM模型加载耗时对比（单位：秒）OSSFluid缓存Fluid缓存 客户端优化HuggingFace TGI Server/Stable Diffusion/Model Serving Programon GPUModelShardFileShardFileShardFileShardFileShardFileDistributed CacheModel StorageFluid SDKCache preloadedPageCache1.自动缓存模型到本地1.模型缓存预热2.并发预热模型到page cache3.推理框架并发加载模型到GPU-67%-85%-71%-86%云原生AI关键技术5.2 Fluid加速大模型推理服务启动AI推理服务启动时延受限于模型数据拉取网络带宽，耗时较长频繁发布、更新模型版本和推理服务扩容，冷启动会造成LLM服务质量波动，导致业务受损。智算时代，基于 ACK 落地云原生 AI81我们不仅将 Fluid 弹性数据集加速的能力应用于分布式训练场景，也可以将其应用大模型的推理服务。在大模型推理服务中存在一个问题，即随着模型体积的增长（现在模型常常达到几 GB 或几十 GB），首次创建，或在运行过程中动态扩容这样的模型服务的冷启动延迟问题会变得非常严重。这是因为我们需要从远程对象存储或 HDFS 中拉取大模型参数，而这种操作往往具有较高的延迟。我们测试过，在一个 165GB 的大模型情况下，拉取所有参数可能需要近一个小时的时间，这在生产环境中是无法接受的，因为它不能提供在线服务。为了解决这个问题，我们为 Fluid 缓存加速功能扩展了数据预取、并发加载、Pagecahce预热等优化手段，并应用到模型服务冷启动的优化中。结果表明，对于 Llama 30B 等流行的大模型，可以实现 70%至 80%，甚至更高的加速启动效果。Arena CLI,Web console,SDKTensorflow,PyTorch,Horovod,DeepSpeed,MPI，PAI,AIACCCPU/GPU/NPUVPC/RDMAHadoop/OSS/CPFSFlink,SparkArenaOperatorsKServePipeline#提交分布式训练任务arena submit mpijob-name=tf-dist-data-workers=6-gpus=2-data=tfdata:/data_dir rdma-gang-env=num_batch=100-env=batch_size=80-tensorboard-image=ali-tensorflow:gpu-tf-1.6.0/root/hvd-distribute.sh 12 2”训练评估推理数据开发云原生AI关键技术6.1 AI任务全生命周期管理Arena覆盖AI任务全生命周期 数据管理，任务管理，模型开发，分布式训练、评估，压测，推理屏蔽所有资源、K8s集群、运行环境管理、任务调度、GPU分配和监控等底层复杂性兼容多种计算框架 J upyter，Tensorflow,Pytorch,MPI,Hovorod,DeepSpeed,Megatron-LM，Spark等提供CLI，go/java/python SDK和WebUI控制台，统一接口，三端互通Arenahttps:/ ACK 落地云原生 AI82Model v1Submit training job1.arena submitKubernetes for trainingKubeFlow(TF,MPI Operator)1.Deploy job2.Lifecycle mgmt/job:ps/task:0/job:ps/task:0/job:worker/task:1/job:worker/task:0(chief)/job:worker/task:2Continuous TrainingModel v2Model v3ExportData ScientistUpdating model for inferenceModel RepositoryOperatorMulti-version models2.arena serve tensorflowUpdate routing rulesIstioDynamic routing mgmtA/B TestKubernetes for serving90%Current version v17%New version v23%New version v3RESTAPI or gRPCApplications3.arena serve traffic-router-split云原生AI关键技术6.2 Arena支持从数据管理，到模型开发-训练-推理的全生命周期AI任务管理ACK 云原生 AI 套件提供的所有组件都以 Kubernetes 标准接口（CRD）和 API 形式，交付给 AI 平台开发运维人员调用。这对基于 Kubernetes 构建云原生 AI 平台来说是非常方便和易用的。但对于数据科学家和算法工程师开发训练 AI 模型来说，Kubernetes 的语法和操作却是一种“负担”。他们更习惯在 Jupyter Notebook 等 IDE 中调试代码，使用命令行或者Web 界面提交、管理训练任务。任务运行时的日志、监控、存储接入、GPU 资源分配和集群维护，最好都是内置的能力，使用工具就可以简单操作。为此，我们创建了一款名为 Arena 的工具，来屏蔽底层资源、Kubernetes、运行环境等各种复杂度的能力，以统一的方式来管理系统、任务、模型开发、分布式训练、模型评估推理、循环迭代等全生命周期。它可以自动化处理复杂的任务，包括调度、Kubernetes 管理和实时监控。此外，Arena 还支持 Go、Java 和 Python SDK，支持二次开发和封装。我们还为运维人员和开发者提供了可视化的控制台，使他们在不同终端上都能实现统一的任务管理。只需使用 Arena 的一条命令，就可以将分布式的任务提交到 Kubernetes 集群中，自动运行，并保存训练结果。另一条命令则可以用于创建模型推理服务，也包括发布、A/B 测试、流量管理等运维操作。智算时代，基于 ACK 落地云原生 AI83arena submit pytorchjob-label cd/ChatGLM-6B/ptuning&bash train.sh/models/thudm-chatglm2-6barena serve custom-name=bloom-tgi-inference-gpus=2-version=alpha-replicas=1-restful-port=8080-image=xxx-text-generation-inference:0.8 text-generation-launcher-disable-custom-kernels-model-id bigscience/bloom-560m-num-shard 2-p 8080云原生AI关键技术6.3 Arena支持主流开源LLM/AIGC模型的预训练、微调、推理适配各种流行的AI框架按需自由选择在固定GPU集群，或者弹性GPU资源上进行训练LLM/AIGC目前我们也为 Arena 扩展了对大模型的支持，兼容了主流的 LLM/AIGC 模型和训练、推理框架。例如，用户可以通过两条命令快速训练和推理 ChatGLM，Llama，Bloom，Baichuan，Qwen 等模型。4.ACK 云原生 AI 套件工程实践提升1 00%GPU利用率提升30%数据访问效率提升20%AI训练速度用户自建 AI 平台阿里云 AI 服务开源 AI 框架与模型三方 AI 优化方案仓库AI 容器镜像模型实验CPU GPU vGPU NPUOSS CPFS HDFS运维流水线弹性伸缩监控故障诊断公共云专有云混合云边缘容器服务（ACK/ACKServerless/ACKEdge/ACK灵骏）AI工程管理命令行工具/SDK开发/运维控制台MLOps/LLMOps数据接入模型开发模型训练模型推理RDMA算法工程师数据科学家AI平台运维人员K8s运维人员IaaS运维人员AI数据加速数据集管理数据访问加速数据集编排AI任务管理任务提交运行任务调度任务弹性异构算力管理资源管理运维资源弹性伸缩资源调度与共享云原生AI套件成本分析多租户云原生AI套件产品形态基于标准Kubernetes，提供组件化能力，全栈优化AI生产系统的性能、效率和成本。智算时代，基于 ACK 落地云原生 AI84前述所有这些关键技术，我们需要考虑如何将它们应用起来，怎样将它们快速应用于用户的生产环境中，以启动用户的第一个 AI 训练和推理任务。为此，在阿里云的容器服务（ACK）上，我们提供“云原生 AI 套件”，旨在将上述所有技术及架构在一个完整的产品中提供给我们的客户和合作伙伴。云原生 AI 套件完全遵循之前介绍的分层参考架构进行实现和交付。用户可以根据自己的需求，在其中选择所需的组件。例如，如果用户对 GPU 管理有特殊要求，则可以利用异构算力中的调度、共享、隔离等能力。如果对任务管理有很多需求，可以利用我们的高级调度策略。如果您需要一个方便快捷的 AI 生产流程管线管理工具，那么 Arena 等套件的能力也可以迅速为您提供帮助。借助这些功能，可以帮助用户实现 AI 训练速度提高 20以上，数据访问效率提高 30以上，而 GPU 利用率则可提高 100以上。Soul 是任意门旗下基于兴趣图谱和游戏化玩法的社交 APP，属于新一代年轻人的虚拟社交网络。基于用户的社交画像和兴趣图谱，通过机器学习来推荐用户可能会产生的高质量的新关系，有丰富的AI业务场景，包括语音匹配、聊天机器人、文本 OCR 识别、图像识别、多模态等。AI 机器学习是公司核心业务，但在传统的虚拟机构建部署方式下，缺乏一个统一的管控平台，导致业务工作流不流畅，开发迭代效率低下，运维管理复杂且资源利用率低下，具体表现为：业务迭代速度慢：研发工程师需要花费大量时间在底层基础设施资源准备、业务集成部署、日志监控等 AI 工程化上，无法专注于业务开发，难以快速响应业务研发需求。运维工作重复：日常需要处理安装 Nvidia GPU 驱动、CUDA 版本、OSS 数据源等环境问题，人力投入大，运维效率低。资源性价比低：CPU 机器处理速度慢，大量堆积机器，导致资源闲置浪费。GPU 机器虽效率高，但现有技术无法提升利用率，资源空置。客户痛点任意门在阿里云上，通过容器服务ACK 云原生 AI 套件，构建了符合开源标准、自主掌控的 AI PaaS 平台，实现了以下特点：全生命周期管理的一站式平台提升迭代效率：提升迭代效率，包括数据管理、AI 任务发布和模型评测等，开发迭代效率提升25 倍。统一的异构资源管理和运维平台降低运维成本：降低运维成本，自动化管理 GPU 节点、算法代码与标准镜像解耦以及自动弹性推理，节省 1 倍运维成本。效率及资源利用率提升：提供专业的 GPU 共享及Fluid 数据加速能力，同时提升业务效能，成本节约 50%。方案亮点任意门 Soul 通过先进的算法驱动和数据分析技术，打造了“平行宇宙”中独立的、沉浸式社区。作为下一代基于人工智能的移动社交网络平台，任意门 Soul 是中国社交 4.0 时代的领军者。其 AI PaaS 平台管理了从初期的数十张 GPU 卡到近千张的超大规模，日承载 AI 业务发布数百次，很好地支撑了业务的高速发展。建设成果相关产品：l 容器服务ACK任意门：基于ACK云原生AI套件打造智能化社交平台l 云原生AI套件ACK 的云原生 AI 套件能够带来什么效果？智算时代，基于 ACK 落地云原生 AI85这里有两个案例来说明。首先，任意门是一个需要大量用户多模态数据进行人工智能驱动的社交平台。客户需要一个能够充分利用云计算弹性资源并具有快速迭代和扩展能力的 AI 平台。借助 ACK 的云原生 AI 套件，任意门构建了一个定制化的基于容器的 AI 平台。现在，该平台已经承载了客户的语音合成、人脸匹配、图像识别和智能聊天等业务场景。支撑 CloudML的自建集群由于资源池容量、资源弹性能力相对有限，导致业务低谷时资源闲置成本高，业务高峰时资源紧张。迁移到基于 Serverless 容器架构的混合云之后，获得了 Serverless 容器带来的敏捷、安全、弹性、低成本等优势，然而也遇到了几个重要的技术挑战：无法定制扩展存储类型：公有云集群只支持阿里云存储类型（如 NAS、OSS等），无法直接适配内部自研的分布式文件存储（StarFS）。缺乏可信透明的数据接入方式：如何在 Serverless 容器的黑盒系统使用过程中规避数据泄露，如何确保数据存储、传输、访问过程中安全可靠，缺乏对应的解决方案。基础设施差异导致用户体验不一致：混合云场景中，当用户任务在公有云和自建集群之间进行迁移时，用户使用体验需要与自建集群上保持一致，不需要做过多的变更。客户痛点阿里云 ACK 云原生 AI 套件中提供的 ack-fluid 存储系统接入方案可以很好的解决以上问题：公共云集群定制扩展自建存储：ack-fluid 基于开源 Fluid 标准对于 ThinRuntime 提供了完整的支持，只要满足开源要求就可以适配 ack-fluid。StarFS 接入只需在开源 Fluid 下即可完成调试，同时借助ACK One 注册集群模式可获得阿里云商业版 Fluid 全部功能。阿里云 ECI 访问云下自建存储：ack-fluid 与阿里云的 ECI 做了无缝支持，无需开启 privileged 权限，就可以满足云上弹性容器实例 ECI 访问云下自建存储系统的需求。用户无需感知基础设施的差异：ack-fluid 提供对于 StarFS 自建 pvc 的丝滑兼容，无需了解 Fluid 的使用方式，只需要 pvc 中添加特定 label 即可，满足了 CloudML 用户无需感知基础设施层面的差异的需求。而在开源 Fluid 中这个工作就非常复杂，需要手动创建和管理 Dataset 和 ThinRuntime 的生命周期。方案亮点“混合云场景下 Serverless 容器方案完美落地，很好地满足了我们简单、安全、弹性、低成本等诉求，小米 CloudML 可以稳定高效地响应业务需求。尤其值得一提的是，通过引入阿里云 ACK 云原生 AI 套件的 ack-fluid 很好地解决了相关技术难点：首先，对于自建存储 StarFS 的访问提供了很好的扩展支持，并且得益于 Fluid 提供的数据集可观测性功能，我们能够获取云上工作负载的数据访问特性，从而支持数据热加载和资源分配调优。其次，方案接入简单、管理便捷。我们自行完成 StarFS 与 Kubernetes 环境的对接工作，整个 thinRuntime 开发简单，无需我们具备复杂的 Kubernetes 定制开发知识。基于这套方案，我们只需要了解 Dockerfile 构建就可以完成，开发工作 2-3 小时左右，显著降低了使用 ECI 接入 StarFS 的工作成本。“客户证言相关产品：l 容器服务ACKl分布式云容器平台ACK Onel 弹性容器实例 ECI小米机器学习平台：基于Fluid的Serverless混合云容器AI平台小米机器学习平台（CloudML）承载了图像、NLP、声学、搜索推荐等应用业务，是小米针对机器学习进行全流程优化的高性能、分布式云服务。第二个案例是小米的机器学习平台。客户采用混合云方式，既使用自有 IDC 中的 GPU 资源，又使用阿里云的弹性 GPU 资源，构建 AI 平台。由于跨地域，使得计算存储分离的架构，在数据复制延迟和聚合带宽的问题非常突出。通过使用 Fluid 的分布式缓存加速和数据统一管理方案，解决了线下自建 StarFS存储的标准化接入和管理问题，并增加了分布缓存线下数据能力，以解决数据加载性能问题。帮助小米构建了一个高效混合云架构下的分布式 AI 平台。智算时代，基于 ACK 落地云原生 AI86123管理员创建ACK集群，添加GPU节点管理员一键选择安装ACK云原生AI套件算法工程师向ACK集群提交模型训练任务AI平台运维人员将训练好的模型在ACK集群中发布为线上推理服务4ACK云原生AI套件使用流程如何使用 ACK 的云原生 AI 套件？只需在阿里云创建一个 ACK 集群，无论是否添加 GPU 节点。一键安装即可将整个云原生 AI 套件部署到集群中。用户可以根据需求选择所需组件，以定制自己的基础 AI 平台。在该平台上进行二次开发和扩展后，开发人员可以通过 Arena或 Jupyter Notebook 进行模型开发，并向 GPU 集群提交模型训练任务。同时，AI 平台的运维人员可以通过AI套件中的运维控制台和运维命令进行模型生产和线上推理服务的便捷运维。AI运维控制台集群大盘ACKPytorchTensorflowGPU NodegpugpuPytorchTensorflowGPU NodegpugpuDatasetSchedulingvolumevolumeArenaCLI/SDKSLB负载均衡用户数据集一键加速成本分析作业大盘Scaling用户权限配额管理低延时LB直通pod蓝绿发布、服务化运维算力、数据的弹性、加速GPU大盘AI Infra/平台运维人员数据科学家/算法工程师GPU共享调度AI开发控制台一键发布服务模型评测工作流编排定时服务提交、管理训练任务开发、调试ACK云原生AI套件使用流程两类角色通过命令行工具和控制台简便操作，高效协同智算时代，基于 ACK 落地云原生 AI87AI 平台或 AI Infra 运营人员如何使用 ACK 云原生 AI 套件进行工作的流程：首先，创建ACK 集群，接着配置调度策略、创建训练数据集或模型集，并通过 AI 运维控制台监控集群运行状况、GPU 分配情况和健康状况等。作为开发团队的数据科学家和算法工程师，则通过 Arena 命令行或 SDK 进行模型开发、训练的迭代实验。最后通过评测和压测，选择出符合预期的模型版本，通过 Arena 创建推理服务，将其发布到生产集群中。我们还提供了 AI 开发控制台，以便于不习惯使用命令行或无需二次开发需求的用户，在可视化界面上完成所有开发、训练任务的操作。欢迎扫码入群与我们交流钉钉群：33214567微信云原生AI应用KubernetesArena-AI任务生命周期管理GPU/vGPU,NPUENI/RDMANAS/OSS/CPFSPytorch Tensorflow TritonDeepspeed TGISpark RayAI/大数据任务调度器任务队列异构算力调度/共享拓扑感知Serverless 推理弹性训练数据集加速AI训练速度提升20%数据访问效率提升30%大模型推理启动速度提升80K云原生AI套件助力大模型工程提效ACK 是基于阿里云容器服务托管的 Kubernetes 服务，经过大量国内外客户的验证。ACK在今年首次参加 Gartner 年度容器管理魔力象限评选，并荣幸地进入了领导者象限，是亚洲地区唯一入选该象限的云服务商。在 ACK 平台上，我们提供了稳定高效的托管 Kuberntes 集群，以及云原生 AI 能力、服务网格能力、多集群、多云管理能力、边缘计算能力、专有云和混合云交付能力，以及对大规模计算服务的高效支持。所有这些能力都以标准 Kubernetes API 和架构提供出来。欢迎广大用户和合作伙伴在 ACK 容器服务上，利用云原生 AI 套件快速构建自己的云原生AI 平台。云原生场景下，AIGC 模型服务的工程挑战和应对88云原生场景下，AIGC 模型服务的工程挑战和应对作者：车漾，阿里云高级技术专家“成本”、“性能”和“效率”正在成为影响大模型生产和应用的三个核心因素，也是企业基础设施在面临生产、使用大模型时的全新挑战。AI 领域的快速发展不仅需要算法的突破，也需要工程的创新。1.大模型推理对基础设施带来更多挑战首先，AI 商业化的时代，大模型推理训练会被更加广泛的使用。比较理性的看待大模型的话，一个大模型被训练出来后，无外乎两个结果，第一个就是这个大模型没用，那就没有后续了；另一个结果就是发现这个模型很有用，那么就会全世界的使用，这时候主要的使用都来自于推理，不论是 openAI 还是 midjourney，用户都是在为每一次推理行为付费。随着时间的推移，模型训练和模型推理的使用比重会是三七开，甚至二八开。应该说模型推理会是未来的主要战场。大模型推理是一个巨大的挑战，它的挑战体现在成本、性能和效率。其中成本最重要，因为大模型的成本挑战在于模型规模越来越大，使用的资源越来越多，而模型的运行平台GPU 由于其稀缺性，价格很昂贵，这就导致每次模型推理的成本越来越高。而最终用户只为价值买单，而不会为推理成本买单，因此降低单位推理的成本是基础设施团队的首要任务。在此基础上，性能是核心竞争力，特别是 ToC 领域的大模型，更快的推理和推理效果都是增加用户粘性的关键。应该说大模型的商业化是一个不确定性较高的领域，成本和性能可以保障你始终在牌桌上。效率是能够保障你能在牌桌上赢牌。进一步，效率。模型是需要持续更新，这就模型多久可以更新一次，更新一次要花多久的云原生场景下，AIGC 模型服务的工程挑战和应对89时间。谁的工程效率越高，谁就有机会迭代出有更有价值的模型。近年来，容器和 Kubernetes 已经成为越来越多 AI 应用首选的运行环境和平台。一方面，Kubernetes 帮助用户标准化异构资源和运行时环境、简化运维流程；另一方面，AI 这种重度依赖 GPU 的场景可以利用 K8s 的弹性优势节省资源成本。在 AIGC/大模型的这波浪潮下，以 Kubernetes 上运行 AI 应用将变成一种事实标准。2.AIGC 模型推理服务在云原生场景下的痛点云原生场景下，AIGC 模型服务的工程挑战和应对90在 AIGC 推理场景下有个关键的矛盾，就是计算存储分离的架构导致的数据访问高延迟、带宽受限问题和大模型规模不断增长的矛盾，它会同时影响成本、性能和效率。模型弹性伸缩、按需使用，是控制大模型成本的利器。然而，如上图右所示，以 Bloom-175B模型（FP16 精度模型大小约 340GiB）为例，模型的扩容耗时为 82 分钟，接近 1 个半小时，为了找到问题的根因，需要对模型启动时间进行拆解，其中主要耗时在于 HPA 弹性、创建计算资源、拉取容器镜像，加载模型。可以看到从对象存储加载一个约 340G 的大模型，耗时大约在 71 分钟，占用整体时间的 85%，这个过程中我们其实可以看到 I/O吞吐仅有几百 MB 每秒。要知道在 AWS 上 A100 按量付费的价格每小时 40 美元，而模型启动时刻 GPU 其实是处于空转的时刻，这本身就是成本的浪费。同时这也影响了模型的启动性能和更新频率。那么，我们有办法解决这个问题吗？一个直观的想法是增加一个缓存层，但是真的增加了缓存层就可以了吗？实践中其实并不是这样的，我们会遇到一系列的问题。首先就是快的问题：能否用好缓存，如果加了缓存但是速度依旧不快，那么是缓存的规划云原生场景下，AIGC 模型服务的工程挑战和应对91问题？硬件配置问题？还是软件配置？网络问题？调度问题？其次就是省：关注成本问题，作为缓存的机器通常是高带宽、大内存、本地盘的机器，这些配置的机器往往并不便宜。如何能够实现性能最大化的同时也有合理成本控制。接着就是好：用户使用复杂不？用户代码是否需要相应的修改。运维团队工作量大吗？模型会不断更新和同步，如何降低这个缓存集群的运维成本。简化运维团队的负担。正是在这种对于缓存工程化落地的思考中，诞生了 Fluid 这个项目。3.Fluid 是什么？首先，让我们来了解一下 Fluid 的概念。Fluid 负责在 Kubernetes 中编排数据和使用数据的计算任务，不仅包括空间上的编排，也包括时间上的编排。空间上的编排意味着计算任务会优先调度到有缓存数据和临近缓存的节点上，这样能够提升数据密集型应用的性能。而时间上的编排则允许同时提交数据操作和任务，但在任务执行之前，要进行一些数据迁移和预热操作，以确保任务在无人值守的情况下顺利运行，提升工程效率。云原生场景下，AIGC 模型服务的工程挑战和应对92从 Fluid 的架构图来看，Fluid 向上对接各种 AI/大数据的应用，对下我们可以对接各种异构的存储系统。Fluid 目前支持了包括 Alluxio、JuiceFS 还有阿里内部自研的 JindoFS、EFC 等多种缓存系统。具体来说 Fluid 提供 5 个核心能力：1）首先是数据使用方式和缓存编排的标准化。一方面，针对场景化的数据访问模式进行标准化，比如大语言模型、自动驾驶的仿真数据、图像识别的小文件，都可以抽象出优化的数据访问方式。另一方面，越来越多的分布式缓存出现，比如 JuiceFS，Alluxio，JindoFS，EFC 可以加速不同的存储，但是他们并不是为 Kubernetes 而生。如果在 Kubernetes 上使用它们，需要抽象标准的 API；Fluid 负责将分布式缓存系统转换为具有可管理、可弹性，可观测和自我修复能力的缓存服务，并且暴露 Kubernetes API。2）其次是自动化，以 CRD 的方式提供数据操作、数据预热、数据迁移、缓存扩容等多种操作，方便用户结合到自动化运维体系中。3）加速：通过场景优化的分布式缓存和任务缓存亲和性调度，提升数据处理性能。4）随处运行，与 Kubernetes 运行时平台无关：可以支持原生、边缘、ServerlessKubernetes、Kubernetes 多集群等多样化环境。可以根据环境的差异选择 CSI Plugin 和sidecar 不同模式运行存储的客户端。5）数据和任务编排：最终连点成线，支持定义以数据集为中心自动化操作流程，定义数据迁移、预热、任务的先后执行顺序依赖。4.Fluid 在云原生 AIGC 模型推理场景的优化概述云原生场景下，AIGC 模型服务的工程挑战和应对93那么回到 AIGC 模型推理场景，Fluid 为这个场景带来了许多优化方案。首先，分布式缓存使用的复杂度高和运行环境差异大，AIGC 应用需要适配不同运行时，包括 Alluxio，JuiceFS，JindoFS，而运行时环境包括公共云、私有云、边缘云、Serverless云，Fluid 都可以提供一键部署、无缝衔接的能力。第二，AIGC 模型推理服务本身有很多灵活多变的业务属性，通过 Fluid 提供的弹性缓存帮您实现需要的时候可以弹出来不用的时候缩回去，能很好地在性能和成本间取得利益最大化。第三，Fluid 提供数据感知调度能力，将计算尽量调度到离数据更近的地方。第四，Fluid 的数据流编排能力，帮助用户把很多推理的行为和数据的消费行为自动化起来，减少复杂度。最后，在性能上，我们也提供了适合云原生缓存的读取优化方案，充分利用节点资源。云原生场景下，AIGC 模型服务的工程挑战和应对94这边是一张 Fluid 的技术架构图。图中可以看到，Fluid 提供 Dataset 和 Runtime 这两种 CRD，它们分别代表了需要访问的数据源和对应的缓存系统。比如在这个例子里面我们使用的是 Alluxio 这个缓存系统，所以对应的就是 AlluxioRuntime 的 CRD。Dataset 中描述了你需要访问的模型的数据路径，比如 OSS 存储桶中的一个子目录。创建了 Dataset 和对应的 Runtime 后，Fluid 会自动完成缓存的配置、缓存组件的拉起，并自动创建一个 PVC。而对于想要访问这个模型数据的推理应用来说，只需要挂载这个PVC，就可以从缓存中读取模型数据，这和 K8s 标准的存储方式也是保持一致的。云原生场景下，AIGC 模型服务的工程挑战和应对95AIGC 推理的运行平台非常多样化，包括云服务的 Kubernetes、自建的 Kubernetes、边缘 的Kubernetes 以 及Serverless 形 态 的Kubernetes。Serverless 形 态 的Kubernetes 由于其易用性、低负担的好处，已经越来越多的成为用户的选择；但是Serverless 由于安全的考量，没有开放第三方存储接口，所以只支持自身存储，以阿里云为例子，只有 NAS，OSS，CPFS 有限存储。在 Serverless 容器平台上，Fluid 会将 PVC 自动转换成可以适配底层平台的 sidecar，开放了第三方的配置接口，可以允许并且控制这个 sidecar 容器的生命周期，保证它在应用容器启动前运行，当应用容器结束后自动退出。这样 Fluid 则提供了丰富的可扩展性，可以运行多种分布式缓存引擎。AIGC 模型需要共享还是独占，这不是一个“一刀切”的问题，需要结合真实的业务场景进行选择。有些 IP 保护，核心模型是需要访问隔离，而另一些开源模型则没有这部分的担心。有些模型性能高度敏感，特别一些最流行常用文生图的场景，需要在 20 秒内完成出图，这样 8-10G 的模型加载时间要控制到 5 秒以内。那就需要在缓存侧做吞吐独享、避免竞争、配合特定调优。而对于一些比较新的文生图，用户就需要考虑资源成本。而 Fluid 针对于独占缓存和共享缓存，都提供了完整的支持，通过 Fluid 都可以灵活配置支持。云原生场景下，AIGC 模型服务的工程挑战和应对96Fluid 提供的第二个优化是可弹性伸缩的计算侧分布式缓存。这里讲的是如何提供高性能。为什么需要弹性伸缩的计算侧分布式缓存？只是使用简单的分布式缓存不够吗？我们可以从技术角度来理解这个问题。在实际的生产场景中，AI 模型推理服务实例往往是多个并发启动的，例如：如果你一次性需要拉起 100 个推理服务实例，每个实例都需要从对象存储中拉取数据，那么每个实例能分到的可用带宽仅有总共可用带宽的百分之一。如果是默认 10Gbps 的 OSSBucket 加载30G 的模型，这个预期耗时就会是 2400s，而且是每个实例都是 2400s。事实上，弹性伸缩的计算侧分布式缓存就是把底层存储系统的有限可用带宽转变为了 K8s集群内可以弹性伸缩的可用带宽，这个可用带宽的大小取决于你分布式缓存的节点数量。从这个角度来说，我们就能根据实际业务场景对于 I/O 的变化需求，变为可随时扩容缩容的分布式缓存集群。这里有一些测试数据我们也可以看到，如果 100 个 Pod 并发启动，使用缓存都能获得很好的加速效果，而使用更多的缓存 Worker 节点，效果会更好。主要的原因就来自于更大的聚合带宽，使得每个 Pod 均分得到的带宽更多。从右边这张图也可以看到，当你使用更多的分布式缓存节点的时候，聚合带宽也是近线性地提升的。云原生场景下，AIGC 模型服务的工程挑战和应对97介绍完如何提升性能之后，接下来考虑的问题就是如何在尽可能节省成本的前提下最大化缓存带来的性能提升，如何在成本和性能间取得平衡实质上是与业务场景的 I/O 访问模式相关的。Fluid 在缓存上暴露的可观测性，配合手动扩缩容、HPA、CronHPA 等 K8s 的扩缩容能力，可以根据业务需求弹性扩容、缩容数据缓存。我们可以举几个具体的例子：对于大语言模型场景，大语言模型一个特点是拥有很强的泛化知识，因此把一个 LLM 加载到 GPU 显存后，它其实可以为多种不同的场景提供服务。因此这种业务的数据 I/O 特点是一次性对 I/O 有很高的要求。对应到缓存的弹性上来，就是一个先扩容，推理服务就绪后缩容到 0 的过程。再来看文生图 Stable Diffusion 的场景，假如是一种 SD 模型市场的场景，那就会包含大量不同风格的 SD 模型，因此尤其对于热点模型，会有持续的 I/O 需求，此时保持一定的缓存副本就是更好的选择。而无论哪种场景，如果因为业务洪峰造成服务端需要扩容，数据缓存可以跟随它做临时扩容，缓解扩容时的冷启动问题。云原生场景下，AIGC 模型服务的工程挑战和应对98公共云提供灵活的弹性能力和高可用性，这是通过底层的多可用区实现的，多可用区对于互联网应用非常合适；它牺牲一点点的性能获得了应用稳定性。但是在 AIGC 大模型场景上，通过实际验证，我们发现跨可用区的延时还是有很大的影响，这是因为大模型文件一般比较大，它传的包就会非常多，对延时起到放大的作用。因此缓存和使用缓存应用之间的亲和性就非常重要，Fluid 提供无侵入性的亲和性调度，根据缓存的地理位置调度应用，优先同可用区调度；同时提供了弱亲和性和强亲和性的可配置性，帮助用户灵活使用。云原生场景下，AIGC 模型服务的工程挑战和应对99现在我们理解了弹性的缓存架构的必要性和优势，但实际用起来也许还是会有一些麻烦。让我们试想这么一个流程，今天有个新的 AI 模型推理业务需要发布上线，为了避免服务冷启动，你先需要部署了一个分布式缓存并扩容到了一定的副本数，接下来你把待发布的模型数据预热到分布式缓存中避免 Cache Miss（这个过程可能要花 30min），最后你拉起 100 个服务实例，等到 100 个服务实例启动完成，这个过程又要花费 1020 分钟；最后，确认服务上线没问题后，把缓存缩容掉减少成本。这个过程中的每一步每隔一段时间就需要人工参与，确认状态并执行下一步。数据访问和消费过程运维过程复杂，耗时费力。Fluid 为了解决这个问题，我们把数据消费过程定义为业务使用数据缓存的过程，以及系统准备数据缓存的过程，对于这些流程我们用数据操作抽象以及数据流编排能力去帮助用户自动化。比如最常见的与数据缓存相关的操作，像是数据迁移、预热以及和业务相关的数据处理，Fluid 都提供了 K8s 级别的抽象去描述。这些数据操作可以串联成一条数据流。于是刚才我们提到的这个例子，就可以用 5 步数据操作来轻松定义。运维人员只需要一次性提交这条数据流，Fluid 自动地会完成整个 AI 模型推理服务发布的流程，提升使用缓存过程的自动化比例。云原生场景下，AIGC 模型服务的工程挑战和应对100那么刚才提到的“用好缓存”的技巧其实都在资源成本和运维效率方面。但实际测试过程中我们发现，服务启动过程使用的带宽远小于这些 GPU 计算实例可用的带宽，这意味着模型的加载效率在客户端上仍然有可以优化的空间。从节点吞吐情况上可以看到，这些 AI 推理的运行时框架会以单线程的方式去按序读取模型参数，这在非容器环境是没有什么问题的，如果使用本地 SSD 盘存储模型参数，加载吞吐很容易就可以到达 34GB/s。但是在计算存储分离架构下，哪怕我们使用了缓存，缓存也需要使用用户态文件系统（也就是 FUSE）这种技术挂载到容器中。FUSE 自身的开销和额外的 RPC 调用，都使得 read 请求的延时变得更高，单线程所能达到的带宽上限也就更低了。云原生场景下，AIGC 模型服务的工程挑战和应对101为了最大化发挥分布式缓存提供的巨大 I/O 吞吐，Fluid 可以提供一个 Python 的 SDK，在用户代码中使用多线程读和预读的方式去加速模型加载过程。从我们的测试结果来看，额外使用这种客户端的优化，可以在使用计算侧分布式缓存的基础上，将冷启动耗时缩短一半，做到 1 分钟内拉起一个接近 100G 的大模型。从右下角的这个 I/O 吞吐情况，也可以看出，我们更充分地利用了 GPU 计算节点的带宽资源。为了评估 Fluid 的性能，我们采用了 HuggingFace Text-Generation-Inference 框架来构建大型语言模型(LLM)的推理服务。我们将模型存储在 OSS 对象存储中，并对用户体验以及直接从 OSS 对象存储拉取与通过 Fluid 拉取数据启动推理服务的性能差异进行了对比分析。我们首先看一下直接访问 OSS 存储的运行效果。这里我们已经创建好了 OSS 的 PV 和 PVC。接着，我们定义一个 deployment：deployment Pod 中挂载刚才的 OSS PVC，使用的容器镜像是 TGI 镜像。还有声明使用云原生场景下，AIGC 模型服务的工程挑战和应对1021 张 GPU 卡，用于模型推理。接着把 deployement 创建下去。然后我们看下这个服务的就绪时间，这边 5 倍速加速了一下。终于就绪了，可以看到整个过程耗费了 101s，考虑到我们的模型大小仅为 12.55G，这个时间可以说是比较长的。最后，让我们看看 Fluid 的优化效果。我们需要定义 Fluid 的 Dataset 和 Runtime 资源，并将分布式缓存部署到集群中。定义数据源、节点个数以及缓存数据的存储介质和大小。由于我们是初次部署弹性分布式缓存，这可能需要约 40 秒的时间。缓存准备完成后，我们可以看到一些缓存的监控信息。PVC 和 PV 也会自动创建。然后，我们定义一个新的 deployment，只需要进行几个修改：添加一个 annotation 来触发 Fluid 的自动数据预热将 OSS 的 PVC 更改为由 Fluid Dataset 自动创建的 PVC替换为一个使用了客户端优化的镜像观察服务的就绪时间，我们可以看到部署只花了 22 秒。我们还可以尝试对现有的deployment 进行扩容，观察第二个服务实例的启动时间。由于所需的模型数据已被完全缓存，第二个服务实例只需 10 秒就能准备就绪。这个例子展示了 Fluid 优化的效果，我们成功提升了服务的启动速度约 10 倍。4.总结Fluid 为 AIGC 模型弹性加速提供开箱即用、优化内置的方案，在达到更好性能的同时还可以降低成本，同时还包含端到端的自动化能力；在此基础上使用 Fluid SDK 可以进一步充分发挥 GPU 实例的带宽能力实现极致的加速效果。云原生场景下，AIGC 模型服务的工程挑战和应对103第四章容器前沿技术与大模型生产实践阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战104阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战作者：刘佳旭，阿里云技术专家1.引言2023 年 7 月，阿里云容器服务 ACK 成为首批通过中国信通院“云服务稳定运行能力-容器集群稳定性”评估的产品，并荣获“先进级”认证。随着 ACK 在生产环境中的采用率越来越高，稳定性保障已成为基本诉求。本文基于 ACK 稳定性保障实践经验，帮助用户全面理解 ACK 稳定性理论和优化策略，并了解如何使用相应的工具和服务进行稳定性保障。2.K8s 集群稳定性和大规模场景下的挑战1）K8s 常见的稳定性痛点Kubernetes 在提供丰富的技术和功能外，架构和运维具有较高的复杂性，也产生了诸多的痛点。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战105痛点 1：在发布、弹性等高峰期，集群控制面服务时断时续，甚至完全不可用面对大流量请求，如果控制面没有自动弹性扩容能力，会无法对负载自适应、导致控制面服务不可用。例如：客户端存在高频度持续 LIST 集群中的大量资源，集群 apiserver/etcd无法自动弹性就可能联动出现 OOM。ACK Pro 托管版 K8s 可以对控制面组件根据负载压力做 HPA 和 VPA，可以有效解决该痛点。痛点 2：集群节点批量 NotReady 导致雪崩，严重影响业务！部分节点出现 NotReady，节点上 Pod 被驱逐调度到健康节点，健康节点由于压力过大也变为 NotReady，加剧产生了更多 NotReady 的节点，业务持续重启。ACK 提供了托管节点池功能，可以对出现 NotReady 的异常节点治愈，重新拉会 Ready 状态，可以有效解决该痛点。痛点 3：业务高峰期需快速弹性，节点上拉取 Pod 镜像耗时长达分钟级，影响业务节点上 kubelet 并发拉取镜像遇到网络带宽限制，需要镜像加速功能支持。ACR 提供了基于 DADI（Data Accelerator for Disaggregated Infrastructure）的按需镜像加载和 P2P镜像加速的功能，可以加速镜像拉取，可以有效解决该痛点。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战106痛点 4：Master 节点/组件运维复杂度高，包含资源配置、参数调优、升级管理等需要大量的线上场景分析和优化、故障处理、规模压测等，来分析、整理并落地最佳实践和配置。ACK Pro 托管版 K8s 在全网的规模体量上万集群，具有自动弹性和生命周期管理的运维管理架构，有丰富的优化、应急处理等经验，持续将最佳实践和参数优化对托管组件升级。2）Kubernetes 集群架构既然有这些痛点，我们从 K8s 架构的角度来分解一下，看看哪些部分可能出现故障和问题：云上 K8s 集群包含控制面、数据面、以及承载控制面和数据面的的云资源。控制面和数据面通过 SLB 和云网络连接。控制面负责集群的 API 层、调度、资源管理、云资源管理等控制面功能，K8s 组件：apiserver/etcd/scheduler/kube-controller-manger/cloud-controller-manager。数据面负责集群的节点管理、Pod 生命周期管理、Service 实现等数据面功能，承载业务Pod 的主体。包含：K8s 组件，kubelet/kube-proxy；系统组件，日志、监控、安全等组阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战107件；其他组件，用户业务组件。控制面、数据面和云资源是有机结合的整体！集群的全链路中，任何一个组件、子链路成为瓶颈，都可能影响到集群的整体稳定性。我们需要从 K8s 系统中发现瓶颈、治理以及优化瓶颈，最终实现 K8s 系统在给定云资源情况下的稳定、高效的利用。3）Kubernetes 稳定性体现我们已经了解了 K8s 集群架构，那么如何评估 K8s 集群的稳定性呢？集群稳定性涵盖Kubernetes 服务可用性、处理时延、请求 QPS 和流量吞吐、资源水位等要素。Kubernetes 稳定性风险和挑战阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战108结合刚才介绍的 K8s 的架构和稳定性体现，我们来看看 K8s 集群的稳定性风险和挑战，在大规模场景下稳定性风险和挑战会更加突出。挑战 1：集群内资源种类繁多，数量巨大大规模集群场景下常见。包含原生 K8s 资源和丰富灵活的 CRD 资源。节点是 K8s 的一种资源，节点规模大的集群是大规模集群的一种；从 K8s 治理的角度，集群中某种资源数量巨大，例如 configmap、secrets 等，即便节点数不大，也可以称为大规模集群。例如：单集群超过 1 万节点规模、单集群有 10W 的 namespace 以及 ns 下secret/configmap 资源。挑战 2：控制面压力的风险控制面组件缓存集群的部分或者全部资源。在大规模场景下，每个组件都会有明显的资源压力。超过资源 Limits 就会触发 OOM 等问题。例如 apiserver 将 etcd 中全部资源在内存中缓存以便响应客户端对 Cache 的 LIST 请求。请求来源复杂。包括随节点规模正增长的 kubelet/kube-proxy/daemonset，也包括系阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战109统组件和用户部署的组件。挑战 3：数据面压力、以及数据面与控制面同步压力的风险数据面节点出现压力以及异常。节点负载压力过高，导致 kubelet/运行时响应慢或者无响应，甚至节点状态 NotReady。数据面与控制面同步瓶颈。数据面与控制面网络带宽打满或者网络不通，kubelet 无法及时更新 node 状态，导致节点状态 NotReady，导致容器调度、service 后端流量转发受影响。挑战 4：云资源稳定性和高可用稳定性有限的云资源容量。例如 SLB 的连接数、带宽，ECS 的内存、CPU 等等，存在打满的风险。集群的核心云资源和组件需要按高可用架构部署。包括跨节点、AZ 等不同高可用等级。3.ACK 稳定性治理和优化策略1）ACK K8s 稳定性概述阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战1102023 年 7 月，ACK 成为首批通过中国信通院“云服务稳定运行能力-容器集群稳定性”评估的产品，并荣获“先进级”认证。ACK K8s 稳定性优化，源于大规模实践经验沉淀，具体包括：ACK 全网管理了数万个 K8s集群，对线上丰富的客户和业务场景提供全面的支持；ACK 作为底座承载了双十一、618 等超大规模的电商业务，经受住了阿里巴巴电商场景的极限压力的考验；对社区原生 K8s 做参数、性能、架构等优化，并形成产品能力。ACK 针对丰富的业务类型和大规模场景进行优化，例如：云上的大规模化场景，支持单集群上万节点Sark/Flink 等大数据场景Tensforflow/Pytorch 等 AI 场景ECI/Spot 等快速弹性场景ArgoWorkflow 等任务流场景2）ACK 集群稳定性治理关键点阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战111a.高可用架构控制面全面按高可用架构部署。数据面提供丰富的高可用产品能力和配置，便于用户提升集群的高可用性。b.K8s 优化包括 APIServer/Etcd/KCM/Scheduler/Kubelet/Kube-proxy 等组件的优化、参数配置等。c.集群容量规划和自动弹性例如：规范 LIST 请求使用、优先使用 Informer 机制、优先使用 PB 协议等等。d.系统组件、用户组件优化控制面托管组件支持根据请求负载自动弹性扩缩容，控制面可观测对用户透出。数据面提供丰富的集群、节点、工作负载、Ingress 等监控告警。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战112e.质量巡检、故障演练、压测体系ACK 组件和集群自动化巡检、定期进行的故障演练和应急预案恢复验证、高效的压测体系。f.数据面优化节点自动运维和自愈能力，镜像加速和 P2P 传输。下面针对部分优化关键点详细展开说明。3）高可用架构控制面实现可用区级别高可用 全部控制面组件实现与阿里云 ECS 的可用区能力对齐的高可用打散。以 APIServer 为例，多副本跨 AZ、跨节点高可用部署方式，任何一个 AZ 失效不影响服务可用性。在 3AZ 地域，ACK 托管集群控制面的 SLA 是 99.95%。对于不具备 3AZ 的地域，ACK 托管集群控制面 SLA 是 99.5%（不具备单可用区的故障容忍）。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战113控制面实现可用区级别高可用全部控制面组件实现与阿里云 ECS 的可用区能力对齐的高可用打散。以 APIServer 为例，多副本跨 AZ、跨节点高可用部署方式，任何一个 AZ 失效不影响服务可用性。在 3AZ 地域，ACK 托管集群控制面的 SLA 是 99.95%。对于不具备 3AZ 的地域，ACK 托管集群控制面 SLA 是 99.5%（不具备单可用区的故障容忍）。数据面支持客户配置丰富的高可用策略。对于 Pod，支持基于节点、部署集、AZ 等不同故障域，结合 K8s 调度中的拓扑分布约束（Topology Spread Constraints），实现不同等级的高可用策略；云盘、负载均衡、虚机节点等云资源均支持 K8s 场景下按多 AZ 打散配置。在分析 APIServer 优化前，先来看一下 K8s API 请求的分析。这里的结论为：不带 ResourceVersion 的 LIST 请求，请求会击穿到 etcd 和 apiserver，对系统压力最大，如果使用 labelSelector/fieldSelector 只能在 apiserver 内存中过滤，不会减少对 etcd 压力；informer 通过 LIST WATCH 的请求组合，最大化降低对控制面 apiserver 和 etcd 的压力，是推荐的机制。4）APIServer 稳定性优化阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战114a.APIServer 自动弹性ACK 管控基于访问压力和集群容量实现 APIServer 实例自动弹性。b.软负载均衡方法：负载不均会导致个别 APIServer 实例资源开销大、容易触发 OOM。Goaway 特性概率性断开并新建 TCP 连接，实现负载均衡的效果。作用：帮助稳定运行的集群能解决负载不均衡问题。c.托管组件可观测性透出全部托管组件 apiserver、etcd 等监控告警对用户透出。支持识别可能存在的非规范 LIST请求的 Grafana 看板，帮助用户评估组件行为。d.集群资源清理 关闭不需要功能及时清理不使用的 Kubernetes 资源，例如 configmap、secret、pvc 等；及时清理不使用的 Kubernetes 资源，例如 configmap、secret、pvc 等。5）Etcd 稳定性优化阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战115a.Data 和 Event etcd 分拆Data 和 Event 存放到不同的 etcd 集群。数据和事件流量分离，消除事件流量对数据流量的影响；降低了单个 etcd 集群中存储的数据总量，提高了扩展性。b.Etcd 根据资源画像 VPA根据 Etcd 资源使用量，动态调整 etcd Pod request/limits，减少 OOM。c.AutoDefragoperator 监控 etcd 集群 db 使用情况，自动触发 defrag 清理 db，降低 db 大小，提升查询速度。6）Scheduler/KCM/CCM 稳定性优化阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战116QPS/Burst 参数调优。KCM/Scheduler/CCM 的 QPS/Burst 参数在规模化场景下需要提升，避免核心组件出现客户端限流；同时观测 APIServer 监控，避免 APIServer 对核心组件限流。7）组件稳定性优化阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战117a.规范组件 LIST 请求必须使用全量 LIST 时添加 resourceVersion=0，从 APIServer cache 读取数据，避免一次请求访问全量击穿到 etcd；从 etcd 读取大量数据，需要基于 limit 使用分页访问。加快访问速度，降低对控制面压力。b.序列化编码方式统一对非 CRD 资源的 API 序列化协议不使用 JSON，统一使用 Protobuf，相比于 JSON 更节省传输流量。c.优选使用 Informer 机制大规模场景下，频繁 LIST 大量资源会对管控面 APIServer 和 etcd 产生显著压力。频繁LIST 的组件需要切换使用 Informer 机制。基于 Informer 的 LIST WATCH 机制优雅的访问控制面，提升访问速度，降低对控制面压力。d.客户端访问资源频度客户端控制访问大规模全量资源的频度，降低对管控的资源和带宽压力。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战118e.对 APIServer 访问的中继方案大规模场景下，对于 Daemonset、ECI pod 等对 APIServer 进行访问的场景，可以设计可横向扩容的中继组件，由中继组件统一访问 APIServer，其他组件从中继组件获取数据。例如 ACK 的系统组件 poseidon 在 ECI 场景下作为 networkpolicy 中继使用。降低管控的资源和带宽压力，提升稳定性。4.ACK 稳定性产品功能和最佳实践器针对刚才提到的 K8s 稳定性风险和挑战，我们看一下 ACK 是如何进行稳定性治理和优化的。ACK 提供了高效丰富的稳定性产品功能，这里着重从可观测性、故障预防与定位、自动化节点运维角度来介绍产品功能，对应的产品功能分别是：Prometheus for ACK Pro容器 AIOps 套件托管节点池帮助客户提升透明可观测、风险可预测、故障可定位、运维自动化的稳定性保障。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战1191）Prometheus for ACK Pro在透明可观测方面，ACK 支持从应用层、APM 层、K8s 层到基础设施层的全景可观测。PrometheusforACKPro 结合容器服务最佳实践经验，提供了可以关联分析、可交互的大盘。例如：全局资源总览、节点总览K8s 核心托管组件的监控，例如 apiserver，etcd 等等集群事件分析在节点层结合 eBPF 实现了无侵入式应用监测基于 ACKPrometheusforACKPro，可以全面覆盖数据面和控制面的可观测性。阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战1202）容器 AIOps 套件-故障预防与定位在智能运维方面，ACK 的容器 AIOps 套件凭借 10 年大规模容器运维经验沉淀，自动化诊断能力能够覆盖 90%的运维问题。基于专家系统 大模型，AIOps 套件提供全栈巡检、集群检查、智能诊断三大功能。全栈巡检，定位集群风险巡检。可以扫描集群健康度和潜在风险，例如云资源配额余量、K8s 集群关键资源水位，并提供修复的解决方案。集群检查，定位运维操作前的检查。例如企业在业务升级过程中经常遇到的 K8s 版本较老，基于各种顾虑不敢升级的问题，阿里云 ACK 可以自动识别出应用是否在使用K8s 老版本废弃的 API、集群资源是否足够，帮助企业规避升级过程中遇到的风险。智能诊断，定位诊断 K8s 问题。可以诊断异常的 Pod，Node，Ingress，Service，网络和内存。3）托管节点池阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战121在节点自动化运维方面，托管节点池是 ACK 面向数据面提供的产品功能。定位是让用户专注上层应用部署，ACK 负责节点池基础运维管理。支持自升级、自愈、安全修复、极速弹性四大功能。自升级是指自动升级 kubelet 和节点组件。自愈是指自动修复运行时和内核问题。例如发现 NotReady 的节点，并治愈恢复为Ready 状态。安全修复是指支持 CVE 修复和内核加固。极速弹性是基于 ContainerOS 以及通用 OS 的快速弹性。P90 统计算法下，完成1000 节点扩容只需要 55s。5.展望ACK 稳定性保障建设会持续演进，会继续为客户提供安全、稳定、性能、成本持续优化的产品和稳定性保障！阿里云 ACK 云上大规模 Kubernetes 集群高可靠性保障实战122基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程123基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps流程作者：匡大虎，阿里云高级技术专家引言安全一直是企业上云关注的核心问题。随着云原生对云计算基础设施和企业应用架构的重定义，传统的企业安全防护架构已经不能够满足新时期下的安全防护要求。为此，企业安全人员需要针对云原生时代的安全挑战重新进行系统性的威胁分析并构建适合企业自身的威胁情报系统，同时在云原生安全体系方法论的指导下，结合云服务商提供的安全产品能力构建端到端的 DevSecOps 流程，维持企业应用全生命周期的持续安全水位。本文分为四部分：其中第一部分会介绍当下云原生安全的现状以及企业应用在云原生化转型中面临的主要安全挑战；在第二部分中会概要性介绍云原生安全相对成熟的一部分安全体系方法论；在第三部分中会结合之前介绍的理论基础，介绍如何通过部署和实时阿里云 ACK 容器服务和ACR 容器镜像服务中提供的一些实用的安全产品能力，帮助企业实现或优化DevSecOps流程；最后，在第四部分会总结介绍企业在实践 DevSecOps 过程中需要遵循的安全最佳实践。1.云原生安全挑战基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程124云原生时代对企业安全的挑战主要来自以下三方面：云原生平台基础设施架构：云原生平台层组件相较于传统架构引入了更多的配置项和隔离层，这就给企业安全管理运维人员提出了更高的运维要求。如何保证平台基础设施层的默认安全性，如何在遵循最小化权限原则基础上进行授权操作，如何建立云原生应用系统的安全审计和监控能力，这些新的挑战都需要云服务商和企业安全管理运维人员协同构建并最终实施到企业云原生化转型后的系统应用架构中。DevOps 软件供应链：云原生弹性、敏捷和动态可扩展的特征极大地改变了传统应用部署模式，应用自身的生命周期被大幅缩短，而企业应用的迭代效率则大幅提升，在企业供应链架构变革的同时需要构建和实施适配供应链各阶段的安全防护能力。应用范式上的改变：随着微服务架构的普适，传统的基于南北向流量的安全边界模式已经变得不使用，企业需要更加细粒度的身份认证和访问控制；同时 Serverless 和函数计算等技术要求云服务商在基础设施层具备更强的安全隔离性和监控能力，而应用的容器形态则需要新的运行时安全监控告警和资产管理模式与之对应。面对重重的安全挑战，企业的安全现状是如何呢？上图是一些主流云原生安全领域厂商在今年发布的最新报告。其中图片左侧来自 Sysdig 今年的云原生安全使用调查报告，报告显示仍然有 87%的容器镜像中包含严重或高危等级的漏洞，同时 90%的企业应用授权并没有基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程125被实际使用；从右侧 Paloalto 今年的云原生安全现状报告中企业客户反馈的 Top 5 挑战中也可以看出，面对云原生时代新的安全挑战，企业无论在组织架构、文化和安全运维上都还没有做好充分的准备。供应链安全也是近两年成云原生安全领域的焦点,我们知道创新和效率是企业发展的关键，在云原生时代的企业开发流程中，开源软件和开发工具可以帮助推动企业提升研发效率。在云原生时代，企业对开源生态越来越依赖，三方软件包的安全成为了无法回避的问题。为此 Gartner 预测：“到 2025 年，全球将有 45%的组织的软件供应链受到攻击，比 2021年增加三倍”。在 sonatype 今年的统计中，仅仅在今年已经有超过 24 万 5 千个软件包中被发现包含漏洞，这个数字是从 19 年到 22 年之合的两倍。由此可见企业的供应链安全也成为攻击者的主要攻击目标，在调查中我们也发现，多数的受访者都清楚的知道来自供应链的安全风险，但只有不到十分之一的企业受访者表示会在生产供应链生命周期的每个阶段进行安全审核和部署防护措施。由此可见企业安全人员的风险意识与有效的供应链风险管理和防护措施的实施之间还是存在了明显的脱节。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程126在传统的软件开发流程中，安全人员通常是在系统交付之前才开始介入进行安全审核工作，这样的安全流程显然已经无法满足云原生时代下软件供应链的快速迭代流程。来自 Gartner 的分析师 David Cearley 早在 2012 年就首次提出了 DevSecOps 的概念。相较与传统软件开发的安全流程，DevSecOps 强调从企业安全文化意识，安全流程左移以及构建全链路的自动化流程等几个要点来加固新时期下企业软件供应链安全。Gartner 预测，到 2025 年将有 60%的企业采用并实践 DevSecOps。DevSecOps 模型强调安全和整体软件开发流程的紧密结合，同时也强调了在不降低企业应用开发迭代速度的前提下，通过执行全面的自动化安全防护措施来确保应用制品和供应链管道的安全性。在当下，绝大多数的企业云原生安全的发展都落后于应用的云原生化进程，而主要的改进方向也集中在下面这三个方向：身份和访问管理：线上授予的权限与实际需要的权限之间存在巨大差异，无疑会给攻击者可乘之机。漏洞和配置管理：大多数的企业生产镜像都没有经过安全加固和最小化的裁剪收敛，另外很多线上应用因为开发调式的一时方便而在容器层配置了过高的特权监控和响应：缺少针对容器资产的运行时监控和防护手段，针对突发的攻击事件也无基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程127法有效完成定位和溯源。这些都是企业应用在云原生化进程中亟需优化和解决的主要安全方向。2.云原生安全体系方法论安全在本质上是一个对系统风险发现、定位和管理的流程。在了解云原生安全，而威胁建模可以在应用设计开发的早期阶段，帮助安全人员识别企业应用架构中潜藏的安全风险和设计缺陷。在上图中，左边是针对云上资源的典型攻击路径分析，我们看到在传统的云服务架构下，针对身份和控制面的不当配置以及网络攻击是攻击者可以利用的主要途径，攻击者可以通过漏洞利用、非授权访问和数据窃取等手段攻击企业服务和数据；而在右边的云原生 k8s 集群的典型攻击路径中，由于云原生技术架构的复杂性，容器应用、运行时、k8s 编排引擎、镜像仓库以及内核层都可能给整个应用系统引入新的风险，同时在网络侧，不同容器微服务应用之间的东西向流量也提供给攻击者更多的可利用目标。而近年来不断爆出云原生社区相关的 CVE 漏洞中，攻击者可以利用的攻击方式也是多种多样，基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程128像一般的提权、仿冒、篡改、抵赖、拒绝服务等典型攻击手段都出现在了近两年公开披露的漏洞利用方式中。为此，需要企业安全人员在传统基础设施架构威胁之外尽可能全面的获取安全威胁信息。同时在企业应用架构发生动态变化的同时，也需要重新评估当前威胁建模下的安全机制和模型矩阵是否也需要随之调整。ATTCK 框架是网络攻击中涉及的已知策略和技术的知识库，其中阿里云也是国内首家针对云原生容器和 Kubernetes 的攻防场景，提出并发布相应 ATT&CK 攻防矩阵的云服务商。在 ATTCK 矩阵中详细描述了攻击者在云原生和 Kubernetes 环境发起攻击的过程和手段，可以帮助企业构建容器化应用安全体系，也是企业构建云原生威胁情报体系可以利用和借鉴的基本框架。整个威胁矩阵由不同的行和列组成，其中行代表了攻击技术，列代表了攻击战术手段。矩阵从左至右可以代表一个通常的容器侧攻击路径。通过了解矩阵中每一个攻击阶段攻击者可以利用的技术手段，可以帮助企业安全运维人员有针对性地进行安全设计和测试演练，当安全事件发生时，也可以帮助有效实施对应的止血和预先的防护措施。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程129为了进一步理解云原生应用安全风险并构建完整的安全防护方案，企业安全运维人员还需要先进的分析方法，覆盖对应用侧风险、开源组件风险、云基础设施风险和应用运行时风险的完整感知。为此 Gartner 牵头在已有的云安全态势管理(CSPM)、云基础设施授权管理（CIEM）和云工作负载保护平台（CWPP）等传统主流云平台安全模型的基础上，提出了 CNAPP 云原生应用保护平台框架，面向云原生应用从开发到运行时刻的全生命周期流程，帮助企业安全团队和 DevSecOps 架构师提供完整视角的应用风险可见性和相应的解决方案。基于 CNAPP理论框架，信通院在 2022 年云原生产业联盟年会上发布了 云原生应用保护平台（CNAPP）能力要求，在 CNAPP 理论框架的基础上，进一步细化了规范要求。从架构图中可以看到 CNAPP 框架集成了之前多个成熟规范的核心特性，可以：更好地适配云原生应用高速迭代的敏捷特性，通过自动化手段减少错误配置和管理。减少参与供应链 CI/CD 管道的工具数量。降低云原生应用安全合规实施复杂性和成本。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程130对于企业应用，安全需求分析、安全测试、安全开发和反复的加固措施也同时伴随着应用的迭代。我们知道企业安全文化意识以及开发、安全运维团队之间的流程协同是DevSecOps 能够有效实施的关键，在 CNAPP 框架中，也同样强调研发和运维侧双向反馈飞轮，加强企业安全可视性和对风险的洞察力，从整体上改善企业安全态势。上图中的研发和运维侧双向反馈飞轮主要分为下面两个方向：从开发到生产：基于安全左移原则，将安全集成到开发人员的工具链中，在代码创建阶段就通过自动化构建管道触发安全测试，以降低后续安全风险和运维成本。从生产到开发：需要企业安全管理人员全面监控线上应用和平台配置，并结合运行时安全配置上下文，提前识别风险并考虑风险处理等级预案，同时将相应的加固措施落实到新的开发迭代流程中。只有通过这样不断循环反馈，才能保证在云原生下应用的高速迭代的过程中持续的安全水位。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程131企业在 DevSecOps 的落地实践中可以充分利用云原生技术，同时结合云服务上的安全产品能力以及部署成熟的安全三方产品也可以帮助企业快速构建 DevSecOps 能力。企业应用的安全性需要贯穿应用程序的整个生命周期。开发是整个应用生命周期的第一个阶段，其结果是创建用于部署和配置应用的云原生模版、容器镜像、应用二进制等云原生制品，这些制品正是运行时被攻击利用的主要源头，相应这个阶段针对不同制品安全扫描就显得格外重要。构建分发阶段包括基于 CI/CD 自动化流程的各种系统测试，尤其针对开源软件，需要进行明确的漏洞风险分级卡点机制，同时加入自动化的加签机制以支持制品的可信校验。部署阶段负责进行一系列“飞行前”检查，以确保将部署到运行环境中的应用程序符合整个企业组织的安全和合规规范。运行时阶段的安全包括计算、存储和访问控制三个关键领域的安全能力。运行时环境的安全性取决于前几个阶段安全实践的有效性，同时需要企业在配置管理、身份和访问控制以及运行时威胁检测方向上基于安全原则实现高效的自动化监控和管理能力，并且通过全局性的安全资产管理和态势感知能力不断发现风险并反馈到生产开发及供应链各环节。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程132最后，企业应用安全需要防患于未然，完备的审计和溯源分析能力以及精准的风险阻断能力可以帮助企业安全运维人员从容应对突发的攻击事件，并在规划的指导下做出快速的决策和响应。最后，安全左移和循环反馈是指导企业基于 DevSecOps 理念实施安全防护的主要原则。在应用制品的供应链生命周期中应尽早地以自动化方式嵌入安全，通过引入自动化的安全扫描和巡检机制，在早期发现并治理常见的软件 CVE 漏洞，可以帮助团队以低成本的方式扼杀风险，同时整体提升团队安全意识。企业在落地并实践了安全左移理念后，并不意味着安全工作的结束。在应用的生产运行阶段，安全管理人员可以采集并掌握更全面的安全上下文信息，并通过威胁分析发现更多在供应链环节无法暴露的安全设计和配置上的问题，只有通过不断的反馈和更新，才能够保持企业应用系统的整体安全水位，同时应对无法预知的安全挑战。3.阿里云容器服务 ACK&容器镜像服务 ACR 安全产品能力通过上面的介绍，我们对云原生安全面临的挑战以及当下比较成熟的云原生安全理论体系有了初步的了解，下面我会具体介绍阿里云 ACK 和 ACR 服务中面向企业提供了哪些安全相关的产品能力，可以帮助企业实现或优化 DevSecOps 流程。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程133首先，围绕 DevSecOps 流程中的核心防护能力和自动化要求，阿里云 ACK 和 ACR 服务也沉淀了 DevSecOps 产品能力，帮助企业实现安全可信的软件供应链。在镜像构建阶段，客户提交源代码变更后，自动触发 ACR EE 的云原生应用交付链功能，开始容器镜像构建，支持自动安全扫描，如果识别到镜像中存在风险，会自动阻断构建流程并钉钉报警。用户可以一键修复镜像中存在的 CVE 漏洞。在镜像交付阶段，ACR 和 ACK 可以基于客户的秘钥进行镜像的加签与验签，确保整个交付链路无篡改。在容器应用运行时，云安全中心可以对 ACK 集群中运行时风险进行防护、感知，以及阻断处理。今年，我们推出了集群容器安全概览功能，可以帮助企业安全管理员更好感知集群配置、应用镜像、容器运行时的安全风险，提升整体安全水位。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程134DevSecOps 的实践依赖企业内部深层次的协同，而不同的工具和实践流程会阻碍跨部门协作的高效性和生产力。通过标准化的平台能够简化部门间沟通和学习成本，让供应链流程更加透明高效ACK、ACR 充分利用云原生技术，在企业供应链流程的关键路径上构建了核心能力，面向企业安全管理员提供了开箱即用的产品能力，安全人员可以通过简单的可视化白屏操作完成制品校验，安全巡检、策略实施等供应链安全防护能力，同时通过不同维度的可视化监控和报表直观的了解并管理应用安全，帮助企业安全管理人员第一时间洞察风险，应对攻击。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程135默认状态下的安全性是整个系统安全体系的根基，不仅决定了生产系统的稳定性，也直接关联了上层安全方案的运维和实施成本。为此，在企业应用系统的设计阶段，安全性就应当作为基本且必要的需求融入设计环节，并在安全专家的指导下审核架构设计中潜藏的风险。企业应用使用哪种凭据访问云资源？基于默认安全和权限最小化原则，在应用内直接使用AK 以及在节点上直接绑定云资源访问权限都是安全上不推荐的做法，此时可以将 RRSA 方案集成到企业应用设计和编码环节，通过 RRSA 方案，可以实现基于 k8s serviceaccount，与阿里云 RAM 服务完成基于 OIDC 协议的访问控制认证，并实现以应用维度最小化隔离授权云资源访问权限。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程136密钥管理一直是企业应用上云的核心问题，云服务商有哪些安全方案可以帮助保护应用密钥？用户又应该在 K8s 环境中采取哪些安全措施帮助管理和使用密钥？应用密钥应该存储在哪里？这些都是企业客户经常会问到的一些基本问题。为此，首先应避免密钥在应用中的硬编码问题。在应用系统开发部署的供应链流程中，任何一个环节对敏感密钥的硬编码都有可能导致泄露风险。通过使用云上 KMS 服务，可以在应用开发、测试、构建等生命周期流程中使用统一方式进行密钥的读写，避免硬编码出现；同时云上的 KMS 服务支持自动化的密钥轮转能力，进一步降低了敏感信息泄露传播的安全风险，同时也可帮助企业应用满足合规需求。通过部署ack-secret-manager插件可以将KMS凭据管家中管理的企业密钥以k8s secret的形式同步导入到业务集群中，企业应用可以直接通过文件挂载的方式使用密钥，在避免密钥硬编码问题的同时保证了业务代码的兼容性，在新版本的 ack-secret-manager 中还支持对接 KMS 服务升级后的专属 KMS 实例，提供更强的密钥安全性隔离保证。K8s 社区基于 CSI 存储标准扩展实现了 secrets-store-csi-driver 用于将存储在外部密钥管基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程137理服务中的密钥以 volume 存储卷的形式挂载到应用 pods 中。和 ack-secret-manager方案不同，该机制避免了 K8s secret 实例的创建，带来的好处一是避免 etcd 中出现明文secret 信息，二来可以在大规模场景下避免 secret 堆积；同时应用仍旧可以保持原先的文件路径方式读取密钥，避免了额外的程序改造代价。基于该插件机制我们实现了阿里云自己的 secrets-store-csi-driver-provider，并且支持通过 ACK 应用市场在集群中一键化部署该插件，同样可以将阿里云 KMS 凭据管家中保存的密钥凭据以文件形式同步到应用容器中，同时支持后端凭据修改后的同步更新能力，保证业务容器中密钥信息的实时性。当然这里也会有“最后一把密钥”的问题，由于插件需要调用 KMS 凭据管家服务的权限，如何在集群中保护插件对 KMS 服务请求的凭据呢？这里推荐使用 RRSA 方案，可以将 KMS凭据的请求权限绑定在插件使用的独立 serviceaccount 上，避免将权限泄露给应用 pod中。对于数据安全性有严格要求的场景，比如当下火热的 AI 大模型，金融支付、隐私认证或涉及知识产权的核心数据计算，除了保证这些核心敏感信息在读写和传输过程中的安全性，还需保证机密信息在云上节点内存运算和存储过程中的安全可信。今年我们还和 Intel 以及CoCo 社区合作，基于 Intel TDX 机型实现了新一代的可信执行加密环境，帮助实现企业数基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程138据全生命周期的安全可信。在应用运行时，云原生工作负载区别于传统基于虚机的应用服务有如下特点：短暂的生命周期，只有秒级的生命周期；编排引擎会根据节点实时资源动态调度工作负载，网络 IP 等应用元数据可能随应用重启不断变化；出于基础设施不可变性，对运行时环境的修改在工作负载重启后不会保留。正因为云原生工作负载自身特点，在应用运行时，当前大多数云原生安全产品对容器侧用户态进程的检测分析都存在不足。而 eBPF 天然的技术优势是提升云原生应用安全可观测性和实现精细化安全事件响应的有力武器。在 ACK 集群中，我们提供了针对 k8s 应用的 exec 活动审计能力，通过 eBPF agent 可以实时获取容器负载中执行的系统调用，并关联映射到在容器实例中执行的具体进程，从而帮助安全运维人员获取攻击者进入到容器实例后发起攻击的命令审计，有效帮助针对安全事件的溯源和止血。同时我们也和 SLS 日志服务提供的强大日志分析检索能力结合，针对云原生的典型漏洞，基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程139提供了可疑的漏洞利用活动的溯源和告警能力，并且通过时间线图表的方式直观的展现给企业安全人员。员工离职后的权限清理问题也是困扰很多企业权限管理员的难题。在 ACK 默认提供的 x509证书认证模式下，企业安全运维人员很可能由于疏漏在删除 RAM 账号或角色前忘记吊销和清理 kubeconfig 权限。通过 ack-ram-authenticator 组件，ACK 托管集群可以通过 Webhook 方式、基于阿里云RAM 完 成 请 求 认 证。相 较 于 ACK 集 群 默 认 提 供 的 x509 证 书 认 证 模 式，使 用ack-ram-authenticator Webhook 认证方式有如下优点：适配企业通过云 SSO 场景，提供灵活可控的数据面 RBAC 授权；角色 SSO 对接场景下 apiserver 审计日志中包含企业 IDP 中的身份信息，有效支持对扮演同一角色的不同 IDP 用户的行为审计；企业员工离职删除 RAM 账号或 RAM 角色时，可自动清理其在账号所有 ACK 集群中的认证访问权限。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程1404.企业 DevSecOps 安全最佳实践“木桶的最大容积取决于最短的一块木板”，云原生安全同样遵循这样的木桶原则。由于云原生技术栈的复杂性，企业安全管理和运维人员更需要在安全准则的指导下，全面充分的了解全局安全风险，提升系统“最低点”安全水位。零信任安全最早由 Forrester 首席分析师 John Kindervag 在 2010 年提出，其核心思想是“Never Trust，Always Verify”。在零信任安全模型中，只要处于网络中，默认情况下任何用户都不可信，任何时刻任何环境下设备和服务的身份权限都需要被持续验证。权限最小化原则是企业安全运维中最基本也是最重要的准则之一。传统应用架构下，系统的权限管理员需要基于权限最小化原则对内部人员授权。在云原生架构下，授权管理不止针对企业中的账号系统，同时需要考虑松耦合微服务架构下众多服务身份的授权安全左移不仅可以有效降低软件自身漏洞而导致的应用风险，同时也能够有效降低企业开发运维成本。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程141企业安全管理人员需要在安全系统设计中规划和覆盖应用周期中的每个阶段，在安全左移和循环反馈原则的指导下，结合 CNAPP 等规范框架的理论指导下完成安全产品能力的建设。这里也列举了企业生产供应链中在开发，构建部署、运行时和反馈阶段环节需要具备的一些核心能力，时间关系就不一一介绍了。基于阿里云 ACK 与 ACR 构建企业级端到端 DevSecOps 流程142DevSecOps 在企业的落地实践离不开上海品茶理念上的转变，在 DevSecOps 体系中，安全应当是企业内部团队共同的目标，而不应只是安全团队自身的职责；企业开发、运维和安全团队应当协同起来，设定统一的目标并共担责任，同时定义团队之间的交流互动方式，能够有效提升业务迭代效率。下面几个方向是企业管理人员在上海品茶 DevSecOps 转型中需要关注的重点方向：人员：拥有合适的人才是 DevSecOps 的基础。安全培训和培养安全拥护者一直是让安全变得重要的首选解决方案；同时 DevSecOps 需要在安全和效率之间取得适当的平衡，另外持续学习，掌握最新的漏洞和策略对于保证应用程序的安全至关重要。流程：制定正确的流程可以确保每个人都站在同一起跑线上，并为安全一致性和凝聚力奠定基础。工具：成功实施 DevSecOps 战略的最后一个要素是工具。Kubernetes 安全领域拥有众多工具，可以解决 Kubernetes 和云原生安全的各个层面的问题。当然，在研究和实施安全工具时，也需要避免使用存在重大缺陷的工具。绩效：在重视生产效率和版本迭代的前提下，可以将 DevSecOps 的实施列入团队绩效考核，并且通过一些具体指标和分级问责机制的建立也是让 DevSecOps 快速融入团队的有效途径。结语最后，欢迎大家选择和使用更多的阿里云 ACK 和 ACR 服务中提供的安全产品能力，让我们共同努力，让 DevSecOps 流程落地实践到更多的企业生产流程中。机密计算容器前沿探索与 AI 场景应用143机密计算容器前沿探索与 AI 场景应用作者：李鹏（壮怀），阿里云高级技术专家、朱江云，英特尔软件与先进技术事业部高级经理企业与个人对数据隐私保护日益关切，从数据，网络的可信基础设施扩展到闭环可信的计算基础设施，可信的计算，存储，网络基础设施必定成为云计算的标配。机密计算技术应运而生，其中一个重要的技术是通过芯片的可信执行环境 TEE 实现数据保护。在 TEE 内执行的应用，不用担心来自其他应用、其他租户、平台方甚至运维内部团队的安全隐患。为了解决企业对数据隐私日益关切，阿里云、达摩院操作系统实验室与 Intel 和龙蜥社区一起，推出基于可信执行环境（TEE）的机密计算容器（Confidential Containers，简称 CoCo）在云上的参考架构。企业可以通过容器服务 ACK TDX 机密沙箱容器节点池实现端到端零信任的应用、数据和模型保护。在 2023 年云栖大会现场，阿里云容器服务高级技术专家壮怀和英特尔中国软件与先进技术事业部的高级经理朱江云共同分享了阿里云容器服务团队与社区和生态伙伴一起，在机密容器领域的探索、安全特性的演进，以及关于如何通过机密容器来保护 AI 应用的数据、模型以及计算展开探讨。1.ACK 端到端可信容器，为数据安全护航阿里云容器服务高级技术专家壮怀首先分享了对当前容器运行时安全主要威胁的分析、企业应该坚守的安全原则及阿里云容器服务如何与机密计算领域生态伙伴一起，为客户提供端到端可信容器，为企业数据安全保驾护航。机密计算容器前沿探索与 AI 场景应用1441）容器运行时安全威胁通常来说，我们对于企业安全的定义是是“在不加剧安全漏洞的情况下，您能否继续高效/安全地工作”。保证容器运行时安全需要通过最小化权限、零信任的原则，以 Never trust,always verfy 的方式思考 IT 设施各个组件之间的交互方式，思考计算如何做到零信任。机密计算容器前沿探索与 AI 场景应用145云计算构建了 RAM 鉴权体系、KMS 的密钥密文的管理能力、存储的 BYOK 加密技术、VPC、安全组、身份认证、鉴权、策略治理等等，即便如此，企业仍需思考是否足够解决云计算中信任问题，如计算过程数据的安全性如何保护、进程的计算过程对 root 的运维透明性如何防御等。安全的好坏取决于“最薄弱的环节”，是大家都知道木桶原则，短板决定了容量，短板决定了安全水位，云计算信任问题在解决了存储和网络相关信任问题，更聚焦到了计算的信任问题。实现安全的过程是对企业资源、所需专业知识、时间管理、实施成本、数据备份/恢复等的“风险管理”。当今的安全趋势是以安全左移，安全贯穿于开发，构建等更早期的阶段，数据的安全性依然需要贯彻于存储、网络和计算的三项基础设施。企业对安全的需要是全天候的、持续不断的、永无止境的，安全就是“在不对网络、生产效率和预算造成负面影响的情况下，以最快的速度学习所有可以学习的知识”。今天第三代的安全容器技术，正是遵循这个原则，从早期的需要侵入式的改造的 SGX1.0，到可以对更大内存空间做机密计算的 SGX2.0，到今天应用无感的平滑迁移进入安全容器技术（TDX/SEV/CCA）。从金融领域，扩展到今天的通用人工智能 AGI 的数据，模型保机密计算容器前沿探索与 AI 场景应用146护。从数据，网络的可信基础设施到闭环可信的计算，可信的基础设施必定成为云计算的标配。运行时的安全，有以下 5 个主要的安全威胁都可能会导致租户容器内的敏感数据遭到泄露：非授权部署错误配置恶意镜像漏洞利用提权攻击和内存溢出/数据攻击在云环境中运行容器时，底层基础设施的安全性和云服务提供商的可信度变得至关重要。如果云服务提供商受到入侵或缺乏适当的安全措施，容器内的敏感数据（如凭据、加密密钥或个人身份信息）可能会被未经授权的人员访问或窃取。今天云原生的安全手段通过相应的手段来治理和防护：OPA 策略治理应对授权和部署攻击配置巡检应对配置漏洞镜像扫描和 BinaryAuth 防范恶意镜像攻击CVE 修复和自动化运维升级抑制漏洞利用攻击而对于上述第 5 中提到的“提权攻击和内存溢出/数据攻击”，则需要使用机密虚拟机或者机密沙箱容器来做软硬一体的可信的计算来从根源上治理。机密计算容器前沿探索与 AI 场景应用147阿里云与 Intel 和龙蜥社区一起，推出机密容器和通用云服务融合的参考架构，三方结合阿里云八代裸金属（Intel）和八代的机密虚拟机实例，KMS，OSS，ACK/ACR 等云服务提供参考解决方案。通过 ACK TDX 机密沙箱容器实现端到端零信任的应用，数据和模型保护。通过 ACK 机密虚拟机节点池，企业无需对应用本身修改，直接部署云原生应用到机密虚拟机节点池，应用可以无缝切换高安全水位，支持多种机密计算场景，如金融风控、医疗健康数据隐私保护，AIGC/LLM 推理和微调，机密数据库，大数据应用等等。2）操作系统和 RunD 对 TDX 支持RunD 安全容器是龙蜥社区开源的下一代容器解决方案，包含 Rust Kata runtime 和Dragonball VMM。RunD 安全容器已经于 2022 年由龙蜥云原生 SIG 开源至 KataContainers 社区，且作为 Kata Container 3.0.0 release 的重要特性。目前龙蜥社区已经完成 Host OS、Guest OS 和 RunD 安全容器对 TDX 硬件的支持工作，并提供机密容器解决方案的端到端支持。机密计算容器前沿探索与 AI 场景应用1483）租户级的远程证明ACK 提供的多租户的远程证明服务提供了完整的租户级远程证明框架，用以支持建立用户对 TEE 从硬件到软件的全栈信任，从而实现注入密钥和证书注入等一系列关键的安全需求。达摩院操作系统实验室致力于研究远程证明架构对应用负载的完整可信，通过 AttestationAgent 运行在 TEE 内（这里的 TEE 主要包括机密虚拟机和机密沙箱内部）收集证据并发送给租户级服务 KBS，KBS 通过将证据转发给后端的 Attestation Service 对证据进行验证，然后向 TEE 内返回证明结果以及所需的秘密资源数据，从而达到对于应用负载，代码，配置，输入的安全度量。机密计算容器前沿探索与 AI 场景应用149远程证明体系整体采用模块化和插件化设计，以统一的软件架构兼容多种 TEE 平台。KBS通过 RESTful API 接收来自 TEE 或者租户的请求，在 KBS 内部我们实现了灵活的资源存储插件和 Attest Proxy 插件，从而允许在实际场景中对接不同的第三方存储服务和Attestation Service。在后端的 Attestation Service 中，集成了 OPA 实现的策略引擎以支持租户深度定制的证明策略。通过 ACK 应用市场可以实现远程证明服务的组件化部署和定制化。机密计算容器前沿探索与 AI 场景应用150在 ACK Pro 集群中可以通过部署远程证明服务，添加节点池，和部署运行时三个步骤来部署机密计算服务。通过选择 ECS 8 代 Intel 物理机来构建 TEE 的安全沙箱容器节点池，或者选择 ECS 8代 Intel 的虚拟机开启机密特性来构建 TEE 的机密虚拟机节点池。通过 ACK 应用市场，云原生的方式一键部署远程证明和代理服务实例，helm installcoco-kbs。通 过ACK应 用 市 场 部 署coco-operator来 提 供 两 种 新 的 容 器 运 行 时，kata-dragonball-tdx，kata-qemu-tdx 以及增强安全特性后的 runc，helm installcoco-operator。2.机密容器关键安全特性探索实践机密计算容器前沿探索与 AI 场景应用151来自英特尔中国软件与先进技术事业部的高级经理朱江云代表 ACK 机密容器生态合作重要伙伴，向观众分享了容器运维行安全的演进、机密容器关键安全特性的发展以及在 AI 等前沿领域的探索落地。容器的运行时，共享内核的 runc 仍然占据主流的部署；随着安全需求的提升，独立内核的沙箱容器出现带来了更好的隔离性和更小的攻击面，降低了宿主机和云厂商的安全风险；随着对用户数据隐私要求的进一步提升，硬件加密的客户机内存和硬件生成的客户机密钥，结合远程证明，进一步保护了客户的隐私数据和代码，避免了硬件所有者窥探计算过程中的数据。机密计算容器前沿探索与 AI 场景应用152机密容器（Confidential Containers）是云原生基金会（CNCF）旗下的一个沙箱项目，它使用硬件信任执行环境（TEE）为容器化的工作负载提供机密性和完整性。机密容器两大设计原则就是易用和安全。从易用性角度，无缝对接 Kubernetes 和容器生态，确保应用能够平滑迁移；从安全性角度，机密容器有着更严格的威胁模型，通过提供 Pod/VM 级TCB，对 IT 运维人员和云厂商也可以做到计算过程的零信任。结合 KMS，BYOK OSS，BYOK EBS，VPC，ACK，ACR 等云服务，端到端把零信任覆盖计算，存储和网络和配置，对所有 POD 之外的输入做验证，所有 POD 里的非应用组件做度量，实现完整的应用可信和安全加固。机密计算容器前沿探索与 AI 场景应用153为了确保 App 容器运行在可信运行时环境 不被恶意篡改，安全容器参考架构提供了可度量的 guest rootfs，并利用 dm-verity 通过远程证明服务提供根文件系统的完整性，并且保证了启动性能。为了确保 App 容器以期待的方式拉起，需要通过 OPA 策略定义和度量容器的元数据，包括：环境变量mount pointsOCI API机密计算容器前沿探索与 AI 场景应用154为了确保容器镜像的完整性，确保拉起过程中没有被恶意修改或者替换，使用镜像签名机制完成 镜像校验，从Key Broker Service 获得校 验密钥，校验Policy 并通过CoSign/sigstore,GPG key 等方式校验镜像的完整性。机密计算容器前沿探索与 AI 场景应用155为了保护镜像的机密性和不可窥探性，容器在运行时需要对主机不可见，通过镜像加密保证容器镜像对服务提供商不可获取，容器镜像在硬件 TEE 里下载和解密对运维人员不可见，加密后的容器镜像支持 OCI 和 distribution，支持按层加密和可选层加密主要针对模型和私有代码的保护，解密密钥在通过远程证明验证后发放只对 TEE 可见。安全的云上存储访问，存储相关的敏感信息以 sealedSecret 方式布署，敏感信息在 TEE环境中被解密，并且这个过程依赖于远程证明，而不依赖于外部存储的传统服务端加密服务，安全挂载服务使用相关机密信息来挂载和解密外部存储。3.基于机密容器构建可信 AI 应用生成式人工智能（AIGC）等创新浪潮驱动了人工智能的新一轮增长，模型训练和模型推理成为云服务器的重要负载。如何在云上保护大数据分析和人工智能应用的数据安全和隐私，是数据科学家和云服务提供商共同面临的挑战。为了应对这个问题，阿里云容器服务推出基于英特尔 TDX 的机密容器服务解决方案，通过 ACK TDX 机密容器实现端到端零信任的数据和模型保护，基于第四代英特尔 至强平台的 高级矩阵扩展（AMX）的 INT8（推理）和 BFloat16（训练/推理）内置 AI 加速能机密计算容器前沿探索与 AI 场景应用156力，可以实现高安全和高性价比的推理和微调服务：安全可信-通过加密 AI 模型存储和加密的私有应用镜像，保障模型数据的机密性与完整性，实现可信 AI 模型推理和微调高性价比-基于 Intel AMX 指令集和 Intel PyTorch 扩展，32 核可以实现秒级出图的推理能力低损耗-加密计算 TDX 性能损耗控制在 3%以下使用 BigDL LLM 在 ACK 机密容器上部署推理和模型调优，BigDL LLM 是 Intel 平台上的大语言模型加速库，结合数据加密和阿里云存储和密钥服务，全链路安全保护的分布式大语言模型安全，也可以全链路安全保护的大语言模型微调数据的安全，通过 BigDL 和ECS 8 代实例实现模型推理和微调的加速。4.容器是承载可信基础设施最好的平台服务云计算提供存储（BYOK 加密）和网络（非对称传输加密）的可信基础设施，发展到今天可信的计算（TDX/SEV/CCA）。大胆的猜测，可信的存储、网络、计算的基础设施必定成机密计算容器前沿探索与 AI 场景应用157为云计算的标配，而容器正是承载可信基础设施最好的平台服务，这也是我们为可信计算落地阿里云的初衷。Koordinator 助力云原生应用性能提升小红书混部技术实践158Koordinator 助力云原生应用性能提升小红书混部技术实践作者：张佐玮，阿里云技术专家、宋泽辉，小红书容器资源调度负责人编者按：Koordinator 是一个开源项目，是基于阿里巴巴内部多年容器调度、混部实践经验孵化诞生，是行业首个生产可用、面向大规模场景的开源混部系统，致力于提升应用服务质量，优化资源使用效率。自 2022 年 4 月正式开源以来，吸引了业界众多优秀工程师的贡献参与和讨论。小红书是 Koordinator 社区的活跃成员，自项目诞生初期就深度参与了一系列重要功能的演进。本文是基于 2023 云栖大会上关于 Koordinator 分享的实录，Koordinator 社区成员宋泽辉（小红书）、张佐玮（阿里云）为大家介绍了小红书混部技术实践以及 Koordinator的近期规划。1.背景介绍随着小红书业务的高速发展，各类在线，离线业务对于计算资源的需求也在快速增长。与此同时，部分在线集群天均利用率水位却维持在较低水平，造成这一现象的主要原因有以下几点：在线服务资源使用量随着终端用户的使用习惯呈现稳定的潮汐现象，夜间 CPU 利用率极低，导致集群均值 CPU 利用率较低；业务保有大量的独占资源池，资源池割裂产生大量的资源碎片，拉低 CPU 利用率；业务为了稳定性考虑，会过量囤积资源，进一步拉低 CPU 利用率；基于以上背景，为了帮助业务降低资源使用成本，提升集群 CPU 利用率，小红书容器团队从 2022 年开始，通过规模化落地混部技术来大幅提升集群资源效能，降低业务资源成本；Koordinator 助力云原生应用性能提升小红书混部技术实践1592.技术演进小红书混部技术演进分为以下四个阶段：阶段一：闲置资源再利用早期集群资源管理粗放，集群中存在大量业务独占资源池，因为资源碎片等因素存在大量低分配率的低效节点，散落在各个集群中的低效节点形成大量资源浪费。另一方面，部分基于 k8s 发布的转码类近线/离线场景，全天时段均存在大量计算资源需求。基于以上背景，容器平台通过技术手段将集群中的闲置资源收集起来，分配给转码类业务场景使用。我们通过 virtual-kubelet 打通元数据集群与物理集群，将闲置资源汇聚起来，在元数据集群分配给转码类场景近线/离线计算服务。策略方面，二次调度器负责巡检集群所有节点，识别为低效节点后标记出来，virtual-kubelet 获取物理集群中的低效节点可用资源作为集群闲置资源二次分配给离线转码，同时二次调度器需要保证一旦在线服务有资源需求，将会立刻驱逐离线 pod 并归还资源。Koordinator 助力云原生应用性能提升小红书混部技术实践160阶段二：整机腾挪分时复用搜推广等业务的独占资源池，CPU 利用率潮汐现象明显，夜间利用率极低，资源池中的单个节点往往也只部署一个大规格业务 Pod，基于以上背景，平台通过弹性能力（HPA），在凌晨业务低峰期按比例对在线业务缩容，腾挪空出整机，并将转码，训练等离线 pod 在该时段运行起来，起到利用率“填谷”的效果。具体实施时，需要确保在线服务能在规定的时间内全部被拉起，为此，策略方面我们实现了离线提前退场，并通过调度器抢占机制兜底，确保在线服务在业务高峰期来临之前能被全量及时拉起。Koordinator 助力云原生应用性能提升小红书混部技术实践161阶段三：常态混部为了降低资源碎片率，降低业务资源持有成本，平台持续推进业务大规模合池，将业务由独占池迁至平台托管的公共混部池，通过合池，资源超卖等技术手段，CPU 分配率得到有效提升，但依旧无法解决合并后的资源池夜间利用率较低等问题。另一方面，合池后的复杂混部场景下，整机腾挪分时混部离线的调度策略很难再继续实施，平台需要通过建设更为细粒度的资源管理与调度能力来实现均值利用率提升的目标，具体包含以下几点：调度侧：通过动态超卖技术获取可二次分配给离线的可用资源量，并抽象出离线资源视图让k8s 调度器感知到，调度器调度离线负载到对应节点上，实现离线对节点利用率的“填谷”效果；通过负载调度，尽可能避免在线服务被调度到高负载机器，让集群中节点负载更加均衡；Koordinator 助力云原生应用性能提升小红书混部技术实践162通过二次调度，驱逐负载热点机器上的高利用率服务，使得集群负载处于动态均衡状态；单机侧：支持 Qos(Quality of service)保障策略，根据服务的 Qos 等级提供差异化的运行时资源保障能力；支持干扰检测、离线驱逐等能力，当离线对在线敏感服务产生干扰时，第一时间驱逐离线；通过以上技术手段，可以有效保障服务混部时的稳定性，从而常态化的让在线离线工作负载混跑在节点上，实现利用率填谷效果的最大化。Koordinator 助力云原生应用性能提升小红书混部技术实践1633.架构设计与实现小红书容器资源调度架构设计如图所示：小红书各类业务场景通过各类发布平台、任务平台提交后，通过上层负载编排能力，以 pod形式下发到统一调度系统。统一调度系统基于不同的调度需求，对在线服务提供强保障的资源交付能力，差异化的 Qos 保障能力，对离线服务提供最小资源需求的保障能力和极致的弹性能力。调度侧：离线调度：coscheduling；二次调度：热点驱逐，碎片整理；Koordinator 助力云原生应用性能提升小红书混部技术实践164负载调度：基于 CPU 水位；资源视图：模拟调度；单机侧：压制策略：bvt 压制，内存驱逐；Qos 保障：绑核，超线程干扰抑制等；Batch 资源上报：batch 可用资源计算，上报；指标采集(from kernel)：psi，sched info 等；干扰检测：基于 cpi，psi，业务指标的干扰检测；1）离线调度资源视图离线服务资源调度的基本原理是基于在线服务负载感知能力的动态超卖，具体实现是将节点空闲资源二次分配给离线业务：其中离线可用资源为节点上的空闲资源（包含未分配资源和已分配未使用资源之和），扣除安全预留资源之后剩余资源，离线可用资源计算公式如下：将计算出的离线可用资源量按照时间分布后如图所示（图中绿色部分）：Koordinator 助力云原生应用性能提升小红书混部技术实践165实际落地过程中，为了避免离线可用资源随在线服务资源使用波动而大幅波动，从而影响离线资源质量和离线服务运行稳定性，通过资源画像对上述公式中的在线服务实际使用量数据进一步处理，去除数据噪点，最终计算出一个相对稳定的离线可用资源量（图中绿色部分），如图所示：Koordinator 助力云原生应用性能提升小红书混部技术实践1662）混部 QoS 保障策略QoS 分级按照业务对于服务质量（QoS:Quality of service）的需求，我们将小红书的业务类型简单的划分为三个 QoS 级别，如下表所示：Qos 等级说明业务场景latency-sensitive最高 Qos 保障等级，延迟极为敏感服务搜推广延迟极为敏感场景mid默认 Qos 保障等级，容忍部分干扰延迟网关，java 微服务batch最低 Qos 保障等级，延迟不敏感，资源随时可能被抢转码，spark，flink，训练等计算场景QoS 保障根据服务的 QoS 需求，节点侧会做 Pod 粒度的分级资源保障，实现各个资源维度差异化QoS 保障策略，具体的保障参数如下；资源特性latency-sensitivemidbatchCPUcpu burstenableenabledisable调度优先级最高默认低绑核share(默认)share(默认)reclaimedKoordinator 助力云原生应用性能提升小红书混部技术实践167numa强保证prefer（默认）noneL3 cache1000%（默认）30%（默认）内存带宽1000%（默认）30%（默认）内存OOM 优先级最低默认最高内存回收水线调高默认调低在 CPU 核调度层面，分别设置了三种绑核类型，并设计了一套精细化 CPU 核编排策略，分配示意图如下：Koordinator 助力云原生应用性能提升小红书混部技术实践168三种绑核类型分别为：exclusive（不推荐）特点：绑定 cpuset 调度域，CCD 感知，numa 绑定，独占排他场景：极为敏感的搜推广大规格延迟敏感服务share特点：绑定 cpuset 调度域，CCD 感知，numa（可选）绑定，share/exlusive 排他，可与 none 类型业务共享场景：容忍部分干扰的 Java 微服务，应用网关，web 服务reclaimed特点：无 cpuset 绑定，可能与非 exlusive 绑核模式业务共享核，核的分配完全交由内核，CPU 资源并非 100%能得到满足场景：batch 类离线服务，部分对延迟无要求的计算服务3）离线驱逐极端场景下，如整机内存使用率较高，有触发 OOM 风险，或者离线业务 CPU 长期得不到满足，单机侧支持按照离线服务内部定义的优先级配置，资源用量，运行时长等多维度综合算分排序后按序驱逐；4.离线业务场景小红书作为一个数亿用户的内容社区，其离线业务场景丰富多样，其中包含大量视频类，图片类转码场景，搜推，cv/nlp 算法推理训练，算法特征生产，数仓查询等离线场景，具体来讲，包含以下业务类型：近离线转码场景（已容器化）Koordinator 助力云原生应用性能提升小红书混部技术实践169Flink 流式/批式计算（已容器化）Spark 批式计算（容器化，on yarn）cv/nlp 算法回扫场景（已容器化）训练场景（已容器化）通过提供以 K8s 为底座的在离线统一调度能力，将这些离线业务与在线服务混合部署在统一计算资源池内，为在线服务提供差异化的资源质量保障，为离线服务提供海量的低层本算力，实现资源效能的提升。1）K8s 与 YARN 混部方案小红书内部商业化，社区搜索等业务存在大量的算法类 spark 任务因为离线集群资源紧张导致任务堆积，不能得到及时处理，同时在线集群在业务低峰时段资源使用率较低；另一Koordinator 助力云原生应用性能提升小红书混部技术实践170方面，相当占比的 spark 任务资源调度仍旧运行在 Yarn 调度器上，在这样的背景下，为了降低业务迁移成本，方案选型方面，我们选择与 kooridinator 社区合作，采用 Yarn onk8s 混部方案来快速落地 Spark 离线场景混部，具体方案如图所示：其中容器化的在线、离线工作负载通过 k8s 链路发布到在线集群内，Spark 作业通过 YarnResourceManager 调度到具体节点，并由节点上的 Nodemanager 组件拉起。其中Nodemanager 通过容器的方式部署在在线 k8s 集群内，除此之外，还涉及到以下组件：调度侧koord-yarn-operator：支持 k8s 与 yarn 调度器资源视图双向同步；节点侧copilot：NodeManager 操作代理，提供 Yarn Task 管控接口；Neptune-agent/koordlet：离线资源上报，节点离线 Pod/task 管理，冲突解决，驱逐，压制策略；Koordinator 助力云原生应用性能提升小红书混部技术实践171支持 K8s 与 YARN 混部的核心能力目前已经在社区研发完成，将于 11 月下旬，在Koordinator 1.4 版本进行发布。2）多调度器资源同步K8s 调度器与 YARN 调度器之间原本独立且相互不感知，为了共享分配在线集群节点上的总可用离线资源，需要通过 koord-yarn-operator 组件来做两个调度器之间的资源双向同步和协调，并实现两个同步链路：1K8s-YARN 调度器资源同步链路，负责同步 Yarn 视角离线资源总量，其中 YARN 离线资源总量计算如下：YARN 离线资源总量=离线总可用量-K8s 侧节点已分配1YARN-K8s 调度器资源同步链路，负责同步 YARN 已分配资源量，其中 k8s 离线资源总量计算如下：k8s 离线资源总量=离线总可用量-YARN 侧节点已分配基于各自节点离线资源视图，两个调度器分别做出调度决策，调度 K8s 离线 Pod 与 YARNTask 到节点上，由于同步过程不适合加锁，可能会出现资源被过量分配的问题：Koordinator 助力云原生应用性能提升小红书混部技术实践172具体解决措施是在单机侧增加了仲裁逻辑，当节点已分配离线服务资源量长期超过节点可用离线资源，且离线使用率持续较高，存在离线服务得不到资源被饿死的可能，单机侧则会根据离线服务的优先级，资源占用量，运行时长等因素综合算分并按序驱逐。3）阿里云 EMR 产品化支持与此同时，阿里云 EMR 团队在产品层面提供了混部功能的开发支持，在兼容 EMR 原有日志，监控，运维逻辑的基础上，支持了 k8s 集群弹性扩缩容 NodeManager Pod 的能力。Koordinator 助力云原生应用性能提升小红书混部技术实践1735.落地收益截止目前，小红书混部能力覆盖数十万台机器规模，覆盖算力规模数百万核，支持数万规模在线、离线场景服务的资源调度。通过大规模容器混部的持续推进，小红书在资源成本效能等方面都取得了显著收益，具体包含以下两方面：CPU 利用率在保证在线服务服务质量的前提下，在线混部集群天均 CPU 利用率提升至 45%以上，部分集群天均 CPU 利用率可稳定提升至 55%。通过在离线混部等技术手段，在线集群 CPU 利用率提升 8%-15%不等，部分存储集群CPU 利用率提升可达 20%以上。资源成本在保证离线业务稳定性的前提下，为小红书各类离线场景提供数百万核时的低成本算力。混部集群 CPU 分配率提升至 125%以上，相较于独占资源池，资源碎片率明显下降。6.社区共建历程小红书是早期参与 Koordinator 社区的公司之一，2022 年 4 月，Koordinator 正式开源，同年 6 月，小红书内部启动了在离线混部项目，开始参与 Koordinator 方案设计与代码提Koordinator 助力云原生应用性能提升小红书混部技术实践174交。2022 年 8 月，小红书与社区共建了 runtime-proxy 组件，并在内部场景落地。2023年 4 月，小红书在社区主导启动了 YARN 与 K8s 混部项目，2023 年 8 月，该方案在小红书内规模化落地。截止目前，依托 Koorindiator 的助力，小红书的混部已经覆盖公司数万台节点，提供数十万核离线资源，整体混部集群的利用率提升至 45%以上。取得了不错的落地效果。7.总结与展望在小红书近一年多混部技术探索过程中，我们在资源效能提升方面积累了较为丰富的落地经验，并取得了不错的提升效果，随着公司业务规模逐步增长，场景愈发复杂，我们将会面临诸多新的技术挑战。下个阶段我们的目标是建设面向混合云架构的统一资源调度能力，具体工作将围绕以下三方面展开：混合工作负载调度能力支持：包括大数据，AI 在内的任务型工作负载调度能力建设，满足小红书所有业务场景的资源调度功能，性能需求；资源效能进一步提升：面向混合云架构，推进更大规模的资源合池，推进 quota 化资源交付，通过更加激进的弹性，混部，超卖等技术手段，实现集群资源利用率的进一步提升，资源成本的大幅下降；更高服务质量保障能力：在更为激进的 CPU 利用率目标背景下，通过建设 Qos 感知调度能力，干扰检测能力，依托安全容器等技术手段，解决深水区混部中可能遇到的各类混部干扰问题；8.Koordinator 社区近期规划再接下来的几个版本中，Koordinator 将在以下几个方面进行重点投入：调度器性能优化：支持等价类调度，通过合并 request 相同的 pod，避免 filter、score等调度过程的重复计算。Koordinator 助力云原生应用性能提升小红书混部技术实践175Network QoS：网络维度容器服务质量，保障高优先级带宽，设计 request/limit 模型，保障最低带宽需求。大数据负载：支持 Gang 调度原子抢占，按分组整体抢占 Pod；面向 Hadoop YARN任务的 QoS 策略适配。资源干扰检测：基于底层指标、感知容器资源竞争情况，识别异常 Pod，消除干扰并反馈调度链路。轻松搭建基于服务网格的 AI 应用，然后开始玩176轻松搭建基于服务网格的 AI 应用，然后开始玩作者：尹航，阿里云研发工程师在 2023 年的云栖大会中，阿里云服务网格 ASM 推出了两全其美：Sidecarless 与Sidecar 模式融合的服务网格新形态主题演讲，并在演讲中展示了一个基于服务网格ASM 各项能力构建的 DEMO AI 应用。该应用集中展示了 ASM 在模型服务、请求处理、请求路由和安全中心集成单点登录等各项能力，且这些能力还完全是以 Sidecarless 的形态来实现的。轻松搭建基于服务网格的 AI 应用，然后开始玩177看完我们的演示，您也许也会想尝试一下，从零开始构建这样的一个应用来玩玩吧！当然！我们向您保证，我们能搭出来的东西，您一定也能搭出来。本文就是这样一篇给各位的入门指引，我们这就开始吧！1.从零开始搭建一个基于服务网格 ASM 的 AI 应用前提条件轻松搭建基于服务网格的 AI 应用，然后开始玩178一个 ACK 集群、一个 ASM 实例以及相关的 istioctl 等工具是一切的根基，我们先来准备一些实验环境。已创建 ASM 实例，且实例版本在 1.18.0.131 及以上。具体操作，请参见创建 ASM实例1。在创建服务网格页面配置数据面模式时，选中启用 Ambient Mesh 模式。已创建 Kubernetes 集群，且满足 Kubernetes 集群及配置要求2。关于创建集群的具体操作，请参见创建 Kubernetes 专有版集群3或创建 Kubernetes 托管版集群4。已添加集群到 ASM 实例。具体操作，请参见添加集群到 ASM 实例5。已按照实际操作系统及平台，下载 Istioctl 服务网格调试工具。详细信息，请参见Istio6。搭建模型推理服务1）开启 ASM 的多模型推理服务生态集成能力对于一个基于 AI 模型推理的应用服务来说，将训练好的模型快速转化为弹性、灵活的模型推理服务无疑是工作的重心之一。作为应用感知的下一代云原生基础设施，服务网格 ASM 也通过其丰富的生态集成能力、集成了云原生推理服务框架 KServe（参考 ASM 集成云原生推理服务框架 KServe7）、为 AI 模型推理的服务化提供了一站式解决方案。在服务网格 ASM 的最新版本中，我们 alpha 阶段地引入了模型推理服务集成的多模型服务框架（modelmesh）。在全新的 modelmesh 服务框架之内，不同的模型、其推理将交给多个运行时工作负载来完成。每个运行时支持不同的模型格式；并且可以同时提供多个模型的推理服务。当我们使用 InferenceService 资源定义一个模型后，模型文件将根据模型的格式、动态地加载到对应的运行时工作负载之中。一个运行时可以同时提供多轻松搭建基于服务网格的 AI 应用，然后开始玩179个模型的推理服务。我们可以通过以下步骤来集成多模型推理服务框架 modelmesh：在 ASM 实例中创建一个名为 modelmesh-serving 的全局命名空间（参考管理全局命名空间8）要使用这个能力，我们首先使用 kubectl 连接到 ASM 实例（参考通过控制面kubectl 访问 Istio 资源9）使用以下这个文件，创建 asmkserveconfig.yamlapiVersion: kubectl 执行以下命令，打开模型推理服务框架集成kubectl apply-f asmkserveconfig.yaml执行完此步骤后，我们可以看到 ACK 集群中出现一个 modelmesh-serving 命名空间，内部包含有模型推理 Servicemodelmesh-serving、以及提供服务的各种运行时工作负载，这就代表模型推理服务已经就绪。轻松搭建基于服务网格的 AI 应用，然后开始玩1802）准备模型文件，声明推理服务模型推理服务框架就绪后，接下来我们需要准备好训练的模型文件，并将模型加载到运行时工作负载中，成为可以对外暴露的推理服务。a.准备模型文件机器学习模型在经过训练后，可以通过各种序列化方式被保存下来（例如：saved_model、pkl 等），模型推理服务器可以加载并利用这些模型文件对外提供训练好的机器学习模型的推理服务。在本 DEMO 应用中，我们也需要准备这样的模型文件。事实上，我们准备了两个训练好的模型。这两个模型分别基于 tensorflow 与 pytorch，其中 pytorch 模型生成的图片风格固定，而 tensorflow 模型可以抽取图片风格，进行不同的风格化处理。轻松搭建基于服务网格的 AI 应用，然后开始玩181模型的获取也非常简单，不需要大家去自己训练了。我们只需要通过 Tensorflow 和Pytorch 的官方渠道即可获取了。TensorFlow模 型 可 通 过Tensorflow Hub获 取，访 问 这 里 来 下 载：https:/tfhub.dev/google/magenta/arbitrary-image-stylization-v1-256/2至于 Pytorch 模型，我们在本例中使用了官方 DEMO 例子中的模型，并将其转换成了ONNX格 式。我 们 可 以 参 考 这 个 教 程 来 下 载 并 转 换 模 型 文 件：https:/pytorch.org/tutorials/advanced/ONNXLive.html（注意：在转换成 ONNX模型的一步，我们是使用了 512*512 的图片作为输入，注意输入图片尺寸，这个对ONNX 格式的模型很重要）。demo 中提供四种固定风格的模型，我们可以任选一款，在我们的 demo 中选择了 candy 模型。下载到本地后，我们随便找个路径作为根目录，新建一个 tensorflow 文件夹和一个pytorch 文件夹，分别保存两个模型的文件。我们将两个模型的模型文件保存成如下的文件夹结构，方便后续操作。Tensorflow 模型大概长这样：Pytorch 模型则是这样的：在根目录运行 ls-R 指令，可以看到如下的文件结构：$ls-Rpytorchtensorflow./pytorch:轻松搭建基于服务网格的 AI 应用，然后开始玩182style-transfer./pytorch/style-transfer:candy.onnx./tensorflow:style-transfer./tensorflow/style-transfer:saved_model.pb variables./tensorflow/style-transfer/variables:variables.data-00000-of-00002variables.data-00001-of-00002variables.indexb.将模型文件加载到 PVC首先创建一个存储类，前往容器服务控制台的 存储 存储类，创建一个存储类：轻松搭建基于服务网格的 AI 应用，然后开始玩183接着创建 PVC，前往容器服务控制台 存储 存储声明，用刚刚创建的存储类来创建一个存储声明 PVC，名字就叫 my-models-pvc。轻松搭建基于服务网格的 AI 应用，然后开始玩184c.创建一个 pod 用来将模型文件拷贝到 PVC 里前往容器服务控制台的工作负载 容器组，点击“使用 YAML 创建”，并在 YAML 框中输入以下内容，点击“创建”来创建一个 pod。apiVersion:v1kind:Podmetadata:name:pvc-accessnamespace:modelmesh-servingspec:containers:-name:mainimage:ubuntucommand:/bin/sh,-ec,sleep 10000volumeMounts:-name:my-pvcmountPath:/mnt/modelsvolumes:-name:my-pvc轻松搭建基于服务网格的 AI 应用，然后开始玩185persistentVolumeClaim:claimName:my-models-pvcd.使用 kubectl cp 将模型文件通过 pod 拷贝进 PVC首先使用 kubectl 连接至 ACK 集群（参考获取集群 KubeConfig 并通过 kubectl 工具连接集群10）。接下来在刚才的模型文件根目录处，打开命令行，运行以下指令：kubectl cp-n modelmesh-serving tensorflow pvc-access:/mnt/models/kubectl cp-n modelmesh-serving pytorch pvc-access:/mnt/models/接下来执行以下命令，确定拷贝已经成功：kubectl exec-n modelmesh-serving pvc-access-ls/mnt/models预期得到以下内容，就说明模型文件已经被拷贝到 PVC 里了。pytorchtensorflowe.使用 InferenceService 自定义资源创建模型推理服务使用以下内容，创建 isvc.yaml 文件apiVersion:serving.kserve.io/v1beta1kind:InferenceServicemetadata:name:tf-style-transfernamespace:modelmesh-servingannotations:serving.kserve.io/deploymentMode:ModelMesh#serving.kserve.io/secretKey:myossspec:轻松搭建基于服务网格的 AI 应用，然后开始玩186predictor:model:modelFormat:name:tensorflowstorage:parameters:type:pvcname:my-models-pvcpath:tensorflow/style-transfer/-apiVersion:serving.kserve.io/v1beta1kind:InferenceServicemetadata:name:pt-style-transfernamespace:modelmesh-servingannotations:serving.kserve.io/deploymentMode:ModelMeshspec:predictor:model:modelFormat:name:onnxstorage:parameters:type:pvcname:my-models-pvcpath:pytorch/style-transfer/isvc.yaml 中声明了两个 InferenceService，分别对应 Tensorflow 和 Pytorch 模型的推理服务声明。使用以下命令，在 ACK 集群中创建模型推理服务。kubectl apply-f isvc.yaml轻松搭建基于服务网格的 AI 应用，然后开始玩187我们可以观察到在集群中，支持 Tensorflow 和 Pytorch 这两个模型的运行时工作负责Pod 被动态扩容拉起，并开始加载对应支持格式的模型。在此 DEMO 示例中，我们用InferenceService 分别声明了 Tensorflow 和 ONNX 格式的模型文件，因此，可以看到，对应拉起的运行时是 triton-2.x 运行时和 ovms-1.x 运行时。当运行时启动与模型加载都完成后，使用 kubectl 获取 InferenceService，可以看到两个 InferenceService 也都对应处于就绪状态：$kubectl get isvc-n modelmesh-servingNAMEURLREADYPREVLATESTPREVROLLEDOUTREVISIONLATESTREADYREVISIONAGEpt-style-transfergrpc:/modelmesh-serving.modelmesh-serving:8033True11dtf-style-transfergrpc:/modelmesh-serving.modelmesh-serving:8033True11d3）在集群中部署业务服务在模型推理服务的前面就是我们的业务服务了，分别是 style-transfer 业务服务和最前方轻松搭建基于服务网格的 AI 应用，然后开始玩188的 AI 应用服务，我们接下来就需要在集群中部署这些服务以及服务的工作负载。a.使用 kubectl 连接到 ACK 集群，并使用如下命令创建一个命名空间来部署应用kubectl create namespace apsara-demob.使用以下内容，创建 ai-apps.yaml 文件apiVersion:v1kind:ServiceAccountmetadata:name:ai-backendnamespace:apsara-demo-apiVersion:v1kind:ServiceAccountmetadata:name:style-transfernamespace:apsara-demo-apiVersion:apps/v1kind:Deploymentmetadata:labels:app:ai-backendname:ai-backendnamespace:apsara-demospec:progressDeadlineSeconds:600replicas:1revisionHistoryLimit:10selector:matchLabels:app:ai-backendstrategy:rollingUpdate:轻松搭建基于服务网格的 AI 应用，然后开始玩189maxSurge:25%maxUnavailable:25%type:RollingUpdatetemplate:metadata:labels:app:ai-backendspec:serviceAccountName:ai-backendcontainers:-image:- AI 应用，然后开始玩190spec:progressDeadlineSeconds:600replicas:1revisionHistoryLimit:10selector:matchLabels:app:style-transfermodel-format:tensorflowstrategy:rollingUpdate:maxSurge:25%maxUnavailable:25%type:RollingUpdatetemplate:metadata:labels:app:style-transfermodel-format:tensorflowspec:serviceAccountName:style-transfercontainers:-image:- AI 应用，然后开始玩191requests:cpu:250mmemory:512MiterminationMessagePath:/dev/termination-logterminationMessagePolicy:FilednsPolicy:ClusterFirstrestartPolicy:AlwaysschedulerName:default-schedulersecurityContext:terminationGracePeriodSeconds:30-apiVersion:apps/v1kind:Deploymentmetadata:labels:app:style-transfername:style-transfer-torchnamespace:apsara-demospec:progressDeadlineSeconds:600replicas:1revisionHistoryLimit:10selector:matchLabels:app:style-transfermodel-format:pytorchstrategy:rollingUpdate:maxSurge:25%maxUnavailable:25%type:RollingUpdatetemplate:metadata:labels:app:style-transfermodel-format:pytorchspec:serviceAccountName:style-transfer轻松搭建基于服务网格的 AI 应用，然后开始玩192containers:-image:- AI 应用，然后开始玩193ipFamilies:-IPv4ipFamilyPolicy:SingleStackports:-name:httpport:8000protocol:TCPtargetPort:8000selector:app:ai-backendtype:ClusterIP-apiVersion:v1kind:Servicemetadata:labels:app:style-transfername:style-transfernamespace:apsara-demospec:internalTrafficPolicy:ClusteripFamilies:-IPv4ipFamilyPolicy:SingleStackports:-name:httpport:8000protocol:TCPtargetPort:8000selector:app:style-transfersessionAffinity:Nonetype:ClusterIPc.使用 kubectl 执行以下命令来部署上方文件中声明的应用服务kubectl apply-f ai-apps.yaml轻松搭建基于服务网格的 AI 应用，然后开始玩1944）创建 ASM 网关、waypoint 网格代理，并部署生效流量规则部署的最后一部分都有关服务网格，具体来说有以下部分：ASM 入口网关。网格 waypoint 代理，它是 Sidecarless 的服务网格能力载体。服务网格流量规则，这些规则将生效到 ASM 网关和 waypoint 代理，保证流量路径按照我们的设计运行。a.部署 ASM 入口网关我们可参考创建入口网关11，来创建 ASM 入口网关。我们需要创建两个 ASM 入口网关，其中一个叫 api-ingresgateway，服务类型为 LoadBalancer，网关上需要开启 80端口；另一个叫 ingressgateway，服务类型为 ClusterIP，网关上需要开启 8008 端口。其余网关配置保持默认即可。都创建完成后，我们应该可以在 ASM 入口网关页面看到这样的显示：b.开启 apsara-demo 命名空间的 Ambient Mesh 模式登录 ASM 控制台12，在左侧导航栏，选择服务网格 网格管理。在网格管理页面，单击目标实例名称，然后在左侧导航栏，选择网格实例 全局命名轻松搭建基于服务网格的 AI 应用，然后开始玩195空间。在全局命名空间页面，单击从 Kubernetes 集群同步自动注入，选择数据面 ACK 集群后单击确定。在全局命名空间页面的数据面模式列，单击 apsara-demo 命名空间对应的切换为Ambient Mesh 模式，然后在确认对话框，单击确定。c.部署 waypoint 代理使用 kubectl 连接到 ACK 集群，然后使用前提条件中安装的 istioctl 工具，执行以下指令：istioctl x waypoint apply-service-account style-transfer-n apsara-demo执行完成后，我们可以使用 kubectl 列出集群中的无状态工作负载。kubectl get deploy-n apsara-demo预期输出：NAMEREADYUP-TO-DATEAVAILABLEAGEai-backend1/11113dstyle-transfer-istio-waypoint1/11113dstyle-transfer-tf1/11113dstyle-transfer-torch1/11113d可以看到集群中除了我们刚才部署的 AI 应用以及 style-transfer 应用的工作负载外，还轻松搭建基于服务网格的 AI 应用，然后开始玩196增加了一个名为style-transfer-istio-waypoint 的工作负载，这就是服务网格的waypoint 代理，它是以独立的工作负载方式部署在集群中的，所提供的所有能力也都是Sidecarless 的。d.部署服务网格规则 使用以下内容，创建 modelsvc-routing.yaml 文件#make sure voyage is 1.13.4.13 or higherapiVersion:networking.istio.io/v1beta1kind:Gatewaymetadata:name:grpc-gatewaynamespace:modelmesh-servingspec:selector:istio:ingressgatewayservers:-hosts:-*port:name:grpcnumber:8008protocol:GRPC-hosts:-*port:name:httpnumber:80protocol:HTTP-apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:vs-modelmesh-serving-service轻松搭建基于服务网格的 AI 应用，然后开始玩197namespace:modelmesh-servingspec:gateways:-grpc-gatewayhosts:-*http:-headerToDynamicSubsetKey:-header:x-model-format-tensorflowkey:model.format.tensorflow-header:x-model-format-pytorchkey:model.format.pytorchmatch:-port:8008name:defaultroute:-destination:host:modelmesh-servingport:number:8033-apiVersion:networking.istio.io/v1beta1kind:DestinationRulemetadata:name:dr-modelmesh-serving-servicenamespace:modelmesh-servingspec:host:modelmesh-serving-servicetrafficPolicy:loadBalancer:dynamicSubset:subsetSelectors:-keys:-model.format.tensorflow-keys:-model.format.pytorch-apiVersion: AI 应用，然后开始玩198kind:ASMGrpcJsonTranscodermetadata:name:grpcjsontranscoder-for-kservepredictv2namespace:istio-systemspec:builtinProtoDescriptor:kserve_predict_v2isGateway:trueportNumber:8008workloadSelector:labels:istio:ingressgateway-apiVersion:networking.istio.io/v1alpha3kind:EnvoyFiltermetadata:labels:asm-system:trueprovider:asmname:grpcjsontranscoder-increasebufferlimitnamespace:istio-systemspec:configPatches:-applyTo:LISTENERmatch:context:GATEWAYlistener:portNumber:8008proxy:proxyVersion:1.*patch:operation:MERGEvalue:per_connection_buffer_limit_bytes:100000000workloadSelector:labels:istio:ingressgateway轻松搭建基于服务网格的 AI 应用，然后开始玩199modelsvc-routing.yaml 中主要包含的是针对集群中的模型推理服务的流量规则。这主要包含两部分规则：针对模型推理服务中不同运行时工作负载的动态子集路由能力高针对 kserve v2 推理接口的 JSON/HTTP-gRPC 请求转码能力我们将在下一个大章节介绍这些能力的细节。使用 kubectl 连接 ASM 实例，执行以下命令，部署 modelsvc-routing 流量规则kubectl apply-f modelsvc-routing.yaml 使用以下内容，创建 app-routing.yaml 文件apiVersion:networking.istio.io/v1beta1kind:Gatewaymetadata:name:ai-app-gatewaynamespace:apsara-demospec:selector:istio:api-ingressgatewayservers:-hosts:-*port:name:httpnumber:8000protocol:HTTP-hosts:-*port:name:http-80number:80轻松搭建基于服务网格的 AI 应用，然后开始玩200protocol:HTTP-apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:ai-app-vsnamespace:apsara-demospec:gateways:-ai-app-gatewayhosts:-*http:-route:-destination:host:ai-backend-svcport:number:8000-apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:style-transfer-vsnamespace:apsara-demospec:hosts:-style-transfer.apsara-demo.svc.cluster.localhttp:-match:-headers:user_class:exact:premiumroute:-destination:host:style-transfer.apsara-demo.svc.cluster.localport:number:8000subset:tensorflow轻松搭建基于服务网格的 AI 应用，然后开始玩201-route:-destination:host:style-transfer.apsara-demo.svc.cluster.localport:number:8000subset:pytorch-apiVersion:networking.istio.io/v1beta1kind:DestinationRulemetadata:name:style-transfer-drnamespace:apsara-demospec:host:style-transfer.apsara-demo.svc.cluster.localsubsets:-labels:model-format:tensorflowname:tensorflow-labels:model-format:pytorchname:pytorchapp-routing.yaml 中主要包含的是对 AI 应用服务和 style-transfer 服务的路由规则。其中包括一个对 style-transfer 不同工作负载进行根据用户身份分流的能力。使用 kubectl 连接 ASM 实例，执行以下命令，部署 app-routing 流量规则kubectl apply-f app-routing.yaml 将 ASM 网关对接阿里云 iDaas 应用身份服务，轻松实现单点登录搭建整个应用的最后一步位于应用的总入口，也就是 ASM 入口网关。在这里，我们还需要将网关与阿里云 iDaas 的 OIDC 应用进行对接，对整个应用进行一个单点登录的配置。我们可以参考这篇文档来进行对接的操作：ASM 集成阿里云 IDaaS 实现网格内应用单点轻松搭建基于服务网格的 AI 应用，然后开始玩202登录13。值得注意的是，我们使用用户 jwt claim 中的额外字段 user_type 来完成用户身份的识别，这需要进行如下操作：点击云身份服务的扩展字段，添加扩展字段（扩展字段名称和 OIDC 登陆后返回的字段名称均可以自定义，这里扩展字段定义为 user_type，OIDC 登陆后返回字段名称会在后面定义为 user_class）：然后编辑用户信息，为指定用户设置该字段：轻松搭建基于服务网格的 AI 应用，然后开始玩203设置好该字段后，需要配置在 OIDC 登陆成功后，返回该字段。进入 OIDC 应用设置，点击登录访问 tab，点击“显示高级配置”。在这里设置新增一个 OIDC 登陆成功后返回的key-value 对，key 是 user_type，value 是 user_class 的值。我们披星戴月我们奋不顾身，终于！我们的 AI 应用搭好了！可以看到，从零开始搭建这样一套集成了模型推理的业务服务确实不能一步登天，不过服务网格 ASM 在这其中通过一些生态集成的能力，以及完善的 Web UI，将很多步骤进行了简化。3）Try it out！在 ASM 控制台的网格管理页面，我们可以直接看到 api-ingressgateway 的服务地址：轻松搭建基于服务网格的 AI 应用，然后开始玩204整个应用的访问入口就是 http:/ASM 网关服务地址/home。用浏览器打开它，就可以开始玩我们的 AI 应用了2.服务网格如何帮助我们这个章节会简要介绍在这个 DEMO 中，服务网格 ASM 开启了怎样的一些能力，帮助我们做到更多。也就是我们在云栖大会中为大家介绍的内容。1）针对模型服务运行时的动态子集路由在 AI 应用的构建中，如何将训练好的模型转化为可靠的推理服务是工作的重心，因此我们首先介绍这个 DEMO 中的模型推理服务。在模型推理服务的整体框架中，由一个整体的 k8s Service 对外提供所有模型的推理。然而，模型有很多格式种类、如何将类似 sklearn、tensorflow、pytorch 等等不同种类的模型统一成 API 相同的推理服务呢？这就要使用不同的运行时。在统一的模型推理 Service 之下，不同的模型、其推理将交给多个运行时工作

0人已浏览 2023-12-15 243页 5星级

点击查看更多后浪研究所：2023年轻人玩转AI报告（11页）.pdf精彩内容。

0人已浏览 2023-12-14 11页 5星级

敬请参阅最后一页特别声明 1 本周化工市场综述本周化工市场综述 AI 方面，本周行业变化不小，包括谷歌推出大模型 Gemini、AMD 发布 MI300X 加速器、联想在首届 AI PC 产业创新论坛. 

0人已浏览 2023-12-14 25页 5星级

敬请参阅末页重要声明及评级说明 证券研究报告 美图发布自研视觉大模型美图发布自研视觉大模型 4.0，Gemini 多模态时代开启多模态时代开启 Table_IndNameRptType 海外科技海外.

0人已浏览 2023-12-14 39页 5星级

 请仔细阅读在本报告尾部的重要法律声明 Gemini 引爆多模态 AI 概念，数据要素景气度向上 计算机行业周报 本周观点本周观点:一、一、GeminiGemini 引爆多模态引爆多模态 AIAI 概.

0人已浏览 2023-12-14 30页 5星级

行业动态跟踪报告 多模态能力表现亮眼，谷歌携 Gemini 王者归来行业动态跟踪报告 请通过合法途径获取本公司研究报告，如经由未经许可的渠道获得研究报告，请慎重使用并注意阅读研究报告尾页的声明内容。行.

0人已浏览 2023-12-14 10页 5星级

本公司具备证券投资咨询业务资格，请务必阅读最后一页免责声明 证券研究报告 1 计算机周报 20231210 谷歌 Gemini 大模型预示三大 AI 机会方向 2023 年 12 月 10 日 市场回.

0人已浏览 2023-12-14 21页 5星级

中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院前言为推进知识图谱与大模型在企业级的落地应用，分析知识图谱与大模型融合技术路径，研究报告从知识图谱与大模型落地面临的瓶颈出发，分析了知识图谱与大模型的主要特征、知识图谱与大模型擅长的主要场景和核心基础能力，对比了知识图谱与大模型的优劣势，进而从技术演化层面、技术互补层面、知识库建设层面探讨了知识图谱与大模型融合的可行性及收益。同时，研究报告分析了知识图谱与大模型融合的技术路径及其关键技术，研究了知识图谱与大模型融合系统评测体系，对比了实际融合系统与大模型的性能测试结果。最终，通过梳理已有11个领域的实践案例，给出了技术挑战与发展展望。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明来源为“中国电子技术标准化研究院”或对应案例提供单位，且不得对本报告进行有悖原意的删减与修改。由于知识图谱与大模型技术发展迅速，研究报告编制时间和作者学识限制，恐有纰漏或不严谨之处，敬请谅解和批评指正。研究报告编写组中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院参编单位及人员中国电子技术标准化研究院郭楠、韩丽、李瑞琪、李湘、胡成林、陈艳利中国电信股份有限公司研究院石晓东、赵龙刚、孙佩霞南京柯基数据科技有限公司杨成彪、吴刚、魏爱梅北京海致科技集团有限公司瞿珂、李思宇、胡嘉彦中译语通科技股份有限公司陈自岩、彭旋沈阳东软智能医疗科技研究院有限公司程万军北京文因互联科技有限公司张屹、李亚军中电科大数据研究院有限公司曹扬、孔德智、熊子奇、尹杨、闫盈盈北京京航计算通讯研究所马静、郝创博、白洋、张彤中科知道（北京）科技有限公司吴章生、李海英、王海波北京中企智造科技有限公司蔡志伟、张燕浪潮软件科技有限公司张峰、王珂琛杭州海康威视数字技术股份有限公司姜伟浩、赵宏、吴炎、吴鹏亮广州柏视医疗科技有限公司刘涛、颜子夜豪尔赛科技集团股份有限公司张丰、刘姝、戴聪棋电科云（北京）科技有限公司方正、王尚帅云从科技集团股份有限公司李军网智天元科技集团股份有限公司贾承斌厦门渊亭信息科技有限公司洪万福、潘璐阳、朱成忠国际商业机器（中国）有限公司（IBM）初德高青岛海尔科技有限公司王先庆、鄂磊、鞠剑伟浪潮电子信息产业股份有限公司李仁刚、贾麒、范宝余北京三快在线科技有限公司黄坤、刘瑾、李轩深圳市矽赫科技有限公司洪鹏辉、洪宝璇、林叠守同方知网数字出版技术股份有限公司万敏锋、相生昌、周永中国电力科学研究院有限公司徐建南、徐会芳、张英强浙江创邻科技有限公司周研、马超湖北汽车工业学院龚家元泰瑞数创科技（北京）股份有限公司刘俊伟、罗伊莎 国电南瑞科技股份有限公司张万才 石超 施雨南京航空航天大学周福辉、袁璐、宋熙富泰华工业（深圳）有限公司史喆、张学琴各章节编辑中国南方电网超高压输电公司李强：第一章中国电信股份有限公司研究院 石晓东第二章网智天元科技集团股份有限公司 贾承斌第三章南京柯基数据科技有限公司 杨成彪第四章厦门渊亭信息科技有限公司 潘璐阳第五章中国电子技术标准化研究院 李瑞琪第六章青岛海尔科技有限公司 王先庆中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院参编单位及人员中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院第一章 背景中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院知识图谱Knowledge Graph-KG国家标准及研究报告学者/机构以结构化形式描述的知识元素及其联系的集合。1知识图谱以结构化的形式描述客观世界中概念、实体及其关系，将互联网的信息表达成更接近人类认知世界的形式，提供了一种更好地组织、管理和理解互联网海量信息的能力。2知识图谱本质上是一种叫作语义网络的知识库，即一个具有有向图结构的知识库。3维基百科：对事实和数字的组合，谷歌将其用于为搜索提供了上下文意义。谷歌于2012年推出，使用维基百科、维基数据和其他来源的数据。百科百度百科：在图书情报界称为知识域可视化或知识领域映射地图，是显示知识发展进程与结构关系的一系列各种不同的图形，用可视化技术描述知识资源及其载体，挖掘、分析、构建、绘制和显示知识及它们之间的相互联系。图结构化形式可呈现为有向图结构化的形式谷歌：知识图谱是一个知识库，其使用语义检索从多种来源收集信息，以提高Google搜索的质量。61GB/T 42131-2022信息技术 人工智能 知识图谱技术框架2中国中文信息学会语言与知识计算专委会，知识图谱发展报告(2018)3漆桂林,高桓,吴天星.知识图谱研究进展J.情报工程,2017,3(1):004-0254王昊奋,漆桂林,陈华钧.知识图谱:方法,实践与应用J.自动化博览,2020(1).DOI:CNKI:SUN:ZDBN.0.2020-01-014.5 L.Ehrlinger and W.Wo,“Towards a definition of knowledge graphs,”SEMANTiCS(Posters,Demos,SuCCESS),vol.48,pp.14,2016.6https:/blog.google/products/search/introducing-knowledge-graph-things-not/Farber：知识图谱是一种资源描述框架（RDF）图，可用于描述任何基于图的知识库。5知识图谱旨在建模、识别、发现和推断事物、概念之间的复杂关系，是事物关系的可计算模型。4高效的检索能力可将概念、实体及其关系结构化组织起来，具有高效检索能力智能化推理能力可从已有知识中挖掘和推理多维的隐含知识附1：海外学者在知识图谱领域相关研究1.知识图谱的定义与发展历程知识图谱的定义知识图谱与传统知识库相比具有的三大特征中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院加菲尔德提出引文索引的思想1955普莱斯引文网络分析1965Quillian语义网络提出最早的表达人类知识1968Feigenbaum知识工程提出专家系统开始广泛研究与应用1977Douglas Lenat建立Cyc知识库1984Tim Berners Lee提出语义网概念，是后续知识图谱的基础1998首届国际语义网大会（ISWC）召开，该会议延续至今，在国际上具有很高的学术影响力2002W3C将RDF和OWL纳入标准，并在后续不断更新，包括RDFS、SPAQL等逐渐填充进入，形成丰富的语义网技术栈 2004Tim Berners Lee提出linked Open Data2006Dbpedia知识库建立2007Schema.org建立2011Google正式提出知识图谱（Knowledge Graph,KG）概念同年，Wikidata项目启动2012首个KG嵌入方法TransE提出,推动了后续包括图神经网络等KG推理方法飞速发展2013OpenKG组织成立2015首届CCKS大会召开2016事理图谱概念提出，强调了KG对事件的顺承、因果等复杂认知能力的建模2018RichPedia作为多模态KG发布，代表KG进入新时代2020首个知识图谱国标发布20221.知识图谱的定义与发展历程知识图谱发展历程中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院具有涌现能力在特定任务上，随着模型规模提升模型性能突然出现显著提升大模型与传统模型相比具有三大特征2参数规模庞大参数规模不少于十亿（1B），严格意义上需超过一百亿（10B）2权威论文中大模型的定义具有通用性能够仅通过提示、微调适应广泛的下游任务2.大模型的定义与发展历程大模型的定义大模型通常是指参数规模在一百亿（10B）以上，使用大规模的训练数据，具有良好的涌现能力，并在各种任务上达到较高性能水平的模型。2狭 义 上：大模型是指参数数量大、结构复杂的深度学习模型，具备涌现能力、通用能力，并能够处理复杂的下游任务，如自然语言处理、图像识别等。广 义 上：中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院AlexNet为代表的新一代模型在规模和性能上超越传统方法2012年自然语言处理模型Word2Vec诞生2013年Google提出Transformer架构，奠定了大模型预训练算法架构的基础2017年 OpenAI发布GPT-1（Decoder）Google发布BERT(Encoder)预训练大模型成为自然语言处理领域的主流2018年RLHF算法被提出2022年3月2023年5月2023年7月OpenAI公司推出GPT-2，模型参数规模15亿，Decoder技术路线优势显现2019年OpenAI公司推出GPT-3，模型参数规模1750亿，在零样本学习任务上实现了巨大性能提升2020年微软发布BEiT-3模型，标志多模态大模型时代到来2022年8月搭载GPT3.5的ChatGPT正式发布2022年11月 GPT4正式发布，包含1.8 万亿参数，采用混合专家模型 百度发布“文心一言”，国内大模型研发热潮涌现2023年3月 国家人工智能标准化总体组下设立大模型标准化专题组，启动标准编制工作 生成式人工智能服务管理暂行办法公布CNN为代表的传统神经网络模型占主导地位2005年中国发布的10亿以上参数大模型超过79个，“百模大战”态势初步形成2.大模型的定义与发展历程大模型的发展历程中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院4.本体构建难度大本体构建对领域专业知识和构建经验要求高，实体与关系的标识和对齐、本体扩展和更新、本体评估和质控、不同本体融合等方面仍面临技术挑战6.知识完备性不足企业级知识图谱构建中通常面临领域边界限制、企业内数据规模有限、数据中知识稀疏等问题，导致其知识完备性不足5.知识通用性不足企业级知识图谱平台及其知识内容具有较强的行业属性和领域专业性，通用性和迁移泛化能力尚有不足，跨行业、跨领域规模化应用有待提升3.语义理解和自然语言处理难度大知识图谱在面对自然语言中的语义歧义、上下文理解、语言常识推理等问题时，仍缺乏有效的解决办法2.知识抽取质量,难以保证知识抽取规则的构建仍主要依赖人工，主观性强，导致可移植性差和误差传播，使得知识抽取质量难以保证1.语料数据标注效率低、主观性强语料数据标注仍大量依靠人工，存在标注效率低、主观性强等问题3.知识图谱落地面临的瓶颈中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院大模型的训练和优化需要大量的算力资源和海量的数据资源，涉及高性能硬件设备、强大的分布式计算能力、数据治理与融合等，投入成本巨大大模型的开放性导致其存在信息泄露、数据攻击的风险，影响输出结果的鲁棒性和安全性大模型的输出结果是根据概率推理而生成，具有随机性和不稳定性，导致其正确性的验证难度大，难以保证结果的准确可信面向特定领域、多应用场景的高质量中文语料规模和质量不足1.训练大模型的成本高2.训练数据的规模和质量不足3.训练过程的可控性差4.输出的可信度不足5.输出的安全性不足6.知识更新的实时性不足7.领域知识的覆盖率不足8.社会和伦理问题隐现大模型的黑盒问题使得其推理过程很难得到合理的解释和有效的控制，增加了大模型优化的难度，并限制了其在部分领域的应用大模型训练新数据、获取新知识的周期较长，且成本较高，导致其数据更新的滞后和知识时效性的不足GPT等大模型对各领域专业知识的覆盖仍不足，对专业问题的回答尚无法令人满意大模型的输出可能存在与社会和伦理要求相悖的内容，如：生成内容消极、负面，具有破坏性等4.大模型落地面临的瓶颈中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院附附1 1：知知识识图图谱谱领领域域国国内内外外学学者者及及相相关关研研究究知知识识图图谱谱国国内内外外研研究究学学者者：G Ge er rh ha ar rd d W We ei ik ku um m，德德国国萨萨尔尔布布吕吕肯肯M Ma ax x-P Pl la an nc ck k信信息息学学研研究究所所T To om m M M.M Mi it tc ch he el ll l，卡卡内内基基梅梅隆隆大大学学计计算算机机科科学学学学院院最最高高级级别别 E E.F Fr re ed dk ki in n 讲讲席席教教授授I Ia an n H Ho or rr ro oc ck ks s，英英国国牛牛津津大大学学计计算算机机专专业业教教授授唐唐杰杰，清清华华大大学学教教授授李李涓涓子子，清清华华大大学学教教授授漆漆桂桂林林，东东南南大大学学教教授授陈陈华华钧钧 ，浙浙江江大大学学教教授授王王昊昊奋奋，同同济济大大学学教教授授刘刘峤峤 ，电电子子科科技技大大学学教教授授G Ge er rh ha ar rd dW We ei ik ku um m研研究究知知识识获获取取表表示示、分分布布式式信信息息系系统统、数数据据库库性性能能优优化化与与自自主主计计；算算、信信息息检检索索与与信信息息提提取取等等；T To om m M M.M Mi it tc ch he el ll l 的的研研究究涵涵盖盖知知识识表表示示、知知识识库库构构建建、机机器器学学习习、人人工工智智能能，机机器器人人和和认认知知神神经经科科学学等等；I Ia an n H Ho or rr ro oc ck ks s 的的研研究究涵涵盖盖述述述述逻逻辑辑、语语义义网网络络、知知识识表表达达、知知识识库库、网网络络本本体体语语言言等等方方向向；唐唐杰杰研研发发出出研研究究者者社社会会网网络络 A Ar rn ne et tM Mi in ne er r 系系统统，唐唐杰杰的的高高引引用用论论文文是是 2 20 00 08 8 年年在在 K KD DD D 会会议议上上发发表表的的“A Ar rn ne et tM Mi in ne er r:e ex xt tr ra ac ct ti io on n a an nd d m mi in ni in ng g o of f a ac ca ad de em mi ic c s so oc ci ia al l n ne et tw wo or rk ks s”对对其其负负责责的的知知识识工工程程实实验验室室 A Ar rn ne et tM Mi in ne er r 系系统统关关键键问问题题进进行行讨讨论论，整整合合来来自自在在线线 W We eb b 数数据据库库的的出出版版物物并并 出出一一个个概概率率框框架架来来处处理理名名称称歧歧义义问问题题；中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院第二章中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院场景名称场景描述大模型知识图谱智能对话内容生成内容加工作品创作机器翻译意图识别智能检索智能推荐辅助决策知识管理代表对此场景有较好的支撑能力。1.知识图谱与大模型的对比典型应用场景层面 知识图谱与大模型分别拥有相对擅长的应用场景。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院应用场景大模型的基础能力知识图谱的基础能力智能对话语义理解、指令遵循、思维链、基础常识支持上下文理解、情感分析、推理规划语义理解、知识融合、知识查询、知识推理内容生成语义理解、指令遵循、思维链、基础常识支持上下文理解、情感分析、数据可视化语义理解、知识融合、知识查询知识推理、知识可视化内容加工语义理解、指令遵循、思维链、基础常识支持上下文理解、语义分割-作品创作语义理解、指令遵循、思维链基础常识支持、上下文理解、情感分析-机器翻译语义理解、指令遵循-意图识别语义理解、上下文理解支持、情感分析-智能检索语义理解、指令遵循、基础常识上下文理解、情感分析语义理解、知识查询、知识推理智能推荐语义理解、推理规划语义理解、知识查询、知识查询辅助决策语义理解、指令遵循基础常识、上下文理解语义理解、知识融合、知识查询知识推理、知识溯源知识管理-知识融合、知识存储、知识补全、知识查询知识推理、知识溯源、知识共享与交换、知识更新与维护1.知识图谱与大模型的对比核心基础能力层面 知识图谱与大模型通过自身的核心基础能力支撑了对应的应用场景，难以简单替代。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院大大模模型型的的优优势势大大模模型型的的不不足足知知识识图图谱谱的的优优势势知知识识图图谱谱的的不不足足通用性：模型具有指令遵循能力，能处理多种任务，并支持多语言、多模态、多领域的应用。可生成性：模型能生成各种形式和风格的文本，也能生成多模态的内容，如图像、音频等。学习能力：基于大量语料的训练，能对新输入产生合理的响应，也能从多模态数据中进行学习。创作能力：能生成新颖、连贯和通顺的文本，也能生成多模态作品，如图片、歌曲等。常识能力：基于海量通用训练数据中的知识，具有常识理解能力。语义理解能力：能根据文本、多模态数据中出现的内容，理解其含义和关系。可解释性：模型的决策过程是黑箱的，难以解释。可信赖性：模型的输出可能存在错误或有偏见的信息。可溯源性：模型的输出是基于训练的数据，而不是特定的数据点或知识点，较难追溯其输出的来源。可校验性：模型的输出和推理结果有赖于通过人工或者其他系统进行校验。可评价性：模型的性能和输出可通过一些标准任务进行评价，尚不成熟。常识能力：无法处理超出训练语料范围的常识问题。领域能力：缺乏丰富全面的领域知识，领域服务能力一般。语义理解能力：可能出现理解错误或歧义等问题。通用性：知识图谱通常面向特定领域，在通用性上可能较弱。可生成性：知识图谱主要用于查询和分析，而非生成新的内容。学习能力：缺乏自主学习能力。创作能力：缺乏自主创作能力。常识能力：局限于知识图谱中的信息，常识能力较弱。语义理解能力：语义理解能力主要局限于知识图谱中的知识内容，理解能力较弱。可解释性：知识图谱可基于基于明确的语义结构进行查询和分析，具有较好的可解释性。可信赖性：知识图谱通常是由专家创建和维护，因此其可信赖性较高。可溯源性：知识图谱中的每个实体和关系都可以追溯到其来源。可校验性：知识图谱中的信息可以通过专家进行校验。可评价性：知识图谱的质量可通过查询的准确性和完整性来评价。领域能力：具有较强的领域知识支持，支撑了其领域服务能力。推理能力：可根据图谱中的精确知识内容和关联结构，进行高可信度的推理。1.知识图谱与大模型的对比技术特性层面中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院过去在技术发展中交替演进由知识工程而提出的语义网络网络式表达人类知识构造，以此为基础构建专家系统以解决实际问题由Google提出的知识图谱系统表达常识知识，补充现有深度学习模型缺乏的认知能力，推理更精准多模态知识图谱利用多模态信息补充符号语义表达的不足，强化知识的表征能力，支撑多模态理解、推理和元认知等能力。知识高度依赖人工定义，难以进行扩展通过图拓扑建立的隐式的复杂语义以模拟人类认知，但表征能力不足知识异构模态语义对齐难，在不同模态间映射关系多样AlexNet代表的深度学习出现由硬件发展推动而产生的新一代AI方法，模型规模和性能超越传统方法需要大量标注数据支持，完全没有知识建模的能力Transformer架构推动大模型发展BERT，Vision Transfomer等依靠预训练模型，以参数化形式建模知识，进一步发展为以GPT系列为代表的大模型技术需要大量数据、大量算力支持，存在幻觉、高层认知能力等缺点多模态大模型利用丰富的多模态数据，强化相互之间语义对齐约束，提升高级认知能力，异构模态之间的数据对齐难，模态间映射关系复杂未来面临共同的挑战与目标相互支持大模型和知识图谱是相互依赖的知识处理与应用技术，知识图谱发展激发了深度学习的需求和发展，深度学习和大模型也成为知识图谱构建的基础能力，并共同面对未来多模态知识相关的挑战。2.知识图谱与大模型融合的可行性技术演化层面中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院融合方向互补大模型擅长处理自然语言和模糊知识，而知识图谱擅长表示结构化知识并进行推理。相互结合，可以充分发挥它们的优势，解决更复杂的问题。互动大模型可以用于从文本中提取知识、从而扩展和丰富知识图谱的内容。知识图谱可以为大模型提供结构化知识进行语义补充和生成引导。增强知识图谱和大模型融合可以相互增强各自的能力。知识图谱可以提高大模型的语义理解和准确性，而大模型可以为知识图谱提供更丰富的语言知识和生成能力。知识图谱大模型知识图谱能够为通用大模型的工业化应用，弥补通用大模型语料里专业领域知识的不足。，可对大模型的生成能力进行各方面的评估，降低事实性错误的发生概率。，适度控制内容生成，大模型可以利用语义理解和生成等能力抽取知识，也可以抽取出隐含的、复杂的、多模态的知识，降低图谱构建成本。大模型可以利用其语义理解和指令遵循等能力增加知识的全面性和覆盖度，生成更加合理、连贯、有创新性的内容，例如文本、图像、音频等。2.知识图谱与大模型融合的可行性技术互补层面中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院大模型知识图谱动态、概率知识库静态知识库参数化知识库，通过网络参数存储知识，不易理解形式化知识库，通过三元组存储知识，结构清晰，查询简单，易于理解隐式知识库，隐式的存储知识，决策的过程难归因、解释、溯源显性知识库，显式地存储知识，有助于归因溯源，提高模型行为的可解释性更新难度大，忘记特定的知识更加困难便于更新、修改、迁移知识知识的通用性更强，适合于高通用知识密度，高专业知识密度（专业语料少）的应用场景知识的领域性更强，适合于高专业知识密度，低通用知识密度场景具有上下文感知能力、深层语义表示能力和少样本学习能力图结构表达能力强。多模态内容采用模型参数存储，有语义对齐和不可解释性。多模态知识按照知识表示形式存储。知识图谱可以通过prompt，来执行相应信息提取以及思维链的推理任务，形式化成不同形式的知识，例如三元组，多元组或者事件链条。可以利用prompt，参与到大模型的训练前的数据构造，训练中的任务，以及训练后推理结果的约束生成，提升大模型的性能。大模型2.知识图谱与大模型融合的可行性知识库建设层面中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院通过将知识图谱作为训练目标、模型输入、专门知识融合模块，增强大模型预训练效果；通过动态知识融合、检索增强的知识融合方法，增强大模型推理能力；通过基于知识图谱的探针、分析技术，增强大模型可解释性。通过将大模型作为编码器或者通过大模型的生成能力，增强知识图谱表征；将大模型作为解码器、生成器，作用于知识补全；利用大模型的生成能力，增强图谱构建，对图谱交互、图谱问答等任务提供支持和提升将大模型与知识图谱进行统一表征，增强结果准确性；将大模型和知识图谱结合，运用于推理过程，弥合文本和结构信息之间的差距并提升推理可解释性。2023，Shirui Pan et.al，大型语言模型与知识图谱协同研究（Unifying Large Language Models and Knowledge Graphs:A Roadmap）3.知识图谱与大模型融合的现有研究工作0 01 1 知知识识图图谱谱赋赋能能大大模模型型0 02 2 大大模模型型赋赋能能知知识识图图谱谱0 03 3 大大模模型型和和知知识识图图谱谱协协同同中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院知知识识图图谱谱 大大模模型型 降低算力：可减少大模型对无结构化文本的依赖，从而降低大模型的预训练或推理所需的算力和时间。提高知识可信度：依托知识图谱中经质量评估的知识，可帮助大模型提高信息的质量和可信度，并保障知识的正确性和时效性。增强通用性、领域能力、认知能力：可帮助大模型获得跨领域和跨语言的知识，并更好地适应不同的领域任务和场景。降低构建成本：依托知识图谱中的结构化知识，可减少大模型对标注数据或专家知识的需求，从而降低大模型的构建成本和难度。提高可生成性：可帮助大模型可生成更贴近实际、更具有解释性的内容。提高创作能力：通过知识图谱的知识增强，可帮助大模型创作内容更具逻辑、一致性和创新性等。增强理解能力：大模型的语义理解能力可帮助知识图谱更好地理解和分类非结构化信息。降低构建成本：大模型的上下文理解能力、基础常识支持能力等可帮助知识图谱提升非结构化数据的知识获取、知识建模、知识融合等能力，降低其构建和维护成本。丰富输出形式：大模型的生成能力可帮助知识图谱获得多元化的知识输出和服务形式，增强知识图谱系统的服务效果，并提升人机交互水平。提高知识完备性：大模型中涵盖的知识及其对新数据的理解能力，可帮助知识图谱进行知识补全和知识校验，提高知识的完备性。提高可解释性：知识图谱的显性知识与大模型的隐性知识相结合，可提高知识应用的可解释性。实现交叉验证：知识图谱的输出与大模型的输出相结合，可为知识应用提供交叉验证/比对的手段，提高服务的可信赖性。优化知识存储：知识图谱的结构化信息存储和大模型的非结构化信息处理相结合，可优化知识存储和检索效率。提高决策能力：知识图谱推理结果与大模型推理结果的结合，可进一步丰富辅助决策的知识背景，并提供更精确的决策建议。增强隐私保护：知识图谱中数据加密和保护能力与大模型数据调用能力相结合，可降低大模型对个人隐私数据的依赖，有利于保障隐私安全。确保知识产权保护：知识管理机制与本地化部署方式相结合，可更好地保护知识产权，防止知识的滥用或盗用。增强伦理边界：通过优化知识图谱中的知识结构及大模型训练样本结构，构建约束规则类知识并降低数据偏见，强化输出边界。4.知识图谱与大模型融合的收益中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院2023第三章中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院图谱2图谱1大模型1大模型2大模型3结构化数据/半结构化数据/非结构化数据数据大模型集合知识图谱集合知识图谱赋能大模型：以知识图谱为工具提升大模型的能力大模型赋能知识图谱：以大模型为工具提升知识图谱的能力知识图谱与大模型协同?利用知识图谱与大模型各自的优势相互赋能（1 1），并结合上层应用集成，实现两者技术的互补。?利用知识图谱间的互联互通及大模型间的集成调度（N N），实现融合后系统能力的持续增强。1.知识图谱与大模型融合的总体技术路线中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院2.大模型赋能知识图谱的技术路径利用大模型在语义理解、内容生成等方面的技术优势，实现大模型对知识图谱构建至应用全生命周期各环节的增强，提升效率和质量。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院1）用大模型增强数据标注利用大模型对原始数据进行实体、关系、事件等标注。2）用大模型增强知识抽取利用大模型进行实体抽取、关系抽取、事件抽取、因果关系抽取等，例如:DeepKE-LLM。3）用大模型增强知识建模利用大模型进行实体类型提取、关系类型提取、事件类型提取、知识体系提取等。4）用大模型增强知识图谱嵌入与表示学习利用大模型作为知识图谱嵌入的文本和图结构编码器，解决结构连通性有限的问题，提升知识抽取的能力。5）用大模型增强知识图谱补全利用大模型作为编码器或生成器来补全知识图谱数据，提升知识补全的能力。6）用大模型增强知识图谱构建利用大模型开展实体发现、共指解析和关系提取，构建特定领域内的知识图谱结构。采用知识蒸馏等技术实现端到端的图谱构建。参考文献 2023 Yunjie Ji,etc.Exploring ChatGPTs Ability to Rank Content:A Preliminary Study on Consistency with Human Preferences2021 Shirui Pan,etc.Unifying Large Language Models and Knowledge Graphs:A Roadmap2023 Xiang Wei,etc.Zero-Shot Information Extraction via Chatting with ChatGPT2.大模型赋能知识图谱的技术路径关键技术示例中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院7）用大模型增强知识融合利用大模型进行术语定义补全、术语对齐和标准化、实体标准化对齐、同义词提取与融合等8）用大模型增强知识推理利用大模型进行关系推理、事件推理等9）用大模型增强知识图谱可视化利用大模型进行多种形式的知识可视化10）用大模型增强知识图谱文本生成利用大模型自然语言理解方面的优势能够提升从知识图谱中生成文本的质量，提高语言的准确性和在现实场景中的可用性。11）用大模型增强知识图谱问答利用大模型抽取自然语言问题中的实体、关系，进入结构化的知识图谱寻找问题答案，再通过大模型组合答案并结合大模型自身的知识广度将更充实的答案以自然语言的方式输出，增强知识图谱问答的广度、自然性和准确性。12）用大模型增强知识图谱多模态知识对齐利用大模型的通用性和对多类型数据统一处理的能力，能够增强多模态知识对齐，赋能多模态知识图谱的构建、表示、推理和应用的全流程。2.大模型赋能知识图谱的技术路径关键技术示例参考文献 2021 Shirui Pan,etc.Unifying Large Language Models and Knowledge Graphs:A Roadmap中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院3.知识图谱赋能大模型的技术路径 应用场景实现示例：基于大模型增强的知识抽取Gitee地址：https:/ apiPrompt意图识别知识图谱分类、实体识别、翻译123实体别称补全实体上下位推理行业背景知识补全知识修正知识溯源3.知识图谱赋能大模型的技术路径 应用场景实现示例：基于知识图谱增强大模型的文档问答1.离线部分，对文档进行预处理，构建段落级索引，包括全文索引和向量索引2.在线部分，使用知识图谱增强大 模型的问答效果：在意图识别阶段，用知识图谱进行实体别称补全和上下位推理；在Prompt组装阶段，从知识图谱中查询背景知识放入上下文；在结果封装阶段，用知识图谱进行知识修正和知识溯源中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院分别发挥知识图谱与大模型两者的技术优势，通过统一知识表征、动态协同知识推理等技术手段，实现企业级认知决策智能水平的升级发展。3.知识图谱与大模型协同应用的技术路径中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院3.知识图谱与大模型协同应用的技术路径1）知识图谱与大模型统一表征技术通过对大模型与知识图谱进行知识统一表征，增强结果的准确性。2）知识图谱与大模型统一构建技术通过融合知识图谱的训练目标和大模型的训练目标，构建统一模型，使得统一模型同时具备大模型的通用知识、语言理解、知识涌现能力和知识图谱的显性知识、限定域知识、可靠性、可解释性能力。3）知识图谱与大模型串行推理技术通过知识图谱与大模型的串行应用，原始信息首先经过知识图谱进行结构化抽取关联信息，将检索结果输入大模型进行预测推理，从而提高知识推理预测的准确性。4）知识图谱与大模型并行推理技术大模型与知识图谱并行召回答案，动态协同进行知识推理，完成答案融合，即能提高推理结果的准确性，又能拓展推理的知识边界。参考文献 2021 Shirui Pan,etc.Unifying Large Language Models and Knowledge Graphs:A Roadmap中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院5）6）7）3.知识图谱与大模型协同应用的技术路径关键技术示例知识图谱与大模型交互接口标准化规定和明确知识图谱与大模型之间交互接口的标准格式，提升不同厂商间产品集成的便捷性。知识图谱与大模型间任务编排与调度技术知识图谱与大模型协同的过程中，需要基于企业内业务流进行任务的编排和调度，以保证协同过程的流畅性和可操作性。知识图谱与大模型协同中隐私保护技术知识图谱与大模型协同过程中，知识图谱内容仍将被用于大模型的输入或输出中，如何保护知识图谱中的隐私数据不泄漏是系统建设的重要环节。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院1.在为用户推荐美食信息的同时，以“知识图谱 大模型”的应用范式智能生成更加触动人心的文案来触达用户。3.知识图谱与大模型协同应用的技术路径 应用场景实现示例：基于大模型和知识图谱融合的文案生成中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院第 四 章中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院参考：IEEE P2807.1知识图谱技术要求与测试评估规范知识图谱系统测评体系知识图谱构建知识图谱应用知识建模知识抽取知识融合知识表示知识存储知识检索智能问答智能推荐智能检索辅助决策知识管理1.知识图谱和大模型系统的测评体系概述中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院大模型系统测评体系大模型开发大模型应用数据构建模型训练模型部署模型管理大模型能力大模型安全语义理解内容生成基础常识智能对话智能检索内容生成智能推荐情感分析可解释性可信耐性可溯源性可评价性可校验性上下文理解推理规划内容加工辅助决策作品创作机器翻译1.知识图谱和大模型的测评体系概述中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院大模型赋能/增强知识图谱系统测评体系知识图谱构建知识图谱应用融合成本计算资源响应速度融合增益存储资源知识规模知识复杂度推理能力知识完备度同知识图谱系统测评构建成本理解能力2.知识图谱与大模型融合系统测评体系中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院知识图谱赋能/增强大模型系统测评体系大模型开发大模型应用大模型能力大模型安全融合成本计算资源响应速度存储资源融合增益训练数据知识可信度知识准确度知识实时性知识运维能力常识能力可解释性认知能力同大模型系统测评2.知识图谱与大模型融合系统测评体系中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院数据集名称规模子任务描述entity-medical-200200条实体识别基于疾病诊疗指南标注的实体识别数据，包含7类实体relation-medical-200200条关系抽取基于疾病诊疗指南标注的关系抽取数据，包含5种关系 任务类型：知识抽取 数据集 测评结果0.730.650.860.510.880.770.470.380.520.4400.10.20.30.40.50.60.70.80.91实体识别关系抽取CasRel传统方法ChatGPTKG ChatGPTChatGLM-6BKG ChatGLM-6Bbert bilstm crf 结果样例KG ChatGPT显著提升了关系抽取的召回率3.知识图谱与大模型融合系统测评结果中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院数据集名称规模子任务描述医药百科图谱200W三元组柯基数据基于开源数据构建的医药领域的全科知识图谱医药常识问题集100条常识问答医学专家人工编辑的常识问题糖尿病问题集100条糖尿病问答医学专家人工编辑的糖尿病领域的诊疗问题肺癌问题集100条肺癌问答医学专家人工编辑的肺癌领域的诊疗问题 任务类型：智能问答 数据集 测评结果（注：每个问题的答案由医学专家打分，0-3分）252329570500300常识问答糖尿病问答肺癌问答总得分ChatGPTKG ChatGPTChatGLM-6BKG ChatGLM-6B文心一言KG 文心一言3.知识图谱与大模型融合系统测评结果中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院 任务类型：智能问答 结果样例肺癌非小细胞肺癌小细胞肺癌肺腺癌鳞状上皮癌大细胞癌80%至85%占比属于属于属于属于属于3.知识图谱与大模型融合系统测评结果中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院数据集名称规模子任务描述event-100100条文本分类-单层级警情数据，单层分类的数据case-1k1000条文本分类-多层级案件数据，有父子三层级分类的数据子任务准确率LLMKG LLM文本分类-单层级67%文本分类-多层级31V%任务类型：文本分类 数据集 测评结果 结果样例3.知识图谱与大模型融合系统测评结果中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院第五章知识图谱与大模型融合 实践案例 ZHI SHI TU PU YU DA MO XING 中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：1、网络运维工作压力大，人员不足，亟需智能化运维工具提高效率；2、运维人员人工判障效率低，客户体验和满意度难以得到保障，亟需通过智能化手段压降运维时长；3、海量的运维知识检索利用难度大，需智能助手帮助运维人员准确快速找到匹配解决方案，提升效率。解决方案：面向生产一线运维人员，基于意图理解和网络大模型技术，打造具有丰富运维知识的运维助手面向运维专家，利用运维助手进行交互问答，提供查询故障现象，故障原因，故障解决方案，解决效果等，随时在线的运维客服助手关键技术：1、基于网络大模型和运维知识图谱技术打造智能运维助手；2、基于意图理解和运维知识图谱打造运维智能问答机器人提升效果：1.电信行业实践案例：网络运维数字员工中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院2.电力行业实践案例：电力智能客服行业需求1、传统智能客服机器人机械化、条目式的知识检索与问答服务存在用户诉求识别率低、泛化性差等问题，无法满足当前电力客服深度智慧化的需求2、为解决话务量大且座席业务繁重问题，亟需开展智能客服的适应性升级改造，建立智能服务一体化运营管理体系，分流缓解话务高峰，降低客服业务运营培训成本，提升电力客服业务服务水平关键技术：1、电力客服领域语言大模型微调优化技术2、基于领域知识图谱的大模型知识增强技术解决方案：利用客服知识图谱、知识库等语料资源以及LLM大语言模型，构建深度智慧、安全可信的电力客服大模型，满足精准的用户诉求分析、多样化的问答任务响应、实时高效的多轮对话等需求，实现客服问题生成式应答和多样化业务的灵活响应。提升效果：提升客服多轮对话内容生成准确率、用户诉求智能客服应答率等性能。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院1、行业数据量庞大且多样化，数据呈分散态势，难以高效整合和分析；2、行业特点较强，数据包含较多专业术语及领域知识，传统NLP技术难以准确理解分析；3、文本数据存在复杂的结构和语法，对处理系统要求较高。信通小数应用基于电力领域特性和通用语料训练而成的面向电力行业的智能交互应用，为电力行业安监、营销、基建等八大领域提供文本处理、信息提取和智能决策等多种需求的产品。1、自然语言处理；2、领域智能交互；3、语义及情感分析。1、在视频会议的转录及提纲环节减轻记录员相关工作量约90%；2、在综合办公的公文写作及大纲编制环节，提升工作人员60%工作效率；3、应急处理缩短45%处理时间。2.电力行业实践案例：信通小数应用0 01 10 02 20 03 30 04 4中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求1）基于数据资产的血缘链路、下游应用级别等维度，构建特殊数据资产识别规则2）在特殊数据资产状态出现异常（变化）时，基于不同的异常（变化）情况，对相对应的管理节点（人员）进行预警解决方案基于知识图谱，构建数据资产的全链路血缘，将应用级别、资产状态等信息作为属性存储，为特殊数据资产识别提供底层支撑基于大模型，从图结构信息和节点属性中提取必要特征，智能的为用户进行特殊数据资产的推荐及相关异常预警提升效果已部署于华东某国网，基于大模型和知识图谱的特殊数据资产识别及管理系统，基于用户不同业务场景，推荐不同类别的特殊数据资产（如核心数据资产、边缘数据资产、冗余数据资产等），帮助用户对数据资产进行管理。且在特殊数据资产发生变化时，对受影响的部门或责任人进行自动预警 关键技术主动元数据、元数据血缘、特征子图、预训练模型2.电力行业实践案例：基于大模型和知识图谱的特殊数据资产识别及管理中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：1.营销领域知识图谱构建费时费力。2.知识图谱的现有展现形式难以快速获取复杂知识和实体关系。解决方案：1.将银行的营销业务知识图谱与大模型相结合，利用大模型实现知识图谱数据的快速提取和分析。2.采用便捷的自然语言交互方式，降低传统图谱分析的复杂性，提升分析效率。关键技术：1.利用大模型进行实体、属性、关系等知识图谱要素提取，辅助知识图谱内容生成。2.训练大模型符合知识图谱内容结构的指令模版。3.利用大模型检索知识图谱进行内容分析。4.调用外部接口进行进一步的业务分析。5.利用大模型整合内容生成最终的回答。提升效果：实现了基于营销知识图谱的分析问答，助力营销业务高效推进。3.金融行业实践案例：银行智能营销助手中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院3.金融行业实践案例：基于大模型的智能图分析平台反欺诈场景应用行业需求：1）根据监管可疑特征构建单规则、复杂规则；规则指标维度较少；预警量大、准确率低；2）基于涉案名单作为样本构建机器学习模型，提升了召回率、准确率，但可解释性低。解决方案：1）基于知识图谱，建立以图算法和机器学习为核心的团伙反欺诈模型，能够挖掘客户关系网络和账户间的隐藏资金链，并提升对可疑团伙的识别能力，无论是静态的还是动态的关系；2）基于大模型，从图结构信息、节点属性和模型特征中提取关键信息，生成智能风险报告，并通过基于特征的联动图谱可视化展示，使得风险分析更加智能化和直观化。提升效果：在银行内反欺诈平台进行了业务可行性评估，智能解读欺诈团伙的行为特征所生成的风险报告，以及提供团伙关系和模型特征的图谱可视化展示，能够提升反欺诈作业人员的研判效率。关键技术：图算法、机器学习、图结构信息抽取、预训练模型中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院4.医药行业实践案例：Clinical lnsight临床试验情报平台行业需求：1、加速药物上市前的临床试验设计和临床试验招募，以及上市后的产品上市教育、药品渠道销售、患者全流程管理和数字化诊疗等多种场景；2、整合多源异构信息为医药场景提供高效、客观、科学的循证支持，实现降本增效。关键技术：1、医药会议摘要的智能问答；2、临床知识报告生成。解决方案：利用知识图谱及LLM大语言模型进行数据的关联分析及内容生成，为企业提供药物试验的潜在竞争情报，并关联临床试验结果，为试验设计提供循证参考。提升效果：1、临床试验的入排标准设计和试验中心筛选环节周期缩短60%；2、实现遵循医学规范，实现医学知识的复用，进一步提高数据的价值和应用。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院1、知识分散，没有有效整合，耗费人工去找寻答案；2、医学问询邮件没办法保证立即回复，无法快速地帮助医生/患者等解决问题；3、整合所有资料的知识点，有局限性，还是会出现无回答的情况。全球化医学Chatbot平台是一个为医药企业打造的面向外部医生、护士、药剂师等医学专业人士，基于知识图谱和LLM大语言模型能力可循证的疾病用药的应用产品。提升医学部/市场部的效率达到50%1、基于知识图谱的知识增强能力；2、文档解析、问答和自动报告的流程自动化。4.医药行业实践案例：医学学术营销平台中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：1）购车是许多人生活中的重大决策之一，人们希望能够获取针对个人需求的准确且全面的汽车推荐信息，包括车型、价格、性能等方面的细节。2）提供购车过程中的相关指导和建议，以便做出明智的选择。解决方案：通过智能问答系统，结合知识图谱与自然语言处理技术，为用户提供车型、参数、技术规格、价格、预算、性能和购车推荐和指导。提升效果：?提供个性化的购车推荐和指导，使用户更容易找到适合自己需求的汽车。?通过价格预测模型，为用户提供参考的价格范围，帮助他们在合理的预算范围内做出选择。?减少用户的购车时间和不必要的试错，提高购车效率和满意度。?构建良好的用户体验，提高用户留存和口碑，为汽车销售商带来更多潜在客户。关键技术：自然语言处理（NLP），智能问答。推推荐荐方方案案一一推推荐荐方方案案二二5.汽车行业实践案例：购车攻略平台1234中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院用户输入 问题:北京地区今年第一季度大众新能源车的销量Prompt 问题:北京地区今年第一季度大众新能源车的销量数据表：汽车月度销量表列名：月份，城市，品牌，型号，动力燃料，销量Prompt 问题:北京地区今年第一季度大众新能源车的销量数据表：汽车月度销量表列名：月份，城市，品牌，型号，动力燃料，销量名词解释：新能源车的动力燃料包括有纯电力，插电混动和燃料电池Prompt 问题:北京地区今年第一季度大众新能源车的销量数据表：汽车月度销量表列名：月份，城市，品牌，型号，动力燃料，销量名词解释：新能源车的动力燃料包括有纯电力，插电混动和燃料电池examples：“广州市去年6月比亚迪新能源车的销量”=“SELECT SUM(sale_amount)FROM car_monthly_sales WHERE city=广州 AND brand=比亚迪 AND month=202206 AND motor_fuel in(纯电力,插电混动,燃料电池)Natural Language to SQLSQL SELECT SUM(sale_amount)FROM car_monthly_sales WHERE city=北京 AND brand=比亚迪 AND month=202301 and month=202303 AND motor_fuel in(纯电力,插电混动,燃料电池)结果是否合理输入结果Reask Prompt generator数据表结构提取信息增强FewshotExamplesLLMYESDBMS查询结果Guardrails基于bert微调的NLP模型用来提取用户提问中涉及的数据表和数据列从车辆信息知识图谱中提取补充信息使用向量相似度检索算法搜索案例使用基于规则的栏栅系统来识别结果的合理性以及是否会暴漏数据隐私NO5.汽车行业实践案例：购车攻略平台中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：1)进一步提升智能家居用户的交互体验，包括交互过程中的连续对话、语义理解、生成人性化回复；2)解决研发人员面对的家电知识零散、知识库建设效率等现实问题，实现降本增效。解决方案：1)利用大模型进行知识泛化，解决知识有限、获取难、知识库构建效率低等问题；2)基于泛化后的语料，实现“任意说”(指令换说法，仍然听得懂)；3)利用大模型的理解与生成能力，实现上下文理解、连续对话、拟人化回复。关键技术：智能家居知识图谱、智能家居行业大模型、安全计算、场景生成等。提升效果：1)智能家居知识图谱的量级从千万提升到亿级，形成高效知识管理平台；2)用户交互体验大幅提升，从以往控制指令说法受限、回复不精准，进化为连续交互、随意交互和引导交互。6.智能家居行业实践案例：智能家居知识泛化及交互提升01020304中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求1、智能生成内容：辅助编者和教师用户内容生成；2、高效内容处理：通过智能系统辅助翻译、转录、汇集、润饰、评估等内容处理工作，大幅提升编辑们的工作效率；3、智能推荐：用人工智能进行信息推荐，扩大其数字营销能力。关键技术：1、大纲和内容的自动生成；2、精准用户画像自动分析与推荐。解决方案：1）基于领域知识等构建跨领域知识图谱，用大模型技术实现知识自动抽取；2）在生成式大模型提升知识图谱的知识创作能力；提升效果：通过基于智能AI系统的数字教材编创系统，为编者、编辑、教员、学生提升智能知识服务7.教育出版行业实践案例：数字教材智能编创与应用系统01030204中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：1）在数字孪生城市行业非结构化数据急剧增多的情况下，构建知识图谱需要依赖人工或者半自动方式进行知识抽取和建模，信息利用效率低，数据分析能力不强。2）现有数字孪生城市知识图谱大部分是针对特定领域或任务定制，扩展性差。解决方案：基于矢量数据、影像数据、模型数据、IOT数据、专题数据等构建数字孪生城市知识图谱，结合大模型预训练提升知识图谱的知识抽取和图谱构建能力，并将知识图谱作为大模型输入，提升大模型专业性和可信性，从而利用知识图谱 大模型提升城市运营以及各领域的指挥决策能力以及准确度。提升效果：数字孪生城市服务平台性能优化，数字孪生城市各领域的信息获取以及利用效率增大，数据分析能力有了很大的提升。关键技术：知识注入辅助模型预训练、基于大模型的知识抽取能力8.智慧城市实践案例：数字孪生城市服务平台中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：社交领域的智能交互机器人难点在于对社交机器人进行成长式的个性化训练，来生成语义连贯自然、富带感情观点、千人千面的多模态内容。基本属性五大人格人物标签体系关系图谱角色内在特征塑造深度强化学习适应策略激励智能感知?阅读?交流?协作?对抗机器人A机器人B知识和数据双驱动预训练社交数据 个性化生成适配多语传播智能网评话题感知生成式对话大模型 人物知识库在指令和上下文中嵌入个性化解决方案：大模型以百万级人物知识库和社交媒体信息作为个性化指令数据进行精调，具备千人千面的角色学习能力。采用内在特征塑造和强化学习对抗反馈的方式不断加强与人类性格、价值的对齐。9.社交领域实践案例：成长式个性化社交机器人中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院提升效果：采用内在特征塑造和深度强化学习的方式训练社交机器人，能够生成语义连贯自然、富带感情观点、千人千面的多模态内容。以Reddit为媒体平台，实现认知舆论战的贴文生产系统，根据热点、关键词进行流畅的本地化的贴文批量生成，拟人通顺度80%，连续生成1200条的可用度80%，重复率20%，具备根据不断变化的热点进行准实时的模型训练更新。关键技术：个性化训练、指令精调、强化学习9.社交领域实践案例：成长式个性化社交机器人中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院行业需求：1、搜索是信息时代的通用性刚需，可以提升用户日常行为的效率；2、提高短文本查询Query和长文本Item的语义表达能力与理解能力，给用户提供更好的搜索体验。解决方案：利用知识图谱及LLM大语言模型，识别用户查询意图、生成语义向量，并进行向量检索，同时基于知识图谱进行关联分析，得到关联推荐结果。关键技术：1、面向指标数据、文献数据的查询意图精准识别；2、面向指标数据、文献数据的语义向量检索提升效果：1、基于大模型的搜索系统的准确率，相比原系统同比提升13%，且大幅降低了人工维护成本；2、大模型赋予搜索更强的自我学习能力，能够持续优化输出结果，更好贴合用户使用习惯，更具个性化。10.科学文献行业实践案例：基于大数据的智能检索01#ONE02#TOW03#THREE04#FOUR中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院基于大模型和知识图谱的知识平台是智慧水利的智能支撑，通过构建水利领域大模型，融合知识图谱技术，面向水务领域知识，形成以知识引擎为核心的事理推演，支撑服务及应用场景包括：场景一：政务（水务方向）智能问答11.水务行业实践案例：基于大模型和知识图谱的智慧水利知识平台关关键键技技术术大模型语义相似度计算、信息抽取、预训练模型语义相似度计算技术。行行业业需需求求各种关于水务相关的在线咨询需要人工解答，查找答案时费力，人工客服容易面临相同问题回答不一致或者回答不及时的问题。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院解决方案：基于应急预案、政策等构建水务知识图谱，并构建基于大模型的智能问答系统，从而利用预训练模型语义计算技术智能识别用户的意图，给出针对性的解决思路或答案，并实现从水务知识图谱中快速检索出准确的答案，提升客服服务效率。提升效果：基于智能AI机器人（硬件）和大屏的水务方向政务智能问答系统，在线回答时效性提升60%，回答准确率显著提高，且已支持多层问答，语音输入，并基于在线文字及语音理解的生成式多模态图表技术，实现了机器人和大屏的在线联动，数字化大屏展示等效果。11.水务行业实践案例：基于大模型和知识图谱的智慧水利知识平台中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院水务相关政策公文面临素材搜寻难、政策发布难、政策宣传难、政策申报难、政策统计繁等问题。基于NLP、知识图谱、大模型技术，构建融合政策、法规、公文、解读、机构、主题等要素构建全域政策关系网络知识图谱，将经验/知识转换为规则政策。政策公文语义搜索、文档解析信息抽取、政策文本关联技术水务政策知识平台（知文智用）智能提供政策语义搜索、公文标引、智能审核等应用，实现公文辅助写作，公文写作联想，相关插件可集成WPS等办公软件，支持公文初稿拟制、河长制日报周报、预警事件处置报告、应急预案等多种文体的自动生成。场景二：水务政策公文服务11.水务行业实践案例：基于大模型和知识图谱的智慧水利知识平台中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院11.水务行业实践案例：基于大模型和知识图谱的智慧水利知识平台场景三：基于大模型的数字孪生水利防洪推演预测系统行业需求：山洪流域防洪需要：精准的预报预测分析、预警消息及时触发并发布、水利应用场景仿真推演、应急预案快速形成并择优。关键技术：水利数据演算分析技术、基于仿真引擎及可视化模型双向渲染技术、数字孪生提升效果：结合大模型技术驱动水利防洪，实现山洪“四预”解决方案：利用大模型技术驱动水利行业专项业务更精准的预报预测分析，结合数字孪生场景实现水利工程实体及单元部件预警消息的空间关联绑定及消息查看，结合大模型技术实现基于仿真引擎及可视化模型双向渲染驱动下的数字孪生水利应用场景仿真推演，基于场景预演结果，实现以知识平台驱动下的调度方案推送，辅助最优预案决策。精准超前预报快速直达预警前瞻科学预演细化实化预案中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院第六章中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院1.基于知识图谱与大模型的融合，实现知识图谱的自动构建、架构动态拓展与自动运维。2.通过知识图谱与大模型的融合，降低对算力、存储等资源的需求，优化运行效率。3.利用知识图谱与大模型的融合，提升知识更新效率。4.通过知识图谱与大模型的融合，实现行业大模型的高效构建。5.基于知识图谱的结构化知识与逻辑推理能力，增强大模型的可解释性与推理能力。6.基于知识图谱增强的大模型，优化解决不确定性问题，提升决策的准确性和效率。0102知知识识图图谱谱与与大大模模型型的的应应用用和和安安全全保保障障知知识识图图谱谱与与大大模模型型的的增增强强和和效效能能提提升升1.利用知识图谱与大模型的融合，实现对复杂业务场景的深度理解和精准响应。2.通过大模型与知识图谱的构建及融合，实现更广泛的多模态应用。3.利用知识图谱增强的大模型，实现内容的自动化审查机制。4.通过知识图谱与大模型的融合应用，实现面向特定领域的安全保障机制。技术挑战中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院发展展望1.建议围绕大模型，加大建设投入与政策保障，纳入国家新型基础设施；2.建议针对大模型，建立国家级的研发中心/基地，提供公开的计算资源、研发资源等，推动中小企业开展研发工作；3.建议围绕知识图谱和大模型融合的数据安全、隐私保护、知识产权保护、伦理等，完善相关法规；4.建议从政策层面，针对国产大模型，开展研发与推广应用的支持。1.建议针对产业需求，开展知识增强大模型的建设，以促进大模型的产业应用；2.建议围绕大模型与知识图谱融合应用，开展行业数据库的打造；3.建议根据产业需求，开展开源训练数据集和知识图谱的建设。1.建议围绕互操作、数据传输与共享、计算资源等技术领域，开展通用标准制订工作；2.建议针对行业应用需求，开展行业标准规范的制订工作。中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院2知 识 图 谱 产 业 推 进 方 阵 简 介知 识 图 谱 标 准 化 工 作 组 简 介1全国信标委人工智能分委会知识图谱工作组及IEEE知识图谱标准化工作组，由中国电子技术标准化研究院牵头，联合知识图谱相关企事业单位、研究院所、高校、机构，旨在运用标准化的理念、方法和技术梳理分析知识图谱领域核心标准化需求，共同推动知识图谱关键标准的研制等工作，支撑知识图谱技术的高质量推广与应用。工作组现有清华大学、阿里巴巴、联想、华为、百度、腾讯、东软、蚂蚁科技、依图等70余家知识图谱领域相关单位共同参与标准编制工作。目前，已发布GB/T 42131-2022人工智能 知识图谱技术框架等国家标准、IEEE标准3项，在研标准10项。知识图谱产业推进方阵旨在培育和壮大知识图谱领域供应商、集成商、服务商与用户企业，以标准化为纽带，共同促进知识要素在各行业领域的挖掘、富集、流动和应用，推动构建跨行业、跨领域的知识挖掘与应用服务新型基础设施。方阵成员包括理事长单位、成员单位，并设置轮值主席、专家委员会、秘书处及必要的工作组。方阵将通过供需对接、诊断评估、测试认证、标准宣贯、教育培训、知识交换协议开发等手段服务产业，不定期开展技术沙龙、案例征集、成果发布、专题竞赛、产业峰会等活动，推动知识图谱的技术创新和产业深化应用。请有意向的单位填写方阵成员单位申请表提交至，经秘书处形式审核及理事长会议审议通过后，将颁发成员单位证书。申请表下载链接如下：https:/ 42131-2022人工智能 知识图谱技术框架等系列国家标准和团体标准，中国电子技术标准化研究院联合北京赛西认证公 司 等 4 0 余 家 单 位 研 制 了 知 识 图 谱 构 建 平 台 认 证 技 术 规 范 、知识图谱应用平台认证技术规范等基础知识图谱产品认证技术规 范，并 研 制 了 金 融 领 域 知 识 图 谱 构 建 能 力 认 证 技 术 规 范 、医疗领域知识图谱应用能力认证技术规范等领域知识图谱认证技术规范，共设置300余项测评指标。现已有联想、华为、百度、蚂蚁科技、清华大学、中国医学科学院医学信息研究所、科大讯飞等30余家单位的知识图谱系统通过首批、第二批和第三批基础知识图谱产品认证，首批医疗领域知识图谱产品认证。获批使用的认证标识如下：序号 标准类型标准名称状态1国际标准ISO/IEC DIS 5392Information technology Artificial intelligence Reference architecture of knowledge engineering信息技术 人工智能 知识工程参考架构在研2国家标准人工智能 知识图谱技术框架国家标准号：GB/T 42131-2022已发布3IEEE标准Framework of Knowledge Graphs知识图谱架构IEEE标准号：IEEE Std 2807-2022已发布4IEEE标准Standard for Technical Requirements and Evaluating Knowledge Graphs知识图谱技术要求及测试评估规范 项目号：P2807.1在研5IEEE标准Guide for Application of Knowledge Graphs for Financial Services金融服务领域知识图谱应用指南 项目号：P2807.2已冻结6IEEE标准Guide for Electric-Power-Oriented Knowledge Graph面向电力行业的知识图谱指南IEEE标准号：IEEE Std 2807.3-2022已发布7IEEE标准Guide for Scientific Knowledge Graphs科技知识图谱指南项目号：P2807.4在研8IEEE标准Guide for Medical Clinical Diagnosis and Treatment Oriented Knowledge Graphs面向临床诊疗的知识图谱指南项目号：P2807.5在研9IEEE标准Guide for Open domain Knowledge Graph Publishing and Crowdsourcing Service开放域知识图谱发布与众包服务指南项目号：P2807.7在研10IEEE标准Standard for knowledge exchange and fusion protocol among knowledge graphs知识图谱间知识交换与融合协议项目号：P2807.8在研11团体标准人工智能 知识图谱 分类分级规范项目号：CESA-2020-019在研12团体标准人工智能 知识图谱 性能评估与测试规范项目号：CESA-2020-020在研13团体标准人工智能 医疗知识图谱 构建要求项目号：CESA-2023-023在研14团体标准人工智能 医疗知识图谱 测试评估要求项目号：CESA-2023-024在研15白皮书知识图谱标准化白皮书已发布16案例集知识图谱赋能疫情防控与复工复产案例集已发布17案例集认知智能时代：知识图谱实践案例集已发布18白皮书知识图谱选型与实施指南已发布19白皮书知识图谱互联互通白皮书已发布20研究报告知识图谱与大模型融合实践研究报告已发布基础知识图谱产品测评与认证介绍：https:/ 系 人:李瑞琪联系方式:电子邮箱:中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院中国电子技术标准化研究院

0人已浏览 2023-12-13 72页 5星级

 1/34 2023年年 12月月 11 日日 行业行业|深度深度|研究报告研究报告 行业研究报告 慧博智能投研 AI Agent行业行业深度：深度：框架拆解框架拆解、应用方向应用方向、应用领域应用领. 

0人已浏览 2023-12-13 34页 5星级