RK3588 NPU部署YOLO11：FP16与INT8量化实战对比

咱们直接进入正题。最近几年边缘端AI部署越来越卷，算法端从YOLOv5一路卷到YOLOv8，再到现在的YOLO11，模型结构不断迭代，算力和精度之间的平衡成了落地最头疼的问题。而硬件端，瑞芯微的RK3588凭借6 TOPS算力的内置NPU，成了中高端边缘计算设备里绕不开的一颗明星芯片。我这段时间一直在折腾RK3588上的目标检测部署，正好把YOLO11模型从PyTorch转到RKNN格式，并系统对比了FP16和INT8两种精度模式在NPU上的表现。这篇就把整个实验过程、量化原理、数据对比和踩过的坑完整记录下来，给后面要用RK3588跑YOLO系列模型的朋友一份可以直接参考的作业。

先交代一下这个项目到底在做什么。简单说，就是把YOLO11模型部署到RK3588的NPU上，通过RKNN-Toolkit2工具链完成模型转换，对比FP16浮点推理和INT8定点量化推理在检测精度、端到端耗时、内存占用上的差异。适合手里有RK3588开发板（香橙派5系列、瑞芯微官方EVB、各类工控机）且需要在本地跑目标检测的算法工程师、嵌入式工程师和学生。这篇文章覆盖从环境搭建、模型导出、RKNN转换、量化校准到板端推理的全流程，不是那种只给结论不教过程的文章。

1. 为什么是RK3588 NPU，以及为什么要抠精度模式

1.1 算力、内存带宽与部署形态的三角关系

RK3588是一颗八核SoC，4个Cortex-A76大核加4个Cortex-A55小核，但真正让它在边缘AI圈子里站稳脚跟的，是集成的那个NPU，标称6 TOPS算力。这个数字看着不大，对比桌面显卡动辄上百TOPS确实有差距，但在7W到15W的功耗墙内，这个算力水平已经能支持比较流畅的实时检测任务。不过，有个地方很容易被刚接触RK3588的朋友忽略：NPU的峰值算力只是理论值，实际能发挥多少，和内存带宽、DDR频率、模型访存特性有极大关系。

RK3588的内存带宽通常是LPDDR4X或者LPDDR5，位宽64-bit，实际带宽大概在20GB/s到40GB/s的量级。模型大到一定程度，计算单元，也就是MAC阵列，就会开始等数据。这时候的瓶颈不在算力，而在访存。我在实验里遇到过一个现象：小模型用FP16和INT8跑出来的耗时差距没有理论值那么大，就是因为数据搬运的开销占了很大比例。这个底层逻辑贯穿整篇实验，后面分析数据的时候会反复提到。

1.2 FP16和INT8到底差在哪里

FP16和INT8是NPU部署里最常见的两种数据精度。FP16叫半精度浮点，用16个bit表示一个数，其中1位符号位、5位指数位、10位尾数位。INT8用8个bit表示整数，范围是-128到127。这里最关键的区别不在表示范围，而在精度粒度。FP16能表示的最小间隔比INT8小很多，所以浮点模型转成FP16几乎不掉点，而转成INT8就会面临量化误差的问题。

RK3588的NPU实际上原生支持INT4、INT8、INT16和FP16这几种精度，官方宣传里特别强调了混合量化能力。也就是说，同一张计算图里，不同的层可以用不同的精度去跑。这个特性非常实用，因为不是所有层都对量化敏感，比如大量的卷积操作对INT8很友好，但某些激活函数或者特殊算子如果强行量化成INT8，精度损失会非常大。

INT8需要考虑的核心问题是量化策略。RKNN-Toolkit2默认采用的是训练后量化（PTQ），也就是模型训练完之后，给一批代表性的校准数据喂进模型，统计每一层的激活值分布，然后算出合适的scale和zero_point。这个过程不需要重新训练，成本极低，但前提是校准数据要选好，最好覆盖真实场景的分布。如果校准集和实际部署场景差异太大，量化出来的模型在真实数据上很可能翻车。

