[参考译文] AM67A：模型编译问题

尊敬的 Zhanying Chen：

这看起来像是未设置 TIDL_TOOLS_PATH 环境变量、因为它只是识别 CPUExecutionProvider。  

在`s本示例`之前、您应该从 edgeai-gst-apps 存储库的根目录下运行开源 setup_env.sh 、以便 TIDL_TOOLS_PATH 设置为指向正确的 tidl_tools 目录。  

顺便说一下、它的最新 AM67A SDK 为 11.0、rel_11_01（与标签 11_01_07_00 相同）[1]要求您在使用编译的模型工件之前在 EVM 板上运行 update_target.sh 脚本。  

[1] https://github.com/TexasInstruments/edgeai-tidl-tools/tree/11_01_07_00 

非常感谢您的答复。 问题已解决。 根本原因是执行时、下载的 onnxruntime-tidl 包中缺少一些文件 source ./setup.sh。 重试下载和设置过程几次就解决了问题。

我当前使用的 edgeai-tidl-tools 版本是 rel_11_01_06_00。

此外,在编译 Deit Transformer 和 SWIN 模型时,我注意到 onnxrt_ep.py 或中没有特定于模型 model_configs.py的配置。 这是否意味着我需要从 Model Zoo 下载模型、并根据相应的 YAML 配置文件修改代码？

例如、我是否应该使用下载模型 swin_base_patch4_window7_224_simp.onnx.link、并将其放在 models/public/ 目录下、然后 model_configs.py 根据中提供的设置在中手动添加预处理和会话相关配置 swin_base_patch4_window7_224_simp_config.yaml？

是否有任何 TI 提供的并已针对这些模型进行了调整的参考实现、或者您会推荐的任何更详细的文档和参考材料？

非常感谢您的答复。 问题已解决。 根本原因是执行时、下载的 onnxruntime-tidl 包中缺少一些文件 source ./setup.sh。 重试下载和设置过程几次就解决了问题。

我当前使用的 edgeai-tidl-tools 版本是 rel_11_01_06_00。

此外,在编译 Deit Transformer 和 SWIN 模型时,我注意到 onnxrt_ep.py 或中没有特定于模型 model_configs.py的配置。 这是否意味着我需要从 Model Zoo 下载模型、并根据相应的 YAML 配置文件修改代码？

例如、我是否应该使用下载模型 swin_base_patch4_window7_224_simp.onnx.link、并将其放在 models/public/ 目录下、然后 model_configs.py 根据中提供的设置在中手动添加预处理和会话相关配置 swin_base_patch4_window7_224_simp_config.yaml？

是否有任何 TI 提供的并已针对这些模型进行了调整的参考实现、或者您会推荐的任何更详细的文档和参考材料？

您好：  
我在执行 int8 量化测试时遇到问题。 被测试的模型是 cl-ort-resnet18-v1。 我设置 debug_level=4、准确度_level=1、timization_scale_type = 0、并在编译模式下运行。 完成后、在 tmp 路径下、每层都有浮点跟踪、以及一个名为 tidl_trace_subgrap_0_0000_0001_0001_00003_00224x00224.y 的文件 这是正常的吗？ 生成工件后、我运行了 python3 onnxrt_ep.py -m cl-ort-resnet18-v1、所有层跟踪（包括 float.bin 和.y 文件）都是在 tmp 目录中生成的。 此时、有一个比.y 文件多的 float.bin 文件—具体而言、最后一层还有一个额外的 float.bin 文件。 这也是正常现象吗？

但是、我发现了一个更明显的问题。 运行 python3 onnxrt_ep.py -m cl-ort-resnet18-v1 后、tidl_trace_subgraph_0_0031_0001_0001_00001_00512_00001x00001_float.bin 文件将在 tmp 目录中生成。 使用 dtype=np.float32 读取数据时、我发现异常数据、最大绝对值为 1.1183523e+27。 因此、在比较每层的量化输出和浮点输出时、相关性非常差。 此外、使用 hexdump -C tidl_trace_subgraph_0_0031_0001_0001_00001_00512_00001x00001_float.bin | HEAD 会表明数据看起来不是正常的 float32 格式。 当我使用 dtype=np.float32 读取在编译模式下生成的 tidl_trace_subgraph_0_0031_0001_0001_00001_00512_00001x00001_float.bin 时、数据范围看起来是正常的。 您能解释一下原因吗？ 或者我的参数设置是否有问题？ 除了这个特定的文件,大多数其他的跟踪文件是相对正常的,相关性达到 1。

