Immich 硬件转码：用 GPU 给视频转码减负的设置方法
视频转码是 Immich 服务器上最重的负载——CPU 满转、风扇起飞，基本都发生在它身上。如果你的机器有 GPU（核显也算），硬件转码可以把这份工作交给专用电路。官方定位是「实验性、可能不适用所有系统」，但对支持的组合，效果立竿见影。
四种加速 API，对号入座
| API | 适用硬件 | 关键前提 |
|---|---|---|
| NVENC | NVIDIA 独显 | 官方驱动；Linux 上还需 NVIDIA Container Toolkit |
| Quick Sync（QSV） | Intel 核显（第 9 代起支持 VP9） | 部分老内核需按社区指引启用低功耗模式 |
| VAAPI | AMD / NVIDIA / Intel 通用接口 | WSL2 下要用 vaapi-wsl 变体 |
| RKMPP | Rockchip ARM 芯片（如 RK3588） | 仅 RK3588 支持硬件色调映射，需装 libmali |
明确的不支持：树莓派；WSL2 上的 QSV。编码格式方面 H.264/HEVC 一般都有，但 NVIDIA 和 AMD 的 GPU 不支持 VP9 编码。
启用五步（Docker Compose 路线）
- 从官方发布页下载
hwaccel.transcoding.yml，放到docker-compose.yml同目录； - 在 compose 文件的
immich-server服务下，取消extends段的注释，把file指向上面的文件、service改成你的后端（如qsv、nvenc、vaapi）； docker compose up -d重建容器；- 管理后台 Video Transcoding Settings（视频转码设置） 里，把硬件加速选项改成对应后端并保存；
- （可选，建议）同一设置页里打开硬件解码——默认只加速编码，解码仍在 CPU 上；打开后才是全链路加速。
走 Docker Compose Builder 生成的用户可以跳过 1–2 步；Unraid/Portainer 这类不支持多 compose 文件的平台，用官方文档提供的「内联写法」把设备映射直接写进主 compose 文件。
预期管理：三个如实提醒
- 文件更大、质量略低：同样参数下硬件转码产物比软件转码大、质量稍差——官方建议配更慢的预设（slower preset）缩小差距；
- 两遍编码（two-pass）只有 NVENC 支持，其他 API 会忽略这个设置；
- 切换是即时的：启用硬件加速后不需要重跑历史任务，之后的转码自动走新路径；想重算旧转码再手动触发对应任务。
验证它真的在干活
转码任务跑着时看 GPU 利用率：NVIDIA 用 nvtop，Intel 用 intel_gpu_top。GPU 有动静 + 转码日志无报错 = 生效。 Jasper Lake、Elkhart Lake 这类 U 处理器需要把恒定质量模式设为 CQP——官方文档有专句提示。
和机器学习加速是两回事
GPU 转码加速的是视频处理；人脸识别与语义搜索 的机器学习是另一个容器、另一套加速配置（官方另有 ML 硬件加速专页）。两者可以分别启用，低配机器先救视频转码这个大头。
视频负载搞定后，服务器的日常压力就平了。最后两页：API 密钥与命令行、从谷歌相册搬家。