Do not buy a GPU for Immich until you know which job is slow.
Immich can use hardware acceleration for two different workloads: video transcoding and machine learning. Those jobs have different hardware paths, different failure modes and different storage side effects. The practical decision is not “GPU or no GPU”; it is whether your library needs accelerated playback compatibility, faster smart-search and face jobs, or just enough CPU and patience.
Separate the two acceleration decisions
| Decision | Immich workload | Supported paths | What to verify |
|---|---|---|---|
| Hardware transcoding | FFmpeg video transcodes for compatibility and playback performance. | NVENC, Quick Sync, RKMPP and VAAPI. | Immich server container sees the device, the admin transcoding setting matches the compose backend, and a new transcoding job uses the accelerator. |
| Hardware-accelerated machine learning | Smart Search, face detection and facial recognition work in the machine-learning service. | ARM NN, CUDA, ROCm, OpenVINO and RKNN. | The machine-learning container logs show the expected provider or model load without errors. |
| Remote machine learning | Moves ML work to a second host while the main Immich server stays smaller. | Remote ML URL plus matching Immich version; optional hardware acceleration on that remote host. | The local service can fall back or intentionally not fall back, depending on how you configure the URLs. |
When CPU-only is still a good plan
- Mostly photos: hardware transcoding helps video work, not normal photo browsing.
- Small family library: the official baseline remains CPU/RAM first; a GPU is not listed as a general requirement.
- Occasional video: scheduled background transcodes may be fine if you do not need fast completion.
- Low-power host: buying a more complex GPU path can add driver, passthrough and update risk that outweighs the benefit.
- Strict storage budget: Immich warns that hardware transcoding can create larger videos than software transcoding at similar settings.
When hardware transcoding is worth testing
| Signal | What it means | Planning response |
|---|---|---|
| CPU spikes during video playback or transcode jobs | The server is doing software video work. | Test one supported backend before buying a new host. |
| Large mobile-video archive | Playback compatibility and encoded-video generation may matter more than photo thumbnails. | Estimate generated-media storage and keep encoded video on fast enough storage. |
| Many users watching videos | Concurrent playback can compete with upload, metadata and thumbnail jobs. | Use Jobs and Workers settings to avoid starving other work. |
| Existing Intel iGPU or supported GPU | You may already own enough acceleration for a proof of concept. | Prefer testing existing hardware before adding a discrete GPU. |
Backend cautions before buying hardware
- Docker Compose scope: Immich's acceleration instructions are written for Docker Compose; other container engines may need different wiring.
- OS support: Immich documents Linux and Windows through WSL2 for hardware transcoding and ML acceleration, with specific limitations such as no Quick Sync support in WSL2.
- Codec limits: H.264 and HEVC are commonly supported, but codec support varies by device; Immich notes that NVIDIA and AMD GPUs do not support VP9 encoding.
- NVIDIA setup: NVENC requires the official NVIDIA driver, and Linux hosts generally need NVIDIA Container Toolkit.
- Intel setup: Quick Sync details vary by CPU generation; VP9 has additional generation and kernel caveats in the Immich docs.
- ML setup: CUDA machine learning requires NVIDIA compute capability 5.2 or higher and a driver new enough for CUDA 12.3; ROCm and ARM paths have their own compatibility limits.
Storage and quality implications
Hardware acceleration is not only a speed decision. Immich says hardware transcoding can produce significantly larger videos than software transcoding with similar settings and typically lower quality, although slower presets and efficient codecs can narrow the gap. The original asset is still kept, and the transcoded version exists alongside it for compatibility and performance. That means encoded-video policy affects storage, backup scope and restore time.
Verification checklist
- Start with a current backup. Changing transcoding policy can overwrite or delete existing transcodes when jobs are rerun, even though originals remain untouched.
- Update compose with the current Immich hardware-acceleration file. Keep it beside the release-matched
docker-compose.yml. - Expose only the needed device. Avoid broad passthrough until the narrow backend works.
- Set the matching admin option. The compose backend and Immich Video Transcoding Settings must agree.
- Run one new job. Existing transcodes do not need to be redone just because acceleration was enabled; new jobs should use the device.
- Check logs and utilization. Confirm the server or ML container is using the expected provider instead of assuming acceleration is active.
- Record storage delta. Compare originals, thumbnails and encoded video before and after the sample.
Commercial decision rule
If you are buying new hardware, prefer a system that meets Immich's CPU, RAM, storage and backup needs first. Treat an integrated GPU as a useful option for video-heavy libraries, not as permission to undersize storage or skip restore testing. A discrete GPU only makes sense when you have measured a real video or ML bottleneck, verified supported drivers for your host OS, and accepted the power and operational cost.
Pair this with the large-library performance guide for job queues and storage placement →
在确认哪个任务变慢之前，不要先为 Immich 购买 GPU。
Immich 可以把硬件加速用于两类不同工作：视频转码和机器学习。它们的硬件路径、故障模式和存储影响都不同。真正的问题不是“要不要 GPU”，而是你的图库是否需要更快的视频兼容转码、更快的智能搜索/人脸任务，还是只需要足够的 CPU 和等待时间。
把两个加速决策分开
| 决策 | Immich 工作负载 | 受支持路径 | 需要验证什么 |
|---|---|---|---|
| 硬件转码 | 用于兼容性和播放性能的 FFmpeg 视频转码。 | NVENC、Quick Sync、RKMPP、VAAPI。 | server 容器能看到设备，后台转码设置与 compose 后端一致，新转码任务确实使用加速器。 |
| 机器学习硬件加速 | Smart Search、人脸检测和人脸识别。 | ARM NN、CUDA、ROCm、OpenVINO、RKNN。 | machine-learning 容器日志显示预期 provider 或模型加载成功且无错误。 |
| 远程机器学习 | 把 ML 工作移到第二台主机，主 Immich 服务器保持更小。 | 远程 ML URL 与匹配的 Immich 版本；远程主机也可选择硬件加速。 | 根据 URL 配置确认本地服务会回退，或按你的选择不回退。 |
什么时候 CPU-only 仍然合理
- 主要是照片：硬件转码帮助的是视频任务，不是普通照片浏览。
- 小型家庭图库：官方基线仍然先看 CPU/RAM；GPU 不是通用硬性要求。
- 偶尔有视频：如果不要求快速完成，后台排队转码可能已经足够。
- 低功耗主机：复杂 GPU 路径会增加驱动、直通和升级风险，收益未必值得。
- 严格控制存储：Immich 提醒，硬件转码在相似设置下可能生成比软件转码更大的视频。
什么时候值得测试硬件转码
| 信号 | 含义 | 规划动作 |
|---|---|---|
| 视频播放或转码任务让 CPU 飙高 | 服务器正在做软件视频处理。 | 先测试一个受支持后端，再决定是否买新主机。 |
| 大量手机视频存档 | 播放兼容性和 encoded-video 生成可能比照片缩略图更重要。 | 估算生成媒体空间，并把 encoded video 放在足够快的存储上。 |
| 多人观看视频 | 并发播放可能与上传、元数据、缩略图任务竞争资源。 | 用 Jobs and Workers 设置避免其它任务被饿死。 |
| 已有 Intel iGPU 或受支持 GPU | 你可能已经拥有足够做验证的加速能力。 | 优先测试现有硬件，不要先加独显。 |
购买硬件前的后端注意事项
- Docker Compose 范围：Immich 的加速说明面向 Docker Compose；其它容器引擎可能需要不同配置。
- 系统支持：Immich 文档说明硬件转码和 ML 加速支持 Linux 与通过 WSL2 的 Windows，同时有 WSL2 不支持 Quick Sync 等限制。
- 编码格式限制：H.264 和 HEVC 通常支持，但具体取决于设备；Immich 说明 NVIDIA 和 AMD GPU 不支持 VP9 编码。
- NVIDIA 设置：NVENC 需要官方 NVIDIA 驱动，Linux 主机通常还需要 NVIDIA Container Toolkit。
- Intel 设置：Quick Sync 细节会随 CPU 代际变化；VP9 还有额外的代际和内核注意事项。
- ML 设置：CUDA 机器学习需要 NVIDIA compute capability 5.2 或更高，并且驱动需要支持 CUDA 12.3；ROCm 和 ARM 路径也有各自兼容性限制。
存储与画质影响
硬件加速不只是速度决策。Immich 表示，硬件转码在相似设置下可能生成明显更大的视频，画质通常也低于软件转码；较慢预设和更高效编码可以缩小差距。原始资产仍会保留，转码版本会作为兼容性和性能文件并存。因此 encoded-video 策略会影响存储、备份范围和恢复时间。
验证清单
- 从当前备份开始。更改转码策略后重新运行任务，可能覆盖或删除现有转码文件；原始文件仍会保留。
- 使用当前 Immich 硬件加速文件更新 compose。让它与同版本的
docker-compose.yml放在一起。 - 只暴露需要的设备。先让最小后端跑通，再考虑更宽的设备直通。
- 设置匹配的后台选项。compose 后端必须与 Immich Video Transcoding Settings 一致。
- 运行一个新任务。启用加速后不需要重做已有转码；之后新任务应使用加速设备。
- 检查日志和利用率。确认 server 或 ML 容器使用了预期 provider，不要只凭感觉判断。
- 记录存储变化。在样本前后比较 originals、thumbnails 和 encoded video。
商业决策规则
如果要购买新硬件，先确保系统满足 Immich 的 CPU、内存、存储和备份需要。集成 GPU 可以作为视频较多图库的有用选项，但不能用来掩盖存储不足或跳过恢复演练。只有当你测到真实的视频或 ML 瓶颈、确认主机系统驱动受支持，并接受功耗和运维成本后，独立 GPU 才有意义。