CubeAI已存在，ST为何仍要推出CubeAI Studio？

▼点击下方名片，关注公众号，获取更多精彩内容▼

我是嵌入式AI贺老师，专注于AI在MCU上的落地应用。关注我，回复【嵌入式AI】，即可免费领取更多专业资料。

凡是接触过 STM32 AI 部署的朋友，或者听过我课程的同学，对 X-CUBE-AI 应该都不陌生。

把训练好的模型导入，选定目标芯片，跑一下 Analyze 看 Flash 和 RAM，做一次 Validate，再 Generate Code，最后合并进工程。

这条流程其实已经沿用好几年了，虽然不算特别流畅，但确实能完成任务。

所以当 ST 在 2026 年正式发布 STM32Cube AI Studio 时，我的第一反应是：

X-CUBE-AI 本来就能把模型部署到 STM32，为什么还要额外搞一个 Cube AI Studio？

如果只是为了换个更好看的 UI，那就真的多此一举了。

不少人习惯把 ST 的 AI 工具笼统叫作"CubeAI"，但严格区分的话，这几个名称其实各有不同含义。

STM32Cube.AI 是一个相对宽泛的概念，可以看作 ST 针对 STM32 推出的整套 AI 部署技术方案。

而我们之前一直在用的那个工具，叫 X-CUBE-AI。它是 STM32CubeMX 的一个 Expansion Package，即扩展软件包，本质上是 CubeMX 内置的一个插件。

标准的使用流程大致如下：

图 1：X-CUBE-AI 的标准操作流程，全部在 CubeMX 中完成

这种设计在 2019 年前后是合理的。那时玩 TinyML 的主要是嵌入式开发者，他们每天都在 CubeMX 里配置时钟、GPIO、DMA、UART，把 AI 模块直接集成进去，学习门槛最低。

ST 官方后来也公开解释过，最初采用 X-CUBE Expansion Package 的形式，就是为了把机器学习能力嵌入到开发者已有的工作流中，避免再单独学习一套新工具。

图 2：X-CUBE-AI 作为 CubeMX 插件的运行界面

但问题在于，到了 2026 年，STM32 上的 AI 开发已经超越了"把模型转成 C 代码"的阶段。X-CUBE-AI 这套内嵌于 CubeMX 的架构，开始显得力不从心。

举一个真实的场景。假设你需要把一个神经网络部署到 STM32H7。

最初你可能只关注两件事：模型占用多少 Flash？推理消耗多少 RAM？只要放得下就继续推进。

但随着项目深入，各种问题会陆续浮现。

比如一个 FP32 模型占 1.8MB Flash，推理耗时 120ms。量化到 INT8 后只需 500KB，速度提升至 35ms，但精度下降了 2%。这种量化方案能否接受？必须用验证集跑一遍才能定夺。

更进一步：

如果把芯片换成 STM32N6，情况会更复杂。N6 内部集成了 Neural-ART Accelerator，即 NPU。这时你又需要弄清楚：哪些算子能在 NPU 上运行？哪些不支持，必须回退到 CPU？不同的优化策略对 NPU 利用率有何影响？

走到这一步，你面对的已经不仅仅是"模型转代码"的简单问题，而是一条完整链路：模型 → 量化 → 优化 → 编译 → 内存规划 → 性能分析 → 精度验证 → 硬件部署。

那么 CubeMX 的本职工作是什么？是 MCU 配置和工程生成：时钟如何配置、GPIO 如何分配、DMA 如何设置、外设如何初始化、Middleware 如何添加、最终生成哪个 IDE 的工程。

AI 模型开发和 MCU 外设配置，已经逐渐演变为两类截然不同的任务。继续把日益臃肿的 AI 工具硬塞进 CubeMX，绝非长久之计。这也是 Cube AI Studio 独立出来最直接的动因。

很多人第一眼看到 Cube AI Studio，会觉得"哦，就是做了一个独立界面"。但在我看来，UI 反而是最次要的变化。

核心的变化在于，ST 对整个 AI 部署工具链进行了重新分层。

STM32Cube AI Studio 现在是一款独立的桌面应用，承担模型导入、分析、优化、量化、Host/Target Validation、性能测试、内存分析、代码生成等全流程工作。

