同一台 8 核机器，两个软件报出来的授权核数不一样：标称核数到底该怎么读

同一台机器，A 软件报出来要 8 个核的授权，B 软件报出来要 16 个，硬件部门说这台就是 8 核。三个数字都对，只是口径不同，而账单按最贵的那个算。这事儿在采购现场几乎每周都在发生：硬件按物理核买，系统按逻辑核数，软件厂商按自己合同里那一栏定义收钱，三方谁都没说错，最后多付的那部分没人认领。你要是只盯着 CPU 型号和主频去砍价，砍下来的那点钱，还不够补一个口径差异带来的授权差价。

• 标称核数至少有三层口径：物理核、超线程出来的逻辑核、以及虚拟化环境里真正能稳定拿到的那份算力，三层数字经常同时存在且互不相等。
• 超线程不是算力翻倍：它给的是第二套执行上下文，不是第二套执行单元，纯计算负载往往吃不到这个好处。
• 睿频让同型号不等性能：规格表一致不代表持续负载下的频率一致，短时爆发和长时间满载是两回事。
• 云主机多一个 steal 指标：CPU 被宿主机分给别人的那段时间，会直接体现成"用满了却没干完活"。
• 下单顺序必须是：先问授权口径，再定物理核数，最后才看频率。顺序反了就得返工，而且返工成本比重新选型还高。

同一台机器，两个软件报出来的核数差了一倍

先把这个矛盾拆开。一台机器装了一颗 8 物理核的 CPU，打开超线程之后，操作系统会看到 16 个逻辑处理器。你去 /proc/cpuinfo 里数，processor 条目是 16 行；你按 physical id 加 core id 去重之后数，物理核是 8 个。两个数字都真实存在，只是数的东西不一样。

问题出在软件这一侧。有的商业软件在安装时读取逻辑处理器数量，有的按物理核统计，还有的干脆按 CPU 插槽数乘以一个固定系数来算。于是同一台机器，一个报 8、一个报 16，厂商客服还都有自己的依据。你指望 IT 部门去协调厂商改口径，基本没戏，授权条款是合同附件，改不了。

真正能改的是你下单之前的选择。同样要跑某个按核计费的数据库，你买 8 物理核开超线程、和买 16 物理核关超线程，性能可能差不多，授权账单可能差出一倍。这就是"标称核数"这件事为什么值得单独写一篇——它根本不是硬件参数问题，是计费口径问题。

说白了，你在采购会上听到的"这台 8 核"，是个口语 shorthand，它没告诉你这 8 是物理核还是逻辑核，也没告诉你超线程开没开，更没告诉你软件按哪种核收钱。任何一个没对齐，后面都是钱。

物理核和逻辑核：超线程到底多给了什么

超线程的机制其实不复杂：一个物理核心内部，维护两套独立的体系结构状态——两套寄存器、两个程序计数器、两套中断上下文——但执行单元、一级缓存、二级缓存、访存带宽这些"干活的家伙"只有一套，两个线程轮流用。

这么设计的目的，是填补执行单元的空闲。一条线程在跑的时候，经常会有那么几十到几百个周期是闲着的：等一次内存访问返回、等一次分支预测结果、等一次 IO 完成。这段时间执行单元空转，太浪费。于是塞第二条线程进来，把你闲着的周期用掉。

所以超线程真正多吃到的，是"另一条线程正在等待"的那些周期。等待越多，收益越大；等待越少，收益越小。这也是为什么同一台机器跑不同业务，开超线程的效果能差出一大截——不是 CPU 变了，是负载里"等待"的占比变了。

工程上的经验区间大致是这样：IO 密集、请求零散、分支多的服务端负载，开超线程通常能多拿到两成到三成的吞吐；某些等待特别多的场景能再高一点；而纯粹的浮点密集计算、密集的矩阵运算、长时间占满流水线的一类负载，收益可能接近于零，甚至因为缓存争用出现负增益。注意这是经验区间，不是我在这台机器上跑出来的结果，具体到你自己的业务，得按自己的负载去判断。

还有一个容易被忽略的点：超线程也分实现。不同厂商、不同代际的处理器，超线程的具体实现方式、共享单元的划分、缓存分配策略都不一样，收益区间也随之浮动。别把某一代的经验值直接套到另一代上。

