4.1.1.7. 模型性能分析与调优¶
本节介绍了如何使用地瓜机器人提供的工具评估模型性能。 如果此阶段发现评估结果不符合预期，强烈建议您尽量在此阶段根据地瓜机器人的优化建议解决性能问题， 不建议将模型的问题延伸到应用开发阶段。
4.1.1.7.1. 使用 hb_perf 工具估计性能¶
地瓜机器人提供的 hb_perf 以模型转换得到的 *.bin 为输入，可以直接得到模型预期上板性能（不含 CPU 部分的计算评估），工具使用方式如下：
hb_perf ***.bin
注解
如果分析的是 pack 后模型，需要加上一个 -p 参数，命令为 hb_perf -p ***.bin。
关于模型 pack，请查看 其他模型工具（可选） 部分的介绍。
命令中的 *.bin 就是模型转换产出的 bin 模型，命令执行完成后，
在当前工作目录下会得到一个 hb_perf_result 目录，分析结果以 html 形式提供。
以下是我们分析一个 MobileNet 的示例结果，其中 mobilenetv1_224x224_nv12.html 就是查看分析结果的主页面。
hb_perf_result/
└── mobilenetv1_224x224_nv12
├── MOBILENET_subgraph_0.html
├── MOBILENET_subgraph_0.json
├── mobilenetv1_224x224_nv12
├── mobilenetv1_224x224_nv12.html
├── mobilenetv1_224x224_nv12.png
└── temp.hbm
通过浏览器打开结果主页面，其内容如下图：
分析结果主要由 Model Performance Summary、Details 和 BIN Model Structure 三个部分组成。 Model Performance Summary 是整个 bin 模型的整体性能评估结果，其中各项指标为:
Model Name——模型名称。
BPU Model Latency(ms)——模型整体单帧计算耗时(单位为 ms)。
Total DDR (loaded+stored) bytes per frame(MB per frame)——模型整体 BPU 部分数据加载和存储所占用的 DDR 总量（单位为 MB/frame）。
Loaded Bytes per Frame——模型运行每帧读取数据量。
Stored Bytes per Frame——模型运行每帧存储数据量。
在了解 Details 和 BIN Model Structure 前，您需要了解子图（subgraph）的概念。 如果模型在非输入和输出部分出现了 CPU 计算的算子，模型转换工具将把这个算子前后连续在 BPU 计算的部分拆分为两个独立的子图（subgraph）。 具体可以参考 验证模型 部分的介绍。
Details 是每份模型 BPU 子图的具体信息，在主页面中，每个子图提供的指标解读如下：
Model Subgraph Name——子图名称。
Model Subgraph Calculation Load (OPpf)——子图的单帧计算量。
Model Subgraph DDR Occupation(Mbpf)——子图的单帧读写数据量（单位为 MB）。
Model Subgraph Latency(ms)——子图的单帧计算耗时（单位为 ms）。
每份子图结果提供了一个明细入口，以上指标都是明细页面提取到的，进入到明细页面可以给您更加细致的参考信息。
注意
需要特别注意的是，明细页面会根据您是否启用调试参数（ debug ）而有所区别，
下方的 Layer Details 仅当在配置文件中设置 debug 参数为 True 时才可以拿到，
这个 debug 参数配置方法请参考 使用 hb_mapper makertbin 工具转换模型 部分的介绍。
BIN Model Structure 部分提供的是 bin 模型的子图级可视化结果，图中深色节点表示运行在 BPU 上的节点，灰色节点表示在 CPU 上计算的节点。
Layer Details 提供到了具体算子级别的分析，在调试分析阶段也是比较不错的参考， 如果是某些 BPU 算子导致性能低，可以帮助您定位到这个具体算子。
其中，每项指标解读如下：
layer：layer 名。
ops：计算量。
original output shape：原始算子输出 shape。
aligned output shape：对齐后的算子输出 shape。
computing cost (no DDR)：计算耗时。
load/store cost：数据搬运耗时。
active period of time：编译后 layer 活跃时间段（不代表该 layer 执行时间，通常为多个 layer 交替/并行执行）。
使用 hb_perf 的意义在于了解 bin 模型子图结构，对于 BPU 上计算部分，该工具也能提供较全面的静态分析指标。
不过 hb_perf 不含 CPU 部分的计算评估，如果 CPU 计算仅限于模型输入或输出部分的常规性处理，不含计算密集型计算节点，这个影响不大。
否则，您就一定需要利用开发板工具实测性能。
4.1.1.7.2. 开发板实测性能¶
开发板上实测模型性能使用的是开发板上 hrt_model_exec perf 工具，
hrt _model_exec 是一个模型执行工具，可直接在开发板上评测模型的推理性能、获取模型信息。
一方面可以让用户拿到模型时实际了解模型真实性能；
另一方面也可以帮助用户了解模型可以做到的速度极限，对于应用调优的目标极限具有指导意义。
使用 hrt_model_exec perf 工具前，有两个准备工作。
确保您已经参考 环境部署 介绍完成了开发板上工具安装。
第二是需要将 Ubuntu 开发机上得到的 bin 模型拷贝到开发板上（建议放在/userdata 目录）， 开发板上是一个 Linux 系统，可以通过
scp等 Linux 系统常用方式完成这个拷贝过程。
注解
此时使用的模型不需要打开 debug，debug 打开会影响模型在开发板的测试结果。
使用 hrt_model_exec perf 实测性能的参考命令如下（注意是在开发板上执行）：
./hrt_model_exec perf --model_file mobilenetv1_224x224_nv12.bin \
--model_name="" \
--core_id=0 \
--frame_count=200 \
--perf_time=0 \
--thread_num=1 \
--profile_path="."
其中，各参数含义如下：
model_file：
需要分析性能的 bin 模型名称。
model_name：
需要分析性能的 bin 模型名字。若 model_file 只含一个模型，则可以省略。
core_id：
默认值 0，运行模型使用的核心 id，0 代表任意核心，1 代表核心 0，2 代表核心 1。若要分析双核极限帧率，请将此处设为 0。
frame_count：
默认值 200，设置推理帧数，工具会执行指定次数后再分析平均耗时。 当 perf_time 为 0 时生效。
perf_time：
默认值 0，单位分钟。设置推理时间，工具会执行指定时间后再分析平均耗时。
thread_num：
默认值 1，设置运行的线程数，取值范围 [1,8]。若要分析极限帧率，请将线程数改大。
profile_path：
默认关闭，统计工具日志产生路径。该参数引入的分析结果会存放在指定目录下的 profiler.log 和 profiler.csv 文件中。
命令执行完成后，您将在控制台得到如下结果。
最终的评估结果就是 Average latency 和 Frame rate，分别表示平均单帧推理延时和模型极限帧率。
如果想获得模型在板子上运行的极限帧率，需将 thread_num 设置得足够大。
Running condition:
Thread number is: 1
Frame count is: 200
Program run time: 818.985000 ms
Perf result:
Frame totally latency is: 800.621155 ms
Average latency is: 4.003106 ms
Frame rate is: 244.204717 FPS
控制台得到的信息只有整体情况，通过 profile_path 控制产生的 profiler.log 和 profiler.csv 文件记录了更加丰富的信息如下：
{
"perf_result": {
"FPS": 244.20471681410527,
"average_latency": 4.003105640411377
},
"running_condition": {
"core_id": 0,
"frame_count": 200,
"model_name": "mobilenetv1_224x224_nv12",
"run_time": 818.985,
"thread_num": 1
}
}
***
{
"processor_latency": {
"BPU_inference_time_cost": {
"avg_time": 3.42556,
"max_time": 3.823,
"min_time": 3.057
},
"CPU_inference_time_cost": {
"avg_time": 0.29193,
"max_time": 0.708,
"min_time": 0.101
}
},
"model_latency": {
"BPU_MOBILENET_subgraph_0": {
"avg_time": 3.42556,
"max_time": 3.823,
"min_time": 3.057
},
"Dequantize_fc7_1_HzDequantize": {
"avg_time": 0.12307,
"max_time": 0.274,
"min_time": 0.044
},
"MOBILENET_subgraph_0_output_layout_convert": {
"avg_time": 0.025945,
"max_time": 0.069,
"min_time": 0.012
},
"Preprocess": {
"avg_time": 0.009245,
"max_time": 0.027,
"min_time": 0.003
},
"Softmax_prob": {
"avg_time": 0.13366999999999998,
"max_time": 0.338,
"min_time": 0.042
}
},
"task_latency": {
"TaskPendingTime": {
"avg_time": 0.04952,
"max_time": 0.12,
"min_time": 0.009
},
"TaskRunningTime": {
"avg_time": 3.870965,
"max_time": 4.48,
"min_time": 3.219
}
}
}
这里的内容会对应到 使用 hb_perf 工具估计性能 中的 BIN Model Structure 部分介绍的 bin 可视化图中，
图中每个节点都有一个对应节点在 profiler.log 文件中，可以通过 name 对应起来。
profiler.log 文件中记录了每个节点的执行时间，对优化节点有重要的参考意义。
由于模型中的 BPU 节点对输入输出有特殊要求，如特殊的 layout 和 padding 对齐要求，因此需要对 BPU 节点的输入、输出数据进行处理。
Preprocess：表示对模型输入数据进行 padding 和 layout 转换操作，其耗时统计在 Preprocess 中。xxxx_input_layout_convert： 表示对 BPU 节点的输入数据进行 padding 和 layout 转换的操作，其耗时统计在 xxxx_input_layout_convert 中。xxxx_output_layout_convert： 表示对 BPU 节点输出数据进行去掉 padding 和 layout 转换的操作，其耗时统计在 xxxx_output_layout_convert 中。
profiler 分析是经常使用的操作，前文 检查结果解读 部分提到检查阶段不用过于
关注 CPU 算子， 此阶段就能看到 CPU 算子的具体耗时情况了，如果根据这里的评估认为 CPU 耗时太长，那就值得优化了。
4.1.1.7.3. 模型性能优化¶
根据以上性能分析结果，您可能发现性能结果不及预期，本章节内容介绍了地瓜机器人对提升模型性能的建议与措施，包括： 检查 yaml 配置参数、 处理 CPU 算子、 高性能模型设计建议、 使用地瓜机器人平台友好结构&模型 等内容。
部分修改可能会影响原始浮点模型的参数空间，意味着需要您重训模型，为了避免性能调优过程中反复调整并训练的代价， 在得到满意性能效果前，建议您使用随机参数导出模型来验证性能即可。
检查影响模型性能的 yaml 参数
在模型转换的 yaml 配置文件中，部分参数会实际影响模型的最终性能，可以先检查下是否已正确按照预期配置， 各参数的具体含义和作用请参考 配置文件具体参数信息 小节的内容。
layer_out_dump：指定模型转换过程中是否输出模型的中间结果，一般仅用于调试功能。 如果将其配置为True，则会为每个卷积算子增加一个反量化输出节点，它会显著的降低模型上板后的性能。 所以在性能评测时，务必要将该参数配置为False。compile_mode：该参数用于选择模型编译时的优化方向为带宽还是时延，关注性能时请配置为latency。optimize_level：该参数用于选择编译器的优化等级，实际生产中应配置为O3获取最佳性能。core_num：配置为2时可同时调用两个核运行，降低单帧推理延迟，但是也会影响整体的吞吐率。debug：配置为True将打开编译器的 debug 模式，能够输出性能仿真的相关信息，如帧率、DDR 带宽占用等。 一般用于性能评估阶段。可关闭该参数减小模型大小，提高模型执行效率。max_time_per_fc：该参数用于控制编译后的模型数据指令的 function-call 的执行时长，从而实现模型优先级抢占功能。 设置此参数更改被抢占模型的 function-call 执行时长会影响该模型的上板性能。
处理 CPU 算子
根据 hrt_model_exec perf 的评估，已经确认突出的性能瓶颈是 CPU 算子导致的。
此种情况下，我们建议您先查看 模型转换工具链算子支持约束列表 章节，确认当前运行在 CPU 上的算子是否具备 BPU 支持的能力。
如果算子不具备 BPU 支持能力，那么就是您的算子参数超过了 BPU 支持的参数约束范围， 将相应原始浮点模型计算参数调整到约束范围内即可。 为了方便您快速知晓超出约束的具体参数，建议您再使用 验证模型 部分介绍的方法做一遍检查， 工具将会直接给出超出 BPU 支持范围的参数提示。
注解
修改原始浮点模型参数对模型计算精度的影响需要您自己把控，
例如 Convolution 的 input_channel 或 output_channel 超出范围就是一种较典型的情况，
减少 channel 快速使得该算子被 BPU 支持，单单只做这一处修改也预计会对模型精度产生影响。
如果算子并不具备 BPU 支持能力，就需要您根据以下情况做出对应优化操作：
CPU 算子处于模型中部
对于 CPU 算子处于模型中部的情况，建议您优先尝试参数调整、算子替换或修改模型。
CPU 算子处于模型首尾部
对于 CPU 算子处于模型首尾部的情况，请参考以下示例，下面以量化/反量化节点为例：
对于与模型输入输出相连的节点，可以在 yaml 文件 model_parameters 配置组（模型参数组）中增加
remove_node_type参数，并重新编译模型。remove_node_type: "Quantize; Dequantize"
或使用 hb_model_modifier 工具对 bin 模型进行修改：
hb_model_modifier x.bin -a Quantize -a Dequantize
对于下图这种没有与输入输出节点相连的模型，则需要使用 hb_model_modifier 工具判断相连节点是否支持删除后按照顺序逐个进行删除。
先使用 hb_perf 工具获取模型结构图片，然后使用以下两条命令可以自上而下移除 Quantize 节点， 对于 Dequantize 节点自下而上逐个删除即可，每一步可删除节点的名称可以通过
hb_model_modifier x.bin进行查看。hb_model_modifier x.bin -r res2a_branch1_NCHW2NHWC_LayoutConvert_Input0 hb_model_modifier x_modified.bin -r data_res2a_branch1_HzQuantize
高性能模型设计建议
根据性能评估结果，CPU 上耗时占比可能很小，主要的性能瓶颈还是 BPU 推理时间过长。 这种情况下，我们已经把计算器件都用上了，发力的空间就在于提升计算资源的利用率。 每种处理器都有自己的硬件特性，算法模型的计算参数是否很好地符合了硬件特性， 直接决定了计算资源的利用率，符合度越高则利用率越高，反之则低。 本部分介绍重点在于阐明地瓜机器人的硬件特性。 首先，地瓜机器人的计算平台旨在加速 CNN（卷积神经网络），主要的计算资源都集中在处理各种卷积计算。 所以，我们希望您的模型是以卷积计算为主的模型，卷积之外的算子都会导致计算资源的利用率降低，不同 OP 的影响程度会有所不同。
整体硬件要求
下表是硬件层面提出的一些计算友好性要求，供您做一个全面参考。
卷积的 Width 对齐
因为计算 MAC 阵列对齐要求的问题，featuremap 的 W 在 8 对齐的时候效率会比较高(Convolution 的 stride=2 时，W 需要 16 对齐)。 如果不是 8 或 16 对齐，那么就会带来算力浪费，导致 MAC 利用率变低。 比如，如果 convolution 的输入 feature 大小是 1x8x9x32 (NHWC)，那么在实际计算时， W 会被 padding 到 16（即 feature 大小变为 1x8x16x32），会造成计算资源浪费。
在设计网络的时候，如果可以改变整个神经网络的输入大小（向上或向下对齐），那么模型的 MAC 利用率会直接提高。
模型输入大小的示例，比如一个多层 stride=2 conv 的网络（从 resnet 截取），输入 224 和 256/192 的区别。
卷积的 Channel 对齐
Channel 在硬件上是需要 8 对齐的，在算法设计的时候最好将 kernel num 调整为 8 的倍数。
对于 Group Convolution，channel 的对齐情况会更加复杂一些。
如果 Kernel 不是 8 的整数倍，那么每个 group 的 kernel num 需要对齐到 8。 而且，由于这个对齐，会导致之后的 convolution 也产生算力浪费。 如上图所示，Convolution2 中对 weight 进行 padding 之后，下一层的 weight 也需要进行 padding。
注解
padding 的方式是每个 group 内对齐到 8，即 padding 的数据是分散在整个 weight 中间。
如果 group 内 channel 不是 8 的整数倍，那么就需要对上一层 convolution 进行 padding。 如上图所示，Convolution1 的 kernel num 从 48 被 padding 到了 64。
另外，如果有连续多个 group convolution 中发生了 group 内 kernel num 或 channel num 不对齐的情况，那么影响会更大。 这种情况下我们需要同时考虑多层 group conv 的对齐要求，会导致更多的 padding。 最差情况下，group convolution 会被转换为普通 convolution。
激活函数
大部分激活函数需要用 LUT 和 Elementwise OP 实现，虽然现在可以支持 LUT 和 Elementwise 操作，但是都是用其它 OP 拼出来的，而且效率都不太高。
如果模型中只有少量的几个地方使用非硬件直接支持的激活函数（非 relu），而且计算量不是特别大，那么是可以使用的。 在这种情况下，对整个模型的计算效率应该不会很大。
如果模型中需要大量使用非硬件直接支持的激活函数，那么会对模型的执行速度产生非常大的影响。
其他建议
地瓜机器人计算平台上的 depthwise convolution 的计算效率接近 100%，所以对于 MobileNet 类的模型，BPU 具有效率优势。
另外，在模型设计时，我们应尽量让模型 BPU 段的输入输出维度降低，以减少量化、反量化节点的耗时和硬件的带宽压力。 以典型的分割模型为例，我们可以将 Argmax 算子直接合入模型本身。 但需注意，只有满足以下条件，Argmax 才支持 BPU 加速：
Caffe 中的 Softmax 层默认 axis=1，而 ArgMax 层则默认 axis=0，算子替换时要保持 axis 的一致。
Argmax 的 Channel 需小于等于 64，否则只能在 CPU 上计算。
BPU 面向高效率模型优化
学术界在持续优化算法模型的计算效率（同样算法精度下所需的理论计算量越小越高效）、参数效率（同样算法精度下所用参数量越小越高效）。 这方面的代表工作有 EfficientNet 和 ResNeXt，二者分别使用了 Depthwise Convolution 和 Group Convolution。 面对这样的高效率模型，GPU/TPU 支持效率很低，不能充分发挥算法效果，学术界被迫针对 GPU/TPU 分别优化了 EfficientNet V2/X 和 NFNet， 优化过程主要是通过减少 Depthwise Convolution 的使用以及大幅扩大 Group Convolution 中的 Group 大小， 这些调整都降低了原本模型的计算效率和参数效率。
地瓜机器人 X3-BPU、J3-BPU 对于 Depthwise Convolution 和 Group Convolution 都有专门的优化，使得用户可以获得最高的计算效率、参数效率。
作为这两类模型的参考示例，工具链 model_zoo 发布物中提供：
efficientnet[-lite]系列，追求极致的计算效率、参数效率。 X3-BPU 能够高效支持，以 EfficientNet Lite0 为例，X3-BPU 帧率为某端侧 30TOPS GPU 帧率 6 倍。
vargnet 系列，地瓜机器人自主设计模型，充分利用 Group Convolution 的高效率，同时针对 X3-BPU、J3-BPU 做了优化。 在地瓜机器人的应用场景中广泛使用。对于训练超参数相对鲁棒，能够以较低的调参代价切换到不同的任务。
更多的模型结构和业务模型都在持续探索中，我们将提供更加丰富的模型给您作为直接的参考， 这些产出已包含在 OE 发布包中，下载方式见 OE 发布包下载。 如果以上依然不能满足您的需要，欢迎在 地瓜机器人官方技术社区 发帖与我们取得联系， 我们将根据您的具体问题提供更具针对性的指导建议。