首页
/ MUI 2021 开发者调查结果解读:社区画像、真实痛点与 v5 迁移全景复盘

MUI 2021 开发者调查结果解读:社区画像、真实痛点与 v5 迁移全景复盘

2026-09-06 18:56:01作者:曹令琨Iris

本篇基于 MUI(Material UI)官方发布的 2021 年度开发者调查结果原始博客(收录于本文档库 docs/pages/blog/2021-developer-survey-results.md),为你完整还原这份 1,591 人参与的调研数据,并结合当前开源仓库中的源码与文档资源,逐一解读 v5 大版本发布后社区的真实反馈。读完本篇,你将系统掌握 MUI 开发者社区在组件库选型标准、v4→v5 迁移体验、样式方案取舍、MUI X 商业化认可度等方面的量化结论,并理解这些数据如何在仓库中沉淀为迁移指南、codemod 自动化工具、样式系统(MUI System / sx prop)等具体工程实践。

调查概览:这是一份怎样的数据样本

MUI 从 2019 年起保持每年开展开发者调查的传统。2021 年的调查于 2022-03-15 随博客正式发布(见原始文章 frontmatter 的 date 字段),共回收 1,591 份有效回答。与往年相比有三个显著变化:

下文按这三个板块逐项展开。

你的需求 Your needs

这部分考察的是开发者对 MUI 的整体依赖度、推荐意愿、核心收益认知、选型标准与改进诉求,是整份调查中信息密度最高、对产品路线影响最大的板块。

如果无法再使用 MUI,你会作何感受?

超过 93% 的受访者表示若无法继续使用 MUI 会感到失望("Very disappointed" 与 "Somewhat disappointed" 之和),与 2019、2020 两年 94% 的比例基本持平。该项共 1567/1589 人回答。

2021 调查:失去 MUI 的失望程度分布,62.7% 非常失望、30.4% 有些失望、6.9% 不失望

值得警惕的信号是:2021 年"Very disappointed"(非常失望)占比相比往年下降了约 10 个百分点,而这部分流失几乎全部转移到了"Somewhat disappointed"(有些失望)区间,意味着部分开发者的产品热情在降温。与此同时"Not disappointed"(不失望)群体增长了 1%。该群体被追问原因后,MUI 团队归纳出三类主要解释:

其一,可替代方案激增。 随着市面上同类 UI 组件库不断涌现,行业通用模式逐步建立,差异化难度加大。MUI 团队对此的回应是"扩展核心产品之外的体验",即下文的 MUI X 与配套产品。

其二,付费产品的引入(Open-core 开源核心模式)。 这是开源项目商业化绕不开的话题:MIT 授权模式成就了庞大的贡献者社区,但维护者几乎无法从开源中获得经济回报。MUI 引入 Open-core 模式——MUI X 组件仍提供 MIT 授权的免费版本,同时对需要更多投入的功能(含支持服务)收费。需要说明的是,原始文档中提到的外部链接(如 Stewardship 页面)不属于当前仓库内容,此处仅作背景转述。调查发布时 MUI X 仍处于早期:它于 2020 年底推出,截至发稿仅约 0.1% 的开发者社区用户升级到了付费 Pro 计划。

其三,v5 的破坏性变更。 MUI Core v5 是当时最重要的版本升级,核心目标是在不牺牲性能的前提下解锁更多自定义能力(customizability),但代价是引入全新样式方案,使 v4 迁移工作量显著增大。

你向朋友或同事推荐 MUI 的可能性有多大?

2021 年 MUI 的净推荐值(Net Promoter Score, NPS)从 2020 年的 62 下降至 46,其中 Promoters(推荐者)从 62.2% 降至 56.4%

2021 调查 NPS 构成:贬损者 10.88%,中立者 32.69%,推荐者 56.43%,整体 NPS 为 46;量表含义:-100 至 0 需改进、0 至 30 良好、30 至 70 优秀、70 至 100 卓越

按 NPS 行业通用分档,30~70 分属于"优秀"(great)区间,因此 46 分仍处健康水位,但距离"卓越"(excellent)仍有明显差距。

