Can Immich Share a GPU or Accelerator With Another Container?
Yes, Immich can share a GPU or accelerator with another container when the host runtime permits concurrent access and both workloads remain inside practical device limits.
Sharing the device does not guarantee isolation or equal performance. Immich may use acceleration for video transcoding or machine-learning inference while another service is encoding media, running AI inference, or using the same render node. Expose the device deliberately, test each workload alone, then run the real overlap and watch for memory, latency, thermal, or driver failures.
Prove Each Container Can Use the Accelerator Alone First
Before testing sharing, verify the host driver and container runtime with one workload at a time. For Immich, trigger the accelerated function you actually intend to use and confirm device utilization plus clean application logs. Repeat with the second container using its normal workload.
The NVIDIA container-runtime example of multiple GPU-enabled containers demonstrates that multiple containers can be launched with GPU access. That proves the runtime model, not that every pair of applications will share fairly or fit into one device.
If either application cannot use the accelerator reliably alone, do not diagnose concurrency yet. Fix driver version, device mapping, permissions, runtime configuration, codec support, or application backend first. A shared test cannot distinguish those baseline problems from actual contention.
Expose Only the Device Each Workload Needs
On systems with multiple accelerators, assign a specific device when possible instead of exposing every GPU to every container. On integrated Intel or AMD graphics, verify the intended render device and group permissions. On NVIDIA, confirm which visible device the process actually selects.
A recent NVIDIA forum answer on sharing one GPU between containers notes that ordinary container processes can access the same GPU when it is exposed to both. The important operational point is that container boundaries do not automatically create a fixed performance share.
Device visibility should be reproducible after container recreation. Restart each service and confirm the same device appears with the same permissions. If one application silently falls back to CPU after restart, fix the mapping before measuring shared performance.
Measure Contention in the Workloads That Actually Overlap
Run Immich by itself and record processing rate, interactive response time, GPU utilization, device memory, CPU fallback, and temperature. Run the other container alone with the same metrics. Then overlap the two representative jobs and compare the change rather than relying on peak theoretical throughput.
A newer NVIDIA discussion about GPU sharing behavior across containers asks whether two containers can select the same devices and contend. That is exactly the boundary to test: visibility is shared access, not automatic admission control or guaranteed capacity.
Accept sharing when both workloads stay accelerated, complete correctly, and remain within your latency and thermal targets. If one job exhausts VRAM, forces the other to CPU, creates encoder allocation failures, or causes user-visible stalls, reduce concurrency, schedule the heavy jobs apart, or assign separate devices.
Separate Transcoding Pressure From Machine-Learning Pressure
Immich can place different stress on an accelerator depending on whether it is encoding video or running machine-learning inference. The other container may also use encode engines, compute units, or shared memory differently. Total โGPU utilizationโ can hide which engine is actually saturated.
The ZimaSpace guide to shared GPU validation across containers provides a useful home-server test pattern: confirm driver and mapping first, then increase representative concurrent sessions while watching device memory, temperature, errors, and fallback behavior.
If video transcoding and ML rarely overlap, scheduling may be simpler than hardware partitioning. If both are latency-sensitive all day, a second accelerator or separate host can produce a clearer failure boundary. The correct architecture depends on the overlap window, not only on whether Docker allows both containers to open the device.
Validate Sharing Through Restart and a Worst Normal Peak
Build a repeatable peak such as one Immich video transcode plus a batch of Smart Search or face-related processing while the second container performs its busiest normal accelerated task. Record completion rates, tail latency, memory use, temperature, errors, and whether either service falls back to CPU.
Restart the containers in both orders and repeat the test. A robust configuration must not depend on which service claimed the accelerator first, unless that priority is an explicit design choice. Check that device nodes and runtime assignments remain stable after a host restart as well.
Keep sharing when the measured overlap stays inside service targets with thermal and memory headroom. Stop increasing concurrency at the first repeatable error or unacceptable latency. Escalate with GPU model, driver/runtime versions, device mappings, VRAM use, workload types, and the exact combination that causes contention.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
