esp32s3平台287k参数量的dstcn模型，推理做不到实时 (AIS-2062)

[yushanyong]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

希望能指明方向：基于什么样的技术路线集成自定义的唤醒模型到esp32s3上

Actual behavior (suspected bug)

项目需要在esp32s3上跑自定义的唤醒模型，当前是基于dstcn来实现的，尝试了两版模型：
V1:
参数：287k (num_layers: 4, kernel_size: 8, hidden_dim: 256)
特征: mfcc, dim: 40, width: 25, shift: 10
V2:
参数：59k (num_layers: 3, kernel_size: 6, hidden_dim: 128)
特征: mfcc, dim: 40, width: 25, shift: 15

最开始尝试int8量化（基于esp-ppq），V1每帧推理耗时44ms左右，V2每帧推理耗时8.5ms左右，V1模型完全不可以，V2可以达到实时，但是59k参数量+int8量化，模型实际效果接近不可用。所以这里第一个问题是：int8量化我尝试很多配置、校准数据和不同模块的量化策略，最终量化误差都很大（V1,V2都是），以至于不可用，所以量化这步是否有什么问题。（脚本、模型和数据在附件）
后又尝试int16量化，误差可接受，但每帧推理耗时相对增加了30%左右，同时调整V2模型的shift到15ms，勉强可以实时，但是V2模型的参数量卓识有些小，效果很难调。但是我看esp-sr中的WN9模型的.data也将近有300k呢，并且模型的实时性和效果都不错，所有第二个问题是：esp-sr跟esp-dl相比是否做了一些硬件适配的推理加速（因为看到有esp-nn）？esp-dl是否也可以支持推理加速？还是说我的模型选型有问题，咱们WN9又是怎么样的模型和怎样的参数量呢

以上是自定义唤醒模型的遇到的瓶颈，希望能予以解答和指明方向。
感谢！

quant_source.zip

Error logs or terminal output

Steps to reproduce the behavior

.

Project release version

master分支

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Linux

Operating system version

esp32s3

Shell

ZSH

Additional context

No response

[BlueSkyB]

你这个问题，和这个251一样。

1.首先，第一个量化的问题，模型的前面两层算子是sub和mul，如果是默认的conservative方法，你esp-ppq导出模型时，会出现问题。你用allin时，量化误差又大，量化误差大是因为前面两层的sub和mul，之前都是float运算，现在变为量化算子了，并且sub这种算子又有量化对齐的概念，所以必不可免可能会引发误差变大。

可以考虑将前面的 sub, mul 两个算子，从onnx文件中去除，自己用float实现一下。

2.第二个问题，对于音频模型，你可以用流式方法来部署，可以参考如何部署流式模型。原理就是减少喂入的input shape，另外，一个onnx直接部署，觉得慢的话，可以像示例中一样，综合评判各部分时间，等分的将模型拆分成两部分或者三部分。以第一帧延缓输出的代价来达到实时的要求。

esp-dl实现对于常用的算子就是使用了汇编指令加速了，当然你自己现实的float是没有加速的，但对于采用了流式，应该影响较少。

[BlueSkyB]

另外，我们不仅可以将整个模型按16bit量化，也支持模型中8bit，16bit混合量化，可以将模型中的某些算子指定为16bit量化。
方法在mobilenetv2示例中有用混合精度量化，指定需16bit量化的算子名称。

[yushanyong]

你这个问题，和这个251一样。

1.首先，第一个量化的问题，模型的前面两层算子是sub和mul，如果是默认的conservative方法，你esp-ppq导出模型时，会出现问题。你用allin时，量化误差又大，量化误差大是因为前面两层的sub和mul，之前都是float运算，现在变为量化算子了，并且sub这种算子又有量化对齐的概念，所以必不可免可能会引发误差变大。

可以考虑将前面的 sub, mul 两个算子，从onnx文件中去除，自己用float实现一下。

2.第二个问题，对于音频模型，你可以用流式方法来部署，可以参考如何部署流式模型。原理就是减少喂入的input shape，另外，一个onnx直接部署，觉得慢的话，可以像示例中一样，综合评判各部分时间，等分的将模型拆分成两部分或者三部分。以第一帧延缓输出的代价来达到实时的要求。

esp-dl实现对于常用的算子就是使用了汇编指令加速了，当然你自己现实的float是没有加速的，但对于采用了流式，应该影响较少。

@BlueSkyB 所以我理解对于拆分模型的方式来说，理论上只要我拆分的足够细，即便是再大的模型也可以实现实时对吧，只是第一帧的延迟会增加。那么对于V1(287k) 甚至更大一些的模型也可以了？

对于拆分有什么好的建议吗，每层都导出一个onnx？

[BlueSkyB]

你这个问题，和这个251一样。
1.首先，第一个量化的问题，模型的前面两层算子是sub和mul，如果是默认的conservative方法，你esp-ppq导出模型时，会出现问题。你用allin时，量化误差又大，量化误差大是因为前面两层的sub和mul，之前都是float运算，现在变为量化算子了，并且sub这种算子又有量化对齐的概念，所以必不可免可能会引发误差变大。

可以考虑将前面的 sub, mul 两个算子，从onnx文件中去除，自己用float实现一下。

2.第二个问题，对于音频模型，你可以用流式方法来部署，可以参考如何部署流式模型。原理就是减少喂入的input shape，另外，一个onnx直接部署，觉得慢的话，可以像示例中一样，综合评判各部分时间，等分的将模型拆分成两部分或者三部分。以第一帧延缓输出的代价来达到实时的要求。
esp-dl实现对于常用的算子就是使用了汇编指令加速了，当然你自己现实的float是没有加速的，但对于采用了流式，应该影响较少。

