JellyfinのCPUコア数を増やすと、実際にいつ高速化するのか？

エヴァ・ウォン

IceWhale author

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

More CPU Cores for Jellyfin: When Do They Actually Make It Faster?

高コア数CPUがJellyfinを高速化するのは、両方の候補を同じ再生経路で比較し、コア数の少ない方が実際にCPUボトルネックになっていることが測定で確認できた場合に限られます。それ以外では、メディアアクセラレーション、コア単体の速度、ストレージ、ネットワーク、温度が先に結果を左右することがあります。

コア数を比較する前にメディアエンジンと再生経路を一定にする

一方の候補がダイレクト再生、もう一方がソフトウェアトランスコード、または片方だけが正常にハードウェアアクセラレーションを利用できる場合、コア数の比較は誤解を招きます。これは異なるワークロードであるため、まずクライアント、ファイル、字幕経路、目標ビットレート、アクセラレーション方式、バックグラウンド負荷を一定にしてから、結果をCPUコア数に帰するのが比較の基本です。

最新のハードウェアトランスコードガイドは、デバイスのサポートとパススルーによって処理経路全体が変わる理由を示しています。一方のプラットフォームがQSV、NVENC、またはVA-APIを使用し、もう一方がソフトウェア処理にフォールバックしているなら、その比較の主眼はコア数ではなく、メディアエンジンと設定です。

両方のシステムが同じ再生モードを示してから、直接比較を始めてください。ハードウェアの違いによって同じアクセラレーション経路を利用できない場合は、それをプラットフォームの優位性として報告し、多コアCPUが単独のコア数実験に勝ったかのように扱わないでください。

両方のCPUが基準を満たせば、ダイレクト再生では差がなくなる

ダイレクト再生では動画のデコードや再エンコードを行わないため、一般的なCPU処理は通常のサーバーロジック、認証、メタデータ処理、ファイル配信に限られます。両方の候補がこれらの処理に十分なCPU性能を持っていれば、コアを増やしても、変更されていないメディアストリームがネットワークを通過する速度は上がりません。

ダイレクト再生のワークロードガイドは、実際の動画トランスコードと比べてCPUの関与がいかに小さいかを示しています。そのため、ダイレクト再生は有用な対照ケースです。両方のCPUが同じファイルを安定したサーバーレイテンシーで配信できるなら、そのワークロードではコア数による差が出ない領域に達しています。

同程度のレイテンシー、消費電力、信頼性でこの基準を満たすなら、コア数の少ない候補の方がコスト面で有利です。別のCPU負荷が同時にホスト全体の結果を変えない限り、使用されていないコアによって高コア数の候補がJellyfinで有利になることはありません。

ソフトウェアトランスコードでは、高コア数CPUが条件付きで勝つ

ソフトウェアによるデコード、フィルタリング、エンコードは複数スレッドを利用できるため、コアを増やすことでフレーム毎秒を向上させたり、CPUのみで複数の変換を同時に処理したりできます。ただし、コーデックの設計、フィルター、同期、メモリ帯域幅、スレッド処理のオーバーヘッドによって、スループットの伸びには限界があります。

制御されたFFmpegのスレッドスケーリングテストでは、少ないスレッド数ではスループットが急速に向上し、その後はスレッドを追加しても貢献度が下がって横ばいになることが示されています。Jellyfinでも注目すべき比較結果は同じです。追加したコアが実際のトランスコードで有用なスループットに変換されている間だけ、コア数に意味があります。

コア数の少ない候補がリアルタイム変換、または必要な同時CPUトランスコード数を維持できず、大きいCPUが同一のワークロードを余裕を持って完了できる場合、高コア数CPUが勝ちます。両方がすでに目標を上回っているなら、追加のスループットは予備能力であり、視聴体験が速くなるわけではありません。

-15% OFF

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

Single board computer zimaboard2

CPU全体にわたってスケールしない処理では、少ない高速コアが勝つこともある

