1. 整体链路拆解为什么ONNX模型不能直接跑到RV1126上1.1 RV1126的NPU只认RKNN模型落地必须过这一关做端侧模型的兄弟应该都有体会在服务器上训练好的模型无论用的是PyTorch还是TensorFlow最终想跑在瑞芯微的芯片上都绕不开模型转换这一步。RV1126这颗芯片算力2.0TOPS在IPC、门禁机、人脸考勤机上用得非常多但它的NPU只吃瑞芯微自定义的RKNN格式。也就是说你手里的ONNX模型再怎么训练得好、精度再高不转成RKNNNPU一概不认。很多第一次接触这块的人会有一个误区模型转换不就是格式改一下吗实际上完全不是这么简单。ONNX是一个开放式的中间表示格式它描述的是模型的计算图结构和权重参数而RKNN是瑞芯微NPU编译器针对自家硬件指令集生成的模型格式。从ONNX到RKNN中间要经历算子映射、图优化、内存布局调整如果做int8量化还要靠数据集去标定每一层的数值范围。整个过程更像是在给NPU“定制编译”一版模型而不是简单改个文件后缀。以人脸识别模型为例常见的链路是训练出一个人脸检测模型比如RetinaFace再加一个人脸特征提取模型比如MobileFaceNet或者是一个端到端的目标检测模型。检测头里通常有SSH上下文模块、PReLU、ROIAlign这类结构这些算子在不同推理框架上的支持程度参差不齐往往是转换过程中最容易卡住的地方。我前前后后帮朋友解决过好几回RV1126上人脸模型转换的问题踩过的坑不少有代表性的基本都集中在这条链路上。1.2 模型转换的整体流程训练、导出、转换、部署整个从ONNX到RKNN的流程可以拆成这么四段第一段是训练和导出在PyTorch或者TensorFlow里把模型训好然后导出成ONNX格式。导出这一步很多人不够重视直接torch.onnx.export一敲就完事结果到了转RKNN的时候报算子不支持回头再改模型来回折腾好几天。建议在导出的时候就检查好opset版本、输入输出的维度是否固定、有没有动态轴。第二段是转换在PC上用瑞芯微官方提供的rknn-toolkit2工具链把ONNX模型解析、优化、量化、生成RKNN文件。这个过程可以在没有开发板的情况下完成工具链自带模拟器能在PC上仿真NPU推理结果这一步对于快速验证模型转换是否成功、精度掉得是否离谱非常关键。第三段是部署把生成的RKNN模型文件推到RV1126板子上用librknnmrt.so这套运行时库去加载模型、设置输入、获取输出。板端的ROC-RK1126或者自己画的底板跑起来之后还要跟PC模拟器上的结果做对比确认一下数值是否对得上因为模拟器和真实NPU之间多少会有一点差异。第四段是调优主要是混合量化、算子保留浮点、预处理挪到硬件加速模块上这类操作目的就是让模型在精度和速度之间找到一个平衡点。1.3 转换前必须先确认的算子兼容性在动手写转换脚本之前强烈建议先做一次算子兼容性检查。RV1126的NPU对算子的支持比RK3588要弱不少很多在PC上跑得好好的算子在RV1126的工具链里根本没有对应的实现。我碰到最多的几个坑PReLU算子。RetinaFace里的PReLU激活如果用比较老的rknn-toolkit版本转换时直接报不支持。后来我查了下新版本的rknn-toolkit2已经支持了但如果你用的是rknn-toolkit 1.x系列就要想办法把PReLU改写成ReLU或者自定义层这会带来一点精度损失但好在不明显。ROIPooling / ROIAlign。检测类模型里很常见的算子在转rknn时容易出问题尤其是ROIAlign如果你用的是老版本框架算子名对不上就会转换失败。解决方案通常是升级工具链版本或者在导出ONNX时把这个层绕过放到板端用CPU去算。Depthwise卷积和普通卷积的混合使用。这个其实不算不兼容但RKNN编译器对内存布局有优化策略如果网络结构层次太深、分支太多编译器自动优化的时候可能把某些算子的输入端搞错导致转换出来的模型跑出来的结果一堆NaN。我遇到过几次最后都是通过在原模型里合并BatchNorm、简化分支结构解决的。给个经验性的建议转换前用Netron打开导出的ONNX模型把整个结构从头到尾过一遍重点关注激活函数、归一化层、池化层、坐标变换这些算子心里有数哪些层后面可能出问题。这一步看起来花时间但实际上能帮你省下后面好几天的排查时间。2. 环境准备rknn-toolkit2的安装与避坑2.1 工具链选型rknn-toolkit还是rknn-toolkit2很多人一开始都会卡在环境安装这一步因为瑞芯微的工具链版本太多了容易搞混。目前官方维护的主要是两条工具链一条是老版的rknn-toolkit主要支持RK3399Pro、RK1808这些老芯片另一条是新的rknn-toolkit2支持RV1126、RV1109、RK3566、RK3568、RK3588这些芯片。RV1126这条线在rknn-toolkit2的文档里是明确支持的所以如果你要为RV1126做转换直接装rknn-toolkit2就行不用看老版rknn-toolkit省得折腾半天装的版本不对config里面target_platform填rv1126直接报错。还有一点要特别注意rknn-toolkit2从1.4.0版本开始对RV1126的支持才比较稳有些早期的0.x版本虽然有RV1126选项但实际转换时算子支持不全很容易出问题。建议直接到瑞芯微的官方仓库下载最新release版本别用旧版本硬扛。2.2 安装步骤和依赖管理rknn-toolkit2的安装方式是提供whl包装之前先把Python环境准备好。我的建议是用conda独立建一个环境不要直接装到系统Python里因为rknn-toolkit2对numpy、onnx、onnxruntime这些依赖版本卡得比较严装到系统环境很容易把别的项目搞坏。我用的是Python 3.8rknn-toolkit2 1.5.0版本依赖的numpy版本是1.24.x左右onnxruntime版本是1.14.x左右。网上有人说Python 3.10也能跑通但我实测下来Python 3.8最稳踩坑成本最低。安装命令如下conda create -n rknn python3.8 conda activate rknn pip install rknn_toolkit2-1.5.0-cp38-cp38-linux_x86_64.whl装完之后验证一下能不能正常importpython -c from rknn.api import RKNN; print(rknn toolkit2 ok)正常打印出rkkn toolkit2 ok就说明环境没问题。如果报缺失依赖按提示pip install补上就行。有个很常见的坑rknn-toolkit2对numpy版本非常敏感如果numpy版本太新比如2.ximport的时候直接报错报错信息还不直观什么_ARRAY_API not found。这时候先把numpy降级到1.24.x再试。2.3 PC模拟器模式和板端接入模式rknn-toolkit2提供了两种运行模式一种叫模拟器模式不需要连接开发板在PC上直接把ONNX模型转成RKNN并且在模拟器里跑一遍推理。这个模式非常有用因为你可以在没有硬件的情况下先把整个转换流程跑通看看模型能不能成功转换、精度掉多少。如果你只是验证转换流程先跑模拟器模式就够了。另一种叫板端模式通过USB把PC和RV1126开发板连起来工具链会把转换好的模型推送到板子上用真实的NPU去推理。这种模式更接近实际部署效果但前提是板子要烧好对应的NPU驱动并且PC端能正确识别到设备。实操经验先模拟器模式验证再上板子验证不要一上来就折腾板端连接问题定位会麻烦很多。而且模拟器模式下转换的精度结果和板端通常差距不大如果模拟器上精度就崩了那基本是量化数据集或者模型本身的问题不用急着去连板子。3. 模型转换实操配置、量化与导出3.1 rknn.config的六个关键参数转换的第一步就是用rknn.config()设置好参数这一步决定了量化方式、目标平台、预处理方式等核心行为。我摘几个最关键的参数说说rknn.config( mean_values[[103.94, 116.78, 123.68]], std_values[[58.82, 58.82, 58.82]], target_platformrv1126, quantized_dtypeasymmetric_quantized-8, quantized_algorithmnormal, optimization_level3, dequantize_outputTrue )mean_values和std_values是图像预处理的均值标准差很多人会忽略这个结果转换出来的模型推理效果全黑、全白或者数值完全不对。这里要特别注意rknn.config里的mean/std对应的是你训练时做的归一化处理的逆过程如果训练时用的是ImageNet的标准归一化那么这里就填ImageNet的均值标准差。target_platform填rv1126这个不用多说就是要明确告诉编译器你最终要跑在什么芯片上。填错平台虽然也能生成rknn文件但上了板子之后性能会差很多甚至有些算子会走CPU兜底推理速度直接崩。quantized_dtypeasymmetric_quantized-8表示做非对称int8量化。非对称量化相比对称量化能更好地表示ReLU之后的非负激活值因此对人脸检测模型这种大量使用ReLU的网络来说默认选这个基本不会错。如果你有一些对精度极其敏感的层可以单独给这些层指定保留float16这就是后面要讲的混合量化。dequantize_outputTrue是个很容易被忽视的参数。默认情况下rknn模型的输出是量化后的int8数据但你在后处理时通常希望拿到浮点数去做阈值判断、框坐标还原。设置这个参数后工具链会在模型末尾加一个反量化操作让最终输出是fp32方便后处理直接使用。我强烈建议打开否则你拿到的输出还得自己在板端手动反量化麻烦不说还容易出错。3.2 量化数据集的选择与处理int8量化是整个转换流程中最重要也最容易翻车的一环。量化的时候工具链需要一批代表性数据去统计每一层激活值的数值范围然后决定怎么把浮点数据映射到int8的256个离散值上。这个代表性数据的质量和数量直接决定了量化后模型的精度。我踩过一个坑一开始图省事直接从网上下载了公开的WIDER Face数据集里随便抽了100张图片做量化数据集结果转换出来的模型在测试集上mAP掉了接近8个百分点。后来换成从实际应用场景中采集的视频帧覆盖了不同光照、不同角度、不同距离的人脸样本同样的模型精度就只掉了3个点左右。这个差异背后的原因是量化标定数据的分布必须和模型实际运行时的输入分布保持一致。如果你部署的场景是室内闸机光照比较均匀人脸都比较正那么你用室外复杂光线的人脸图去量化等于是用错误的数据分布去估算激活值的范围量化误差自然就大。实际操作建议量化数据集至少200张多一点更好我一般用500张左右就够。数据要尽量覆盖实际场景的各种情况不要只挑清晰的、角度正的图。图片不要做额外的裁剪或缩放直接用你推理时会送入模型的尺寸。如果模型有多个输入或者多个任务头量化数据集里也要保证各类别都有足够样本。rknn-toolkit2支持通过txt文件指定量化数据集的路径列表也可以传入一个list里面存着已经读取好的图片数组。我习惯用txt文件方式方便反复调试不同数据集时修改而不用改代码。3.3 从load_onnx到export_rknn的完整转换脚本下面给一个我在RV1126上转换人脸检测模型时用的完整脚本你基本上可以直接照着改import os import cv2 import numpy as np from rknn.api import RKNN ONNX_MODEL retinaface_mobile0.25.onnx RKNN_MODEL retinaface_mobile0.25.rknn QUANT_IMG_DIR quant_imgs IMG_PATH test.jpg def main(): rknn RKNN() # 1. config rknn.config( mean_values[[103.94, 116.78, 123.68]], std_values[[58.82, 58.82, 58.82]], target_platformrv1126, quantized_dtypeasymmetric_quantized-8, quantized_algorithmnormal, optimization_level3, dequantize_outputTrue ) # 2. load onnx ret rknn.load_onnx(modelONNX_MODEL) if ret ! 0: print(load onnx failed) exit(-1) # 3. build ret rknn.build(do_quantizationTrue, datasetdataset.txt) if ret ! 0: print(build rknn failed) exit(-1) # 4. export ret rknn.export_rknn(RKNN_MODEL) if ret ! 0: print(export rknn failed) exit(-1) # 5. init runtime and inference on simulator ret rknn.init_runtime() if ret ! 0: print(init runtime failed) exit(-1) img cv2.imread(IMG_PATH) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) outputs rknn.inference(inputs[img]) print(outputs shape:, [o.shape for o in outputs]) rknn.release() if __name__ __main__: main()dataset.txt的内容很简单每行一个图片路径quant_imgs/0001.jpg quant_imgs/0002.jpg quant_imgs/0003.jpg ...需要说明的是rknn.build里的do_quantization参数如果你只是先验证模型能不能转通可以先设成False跑一遍确认结构没问题了再开量化。我现在的习惯是新模型第一次转换先不开量化等确认结构能编译过、输出形状是对的再开量化去试精度。这样能把“结构问题”和“量化精度问题”分开排查。另外转换过程中如果报错说算子不支持先别急着改模型。可以试着重装最新版rknn-toolkit2很多时候算子支持问题在新版本里已经修复了。如果新版本还报再考虑改写模型结构。3.4 模型输出是量化数据还是浮点数据的判断转换完成之后很多人不知道如何判断模型输出到底是不是浮点。有个快速的办法在转换脚本里用同一张图分别调用rknn和onnxruntime跑一遍对比输出的数值范围。如果rknn输出的数值和onnxruntime的数值基本在一个量级说明dequantize_output生效了拿到的是浮点结果。如果rknn输出的数值都是整数或者一堆看起来像“噪声”的离散值那说明输出还是int8量化的。我自己写了一个对比脚本跑完之后能直接打印出两个框架输出值的均值和方差一眼就能看出差异import onnxruntime as ort sess ort.InferenceSession(retinaface_mobile0.25.onnx) ort_outputs sess.run(None, {input: img.astype(np.float32)}) # rknn_outputs来自上一步rknn.inference的结果 for i, (a, b) in enumerate(zip(rknn_outputs, ort_outputs)): print(foutput[{i}]: rknn mean{a.mean():.4f} var{a.var():.4f} fort mean{b.mean():.4f} var{b.var():.4f})如果rknn的输出均值只有正常fp32均值的一半或者数值特别小不要怀疑肯定是量化哪里出了问题优先检查量化数据集和mean/std配置。4. 精度与性能int8量化后精度下降的排查思路4.1 量化精度掉点的常见原因分析int8量化后精度下降是端侧模型落地中最常见的痛网上随便一搜就是一堆相关提问。我按自己遇到的情况把原因归纳成几类第一类量化数据集质量差。这是最典型的原因。数值范围统计得不准确后面的每一步都是错的。我做过测试用100张质量差的数据集和500张质量好的数据集同样的模型前者精度掉5到8个百分点后者只掉2个点左右。第二类模型里有对数值范围特别敏感的算子。最典型的是sigmoid和softmax这类会把数值范围压缩到很小的区间里的激活函数。在fp32下这些函数能精确表达小数点的后几位但量化为int8后这些细节全都丢失了导致后面层的输入误差被逐步放大。第三类某些层的权重范围差异巨大。比如注意力机制里的全连接层或者head部分最后一层卷积权重参数的分布可能非常不均匀。如果这些层也被量化到int8信息丢失会很严重。拿到一个转换后精度掉点的模型我的排查路径是先用模拟器跑一遍onnx和rknn的结果对比锁定第一个出现明显数值偏差的层然后逐层往上看是哪一层“爆掉”的。rknn在build的时候可以打开debug log工具链会打印每一层的量化信息包括每层输入输出的min/max值范围。看这些信息就比较容易判断出问题出在哪个层。4.2 使用混合量化保住关键层精度如果定位到了敏感层最直接的办法就是用混合量化把这些层设定为保持fp16而其他层继续用int8。很多情况下模型大部分层用int8是完全没有问题的只需要把检测头或者某些归一化层保留浮点整体精度就能回来一大截。在rknn-toolkit2里混合量化主要是通过custom op的方式实现的。你可以为特定的算子指定一个自定义配置让编译器对这些算子不做量化直接用fp16推理。比如我想让网络最后两个卷积层保持浮点rknn.config( mean_values[[103.94, 116.78, 123.68]], std_values[[58.82, 58.82, 58.82]], target_platformrv1126, quantized_dtypeasymmetric_quantized-8, quantized_algorithmnormal, optimization_level3, custom_op[ { op_name: conv_last_1, op_type: CONV, quantized_dtype: float16 }, { op_name: conv_last_2, op_type: CONV, quantized_dtype: float16 } ] )op_name要填ONNX模型里对应的算子名称用Netron就能查到。这一步实际操作起来有几个小技巧优先保住检测头的输出层尤其是框坐标回归分支坐标回归对数值精度比分类分支敏感得多。如果模型有多个分支输出尽量只保留一个对精度最关键的输出分支为浮点其他的保持int8这样可以最大程度减少混合量化带来的性能损失。可以多试几种组合比如只保一个层、保最后两个层、保三个层分别build一次在模拟器上跑同一张图对比精度和耗时挑一个性价比最高的方案。4.3 板端推理与PC模拟器结果不一致的问题有一个现象很让人头疼在PC模拟器上跑模型精度看起来不错但一上RV1126板子同样的输入图像输出的框位置偏了置信度也变了。这种情况我遇到过排查下来主要有两个原因。第一个原因是板端的NPU驱动版本和PC端工具链版本不匹配。RV1126的板端固件里带的是librknnmrt.so运行时库它和rknn-toolkit2的版本有对应关系。如果你用最新版工具链生成的rknn模型拿到一个驱动版本很旧的板子上跑就可能出现数值偏差甚至推理失败。解决办法就是把板端的rknpu驱动和工具链版本对齐最好用官方配套的固件。第二个原因是预处理差异。模拟器模式下的rknn.inference内部按你config里设置的mean/std做预处理。但板端部署时通常是你把图像读进内存然后手动做resize、减均值、除方差这些操作再传给NPU。如果两边的预处理逻辑有一点偏差比如resize的插值算法不同双线性、最近邻等输出的数值就会不一样。我遇到过最典型的一个案例PC上用cv2.resize的INTER_LINEAR板端写代码的人用了INTER_NEAREST出来的结果框偏移了好几个像素。排查这种问题最好的办法是在板端代码里把传入NPU之前的输入图像保存下来和PC端传给rknn.inference的图像做像素级对比能快速定位是预处理的问题还是NPU推理本身的问题。4.4 RV1126上的人脸识别模型的性能瓶颈RV1126的NPU标称算力2.0TOPS理论峰值不低但实际跑起来性能瓶颈往往不在算力本身而在数据搬运和预处理上。我实测跑一个MobileFaceNet特征提取模型输入112x112int8量化之后NPU推理时间大概在5毫秒左右。但如果你在板端用CPU做图像缩放、颜色空间转换、减均值除方差这些预处理的时间加起来可能比NPU推理本身还长。很多人以为模型跑得慢实际上慢在预处理上。针对这个问题RV1126有硬件加速模块RGA可以专门做图像的缩放和格式转换。把resize和cvtColor这些操作从CPU挪到RGA上能明显降低预处理耗时。具体使用方法可以参考RV1126的RGA驱动文档代码里通过调用RGA接口把图像数据处理好再送到NPU推理。另一个性能瓶颈点是在推理频率上。人脸识别如果做实时视频流处理每帧都要跑一次检测加一次特征提取。如果流程设计得不好串行执行检测和特征提取帧率会很难看。建议的做法是检测和特征提取流水线并行或者降低检测帧率比如每3帧做一次检测对检测到的人脸区域做特征提取这样整体帧率会有明显提升。5. 完整命令与部署参考从转换脚本到板端推理5.1 一个可直接复制的完整转换脚本把前面的零散代码整合一下给一份我实际项目里在用的完整脚本你直接保存成convert.py就能跑import os import cv2 import numpy as np from rknn.api import RKNN ONNX_MODEL face_det.onnx RKNN_MODEL face_det.rknn QUANT_IMG_DIR quant_imgs TEST_IMG test.jpg DATASET_FILE dataset.txt def generate_dataset_txt(): img_list sorted(os.listdir(QUANT_IMG_DIR)) with open(DATASET_FILE, w) as f: for name in img_list: if name.endswith((.jpg, .jpeg, .png)): f.write(os.path.join(QUANT_IMG_DIR, name) \n) print(fdataset.txt generated, total {len(img_list)} images) def convert(): rknn RKNN() rknn.config( mean_values[[103.94, 116.78, 123.68]], std_values[[58.82, 58.82, 58.82]], target_platformrv1126, quantized_dtypeasymmetric_quantized-8, quantized_algorithmnormal, optimization_level3, dequantize_outputTrue ) assert rknn.load_onnx(modelONNX_MODEL) 0, load onnx failed assert rknn.build(do_quantizationTrue, datasetDATASET_FILE) 0, build failed assert rknn.export_rknn(RKNN_MODEL) 0, export failed print(convert done:, RKNN_MODEL) rknn.release() def verify(): rknn RKNN() rknn.load_rknn(RKNN_MODEL) rknn.init_runtime() img cv2.imread(TEST_IMG) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) outputs rknn.inference(inputs[img]) for i, out in enumerate(outputs): print(foutput[{i}] shape{out.shape} mean{out.mean():.4f} std{out.std():.4f}) rknn.release() if __name__ __main__: generate_dataset_txt() convert() verify()跑通这个脚本你手里就会有一个face_det.rknn模型文件和一份模拟器验证输出。注意verify阶段打印出来的output信息要确认输出形状和你模型定义的一致如果shape对不上多半是在转换过程中某些算子的输出被编译器裁剪掉了。5.2 RV1126板端NPU推理流程模型转换成功之后最后一步就是在RV1126板子上跑起来。板端的开发一般用C或者C调用librknnmrt.so的API也有Python版本的rknn-toolkit-lite2但工业部署场景下C接口更常见也更稳定。整个NPU推理流程包括这么几个步骤#include rknn_api.h // 1. 初始化 rknn_context ctx; rknn_init(ctx, face_det.rknn, 0, 0, NULL); // 2. 查询输入输出信息 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); // 3. 设置输入 rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size img_width * img_height * 3; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf img_data; inputs[0].pass_through 0; rknn_inputs_set(ctx, 1, inputs); // 4. 推理 rknn_run(ctx, NULL); // 5. 获取输出 rknn_output outputs[io_num.n_output]; for (int i 0; i io_num.n_output; i) { outputs[i].want_float 1; // 希望拿到浮点输出 } rknn_outputs_get(ctx, io_num.n_output, outputs, NULL); // 6. 后处理释放 // ... rknn_outputs_release(ctx, io_num.n_output, outputs); rknn_deinit(ctx);有几个细节需要提醒inputs[0].fmt设置成NHWC还是NCHW取决于你模型转换时输入张量的排布一般ONNX默认NCHW但rknn内部的输入接口允许你传递NHWC的数据编译器会在内部做转换。我个人习惯在板端就把数据排列成NHWC省掉一次数据转置。pass_through参数表示要不要跳过预处理直接传给模型如果你在代码里已经手动做了减均值除方差可以把pass_through设为1如果没做就设为0让NPU内部按config里的mean/std处理。这个地方很容易搞混建议一开始统一用pass_through0等能跑通了再考虑优化预处理。want_float设为1之后工具链会把输出反量化为浮点再返回方便后处理。如果只想拿int8原始输出做后处理以节省内存带宽可以把want_float设为0但对应的后处理逻辑也要跟着改。5.3 部署阶段再做一轮优化模型从转换到真正能稳定跑业务中间通常还要经历几轮优化。我总结几个在RV1126上性价比比较高的优化手段第一输入分辨率尽量固定。如果模型的输入尺寸是动态的RKNN每次推理可能都要重新做内存分配和算子调度影响稳定性。人脸检测模型一般固定320x240或者640x480就够了人脸识别模型固定112x112在导出ONNX的时候就把输入尺寸写死。第二多线程流水线。RV1126是四核A7 CPU加NPU你可以把图像采集、预处理、推理、后处理四个阶段拆到不同的线程里用队列串起来形成流水线。这样每一帧的耗时不是四个阶段的总和而是最长那个阶段的耗时帧率能提升一截。第三图像缩放尽量走RGA。前面提过CPU做resize在这种小算力平台上很费时间特别是视频流场景每帧都要缩放CPU占用率会一直居高不下。RGA硬件加速能减轻CPU压力把节省下来的CPU资源留给后处理和业务逻辑。第四NPU推理和CPU后处理分开。检测模型的后处理里有不少循环和排序操作如果在NPU推理返回后直接在主线程里跑整个流程会被拖慢。正确做法是NPU推理线程只管推理把输出丢到结果队列后处理线程从队列里取数据做decode和NMS这样检测帧率能稳定不少。5.4 常见问题速查表现象可能原因排查方法转换时算子不支持模型包含RV1126 NPU不支持的算子用Netron检查模型结构替换或删除对应算子转换成功但模拟器推理全是NaN模型结构有死路或编译器图优化出错先关了量化试一次确认是不是量化的问题如果是尝试简化模型结构量化后精度掉得厉害量化数据集太少或分布不符增加量化数据量到500张覆盖实际场景PC模拟器正常但板端结果偏板端NPU驱动版本老升级rknpu驱动到和工具链匹配的版本板端预处理顺序不对resize插值方式、mean/std顺序不一致保存板端预处理后的图像与PC端逐像素对比推理速度远低于预期预处理拖慢、模型输入动态shape用RGA做预处理固定输入尺寸检查是否走了CPU兜底算子初始化rknn_context失败板端缺少NPU驱动或权限不对确认librknnmrt.so存在检查/dev/rknpu设备节点写在最后回顾一下整个RV1126人脸识别模型的转换流程最核心的一点就是转换不是一锤子买卖更像是一个反复迭代的过程。先跑通结构再调量化精度再上板验证每一轮都可能要回到上一步重新修改。这个过程中最大的敌人是“我以为没问题”的心态——以为模型结构简单就不会有算子问题以为随便抽几张图做量化就够了以为PC模拟器结果好上板就一定好。我个人的体会是如果你负责的是一个长期维护的产品线建议把转换脚本、量化数据集、验证脚本这三样东西像代码一样管理起来每次模型迭代都跑一遍完整流程把所有环节的数值结果记录下来。这样一旦某个版本出了问题你可以快速对比历史数据定位是哪一步引入的偏差。在端侧模型落地这条路上稳定的流程规范和详细的日志比对往往比临场Debug更管用也更省时间。