企业官网建设流程全解析

1. 项目概述：RKNN模型评估不是“跑个分”那么简单

你拿到一个.onnx模型，用rknn-toolkit2转成.rknn，烧进RK3566板子，一跑eval_perf——显示“FPS: 42.3”，内存占用“DDR: 187MB”。你松了口气，觉得“能用”。但等真正集成进摄像头实时推理流水线时，系统开始卡顿、帧率跳变、偶尔OOM崩溃，日志里反复出现[rknn_api] memory alloc failed。这时候你才意识到：那个看似干净的eval_perf输出，根本没告诉你真实战场上的表现。RKNN模型评估，尤其是性能评估和内存评估，从来不是在理想环境里点一下命令就完事的工程动作，而是一场需要穿透硬件层、驱动层、模型层、运行时层的系统性压力测试。它要回答的不是“能不能跑”，而是“在什么条件下稳定跑多久”“在多大负载下不掉帧”“当输入分辨率突变时内存会不会雪崩式增长”。我做过不下30个RK3566边缘AI项目，从工业质检到车载DMS，踩过最深的坑，90%都出在评估阶段——把eval_perf当成验收标准，而不是诊断工具。关键词RKNN、性能评估、内存评估、RK3566、eval_perf，每一个都不是孤立概念：RKNN是载体，性能评估是时间维度的稳定性验证，内存评估是空间维度的安全边界测绘，RK3566是物理约束锚点，eval_perf只是暴露问题的第一道探针。这篇文章不讲怎么装toolkit2，不讲基础转换命令，只聚焦于你烧录模型后、交付前最关键的那72小时——如何用一套可复现、可量化、可归因的方法，把模型在RK3566上的真实能力摸透。适合已经完成ONNX→RKNN转换、正准备上板验证的嵌入式AI工程师、算法部署工程师，以及需要对模型交付质量负最终责任的技术负责人。如果你还在纠结“yolo26n-sem rknn为什么int8量化后精度下降”，那说明你还没走到评估这一步；如果你已经看到“rknn 回归模型 不量化正常”，却没深挖背后内存分配模式的差异，那你离线上事故只差一次温度升高。

2. RKNN模型评估的整体设计逻辑：为什么不能只信eval_perf一行输出

2.1 eval_perf的本质：一个高度简化的单点快照

eval_perf命令看起来很直观：python3 eval_perf.py --model model.rknn --device rk3566 --inputs input.bin。它默认执行10次前向推理，取平均耗时算FPS，同时记录一次推理过程中的峰值内存占用。但这个“一次”和“10次”，恰恰掩盖了三个致命盲区。第一，它不模拟真实业务流——工业相机是持续推流的，每秒30帧，连续跑8小时，而eval_perf只测10次，连一次完整帧间隔（33ms）都没覆盖。第二，它不触发内存碎片化——RKNN Runtime的内存管理器（MMU+DDR allocator）在首次加载模型时会预分配大块连续内存，但真实场景中，模型推理、图像预处理、后处理结果回传、日志写入、网络收发会频繁申请/释放小块内存，导致DDR出现大量不可用的碎片空洞，此时即使总剩余内存充足，也会因无法凑出一块64MB连续空间而失败。第三，它忽略硬件状态耦合——RK3566的NPU频率、DDR带宽、CPU负载、温控策略是动态联动的。eval_perf运行时，系统可能处于冷态，NPU跑在1.2GHz满频；但实际运行2小时后，板子温度升至65℃，NPU自动降频至800MHz，此时FPS必然断崖下跌，而eval_perf完全不反映这种热衰减。我曾在一个AGV避障项目中遇到典型案例：eval_perf测得YOLOv5s-rknn在RK3566上达58FPS，现场部署后，连续运行15分钟，帧率从55跌到22，最后卡死。抓取dmesg发现thermal thermal_zone0: critical temperature reached(85 C)，但eval_perf报告里连温度字段都没有。所以，评估设计的第一原则就是：必须脱离单点快照，构建时序化、压力化、状态耦合的评估矩阵。

2.2 性能评估与内存评估的耦合关系：时间换空间？还是空间换时间？