1.3 实验硬件与软件栈选型

这次实验用的硬件是瑞芯微官方的RK3588 EVB板（8GB LPDDR4X版本），操作系统为Ubuntu 22.04，内核自带RKNPU驱动。系统镜像是官方提供的Linux SDK编译出来的，包含了rknpu2运行时库librknnrt.so。软件开发套件用的是rknn-toolkit2 2.0.0-beta0版本，配套rknn-toolkit-lite2在板端做推理。YOLO11模型来自Ultralytics官方仓库，用的YOLO11s规格。

选YOLO11s而不是更大的版本，有两点考虑。一是YOLO11s在COCO上的mAP约39.5，体积适中，参数量约9.4M，GFLOPs约21.5，比较接近真实工业场景的常见规模。二是YOLO11n虽然更快，但精度损失在量化后会被放大，对FP16和INT8的差异分析不够视觉化。YOLO11m以上的规格在RK3588上FP16推断延迟可能超过150ms，不适合当作实时检测的比较基准。

软件环境方面，重点关注的是RKNN-Toolkit2的版本。目前瑞芯微的更新节奏比较快，不同版本之间API差别不小。我这次用的版本是基于Python 3.8环境，宿主机是x86 Ubuntu 20.04，用Docker方式跑的，避免了Python版本冲突问题。训练和导出YOLO11模型的PyTorch版本是2.1.0，Ultralytics版本是8.3.x。

2. 核心算法原理与量化实验设计

2.1 YOLO11网络结构对NPU部署的影响分析

YOLO11是Ultralytics在YOLOv8基础上的又一次迭代。整体结构延续了CSPDarknet的风格，Backbone部分采用了C3k2模块替代了之前的C2f模块，Neck部分维持了PAN-FPN结构，Head部分还是Decoupled Head，也就是解耦头设计，分类和回归分别走不同的卷积分支。这些改动对检测精度有帮助，但部署层面有几个点需要特别关注，直接关系到NPU能不能跑得顺。

第一个点是SiLU激活函数。YOLO11大量使用SiLU，也就是Swish函数。这个东西在GPU上非常快，因为GPU有专门的计算单元处理这类非线性激活。但RK3588的NPU对SiLU这类的复杂激活支持并不好，某些版本的RKNN编译器会把SiLU拆成sigmoid和乘法组合，增加额外的算子调度开销。实际转换的时候，我建议直接检查生成的RKNN计算图，看看SiLU是否被原生支持还是被拆分了。

第二个点是上采样方式。YOLO11的Neck里有上采样操作，默认用的是最近邻插值。这个算子对NPU来说是比较边缘的支持对象，虽然RKNN编译器能处理，但效率往往不如CPU上的优化实现。实测下来，如果整个模型的瓶颈在上采样层，NPU的利用率先打折扣，耗时反而比混合部署CPU更差。这个情况在做INT8优化时尤其明显，需要单独考虑算子的异构分配。

第三个点是检测头。YOLO11的Decoupled Head输出三个尺度的检测结果，每个尺度分别有分类和回归两个分支。这个设计对提高小物体检测效果有帮助，但也意味着输出张量数量更多，后处理复杂度更高。NPU主要负责网络推理，这部分输出的是原始张量数据，最终还是得靠CPU做NMS。所以端到端延迟不仅看NPU推理时间，还要算上输出拷贝和NMS的时间。

2.2 RKNN量化原理：从FP32到FP16和INT8

在说量化实验之前，先把RKNN的量化机制讲清楚。浮点模型转成INT8，核心是找一个缩放因子scale和一个零点zero_point，使得浮点数值范围能映射到[-128, 127]的整数范围内。YOLO11的权重基本都在[-1, 1]之间分布，激活值则取决于中间特征图的数值范围。

