- 设备环境：QNAP TS-453Dmini
- CPU: J4125
- GPU: UHD 600
- BUG现象：AI相册显示启用 GPU 计算成功，并选中了UHD 600，实际人脸识别或智能识别时GPU完全无法使用，导致一小时只能处理200张左右的照片
最近把威联通的古董NAS重装了万人推荐的飞牛，买了枚新SSD来安装，结果一个星期新SSD坏了，又换回老SSD了，期间让人最无法接受的就是相册的人脸识别和智能识别，1W+的照片，一小时只能出了200左右，两天都跑不完，也就是说，从威联通切到飞牛这段时间里，5天多都在跑相册的识别，似乎论坛里一直有人反馈，却没有看到一个有价值的回答。
于是准备自己动手查查，找了一下日志发现GPU验证已经显示正常，内容如下：
/usr/trim/logs/ai_manager/com.trim.gpu_verify/stdout.log
[15:18:14.034] [info] check_model:/usr/trim/lib/ai_manager/com.trim.gpu_verify/check_support.onnx
[ne]max connections: 10 (5 per worker), workers: 2
[ne]socket timeout: 0s
[15:18:14.174] [info] Available OpenVINO devices: ['CPU', 'GPU']
但是 com.trim.face_det 和 com.trim.img2vec 运行都报错了
Traceback (most recent call last):
File "/workspace/img2vec/img2vec.py", line 119, in <module>
File "/workspace/img2vec/img2vec.py", line 59, in __init__
File "/usr/trim/lib/ai_manager/pyenv/lib/python3.11/site-packages/openvino/runtime/ie_api.py", line 543, in compile_model
super().compile_model(model, device_name, {} if config is None else config),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Exception from src/inference/src/cpp/core.cpp:104:
Exception from src/inference/src/dev/plugin.cpp:53:
Check 'false' failed at src/plugins/intel_gpu/src/plugin/program_builder.cpp:185:
[GPU] ProgramBuilder build failed!
Exception from src/plugins/intel_gpu/src/runtime/ocl/ocl_stream.cpp:429:
[GPU] clWaitForEvents, error code: -14
顺着报错信息，看到这是Intel的OpenVINO的初始化接口，就手写了几行Python在NAS里运行看看
model = core.read_model(model=model_xml, weights=model_bin) if model_bin else core.read_model(model_xml)
compiled = core.compile_model(model=model, device_name=device)
把人脸识别和智能识别的两套模型丢进去跟前面日志是相同的错误。
期初以为是模型太大，UHD 600这种弱**核显无法加载，毕竟QNAP并没有开放BIOS设置GPU分配内存。
于是我在huggingface上弄了几兆的小模型 face-detection-retail-0004 分别试了FP32/FP16/FP16-INT8的版本，错误依旧一样。
再搜索发现可能是驱动问题，但是我记得视频里是可以调用GPU解码的，直到用 demsg看到GPU HANG
[ 0.020984] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.12.18-trim root=UUID=b94c1d4a-9c14-469c-a271-4f3585de1a26 ro modprobe.blacklist=pcspkr quiet splash i915.enable_guc=0 i915.enable_rc6=0
[ 1.697076] ACPI: bus type drm_connector registered
[ 2.552323] i915: unknown parameter 'enable_rc6' ignored
[ 2.553065] i915 0000:00:02.0: [drm] Unknown revision 0x06
[ 2.553070] i915 0000:00:02.0: [drm] Found GEMINILAKE (device ID 3185) display version 10.00 stepping **
[ 2.553076] i915 0000:00:02.0: [drm] Unknown revid 0x06
[ 2.553722] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 2.553851] i915 0000:00:02.0: [drm] couldn't get memory information
[ 2.554329] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 2.555498] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
[ 3.577770] i915 0000:00:02.0: [drm] [ENCODER:147:DDI A/PHY A] failed to retrieve link info, disabling eDP
[ 3.583539] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 0
[ 3.683871] fbcon: i915drmfb (fb0) is primary device
[ 3.748373] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[ 7.508795] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
[ 7.564008] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 7.564237] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm.
[ 8.327362] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[ 8.455607] snd_hda_intel 0000:00:0e.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 8.687239] mei_hdcp 0000:00:0f.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
[ 57.804710] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
[ 57.804790] i915 0000:00:02.0: [drm] python[7129] context reset due to GPU hang
[ 57.809107] i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:e757fefe, in python [7129]
这里已经不得不承认是GPU驱动问题了，搜了一圈发现很多人遇到了，结论就是：
在Linux 6.X系列的内核中，GEMINILAKE系列的核显（如：UHD Graphics 600）都有兼容性问题，i915对老设备只有5.X系列支持得比较好
不死心的我看到有人提到通过设置GRUB参数，禁用一些功能可能可以兼容，于是我在 /etc/default/grub 里设置了
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_guc=0 i915.enable_rc6=0"
可是依旧不管用，clinfo里看到驱动版本是 OpenCL 3.0 NEO + 24.31.30508.7，已经非常新了，现在我也不知道怎么处理了，内核降级？trim里那么多定制的组件在旧内核中能用吗？不敢试啊，我怕3天的相册任务再来一次！问题已经定位到这里了，官方能提供内核降级渠道？或者更完美的解决方案？
已知的解决方案是降级到Linux 5.X内核
手动分割线，以下是吐槽
还有一个槽点就是NAS最核心的功能：文件管理，NAS系统怎么说也用了四五个了，第一次看到飞牛这种管理方式的。一般的NAS系统，创建文件夹的时候，这个文件夹应该就是共享态，通过权限管理约束可访问用户，飞牛是直接在 /volN/1000下面创建的，倒不是 <UID>这一级目录不可行，只是感觉这就不是共享目录了，选中一个文件夹进行分享后，是在 /vol0N/<UID> 下创建了一个软连接，其他用户即便是能访问，也是通过共享目录才能看到，给人的感觉就是这是一台电脑共享了一个文件夹的感觉。
另外，ssh上去 mkdir创建在非 /volN/<UID>下的文件夹在WebUI的文件管理里默认是看不到的，需要切换到管理员视角才行，也就是其他app是无法选中这个文件夹的，例如相册、视频、docker-compose等等，整个飞牛的思路更像是在做个人电脑的思路，而不是 NAS(Network Attached Storage)
2025-11-6 01:11:54
2025-11-7 22:52:44 楼主