边缘设备AI：瑞芯微RKNN/NPU

CH-33-02-024·约 18 分钟·物联网与边缘智能·更新 2026-08-13

想象你是一位米其林三星大厨，想把招牌分子料理搬到夜市小摊上。菜谱写得再高级，摊位上那台智能灶台也只认固定的火候档位和标准化动作。你当然不能把厚厚一本私房菜谱直接塞进灶台，你需要一位翻译官：把“低温慢煮”翻译成“隔水炖”，把“分子料理”翻译成“勾芡”，把精确到克的调料换成“一勺”“半勺”。在边缘AI世界里，云端训练好的深度学习模型就是那本豪华菜谱，瑞芯微RKNN工具链就是那位翻译官，而NPU就是只会照菜谱执行的智能灶台。本文会用这条“夜市摆摊”的线索，讲清楚大模型如何从云端走进RK3588边缘设备：模型转换流程、算子兼容处理、多核NPU调度，再到智能安防与边缘网关的实际部署。

岗位关联

掌握RKNN/NPU，就等于掌握了把云端AI菜谱移植到千万边缘设备上的“翻译手艺”，这是边缘AI工程师、嵌入式AI开发者最核心的竞争力之一。

可视化演示
边缘推理基础
RKNN开发工具
模型转换流程
算子兼容处理
多核NPU调度
RK3588部署
安防方案实战
边缘网关方案
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示瑞芯微RKNN工具链将ONNX模型转换为.rknn格式、算子兼容性映射及RK3588三核NPU任务调度的完整流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

ONNX→RKNN模型转换流程 ONNX源模型 RKNN工具链 rknn.build(doQuant=True) FP32转INT8量化部署

边缘推理基础

把菜谱从米其林餐厅搬到夜市，最急迫的理由是客人等不了两小时。如果每道菜都要打电话回总店问一次做法，夜市早就排起长队。云端推理就是这种“打电话问总店”的模式：摄像头把画面传到云端，云端跑完模型再把结果传回来。网络一抖动，视频卡顿，隐私数据也暴露在路上。边缘推理则是在摊位本地就把菜做好，端到端时延大幅缩短，断网也能营业。

瑞芯微RK3588内置的NPU就是专门负责“颠勺”的智能灶台。CPU像厨师的双手，能处理各种杂活但重体力活效率不高；GPU像一把大火，能炒很多菜但功耗高；NPU则针对卷积、矩阵乘法这类规律动作做了硬件级优化，单位功耗下吞吐量远高于前两者。当然，夜市灶台空间有限，模型不能原封不动搬过来，这正是后文RKNN工具链要解决的问题。

在边缘设备上，一次完整推理的时间可以拆成三部分：

理解了这三段时间，你就明白为什么安防摄像头、边缘网关都拼命把模型往本地搬：客人要的不是“米其林名头”，而是“马上能吃到的热乎菜”。

\begin{aligned}T_{\text{edge}} &= T_{\text{pre}} + T_{\text{infer}} + T_{\text{post}}\\T_{\text{cloud}} &= T_{\text{pre}} + T_{\text{net}} + T_{\text{infer}} + T_{\text{post}}\end{aligned}

边缘推理省掉了网络传输时间，相当于在夜市本地备菜，不必每次下单都打电话问总店。

预处理时间把原始画面缩放、归一化、调成网络需要的维度，这是每道菜上锅前的“切菜备料”。
$T_{\text{pre}}$
网络传输时间视频和结果在设备与云端之间往返的时间，相当于打电话问总店的路程时间。
$T_{\text{net}}$
模型推理时间NPU真正执行卷积、池化等算子的时间，相当于灶台上翻炒炖煮的“烹饪时间”。
$T_{\text{infer}}$
后处理时间对网络输出做非极大值抑制、阈值过滤、坐标还原，相当于出锅装盘和审核摆盘。
$T_{\text{post}}$

RKNN开发工具