RKNN-Toolkit2在PTQ流程里会对每一层的卷积权重和每一层的激活输出做范围统计。权重量化相对简单，因为推理时权重是静态的，只需要读取一遍权重文件统计min和max。激活量化复杂，因为激活值依赖输入数据的分布，所以需要喂一批校准图片，跑一遍前向过程，然后对每个中间Tensor做统计。

校准数据数量的选择是个典型的工程权衡。太少，比如只放10张图，中间激活的极值可能没被完全覆盖，量化范围过窄，溢出概率增大。太多，比如放了500张图，校准时间拉长，而且会引入很多极端case，导致量化范围过宽，整体精度反而下降。我测试下来，100到200张有代表性的图片是一个比较稳妥的选择，后面实验里就固定用200张VOC类自然图像做校准集。

FP16转换相对简单，因为FP16的动态范围能覆盖FP32的大部分情况，原则上只需要做一次直接类型转换，不需要额外的校准流程。RKNN-Toolkit2里指定optimization_level和target_platform之后，传给RKNN的模型会自动以FP16或者INT8的方式编译和存储，具体走哪条路径主要是通过set_quant_config和config里的量化配置来控制。

这里有个非常重要的细节：不是说选了INT8量化，整张图就全部是INT8。RKNN-Toolkit2有一个量化策略评估机制，会根据每层对精度的影响自动决定哪些层保持FP16计算。这也就是所谓的混合精度量化。你可以通过量化配置文件里指定自定义量化层，也可以让编译器自动决策。自动决策模式下，最终生成的模型里部分层还是FP16，NPU会同时处理两种精度的数据。

2.3 评估指标与实验控制变量

这个实验最核心的对比维度有三个：检测精度、推理速度、模型体积。检测精度用COCO mAP50和mAP50-95来评估，这是目标检测领域通用标准，也方便横向参考。推理速度分两个层面看，一个是纯NPU推理时间，即从输入图像送入model推理到拿到原始输出的耗时，另一个是端到端延迟，包含图像预处理、NPU推理、输出后处理（NMS）的完整流程。

为了保证结果可复现，所有测试都固定了输入分辨率640×640，单batch推理。数据方面，从COCO val2017里随机抽了2000张图，保证每张图在同一个尺度下做预处理。摄像头实测的场景单独拿出来作为补充测试，不走COCO评估流程。这部分的耗时不纳入精度评估，只看延迟和稳定性。

控制变量主要在软件版本和线程设置上。NPU推理部分设置了单线程执行，避免多线程调度带来的不确定性。CPU侧的后处理用OpenMP并行，线程数固定为4。图像预处理统一用OpenCV的resize加letterbox方案，生成的letterbox参数直接传给后处理做坐标还原，省掉了一部分重复计算。

3. 实操过程：从PyTorch到RKNN的完整落地流程

3.1 环境搭建与依赖安装

整个部署链路分宿主机和板端两部分。宿主机上跑的是RKNN-Toolkit2，负责模型转换、量化和仿真测试，x86环境下跑这个工具效率更高，因为涉及PyTorch模型加载和前向传播仿真。板端跑的是RKNN-Toolkit-Lite2，也就是只做推理的轻量级运行时库。

宿主机环境我这边是Ubuntu 20.04，Python 3.8，用conda创建了独立环境。安装命令如下：

# 创建Python虚拟环境 conda create -n rknn2 python=3.8 conda activate rknn2 # 安装RKNN-Toolkit2 pip install rknn-toolkit2-2.0.0-beta0-cp38-cp38-linux_x86_64.whl # 安装必要的依赖 pip install numpy==1.24.4 opencv-python==4.8.1.78 pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu118

板端环境就简单得多，主要是把RKNN-Toolkit-Lite2的whl包传上去安装，然后把编译好的librknnrt.so放在/usr/lib目录下：