你从 MUI 获得的最大收益是什么?

该问题 2021 年共有 1422/1589 人作答。下图为 2019 与 2021 两轮结果的对比柱状图:

2021 调查:使用 MUI 的主要收益维度(2019 vs 2021 对比)——2021 年:节省时间 597、设计 407、组件 309、开发者体验 306、可定制性 181、文档 57、社区支持 26、无障碍 24、性能 17

将回答分类聚合后,相比 2019 年增长的维度包括:

  • 社区(2.9x):社区规模翻倍的同时,对社区的认可度增长了 190%,呈现明显的网络效应——用户翻倍,社区价值增至三倍。
  • 无障碍(2.2x):组件可访问性投入被社区切实感知。
  • 可定制性(1.6x):开发者开始认可 v5 引入的新能力,但文档中坦承仍有很多工作要做。
  • 组件(1.6x),其中"组件质量"维度的认可度与往年持平,说明维护团队在规模扩张中守住了质量底线。
  • 节省时间(1.4x):主要指向 UI 开发过程中的时间节约,MUI 认为这既可能源于市场对"更快交付"的压力,也与下面的开发者体验提升相关。
  • 开发者体验(1.1x):其中"一致性"子维度增长达 1.75x——组件数量变多后,开发者更真切地感受到统一设计语言带来的前后端一致性收益;而"易用性"维度无变化,MUI 将之归因于 React(hooks)API 形态与缺少针对性 API 优化,并计划交由新组建的 Developer Experience 团队跟进。

下降的维度是设计(x0.75):

  • Material Design(x0.4):作为默认设计语言的"卖点"正在减弱。
  • Look & feel(观感,x1.17):反而上升,文档将其解释为一种"迁移效应"——人们如今更关心最终效果而非规范本身。

为便于引用,原始博客将全部回答的细分归类放在可折叠面板中,核心分布如下(数字为该分类被提及次数):

计数 分类
597 time(节省时间)
407 design(设计)——其中 look & feel 148、look & feel+ 122、consistency 73、Material Design 73
309 components(组件)——其中 quantity(数量)173、quality(质量)124
306 DX(开发者体验)——其中 easy to use 221、consistency 49、API 32
181 customizability(可定制性)
57 docs(文档)
26 community(社区)
24 accessibility(无障碍)
17 performance(性能)——其中 runtime 15、bundle size 1
9 community support(社区支持)
5 icons(图标)
3 typescript
2 animations(动画)

对下列陈述的认同度评分

共 1534/1589 人作答,结果呈现"整体认同、但强认同不足"的形态:

  • "我能找到所需的大部分组件":45.5% 强烈同意 + 45.9% 同意;
  • "我能轻松定制组件以匹配期望设计":仅 23.4% 强烈同意,但同意率达 46.1%;
  • "我能在文档中找到大多数问题的答案":24.1% 强烈同意 + 50.1% 同意;
  • "我认为库的性能很棒":26.4% 强烈同意 + 44.3% 同意;
  • "每当我需要帮助时(Stack Overflow 或 GitHub),都能得到有帮助的回复":20.9% 强烈同意 + 36.7% 同意,另有高达 36% 持中立态度。

MUI 团队指出:除第一条外,其余陈述的"强烈同意"与"同意"之间存在明显落差,说明在可定制性、性能与社区支持三个维度仍有持续的提升空间——这与上文"最需改进项"的聚类结果相互印证。

选择 UI 库最重要的标准是什么?

通过 Typeform 的排序题,1500/1589 名受访者对选型标准做了优先级排序,结果为:

  1. 设计(look & feel,观感)
  2. 可定制性(Customizability)
  3. 文档质量(Documentation quality)
  4. 全面性(Comprehensiveness)
  5. 性能(Performance)
  6. 流行度(Popularity)
  7. 无障碍(Accessibility)
  8. 提供的支持与帮助(Offered support and help)
  9. 包体积(Bundle size)

结论与上一年差异不大:观感设计仍居首位,可定制性与文档质量稳居前三;性能是本年度最显著的"上升者",首次跻身第五。

我们还能为改进 MUI 做些什么?

