Skip to main content
许多边缘 AI 项目最初选择 NVIDIA Jetson 是有充分理由的：开发循环基于熟悉的 Linux、Python、PyTorch、CUDA、TensorRT、OpenCV 以及经常用到的 DeepStream。一个团队可以训练模型、导出它、用 TensorRT 优化它、将它接入摄像头流水线，并快速交付一个可工作的原型。 当同一个团队开始考虑 Qualcomm Dragonwing 硬件时，第一个问题通常是：
如果这里的”模型”指的是像 best.pt 这样的 PyTorch 检查点，答案基本上是肯定的。 好消息是：如果你已经有训练好的 PyTorch 模型，将它导出到一个干净的静态 ONNX 图，能让许多受支持的视觉模型在通往 Qualcomm 的道路上走完很大一部分。不是 100%，也不是每个算子都可以，但足以让迁移通常变成一个优化和产品化问题，而不是一个重新训练的问题。 最重要的区分是：
一个 TensorRT .engine 文件无法迁移到 Qualcomm。它已经是一个编译后的、NVIDIA 特定的部署工件，与 TensorRT、CUDA、JetPack 以及它所构建的 GPU 架构绑定。但该引擎背后的源模型仍然有价值。如果你有 .pt 或一个干净的 ONNX 导出，你并不是从零开始。 剩下的工作是让该模型在 Dragonwing 上变得快速、准确、可测量且可交付。 在本系列中，我们将围绕一个 Jetson 智能摄像头应用来展开，它带有一个自定义 YOLO 检测器、一个 TensorRT 引擎、CUDA/DeepStream 风格的预处理，以及一个可选的本地 LLM sidecar。目标平台首先是 Dragonwing IQ-9075，在设置或运行时不同的地方会点出 IQ-8275。 在开始迁移之前，先把无聊但重要的事实收集起来：

​
Jetson 的心智模型

一条常见的 Jetson 部署路径如下：
对于摄像头应用，周边的技术栈通常是这样的：
开发者体验以 TensorRT 和 CUDA 为中心。你可能会用 trtexec 来构建和基准测试：
如果 TensorRT 拒绝某个算子，你就重写图或写一个 TensorRT 插件。如果需要 INT8，就使用 TensorRT 校准。如果做剖析，就使用 trtexec、Nsight Systems、Nsight Compute、tegrastats 或 DeepStream 剖析。 这是一个连贯的世界。但它不是 Qualcomm 的世界。

​
Dragonwing 的心智模型

在 Dragonwing 上，高层路径不同，但第一步很熟悉：
那个 ONNX 导出就是桥梁。对于许多具有受支持算子的常规视觉模型，得到一个干净的静态 ONNX 模型意味着核心模型迁移基本已经解决。剩下的工作是部署工程：
Qualcomm 迁移通常不是”从零重新训练模型”。它是”把你已经训练好的模型转变成用于另一套加速器栈的生产工件”。

​
入门速度差距是真实存在的

不要把下面这些路径描述成等价的： Jetson 通常通过一条隐藏了更多硬件特定工作的框架/运行时路径，从”我找到了一个模型”到”推理运行起来”。当模型已经被 AI Hub、GenieX、LiteRT 或另一条已验证的运行时路径覆盖时，Qualcomm 可以提供同样快速的首次结果。差距出现在模型是自定义的时候：导出、量化、上下文生成、目标特定打包和不受支持算子的调试都是真正的门槛。 比起暗示”每个模型在 ONNX 导出后就基本解决了”，下面的实际区分更有用：
优化后的端点通常是 QAIRT/QNN 上下文二进制文件，而不是 TensorRT 引擎。 一个实际的 Qualcomm 模型生命周期如下：
Qualcomm 部署比常见的 TensorRT 工作流更偏向提前编译（ahead-of-time）。你为目标 SoC、SDK、BSP、后端和精度准备工件。

​
Jetson 与 Dragonwing 一览

简短版本：
命名说明：本系列使用 HTP/NPU 指代 Hexagon Tensor Processor 加速路径。某些工具通过 DSP 或 HTP 后端名称暴露该路径，例如 --backend dsp；GenieX 和产品资料可能称之为 NPU。

​
硬件目标很重要

最佳实践：不要把每个 Qualcomm 目标都视为可互换的。 命名说明：家族名称常写作 IQ-9/IQ-8，而设置页面和 AI Hub 设备名称通常使用 IQ-9075/IQ-8275 EVK。选择设备或文档时请使用 EVK 名称。 来自当前 Dragonwing 设备文档，注意这些是供应商公布的峰值能力而非实测结果（IQ-9075 EVK 设备概览 和 IQ-8275 EVK 设备概览）： 这会影响上下文二进制生成、运行时库、VTCM 设置、性能预期和验证。 例如，最佳实践是在迁移到另一个 SoC 时重建并重新验证上下文二进制文件。QAIRT SDK 更新、BSP 更新、新目标 SoC 或模型更新可能都需要同样的处理。 对于习惯把模型文件当成产品工件的团队来说，这是一个重大转变。