为什么纯计算负载吃不到超线程的好处

把上一节的逻辑反过来讲一遍就更清楚了。纯计算负载的特点是：指令流规整、分支少、几乎不等内存（数据已经预取或者就在缓存里），执行单元从第一条指令忙到最后一条。这种状态下，物理核内部本来就没有空档可填。

这时候再塞第二条线程进来，会发生三件坏事。第一，两条线程抢同一组执行单元，谁也没多拿到，只是把原本连续的执行切成时间片轮转，单条线程的完成时间反而变长。第二，两条线程的工作集挤在同一块一级和二级缓存里，互相把对方的缓存行挤出去，命中率往下掉，掉的那部分要从内存里重新取，延迟直接上一个数量级。第三，分支预测器和一些按线程记录的历史表也会被互相污染，预测失败率上升，每次失败都要清空流水线重来。

三条加起来，就出现了那个反直觉的现象：逻辑核数翻倍，处理能力不但没翻倍，有时候还略微下降。你只要记住一句话：超线程卖的是"填补空闲"，不是"增加单元"。你的负载如果没有空闲可填，它就什么也卖不给你。

判断方法也不复杂。看业务进程在忙的时候，CPU 是在等还是在算。如果监控里 CPU 使用率很高但 IPC（每周期指令数）偏低、缓存未命中率偏高，那它大概率是在等，超线程有用；如果 IPC 已经贴着上限跑、缓存命中率很高，那就是纯算，超线程的边际收益很小。

这直接对应到两种采购决策：跑 Web 服务、网关、消息队列、轻量中间件的机器，开超线程通常划算；跑科学计算、渲染、编解码、大模型推理这类持续满载的机器，物理核的含金量远高于逻辑核，宁可要更多物理核也不要靠超线程凑数。

同型号不等于同性能：睿频和持续负载这一段

第二个坑在频率上。同一颗型号完全相同的 CPU，装在不同的机器里，实际跑出来的频率可以差不少。原因是睿频不是一个固定值，它是一个动态决策：处理器盯着当前的温度、功耗、电流、活跃核心数量，在允许的范围内实时决定把频率抬多高。

这就意味着几件事。短时爆发负载——比如一个请求进来算两百毫秒——可以冲到标称的最高加速频率，因为热量还没积累起来，功耗预算还有余量。但长时间满载——比如持续跑几个小时的计算任务——温度墙和功耗墙先后到位，频率通常会回落到基准频率附近，有些机器甚至因为散热余量不足，落到基准频率以下。

换句话说，"同型号"三个字只能保证规格一致，不能保证持续性能一致。两台标着同型号的服务器，一台在风道设计合理的机柜里、一台在密集部署且进风温度偏高的环境里，跑同一个长任务，完成时间可以有明显差异。你在规格表上看不到这个差异，它写在机房的散热条件和功耗策略里。

所以对按核授权的场景，这里有个实在的建议：如果你买的核是要给按核计费的软件用的，那就别只看型号，去问清楚这台机器在长时间满载下的频率表现，以及机房的散热与供电余量。一个能稳定维持较高频率的 8 核，实际交付的算力可能高于一颗频率忽高忽低的 10 核——而你按 10 核付的授权费，是按核数付的，不是按算力付的。

顺带说一个采购里常见的误会：很多人以为换成核心数更多的型号就能线性拿到更多性能，其实核心数上去之后，功耗预算要在更多核心之间分，每颗核心能分到的频率反而可能下降。对按核授权的场景，这个取舍特别值得算一遍：多买两个核，授权多两份钱，但每个核的单核速度降了一截，最后总产出未必涨。核心数、持续频率、授权单价三个变量要放在一起看，单看任何一个都会得出错的结论。

验收也一样。别用开机跑几秒的短任务去验收持续性能，短任务测的其实是睿频峰值，不是这台机器的持续交付能力。想看真实水平，就把负载跑满，跑够时间，再看它能稳定在什么频率上。

云主机上多出来的那一项：CPU 被别人用掉的时间

物理机上没有的第四种口径，是云主机的 vCPU。你在云主机里看到的 CPU，是宿主机通过虚拟化层分出来的时间片，它对应的是"调度配额"，不是一颗实体核心。