共有 1007/1589 名受访者作答(开放题,词云统计),出现频率最高的主题如下:

  • 更多组件:持续涌现对图表(charts)、表单(forms)、日历(calendars)等进阶组件的需求。
  • 更多示例:v5 升级后大量既有学习资料过时,官方需要重建演示体系。
  • 提供更多主题:即便 Material 3 已发布,仍有很多开发者认为 Material Design 过时,MUI 因此开始推进第二套设计系统(即后来的 Joy UI / MUI Base 生态方向)。
  • 更少的破坏性变更:v5 的新样式方案带来了显著迁移成本。MUI 在文中承诺不计划在当年度发布任何大版本,且将大版本间隔至少保持在 12 个月以上
  • 改进定制能力:高频诉求包括让定制更简单、补充常见用例(如 font-family、primary/secondary 颜色)示例、增强主题能力。值得注意的是,尽管 Emotion 与 styled-components 已相当流行,社区对"更轻松地定制组件"的需求依然巨大。

按主题聚类的完整分布如下(数字为提及次数):

计数 一级分类 主要细分
329 docs(文档) 更多示例 62、更多模板 29、对新手友好 28、教程 28、API 19
300 more components(更多组件) 表单 26、图表 21、轮播 17、lab 转 core 12
265 customization(定制) 更简单 69、文档 44、改善自定义主题 27、颜色 26、主题化 25
212 system(样式系统) 希望 makeStyles 回归 36、SASS 15、与 Tailwind CSS 互操作 11、简化 14、CSS 变量 8
172 design(设计) 提供更多主题(不只 Material Design)51、默认主题观感 28、推进 @mui/base 27、Material Design v3 24、放弃 Material Design 13
109 performance(性能) 包体积 46、运行时 16
97 DX(开发者体验) 更简单 27、API 20、更高层组件 API 17
75 data grid(数据表格)
61 free vs. paid(免费 vs 付费) 全部 MIT 18、更便宜的 Pro 8、已有功能不收费 8
61 fewer breaking changes(更少破坏性变更)
47 typescript 更快的类型检查 11、文档 5
41 date picker(日期选择器) 稳定化 5、区间选择 3
26 community(社区) 培育 14、支持 9
20 icons(图标) 更多图标 12
19 accessibility(无障碍) 实现 9、文档 6、全面审计 2
15 react native
10 low-code
9 animations(动画)
7 修复更多 bug

MUI 团队借此也明确了提需求的最优姿势,这些规则至今仍是社区协作规范:

  • 在 MUI Core / MUI X 仓库中提交 issue 时会被打上 Waiting for upvotes 标签,投票越多优先级越高,因此需求描述要结构化、有调研、有说服力;
  • 请求新组件时,建议先对同类既有实现做基准调研(benchmark);
  • 尽量清晰描述问题本身,因为往往已有现成组件可解决;
  • 若请求更易用的定制能力,请展示期望效果并详细说明卡点。

你的产品 Your product

该板块围绕开发者实际使用 MUI 构建什么、用什么技术栈、迁移 v5 的真实体验展开。

使用 MUI 之前你主要用什么?

1389/1589 人作答:Bootstrap 40.6%"一开始就用 MUI" 37.4%(2020 年该比例仅 13%,增幅惊人)、Tailwind 4.8%、Ant Design 4.8%、Angular Material 4%、Semantic-UI 4%、Chakra UI 0.7%。大量新项目直接把 MUI 作为起点,是对产品力的有力背书。

除 MUI 外你还同时使用以下哪些?

1468/1589 人作答:仅用 MUI 占 70.7%,其余为 Tailwind 10.3%、Bootstrap 9.8%、Ant Design 4% 等。MUI 基本覆盖了绝大多数团队对组件库的全部需求,这正是官方最看重的优先级之一。

你为谁开发?

1523/1589 人作答:为公司 65.6%、个人副业项目 20.8%、客户项目 12.9%。与 2020 年相比,客户项目与个人项目排名互换,可能是 v5 激起了开发者在个人站点/应用中尝鲜的兴趣。

你主要与谁协作?

