Rozwiązanie społecznościowe

Przywróć działanie uczenia maszynowego Immich po przejściu z NVIDIA na Intel Arc w systemie ZimaOS

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.

Zastąpienie karty NVIDIA RTX 2070 kartą Intel Arc może sprawić, że jedna aplikacja self-hostingowa nadal będzie działać, podczas gdy inna utraci akcelerację. Dokładnie to wydarzyło się w źródłowym wątku z czerwca–sierpnia 2026 roku. Po wymianie RTX 2070 na Intel Arc A310 sprzętowe transkodowanie w Jellyfin nadal działało, a intel-gpu-top działało na hoście ZimaOS, ale rozpoznawanie twarzy w Immich przestało działać, a widżet GPU na stronie głównej ZimaOS zniknął.

Opublikowany plik YAML Immich wyjaśniał, dlaczego aplikacje zachowywały się inaczej: usługa uczenia maszynowego nadal zawierała rezerwację GPU Docker w stylu NVIDIA. Ścieżka Intel Immich korzysta z OpenVINO i bezpośredniego dostępu do /dev/driAutor oryginalnego wpisu ostatecznie zmodyfikował plik YAML w nowszym interfejsie ZimaOS i potwierdził, że uczenie maszynowe znów zaczęło działać.

Działający Jellyfin nie dowodzi, że Immich ML ma dostęp do GPU

Jellyfin i uczenie maszynowe Immich działają w oddzielnych kontenerach. Każdy z nich otrzymuje własny obraz, urządzenia, zmienne środowiskowe i uprawnienia wykonawcze. Przekazanie karty Intel GPU do Jellyfin nie zapewnia dostępu do GPU usłudze ML Immich. /dev/dri automatycznie pojawiać się wewnątrz immich-machine-learning.

Była to najważniejsza korekta koncepcyjna w całym wątku. Wykrywanie GPU na poziomie hosta, transkodowanie Jellyfin, uczenie maszynowe Immich i widżet GPU w ZimaOS to cztery odrębne warstwy.

Usługa uczenia maszynowego nadal wyglądała jak stara konfiguracja NVIDIA

Źródłowy plik YAML zawierał rezerwację urządzenia Docker podobną do:

deploy:
  resources:
    reservations:
      sekcję dla usługi ML i zapewnienie przekazania urządzeń renderujących Intela, koncepcyjnie za pomocą:
        - capabilities:
            - gpu
          device_ids:
            - "0"

To ogólne przypisanie GPU zostało przeniesione z poprzedniej konfiguracji z RTX 2070. Nie pasowało do standardowej ścieżki Intel OpenVINO używanej przez Immich.

Najpierw sprawdź, czy karta Intel GPU istnieje na hoście ZimaOS

Autor oryginalnego wpisu ustalił już dwa cenne fakty:

  • intel-gpu-top działało z terminala ZimaOS;
  • Jellyfin mógł używać karty Arc A310 do sprzętowego transkodowania.

Wyniki te pokazują, że jądro hosta i co najmniej jedna ścieżka multimedialna w przestrzeni użytkownika mogły korzystać z GPU. Dzięki temu teza, że „karta Arc w ogóle nie jest wykrywana”, jest mało prawdopodobnym wyjaśnieniem problemu Immich.

Następnie sprawdź /dev/dri wewnątrz kontenera Immich ML

Osoba pomagająca na forum zasugerowała osobne sprawdzenie hosta i kontenera. Najbardziej przydatną informacją diagnostyczną jest to, czy kontener uczenia maszynowego może zobaczyć /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.

Jeśli host ma urządzenie renderujące Intela, ale kontener go nie ma, rozwiązania należy szukać w definicji kontenera, a nie w BIOS-ie płyty głównej ani konfiguracji PCIe.

Bieżące ML Immich dla Intela korzysta z OpenVINO

Bieżąca obsługa akcelerowanego sprzętowo uczenia maszynowego w Immich dla układów Intela korzysta z OpenVINO. Kontener uczenia maszynowego potrzebuje odpowiedniego obrazu OpenVINO lub jego wariantu, a także dostępu do urządzeń renderujących.

Przed edycją bieżącego stosu skorzystaj z aktualnych wymagań Immich dotyczących akcelerowanego sprzętowo uczenia maszynowego z Intel OpenVINO, ponieważ tagi obrazów i obsługiwane opcje akceleratorów mogą zmieniać się między wydaniami Immich.

