导读：本站Ollama篇刚聊过"跑在自己机器上的AI"，这篇把AI用在更戳人的地方——相册。手机256G被照片塞满、Google Photos高质量备份开始吃订阅费、iCloud容量按月交钱、国产网盘的"相册智能分类"背后是云端AI在翻你的全家福——照片这个刚需，隐私浓度是所有数据里最高的，却偏偏被塞在别人服务器上最久。Immich是这个赛道目前最能打的选手：手机APP自动备份、人脸识别、智能搜索、时间线回忆、外链分享，功能对着Google Photos抄作业，但照片一张不离开你的机器。这篇讲透：照片管理的三重焦虑、Immich的功能版图、小鸡上的部署姿势（机器学习容器怎么取舍）、手机端自动备份与省电、AI识脸和搜索的实际体验、家庭多账号与分享、资源账（内存是硬门槛）、以及怎么把它接进备份篇的restic体系——让"回忆"这种东西，从此只存放在你自己的硬盘上。
一、三重焦虑：空间、隐私、检索
手机相册的困境几乎是全民级的。焦虑一，空间：照片视频一年产生几十上百G，256G的手机两年就顶到红线，iCloud/Google One的订阅费交着难受、不交难受；换机迁移更是渡劫——微信里传一遍压缩到没法看，数据线导出又慢又乱。焦虑二，隐私：你可能不在乎别人看你聊天记录，但相册不一样——孩子的成长照、家里的门禁密码照片、身份证银行卡的随手拍、体检报告的截图，全躺在云相册里被"智能分类"着。所谓智能，意味着云端AI逐张看过你的照片；所谓免费，意味着你的家庭影像在给别人的模型做训练数据。焦虑三，检索：照片一多，"想找去年在海边拍的那张"就成了大海捞针——本地相册的搜索基本只能按时间翻，云相册的搜索好用，但代价就是隐私。三重焦虑指向同一个解法：一台自己的服务器加一个像样的相册软件。小鸡玩家手里恰好有机器（MinIO篇、Gitea篇一路下来，栈里就缺这一块），缺的只是那个"像样"的软件——Immich补的就是这块拼图。
二、Immich是什么：对着Google Photos抄作业的开源相册
Immich是2022年起步的开源项目，定位一句话：高性能的自托管照片视频管理方案。它的功能清单几乎是对着Google Photos逐项抄的：手机APP自动备份（iOS/Android官方双端，不是网页套壳）、网页端时间线浏览、AI人脸识别自动聚人、场景与物体智能搜索（搜"海边""猫""生日蛋糕"直接出结果）、照片元数据地图（拍照地点聚合）、外链分享相册、回收站与回收机制、只读账号与多用户。工程上它有几个值得称道的设计：底层用PostgreSQL存元数据、照片文件本体以年月目录平铺在磁盘上（不打包、不加密存储、随时可以直接拿走，这点比很多把数据锁进私有格式的方案厚道得多）；机器学习部分（识脸、打标、CLIP语义搜索）独立成一个容器，不喜欢可以整个裁掉，相册照常能用；缩略图和转码按需生成，浏览时滑动流畅度对齐商业产品。发展势头上，它是目前GitHub上这个赛道Star增速最猛的项目，社区活跃、月度发版，坑在被快速填平——选自托管软件最怕选到"停更弃子"，Immich没有这个风险。同类简单对比：PhotoPrism老牌但移动端弱、Nextcloud Photos功能单薄、LibrePhotos折腾度高，Immich是"功能、体验、活跃度"三项全能的那个，个人玩家闭眼选它不会错。
三、部署：Compose拉起一套微服务栈
Immich是一套多容器架构，官方给了docker-compose.yml，拉下来改几个环境变量就能起（Compose篇的老流程）。栈里的成员：`immich-server`主服务（API+网页）、`immich-machine-learning`机器学习容器（识脸/打标）、PostgreSQL数据库（加pgvecto.rs向量插件）、Redis缓存。关键配置三处：UPLOAD_LOCATION指定照片存放目录（务必指到数据盘——磁盘爆满篇的教训：20G系统盘装不下几个人的回忆，规划好路径再起容器）；数据库密码强随机；机器学习容器在低配机器上的取舍后面单独算账。启动后浏览器访问8080端口（默认），第一个注册的账号是管理员，管理后台里把"开放注册"关掉，然后给家里人逐个开账号——每人独立的时间线、独立的回收站，互不越界。升级姿势值得单独说：Immich迭代快，但它的数据库结构也常动，升级前务必先把UPLOAD_LOCATION和数据库目录打快照（备份篇的restic对停机状态的数据目录做全量最稳），然后`docker compose pull && docker compose up -d`——出了问题回滚快照，几分钟的事。数据库是Immich唯一"娇贵"的部分：照片文件怎么都还在，但元数据库坏了，人脸分组和时间线就全没了——所以它应该是你备份清单里优先级最高的目录之一。
四、手机端：自动备份的正确姿势
Immich的移动APP（官方出品，两大商店都能下）装好登录后，核心就一个开关：自动备份。打开后它会在充电+WiFi（可配置）时把相机胶卷增量备份上去，新拍的照片几分钟内就出现在网页端时间线。几个实战设置值得注意：其一，备份策略——建议选"仅新照片"模式而不是全量回传（已经手动整理过的老照片可以挑着传，一口气全传对家庭宽带上行和服务器磁盘都是冲击）；其二，视频开关——视频体积是照片的几十倍，小鸡磁盘紧张的话先关视频只传照片；其三，iOS的后台限制——和ntfy篇讲的iOS推送税同一个原理：iOS对APP后台活动管得严，自动备份经常要等你打开APP时才补跑，安卓没这个问题但要注意厂商ROM的电池优化白名单（Syncthing篇讲过的那套操作，一模一样）。家人的手机也装上、登录你开的账号，从此每个人的手机相册都成了"薄客户端"：随手拍、随便删，原件永远在小鸡上有一份——"手机丢了照片还在"这一件事，就值得全家每人装一个APP。
五、AI能力：识脸、语义搜索与时光回忆
Immich的AI三件套是它和"简陋自建相册"拉开差距的地方，也是机器学习容器的存在意义。人脸识别：上传的照片会被自动检测人脸、提取特征、聚类分组，你在网页上给每组脸命名一次（"妈妈""老婆""大宝"），之后所有照片自动按人索引——点某个人头像，跳出来的就是跨越数年的TA的所有照片，这个体验一旦用上就回不去了。语义搜索：基于CLIP模型给每张照片生成向量描述，搜索框直接输自然语言——"海边日落"、"生日蛋糕"、"火锅"——不依赖任何手动打标签，中文搜索效果相当好（Immich支持设置多语言模式）。时间线与地图：按时间轴滚动浏览，配合EXIF里的GPS坐标自动生成足迹地图（隐私敏感的话后台可以整体关闭地理位置功能）。AI任务的运行机制要注意：机器学习容器是异步队列处理，新照片入库后要排队跑识别，几百张照片在CPU上可能要跑十几分钟——后台能看到队列进度，不是卡了，是在算。识脸数据存在你自己的PostgreSQL里，CLIP模型跑在你自己的CPU上——"AI看过你的照片"这件事发生在你自己的机器上，这是Immich和云相册的本质区别，也是它和Ollama篇一脉相承的立场：算力和数据都该有自己的份。
六、资源账：内存是硬门槛，机器学习可裁剪
小鸡跑Immich的门槛比跑个Nginx高不少，账要提前算。内存：基础栈（不含机器学习）大约需要1.2-1.5G（PostgreSQL加Java式的服务开销），加上机器学习容器（Python+PyTorch）再要1-2G——2G内存的机器只能跑"裸相册"（关掉AI），4G是舒适线，8G全家桶无压力；跑不动就想办法：Swap篇的兜底方案能让2G机器勉强活，但缩略图批量生成时会卡。CPU：缩略图转码是CPU密集型，初次导入几千张照片的那几个小时风扇会转得欢——跑完就安静了，日常浏览几乎无感；机器学习推理同理，导入期忙、之后闲置。磁盘：这个才是大头——照片本体按你家的量级来（一家人一年几十G很正常），再加10-20%的缩略图与转码缓存；UPLOAD_LOCATION放数据盘、Docker目录也挪到数据盘（磁盘爆满篇的systemd override手法对Docker的data-root同样适用）。带宽：手机备份走的是家庭宽带上行——上行30Mbps的宽带，100G照片首次备份要传一整晚，之后增量就轻了；计量小鸡注意流入流量（流量计费篇的表要翻出来对一下，不过多数套餐只计流出或单向计量，看清规则）。结论：一台4G内存+大磁盘的年付小鸡，就是一台体面的家庭相册服务器——磁盘预算给足，其他都是小事。
七、分享与多用户：家人的照片各自管，想秀的照片发链接
家庭场景的相册绕不开"分享"两个字。账号体系：管理员给每位家庭成员开独立账号，各自的备份各自的时间线，互不可见——老婆的闺蜜聚会照不会混进你的时间线，孩子的照片两边都有（各自备份各自上传）。共享相册：建一个"全家2026"共享相册，所有人往里放，大家都能看——家庭旅行的照片汇总场景的标配。外链分享：选几张照片或一个相册生成外链，设置过期时间（一天/一周/永久）和密码，发给七大姑八大姨——对方点开就是网页浏览，不需要装APP不需要注册，链接过期自动失效。只读账号：给长辈开只读账号，他们只能看不能传——从此家庭群里再也没有"重复九连发"。安全上两件事不能省：其一，整套服务暴露公网必须走HTTPS（反代篇的Nginx加HTTPS篇的证书，第N次复用），照片比密码找回邮件更不该明文传输；其二，管理后台关掉开放注册，外链分享功能给家人交代清楚纪律——它分享的是原图，链接本身就是钥匙，设过期时间是好习惯。
八、接进备份体系：回忆值得3-2-1
相册建好后的最后一步，是把它接进已有的备份体系——照片这种"丢了就永远没了"的数据，一份都不嫌多。Immich的备份策略分两层：热备：直接把另一台机器（家里的NAS或旧电脑）用rsync定时同步UPLOAD_LOCATION目录（cron篇的定时任务），照片本体是平铺文件，rsync增量同步无痛；数据库目录停机快照或用pg_dump导出SQL——两样都有，才算"整套可恢复"。冷备：restic把UPLOAD_LOCATION和数据库导出加密快照，推到MinIO异地仓库（MinIO篇搭的那个S3正好用上）——3-2-1原则（备份篇）在照片场景的全套落地：小鸡上原件一份、家里NAS一份、异地加密一份。有人会问：Immich不是有冗余机制吗？有，但它防的是文件损坏，防不了"整台小鸡没了"——商家跑路、机房失火、账号被封，这些事在VPS圈年年有（heyunidc那篇跑路预警还挂着呢）。照片的特殊之处在于：它不像网站可以重建，不像代码可以重拉——它是唯一真正不可再生数据。所以哪怕你全网其他服务都不备份，相册这一份的3-2-1也值得做全套：算笔账，1T照片的异地restic仓库，年成本不过一台小鸡的零头，而它保的是全家十年的回忆。
结语
从MinIO的对象存储到Gitea的私有代码，本站的自托管清单一路在"把数据搬回家"——但真正让家人也受益的，是这篇的照片库：父母不用再学"怎么清理手机空间"，老婆的相册不再被"存储空间不足"的弹窗骚扰，孩子的每一张照片在两台机器三个地点有副本，AI识脸跑在你自己的CPU上。部署花一小时，全家受益十年——这笔账怎么算都是自托管里性价比最高的一单。今晚就把Compose文件拉起来，先传个几百张试试时间线和识脸的丝滑；等家里人的手机都装上APP、自动备份悄悄跑起来的那天，你会收到一句"这个真好用"——自托管玩家的勋章，从来不是跑了多少服务，而是家人那句轻描淡写的肯定。
