Qualcomm® AI Engine Direct 使用手册（8）-Toy模板网

这篇具有很好参考价值的文章主要介绍了Qualcomm® AI Engine Direct 使用手册（8）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

4.1.2 HTP - QNN 上下文二进制大小

QNN 上下文二进制大小

QNN 使用 QNN 上下文二进制来执行神经网络。图形准备后，“QNN 上下文” 二进制”包含信息和为了更快地推理模型而进行的优化。 “QNN 上下文二进制”具有与 QNN 模型的尺寸相比，尺寸更大。尺寸增大的原因如下：

操作数：HTP 尝试并行运行尽可能多的操作。为了能够融入 VTCM，将繁重的操作拆分为较小的操作。这通常会导致数量增加上下文二进制中需要存在的操作，导致其大小增加。例如，如果每个操作占用 40 个字节的 Context Binary 以及上述优化前后的操作数量是 30 和 300,000，那么我们在 Context Binary 中分别需要 1.2 KB 和 12 MB。下图展示了一个大需要将转换操作分解为更小的操作。
排序和数据分页：随着操作数量的增加，Context Binary 还必须需要存储有关操作顺序的信息以及有关数据分页的信息（需要进行哪些操作）写入 DDR 并需要在执行期间带回 VTCM）。这些信息也有助于到准备好的上下文二进制文件的大小。
图中的常量数据：QNN 上下文二进制包含图的所有常量数据。恒定数据其中包括卷积滤波器。这些过滤器可以填充到 QNN 上下文二进制文件中表示内部 HTP 格式以提高性能效率，导致 QNN 上下文的大小额外增加二进制。

Op写作指南
本节作为用户为可运行的图形开发自定义操作的指南 HTP 后端。它还包括一些示例，可以帮助用户熟悉 HTP 核心软件的不同方面。

QNN HTP Op 包 - 常见默认包操作使用示例
QNN HTP 优化实用函数使用示例
Op 封装的 HTP 核心接头
实施行动
QNN HTP Op Package API 修订历史
优化语法
QNN HTP Op 包 - Relu Op 示例
QNN HTP-FP16 Op 封装 - Relu Op 示例
调度与分配
为暂存缓冲区分配内存
张量和内存布局
编写 QNN HTP Op 包
一般 OpPackage 中心迁移指南
Op 包迁移指南

网络设计建议

HTP 支持 A8、A16 和 FP16 激活。一般来说，精度以及功率和能量要求遵循：订单 A8 < A16＜ FP16。因此，为了最大限度地降低功耗，应首先尝试 A8 模式并检查结果的准确性。如果精度不够，请尝试 A16 模式，如果仍无法达到所需的精度，请转至 FP16 模式。

以下部分介绍了图形设计中的一些最佳实践，可实现 HTP 硬件的最佳使用从性能和准确性的角度来看。

性能和能源指南
避免低深度激活
避免低深度激活（更多示例）
尽可能使用空间到深度变换
降低 TCM 对性能和功能的要求
激活函数的选择
通道数
量化 16 位激活 (A16) 与 FP16 和激活融合：性能和功耗差异
避免首先将 PyTorch 模型转换为 onnx
权重的 INT4 编码
其他性能和能源指南
准确性指南
权重的对称量化
建议在量化模型时始终使用权重的对称量化以获得基于 HTP 的目标的最佳精度。建议激活数据不对称。

量化意识训练
建议尽可能使用量化感知训练以提高准确性特别是在高分辨率图像转换模型的情况下。使用量化感知训练可以消除使用 16 位激活的需要，并且可以允许使用 8 位激活，这将提高性能和功耗。使用量化感知训练时，请记住以下几点：

对原始浮点模型和具有 fakequant 节点的模型之间的原始框架中的输出进行比较有助于确定量化感知训练模型的质量
确保所有层/内核都有 fakequant 节点

UINT16 激活 & INT16 权重/滤波器
A16W16（int16 权重以及 uint16 激活）支持多种卷积类型的操作。这通常用于图像增强网络，但也可用于其他类型的用例。

此功能仅在选定的 SoC 上启用。为了进一步提高精度，未来将添加每通道量化方法。