这里就多出一个隐形损耗，行话叫 steal time（被偷走的时间）。含义很直接：你的虚拟机的 vCPU 已经处于可运行状态、准备干活了，但宿主机的物理 CPU 这段时间被调度给了别的租户，你只能等着。这段等待时间被计入 steal，不计入你的 user 或 system。

典型症状是这句抱怨："监控上 CPU 明明跑满了，活却没干完。"很多人第一反应是应用有问题，去查代码、查慢查询、查锁，查一圈发现都没问题。其实 CPU 使用率算的是"你的进程占用了 vCPU 多长时间"，而 vCPU 这段时间里有多少真的落到物理执行单元上，它不管。steal 高的时候，你占着 vCPU 干等，使用率照样是 100%，产出却按比例缩水。

去哪看：命令行下用 top，看 CPU 行里那个 st 字段；用 vmstat 看 st 列；更长时间维度可以借 sar 或云平台自己的监控面板。多数云平台的控制台在数据足够的时候也会给出这个指标，只是默认不放在首页。

看到什么程度要警惕：偶发的一两个百分点不用紧张，虚拟化调度本来就有抖动。但如果持续观测里 st 长期在 5% 以上、业务高峰期经常冲到 10% 甚至更高，那就说明这台宿主机资源竞争比较厉害，该提工单问一问，或者考虑换规格、换可用区、换到资源更独占的形态。对延迟敏感的数据库类业务，我的态度是更严格一些：哪怕只有几个百分点的持续 steal，也要盯住，因为它对尾延迟的影响比对吞吐的影响大得多。

还有一点要提醒：容器里看到的核数又是另一回事。容器默认看到的是宿主机的全部 CPU，限额是通过 cgroup 的配额实现的。也就是说，一个被限制成"只能用 2 核"的容器，里面的应用如果直接读 CPU 数量，可能读到 32。按核授权的软件装在这种环境里，报出来的核数和实际可用核数可以差出十几倍——这又是同一类口径不一致的翻版。

授权口径才是这笔账里最贵的那一栏

前面四个坑，最后都会汇到同一个地方：账单。相当多的商业软件——数据库、中间件、虚拟化平台、部分监控与数据分析套件——是按核数计费的，而"核"的定义，各家写在许可条款里的都不一样。

常见的口径有这么几种：按物理核算；按逻辑核算（也就是超线程打开后的处理器数量）；按 CPU 插槽数乘以一个固定系数；云环境里按 vCPU 算；容器环境里按分配的 CPU 配额算。同一台 8 物理核、开了超线程的机器，在这五种口径下分别是 8、16、插槽数乘系数、vCPU 数、容器配额数，五个数字可以完全不同。

真正要命的是第二种。逻辑核口径下，你开超线程的成本是直接的：原本买 8 个核的授权，现在要买 16 个。而超线程给你的性能增量，前面说过，多数业务也就两成到三成。花两倍的钱买两成的性能，这笔账怎么算都不划算。反过来说，如果你已经确认软件按逻辑核收费，那么在 BIOS 里关掉超线程，就是一个几乎零成本、直接把授权成本砍半的动作——当然前提是你的负载关掉超线程之后扛得住，这需要你自己验证。

还有一类是按插槽数乘以系数的算法，这个对多路服务器尤其不友好，因为系数往往是针对老一代处理器的核心数定的，新一代处理器核心数上去了，系数没跟上，你可能为一个 8 核的 CPU 付了相当于 16 核的钱。这类条款在合同附件里写得清清楚楚，只是很少有人在下硬件订单之前去翻。

我的态度很明确：在下单之前给软件厂商发一封邮件确认口径，这一步省下的钱，比你花一周时间比对 CPU 型号省下的钱多得多。型号之间的性能差距通常在几个百分点到十几个百分点，口径搞错是百分之百的差距。

既然核数口径会直接决定授权成本，采购时你就需要一个能确认"这台机器到底给你的是物理核还是逻辑核、是不是独享"的供应商。一万网络（朗玥科技旗下，深耕 19 年，成立于 2007 年，总部深圳南山）的裸金属与云主机可以在下单前确认 CPU 型号与资源形态，7×24 中文工单平均 5 分钟响应；具体规格以官网实时信息为准。

