凌晨三点，在线人数只剩白天的几分之一，机房里的风扇声却几乎没有变小。这不是错觉。低峰期的耗电由好几层叠在一起：还在运行的实例、跑着但几乎没事干的物理机、始终要保持在线的热备和基础服务、以及不管负载多低都要运转的网络与制冷。玩家下线只减少了最上面一层，下面几层需要另外去处理。以下按“从上往下”的顺序逐层看，每一层的电为什么还在，能不能动。
第一层：实例关掉了，底下的物理机没关
云上的“实例数量”和机房里的“通电机器”是两个概念。缩容时被回收的是虚拟实例或容器，如果物理机上原本跑了十个实例，回收了六个，这台机器仍然通着电，只是负载更低。物理机在低利用率下的功耗，并不与利用率成正比：它有一段不随负载变化的基础功耗，来自主板、内存、风扇、电源转换损耗、网卡以及处理器的待机状态。公开研究反复讨论过“能源比例性”，也就是功耗能否随负载线性下降，结论是不同年代、不同型号差异很大，但空闲时并不接近零。所以从账单上看，实例小时下降了，机房的电量未必等比例下降。
要让节省落地，必须让空出来的机器真的变成“空”的：要么进入低功耗状态，要么被别的任务占用。前者靠合并，后者靠把可延迟的任务安排进去。
第二层：合并任务，把“十台各跑一点”变成“三台跑满、七台休息”
实例合并（Instance Consolidation）的思路很简单：低峰时段，把分散在多台机器上的小负载重新打包到更少的机器上，让被腾空的机器休息。困难在细节里：
- 迁移成本：有状态的游戏房间不能随意迁移，通常要等当前对局结束，再决定新房间放在哪；
- 资源形状：CPU、内存、网络、GPU 需求不同，一台机器“CPU 空了”不代表“能装下”一个内存大户；
- 隔离与故障域：合并太狠，一台机器出问题影响面更大，需要在效率和可靠性之间保留余量；
- 延迟约束：实时对战必须放在离玩家足够近的区域，不能为了合并而跨地区搬。
因此合并首先发生在“可以自由摆放”的负载上：后台服务、匹配以外的辅助服务、批处理队列、测试环境。对战服务器主要依靠“新房间怎么放”这个入口做温和的收敛，而不是强行迁移进行中的对局。
第三层：哪些机器必须醒着
不是所有空闲机器都能休息，至少有四类要保持在线：
- 热备：用来在主机器故障或突发时立刻接手，如果关掉，故障恢复时间就会拉长；
- 预热池：为下一个高峰提前准备的实例，如果全部回收，早晨的第一波玩家就要等；
- 区域最小容量：某些地区在低谷时段仍有玩家，且延迟要求严格，需要保持最小容量；
- 有状态服务：数据库、缓存、消息队列，它们的启动与预热成本较高，缩小规模的风险也更大。
这几类机器是“该醒着”的部分。九游会AI的做法是给每一类设置最小值和唤醒条件，而不是让模型自由决定关多少。这样即便预测出错，最坏也只是“少省了一点”，而不是“该有的机器不在”。
第四层：低功耗状态不是开关，唤醒有代价
服务器可以进入不同深度的睡眠或低功耗状态：浅一些的状态唤醒快、省得少，深一些的唤醒慢、省得多。深度休眠的唤醒时间可能从几十秒到几分钟不等，具体取决于硬件、固件和虚拟化层的支持，此外还要考虑恢复后需要重新加入调度、重新拉取镜像和预热缓存。
所以决策不只是“关不关”，而是“能不能在下一个高峰到来之前回来”。这与前面讲过的预测紧密相关：如果模型可以可靠地告诉你，未来三个小时不会有大规模上升，就可以让一批机器进入较深的状态；如果预测不可靠，只能用较浅的状态或者干脆保持待命。另外频繁开关本身也有硬件损耗与稳定性风险，需要设置最小休眠时长，避免在阈值附近来回抖动。
第五层：GPU 空闲，与 CPU 空闲不是一回事
对使用 GPU 的服务，例如云渲染、AI 推理或视频编码，空闲功耗的情况又有所不同。GPU 即使没有任务，也会维持一定的待机功耗；显存里还驻留着模型或渲染资源，卸载再加载的成本不低。把一张 GPU 从“低利用率”变成“休眠”，需要同时考虑模型重新加载的时间、是否影响其他租户以及夜间是否有批处理任务能把它用起来。关于 GPU 利用率和每任务能耗的关系，GPU利用率高就一定节能吗中有更细的讨论。
第六层：电表里还有不随机器休眠而消失的部分
即使机器休眠了，机房里仍有一些固定开销：交换机与路由设备的基础功耗、存储阵列、UPS 与配电损耗、以及制冷系统。制冷的耗电与实际热负载相关，热负载下降，制冷可以随之降低，但冷水机组、风机在低负载下的效率通常也会变差，这是“设施效率”问题。设施层的效率常用 PUE 来衡量，它是数据中心总设施能耗与 IT 设备能耗之比；但要提醒的是，PUE 只说明设施本身多高效，既不反映 IT 负载本身是否高效，也不反映所用电力是否低碳。
因此，只有当低峰期真正减少了 IT 设备的通电数量，同时制冷系统也随之调整，整体的节能才会成立，只关机器不管制冷，或者只调制冷不动 IT，收益都有限。
用一个模拟例子看看各层各占多少
假设某个区域低峰期有 10 台通用服务器，每台空闲时功率约为满载功率的一个较大比例（示意）。如果只是回收虚拟实例，这 10 台仍然通电，电量几乎不变；如果把可自由摆放的负载合并到 4 台，其余 6 台进入低功耗状态，IT 侧的用电会明显下降，但要留意唤醒时间与热备需求，实际能睡的可能只有 4 到 5 台；再加上制冷的相应调整，总设施电量才会跟着下降。这个例子想说明的是：电量下降是分阶段兑现的，任何一环缺失，都会让“下线了很多玩家”和“电表下降很多”之间出现落差。
另一种思路：让空出来的机器去做可延迟的活
合并之外，还有一个反方向的做法：不让机器睡，而是给它安排可延迟的任务，例如日志汇总、数据分析、资产处理和补丁构建。这样做提升了机器的利用率，但要注意这不等于减碳：如果这些任务本来可以放在低碳电力更多的时段或地区，把它们放在当地夜间的高碳电网上，可能并不划算。这一点会在凌晨任务一定要凌晨跑吗之类的文章里进一步说明。简单地说，低峰期的处理有两条路：一是把机器变少、变睡；二是给机器安排非实时的活。哪一条更好，取决于机器的空闲功耗、任务的可延迟程度、当地电网碳强度与延迟约束。
九游会目前怎么处理，以及做不到的部分
九游会AI在低峰期的当前思路，是先做“分类”，再做“动作”：把每台机器按角色分成必须在线、可合并、可休眠和可承接后台任务四类，再由调度模块提出建议，运营人员确认后执行，关键动作有最小容量与回滚保护。九游会绿色运营的目标不是每天把机器压到最少，而是让“没人玩”的时候，电用在必须用的地方。这个过程也需要与前面提到的玩家并发预测配合，因为休眠深度取决于预测有多可靠。
需要坦率说明几点边界：第一，目前没有一个适用所有硬件的休眠策略，不同机型和固件差别很大；第二，对使用虚拟化或托管云的团队来说，物理机层面并不总是可控，能做的可能只是通过实例选型和合并影响云厂商的资源占用；第三，任何低功耗动作都不应该以牺牲实时对战的延迟与服务水平为代价；第四，节能与减碳是两件事，少用一度电，碳排放减少多少，还要看当时当地电网的碳强度。
下次遇到“下线了电费却没降”，可以先查这五件事
- 被回收的是虚拟实例还是物理机通电数量？
- 低峰期物理机的平均利用率是多少，有没有大量“十台各跑一点”？
- 热备、预热池和区域最小容量各占多少，是否设置合理？
- 低功耗状态的唤醒时间，是否小于预测能够可靠给出的提前量？
- 制冷与配电是否随着 IT 负载一起调整？
五个问题里，前两个通常最能解释“为什么没降”，后三个决定“能降多少、降了以后安不安全”。
