九游会绿色运营：让游戏算力跟着玩家需求动态变化

游戏服务器最容易被忽略的浪费，不是玩家太多时的高功率，而是玩家已经散去、机器却仍按高峰配置待命的那几个小时。九游会绿色运营这个栏目，讨论的就是这类具体问题：算力该在什么时候开、开多少、什么时候可以放心地收，以及收的时候怎样不让玩家察觉到卡顿。

我们的出发点很朴素：绿色运营不等于少开服务器，而是在体验稳定的前提下，让长期空闲的那部分算力尽量少。下面按一条运营链路来讲，从玩家需求一路讲到服务器、预测、调度和节能核算，并说明每一步在什么情况下会出错。

从玩家需求出发，而不是从机器数量出发

传统容量规划常常把“机器数量”当成起点：历史上最高峰有多少人，就按那个数字再加一层保险去保留实例。这样做稳，但代价是低峰期利用率长期偏低，而机器不管有没有人玩，都在持续消耗电力。

九游会绿色运营的思路正相反，先把玩家需求拆开看：在线人数只是总量，真正决定负载的还有地区分布、游戏模式、对局长度、匹配队列长度和大厅与战斗服务器的比例。同样是一万人在线，如果大多数人挂在大厅里，与大多数人处于战斗中，对服务器 CPU 的压力可以差很多。需求画像越细，后面的预测才越有意义。

需求画像还要记录“玩家为什么在这个时间上线”。工作日晚上的自然高峰、周末午后的长对局、版本更新后的回流、赛事直播带来的临时涌入，它们的形状和持续时间都不同：自然高峰爬升平缓，赛事带来的涌入则可能在几分钟内出现。把这些原因标注进历史数据，模型才能在下一次类似事件到来之前，给出更有依据的估计，而不是把所有波动都当成随机噪声。

服务器负载：在线不等于满载

“服务器在线”和“服务器在干活”是两回事。一台机器即使几乎没有请求，也会消耗一部分基础功率，这部分通常叫空闲功率（Idle Power）。举一个模拟示例：假设某台服务器满载时功率为 1，空闲时并不是 0.2，而可能仍有相当一部分，具体比例取决于硬件世代和电源管理设置，这里的数字只是帮助理解，不代表任何真实设备的测量结果。

这带来一个反直觉的结论：把负载平均摊在许多台低利用率的机器上，往往比集中到较少的机器上更耗电。相关的机制，我们在服务器利用率只有20%，电费会不会只剩20%里专门展开讲过，包括 CPU 与 GPU 各自的空闲功耗特性。

用预测替代冗余：并发预测与 Autoscaling

把冗余换成预测，需要一个能回答“未来几分钟到几小时需要多少实例”的模型。输入通常包括历史在线人数、星期与节假日、版本更新与活动日程、地区时区，以及最近几分钟的增长斜率。晚上玩家多就一定要多开服务器吗详细讲了这条预测链路，以及为什么预测输出要带一个区间，而不是一个点。

预测一定有误差，所以 Autoscaling 里必须留缓冲。缓冲比例取决于三件事：预测误差的分布、实例冷启动所需时间、以及人数爬升速度。冷启动越慢，就越需要提前扩；预测越不稳，缓冲就越厚。九游会目前的设计取向，是让缓冲比例随近期预测误差自动调整，而不是写成一个固定的常数。

版本上线与活动日：最不能靠平均值

新版本上线当天是最容易出事的时间点：历史数据里没有完全相同的先例，玩家可能在开服后几分钟内集中涌入。这时平均意义上的预测几乎没用，需要把宣发节奏、预下载完成率、预约人数等外部信号一起纳入，并且提前做压测。新版本上线当天服务器该提前开多少专门讨论了这类场景，也讲了兜底策略，比如排队限流、分区开放和预热池。

这里要坦白一点：突发场景下，省电的优先级低于稳定。宁可上线当天多开一些，也不要为了节能让登录排队变成事故。绿色运营的收益主要来自其余的绝大多数日子，而不是这一天。

低峰期：合并、休眠和热备的取舍

