加载失败
这是一篇 2026 年的云 VM 性能/价格横向对比，覆盖 44 种 VM、7 家提供商，目的在于找出不同实例在性能/成本上的相对表现。评论讨论的核心是公有云的弹性与托管服务价值（自动扩缩、多区域、托管数据库等）与专用裸金属/colocation（如 Hetzner、OVH、Datapacket 或自建机架）在单指令或单核成本上的优势之间的权衡。讨论还具体涉及 AMD 新架构（Turin、EPYC 4565p）在单核与多核基准的亮眼表现、spot/reserved 定价策略、以及出网/存储等隐性费用对 TCO 的决定性影响。评论中也提到若干工具和资源以简化裸金属/托管选型与基准（如 BlueDot 的 TUI 聚合、baremetalsavings、Blacksmith.sh 和 yabs 基准脚本）。
多位评论指出专用主机或机柜托管在性能/价格上常明显优于大云厂商，特别是对固定或 CPU 密集型负载。具体例子包括 Hetzner 的 CPX22、16‑core Ryzen 9 7950X3D 报价约 €104/月，以及 OVH/Datapacket 可拿到含 Turin 或 EPYC 4565p 的高线程机器，整体价格远低于公有云同级别实例。有人实测把约 $500 的 EPYC 4565p 装进自有机架后整机成本低于 $2k，单核在某些基准上比云上 Turin 快近 2×。尽管有评论提到 Hetzner 最近涨价（约 30%），但共识是对稳定且可接受单一区域部署的项目，专用/托管能显著降低“每指令/每核心”成本。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
反对者强调简单的硬件回收期计算忽略了机柜托管费、安装费、电力、带宽以及为冗余而购置的备用机器，导致所谓“几个月回本”在现实中常伸长为数年。工程迁移、人力成本和为可靠性设计的多机部署也会吞噬节省；有人举例说明几名工程师一周的迁移工作就能抵消基础设施看似节省的费用。云端的弹性（按需扩缩、地域分发、托管服务）与运维效率也是重要价值点，因此推荐把运维成本、迁移代价和 spot/reserved 定价一并纳入对比。许多评论建议对特定场景做成本-收益表或采用混合方案（机架做基底、云做弹性扩展）以减小风险。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论普遍赞扬 AMD 在服务器端的迭代（Milan→Genoa→Turin），认为 Turin 表现出色并带来显著性能提升。有人报告 EPYC 4565p 在自有硬件上可稳定 boost 到 ~5.1GHz，在单核基准上比云端同类 Turin 实例（约 4.1GHz）快近两倍；桌面带 3D‑VCache 的芯片在单线程场景仍然出众，但服务器芯片在多线程与持续负载下更具优势。评论还指出不同平台在内存与 I/O 子系统上差异显著，评估时不能只看核数或标称频率。总体结论是 AMD 在性价比与单指令性能上已非常具有竞争力，但需要按负载类型具体选择 CPU 家族。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
多位评论注意到 OCI 的计算定价和在某些情形下更便宜或免费的出网流量能显著降低账单，因而成为“低成本”选项。与此同时，评论普遍警告 OCI 在用户体验、托管服务可靠性和账号管理上存在问题（如试用被关停、控制台难用），并提醒不要贸然使用其专有 DBaaS 以免被锁定。一些团队的经验是把应用只依赖基础的 Compute/Block/Object Storage，借此获得成本优势，同时为此付出更多 SRE/DevOps 工作（例如自写 autoscaling 逻辑）。结论是 OCI 可显著削减云费，但前提是有意识地避免专有托管服务并接受较差的 UX 与额外运维负担。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多名评论者指出云厂商并非在 VM 本体上赚最多，出网（egress）、快照、弹性 IP、存储 I/O 等零星费用才是账单的大头。AWS 的带宽定价被描述为极高的加价点，评论建议在基准中加入网络性能、出网成本和 SAN/非本地存储表现，因为这些会显著影响 TCO（总拥有成本）。OCI 在出网定价上被视为优势之一，但总体上网络和存储的定价策略往往比单机小时价更能左右最终账单。因而仅凭每小时 VM 单价做决策通常不足以反映真实花费。
评论反复强调没有工作负载背景的宏观基准容易误导：CI、编译和许多开发工具存在单线程瓶颈并且利用率不固定，burstable 实例需先耗尽 CPU credit 才能做公平对比。vCPU 数量可能被超分配或出于 live migration 而屏蔽部分 CPU feature，实际表现会与 /proc/cpuinfo 上看到的不同；同时“noisy neighbour”与 I/O 瓶颈也会影响效率。因此建议把 CI 的占空比、单核延迟、IO 与网络延迟、以及 spot/预留定价都纳入评估，并补充 GPU（训练/推理）基准以覆盖更多负载场景。最终建议是用真实负载数据持续进行 rightsizing 或用工具自动化迁移与调优，而不是只看单点基准。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
为减少从云转向专用机的摩擦，评论推荐了若干聚合与托管工具：BlueDot（一个 TUI 比价器）可将数万种配置跨多云聚合比价，baremetalsavings 提供裸金属价格比较，Blacksmith.sh 提供托管专用主机服务，yabs 是社区常用的基准脚本。评论指出这些工具能让拿到 Hetzner 或 OVH 的低价机器变得像在 AWS 上开实例那样方便，社区论坛（LowEndTalk、Discord）和促销（黑五）也常能拿到零 setup 或低价测试主机。尽管工具降低了选型成本，大家仍提醒它们不能替代对灾备、替换周期和运维自动化的长期规划。
vCPU: 虚拟 CPU（vCPU），云厂商分配给 VM 的逻辑核心；vCPU 可能被超分配或屏蔽部分硬件特性，因此标称核数不等同于物理核心的实际单核性能。
spot instance: Spot instance（抢占式实例/spot）是云供应商基于闲置容量以极低价格出租的实例，随时可能被回收，适合容错型批处理或短时任务以降低成本。
colocation / colo: Colocation（机柜托管/colo）是在第三方数据中心放置自有服务器并支付机架、电力与带宽等费用，能获得更优硬件性价比但需承担现场维护和替换周期。
bare metal: Bare metal（裸金属/专用主机）指租用整台物理服务器而非虚拟化实例，优点是无虚拟化开销、单线程与 I/O 性能更好，但缺少云原生的弹性和托管服务。
egress（出口带宽）: Egress（出口流量/带宽外发）指从云平台向互联网传输数据的费用，常常是云账单中最昂贵且容易被忽略的部分，显著影响总拥有成本。
single-thread performance: Single-thread performance（单线程性能）衡量单个 CPU 核心在串行任务上的执行速度，对编译、CI、延迟敏感应用等影响显著，不能简单用核数替代。