Immichは別のコンテナとGPUやアクセラレーターを共有できますか？

はい、ホストのランタイムが同時アクセスを許可し、両方のワークロードが実用上のデバイス制限内に収まる場合、Immich は別のコンテナと GPU またはアクセラレーターを共有できます。

デバイスを共有しても、分離や均等なパフォーマンスが保証されるわけではありません。別のサービスがメディアのエンコード、AI 推論、または同じレンダーノードを使用している間、Immich は動画トランスコードや機械学習推論にアクセラレーションを使用することがあります。デバイスは意図的に公開し、各ワークロードを単独でテストしてから、実際に重複する処理を実行し、メモリ、レイテンシ、温度、ドライバーの障害を監視してください。

まず各コンテナが単独でアクセラレーターを使用できることを確認する

共有をテストする前に、ワークロードを一度に 1 つずつ実行し、ホストドライバーとコンテナランタイムを確認します。Immich では、実際に使用する予定のアクセラレーション機能を実行し、デバイスの使用状況とアプリケーションログに問題がないことを確認してください。次に、2 番目のコンテナでも通常のワークロードを使って同じ確認を行います。

NVIDIA コンテナランタイムの 複数の GPU 対応コンテナに関する例は、GPU アクセスを許可した複数のコンテナを起動できることを示しています。これはランタイムのモデルを証明するものであり、あらゆるアプリケーションの組み合わせが公平に共有できることや、1 台のデバイスに収まることを意味するものではありません。

いずれかのアプリケーションが単独でもアクセラレーターを安定して使用できない場合は、まだ同時実行の診断を始めないでください。実際の競合と基礎的な問題を区別できるよう、まずドライバーのバージョン、デバイスマッピング、権限、ランタイム設定、コーデックのサポート、またはアプリケーションのバックエンドを修正します。

各ワークロードに必要なデバイスだけを公開する

複数のアクセラレーターがあるシステムでは、可能な限りすべての GPU をすべてのコンテナに公開するのではなく、特定のデバイスを割り当てます。Intel または AMD の統合グラフィックスでは、意図したレンダーデバイスとグループ権限を確認してください。NVIDIA では、プロセスが実際に選択している表示デバイスを確認します。

NVIDIA フォーラムの 1 つの GPU をコンテナ間で共有する方法に関する最近の回答では、同じ GPU が両方に公開されていれば、通常のコンテナプロセスからアクセスできると説明されています。運用上重要なのは、コンテナの境界によってパフォーマンスの固定配分が自動的に作られるわけではないという点です。

デバイスの可視性は、コンテナを再作成した後も再現可能であるべきです。各サービスを再起動し、同じデバイスが同じ権限で表示されることを確認してください。再起動後に一方のアプリケーションが気付かないうちに CPU にフォールバックする場合は、共有パフォーマンスを測定する前にマッピングを修正します。

実際に重複するワークロードで競合を測定する

Immich を単独で実行し、処理速度、インタラクティブな応答時間、GPU 使用率、デバイスメモリ、CPU へのフォールバック、温度を記録します。もう一方のコンテナも同じ指標で単独実行します。その後、代表的な 2 つのジョブを重複させ、理論上の最大スループットではなく、変化を比較してください。

NVIDIA の コンテナ間の GPU 共有動作に関する新しい議論では、2 つのコンテナが同じデバイスを選択して競合できるかが問われています。まさにここがテストすべき境界です。可視性の共有は共有アクセスを意味しますが、自動的なアドミッション制御や容量の保証を意味するものではありません。

両方のワークロードがアクセラレーションを維持し、正常に完了し、レイテンシと温度の目標内に収まるなら、共有を許容できます。一方のジョブが VRAM を使い果たす、もう一方を CPU に移行させる、エンコーダーの割り当てエラーを発生させる、またはユーザーが認識できる遅延を引き起こす場合は、同時実行数を減らすか、高負荷のジョブを別の時間帯にスケジュールするか、別々のデバイスを割り当ててください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

トランスコードの負荷と機械学習の負荷を分けて考える

Immich がアクセラレーターにかける負荷は、動画をエンコードしているか、機械学習推論を実行しているかによって異なります。もう一方のコンテナも、エンコードエンジン、演算ユニット、共有メモリを異なる形で使用する可能性があります。「GPU 使用率」の合計値だけでは、どのエンジンが実際に飽和しているのか分からないことがあります。

ZimaSpace の コンテナ間で共有 GPU を検証する方法ガイドでは、ホームサーバー向けの有用なテスト手順が紹介されています。まずドライバーとマッピングを確認し、その後、デバイスメモリ、温度、エラー、フォールバックの挙動を監視しながら、代表的な同時セッション数を増やしていきます。

動画トランスコードと ML の処理がほとんど重ならない場合は、ハードウェアの分割よりもスケジューリングのほうが簡単かもしれません。両方が終日レイテンシに敏感な場合は、2 台目のアクセラレーターまたは別のホストによって、より明確な障害境界を構築できます。適切なアーキテクチャは、Docker が両方のコンテナによるデバイスのオープンを許可するかどうかだけでなく、重複する時間帯によって決まります。

再起動と通常時の最悪ピークを通じて共有を検証する

Immich の動画トランスコード 1 件と Smart Search または顔関連の処理のバッチを実行し、その間に 2 番目のコンテナが通常のアクセラレーション処理で最も忙しいタスクを実行する、といった再現可能なピーク負荷を作成します。完了率、テールレイテンシ、メモリ使用量、温度、エラー、いずれかのサービスが CPU にフォールバックするかどうかを記録してください。

両方の順序でコンテナを再起動し、テストを繰り返します。優先順位を明示的な設計上の選択としている場合を除き、堅牢な構成は、どちらのサービスが先にアクセラレーターを確保したかに依存してはいけません。ホストの再起動後もデバイスノードとランタイムの割り当てが安定していることも確認してください。

測定した重複処理が、温度とメモリに余裕を残したままサービスの目標内に収まるなら、共有を続けてください。再現性のあるエラーまたは許容できないレイテンシが初めて発生した時点で、同時実行数を増やすのを止めます。問題をエスカレーションする際は、GPU モデル、ドライバーとランタイムのバージョン、デバイスマッピング、VRAM 使用量、ワークロードの種類、競合を引き起こす正確な組み合わせを提示してください。