64
51
飞牛相册 AI 硬件加速实测
2026-09-13 20:04:25
0点赞
0收藏
0评论
独立实测报告 + 标准测速手册 · 持续更新（本版 2026-09-13）· 本机实测环境：飞牛 fnOS（Jack-fnOS，内核 6.18.18.c952-trim；Jin-fnOS，内核 6.18.18.c1032-trim）
本文由原《实测研究报告》与《标准测速案例》合并而成：第一～九节是结论与取证，第十节是可复现的 A/B/C 测速流程，附录 A 为路径速查与自行验证方法。
这份报告会一直长：每到手一台新实机，就按第十节的 A/B/C 协议跑一轮，把读数追加进第三～五节与 3.1 证据台账，并据此修订第七节的判据——已经写下的结论会被新实机推翻或收紧（Gen11 从「不可用」改成「可用」就是这么来的）。已列队待测的实机（i3-7100、7840 系列、300U、2200U）见 7.2。
怎么读：
决定买哪台 / 手上这台能不能用 → 摘要 → 第五节兼容性全图 → 第七节结论 → 第八节选型建议
已经在跑，担心会不会崩、出问题怎么查 → 4.2.3（Gen11 的 HANG 现场）→ 10.7 判定口径 → 10.8 已知坑
要自己复现测速 → 3.1 证据台账 → 第十节 A/B/C 协议 → 附录 A
摘要
飞牛（fnOS）相册 AI 的 GPU 加速受两条硬约束支配，Intel 与 AMD 的判据不同：
Intel：Gen ≥ 12 为稳妥线；Gen11 可用。判据是核显代际，与 CPU 是否带小核（E-core）无关——N100 等纯 E-core 平台同样达标。Gen9（Gemini Lake）实测 GPU 后永久停留 CPU（不支持）；Gen11（Jasper Lake N5095A，2026-09-13 实测）核显确实被调用、确实出活，日常可用。已知限度是偶发 GPU HANG（Resetting rcs0 for preemption time out，ecode 11:1:8ed9fff3），由 ai_manager 自动降级 CPU 并回迁 GPU，不构成「不可用」。成因尚未锁定：并发没能在短窗口内复现它，而三次 GPU HANG 中有两次的现场是 trim.txt2vec——「txt2vec 同时在场」比「并发」更可疑（见 4.2.3）。
AMD：看 gfx 目标是否被推理后端覆盖。社区排查的 ROCm 7.2 rocBLAS 内核列表含 gfx1030/1100/1101/1102/1150/1151/1200/1201/908/90a/942/950，不含任何 Vega（gfx90c/902/909）、不含 RDNA2 核显（gfx1035）；但 780M（gfx1103）同样不在列表却实测可用——该列表是参考而非绝对判据，最终以实测 GPU 占用为准。
「能激活」≠「会调用」：装 ROCm 后设备枚举成功、相册开关能点亮，但推理后端可能根本没挂上。唯一判据是任务运行时 GPU 占用非 0。
本机实测（4.3 / 4.4）：6305（Gen12 Xe，2 核）人脸 247.4 张/分、智能分类 25.72 张/分，并发 145.05 / 20.1，三轮零 HANG；N5095A（Gen11，4 核）对应为 148.94 / 8.54，并发 78.55 / 5.18，同样零 HANG。Gen11 → Gen12 收益不均衡：人脸快 1.7–1.9 倍、智能分类快 3.0–3.9 倍——前者压不满核显，后者是纯 GPU 瓶颈。8745HS（RDNA3 780M）走 ROCm 的人脸识别 GPU 参与确认（2026-09-01）。
一项排查提醒：相册界面报「设备负载过高或 AI 服务不可用」时，别按字面去查 CPU 负载——它是错误码 errorCode.4057 的兜底文案，实际含义是 AI 服务调用失败（见 4.2.5）。
瓶颈常在数据吞吐：存量已处理完的家庭场景，增量走 CPU 慢算够用；但智能识别是明确的例外——实测是纯 GPU 瓶颈，换更快的 CPU 不会让它变快（见 4.5）。
版本基线（2026-09-13）：系统 v1.2.0604、相册 v0.9.13（Gen11 实测版）；前基线为系统 v1.2.0602（2026-09-03）/ 相册 v0.9.11；AMD 适配自 v1.1.29（2026-04-16）起。
一、测试背景
飞牛相册的 AI 功能包含两大模块：
智能分类：trim.img2vec——按内容给照片自动分类/打向量
人脸识别：trim.face_det——检测、识别照片中的人脸
以文搜图文本编码：trim.txt2vec——把搜索词编码成向量。新版新增的第三个服务；Gen11 那轮观测里三次 GPU HANG 有两次的现场是它（见 4.2.3）
两者都是本地推理。Intel 平台走 OpenVINO，AMD 平台走 ROCm + MIGraphX，两条链路的硬件门槛完全不同。本报告回答：两块平台各自要满足什么条件，相册 AI 才能真正用上 GPU？
二、测试环境
威联通 TS-451D（旧）：J4025（Gemini Lake）· Gen9 · UHD 600（12EU）· 8G（2×4G DDR4-2400）双通道 · 飞牛 fnOS · 内核 6.18.18
智微智能 e098（6305）：Celeron 6305（Tiger Lake）· Gen12（Xe） · UHD G4（48EU，设备 ID 9a78）· 8G（2×4G DDR4-2666）双通道 · 飞牛 fnOS · 内核 6.18.18
玄派 Z10 Turbo（8745HS）：Ryzen 7 8745HS · RDNA3 Radeon 780M · ROCm 7.2 + MIGraphX · 人脸识别 GPU 实测（2026-09-01）
N5095A 小主机（Jin-fnOS，2026-09-13 新增）：Celeron N5095A（Jasper Lake）· Gen11 · UHD Graphics（设备 ID 4e55）· 8G（2×4G DDR4-2666）双通道，系统可用约 7.5G · 飞牛 fnOS 1.2.0604 / 相册 0.9.13 · 内核 6.18.18.c1032-trim
注 1：飞牛相册「增强模型」有 8G 总内存门槛（≥8G 才可选），识别时内存占用约 3-4G。 注 2：变量说明——Intel 三台测试机内存构型一致，均为 8G（2×4G DDR4）双通道：6305 与 N5095A 为 DDR4-2666、J4025 为 DDR4-2400；系统可用 7.4–7.5G，差额来自核显保留。故三台之间内存不是变量。内存门槛只影响「增强模型」可选性，不影响本报告结论：基础人脸/智能识别无内存门槛；且 J4025 的 GPU HANG 为日志级证据（GPU HANG + clWaitForEvents -14），与内存无关。
三、测试方法与工具
全部数据来自实机采样，非估算：
GPU 引擎占用（Intel）：intel_gpu_top -l -J（JSON 输出，逐引擎、逐进程采样）
GPU 占用（AMD）：系统资源管理器 GPU 页 + rocm-smi --showuse
进程状态：ps / pgrep（相册 AI 进程为 root，需 sudo）
缓存证据：核对 OpenVINO GPU/CPU 编译缓存的物理位置与格式
3.1 证据台账（每条结论对应哪次实测）
本文是持续更新的报告，版本一变结论就可能变——读任何一条结论前，先对这张表：
2026-09-13
机器（核显）：6305（Gen12 Xe，2 核）
相册版本：0.9.13
取证方式：intel_gpu_top -J 的 clients 归属 + /proc CPU 差分 + SQLite / pgvector 行数
结论落在：4.3 · 4.4 · 第五 / 七 / 八节
2026-09-13
机器（核显）：N5095A（Gen11，4 核）
相册版本：0.9.13（系统 1.2.0604）
取证方式：dmesg + ai_manager 日志 + intel_gpu_top -J
结论落在：4.2 · 第二节
2026-09-01
机器（核显）：8745HS（RDNA3 780M）
相册版本：—
取证方式：系统资源管理器 GPU 页 + rocm-smi --showuse
结论落在：6.4 · 第八节
≤2026-09
机器（核显）：J4025（Gen9）
相册版本：—
取证方式：dmesg + OpenVINO 日志
结论落在：4.1
社区（非本机）
机器（核显）：680M / 890M / 8060S / 300U / Vega 3 等
相册版本：各版本
取证方式：社区帖 + 复现命令
结论落在：6.3 · 6.4 · 6.5
证据强度分两档：本机行都有原始日志或 DB 读数，可复核；社区行只有二手描述，引用时已逐条标注来源与局限（如 6.2 的 rocBLAS 列表并非官方清单）。
四、Intel 实测结果
三代实机总表（都是机主自己的机器，逐条证据见 4.1 / 4.2 / 4.3）：
Gen9
本机平台：J4025（威联通 TS-451D）
核显（规模）：UHD 600 · 12EU
GPU 真被调用：❌ 一开 AI 就崩，降级后再没回到 GPU
人脸 张/分：—
分类 张/分：—
并发 人脸 / 分类：—
GPU HANG：有（降级后永久停 CPU）
定性：不支持
Gen11
本机平台：N5095A（4 核 · 8G 双通道）
核显（规模）：UHD · 16EU
GPU 真被调用：✅ clients 归属确认两个模块
人脸 张/分：148.94
分类 张/分：8.54
并发 人脸 / 分类：78.55 / 5.18
GPU HANG：偶发（4.2.3）
定性：可用
Gen12
本机平台：6305（2 核 · 8G 双通道）
核显（规模）：Xe · 48EU
GPU 真被调用：✅ clients 归属确认两个模块
人脸 张/分：247.4
分类 张/分：25.72
并发 人脸 / 分类：145.05 / 20.1
GPU HANG：0（三轮 120 s）
定性：支持
Gen12 参考
本机平台：N100 / N150（本机未实测）
核显（规模）：Xe · 24EU
GPU 真被调用：社区实测无问题
人脸 张/分：—
分类 张/分：—
并发 人脸 / 分类：—
GPU HANG：—
定性：支持
速率是同一套真实素材、同一套协议、120 秒窗口下的读数（口径见第十节）；Gen9 因 GPU 路径不可用，没有速率数据。跨代差距与并发衰减见 4.4，瓶颈判定见 4.5，SKU 覆盖面见第五节的完整兼容表。
4.1 Gen9（J4025 / Gemini Lake）：GPU 不可用
打开 AI 识别后日志直接出现 GPU 故障，飞牛随即降级 device:CPU 并限 1 核：
dmesg: GPU HANG OpenVINO: ProgramBuilder build failed OpenVINO: clWaitForEvents -14
根因不是驱动缺失，而是飞牛内核 6.18 的 i915 对 Gemini Lake 的 compute 支持有缺陷；J4125 / J5005 等为同类现象。
2026-09 更新：v1.2.0505 起结论松动但未官宣——社区实测同版下 J4125 UHD600 首次真正调用核显、人脸识别快约 10 倍。反例与系统性坑仍在：部分 J4125 更新相册后调不到 GPU；J4105/J4125 仅 SSE4.2 无 AVX，而相册内置 OpenVINO 2024.4 无条件加载 NPU 插件 → illegal instruction、gpu_verify 崩溃（官方已收录 BUG，临时解法是重命名禁用 libopenvino_intel_npu_plugin.so）。定性：部分环境可用、仍不稳，非选型依据。
4.2 Gen11（Jasper Lake N5095A）：可用，但偶发 GPU HANG
2026-09-13 实机取证（Jin-fnOS：N5095A / 系统 1.2.0604 / 相册 0.9.13 / 内核 6.18.18.c1032-trim）。内核自报代次：
i915 0000:00:02.0: [drm] Found jasperlake (device ID 4e55) integrated display version 11.00 stepping B0 i915 0000:00:02.0: [drm] GT0: GuC firmware i915/ehl_guc_70.1.1.bin version 70.1.1 i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads
4.2.1 核显确实被调用
intel_gpu_top -J 的 clients 段直接给出归属 PID，而不是看配置开关：
trim.img2vec 智能分类
观测到的落点：device:GPU（15:03:57 回迁后 pid 10196）
Render/3D 占用：88% – 105%
判定：✅ 接近满载，GPU 编译出 613M .blob
trim.face_det 人脸识别
观测到的落点：崩溃前 device:GPU（pid 8125 / 8146）
Render/3D 占用：8.5% – 53%
判定：✅ 缓存目录 40+ 个 .cl_cache，CPU+GPU 并行
trim.txt2vec 以文搜图
观测到的落点：存活期内 device:GPU
Render/3D 占用：56 秒内完成约 80 次推理
判定：✅ 走 GPU；随后遇一次 GPU HANG
三者都会被 FallbackSrv 打回 CPU（见 4.2.4），所以上表是 GPU 期间的占用，不是全程常驻状态。产出侧同步推进：photo 表 1125 张；观测 1 小时 37 分内 user_photo_category 5 → 17 条、face 80 → 287 条、face_task_log 88 → 387 条。
.cl_cache 是 OpenVINO GPU 插件写入的 OpenCL 内核缓存，不是 CPU 端产物；.blob（编译后的模型）与 .cl_cache（编译后的内核）同属 GPU 路径，CPU / ONNX 兜底模式走 onnx_model，不产生这两类文件。
4.2.2 第一次崩溃的根因：i915 抢占看门狗，不是 CPU 被占满
14:38:19 —— 五个 AI 服务全部被停（模型与依赖更新）
14:48:38 / 39 —— face_det、txt2vec 相继启动；face_det 自报 cpu_usage=100.0
14:48:59 —— txt2vec 就绪（20 秒完成 GPU 编译），随即把类别词表连续编码：约 80 次调用 / 56 秒，≈1.4 次每秒
14:49:17 —— face_det 就绪，开始向同一条 GPU 提交工作
14:49:55 —— txt2vec 崩溃
14:51:17 —— img2vec 才启动
i915 0000:00:02.0: Resetting rcs0 for preemption time out i915 0000:00:02.0: trim.txt2vec[8197] context reset due to GPU hang i915 0000:00:02.0: GPU HANG: ecode 11:1:8ed9fff3, in trim.txt2vec [8197] ai_manager: runAndWaitForSrvStarted bootCmd wait err: signal: segmentation fault ai_manager: ... recoverable: true, expire: 1m0s, reason: rpc call failed, code=20150
根因在 GPU 引擎层：内核给的诊断是 preemption time out——高优先级上下文要求抢占 rcs0，txt2vec 的上下文在 i915 抢占窗口（默认 640ms）内没有让出，看门狗判定挂死并 reset 整条 rcs0。两条佐证：① 崩溃那一刻最重的 img2vec 根本没在跑（启动时间戳 14:51:17，比崩溃晚 82 秒），当时只有 2 个 AI 服务活着、机器 4 个核；② 这是冷启动高并发窗口——txt2vec 刚做完冷编译就进入 1.4 次/秒的连续推理，38 秒后 face_det 也上 GPU，两个 OpenVINO GPU 上下文撞在同一条 rcs0 上。但故障随后在非启动窗口也复现了两次（4.2.3），所以「启动风暴」只是首次的诱因，不是根因的边界。
CPU 负载不是主因、但可能是加剧因素：face_det 自报 cpu_usage=100.0，ai_manager 自身也按负载限核（limited service to 2/4 CPU(s)）；但第二次 HANG 时 load average 只有 2.17 / 4 核（≈54%），不足以解释全部现象。
4.2.3 观测记录：观测窗内三个服务各崩一次（窗外另有 1 次未致死）
14:49:55
崩溃服务：trim.txt2vec [8197]
内核 GPU HANG：✅ #1 ecode 11:1:8ed9fff3
处置：fallback srv → CPU/ONNX
15:02:38
崩溃服务：trim.img2vec
内核 GPU HANG：❌ 无 HANG
处置：fallback srv → CPU/ONNX → 15:03:57 回迁 GPU
15:05:08
崩溃服务：trim.face_det [8146]
内核 GPU HANG：✅ #2 ecode 11:1:8ed9fff3
处置：fallback srv → CPU/ONNX
15:40:24 （观测窗外）
崩溃服务：trim.txt2vec [14572]
内核 GPU HANG：✅ #3 ecode 11:1:8ed9fff3
处置：服务存活，降级待恢复
[14:49:55] Resetting rcs0 for preemption time out [14:49:55] trim.txt2vec[8197] context reset due to GPU hang · GPU HANG: ecode 11:1:8ed9fff3 [14:49:55] GPU error state saved to /sys/class/drm/card0/error [15:05:08] trim.face_det[8146] context reset due to GPU hang · GPU HANG: ecode 11:1:8ed9fff3 [15:40:24] trim.txt2vec[14572] context reset due to GPU hang · GPU HANG: ecode 11:1:8ed9fff3
三个不同进程、观测窗内 16 分钟、ecode 一字不差（窗外 15:40:24 的第 4 次是同一个 ecode，四次事件合计跨 51 分钟）——这是确定性的故障签名，指向 i915 在该 Gen11（Jasper Lake，ehl_guc_70.1.1）平台上对 OpenVINO GPU 负载的抢占处理，而不是随机过载。
「GPU HANG」有两种后果，口径必须分开：
进程死亡
日志特征：signal: segmentation fault + code=20150
出现次数：3 次（含 15:02:38 那次无 HANG 的）
服务存活、降级待恢复
日志特征：save failed boot cmd ... recoverable: true, expire: 2m0s + fallback srv，无 segfault
出现次数：1 次（15:40:24）
expire: 2m0s 也解释了 4.2.4 的回迁时间差——15:02:37 fallback → 15:03:50 try recover 相隔 73 秒，正是这个过期窗口到期后重试。
观测边界：本次取证在 15:06:10 由人工取消相册 AI 任务结束，晚于 15:05:08 那次崩溃 62 秒，因此它解释不了任何一次崩溃，只解释了之后服务为何不再运行。长时间持续负载下是否会自行稳定，本次未观测到结论。另需注意 Resetting rcs0 会连带销毁该引擎上所有上下文，持有者随即段错误。
不能据此认定「崩溃由并发引起」：这里只观测到「多服务同时在跑」这一相关项。2026-09-13 换真实库重测 A/B/C（含并发）各 2 分钟零 HANG，并发没能在短窗口内复现它；而三次 GPU HANG 中有两次的现场是 txt2vec，那三轮里 txt2vec 全程未运行——「txt2vec 同时在场」比「并发」更可疑。诚实的边界：120 秒太短，「两分钟不崩」不等于「不会崩」，要检验并发假设需把 C 拉到与历史崩溃同量级（十几分钟以上）并让 txt2vec 同时在场。
4.2.4 ai_manager 的降级—回迁状态机（全自动，无需人工干预）
15:02:37 fallback srv: com.trim.img2vec 15:02:37 run fallback srv: com.trim.img2vec → 新进程以 device:CPU / model_format:ONNX 起来 15:03:50 try recover hardware mode, srvName: com.trim.img2vec 15:03:57 try recover hardware mode success → 回到 device:GPU 15:05:08 fallback srv: com.trim.face_det → 下一个服务又被打下来
符号表对应 (*SrvLifeService).FallbackSrv、(*SettingService).SetGPU / deviceProbeStatus / nextGPUHardwareID。本次观测到一次完整的「回迁 → 再被打断」（15:03:57 回 GPU，71 秒后又被 reset），样本只有一次，可视为高并发下的偶发现象。
与 4.1 的关键区别：Gen9 是 GPU 从不可用、永久停在 CPU（「不支持」）；Gen11 是能上 GPU、能出活，偶发 reset 时自动在 GPU / CPU 之间切换（「可用」）。
4.2.5 排查与运维口径
界面文案不可作为定性依据。相册提示出自 trim.photos 的 i18n：errorCode.4057 = 设备负载过高或 AI 服务不可用。4057 是服务调用失败的兜底错误码，本次由服务段错误后套接字断开触发：
srv call err: Post "http://unix/": EOF, caller: trim-photos, srvName: com.trim.txt2vec, method: inferTxt2Vec
文案把「负载过高」与「AI 服务不可用」两个原因并列，看到「负载」二字容易往 CPU 占用上找，本次实际命中的是后半句。
判断核显是否真在跑，看三处：① intel_gpu_top -J 的 clients 段有没有目标 PID（唯一直接证据；采样本身有 perf 开销，排查时别高频跑）；② 服务 stdout.log 的 device: 字段是 GPU 还是 CPU；③ 产出表 user_photo_category / face 的行数有没有增长。故障现场：HANG 时 GPU 错误状态会存到 /sys/class/drm/card0/error，需要深挖时可 sudo cp 出来解析。
4.2.6 实测吞吐：智能识别吃满核显，人脸识别不是
本节已于 2026-09-13 用机主真实照片库重测，旧数据作废——旧的 1125 张（975 NEF + 150 JPEG）中间库测出人脸 27 张/分、GPU 均值 19.8%、rc6 80.3%，瓶颈压在 RAW 解码上，不能代表日常环境。现行素材：1398 张（1331 JPEG + 67 MP4，全部 2025 年手机拍摄，无 RAW）。
三个用例各 120 秒，同一天、同一台机器、同一份素材，每轮前用脚本清表复位（保留 170 条分类提示词）：
A
并发情况：仅人脸识别
人脸 张/分：148.94
分类 张/分：—
GPU Render/3D 均值：60.5%
rc6 空闲：39.0%
GPU 频率：475.6 MHz
HANG：0
B
并发情况：仅智能识别
人脸 张/分：—
分类 张/分：8.54
GPU Render/3D 均值：98.1%
rc6 空闲：1.8%
GPU 频率：736.7 MHz
HANG：0
C
并发情况：两个同时
人脸 张/分：78.55
分类 张/分：5.18
GPU Render/3D 均值：99.5%
rc6 空闲：0.5%
GPU 频率：744.6 MHz
HANG：0
clients 归属与 CPU 侧（本机 4 核，100% = 占满一个核）合并成一张表：
A
face_det GPU（峰值）：61.6%（80.6%）
img2vec GPU（峰值）：—
两者之和：61.6%
face_det CPU：94.4%
img2vec CPU：—
4 核占用：~1 核
B
face_det GPU（峰值）：—
img2vec GPU（峰值）：98.7%（105.1%）
两者之和：98.7%
face_det CPU：—
img2vec CPU：102.3%
4 核占用：~1 核
C
face_det GPU（峰值）：33.6%（45.4%）
img2vec GPU（峰值）：66.4%（82.2%）
两者之和：100.0%
face_det CPU：93.3%
img2vec CPU：99.7%
4 核占用：~1.93 核（空 2 核）
两个人脸/分类服务各自稳定占用约一个核——C 里两个加起来约 1.93 个核，4 核里始终空着约 2 个（C 的 load1 峰值 2.29 也印证）。并发时的争抢点是核显，不是 CPU。
txt2vec 三轮全程 0.0%，即这条路径没被覆盖。
A 与 B 的 CPU 占用几乎相同（94.4% vs 102.3%），吞吐却差 16 倍（148.94 vs 8.54 张/分）——CPU 不解释两者的速率差，核显才是分水岭。
结论：能不能吃满核显，取决于跑哪个模型，不取决于「有没有开 GPU 加速」。 人脸识别单跑 GPU 60.5%、rc6 还有 39% 空闲、频率 475 MHz（本机上限约 752），而 CPU 已 94.4%——单张 0.41 秒，核显不是它的瓶颈；智能识别单跑 GPU 98.1%、rc6 1.8%、频率 736.7 MHz，单张 6.53 秒，比人脸慢约 16 倍——纯 GPU 密集型。
并发是分摊，不是过载：B 单跑时 rc6 就已经是 1.8%，C 叠上人脸只降到 0.5%——核显在 B 阶段已饱和，再加一个人脸任务不会让它更吃紧，只是把吞吐切走一块。
⚠️ 本轮没采「整机 CPU 利用率」，上表是各服务进程的 CPU；load1 只是替代指标，不是利用率。要回答「这台机器整体用了多少 CPU」必须读 /proc/stat 的 idle 差分——本机既无 sar/sysstat 历史，A/B/C 又已过去，事后无法回填。套件已补该采样（cpu_machine() → cpu.sys），从下一轮起自动记录。量级参照：该机空载约 26%。
4.3 Gen12（6305 / Xe · 2 核）：两模块都走 GPU
2026-09-13 在同一套素材上跑完 A/B/C 三个标准用例（协议见第十节，窗口 120 秒）。三轮 GPU HANG / rcs0 reset / fallback / segv 全部为 0。
A
内容：人脸单跑
时长：122 s
人脸 张/分：247.4
分类 张/分：—
face CPU：75.1%
vec CPU：—
整机 CPU：51.3%
GPU R3D：23.6%
GPU 峰值：57.2%
rc6：75.4%
频率：352.3 MHz
B
内容：智能分类单跑
时长：124 s
人脸 张/分：—
分类 张/分：25.72
face CPU：—
vec CPU：100.2%
整机 CPU：66.0%
GPU R3D：96.8%
GPU 峰值：100%
rc6：3.2%
频率：1000.9 MHz
C
内容：两者并发
时长：128 s
人脸 张/分：145.05
分类 张/分：20.1
face CPU：68.8%
vec CPU：73.9%
整机 CPU：95.9%
GPU R3D：97.9%
GPU 峰值：100%
rc6：2.1%
频率：906.1（峰值 1227.7）MHz
clients 归属（「谁在真的用核显」的唯一直接证据）：A → trim.face_det 23.6% 独占；B → trim.img2vec 97.2% 独占；C → trim.img2vec 81.7% + trim.face_det 18.6%。两模块都确实在核显上跑，不是只看 device:GPU 字样。
智能分类是纯 GPU 任务：单跑 RCS 96.8%、rc6 掉到 3.2%、频率顶到 1000.9 MHz，clients 里 97.2% 全归 img2vec——核显就是瓶颈。
人脸识别是 CPU+GPU 混合：单跑时 GPU 只吃到 23.6%（峰值 57.2%）、rc6 仍有 75.4%、频率仅 352.3 MHz（大半时间在等），CPU 侧 75.1%（约 1.5 核）——瓶颈在 CPU 侧。
并发时核显被榨满：整机 CPU 95.9%、RCS 97.9%、rc6 2.1%，两个服务按约 4:1 分摊核显。
4.4 Gen11 ↔ Gen12 对照：并发分摊与换机收益
同一套素材、同一协议（120 秒窗口）、同为机主真实库，两台机器的直接对照：
A 人脸 张/分
Gen11 N5095A（4 核）：148.94
Gen12 6305（2 核）：247.4
差距：1.66×
B 分类 张/分
Gen11 N5095A（4 核）：8.54
Gen12 6305（2 核）：25.72
差距：3.01×
C 人脸 张/分
Gen11 N5095A（4 核）：78.55
Gen12 6305（2 核）：145.05
差距：1.85×
C 分类 张/分
Gen11 N5095A（4 核）：5.18
Gen12 6305（2 核）：20.1
差距：3.88×
三轮 HANG 次数
Gen11 N5095A（4 核）：0
Gen12 6305（2 核）：0
差距：—
并发时两机都是「按比例分摊」，不是过载——核显在并发时被榨满（Gen11 客户端合计 100.0%、Gen12 97.9%），两个服务各自变慢但都正常出活、都不崩：
Gen11 人脸识别
单跑 张/分：148.94
并发 张/分：78.55
衰减：−47%
并发时核显归属：33.6%
Gen11 智能分类
单跑 张/分：8.54
并发 张/分：5.18
衰减：−39%
并发时核显归属：66.4%
Gen12 人脸识别
单跑 张/分：247.4
并发 张/分：145.05
衰减：−41.4%
并发时核显归属：18.6%
Gen12 智能分类
单跑 张/分：25.72
并发 张/分：20.1
衰减：−21.8%
并发时核显归属：81.7%
收益不均衡，原因在瓶颈不同：人脸本来就压不满核显（瓶颈在 CPU / 数据吞吐），换更强的核显只能快 1.7–1.9 倍；智能分类是纯 GPU 瓶颈，核显规格直接换算成速率，故快 3–4 倍（6305 是 Xe 48EU，Jasper Lake 只有 16EU——EU 数正好差 3 倍，与实测的 3.0–3.9× 几乎重合；两台内存同为 8G 双通道，内存不是变量）。
4.5 瓶颈在核显、CPU 还是数据吞吐
判据是「三选一」的一张表，在 10.7 第 3 条；本节只记本机实测到的形态：
同一台机器上两个任务的瓶颈完全不同：人脸识别 CPU 94.4%、GPU 60.5%（CPU 受限，核显用不满）；智能识别 GPU 98.1%、rc6 1.8%（GPU 受限）。所以不能只测一个任务就下结论。
另有一类瓶颈既不在核显也不在 CPU，而在数据吞吐：N150+独显组合受 IO 限制也未显著更快。对历史照片已批量的家庭场景，新增量走 CPU 慢算的增量处理完全够用——这也是 6305 转正主力 NAS 的决策依据之一。
适用范围：本条不适用于智能识别。用真实 JPEG 库实测，智能识别单跑就能把核显压到 98.1%、rc6 掉到 1.8%、频率顶到 736.7 MHz，它确实是 GPU 瓶颈。旧版曾把 RAW 解码瓶颈当成普遍规律（当时的中间库以 NEF 为主），已更正。
五、Intel 兼容性全图
飞牛官方无实时兼容性列表，以下为社区实测 + 本机取证汇总：
Gen9
平台：Gemini Lake J4025/J4125（本机实测）
相册 AI GPU：⚠️ GPU HANG 回退 CPU；v1.2.0505 起部分环境可用仍不稳
判定：不支持 / 非选型依据
Gen9
平台：8 代 i3-8100（UHD 630）
相册 AI GPU：⚠️ 可能死机（兼容 bug，关 GPU 走 CPU 稳定）
判定：半支持
Gen11
平台：Jasper Lake N5095A / N5105 / N6005（N5095A 于 2026-09-13 本机实测）
相册 AI GPU：✅ face_det RCS 8.5–53%、img2vec RCS 88–105% 确认走 GPU；⚠️ 偶发 Resetting rcs0 for preemption time out（ecode 11:1:8ed9fff3）+ SIGSEGV，靠 ai_manager 在 GPU / CPU 间反复切换。旧版「img2vec SIGSEGV 自杀」已于 1.2.0604 / 相册 0.9.13 修复
判定：✅ 可用；偶发 GPU HANG（成因未定，见 4.2.3）
Gen12
平台：Tiger Lake 6305 Xe（本机实测）
相册 AI GPU：✅ clients 归属确认两模块都走 GPU：face_det RCS 23.6%、img2vec RCS 96.8%，并发 97.9%
判定：支持（实测 247 张/分 人脸 · 25.7 张/分 分类，见 4.3）
Gen12
平台：12/13 代 i3/i5（UHD 730/770）
相册 AI GPU：✅ 优秀；AV1/HEVC/VP9 全解码
判定：最优
Gen12
平台：Alder-N N95/N100/N200/N305 及新款 N150/N250/N350/N355（46d4/46d3）
相册 AI GPU：✅ 无问题；新款另有官方适配（v0.8.41 转码官宣 + v1.1.29 白名单含 46d4/46d3），社区实测坐实
判定：支持（新款本机未实测）
同核显核心的 SKU 合并为一行：N5095A 与 N5105/N6005 是同一颗 Jasper Lake 核显，N100 与 N150 是同一颗 Gen12 Xe（24EU），走同一条 i915 + OpenVINO 路径，相册 AI 表现不会有差异，故不单列。
几个重要结论：
判据是核显 Gen、不是 CPU 是否小核：N100/N305（Alder-N）与 N5105/N5095（Jasper Lake）同为 E-core Atom，但前者核显 Gen12 ✅、后者 Gen11。Gen12 仍是稳妥线；Gen11 自 2026-09 实测起可用（人脸与智能分类均走 GPU），限度是偶发 GPU HANG。
代次澄清：CPU 代数 ≠ 核显 Gen——J4025 与 i3-8100 同为 Gen9，6305 与 N100 同为 Gen12。OpenVINO 只认核显 Gen。
Gen12 内差异巨大：同为 Gen12，6305 的 Xe 是 48EU，N100 只有 24EU——规格差一倍。Gen11 → Gen12 的实测收益（4.3）：人脸快 1.7–1.9 倍、智能分类快 3.0–3.9 倍——规格差只在 GPU 密集型模块上才如实兑现。
CPU 慢算兜底：无 GPU 加速时飞牛降级 CPU 推理并限 1 核。OpenVINO 的 CPU 推理按代次分级（Xeon=AVX-512、Core=AVX2、Atom=SSE），老 Atom 系最慢。
人脸识别模型 V1.0.1 起官方支持 Intel GPU（随相册 v0.8.50 / fnOS v0.9.18 生效），与 6305 实测（face_det CPU+GPU 并行）吻合。已知坑：cluster.bin 依赖 GLIBC 2.38，Debian 12 报 start model error 需替换旧版。
六、AMD：ROCm 的 rocBLAS 内核列表决定可用性
6.1 官方口径与前置条件
fnOS v1.1.29（2026-04-16）起支持 AMD GPU 做相册人脸识别和智能识别，官方覆盖范围表述为「GCN5、Vega 一直到 RDNA4」。前提是先在应用中心（不要手动下 deb）安装：
AMD ROCm 7.2
飞牛 AI 引擎（AMD MIGraphX）（落地路径约 /var/apps/trim.ai-runtime-amd-migraphx/）
装完完整重启一次（仅后台刷新不加载新驱动）。该版本内核升到 6.18.18，升级过内核后需重装此前手动装的显卡驱动，否则设备列表可能为空。
6.2 决胜判据：rocBLAS 内核列表
官方宣传的「GCN5→RDNA4 全覆盖」指的是驱动层的识别与转码兼容，不等于 AI 推理后端有对应 kernel。真正的门槛在上游：
ROCm 7.2 的 rocBLAS 自带内核只有这些架构：
gfx1030, gfx1100, gfx1101, gfx1102, gfx1150, gfx1151, gfx1200, gfx1201, gfx908, gfx90a, gfx942, gfx950
关键限定：该列表来自社区在排查 gfx90c 问题时的排查记录，不是官方权威清单——飞牛的 MIGraphX 运行时是否自带某些 arch 的 kernel，只有实测能确认。已知反例：780M（gfx1103）不在该列表内却实测可用（见 6.4）。
可以确定的是上游态度：Vega 架构在 ROCm 6.x 之后已被 AMD 官方放弃，gfx902/gfx909（Vega 3）从未进过官方支持列表。
结论：列表用于预判，实测 GPU 占用才是终判。
飞牛社区共创的《fnOS 系统支持显卡范围验证表》口径与此一致：
相册 AI 支持以 RDNA2–RDNA4 为主；影视解码支持 GCN5 / Vega / RDNA1–RDNA4 及上述 APU。
即 Vega 系在「影视」列、不在「相册 AI」列。
6.3 「能激活」≠「会调用」
这是 AMD 侧最容易踩的认知坑，分两层：
设备枚举层：装了 ROCm 后 rocminfo 能列出核显 → 相册 AI 设置页开关点亮、显示「已启用」。v1.1.29 还专门「优化 AI 硬件加速模块的启用重试机制」「优化 GPU 型号显示准确性」，让这个开关更容易点亮。
推理执行层：rocBLAS 缺该 arch 内核 → MIGraphXExecutionProvider 加载失败 → ONNX Runtime provider 只剩 ['CPUExecutionProvider'] → 进程带着 --model_format MIGRAPHX --device GPU 参数启动却静默回落 CPU，rocm-smi --showuse 恒为 0%。
取证反例（社区，fnOS 1.2.0401，Radeon 680M）：用户反查发现 face_det.bin 未链接任何 libamdhip64.so/ROCm 运行时库、strings | grep -iE "rocm|hip|gfx" 输出为空、任务满负载时进程未打开 /dev/kfd——即「相册显示识别到 AMD GPU」只代表设备枚举成功，不代表在跑 GPU。
6.4 支持光谱（截至 2026-09）
Vega
代表核显：300U / 3500U / 5825U（Vega 3/8）
gfx：gfx902/909/90c
在 rocBLAS 列表：❌
实测状态：❌ 装了 ROCm 也 GPU 0%；部分报「启动失败，无可用设备」
RDNA2
代表核显：680M（7735HS）
gfx：gfx1035
在 rocBLAS 列表：❌
实测状态：⚠️ 设备可见但 GPU 全程 0%（社区取证见 6.3）
RDNA3
代表核显：780M（8745HS）
gfx：gfx1103
在 rocBLAS 列表：❌
实测状态：✅ 实测通过：人脸识别 GPU 22%、Compute 22%、65°C（2026-09-01）——列表外仍可用，说明列表不是绝对判据
RDNA3.5
代表核显：890M（HX 370） / 860M / 880M
gfx：gfx1150
在 rocBLAS 列表：✅
实测状态：⚠️ 890M 实测：能激活、能识别出 Radeon(TM) 890M Graphics，但人脸识别仍 CPU 为主、GPU 偶尔动；860M / 880M 无专门实测，同 gfx 同路径可外推
RDNA3.5
代表核显：8060S（Max+ 395，40CU）
gfx：gfx1151
在 rocBLAS 列表：✅
实测状态：✅ 人脸 545 张 GPU ~14%、CPU 几乎不动；智能识别 GPU 拉满
读法：AMD 侧的可支持面是 RDNA3 及以上、且核显规模足够。同为 ROCm 支持档内，40CU 的 8060S 实测优秀，16CU 的 890M 却调度不充分——进了列表只保证「能跑」，不保证「跑得快」。
6.5 300U / Vega 3 专项
Athlon 300U（Zen+，Radeon Vega 3，gfx902/gfx909）是常见误区集中点，结论：
「能在 AI 相册激活」可信——装了 ROCm 7.2 + MIGraphX AI 引擎后，设备枚举层能通过，相册 GPU 加速开关可以点亮。
但推理不会真的走 GPU——rocBLAS 不含 gfx902/gfx909 内核，必然回落到 CPU。判据见 6.3。
CPU 模式本身可用且不慢：社区实测 2.6 万张照片人脸识别，300U 纯 CPU 约 10-12 小时；同价位 Intel 3865U（带 HD610 核显加速）跑了约两天。即 300U 的 CPU 跑相册 AI 效率不差，GPU 加速属于锦上添花。
影视硬解正常：Vega 3 的 H.265 4K60 硬解可用（走 VA-API，与 ROCm 无关）。有人把「影视转码能调 GPU」误读为「相册 AI 也能调 GPU」，这是该说法最常见的来源。
别只看开关：社区帖子里的「实测成功调用 GPU」需核对是否为影视转码，或仅有开关界面截图。
6.6 社区补丁路线（非官方）
社区仓库 likelovewant/ROCmLibs-for-gfx1103-AMD780M-APU 在 v0.5.7 / v0.6.2.4 版本提供了 gfx90c（Vega 8）的 TensileLibrary 文件，解包后替换到 /opt/rocm/lib/rocblas/library/，可让 gfx90c 走通 MIGraphX 链路；理论上适用于任意 Debian/Ubuntu + ROCm 7.2 + gfx90c 环境。属非官方、需自行折腾，升级兼容性与稳定性自负。gfx902/gfx909 的适配难度更高、社区验证更少。
七、结论
Intel 判据：核显 Gen ≥ 12 为稳妥线（与 CPU 是否含 E-core 无关）。Gen9 不支持（GPU 后永久退 CPU）、Gen11 可用（2026-09-13 N5095A：intel_gpu_top 确认 face_det / img2vec 走 GPU、产出正常；限度见第 6 条）、Gen12 完整可用。
AMD 判据：核显/独显的 gfx 目标是否被推理后端覆盖。RDNA3/RDNA3.5 有实测可用案例；Vega 全系（含 300U）与 RDNA2 核显（680M）既不在社区列出的 rocBLAS 内核列表内，也无任何可用实证——预期回落 CPU，但因列表非绝对判据，最终仍需实测确认。
「能激活」不等于「会调用」：AMD 侧尤其要分清设备枚举成功与推理真正上 GPU——判据只有任务运行时 GPU 占用非 0。
实测确认：6305（Gen12 Xe）智能分类 GPU 满载（RCS 96.8%、rc6 3.2%）、人脸 CPU+GPU 并行（GPU 23.6% / CPU 75.1%），两模块的 clients 归属均已确认（4.3）；N5095A（Gen11）人脸 + 智能分类双 GPU 确认（2026-09-13）；8745HS（RDNA3 780M）ROCm 人脸识别 GPU 参与确认。
瓶颈常在吞吐：AI 耗时更常见于数据吞吐而非显卡算力；无 GPU 时飞牛降级 CPU 推理（限 1 核）可用。
Gen11 的已知限度是「偶发 GPU HANG」，不影响其可用定性：四次事件跨 51 分钟、ecode 完全相同（11:1:8ed9fff3），是驱动层的确定性故障路径而非随机过载；ai_manager 的 FallbackSrv → try recover hardware mode 会自动把服务拉回 GPU。代价是并发批处理时速度在 GPU / CPU 间骤降，界面表现为「部分照片未完成智能识别」。触发条件未锁定，见 4.2.3。
7.1 未决问题（下一轮实测的靶子）
报告里凡写「成因未定 / 触发条件未锁定」的，都汇总在这里，避免散落在各节被漏读：
1
未决问题：并发是否会引起 GPU HANG
现在答不了的原因：换真实库后 A/B/C（含并发）各 120 秒零 HANG；而三次 HANG 有两次的现场是 txt2vec，那三轮里它全程没运行
怎么答：把 C 拉到与历史崩溃同量级（≥15 分钟），并让 txt2vec 同时在场（4.2.3）
2
未决问题：Gen11 长时间跑会不会自行稳定
现在答不了的原因：观测在人工取消处结束，没跑到自然收敛
怎么答：让 AI 任务连续跑 2 小时以上，记 HANG 间隔与是否变密
3
未决问题：「重置」何时会重建 170 条提示词向量
现在答不了的原因：同样的复位方式，一次重建一次没有；已确认起「智能识别」任务本身也会触发
怎么答：反复复位并记录 category_prompt_vector 行数与 txt2vec 起停（已知坑 18）
4
未决问题：Gen12 是否也会 HANG
现在答不了的原因：三轮各 120 秒零 HANG，样本太薄，不足以说「不会崩」
怎么答：同第 1 条，长窗口覆盖 6305 与 N100 各一台
5
未决问题：AMD 侧的速率数据
现在答不了的原因：现只有 GPU 参与度证据（780M GPU 22% 等），没有任何一级的张/分
怎么答：用第十节同一套协议跑 8745HS，GPU 采样换 radeontop -d - -l（见 A.3）
6
未决问题：Gen11 的「可用」结论会不会再松动
现在答不了的原因：Gen9 也是自 v1.2.0505 起出现可用案例，说明代际门槛是软边界而非硬线
怎么答：跟踪后续版本的 i915 / OpenVINO 变更，重点看 ehl_guc 固件
7.2 待测实机队列（持续追加）
新实机到手就按第十节的 A/B/C 跑一轮，读数并入第三～五节、并修订第七节的判据。核显规格按公开资料暂列，实测以机器上的 lspci -k / rocminfo 为准：
i3-7100（Kaby Lake，2 核 4 线程）
核显：HD 630 · Gen9.5 · 24EU
要验证什么：Gen9.5 到底站哪一边——这一档现在全是社区案例（i3-8100 的 UHD 630 同为 Gen9.5），本机实测只有 Gen9（J4025，不支持）与 Gen11（可用）两端，中间是空的
7840 系列（7840HS / 7840U）
核显：Radeon 780M · RDNA3 · gfx1103
要验证什么：补齐 AMD 侧的速率数据（第 5 条）；与 8745HS 同核显，可交叉验证同一颗核显在不同整机上的表现
Athlon 300U
核显：Radeon Vega 3 · gfx902 · 3CU
要验证什么：把 6.5 的社区数字（纯 CPU 跑 2.6 万张约 10-12 小时）换成本机 A/B/C 读数——第六节至今没有一条 Vega 的一级速率数据
Ryzen 3 2200U
核显：Radeon Vega 3 · gfx902 · 3CU
要验证什么：同上；与 300U 同 gfx 目标但 CPU 是 Zen（300U 是 Zen+），顺带看降级到 CPU 推理后两代差多少
八、选型建议
跑飞牛相册 AI（GPU 加速）：
Intel：核显 ≥ Gen12 为稳妥线（Tiger Lake Xe / UHD 730/770 / Alder-N N100、N150 等均达标）。Gen11（Jasper Lake N5095/N5105）2026-09 实测核显能被调用（人脸 + 智能分类均见 GPU 占用），可用——日常与增量场景够用。若一次导入整库且要求无人值守跑完，建议直接上 Gen12：同素材实测（4.4）人脸快 1.7–1.9 倍、智能分类快 3.0–3.9 倍，折算到 2.1 万张的整库首扫，只跑智能分类约 14 小时 vs 41 小时（Gen11 的限度见 §七 第 6 条）
AMD：RDNA3 及以上，且核显规模越大越好（780M / 8060S 有实证；890M 能跑但调度不充分；Vega、RDNA2 核显不要指望）
其他：NVIDIA（GeForce 700+）为官方支持面
只做普通存储、不用相册 AI GPU：Gen9 平台、AMD Vega 平台可接受，AI 走 CPU（限 1 核，慢）；Gen11 已可走 GPU
相册增强模型：内存 ≥ 8G（硬门槛，与核显无关）
300U 类低功耗小主机：当存储/转码机合适（Vega 3 硬解 H.265 4K60 正常，待机功耗低），相册 AI 走 CPU 也能跑完（2.6 万张约 10-12 小时），但不要为 GPU 加速买它。
Intel 现役推荐：
性价比之选：N100 类（Gen12 Alder-N，相册 AI 无问题）
最强档：i3-12100 / i5-12500（UHD 730/770，AV1 全解码，相册 AI 最优）
⚠️ 内核与维护风险：飞牛 6.18.18-trim 定制内核对 i915 有裁剪翻车前科——UHD770 升级后核显失效（dkms 内核版本串不变 → Exec format error / 无 renderD128）、Core Ultra 265k 无法切 xe 驱动、i915-sriov-dkms 与内核版本错位。官方内核支持 ≠ 飞牛裁剪版实际可用。社区新增绕行解法：Alder/Raptor Lake 改走内核 Xe 驱动（xe.force_probe=4680、i915.force_probe=!4680）可绕开 dkms。对在用 6305（Tiger Lake，i915 主线路径、无 SR-IOV）：不在风险面，升级后 ls /dev/dri 验 renderD128 即可；升级前仍建议保留回退手段。
九、版本与运维提示（2026-09）
Gen11 支持演进：结论为「可用」（2026-09-13 实测，系统 1.2.0604 / 相册 0.9.13）：N5095A 的 face_det 与 img2vec 均确认调用 GPU 并正常出活（见 4.2.1），旧版「img2vec SIGSEGV 自杀」已修复。
Gen11 的已知限度：偶发 GPU HANG / 服务段错误（2026-09-13，观测窗 13:29–15:06，末段由人工取消任务结束，非故障停摆）：四次事件的完整时刻表、日志与两种后果的分野见 4.2.3。触发条件尚未锁定——换真实库后重测 A/B/C（含并发）各 2 分钟零 HANG，而三次 GPU HANG 中有两次的现场是 txt2vec，该变量比「并发」更可疑。ai_manager 全自动降级 / 回迁但会循环；GPU 错误状态落在 /sys/class/drm/card0/error，可留存备查。
排查口径：相册界面「设备负载过高或 AI 服务不可用」= 错误码 errorCode.4057 的兜底文案，指向 AI 服务调用失败，不要据此判断 CPU 负载。判断核显是否真在跑，看三处：intel_gpu_top -J 的 clients 归属 PID、服务 stdout.log 的 device: 字段（GPU / CPU）、以及 user_photo_category / face 产出行数是否增长。
相册 AI 多 Intel 显卡修复（v1.2.0505）：修复接入多张 Intel 显卡时无法调用 Intel GPU 做相册 AI 加速。
相册数据备份与还原（v1.2.0602 + 相册 v0.9.11）：系统「备份和还原」支持相册数据（含 AI 索引、人物关系）定时备份与跨设备还原，缓解「卸载重装相册丢 AI 识别结果」的痛点。
升级注意：内核升级后需重装此前手动装的显卡/网卡驱动，否则设备列表可能为空；trim 定制内核的 i915 风险见第八节末段。
十、标准测速案例（可复现的 A/B/C 流程）
本节回答三个问题：核显有没有被真正调用、单独跑多快、两个任务一起跑会不会崩。
配套脚本：飞牛AI相册测速脚本/fnai_suite.py、飞牛AI相册测速脚本/run_case.sh；制定于 2026-09-13，在 N5095A / Gen11 上实测定型。
本机（N5095A）的实测参考值见 4.2.6，本节只讲流程与判据。
10.1 这个案例回答三个问题
1
问题：核显有没有被真正调用
判据：intel_gpu_top -J 的 clients 段里出现目标服务的 PID/名字
2
问题：单独跑多快
判据：产出表斜率（张/分）+ 单张耗时
3
问题：两个任务一起跑会不会崩
判据：GPU HANG / rcs0 reset / fallback / segfault 次数
核心设计：三个用例唯一的变化是「同时跑几个任务」，其余全部锁死。这样 A/B 各自干净、C 出现差异时才能归因到「并发」本身。
10.2 不变量与素材口径
⚠️ reset 会真实删除相册 AI 产出——这套流程不要在生产库上跑。 三个用例都要求产出归零，脚本的 reset 直接清空人脸 5 张表与 pgvector 2 张表；在主力 NAS 上跑一次，等于清空相册的人脸与分类索引（界面表现为「人物没了、分类没了」，要重跑全量才能恢复）。脚本会把 photo.db 与待清表 pg_dump 到 /root/fnai_bench/backup/，但那是当轮测试态的转储、不是你的原始库，不能用来还原到测试之前。要跑就在测试机或空库上跑；非要在生产库上跑，先自己做一次完整备份。
素材集
冻结值（以本机为例）：固定的一个真实素材集（见下方「素材定义」），三用例跑完必须一字不差
校验方式：preflight 的 fingerprint + by_type
AI 产出
冻结值（以本机为例）：人脸 5 张表 + pgvector 2 张表归零
校验方式：每个用例前执行一次 reset
服务冷启动
冻结值（以本机为例）：任务启动前 trim.face_det / trim.img2vec 进程不存在
校验方式：pgrep -x
采样口径
冻结值（以本机为例）：每 10 秒一个采样点
校验方式：fnai_suite.py sample 固定
计时起点
冻结值（以本机为例）：首个产出增量出现之后才起算
校验方式：--wait-first-output（跳过 OpenVINO 冷编译）
用例时长
冻结值（以本机为例）：标准 600 秒；本文 4.2.6 / 4.3 的参考值用的是 120 秒快速口径——只够看速率与 GPU 归属，不足以断言「不会崩」
校验方式：--seconds
后台干扰
冻结值（以本机为例）：无转码、无 Docker 重负载、无备份、无新照片导入
校验方式：人工确认
10.2.1 素材定义（本案例采用「日常真实素材」，由机主自行准备与维护）
本案例不使用人工裁剪的测试图集，而是用机主自己的一份固定真实照片库，理由是它更贴近日常使用形态（手机直出的大批 JPEG、相机 RAW、以及同样的视频条目），测出来的速率才对得上真实体验。
来源 —— 机主自己的手机相册备份（如 MobileBackup/<用户>/DCIM/Camera/<年>/<月>/）
内容 —— 该年份的照片 + 视频，不剔除、不筛选
固定性 —— 一旦导入完成即冻结，测试期间不再增删；每次测试前后用 fingerprint 校验
维护方 —— 机主自行操作（导入、冻结、清理），本案例只负责记录与校验
为什么必须冻结：fingerprint 一变，三用例的素材基数就不同，速率不能横比、也不能和别的机器比。
导入过程本身会污染测量：新照片导入会触发相册重扫（日志 allPhotos :N freshPhotos:N）与缩略图生成，这是重 CPU/IO 负载。必须在导入完全结束、fingerprint 连续 5 分钟不变之后，再 preflight 重建基线、再开测。
RAW 与视频要单独记：by_type 里的 NEF（RAW）解码压在 CPU 上、mp4 走的是另一条（视频抽帧）路径，两者都会显著改变速率。跨机器对比时若 NEF/视频占比不同，只能比「同机三用例的相对关系」和「是否出现 HANG」，不能比绝对张/分。
为什么每个用例前都要 reset：三个用例必须从同一起点起跑才能横比。A 跑完会留下约 270 张已完成人脸，若不清空，C 的起点就和 A、B 不同。
reset 一律带 --keep-prompts：category_prompt_vector（170 条分类提示词向量）是常量、不属于被测产出，保留它可以避免每次让 txt2vec 重建、把冷启动噪声混进分类用例。新机器首次测试前先随便跑一次智能识别让提示词向量生成出来。
10.3 准备（一次性）
10.3.1 放脚本
sudo mkdir -p /root/fnai_bench sudo cp fnai_suite.py /root/fnai_bench/
10.3.2 登记环境 + 采基线
sudo python3 /root/fnai_bench/fnai_suite.py preflight
产出 /root/fnai_bench/baseline.json，登记：主机名 / 内核 / 核数 / 内存 / 核显 PCI ID / i915 固件与 Found ... integrated display version / /dev/dri 节点 / 相册版本 / 素材构成与指纹 / 重置前的各表行数 / 基线 HANG 与 segfault 计数。
后面所有稳定性数字都是相对这个基线的增量，所以这一步不能省。
10.3.3 冻结素材
测试期间不导入任何新照片，不跑媒体库重扫。
如果照片目录会被其他设备写入（同步、手机备份），先断开。
三用例跑完后重新 preflight，比对 fingerprint 是否与 3.2 一致；不一致则三次结果全部作废。
10.4 每个用例的标准动作（A / B / C 通用）
步骤 1 — 复位
⚠️ 界面的「重置」不是一个单纯的清空动作 —— 它会顺带把任务全量重跑起来。 本机实测（trim.photos 的 info.log，同一秒内三行）：
15:39:36 AIFaceController Run userId:1 mode:&{all} 15:39:36 Run Face 1 mode: all 15:39:36 ResetFace removed all: /var/apps/trim.photos/meta/data/face/1
即「重置人脸识别」= 清空 + 立刻以 all 模式跑全量人脸。error.log 里对应的收尾是 runAllMode err: manual cancel（人工取消时）。 智能识别的重置同理走 RunAllMode。所以不要指望重置完机器是安静的。
做法（二选一）：
1a. 推荐 —— 用脚本复位，不碰界面的重置按钮。 脚本只清表，不触发 RunAllMode：
sudo python3 /root/fnai_bench/fnai_suite.py reset --keep-prompts
脚本会：① 用 SQLite 在线备份 API 备份 photo.db，用 pg_dump 备份待清的 pgvector 表到 /root/fnai_bench/backup/；② 清空产出表；③ 打印各表归零后的行数。
⚠️ 脚本清表 ≠ 停掉正在跑的任务，机器也不会因此变安静。 本机实测（2026-09-13）：界面里手动起的人脸识别一直没退出时，连做两次脚本复位，face_task_log 被清掉后又被同一个任务接着写回（2→30→54→79→104）。关键证据是 info.log 里并没有新的 Run Face 记录——是同一个任务在长跑，不是清表触发了重跑。所以复位前必须先确认两个 AI 服务进程都不存在（pgrep -ax trim.face_det / trim.img2vec），否则清了也是白清。
用 1a 之后必须在界面上重新发起一次任务（界面的「开始」）。本方案不逆向 web API，无法脚本起任务。
1b. 若只能用界面的重置 —— 重置后立刻在界面取消该任务，然后按步骤 2 校验机器确实静下来了。取消会留下几秒内跑完的少量照片（本机实测个位数），对斜率无影响（计时起点在首个产出增量之后）。但「取消」不一定马上生效——本机实测出现过点了取消、error.log 里也落了 manual cancel，进程却仍然存活、进度钉死不动的情况（见「已知坑」）。取消后必须按步骤 2 实测确认，不能凭点了按钮就算数。
复位校验：清空后各表必须为 0；category_prompt_vector 保留 170。再确认 60 秒内进度表增量为 0 且 pgrep -x trim.face_det / trim.img2vec 均为空，才算真的静下来。
⚠️ 另一个必须等干净的窗口：170 条分类提示词的重建。 本机实测：重置之后 trim.photos 调了 initCategoryPromptsIfAbsent，把 170 个分类名逐条送去 txt2vec 编码（call txt2vec, lang: zho_Hans, text: 动物园 ……），约 1.2 秒一条、全程 GPU，跑完才 stop srv: com.trim.txt2vec。日志里数到 170 条 call txt2vec 之后再没有新的，才算这段负载结束。
这一步对**用例 B（智能识别）**是致命的污染源——提示词编码和照片编码抢同一张核显，会把 B 的速率压低、还可能直接触发 HANG。判断方法：
# 提示词重建是否还在跑：这条命令的输出行数应停在 170 且不再增长 sudo grep -c "call txt2vec" /usr/trim/logs/ai_manager/info.log # txt2vec 进程必须已经退出 pgrep -ax trim.txt2vec
步骤 2 — 等机器静下来
# 两个 AI 服务进程应该都不存在 pgrep -ax trim.face_det ; pgrep -ax trim.img2vec # 进程还在的话，看它的 CPU 时间有没有在涨（10 秒一次，连看三次） # 不涨 = 空转的残留进程，进度条也不会动，但它仍然占着服务，必须人工取消 for i in 1 2 3; do awk '{print "utime+stime=" $14+$15}' /proc/$(pgrep -x trim.face_det | head -1)/stat 2>/dev/null sleep 10 done # 进度表 60 秒内必须纹丝不动（这一步专门抓「重置自启动」） sudo python3 /root/fnai_bench/fnai_suite.py sample --label idle --seconds 60 # GPU 应该基本空闲（rc6 接近 100%），确认后 Ctrl-C sudo intel_gpu_top -s 1000
idle 这一轮若两路计数有增长，说明还有任务在跑（多半就是重置带起来的），回步骤 1 处理。
⚠️ 「进度不动」有两种，别混为一谈。 一种是任务真的结束了、进程已退出——干净。另一种是进程还活着但累计 CPU ticks 完全不动（本机实测 51864 → 51865 → 51865 → 51865，状态 S，进度钉死在 104），这是空转的残留，机器并不闲，而且界面上的「取消」可能已经点过、error.log 里也落了 manual cancel 却不生效。判断依据是 pgrep 而不是进度条：只有 pgrep 为空才算干净，进度不动但进程还在的要人工再停一次。
步骤 3 — 起任务 + 同时开始采样
终端 1（GPU 录制，全程后台）：
sudo timeout 620 intel_gpu_top -J -s 2000 > /root/fnai_bench/gt_A.json
相册界面：启动对应用例的任务（见第五节）。
终端 2（采样，10 分钟，自动等首个产出增量）：
sudo python3 /root/fnai_bench/fnai_suite.py sample --label A --seconds 600
采样器每 10 秒打印一行：t / face 完成数 / vec 完成数 / 四个进程的瞬时 CPU% / load1。
瞬时 CPU 读的是 /proc//stat 的 utime+stime 差分，不是 ps 的 %CPU（后者是进程启动至今的平均值，测速时没有意义）。
步骤 4 — 收尾与解析
sudo python3 /root/fnai_bench/fnai_suite.py gpu --label A --file /root/fnai_bench/gt_A.json
此时 /root/fnai_bench/results/A.json 里同时有速率、CPU、GPU 与稳定性全套数据，A.csv 是逐点原始记录。
步骤 5 — 冷却
停掉任务 → 等两个 AI 服务进程消失、rc6 回到约 100% → 再进下一个用例。
10.5 三个用例
A
相册界面操作：只启动人脸识别
同时在跑：仅 trim.face_det
预期看到：face_task_log 增长，user_photo_vector_1_0 不动
B
相册界面操作：只启动智能识别
同时在跑：仅 trim.img2vec（+ trim.txt2vec）
预期看到：user_photo_vector_1_0 增长，face_task_log 不动
C
相册界面操作：人脸识别 + 智能识别同时启动
同时在跑：两个都在
预期看到：两张表同时增长
用例 C 的启动前校验：先启动一个，确认其服务已在 GPU 上并开始产出，再启动第二个。用 run_case.sh 的第三个参数把门禁交给脚本，不要靠人眼盯着时间：
sudo bash /root/fnai_bench/run_case.sh C 600 face_det,img2vec
第三个数是用例时长，按 10.2 的不变量取 600 秒（只想验证流程是否跑通时可用 120 秒做快速演练，本文 4.2.6 与 4.3 的参考值都是 120 秒窗口——短窗只够看速率与 GPU 归属，不足以断言「不会崩」）。它会先等 trim.face_det 与 trim.img2vec 同时在场，再等首个产出增量、再开表。若省掉第三个参数，采样器的「任一进度表在涨」条件会被先启动的那个服务立刻满足，窗口前半段就成了单任务，这轮 C 作废（见「已知坑」第 15 条）。
两个服务都在场后，用 comm 名精确复核（不要用 pgrep -f 'trim.face_det.bin'，匹配不到，见「已知坑」第 14 条）：
pgrep -ax trim.face_det ; pgrep -ax trim.img2vec
最终判定看采样输出：face= 与 vec= 两列都在涨，才说明这轮 C 有效。
用例 C 的意义：它是本案例唯一能区分「崩溃是负载高引起」还是「并发引起」的用例。A、B 各跑 10 分钟不崩、C 崩了，就说明崩溃与并发相关而与单任务负载无关。（2026-09-13 的实测里 C 没崩，这条推论因此未被证实，见 4.2.3。）
10.6 记录与汇总
sudo python3 /root/fnai_bench/fnai_suite.py summary
生成 /root/fnai_bench/summary.md，一张表横向对比三个用例：
再补一张跨机器对比表（每台机器三行）：机器 / 核显代际 / 内核 / 相册版本 / A 速率 / B 速率 / C 速率 / C 的 HANG 次数。
手工补充记录（脚本采不到的）：
机型 / 核显代际 / 内核 / 相册版本 ——
界面是否报错、报什么 ——
任务是否跑完、是否人工中断 ——
室内温度 / 是否降频 ——
10.7 判定口径（避免各人说各话）
1. 核显有没有被调用 —— 只看一件事：GPU 采样的 clients 段里有没有目标服务的名字与 PID。配置开关、界面图标点亮都不算。
2. 速度取斜率，不取端点差 —— 用最小二乘拟合 (t, 计数)，输出「张/分」。端点差会被首尾两次采样的抖动放大。
3. 是算力受限还是时延受限 —— 看 CPU 与 GPU 两个均值：
GPU 均值接近 100%，rc6 接近 0 —— GPU 受限：换更强的核显能提速
GPU 与 CPU 都远低于 50% —— 时延受限：瓶颈在串行环节（缩略图查找、每张一次 IPC 往返、DB 写入），加 CPU 加核显都不会变快
某个进程 CPU 接近单核 100% —— CPU 受限：看是推理进程还是调用方 / 缩略图服务
本机实测到的两种形态：人脸识别 GPU 均值 60.5%、rc6 还有 39% 空闲、CPU 94.4%（用不满核显，瓶颈不在 GPU）；智能识别 GPU 均值 98.1%、rc6 1.8%（GPU 受限）。同一台机器上两个任务的瓶颈完全不同，所以不能只测一个就下结论。（本行原记「人脸 GPU 约 20%、CPU 约 23%」，出自 2026-09-13 已作废的 NEF 中间库，见 4.2.6。）
4. 稳定性口径 —— 全部相对 preflight 基线取增量，别用绝对值：
GPU HANG
来源：dmesg
含义：内核判定 GPU 挂死。注意 HANG ≠ 进程死亡：本机四次事件里三次以 segmentation fault 收场，另一次服务存活、只被标记 save failed boot cmd ... recoverable: true, expire: 2m0s 后降级到 CPU。所以 HANG 数与 segfault 数要分别记，不能互相替代
Resetting rcs0
来源：dmesg
含义：i915 抢占看门狗超时、整条渲染引擎被 reset（该引擎上所有上下文一起被销毁）
fallback srv:
来源：ai_manager info.log
含义：ai_manager 把服务降到 CPU/ONNX
try recover hardware mode success
来源：ai_manager info.log
含义：自动回迁 GPU
segmentation fault
来源：ai_manager error.log
含义：服务进程崩溃
code=20150
来源：ai_manager error.log
含义：rpc 调用失败（调用方拿到的就是它）
5. 人工停止 ≠ 崩溃，必须分开：
有序/人工停止：stopped intentionally by signal: terminated
崩溃：signal: segmentation fault + code=20150
报告里凡出现「服务停了」，必须写清是哪种。
10.8 已知坑（本机实测踩出来的，务必先看）
读数与采样口径
sudo 时间戳会在长脚本里过期 —— 脚本尾部用 $(sudo dmesg ...) 会静默返回空，grep -c 于是给出 0，读数直接错。本套件全程用 sudo python3 一次提权，不要在脚本里混用零散 sudo。
intel_gpu_top -J 的输出不能逐行 json.loads —— 它是多个 pretty-print JSON 对象首尾相接，逐行解析会得到 0 帧（本机就踩过）。要用 json.JSONDecoder().raw_decode 循环解析（套件里已封装）。
分类的行数不能当速率 —— user_photo_category 只给匹配上分类的照片写行（170 个智能分类，本机匹配率约 15%），所以它增长极慢且会长时间停顿，看着像卡死。分类的真进度是 pgvector 的 user_photo_vector_1_0（每张照片一行）。
人脸的进度是 face_task_log —— 一行 = 一张照片，可以直接用。注意 face 表是一行一张脸（本机约 2.7 张脸/照片），不能当进度。
ps 的 %CPU 是启动至今的平均值 —— 短窗口测速必须读 /proc//stat 差分。
冷编译要排除 —— OpenVINO 在 GPU 上首次跑模型要编译 .blob / .cl_cache（本机约 20 秒），第一批照片明显慢。所以计时起点定在「首个产出增量出现之后」。
界面文案不能当定性依据 —— 「设备负载过高或 AI 服务不可用」是 errorCode.4057 的兜底文案，把「负载」和「服务不可用」两个原因并列。本机实测命中的是后半句（服务段错误、套接字断开），不要据此去查 CPU 负载。
RAW 素材的 CPU 开销 —— NEF 等 RAW 的解码/缩放压在 CPU 上。素材构成差异大的两台机器不能直接比速率，必须在报告里写明 NEF/JPEG 比例。
进程、库与环境
pgrep -x 匹配的是内核 comm，最长 15 字符 —— 服务名过长会被截断导致匹配不到。
pgvector 的 PostgreSQL 实例是按需启停的，测速时往往正停着 —— 它和系统主 PG（/var/lib/postgresql/15/main）是两个独立实例，socket 在 /var/apps/trim.photos/meta/data/pgvector/sock。相册不用它就把它停掉，socket 文件随之消失。此时任何 psql 都会连接失败——若脚本把失败吞成 -1，就会拿 -1 当行数继续算，读数全错（本套件第一版正是这么翻的车，现已改为读不到即报错退出）。手动拉起：
sudo bash /var/apps/trim.photos/meta/data/pgvector/start.sh ls /var/apps/trim.photos/meta/data/pgvector/sock/ # 出现 .s.PGSQL.5432 才算起来
套件的 preflight / reset / sample 会自动拉起它（见 pg_ensure()）。
重置会连带重建 170 条分类提示词向量 —— 见步骤 1 的第二个告警框，--keep-prompts 可避免。
界面的「重置」会自启动全量任务 —— 见步骤 1 的告警框。以为重置完是零点静默、实则任务已在 GPU 上跑，直接起用例会得到「两次叠加」的读数。
测试期间不要跑别的重活 —— 转码、Docker、备份、系统更新都会污染 CPU 与 IO 读数；系统更新还可能换内核，直接让结论作废。
任务状态判读
pgrep 的两种匹配别用错 —— pgrep -x trim.face_det 匹配的是内核 comm（最长 15 字符，这几个服务名都塞得下，可用）；pgrep -f 匹配的是完整命令行，而这些服务的实际命令行是 /usr/trim/lib/ai_manager/com.trim.face_det/cp311/face_det.bin，不含 trim.face_det.bin 这个子串。本机实测：用 pgrep -f 'trim.face_det.bin' 查，服务明明在跑却返回空（差点据此误判「服务不在」）。要按命令行匹配就用 com.trim.xxx/cp311/ 片段。
用例 C 不能只靠采样器的「首个产出增量」开表 —— 采样器的等待条件是「任一进度表在涨」，所以先起了智能识别再去起人脸时，它会立刻开表，窗口前半段其实只有单任务，这轮 C 就废了。run_case.sh 的第三个参数就是干这个的：run_case.sh C 600 face_det,img2vec 会先等这两个服务同时在场再开表。判定这轮 C 是否有效，不看进程，看采样输出里 face= 与 vec= 两列是否同时增长。
点了「取消」不等于任务停了 —— 本机实测：error.log 里已落了三条 manual cancel，trim.face_det 进程却仍然存活、进度钉死不动、累计 CPU ticks 冻在 51864→51865→51865→51865。这种残留既不产出也不释放服务。判断机器是否真的闲，只能看 pgrep -x 为空，不能看进度条不动。
AI 服务是按需启停的，进程时有时无是正常的 —— ai_manager 空闲时会回收它（release idle srv → stop srv → stopped intentionally by signal: terminated）。所以**「进程不在」不等于任务结束**，要结合进度表一起看；反过来，进度表在涨时进程却查不到，多半是 pgrep 匹配串写错了（见第 14 条）。
脚本与残留状态
「重置」会不会重建 170 条提示词向量，触发条件还没锁死 —— 2026-09-13 在 6305 上观测到两种结果：一次重置后 category_prompt_vector 稳稳保持 170、txt2vec 全程没起；另一次同样的复位方式却把 txt2vec 拉了起来，提示词掉到 52 再补回 170、txt2vec 调用 累计从 170 涨到 340（多编了一遍）。原先以为「只有界面上的『重置』按钮才触发重建」，那次说明起『智能识别』任务本身也会触发。结论：别把「复位后是零点静默」当默认前提，复位后必须盯 category_prompt_vector 与 txt2vec 进程，等它归位再起用例。本机这次重建约 30 秒（协议步骤 1 记的 204 秒是另一台机器的值，不是常数，别拿它估时间）。
run_case.sh 的服务门禁只查「在场」，不查 txt2vec 是否退出 —— 第三个参数（如 face_det,img2vec）等的是这两个服务同时存在，但若复位触发了提示词重建，txt2vec 会一起在场抢核显，窗口就被污染。本机这轮是在外面套了个串行器，先确认 txt2vec 退出、再冷却 20 秒、才起用例 C，窗口才干净。直接跑 run_case.sh C 时要自己补这道门；另外这轮 C 从「两服务到位」（18:31:43）到开表（18:31:48）只差 5 秒，余量很薄，机器再慢一点就会把重建段算进窗口。
device 字段在服务没跑时读到的是历史值 —— 该字段取自服务 stdout 里末次出现的 device:GPU/CPU。用例 C 里 txt2vec 全程没运行，device.text 却读到了 GPU（上一轮遗留）。服务没在跑时这个字段无意义，判读时必须结合该服务 CPU 占用是否为 0。
附录 A：速查与自行验证
A.1 路径与表速查（fnOS + 相册 0.9.13，换机器先核对）
相册 SQLite —— /usr/local/apps/@appdata/trim.photos/db/photo.db
相册向量库（PostgreSQL + pgvector 独立实例） —— socket /var/apps/trim.photos/meta/data/pgvector/sock，库 postgres
AI 服务日志 —— /usr/trim/logs/ai_manager/{info.log,error.log}
单服务日志 —— /usr/trim/logs/ai_manager/com.trim.<服务名>/stdout.log
人脸识别进度
表：SQLite face_task_log
一行代表：一张照片
人脸识别结果
表：SQLite face
一行代表：一张脸
人脸聚类结果
表：SQLite person
一行代表：一个人
分类进度（真进度）
表：pgvector user_photo_vector_1_0
一行代表：一张照片
分类结果
表：SQLite user_photo_category
一行代表：一个「照片 × 分类」匹配
分类提示词向量
表：pgvector category_prompt_vector
一行代表：一个分类（170 条，常量）
人脸特征
表：pgvector face_vector_1
一行代表：一张脸
人脸识别
comm：trim.face_det
作用：人脸检测
智能识别
comm：trim.img2vec
作用：图像向量（智能分类 / 相似照片）
以文搜图
comm：trim.txt2vec
作用：文本向量（分类提示词编码）
调用方
comm：trim-photos
作用：相册主进程
图像服务
comm：imagesrv
作用：缩略图与图像处理
A.2 自行验证方法
通用
确认核显 Gen / 设备 ID（Intel）：lspci -k | grep -A2 VGA（或看 /sys/class/drm/ 的 renderD*），设备 ID 对照正文兼容表。
查看相册 AI 进程（root 进程，需 sudo）：sudo pgrep -f 'face_det.bin|img2vec.bin'
GPU 故障日志：/usr/trim/logs/ai_manager/info.log；失败时见 error.log（GPU HANG、ProgramBuilder build failed、clWaitForEvents -14）。
相册元数据与任务进度：/usr/local/apps/@appdata/trim.photos/db/photo.db（SQLite，file_task 表含 file_count/done_count）。
Intel 专用
逐进程 GPU 引擎占用：sudo intel_gpu_top -l -J（i915 平台可用）。
AMD 专用（三条命令定论）
看架构：sudo /opt/rocm/bin/rocminfo | grep gfx → 预期 gfx902/gfx909（Vega 3）、gfx90c（Vega 8）、gfx1035（680M）、gfx1103（780M）、gfx1150/1151（RDNA3.5）
看 rocBLAS 是否有你的 arch（决定真假）：ls /opt/rocm/lib/rocblas/library/ | grep -i gfx
终极判据 · 任务运行时看 GPU 占用：watch -n1 sudo /opt/rocm/bin/rocm-smi --showuse
验证 MIGraphX provider 是否挂上：
sudo /var/apps/trim.ai-runtime-amd-migraphx/meta/penv/310_general/bin/python3 -c "import onnxruntime as ort; print(ort.get_available_providers())"
期望看到 MIGraphXExecutionProvider；只有 ['CPUExecutionProvider'] 就是没挂上。
验证算力节点：AI 任务运行时 ls -l /proc//fd | grep kfd，未打开 /dev/kfd = 走的还是 CPU。
以上路径基于飞牛 fnOS（Jack-fnOS，内核 6.18.18）实测，其他版本目录结构可能略有差异。
A.3 换机器适配点
改脚本顶部 CONFIG 段：PHOTO_DB / PG_SOCK / AI_LOG_DIR。先在机器上 ls 确认这几个路径存在，不同相册版本或自定义安装位置会不一样。
AMD 机器：没有 intel_gpu_top，GPU 采样换成 radeontop -d - -l；device: 字段取值仍是 GPU / CPU，其余口径不变。若走 ROCm，还应记录 rocminfo 的 gfx 目标。
换机器后先跑一次 preflight，确认五张产出表都存在；表名若对不上，说明相册版本差异，需要先重新定位进度口径。
素材不同（数量、RAW 比例）时不能直接比速率，只能比「同机三用例之间的相对关系」和「是否出现 HANG」。
测试数据均为实机采样，可复现。方法与实测读数见正文第三、四、十节及附录；逐点采样原始文件不随文档存放，重跑即得。
版本 v3.4 · 2026-09-13 · 标明持续更新 + 待测队列：抬头写明本文持续更新——每台新实机跑完 A/B/C 就追加读数、并修订已写下的结论；新增 7.2 待测实机队列（i3-7100 / 7840 系列 / Athlon 300U / Ryzen 3 2200U 及各自要验证的问题）。
版本 v3.3 · 2026-09-13 · 去重与导航：§4.5 删去与 10.7 重复的判据表，只留本机实测形态；§七 第 1 条与第八节 Intel 条目去重（故障机理只留在 §七 第 6 条）；附录 A/B 合并为「附录 A：速查与自行验证」（A.1 路径与表速查 / A.2 自行验证方法 / A.3 换机器适配点），全文引用同步改指；§10.8 已知坑分四组小标题（读数与采样口径 / 进程、库与环境 / 任务状态判读 / 脚本与残留状态），编号未变；文首新增「怎么读」导航。勘误（内存构型）：三台 Intel 测试机内存构型一致，均为 8G（2×4G DDR4）双通道——6305 与 N5095A 为 DDR4-2666、J4025 为 DDR4-2400；原记 N5095A「7.5G 单通道」与 J4025「4G 单根」均有误（7.5G 只是系统可用量，通道数系误推）；4.4 里把「单通道」当作 Gen11 分类慢的成因之一已删去（两台同为 8G 双通道，该项不成立），§五 中未经实测的「Xe 48EU + 双通道 ≈ N100 的 3-4 倍」也改为只陈述 EU 规格差。
版本 v3.2 · 2026-09-13 · 补总表与台账：§四 开头新增三代实机总表（Gen9 / Gen11 / Gen12 的 GPU 归属、张/分、并发、HANG 一表读完）；§三 新增 3.1 证据台账（每条结论对应哪次实测、哪台机器、哪个版本）；§七 新增 7.1 未决问题（6 条待验证的靶子）；§10.2 顶部补「reset 会真删相册 AI 产出」的安全告警，并把用例时长区分为 600 秒标准口径与 120 秒参考值口径。勘误两处：① 4.2.3 后果表的「进程死亡 4 次」应为 3 次（观测窗内 3 次死亡 + 窗外 15:40:24 那次服务存活），小节标题的「16 分钟」与 §七 的「跨 51 分钟」现已分别标注为窗内 / 四次合计；②「三次崩溃中有两次的现场是 txt2vec」更正为「三次 GPU HANG 中有两次」——按 4.2.3 的表逐行核对，这是唯一与表相符的口径。
版本 v3.1 · 2026-09-13 · 补录 Gen12（6305）A/B/C 实测：4.3 由定性描述改为完整实测表（人脸 247.4 张/分、分类 25.72 张/分、并发 145.05 / 20.1，三轮零 HANG / 零 rcs0 reset），4.4 补并发分摊与衰减对照；确认 Gen11 → Gen12 收益不均衡（人脸 1.7–1.9×、分类 3.0–3.9×），根因是两模块瓶颈不同（人脸压不满核显、分类是纯 GPU 瓶颈）；§五 兼容性表 Gen12 6305 行与 §八 选型建议同步更新；新增已知坑 18–20（提示词重建触发条件未锁死、run_case.sh 服务门禁不查 txt2vec 退出、device 字段历史值陷阱）。
版本 v3.0 · 2026-09-13 · 合并《标准测速案例》：第十节收录 A/B/C 标准动作与判定口径，附录 B 收录路径速查与换机适配点（v3.3 已并入附录 A）；同核显核心的 SKU 合并为一行（Jasper Lake N5095A/N5105/N6005、Alder-N N100/N150 系、AMD gfx1150 的 890M/860M/880M）· 同版删去 7 处截图引用，源文件已删除。
v2.7：用机主真实 JPEG 库重测 Gen11 三用例，推翻 v2.6 的 4.2.6 结论——旧结论「GPU 不是瓶颈」是 975 张 NEF 中间库的产物，瓶颈压在 RAW 解码；真实库下人脸 148.94 张/分（GPU 60.5%，核显非瓶颈）、智能识别 8.54 张/分（GPU 98.1%、rc6 1.8%，纯 GPU 瓶颈）。三轮含并发全部零 HANG，不再支持「崩溃由并发引起」——三次历史 HANG 有两次现场是 trim.txt2vec，而本轮 txt2vec 全程未运行。详见 4.2.6 / 4.4 / 4.5。
v1.4（原测速案例）：fnai_suite.py 与 run_case.sh 在真机跑通 A/B/C 三轮 · 修 sec_per_photo 误除以末值而非增量的 bug · 套件新增整机 CPU 采样（cpu.sys）· 新增已知坑 14–17 · 步骤 1 更正「脚本清表不会停掉正在跑的任务」。
如需转载注明出处
作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～