翻译官不能只靠一张嘴，还得有词典、语法手册和校对工具。瑞芯微的RKNN工具链也一样，核心是“三件套”：rknn-toolkit2负责把训练好的模型编译成RKNN格式，相当于把菜谱翻译成灶台指令；RKNN Runtime负责在设备上读取并执行RKNN模型，相当于灶台内置的菜谱播放器；RKNPU驱动则是灶台和煤气管道之间的阀门，让硬件真正运转起来。

开发者的日常流程是先装好Python环境，用pip安装rknn-toolkit2，再在开发板上烧录配套固件。最容易踩坑的是版本配套：翻译官词典是2024年新版，灶台固件却还是2022年老版，两边对同一个词的理解完全不同。因此官方文档通常要求工具链、运行时、驱动三者版本严格匹配。

版本匹配关系可以写成一句“能不能开工”的判断：

所以拿到一块新开发板，第一件事不是急着跑模型，而是先确认工具链版本、固件版本、驱动版本三者“三合一”。版本统一了，后面才不会出现“翻译官说人话，灶台当鸟语”的尴尬。

M = \begin{cases} 1, & V_{\text{toolkit}} = V_{\text{runtime}} \\ 0, & V_{\text{toolkit}} \ne V_{\text{runtime}} \end{cases}

翻译官和灶台固件必须说同一种语言，否则转换出来的模型格式再对，设备也“看不明白”。

工具链版本rknn-toolkit2的版本号，好比翻译官的词典版本。
$V_{\text{toolkit}}$
运行时版本设备端RKNN Runtime的版本号，好比灶台固件能识别的指令集版本。
$V_{\text{runtime}}$
版本相等两者必须一致，翻译官翻译出来的每句话，灶台才都能执行。
$V_{\text{toolkit}} = V_{\text{runtime}}$
匹配标志等于1表示可以正常开发，等于0表示需要先统一版本再继续。
$M$

模型转换流程

米其林菜谱通常用西式术语写成，夜市灶台看不懂。翻译官的第一步，是先把菜谱誊抄成行业通用的“烹调规范书”，也就是ONNX格式；接着再把规范书翻译成灶台的“机器动作”，也就是RKNN格式。两条腿走路，既保留了原始模型的兼容性，又能被瑞芯微设备识别。

具体来说，转换流程分为四步：第一步，准备好训练好的PyTorch或TensorFlow模型，导出为ONNX；第二步，在rknn-toolkit2中调用rknn.config配置输入图像尺寸、量化方式；第三步，用rknn.load_onnx加载ONNX模型，再调用rknn.build完成编译，最终用rknn.export_rknn导出RKNN文件；第四步，在开发板上用rknn.init_runtime加载模型，跑一张测试图验证输出是否符合预期。

模型转换时最容易被忽略的是输入数据的预处理一致性。训练时图片要减均值再除标准差，转换后的模型也需要一模一样的前处理：

转换完成后，建议先在板上用同一张图对比原始模型和RKNN模型的输出。如果结果差距过大，可以检查预处理参数、量化配置和输入布局，把问题定位在“翻译没听懂”还是“灶台没烧透”。

x_{\text{input}} = \frac{x_{\text{pixel}} - \mu}{\sigma}

这道公式相当于告诉灶台“所有食材在上锅前都要先洗好切块”，如果训练和部署的预处理不一致，模型精度就像菜里盐放重了，全盘变味。

像素值原始图像每个通道的数值，范围通常是0到255，相当于买回来的带皮原食材。
$x_{\text{pixel}}$
均值训练数据集的通道均值，相当于这批食材的“正常含水量”。
$\mu$
标准差训练数据集像素值的分布宽度，相当于食材大小的波动范围。
$\sigma$
归一化结果减去均值再除以标准差后得到的标准输入，灶台只认这种统一规格的料。
$x_{\text{input}} = \frac{x_{\text{pixel}} - \mu}{\sigma}$

算子兼容处理