很多人把性能和内存当成两个独立指标，分别优化。这是大错。在RK3566这类资源受限的SoC上，二者是强耦合的零和博弈。举个具体例子：你在rknn-toolkit2转换时设置target_platform='rk3566'，并开启optimization_level=3（最高优化）。toolkit2会自动将模型中多个小卷积层融合为一个大卷积，减少kernel launch次数，提升NPU利用率——这直接提升FPS，但融合后的层需要更大的中间特征图缓存空间。实测一个ResNet18分支，在opt_level=3下，单次推理峰值DDR占用从142MB涨到198MB，涨幅39%，但FPS从38.2提升到45.7，涨幅19.6%。表面看很划算，但当你把模型放进一个已有200MB DDR预留空间的系统时，198MB就踩在了悬崖边上。一旦系统其他模块（如OpenCV图像缩放）临时申请5MB内存，立刻OOM。反过来，若你为保内存安全，强制设optimization_level=1，峰值内存压到135MB，但FPS掉到32.1，无法满足30FPS实时性要求。这就是典型的“时间换空间”陷阱。更隐蔽的是“空间换时间”的反向陷阱：某些模型在int8量化后，因数值范围压缩，激活值分布变窄，NPU可以启用更激进的权重预取策略，反而降低访存延迟，提升FPS；但量化引入的舍入误差，可能让某些层输出张量尺寸异常膨胀（比如BN层重参数化后shape计算偏差），导致内存占用不降反升。我们测试过yolo26n-sem rknn，int8量化后理论应省30%内存，实测DDR峰值却从176MB升至189MB，查根源发现是语义分割头的上采样层在量化后，插值算法内部临时缓冲区申请逻辑被触发，多占了13MB。因此，评估设计的第二原则是：性能与内存必须联合建模，任何单一指标的优化，都需同步观测另一指标的变动幅度与波动区间。我们采用“双轴评估法”：横轴是推理负载强度（1fps/10fps/30fps/60fps持续流），纵轴是系统状态维度（冷态/稳态/热态、空闲内存/高内存压力），每个交叉点跑至少30分钟压力测试，记录FPS均值、标准差、内存峰值、内存波动方差四个核心值。

2.3 RK3566硬件特性对评估方案的硬约束

RK3566不是通用GPU，它的NPU、DDR控制器、内存管理有独特行为，评估方案必须适配这些物理事实。首先是NPU的“批处理饥饿”特性：RK3566 NPU对batch size=1的推理效率极低，因为其硬件调度器为batch size≥4做了深度优化。我们实测同一个YOLOv5s模型，batch=1时FPS仅28.3，batch=4时飙升至92.1，但内存占用也从165MB涨到312MB。这意味着，如果你的应用是单帧检测（如扫码枪），强行用batch=4不仅浪费内存，还因等待凑够4帧而引入额外延迟。评估时必须按真实业务batch size跑，而非追求理论峰值。其次是DDR的“非对称带宽”：RK3566的LPDDR4X通道在读写方向上带宽不同，读带宽约12.8GB/s，写带宽仅8.5GB/s。模型推理中，权重读取（read-heavy）和特征图写入（write-heavy）比例失衡时，会暴露瓶颈。例如，Transformer类模型因大量KV cache写入，在RK3566上写带宽常成瓶颈，FPS卡在35左右，而同等FLOPs的CNN模型可达65FPS。eval_perf默认用随机输入，无法暴露这种访存模式差异。最后是内存管理的“两级分配”：RKNN Runtime先向Linux kernel申请大块内存（通过ion driver），再在用户态做细粒度分配。kernel层分配失败（out of memory）和用户态分配失败（fragmentation）的日志完全不同，前者报ion_heap_alloc错误，后者报rknn_api memory alloc failed。很多工程师只看后者，忽略了kernel层已无连续大页可用。因此，评估设计的第三原则是：必须将RK3566的硬件微架构特性编码进测试用例，让评估本身成为硬件压力探测器。我们在测试脚本中强制注入三类压力源：① 模拟高写入负载（用OpenCV生成随机噪声图并cv2.imwrite到tmpfs）；② 主动制造内存碎片（循环malloc/free 1MB~8MB随机大小内存块）；③ 强制温控干预（用echo 75 > /sys/class/thermal/thermal_zone0/emul_temp模拟高温）。只有在这种“地狱模式”下活下来的模型，才配进产线。