玩家下线之后，服务器该怎么办，答案并不统一。有的实例可以合并对局后关闭，有的进入低功耗状态，有的则必须保持热备，因为下一波玩家的涌入可能比模型预期的更早到来。玩家已经下线，服务器为什么还在耗电把这几类实例的判断条件列得更细，包括休眠唤醒时间、状态数据是否需要迁移、以及对局收尾的排空（drain）流程。

关机也不是免费的：频繁启停会带来额外的初始化能耗与缓存失效，唤醒时间过长还会让预测的误差被放大。所以是否值得关，要看这台机器预计空闲多久，而不是一律关。

比较稳妥的顺序通常是先合并、再降频、最后才休眠或关闭：先把分散在多台机器上的低负载对局合并，让部分机器腾空；对腾空的机器先启用电源管理与降频，观察一段时间没有回涌，再决定是否进入更深的休眠状态。热备实例则按区域和游戏模式保留最小数量，数量本身也由预测给出，而不是凭经验拍板。

可延迟任务的低碳窗口

不是所有算力都需要即时响应。日志分析、数据统计、资产处理、补丁构建和模型训练，这类非实时任务往往可以推迟几个小时，放到电网碳强度更低的时段，或者放到本来就闲着的机器上。凌晨任务一定要凌晨跑吗讲的正是这种“计算窗口”的选法：约束是截止时间、数据位置和成本，目标是尽量落在低碳或低负载的时段。

要提醒的是，这里说的是碳，而不是电量。把任务挪到低碳时段，总耗电可能不变甚至略增，但碳排放可能下降。反过来，少耗电也不一定少排碳。我们始终把能耗效率（Energy Efficiency）和碳效率（Carbon Efficiency）分开计量，避免用其中一个去代替另一个。

体验红线：什么不能为了节能而动

实时对战服务器主要受延迟与 SLA 约束，玩家位置、网络路径和匹配质量比省电优先得多。九游会绿色运营不打算把实时对战迁到远离玩家的低碳地区，那样只会让延迟升高、丢包和重连变多，也会让网络传输本身耗更多电。可以动的，是大厅之外的后台服务、非实时批处理和预留容量的配置方式。

此外，每一次自动缩容都应该有可回滚的保护条件，比如关键指标恶化时立即恢复实例、限制单次缩容的幅度，以及对新版本、活动期间冻结缩容。这些保护写不进漂亮的节能数字里，却决定了系统敢不敢真正启用。

还有一类边界是玩家感知：缩容期间如果匹配时间变长、跨区匹配变多，玩家不会关心后台省了多少电，只会觉得游戏变差了。因此绿色运营的指标里，除了利用率、电量和碳强度，还应同时盯着匹配等待时间、对局延迟分布和掉线率。任何一项明显恶化，都应视为这次调整失败，而不是“为节能付出的合理代价”。

怎么核算节能：别把口径混掉

核算节能时最常见的错误，是把功率（kW）和电量（kWh）混着用，或者把不同系统边界的结果放在一起比。功率是瞬时值，电量是功率随时间的积分；一台机器开关的时刻不同，功率曲线看起来差别不大，累计电量却可能差很多。

数据中心层面还有 PUE：PUE 等于设施总能耗除以 IT 设备能耗，反映的是设施效率，并不说明电力是否低碳，也不说明 IT 负载本身是否高效。减少服务器空转，改善的是 IT 侧的电量；再乘上 PUE，才是设施层的总电量；再乘上区域和时段的碳强度，才是碳排放。这三步任何一步缺失，得出的“节能比例”都需要谨慎对待。九游会的做法，是把每一步的数据来源和假设明确标注在报告里。

九游会绿色运营目前能做什么，不能做什么

目前的设计取向是：读取在线人数、实例数量、CPU 与 GPU 利用率和区域信息，生成负载预测与扩缩容建议，并对可延迟任务给出候选的运行窗口。建议在真正执行前，可以先在模拟环境里评估延迟与容量影响，再由运营人员确认。

它不能替代压测，也不能保证每一次预测都准确；对没有历史数据的新游戏、新地区、新活动，模型给出的区间会很宽，此时更应该依靠人工经验。如果你想了解这些能力如何接入整套流程，可以参阅九游会数据中心AI栏目里对区域与算力调度的讨论，以及九游会碳足迹AI对排放核算口径的说明。