来源：notes/documents/04_dg板卡X5_BPU推理服务_全模型跑测结果.md

dg 板卡 X5 BPU 全模型跑测：34 个官方模型在同一张图上的表现

日期：2026-09-19　设备：RDK X5（dg，10.71.48.154）　服务：http://10.71.48.154:8080

一句话结论

把板子上 /opt/hobot/model/x5/basic 里的 34 个官方 .bin 模型全部跑通了一遍（34 次推理 + 9 个检测模型的 letterbox/stretch 对照），结果是：20 个开箱能用（8 个检测 + 12 个分类），1 个 kind 认对了但解码是错的（yolov8_seg 被当检测器跑），5 个语义分割要自己补后处理才能看到类别图，8 个只吐原始张量（yolov3、yolov3-darknet53、yolov2、ssd、fcos×3、centernet）。最快的模型 2.4 ms（mobilenetv1），最慢 102 ms（yolov5x 672），全部 34 个模型 34/34 推理成功、零报错。

输入

一张随机取的静物照片（picsum seed 342，1280×960）——木桌上放着笔记本电脑、手机、马克杯、手账本和笔。选它是因为一张图能同时喂饱三类任务：检测有明确的 COCO 物体、分类有明确的语义、分割有清晰的区域边界。

推理参数：score_thres=0.25、max_det=50、分类 topk=5、检测默认 resize=letterbox。

总览：34 个模型

「服务识别的 kind」是服务自己根据输出张量形状猜出来的任务类型（bpu_service/engine.py 的 kind()）。34 个模型里 21 个被认出并走了专用解码路径（其中 yolov8_seg 走错了路），13 个落到 generic（原始张量）：8 个旧检测器 + 5 个分割。

1. 目标检测：9 个模型能出框

这张图的正确答案是 laptop（笔记本）、cup（马克杯）、cell phone（手机）、book（手账本）、diningtable（木桌） 五类。

看图说话

最准的一版（yolo11m letterbox，5 个框：laptop 0.95、cup 0.91、cell phone 0.90、cell phone 0.58（重复框）、diningtable 0.52）：

第二准（yolov5x 672，98.7 ms，比 yolov8 多出手机和桌面）：

漏检的样子（yolov8 只出了 2 个框，手机完全没找到）：

结论

• yolo11m 和 yolov10 是这张图上的赢家：5 框 / 4 框，laptop 0.95/0.97、cup 0.91/0.93，手机也都抓到了（0.90/0.49），还给出了 diningtable。
• yolov8 最快也最省，但会漏目标：9.2 ms 只出 2 框，手机（画面左下的深色长方形）直接漏掉，桌面也没出。
• 9 个检测器没有一个检出 book：画面左下那本黑色手账本是个大目标，但它是深色物体压在同为深色木纹的桌面上，9 个模型集体漏检。这说明低对比度、小色差的目标才是这类 COCO 检测器的真短板，比「小目标」更致命。
• 重复框没有被 NMS 压掉：yolo11m 吐出两个 cell phone（0.90 / 0.58）、yolov5x 也吐两个，两个框并不完全重叠，NMS 阈值 0.45 压不住。要更干净得降 nms_thres。
• yolov5s_v6 与 yolov5s_v7 结果几乎逐位一致（同一份权重、不同版本头），可以认为是一个模型。
• letterbox vs stretch 在 4:3 图上差异很小：640/672 的方形输入配 4:3 的图，1280×960 缩到 640 后是 640×480，letterbox 要上下各补 80 px 黑边，但两者得分差普遍在 0.05 以内。相比之下，之前那张竖图（青梅酒）上 letterbox 明显赢，说明 resize 策略要看图片长宽比。

一个必须点名的坑：yolov8_seg 被当成检测器跑

yolov8_seg_640x640_nv12 是实例分割模型。它的真实输出是 6 个张量：

output0: [1, 80, 80, 80]  类别分数（大尺度，80 类）
387:     [1, 40, 40, 80]  类别分数（小尺度）
371:     [1, 80, 80, 32]  mask 系数（大尺度）
395:     [1, 40, 40, 32]  mask 系数（小尺度）
output1: [1, 80, 80, 64]  mask 原型（64 维）
379:     [1, 40, 40, 64]  mask 原型（小尺度）

服务的解码器只按 YOLOv8 检测头去解释，把 80 通道的类别分数图和 32 通道的 mask 系数图混在一起当成检测输出，于是吐出 50 个（被 max_det=50 截断，实际会给满 100 个）「bear 0.88 / umbrella 0.87」这种完全不存在的框。结论：kind=yolov8 这个配置对 seg 模型是错的，要正确使用它得单独写分割头（取 box + mask 原型与 mask 系数做矩阵乘、再阈值化）。

2. 图像分类：12 个模型，好坏分明

结论

