📚 课程目录第1章课程导入与平台全景

1. 课程导入与平台全景

在开始写第一行代码之前，我们需要先建立一张"地图"：这条开发链路上有哪些硬件、哪些软件、哪些工具，它们各自承担什么职责，数据从摄像头到推理结果又经过了哪些环节。只有把这张地图建立起来，后续的模型转换、量化、部署与调优才不会变成零散的命令堆砌。

为什么需要"边缘"AI视觉

传统视觉方案通常把摄像头采集的图像通过 Wi-Fi 或 4G 上传到云端，由服务器上的 GPU 完成推理，再把结果回传。这条链路在演示阶段很方便，但一旦进入真实产品就会暴露三个问题：时延（往返网络通常带来 100 ms 以上的额外延迟，对避障、机械臂抓取这类闭环控制不可接受）、带宽与成本（一路 1080p@30fps 的 H.264 码流约 2～4 Mbps，几十路摄像头就会让上行带宽和云服务器费用迅速膨胀）、隐私与可靠性（医疗影像、人脸、工业质检画面往往不允许离开本地，且断网即失效）。

边缘 AI 的思路是把推理下沉到设备端：图像在本地完成采集、预处理、推理和后处理，只把结构化结果（如目标类别、坐标、置信度）或异常帧上传。高通 Snapdragon 平台的价值正在于此——它把 CPU、GPU、DSP、ISP 和专用 NPU 集成在一颗 SoC 上，并共享统一的内存与电源管理，使得"低功耗 + 低时延 + 可离线"三者可以同时成立。

平台软硬件生态概览

从硬件看，Snapdragon 视觉平台的核心是 Hexagon NPU（神经网络处理单元），它与 Adreno GPU、Kryo CPU、Spectra ISP 共同构成异构计算单元。Spectra ISP 负责从 MIPI CSI 摄像头接收 RAW 数据并完成去马赛克、降噪、自动曝光；Hexagon NPU 承担卷积、矩阵乘等张量运算；Adreno GPU 适合做图像缩放、色彩空间转换等并行预处理；CPU 则负责调度、业务逻辑与后处理。这种分工意味着：并不是所有计算都该丢给 NPU，把预处理放在 GPU、把控制流放在 CPU，往往比全部塞进 NPU 更快。

从软件看，整条工具链可以概括为"训练在框架、转换在工具、运行在运行时"三层。训练阶段常用 PyTorch 或 TensorFlow；转换阶段使用 Qualcomm AI Engine Direct（QNN） 或 SNPE 把模型转为 DLC 格式，并通过 AIMET 工具做量化；运行阶段由 Qualcomm AI Runtime（QAIRT） 在设备上加载并调度到 NPU/GPU/CPU。开发板侧通常使用 Qualcomm Linux 或 Android，配合 GStreamer 完成摄像头取流。

典型应用场景

Snapdragon 边缘视觉平台覆盖的场景大致可以分为四类。第一类是智能安防与行为分析：在 IPC 或 NVR 上做人员检测、越界报警、安全帽识别，要求 7×24 小时稳定运行且功耗可控。第二类是工业质检：产线相机对零件做缺陷检测，节拍往往在 100 ms 以内，模型多为小目标检测或分割。第三类是零售与交互终端：自助结算的商品识别、客流统计、手势交互，强调多路视频并发与低延迟响应。第四类是机器人与无人机：视觉 SLAM、避障、目标跟踪，对时延和功耗极为敏感，通常需要 NPU 与 GPU 协同。

这些场景的共同点是：模型规模不大（多在 1～20 M 参数），但对帧率、时延、功耗有明确指标。例如一个典型的人形检测任务，目标可能是 1080p 输入、30 fps、单帧端到端延迟低于 50 ms、整机功耗低于 5 W。这些数字会直接决定后续量化策略和算子分配方式。

学习路径规划

本课程按"认知—环境—模型—部署—优化—落地"的顺序推进，建议按以下节奏学习：

第 1～4 章（认知与环境）：理解平台架构、异构计算分工，完成开发板、SDK、交叉编译环境的搭建，能跑通摄像头取流与一个预置模型。
第 5～12 章（模型与转换）：掌握从 PyTorch 导出 ONNX、再用 QNN 转为 DLC 的完整流程，理解算子支持列表与不支持的算子如何替换。
第 13～20 章（量化与部署）：使用 AIMET 做 PTQ 与 QAT，理解校准集选择、逐层敏感度分析、混合精度配置，并把量化模型部署到设备上验证精度损失。
第 21～26 章（性能优化）：分析 NPU/GPU/CPU 的负载分布，优化预处理流水线，使用零拷贝、多线程与批处理提升吞吐。
第 27～30 章（工程落地）：完成一个端到端视觉应用，包含模型热更新、异常恢复、日志与功耗监控。

建议在每章结束后，把当章的配置、命令和观察到的指标记录到一份自己的"部署日志"中。边缘部署的很多问题（如量化后精度骤降、算子回退到 CPU 导致帧率腰斩）都依赖对比历史数据才能快速定位。

一个可参考的起步示例

为了让你对"输入—处理—输出"有具体感受，这里给出一个最小可运行的取流与推理骨架（示例参数，非实测结果）。假设使用 1080p USB 摄像头，模型输入为 640×640，量化类型为 INT8：

# 1. 查看摄像头节点与支持格式
v4l2-ctl --list-devices
v4l2-ctl -d /dev/video0 --list-formats-ext

# 2. GStreamer 取流并缩放到模型输入尺寸
gst-launch-1.0 v4l2src device=/dev/video0 ! \
  video/x-raw,width=1920,height=1080,framerate=30/1 ! \
  videoscale ! video/x-raw,width=640,height=640 ! \
  videoconvert ! appsink

# 3. 使用 QAIRT 加载 DLC 模型（示意）
qnn-net-run --model yolov8n_int8.dlc \
  --input_list input_list.txt \
  --backend libQnnHtp.so \
  --output_dir ./out

运行后应重点观察三项：帧率（是否接近 30 fps）、单帧推理耗时（NPU 上 640×640 INT8 模型通常在 10～30 ms 量级，具体取决于芯片型号）、输出张量形状（是否与后处理代码预期一致）。如果帧率明显偏低，优先检查是否有算子回退到 CPU，可通过 QAIRT 的 profiling 日志查看每个算子的执行单元。

不同 Snapdragon 型号的 NPU 算力、支持的算子集和 QAIRT 版本存在差异。拿到开发板后，第一步应确认芯片型号与 SDK 版本匹配，再选择对应的 DLC 转换配置，否则容易出现模型加载失败或推理结果异常。

建立这张全景地图之后，后续每一章都会在这张图上"点亮"一个具体环节。你现在需要记住的核心是：数据从摄像头进入 ISP，经预处理后由 QAIRT 调度到 NPU/GPU/CPU 执行，结果再回到应用层。理解这条链路，是后面所有优化工作的前提。