Quattro core sono adatti a una casa con Plex dominata dalla riproduzione diretta; otto core giustificano il costo quando le transcodifiche software e i processi simultanei sull’host superano una soglia misurata.
Il numero di core è solo uno degli aspetti. Il confronto cambia quando l’accelerazione video hardware, i codec dei client, i sottotitoli, la latenza dello storage o i processi di backup diventano l’anello debole. Definisci il carico di lavoro prima di considerare otto core come margine di sicurezza.
Verifica di compatibilità: cosa impone ciascun client?
Registra i codec, le risoluzioni, i sottotitoli, il bitrate remoto e la percentuale di riproduzione diretta utilizzati in casa. Una CPU a quattro core con un percorso funzionante per il video hardware può superare una CPU più potente che ricorre alla transcodifica software. Se un client necessario non supporta la riproduzione diretta e l’accelerazione hardware non è disponibile, interrompi il confronto basato sul numero di core e risolvi prima il percorso multimediale.
Asse: concorrenza tra client con un unico carico di lavoro
Esegui il carico di picco previsto: sessioni di riproduzione diretta, una o più transcodifiche, una scansione della libreria e qualsiasi processo di backup che normalmente si sovrapponga. Quattro core offrono il miglior rapporto tra adeguatezza e prezzo quando l’utilizzo della CPU rimane al di sotto del margine sostenibile e la riproduzione resta stabile. Otto core sono preferibili quando le transcodifiche software si accodano, i sottotitoli consumano CPU o i processi in background sottraggono ripetutamente margine alla riproduzione.
Asse: consumi, temperature e costo di gestione
Otto core possono ridurre le code, ma possono anche aumentare il calore, il rumore della ventola e i consumi in idle. Confronta il costo totale di gestione per il periodo in cui prevedi di tenere acceso il server, includendo raffreddamento, storage e una destinazione per i backup. Se i core aggiuntivi restano inattivi perché i client usano la riproduzione diretta, l’opzione più economica è quella tecnicamente corretta.
Asse: espansione e limite di guasto
Scegli la CPU che lasci un passo successivo ben definito. Se la crescita prevista consiste in altre due transcodifiche remote, un aggiornamento dell’accelerazione hardware o un nodo di transcodifica separato potrebbe essere una scelta migliore del raddoppio dei core. Mantieni il database multimediale, la cache e i backup su ruoli espliciti, in modo che un cambio di CPU non modifichi il percorso di ripristino.
Verdetto condizionale e opzione intermedia
Scegli quattro core quando il picco misurato consiste soprattutto nella riproduzione diretta, l’accelerazione hardware è disponibile e i processi in background restano al di sotto del margine. Scegli otto core quando la concorrenza tra client crea code ripetibili di transcodifica software o contesa sulle risorse dell’host. Scegli una CPU con meno core e una iGPU supportata se supera lo stesso test; non scegliere nessuna delle due se il vero collo di bottiglia è il percorso di rete o dello storage. Una discussione sull’hardware per più flussi illustra perché il tipo di transcodifica sia più importante del numero di flussi dichiarato (prove sui carichi di lavoro con flussi misti).
Confronti tra prodotti
Altro da leggere

Server Jellyfin dedicato o host condiviso per app: quale confine fa al caso tuo?
Scegli un hosting dedicato per prestazioni prevedibili di media e ripristino; scegli un hosting condiviso quando i carichi di lavoro sono leggeri e l’isolamento...

Jellyfin vs Plex per lo streaming domestico multiutente: copertura dei client o controllo?
Plex vince quando il criterio decisivo è la compatibilità con i client; Jellyfin vince quando il criterio decisivo è il controllo; entrambi possono essere...

Database Plex locale o host database dedicato: la separazione migliora l’affidabilità?
Una correzione di un confronto errato relativo alla posizione del database di Plex, all’archiviazione di rete, ai backup coerenti e alla ridondanza a livello...

