队伍：AP0200008
目录
4.2 对 TPU - MLIR 在 DSA 相关编译器的看法
4.3 对 TPU - MLIR 在异构计算编译器方面的看法
一、描述 UNet 适配过程
1.1详细步骤
整个步骤遵照官网教程以及复赛指南进行，分为以下几步：
- Docker 环境搭建及测试
- 利用 PyTorch 内建工具导出 UNetONNX 模型.
- 利用 model _ transform. py 工具导出UNetfloat32tpuMLIR模型
- 利用 run _ calibration . py 工具在测试数据集上计算模型量化用的校准表
- 利用 model _ deploy . py 工具的对称量化方法将UNetfloat32tpuMLIR转化为UNetINT8symmetrictpuMLIR，同时输出等价的 bmodel 文件
- 利用UNetINT8symmetrictpuMLIR在测试数据集上完成推理在此基础上，前后处理阶段也分别做了一定优化，具体优化方式在＃2解决问题的过程中有详细描述。比赛过程中，按照上述流程根据不同的分辨率设置进行搜索，选择较优的模型提交。
2．可复现的结果
结果复现已审核， DiceScore 为0.96753341，单张推理时间5.054758ms，按照核算方式总分391.698583，排名第一。
二、解决问题的过程
2.1 列举在适配过程中遇到的困难，以及解决方法
a．低分辨率下，分割误差大工
主要原因是在分割的主体之外，存在零散的小块误分割空洞（红色标记），这些区域是可以直接处理的，利用 OpenCV 寻找最大的连通区域，重新构造分割 mask 输出即可。虽然这种方法无法处理与分割目标相近的误分类区域（绿色标记），但是还是有一定提升的（具体数值忘记了）。
2.2 低分辨率下，输出仍然不够准确
主要是问题＃1提到的与目标相近的误分类区域（绿色标记）。这很大程度是因为图片缩放后，卷积核感受野在实际上增大了，由于量化损失以及缩放损失的累计，对边缘部分不能细粒度地完成分类。
如果将测试图片进行堆叠，可以发现由于数据集比较统一，大多数的分割主体都位于红色虚线内，在推理过程中可以将这一先验引入到前处理过程，经过粗略的定位可以得到一个大约1650x810的切分区域，在每次推理的前处理中 Crop 一下图像即可，推理完成后对应地对红框外的区域进行补全。这个优化大概可以得到～10个点的提升（如果没记错的话）。
2.3 最优分辨率选择
一个比较显然的事实是：分辨率越低，推理延迟越低，但精度损失越大。在比赛中，为了达到比较好的平衡，将图像高设置在200-500这个区域进行搜索。另一个问题是怎么缩放，这里我选择的策略是按比例缩放，原图大概是3:2的图像，因此在设置图像高时可以对应的到图像的长。在应用 Crop 优化后，按照2:1的比例进行缩放。
在前期实验中，图像宽高都设置为64的倍数，以快速进行粗粒度的搜索。最后提交时试了不同的分辨率。
2.4 其他还没来得及做的优化
因为最后两天才定了最终方案，因此还有一些优化的方法没有使用：
- 优化2里使用了原图来确定 Crop 区域，实际上如果使用参考输出的堆叠图像应该能寻找到更好的边界
- 没有使用 onnxsim ，应该可以减少一两个 Op
- 由于该模型实际上是一个二分类模型，那么其 logits 也是有一定特征的。优化1提到的红色标记区域和绿色标记区域，在后处理中很简单地通过比较大小 np . where ( out _[0,0]> out _[0,1]的区域，这个分类结果的 Confidence 是很低的。如果设置一个阈值 T ，该写为 np . where (( out _[0,0]-out0,)> T ,0,), KaMT ,能够得到不同的第一阶段输出，对于最终结果也是有影响的。在固定数据集和模型的情况下，应该是有一个最优的 T 。
三、提出 TPU - MLIR 可以改进的部分
3.1 在使用上可以精简的地方
接触的工具比较少，感觉已经比较精简了。 model _ deploy 工具里有 tolerance 设置，这个感觉也可以不做设置或不满足时不 raiseerror ，在完成之后输出 npz _ tool 输出的相似度范围。在比赛中设置一个固定的 tolerance 之后偶尔会遇到低于阈值然后断掉的情况，这个阈值应该是按照经验均衡了效果和速度定的一个值，但是实际上低一点也可以接受。
3.2 在功能上可以增强的地方（需具备可行性）
- 生成校准表时，内存占用很大，应该是可以优化的。
- 可以补充工具文档说明，在使用过程发现会产生很多中间输出，虽然再翻阅文档和尝试后能够大概了解各中间输出的作用，但是如果在文档中做一个说明则更好。
- 文档里好像没有提到 dynamicshape 模型的部署，但是代码里是有的，如果该功能是可用的可以加到文档里。
四、简介对 TPU - MLIR 工程的看法
4.1 对 MLIR 的看法
与 TVM 等深度学习编译器不同， MLIR 并不是面向机器学习模型而提出来的一个框架，但是借助它可以完成类似的工作。现在各厂商 DSA 不同，单独地设计工具链（如 SAIL ）是很麻烦的一件事，与 TVM 等框架的集成又需要深度定制，有些硬件由于张量化不好做，可能 TVM 的优势也发挥不起来。 MLIR 基于 LLVM 框架，可定制性很高，因为它的 Multi - level 设计，上层可以接入机器学习的计算图 IR 规范，底层可以依靠方言接入硬件指令层级 IR ，可以进行很好的扩展。在开发过程中，编译器团队可能更熟悉 MLIR ，它更像是做系统的人做出来的东西；而做部署的团队可能更熟悉 TVM ，它更像是做深度学习的人做出来的东西。但他们的抽象的框架都相似，在 Pass 和一些功能性上可能各有优势。对于在 DSA 上搭建工具链选择任何一个都可以，工具不是目的。
4.2 对 TPU - MLIR 在 DSA 相关编译器的看法
对 MLIR 和 TPU - MLIR 还不够熟悉，没有什么看法。但是整体来看，做 MLIR 实际落地并且开源的团队，确实是 TPU - MLIR 做的最好。
4.3 对 TPU - MLIR 在异构计算编译器方面的看法
对异构计算编译器不了解，但是跟着 TPU - MLIR 工具链走下来的话发现最后还是生成的 bmodel 文件，应该还是 bmodel 加载-> host 发送输入张量地址到 TPU -> TPU 计算这个方式，而 bmodel 文件还是顺序的指令集合。本质上与之前的 BMNNSDK 一套相似，可能借助 MLIR 这个平台在后期新的硬件或者指令集上能够有较好的可扩展性。