Community-Lösung

Immich-Maschinenlernen nach dem Wechsel von NVIDIA zu Intel Arc auf ZimaOS wiederherstellen

A June–August 2026 solved thread where Jellyfin used an Intel Arc A310 successfully but Immich facial recognition stopped because the machine-learning service still carried NVIDIA-style GPU reservations. The original poster confirmed machine learning worked again after editing the YAML.

Wenn man eine NVIDIA-GPU durch eine Intel-Arc-Karte ersetzt, kann eine selbst gehostete Anwendung weiterhin funktionieren, während eine andere ihre Beschleunigung verliert. Genau das geschah in diesem Quellthread von Juni bis August 2026. Nach dem Austausch einer RTX 2070 gegen eine Intel Arc A310 funktionierte die Hardware-Transkodierung in Jellyfin weiterhin und intel-gpu-top funktionierte auf dem ZimaOS-Host, aber die Gesichtserkennung von Immich wurde beendet und das GPU-Widget auf der ZimaOS-Startseite verschwand.

Die veröffentlichte Immich-YAML-Datei zeigte, warum sich die Anwendungen unterschiedlich verhielten: Der Machine-Learning-Dienst enthielt weiterhin eine Docker-GPU-Reservierung im NVIDIA-Stil. Immichs Intel-Pfad verwendet OpenVINO und direkten Zugriff auf /dev/dri. Der ursprüngliche Verfasser bearbeitete die YAML schließlich in der neueren ZimaOS-Oberfläche und bestätigte, dass das maschinelle Lernen wieder funktionierte.

Dass Jellyfin funktioniert, beweist nicht, dass Immich ML GPU-Zugriff hat

Jellyfin und das maschinelle Lernen von Immich laufen in getrennten Containern. Jeder erhält sein eigenes Image, seine eigenen Geräte, Umgebungsvariablen und Laufzeitberechtigungen. Die Übergabe einer Intel-GPU an Jellyfin verleiht dem Immich-ML-Container nicht automatisch GPU-Zugriff. /dev/dri automatisch innerhalb von immich-machine-learning.

Dies war die wichtigste konzeptionelle Korrektur im Thread. GPU-Erkennung auf Host-Ebene, Jellyfin-Transkodierung, Immich ML und das ZimaOS-GPU-Widget sind vier unterschiedliche Ebenen.

Der Machine-Learning-Dienst sah weiterhin wie die alte NVIDIA-Konfiguration aus

Die YAML-Quelldatei enthielt eine Docker-Gerätereservierung ähnlich wie:

deploy:
  resources:
    reservations:
      devices:
        - capabilities:
            - gpu
          device_ids:
            - "0"

Diese allgemeine GPU-Reservierung war aus der vorherigen RTX-2070-Konfiguration übernommen worden. Sie entsprach nicht dem üblichen Intel-OpenVINO-Pfad, den Immich verwendet.

Zuerst prüfen, ob die Intel-GPU auf dem ZimaOS-Host vorhanden ist

Der ursprüngliche Verfasser hatte bereits zwei wichtige Fakten festgestellt:

  • intel-gpu-top funktionierte über das ZimaOS-Terminal;
  • Jellyfin konnte die Arc A310 für Hardware-Transkodierung verwenden.

Diese Ergebnisse zeigen, dass der Host-Kernel und mindestens ein Medienpfad im User-Space die GPU verwenden konnten. Sie machen „Die Arc-Karte wird überhaupt nicht erkannt“ zu einer wenig überzeugenden Erklärung für den Fehler von Immich.

Dann /dev/dri im Immich-ML-Container überprüfen

Der Community-Responder empfahl, den Host und den Container getrennt zu überprüfen. Die nützlichste Diagnose ist, ob der Machine-Learning-Container darauf zugreifen kann /dev/dri.

Wenn der Host über das Intel-Render-Gerät verfügt, der Container jedoch nicht, muss die Behebung in der Containerdefinition und nicht im BIOS des Mainboards oder in der PCIe-Konfiguration erfolgen.

Das aktuelle Intel-ML von Immich verwendet OpenVINO

Die aktuelle hardwarebeschleunigte Machine-Learning-Unterstützung von Immich verwendet OpenVINO für Intel-Hardware. Der Machine-Learning-Container benötigt das passende OpenVINO-Image oder eine entsprechende Image-Variante sowie Zugriff auf die Render-Geräte.

Bevor du einen aktuellen Stack bearbeitest, lies die aktuellen Anforderungen von Immich für hardwarebeschleunigtes Machine Learning mit Intel OpenVINO, da sich Image-Tags und unterstützte Beschleunigeroptionen zwischen Immich-Versionen ändern können.

Die Community schlug vor, die NVIDIA-Reservierung zu entfernen und den Zugriff auf Intel-Geräte hinzuzufügen

