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

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Can Home Assistant Share a GPU or Accelerator With Another Container? - Zima Store Online

はい、Home Assistant関連のワークロードであれば、別のコンテナとGPUを共有できる場合があります。ただし、答えはアクセラレーターの経路と仮想化の境界によって異なります。

通常、Home Assistant Core自体にGPUは必要ありません。アクセラレーターは主にFrigate、ローカルでの画像認識やAI、メディア処理、または別の関連サービスで使用されます。Linuxでは、複数のコンテナに同じレンダリングデバイスへのアクセスを許可し、ドライバーに処理をスケジュールさせることが可能な場合があります。一方、PCIeデバイス全体をパススルーで受け取るVMは別のモデルであり、そのデバイスをホストや他のゲストから利用できなくする可能性があります。権限を変更する前に、実際にデバイスを使用するプロセスを特定してください。

まず、どのHome Assistantワークロードが実際にアクセラレーターを必要としているかを特定する

ホストにGPUがあるからといって、Home Assistant CoreコンテナにGPUを渡してはいけません。使用するプロセスを明確にしてください。Frigateの動画デコード、OpenVINOによる物体検出、ローカルの言語・画像認識サービス、音声処理、またはHome Assistantが呼び出す別のコンテナなどです。デバイスのマッピングは、そのワークロードのコンテナとセキュリティ境界に割り当てるべきです。

Frigateのデプロイでは、デバイス経路のモデルが明確に示されます。ハードウェアアクセラレーションを利用するには、特定のレンダリングデバイスがコンテナスタック全体を通じて見えている必要があります。最新のFrigate iGPUパススルーガイドは、ホストにGPUがあるというだけで判断せず、デバイスの可視性、グループ権限、仮想化レイヤーを検証しなければならない理由を説明しています。

Home AssistantがAPIやMQTT経由でアクセラレーターを使用するサービスを調整するだけなら、Coreがデバイスへ直接アクセスする必要はありません。GPUのマッピングを実際に使用するコンテナに限定すれば、権限を減らせて、障害の切り分けも容易になります。

共有LinuxレンダリングデバイスとGPU全体のVMパススルーは異なるモデル

Linuxコンテナでは、/dev/dri/renderD128などのレンダーノードを複数のコンテナにマッピングすることで、両方のアプリケーションがホストドライバー経由で処理を送信できる場合があります。共有しているのはスケジューラーとメモリリソースであり、それぞれが独立した物理GPUを受け取るわけではありません。特定のワークロードで安全に利用できるかどうかは、ドライバーとアプリケーションの動作にも左右されます。

LXCのGPUパススルーガイドでは、コンテナの境界が明確に説明されています。ホストが実際のGPUドライバーを保持し、コンテナには/dev/dri/renderD128など、選択したデバイスノードだけを渡します。この共有レンダリングデバイスモデルでは、複数のコンテナが同じアクセラレーター経路にアクセスできますが、GPUエンジン、メモリ帯域幅、ベンダー固有の制限を共有することになります。

PCIeデバイス全体を仮想マシンにパススルーする場合は異なります。最新のProxmox VFIO手順では、この引き渡しを1台のVMによるGPUの排他的な所有として説明しており、そのカードで通常のホストドライバー共有経路は利用できなくなります。SR-IOV、メディエーションデバイス、vGPUなどの機能は、対応ハードウェア上で別の共有モデルを構築できますが、それらは独立した機能であり、通常のパススルーから利用できると考えてはいけません。

性能テストの前に、両方のコンテナで可視性と権限を確認する

各アクセラレーター利用者を個別に起動し、コンテナ内からデバイスノード、ユーザーとグループの権限、ドライバーライブラリ、アプリケーションのハードウェアレポートを確認してください。特権コンテナは、必要なレンダリングデバイスやグループを理解する代わりにはなりません。意図したワークロードが動作するために必要な最小限のデバイスアクセスだけを付与してください。

同じLXCデバイスマッピング手順では、コンテナ内からレンダーノードを確認し、ホスト上での可視性だけを信頼せず、実際のサービスアカウントでテストすることを推奨しています。この方法でコンテナレベルのアクセラレーターアクセスを確認してから性能を比較してください。ホスト上でデバイスが一覧表示されても、アプリケーションがそのデバイスを開ける証拠にはなりません。

両方のコンテナが独立してハードウェアを使用していることを確認できた場合にのみ、可視性の確認段階を通過したと判断してください。一方が気付かないままCPUへフォールバックする場合は、同時実行テストを行う前にマッピングまたはドライバー設定を修正してください。そうしないと、GPU共有が機能しているように見えても、実際にはホストが一方のワークロードをソフトウェアで処理している可能性があります。

-15% OFF

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

Single board computer zimaboard2

単独テストと同時実行テストを行い、共有の限界を確認する

まず各ワークロードを単独で測定します。フレーム処理時間、エンコード・デコード速度、アクセラレーター使用率、メモリ使用量、温度、消費電力、アプリケーションの遅延を確認してください。次に、両方を通常のピーク負荷で同時に実行します。重要なHome Assistant関連ワークロードが期限を守り、どちらのアプリケーションでもエラーやフォールバックが発生しない場合に限り、共有構成を許容できます。

ZimaSpaceにある1台のGPUを複数のコンテナで共有する方法のテストでも、同じ運用上の原則が示されています。デバイスの可視性は最初の確認項目にすぎず、実際に共有できるかどうかは、同時実行時の安定性とリソース競合によって決まります。

実際の同時実行負荷で、両方の利用者が遅延とメモリの上限内に収まる場合は、アクセラレーターを共有してください。一方のジョブによってフレーム落ち、推論遅延、ドライバーリセット、メモリ不足エラー、サーマルスロットリング、不安定なフォールバックが発生する場合は、分離します。GPU全体をVMにパススルーしている場合は、すでに所有されている物理デバイスを2つ目のコンテナにマッピングしようとせず、仮想化レイヤーを再設計するか、別のアクセラレーターを追加してください。