3. 核心细节解析：性能评估的4层穿透式测量法

3.1 第一层：基础层——脱离eval_perf，手写高精度计时器

eval_perf的计时基于Python time.time()，在RK3566的ARM Cortex-A55上，其精度受系统调度干扰极大。我们实测过，同一模型连续10次eval_perf，单次推理时间标准差高达±15.3ms，而NPU硬件计时器精度是纳秒级。必须绕过Python层，直取硬件时钟。方法是利用RKNN Runtime提供的rknn_query接口，在C++侧调用RKNN_QUERY_PERF_DETAIL获取NPU内部cycle counter。具体操作：修改rknn-toolkit2源码中的eval_perf.py，在rknn.eval_perf()调用前后，插入自定义C++扩展模块，该模块通过ioctl调用RKNN_IOCTL_GET_PERF_INFO，读取npu_cycle字段。公式为：推理耗时(ms) = (npu_cycle_end - npu_cycle_start) / (NPU_FREQ_HZ / 1000)。RK3566 NPU标称频率1.2GHz，但实测在散热良好时可达1.25GHz，需用cat /sys/devices/platform/ff3f0000.npu/frequency确认实时频率。这样得到的耗时，标准差可压到±0.2ms以内。更重要的是，它能分离出纯NPU计算时间，排除数据搬运（DDR<->NPU）开销。我们曾用此法定位到一个关键问题：某模型eval_perf报告FPS 42，但硬件计时显示NPU计算仅占68%，其余32%耗在DDR搬运上。进一步用perf record -e armv8_pmuv3_000/cycles/ -g抓取，发现是输入图像预处理（BGR2RGB+Normalize）在CPU端未用NEON加速，成了瓶颈。改用OpenCV的cv2.cvtColor（自动调用NEON）后，整体FPS提升至51。所以，基础层测量不是炫技，而是为了把“模型慢”这个模糊结论，精准定位到“是NPU算得慢，还是数据搬得慢”。

3.2 第二层：时序层——构建30分钟滚动窗口性能曲线

单次FPS没有意义，必须看趋势。我们开发了一个轻量级Python守护进程，每5秒采集一次当前推理耗时（基于硬件计时器），存入环形缓冲区，维持最近360个点（即30分钟数据）。关键创新在于“滚动窗口统计法”：不只算均值，而是每分钟计算三个衍生指标：① FPS均值（反映整体水平）；② FPS标准差（反映稳定性，>3.5说明抖动严重）；③ 低于目标FPS的帧数占比（如目标30FPS，则统计<28FPS的帧占比，>5%即预警）。这个设计源于一个血泪教训：某安防项目要求30FPS，eval_perf测得32.1，上线后用户投诉“画面卡顿”。抓取30分钟数据发现，FPS均值确实是31.8，但标准差高达8.7，且每3-5分钟出现一次<15FPS的尖峰，持续2-3秒。查日志发现是红外补光灯开关瞬间，电源电压波动导致NPU短暂复位。这种瞬态问题，eval_perf的10次快照根本捕获不到。滚动窗口曲线让我们第一次看清了“性能脉搏”。实现上，用psutil.sensors_temperatures()同步采集CPU/NPU温度，用cat /proc/meminfo | grep MemAvailable监控可用内存，全部时间戳对齐。最终生成的CSV包含列：timestamp, fps_mean, fps_std, fps_under_thres, temp_npu, mem_available。用pandas绘图，横轴时间，纵轴多Y轴（FPS、温度、内存），一眼就能看出性能下跌是否与温度飙升或内存告急同步。这套方法已固化为我们的CI/CD流水线环节，任何模型PR合并前，必须通过30分钟滚动窗口测试，且三项指标全绿（std<2.0, under_thres<1%, temp<70℃）才允许合入。

3.3 第三层：压力层——四维负载注入测试框架

真实世界不会让你安静跑分。我们构建了四维负载注入框架，模拟最恶劣工况：

