3台以上のJellyfinサーバー候補を比較する際は、まず実際のワークロードに対応できないものを除外し、その後、再生、ストレージ、復旧、所有コストを左右する仕様だけを採点します。
候補を見る前に、1つのワークロード契約を作成する
通常時で最も負荷が高い時間帯を定義します。同時利用者数、クライアントの種類、Direct Playの割合、繰り返し発生するトランスコード、字幕の動作、HDRトーンマッピング、リモートアップロード、ライブラリ容量、ストレージの増加量、その他の常時稼働サービスなどを決めます。満たすべき結果が固定されるまで、候補を「より優れている」と判断することはできません。
現在のJellyfinハードウェア選定ガイドがDirect Playとトランスコードから始めているのは適切です。この1つのワークフロー上の選択によって、数多くの大まかなCPU比較よりも必要な計算性能が大きく変わるからです。
曖昧な目標ではなく、合格条件を書き出します。代表的なトランスコードがリアルタイムを上回ること、アプリ状態用ストレージに十分な空き容量があること、有線ネットワークがピーク負荷に対応できること、そして延期できないバックグラウンド処理が同時に実行されてもホストが応答性を維持することです。これらを、すべての候補がクリアすべき関門にします。
性能を採点する前に、互換性で候補を除外する
CPUアーキテクチャ、OSのサポート状況、ハードウェアによる動画デコード/エンコード、コンテナまたはVMでのデバイスパススルー、RAMの上限、ストレージインターフェース、ネットワークポート、物理的な拡張性を確認します。メディアエンジンを利用できなかったり、必要なドライブを搭載できなかったりする候補は、高いベンチマーク性能でも救えません。
実用的なホームサーバー用ミニPCガイドでは、RAMの上限とポート数を重視しています。これらは後から追加するのが難しい、または不可能だからです。これが正しい比較方法です。ベンチマークの勝利を評価する前に、構造上の不一致を除外します。
互換性には点数ではなく、PASS/FAILを使います。利用するクライアントに必要なアクセラレーター経路がない候補は、「5点減点」ではなく不合格です。すべての候補が合格した場合、その仕様の重みを下げ、次の評価軸に進みます。
残ったすべての候補を、1つの判断軸ずつ比較する
なお違いが残る要素について行を作ります。検証済みのメディアアクセラレーション、ソフトウェア処理用のCPU余力、同時稼働サービス向けのRAM、アプリストレージのレイテンシ、ドライブ拡張性、ネットワーク経路、アイドル時消費電力、騒音、保守性などです。候補A、B、Cを同じ行で比較してから次の項目に進みます。Aのミニレビューを書き、次にB、最後にCを書く方法は避けてください。
実用的なホームラボ候補ガイドでは、ピーク時のCPU性能だけを唯一の軸とせず、消費電力、拡張性、ネットワーク、騒音、ワークロードへの適合性を比較しています。ZimaSpaceのJellyfin仕様変換フレームワークも、CPU、RAM、IOPSに同じ考え方を適用しています。
容量を増やしても結果が変わらない軸の重みは下げます。メディアストレージとクライアントが1GbEを超えないなら、10GbEポートに点数を与える価値はありません。ビデオエンジンが負荷の大部分を処理し、CPU負荷の高い併用サービスもないなら、16コアCPUにも点数を与える必要はありません。こうして、仕様の数字だけを追いかける比較を排除できます。
重要なワークロードには、実測または再現可能な根拠を使う
勝敗を左右し得る少数の軸では、合成ランキングより実テストを優先します。同じ難しいファイルを再生し、同じトランスコードを強制し、同じスキャンを実行し、同じアイドル時消費電力を測定します。候補を直接テストできない場合は、世代レベルのコーデック対応状況や独立したベンチマークを使い、不確実性があることも明示します。
実用的なサーバー比較は、同一ワークロードのベンチマーク手法に従うと、より信頼性が高まります。ワークロードを一定に保ち、候補の属性を1つだけ変え、判断に結び付くレイテンシやスループットを測定します。
互換性のないベンチマークを1つのスコアにまとめないでください。Cinebenchの結果はJellyfinのトランスコード能力を証明せず、SSDのシーケンシャル帯域幅もメタデータのレイテンシを証明しません。各ベンチマークは、実際に表しているワークロードにだけ使用します。
最終的な判断軸に、所有と復旧を加える
複数の候補がすべてワークロードに合格したら、購入価格が意味を持ちます。アイドル時消費電力、保証とサポート、交換可能なRAMまたはストレージ、交換部品の入手性、騒音、ドライブ拡張性、交換用ハードウェア上でJellyfinの状態をどれだけ早く復元できるかを加えます。これらは、再生性能が同じように感じられるマシン同士の優劣を決めることがあります。
ホームラボのコスト内訳では、ハードウェア費用、電力、バックアップ機器、作業時間を、1回の購入価格の背後に隠すのではなく、同じ所有モデルに含めるべき理由が示されています。
価格は、適合性を確認した後の上限または同点時の決め手として使います。最も安い不合格候補はお買い得ではなく、最も高価な合格候補が自動的に安全とは限りません。想定する利用期間に必要な復旧性と拡張性を満たす中で、最もコストの低い合格候補を選びます。
仕様ランキングではなく、短い候補マトリックスで結論を出す
| 判断の関門 | 候補A | 候補B | 候補C |
|---|---|---|---|
| 重要なクライアント+必要なトランスコード | PASS/FAIL | PASS/FAIL | PASS/FAIL |
| 検証済みのアクセラレーション経路 | PASS/FAIL | PASS/FAIL | PASS/FAIL |
| RAM/ストレージ/ネットワークの拡張性 | 適合 | 適合 | 適合 |
| 高負荷ワークロードの実測余力 | 評価値 | 評価値 | 評価値 |
| 3~5年間の所有コスト | 見積もり | 見積もり | 見積もり |
| 復旧と交換の経路 | 強い/弱い | 強い/弱い | 強い/弱い |
いずれかの候補がすべての重要な関門に合格し、実測で十分な余力があり、より高価な機能を追加してもユーザーが見て分かる結果が変わらないなら、比較を終えます。現在の実測ミニPC比較では、コンセントからの消費電力テスト条件を公開し、直接測定した結果とコミュニティから収集した数値を分けています。これが正しい比較姿勢です。測定手順を明示したうえで、Jellyfinの同点を決める際は、関係のないピーク仕様を評価するのではなく、価格、サポート、騒音、拡張性を使います。
3台すべてが重要な関門に失敗した場合、失敗を平均して勝者を決めないでください。候補リスト、クライアント戦略、またはストレージ構成を変更します。意思決定マトリックスが機能しているのは、「どれも選ばない」が正当な答えになるときです。
購入ガイド
もっと読む

Jellyfinの保証・交換・復旧コストを評価する方法
より安価なJellyfinサーバーとは、必ずしも購入時の価格が最も低いものや保証期間が最も長いものではなく、回収可能な所有コストがより低いものです。

より多くのCPUコアが実際に役立つJellyfinのワークロードとは?
実測したJellyfinの処理がCPU並列化されている場合にのみ、CPUコア数を増やしましょう。Direct Playやハードウェアアクセラレーションによる動画再生では、通常、ボトルネックは別の箇所に移ります。

ユーザー数とデータ量の増加に伴い、JellyfinにはどれくらいのRAMが必要ですか?
アクティブユーザー数と同時に稼働するワークロードを基準にJellyfinのRAM容量を決め、ライブラリのサイズではなく、メモリプレッシャーやスワップ、OOMイベントが限界を示したときにアップグレードします。

