25 TOPS描述的是特定计算条件下的运算能力，不是一条视频链路每秒能交付多少帧。给树莓派装上NPU后，解码、缩放、数据转换和后处理仍可能占据大部分时间；推理阶段变快，不保证整条链路按同样倍数变快。

Sixfab AI HAT+与DEEPX最近的报道提供了一个具体例子。判断它是否适合你的视觉项目，应该从模型能否正确部署、端到端延迟和整机功耗开始，而不是把TOPS直接除成FPS。Read in English。

这条新闻说了什么，又没说什么

Google News收录了EE Times Asia在10月16日的报道，署名为DEEPX。它介绍第三方Sixfab AI HAT+上的DX-M1M NPU，标称最高25 TOPS，并引用约3W典型持续NPU功耗。这里属于厂商提供的信息，不是本文独立测得的结果。

报道追溯到Raspberry Pi在10月5日发布的介绍，板卡此前已推出，不能把10月16日的报道包装成当日首次发布。Sixfab产品页将25 TOPS对应为INT8规格，并列出独立NPU内存；这也不等于能够以同一速度运行任意精度、任意模型。

更有用的消息是软件路径：支持的模型需要经编译部署，主机继续承担相机与应用工作。端侧视觉有机会摆脱持续云连接，但究竟省下多少延迟、功耗或网络流量，仍取决于实际工作负载。

把一帧拆成真正发生的阶段

从相机到结果，中间通常有采集、解码、前处理、传输、推理、后处理和交付。NPU推理只是其中一段。测到“模型调用用了几毫秒”，不能直接报告为“画面到告警用了几毫秒”。

先定义起止点。起点可以是帧进入应用、解码完成或曝光结束，终点可以是结果生成、显示或业务动作提交。不同边界回答不同问题；如果不知道时间戳覆盖哪里，两组延迟就没有可比性。异步接口返回时也不一定表示推理完成，计时终点应对应所需结果真正可用的事件。

下文只研究单帧严格串行、无排队的处理预算。采集供给另设帧率上限，不把相机等待偷偷加进或移出同一个数字。数值是人为构造，便于复现，不代表这块板卡的真实速度。

推理加速5倍，总延迟只缩短一点

假设前处理12ms，NPU段5ms，后处理8ms，总处理延迟25ms。即使将NPU段缩到1ms，总延迟仍为21ms；整条串行路径加速25/21≈1.19倍，而不是5倍。

用Amdahl形式表达：可加速部分占比f=5/25=0.2，局部加速s=5，总加速为1/((1-f)+f/s)。即使推理耗时趋近零，固定的20ms仍在，串行处理能力最多从40帧/秒升到50帧/秒。

若相机只提供30帧/秒，这两套预算都能跟上供给，在这个无排队、无丢帧的理想预算里，交付帧率同为30；实际系统仍需检查采集和输出环节。新硬件仍可能降低处理延迟、释放其他资源，却不能从这个例子推出相机会产生更多帧。吞吐、延迟和余量要分别报告。

用八项断言核对预算

下面用标准库分数精确计算，不连接相机、不调用NPU，也不运行模型。capacity只表示这个无重叠串行模型的理论服务能力；delivered再受输入帧率约束，均不是设备测评。

# Hypothetical serial budget; no NPU, camera or model is run.
from fractions import Fraction as F

def budget(pre_ms,infer_ms,post_ms,source_fps):
    stages = [F(pre_ms),F(infer_ms),F(post_ms)]
    if any(x<0 for x in stages) or sum(stages)<=0 or source_fps<=0:
        raise ValueError("positive total and source rate required")
    latency = sum(stages)
    capacity = F(1000)/latency
    return latency, capacity, min(F(source_fps),capacity)

base = budget(12,5,8,30)
fast = budget(12,1,8,30)
assert base == (25,40,30)
assert fast[0] == 21
assert fast[1] == F(1000,21)
assert fast[2] == 30  # source rate still limits delivered frames
assert base[0]/fast[0] == F(25,21)
assert F(1)/(F(4,5)+F(1,5)/5) == F(25,21) # Amdahl form
assert budget(12,1,8,50)[2] == F(1000,21)
assert fast[0]>20  # misses a hypothetical20ms processing deadline
print("8 budget checks passed; speedup=25/21, not5")

