相关文章推荐
joint 模型基本信息:
  • 模型输入 tensor DType 默认为 UINT8 , Layout NHWC .

  • 模型输出 tensor DType 默认为 FLOAT32 , Layout NCHW .

  • ColorSpace : 默认为 TENSOR_COLOR_SPACE_AUTO , 可以根据模型输入 channel 数自动识别
    • 3-channel: BGR

    • 1-channel: GRAY

    • 其他可选: RGB , NV12 , NV21 , BGR0

    • 如果需要换 VNPU 设定, 需要重新编译, 而不能通过已有的 joint 直接更换 VNPU 设定

      想要做到直接通过 joint 模型来修改 vnpu 设定在技术上无法实现, 原因在于:

    • 工具链在编译时需要根据输入的配置信息进行模型编译, 而编译是把最初的模型逐步变成二进制指令代码, 需要模型的很多原始信息

    • 编译又是不断 lowering 的过程, 会丢失信息, 编译后的二进制指令代码, 无法复原出最开始的模型信息

    • 除此之外, 不同 vnpu 配置下会使用不同的硬件资源, 编译出的最优二进制模型不同

    • 综上, 如果需要修改 vnpu 的模式, 需要重新进行转换.

      检测模型在转换过程中出现 OutOfMemory(OOM) 错误, 如何解决

      检测模型如果输出 layout NCHW 的话, 会出现 OOM 错误, 这是 因为 NPU 默认输出 layout NHWC , 而检测模型输出的 featuremap 较大, 直接 transpose 时容易挤爆内存. 因此检测模型转换时需要指定输出 layout :

      pulsar build --input xxx.onnx --config xxx.prototxt --output xxx.joint --output_tensor_layout nhwc
      pulsar build  --config  --output_config 有什么区别
      

      --config 是用户友好的 prototxt , 提供了多种简化配置的语法糖

      --output_config 会展开所有语法糖, 并保存成工具链友好的配置文件

      现阶段 pulsar run 仿真功能需要使用 --output_config 生成的配置文件

      pulsar_conf { batch_size_option: BSO_DYNAMIC # 编译后的模型支持动态 batch batch_size: 1 # 实际推理时常用 batch_size batch_size: 2 # 实际推理时常用 batch_size batch_size: 4 # 最大 batch_size 为 4

      更详细的介绍可以参考 pulsar_conf.

      dataset_output_type 默认是 BGR, 是否指使用数据集里的图片校正时使用的是 BGR 格式输入到模型. 如果是的话 config.prototxt 里的 mean std 是不是也要按照 BGR 顺序设置

      是需要按照顺序配置的. dataset_output_type 值是 BGR 代表编译时是按照 BGR 格式来读取的校正图片数据, 从而 mean/std 也要按 BGR 顺序设置

      Q 值不还是要接 CPU 做除法, 没有省时间啊

      是要接 CPU , 但 /Q 操作可以跟其他操作耦合起来, 大部分情况都是几乎免费的

      比如检测后处理步骤 NMS 后需要做除法, 则 分母*Q 即可

      检测网络单独做大 tensor 乘法, 可能需要 NPU 数倍时间, NMS 后计算量小

    • 该文件夹下包含一个或多个 part_x.lava 文件夹(其中 x 代表编号, 从 0 开始),

    • 每一个 part_x.lava 文件夹下均包含一个 inference_report.log 文件,

    • 对于小模型来讲通常只有一个 part_0.lava 文件夹以及一个 inference_report.log,

    • 而当模型过大时, 会拆成多个子模型按顺序执行, 这样就会出现多个 part_0.lava 文件夹.

    • 这种情况下, 这个模型的 tot_cyc 是这些单个子模型的 tot_cyc 之和, 与 DDR 交互传输的数据量 total_io_data_size 是这些单个子模型的 total_io_data_size 之和.

      # 模型较小, 仅包含 part_0.lava 文件夹  DEMO cd inference_report
      ➜  inference_report tree -L 2
      └── part_0.lava
          ├── inference_report.log
          ├── subgraph_0
          ├── subgraph_1
          ├── subgraph_2
          ├── subgraph_3
          ├── subgraph_4
          └── subgraph_5
      7 directories, 1 file
      

      查看 inference_report.log , 示例如下:

      inference_report.log 中包含一些自定义术语, 以下对部分术语进行 名词解释

    • ld, 即从 DDR 读, 往 OCM

    • st, 从 OCM 读, 往 DDR

    • mv, 从 OCM 读, 往 OCM

    • 通过一个典型的示例说明 inference_report.log 的作用, 如以下 case:

      在非虚拟 NPU 条件下, 如图(上图蓝框)所示, 有三类 EU 参与了模型推理, 分别为 conv-2coresteng 以及 stream, 而表格统计了 cycle 占比, 物理意义为每类 EU 实际运行的 cycle 除以模型推理实际花费的总 cycle. 该 ratio 可直观反应 EU 的繁忙程度, 例如图中 tengratio 达到了 98%, 几乎已经在满负荷工作.

      tengstream 具备在 DDR 上进行数据读写的能力. 在图的 profile stream EU 中详细统计了各类任务所占的比重, 可观察 ld_ratio/ld_param_ratio/st_ratio (上图红框) 的数值, 反应了对应 EU 进行 DDR 读写任务的时间及占比, 进而可分析 DDR 带宽压力.

      一般而言, 下述条件可以反应模型在给定 DDR_BW 情况下的速度瓶颈:

    • teng/streamratio 占比较高, 且明显高于其他 EUratio

    • teng/stream 中的 ld_ratio/ld_param_ratio/st_ratio 占比较高

    • 反之, 下述条件可以反应模型的速度瓶颈为计算能力:

    • convratio 占比较高, 且明显高于其他 EUratio

    • 更具体点说, 图中模型 tengratio98%, 显著高于 conv39.0%; 而 teng 中的 DDR 读写任务的时间占比为 87.1% + 0.4% = 87.5%, 占了该 EU 的主要工作时间, 因此认为该模型的速度瓶颈为 DDR 带宽。

      对于虚拟 NPU111 来讲, 其中只有两个 EU, 分别为 conv-1core/teng, 统计方式与非虚拟 NPU 一样.

 
推荐文章