# 板端安装 pip install rknn-toolkit-lite2-2.0.0b0-cp38-cp38-linux_aarch64.whl

版本这块要特别留意。rknn-toolkit2的主版本和板端运行库librknnrt.so必须是配套的，否则加载模型的时候会报版本不匹配的错误。我自己踩过坑，新版的rknn-toolkit2转换出来的模型，放到旧的板端运行库上直接报"Invalid RKNN model"。

3.2 YOLO11模型导出为ONNX格式

RKNN-Toolkit2目前对PyTorch模型的支持是通过ONNX中间格式实现的，所以第一步是把Ultralytics的PyTorch模型导出成ONNX。这一步用Ultralytics自带的export接口就能完成：

from ultralytics import YOLO # 加载训练好的模型 model = YOLO('yolo11s.pt') # 导出ONNX模型，opset设为12，RKNN对低版本opset兼容性更好 model.export(format='onnx', opset=12, imgsz=640)

这里有两个参数很关键。opset版本我建议用12或者13，RKNN编译器对这两个版本的算子覆盖度比较高。太高的opset版本，比如17以上，虽然支持的算子更多，但遇到某些新算子反而可能触发编译器兼容性问题。imgsz固定为640，这个要和后续RKNN转换时的input_size保持一致，否则输入维度对不上。

导出完成后，用onnxsim做一次模型简化，去掉一些冗余的shape操作和常量节点，能有效减少RKNN转换时出现不支持的算子风险。命令如下：

python -m onnxsim yolo11s.onnx yolo11s_sim.onnx

这一步不是必须的，但强烈建议做。ONNX模型经过训练框架导出后，经常会带一些训练痕迹的节点，比如Dropout、BN的scale变化等，这些对推理无关但容易干扰RKNN的图优化。onnxsim能把计算图剪得干净很多，后续转换成功率明显提升。

3.3 使用RKNN-Toolkit2完成FP16与INT8模型转换

ONNX模型准备好之后，就是重头戏RKNN转换了。这里直接给出我调试好的完整转换脚本：

import os import cv2 import numpy as np from rknn.api import RKNN # 初始化RKNN对象 rknn = RKNN() # 1. 配置模型输入和量化参数 rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588', optimization_level=3, quantized_dtype='w8a8', # 权重量化为8bit，激活量化为8bit quantized_algorithm='normal', quantized_method='layer', ) # 2. 加载ONNX模型 ret = rknn.load_onnx(model='yolo11s_sim.onnx') if ret != 0: print('Load ONNX model failed!') exit(ret) # 3. 构建RKNN模型，这里通过do_quantization控制是否INT8量化 # 不调用do_quantization则默认生成FP16模型 ret = rknn.build(do_quantization=False, dataset=None) if ret != 0: print('Build FP16 model failed!') exit(ret) # 4. 导出FP16版本的RKNN模型 ret = rknn.export_rknn('yolo11s_fp16.rknn') if ret != 0: print('Export FP16 model failed!') exit(ret) # 5. 重新加载模型，执行INT8量化 rknn.release() rknn = RKNN() rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588', optimization_level=3, quantized_dtype='w8a8', quantized_algorithm='normal', quantized_method='layer', ) ret = rknn.load_onnx(model='yolo11s_sim.onnx') if ret != 0: print('Load ONNX model failed!') exit(ret) # 6. 生成量化校准数据集 # 从训练集中抽取200张代表图片存成list文件 with open('calib_list.txt', 'w') as f: for img_name in calib_images: f.write(os.path.join('calib_imgs', img_name) + '\n') ret = rknn.build(do_quantization=True, dataset='calib_list.txt') if ret != 0: print('Build INT8 model failed!') exit(ret) ret = rknn.export_rknn('yolo11s_int8.rknn') if ret != 0: print('Export INT8 model failed!') exit(ret) print('Conversion completed!')

