マルチユーザーのJellyfinには、iGPUのどれくらいの余力が必要？
Jellyfinでは、キューを発生させずに、通常時に想定される最も負荷の高い同時ハードウェアトランスコード構成を維持できるだけのiGPUの余裕が必要です。
コーデックのデコード、出力解像度、HDRトーンマッピング、字幕の焼き込み、フレームレート、メモリ帯域幅によって負荷は変わるため、iGPUあたりのユーザー数に普遍的な基準はありません。ダイレクトプレイのユーザーはトランスコード容量をほとんど消費しませんが、難しい変換1件で、単純な変換数件以上の負荷がかかる場合があります。パーセンテージやストリーム数を決める前に、ワークロードの構成を作成してください。
ユーザー数ではなくトランスコードの種類を数える
6人のユーザーがいる家庭でも、ほとんどのクライアントがダイレクトプレイなら、2人のリモートユーザーよりグラフィックス処理の負荷が低い場合があります。容量計画では、アカウント数ではなく、実際にメディアエンジンへ渡される再生モードとフィルターを数えるべきです。
異なるJellyfinの変換経路では、同じシステムでもスループットが大きく異なることがあります。
想定されるセッションを、ダイレクトプレイ、単純なハードウェアトランスコード、トーンマッピング付きトランスコード、字幕の焼き込みに分類してください。アカウント数ではなく、重み付けした構成を基準に容量を決めます。
トーンマッピングと焼き込みには追加の余裕が必要
メディアエンジンが行う処理は、エンコードとデコードだけとは限りません。HDR変換や字幕の合成が、同時実行数を最初に制限する段階になることがあります。
字幕の焼き込みの動作を見ると、元の動画コーデックに互換性がある場合でも、字幕の選択によって動画全体の処理が必要になる理由が分かります。
家庭内でそのようなコンテンツを利用する場合は、ピークテストに少なくとも1件の高負荷なHDRと字幕の組み合わせを含めてください。そうしないと、そのコンテンツを初めて再生したときに、計算上の余裕がなくなる可能性があります。
統合グラフィックスはシステムメモリ帯域幅も共有する
iGPUには、ワークステーション向けの独立したメモリサブシステムがあるわけではありません。システムメモリを共有するため、メモリチャネル構成や他のワークロードの影響を受けることがあります。そのため、ホスト環境も結果の一部になります。
同じホストに配置されたアプリケーションでは、ワークロードが重なるとリソース干渉が発生することがあります。そのため、クリーンなトランスコードベンチマークでは、負荷の高いホームサーバーでの容量を過大評価する可能性があります。
通常利用する関連サービスを稼働させた状態で、トランスコードの組み合わせを再テストしてください。ハードウェアアクセラレーション対応ストリーミングの基準値は、何も動作していないベンチマーク環境ではなく、実際に運用するホストを反映したものであるべきです。
測定した失敗点より上に余裕を確保する
エンジンが安定したレイテンシーでリアルタイム出力を維持しているなら、高い使用率が必ずしも問題になるとは限りません。しかし、余裕のない飽和状態では、少し難しいファイルが1つ加わるだけでシステムが不安定になります。トランスコード速度や再生の安定性が低下するポイントを定義してください。
USEメソッドを使えば、根拠のない安全なパーセンテージではなく、使用率、飽和状態、エラーを明確に表現できます。
再現性のある最初の失敗が発生するまで同時実行数を増やし、そのポイントより十分低い位置に、通常の変動に対応できる余裕を持たせて運用上限を設定してください。ドライバー、クライアント、または主要なライブラリを変更した後は、再テストしてください。
おすすめ商品
テック＆AIハブ
もっと読む
秘密ブローカーは、プロンプトに認証情報を露出させずにAIエージェントへどのように認証情報を渡すのか？
シークレットレスなホームAIエージェントアーキテクチャを通じて、ワークロードID、ポリシー、トークン発行、リクエストインジェクション、編集、期限切れ、失効を追跡します。
ツールサンドボックスはAIエージェントの副作用をどのように封じ込めるのか？
隔離、機能ゲート、使い捨て状態、送信制御、クォータ、監査ログによって、アクションの安全性を証明することなくAIエージェントの副作用を制限する方法をご覧ください。
制約付きデコーディングはどのようにスキーマ準拠のJSONを生成するのか？
スキーマのコンパイル、トークンマスキング、パーサーの状態、サポートされるサブセット、レイテンシ、切り詰め、そして構造的な有効性が正しい値を保証しない理由を理解する。
