Replacing an NVIDIA GPU with an Intel Arc card can leave one self-hosted application working while another loses acceleration. That is exactly what happened in this June–August 2026 source thread. After swapping an RTX 2070 for an Intel Arc A310, Jellyfin hardware transcoding continued to work and intel-gpu-top worked on the ZimaOS host, but Immich facial recognition stopped and the ZimaOS home-page GPU widget disappeared.
The posted Immich YAML revealed why the applications behaved differently: the machine-learning service still carried an NVIDIA-style Docker GPU reservation. Immich's Intel path uses OpenVINO and direct access to /dev/dri. The original poster eventually edited the YAML in the newer ZimaOS interface and confirmed that machine learning started working again.
Jellyfin Working Does Not Prove Immich ML Has GPU Access
Jellyfin and Immich machine learning are separate containers. Each receives its own image, devices, environment, and runtime permissions. Passing an Intel GPU to Jellyfin does not make /dev/dri automatically appear inside immich-machine-learning.
This was the most important conceptual correction in the thread. Host-level GPU detection, Jellyfin transcoding, Immich ML, and the ZimaOS GPU widget are four distinct layers.
The Machine-Learning Service Still Looked Like the Old NVIDIA Setup
The source YAML contained a Docker device reservation similar to:
deploy:
resources:
reservations:
devices:
- capabilities:
- gpu
device_ids:
- "0"That generic GPU reservation had been carried over from the previous RTX 2070 configuration. It did not match the normal Intel OpenVINO path used by Immich.
First Verify the Intel GPU Exists on the ZimaOS Host
The original poster had already established two valuable facts:
-
intel-gpu-topworked from the ZimaOS terminal; - Jellyfin could use the Arc A310 for hardware transcoding.
Those results show that the host kernel and at least one userspace media path could use the GPU. They make “the Arc card is not detected at all” a poor explanation for Immich's failure.
Then Verify /dev/dri Inside the Immich ML Container
The community responder suggested checking the host and container separately. The most useful diagnostic is whether the machine-learning container can see /dev/dri.
If the host has the Intel render device but the container does not, the fix belongs in the container definition rather than the motherboard BIOS or PCIe configuration.
Current Immich Intel ML Uses OpenVINO
Immich's current hardware-accelerated machine-learning support uses OpenVINO for Intel hardware. The machine-learning container needs the appropriate OpenVINO image or image variant plus access to the render devices.
Before editing a current stack, use Immich's current Intel OpenVINO machine-learning requirements, because image tags and supported accelerator options can change between Immich releases.
The Community Suggested Removing NVIDIA Reservation and Adding Intel Device Access
The responder proposed removing the old deploy.resources.reservations.devices section for the ML service and ensuring the Intel render devices were passed through, conceptually using:
devices:
- /dev/dri:/dev/driThe reply also suggested an OpenVINO-specific machine-learning image for the version the user had posted.
Those exact version tags belong to the source timeframe. Use current Immich tags rather than freezing the 2026 version number.
Use the Machine-Learning Logs to Confirm the Accelerator Provider
A working /dev/dri mount is necessary but not sufficient. After changing the YAML, restart Immich and inspect the machine-learning logs for accelerator initialization, model loading, or provider errors.
This is preferable to judging success from the ZimaOS GPU widget because the application log tells you whether the specific ML service is actually using the intended backend.
Newer ZimaOS YAML Editing Made the Fix Easier
When the original poster returned on August 24, they specifically noted that the latest ZimaOS version exposed YAML editing more directly from the server homepage. That removed the earlier difficulty of finding the underlying app YAML.
This is an important version boundary: older advice about locating generated Compose files manually is less relevant after ZimaOS App Store 2.0 added native YAML editing.
The Original Poster Confirmed Machine Learning Recovered
The final source reply says that after removing the old GPU reservation block and adjusting the device configuration, Immich machine learning started working again.
That makes this a solved source case. It does not prove that every Intel Arc model or every Immich version uses the same exact YAML, but it strongly validates the diagnosis: the ML container was still configured for the previous GPU model.
The Missing ZimaOS GPU Widget Was a Separate Issue
The home-page GPU widget disappeared after the switch to Arc A310, but Jellyfin was already using the GPU. That means the dashboard widget could not be treated as the authoritative indicator of GPU support.
For application troubleshooting, prioritize host device detection, container device visibility, and application logs over a decorative utilization widget.
A Better GPU Migration Checklist
- Confirm the new GPU and driver at the ZimaOS host level.
- Verify each accelerated application separately.
- Remove device reservations specific to the old vendor.
- Use the accelerator backend required by the new vendor.
- Pass the required render devices into each relevant container.
- Restart only the affected stack and inspect logs.
- Trigger new Immich machine-learning work and confirm results appear.
Immich Intel Arc FAQ
Why did Jellyfin keep working while Immich facial recognition stopped?
The two applications run in different containers and require separate GPU configuration.
Which backend does current Immich use for Intel GPU machine learning?
OpenVINO.
Was the original Arc A310 problem solved?
Yes. The user confirmed that editing the YAML restored machine learning.
Does the ZimaOS GPU widget determine whether Immich can use the GPU?
No. The source case had a missing widget while Jellyfin GPU acceleration still worked.
