晚上八点，在线人数曲线爬上去，运维的第一反应往往是多开机器。这个反应在体验上没错，在效率上却常常是错的：真正让服务器紧张的，不是“人多”这个结果，而是人数上升的速度超过了新实例的启动速度。反过来，为了不被这个速度差咬到，很多团队选择白天就把机器留好，于是低峰时段服务器一直在低利用率里空转。九游会AI在绿色运营里要处理的，正是这段长期空闲的算力，而不是靠压缩机器数量去换电费。
在线人数不等于负载：先弄清楚服务器到底在忙什么
同样是一万人在线，压力可以差很多。一万人挤在大厅、商城和好友列表里，压力主要落在无状态的接口服务和数据库上；一万人分散在几千个对战房间里，压力落在游戏服务器实例的 CPU 和网络收发上；如果其中还有大量玩家在同一时刻进入匹配队列，撮合服务的计算量又会陡增。所以负载预测的对象不应该只是“在线人数”这一条曲线，而应该拆成登录速率、匹配队列长度、活跃房间数、每房间平均 tick 开销、出口带宽这几层。
拆开以后还有一个好处：不同层的伸缩速度不一样。无状态接口层可以几十秒扩容，游戏房间实例可能要几分钟，带状态的数据库分片则几乎不可能临时扩。预测模型对每一层要给出各自的提前量，而不是一个统一的“服务器数量”。
为什么传统做法会留下长期空闲
传统的容量规划是按峰值反推：历史最高并发乘一个安全系数，再加上一个“万一活动更火”的余量。这个做法的逻辑很稳，因为卡顿的代价直接体现在玩家流失和客诉上，而闲置机器的代价只是一笔看不太见的电费与云账单。问题在于，这个安全余量被固定在了全天候，而不是随时间变化的。
另一个原因是冷启动时间。如果一个实例从申请到能接客要几分钟，甚至包含拉取镜像、加载地图与配置、预热缓存，那么“看到人多了再开”就来不及，只能提前开。提前多久、开多少，本质上是预测问题；在没有预测的时候，人们只能用“一直开着”来回答。九游会绿色运营把这件事写成一个可以被检验的指标：不同时段的服务器利用率与被拒绝、被排队的玩家比例，一起看，缺一不可。
预测需要读哪些信号
只用历史在线人数，能学到日内和周内的节律，但学不到“下周三有版本更新”。实际能提高预测质量的信号大致有几类：
- 时间结构：小时、星期、地区所在时区、法定节假日与学校假期；
- 内容日程：版本更新、新赛季、限时活动、联动内容上线、赛事直播时间；
- 上游流量：预约人数、补丁下载量、官网访问与推送触达量，这些往往先于在线人数上升；
- 系统状态：当前登录速率、匹配队列、各区服的房间数，这是最短期预测最可靠的输入。
信号多不等于越多越好。每加一个信号，就多一个可能缺失或延迟的数据源，预测系统必须能在某个信号缺失时降级，而不是整个失灵。
预测要看多远：从冷启动时间倒推
预测窗口不是拍脑袋定的。假设一类游戏房间实例从触发到可接客需要三分钟，再加上决策周期一分钟，那么模型至少要看到四分钟以后，才有意义；再往后看的部分用来做更长的容量安排，比如是否提前把一批预热实例保持在待命状态，或者是否要在凌晨把区域的基础实例数调低。
所以更合理的结构是两层：几分钟尺度的短期预测负责实例的增减，几小时到一天尺度的中期预测负责基线容量与预热池大小。两层的误差来源也不同：短期误差主要来自随机波动，中期误差主要来自“有没有把日程与事件考虑进来”。
| 时段（模拟） | 预测并发区间 | 固定峰值配置的实例数 | 按预测配置的实例数 |
|---|---|---|---|
| 凌晨低谷 | 2万–3万 | 100 | 约 30 |
| 午后平峰 | 5万–7万 | 100 | 约 60 |
| 晚高峰 | 9万–11万 | 100 | 约 100 |
| 新版本上线夜 | 13万–18万 | 100 | 约 150，含预热池 |
这个示意表里有两点值得注意：晚高峰时按预测配置并不比固定配置少，节省几乎全部来自低谷与平峰；而新版本上线夜，固定配置反而不够，需要的是更大的预热池，而不是更少的机器。所谓“绿色”，不是把曲线整体压下去，而是让配置去贴近曲线。
缓冲比例与兜底：预测一定会错，问题是错了以后怎么办
任何预测都有误差，所以输出应当是区间而不是单点值。配置实例数时，参考的是区间上沿，而缓冲比例则由近期的误差决定：最近一周预测偏低的次数多，缓冲就调高；模型表现稳定，缓冲可以收紧。这样缓冲比例是一个会随证据变化的量，而不是一个永远不动的“保险系数”。
几种常见的兜底做法：
- 扩容快、缩容慢：扩容触发条件宽松，缩容要求连续多个周期都低于阈值，避免在波动上反复开关；
- 预热池：保持一小批已经加载完毕的实例待命，遇到突发时先顶上，再由正常扩容补位；
- 排队与限流：当登录速率超过承载能力，宁可让玩家看到明确的排队提示，也不要让所有人一起卡；
- 回退规则：模型输入缺失或输出异常时，自动切回基于当前指标的规则伸缩，并通知运营人员。
需要强调的是，实时对战服务器优先保证的是延迟与服务水平。在这一层，任何“为了少开机器”而挤占缓冲的做法，都不属于九游会绿色运营的思路。
预测在哪些情况下不能相信
第一是新游戏或新区服，没有历史，模型只能靠相近产品的经验与人工设定，误差区间要放得很宽。第二是外部故障之后的集中回流：平台或网络故障恢复的一瞬间，玩家同时涌回，这种曲线在历史里很少见，模型往往严重低估。第三是玩家行为改变，比如某个玩法调整后，单房间人数与时长分布变了，旧模型的假设就不再成立，这类模型漂移需要靠持续对比预测与实际来发现。第四是数据延迟：如果在线人数指标本身晚了一分钟，那么再好的模型也是在看过去。
所以在方案里，预测模型不是唯一决策者，它的输出会被容量上限、最小实例数和人工审批阈值共同约束。这些边界本身就是设计的一部分。
从“少开实例”到“少耗电”，中间还隔着几步
把一个虚拟实例关掉，账单上的实例小时确实少了，但物理机未必因此少耗电。如果同一台服务器上只是少了几个实例，它可能依然在低利用率下运转，而空闲状态的功耗并不接近零：公开研究反复讨论过服务器空闲功耗占峰值比例这个问题，不同年代、不同型号差别很大，结论是空闲不等于不耗电。只有把留下来的实例合并到更少的机器上，再让空出来的机器进入低功耗状态或被其他任务占用，节省才真正落地。这一段的细节在玩家已经下线，服务器为什么还在耗电里展开，更底层的功率与利用率关系可以看服务器利用率只有20%，电费会不会只剩20%。
另外必须区分：节能与减碳不是一回事。少用一度电，减少的碳排放取决于当时当地的电网碳强度；把可延迟的批处理任务移到低碳时段，可能降低碳排而并没有降低耗电。对实时游戏而言，位置由玩家决定，主要的空间是“别在低谷时段空转”；对日志分析、补丁构建这类非实时任务，则可以进一步考虑时间和区域。
九游会目前的处理思路与边界
九游会AI在这件事上的当前思路，可以概括为：先把预测做成可解释、可回放的东西，让运营人员能看到“为什么预测今晚要提前开这些机器”，再逐步让系统给出扩缩容建议。预测负责回答未来负载，调度负责回答机器怎么摆，两件事分开，是因为它们的错法不一样。更宏观地说，容量调度还要同时看延迟、区域容量与设施效率，这部分放在游戏数据中心为什么不能只追求最低PUE中讨论。
这里也要诚实说明目前做不到的部分：模型无法预知突发的社交事件，不能替代对新版本的人工评估，也不能保证在任何情况下都不排队。九游会不会给出“一定节能百分之几”的承诺，因为这个数字取决于游戏的负载形态、实例启动速度、机房的硬件与电力结构。想了解更多同类内容，可以到九游会绿色运营栏目里按主题浏览。
怎么判断体验没有因此变差
省算力的方案最容易在“平均值”上显得漂亮：平均延迟没变，平均利用率上去了。但玩家感受到的是尾部：晚高峰前十分钟的匹配等待、某个区服的短暂丢包、进入房间时多出来的两三秒。因此评估动态扩缩容，至少要同时盯住几组指标：匹配等待时间的高分位数（例如 P95）、房间创建失败率、实例启动到可用的耗时分布、各区服的延迟高分位，以及登录排队的发生次数。如果这些指标在启用预测前后没有恶化，才可以说节省是“有效的”；一旦有恶化，就应该先收紧缩容、放大缓冲，而不是先怪玩家网络。
另外一个常被忽略的细节是缩容的方式。实例上仍有对局时不能直接终止，需要先停止接收新房间、等当前对局自然结束再回收。这个“排空”过程本身也需要时间，会让缩容比扩容更慢，这也是前面强调“扩容快、缩容慢”的现实原因。
如果要自己评估：四个先问的问题
- 一台游戏实例从触发到可接客要多久？这决定了预测至少要看多远。
- 过去一个月，被排队或被拒绝的玩家比例是多少？先确认“保守”的代价有多大，再谈缩减。
- 低谷时段的服务器平均利用率是多少？如果本来就不低，空间不大。
- 缩下来的机器，有没有真的被合并或进入低功耗状态？否则省下的只是账面上的实例。
这四个问题回答完，预测是否值得做，通常就比较清楚了。省电这件事要落在体验不受损的前提上，才算得上运营，而不是一次性的压缩。