• 维度1：输入扰动——不只用固定input.bin，而是实时生成变异输入：① 分辨率阶梯变化（640x480 → 1280x720 → 640x480循环）；② 图像噪声注入（高斯噪声σ=0.05/0.1/0.2）；③ 全黑/全白/纯色块输入（触发NPU特殊路径）。原因：某些模型在特定输入下会触发低效分支，如YOLO的anchor匹配逻辑在全黑图上可能遍历所有grid。
• 维度2：系统竞争——用stress-ng --cpu 4 --io 2 --vm 2 --vm-bytes 512M模拟CPU/IO/内存压力，让RK3566处于75%系统负载。观察FPS衰减率，>20%即判定模型对系统扰动敏感。
• 维度3：内存压力——用dd if=/dev/urandom of=/tmp/ramdisk/bigfile bs=1M count=500在tmpfs（RAM盘）写入500MB垃圾文件，再用sync && echo 3 > /proc/sys/vm/drop_caches清缓存，制造内存紧张。此时若模型内存占用波动超±15MB，说明其内存管理鲁棒性差。
• 维度4：热力耦合——用echo 65 > /sys/class/thermal/thermal_zone0/emul_temp设定恒温，再逐步提高至80℃，每5℃停顿10分钟，记录FPS拐点。RK3566在75℃以上会强制NPU降频，FPS应平滑下跌；若出现断崖式下跌（如75℃时52FPS，76℃时骤降至28FPS），说明模型存在未优化的高功耗算子，加剧了热失控。
  这个框架不是一次跑完，而是按“单维注入→双维叠加→四维满载”渐进式执行。我们发现，80%的线上性能问题，都能在双维叠加阶段复现，比如“输入分辨率突变+系统CPU压力”组合，会放大NPU上下文切换开销，导致FPS波动翻倍。

3.4 第四层：归因层——NPU指令级性能剖析

当FPS异常时，eval_perf给不了答案，必须深入NPU指令流。RKNN SDK提供rknn_profile工具，但默认输出是晦涩的十六进制trace。我们将其封装为可读性分析器：python3 profile_analyzer.py --trace trace.bin --model model.rknn。它解析出三类关键信息：

• 算子热点：列出耗时TOP10算子，如conv2d_3x3: 18.7ms (32.1% total)，并标注其输入/输出shape、数据类型（fp16/int8）。若某个conv2d耗时异常，可检查其weight shape是否过大（如7x7卷积未被toolkit2优化）。
• 访存瓶颈：统计DDR读/写带宽占用率。若DDR read bandwidth: 92%，而DDR write bandwidth: 35%，说明是权重读取瓶颈，应考虑权重分片或缓存优化。
• 流水线气泡：显示NPU pipeline stall周期数。理想情况下stall < 5%，若stall_cycles: 12.3%，说明数据供给不足，需检查DMA配置或输入buffer预分配策略。
  我们曾用此法解决一个经典问题：onnx转rknn int8后精度下降，但profile显示int8版conv2d耗时比fp16版还高15%。深入看发现，int8版因量化参数不对齐，触发了NPU的“slow path”微码，而fp16版走的是硬件加速路径。解决方案不是调参，而是强制toolkit2用quantized_dtype='asymmetric_quantized-u8'并指定input_data_type='uint8'，让整个流程走fast path。这证明，性能评估的终极目标不是“跑多快”，而是“知道为什么快或慢”，从而指导模型重构或toolkit2参数调整。

4. 内存评估的3阶递进式测绘法

4.1 第一阶：静态内存测绘——解构.rknn文件的内存布局

eval_perf报告的“DDR: 187MB”是个黑盒总量，必须拆解。RKNN模型文件本质是序列化的内存镜像，用rknn_parser工具可导出内存布局图：rknn_parser --dump_mem_layout model.rknn > layout.txt。layout.txt包含三大部分：