有几个配置项值得展开说。quantized_dtype='w8a8'表示权重和激活都量化成INT8。RKNN也支持w8a16这样的非对称组合，但实践中w8a8最均衡。optimization_level=3是最高优化等级，编译器会做更激进的算子融合和图优化。

do_quantization=False生成的模型默认就是FP16精度（前提是NPU驱动支持FP16），这个路径不需要校准集，直接从FP32权重转为FP16即可。FP16模型换算过程非常快，基本秒出。而INT8模型因为有校准步骤，耗时取决于校准图片数量和模型复杂度，YOLO11s在x86宿主机上跑一次量化大概需要5到8分钟。

3.4 板端推理代码与性能测试方法

模型转换完成后传到板端，接下来是板端推理测试。RKNN-Toolkit-Lite2的推理API和宿主机端几乎一致，主要差别在初始化时不需要加载模型，而是直接读取rknn文件。

板端推理的核心代码如下：

import cv2 import numpy as np from rknnlite.api import RKNNLite # 初始化RKNNLite rknn_lite = RKNNLite() # 加载RKNN模型 ret = rknn_lite.load_rknn('yolo11s_int8.rknn') if ret != 0: print('Load RKNN model failed') exit(ret) # 初始化NPU核心，RK3588有三核NPU，可以指定core_mask # RKNN_NPU_CORE_0/1/2对应单核，RKNN_NPU_CORE_AUTO自动分配 ret = rknn_lite.init_runtime(core_mask=RKNNLite.NPU_CORE_0) if ret != 0: print('Init runtime failed') exit(ret) # 读取测试图片并做letterbox预处理 img = cv2.imread('test.jpg') img_640, ratio, dw, dh = letterbox(img, (640, 640)) # 推理 outputs = rknn_lite.inference(inputs=[img_640]) # 后处理（解码） boxes, scores, class_ids = postprocess(outputs)

性能测试要特别注意计时方式。rknn_lite.inference()内部包含数据从CPU拷贝到NPU内存、NPU计算、结果拷贝回来的完整流程。我在代码里分别统计了preprocess耗时、inference耗时、postprocess耗时和总耗时，用time.perf_counter()精确计时。

多次推理取平均值时，建议前10次作为warmup，不计入统计。NPU有个好处是第一次推理时驱动和NPU微码会做初始化，延迟明显比后续高很多，这个不算数，必须排除掉。

4. FP16与INT8性能数据对比

4.1 推理延迟与吞吐量详细数据

这是整个实验最核心的对比数据。我在RK3588上分别跑了YOLO11s的FP16模型和INT8模型，测试方式是连续推理200帧，去掉前10次warmup，取剩余190帧的平均耗时。同时记录了使用单核NPU和三核并发两种模式下的数据。

数据非常有意思。单核情况下，INT8比FP16快了大概1.63倍，接近理论值2倍，但没完全达到。三核并发时，INT8比FP16快了约2.45倍。三核并发对INT8模型的利用率更高，说明三核并发模式本身也会影响资源调度。

需要注意的是，高效利用三核NPU的前提是模型本身不支持三核并行计算。RKNN运行库的做法不是把单次推理拆到三颗NPU上并行，而是通过多个线程并行执行多个推理任务。每个线程初始化时通过core_mask指定占用哪个NPU核心。所以如果你只有一路视频流，三核并发的优势不明显。但如果是处理多路摄像头，每路视频流在一个NPU核心上推理，三核并发就能吃掉三倍的吞吐量。

另外一组数据是模型体积。FP16模型的大小是17.8MB，INT8量化后是9.2MB，压缩了48.3%。这个在嵌入式设备上非常有意义，一方面降低存储占用，另一方面减少模型加载时间。实际测试中，从存储读取RKNN文件并加载进内存，FP16版本大约需要0.9秒，INT8版本只需要0.4秒。

4.2 精度对比：量化损失有多大