Der Antwortende schlug vor, das alte deploy.resources.reservations.devices Abschnitt für den ML-Dienst und sicherzustellen, dass die Intel-Render-Geräte durchgereicht wurden, sinngemäß mit:

devices:
  - /dev/dri:/dev/dri

In der Antwort wurde außerdem ein Machine-Learning-Image speziell für OpenVINO für die vom Benutzer angegebene Version vorgeschlagen.

Diese exakten Versions-Tags gehören zum damaligen Zeitraum. Verwende aktuelle Immich-Tags, statt die Versionsnummer von 2026 festzuschreiben.

Verwende die Machine-Learning-Protokolle, um den Accelerator-Provider zu bestätigen

Eine funktionierende /dev/dri mount ist notwendig, aber nicht ausreichend. Starte Immich nach der Änderung der YAML-Datei neu und prüfe die Machine-Learning-Protokolle auf die Initialisierung des Beschleunigers, das Laden des Modells oder Provider-Fehler.

Das ist zuverlässiger, als den Erfolg anhand des GPU-Widgets von ZimaOS zu beurteilen, da das Anwendungsprotokoll zeigt, ob der jeweilige ML-Dienst tatsächlich das vorgesehene Backend verwendet.

Die neuere YAML-Bearbeitung in ZimaOS erleichterte die Behebung

Als der ursprüngliche Verfasser am 24. August zurückkehrte, wies er ausdrücklich darauf hin, dass die neueste ZimaOS-Version die YAML-Bearbeitung direkter von der Server-Startseite aus ermöglichte. Dadurch entfiel die frühere Schwierigkeit, die zugrunde liegende App-YAML-Datei zu finden.

Dies ist eine wichtige Versionsgrenze: Ältere Hinweise zum manuellen Auffinden generierter Compose-Dateien sind weniger relevant, seit der ZimaOS App Store 2.0 die native YAML-Bearbeitung eingeführt hat.

Der ursprüngliche Verfasser bestätigte, dass sich die Funktionen für maschinelles Lernen wiederhergestellt hatten.

Die abschließende Antwort im Ausgangsfall besagt, dass das maschinelle Lernen in Immich nach dem Entfernen des alten GPU-Reservierungsblocks und der Anpassung der Gerätekonfiguration wieder funktionierte.

Damit handelt es sich um einen gelösten Ausgangsfall. Das beweist nicht, dass jedes Intel-Arc-Modell oder jede Immich-Version exakt dieselbe YAML-Konfiguration verwendet, bestätigt aber die Diagnose deutlich: Der ML-Container war noch für das vorherige GPU-Modell konfiguriert.

Das fehlende ZimaOS-GPU-Widget war ein separates Problem.

Das GPU-Widget auf der Startseite verschwand nach dem Wechsel zur Arc A310, aber Jellyfin verwendete die GPU bereits. Daher konnte das Dashboard-Widget nicht als maßgeblicher Indikator für die GPU-Unterstützung betrachtet werden.

Bei der Fehlerbehebung von Anwendungen sollten die Erkennung des Geräts durch den Host, die Sichtbarkeit des Geräts im Container und die Anwendungsprotokolle gegenüber einem dekorativen Auslastungs-Widget Vorrang haben.

Eine bessere Checkliste für die GPU-Migration

  1. Die neue GPU und den Treiber auf Host-Ebene in ZimaOS bestätigen.
  2. Jede beschleunigte Anwendung separat überprüfen.
  3. Gerätereservierungen entfernen, die für den alten Anbieter spezifisch sind.
  4. Das vom neuen Anbieter benötigte Beschleunigungs-Backend verwenden.
  5. Die erforderlichen Render-Geräte in jeden relevanten Container durchreichen.
  6. Nur den betroffenen Stack neu starten und die Protokolle prüfen.
  7. Neue Aufgaben für das maschinelle Lernen in Immich auslösen und bestätigen, dass Ergebnisse angezeigt werden.

Häufig gestellte Fragen zu Intel Arc in Immich

Warum funktionierte Jellyfin weiterhin, während die Gesichtserkennung in Immich ausfiel?

Die beiden Anwendungen laufen in unterschiedlichen Containern und erfordern eine separate GPU-Konfiguration.

Welches Backend verwendet die aktuelle Immich-Version für maschinelles Lernen mit Intel-GPUs?

OpenVINO.

Wurde das ursprüngliche Problem mit der Arc A310 gelöst?

Ja. Der Benutzer bestätigte, dass die Bearbeitung der YAML-Datei die Funktionen für maschinelles Lernen wiederhergestellt hat.

Bestimmt das GPU-Widget von ZimaOS, ob Immich die GPU verwenden kann?

Nein. Im Ausgangsfall fehlte das Widget, während die GPU-Beschleunigung in Jellyfin weiterhin funktionierte.