有些米其林工序，夜市灶台根本做不到。比如“液氮急冻”这一招，小摊没有液氮罐。翻译官的解决办法是改写工序：用“冰箱冷冻”代替“液氮急冻”，或者把整道菜重构成更朴素的版本。在NPU世界里，这些“招式”就是算子，比如卷积、池化、归一化、激活函数。NPU并不是每个算子都有硬件加速单元，遇到不支持的操作，就需要做算子改写。

瑞芯微提供了一张算子支持列表。开发者转换模型时，如果遇到不支持的算子，通常有三种应对方式：一是把一个大算子拆成多个支持的小算子；二是把该层回退到CPU执行，让NPU和CPU协同工作；三是修改网络结构，换用更常见的算子组合。第三种方式最彻底，但需要重新训练，成本最高。

量化则是另一种“降本增效”的手法。NPU为了省内存，常把浮点权重压缩成int8整数，就像把精确定到克的调料改成“半勺”“一勺”。量化公式是：

算子兼容和量化精度是一体两面。碰上精度掉点，不要急着怀疑食材，先用逐层输出对比定位是哪一步翻译变了味：是算子替换引入了差异，还是量化把关键层的信息“磨”掉了。

q = \mathrm{round}\left(\frac{r}{S} + Z\right)

公式里的S是量化步长，Z是零点偏移，真实浮点数r经过缩放和平移后四舍五入，变成灶台能读的整数刻度。

真实值原始的浮点权重或激活值，相当于菜谱上精确的克数。
$r$
缩放比例把浮点范围映射到int8整数范围的比例因子，相当于“一勺等于多少克”。
$S = \frac{r_{\max} - r_{\min}}{255}$
零点偏移浮点0值对应的整数点，相当于量杯上的“0刻度线”在哪里。
$Z$
四舍五入取整round把连续的浮点数映射到离散整数，必然带来极小的量化误差。
$\mathrm{round}\left(\frac{r}{S} + Z\right)$

多核NPU调度

夜市生意火爆时，一个灶口根本忙不过来。RK3588的NPU内部有三个核心，相当于三个灶口。你可以只开一个灶口慢慢炒，也可以三个灶口同时开工：一个炒饭、一个煲汤、一个蒸菜。RKNN工具链通过核心掩码来指定任务跑在哪个核上，比如RKNN_NPU_CORE_0、RKNN_NPU_CORE_1、RKNN_NPU_CORE_2，也可以选自动调度模式。

多核调度不是“核越多越快”这么简单。翻台率受制于最慢的环节：如果三个灶口分工不均，一个灶口忙到冒烟，另外两个闲得擦桌子，整体速度并不会提升。此外，切菜、装盘这些串行工序仍然要一个人做。阿姆达尔定律专门描述这种“并行收益递减”现象：

实际开发中，还要考虑核间通信、DDR带宽和功耗。开三个核可能把整板功耗推到极限，散热跟不上时反而会降频。所以多核调度是一场“上菜速度、电费、设备寿命”的三方谈判，需要反复压测找平衡点。

S_p = \frac{T_1}{T_p} = \frac{1}{(1-f)+\frac{f}{p}}

如果整个流程中有40%的时间必须串行，那么哪怕核数无限增加，理论加速最多也只有2.5倍；三个灶口解决不了“备菜必须一个人做”的瓶颈。

单核执行时间只用一个NPU核跑完整段推理的时间，相当于只有一个灶口做完全部菜。
$T_1$
多核执行时间用p个核并行后的总时间，相当于三个灶口一起开火。
$T_p$
可并行比例能被多个核分担的工作占比，比如多路视频的各帧推理。
$f$
核数参与并行计算的NPU核心数量。
$p$
加速比多核相对单核的倍速提升，理想情况下接近1/(1-f)。
$S_p$

RK3588部署

菜谱翻译好了，真正上灶还要接通燃气、固定锅位、备好调料。RK3588部署的第一步是硬件接口接入：MIPI-CSI接摄像头，以太网口接视频流，USB/PCIe接扩展设备。硬件通路打通后，软件层通过RKNN Runtime调用NPU，C API和Python API都有完整封装。

