边缘计算

前言：为什么同一个模型在不同 NPU 上差距很大？ 做嵌入式 AI 部署时，很多人第一次拿到 NPU 板卡都会有一个误解：只要芯片宣传页写着 1TOPS、6TOPS 或 10TOPS，模型就应该按照这个数字线性变快。实际项目里经常不是这样。同样一个 YOLO、MobileNet 或语音关键词模型，在 A 芯片上跑得很顺，在 B 芯片上却卡在某几个算子；同样是 INT8 量化，有的模型精度几乎不掉，有的模型会出现明显误检；同样是官方转换工具，有的网络一键通过，有的网络需要反复改 ONNX 图、替换算子、拆分子图。 这些问题并不神秘，本质上是 NPU 的计算阵列、片上 SRAM、DMA、数据布局、编译器和运行时之间存在非常强的耦合。CPU 代码慢了，我们通常先看热点函数；GPU 程序慢了，会看 kernel occupancy、显存访问和线程块；NPU 部署慢了，也要有类似的分析框架：先判断瓶颈是算力、带宽、算子支持、量化误差，还是 CPU/NPU 之间的调度开销。 本文从工程视角拆解嵌入式 NPU 的典型架构，并围绕一个真实部署流程展开：模型导出、图优化、量化校准、算子映射、内存规划、运行时流水线和性能排查。文章不绑定某一家芯片，但会覆盖 RK、Amlogic、Kendryte、寒武纪边缘模块以及很多 MCU 级 NPU 都会遇到的共性问题。读完后，你应该能判断一个模型为什么没有跑满 NPU，也能知道该从哪里下手优化。 一、先把 TOPS 的含义说清楚 TOPS 是每秒万亿次操作数，通常用于描述 INT8 乘加能力。例如一个 2TOPS 的 NPU，理论上每秒可以完成 2 万亿次 8 bit 整数运算。问题在于，这个数字往往是理想条件下的峰值：输入输出都在合适的数据布局中，算子可以完全映射到矩阵乘阵列，片上缓存命中率足够高，DMA 搬运没有拖后腿，调度器没有频繁切换任务。 在实际模型里，真正能高效利用 NPU 的通常是卷积、深度卷积、全连接、矩阵乘、部分池化和激活函数。很多看起来不起眼的操作，例如 Reshape、Transpose、Slice、Gather、Resize、NonMaxSuppression，如果不能被 NPU 原生支持，就可能回退到 CPU。一次 CPU 回退不仅带来计算时间，还可能带来缓存同步、数据格式转换和内存拷贝。模型中只要有几个这样的“断点”，端到端延迟就会明显变差。 评估 NPU 时，比 TOPS 更有价值的是下面几个指标： ...

前言 在深度学习从学术研究走向工业落地的今天，推理性能已经成为决定项目成败的关键因素。 你可能有过这样的经历：花了几个月时间精心训练了一个准确率 99% 的模型，结果一到生产环境就傻眼了——单帧推理需要 500ms，离业务要求的 30ms 差了十万八千里。这时候你面临两个选择：要么花几十万升级硬件，要么想办法把模型跑快一点。 TensorRT 就是帮你实现第二个选择的神器。作为 NVIDIA 推出的深度学习推理优化器，它能让同样的模型在同样的硬件上跑出 4 到 20 倍的性能提升，而且精度损失可以控制在 1% 以内。更重要的是，这种提升是「免费」的——不需要改变网络结构，不需要重新训练，只需要多一道「编译」工序。 这篇文章是我过去三年使用 TensorRT 的经验总结。从最基础的环境搭建，到 ONNX 模型转换，再到 INT8 量化校准，最后到生产级的 C++ 部署，我会把每一个坑、每一个优化技巧都毫无保留地分享给你。如果你正在做模型部署，或者正在为推理速度发愁，这篇文章就是为你准备的。 一、为什么我们需要 TensorRT？ 在深入技术细节之前，我们先来回答一个最基本的问题：既然 PyTorch 和 TensorFlow 本身就能跑推理，为什么还要折腾 TensorRT？ 1.1 训练框架的设计目标不是推理 PyTorch 和 TensorFlow 作为训练框架，它们的设计优先级是： 灵活性 - 支持任意计算图的动态构建 易用性 - Python 接口、自动微分 通用性 - 支持从 CPU 到多 GPU 的各种硬件 推理性能从来都不是它们的首要设计目标。为了灵活性，PyTorch 每次执行都要重新遍历计算图，每一个算子都要走通用的 CUDA kernel，这中间浪费了大量的性能。 举个例子：一个简单的 Conv + BatchNorm + ReLU 组合，在 PyTorch 里会执行三次独立的 kernel 调用，每次都要读写全局显存。而 TensorRT 会把这三层融合成一个 kernel，中间结果全部存在寄存器里——光这一项就能带来 2-3 倍的性能提升。 ...