尊敬的 Zhanying Chen：

好的、我假设您的模型 没有 经过预先请求（否则，您需要相应地为 TIDL 设置输入设置[1]  

当使用 debug_level 4 运行时、它会为 TIDL 运行的每一层创建层跟踪。 Y 文件是定点值、_float.bin 文件是   这些.Y 文件的去量化版本。

这意味着两者之间的直接比较将产生令人困惑的结果、因为.bin 文件与.Y 相同的数据、只是通过重新缩放和应用偏置项而转换为 fp32。 比较跟踪应该使用来自不同量化设置的 float.bin 文件、或者对比直接在模型页面上转储中间输出。 在 CPU 上运行时。 请参阅 [2]。

此时、有一个比.y 文件多的 float.bin 文件—具体而言、最后一层还有一个 float.bin 文件。 这也是正常的吗？

是的、这是典型情况。 应该有额外的 float.bin 用于输入和输出张量、尤其是在 float32 中输出到网络的情况下（根据.ONNX 模型）。  

[quote userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6379146 通过 dtype=np.float32 读取数据时、我发现异常数据、最大绝对值为 1.1183523e+27。 因此、在比较每层的量化输出和浮点输出时、相关性非常差。 此外、使用 hexdump -C tidl_trace_subgraph_0_0031_0001_0001_00001_00512_00001x00001_float.bin | HEAD 会表明数据看起来不是正常的 float32 格式。 当我使用 dtype=np.float32 读取在编译模式下生成的 tidl_trace_subgraph_0_0031_0001_0001_00001_00512_00001x00001_float.bin 时、数据范围看起来是正常的。 [/报价]

高的最大值很奇怪、是的。 这意味着从.Y 定点迹线进行量化后、按极大的值缩放。 这看起来并不是典型的。 这是唯一发生的层吗？ 一些异常值可能不会对量化参数产生较大变化。  

另外、这是网络的最后一层、还是其他层的表现正常？ 以后各层的准确性是否会恢复？ 我还想知道第 31 层是什么层类型（例如，带熔合激活的卷积）

[1] https://github.com/TexasInstruments/edgeai-tidl-tools/blob/master/docs/model_compilation.md#quantization-specific-options --对于 ONNX 预先请求的、请参见  advanced_options:prequantized_model 

[2] https://github.com/TexasInstruments/edgeai-tidl-tools/blob/master/scripts/debug/layer_trace_inspector/README.md 

BR,
Reese

非常感谢您的答复。

我尝试了您在之前的回答中建议的方法、但我仍然看到相同的问题。

float.bin 跟踪文件的生成方式如下：

1. 设置 debug_level=4 和 tensor_bits=32。

2. 运行：

   python3 onnxrt_ep.py -c -m cl-ort-resnet18-v1
   

3. 然后运行：

   python3 onnxrt_ep.py -m cl-ort-resnet18-v1
   

4. float.bin 从 /tmp 目录复制生成的文件。

.y 跟踪文件的生成方式如下：

1. 设置 debug_level=4 和 tensor_bits=8。

2. 运行：

   python3 onnxrt_ep.py -c -m cl-ort-resnet18-v1
   

3. 然后运行：

   python3 onnxrt_ep.py -m cl-ort-resnet18-v1
   

4. .y 从 /tmp 目录复制生成的文件。

在比较相应迹线之间的相关性后、我发现只有第 31 层TIDL_PoolingLayer() 具有负相关系数。 对于所有其他层、相关系数约为 0.98 或更高。

特别奇怪的是、第 32 层是 a TIDL_ReshapeLayer、其相关系数约为 0.99。 由于第 32 层仅对第 31 层的输出执行整形操作、因此我期望它们的数据与张量形状相同。 但是、布线中的数据并不相同。

根据 subgraph_0_tidl_net.bin.svg,第 31 层和第 32 层使用相同的量化尺度,这似乎是合理的。

此时、最可能的解释是：

1. 错误读取第 31 层布线。

2. 第 31 层布线数据存储在与其他层不同的特殊布局或顺序中。

您能解释一下导致此行为的原因吗？

我还附上了 比较结果。  您能否查看并帮助分析问题？

任何见解都将非常感谢。

=========================================================================================================================
TIDL 层比较详细总结
=========================================================================================================================

总体统计数据
--------------------------------------------------------
已处理的总层数：33
平均相关性：0.956779
平均 SNR：16.92dB
平均绝对差值：0.106787
平均最大绝对差值：0.731458

最佳层（最高相关性）
--------------------------------------------------------
层 ID：1
层类型：TIDL_DataConvertLayer
相关性：0.999983
SNR：33.63dB
平均绝对差值：0.887097
最大绝对差值：2.000000

最差层（最大误差）
--------------------------------------------------------
层标识：31.
层类型：TIDL_PoolingLayer
相关性：–0.079204
SNR：–1.71dB
平均 ABS 差值：1.201779
最大 ABS 差值：6.981273

详细信息
=========================================================================================================================
ID 类型标度校正 SNR MeanDiff MaxDiff
----------------------------------------------------------------------------------------------------
1 TIDL_DataConvertLayer 1.0000 0.999983 33.6 0.887097 2.000000
2 TIDL_ConvolutionLayer 72.5102 0.997279 22.3 0.011974 0.113018
3 TIDL_PoolingLayer 72.5102 0.998211 24.0 0.012815 0.109948
4 TIDL_ConvolutionLayer 96.8083 0.994732 19.5 0.009364 0.073665
5 TIDL_ConvolutionLayer 31.3994 0.996618 21.6 0.023083 0.144577
6 TIDL_EltWiseLayer 31.3994 0.995041 19.6 0.027936 0.198592
7 TIDL_ConvolutionLayer 112.1579 0.987091 15.6 0.013332 0.162436
8 TIDL_ConvolutionLayer 26.7708 0.991234 17.4 0.042589 0.375309
9 TIDL_EltWiseLayer 53.5416 0.991059 17.4 0.043243 0.372609
10 TIDL_ConvolutionLayer 125.8642 0.990888 17.4 0.011744 0.205541
11 TIDL_ConvolutionLayer 38.6721 0.987486 16.0 0.024017 0.336742
12 TIDL_ConvolutionLayer 43.4524 0.990537 17.2 0.034056 0.482496
13 TIDL_EltWiseLayer 77.3441 0.986302 15.6 0.022858 0.426664
14 TIDL_ConvolutionLayer 124.3273 0.986506 15.7 0.008314 0.231640
15 TIDL_ConvolutionLayer 35.4379 0.989855 16.9 0.034745 0.4949441
16 TIDL_EltWiseLayer 35.4379 0.987521 16.0 0.024220 0.4949441
17 TIDL_ConvolutionLayer 150.3406 0.987814 16.1 0.012051 0.894124
18 TIDL_ConvolutionLayer 86.8233 0.993675 18.9 0.010532 0.167100
19 TIDL_ConvolutionLayer 33.3250 0.990988 17.4 0.034477 0.424768
20 TIDL_EltWiseLayer 66.6499 0.988109 16.2 0.016939 0.411054
21 TIDL_ConvolutionLayer 122.3459 0.986370 15.6 0.005592 0.200055
22 TIDL_ConvolutionLayer 31.5285 0.990145 16.9 0.030157 0.615458
23 TIDL_EltWiseLayer 63.0570 0.985977 15.5 0.017564 0.466482
24 TIDL_ConvolutionLayer 104.5296 0.980982 14.2 0.006974 0.222567
25 TIDL_ConvolutionLayer 63.1702 0.987106 15.9 0.031259 0.406923
26 TIDL_ConvolutionLayer 45.6950 0.985622 15.4 0.059418 0.466563
27 TIDL_EltWiseLayer 45.6950 0.978477 13.7 0.015119 0.558569
28 TIDL_ConvolutionLayer 155.8160 0.975288 13.0 0.006958 0.216080
29 TIDL_ConvolutionLayer 5.3386 0.983551 14.6 0.298886 1.991327
30 TIDL_EltWiseLayer 10.6773 0.983073 14.6 0.172177 2.074892
31 TIDL_PoolingLayer 21.3546 –0.079204 –1.7 1.2011779 6.981273
32 TIDL_ReshapeLayer 21.3546 0.991290 17.0 0.102834 0.620338
33 TIDL_InnerProductLayer 3.7321 0.994110 19.0 0.269856 1.197404

=========================================================================================================================
QUALITY ASSESSMENT
=========================================================================================================================
 好:INT8 模型可以很好地匹配浮子模型

相关性> 0.999：1 层
相关性> 0.99：15 层
相关性> 0.95：32 层
相关性< 0.90：1 层

尊敬的 Zhanying：

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6390200

.y 跟踪文件的生成方式如下：

1. 设置 debug_level=4 和 tensor_bits=8。

2. 运行：

   python3 onnxrt_ep.py -c -m cl-ort-resnet18-v1
   

3. 然后运行：

   python3 onnxrt_ep.py -m cl-ort-resnet18-v1
   

4. .y 从 /tmp 目录复制生成的文件

[/报价]

我会注意到、当 debug_level=4 时、.y 文件也会被量化到_float.bin 中、即使 tensor_bits=8 也是如此

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6390200

此时、最可能的解释是：

1. 错误读取第 31 层布线。

2. 第 31 层布线数据存储在与其他层不同的特殊布局或顺序中。

[/报价]

我认为这是前者,但让我跟进后端开发团队,以确认这一点。  

由于您在此处的输出相当准确、因此我认为第 31 层比较问题对于调试并不重要。  

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6390200 ]31 TIDL_PoolingLayer 21.3546 –0.079204 –1.7 1.201779 6.981273
32 TIDL_ReshapeLayer 21.3546 0.991290 17.0 0.102834 0.620338
33 TIDL_InnerProductLayer 3.7321 0.994110 19.0 0.269856 1.197404

