基于 U-Net 网络的图像分割的 MindStudio 实践
本文分享自华为云社区《【MindStudio训练营第一季】基于U-Net网络的图像分割的MindStudio实践》，作者：Tianyi_Li 。
基于 ECS（Ascend310）的 U-Net 网络的图像分割
1. U-Net 网络介绍：
U-Net 模型基于二维图像分割。在 2015 年 ISBI 细胞跟踪竞赛中，U-Net 获得了许多最佳奖项。论文中提出了一种用于医学图像分割的网络模型和数据增强方法，有效利用标注数据来解决医学领域标注数据不足的问题。U 型网络结构也用于提取上下文和位置信息。
[U-Net 论文]: Olaf Ronneberger, Philipp Fischer, Thomas Brox. “U-Net: Convolutional Networks for Biomedical Image Segmentation.”conditionally accepted at MICCAI 2015. 2015.
2. ECS 运行说明
我们的操作基本都在 root 用户下执行。
首先，修改 bash，具体命令和结果如下。
本项目支持 MindStudio 运行和终端运行。
（1）下载项目代码
下载链接：https://alexed.obs.cn-north-4.myhuaweicloud.com/unet_sdk.zip
将项目文件 unet_sdk.zip 上传至华为云 ECS 弹性云服务器/root/目录下，并解压；或者下载到本地电脑，用 MindStudio 打开。将之前 unet_hw960_bs1.air 模型放到/unet_sdk/model/目录下。
项目文件结构
(2) 模型转换
将 unet_hw960_bs1.air 模型转为昇腾 AI 处理器支持的.om 格式离线模型，此处模型转换需要用到 ATC 工具。
昇腾张量编译器（Ascend Tensor Compiler，简称 ATC）是昇腾 CANN 架构体系下的模型转换工具，它可以将开源框架的网络模型或 Ascend IR 定义的单算子描述文件（json 格式）转换为昇腾 AI 处理器支持的.om 格式离线模型。模型转换过程中可以实现算子调度的优化、权值数据重排、内存使用优化等，可以脱离设备完成模型的预处理。
(3) 运行脚本
运行脚本：
注意 air 模型转 om 只支持静态 batch，这里 batchsize=1。
参数说明：
输出结果：
ATC run success，表示模型转换成功，得到 unet_hw960_bs1.om 模型。
模型转换成功之后，可以使用 MindX SDK mxVision 运行脚本，在 Ascend 310 上进行推理。
(4) MindX SDK mxVision 执行推理
MindX SDK 文档请参考：https://support.huaweicloud.com/ug-vis-mindxsdk203/atlasmx_02_0051.html
MindX SDK 执行推理的业务流程：
通过 stream 配置文件，Stream manager 可识别需要构建的 element 以及 element 之间的连接关系，并启动业务流程。Stream manager 对外提供接口，用于向 stream 发送数据和获取结果，帮助用户实现业务对接。
plugin 表示业务流程中的基础模块，通过 element 的串接构建成一个 stream。buffer 用于内部挂载解码前后的视频、图像数据，是 element 之间传递的数据结构，同时也允许用户挂载元数据（Metadata），用于存放结构化数据（如目标检测结果）或过程数据（如缩放后的图像）。
MindX SDK 基础概念介绍：
MindX SDK 基础插件：
MindX SDK 业务流程编排：
Stream 配置文件以 json 格式编写，用户必须指定业务流名称、元件名称和插件名称，并根据需要，补充元件属性和下游元件名称信息。
以下表格为本实验 pipeline/unet_simple_opencv.pipeline 文件及其对应的名称及描述：
pipeline/unet_simple_opencv.pipeline 文件内容如下，可根据实际开发情况进行修改。
(5) 修改 modelPath
打开 pipeline/unet_simple_opencv.pipeline 文件，将"mxpi_tensorinfer0"元件的属性"modelPath"（模型导入路径）修改为模型转换后保存的 om 模型"model/unet_hw960_bs1.om"。
修改结果：
modelPath 修改完成之后，保存 pipeline/unet_simple_opencv.pipeline 文件。StreamManagerApi：StreamManagerApi 文档请参考：https://support.huaweicloud.com/ug-vis-mindxsdk203/atlasmx_02_0320.htmlStreamManagerApi 用于对 Stream 流程的基本管理：加载流程配置、创建流程、向流程发送数据、获得执行结果、销毁流程。
这里用到的 StreamManagerApi 有：
InitManager：初始化一个 StreamManagerApi。
CreateMultipleStreams：根据指定的配置创建多个 Stream。
SendData：向指定 Stream 上的输入元件发送数据(appsrc)。
GetResult：获得 Stream 上的输出元件的结果（appsink）
DestroyAllStreams：销毁所有的流数据。
main.py 文件内容如下，可根据实际开发情况进行修改。
run.sh 文件内容如下，可根据实际开发情况进行修改。参考 SDK 软件包 sample 脚本，需要按照实际路径修改各个环境变量路径。
(6) 运行脚本
激活 mxVision 环境变量（本作业无需此步骤）：
运行脚本：
运行截图如下：
通过 MindStudio 运行，会自动上传代码到预设路径，并执行，运行结果如下：
MindStudio 专家系统工具
专家系统工具当前支持专家系统自有知识库和生态知识库对模型/算子进行性能分析，支持性能调优一键式闭环实现一键式性能问题优化能力。
专家系统自有知识库当前提供的功能：基于 Roofline 模型的算子瓶颈识别与优化建议、基于 Timeline 的 AI CPU 算子优化、算子融合推荐、TransData 算子识别和算子优化分析。
生态知识库的专家系统性能调优功能：由生态开发者使用 Python 编程语言进行开发，用户通过调用专家系统提供的接口，对生态开发者提供的模型/算子进行性能分析。
MindStudio IDE 当前版本仅支持的生态知识库创建功能，可以在上面完成生态知识库代码开发，暂不支持对生态知识库的专家系统分析功能。性能调优一键式闭环提供一键式性能问题分析和优化能力，有效提升用户性能分析和优化效率。
下面介绍如何使用专家系统工具对模型和算子进行性能瓶颈识别并输出优化建议。
1. 单击菜单栏“Ascend > Advisor”，弹出专家系统工具界面 。如图所示。
2. 单击上图界面左上角红框中的按钮，打开专家系统配置界面，各参数配置示例如图所示。
各参数具体说明如下：
3. 配置完成后单击“Start”启动分析。
之后开始运行，如图所示，具体时间与网络情况有关。
运行完成后，会自动跳转到如下图所示界面。
这里的 Model Performance Report 是模型性能的总结报告。根据该页面，可以知道模型性能是好是坏，也可以知道模型的吞吐率和运行时间，AI Core 的利用率，Tiling 策略是否合理，部分字段说明如下所示，具体可参见https://www.hiascend.com/document/detail/zh/mindstudio/50RC3/msug/msug_000285.html。
从上述截图的分析结果可以看出我们所用的 U-Net 模型的芯片利用率是偏低的，甚至可以说是很差，有很大的优化的空间。下面我们来详细分析。
先来看根据总体性能数据汇总计算得出的 Model Performance，显示为 Bad，情况不乐观啊。接着看看汇总信息。
可以看到 Cube 吞吐量 Cube Throughput 约 393 GOps，Vector 吞吐量 Vector Throughput 约 0.89 GOps，AI Core 执行时间 88712us，任务执行时间 177183us，平均 BlockDim 利用率 Avg BlockDim Usage，算子执行时的平均核心数，数值为 1，这反映了反映芯片利用情况，考虑到我们 ECS 的 Ascend 310 总计 2 个 AI Core，且由系统自动调度，这里为 1 还可以接收。但下面的数据可难看了。
如图所示，芯片利用率 Chip Utilization。按照规则，80 为优，显示为绿色；小于 80 则为差，显示为红色。根据 Pipeline Bound 的数值计算得出。而我们这里直接为 0 了。再看 Cube 利用率 Cube Ratio 约为 0.41，Vector 利用率 Vector Ratio 约为 0.29，Scalar 利用率 Scalar Ratio 约为 0.26，还有优化空间，而 MTE1 瓶颈、MTE2 瓶颈、MTE3 瓶颈都还不小。特别是 MTE2 瓶颈，约为 0.39。下面接着看。
来看内存读入量的数据切片策略 Tiling Strategy 为 5.23，情况糟糕。根据规则，数值达到 80 为优，显示为绿色；小于 80 则为差，显示为红色。这是根据 Memory Redundant 的数值计算得出。同时，可以看到真实内存读入量 Real Memory Input(GB)约为 1.44GB，真实内存写出量 Real Memory Output(GB)约为 0.60GB，都在可用范围内。
接下来进入 Computational Graph Optimization 界面，如图红框所示两处都可以，二者就是简版和精装版的区别了。在这里，我们可以看到计算图优化，算子融合推荐功能专家系统分析建议，会分行展示可融合的算子。
先来看看需要进行 UB 融合的算子，点击算子，会自动跳转相应的计算图，既直观又方便啊。同时我们看到可融合算子的执行时间 Fusion Operator Duration 达到了约 9585us，接近 10ms 了，算是比较大了。本模型没有 AIPP 融合推荐和 L2Cache 融合推荐。
我们直接看 TransData 算子融合推荐，如图所示。该算子执行持续时间在 2.5ms 左右，也不算小了，也是一个值得优化的地方啊。
但遗憾的是本次 Roofline 页面（基于 Roofline 模型的算子瓶颈识别与优化建议功能输出结果）和 Model Graph Optimization 页面（基于 Timeline 的 AICPU 算子优化功能输出结果）都没什么结果展示，具体分别如下图所示。
这里提个建议，看了下运行日志（显示了这一句[ERROR] Analyze model(RooflineModel) failed, please check dfx log.），Roofline 之所以没有结果显示，可能是 Roofline 运行失败，不过这个日志有点太简洁了，不太友好，也没有给出 dfx log 的具体路径或位置，哪怕弹出一个链接给用户，让用户去自行查找呢，这都没有，感觉界面不太友好啊。
专家系统提供对推理模型和算子的性能瓶颈分析能力并输出专家建议，但实际性能调优还需用户自行修改，不能做到性能调优一键式闭环。而性能调优一键式闭环提供一键式性能问题分析和优化能力，有效提升用户性能分析和优化效率。同时，性能调优一键式闭环当前实现生态知识库 ONNX 模型的部分推理场景瓶颈识别和自动化调优能力。
但这需要准备待优化的 ONNX 模型文件（.onnx）以及 ONNX 模型经过 ATC 转换后的 OM 模型文件（.om），而我们这次是.air 模型转 om 模型，虽然可以获得 onnx 模型，但太麻烦了，我们这次就不尝试了。
这里再提个建议，性能调优一键式闭环还需要下载 ONNX 模型调优知识库，我按照文档（文档链接：https://www.hiascend.com/document/detail/zh/mindstudio/50RC3/msug/msug_000303.html）中提供Link跳转下载（如下图所示），未能找到文档后续所说的KnowledgeBase Configuration 知识库配置文件 echosystem.json。不知道是不是我的问题，建议工程师看看，验证一下。
MindStudio Profiling 工具
Profiling 作为专业的昇腾 AI 任务性能分析工具，其功能涵盖 AI 任务运行时关键数据采集和性能指标分析。熟练使用 Profiling，可以快速定位性能瓶颈，显著提升 AI 任务性能分析的效率。
下面介绍使用 Profiling 工具采集性能数据并作简单的性能数据分析。
1. 更换 python 链接（可选）
这里先给大家排下雷，如果大家遇到如下报错，那么按照下面的操作修复下就行了，报错信息如下图所示：
个人认为，这应该是本地电脑没安装 Python 或者安装了，但是没有添加到系统 Path，以致无法调用，这应该 Profiling 需要在 Windows 上调用 Python 做一些操作，但无法调用 Python 导致的。那么我们只要安装 Python 的时候，选择添加到 Path，或者已经安装 Python 的同学，将 Python 添加到 Path，最终使得能够在 Windows 终端下直接调用 Python 即可。最终效果示例如下：
此外，因为 ECS 终端默认启动的 Python 是/usr/bin/python，而在 ECS 默认是 Python2 直接运行程序会报错，而我们需要用 Python3，所以需要重新链接符号，具体流程为：删除 python 链接文件–>>新建链接文件到 python3，下面是操作步骤：
那么有人可能就要问了，为什么是/usr/local/python3.9.5/bin/python3 呢？因为我们在通过 MindStudio 直接在远程 ECS 上运行的时候，就是用的这个啊，来张图看看：
这里提个建议，我之前运行会报错，详情见https://www.hiascend.com/forum/thread-0229107014330773104-1-1.html，连着两天重启，试了好几次，就是不行，后来又试了一次，突然就可以了，感觉很奇怪，莫明其妙地报错，莫名其秒地好了，这给我一种 IDE 很不稳定的感觉。建议优化一下，提升下稳定性。
2. 执行 Profiling 采集
（1）单击菜单栏“Ascend > System Profiler > New Project”，弹出 Profiling 配置窗口 。
配置“Project Properties”，配置工程名称“Project Name”和选择工程路径“Project Location”。单击“Next”进入下一步。
（2）进入“Executable Properties”配置界面。
（3）进入“Profiling Options”配置界面，配置项按默认配置
完成上述配置后单击窗口右下角的“Start”按钮，启动 Profiling。工程执行完成后，MindStudio 自动弹出 Profiling 结果视图。
先来看下全量迭代耗时数据，在 Timeline 视图下查看 Step Trace 数据迭代耗时情况，识别耗时较长迭代进行分析。注意，可选择导出对应迭代 Timeline 数据，单击耗时较长迭代按钮
弹出对话框，单击“Yes”导出对应迭代 Timeline 数据。如图所示，如果最初看不见，建议将鼠标放到图上，之后滑动放大，就能看见了。
还可以查看迭代内耗时情况：存在较长耗时算子时，可以进一步找算子详细信息辅助定位；存在通信耗时或调度间隙较长时，分析调用过程中接口耗时。如图所示。
在界面下方还能查看对应的算子统计表：查看迭代内每个 AICORE 和 AICPU 算子的耗时及详细信息，进一步定位分析算子的 Metrics 指标数据，分析算子数据搬运、执行流水的占比情况，识别算子瓶颈点。
此外，这里还能查看组件接口耗时统计表：查看迭代内 AscendCL API 和 Runtime API 的接口耗时情况，辅助分析接口调用对性能的影响。
这个要说一下，限于屏幕大小，上述这次数据的完整展示，可能需要放大或缩小，或者调整某些部分大小，这些操作很卡顿，操作起来没什么反应，仿佛这个界面卡死了，可用性差，用户体验不好，建议优化一下。
我们可以看到下图中这个 Op 的 Task Wait Time 要 9.895us，而其他 Op 基本为 0，所以可以考虑试试能不能减少这个 Wait Time，从而提升性能。
这里说一下，上图中这个 Op Name 很长，我需要将这栏横向拉伸很长才能完整显示，这有点麻烦，我本来想将鼠标悬停此处，让其自动显示完整名称，但好像不行，能否考虑加一下这个悬停显示全部内容的操作，否则我要先拉伸看，之后再拉回去看其他，比较麻烦。
还记得之前我们在专家系统工具那时提到的 MTE2 瓶颈相比之下有些大（约 0.39）嘛？这里从下图看到 Mte2 时间较长，约 3.7ms，说一下，mte2 类型指令应该是 DDR->AI Core 搬运类指令，这里我们量化一下看看，如下图所示，AI Core 时间约为 6.8ms，但 Task Duration 约 12.5ms，几乎翻倍了，说明我们 Task 只有约一半时间是真正用于 AI Core 计算，很明显很多时间被浪费了。
说明这一点还是比较值得优化的。而各个工具之间也是可以相互辅助，相互验证更好地帮助我们定位问题。下面我们再看看，先确认下 Timeline 颜色配置调色板，如下图所示。而我们之前看到的 Timeline 基本是绿色，未见黄色或红色，估计没什么优化空间了。还是优先做明显地值得优化地点吧，这也算抓大放小吧。
好了，我们再看点其他的，比如 Analysis Summary，这里展示了比较详细的软硬件信息，比如 Host Computer Name、Host Operating System 等，还有我们 ECS 上用的 CPU 的详细信息，包括型号、逻辑核心数量等，令我感兴趣的是，还有 Ascend 310 的信息，包括 AI Core 数量 2， AI CPU 数量 4，Control CPU 数量 4，Control CPU Type 为 ARMv8_Cortex_A55，以及一个 TS CPU，很详细了，很好地展示了 Ascend 310 的内部硬件信息，更有助于我们了解这款处理器。
同时，再来看看 Baseline Comparison 吧。
总的来说，MindStudio 提供了 Host+Device 侧丰富的性能数据采集能力和全景 Timeline 交互分析能力，展示了 Host+Device 侧各项性能指标，帮助用户快速发现和定位 AI 应用、芯片及算子的性能瓶颈，包括资源瓶颈导致的 AI 算法短板，指导算法性能提升和系统资源利用率的优化。MindStudio 支持 Host+Device 侧的资源利用可视化统计分析，具体包括 Host 侧 CPU、Memory、Disk、Network 利用率和 Device 侧 APP 工程的硬件和软件性能数据。通过 Profiling 性能分析工具前后两次对网络应用推理的运行时间进行分析，并对比两次执行时间可以得出结论，可以帮助我们去验证替换函数或算子后，是否又性能提升，是否提升了推理效率。此外，还可以帮助我们挑选应该优先选择的网络模型，或者测试自定义算子是否达到最优性能，是否还存在优化空间等等，还是挺有用的。
MindStudio 精度比对工具
1. 定义
为了帮助开发人员快速解决算子精度问题，需要提供自有实现的算子运算结果与业界标准算子运算结果之间进行精度差异对比的工具。
2. 功能
提供 Tensor 比对能力，包含余弦相似度、欧氏相对距离、绝对误差（最大绝对误差、平均绝对误差、均方根误差）、相对误差（最大相对误差、平均相对误差、累积相对误差）、KL 散度、标准差算法比对维度。
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/6f118fd2d2ed2bdda52eb531f】。文章转载请联系作者。
提供全面深入的云计算技术干货 2020-07-14 加入
生于云，长于云，让开发者成为决定性力量
评论