📚 课程目录第3章性能评估与基准测试

3、性能评估与基准测试：如何准确测量推理延迟、吞吐量、内存占用，使用rknn-toolkit2和rknn_perf工具进行性能分析

在RKNN模型部署流程中，性能评估与基准测试是连接模型转换与硬件适配的关键环节。很多开发者完成模型转换后，发现NPU推理速度远低于预期，却无法定位瓶颈究竟出在模型结构、量化精度、算子支持还是内存带宽上。本章将系统讲解如何利用rknn-toolkit2的Python接口和rknn_perf命令行工具，建立一套可重复、可对比、可定位的性能基准测试方法，涵盖延迟、吞吐量、内存占用三大核心指标，并给出从测量到分析的完整闭环。

3.1 核心原理：性能指标的定义与测量边界

在RKNN场景下，性能测量不能简单等同于“跑一次看时间”。我们需要区分三个层次：模型推理时间（NPU执行计算图的时间）、端到端延迟（从输入数据到达应用层到输出结果返回的总时间，包含前后处理、数据拷贝、内存分配等）、以及系统吞吐量（单位时间内处理的样本数量）。RKNN模型转换后，推理延迟通常指NPU执行推理的时间，但实际部署中，CPU与NPU之间的数据搬运往往占据总延迟的30%-50%，这是初学者最容易忽略的盲区。

测量边界决定了数据的可信度。例如，rknn-toolkit2的模拟器（Simulator）运行在x86主机上，其延迟数据仅用于验证模型正确性和估算NPU计算量，不能作为真实板端性能依据。而rknn_perf工具在板端运行时，可以获取每个算子的执行时间、NPU利用率、内存带宽等硬件级数据，这才是调优的权威依据。此外，测量时的预热（Warm-up）机制至关重要——NPU首次推理会触发权重加载、内存池初始化等操作，若不进行预热，测得的延迟可能比稳态值高出2-5倍。

  关键认知：性能基准测试的目标不是得到一个“好看的数字”，而是建立可复现的测量环境，使得每次修改模型或配置后，能够通过对比数据定位性能变化的原因。因此，固定输入尺寸、固定预处理流程、固定推理次数、固定线程数，是保证测量有效性的前提。

3.2 判断方法与操作流程：从工具链到板端实测

完整的性能评估流程分为三个阶段：主机端预评估、板端基准测试、瓶颈定位分析。每个阶段使用的工具和关注指标不同，下面逐一展开。

3.2.1 主机端预评估：rknn-toolkit2的Python接口

在模型转换完成后，首先使用rknn-toolkit2的Python API进行快速验证。以下代码展示了如何加载RKNN模型并执行推理计时：

import numpy as np
import time
from rknn.api import RKNN

rknn = RKNN()
# 加载已转换的RKNN模型
ret = rknn.load_rknn('./model.rknn')
if ret != 0:
    print('模型加载失败')
    exit(-1)

# 初始化运行时环境，target=None表示模拟器
ret = rknn.init_runtime(target=None)
if ret != 0:
    print('运行时初始化失败')
    exit(-1)

# 构造固定输入（与训练时预处理一致）
input_data = np.random.randn(1, 3, 224, 224).astype(np.float32)

# 预热：执行3次推理，排除初始化影响
for _ in range(3):
    outputs = rknn.inference(inputs=[input_data])

# 正式测量：执行100次，统计延迟
times = []
for _ in range(100):
    t0 = time.perf_counter()
    outputs = rknn.inference(inputs=[input_data])
    t1 = time.perf_counter()
    times.append((t1 - t0) * 1000)  # 转换为毫秒

times.sort()
avg_latency = np.mean(times)
p50 = times[50]
p95 = times[95]
print(f'平均延迟: {avg_latency:.2f} ms')
print(f'P50延迟: {p50:.2f} ms')
print(f'P95延迟: {p95:.2f} ms')

这段代码的核心在于：固定输入张量、预热、多次测量并统计百分位数。P95比平均值更能反映真实用户体验，因为NPU调度存在偶发抖动。需要注意的是，模拟器模式下，inference()函数内部会模拟NPU计算，但内存访问模式与真实硬件差异较大，因此该数据仅用于快速验证模型是否可运行、延迟量级是否合理。

3.2.2 板端基准测试：rknn_perf工具

rknn_perf是RKNN工具链中专门用于板端性能剖析的命令行工具。它将RKNN模型部署到目标设备上，逐层执行并记录每个算子的耗时、NPU利用率、内存读写量。使用方法如下：

# 将模型和工具推送到开发板
adb push model.rknn /data/local/tmp/
adb push rknn_perf /data/local/tmp/
adb shell chmod +x /data/local/tmp/rknn_perf

# 执行性能剖析，输出详细报告
adb shell /data/local/tmp/rknn_perf -m /data/local/tmp/model.rknn \
    -i input.bin -o output.bin -r 10 -t 4

参数说明：-m指定模型路径，-i输入数据文件（二进制格式），-r重复次数，-t线程数。执行后，rknn_perf会生成一份包含每个算子名称、类型、耗时（微秒）、NPU周期数、DDR读写量的报告。这份报告是定位性能瓶颈的核心依据。

测量阶段	工具	关键指标	数据可信度	主要用途
主机端预评估	rknn-toolkit2 Python API	推理延迟（模拟）	低（仅参考）	验证模型可运行性、快速迭代
板端基准测试	rknn_perf	算子耗时、NPU利用率、内存带宽	高（硬件实测）	定位瓶颈算子、评估优化效果
端到端延迟	自定义C++/Python脚本	总延迟、数据拷贝时间	高（真实部署）	评估用户体验、系统级优化