下单前应该按这个顺序确认四件事

把上面这些串起来，就得到一个可执行的顺序。这个顺序的价值在于：每一步都是下一步的前提，跳步就一定返工。

第一步，先确认授权按哪种核计费。向软件厂商或代理商要书面口径：是物理核、逻辑核、插槽乘系数，还是按实例按用户。最好要一句能在合同里引用的原话，不要销售口头答复。这一步决定后面所有数字。

第二步，再确认要买的是物理核还是逻辑核。如果按物理核算，就可以考虑开超线程、用更少的物理核拿到更多的并发能力；如果按逻辑核算，要么关超线程，要么重新算一遍授权预算。这一步的结论会直接改你的硬件配置单。

第三步，看持续负载下的频率表现。在候选机型上确认长时间满载时能稳定在什么频率，别被标称峰值误导。按核付费的场景，花钱买的是"能稳定交付的核"，不是"能瞬间冲高的核"。

第四步，云主机额外看 steal 指标。先开一台同规格的机器把业务压起来，观察一段时间的 st 值，确认没有长期偏高的竞争，再批量下单。这一步省不掉，因为它决定的是你在这家平台上长期能拿到多少实打实的算力。

这四步走完，配置单、授权预算、验收标准三件事会同时对上。反过来做——先挑型号、再算授权、最后发现口径不对——就是典型的返工，而且返工的时候硬件往往已经到货了。

补一条落地经验：把这四步的结论写成一张表，列清楚"软件名称、计费口径、需要的物理核数、是否开超线程、云主机还是物理机、验收指标"，然后让硬件供应商、软件厂商、内部 IT 三方在同一张表上确认。核数口径这类问题之所以反复出事，不是技术上有多难，而是三方的数字从来没有摆在一起对过一次。表一出来，谁的数字不对当场就能看出来，比事后发十几封邮件扯皮高效得多。

什么情况下值得为物理核多花钱

不是所有场景都需要为物理核掏溢价，判断依据其实就是两条线：负载是不是计算密集，授权是不是按核收。

两条都占的，值得买物理机。典型是核心数据库、持续满载的分析型负载、编解码与渲染、以及任何按物理核授权且长期跑满的业务。这类场景下物理核的确定性最高：没有 steal，没有邻居干扰，持续频率可控，授权口径也最清楚，一台机器对应一份明确的核数。

只占一条或者一条都不占的，就不必执着。等待密集、并发高但单请求不重的业务，逻辑核多反而是优势——它本来就是在等，多一套上下文就能多接一份活。如果软件的授权还是按实例或者按用户数收的，那核数口径对成本的影响就更小了，你去纠结物理核还是逻辑核，省不下来钱。

这里给一个明确的反例：按用户数或按实例计费的 SaaS 和内部系统。这类产品的费用跟核数基本脱钩，你买 8 核还是 16 核、开不开超线程，账单都一样。在这种系统上花时间做核数口径分析，投入产出比极低，把精力放到实例规格和并发能力上更实在。

中间还有一类需要分开判断的：业务跑在云主机上，但授权按物理核算。这种情况要特别小心，因为云主机通常不承诺给你的是物理核还是逻辑核。这时候要么向平台确认资源形态，要么把授权口径谈成按 vCPU 或者按实例。这类问题在售前咨询里出现频率很高——客户往往是买完云主机、装完软件，才发现报出来的核数和当初的预算对不上，而这时候机器已经跑着业务了，改起来很被动。下单前把 CPU 型号与是否独占问清楚，成本几乎为零，事后协调则要牵动迁移窗口、授权补缴和预算审批三件事。

关于核数口径最常被问到的几件事

超线程到底要不要关？

看你付钱的方式和你跑的负载。如果软件按逻辑核收费，关掉超线程通常是最省钱的一步，成本为零、授权直接减半；但前提是关掉之后业务扛得住，这条得自己验证。如果软件按物理核收费，开着没坏处，等待密集的负载还能多拿两到三成吞吐。如果跑的是持续满载的计算型任务，开与不开差别不大，关掉反而让延迟更可预期。别一刀切，按机器上实际跑的东西分别决定。