前言 2026 年，AI 算力正在经历一场深刻的范式转移。 当所有人都在追捧千亿参数大模型的时候，另一股更接地气的力量正在悄然壮大——边缘 AI。根据 IDC 的预测，到 2027 年，超过 50% 的数据处理将在边缘侧完成，而不是集中在云端数据中心。 这股趋势在计算机视觉领域表现得尤为明显。安防摄像头、工业检测设备、智能驾驶辅助系统、服务机器人……这些场景对目标检测算法不仅要求**低延迟、高可靠性、隐私安全，而这些恰恰是云端推理无法满足的痛点： 延迟问题：云端推理往返延迟通常在 100ms 以上，无法满足实时检测需求 带宽成本：4K 视频流每秒 10Mbps，24 小时上传是 100GB 以上 隐私安全：敏感场景不允许视频流离开设备 断网运行：工业场景必须支持离线工作 于是，如何在算力有限的边缘芯片上跑起 YOLO，就成了嵌入式 AI 工程师的核心课题。 YOLOv8 作为 Ultralytics 推出的新一代检测模型，在精度和速度上达到了新的平衡，但默认导出的 PyTorch 模型在边缘设备上根本跑不起来——300+MB 的显存占用、100ms+ 的推理时间，完全无法满足产品级要求。 本文将带你从零开始，完整走完 YOLOv8 从训练好的 .pt 模型到边缘设备部署的全过程：ONNX 导出、NCNN 转换、INT8 量化、NEON 优化，最终在树莓派 5 上达到 25 FPS 的实时检测速度。 ![YOLOv8 边缘设备部署流程 一、为什么边缘 AI 是未来？ 1.1 云计算的天花板 很多初学者常常有一个常见的误区：“既然云端算力这么强，为什么不直接把视频传到云端做检测？ 我在某智能安防项目踩过这个坑。一开始方案很简单：摄像头 RTSP 流拉流 → FFmpeg 编码 → HTTP 上传 → 云端 GPU 推理 → 结果返回。 ...

前言 在 AI 技术快速落地的今天，边缘计算正成为一个不可忽视的重要方向。与云端推理相比，边缘计算具有延迟低、隐私性好、带宽占用少等天然优势。然而，要在嵌入式设备上实现实时 AI 推理，仅仅依靠通用 CPU 的算力是远远不够的。一张 4K 分辨率的图像包含超过 800 万像素，即使是最简单的颜色空间转换操作，如果全部由 CPU 完成，也需要耗费数十毫秒，这对于要求 30fps 以上的实时应用来说是无法接受的。 瑞芯微的 RK3588 芯片正是为了解决这一问题而设计的旗舰级边缘计算平台。它不仅集成了 8 核 ARM CPU 和 Mali-G610 GPU，更重要的是内置了专门的 AI 加速单元——6TOPS 算力的 NPU（神经网络处理器）以及 RGA（2D 图形加速引擎）。这两个硬件加速单元是 RK3588 能够实现实时 AI 视频分析的核心所在。 然而在实际开发中，许多开发者并没有充分发挥这些硬件加速能力。最常见的问题是用 CPU 做图像预处理然后送 NPU 推理，或者在各硬件单元之间进行了不必要的内存拷贝。这些做法不仅浪费了宝贵的硬件资源，还可能导致整个系统的性能下降 5-10 倍。 本文将从底层原理出发，深入解析 RK3588 的 RGA 2D 加速引擎和 NPU 神经网络加速器的工作机制，结合大量可运行的代码示例，带你掌握边缘计算平台的性能优化技巧。我们会详细讲解如何构建零拷贝的数据流水线，实现 VPU-RGA-NPU 的全硬件加速，最终达到 4K 视频下 30fps 以上的 AI 分析能力。 一、为什么边缘计算需要硬件加速？ 在深入讲解 RGA 和 NPU 之前，我们首先需要理解为什么在边缘计算场景下硬件加速是必不可少的。 让我们来看一个典型的 AI 视频分析应用的处理流程： ...