3.3 案例拆解：从“延迟超标”到“瓶颈定位”的完整闭环

某安防检测项目使用RK3588平台部署YOLOv5s模型，转换后实测单帧推理延迟为45ms，而项目要求是30ms以内。开发者最初怀疑是量化精度问题，但通过rknn_perf分析后发现，瓶颈并非计算量，而是数据搬运和算子调度。

初始现象与数据：使用rknn_perf对模型进行剖析，报告显示Conv_0算子耗时2.1ms，Conv_15算子耗时3.8ms，但Transpose算子耗时高达12.5ms，且DDR读取量达到480MB/s。进一步检查发现，模型输入为RGB三通道，但NPU内部数据布局要求NHWC格式，导致每次推理都需要进行通道重排。

分析判断过程：通过对比rknn-toolkit2的模拟器输出，发现模拟器延迟为28ms，而板端为45ms，差异主要来自内存访问模式。模拟器不模拟DDR带宽限制，因此无法暴露数据搬运瓶颈。结合rknn_perf的算子耗时分布，确认Transpose算子是主要瓶颈。

实际操作步骤：首先，在模型转换时设置optimization_level=3，让RKNN编译器自动融合Transpose到相邻卷积中；其次，将输入预处理从RGB改为BGR（匹配NPU内部布局），减少一次通道转换；最后，在rknn_perf中开启--memory-reuse标志，复用中间张量内存。

结果对比：优化后，Transpose算子耗时从12.5ms降至0.8ms，整体推理延迟从45ms降至26ms，满足项目要求。内存峰值从620MB降至410MB，吞吐量从22FPS提升至38FPS。

复盘经验：性能瓶颈往往不在计算密集的卷积层，而在数据布局转换、内存拷贝等“隐形”操作。rknn_perf的算子级报告是定位这类问题的唯一可靠手段。此外，优化时优先调整模型转换参数（如优化级别、量化策略），其次才考虑修改网络结构。

常见误区：不要仅依赖主机端模拟器的延迟数据做性能判断。模拟器无法反映NPU的真实调度延迟、DDR带宽竞争和缓存命中率。所有性能优化决策必须以rknn_perf在板端实测的数据为准。

3.4 内存占用测量与优化策略

内存占用是嵌入式部署的硬约束。RKNN模型的内存消耗分为三部分：模型权重（静态分配）、中间特征图（动态分配）、运行时缓冲区（输入输出、临时计算）。rknn-toolkit2提供了内存分析接口，可以在转换时输出内存估算：

# 在转换时获取内存信息
rknn.config(mean_values=[[0,0,0]], std_values=[[255,255,255]], 
            target_platform='rk3588', optimization_level=3)
ret = rknn.load_onnx(model='yolov5s.onnx')
ret = rknn.build(do_quantization=True, dataset='dataset.txt')
# 输出内存使用报告
memory_info = rknn.get_memory_info()
print(f'权重内存: {memory_info["weight_size"] / 1024:.1f} KB')
print(f'中间张量内存: {memory_info["tensor_size"] / 1024:.1f} KB')
print(f'总内存: {memory_info["total_size"] / 1024:.1f} KB')

在板端，可以通过cat /proc/meminfo或使用rknn_perf --memory-profile获取实际内存峰值。优化内存占用的常用手段包括：使用--memory-reuse复用中间张量、减少输入批次大小、将权重从FP16量化为INT8（可减少50%权重内存）、以及调整NPU与CPU之间的内存分配策略。

经验提醒：测量吞吐量时，不要使用单线程串行推理。RKNN支持多线程并行推理，在RK3588上开启4线程可将吞吐量提升2-3倍。但线程数并非越多越好，超过NPU核心数后，线程切换开销会抵消并行收益。建议测试1/2/4/8线程下的吞吐量，绘制曲线找到拐点。

3.5 常见误区与总结复盘

在性能评估实践中，以下误区会导致优化方向错误：

忽略预热直接计时：首次推理包含权重加载和内存初始化，延迟可能是稳态的3倍以上。必须预热至少3次后再开始计时。
使用随机输入而非真实数据：随机输入可能导致NPU某些算子的分支预测失效，测得的延迟偏高。应使用与训练集分布一致的验证集图片。
只关注平均延迟忽略抖动：NPU调度受中断、内存竞争影响，P95延迟可能比平均值高20%-50%。对于实时系统，必须关注P95甚至P99。
混淆模拟器与板端数据：模拟器适合功能验证，性能数据仅作参考。所有优化决策必须基于rknn_perf的板端实测。
忽略数据拷贝时间：在端到端延迟中，CPU与NPU之间的数据搬运（如cv::Mat到rknn_input）可能占总延迟的30%以上。使用零拷贝接口（如DMA）可显著降低这部分开销。

总结本章核心要点：性能评估不是一次性的测量活动，而是贯穿模型优化全周期的反馈机制。建立标准化的测量脚本、固定测试条件、保存历史数据，才能在每次修改后快速判断性能变化。rknn-toolkit2负责“能不能跑”，rknn_perf负责“哪里慢”，两者结合才能形成完整的性能优化闭环。下一阶段，我们将基于这些测量数据，深入探讨算子级优化的具体技术。