精度评估方面，我在COCO val2017随机抽取的2000张图上做了完整测试。基础模型是Ultralytics官方预训练的YOLO11s，COCO原生mAP50是58.6，mAP50-95是39.5。我的测试结果如下：

FP16基本无损，mAP50只下降了0.2，这完全在可接受范围内。INT8的损失比较明显，mAP50下降了1.8，mAP50-95下降了2.4。对目标检测任务来说，这个损失幅度属于中规中矩，如果对精度要求极高的场景可能得进一步做量化感知训练(QAT)，但大多数实际应用场景是完全够用的。

量化损失具体集中在哪些目标上，这个值得分析。我把检测结果按目标大小分成小目标（面积<32×32）、中目标（32×32到96×96）、大目标（>96×96）三档。INT8模型在大目标上几乎没掉点，mAP50只下降了0.4，中目标下降了1.2，小目标下降了3.8。这个规律和激活值分布有关，小目标通常对应特征图里的高频率响应，数值动态范围大，INT8量化时更容易溢出或丢失细节。

一个直观的现象是，INT8模型在检测远处小物体时容易出现漏检，尤其是在低光环境。如果实际业务场景里小目标占比高，建议先在CPU上用FP16模型做基线，再对比INT8，确认漏检率可控后再上线INT8方案。不然省下的算力资源可能全被后处理系统的调优消耗掉了。

4.3 NPU算子执行效率分析

RKNN编译器提供了详细的profiling工具，可以直接输出每一层的耗时和利用率。我分别对FP16和INT8模型做了层级别的性能分析，这个价值其实非常高，能帮你定位模型里真正拖后腿的算子。

从profile输出看，FP16模型里耗时占比最高的三层分别是：第5个C3k2模块的一个大卷积（12.3ms）、第8个C3k2模块的卷积（9.8ms）、检测头里的第一个卷积分支（8.2ms）。这些大卷积都是channel数超过256的巨型计算，对MAC阵列的压力最大。

INT8模型里，同样这几层的耗时大幅下降，降到原来的40%到55%。占用率最高的层变成了上采样层和最后的输出卷积层。这说明INT8量化后，原本的计算瓶颈被逐步削弱，访存瓶颈和算子调度开销开始浮出水面。针对这个现象，RKNN编译器会在某些场景下自动把耗时占比高的算子分配到CPU上执行，利用CPU和NPU的并行性。

我做了个额外测试，强制让上采样层跑到CPU上，其他层留在NPU。结果是总推理时间反而增加了8%左右，这是因为数据需要从NPU内存拷贝到CPU内存，再拷贝回来，DMA搬运的开销比NPU自己算还大。所以混合部署不是改改配置就能赢，必须具体问题具体分析，以profile数据为准。

5. 踩坑实录与优化技巧

5.1 模型转换期的坑：算子不支持与维度不匹配

RKNN-Toolkit2转换模型时，最容易遇到的报错就是"Unsupported operator"。YOLO11导出成ONNX后，我最初在opset 17下转换，报错说遇到GridSample和ScatterND算子不支持。这个其实是Ultralytics某些导出选项带进来的，换成opset 12之后问题消失。

还有一个比较隐蔽的问题是动态维度。如果导出ONNX时指定了动态batch，比如-1，RKNN编译器会报维度错误。RKNN的模型尺寸在转换时就必须固定下来，动态shape是不支持的（除非用1.x的旧版RKNN模型支持一部分，但优化效果差很多）。所以导出时一定用固定shape，model.export(format='onnx', opset=12, imgsz=640)生成的模型默认batch=1，h=640，w=640。

第三个坑是color format，也就是颜色空间。YOLO11训练时图像通道顺序是RGB，数据预处理方面，我习惯直接用mean_values=[[0,0,0]]、std_values=[[255,255,255]]，也就是不做均值归一化，只做缩放。但如果是OpenCV读取的BGR图像，需要在送入RKNN之前做BGR到RGB的转换，不然检测框会错位，准确率掉得离谱。实测如果不转换，mAP50直接跌到15以下。

