机器学习模型选择与显存

先弄清两类模型

Immich 的机器学习微服务内部其实有两种模型：人脸识别模型负责把脸从照片里找出来并聚成人物组，文字向量模型负责把照片内容变成可搜索的向量。部署时不用刻意区分，但调优时要知道自己换的是哪一个——换小模型省显存是为了哪个功能，效果落点不同。

默认的人脸识别模型在准确率和体积之间取了一个比较均衡的点，普通家庭照片足够用。默认的文字模型同样如此，支撑日常的语义搜索。正因为默认配置是多数人的最优解，建议第一次部署不要动它们，跑完全库觉得哪里不满意再针对性调整。

一个常见的误会是以为模型越大识别越准越大越好。实际上人脸识别存在收益递减：超过某个档位之后，准确率的提升感知不到，显存和扫描时间却实打实地增加。对几千到几万张照片的家庭库，默认模型就在甜点上。

什么时候该换模型

需要换模型的信号通常很具体：显存告急导致微服务启动反复失败或者时不时崩溃；全库扫描慢到无法接受，想用更轻的模型换时间；或者反过来，对识别准确度要求高，愿意用更大模型换效果。没有这些信号，换模型的收益几乎为零，还可能带来新的兼容问题。另外一个冷门的信号是人物分组数量异常——人物数远多于实际人数，说明模型把同一个人拆成了好几组，这时候换模型比反复手动合并有效率。

第四种情况要单独提一句：换文字向量模型会导致已有的搜索索引需要重建，因为不同模型的向量空间不兼容。这一点官方文档有提示，动手前先估算全库重建的时间成本。人脸识别模型则没有这个包袱，换完会自动逐步重新分组。

显存到底吃多少

人脸识别模型的推理显存占用主要来自模型本体和每次批处理的中间结果。Immich 批量处理时的图像张数会影响瞬时占用，显存吃紧时可以先把并发数调小，扫描从三张一批降到一张一批，显存需求立刻就降下来了，代价只是总时间拉长。

一个实操感的参考：入门级显卡跑默认模型很从容；跑大型模型可能会到显存上限附近反复横跳；纯 CPU 模式则完全不占显存，代价是时间。所以省显存有三条路可选——换小模型、降并发、干脆用 CPU，三者可以叠加。

显存与并发的关系

人脸识别模型的推理显存占用主要来自模型本体和每次批处理的中间结果。Immich 批量处理时的图像张数会影响瞬时占用，显存吃紧时可以先把并发数调小，扫描从三张一批降到一张一批，显存需求立刻就降下来了，代价只是总时间拉长。反过来说，显存充裕时调高并发能明显缩短扫描时间，这是一组可以随时调的旋钮。

并发不是越大越好。CPU 我核数有限时，高并发只会让线程互相等待，磁盘也可能成为短板——机械盘的随机读取跟不上并发队列时，加并发纯属添乱。一个实用的起点：CPU 核数除以二向下取整，跑一轮看时间和负载再微调。

换模型的具体操作

换模型在 Immich 里是配置项，不是动文件夹。在管理界面的机器学习设置里可以指定模型名称，服务会自动从模型仓库拉取。不需要自己下载文件、放目录、改权限——这一点比很多自建项目友好得多，也是它降低使用门槛的关键设计之一。

几个配套细节值得注意。换模型后微服务会自动重启并重新扫描，已经分好组的人脸会清空重来，名字要重新指认。所以换人脸模型的时机最好是全库扫描还没开始、或者愿意接受重来一次的时候。模型文件有数十 MB 到上百 MB 不等，第一次拉取需要点时间，国内网络环境慢的话可以先挂代理拉完再断开。

换模型的频率建议是低频操作。每次大版本升级时官方可能更换默认模型，这时候跟着官方走通常比自己折腾更稳。社区讨论里常出现的玄学问题——同样的配置换个版本效果就变——多半是默认模型跟着版本变了，而不是玄学。