• 7 个模型答对了，而且意见高度集中：vargconvnet 0.729 / mobilenetv1 0.689 / googlenet 0.567 / mobilenetv2 0.416(desk) / resnet18 0.291 / efficientnet_lite0 0.255 / lite1 0.194，标签全落在 notebook computer / laptop / desk 这个小圈子里。
• 5 个模型基本报废：efficientnet_lite2 / lite3 / lite4 / efficientnasnet_s / nasnet_m，top-1 只有 0.05～0.24，答案从 nail 到 grand piano 完全不着边。
• 我做了交叉验证排除「图片太难」这个解释：换成 bus.jpg（板子自带的标准测试图，画面是公交车和人），lite0 仍然答对（minibus 0.776）、vargconvnet 答对（0.512），而 lite2 答 nail 0.065、lite3 答 file cabinet 0.054、lite4 答 paddle 0.082、nasnet_m 答 binder 0.472——换图同样不对，说明问题在模型＋预处理，不在图片。
• 根因判断：服务的预处理是「BGR → resize → NV12」，没有做 ImageNet 的 RGB 转换与 mean/std 归一化。对预处理的容忍度高的模型（mobilenet / resnet / googlenet / vargconvnet / lite0 / lite1）照样能出正确答案，敏感的（lite2/3/4、nasnet）就塌成近似均匀分布。要救它们，得在 bpu_service/preprocess.py 里按模型挂一组 mean/std。
• 顺带发现：分类模型输出头的命名毫无规律（prob / output / 687 / 439），服务的 decode_classification 是靠在输出里找一个 (1, C, 1, 1) 形状的张量来自动定位头部的——这也是它能一口气吃下 12 个分类模型的原因。

3. 语义分割：5 个模型，服务不认，我补了后处理

这 5 个模型的输出格式各不相同，服务的 decode 里没有分割分支，所以 HTTP 只返回张量统计。我写了 tools/render_outputs.py 把张量还原成类别图（Cityscapes 19 色调色板），叠在原图上：

最重要的发现：这 5 个模型全是 Cityscapes（城市道路）权重，只有 19 个类别，没有「桌子 / 笔记本 / 杯子」。让它们看一张桌面静物照，它们会强行把桌面判成 road / car / person：

• mobilenet_unet 的输出最碎：19 个类里用上了 18 个，桌面大片判成 car / truck（暗红），背景判成 sky（蓝）和 vegetation（绿），一块一块像打翻的调色盘——不是它看不懂，是它非得在 19 个道路类里挑一个；
• deeplab（em1）用的类别里彻底没有 sky / vegetation，于是把笔记本和桌面整片判成 car / person（红），背景判成 building / wall（棕）；
• stdc / fastscnn 输出分辨率只有 64×128，天空和背景直接糊成 vegetation（绿）。

也就是说，这 5 个模型对「非道路场景」根本没有语义能力，这不是坏了，是训练域不对。要用就得换在目标域训练的权重，或者老实接受它们只能做道路场景。另外它们的分辨率差异也很大：deeplab 输出 1024×2048 全分辨率，stdc 只有 64×128。

4. 只有原始张量的 8 个模型

这 8 个模型跑得动、延迟是真实的，但服务不会解释它们的输出，HTTP 接口只能给出张量的名称、形状、最小/最大值。

CenterNet 的 80 通道热图我单独渲染并解了一下峰值——热图的前三个峰值就是画面里的三件东西，说明模型完全没问题，只是服务没有解码器把它翻译成框：

结论：要让这 8 个模型「能用」，得再写 5 个解码器（YOLOv3、YOLOv2、SSD、FCOS、CenterNet）。工作量不小，但从延迟看它们并不差（4～39 ms）。

5. 值得记住的结论

• 类别体系决定天花板：检测只有 COCO 80 类、分类只有 ImageNet 1000 类、分割只有 Cityscapes 19 类。图里出现体系外的东西（青梅酒、茶壶、海鲜煎饼），模型只能往最近的类上靠——它不是「看不出来」，是「没有这个词」。
• 同一个服务，34 个模型分成四档：20 个开箱能用、1 个解码错误（yolov8_seg）、5 个要补后处理（分割）、8 个要补解码器（旧检测器）。
• 预处理是隐藏变量：同样是 ImageNet 分类，vargconvnet 能到 0.729，efficientnet_lite4 只有 0.095 且答案荒谬——同一套「BGR→NV12」预处理不能通吃所有模型。
• kind 自动识别很关键：如果没有 kind() 那套按张量形状猜任务类型的逻辑，这 34 个模型得逐个手写配置。它一次覆盖了 21 个。
• 速度梯队：分类 2.4～5.3 ms < 小检测器 9～33 ms < 大检测器/分割 37～102 ms。yolov5x 672 是最慢的（98.7 ms），比 yolov8 慢 10 倍。
• 模型重复率很高：yolov5s_v6 与 v7 输出一致、yolov5s 与 yolov5s_v6 近似、fcos 三个只是主干不同——34 个里有相当一部分是同一家族的规格变体，不是 34 种能力。

6. 复现方式

一张图跑完整个模型库（两个工具都在 source_materials/bpu-service/tools/）：

# 在能访问板子的机器上：模型库全量跑测 -> pass1.json / pass2.json + 标注图
python3 tools/run_model_zoo.py seed342.jpg /tmp/zoo/run
#   pass1.json：34 个模型逐个跑（kind / 延迟 / 框 / top-5 / 张量清单）
#   pass2.json：9 个可解码检测器的 letterbox 与 stretch 对照

# 在板子上：把只有原始张量的模型渲染成可视化
ssh dg 'cd /opt/bpu-service && python3 tools/render_outputs.py stdc_512x1024 /tmp/zoo/zoo.jpg /tmp/zoo/stdc.png'

产物：

• 本文档的原始数据：notes/documents/assets/dg_x5_zoo/data/pass1.json、pass2.json
• 图片素材：notes/documents/assets/dg_x5_zoo/
• 新增工具：source_materials/bpu-service/tools/run_model_zoo.py（模型库全量跑测）、render_outputs.py（分割 / 热图渲染）
• 运行环境：RDK X5 dg（10.71.48.154），服务 bpu-service，systemd 托管