NVIDIA GPUをIntel Arcカードに交換すると、あるセルフホストアプリケーションは動作し続ける一方で、別のアプリケーションではアクセラレーションが失われることがあります。2026年6月から8月にかけてのこのソーススレッドで起きたのは、まさにそれでした。RTX 2070をIntel Arc A310に交換した後も、Jellyfinのハードウェアトランスコーディングは引き続き動作し、 intel-gpu-top ZimaOSホスト上では動作していましたが、Immichの顔認識は停止し、ZimaOSホームページのGPUウィジェットも表示されなくなりました。
投稿されたImmich YAMLから、アプリケーションの動作が異なっていた理由が明らかになりました。機械学習サービスには、NVIDIA向けのDocker GPU予約設定がまだ残っていました。ImmichのIntelパスはOpenVINOを使用し、直接アクセスします /dev/dri。元の投稿者は最終的に、新しいZimaOSインターフェースでYAMLを編集し、機械学習が再び動作し始めたことを確認しました。
Jellyfinが動作しているからといって、Immich MLがGPUにアクセスできるとは限りません
JellyfinとImmichの機械学習は別々のコンテナです。それぞれが独自のイメージ、デバイス、環境、ランタイム権限を受け取ります。JellyfinにIntel GPUを渡しても、 /dev/dri 内部に自動的に表示される immich-machine-learning.
これは、このスレッドで最も重要な概念上の修正でした。ホストレベルのGPU検出、Jellyfinのトランスコーディング、Immich ML、ZimaOSのGPUウィジェットは、それぞれ別の層です。
機械学習サービスは、依然として古いNVIDIA構成のように見えました
元のYAMLには、次のようなDockerデバイス予約が含まれていました。
deploy:
resources:
reservations:
devices:
- capabilities:
- gpu
device_ids:
- "0"その汎用GPU予約設定は、以前のRTX 2070構成から引き継がれたものでした。Immichが使用する通常のIntel OpenVINOパスには適合していませんでした。
まず、ZimaOSホストにIntel GPUが存在することを確認します
元の投稿者は、すでに2つの重要な事実を確認していました。
-
intel-gpu-topZimaOSのターミナルから動作しました。 - Jellyfinでは、ハードウェアトランスコーディングにArc A310を使用できました。
これらの結果から、ホストカーネルと少なくとも1つのユーザー空間メディアパスではGPUを利用できることが分かります。そのため、「Arcカードがまったく検出されていない」という説明では、Immichの失敗をうまく説明できません。
次に、Immich MLコンテナ内で /dev/dri を確認します
コミュニティの回答者は、ホストとコンテナを分けて確認するよう提案しました。最も有用な診断は、機械学習コンテナから見えるかどうかです /dev/dri.
ホストにIntelのレンダーデバイスがあっても、コンテナにない場合、修正すべき場所はマザーボードのBIOSやPCIe構成ではなく、コンテナ定義です。
現在のImmichのIntel MLはOpenVINOを使用
現在のImmichにおけるIntel向けハードウェアアクセラレーション対応機械学習では、OpenVINOを使用します。機械学習コンテナには、適切なOpenVINOイメージまたはイメージバリアントに加えて、レンダーデバイスへのアクセスが必要です。
現在のスタックを編集する前に、イメージタグや対応アクセラレーターの選択肢はImmichのリリースによって変わる可能性があるため、Immichの現在のIntel OpenVINO機械学習要件を確認してください。
コミュニティはNVIDIAの予約を削除し、Intelデバイスへのアクセスを追加することを提案
回答者は、古いものを削除することを提案しました deploy.resources.reservations.devices MLサービスのセクションに記述し、Intelのレンダーデバイスがパススルーされるようにすることです。概念的には次のようになります。
devices:
- /dev/dri:/dev/dri返信では、ユーザーが投稿したバージョン向けに、OpenVINO専用の機械学習イメージを使うことも提案されていました。
これらの正確なバージョンタグは、当時の情報に基づくものです。2026年のバージョン番号を固定するのではなく、現在のImmichタグを使用してください。
アクセラレータープロバイダーを確認するには機械学習ログを使用
動作する /dev/dri mountは必要ですが、それだけでは不十分です。YAMLを変更した後、Immichを再起動し、アクセラレーターの初期化、モデルの読み込み、またはプロバイダーのエラーがないか、機械学習ログを確認してください。
ZimaOSのGPUウィジェットで成功を判断するよりも、この方法が望ましいです。アプリケーションログを確認すれば、特定のMLサービスが実際に意図したバックエンドを使用しているかどうかが分かるためです。
新しいZimaOSのYAML編集で修正が容易に
元の投稿者は8月24日に戻ってきた際、最新版のZimaOSではサーバーのホームページからYAMLをより直接的に編集できるようになったと明確に述べました。これにより、以前は基盤となるアプリのYAMLを見つけるのが難しかった問題が解消されました。
これは重要なバージョンの境目です。生成されたComposeファイルを手動で探すという以前のアドバイスは、ZimaOS App Store 2.0でネイティブのYAML編集機能が追加された後では、あまり relevant ではありません。
投稿者本人が機械学習の復旧を確認しました
元の回答の最終部分では、古いGPU予約ブロックを削除してデバイス構成を調整した後、Immichの機械学習が再び動作し始めたと述べています。
これにより、元の事例は解決済みとなります。ただし、すべてのIntel ArcモデルやすべてのImmichバージョンでまったく同じYAMLが使用されることを証明するものではありません。それでも、MLコンテナが以前のGPUモデル用に構成されたままだったという診断を強く裏付けています。
表示されなくなったZimaOS GPUウィジェットは別の問題でした
Arc A310への切り替え後、ホームページのGPUウィジェットが消えましたが、その時点ですでにJellyfinはGPUを使用していました。つまり、ダッシュボードのウィジェットをGPUサポートの決定的な指標とみなすことはできませんでした。
アプリケーションのトラブルシューティングでは、装飾的な使用率ウィジェットよりも、ホストによるデバイス検出、コンテナからのデバイス認識、アプリケーションログを優先してください。
より良いGPU移行チェックリスト
- ZimaOSホストレベルで、新しいGPUとドライバーを確認します。
- アクセラレーションを使用する各アプリケーションを個別に確認します。
- 以前のベンダー固有のデバイス予約を削除します。
- 新しいベンダーが必要とするアクセラレーターバックエンドを使用します。
- 必要なレンダーデバイスを、該当する各コンテナに渡します。
- 影響を受けたスタックだけを再起動し、ログを確認します。
- Immichの新しい機械学習処理を実行し、結果が表示されることを確認します。
Immich Intel Arcに関するFAQ
Jellyfinは動作し続けたのに、Immichの顔認識が停止したのはなぜですか？
2つのアプリケーションは異なるコンテナで実行されるため、それぞれ個別にGPUを構成する必要があります。
現在のImmichは、Intel GPUによる機械学習にどのバックエンドを使用しますか？
OpenVINO。
元のArc A310の問題は解決しましたか？
はい。ユーザーは、YAMLを編集したことで機械学習が復旧したと確認しました。
ZimaOSのGPUウィジェットは、ImmichがGPUを使用できるかどうかを判定しますか？
いいえ。元の事例では、JellyfinのGPUアクセラレーションが引き続き機能している一方で、ウィジェットが表示されなくなっていました。