如果有任何问题、我想说第 33 层可以用设置advanced_options:output_feature_16bit_names_list““和advanced_options:params_16bit_names_list““进行 16 位量化[1]

[1] github.com/.../model_compilation.md

感谢您的答复。

我当前使用的是 11_01_06_00 版本标签、我的调试工作基于 onnxrt_ep.py 脚本。

在您最近的建议中、大多数参考资料似乎都来自 master 分支、在这里、调试示例基于 basic_example.py 而不是 onnxrt_ep.py。

我想了解在将我的环境其余部分保持在 11_01_06_00 的同时使用 master 分支中的脚本是否安全。 具体来说：

1. 是否可以 在当前 11_01_06_00 环境中直接使用主分支的 basic_example.py 脚本？

2. 如果我这样做、它能否生成与 11_01_06_00 工具链或运行时不兼容的工件？

3. 我们的目标 SoC 是 AM67A、我们当前的所有编译和部署环境都基于 11_01_06_00。 为了调试精度和量化问题、您会建议使用以下哪些脚本： 11_01_06_00 的 onnxrt_ep.py 或 master 的 basic_example.py？

4. 与 11_01_06_00 版本相比、master 分支包含更多的调试文档和故障排除指南、因此在调查跟踪、量化和精度问题时、我应该遵循哪些材料？ 我是否应该只依赖对应于 11_01_06_00 的文档、或者主分支调试指南通常也适用于 11_01_06_00？