代码已在本地执行，八项断言通过。它还说明一个容易忽略的情况：推理段只需1ms，总处理仍为21ms，因此依然超过假设的20ms处理期限。只给推理函数设定性能目标，可能无法满足业务真正关心的期限。

如果流水线重叠，别把公式照搬过去

实际应用可能让CPU处理下一帧时，NPU同时执行上一帧。此时稳态吞吐不再简单等于1000除以所有阶段之和；还要看并行度、共享CPU、内存带宽、传输与同步。前处理和后处理若争用同一CPU资源，也不能当成两台独立机器。

这不推翻上面的推导，而是换了前提。给出一个加速数字时，应说明测的是单帧延迟、长时间平均完成率，还是多帧并行情况下的吞吐。不要把串行模型的上界拿来承诺流水线实测，也不要用流水线吞吐掩盖单帧等待。

多相机、多模型更需要记录帧的来源和完成时间。平均FPS看起来足够，某一路可能持续变慢；长队列也可能让结果对应很久以前的画面。对事件判断，应同时观察结果新鲜度和遗漏，而不只是设备利用率。

先验证模型正确，再比较快不快

Raspberry Pi介绍的部署路径涉及DX-COM、.dxnn与DX-RT。这里的关键词是“支持的模型”，不是任意ONNX文件都能无条件运行。转换成功之后，也应核对算子、输入布局、量化与后处理是否仍对应原任务。

建立一个明确的原始精度基线，选用来自真实场景分布、已获授权且不含私人数据的测试样本。分别比较类别、框、分数或业务最终判断；不要只检查程序有没有报错。低照度、模糊、遮挡等变化可能比样例图更接近部署压力。

延迟对照要保持模型版本、输入尺寸、预处理、batch与判定标准一致。若同时更换模型和分辨率，速度提升就不能全部归到NPU。精度变化也不能被更高FPS抵消，除非它仍满足事先约定的任务要求。

3W不是整台树莓派的用电预算

约3W这一说法指向NPU，不包含整机所有组成部分。主机、摄像头、存储、网络和散热都有成本；电源额定功率也不是实时实际功耗。比较方案时，先确定测量的是芯片、板卡、主机加板卡，还是电源入口。

如果要计算每帧能耗，应使用同一时间窗内系统耗电量除以有效完成帧数。把NPU标称功耗除以整条链路FPS，会混合不同测量边界；把空闲帧、无效结果算进分母，也可能把效率画得过好。

持续运行还需观察温度与频率，而不是只看启动后的短时峰值。本文没有这块硬件的实测数据，因此不提供“省电百分比”或购买结论；这些问题应在最终机箱、供电与负载下验证。

从一个小而完整的视觉任务开始

先挑一个读者真正要完成的任务，例如对非敏感工件做缺陷分类，固定输入规格和成功标准。随后记录每阶段耗时、端到端延迟分位数、有效完成率、误判与漏判，再观察稳态功耗和温度。每个数值标明窗口与测试条件。

如果主机处理占大头，优先排查重复缩放、无必要复制、同步等待和输出编码；如果模型转换不满足要求，先解决模型支持与精度。只有推理确实是主要瓶颈时，更多TOPS才可能直接推动当前目标。

昨天的GPU排队文章讨论“有资源不等于能放置”；这里是另一个边界：“有峰值计算能力不等于端到端有对应收益”。用约束和证据定位问题，比挑一个最大的规格数字更可靠。

来源与验证范围

新闻线索为Google News收录的10月16日报道，原始介绍见Raspberry Pi，10月5日；规格范围以Sixfab产品页为准。两幅图、时间预算与代码是原创教学内容，未进行设备或模型实测。

如果这个预算例子帮你避免把TOPS误当成业务帧率，或让一次端侧性能对照更清楚，欢迎通过文末支持区自愿支持。