• Model Code Section：NPU可执行代码段，存放编译后的kernel二进制，通常2-5MB。
• Weight Section：量化后的权重数据，是内存大头。int8模型此处为weights_size_bytes，fp16模型则翻倍。注意：toolkit2在转换时若开启do_quantization=True，会自动对权重做聚类压缩，实际size可能小于理论值。
• Runtime Memory Section：运行时动态分配区，又分两块：①static_mem：模型固有需求，如各层output buffer的最小保证空间；②dynamic_mem：推理时按需申请的临时空间，如softmax的中间缓存、RNN的hidden state。
  关键洞察在于：static_mem是刚性需求，必须在DDR中预留连续空间；dynamic_mem是弹性需求，可碎片化分配。我们曾遇到一个案例：eval_perf报DDR 192MB，但layout.txt显示static_mem=145MB，dynamic_mem=47MB。系统预留了200MB，看似足够，但static_mem要求145MB连续，而系统内存碎片化后，最大连续块仅138MB，导致加载失败。解决方案是：在板级启动脚本中，用mem=192M内核参数预留一块专用内存池，专供RKNN使用。所以，静态测绘不是看总数，而是看static_mem是否超过系统最大连续内存块。我们写了个Python脚本，自动解析layout.txt，提取static_mem值，并与cat /proc/meminfo | grep "MemTotal\|MemFree"对比，生成预警：“WARNING: static_mem (145MB) > max_contiguous_block (138MB), risk of OOM”。

4.2 第二阶：动态内存测绘——实时追踪内存分配链

静态布局是理论值，真实运行中，RKNN Runtime会根据输入shape动态调整buffer大小。必须用rknn_mem_trace工具抓取运行时内存事件：rknn_mem_trace --model model.rknn --trace_file trace.mem。trace.mem是二进制日志，我们用自研mem_tracer.py解析，生成三类视图：

• 分配时序图：X轴时间，Y轴内存地址，每条线代表一次malloc，长度为size，颜色区分来源（weight/init/output/temp）。可直观看到内存是否随推理次数线性增长（内存泄漏）或周期性脉冲（如每帧申请新temp buffer）。
• 堆栈溯源表：对每次alloc，打印调用栈，如rknn_init -> nn_layer_init -> malloc_output_buffer。若发现malloc来自nn_layer_init但size为0，说明该层output shape计算错误，需检查ONNX模型中dynamic axes定义。
• 碎片热力图：将DDR地址空间划分为1MB区块，统计每区块的alloc/free频次。高频区块（红色）是热点，易碎片化；低频区块（蓝色）是冷区，可考虑引导分配器优先使用。
  我们用此法揪出一个隐藏极深的问题：某语义分割模型在int8量化后，dynamic_mem分配频次比fp16高3倍。溯源发现，量化后某些层的output shape计算引入了浮点误差，导致ceil(height/stride)结果多算1，使output buffer多申请一行像素，累积下来，每帧多占128KB，1000帧就多占125MB，最终OOM。修复方法是在ONNX模型中显式设置output_shape = [1, C, H, W]，禁用动态推导。

4.3 第三阶：系统级内存测绘——穿透Linux Kernel的内存审计

RKNN的内存问题，50%根子在Linux kernel层。必须用/sys/kernel/debug/ion/接口审计ION内存池。步骤：

1. 启动模型前，记录基线：cat /sys/kernel/debug/ion/ion_heap_total（总池大小）、cat /sys/kernel/debug/ion/ion_heap_free（空闲大小）。
2. 运行30分钟压力测试，期间每分钟执行：cat /sys/kernel/debug/ion/ion_heap_allocated（已分配）、cat /sys/kernel/debug/ion/ion_heap_handle_count（句柄数）。
3. 测试后，对比基线，计算allocated_delta = allocated_end - allocated_start。若allocated_delta > model_static_mem * 1.1，说明有内存泄漏（句柄未释放）。
   更关键的是看handle_count：RKNN每次rknn_init创建一个ION handle，rknn_release应销毁它。若handle_count持续增长，就是典型的handle泄漏。我们曾在一个长期运行项目中发现，handle_count从初始12涨到3200，而allocated只增了8MB，说明泄漏的是轻量级handle，但累积后耗尽了ION descriptor table。根因是客户代码中rknn_release调用被异常跳过。解决方案是：在rknn_init后立即cat /sys/kernel/debug/ion/ion_heap_handle_count打点，作为泄漏检测哨兵。这套系统级测绘，把内存问题从“RKNN模块故障”定位到“Linux ION子系统资源耗尽”，为跨团队协作提供了明确依据。

5. 实操过程：从零搭建RK3566 RKNN评估流水线

5.1 环境准备与工具链定制

