有效算力产出只有三成时，GPU报价要重新算一遍

术语解构系列·有效算力成本

文中数据来源、查证时间见文末“资料来源”与“资料边界说明”。

一、报价单上少写了一个分母

云厂商的算力报价页，通常只写一行数字：每卡每小时多少钱。

这行数字回答的是，这张卡开着，一小时收你多少钱。它没有回答另一个问题：这一小时里，这张卡有多少时间、以多高效率，真正变成了你的训练吞吐、推理token和业务结果。

这中间少写的分母，就是有效利用率。

这里先把口径说清楚。本文说的有效利用率，不是单一监控面板里的GPU使用率，也不是MFU。它更接近一个算账口径：一张GPU的标称能力，经过工程效率、任务排布和时间满载之后，最后有多少变成了有效产出。

上半年，这个问题被重新摆到台面上。腾讯云运营商解决方案总经理张晋在2026年MWC上海智能数据中心峰会上，给出过一个判断：相关研究数据显示，国内智算中心GPU平均利用率不足30%。他同时用一个公式拆解这个数字：

算力生产力 = 标称算力 × 效能系数 × 满载系数

标称算力是规格书上的数字。效能系数看GPU跑得快不快，报道中给出的平均值约0.6。满载系数看GPU跑得满不满，平均值约0.5。两个系数相乘，100%的标称算力，最终只剩下约30%的有效产出。

这不是说所有智算中心的每张GPU监控面板都只有30%。它说的是更综合的算力生产力：既包括卡有没有在工作，也包括跑起来以后有没有被网络、显存、调度、计算气泡拖慢。

还有几条公开信息可以放在旁边看。韦乐平在2025云网智联大会上提到，国内智算中心超过280个，GPU利用率很不均衡，平均不到30%。中国信通院云大所刘如明在2025万卡AI集群建设论坛上给过一组卡时口径：2025年国内智算共算量约38亿卡时，同期用算量约14亿卡时，用算占比36.8%。另有媒体文章转引浪潮人工智能研究院测算，称我国智算中心平均算力使用率约30%。

这些数字不是同一个指标，不能互相当作严格校验。它们共同指向的是一个趋势：很多智算资源建起来了，但还没有稳定转化成足够高的有效产出。

作为对照，并行科技COO乔楠在媒体报道中称，公司算力利用率在90%到95%之间。这个数字是公司口径，不是行业统计，但它提供了一个头部算力运营平台的参照：同样是算力资源，经过跨区域调度和运营管理后，利用率可以和行业平均说法拉开很大差距。

这篇文章要拆的就是这个差距。不是为了证明某个30%一定精确，而是想让读者建立一个核算习惯：GPU报价不能只看每小时多少钱，还要看这份报价背后有多少有效算力真的被用出来。

二、同样报价，单位有效成本可能差三倍

先把公式写出来：

单位有效算力成本 = 实例小时价 ÷ 有效利用率

这里的有效利用率，可以是你自己业务里的GPU非空闲时间，也可以是更严格的有效吞吐口径，比如tokens/s/GPU、样本/s/GPU、每百万token成本。文章前面引用的30%，属于综合有效产出率口径。为了让账算得直观，下面先把它近似代入这个公式。

假设某型号GPU的报价是每卡每小时100元。这个数字只是为了方便心算，不对应任何具体厂商的真实报价。

如果有效利用率是30%：

1

单位有效算力成本 = 100 ÷ 30% ≈ 333元/有效GPU小时

如果有效利用率是90%：

1

单位有效算力成本 = 100 ÷ 90% ≈ 111元/有效GPU小时

两者相除，约等于3倍。

这就是标题里的意思。价格表上都是100元一小时，但一边只有三成有效产出，另一边接近九成有效产出，摊到每个有效GPU小时上，成本就不在一个层级。

所以，客户比较GPU云服务器时，只看A厂每小时多少、B厂每小时多少，意义有限。真正该问的是：我的任务在这套平台上能跑到多少有效利用率？能不能排队？能不能错峰？能不能批处理？能不能被更细粒度地切分？能不能和别的任务混部？

报价只在分子上做文章，利用率决定分母。

