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

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

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

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

致同咨询行业洞察高端装备制造 工业机器人行业2023年12月发布引言 工业机器人被誉为“制造业皇冠上的明珠”，具有易用性、智能化、生产效率及安全性高、易于管理且经济效益显著等特点，是智能制造中的重要一环。当前处于市场空间大、应用场景可拓展可精进的阶段。根据IFR数据，中国为工业机器人第一大市场，2022年我国工业机器人市场规模达87亿美元，全球占比45%。2022年中国工业机器人销量约30万台，2011-2022年复合增长率达26%，远高于全球市场的12%复合增长率。工业机器人广泛应用于消费电子、汽车、金属制品等领域，且随着新能源行业兴起，逐步向锂电、光伏等行业拓展。工业机器人市场集中度较高，由来自日本、瑞士和德国的“四大家族”长期占据主导地位。2022年发那科（FANUC）、安川（YASKAWA）、ABB、库卡（KUKA）在中国的销量市占率合计高达39%，而同期我国工业机器人龙头埃斯顿和汇川技术机器人销量市占率仅为6%和5%。此外，2022年中国市场国产化率仅36%，国产化前景广阔。产业政策频出，国家大力支持工业机器人发展。2023年1月，工信部等17部门发布“机器人 ”应用行动实施方案，方案制定了到2025年我国制造业机器人密度较2020年实现翻番的目标。同时，国务院提出的中国制造2025为中国制造业未来10年设计顶层规划和路线图，推动中国到2025年基本实现工业化，迈入制造强国行列。点击下方图标，了解相关详情行业回顾市场回顾尽调常见风险提示行业政策法规行业趋势分析定义与概念行业热点聚焦高端装备制造 工业机器人行业 1行业概况 定义与概念简介：工业机器人分类2022年中国市场工业机器人销量占比 工业机器人，指面向工业领域的多关节机械手或多自由度的机器装置，它能自动执行工作，是靠自身动力和控制能力来实现各种功能。工业机器人可根据结构和功能，分为垂直多关节机器人、水平多关节机器人（SCARA）、并联机器人（DELTA）和协作机器人。数据来源：IFR、东吴证券研究所垂直多关节机器人协作机器人水平多关节机器人并联机器人67%2%7$%垂直多关节机器人 负载3-600KG 应用于汽车、食品、锂电、消费3C领域 由相互垂直的直线构成，具有高精度、高速度和高可靠性的特征。常用于装配、包装、搬运等场景水平多关节机器人（SCARA）负载3-50KG 应用于电子、食品、半导体、金属制品、医疗领域 由相互平行的直线构成，具有高速度和高精度的特征，用于要求高精度的装配和搬运任务并联机器人（DELTA）负载3-100KG 应用于电子、食品、医药领域 具有三个或多个自由度，用于要求高速度、精度的应用，具有高度灵活的结构和快速完成任务的能力协作机器人 负载3-30KG 应用于3C、汽车零部件、科研教育、机械加工领域 可以与人在同一工作空间内协同作业，区别于传统工业机器人，具有安全、易用、灵活的特征高端装备制造 工业机器人行业 2行业概况 工业机器人产业链图谱上游核心零部件减速器垂直多关节机器人并联机器人控制器水平多关节机器人协作机器人伺服电机传感器等其他零部件注：排名不分先后；数据来源：亿欧智库、36氪研究院、开源证券研究所、东吴证券研究所中游机器人本体下游集成应用汽车3C电子光伏锂电工业机器人集成产线高端装备制造 工业机器人行业 3市场回顾 全球和中国工业机器人市场规模20020202222023E2023E数据来源：IFR、中国电子学会、浙商证券研究所数据来源：IFR、中国电子学会、方正证券研究所全球工业机器人市场规模及增速亿美元亿美元中国工业机器人市场规模及增速 2023年全球工业机器人市场有望达210亿美元，预计同比增速为8%，保持较稳定的增长趋势；2019年因贸易摩擦等因素，全球工业机器人市场有所萎缩，2020年至今市场快速恢复，并维持增长趋势。中国目前是全球最大的工业机器人市场，2023年我国工业机器人市场规模有望达99亿美元，在全球工业机器人销售额比重有望达47%；2019-2023年，中国工业机器人市场规模保持超过10%的年增长，市场规模占全球规模比例呈上升趋势。全球市场规模全球同比增速中国市场规模中国同比增速中国市场占全球比例200250 0%0%-10%-20 19201910 %0%-10%-200P 0250GCEG%高端装备制造 工业机器人行业 4市场回顾 中国工业机器人市场和国产化率情况2000222023Q1数据来源：MIR，华泰研究数据来源：MIR，华泰研究2022年国内工业机器人市场竞争格局前十大工业机器人厂商销量市占率合计：66%发那科，15%KUKA，8B，8%安川，8%埃斯顿，6%雅马哈，4%埃夫特，2%川崎，3%汇川，5%爱普生，7%国内市场国产化率情况 2022年国内工业机器人市场中，发那科、ABB、KUKA、安川四大机器人家族合计占比达39%，仍占据市场主导地位；前十大工业机器人厂商合计占比达66%，其中埃斯顿、汇川技术和埃夫特为国产头部企业，合计占比达13%。工业机器人领域国产替代进程逐步提速，2023年第一季度国产化率达41%，有望实现中国制造2025提出的2025年实现工业机器人内资品牌市场份额占比50%的目标。201918 $0)26A%国产化率40P 0%0%高端装备制造 工业机器人行业 5行业回顾 上游核心零部件核心零部件成本占比核心零部件国产化率工业机器人核心零部件为减速器、伺服电机和控制器，成本占比合计高达70%。核心零部件的主要功能如下：减速器：降低伺服电机的转速和转矩，提高精度和负载，核心指标为器件寿命、精度及稳定性；伺服电机：执行控制器指令，将电能转化为机械能，实现机器人运动，核心指标为驱动器、编码器性能；控制器：控制机器人的运动轨迹、速度和姿态，是机器人的大脑，核心指标为精度、稳定性和底层算法。工业机器人核心零部件整体国产化率较低，主要技术差距包括：减速器：国产减速器精度保持度、稳定性和可靠性略低于国外领先厂商，技术创新和产品升级略有落后，定制化能力稍显不足；伺服电机：精度略低、响应速度无法跟上算法需求、多轴联动情况下的精密控制效果不足；控制器：研发时间短，缺乏大量实践数据以优化算法，成熟产品多为封闭式架构难以参考，配套的减速器和伺服电机需要进口，磨合不足。数据来源：OFWEEK机器人网，华泰研究数据来源：开源证券研究所核心零部件，70%本体，15%其他成本，15%减速器，35%伺服电机，20%控制器，15%国产 非国产800 %0%减速器伺服电机控制器655xp0%高端装备制造 工业机器人行业 6行业回顾 下游集成与应用汽车锂电光伏消费电子 汽车整装和汽车零部件生产行业高度自动化、流程标准化，是工业机器人应用成熟的产业 工业机器人几乎适配所有生产环节，包括上下料、装配、打磨、抛光等等，2025年全球汽车行业对工业机器人的需求将达到约600万台 锂电产业增速迅猛，是工业机器人未来重点发力领域 工业机器人的使用几乎可以覆盖锂电产业制片到Pack全流程，应用场景包括上下料、清洁、高速堆叠、焊接、外壳安装和打包等，全流程覆盖率有望达65%中国是全球最大光伏市场和产业链供应商，光伏产业预计保持生产出口高增长 光伏行业对工业机器人的承载能力和产线的洁净程度有较高要求，主要自动化流程有切边、装框、密封等 消费电子是工业机器人重要的下游行业，2022年终端产品出货量有所下降，但未来有望逐步回暖 消费电子自动化产线，零件重量轻，对精准度、定制程度和模块化有较高的要求，主要自动化流程包括上下料、螺丝拧紧、装配、分拣和检测等，适合SCARA、DELTA和协作机器人数据来源：TE智库其他，23%电子，21%锂电，6%光伏，5%金属加工，11%仓储物流，9%汽车，25%高端装备制造 工业机器人行业 7行业热点聚焦 工业机器人行业并购交易概览近期工业机器人行业代表性并购交易时间标的公司轮次交易金额投资方2023年10月天创机器人C轮超亿元工创汇吉基金、海创汇基金、置柏投资2023年9月长广溪智造A轮近亿元东海投资2023年6月行健智能B轮6000万元同创伟业、东方嘉富2023年6月图灵智造A轮近亿元陕煤集团、上海大钧资本、海南集润嘉等2023年5月日本GitaiB 轮3,000万美元Green Co-Invest、Pacific Bay Fund等2023年3月斯坦德机器人C轮数亿元小米产投、中信建投2022年12月智昌集团Pre-IPO轮3.5亿元宁波产业发展、余姚经开区建投2022年7月节卡机器人D轮约10亿元淡马锡、淡明、软银愿景二期等2022年6月镁加科技C轮3亿美元高盛资产管理、亚投资本、纪源资本等高端装备制造 工业机器人行业 8行业热点聚焦 热点事件互联网巨头下海，资本市场重启投资周期1月：饿了么入股服务机器人产品与解决方案提供商擎朗智能6月：字节跳动入股AMR软硬件和云服务开发的机器人企业Syrius炬星11月：美的集团公告计划全面收购库卡机器人，实现对库卡的全资控股政策明确2025年制造业机器人发展目标以及机器人十大应用场景工信部等 17 部门发布“机器人 ”应用行动实施方案，方案制定了到 2025 年我国制造业机器人密度较2020年实现翻番的目标中国工业机器人密度首超美国据国际机器人协会数据，2022年全球制造业工业机器人密度已上升至每万人141台，是六年前的两倍多。其中，我国的工业机器人的密度首次超过美国，工业机器人密度达到每万名工人322台，约是十年前的13倍，在全球排名第五政策引导下，机器人行业获得空前关注由工信部牵头、十五部门联合印发“十四五”机器人产业发展规划，倡导开展从机器人产品研制、技术创新、场景应用到模式推广的系统推进工作，支持新兴领域探索开展机器人应用机器人与AI技术结合，提高机器人在各行业的渗透率3月，谷歌与柏林工业大学共同推出了史上最大的视觉语言模型PaLM-E，该模型随后将运用到工业机器人上4月，第六届数字中国建设峰会上，阿里巴巴将千问大模型接入工业机器人，成功用对话操控机器人工作工业机器人市场持续受到资本青睐2022全年，工业机器人行业发生投融资93起，领域亿元级融资事件达41起。其中节卡机器人完成约十亿元D轮融资，并启动IPO进程，有望成为中国协作机器人第一股111月1月12月34月112月2021年2022年2023年高端装备制造 工业机器人行业 9行业政策法规(1/2)时间发布单位法规名称法规内容2023年1月工信部、教育部等十七部门“机器人 ”应用行动实施方案 到2025年，制造业机器人密度较2020年实现翻番，服务机器人、特种机器人行业应用深度和广度显著提升，机器人促进经济社会高质量发展的能力明显增强。聚焦10大应用重点领域，突破100种以上机器人创新应用技术及解决方案，推广200个以上具有较高技术水平、创新应用模式和显著应用成效的机器人典型应用场景，打造一批“机器人 ”应用标杆企业，建设一批应用体验中心和试验验证中心。2021年12月工信部、国家发改委、教育部等八部门“十四五”智能制造发展规划 大力发展智能制造装备，推动先进工艺、信息技术与制造装备深度融合，通过智能车间/工厂建设，带动通用、专用智能制造装备加速研制和迭代升级，具体包括：研发通用智能制造装备，例如智能焊接机器人、智能移动机器人、半导体（洁净）机器人等工业机器人；研发新型智能制造装备，例如融合数字孪生、大数据、人工智能、边缘计算、虚拟现实/增强现实等新技术的智能工控系统、智能工作母机、协作机器人、自适应机器人等新型装备。2021年12月工信部、国家发改委、科技部等十五部门“十四五”机器人产业发展规划 到2025年，我国成为全球机器人技术创新策源地、高端制造集聚地和集成应用新高地；推动一批机器人核心技术和高端产品取得突破，整机综合指标达到国际先进水平，关键零部件性能和可靠性达到国际同类产品水平；机器人产业营业收入年均增速超过20%，建成3到5个有国际影响力的产业集群。2021年12月工信部、国家标准化管理委员会国家智能制造标准体系建设指南（2021版）加快制定人机协作系统、工艺装备、检验检测装备等智能装备标准。其中，工业机器人标准主要包括数据格式、对象字典等通用技术标准；信息模型、编程系统、用户、工业机器人之间的接口与通信标准；工业机器人与人、环境、系统及其他装备间的协同标准；性能、场所适应性等测试与评估标准。2021年10月中共中央、国务院国家标准化发展纲要 加强关键技术领域标准研究：研究制定智能船舶、高铁、新能源汽车、智能网联汽车和机器人等领域关键技术标准，推动产业变革。2021年3月全国人大常委会中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要 推动制造业优化升级，深入实施智能制造和绿色制造工程，发展服务型制造新模式，推动制造业高端化智能化绿色化。培育先进制造业集群，推动集成电路、航空航天、船舶与海洋工程装备、机器人、先进轨道交通装备、先进电力装备、工程机械等产业创新发展。高端装备制造 工业机器人行业 10行业政策法规(2/2)时间发布单位法规名称法规内容2021年1月工信部基础电子元器件产业发展行动计划（2021-2023）利用我国工业领域自动化、智能化升级的机遇，面向工业机器人和智能控制系统等领域，重点推进伺服电机、控制继电器、传感器、光纤光缆、光通信器件等工业级电子元器件的应用。2021年1月工信部工业互联网创新发展行动计划（2021-2023年）建设工业互联网网络信息模型实验室。面向仪器仪表、数控机床、机器人等领域开发100个以上网络信息模型。2020年10月国家发改委、科技部、工信部等六部门关于支持民营企业加快改革发展与转型升级的实施意见 实施机器人及智能装备推广计划，扩大机器人及智能装备在医疗、助老助残、康复、配送以及民爆、危险化学品、煤矿、非煤矿山、消防等领域应用。加快高危行业领域“机器化换人、自动化减人”行动实施步伐，加快自动化、智能化装备推广应用及高危企业装备升级换代。2020年9月国家发改委、科技部、工信部、财政部关于扩大战略性新兴产业投资培育壮大新增长点增长极的指导意见 加快高端装备制造产业补短板：重点支持工业机器人、建筑、医疗等特种机器人、高端仪器仪表、轨道交通装备、高档五轴数控机床、节能异步牵引电动机、高端医疗装备和制药装备、航空航天装备、海洋工程装备及高技术船舶等高端装备生产，实施智能制造、智能建造试点示范。2020年8月国家标准化管理委员会等五部门国家新一代人工智能标准体系建设指南 注重与智能制造、工业互联网、机器人、车联网等相关标准体系的协调配套。建立完善智能机器人标准：围绕服务机器人，完善服务机器人硬件接口、安全使用以及多模态交互模式、功能集、服务机器人应用操作系统框架、服务机器人云平台通用要求等标准；围绕工业机器人，重点在工业机器人路径动态规划、协作型机器人设计规范等开展标准化工作。2019年12月中共中央、国务院长江三角洲区域一体化发展规划纲要 聚焦集成电路、新型显示、物联网、大数据、人工智能、新能源汽车、生命健康、大飞机、智能制造、前沿新材料十大重点领域，加快发展新能源、智能汽车、新一代移动通信产业，延伸机器人、集成电路产业链，培育一批具有国际竞争力的龙头企业。致同观点：智能制造是“中国制造2025”大背景下产业创新的重要方向，也是推动新一代信息技术和制造技术融合发展的主要渠道。近年来国家大力支持工业机器人发展，产业政策频出，产业发展将步入新阶段，迎来新的机遇、目标和挑战。高端装备制造 工业机器人行业 11行业趋势分析(1/2)主要趋势描述解决方案客户的挑战行业应用横向和纵向拓展，下游新兴市场增速强劲带动机器人整机需求增长 工业机器人主要用于电子消费和汽车领域，而随着新能源汽车与光伏产业的发展，推动工业机器人的需求多元化和市场扩容：横向拓展-向自动化程度高、标准化流程强的行业拓展：消费电子、汽车等传统行业自动化程度高、流程标准性强，是工业机器人应用成熟的行业；新能源中锂电、光伏市场增长，其标准化产品和生产过程中的自动化需求对机器人产生了需求；纵向拓展-向更精密的加工场景拓展：从过去从事搬运上下料等简单操作，向装配、打磨、抛光等高精度、高灵敏精密加工场景扩展。2022年，3C电子和食品饮料行业受消费不振影响，增速放缓，取而代之的是新能源汽车、光伏等相关产业的稳定增长。国内新能源汽车在全球电动化的大势下，即便受原材料价格上涨和补贴退坡影响，在2021、2022年产销量仍保持较高速增长。光伏装机量在宏观政策的推动下始终保持高景气度，同时，海外市场受缺电、电价高企影响，光伏产品需求攀升，成为我国光伏产品出口的重要支撑因素。咨询服务 商业咨询 融资并购（融资顾问）交易支持（财务、税务尽职调查、市场分析、商业计划、财务预测、估值分析等）面临市场的变革与挑战，如何更快地响应需求端的发展变化？是否有切实有效的战略规划帮助企业寻求进一步发展？人机协作不断深化，协作机器人成为赛道热点 协作机器人属于工业机器人的分支。区别于传统工业机器人追求“刚度”的特点，协作机器人更多地追求轻量化、柔性及安全协作性，在应用于工业场景中时，打破了传统工业场景的局限，在机器人产品与工人之间无需设置隔离栏进行分离，双方能够在共同空间中进行近距离交互，实现人机共融协同作业，充分发挥机器人的效率及人类的智能。由于具备使用灵活、易编程和低使用成本的优势，协作机器人正处于快速导入阶段。当前，国内协作机器人产业发展迅猛，参与企业不断提升。发展前景看，协作机器人可以满足工业和服务多个场景的应用需求，具备广阔的市场空间。根据IFR统计数据，近年来全球协作机器人销量持续保持高速增长，2021年全球销量达到3.9万台，同比增长约50%，2017-2021年复合增长率约为37%。根据高工产业研究院（GGII）预测，2023年全球协作机器人销量将达8万台，市场规模将接近120亿元。咨询服务 融资并购（融资顾问）交易支持（财务、税务尽职调查、市场分析、商业计划、财务预测、估值分析等）对协作机器人赛道企业的投资并购时，是否充分了解投资标的的盈利能力和资产质量？高端装备制造 工业机器人行业 12行业趋势分析(2/2)主要趋势描述解决方案客户的挑战5G 大数据，工业机器人未来将更高效和智能 5G联接技术的进步，为机器人协作、上云提供了必要的支撑，同时为AI、大数据等新兴技术在机器人上的应用以及机器人深入各行各业打造了坚实的基础。5G的发展为工业机器人“互联”“上云”提供高速网络支持，可以帮助机器人把大量的数据和信息处理放到云端进行，大幅降低机器人成本；其宽带实时交互可以使得机器人行为、机器人与机器人的协作和执行云端命令更加实时、高效，提高工作效率。咨询服务 融资并购（融资顾问）交易支持（财务、税务尽职调查、市场分析、商业计划、财务预测、估值分析等）如何降低工业互联网的投资成本？在工业互联网下，对信息传递、储存的安全性提出了更高的要求。AI赋能下，工业机器人正在向具身智能演进 工业机器人需要专业工程师手动编写代码来改进流程，经过反复调试后，才能匹配产线特有的任务需求，开发交付门槛较高，高昂成本极大阻碍了工业机器人的普及。而在AI的引入后，可以替代工程师在循环中的位置，工程师可通过大模型自动生成代码指令完成机器人功能的开发与调试，通过高级语言命令与语言模型交互，实现无缝部署各种平台和任务。具身智能的特点是自主感知物理世界，用拟人化的思维路径去学习，从而做出人类期待的行为反馈，而不是被动的执行。从工业领域落地情况来看，目前具身智能还处在产业发展早期，AI应用集中在部分简单场景。从愿景来看，未来在工艺改进、产线设计等环节，除了一开始的人工指导和监督外，只要把任务告知具身智能机器人，即可够实现全程无人化生产，并进行自我迭代和升级。咨询服务 融资并购（融资顾问）交易支持（财务、税务尽职调查、市场分析、商业计划、财务预测、估值分析等）如何应对技术革命对现有业务的挑战和机遇？高端装备制造 工业机器人行业 13尽调常见风险提示序号问题点致同观点1核心零部件供应商集中度高且依赖进口 工业机器人的控制和驱动功能均来自于核心零部件，包含控制器、伺服电机和减速器，由于技术壁垒较高，主要核心零部件仍被国外供应商垄断，国产化率较低（整体低于35%）。虽然国内企业已基本掌握了工业机器人的设计制造技术，并且在工业机器人精密传动技术、机器人高性能控制和驱动技术、传感技术等领域的研究也有所突破。然而在核心和关键技术的原创性研究、高可靠性关键零部件、系统工艺应用解决方案以及主机批量生产等方面仍存在一些不足。技术壁垒制约国内整机厂商渗透高精度应用场景，使得高端市场难以进入。2原材料价格的波动影响工业机器人本体制造商盈利能力 核心零部件控制器、伺服电机和减速器占机器人整机成本的比例高达70%。由于国内工业机器人整机厂商采购规模相对较小，相比外资品牌没有议价权，采购成本更高。2021年以来，进口电子元器件价格上涨，交期延长，如未来工业机器人原材料出现供应不及时、价格大幅上涨或供应商中止、减少对厂商的材料供应，而工业机器人整机厂商不能采取措施转移上述压力，将会挤压盈利空间。3市场竞争加剧，毛利率下降的风险 工业机器人部分产品细分市场扔处于快速发展阶段，但随着产业引导和资本助力新的竞争对手不断加入，原有竞争对手持续发力，同时产品普及率上升，市场规模增速放缓，机器人整机厂商将面临市场竞争加剧的风险，而价格战通常成为主要的竞争方式。当厂商对成本的控制无法匹配价格的下降，将导致盈利能力下降。因此整机厂商需要紧跟市场发展趋势，有效提升技术实力和产品质量，提高管理、生产及服务能力，通过设置较高的竞争壁垒，才能应对价格战的冲击。4存货规模较高和减值风险 对于标准化的机器人整机业务，厂商生产模式通常为“以销定产”结合安全库存；同时由于部分原材料供应链较长，通常进行提前备货以应对市场需求的波动。因此，部分整机厂商存在因技术或市场变化等原因导致的存货减值风险，如因对市场判断过于乐观，存货超额备货出现跌价风险以及因客户集中度过高，销售不及预期产生库存压力。此外，对于机器人集成业务，由于需满足终端客户定制化的需求，生产周期长于标准化产品，此外交付后须经客户上线验证，长时间的验证周期（通常大于6个月）都将导致存货规模较高和周转率较低的特点。5集成业务需要较高的营运资金投入 工业机器人集成商向终端客户交付定制化集成项目（如定制化生产线、工作站等），通常与客户约定的结算模式为3-3-3-1，即预收30%，发货收款30%，验收收款30%，10%质保金在1-2年质保期后收回。由于交付后客户的长验证周期导致应收账款和存货的周转率较低，而对上游供应商的需按约定付款，无法与下游客户收款签订背靠背的协议，且对供应商的账期也远低于下游客户的回款周期，因此集成商的业务运营需要投入较高的营运资金。高端装备制造 工业机器人行业 14行业领导合伙人陈敬文 电话 86 21 2322 0279邮箱 2023 致同会计师事务所（特殊普通合伙）。版权所有。“Grant Thornton（致同）”是指Grant Thornton 成员所在提供审计、税务和咨询服务时所使用的品牌，并按语境的要求可指一家或多家成员所。致同会计师事务所（特殊普通合伙）是Grant Thornton International Ltd（GTIL，致同国际）的成员所。GTIL（致同国际）与各成员所并非全球合伙关系。GTIL（致同国际）和各成员所是独立的法律实体。服务由各成员所提供。GTIL（致同国际）不向客户提供服务。GTIL（致同国际）与各成员所并非彼此的代理，彼此间不存在任何义务，也不为彼此的行为或疏漏承担任何责任。本出版物所含信息仅作参考之用。致同（Grant Thornton）不对任何依据本出版物内容所采取或不采取行动而导致的直接、间接或意外损失承担责任。致同咨询高端装备制造 工业机器人行业小组虞玮 合伙人 电话 86 21 2322 0588 邮箱 张龑 经理电话 86 21 2322 0302 邮箱 刘访 经理电话 86 21 2322 0477 邮箱 梁家欢 项目助理邮箱 小组成员

