模型部署

前言：为什么同一个模型在不同 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 更有价值的是下面几个指标：...

前言 在边缘设备上部署深度学习模型，一直是嵌入式 AI 领域最具挑战性的课题之一。当你训练好了一个准确率令人满意的 PyTorch 模型，满心欢喜地想把它搬到 ARM 开发板上跑一跑，却发现原始模型推理一次需要好几秒，这样的性能在实际产品中根本无法使用。这时你才意识到，训练和部署之间，隔着一道看不见却异常宽阔的鸿沟。 这道鸿沟的两边是完全不同的世界：训练端追求的是灵活的算子支持、便捷的调试接口、高效的分布式训练；而部署端追求的却是极致的推理速度、最小的内存占用、最低的功耗开销。大多数框架都是为训练设计的，即使像 PyTorch 这样优秀的框架，其 C++ 前端 LibTorch 在嵌入式设备上的表现也往往差强人意。 于是我们需要专门的推理框架。在众多推理框架中，腾讯开源的 NCNN 是一个相当特别的存在。它从诞生之初就是为移动端和嵌入式设备设计的，没有历史包袱，从内存管理到算子实现都围绕 ARM 架构深度优化。更重要的是，NCNN 是纯 C++ 实现，没有任何第三方依赖，这意味着你可以轻松将它集成到各种奇葩的嵌入式环境中。 我第一次接触 NCNN 是在一块瑞芯微 RK3399 开发板上部署目标检测模型。当时用 PyTorch 推理一帧 YOLO 需要约 800ms，用 TensorFlow Lite 也需要 400ms 左右，而用 NCNN 优化后，同样的模型在同一硬件上只需要 120ms，这还没开启 Vulkan GPU 加速。那一刻我真切感受到，一个好的推理框架带来的性能提升，往往比换一颗芯片还要显著。 这篇文章会带你完整走一遍 NCNN 的部署流程：从模型训练完成后的 ONNX 导出，到 onnx2ncnn 转换，再到模型优化、INT8 量化、最后编写 C++ 推理代码。文中所有命令和代码都经过实际验证，你可以照着一步步操作。 一、为什么选择 NCNN？ 在深入具体操作之前，我们先聊聊为什么在众多推理框架中选择 NCNN，它的核心优势在哪里，又有哪些局限性。 1.1 推理框架的选型维度 选择一个推理框架，通常需要考虑以下几个维度： 维度 说明 重要程度 性能 同样硬件上的推理速度 ⭐⭐⭐⭐⭐ 模型支持 能否正常转换你的模型 ⭐⭐⭐⭐⭐ 易用性 文档是否完善，社区是否活跃 ⭐⭐⭐⭐ 跨平台 支持多少种目标硬件 ⭐⭐⭐⭐ 二进制体积 对资源紧张的 MCU 很重要 ⭐⭐⭐ 许可证 是否允许商业闭源使用 ⭐⭐⭐⭐ 用这个维度表来评估 NCNN，你会发现它在大多数项上得分都很高：性能在 ARM CPU 上属于第一梯队，模型支持覆盖了绝大多数常见算子，Apache 2....

前言 在深度学习从学术研究走向工业落地的今天，推理性能已经成为决定项目成败的关键因素。 你可能有过这样的经历：花了几个月时间精心训练了一个准确率 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 倍的性能提升。...