但它的底层核心并非另起炉灶重写了一套模型编译器。Cube AI Studio 底层调用的是 ST Edge AI Core——这才是负责模型分析、优化、验证和生成 C 代码的核心模块。Cube AI Studio 更像是围绕该核心搭建的一套图形化操作环境。

图 3：STM32Cube AI Studio 作为独立桌面应用的主界面

同时，它并未抛弃 CubeMX。根据 ST 当前发布的官方文档，Cube AI Studio 在需要进行 MCU 配置和工程生成时，仍会调用 STM32CubeMX；需要把验证程序烧录到板子上时，则使用 STM32CubeProgrammer。

换言之，几款工具的职责变得更加清晰：

这种分层架构比过去的"X-CUBE-AI 插件"模式更易于扩展。尤其是 STM32 开始集成 NPU、支持外部存储器、划分多内存区域之后，独立工具的价值会愈发凸显。

如果仅仅是把 X-CUBE-AI 从 CubeMX 中抽出来单独做一个软件，那确实意义不大。Cube AI Studio 的另一个重要变化是，ST 开始把更多"模型开发阶段"的能力直接整合进工具中。

过去 X-CUBE-AI 反馈给开发者的主要就是三个数字：Flash 占用、RAM 占用、Latency 耗时。

Cube AI Studio 能够下钻得更深：查看模型每一层的推理指标，对部署后的模型执行 Accuracy Validation，还能对比不同优化方案的结果。ST 官方专门加入了 experiment comparison 功能，用于权衡不同实验之间的取舍。

这个功能对嵌入式 AI 开发尤为实用。因为 MCU 上的 AI 几乎没有绝对最优解，开发者经常需要面对各种 trade-off：

开发者需要反复调整模型和部署参数，Cube AI Studio 开始把这种工作模式直接内置到工具中，而不是让开发者自己用 Excel 手动记录。

另一个值得关注的亮点是内存管理。当前官方文档已经明确列出了 External RAM/Flash、Memory Pool、Weight Compression 等功能。

过去运行几十 KB、几百 KB 的小型模型时，内存如何分配或许并不复杂。但如今如果做目标检测、视觉识别、语音处理等任务，模型体积可能达到数 MB 甚至更大。内部 SRAM、外部 SDRAM/PSRAM、内部 Flash、外部 NOR Flash 之间如何布局，直接决定了模型能否成功运行。

到了 STM32N6 这一代，芯片内部加入了 Neural-ART NPU。Cube AI Studio 能够针对支持 Neural-ART 的 STM32 进行模型编译，将可由 NPU 执行的算子映射过去，不支持的部分则回退到 CPU。ST 的目标是尽可能在算子级别提升硬件加速的占比。

由此看来，AI 部署工具需要管理的信息量，已经远远超过当年 X-CUBE-AI 的水平。

回到最初的问题。X-CUBE-AI 和 Cube AI Studio 的区别，归根结底是产品定位发生了转变。

表面上看似差别不大，但背后的开发流程已截然不同。早期的 MCU AI 重点是"能不能跑起来"，而如今越来越多的项目开始考虑"占用多少资源、运行多快、精度如何、能否利用 NPU、不同方案之间如何抉择"。

ST 也通过实际行动表明了其战略方向：X-CUBE-AI 已被标注为 NRND（Not Recommended for New Design）。官方文档同时指出，自 ST Edge AI Core 3.0.0 起，X-CUBE-AI 插件不再获得支持，新项目应采用 STM32Cube AI Studio。

但如果你现在刚开始接触 STM32 AI，或者准备启动新项目，方向已经相当清晰：后续应逐步把主要工具切换到 STM32Cube AI Studio。尤其是计划使用 STM32N6、Neural-ART NPU，或开发更复杂的视觉、音频 AI 模型时，Cube AI Studio 的重要性会越来越突出。

参考资料：ST Blog - STM32Cube AI Studio ｜ STM32Cube AI Studio 官方文档 ｜ ST Community - Introducing STM32Cube AI Studio ｜ ST - X-CUBE-AI 官方页面

END