标准rknn-toolkit2安装包（v1.7.0）不包含我们所需的深度剖析功能，必须源码编译定制。步骤：

1. 下载rknn-toolkit2源码：git clone https://github.com/rockchip-linux/rknn-toolkit2.git，检出tagv1.7.0。
2. 修改src/python/rknn/api/rknn.py，在class RKNN中添加_get_perf_detail方法，封装RKNN_IOCTL_GET_PERF_INFO调用。
3. 修改src/python/rknn/api/rknn.py，在eval_perf函数中，替换time.time()为self._get_perf_detail()调用。
4. 编译安装：cd src && make clean && make all && cd ../.. && pip3 install -e .。

提示：编译前确保RK3566 SDK已安装，export RKNN_SDK_ROOT=/path/to/rknn-toolkit2。若遇librknnrt.so not found，需将$RKNN_SDK_ROOT/lib加入LD_LIBRARY_PATH。

同时，需准备系统级工具：

• stress-ng：apt-get install stress-ng，用于系统负载注入。
• perf：apt-get install linux-perf，用于CPU性能剖析。
• ion-dump：从Rockchip kernel源码编译，用于ION内存审计。
• 自研脚本：rolling_eval.py（滚动窗口）、load_injector.py（四维负载）、mem_tracer.py（内存追踪），全部开源在我们的GitHub仓库（链接略，按需提供）。

5.2 标准评估流程：7步走完一次完整评估

我们固化了一套7步评估流程，每次评估严格按序执行，确保可复现：

1. 冷态基线采集：板子断电重启，待温度稳定在25℃，运行eval_perf10次，记录基础FPS和内存。
2. 静态布局解析：rknn_parser --dump_mem_layout model.rknn > layout.txt，提取static_mem，与free -m对比。
3. 滚动窗口测试：python3 rolling_eval.py --model model.rknn --duration 1800（30分钟），生成perf_curve.csv。
4. 四维负载注入：依次执行load_injector.py --mode resolution_jitter、--mode cpu_stress等，每项持续10分钟，记录FPS衰减率。
5. NPU性能剖析：rknn_profile --model model.rknn --trace_file trace.bin，用profile_analyzer.py解析。
6. 内存动态追踪：rknn_mem_trace --model model.rknn --trace_file trace.mem，用mem_tracer.py生成热力图。
7. 系统级ION审计：ion-dump全程监控，测试前后对比handle_count和allocated。
   每步输出必须存档，形成评估报告模板。我们用Jinja2渲染HTML报告，自动嵌入曲线图、热力图、关键指标表格。一份完整报告包含：① 基础指标摘要（FPS均值/标准差/内存峰值）；② 滚动曲线（带温度/内存叠加）；③ 负载注入结果矩阵（4×4表格，行是负载维度，列是FPS衰减率）；④ NPU热点算子TOP5；⑤ 内存分配链关键帧截图；⑥ ION审计对比表。这份报告，就是模型能否交付的唯一通行证。

5.3 关键参数配置与实测经验

RKNN评估中，几个参数的取值直接影响结果可信度，全是血换来的经验：

• --loop参数（eval_perf的迭代次数）：绝不能用默认10次。我们设为--loop 300，确保统计显著性。实测300次后，FPS标准差收敛至±0.3ms，而10次时为±15ms。
• 输入数据格式：eval_perf默认用.bin，但.bin是raw bytes，不包含shape信息。必须用--input_format nhwc明确指定，否则RKNN Runtime可能误判channel顺序，导致内存分配错误。我们统一要求输入为.npz格式，内含input数组和shape元数据。
• 温度控制：RK3566的thermal zone 0对应CPU+NPU，zone 1对应GPU。评估时只干预zone 0，用echo 70 > /sys/class/thermal/thermal_zone0/emul_temp，避免影响GPU干扰测试。
• 内存压力基准：stress-ng --vm 2 --vm-bytes 512M中，--vm 2启2个worker，--vm-bytes 512M指每个worker申请512MB，总压1GB。RK3566板载2GB RAM，此压力恰到好处，既制造紧张又不致系统崩溃。
• 动态内存阈值：我们设定dynamic_mem波动警戒线为static_mem * 0.15。若实测dynamic_mem标准差 > 15%static_mem，即判定模型内存行为不稳定，需重构。