这里再补一个容易混的概念：利用率不等于MFU。之前拆1P算力时讲过，MFU衡量的是模型训练实际FLOPS相对硬件峰值FLOPS的比例，回答的是卡在跑任务时算得快不快。本文讲的有效利用率，更关心资源有没有持续产生业务结果。一张卡可以MFU不低，但每天只跑几个小时；也可以一直有任务在跑，但因为通信等待、显存碎片、批量太小，单位时间产出不高。新闻稿和报价表经常把这些词混着用，读者自己算账时要先分清口径。

三、低利用率不是浪费两个字能解释

看到30%这个数字，第一反应很容易是管理不善、资源浪费。但如果把镜头拉远一点，会发现它通常是几类结构性问题叠在一起。

第一，峰谷负载。 之前讲DeepSeek峰谷定价时算过这笔账：GPU集群一天24小时都在产生折旧、电费、制冷和运维成本，但用户请求不是平均来的。上午和下午是高峰，凌晨大量空闲。按平均负载建集群，高峰扛不住；按峰值负载建集群，大部分时间会闲。平台用峰谷价格引导客户错峰，本质上就是在处理这条负载曲线。

第二，采购提前量。 智算中心建设周期以季度、年计，业务需求却是逐步爬坡的。批项目、建机房、采购服务器时，往往按远期规划报规模。落地初期真实负载接不住这么多卡，生命周期前半段自然会压低平均利用率。再叠加GPU架构更新、租赁价格变化和折旧压力，运营方不能只看硬件还能不能用，还要看它在未来几年还能不能以有竞争力的成本产出算力。

第三，工程效率。 张晋公式里的效能系数，讲的是GPU跑起来以后还有多少标称能力能释放出来。网络丢包、通信等待、显存碎片、KV Cache膨胀、Prefill和Decode阶段错配，都会让标称算力打折。它不是满载系数，但会影响最终有效产出。

第四，资源粒度太粗。 NVIDIA在2026年一篇讨论Kubernetes GPU集群可观测性的技术博客里提到，很多平台团队看不清GPU被谁占用、占了多少显存、任务是否在排队或空闲。工程师为了避免资源争抢，习惯性申请一整张GPU，但模型经常只用到30%到50%的可用显存和计算资源。这是NVIDIA/Run:ai产品语境下的观察，不能当作全网平均利用率统计，但它说明整卡申请、实际吃不满，是GPU平台管理里足够常见的问题。

再看海外口径。美国能源部资助、劳伦斯伯克利国家实验室发布的《2024 United States Data Center Energy Usage Report》，在做数据中心能耗建模时，把AI训练服务器的运行时间假设为80%，推理服务器假设为40%，并在2024到2028年的场景中，对训练取75%到85%、对推理取37.5%到42.5%的变化区间。

这份报告不是云厂商GPU平均利用率统计，也不能和国内智算中心不足30%的说法直接相除。它更适合作为旁证：训练和推理的利用率结构不同，推理侧40%左右的运行时间假设，并不是离谱数字，而是已经被放进严肃能耗模型里的口径。

所以，低利用率不是一句浪费就能打发。它背后有需求峰谷、建设提前量、调度粒度、工程效率和业务变现节奏。问题不是系统里能不能留余量，而是这部分余量最后由谁买单，客户有没有把它算进单位成本。

四、先把报价表改成自己的核算表

回到客户或团队，第一步不是立刻喊提高利用率，而是把云厂商报价单改造成自己的成本核算表。

如果你在用A100、H100、L20这类GPU实例，账本上不该只记每小时多少钱，至少要多记三类数字：

腾讯云GPU云服务器监控文档对GPU使用率的定义是，评估负载所消耗的计算能力，即非空闲状态百分比，统计维度到单张卡。这个指标不是万能的，它替代不了MFU，也不能直接说明模型训练效率。但如果它完全没有出现在成本表里，你就只是在比较报价，没有在比较算力成本。

这个核算表能避开一个很常见的坑：低价实例可能只是把浪费藏进了利用率里。

假设A实例报价每小时8元，但你的任务实际只能跑到25%有效利用率，有效成本就是32元。B实例报价每小时12元，看起来贵50%，但能稳定跑到70%有效利用率，有效成本约17.1元。报价更高的B，真实算力反而更便宜。

不把利用率算进去，低价很容易变成错觉。

五、有了核算表，再谈怎么把成本降下来

企业能做的事大致有四类。目标不是把仪表盘上的利用率堆到100%，而是在可接受的延迟和稳定性约束下，把单位业务产出的成本压低。

