【影音服务器 02】Jellyfin 硬件选型与转码算力：VPS 没有核显时每路要多少 CPU（2026）

第 01 篇定下了「用 Jellyfin、跑在 VPS 上」的方向，本篇专攻最硬核也最容易算错的一环：硬件选型与转码算力。影音服务器和普通博客、API 服务最大的不同，是它吃的是「计算密集型的实时转码」，而廉价 VPS 恰恰在这一点上最弱。本文把「VPS 没有核显」这个残酷现实讲透，并给一张可直接查的算力表，告诉你不同清晰度每路要多少 CPU，什么情况下该上 GPU 实例，以及 2026 年几家主流厂商机型的真实取舍。把这一篇读透，你基本就不会在硬件上花冤枉钱。

延伸阅读

更多相关攻略推荐：2026 独立站 PCI-DSS 自查清单：SAQ A 还是 A-E、2026 只选月付 VPS：不锁年付、随时退的试错策略、2026 海外仓/ERP 系统自建部署：独立服务器还是云 VPS？、2026 实测：VPS 上自托管 AI 编程助手——Continue、【知识库自托管 02】2026 实测：VPS 自托管 Anythin。

家里的黄金标准：Intel 核显 QuickSync

在家用平台，Intel 第 10 代以后的核显（UHD 630 / 730 / 750）通过 QuickSync 能轻松扛 4–5 路 4K 转码，功耗还低，被公认为影音服务器的「黄金标准」。但问题来了：普通 KVM VPS 不会把宿主的核显直通给你。RackNerd、Contabo、Hetzner、CloudCone 这些常规 VPS 套餐，几乎都不提供 /dev/dri 设备（即没有可用的 Intel iGPU 或 NVIDIA 显卡）。所以「在 VPS 上跑影音服务器」的核心策略是：尽量 Direct Play，转码靠 CPU 顶上。这里要纠正一个常见误解：有些人看到厂商宣传「支持硬件加速」指的是网络层面的加速（如 AES-NI、虚拟化），而不是视频转码的 GPU 加速，两者完全不是一回事，下单前一定要确认到底给不给你 /dev/dri。

Direct Play 优先：能不转码就不转码

转码发生的根本原因是「客户端支持的格式」和「片源格式」对不上，或者带宽不够需要降码率。如果你的客户端（如 Jellyfin 官方 App、Infuse、Kodi）原生支持 H.265/HEVC、H.264、AV1 和常见音频，且网络够快，绝大多数情况下走 Direct Play，服务端几乎零 CPU 占用。所以硬件选型的第一个杠杆不是「买多大 CPU」，而是「把客户端和片源对齐，让转码尽量少发生」。这和第 04 篇的客户端矩阵直接相关：选对客户端，很多「卡顿」其实是客户端不支持格式导致强制转码，换 Infuse 这类原生解码客户端往往立竿见影。换句话说，优化客户端比加 CPU 核数更划算。

软件转码到底吃多少 CPU：算力表

当转码不可避免（弱网、老电视、字幕硬烧），纯 CPU 软件转码（x264）的单路开销大致如下，按现代 Xeon/EPYC 单核性能估算：

结论：一台 2 核 4GB 的 VPS 适合「单人 Direct Play + 偶发 1 路 1080p 转码」；家庭 2–3 人并发，建议 4 核起；一旦涉及 4K → 1080p 转码，4 核会很快打满，得上 8 核或考虑 GPU。需要强调的是，这些数字是基于「较新架构 CPU」的乐观估计；如果是几年前的老 E5，单核性能腰斩，实际所需核数要翻倍。所以下面一节专门讲 CPU 型号比核数更重要。

CPU 型号比核心数更关键

