138 lines
6.2 KiB
Markdown
138 lines
6.2 KiB
Markdown
|
# mmdeploy 各目录功能
|
|||
|
|
|
|||
|
|
本文主要介绍 mmdeploy 各目录功能，以及从模型到具体推理框架是怎么工作的。
|
|||
|
|
|
|||
|
|
## 一、大致看下目录结构
|
|||
|
|
|
|||
|
|
整个 mmdeploy 可以看成比较独立的两部分：模型转换 和 SDK。
|
|||
|
|
|
|||
|
|
我们介绍整个 repo 目录结构和功能，不必细究源码、有个印象即可。
|
|||
|
|
|
|||
|
|
外围目录功能：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
$ cd /path/to/mmdeploy
|
|||
|
|
$ tree -L 1
|
|||
|
|
.
|
|||
|
|
├── CMakeLists.txt # 编译模型转换自定义算子和 SDK 的 cmake 配置
|
|||
|
|
├── configs # 模型转换要用的算法库配置
|
|||
|
|
├── csrc # SDK 和自定义算子
|
|||
|
|
├── demo # 各语言的 ffi 接口应用实例，如 csharp、java、python 等
|
|||
|
|
├── docker # docker build
|
|||
|
|
├── mmdeploy # 用于模型转换的 python 包
|
|||
|
|
├── requirements # python 包安装依赖
|
|||
|
|
├── service # 有些小板子不能跑 python，模型转换用的 C/S 模式。这个目录放 Server
|
|||
|
|
├── tests # 单元测试
|
|||
|
|
├── third_party # SDK 和 ffi 要的第三方依赖
|
|||
|
|
└── tools # 工具，也是一切功能的入口。除了 deploy.py 还有 onnx2xx.py、profile.py 和 test.py
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
这样大致应该清楚了
|
|||
|
|
|
|||
|
|
- 模型转换主要看 tools + mmdeploy + 小部分 csrc 目录；
|
|||
|
|
- 而 SDK 的本体在 csrc + third_party + demo 三个目录。
|
|||
|
|
|
|||
|
|
## 二、模型转换
|
|||
|
|
|
|||
|
|
模型以 mmcls 的 ViT 为例，推理框架就用 ncnn 举例。其他模型、推理都是类似的。
|
|||
|
|
|
|||
|
|
我们看下 mmdeploy/mmdeploy 目录结构，有个印象即可：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
.
|
|||
|
|
├── apis # tools 工具用的 api，都是这里实现的，如 onnx2ncnn.py
|
|||
|
|
│ ├── calibration.py # trt 专用收集量化数据
|
|||
|
|
│ ├── core # 软件脚手架
|
|||
|
|
│ ├── extract_model.py # onnx 模型只想导出一部分，切 onnx 用的
|
|||
|
|
│ ├── inference.py # 抽象函数，实际会调 torch/ncnn 具体的 inference
|
|||
|
|
│ ├── ncnn # 引用 backend/ncnn 的函数，只是包了一下
|
|||
|
|
│ └── visualize.py # 还是抽象函数，实际会调用 torch/ncnn 具体的 inference 和 visualize
|
|||
|
|
..
|
|||
|
|
├── backend # 具体的 backend 包装
|
|||
|
|
│ ├── base # 因为有多个 backend，所以得有个 base 类的 OO 设计
|
|||
|
|
│ ├── ncnn # 这里为模型转换调用 ncnn python 接口
|
|||
|
|
│ │ ├── init_plugins.py # 找 ncnn 自定义算子和 ncnn 工具的路径
|
|||
|
|
│ │ ├── onnx2ncnn.py # 把 `mmdeploy_onnx2ncnn` 封装成 python 接口
|
|||
|
|
│ │ ├── quant.py # 封装 `ncnn2int8` 工具为 python 接口
|
|||
|
|
│ │ └── wrapper.py # 封装 pyncnn forward 接口
|
|||
|
|
..
|
|||
|
|
├── codebase # mm 系列算法 forward 重写
|
|||
|
|
│ ├── base # 有多个算法，需要点 OO 设计
|
|||
|
|
│ ├── mmcls # mmcls 相关模型重写
|
|||
|
|
│ │ ├── deploy # mmcls 对 base 抽象 task/model/codebase 的实现
|
|||
|
|
│ │ └── models # 开始真正的模型重写
|
|||
|
|
│ │ ├── backbones # 骨干网络部分的重写，例如 multiheadattention
|
|||
|
|
│ │ ├── heads # 例如 MultiLabelClsHead
|
|||
|
|
│ │ ├── necks # 例如 GlobalAveragePooling
|
|||
|
|
│..
|
|||
|
|
├── core # 软件脚手架，重写机制怎么实现的
|
|||
|
|
├── mmcv # mmcv 有的 opr 也需要重写
|
|||
|
|
├── pytorch # 针对 ncnn 重写 torch 的 opr，例如 Gemm
|
|||
|
|
..
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
上面的每一行是需要读的，请勿跳过。
|
|||
|
|
|
|||
|
|
当敲下`tools/deploy.py` 转换 ViT，核心是这 3 件事：
|
|||
|
|
|
|||
|
|
1. mmcls ViT forward 过程的重写
|
|||
|
|
2. ncnn 不支持 gather opr，自定义一下、和 libncnn.so 一起加载
|
|||
|
|
3. 真实跑一遍，渲染结果，确保正确
|
|||
|
|
|
|||
|
|
### 1. forward 重写
|
|||
|
|
|
|||
|
|
因为 onnx 会生成稀碎的算子、ncnn 也不是完美支持 onnx，所以 mmdeploy 的方案是劫持有问题的 forward 代码、改成适合 ncnn 的 onnx 结果。
|
|||
|
|
|
|||
|
|
例如把 `conv -> shape -> concat_const -> reshape` 过程改成 `conv -> reshape`，削掉多余的 `shape` 和 `concat` 算子。
|
|||
|
|
|
|||
|
|
所有的 mmcls 算法重写都在 `mmdeploy/codebase/mmcls/models`目录。
|
|||
|
|
|
|||
|
|
### 2. 自定义算子
|
|||
|
|
|
|||
|
|
针对 ncnn 自定义的算子都在 `csrc/mmdeploy/backend_ops/ncnn/`目录，编译后和 libncnn.so 一起加载。本质是在 hotfix ncnn，目前实现了
|
|||
|
|
|
|||
|
|
- topk
|
|||
|
|
- tensorslice
|
|||
|
|
- shpe
|
|||
|
|
- gather
|
|||
|
|
- expand
|
|||
|
|
- constantofshape
|
|||
|
|
|
|||
|
|
### 3. 转换和测试
|
|||
|
|
|
|||
|
|
ncnn 的兼容性较好，转换用的是修改后的 `mmdeploy_onnx2ncnn`，推理封装了 `pyncnn`+ 自定义 ops。
|
|||
|
|
|
|||
|
|
遇到 snpe 这种不支持 python 的框架，则使用 C/S 模式：用 gRPC 等协议封装一个 server，转发真实的推理结果。
|
|||
|
|
|
|||
|
|
渲染使用上游算法框架的渲染 API，mmdeploy 自身不做绘制。
|
|||
|
|
|
|||
|
|
## 三、SDK
|
|||
|
|
|
|||
|
|
模型转换完成后，可用 C++ 编译的 SDK 执行在不同平台上。
|
|||
|
|
|
|||
|
|
我们看下 csrc/mmdeploy 目录结构：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
.
|
|||
|
|
├── apis # Csharp、java、go、Rust 等 ffi 接口
|
|||
|
|
├── backend_ops # 各推理框架的自定义算子
|
|||
|
|
├── CMakeLists.txt
|
|||
|
|
├── codebase # 各 mm 算法框架偏好的结果类型，例如检测任务多用 bbox
|
|||
|
|
├── core # 脚手架，对图、算子、设备的抽象
|
|||
|
|
├── device # CPU/GPU device 抽象的实现
|
|||
|
|
├── execution # 对 exec 抽象的实现
|
|||
|
|
├── graph # 对图抽象的实现
|
|||
|
|
├── model # 实现 zip 压缩和非压缩两种工作目录
|
|||
|
|
├── net # net 的具体实现，例如封装了 ncnn forward C 接口
|
|||
|
|
├── preprocess # 预处理的实现
|
|||
|
|
└── utils # OCV 工具类
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
SDK 本质是设计了一套计算图的抽象，把**多个模型**的
|
|||
|
|
|
|||
|
|
- 预处理
|
|||
|
|
- 推理
|
|||
|
|
- 后处理
|
|||
|
|
|
|||
|
|
调度起来，同时提供多种语言的 ffi。
|