1527/1589 人作答(本年度新增问题):其他开发者 67.2%、设计师 34.3%、产品经理 29.2%、独自一人 28.9%。该结果提醒官方:文档与代码不仅服务于开发者,还必须让设计师、产品经理等非技术干系人能够理解。

今年你用 MUI 交付了多少个 Web 应用?

1051/1589 人作答:0-1 个(494)、2-3 个(381)、4-5 个(122)、6-10 个(26)、10+ 个(28)。约 47% 的作答者只交付了 1 个应用或仅维护既有应用;5% 交付 6 个以上,其中过半超过 10 个。

你在应用中使用哪些 MUI 产品?

1551/1589 人作答:MUI Core(MIT 授权基础组件,默认 Material Design)96.6%、MUI X(进阶组件集合,MIT 与商业授权并存)14.7%(其中 MIT 授权 126 人、商业授权 99 人)。高比例的商业授权使用者让团队对 MUI X 的付费化方向更有信心。

本次调查前你了解 MUI X 吗?

1312/1589 人作答:知道 54.5%、不知道 45.5%。近半数受访者此前完全不了解 MUI X,说明其认知度仍有很大扩展空间。

你目前是否在使用任何付费 UI 组件库?

1584/1589 人作答:是 11.8%、否 88.2%。大多数人不使用付费库;而付费用户中多数正在用 MUI X。这说明"纯 OSS 生态未能完全满足开发者需求",MUI X 的假设与执行方向部分得到验证。

如何改进 Data Grid(数据表格)?

64 名 Data Grid 使用者作答,高频诉求:

  • 可定制性(21.9%):MUI 承认在主题化与 headless API 文档上仍有缺口;
  • 更便宜的 Pro 计划(17.2%):Pro 定价面向专业组织团队,但反馈者多为个人开发者,MUI 认为存在面向个人扩展产品线的机会;
  • 更多功能与缺陷修复(合计约 22%):新功能集中在可折叠行、列宽调整、ERP 类场景;修复集中在 REST API 分页、后端过滤与单元格编辑器;
  • 文档与观感改进:Data Grid 文档需要大改;过滤交互体验(UX)是被反复提及的点。

细分归类:customizability 14、cheaper Pro plan 11、more features 8(master detail 2、row editing 1、column pinning 1、column resizing 1)、fix features 6(filtering 3)、docs 5、look and feel 4、maintain it 3、bugs 2、performance 2 等。

如何改进 Data Grid Pro?

75 名 Data Grid Pro 使用者作答,核心诉求:

  • 更多功能(39.8%):分组为呼声最高的功能(原文链接指向 MUI X 官方文档,不在本仓库范围内),其后依次是 master detail(主从明细)、聚合、搜索、tree data(树形数据)、column pinning(列固定)。官方在分析期间已发布其中一部分。
  • 可定制性(20.4%):多数请求指向数据表格交互行为层面的可调性,其次才是样式与文档。
  • 修复功能(15.1%):过滤居首,其次是懒加载与 SSR 支持。
  • 性能(5.4%):诉求分布在运行时与包体积两侧,官方承认此前几乎未投入包体积优化,认为存在"低垂果实"。

细分归类:more features 37(grouping 6、master detail 6、aggregation 3、search 3、tree data 3、column pinning 2)、customizability 19(behavior 7、style 5、docs 4)、fix features 14(filtering 10)、performance 5、docs 4、cheaper premium plan 3、bugs 2 等。

使用 Data Grid 之前你在用什么?

149 人作答:自研数据表格 29.9%、MUI Table 17.9%、之前没用过 7.5%、material-table / material-datatables / Sencha / Kendo UI 各约 4.5%~6%。大量团队选择自研表格,而标准 MUI Table 能满足相当多场景,这两点都让官方印象深刻。

你在构建什么类型的应用?

1523 人(原文数据对应柱状图统计口径,作答约 1480+)作答:Dashboard 后台管理应用 26.3%、企业级应用 25.9%、自定义设计系统 9.7%、落地页 8.1%、电商 7.8%、个人网站/作品集 6.9%、CMS 6.1% 等。企业应用、Dashboard 与设计系统依旧占据前三;电商与作品集场景的显著增长是本年新趋势。