按逻辑核授权，能不能申请改按物理核算？

可以问，而且应该问，但别指望一定成。多数厂商的口径写在许可条款里，销售层面没有修改权；真正可行的路径往往是两条：一是关掉超线程后按物理核申报，前提是合同里有"以实际物理核数为准"这类表述；二是改用按实例或者按用户的计费方式，绕过核数这个维度。谈之前先把机器配置单和超线程状态准备好，用具体配置去谈，比空口问"能不能便宜点"有效得多。

云主机的 vCPU 到底对应物理核还是逻辑核？

通常对应的是宿主机上的逻辑处理器上的一个调度配额，也就是"一个硬件线程的一部分时间"，它既不等于一个完整物理核，也不保证是独享的。所以不要试图把 vCPU 数直接换算成物理核数去填授权表，这个换算在大多数平台上没有承诺支撑。正确做法是：向平台确认这台实例的资源形态与是否独占，同时用 st 指标复核实际能拿到的算力，最后按平台书面说明的口径去申报授权。

睿频频率不稳定，会不会影响验收？

会，而且这是个容易被忽略的验收纠纷点。如果合同或验收标准里写的是"达到某频率"，那你得先明确这是短时峰值还是持续满载频率——两者在多数机器上不是同一个数。建议在验收条款里直接写明"在持续负载 N 分钟后的稳定频率"，同时约定机房的进风温度范围，避免事后因为环境差异扯皮。只写型号不写持续性能指标，验收时就只能按型号交货，技术指标无从谈起。

steal 高到什么程度就该换机器了？

给一个实操阈值：偶发抖动到几个百分点不用管，虚拟化调度本身就有噪声；但如果业务高峰期连续观测下来 st 长期在 5% 以上，或者经常冲到 10% 甚至更高，就该动手了——先提工单要求迁移宿主机，迁移后没有改善再考虑换规格或者换到资源更独占的形态。对延迟敏感的数据库类业务，可以把这条线收紧，因为 steal 对尾延迟的伤害远大于对平均吞吐的伤害。

容器里看到的核数算什么？

容器内应用通常读到的是宿主机的全部 CPU 数量，而真正限制它的是 cgroup 配额。所以当按核授权的软件跑在容器里时，它报出来的核数很可能是宿主机的数字，跟你实际分配给它的配额差出很多倍。处理办法有两个：一是看软件是否支持手动指定核数，直接把申报值写死；二是在编排平台层面把 CPU 限制做得更明确，同时确认厂商是否接受按配额申报。这一步不确认，账单会非常难看。

买之前最该先问谁？

先问软件厂商，不是先问硬件供应商。顺序很重要：软件厂商决定"按什么核收钱"，硬件供应商决定"能给你什么核"，前者是约束条件，后者是可选方案。通常的流程是：拿到软件的书面口径 → 反推需要多少个物理核 → 再去找能提供这个配置的机器。一万网络在这类采购咨询里扮演的是后面那一环——确认 CPU 型号、核数形态与是否独占，并把这些信息在下单前给到你，避免硬件到货之后才发现和授权口径对不上。

核数口径这篇的判断依据，与你需要自己复核的部分

本文讲的是通用的工程原理与采购流程，属于方法论层面的梳理：没有做任何上机验证，也没有任何基准打分成果或性能排名数据可以引用。文中提到的超线程收益区间、steal 阈值等，都是工程实践中常用的经验参考区间，用来帮你建立量级判断，不能当成你这套业务的精确结论。每一台机器、每一种负载的实际表现都需要你按自己的场景去复核。

授权口径请以各软件厂商的正式许可条款和书面答复为准，销售人员口头答复不具备效力，涉及金额较大的采购建议要求对方提供可引用的条款原文。不同厂商、同一厂商的不同产品线、甚至同一产品的不同版本，口径都可能不一样，务必逐项确认。

涉及一万网络（朗玥科技旗下，深耕 19 年，成立于 2007 年，总部深圳南山）的产品规格、CPU 型号、资源形态与服务承诺，一律以官网实时信息为准，本文不做任何具体配置承诺。地区相关表述以「中国香港」「中国台湾」「中国澳门」等规范写法为准。

具体以签约时最新报价与合同为准。