​
承诺之前：迁移适配性检查

在构建转换流水线之前先做这项检查： 如果这张表存在未知项，请把首个 Dragonwing 里程碑视为一次评估，而不是移植承诺。

​
迁移的起点只有一个问题：你有源模型吗？

在写新代码之前，先盘点你实际拥有的东西。 如果你有下面这些，你的情况就不错：
对于 PyTorch 模型，第一个有用的里程碑很无聊：
然后在做任何加速器特定的事情之前，先在 CPU 上验证该 ONNX。 模型周围的文件也很重要：
不能直接迁移的 Jetson 特定工件：
如果你只有 model.engine，迁移就会阻塞，直到你恢复源模型。TensorRT 引擎不是一种中立的模型交换格式。

​
在构建转换流水线之前先检查 AI Hub

最快的 Qualcomm 路径通常不是转换，而是复用。在投入自定义转换流水线之前，先检查是否有兼容的工件。 如果你的模型架构已经存在于 Qualcomm AI Hub 中，你或许可以下载一个预构建的工件，或者至少获得针对目标设备的预先测量的性能。 例如：
当前文档以 AI Hub IoT 模型目录为准，涵盖 LLM、VLM、视觉、音频、深度、恢复和机器人等领域的数百种模型变体。 如果存在兼容的工件，你可以跳过困难的部分：
那是通往一个可工作演示的最短路径。

​
运行时选择是一个产品决策

Dragonwing 提供不止一个执行目标：
当你需要正确性和调试时先使用 CPU。CPU 执行较慢，但它在你验证预处理、张量布局、输出解码和后处理时能去除加速器特定的变量。 当模型或应用受益于浮点加速、HTP 路径尚未就绪、或某个算子对 NPU 部署很别扭时，把 GPU 作为中间路径。请注意 GPU 使用可能会与显示或图形工作产生资源竞争。 当目标是高效的边缘推理时使用 HTP/NPU。这就是量化和目标特定工件最重要的地方。 避免像”Qualcomm 需要量化”这种笼统说法。更精确的措辞：
Qualcomm CPU 执行可以运行浮点模型。GPU 执行可能是有用的中间路径，具体取决于运行时和算子支持。为了获得最佳性能和支持，HTP/NPU 加速通常期望低精度工件，例如 INT8/a8w8 或相关受支持模式。

​
基准测试之前先验证

对损坏模型的基准测试就是噪声。 在收集延迟或吞吐量数字之前，先验证加速器：
然后对着正确的基线验证模型输出。对于迁移后的模型，基线通常应该是 ONNX Runtime FP32，而不是 TensorRT FP16。 为什么不用 TensorRT？因为 TensorRT 已经应用了 NVIDIA 特定的图变换、精度选择和插件行为。中立的比较点是源模型的导出。 一个好的验证链看起来像这样：
只有这样，你才应发布延迟、FPS、功耗或 tokens/sec。

​
四条迁移路线

本系列将迁移分解为四种常见情形。

​
1. 还没有模型

从 Qualcomm AI Hub 或参考模型开始。避免在还没有产品问题之前就制造出可移植性问题。

​
2. 现有的 CNN、检测器或分类器

恢复源模型、导出静态 ONNX、检查 AI Hub，然后仅在必要时进行转换/量化/构建。

​
3. LLM、VLM、音频或 VLA 工作负载

把它当作一个运行时编排问题，而不仅仅是模型转换问题。你现在需要关心提示格式化、prefill、decode、KV 缓存、内存、tokens/sec、TTFT、多模态拆分和量化敏感度。 Qualcomm 路径包括 llama.cpp HTP 和带 QAIRT 工件的 GenieX。

​
4. 完整的多媒体应用

一个智能摄像头不只是一个神经网络。它是一个从摄像头到推理到输出的流水线。DeepStream 和 CUDA 组件需要通过 IM SDK、GStreamer、QNN、显示、编码、叠加和跟踪等组件获得 Qualcomm 等价物。

​
下一步

在下一篇文章中，我们将完全避免自定义模型迁移，做最快的有用之事：让一个 IQ-9075 EVK 启动、验证 HTP，并运行一个已知良好的 LLM 和视觉模型。 在那之后，本系列将沿着运行中的智能摄像头迁移，走过 YOLO 模型重建、量化、GenAI/sidecar 选择、IM SDK/GStreamer 流水线迁移，以及从标准 Ubuntu 到使用 QLI 资源的客户自维护 Yocto 系统的可选过渡。