同样是 4 核，老旧 E5 和当代 EPYC/Intel 的单核性能差出一倍多，转码体验天差地别。选购时优先看厂商标称的 CPU 型号与单核跑分，而不是只看核数。Hetzner 的 AMD 机型、Contabo 的 Ryzen 机型单核强、性价比高，是影音服务的常见选择；RackNerd、CloudCone 的特价机便宜但多为老架构，适合轻量 Direct Play，不适合多路转码。一个实用建议：在厂商页面记下 CPU 型号，去公开跑分库查它的单核分数，再对照上面的算力表倒推「我能扛几路」。例如一颗单核跑分 2000 的 4 核机，面对 1080p→1080p 降码（约 1.2 核/路），稳定扛 3 路问题不大；而单核 1000 的老机器同样 4 核，可能 2 路就到顶。

那要不要上 GPU 实例

市面上有带 GPU 的实例（如 Vultr 的 A40、Lambda 的按需 GPU），硬件转码轻松几十路。但价格通常极其昂贵，对一台「看个片」的服务器来说，这个价已经能买好几年流媒体会员了。所以普通用户不要在 VPS 上追求 GPU 转码；把预算花在「更大的 CPU 核数」和「更大的带宽」上更划算。只有当你明确要对外提供多路 4K 转码服务（比如小型影音站），才值得评估 GPU 实例。另外，即便上了 GPU 实例，也要确认厂商确实把卡直通进了你的容器（/dev/dri 可见），否则花了 GPU 的钱还是只能软件转码，那就 double 冤枉。

转码质量设置：CRF 与预设

软件转码时，Jellyfin 允许设置 x264 的 CRF（恒定质量因子，默认约 23）和预设（preset，越快越省 CPU 但体积大）。对 VPS 这种 CPU 紧张的环境，适当调高 preset（如 veryfast）能显著降低 CPU 占用，代价是文件略大、对带宽要求略高——这和第 03 篇的带宽账是联动的。反过来，若带宽充足、CPU 紧张，宁可调高 CRF/用更快预设保流畅，也别让转码把整台机器拖死。理解这组权衡，你就能在「画质、CPU、带宽」三角里找到自己那台机器的最优解。

存储与内存怎么配

Jellyfin 服务本身不吃内存，4GB 足够；真正吃内存的是元数据索引和图片缩略图缓存，图库大时 4GB 会偏紧，建议 8GB。存储方面记住三条：第一，系统盘 20–40GB 足够跑服务；第二，片库用挂载的外部块存储或家里 NAS，别买大系统盘；第三，缩略图缓存很占空间，给元数据目录单独挂一块盘更稳。举个例子：一个 2000 部电影的库，元数据 + 缩略图可能轻松吃掉 10–30GB，若和片库挤在同一块小盘上，扫描时 IO 争抢会让界面卡顿。具体带宽账和流量钱怎么算，看第 03 篇。

实测参考：2026 年几家机型的取舍

把上面所有原则落到具体厂商：RackNerd 年付特价机多为老 E5/老 AMD，单核弱、流量大、便宜，适合「基本 Direct Play + 单人偶尔转码」；CloudCone 类似，常有大流量包；Contabo Ryzen 机型单核明显更强、盘大，适合「服务 + 片库一台机 + 轻度多路转码」；Hetzner 的 CCX/CP 系列 AMD 单核强、网络好，适合对欧洲延迟敏感的家庭。没有「唯一正确」的选择，只有「和你的观看方式匹配」的选择——这也是为什么第 01 篇让你先定软件、再定硬件、最后定网络。

转码监控：怎么确认确实在转码

部署完别凭感觉判断，用数据说话。在 Jellyfin 后台的「活动 / 会话」里能看到每路播放是 Direct Play 还是转码、用了多少 CPU、当前码率多少；容器层面用 docker stats jellyfin 能实时看到 CPU 占用曲线。如果你预期是 Direct Play 但实际在转码，第一反应应该是查客户端格式支持，而不是加机器。长期观察还能帮你反推「我家到底几路并发」，回头修正第 01 篇的选型框架，形成闭环。另外，首次上线建议故意播一部高码率片子、故意用不支持格式的客户端，亲眼看一次转码发生、看一次 CPU 曲线跳动，你会对「算力表」里的数字有肌肉记忆，以后选型不再心虚。