使用什么交付形态?

1509/1589 人作答:SPA 单页应用(Create React App 等)74.7%、SSR 服务端渲染网站(Next.js、Gatsby 等)20.8%、桌面应用(Electron 等)3.5%、原生移动应用 0.6%。

使用什么类型系统?

1501/1589 人作答:TypeScript 63.8%(2020 年尚非主流,一年间强势登顶)、不用类型系统 18%、prop-types 16.6%、Flow 1.4%。TypeScript 的爆发式增长,与当前仓库中"TypeScript 源码 + 生成 PropTypes"的双轨模式高度吻合——从源码结构看,packages/mui-material/srcdocs/src 等目录均以 .ts/.tsx 为主要实现语言,并通过 packages-internal/scripts/typescript-to-proptypes 自动生成运行时校验所需的 PropTypes。

你使用哪个框架?

1497/1589 人作答:Create React App 62.4%、Next.js 21.9%(2020 年仅 12.4%,增幅显著)、自定义 webpack 10.7%、Gatsby 0.9%。当前仓库的 examples 目录即为这一趋势的缩影——其中包含 material-ui-nextjs(App Router)、material-ui-nextjs-pages-routermaterial-ui-remix-ts 等大量基于 Next.js/Remix 的 SSR 示例工程。

你使用什么样式方案?

1492/1589 人作答:MUI Core v4(JSS)45%、styled-components 37.9%、Emotion 30.2%、SASS 20.8%、CSS Modules 18.9%、Vanilla CSS 17.6%、Tailwind CSS 9.1%、Stitches 0.4%。由于 v5 发布不久,JSS 用户仍占多数;但 Emotion 与 styled-components 的增长才是关键信号——它们正是 v5 新样式方案的底层基础。官方预告当年将聚焦扩展 MUI System(对应仓库文档 the-sx-prop.md)以完善这套新方案。从当前仓库源码看,v5 引入的样式引擎被抽象为独立的 packages/mui-styled-engine(默认 Emotion 实现)与 packages/mui-styled-engine-sc(styled-components 适配),这就是"样式方案可插拔"架构的直接体现。

你是否已迁移到 MUI Core v5?

1546/1589 人作答:已迁移 63.3%、未迁移 36.7%。团队计划在接下来一年重点打磨文档与自动化工具(对应仓库中现成的 v4→v5 迁移指南 与 codemod 工具集)。

哪句话最能概括你的迁移体验?

930/1589 人作答:43%——"过程有挑战,但 MUI 的文档和资源帮我搞定了";38.5%——"很顺畅,现在运行良好";14.3%——"不太好,问题多且耗时";2.8%——"很糟糕,甚至后悔迁移"。

MUI 应如何改进迁移体验?

472/1589 人作答:文档整体改进 43.2%、自动化 20.7%、更少破坏性变更 15.6%、更少的样式方案破坏性变更 8.5%、更多教程 5.4% 等。官方表示 codemod 首次大规模应用于迁移流程并收获正面反馈,但同时也看清了它的能力边界,将持续迭代。这一点在仓库中有充分物证:codemod 工具按版本组织在 packages/mui-codemod/src/v5.0.0 目录下,其中既有面向全量一键迁移的 preset-safe.js,也有处理新旧样式体系差异的 adapter-v4.jsjss-to-styled.js;对应的 v5 迁移文档(含从 JSS 迁移的专项指南 migrating-from-jss.md)也一并保留在仓库中,可作为历史佐证。

你尚未迁移的原因是什么?

441/1589 人作答:没时间/带宽 28.4%、直接从 v5 起步 14.6%、担心破坏性变更数量 12.3%、已计划未开始 9.5%、缺动力 8.5%、非优先级 7.3%、不喜欢新样式方案 4%、被第三方依赖阻塞 3.3%、不知道 v5 3.3%、迁移进行中 3.3%、出现回归退回 v4 1.3%。MUI 的回应要点包括:理解"第三方依赖阻塞"等非可控因素;承认对破坏性变更数量的恐惧合理;对新样式方案的异议持开放态度(并回顾了 样式方案选型讨论 issue 这类开放决策传统);鼓励遇到回归的用户提交 issue。