推理引擎调用的关键路径是：rknn_init初始化上下文，rknn_inputs_set把输入数据送入NPU，rknn_run触发推理，rknn_outputs_get取回结果。每一次调用都像餐厅里“下单—炒菜—上菜”的完整循环。为了减少等待，RKNN还支持零拷贝内存，让CPU和NPU共享同一块物理内存，省掉“把菜从A桌端到B桌”的搬运时间。

部署后必须做性能压力测试，最核心的指标是端到端帧率：

部署完成后，建议用多路视频同时跑压力测试，观察CPU占用率、NPU占用率、内存带宽和板卡温度。任何一路变成瓶颈，都可能让整个系统从“流畅营业”滑向“排队瘫痪”。

\mathrm{FPS} = \frac{1}{T_{\text{pre}} + T_{\text{infer}} + T_{\text{post}} + T_{\text{copy}}}

“能跑通”不等于“跑得动”，如果每帧要花200毫秒，那一路视频最多只能跑到5帧；只有把四段时间都压下来，多路视频才能真正并行。

预处理时间图像缩放、格式转换、归一化的耗时。
$T_{\text{pre}}$
推理时间NPU执行算子网络的耗时，通常是整条链路的大头。
$T_{\text{infer}}$
后处理时间解码输出、画框、过滤结果的耗时。
$T_{\text{post}}$
拷贝时间输入输出数据在CPU与NPU之间搬运的耗时，零拷贝可以显著压小这一项。
$T_{\text{copy}}$
帧率一秒钟能处理多少帧图像，是边缘设备“接待能力”的直接体现。
$\mathrm{FPS}$

安防方案实战

智能安防是RK3588最典型的落地场景之一。想象夜市摊口装了监控摄像头，老板想自动识别“谁在偷东西”“谁在排队超时”。这套系统的关键不是把每帧视频都传回云端，而是在设备端完成人脸抓拍、人体检测和行为分析。

实际安防流程一般是：摄像头通过MIPI-CSI或RTSP接入，RK3588先做视频解码，再送进RKNN模型做人脸检测，检测到人脸后送入质量评估模块去模糊、去重，最后只把清晰且符合条件的人脸截图上报。这样一来，原本需要传输几小时视频的带宽压力，被压缩成几张关键人脸图片。

安防系统最常见的指标是误检率。试想系统把电线杆当成行人，就会反复触发报警，让老板烦不胜烦。误检率的定义是：

在RK3588上做安防调优，可以从三方面入手：降低输入分辨率，比如从1080P降到720P；使用隔帧检测，比如每三帧才检测一次；把不同路的视频分配到不同的NPU核心。误检漏检排查时，先收集现场失败样本，再对比模型输出和真实标注，用数据说话，而不是盲目调整阈值。

\mathrm{FAR} = \frac{N_{\text{false}}}{N_{\text{detect}}}

误检率等于“认错的人数”除以“所有被认出来的人数”。调参时通常先调检测置信度阈值：阈值太高会漏检，太低会误检，就像夜市保安既不能太迟钝，也不能风声鹤唳。

误检数量被模型错误识别为目标的样本数，比如把垃圾桶认成人。
$N_{\text{false}}$
总检出数量模型输出为正例的样本总数。
$N_{\text{detect}}$
误检率误检数量占总检出数量的比例，这个值越低，系统报警越可信。
$\mathrm{FAR} = \frac{N_{\text{false}}}{N_{\text{detect}}}$

边缘网关方案

如果说安防是单点监控，边缘网关就是夜市摊位的中枢管理员。它不仅要看摄像头，还要管烟雾报警器、门禁、温湿度传感器和广播喇叭。多路视频、多类传感器、多条联动规则，全部汇入一台RK3588网关，在本地完成决策。