0人已浏览 2023-12-15 16页 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星级

2 0 2 3 年深度行业分析研究报告请务必阅读报告附注中的风险提示和免责声明7目录目录一、人形机器人行业发展历程一、人形机器人行业发展历程1.1 机器人行业发展历程：诞生于实验室，工业机器人先行，走.

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

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

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

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

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

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

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

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

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

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

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

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

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

 智能焊接机器人行业深度报告：智能焊接大势所趋，智能焊接机器人行业深度报告：智能焊接大势所趋，看好具备先发优势的国产厂商看好具备先发优势的国产厂商首席证券分析师：周尔双执业证书编号：S060051511. 

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

数字经济行业系列报告2023年12月05日中航证券研究所发布证券研究报告请务必阅读正文后的免责条款部分行业评级：增持虚拟数字人行业专题报告：有“智”者事竟成中航证券社会服务团队分析师：裴伊凡证券执业证. 

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

请务必阅读正文之后的免责条款部分请务必阅读正文之后的免责条款部分 2023.12.10 AI 终端时代来临，引领消费电子新浪潮终端时代来临，引领消费电子新浪潮 王聪王聪(分析师分析师)舒迪舒迪(分析师. 

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

2023 年深度行业分析研究报告 内容目录内容目录 1.看好工业机器人赛道，受益智能制造看好工业机器人赛道，受益智能制造+国产化双重驱动国产化双重驱动.7 1.1.“机器人+”风起，看好相关产业链机会. 

0人已浏览 2023-12-14 48页 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星级

AI时代体育秒针系统秒针系统Version 20231208秒针系统营销事业部体育组Contact Us M2023体育营销白皮书体育营销的笋盘时代01体育大项的营销优势02体育营销价值洼地 潮流小众运动03AI时代体育流量新玩法04体育行业舆情大数据研究方法与数据来源体育营销行业现状研究行业专家深访数据来源 秒针魔方大数据库 秒针CSI体育明星评估数据库 秒针SEI体育节目赞助价值数据库 秒针LBS大数据 其他研究机构的数据统计通过舆情大数据去洞察体育项目热度与体育营销的活力利用CSI与SEI指数去评估主流体育赛事的赞助价值与影响力秒针LBS大数据反映国民线下参与体育活动的积极性其他机构的统计数据作为分析体育运动的补充资料分析方法通过案头研究了解体育营销行业的行业基本现状体育项目的历史产出作为对特定分析模块的信息补充数据来源分析方法数据来源分析方法秒针分析师的案头研究秒针的体育项目历史产出对品牌方、资源方、平台方的体育行业专家进行深度访谈样本量：8人专家访谈主要针对体育营销行业特征、小众潮流运动营销优势、主流赛事的营销优势等方面进行深入探讨，补充进白皮书体育营销的笋盘时代疫情消散、中国体育产业将在利好的环境中再度扬帆起航体育政策支持赛事氛围浓郁国民积极参与明确到 2035 年建成“体育强国、健康中国”。在此大背景下，近年来国家陆续出台鼓励、支持体育事业发展的政策体育强国建设纲要全民健身计划(20212025 年)“十四五”体育发展规划全国体育场所总数从2019年的354.4万个增加到2023年的450.9万个疫情管制降级之后，各项滞办、待办赛事都逐一推进，基本上每月都有重大赛事，今年全年赛事氛围浓郁2023全国帆船锦标赛2023国际泳联跳水世界杯2023世界乒乓球职业大联盟中国系列赛2023苏迪曼杯世界羽毛球混合团体锦标赛第31届世界大学生夏季运动会第19届亚洲运动会 2023年中国经常参与体育锻炼的人口超5亿2023年中国体育消费规模为1.5万亿，预计2025年将增长至2.8万亿元预计2025年中国体育产业从业人口将达到800万2023-2024年，大量重要国际赛事将会在国内外举办1月2月3月4月5月6月第31届世界大学生冬季运动会澳大利亚网球公开赛亚洲羽毛球团体锦标赛自由式滑雪和单板滑雪世界锦标赛世界速度滑冰锦标赛世界短道速滑锦标赛世界花样滑冰锦标赛世界乒乓球职业大联盟中国系列赛女子冰球世界锦标赛世界斯诺克锦标赛亚洲羽毛球锦标赛世界乒乓球锦标赛法国网球公开赛世界女排联赛世界男排联赛7月8月9月10月11月12月世界游泳锦标赛女足世界杯第31届世界大学生夏季运动会世界射击锦标赛世界田径锦标赛世界羽毛球锦标赛男篮世界杯世界举重锦标赛亚洲乒乓球锦标赛第19届亚洲运动会中国网球公开赛世界体操锦标赛上海网球大师赛世界蹦床锦标赛羽毛球世界巡回赛总决赛1月2月3月4月5月6月足球亚洲杯澳大利亚网球公开赛世界花样滑冰锦标赛世界游泳锦标赛举重亚锦赛速度滑冰世锦赛世界乒乓球锦标赛室内田径世锦赛短道速滑世锦赛花样滑冰世锦赛斯诺克世界公开赛斯巴达勇士赛羽毛球亚锦赛F1中国大奖赛2024斯诺克世锦赛汤尤杯羽毛球赛中国网球巡回赛环意大利自行车赛冰球世锦赛女排国家联赛法网足球欧洲杯足球美洲杯环法自行车赛7月8月9月10月11月12月巴黎奥运会斯坦科维奇杯洲际篮球赛环西班牙自行车赛威克多中国羽毛球公开赛公路自行车世锦赛中国网球公开赛上海劳力士大师赛WTT世界杯斯诺克武汉公开赛环广西国际公路自行车赛世界羽联中国大师赛速度滑冰世界杯中国杯帆船赛举重世锦赛中国网球巡回赛年终总决赛短道速滑世界杯世界羽联巡回赛总决赛国际乒联混合团体世界杯2023年2024年主流球类运动的声量今年获得了大幅提升，体育热度显著回暖篮球跑步路亚&垂钓登山游泳足球骑行滑雪乒乓球羽毛球高尔夫潜水棒球陆冲&滑板网球排球拳击跆拳道攀岩飞盘皮划艇桨板空手道腰旗橄榄球2023体育运动声量&互动量情况05B10B15B20B25B30B跑步篮球足球乒乓球羽毛球网球主流体育运动声量对比20222023Buzz 23%Buzz 30%Buzz 52%Buzz 26%Buzz 22%Buzz 390M20M30M40M备注：信息来源于秒针大数据库，抓取时间为 2023.01.01 2023.09.30从上海体育场与Nike篮球公园的单日人流量变化可以看出消费者对于赛事的热情依旧，从消费端为体育营销提供良好的基础上海体育场赛时人流量约为10,000人/天是非赛时单日人流的15倍040008000月12日7月22日8月1日8月11日8月21日8月31日9月10日9月20日9月30日10月10日上海体育场2023年第三季度人流变化情况中超联赛：上海申花 vs 青岛海牛中超联赛：上海申花 vs 梅州客家中超联赛：上海申花 vs 成都蓉城中超联赛：上海申花 vs 上海海港上海体育场Nike篮球公园的单日人流高峰均出现在街头篮球赛事期间-2,000 4,0007月12日7月22日8月1日8月11日8月21日8月31日9月10日9月20日9月30日10月10日Nike篮球公园2023年第三季度人流情况NBA2023 街球霸王全明星赛腾讯“篮球风暴”上海站备注：信息来源于秒针LBS数据篮 球球星相关声量占50%赛事相关声量占30%主流运动的声量主要集中于赛事和体育明星50 0%排 球乒 乓 球46D%球星相关声量占44%赛事相关声量占46d%球星相关声量占64%赛事相关声量占16%足 球网 球羽 毛 球球星相关声量占38%赛事相关声量占41%球星相关声量占38%赛事相关声量占37%球星相关声量占38%赛事相关声量占23%备注：数据来源于秒针大数据库41!8r8%798#0A1pYi%主流运动项目的声量大数据中运动赛事的声量占比表现不俗，进一步推动品牌方对赞助运动赛事的关注男篮世界杯CBACUBA202324274年份赛事上海马拉松重庆马拉松无锡马拉松202320 (尚未举办)3534202221417年份赛事世界杯女足世界杯中超-6201915911年份赛事篮球赛事声量在篮球总声量中占比30%足球赛事声量在足球总声量中占比41%跑步赛事声量在跑步声量中占比31%跑步篮球球品牌方对体育赛事的赞助热情上升运动赛事在运动话题声量中占比显著备注：运动项目大数据的抓取时间跨度为2023年1月1日 2023年9月30日，来源于秒针大数据库；体育赛事赞助情况来源于百度、搜狐新闻；品牌方赞助情况表格里面的数字是比赛的赞助商数量。50P%体育明星带来的声量占比相较于运动赛事更加显著品牌方在进行体育营销的时候越来越重视对体育明星的投入我国运动员近年代言签约数量体育明星声量在相应运动总声量中占比显著备注：2023年的数据日期范围为2023年1月1日至2023年8月24日；代言统计来源于 中国青年报、艾漫数据等38b%篮球总声量的50.2%都来自球迷对于篮球明星的关注，篮球明星对于体育营销的声量贡献作用巨大足球总声量的38%都来自球迷对于足球明星的关注，足球明星对于制造体育营销的声量，增加品牌曝光度非常重要1612021年2020年852019年762018年422017年382016年222015年8不同于主流运动的声量主要来源于赛事和体育明星潮流、小众运动的声量则更多是UGC声量87UbXxrrR%UGC 声量占62%UGC 声量占58%UGC 声量占78%骑行高尔夫皮划艇登山棒球拳击滑雪UGC 声量占72%UGC 声量占72%UGC 声量占52%UGC 声量占87prUWW%UGC 声量占70%UGC 声量占85%UGC 声量占72%桨板腰旗橄榄球陆冲&滑板攀岩路亚&钓鱼潜水飞盘UGC 声量占55%UGC 声量占57%UGC 声量占57%UGC 声量占55r%备注：信息来源于秒针大数据库主流运动的社媒声量整体领先于大部分潮流小众运动，但潮流小众运动的UGC含量更高，且声量同比增长更高，两类运动各有千秋，都是体育营销的良好载体不同运动项目的声量情况与UGC声量占比情况0 0Pp0%(20.00)-20.00 40.00 60.00 80.00 100.00 120.00 140.00 160.00声量同比增幅UGC声量占比备注：信息来源于秒针大数据库，抓取时间为 2023.01.01 2023.09.30 与 2022.01.01 2022.09.30篮球足球路亚&钓鱼游泳羽毛球乒乓球网球排球跑步登山骑行滑雪陆冲&滑板潜水棒球高尔夫拳击腰旗橄榄球皮划艇攀岩飞盘桨板2023年前九个月的运动声量决定气泡大小潮流小众运动UGC声量中大部分为参与运动的分享但也有不少声量是在线讨论运动装备以及关注运动旅游UGC声量话题占比分享参与运动的常分享他的运动趣事运动装备相关运动旅游37.5 %5%备注：信息来源于秒针大数据库受到滑雪、冲浪等小众运动参与度上升的推动体育旅游的相关声量在近些年有明显上升中国的发展情况在中国都有哪些主要形式登冲浪滑雪滑沙骑骆驼骑早期的体育旅游一直以马拉松、登山等单项赛事为主体，种类单一。如今体育旅游产业结构呈现出丰富多彩的发展格局，包括草原项目、水上项目等多种类型的体育旅游产品已经开始得到市场的认可。截止2021年中国体育旅游行业市场规模达12718.8亿元，预测2026年可达到38814.5亿元。30(2A%9$&)0qFF9(!%0P0%漂流登山骑马冲浪滑雪2021-2023热门体育旅游项目声量趋势202)F%94)926I2!1%0P0%漂流登山骑马冲浪滑雪2021-2023热门体育旅游项目互动量趋势202120222023备注：信息来源于秒针大数据库体育旅游构成了部分地区经的济重要创收来源受到政府的鼓励与支持，这项产业将会在全国范围内受到重视、并持续带动地方经济发展备注：数据来源于体育旅游经济及社会影响、中国经营报、万宁发布厅从全球市场来看，体育旅游占旅游市场的平均比重是15%，发达国家则高达25%，而我国目前的占比仅为5 20年，我国体育旅游总人数达到10亿人次，总消费规模突破1万亿元，并在政府政策支持下不断扩张冰雪旅游资源集中的张家口市，冰雪旅游成为该市经济重要引擎创造就业：2022年张家口崇礼区，每4个人中就有1人从事跟冰雪相关工作，超过3万人直接或者间接进入了冰雪产业或旅游产业，其中包括了9,000人的贫困人口拉动投资：截至2022年初，张家口累计签约冰雪产业项目109个，包含价值40亿的冰雪装备研发制造项目54项推动经济：预计到2025年，张家口将接待冰雪游客1500万人次，冰雪旅游收入达到400亿元海南万宁市作为冲浪资源丰富的城市，跟上了体育旅游的风潮，努力奔向百亿级的产业集群城市万宁不断建设包含冲浪、海上低空飞行等项目的旅游产业，并于2023年一季度接待122万游客，创造20多亿的旅游收入2023年中秋国庆长假，万宁三大湾区共接待游客47万人次，实现旅游收入2.5亿元体育装备制造业同样可以从潮流小众运动发展中获取红利,年轻群体作为潮流小众运动主要参与者，其对于运动装备的积极消费态度，将极大刺激体育装备制造业的发展备注：数据来源于艾瑞咨询中国年轻人运动发展白皮书中国年轻群常消费的体育品类285.50.70G.10G.70a.30d.60%报名参加各种比赛支付运动场地费用观看体育赛事费用报名运动培训购买健康食品购买鞋服购买运动器材/配件中国年轻群体购买体育装备年均花费86.6%的户选装备时偏好型专业运动装备制造商5.9.45.2#.0%7.8%5.7%8K中国年轻滑雪爱好者运动为及消费特征消费情况平均年消费额：5429.3 元消费品类TOP5：雪具购买-67.7%雪具租赁-56.3%滑雪场票-52.6%滑雪培训课程-48%护具-43.8%消费趋势62.9%的近5年在滑雪运动上消费呈现增加势头消费增加的品类主要是雪具购买 或 租赁、滑雪场票滑雪是年轻人参加潮流小众运动时消费支出最多的运动，人均年消费达到5,429.3元，高于大部分其他运动滑雪爱好者认为更好的滑雪装备是他们提升专业水平的最主要方式，具备此类认知的爱好者占消费群体的60.7%潮流小众运动发展红利的外溢不仅仅带动了相关产业其自身具备的优质属性使得这一领域非常值得去做体育营销位处时代前沿的小众运动，一方面可以满足大众的好奇新鲜感，另一方面也是能够彰显身份的个性化标志。位处高线城市的高收入高认知人群，同时也更认同关注潮流品质运动。小众潮流赛事垂直对标于高净值人群，匹配程度高人群接受度高。在日益复苏的经济趋势和利好的政策驱动下，小众潮流有望成为尚未被重视的体育价值洼地。运动带来即刻积极的大脑反馈和长期健康的生活状态，形成正向闭环。体育大项的营销优势主流体育赛事是体育营销的传统重心，受关注度高、曝光效果好、触达人群广，刚过去不久的足球世界杯的调研数据就很好的诠释了这些特征备注：数据引述自2023年1月秒针为在世界杯投放广告的客户所做的营销效果评估报告。世界杯关注程度31.1 41.9 18.8 6.3 完全不关注不太关注一般比较关注非常关注91.8%世界杯调研收视率93.2.2%狂飙调研收视率乘风破浪3调研收视率46.7F.7X.6X.6%世界杯秉承着传统主流体育赛事的营销特征，广告营销形式丰富，赛场内外相辅相成，并且不断补充新的营销形式进入品牌营销中，为品牌方提供多样化的选择备注：数据引述自2023年1月秒针为在世界杯投放广告的客户所做的营销效果评估报告。球场-画外音广告球场-角标球场内营销球场-显示屏球场-球衣赞助球场-虚拟Logo演播室-大屏背投场外营销-球星代言场外营销-品牌赞助球场外营销（演播室&线上）演播室-主持人口播演播室-桌面摆件场外营销-官方推广NBA营销平台价值不可小觑，2023NBA季候赛总决赛的话题热度是年度体育赛事基准值的两倍，观众对节目满意度高达96%备注：数据引述自2023年7月秒针为在NBA季后赛总决赛投放广告的客户所做的营销效果评估报告。NBA2023全明星赛总决赛的节目关注与参与指数趋势NBA2023全明星赛观看与喜爱率趋势103.08112.28102.16204.04210.10188.200250week 1week 2week 3Benchmark93.35Benchmark107.22关注指数参与指数关注指数Benchmark参与指数Benchmark24%#%0 00%week 1week 2week 3Benchmark20.5nchmark92.2%调研观看率喜爱度调研观看率Benchmark喜爱度Benchmark球场内营销球场外营销（演播室&线上）NBA同样为品牌方提供了场内外多种类型的广告位供营销投放，通过在直播右下角植入购买链接的【边看边买】广告位更是为品牌直接带来了流量转化备注：数据引述自2023年7月秒针为在NBA季后赛总决赛投放广告的客户所做的营销效果评估报告。球场-场边显示屏球场-球衣赞助球场-IGE球场-虚拟地贴演播室-桌面摆件场外营销-中插广告场外营销-官方推广球场-镜外画面演播室-主持人口播演播室-大屏背投场外营销-边看边买作为主流赛事的延申贵州村超承接着主流比赛的关注度外溢红利，同样能够作为体育营销的良好载体备注：贵州村超数据来源于秒针大数据库、秒针Social X，其他信息参考清研智谈“村超”出圈，掀起贵州乡村文旅发展新浪潮擅用传播媒介积极与主流媒体合作，利用央视、新华社、人民日报、光明日报等不断扩大知名度重视自媒体平台，快速开通线上官号进行圈粉，抖音官号已经积累125万粉丝与足球名宿（范志毅等）、明星（香港明星足球队）足球评论家（韩乔生）联动，制造热点，增温宣传实力引流客群2023年村超开赛后一个月，吸引游客42万余人次，包含外地游客11.61万人次村超所在的榕江县5月接待游客107.37万人次，住宿业同比增长30.7%，环比增长89.9%，餐饮业同比增长50.5%，环比增长42.8 23贵州村超声量823234084450200000400000600000五月六月七月八月（4个月声量高达93万）村超在多个社交平台热度榜居榜首成熟的运营手段曝光度高村BA在多个社交平台热度榜居榜首平台直接下场运营通过与知名篮球KOL联动等方式，对现场赛事进行解读，打造篮球圈层的整合营销直播之外，还推出纪录片村BA“全民心”，带动更多的人了解贵州举办地的篮球文化底蕴，感受“村BA”质朴、美好的体育精神，以情感为连接、构建深度内容，引发大众情感共鸣“快手贵州村BA”直播总观看人次超3亿相关话题视频播放量达4.5亿#村BA又开打了“、”#在家乡为热爱上投“、”#村篮球队原来这么厉害“等话题斩获161个热榜知名品牌方赞助京东健康、杰士邦等品牌已经与“快手贵州村BA”进行商业合作备注：贵州村BA数据来源于秒针大数据库、秒针Social X，其他信息参考搜狐“快手村BA”贵州站出圈背后2357542490279275078834404000008000001200000七月八月九月十月（4个月声量高达150万）2023贵州村BA声量贵州村BA在声量、热度方面同样是不容忽视的体育营销载体纵观整个体育营销领域主流赛事能够为品牌方提供更广泛、更下沉、更深度、更多频次的曝光主流赛事的高关注度是提升品牌知名度的捷径多样化的广告位投放能提高品牌回想度品牌与赛事的场外联动能做更有效的观众渗透主流赛事的延申赛事为品牌提供下沉曝光渠道短视频平台传播是主流赛事与广告提升二次曝光的良好媒介体育营销价值洼地 潮流小众运动对于品牌方来说潮流小众运动的体育营销尚处于起步阶段，赞助商不饱和是常态，合作空间大传统运动2023美国职业足球大联赛新潮运动2023橄榄球CNFL常规赛美国职业足球大联赛2023赛季美国职业足球大联赛2023赛季赞助商合作商类型多达25种，涵盖方方面面CNFL，为华美橄榄球联盟简称。作为国家高水平成人业余联赛之一，也是中国最早的民间美式橄榄球联赛。2023CNFL常规赛场地内未展示出明显的赞助商广告潮流小众运动的赞助商以普通赞助商为主品牌方的赞助门槛低备注：数据来源于各小众运动的官方海报或者官方发文新潮运动赛事涌现赛事品牌赞助商大部分较为小众冲浪2023“青岛杯”冲浪公开赛锐速特 Beach Business 思德运动 板式网球2023年昆明HEAD杯板式网球邀请赛海德中国 HEAD CHINA 农夫山泉橄榄球2023首届北京腰旗橄榄球公开赛卡尔美体育 燃力士 DODOWA路亚2023岸钓之王全国巡回赛NS SHIMANO禧玛诺滑板2023第四届开封长板公开赛魔术师长板 与板 CLOUDWHEEL云轮 逆山长板皮划艇2023西青漂岛皮划艇赛乐划桨板 Maxped战马能量饮料 Molokai桨板（业余赛事）（业余赛事）（市级赛事）（业余赛事）（市级赛事）（市级时尚体育联赛）相较于传统体育而言潮流小众运动的体育营销形式更灵活多样，更适合品牌方去实现多种方式的人群触达传统运动马拉松官方赛事新潮运动越野跑赞助商以传统的展架广告版呈现（2023年哈尔滨马拉松）赞助商以传统的旗帜&横幅广告呈现（2023年上海马拉松）马拉松作为国际普及的长跑项目，历届举办赛事已较为成熟。马拉松赛事赞助品牌多以传统的实体展牌呈现。与主流平台合作，参与可得品牌产品。增加曝光率的同时，与消费者互动性更强。运动类博主社媒传播，比起传统电视转播，品牌触达率更高。越野跑作为疫情后新起的户外运动，受到年轻人的广泛关注。小众运动赛事规模还未成熟，且更易融入“互联网 体育”的全新业态。从数据角度来看，潮流小众运动的声量基本都呈现较高的涨幅，大部分运动的互动也增幅明显，这些运动在消费端的受关注度与热度直接体现了其良好的营销载体的价值声量互动量同增幅声量同增幅互动量互动量/声量21M910M 106% 59B18M796M 128% 56E6M383M 14% 13g5M102M 21% 8 4.4M173M 1% 894.4M280M 12%-24d3.9M83M 62% 1!2.4M226M 17%-141.2M29M 18%-4$1.1M28M 13%-54&0.7M21M 60% 11700.5M14M 151% 129&0.1M2M 9%-55$单位：M（百万）骑行高尔夫皮划艇登山棒球拳击滑雪桨板腰旗橄榄球陆冲&滑板攀岩路亚&钓鱼潜水飞盘备注：声量、互动量数据来源于秒针魔方大数据库，覆盖时间段为2022年1月1日 2022年9月30日、2023年1月1日 2023年9月30日.31M1,516M 84%-6P包括耐克、棒约翰等市场主要品牌在内的一些品牌已经注意到“骑行”运动所蕴含的营销价值Nike 联合RE 赞助23年的“北京城市涂鸦”骑行活动棒约翰今年在沪开设全国首家“骑行”主题餐厅骑行者小红书发帖主办方宣传照上海定西路餐厅小红书KOL宣传推广Ocean Pacific 联合 RIO赞助2022年上海“为浪而生”陆冲板比赛陆冲板小红书KOL与多个品牌合作进行产品推广RIO则在陆冲板赛事领域先人一步，率先实现营销赞助除了品牌对运动赛事的直接赞助，潮流小众运动的KOL也率先收到了运动品牌的关注AdidasOn昂跑Converse匡威Surpine松野湃主办方宣传片陆冲板玩家小红书发帖总而言之，潮流小众赛事作为体育营销的价值洼地，能够为品牌方提供更垂直、入门更低、更多样化的营销合作潮流小众赛事的垂直性是品牌方搅动圈层营销的法门成长在主流赛事的热度阴影下，营销价值鲜少被品牌方注意到，合作空间大价值洼地属性能够提供更低的经济门槛UGC含量更高的前提为线上多样化营销提供沃土不断壮大的运动声量赋予品牌方借势而上的机遇AI时代体育流量新玩法资源定位预算大小发掘体育价值洼地顶级体育资源布局品类相关垂直体育资源布局体育营销策略画布打造顶级IP赞助壁垒培养专业体育资源伏击营销社群营销Last Minute资源精准触达科学评估沉淀资产KOLKOLKOCKOC线上：定向人群饱和触达线下：场景植入运动垂直受众触达率ROI(品牌收益/转化收益)品牌&运动项目关联用户运动标签社群沉淀通过大数据表现，了解各类运动的热度与粉丝圈层情况，确定营销蓝海跨平台实现数据打通，丰富潜客兴趣标签，实现多平台触达 建设私域渠道（如 App、小程序），获得潜客更多社交层面信息 与社媒平台拓展合作，打通生态，赋予单一潜客更丰富立体的标签，赋能精准投放利用大数据与用户圈层研究的方法确定体育营销洼地 潮流小众运动热度大数据 潮流小众运动粉丝圈层研究 发现优质潜力KOL/KOC识别体育营销洼地新时代玩转体育流量的框架构想AIGC赋能营销曝光利用AIGC技术批量生成营销软文，通过KOC实现垂直受众高频次种草曝光 立足传播数据表现，结合品牌受众与KOL&KOC粉丝圈层的重合度，选择合适的KOL&KOC 利用AIGC技术，为KOL&KOC软文的生产传播提升效率，增加曝光与触达垂直兴趣人群精准触达秒针大数据平台秒针运动行业知识图谱秒针消费者圈层研究秒针AIGC能力数据治理数据储存数据安全人工智能识别体育营销洼地、优化潜客精准触达、AIGC赋能营销曝光是新时代玩转体育流量的三驾马车与主流赛事的体育营销合作必不可少，是品牌增加曝光的最直接的方法，潮流小众赛事则能够帮助品牌精准触达潜客，是不能被忽视的价值洼地主流赛事潮流小众赛事与主流赛事的合作，是体育营销的基建工程受益于主流赛事拥有庞大粉丝群体，品牌认知会获得广泛传播“积极、拼搏”是不少品牌希望从体育营销中获得的形象标签，主流比赛能很好满足大部分品牌的营销需求与潮流小众赛事的合作，是体育营销的精确制导潮流小众赛事粉丝群体更加垂直潮流小众赛事更能吸引个性鲜明、热衷尝试的受众，为品牌提供良好的营销基础从运动的社会热度、热度增幅、赛事成熟度、运动赛事合作难度等维度去筛选出体育营销的价值洼地潮流小众运动舆情声量声量增幅赛事成熟度整体合作难度价值洼地属性强弱路亚&垂钓20.9M72%骑行12.3M119%羽毛球4.4M26%高尔夫3.8M16%棒球3.3M123%陆冲3.3M12%网球2.7M22%桨板0.4M184%腰旗橄榄球0.1M54%非常一般体育营销需要从价值洼地中选择最适合品牌的潮流小众运动进行合作，圈层研究能够很好的赋能选择 适合品牌：有明确的目标人群倾向的品牌营销活动 选择依据：圈层的 性别 x 年龄 x 地域 x 收入 等 输出：目标人群覆盖最多、浓度最高的圈层根据品牌目标人群（TA）匹配性选择 适合品牌：对TA没有具象化的要求，希望寻找最具影响力的圈层，进行大面积的品牌传播营销活动 选择依据：圈层的规模、声量、增长率 输出：当前声量最高，规模最大，增长力最快的圈层根据圈层影响力选择 适合品牌：对营销活动的直接转化和销量要求高，希望传播能直接带货 选择依据：圈层对制定品类/品牌的讨论量、讨论占比 输出：对目标品类关注最多、讨论最多的圈层根据品类相关性选择因共同兴趣、爱好、价值观、社会属性等共性特征而集聚，形成具有一定文化认同感或共性目标的社群或部落，即圈层圈层的定义与圈层营销的执行手段进行潮流小众运动营销的品牌一般都目标明确，更适合这项原则社交媒体内容设计更注重兴趣导向，对运动社群可以结合数据做进一步细分，找到最适合目标人群的兴趣场景专业运动赛事APP运动小程序报名入口品牌A祝贺XXX夺冠赛事夺冠时刻赛场广告牌伴随各类赛事兴起，新的运动线上入口涌现，品牌可抓住机遇精准触达兴趣受众除了直接触达潜客，KOL的带货营销也必不可少，潮流小众运动的KOL同样需要进行分级,而KOC做为越来越受关注的资源，则非常考验营销者的群控技术行业特征粉丝多元性不显著较显著单圈层多圈层KOL层级特征T1超头部T2头部T3肩部T4腰部T5(KOC)尾部制造&迅速引爆话题种草品类广泛扩大传播声势&加强背书种草品类较专调动参与度&深化认知种草品类精专击破圈层&深度种草跨圈层种草能力初现二次传播&口碑裂变类朋友圈种草小红书抖音微博转化效率转化效率转化效率AIGC技术可以被用来赋能KOC渠道实现品牌的高频曝光，并且能够统一每一篇营销软文的质量AIGC在营销物料上的应用AIGC赋能KOC软文生产的流程文本生成 结构化写作：新闻稿 非结构化写作：故事情节续写 辅助性写作：文本润色 闲聊机器人 文本交互游戏图像、视频、文本间跨模态生成 文字生成图像 文字生成演示视频 文字生成创意视频 图像/视频到文本：视觉问答系统视频生成 视频属性编辑：删除特定主体 视频自动剪辑 视频部分编辑：视频换脸等图像生成 图像编辑工具：去除水印 创意图像生成：生成画作 功能性图像生成：生成海报AIGCAIGC生产内容专业团队二次加工初次内容初次内容多样化内容推送KOLKOL用户发布关于我们 秒针系统是明略科技旗下专注于营销实效管理的专业品牌，将营销实效管理拆分成流量实效、内容实效和用户实效三大能力，通过测量、洞察、优化，形成营销实效闭环，为企业提供一站式营销数字化服务。帮助品牌突破现有瓶颈，引发营销生产力的大爆发，帮助广告主实现千人千面营销的测量、洞察和优化。扫码咨询 体育营销相关干货/咨询

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

版权归属 上海嘉世营销咨询有限公司人形机器人行业简析报告商业合作/内容转载/更多报告01.全球机器人行业进入智能应用期数据来源：公开数据整理；嘉世咨询研究结论；图源网络全球机器人行业的发展经历了萌芽阶段（20世纪40-50年代）、初级阶段（20世纪60-70年代）、迅速发展阶段（20世纪80-90年代）、智慧化阶段（21世纪初-至今）等四个阶段。当前阶段，随着感知、计算、控制等技术的迭代升级和图像识别、自然语音处理、深度认知学习等人工智能技术在机器人领域的深入应用，机器人领域的服务化、智能化、通用化趋势日益明显。在日本，机器人的关键性部件减速器是遥遥领先的，并且已经形成了技术壁垒；德国则在原材料、本体零部件具有很大的优势；美国当前在人形机器人方面、机器人AI技术方面引领潮流。全球机器人历史发展阶段20世纪40-50年代萌芽阶段20世纪60-70年代初级阶段20世纪80-90年代迅速发展阶段21世纪初至今智慧化阶段美国橡树岭等国家实验室取得初步研究成果1945年第一台可编程式机器人诞生，具备了机器人雏形德国、日本第二次世界大战后劳动力短缺，工业基础好按程序重复作业计算机技术、传感器技术迅速发展具备初步感知、反馈能力，在工业生产中广泛应用制造业升级，工业自动化，机器人代替人具有逻辑思维、决策能力02.“具身智能”被认为是人工智能的终极形态数据来源：公开数据整理；嘉世咨询研究结论；图源网络具身智能（Embodied AI）指的是具有身体的人工智能，是AI进入物理世界交互的载体。它包含AI领域几乎所有的技术，包括机器视觉、自然语言理解、认知和推理、机器学习、机器人学等，横跨多个学科方向，是人工智能的集大成者。目前，具身智能已经成为国际学术前沿研究方向，包括美国国家科学基金会在内的机构都在推动具身智能的发展，各大国际学术会议也在越来越多地关注具身智能，美国顶尖高校已经开始形成具身智能研究社区。具身智能为人工智能终极形态具身机器人四大挑战形态生成形态生成形态生成进化优化人工设计强化学习形态行为学习利用形态产生行为利用形态控制行为利用学习提升行为利用行为实现学习利用学习优化形态机器人不能够像大语言模型一样有一个基础大模型直接一步到位，做到最底层的控制。如何把机器人多模态的感官感知全部融合起来，仍面临诸多难题需要解决。机器人的发展需要收集很多数据，其中也面临很多安全隐私等方面的问题。计算能力的挑战。即使谷歌Transformer模型，要做到机器人控制，距离实际需要的控制水平仍有许多事情要做。0102030403.人形机器人有望成为“具身智能”终极载体数据来源：公开数据整理；嘉世咨询研究结论；图源网络人形机器人一方面由于其与人类相似，能够更好地服务人类，所以有望成为数量最大的机器人类型；另一方面由于其下游应用广泛，所以有望接触更多复杂场景。得益于未来人形机器人基数大&场景复杂的特性，其有望成为具身智能最好的载体。今年，微软、OpenAl、Engineered Arts、特斯拉等公司相继推进 AI 机器人布局，且已有人形机器人投入实际使用，如1X Technologies披露其人形机器人EVE自今年4月以来已在美国和欧洲投入实际工作（担任保安）。2023年2月微软 宣布正在探索如何将ChatGPT扩展到机器人领域，旨在让人类用自然语言控制机器人等硬件平台。4月腾讯、小米 腾讯Robotics X实验室推出自研机器人灵巧手(TRX-Hand)和机械臂(TRX-Arm);北京小米机器人技术有限公司成立。6月英伟达、谷歌 英伟达开发IndustReal用于帮助机器人解决仿真中的装配任务;谷歌DeepMind推出用于机器人的AI智能体。3月Open Al,Engineered Arts OpenAl 领 投 挪 威 人 形 机 器 人 公 司1XTechnologies;Engineered Arts 展 示 接 入 GPT-3 的Ameca.5月特斯拉、英伟达、1X、优必选 2023特 斯拉股东大会.上展示了接通FSD算法的人形机器人Optimus最新进展;黄仁勋表示人工智能的下一个浪潮将是具身智能;1X Technologies人形机器人已在美国和欧洲担任保安;优必选发布Walker X在智慧工厂“中工作的演示视频7月达闼、谷歌 达闼展示接入大模型的类人形机器人;李飞飞团队将大模型接入机器人实现零训练行动规划;谷歌发布机器人研究新进展RT-2。04.软件决定人形机器人高度数据来源：公开数据整理；嘉世咨询研究结论；图源网络人形机器人本质是AI系统落地物理世界的最佳载体，算法是核心，需与硬件匹配。算法对运动能力的控制，包括本体平衡、行走的步态、手部抓取等规划与控制。这需要成熟的感知系统基础、强大的算法分解任务和规划动作、大模型不断仿真训练以及超强的算力支撑，同时要求算法与硬件相匹配。这要求机器人企业需自研算法，并持续更新迭代。人形机器人产业链主要包括上游的核心零部件，例如无框力矩电机、空心杯电机、传感器、专用芯片等；中游为机器人本体制造，包括设计、制造、测试三大环节;下游为人形机器人应用领域，包括工业制造、仓储物流、医疗服务、商业服务、家庭使用等。人形机器人软硬件架构示意图 世界模型工艺参数文本编程语言工艺参数图形化编程语音指令工具模型感知模型拖动示范离线编程自助规划规划控制建模支持模块接口RT-Platform RT-Runtime第三方支持库RT-OSALNonkT-Runtime操作系统无框力矩电机空心杯电机编码器丝杠传感器减速器芯片 任务层任务层操作系统操作系统层支持库层支持库硬件层硬件层实时控制层实时控制层04.软件决定人形机器人高度数据来源：公开数据整理；嘉世咨询研究结论；图源网络人形机器人行业产业链 上游-核心零部件中游-人形机器人本体下游-人形机器人应用无框力矩电机动力电池空心杯电机热管理系统减速器传感器编码器专用芯片行星滚柱丝杠执行器总成 机器人本体设计机器人本体测试机器人本体制造工业制造商业服务仓储物流家庭使用医疗服务 05.人形机器人三大驱动模式数据来源：公开数据整理；嘉世咨询研究结论；图源网络人形机器人包括液压，气动和电机三种驱动方式。相比于液压驱动、气动驱动，电机驱动可采用多种灵活的控制方案，运动精度高，成本低，驱动效率高，能保证机器人能完成高复杂、高精度的动作。因此，基于电机驱动的人形机器人商业化机会更高。驱动方式液压驱动气动驱动电机驱动特点液压驱动系统通常由液动机(各种油缸、油马达)、伺服阀、油系、油箱等组成，以压缩机油来驱动执行机构进行工作。气力驱动系统通常由气缸、气阀、气罐和空压机(或由气压站直接供给)等组成，以压缩空气来驱动执行机构进行工作。电力驱动是利用电动机产生的力矩，直接或经过减速机构驱动机器人，以获得所需的位置、速度和加速度。优点操作力大、体积小、传动平稳且动作灵敏、耐冲击、耐振动、防爆性好。空气来源方便、动作迅速、结构简单、造价低、维修方便、防火防爆、溜气对环境无影响。电源易取得，无环境污染，响应快，驱动力较大，信号检测、传输、处理方便，可采用多种灵话的控制方案，运动精度高，成本低，驱动效率高。缺点液压驱动系统对密封的要求较高，且不宜在高温或低温的场合工作，制造精度较高，成本较高。操作力小、体积大，由于空气的压缩性大、速度不易控制、响应慢、动作不平稳、有冲击。动态形态有限、功率密度有限。使用范围液压系统具有较大的功率体积比，适合于大负载情形:安全要求高的场景。因气力驱动系统的压强一般只有60MPa左右，此类机器人适宜抓举力要求较小的场合。适合于中等负载，动作复杂、动作轨迹严格的机器人应用产品波士顿研发的Atlas东京大学研发的Liberobot本田ASIMO、AgilityRobotics研发的Digit、优必选Walker、特斯拉Optimus06.我国政策引导人形机器人产业发展数据来源：公开数据整理；嘉世咨询研究结论；图源网络2023年我国相关政策密集出台，积极推动人形机器人产业发展。2023年5月31日，深圳市提出建设1000亿元人工智能基金群，推动智能机器人发展；6月15日，上海市在三年计划中提出加快人形机器人创新发展；6月28日，北京市提出集中突破人形机器人原型机关键技术；9月13日，工信部以榜单的形式鼓励各社会部门积极突破人形机器人核心技术。目前人形机器人产业尚处发展初期，我国各部门相关政策的密集出台有助于抢占行业先机，为人形机器人产业创建良好的发展环境，未来人形机器人行业有望在政策的持续催化下迎来加速发展的契机。我国政策引导人形机器人产业发展 地区文件内容2023/5/31深圳市深圳市加快推动人工智能高质量发展高水平应用行动方案(2023-2024年)统筹设立规模1000亿元的人工智能基金群，创建人工智能先锋城市;提出民生诉求平台嵌入民意速办AI机器人，积极孵化高度智能化的生产机器人，孵化高度智能化的生产机器人。.2023/6/15上海市上海市推动制造业高质量发展三年行动计划(2023-2025年)深入贯彻制造强国战略，努力打造高端制造业增长极;打造世界级产业集群，提出加快人形机器人的创新发展。2023/6/28北京市北京市机器人产业创新发展行动方案(2023-2025年)加快推动机器人产业创新发展，紧扣机器人智能化、仿生化、模块化发展趋势，打造全球机器人产业高地;加紧布局人形机器人，支持高效和企业开展人形机器人研发攻关，集中突破人形机器人通用原型机和通用人工智能大模型等关键技术。2023/9/13工信部2023年未来产业创新任务揭榜挂帅工作加快人形机器人等未来产业的创新发展，鼓励企业、金融机构、科技服务机构、高校、科研院积极参与，发掘培育一批掌握关键核心技术、具备较强创新能力的优势单位，突破一批标志性技术产品，加速新技术、新产品落地应用。07.人形机器人市场规模或超千亿美元数据来源：公开数据整理；嘉世咨询研究结论；图源网络人形机器人应用领域广泛，理论上能应用于绝大多数行业。传统的机器人分为工业机器人、服务机器人和特种机器人三类，能覆盖的下游场景有限，而人形机器人在结构上与人类类似，理论上能覆盖所有涉及人类作业的下游场景，未来有望应用于多个下游行业。据高盛预测，未来1015年人形机器人市场空间至少达60亿美元，最理想情况下预计2035年人形机器人市场空间有望达1540亿美元。从远期来看，马斯克预计人形机器人数量将远超电动车，假设人形机器人与人口比例为2：1，未来人形机器人需求量有望达到100200亿台。2026-2030 年全球及中国人形机器人行业市场规模预测(亿美元)2022-2028全球人形机器人市场规模预测趋势（亿美元）020406080020222023E2024E2025E2026E2027E2028E05002026E2030E全球中国08.人形机器人零部件国产替代空间大数据来源：公开数据整理；嘉世咨询研究结论；图源网络2023年人形机器人核心零部件价值量排名前三的是无框力矩电机、减速器和力传感器;2030 年无框力矩电机价值量占比下降，力传感器、减速器价值量占比上升，且力传感器将超过减速器，排名第二、三者合计占比仍超过 50%。从单机价值量占比来看，无框力矩电机、减速器和力传感器价值量占比较高；从降本空间来看，空心杯电机、无框力矩电机等降本空间较大；而从国产替代空间来看，行星滚柱丝杠、空心杯电机、惯导 imu 等国产化率较低，国产替代空间大。2023 年人形机器人核心零部件价值量分布图预测中国人形机器人行业核心零部件国产替代空间对比21.0.0.0.0%4.0%1.0(.0%无框力矩电机减速器力传感器丝杠空心杯电机惯导imu其他核心零部件2023单机价值量占比国产化率部分代表企业无框力矩电机21%中等步科股份、利川科技、昊志机电等减速器16%较高绿的谐波、昊志机电、国茂股份、秦川机床、丰立智能双环传动、中大力德、科风智能等力传感器16%中等柯力传感、昊志机电等丝杠14%低五洲新春、新剑传动、贝斯特、恒立波压、秦川机床、鼎智科技、利川科技、长盛轴承、南京工艺等空心杯电机4%低鸣志电器、鼎智科技(江苏雷利)、托邦股份等惯导imu1%低芯动联科、华依科技、苏州固锝等09.中国第一、二产业人形机器人替代市场空间大数据来源：公开数据整理；嘉世咨询研究结论；图源网络农业机器人的成本偏高被认为是其发展的最大制约因素之一，制约了市场的增长。随着未来人形机器人成本的下降，农业人形机器人将有巨大的机会。根据中国煤炭工业协会数据，一个人形机器人可以不间断的工作，替代3个矿工，按照1：3的比例，人形机器人在中国煤矿领域潜在的市场空间也达千亿元。未来人形机器人可替代“危、繁、脏、重”施工作业。这部分工作若由人形机器人代替，考虑到建筑行业是世界上数字化程度最低、自动化程度最低的行业之一。即使在1%替代率的保守假设下，按机器人单体30万的价格来计算，国内潜在市场空间也在千亿以上。我国第一、二产业人形机器人替代市场空间预测当前就业人数（万人）机器人单价（万元）预计替代比例（下限）预计替代比例（上限）潜在市场空间下限（亿元）潜在市场空间上限（亿元）农业17700301%5S1026550建筑592当前就业人数（万人）机器人替人比例机器人单价（万元）机器人数量（万）潜在市场空间（亿元）煤矿1221：330411220制造业104711：3.33031739519410.中国第三产业人形机器人替代市场空间数据来源：公开数据整理；嘉世咨询研究结论；图源网络在家庭服务机器人领域，“陪伴”是一个未被解决的刚需。陪伴机器人就是以情感识别为特征，聚焦家居陪伴，涵盖儿童陪伴、老人陪伴、宠物陪伴等场景，而人形机器人的独特优势正有望替代家政清洁和家庭陪伴两种刚需场景，可有粘性地融合于家庭，成为智慧家庭的一部分。物流工作重复性、机械性较强，且工作时长较长，较大的工作强度使得机器人方案具备合理性。这部分物流的工作若由人形机器人代替，即使在5%替代率的保守假设下，仅国内潜在市场空间就在千亿以上。在商用领域，仅假设餐饮、旅游和酒店三个细分赛道，用保守5%的人形机器人替代率，未来国内市场空间就可以达到百亿元。我国家庭/物流行业人形机器人替代市场空间预测我国商用行业人形机器人替代市场空间预测当前就业人数（万人）机器人单价（万元）预计替代比例（下限）预计替代比例（上限）潜在市场空间下限（亿元）潜在市场空间上限（亿元）家庭服务37603050V4033840细分领域当前就业人数（万人）机器人单价（万元）预计替代比例（下限）预计替代比例（上限）潜在市场空间下限（亿元）潜在市场空间上限（亿元）物流服务快递3003050E02700外卖7003050506300合计0细分领域当前就业人数（万人）机器人单价（万元）预计替代比例（下限）预计替代比例（上限）潜在市场空间下限（亿元）潜在市场空间上限（亿元）商用餐饮2533050792275旅游283050B252酒店2743050A12466合计555832499311.各家企业持续推动人形机器人降本数据来源：公开数据整理；嘉世咨询研究结论；图源网络过去高昂的成本是制约人形机器人大规模量产的关键因素，降本将是人形机器人商业化推广的必由之路。过去一台Atlas造价高达200万美金，这也导致其至今难以走出实验室、走向商业化。在电机驱动方案中，伺服驱动器将位置、速度、扭矩传输给伺服电机，伺服电机将接收到的电压信号转换为扭矩、转速，虽然扭矩密度远低于液压驱动，但电机驱动可以通过搭配减速器来加以补足，其现有技术已能满足机器人的多数运动需求，同时拥有能量转化效率、易维护、低成本、零件规整等优势。使用电机驱动和液压驱动方案的人形机器人对比比较项特斯拉Optimus优必选Walker X小米CyberOne波士顿动力Atlas成本2万美元以下(目标)10万美元以下10万美元左右200万美元.驱动方式电机驱动电机驱动电机驱动液压驱动动力扭矩峰值-200Nm300Nm890Nm(旧版)12.人形机器人的竞争格局数据来源：公开数据整理；嘉世咨询研究结论；图源网络随着零矩点（ZMP）稳定性理论被攻克，人形机器人逐步由静态机转向动态机发展。波士顿动力、软银、亚马逊等企业纷纷布局人形机器人行业，2021年特斯拉强势入局，推动了全球人形机器人行业加速发展。在全球人形机器人产业逐步成长的背景下，2000年国内首台人形机器人“先行者”（国防科大发布）问世，并涌现了优必选、小米、傅利叶、达阔等一批人形机器人主机厂。各主机厂人形机器人布局型号生产商国家发布时间参敷产品特点ASIMO本田日本2000年身高13m,体重48g,最大速度是9km/h,全身57个关节实现小跑、单脚跳、上下楼梯以及踢足球等系列复杂运动Adas波士顿动力美国2013年身高1.5m,体重80g,速度1.5m/s,依靠28个液压执行器实现各种高难度运动高动态的运动性能，能做高难度运动动作Walker优必选中国2016年身高1.3m,体重63kg,具备36个高性能伺服关节突破了波动地形 上的自平衡，力位混合控制，不平整地面行走等技术GingrXR-1达阔中国2019年身高16m,重62kg,能够最快以1m/s速度移动，全身共34个智能柔性关节SCA具备抓取负载能力,能完成端茶倒水、穿针引线等高难度复杂动作AmecaEngincred Ats英国2021年高1.87m,重49kg,身体共有52个模块，支持51种关节运动实现人类面部表情的高度模仿，但运动功能非常有限CyberOne小米中国2022年身1.77m,体重52kg,单手握持1.5千克重物、多达21个自由度感知人类情绪，具有视觉建模能力Optimus特斯拉美国2022年身高1.72m,重量73kg,负载9kg,全身共28个自由度，灵巧手11个自由度具有自由行走和自我组装的能力;可以在不同的环境中自主导航GR-1傅利叶中国2023年身高1.65m,体重达到55kg,全身自由度多达40个，步行速度可达到5km/h，负重50kg采用自研FSA高性能一体化执行器，拥有强大且灵活的运动性能远征A1 智元中国2023年身高1.75m,体重S53kg,最高步速可达7km/h，全身49个自由度，整机承重80kg,单臂最大负载5g成本价不到20万元，自研核心关节电机PowerFlow,灵巧于5kilHand,统一软件框架AgiROS,语言任务模型WorkGPT,具身智脑E1-Brain架构13.大模型有望促进人形机器人加速落地数据来源：公开数据整理；嘉世咨询研究结论；图源网络人工智能算法是人形机器人的“灵魂”。人形机器人软件架构自下而上可大致分为算力、操作系统、人工智能算法与应用四个层级，其中人工智能算法包括感知算法、运动控制算法、大语言模型与其他AI算法，是人形机器人“智能性”的来源。大模型蓬勃发展，催化人形机器人加速落地。Transformer架构解决了传统RNN和CNN无法解决长距离信息关联的难题，推动人工智能向大模型时代迈进，以ChatGPT为代表的大语言模型的率先落地验证了其可行性，未来更多大模型有望逐渐成熟。伴随着大模型的发展，人形机器人的可用性有望显著增强，相关产业链有望加速落地。人形机器人软件架构 Tesla有望将电动车能力复用至人形机器人 应用层人工智能算法人工智能算法人工智能算法感知算法运动控制算法感知算法应用端自平衡系统LinuxTesla Dojo、D1芯片、FSD芯片占用网络模型Transformer BEVFSD 深度学习14.人形机器人行业四大发展趋势数据来源：公开数据整理；嘉世咨询研究结论；图源网络人形机器人越来越接近人以及技术的高度融合01人工智能技术让机器人可以实现多模态发展，从语音、视觉感知、决策、控制等多方面为机器人更好进行学习训练和进化，使人与机器人之间的交互形式更加多样，除了语言、肢体之外，人形机器人在未来更是有望仅通过观察人类表情就获得指令。全产业链模式的厂商将会获得优势竞争地位02整体而言，人形机器人赛道处于相当早期的阶段，当前并未形成产业化，各大参与者以研发为主，赛道的参与者主要将其定位为基础研究平台。从产业链发展趋势来看，“核心零部件生产 本体生产 系统集成”的全产业链模式的厂商将会获得优势竞争地位。“机器人 ”加速机器人应用拓展在人工智能、新型传感、生物仿生、新材料等多种技术融合驱动下，机器人向复杂精密场景渗透的步伐不断加快，在未来可落地的应用场景进一步打开了想象空间，并在关键零部件性能提升，拓展应用深度广度，有力支撑行业数字化转型、智能化升级。伦理和法规问题将变得更加重要人形机器人引发了一系列伦理问题，包括机器人是否应该拥有权利、如何处理机器人的责任问题以及机器人在决策中的角色等。社会需要制定相关法律和伦理准则来解决这些问题，以确保人形机器人的发展不会伤害社会价值观和道德标准。本报告为简版报告，内容均从嘉世咨询原有完整报告中精炼提取，如需了解详细内容，请联系：.本报告中的所有内容，包括但不限于文字报道、照片、影像、插图、图表等素材，均受中华人民共和国著作权法、中华人民共和国著作权法实施细则及国际著作权公约的保护。本报告的著作权属于上海嘉世营销咨询有限公司所有，如需转发、转载、引用必须在显著位置标注出处，并且不得对转载内容进行任何更改。本报告是免费报告，任何机构和个人不得将本报告用于收费为目的经营活动。版权说明版权归属 上海嘉世营销咨询有限公司

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