感谢您对基于 11_01_06_00 版本的 AM67A 工程建议调试工作流程的指导。

您好：

请继续阅读 11_01_06_00 分支中的示例。 他们对 11_02_xx 及以后的示例和文档进行了重大修改。 文档中的要点仍然存在、但确切的脚本有点不同（尤其是示例）。

大多数文档在 11_01_06_00 中仍然存在、但可能具有不同的页面名称或位于不同的目录中。 在我看来、较新的文档更具可读性。  

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6392076

• 是否可以 在当前 11_01_06_00 环境中直接使用主分支的 basic_example.py 脚本？

[/报价]

你可能可以,但没有保证这将有效. 我认为它应该会起作用

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6392076

• 如果我这样做、它能否生成与 11_01_06_00 工具链或运行时不兼容的工件？

[/报价]

只要将 TIDL_TOOLS_PATH 环境变量指向从 11_01_06_00 分支下载的一组 tidl_tools、它们生成的工件就会与 11.1 SDK 兼容

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6392076

• 我们的目标 SoC 是 AM67A、我们当前的所有编译和部署环境都基于 11_01_06_00。 为了调试精度和量化问题、您会建议使用以下哪些脚本： 11_01_06_00 的 onnxrt_ep.py 或 master 的 basic_example.py？

[/报价]

好的、这是一个要点。 AM67A 没有 11.1 SDK 版本。 该器件的最后一个 Edge AI Linux SDK 为 11.0、因此您应该使用 rel_11_0 的分支或使用向后兼容版本（最后一个版本为奇数，例如 11_01_07 并在 EVM 上使用相应的 update_target.sh） 。  