5.2 板端推理期的坑：内存对齐与后处理优化

INT8模型如果用默认的rknn_lite.inference()传入numpy数组，数据会被自动拷贝到NPU的buffer里，这个拷贝过程会占掉一部分耗时。如果你追求极致性能，可以提前用rknn_lite.get_input_tensors()获取输入tensor的buffer地址，然后直接写入数据，省掉一次拷贝。

后处理NMS部分，RKNN的输出格式和PyTorch原版不同。原版YOLO11输出的格式是[1, 84, 8400]，其中84对应4个box坐标+80个类别分数。但RKNN输出的格式可能是[1, 8400, 84]或者做了维度调整，需要仔细查看转换时的输出信息。同时需要注意，RKNN输出的坐标格式可能是cxcywh，也可能是xywh，具体看RKNN编译器版本。我这边实测下来，YOLO11的RKNN输出是cxcywh格式，而YOLOv8是xywh格式，这个不统一让很多新手直接翻车。

后处理还有个大坑是置信度阈值。量化后的模型置信度输出值分布会跟FP32模型不一样，比如FP32模型在阈值0.25时表现不错，INT8模型可能在同样的置信度阈值下漏掉很多目标。建议单独对量化模型做一个阈值扫描，把阈值调低或者调高，找到最合适的点。我这边INT8模型的阈值从0.25调到0.18之后，mAP50从56.8提升到57.5左右，效果很明显。

5.3 进一步压榨性能的三个可行方向

模型转换和基本部署完成之后，如果你还想继续压缩延迟，有几个方向可以试。

第一个方向是输入分辨率调整。YOLO11s在640×640输入下INT8推理耗时17.6ms（三核），但如果业务场景里不需要检测太小的物体，把输入分辨率降到480×480，推理耗时能压到11ms左右，端到端FPS可以拉到60以上。这属于典型的精度和速度取舍，需要根据业务需求评估。

第二个方向是变化后处理。C++版本的NMS优化空间非常大，对比Python版本能快上数倍。Python版本YOLO11后处理在RK3588的CPU上跑需要4ms左右，用C++实现之后能压缩到1ms以下。如果做多路视频流，这个差距会被放大得十分明显，多路共用一套推理服务的时候必须用C++。

第三个方向是硬件编解码联动。RK3588有硬件JPEG编码器和视频编码器，利用RKMPP可以直接把摄像头输入的YUV图像做缩放和格式转换，再直接送进NPU，省去OpenCV软件缩放的开销。这套方案我在另一个项目里验证过，可以省掉大约2ms的图像预处理时间，而且CPU占用率会显著下降。

6. 实验总结与部署建议

最后聊一点个人体会。FP16和INT8在RK3588上不是二选一的关系，而是适用场景不同。如果你做的是高精度离线分析，数据量不大，延迟要求不高，FP16省心且无损，直接上。如果你做的是实时视频流分析，对延迟和吞吐量敏感，INT8的40 FPS（三核）和48%的体积压缩非常值得。

在实际项目中，我更推荐的做法是做一个运行时可切换方案：加载INT8模型作为默认推理引擎，同时保留FP16模型备用。当检测到当前场景质量较差，置信度普遍偏低或小目标漏检明显时，动态切回FP16模式。RK3588的NPU支持同时加载多个模型，切换成本其实就是一次指针引用的开销。

部署过程中还有一个容易被忽视的问题，就是散热。RK3588在长时间高负载推理时，芯片温度很容易冲上80度以上，这时候NPU会触发降频保护，性能可能掉到正常状态的70%。我的做法是在设备里主动控制NPU占用率，不让它长时间跑满，或者外加主动散热风扇，确保温度控制在75度以下。这些基础工作做好，模型本身优化的效果才能真正发挥出来。