低代码工具相关

1542/1589 人作答:使用过低代码工具 16.1%。使用者主要用它构建内部工具(22.5%)、落地页(22.1%)、分析型 Dashboard(17.6%)与设计系统(15.6%)。在被问及"若 MUI 做低代码工具,最匹配的使用场景"时(1200/1589 作答),排在前列的是:交付 React 设计系统(22.2%)、可视化构建后生成高质量 React 代码(19.2%)、Dashboard 快速数据可视化(18.3%)、高保真原型与设计交接(13.6%)。这也为后续 Toolpad 等低代码产品的立项提供了社区侧的数据支撑。

关于你 About you

此板块刻画受访者画像,帮助理解样本的代表性。

  • 如何第一次听说 MUI(1417/1589 作答):自然搜索 57.8%、口口相传 25.8%、社交媒体 8.4%、博客 4.4%。
  • 当前职位(1497/1589 作答):全栈开发 52.6%、前端开发 30.5%、创业者(全栈包办)7.5%、前端初学者 2.6%、工程经理 2.6%、后端 1.1%、设计师 1%、产品经理 0.7%。
  • 所在公司规模(1222/1589 作答):2-10 人 358、100+ 人 305、0-1 人 187、21-50 人 139、11-20 人 136、51-100 人 97。企业用户与大厂占比可观,与"为企业与 Dashboard 开发"的主流场景吻合。
  • JavaScript 年限(1520/1589 作答):3 年以上合计约 73%,资深开发者为主。
  • React 年限(1523/1589 作答):2 年及以上合计约 61%,3 年以上约占 40%。
  • MUI 年限(1519/1589 作答):1 年以上合计约 64%,其中 16.6% 刚起步("Just getting started"),2.8% 自称先驱(5 年以上)。

结论与后续行动:从数据到仓库的落地

年度调查是 MUI 决定下一步行动最重要的依据之一。2021 年 MUI 发布了史上最大规模更新(v5),并开始投资 MUI X、设计套件与高级模板等互补产品。官方基于本份数据总结了六大改进方向:

  • 文档:v5 发布使大量第三方教程过时,需要更多示例、教程与更全面的内容。
  • 定制化:新样式方案(基于 Emotion,仓库实现见 packages/mui-styled-engine,配套 MUI System 文档见 the-sx-prop.md)是正确方向,但定制体验仍有大量优化空间。
  • 设计质量:设计仍是选型第一驱动力,但"只有 Material Design 一种默认设计方向"正成为用户流失原因,促使团队探索替代设计系统。
  • 破坏性变更:多数应用深度依赖 MUI,官方将尽力压缩破坏性变更频率,并继续投资自动化工具(codemod)。
  • 商业与 MIT 平衡:坚持 OSS 优先,同时通过付费产品与支持服务补充可持续性。
  • 性能:探索 TypeScript 优化潜力,并承认 MUI System 的速度有待提升。

如果你希望继续影响路线图,官方建议的方式是:在 MUI Core / MUI X 仓库提交 issue、为感兴趣的 issue 投票、在 issue 中留下对任何改进点的看法——"投票越多,优先级越高"。

延伸阅读

本仓库保留了与本文所涉主题直接对应的原始资源,可进一步深入:

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
1.13 K
2.75 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件,TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件,使 PyTorch 框架能够直接调用昇腾 NPU,为开发者提供昇腾 AI 处理器的超强算力。
Python
857
1.35 K
docsdocs
暂无描述
Markdown
897
5.8 K
kernelkernel
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
529
593
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
916
1.83 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
3.58 K
1.01 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.35 K
1.46 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。
Jupyter Notebook
1.01 K
515
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR(Multi-Level Intermediate Representation)构建的,面向昇腾亲和算子编译时使用的中间表示,提供昇腾完备表达能力,通过编译优化提升昇腾AI处理器计算效率,支持通过生态框架使能昇腾AI处理器与深度调优
C++
547
388