边缘网关的典型架构是：RTSP拉流模块接入多路摄像头，解码后送入RKNN推理引擎做结构化分析，结果交给规则引擎判断是否触发报警。规则引擎就像摊位管理员手里的“标准作业手册”：如果画面里出现烟火，就联动断电并播报警告；如果检测到人员摔倒，就通知管理人员。这些规则全部在本地运行，断网也不会失守。

网关长期无人值守，可用性尤其重要。假设设备平均跑1000小时才坏一次，坏了要10小时才修好，可用性计算如下：

边缘网关的维护升级策略还包含模型热更新：RKNN模型文件可以打包成版本，通过管理平台下发给网关，网关收到后切换到新模型再重启推理服务。整个过程像给摊位换新菜谱，但不用把整台灶台搬回工厂。

A = \frac{\mathrm{MTBF}}{\mathrm{MTBF} + \mathrm{MTTR}}

MTBF是平均无故障时间，MTTR是平均修复时间。提升可用性有两个方向：让设备更不容易坏，或者让设备坏得更快被修复；对边缘网关来说，支持远程OTA升级和自动重启机制尤为关键。

平均无故障时间设备两次故障之间的平均工作时间，相当于摊位设备“皮实程度”。
$\mathrm{MTBF}$
平均修复时间从故障发生到恢复服务平均需要的时间，相当于师傅上门维修的速度。
$\mathrm{MTTR}$
可用性设备正常运行时间占总运行时间的比例，越接近1说明系统越可靠。
$A = \frac{\mathrm{MTBF}}{\mathrm{MTBF} + \mathrm{MTTR}}$

AI 应用场景

RK3588智能安防抓拍盒

阶段：模型转换与边缘部署

解决的问题：传统安防方案把全部视频回传云端，消耗带宽大、时延高，且人脸等敏感数据存在隐私风险。RK3588在设备端完成人脸检测、抓拍、质量过滤，只上传有效截图。

具体案例：园区出入口部署RK3588智能盒，接入四路摄像头。开发阶段把YOLOv5模型导出ONNX，经rknn-toolkit2转换为RKNN格式并开启int8量化，部署后在NPU三核上并行处理四路视频流，端到端抓拍帧率达到25 FPS。

工厂边缘网关质检与联动

阶段：多核调度与网关集成

解决的问题：工业产线要求毫秒级响应，不能依赖云端；同时需要与PLC、报警器等设备联动。边缘网关在本地运行质检模型，并把判定结果通过规则引擎下发到执行机构。

具体案例：某电子元件工厂在RK3588网关接入两路工业相机，模型检测元件表面的划痕和污点。遇到不合格品时，网关直接控制机械臂剔除，同时把缺陷图片存入本地数据库。断网期间产线照常运行，网络恢复后自动同步日志。

Python 演示

python43 行

import numpy as np class RKNNModelSim:    def __init__(self, source="float_model"):        self.source = source        self.params = {}        self.quantized = {}     def load_weights(self, size=16):        rng = np.random.default_rng(42)        self.params["weight"] = rng.normal(0, 1, size)        self.params["bias"] = rng.normal(0, 0.5, size)        return self.params     def quantize_params(self, bits=8):        w = self.params["weight"]        amax = np.max(np.abs(w))        scale = amax / (2 ** (bits - 1) - 1)        zero_point = 0        q = np.clip(np.round(w / scale), -128, 127).astype(np.int8)        self.quantized["scale"] = scale        self.quantized["zero_point"] = zero_point        self.quantized["weight"] = q        return q     def simulate_infer(self, x):        scale = self.quantized["scale"]        w = self.quantized["weight"].astype(np.float32) * scale        return np.dot(x, w) + self.params["bias"] * 0.01  def run_convert_flow():    model = RKNNModelSim("pytorch_demo")    model.load_weights(16)    q = model.quantize_params()    x = np.ones((1, 16), dtype=np.float32)    y = model.simulate_infer(x)    print("quantized weight sample:", q[:4])    print("inference output:", y)  if __name__ == "__main__":    run_convert_flow()

