複数のメディアコンテナで、デバイスの競合なしに1つのGPUを共有できますか？
はい、ホストドライバーとランタイムが同時アクセスをサポートし、各コンテナにデバイスが正しく割り当てられていれば、複数のメディアコンテナで1つのGPUを共有できます。
コンテナは通常、完全にパススルーされた仮想マシンのようにGPUを排他的に占有することはありません。Intel Quick SyncやAMD VA-APIは共有レンダーデバイスを公開するのが一般的です。一方、NVIDIAコンテナでは、ハードウェア、ドライバー、コーデック、メモリ、セッションの制限内で、1つのドライバースタックとGPUを共有できます。オーケストレーションがデバイスを排他的に割り当てる場合、権限が異なる場合、コンテナに互換性のないライブラリが含まれている場合、または同時トランスコードがGPUの実用上の処理能力を超えた場合に、競合が発生します。
ホストがGPUの同時ワークロードをサポートしていることを確認する
まずホストドライバーをインストールして確認し、その後、既知の正常なコンテナの外部または内部で、ハードウェアアクセラレーションによるトランスコードを実行します。GPUモデル、ドライバー、対応するエンコードおよびデコードコーデック、メモリ、観測された使用率を記録してください。
TrueNASコミュニティのディスカッションでは、GPUが専用のアプリケーションリソースとして割り当てられるのではなく、使用可能な状態で公開されている場合に、複数のアプリが同じGPUを共有できると報告されています。重要なのは、共有デバイスアクセスと排他的なパススルーの違いです。
1つのコンテナがGPUを安定して使用できない場合は、別のコンテナを追加しないでください。同時実行をテストする前に、ホストドライバー、カーネルデバイス、ファームウェア、またはランタイムを修正してください。
すべてのコンテナに正しいデバイスを公開する
IntelおよびAMDでは、各コンテナに渡される/dev/driのカードノードとレンダーノードを比較します。NVIDIAでは、ランタイムまたはデバイスリクエスト、表示デバイス変数、ドライバー機能を比較します。
NixOSのJellyfin事例では、オペレーティングシステムとデバイス環境が変わったことで、同じホストGPUの動作がコンテナごとに異なったと説明されています。これは、Composeの1行をコピーするよりも、デバイス公開設定とライブラリを一致させることが重要である理由を示しています。
各アプリに必要な最小限のデバイスセットを使用し、近道として特権モードを使わないでください。再ビルド後に、期待されるレンダーノードまたはNVIDIAデバイスがすべてのコンテナ内に表示されることを確認します。
コンテナ間で権限とユーザーグループを一致させる
ホスト上のレンダーデバイスの数値所有者とグループを記録し、各コンテナプロセスが対応する補助グループまたは権限を持っていることを確認します。イメージ固有のユーザー名は、異なる数値IDにマッピングされる場合があります。
GPUは一覧に表示されるのに開けないコンテナは、ソフトウェアトランスコードにフォールバックしたり、権限拒否を報告したりすることがあります。この失敗は、別のメディアコンテナが動作し続けるため、デバイス競合のように見える場合があります。
同じファイルとコーデックを使い、各コンテナを単独でテストします。イメージのアップグレードや再作成で削除されないよう、Composeで権限設定を明示してください。
コーデック、ドライバー、ランタイムの互換性を確認する
H.264、HEVC、AV1、トーンマッピング、字幕、スケーリング、OpenCLまたはCUDAフィルターなど、各アプリがGPUに実行させるコーデックとフィルターを比較します。あるワークロードが必要とする機能を、別のワークロードはまったく使用しない場合があります。
Jellyfin向けの最新GPUパススルーガイドでは、すべてのハードウェアアクセラレーション経路を同じものとして扱うのではなく、コンテナ設定をIntel QSV、NVIDIA NVENC、またはAMD VA-APIに合わせることを重視しています。ランタイムはGPUファミリーに適合している必要があります。
ホストドライバーとコンテナランタイムのライブラリに互換性を持たせ、個々のメディアコンテナ内に競合するドライバーを同梱しないでください。デコード、エンコード、トーンマッピングをそれぞれ個別にテストします。
同時セッション数、メモリ、温度の制限を測定する
各コンテナでハードウェアトランスコードを1つずつ開始し、GPUプロセス、使用率、エンコーダーとデコーダーの負荷、メモリ、温度、エラー、ストリームの安定性を監視します。実際に使用するメディアを使い、同時実行数を徐々に増やしてください。
Proxmoxコミュニティの構成例では、複数のJellyfinインスタンスで同時にトランスコードを実行し、ホストから動作を確認しています。また、同時セッションには実用上の制限があることも示されています。これらの制限はハードウェアとソフトウェアによって決まります。
共有GPUが正常に動作しているのは、両方のアプリがハードウェアアクセラレーションを維持し、応答性を保っている場合です。再生の途切れ、エンコーダーの作成失敗、メモリ不足エラー、温度によるリセット、一方のアプリが他方をソフトウェア処理へ移行させる現象は、ワークロードが現在の余力を超えていることを示します。
GPUを共有しながら設定とトランスコードのパスは分離する
各メディアコンテナに、独自の設定データベース、キャッシュ、トランスコードディレクトリ、ポート、ユーザーIDを割り当てます。アプリケーションが共通の状態ディレクトリを明示的にサポートしていない限り、共有するのは読み取り専用のメディアライブラリとGPUデバイスだけにしてください。
ZimaSpaceのコンテナ依存関係の分離ガイドは、GPU競合と、データベース、キャッシュ、ネットワーク、マウントの障害を区別するのに役立ちます。
両方のコンテナが再ビルド後も動作し続け、ハードウェアアクセラレーションを同時に使用し、それぞれの権限と状態を守り、セッション数、メモリ、温度の制限内に収まって初めて、この設計は検証済みといえます。同時ワークロードで必要な品質を安定して満たせない場合は、別のGPUまたはソフトウェアフォールバックを使用してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
