2. 边缘计算与NPU基础
多路视频NPU部署的第一性问题，不是“模型怎么调”，而是“算力从哪里来、以什么形态存在、如何被调度”。边缘计算与NPU基础，决定了后续所有部署策略的上限与边界。本章从边缘计算的本质出发，拆解NPU的硬件架构特点，并对Jetson、RK3588、算能三条主流技术路线做横向对比，为后续的算力分配与吞吐优化建立决策坐标系。
2.1 边缘计算的核心概念与部署边界
边缘计算并非简单地把服务器搬到现场，而是一种分布式计算范式：数据在靠近数据源头的网络边缘侧完成采集、处理、推理与决策。在视频场景中，边缘节点通常部署在摄像头附近、园区机房或车载终端，承担视频解码、预处理、AI推理、结构化输出等任务。与云计算相比，边缘计算的核心价值在于三点：低时延（端到端延迟可控制在20ms以内）、带宽节省（只上传结构化数据而非原始码流）、数据主权（敏感视频不出本地网络）。
从系统架构看，边缘视频部署通常采用“摄像头 → 边缘节点 → 云端”的三级链路。边缘节点内部又分为“接入层 → 解码层 → 推理层 → 输出层”四个逻辑模块。接入层负责RTSP/GB28181等协议取流；解码层使用硬件解码器将H.264/H.265码流转为YUV/RGB帧；推理层将帧送入NPU执行模型计算；输出层将检测/识别结果封装为JSON或MQTT消息上行。理解这条链路是后续算力分配的基础——NPU只是其中一环，但往往是最容易成为瓶颈的一环。
2.2 NPU架构核心特点与性能影响因素
NPU（Neural Processing Unit）是专为神经网络推理设计的加速器，其架构与CPU/GPU有本质区别。理解NPU架构，需要抓住五个关键维度：MAC阵列规模、片上存储层次、数据通路带宽、指令调度方式、精度支持范围。
MAC阵列是NPU的计算核心，由大量乘加单元组成。以INT8精度为例，一个MAC每秒可完成一次8位乘加操作。Jetson Orin的NPU包含多个深度学习加速器（DLA），每个DLA内部有大量MAC并行工作。MAC阵列的规模直接决定峰值算力，但峰值算力只有在数据持续供给时才能发挥。
片上存储层次决定了数据搬运的效率。NPU通常包含大容量SRAM作为中间缓冲区，用于存放激活值、权重和中间结果。若SRAM容量不足，NPU需要频繁访问外部DRAM，导致实际吞吐量大幅下降。例如，RK3588的NPU配备较大片上缓冲，但若模型权重超过SRAM容量，则需频繁换入换出，推理速度可能下降40%以上。
数据通路带宽是另一个关键瓶颈。NPU与内存之间的总线带宽决定了每秒能搬运多少数据。以1080p@30fps视频帧为例，单帧YUV420数据约3MB，若NPU每秒处理30帧，则仅输入数据就需要90MB/s的带宽，再加上权重和中间结果，总带宽需求可能超过500MB/s。实际部署中，DMA（直接内存访问）的调度效率往往比峰值带宽更重要。
指令调度方式影响多路视频的并发能力。部分NPU支持多核并行，但核间同步和任务分配需要软件显式管理。例如，算能BM1684X支持多核流水线，但需要开发者手动将多路视频分配到不同核心，否则会出现负载不均。Jetson的DLA则支持硬件自动调度，但灵活性稍差。
精度支持决定了模型量化的空间。主流边缘NPU均支持INT8量化，部分支持FP16/BF16。INT8可将吞吐量提升2-4倍，但需要做好量化校准，避免精度损失。实际项目中，建议优先使用INT8部署，同时保留FP16备用方案。
| 架构维度 | 对多路视频部署的影响 | 优化方向 |
|---|---|---|
| MAC阵列规模 | 决定峰值算力上限 | 选择与模型复杂度匹配的算力档位 |
| 片上SRAM容量 | 影响权重驻留率与数据搬运次数 | 优先使用小模型或模型裁剪 |
| 内存总线带宽 | 制约实际帧率与并发路数 | 使用NV12直接输入，避免RGB转换 |
| 指令调度方式 | 影响多路任务并发效率 | 合理划分任务分组，避免核间竞争 |
| 精度支持 | 决定量化后吞吐与精度平衡 | 使用INT8+量化感知训练 |
2.3 主流边缘设备对比：Jetson、RK3588、算能
当前多路视频NPU部署最常用的三条技术路线分别是NVIDIA Jetson系列、瑞芯微RK3588、算能（Sophgo）系列。三者各有侧重，选择的关键在于项目约束条件：生态成熟度、单位算力成本、功耗限制、工具链易用性。
NVIDIA Jetson（以Orin NX 16GB为例）提供约100 TOPS INT8算力，支持CUDA生态，可直接运行TensorRT优化后的模型。其优势在于生态完善——几乎所有主流模型都有现成的TensorRT引擎或ONNX转换方案，且支持动态shape和多路视频流并行。缺点是价格较高，且功耗相对较大（15W-40W）。适合对开发效率要求高、预算充足、需要快速落地的项目。
瑞芯微RK3588内置6 TOPS NPU，支持INT8/INT16，搭配RKNN工具链。其优势在于性价比极高，且芯片集成8核CPU、Mali GPU和强大的ISP，适合做轻量级多路视频分析（如4-8路1080p）。RKNN工具链对YOLO系列、PP系列等常见模型支持良好，但算子覆盖不如CUDA全面。适合成本敏感、场景相对固定的项目。
算能SM系列（如BM1684X）提供32 TOPS INT8算力，采用TPU架构，支持TPU-MLIR编译器。其优势在于对Transformer类模型和CV模型均有较好支持，且支持多芯片级联扩展。工具链相对年轻，但文档和社区正在快速完善。适合需要更高算力、且愿意投入时间适配工具链的团队。
| 对比维度 | Jetson Orin NX | RK3588 | 算能BM1684X |
|---|---|---|---|
| NPU算力 | 100 TOPS (INT8) | 6 TOPS (INT8) | 32 TOPS (INT8) |
| CPU | 8核A78AE | 8核A76+A55 | 8核A53 |
| 内存带宽 | 102.4 GB/s | 51.2 GB/s | 64 GB/s |
| 工具链 | TensorRT, CUDA | RKNN-Toolkit2 | TPU-MLIR |
| 典型功耗 | 15W-40W | 5W-15W | 15W-25W |
| 参考价格 | 高 | 低 | 中 |
| 多路视频能力 | 16路1080p@30fps | 8路1080p@30fps | 12路1080p@30fps |
2.4 实战场景：8路视频结构化项目的设备选型与验证
某园区安防项目需对8路1080p@25fps摄像头进行实时人车结构化分析，检测模型为YOLOv5s（输入640×640），识别模型为轻量级ReID。项目约束：设备部署在室外机柜，功耗不超过25W，预算单台不超过5000元，要求端到端延迟低于200ms。
初步筛选：RK3588算力6 TOPS，理论上可支持8路，但需验证实际吞吐。Jetson Orin NX性能充足但超预算。算能BM1684X算力32 TOPS，价格适中，但工具链适配需评估。
实测验证过程：
- 在RK3588上使用RKNN-Toolkit2将YOLOv5s转换为RKNN格式，INT8量化后模型大小约8MB。
- 编写多线程推理程序，每路视频独立线程，使用NPU异步接口提交任务。
- 实测8路并发时，NPU利用率约85%，但CPU后处理（NMS+跟踪）占用过高，导致整体帧率降至20fps。
- 优化方案：将NMS操作迁移到NPU的CPU核上并行处理，并使用硬件解码器直接输出NV12格式，避免颜色空间转换。
- 优化后8路均达到25fps，端到端延迟约120ms，功耗18W，满足要求。
结果对比：RK3588在优化后完全满足需求，成本仅为Jetson方案的1/3。但若后续需升级为YOLOv7或增加更多路数，则需重新评估算力余量。
2.5 常见误区与选型复盘
误区一：TOPS越高越好。TOPS是峰值算力，实际吞吐受限于存储带宽和调度效率。例如，某设备标称34 TOPS，但实际运行YOLOv5s仅能达到40fps，而另一设备标称26 TOPS却能达到55fps，原因在于后者片上缓存更大、DMA调度更高效。
误区二：只关注NPU，忽略CPU后处理。多路视频场景中，NMS、目标跟踪、结构化逻辑通常运行在CPU上。若CPU性能不足，即使NPU空闲，整体帧率也会被拖累。建议选择CPU核数较多、主频较高的设备，或将后处理任务分散到多个CPU核。
误区三：忽视工具链算子支持。部分NPU对某些算子（如动态尺寸Resize、特定激活函数）支持不佳，导致模型转换失败或推理速度骤降。选型前应使用目标模型做一次完整的工具链验证，而非仅看官方支持的模型列表。
误区四：未考虑多路并发时的内存竞争。多路视频同时推理时，内存带宽成为共享资源。若每路视频都分配独立缓冲区，总内存占用可能超出设备物理内存，导致系统换页。建议使用内存池复用机制，并限制每路视频的帧队列深度。