目的：用一个迷你模型演示浮点权重量化为int8并还原推理结果的过程，相当于把菜谱中的克数换成“勺数”再炒一遍。

rng = np.random.default_rng(42)生成可复现的随机权重，模拟训练好的浮点模型参数。
amax = np.max(np.abs(w))找出权重绝对值的最大值，决定量化范围。
scale = amax / (2 ** (bits - 1) - 1)计算量化步长S，也就是“一勺对应多少克”。
q = np.clip(np.round(w / scale), -128, 127).astype(np.int8)浮点权重除以S后四舍五入并截断到int8范围。
model.quantize_params()调用量化方法，产出scale、zero_point和量化后的权重。
model.simulate_infer(x)先把量化权重反量化回浮点，再执行矩阵乘法模拟NPU推理。

常见误区

误区“我把PyTorch模型导出成ONNX，再在代码里调用export_rknn，这不就是换了个格式吗？应该很快吧。”初学者常把模型转换当成文件重命名。

正解RKNN转换本质上是给模型做一次“整容级编译”：算子映射、融合、剪枝、量化、内存布局优化全都在这一步完成。就像翻译官不是逐字翻译，而是把整道菜重新编排成灶台能执行的工序。文件后缀只是最终包装，前面的编译过程才是核心。

为何常见：因为工具链屏蔽了底层细节，调用几个API就得到.rknn文件，容易让人误以为只是格式变化。

误区“我在电脑上训练好的模型，只要转成RKNN，NPU就应该能跑，算子应该都能自动支持。”

正解NPU硬件加速的算子种类有限。遇到不支持的算子，必须替换、拆分或回退CPU执行。就像夜市灶台没有蒸汽烤箱，你不能硬塞一道需要蒸汽烤箱的菜，只能换做法。开发前应查阅RKNN算子支持列表，提前评估模型可转换性。

为何常见：深度框架用起来很方便，让人忽略了硬件加速器“只会特定动作”的本质。

误区“RK3588有三个NPU核，开三个核应该比一个核快三倍，否则就是工具链有问题。”

正解多核加速受阿姆达尔定律约束，串行部分、数据搬运、核间通信都会拉低加速比。三核并行能达到2倍以上已经是优秀结果。就像三个灶口同时炒菜，备菜、装盘、洗锅的人仍然只有一个。

为何常见：人直觉上认为“人多力量大”，忽略了并行任务之间的协作成本。

误区“int8量化就是把浮点数字取整，精度肯定损失很大，所以我不敢用。”

正解合理的量化配置会先做校准统计，计算合适的缩放比例和零点偏移，把精度损失控制在1%以内。量化误差更像“用半勺盐代替3克盐”，口味会变，但不至于难吃。对边缘设备来说，int8换来的是内存减半、速度翻倍，收益远大于损失。

为何常见：初学者一看到“四舍五入”就联想到精度灾难，忽略了校准和per-channel量化等补偿手段。

误区“RKNN模型能跑了就行，图片放进去直接出结果，缩放和归一化应该是模型自己完成的。”

正解RKNN通常不包含你的归一化逻辑。训练时的mean/std、BGR/RGB通道顺序、resize尺寸，部署时必须在前后处理代码里手动复现。预处理不一致会导致“菜谱是对的，但上锅前少洗了一次菜”，输出结果完全走样。

为何常见：因为训练框架的数据加载器自动做了预处理，开发者没有意识到这些“隐藏步骤”也需要带到部署端。

面试题

Q1. 在RKNN工具链中，负责把模型编译成NPU可执行格式的核心组件是？

单选题 · easy

A.rknn-toolkit2← 正确答案
B.视频解码器
C.边缘网关
D.温度传感器

答案：A。rknn-toolkit2负责模型转换和编译，相当于翻译官。视频解码器、边缘网关、温度传感器都不是模型编译组件，它们只是部署环节中的配套设备。

Q2. 将PyTorch模型转换为RKNN模型，常见的第一步是？

单选题 · mid

