假设你的模型工件现在在 Qualcomm Dragonwing 上运行。这是必要的,但它很少就是整个产品。 大多数 Jetson 边缘 AI 产品是围绕模型包装的应用:
移植流水线,而不仅仅是神经网络。在贯穿的案例研究中,这里就是 YOLO 上下文二进制文件不再是独立模型工件、而成为实时摄像头、元数据、叠加、编码和健康监控应用一部分的地方。 在开始之前:
为什么仅模型移植不够
一个模型可以通过每个张量级验证关口,仍然在产品内部失败。 常见原因:DeepStream 到 IM SDK 的映射
一份实用映射看起来是这样的:
这不是每个属性的一对一替换。这是一份起始地图,让团队能够识别哪些代码消失、哪些配置移动、哪些行为需要新的验证检查。当前 IM SDK 示例使用
qticamsrc;旧示例可能显示 qtiqmmfsrc。在复制流水线之前,请在你的镜像上运行 gst-inspect-1.0。
先从文件开始,然后再到摄像头
最便宜的路径是首先去除实时摄像头的可变性。 在 Jetson 和 Qualcomm 上使用同一个输入视频:一条最小 Qualcomm 摄像头 AI 流水线
一条用于实时摄像头检测器的简化 IM SDK 风格流水线如下。它遵循当前 IM SDK 目标检测示例,但确切属性是模型和版本特定的;请在你的镜像上用gst-inspect-1.0 qticamsrc qtiqmmfsrc qtimlqnn qtimlpostprocess 验证它们。在本系列使用的 IQ-9075 实验室镜像上,qtiqmmfsrc 存在而 qticamsrc 不存在,因此请把源元素视为镜像相关的:
保持预处理无聊
大多数迁移 bug 隐藏在预处理中。 对于每个模型,在模型侧配置文件中记录这些字段:把后处理视为应用代码
对于 YOLO 类模型,把 NMS 保持在图外通常是最简单的迁移路径。 后处理通常包括:元数据取代胶水代码
DeepStream 应用常常依赖附加到缓冲区的元数据。IM SDK 有相同的宽泛想法:推理产生张量,后处理把张量转换为元数据或掩码,下游元素使用该元数据进行跟踪、叠加、流传输或下一阶段推理。 一种常见模式:多流是 Qualcomm 可以大放异彩的地方
Jetson 应用常常依赖一个 GPU 完成推理、CUDA 预处理、显示和编码。Qualcomm Dragonwing 设备有更异构的流水线:摄像头 ISP、HTP/NPU、Adreno GPU、视频编解码、CPU 和 DSP 资源可以各承担不同的部分。 这不会让性能自动发生。它给你更多的放置选择。 对于多流产品,测量:部署包
只包含模型的包对真实多媒体应用来说太小了。把契约打包在模型周围:验证清单
在称应用已迁移之前,让这些检查变得无聊:gst-launch-1.0 命令。生产版本应仍保持相同的流水线形态,只是有更好的配置、日志、服务管理和更新行为。