Społeczność zasugerowała usunięcie rezerwacji NVIDIA i dodanie dostępu do urządzeń Intela deploy.resources.reservations.devices Osoba odpowiadająca zaproponowała usunięcie starej

sekcję dla usługi ML i zapewnienie przekazania urządzeń renderujących Intela, koncepcyjnie za pomocą:
  - /dev/dri:/dev/dri

W odpowiedzi zasugerowano również obraz uczenia maszynowego przeznaczony dla OpenVINO dla wersji podanej przez użytkownika.

Te dokładne tagi wersji odpowiadają okresowi źródłowemu. Użyj aktualnych tagów Immich zamiast zamrażać numer wersji z 2026 roku.

Użyj dzienników uczenia maszynowego, aby potwierdzić dostawcę akceleratora

Działające /dev/dri mount jest konieczny, ale niewystarczający. Po zmianie pliku YAML uruchom ponownie Immich i sprawdź dzienniki uczenia maszynowego pod kątem inicjalizacji akceleratora, ładowania modelu lub błędów dostawcy.

Jest to lepsze rozwiązanie niż ocenianie powodzenia na podstawie widżetu GPU w ZimaOS, ponieważ dziennik aplikacji informuje, czy konkretna usługa ML faktycznie korzysta z zamierzonego backendu.

Nowsza edycja YAML w ZimaOS ułatwiła rozwiązanie problemu

Gdy autor pierwotnego wpisu wrócił 24 sierpnia, wyraźnie zaznaczył, że najnowsza wersja ZimaOS umożliwiła bezpośrednią edycję YAML-a z poziomu strony głównej serwera. Wyeliminowało to wcześniejszą trudność ze znalezieniem bazowego pliku YAML aplikacji.

To ważna granica wersji: starsze porady dotyczące ręcznego wyszukiwania wygenerowanych plików Compose są mniej istotne, odkąd ZimaOS App Store 2.0 dodał natywną edycję YAML.

Autor pierwotnego posta potwierdził przywrócenie działania uczenia maszynowego

W końcowej odpowiedzi w źródłowej sprawie podano, że po usunięciu bloku rezerwacji starego GPU i dostosowaniu konfiguracji urządzeń uczenie maszynowe w Immich znów zaczęło działać.

To oznacza, że pierwotna sprawa została rozwiązana. Nie dowodzi to, że każdy model Intel Arc ani każda wersja Immich korzysta dokładnie z tego samego YAML, ale mocno potwierdza diagnozę: kontener ML był nadal skonfigurowany dla poprzedniego modelu GPU.

Zniknięcie widżetu GPU w ZimaOS było osobnym problemem

Widżet GPU na stronie głównej zniknął po przejściu na Arc A310, ale Jellyfin już korzystał z GPU. Oznacza to, że widżetu pulpitu nie można traktować jako wiarygodnego wskaźnika obsługi GPU.

Podczas rozwiązywania problemów z aplikacją w pierwszej kolejności sprawdź wykrywanie urządzenia przez hosta, widoczność urządzenia w kontenerze oraz dzienniki aplikacji, zamiast polegać na dekoracyjnym widżecie wykorzystania GPU.

Lepsza lista kontrolna migracji GPU

  1. Potwierdź obecność nowego GPU i sterownika na poziomie hosta ZimaOS.
  2. Zweryfikuj osobno każdą aplikację korzystającą z akceleracji.
  3. Usuń rezerwacje urządzeń właściwe dla starego dostawcy.
  4. Użyj backendu akceleratora wymaganego przez nowego dostawcę.
  5. Przekaż wymagane urządzenia renderujące do każdego właściwego kontenera.
  6. Uruchom ponownie tylko stos, którego dotyczy problem, i sprawdź dzienniki.
  7. Uruchom nowe zadanie uczenia maszynowego w Immich i potwierdź, że wyniki się pojawiają.

FAQ dotyczące Intel Arc w Immich

Dlaczego Jellyfin nadal działał, podczas gdy rozpoznawanie twarzy w Immich przestało działać?

Obie aplikacje działają w różnych kontenerach i wymagają osobnej konfiguracji GPU.

Z jakiego backendu obecny Immich korzysta do uczenia maszynowego na GPU Intela?

OpenVINO.

Czy pierwotny problem z Arc A310 został rozwiązany?

Tak. Użytkownik potwierdził, że edycja YAML przywróciła działanie uczenia maszynowego.

Czy widżet GPU w ZimaOS decyduje o tym, czy Immich może korzystać z GPU?

Nie. W źródłowej sprawie brakowało widżetu, ale akceleracja GPU w Jellyfin nadal działała.