能错峰的任务就错峰。 日报、批量处理、离线分析、历史文档打标签、非实时内容生成，都不一定要挤在白天高峰。DeepSeek峰谷定价那篇讲过，高峰贵、低谷不变，本质上是把负载曲线写进账单。即使你用的平台没有峰谷价，主动错峰也能让自己的任务落进资源更空的时间段。

能批处理的请求就批处理。 推理服务最怕请求稀疏，但又要求低延迟。适当的动态批处理，可以在不明显牺牲体验的前提下提高吞吐。内部工具、异步生成、内容审核、报表整理这类任务，不一定需要像聊天机器人一样逐字返回，批处理带来的成本改善会更明显。

能混部的业务就混部。 在线推理对延迟敏感，负载有峰谷；离线任务对延迟不敏感，但需要持续吃算力。两类任务如果完全隔离部署，低峰时在线GPU会空着。如果能用优先级、抢占和资源隔离把它们放到同一资源池，离线任务就能填补在线服务的波谷。

腾讯云TKE qGPU在离线混部文档里写得很直接：实时推理对资源和延迟敏感，需要尽快拿到资源，但利用率通常偏低；模型训练消耗大量GPU资源，但对短时间抑制不那么敏感。给出的方案是把在线高优先级任务和离线低优先级任务部署在同一张GPU上，用低优先级任务吃掉高优先级任务的空闲算力。

张晋在同一场演讲里给出过一个具体的对照案例，正好把这套逻辑量化了：在核心推理集群的高强度业务混部实测中，通过腾讯TKE调度大脑和qGPU算力切分协作，综合满载率提升到85%，相当于利用率翻倍，实际运营TCO节约约50%。他还给出了另一组更大的对比——传统粗放堆砌的机房，综合算力生产率不到30%；而对效能系数和满载系数做双重优化以后，整座“Token工厂”的综合效率可以跃迁到76%。同一场演讲里，“不到30%”和“76%”构成了一个清晰的工程对照：前者描述传统粗放堆砌下的综合算力生产率，后者描述经过效能系数和满载系数双重优化后，腾讯云给出的目标/案例水平。它不是行业平均值，也不代表所有集群都能照搬。

小红书CPU混部案例也能提供一个思路参照。它证明的是统一调度和混部可以改善资源池利用率，不等于GPU场景可以照搬同样幅度。GPU还有显存、算力隔离、通信和延迟抖动问题，落地难度更高。

用竞价实例吃平台的低谷。 前三条是让自己的负载更均匀，这一条是利用平台负载不均匀的结果。AWS Spot Instance使用EC2闲置容量，价格相对按需实例最高可省90%，但平台需要收回容量时可能中断。Google Cloud Spot VM对很多机型、GPU、TPU提供相对按需最高91%的折扣，但资源可能被抢占。Azure Spot VM也是用较低价格使用未被使用的计算容量，代价是Azure需要容量时会驱逐虚拟机。阿里云抢占式实例的定义，是对当前闲置资源出价，直到出价低于市场价或库存不足才会被回收。

这些产品说的是同一件事：如果你的任务能接受不确定性，愿意在平台空闲时跑，平台就愿意把闲置容量便宜卖给你。

预留实例是另一面。阿里云预留实例券代表承诺一定使用时长以换取更低成本，但无论能否匹配到实际运行的实例，有效期内都要按付费类型支付费用。AWS Reserved Instance页面也写明，买了之后不管实例是否运行，整个预留期都要计费。

按量、预留、Spot，本质上是三种风险分配方式。按量最贵，因为你既要灵活又不承诺长期消化容量。预留能打折，因为你承诺未来会持续使用。Spot最便宜，因为你替平台消化闲置容量，还承担中断风险。

六、两篇文章，其实讲的是同一条负载曲线

这篇可以和峰谷定价那篇（《同一个问题，上午9点问比凌晨贵一倍：DeepSeek峰谷定价的算力账》）放在一起看。

峰谷定价讲的是平台侧：GPU集群一天24小时都有成本，但请求分布不均匀，于是平台把负载曲线印到对外价格表上，高峰贵，低谷便宜或不变，用价格引导客户搬任务。

这篇讲的是客户侧：同样一条负载曲线，换到自己的账本里，就是有效利用率。利用率越低，同样的硬件投入，摊到每一份有效产出上的成本越高。

一端是平台定价，一端是客户核算。你在峰谷定价那篇看到的错峰调用，和这篇讲的提高有效利用率，做的是同一件事：让本来闲着的算力多产出一点东西。