A.导出为ONNX中间格式← 正确答案
B.直接修改文件后缀
C.将模型上传到云端
D.跳过所有算子检查

答案：A。PyTorch模型通常先导出为ONNX，再交给rknn-toolkit2转换成RKNN。直接改后缀、上传云端、跳过算子检查都不是合法流程，也不符合RKNN工具链的标准处理逻辑。

Q3. 量化公式 q = round(r/S + Z) 中，字母S代表什么？

单选题 · mid

A.权重矩阵的均值
B.缩放比例或量化步长← 正确答案
C.零点偏移量
D.模型训练轮数

答案：B。S是缩放比例，相当于“一勺对应多少克”；Z是零点偏移，对应量杯的刻度线。均值、训练轮数与量化公式无关，S和Z才是浮点转整数的两个关键参数。

Q4. RK3588内置NPU的算力大约是多少？

单选题 · easy

A.3 TOPS
B.6 TOPS← 正确答案
C.12 TOPS
D.20 TOPS

答案：B。RK3588的NPU算力约为6 TOPS，适合多路轻量级视觉模型推理。3 TOPS偏低，12和20 TOPS通常对应更高端平台，不是RK3588的标称参数。

Q5. 边缘推理相比云端推理的优势包括哪些？

多选题 · easy

A.降低网络传输时延← 正确答案
B.保护本地数据隐私← 正确答案
C.完全不受功耗限制
D.断网时仍可工作← 正确答案

答案：ABD。边缘推理把计算放在本地，省去网络传输，降低时延并减少数据外泄风险；设备断网时推理服务也能继续运行。C错误，边缘设备功耗受限，恰恰需要做功耗优化。

Q6. 遇到RKNN不支持的算子，可以采取哪些处理办法？

多选题 · mid

A.把算子拆成等价组合← 正确答案
B.让该层回退到CPU执行← 正确答案
C.直接忽略该算子
D.重新设计网络结构← 正确答案

答案：ABD。不支持的算子可以拆解、改写，或回退CPU执行，也可以重新设计网络避开它。C直接忽略算子是严重错误，会导致网络输出错误，甚至无法完成转换。

Q7. 多核NPU性能提升理论上受什么定律制约？

单选题 · mid

A.摩尔定律
B.阿姆达尔定律← 正确答案
C.墨菲定律
D.帕金森定律

答案：B。阿姆达尔定律描述了并行系统中串行部分对加速比的天花板限制。摩尔定律描述晶体管数量，墨菲定律和帕金森定律都不是并行计算理论，因此正确答案是B。

Q8. 边缘网关的可用性公式 A = MTBF/(MTBF+MTTR)，要提高可用性，最有效的措施是？

单选题 · hard

A.提升摄像头分辨率
B.缩短平均修复时间← 正确答案
C.减少训练数据集大小
D.增大单路视频码率

答案：B。可用性由MTBF和MTTR共同决定，缩短修复时间能直接提高A。提升分辨率、减小训练集、增大码率都不会改善可靠性，反而可能加大设备负载，降低MTBF。

Q9. RK3588部署多路视频时，性能压力测试最应该关注哪个指标？

单选题 · hard

A.端到端每秒处理帧数← 正确答案
B.模型参数量大小
C.训练数据集大小
D.云端网络带宽

答案：A。端到端FPS直接反映设备能同时处理几路视频，是部署性能的核心指标。模型参数量、训练集大小是模型侧因素，云端带宽与本地性能压力测试关系不大。

Q10. 关于多核NPU调度的阿姆达尔定律，以下说法正确的是？

多选题 · hard

A.并行占比越高，加速比越大← 正确答案
B.核数无限增加时，加速比趋近1/(1-f)← 正确答案
C.串行部分对加速比没有影响
D.核间通信开销不会影响加速比

答案：AB。可并行比例f越高，加速比越大；当p趋于无穷时，加速比极限是1/(1-f)。串行部分恰恰是瓶颈，核间通信开销也会降低实际加速比，因此C和D错误。