5.4 从评估结果反推模型与toolkit2优化方向

评估不是终点，而是优化起点。我们建立了“评估-归因-优化”闭环：

• 若NPU profile显示conv2d耗时TOP1，且stall_cycles高：优化方向是检查卷积kernel size，将7x7改为3x3+3x3级联，或启用toolkit2的advanced_optimization=True自动融合。
• 若内存测绘显示dynamic_mem异常高：检查ONNX模型中是否有Resize、Upsample等动态算子，强制用torch.nn.functional.interpolate并指定size=(H,W)固定输出shape。
• 若滚动曲线显示FPS随温度线性下跌：说明模型存在高功耗算子，用profile_analyzer.py定位后，将该层权重从int8降为fp16（quantize_inputs=['layer_name']），以降低NPU功耗。
• 若ION审计发现handle_count持续增长：在客户代码中添加atexit.register(rknn_release)，确保进程退出时强制释放。
  这个闭环，让评估从“验货”升级为“炼丹”，每一次失败的评估，都指向一条明确的优化路径。我们有个项目，经过3轮评估-优化迭代，模型从初版的“eval_perf 42FPS，但线上必崩”，最终稳定在“滚动窗口FPS均值48.2±0.8，内存峰值176MB±2MB，热态75℃下FPS 45.1”，成功交付。

6. 常见问题与排查技巧实录

6.1 “rknn 回归模型 不量化正常，int8 量化后精度下降”——这不是精度问题，是内存问题

这个热搜词背后，90%的案例其实不是精度损失，而是int8量化改变了内存访问模式，暴露出原有模型的内存缺陷。典型现象：int8版eval_perf FPS更低、内存更高，且推理结果出现大片空白（语义分割）或bbox漂移（检测）。排查步骤：

1. 先用rknn_parser --dump_mem_layout对比fp16和int8版的static_mem，若int8版static_mem暴涨（如+40MB），说明量化后某些层output buffer计算错误。
2. 用rknn_mem_trace抓取int8版的内存分配链，重点关注output_buffer的size。我们曾发现，int8量化后，某BN层的output_shape因量化scale计算误差，从[1,64,120,160]错算为[1,64,121,161]，多占一行一列，累积起来多占1.2MB/帧。
3. 解决方案不是调量化参数，而是修复ONNX模型：用onnx-simplifier简化模型，消除冗余reshape，再用onnx.shape_inference.infer_shapes强制推导shape，最后转换。实测此法让int8版static_mem回归正常，精度也同步恢复。

6.2 “yolo26n-sem rknn”在RK3566上内存爆满——语义分割头的内存黑洞

yolo26n-sem这类模型，分割头常含nn.Upsample或F.interpolate，其内存占用与输入分辨率呈平方关系。eval_perf用640x480输入，内存OK；但真实场景用1280x720，内存直接翻2.25倍。排查技巧：

• 在rknn_toolkit2转换时，加参数--input_shape "[1,3,1280,720]"，强制toolkit2按最大分辨率计算buffer。
• 用profile_analyzer.py看Upsample算子的input_shape和output_shape，若output远大于input，说明上采样倍数过高。
• 终极方案：将分割头从模型中剥离，用OpenCV的cv2.resize在CPU端后处理，虽然FPS降2-3，但内存节省40MB以上，且更稳定。

6.3 “搭建rknn-toolkit2”时编译失败——缺失Rockchip私有库

常见错误：undefined reference to 'rkmedia_*'或'rknn_*'。这不是toolkit2问题，而是未正确链接Rockchip SDK。必须：

1. 从Rockchip官网下载rknn-toolkit2-sdk（非toolkit2源码），解压后export RKNN_SDK_ROOT=/path/to/sdk。
2. 确保$RKNN_SDK_ROOT/lib下有librknnrt.so、librkmedia.so等。
3. 编译时，在setup.py的ext_modules中，libraries参数必须包含['rknnrt', 'rkmedia']，library_dirs包含$RKNN_SDK_ROOT/lib。

注意：Rockchip SDK版本必须与RK3566固件版本严格匹配，v1.7.0 toolkit2需搭配SDK v1.7.x，混用必失败