写在最后

云厂商挂出的每小时X元，只是标价。

真正决定单位算力成本的，是这行标价背后那个很少写出来的分母：这张卡有多少时间、以多高效率，变成了有效产出。

国内智算中心有效产出约三成的公开说法，头部平台90%以上利用率的公司口径，都不适合简单当作同一张统计表里的数字。但它们放在一起，足够提醒我们一件事：算力采购不能只比报价，还要比有效利用率。

下次比较GPU云服务，除了问多少钱一小时，还可以多问一句：

这份报价，最后会摊到多少有效GPU小时上？

这个问题，比报价单上的小数点更接近真实成本。

参考资料

• 《警惕算力泡沫：万亿投资，七成空转》，虎嗅网转载自公众号“科技四少”：https://www.huxiu.com/article/4874555.html
• 《“国内智算中心超280个，GPU利用率平均不到30%”》，观察者网/新浪财经转载：https://finance.sina.com.cn/roll/2025-04-24/doc-ineufnkz9220460.shtml
• 《腾讯云张晋：AI下半场，拼的是工程化能力》，C114通信网：https://m.c114.com.cn/w16-1313164.html
• 《你有万卡集群，但你有算力资产么？》，2026第三届AI算力产业大会官网，转述中国信通院云大所云计算部副主任刘如明在IDCC2025“2025万卡AI集群建设论坛”上的发言：https://www.suanliai.cn/shishiyaowen/665.html
• NVIDIA Technical Blog， “Get Real-Time Visibility into GPU Usage Across Kubernetes Clusters”， 2026年。
• Shehabi, A. et al. 2024 United States Data Center Energy Usage Report， Lawrence Berkeley National Laboratory, LBNL-2001637。
• 腾讯云官方文档《qGPU在离线混部》《GPU云服务器GPU使用率监控指标说明》。
• AWS官方文档《Amazon EC2 Spot Instances》《Amazon EC2 Reserved Instances》。
• Google Cloud官方文档《Spot VMs》。
• Microsoft Azure官方文档《Azure Spot Virtual Machines》。
• 阿里云官方帮助文档《创建抢占式ECI实例》《预留实例券》。
• 《集群CPU利用率均值一年提升25%，小红书混部技术的优解方案》，腾讯云开发者社区：https://cloud.tencent.com/developer/article/2366704
• 本文系列前作：《同一个问题，上午9点问比凌晨贵一倍：DeepSeek峰谷定价的算力账》《为什么CPU能一卖四，GPU却只能整卡出租？》《理解什么是“1P”算力》。

资料边界说明： 文中“国内智算中心GPU平均利用率不足30%”来自腾讯云张晋在2026年MWC上海智能数据中心峰会上的公开发言，经媒体报道转述。本文未找到腾讯云官方演讲全文或视频，具体措辞以张晋本人及腾讯云官方口径为准。张晋公式中的30%，严格说是“标称算力×效能系数×满载系数”后的综合算力生产力，不等同于单一监控指标里的GPU非空闲时间。本文在算例中把它近似作为“有效利用率”代入，是为了说明成本核算关系，不是精确财务模型。文中提到的“混部后满载率提升到85%”“综合效率跃迁至76%”，同样来自张晋这场演讲，是腾讯云在自家核心推理集群做混部优化后的实测/披露案例，代表的是优化后能达到的水平，不是行业平均水平，不能理解成所有企业混部后都能做到76%。

韦乐平“平均不到30%”、信通院“用算占比36.8%”、浪潮人工智能研究院“约30%”和并行科技“90%到95%”，来源、统计对象和口径不同，不能互相直接相除，也不能当作同一份行业统计表。本文只把它们作为公开信息中的趋势信号使用：国内部分智算资源存在建多用少、调度不足、有效产出偏低的问题。

LBNL能耗报告的训练/推理运行时间假设，统计对象是美国数据中心能耗建模，不等同于云厂商实际GPU平均利用率，也不能和国内智算中心不足30%的数字直接比较。NVIDIA技术博客中30%到50%的表述来自NVIDIA/Run:ai产品语境下的观察，不构成全网平均利用率统计。文中100元/30%/90%、8元/25%对12元/70%均为简化算例，报价数字不对应任何具体云厂商在特定时点的真实价格，实际报价请以官网当日信息为准。