@BlueSkyB 所以我理解对于拆分模型的方式来说，理论上只要我拆分的足够细，即便是再大的模型也可以实现实时对吧，只是第一帧的延迟会增加。那么对于V1(287k) 甚至更大一些的模型也可以了？

对于拆分有什么好的建议吗，每层都导出一个onnx？

是的，你拆分的越多，那输出的有效帧，相对于输入，延时会更大。拆分为几部分，取决于你的模型，以及项目对实时性和输出延时的平衡考量，没有什么黄金标准。
拆分就是每个部分导出一个onnx，可以看看说明文档以及示例，示例中将大模型拆成三个小模型，会有三个onnx生成。

[yushanyong]

好的，我研究一下，感谢

[yushanyong]

@BlueSkyB 您好，对于拆分模型来部署的方案我还是有一些疑问想请教一下
当前我的部署方式是一个onnx模型（287k参数量），每次处理一帧数据（[1,1,40], 特征维度40，已经是最小单元），耗时44ms左右。
假如拆分成3个模型，每次处理一帧数据，顺序过3个模型，理论上耗时应该是大于44ms的啊，我看部署代码的实现也是时间步同步的：

    for (int i = 0; i < TIME_SERIES_LENGTH; i++) {
        one_step_input_tensor->set_element_ptr(const_cast<int8_t *>(&test_inputs[i][0]));
        // Because the first layer of model_0 in the example is conv, so the time series dimension is 1.
        input_tensor->push(one_step_input_tensor, 1);

        if (i < (input_tensor->get_shape()[1] - 1)) {
            // The data is populated to facilitate accuracy testing, as this step is omitted in actual deployment.
            continue;
        } else {
            switch (step_index) {
            case 1:
                output = (*p_model_0)(input_tensor);
                step_index++;
                break;
            case 2:
                output = (*p_model_1)(output);
                step_index++;
                break;
            case 3:
                output = (*p_model_2)(output);
                dl::tool::copy_memory(output_buffer + (i / 3 - 1) * STREAMING_WINDOW_SIZE * TEST_INPUT_CHANNELS,
                                      output->data,
                                      STREAMING_WINDOW_SIZE * TEST_INPUT_CHANNELS);
                step_index = 1;
                break;
            default:
                break;
            }
        }
    }

所以还是没太理解，单个大模型做不到实时，拆分后实现实时的方案。还是说每个子模型需要异步处理，烦请再指导一下，谢谢

[yushanyong]

@BlueSkyB 大佬可是加个微信吗，想深入请教一下^V^，yy601222543

[BlueSkyB]

微信我们不太方便使用，用微信回复更不及时。
你的输入是一帧数据？特征维度是40？那确实用不了流式，之前我以为你模型的时间序列维度是40。如果时间序列维度是40，你模型分成三部分的话，时间序列维度就可以降为3。

回到你的模型，如果是全int8量化的话，我刚才跑了下，只需要21+ms。
可以参照在247 issue中回答的下面部分内容，检查下：

2.If your model is loaded in rodata mode ​​and​​ param_copy is disabled, the inference time will increase. This is explicitly mentioned in the documentation if you review it carefully Load model from rodata

3.For models with ​​16-bit quantization​​, the inference time will be ​​twice as long​​ compared to 8-bit quantization.

4.For ​​custom projects​​, please verify the following configurations in sdkconfig, you can compare and check the configurations in ​​sdkconfig.defaults.esp32s3​​:
PSRAM frequency
PSRAM bus width
CPU frequency
Data cache size
Data cache line size
Instruction cache size

[yushanyong]

@BlueSkyB 对，我的输入是[1,1,40] （batch-size, time-dim, feat-dim， time-dim是动态的其实）,帧移10ms，每次推理一帧，我又对比了一下int16和int8模型的推理耗时，int16需要50+ms，int8需要20+ms，但是int8还是误差太大，基本不可用，而且20+ms也还是不能够实时；配置相关我看了一下，好像都没啥大问题。具体的一些日志和配置在附件里，还能有什么办法呢

287k模型_int8量化_误差太大不可用.txt
287k模型_int16量化_误差可接受.txt
sdkconfig.txt

[BlueSkyB]

其它的，没太多好办法了。
你的帧移确实有点小，我们sr wakenet的帧移要比你大。
尝试下调整模型结果呢？我看251的模型和你一样，但他把模型缩小了四倍。

[yushanyong]

这个维度的压缩我也试过，效果差一些。感谢回复，我再研究研究。
我在issue 之前也提了一个请求，可以帮忙跑一个吗，万分感谢
@BlueSkyB

[sun-xiangyu]

串台了，目前唤醒词训练比较忙，有空会帮忙训练

[fanlu]

@BlueSkyB @sun-xiangyu sr-wakenet里面的三阶段step1 step2 step3是以什么为依据去切开的呢，另外这三个step是串行还是并行，如果是并行的话需要怎么设计呢？

[BlueSkyB]

文档中有提及，拆分根据模型结构自由决定，没有固定范式。
对于最终模型的输出结果来说，模型运行依旧是串行的。只不过每一帧的时间节点，只运行模型的其中一个step模块。以此来减少每帧的计算时间，能及时接收实时数据。
你可以拆成三部分，也可以拆成四部分或者更多，取决于拆分是否能满足实时喂入数据，以及与延时要求的平衡，拆分的越多，那就能更及时接收数据，但输出的有效结果延时就越大。如果拆成三部分，那在第三帧时，才能获得模型处理的最终结果。

@BlueSkyB @sun-xiangyu sr-wakenet里面的三阶段step1 step2 step3是以什么为依据去切开的呢，另外这三个step是串行还是并行，如果是并行的话需要怎么设计呢？