総コア数だけでは、コア単体の性能、アーキテクチャ世代、持続的なクロック動作、電力制限は分かりません。Jellyfinの一部の処理や補助プロセスはスレッド数が少ないため、別のプロセッサーの方が総コア数が多くても、個々のコアが強いCPUの方が早く完了できる場合があります。

同じ限界効用の曲線は、スケジュール可能なスレッド数が増えても、1つのタスクにとって自動的に有用になるわけではない理由を示しています。有効な並列処理を使い切った後は、別のアイドル状態のコア群よりも、シングルスレッド応答性、キャッシュ動作、持続周波数の方が重要になることがあります。

このような場合は、仕様表の比較よりもモデル間の実測が有効です。制御されたバックグラウンド状態でのインターフェースの応答性など、スレッド数の少ない処理を、トランスコード総スループットとは分けて測定してください。多スレッドテストでは負けるCPUがインタラクティブな処理では速いこともあれば、その逆もあります。

追加コアがホスト全体の結果を最も変えやすいのは、CPU処理を同時に実行する場合

JellyfinをVM、ダウンロード自動化、バックアップ、写真解析、ビルド、ローカルAIなどと同じマシンで実行すると、比較結果は変わります。これらのサービスは、Jellyfinがアプリケーションの応答性やソフトウェア処理へのフォールバックを必要とするのと同時にCPUを消費することがあります。そのため、Jellyfin単体では使い切れない場合でも、高コア数CPUが余裕を維持できる可能性があります。

最新の複数サービス向けミニPC比較では、ホームサーバーのあらゆる処理がCPUバウンドだと仮定せず、CPUクラスをRAM、ネットワーク、電力、仮想化への適性と合わせて評価しています。これがホスト全体での正しい比較です。追加のコアは、通常時の複合ピーク負荷が実際にそれらを使用するときに意味を持ちます。

ZimaSpaceのハードウェアアクセラレーション比較は、補足となる境界条件を示しています。まず繰り返し発生する動画処理をオフロードし、その後で残った共有サービスがより大きなCPUを必要とするか判断してください。これらのサービスを再生処理から離れた時間帯にスケジュールできるなら、コア数の少ない候補の方が常時稼働ホストとして適している可能性があります。

条件付きの結論：コア数の少ない候補が飽和してから、追加のコアを選ぶ

両方の候補で同じ代表的なピーク負荷を実行し、再生モード、該当する場合はトランスコード速度、CPU使用率、タスク完了時間、温度、消費電力、ユーザーが感じるレイテンシーを記録してください。コア数の少ないマシンが処理期限に間に合わなくなるか、安定した頭打ちに達するまで、CPU並列性だけを高めていきます。

測定済みの同一プロトコルのハードウェア比較は、ここで重要な報告方法を示しています。電力と負荷をどのように測定したかを明示し、直接測定した数値と出典のある数値を区別しています。Jellyfinの比較でも、ファイル、クライアント、アクセラレーションの状態、バックグラウンドサービスについて同じように記載すべきです。

制御された結果	コア数の少ない候補	コア数の多い候補
両方でダイレクト再生が成功	通常はコストパフォーマンスに優れる	視聴速度の優位性なし
両方で同じハードウェアトランスコードが成功	通常は十分	追加コアの大半は予備能力
ソフトウェアトランスコードがリアルタイム処理に届かない	CPUバウンドなら不利	ワークロードがスケールする場合のみ有利
スレッド数の少ない処理	コア単体の性能が高ければ勝てる	コア数だけでは決まらない
CPU負荷の高い複合ピーク	余裕を失う可能性がある	追加コアが有効に使われる場合に有利

コア数の少ない候補が最初にCPUボトルネックとなり、大きいCPUが同じ条件下でそのボトルネックを解消できる場合に限り、高コア数CPUを選んでください。両方が条件を満たすなら、代わりにメディアエンジンのサポート、消費電力、価格、保守性、ストレージ、ネットワーク、復旧性で選びましょう。コア数の多さが結果を変える仕様になるのは、ワークロードがそれらを利用できることを実証してからです。