A16W16机型与A16W8、FP16机型对比预期如下：

通过训练后量化，A16W16 模型预计将比 A16W8 模型获得更好的精度。
A16W16 模型预计将比 FP16 模型实现更好的功效，同时保持相似的精度结果。

A16W16 支持的卷积类型运算列表：

转换2d
深度Conv2d
转置Conv2D
完全连接
马特穆尔
批归一化
层规范

所有权重/滤波器都需要对称量化。对于Matmul，输入A必须是非对称量化的，输入B必须是对称量化的。详情请参阅HTP后端操作定义补充。

限制：由于 Hexagon 硬件限制，INT16 权重有一个特殊限制，即权重值的范围为 0x8000 到 0x7F7F，而不是完整的 16 位范围 0x8000 到 0x7FFF。使用 A16W16 时，请添加到量化器选项。–restrict_quantization_steps “-0x8000 0x7F7F”

让步和先发制人
Yielding 和 Pre-Emption 是一种基于用户的合作实现上下文切换。以下文档旨在帮助用户理解不同的并发场景及其预期行为。

HTP产量

VTCM分享
从hexagon-v73开始，同一进程中的其他线程可以共享VTCM资源使用 QNN HTP，使用以下页面中描述的过程：

VTCM分享

子系统重启 (SSR)
QNN HTP BE 特定功能，允许 CDSP 子系统自动重新启动无效连接崩溃后。详细信息见下页：

QNN HTP SSR

Qmem 图（仅共享缓冲区图）
QNN HTP BE 特定功能，允许用户使用数据缓冲区进行共享访问 QNN HTP 后端处理域。使用共享缓冲区可以消除数据在主机 CPU 和 HTP 加速器上的客户端代码之间进行复制。

QNN HTP Qmem 图

HTP 会话和神器使用指南

QNN 每个进程仅支持一组库。这些库必须具有相同的 SDK 版本并且有匹配的 Hexagon 架构版本。出于说明目的，V73 Hexagon 架构图表中将使用库；同样的准则也适用于非 V73 工件。这下面显示了 QNN 支持的库布局。
int 16 a8w8 a16w16,Qualcomm,笔记,AI,人工智能,Qualcomm,ai
为了防止不正确的 QNN 库布局，Qualcomm 建议采取以下措施：

对于单个进程（后端、存根、skel 等），应提供每个库的一份副本。
后端库 (libQnnHtp.so) 应使用 dlopen 显式加载，而不是作为依赖项动态链接。
库应该彼此位于同一目录中（只要正确设置 ADSP_LIBRARY_PATH 来查找库，skel 就是一个例外）。
不要重命名库以加载多个副本，因为这是不受支持的。

QNN 不支持在单个访问中访问 QNN 后端库 (libQnnHtp.so) 的多个副本过程。下面描述了两种不同的布局，其中设备上存在多个后端库。

int 16 a8w8 a16w16,Qualcomm,笔记,AI,人工智能,Qualcomm,ai

对于要加载的两个后端库，可以从某个库显式加载该库的第二个副本与第一个库所在的目录不同的目录，或者在期间创建了重复的文件系统进程执行（对于 android 目标，adb remount）。无论哪种情况，上面显示的两个工件布局不支持。如果在运行时检测到这些布局，则会出现 QNN_COMMON_ERROR_LOADING_BINARIES 从以下 API 返回：

QnnBackend_registerOpPackage
QnnBackend_validateOpConfig
QnnContext_create
QnnDevice_create
QnnGraph_create

批量推理和多线程推理的好处
多线程隐藏了 CPU/HTP 通信时间 (RPC) 的成本。在单线程推理中，HTP 硬件的利用效率不高，如下例所示。
int 16 a8w8 a16w16,Qualcomm,笔记,AI,人工智能,Qualcomm,ai
将此与多线程推理进行比较。这里，第一次推理的 RPC 使用的时间被掩盖了在第二个线程中进行推理。因此，HTP 硬件花费的空闲时间更少。同样，使用多重推论每批次提高了权重内存的重用，从而避免重新加载权重。这里需要注意的是激活大小是影响使用批次效益的一个因素。