无论选哪种组合，都建议把当前用的模型和并发设置记进部署笔记。微服务反复重启的故障现场里，你未必记得一个月前改过什么——哪怕只是一行环境变量的改动，也可能是问题的源头。

CPU 模式的生存指南

没有显卡的读者完全可以把这一节当主路径看。CPU 模式不是降级方案，它和 GPU 模式跑的是同一套模型、同一套逻辑，唯一差别是计算发生在 CPU 上。几千张照片在四核 CPU 上扫描半个小时以内就能完事；两万张以上才开始需要耐心，睡前点扫描、第二天看结果是标准节奏。把电源管理里 CPU 的节能策略检查一遍，有些小主机会主动降频，扫描期间保持全速更有利于尽早跑完。

两个提速小技巧。第一是确认 CPU 没有被其他服务占满——转码任务和扫描抢核心时会互相拖慢；第二是在首次扫描期间临时调高机器学习服务的并发数，跑完再调回。这两招都不花钱，效果立竿见影。

还有一招是分批扫描。Immich 支持在新增照片时逐步处理，不必一次性导入全部历史照片。把几年的旧照片分成年度批次导入，每批跑完再导入下一批，既能尽早开始用相册，也避免机器连续高负载十几个小时。对温控严格的被动散热小主机，这个策略尤其友好。分批的另一个好处是出问题好定位：某一批导入之后识别效果异常，范围立刻缩小到那批照片，而不用面对一整个图库找原因。

值得注意的是，更换文本向量模型、重建索引这类操作都应该安排在夜间。它们对资源的占用和扫描类似，但不可中断性更强——中途打断可能导致索引处于不一致状态，需要重新开始。

社区里的常见组合

社区经过大量实践，沉淀出一些常见组合可以参考。照片量在几万张以内的家庭，默认模型加任意入门显卡是万金油；纯 CPU 环境下，把并发调到一或二、用默认模型跑通宵是常见做法；对识别效果有更高要求的，会换更大的人脸模型，同时把搜索索引重建安排在夜间。这些组合没有唯一答案，但都比从零摸索快。

另外说个容易混淆的点：机器学习服务的显存占用和你换不换版本关系不大，和同时处理的图片数量关系很大。所以升级 Immich 之后如果突然显存紧张，先怀疑并发设置，再怀疑版本。

机器学习服务的健康检查

上线之后，这个微服务的健康状态值得偶尔看一眼。判断它工作正常有三个简单标志：管理界面里机器学习设置页能正常打开；新上传的照片几分钟内出现人脸分组；搜索接口响应不超时。三者都正常说明它运转良好，不用深究内部细节。养成每月扫一眼的习惯，比出问题时手忙脚乱从容得多。

反过来，几个异常信号值得注意：设置页打不开通常是服务挂了，重启容器多半解决；照片上传后一直没有人脸分组，可能是扫描队列积压或者模型拉取失败；搜索每次都超时，多半是并发设太高把服务压垮了。日志里相关的关键词都很直白，对照上文的故障表基本能定位到位。

日志在哪里看需要单独说一下：容器日志通过宿主机的容器命令查看，Immich 的管理界面里也能看到任务队列的运行状态。后者足够回答日常问题，前者只在服务级别故障时才需要翻。

小结

模型选择的核心就一句话：默认配置是多数人的最优解，看到具体信号再动手。省显存有三条路（小模型、降并发、 CPU 模式）可叠加使用；换文字向量模型要重建索引，换人脸模型要重新分组，把这两次重建安排在全库扫描之前最划算。

延伸阅读

• 上一章《Docker Compose 全家桶解读》：机器学习服务在全家桶里的位置。
• 《自建 NAS 完全指南》：显卡直通与容器资源限额的配置方法。
• 《群晖 DSM 实用指南》：群晖上容器与硬件直通的操作差异。