在此场景中、onnxrt_ep.py 在 11_01_07、11_01_06 和之前的版本中是相同的。 在您的情况下、我建议使用 onnxrt_ep.py。  

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6392076

1. 与 11_01_06_00 版本相比、master 分支包含更多的调试文档和故障排除指南、因此在调查跟踪、量化和精度问题时、我应该遵循哪些材料？ 我是否应该只依赖对应于 11_01_06_00 的文档、或者主分支调试指南通常也适用于 11_01_06_00？

[/报价]

较新版本中的调试指南也适用于 11_01_06。 唯一的区别是当调试指南指向其他脚本（通常是 Python 脚本）时、这些脚本可能只存在于存储库的较新版本中

版本控制和兼容性参考：  

• https://github.com/TexasInstruments/edgeai-tidl-tools/blob/11_02_07_00/docs/sdk_version_compatibility_table.md
• https://github.com/TexasInstruments/edgeai-tidl-tools/blob/11_02_07_00/scripts/setup/README.md#target-setup-scripts-overview 
• https://github.com/TexasInstruments/edgeai-tidl-tools/blob/11_01_07_00/docs/update_target.md 
  • 这在 AM67A 场景中是最正确的。 AM67A 使用 TISDK_image=“edgeai“

非常感谢您的答复。

我尝试使用 basic_example.py 主分支的脚本进行编译和推理,同时仍然使用 11_01_06_00 发行标签和运行时环境。

我比较：

1. 每一层都具有黄金输出和 TIDL 浮动输出。

2. TIDL 可为每层提供浮点输出和 TIDL 固定输出。

（第二宗个案的比较结果已在我上次的答复中提供。）

在这两项比较中、第 31 层（分组）的相关性均为最低、而几乎所有其他层的相关性约为 0.98。

由于这个问题始终在同一层被观察到,因此我想了解 cl-ort-resnet18-v1resnet18_opset9.onnx在 TIDL 编译或跟踪生成过程中是否有对 () 模型的特殊处理。

具体来说：

• 该层的跟踪输出是否可能与原始 ONNX 池层的输出不直接对应？

• 是否存在任何可能影响与第 31 层关联的迹线输出的层融合、优化、数据布局转换或其他内部处理？

• 后端是否可能错误地读取或生成跟踪数据、从而导致跟踪输出与实际图层输出不匹配？

• 跟踪数据是否可以映射到与预期不同的内部层？

由于此问题妨碍了我们的准确性分析、请您尽快帮助确认该问题。

希望就如何进一步调查这一问题提出任何建议。

尊敬的 Zhanying：

[引述 userid=“692944“ url=“~/support/dlp-products-group/dlp/f/dlp-products-forum/1651815/am67a-model-compilation-issue/6395280

• 每一层都具有黄金输出和 TIDL 浮动输出。

• TIDL 可为每层提供浮点输出和 TIDL 固定输出。

[/报价]

只是简单说明一下：如果运行模型 wtih debug_level=4、您将在/tmp 下获得.Y 文件和_float.bin 文件。 在本例中、_float.bin 文件与.Y 文件相同的数据、但它已被量化（转换为 fp32，乘以缩放器，如果量化设置用于非对称量化，则可选择添加一个偏置项）  。  

第一个项目符号是一个很好的比较、但第二个项目符号不是、因为您要将相同的数据与自身进行比较。 对于第 2 点、标准方法是编译 tensor_bits=32 的模型、运行模型以收集_float.bin 文件、然后使用 tensor_bits=8（或 16）重新编译、运行模型以收集已进行量化的_float.bin、最后对每层的这两组_float.bin 文件进行比较。  

我不确定您的关联数据是否来自要点 1 或要点 2 中的方法

---

 我记得以前在某些层（如池化层）看到过类似的行为。 我已经看到像数据成形层这样的层与 OSRT 模型中的原始浮点不直接关联（例如 ONNXRT）。 让我看看是否有任何解决办法来启用这种关联或更具体的解释。  

第 32 层具有非常高的相关性。 这样就消除了我对第 31 层相关性较差的担忧。  

我不认为不同的层是相关的（即层本身不匹配）。  更有可能与池层数据的表示方式有关

BR、
Reese