看服务器监控面板时，有一个很自然的直觉：CPU 平均利用率 20%，说明这台机器只用了两成，那么电费大概也就是两成。这个直觉几乎必然是错的，而且错的方向对运营很不利——它会让人觉得低利用率“反正也没花多少钱”，于是长期放着不管。九游会在整理绿色运营流程时，最先要求把“利用率”和“功率”分开看，就是因为这两条曲线之间的落差，正是空闲算力里最大的浪费。
利用率是比例，功率是电表读数，两者不成正比
一台通用服务器的功率大致由两部分构成：一部分是只要开机就存在的基础功率，包括主板、内存刷新、风扇、网卡、电源转换损耗，以及没有任务时也保持供电的处理器和加速卡；另一部分才是随负载上升而增加的动态功率。业内把“功率随负载线性下降到接近零”的理想情形叫能耗比例性（Energy Proportionality）。现实中的服务器离这个理想有很大距离：空闲功率占峰值功率的比例，随硬件代际、电源管理设置和固件版本差别很大，较早一代的服务器空闲时可以耗掉峰值的一半以上，较新的机型和调优较好的配置会明显低一些，但仍然不是零。本文不给任何“某型号空闲多少瓦”的断言，因为这必须在自己的机器上用功率计或BMC读数测出来。
这带来一个反直觉的后果：利用率越低，每单位工作分摊到的电反而越多。同样处理一万个玩家的心跳包，跑在一台 80% 利用率的机器上，和摊在五台各 16% 的机器上，后者的总耗电明显更高。所谓“隐藏能耗”，隐藏的就是这一段没有产出、却真实计入电表的功率。
模拟示例：100台机器在20%利用率下的账
假设有一个区域，部署了 100 台同型号的游戏逻辑服务器，每台峰值功率 500W，空闲功率设为峰值的 40%，也就是 200W。按线性模型，利用率为 u 时功率为 200 + 300 × u（单位W）。
- 低峰时段，全部 100 台都在线，每台利用率 20%：单台功率 200 + 300 × 0.2 = 260W，整体 26kW。虽然利用率只有 20%，功率已经是峰值的 52%。
- 每单位工作的电耗：满载时 500W 完成 1 份工作；20% 利用率时 260W 完成 0.2 份工作，也就是每份工作耗电是满载时的 2.6 倍。
- 合并后：总工作量等于 100 台 × 20% = 20 份满载机器的工作。把它们集中到 25 台上，每台约 80% 利用率，单台功率 200 + 300 × 0.8 = 440W，合计 11kW；再留 5 台保持空闲热备，5 × 200W = 1kW；其余 70 台进入低功耗休眠，假设每台 30W，共 2.1kW。合计约 14.1kW。
与原来的 26kW 相比，示例里功率下降了约四成半。注意这个结论有三个前提在起作用：一是任务确实可以被合并而不影响延迟；二是休眠机器能够在需要时及时唤醒；三是 80% 这个目标利用率不会引发排队或抖动。任何一个前提不成立，节省的比例就会缩水，甚至变成事故。
另外，服务器的电还要乘上机房的制冷与配电开销。如果这个示例所在机房的 PUE 设为 1.5，那么 IT 功率每减少 1kW，设施总功率大致减少 1.5kW，冷却系统也不用再为没有产出的热量继续工作。不过 PUE 只描述设施相对 IT 设备的额外开销，并不说明电从哪里来，这一点在《数据中心PUE很好看，为什么整体碳排还是可能很高？》里有单独展开。
“空闲”其实分四种，处理方式各不相同
在游戏基础设施里，把所有没跑满的机器都叫“空闲”，会直接导致错误的操作。九游会在做空闲算力分析时，至少区分下面四种情况。
被预留出来的冗余
为了应对开服、活动或热门时段的突然涌入，运营会提前多开实例，这部分是“有意的空闲”。它是否合理，取决于预测的准确度和实例冷启动时间。如果新实例从申请到可接入玩家要几分钟，那么缓冲就必须覆盖这几分钟内的人数增长。这类问题在《晚上玩家多就一定要多开服务器吗？九游会AI开始预测“下一小时到底需要多少算力”》里有更完整的讨论，这里只强调一点：冗余不是错，长期不加区分的冗余才是错。
玩家已下线但实例还在的遗留
对局结束、房间空了、分区人数很低，但进程和虚拟机依然驻留，占用的内存与底座功率一直在。这类空闲最适合合并或回收，前提是没有会话状态需要迁移。
被拆散的负载
同一份工作被摊到过多的小实例上，每台都不满。这类情形本质上是装箱问题，把小实例合并到较少的机器上就能提升单机利用率，同时释放整机。
本来就可以推迟的后台工作
日志分析、资产处理、补丁构建、内容生成和离线模型训练，并不要求马上跑。它们往往被安排在“凌晨”，但凌晨并不一定是最好的时间，这在《玩家已经下线，服务器为什么还在耗电？九游会AI如何处理低峰期资源》一文里从低峰期资源的角度做了梳理。
哪些机器能合并、能睡、必须热着
四种空闲对应的处置方式大致是：合并、休眠、热备、延迟。判断顺序可以写成几句话，而不是一条“利用率低于某阈值就关机”的规则。
- 可合并：无状态或状态可以快速迁移的逻辑服务，目标机器有足够的内存与网络余量，合并后的峰值利用率仍留有缓冲。
- 可进入低功耗状态：未来一段时间预测人数很低、唤醒时间小于预测窗口的机器。这里的关键数据是“唤醒到可接入”的实际耗时，而不是厂商标称的唤醒时间。
- 必须热备：承担实时对战、匹配、登录和支付回调的关键路径，以及所在区域没有第二个可选区域的机器。这类机器省电的收益，远小于一次玩家大规模掉线带来的损失。
- 可延迟：不影响玩家实时体验的后台批处理。它们不应该占用热备机器的“空闲”而无限增长，也不应该在玩家高峰时和实时服务抢资源。
实时游戏的基本原则没有变：延迟与可用性优先，节能是在满足这两个约束之后的空间。一个好的空闲算力策略，应该允许在数据里看到“这台机器因为延迟约束不能动”这样的结论，而不是硬把利用率数字压下去。
GPU的空闲比CPU更难看，也更难观测
CPU 利用率是大多数监控默认提供的指标，GPU 就没那么直接。用于云渲染、视频编码、AI 推理或画面处理的 GPU，其“利用率”指标只反映一段时间内有没有内核在执行，并不等于流处理器真的被填满，也不区分显存带宽是否成为瓶颈。一张 GPU 显示 60% 利用率，可能其中一半时间只是在等数据。
近期有研究专门讨论这一点。2026 年 4 月一篇 arXiv 论文《The Energy Cost of Execution-Idle in GPU Clusters》测量了 GPU 集群里一种“执行中的空闲”状态：任务仍占着 GPU，但硬件处于低活动。论文报告在其研究的集群里，这种状态占了任务执行时间的约两成、能耗的一成左右。这个数字属于他们研究的具体集群与工作负载，不能直接套用到游戏渲染或推理上，但它提醒了一件事：只看“GPU 有没有被任务占用”，会低估真正没有产出的能耗。
所以九游会在设计观测口径时，倾向于把 GPU 的“被占用”和“有效吞吐”分开，并把每个任务的能耗作为单独指标。GPU 利用率高是否就意味着节能，本身是另一个值得单独讨论的问题，可以参考《GPU利用率高就一定节能吗？九游会为什么要同时观察吞吐量和每任务能耗》。
合并的代价：预测误差、冷启动与缓冲比例
合并和休眠都不是免费的。最直接的风险是预测低估：机器已经被合并或休眠，人数却比预测涨得快，新实例启动的几分钟里玩家会遇到排队、登录失败或者延迟抬升。要控制这种风险，需要至少三个参数：
- 预测误差的分布：不是平均误差，而是高估和低估各自的尾部。低估的尾部决定缓冲要留多少。
- 冷启动时间：从决策到实例可接入玩家的全过程，包含镜像拉取、进程加载、配置同步和健康检查，它必须小于预测窗口。
- 缓冲比例：不是一个固定数字，而应该随时段、事件类型（例如版本更新和限时活动）和最近的预测误差动态调整。
在开服或大型更新的窗口内，所有这些参数都会更难估，因为没有可对照的历史模式，此时保守策略往往更合理，而不是激进地压缩冗余。这部分在《新版本上线当天服务器该提前开多少？九游会AI如何预测突发玩家流量》里单独讨论。
反过来说，如果预测太保守，就等于回到“长期保持大量空闲算力”的老办法。所以合理的做法是分级：对影响玩家体验的路径宁可多留，对后台任务和低敏感度服务大胆合并，并且要把“当时为什么没有合并”记录下来，方便复盘。
九游会当前的处理思路与技术边界
九游会AI在这个问题上的设计取向是先看清楚、再谈动手。它读取的输入包括各实例的 CPU、内存、GPU、网络指标，按项目里配置的服务器区域和游戏模式聚合的在线人数，以及实例的冷启动时间。输出的是对每一类机器的建议：合并、休眠、保留热备还是延迟，并给出估算的功率变化区间。是否真的执行，仍然需要运营人员确认，或者经过规则约束与模拟验证之后才交给调度系统，具体的层次划分见后面讨论“建议—模拟—执行”的文章。
几个诚实的边界需要说清楚：
- 如果没有机器级的功率读数，只有利用率，九游会AI给出的节电估算只是模型值，需要用实测电表或云服务商提供的能耗数据校准。
- 多租户环境里，一台物理机上的多个虚拟机功率如何拆分，本身存在分摊口径的争议。
- 休眠和唤醒本身会消耗电力，也会带来硬件应力；频繁切换的机器未必省电。
- 目前不能声称任何具体的节电比例，这些比例只在接入真实数据并按项目校准之后才有意义。
省了电，不一定少了碳
还有一条容易被混淆：以上讨论的是节能（Energy Efficiency），也就是少用多少 kWh。减碳（Carbon Efficiency）还取决于这些电是在哪里、什么时候用的。假设两个机房各自节省 1kWh，一个所在电网煤电比例高，另一个所在电网水电或风电比例高，两者减掉的排放并不相同，更何况休眠机器减少的其实是边际电力，边际排放因子和平均排放因子也可能不同。站内《九游会官网为什么不把“节能”和“低碳”画等号？同样少用1度电，减排效果可能完全不同》一文对此有专门解释。
因此，一套完整的空闲算力分析，最后应该同时给出两个数字：功率或电量的变化，以及按对应区域排放因子换算的碳排变化，并注明各自的不确定性范围。
不该轻易下的几个结论
最后列出几种典型的误判，方便在读监控时自查。
- “平均利用率低，所以可以关机”：平均值会掩盖尖峰，一个每天晚上八点涨三倍的服务，用日均值看永远是空闲的。
- “合并后利用率提高，所以一定更省电”：如果合并后的机器进入了功率曲线陡峭的区间、触发降频或更高的风扇转速，收益会低于预期。
- “GPU 没有在满载，所以可以拿去做别的”：共享 GPU 会引入干扰，影响渲染或编码的帧时间稳定性，实时业务往往不能这么做。
- “PUE 低，所以空闲不重要”：PUE 低只能说明每一度 IT 用电对应的设施开销小，没产出的 IT 用电本身依然是浪费。
在线并不等于满载，两者之间有大量空间。把这段空间量出来、分类、留出足够的安全边界，再决定是省电还是省碳，才是九游会看待空闲算力的基本方式。
