先做一个思想实验。某运营团队手里有两个区域的机房，甲机房PUE很漂亮，乙机房PUE一般。有人提议：既然甲更“高效”，就把乙机房上的游戏服务器全部迁过去。这个提议在表格上很好看，但一落到真实运营，会立刻碰到三个问题：甲机房离一部分玩家太远，往返延迟撑不住实时对战；甲所在地区的电网碳强度可能比乙高很多；甲机房的GPU和CPU本来就跑得很满，再塞进去只会排队。PUE低是好事，可它只是多目标问题里的一个数字，不是答案。
PUE到底量了什么，又没量什么
PUE（Power Usage Effectiveness）的定义很直白：数据中心总设施能耗除以IT设备能耗，数值不会小于1.0。分子里除了服务器、存储和网络设备，还包括制冷、配电损耗、照明等设施开销。所以PUE反映的是“送到IT设备的每1度电，机房自己要多花多少”。ISO/IEC 30134系列把它作为数据中心关键性能指标之一，该系列里另有专门的可再生能源因子（REF）来表达电力来源，这本身就说明PUE不承担“电从哪来”的职责。
2025年一篇讨论云基础设施的论文（xPUE）也直接列出了PUE的几条局限：它不区分工作负载差异，不反映服务器利用率，不体现各地气候对制冷的影响，也不衡量机房实际完成了多少计算。换句话说，PUE量的是“外壳”的效率，不是“里面的机器在干什么”。此外还有口径问题：用瞬时值、月均值还是年均值，IT能耗在哪一级配电处计量，都会让同一个机房算出不同的数字，跨机房对比时必须先确认口径一致。
结论只有两句：PUE低说明设施开销小，不说明电是低碳的，也不说明IT负载本身高效。要把这三件事分开看，后面才谈得上调度。
一个模拟示例：PUE更高的机房，碳排可能更低
假设同一批离线任务需要IT设备用电100 kWh，可以放在甲或乙。甲机房PUE为1.15，所在电网的平均碳强度设为600 gCO2/kWh；乙机房PUE为1.35，所在电网设为150 gCO2/kWh。
| 机房 | PUE | 总用电（kWh） | 碳强度（gCO2/kWh） | 碳排（kg CO2） |
|---|---|---|---|---|
| 甲（示意） | 1.15 | 115 | 600 | 69 |
| 乙（示意） | 1.35 | 135 | 150 | 20.25 |
乙机房多用了20 kWh，碳排却只有甲的三分之一左右。这就是九游会在内容里反复强调“Energy Efficiency 与 Carbon Efficiency 不是一回事”的原因：少耗电不等于少碳排。反过来，如果乙的电网碳强度也是600，那乙就是纯粹的输家。所以碳强度这一列必须有数据，而且要知道它用的是平均值还是边际值——这两者对调度结论的影响在数据中心PUE很好看，为什么整体碳排还是可能很高里有更完整的推演。
IT侧的效率：同样的电，做了多少事
PUE把分母当作既定事实，可分母里恰恰藏着最大的弹性。一台GPU服务器开着，功率并不会随任务量线性下降，低负载时依然要付出相当比例的基础功耗；GPU利用率高，也不代表每个任务花的电少，可能只是任务在排队等显存，或者在跑低效的批大小。判断IT侧的效率，要同时看吞吐量和每任务能耗，也就是Performance per Watt这个思路，关于“GPU利用率高就一定节能吗”这类误判，九游会在数据中心栏目里专门写过。
放到调度里，含义很具体：把任务合并到更少的机器上，可以让空转的机器休眠，但合并过头会推高尾延迟；把渲染或推理任务放到更高效的GPU代际上，每玩家小时的电量可能明显下降，即便这个机房的PUE并不突出。因此多目标调度里，IT能耗不是常数，而是调度本身要优化的对象。
网络和延迟：把距离当成成本，而不是备注
实时游戏的第一约束是玩家感受到的延迟与抖动。玩家到机房的物理距离、途中的路由跳数、拥塞和运营商互联点，共同决定往返时间。这个约束通常以SLA或QoS目标的形式写下来，例如“某区域玩家到对战服务器的往返延迟的第95百分位不超过某个阈值”，阈值随游戏类型差别很大，动作类和回合类的要求完全不同。
距离对能耗也有影响：数据要穿过更多网络设备和更长的链路。但网络传输的“每GB能耗”估算在学界分歧很大，不同研究的假设、口径和年代差别明显，所以九游会的做法是：延迟当作硬约束处理，网络能耗当作需要标注不确定区间的软目标，而不是拿一个看似精确的每GB数字去做迁移决策。这一点在评估视频编码和CDN分发时同样适用。
先分类，再谈优化：不是所有负载都值得多目标
多目标优化的第一步常常被跳过：先把负载按“能不能动”分开。
- 实时对战与房间服务：受玩家位置和延迟约束，区域基本固定，能优化的主要是同区域内的实例数量、打包密度和空闲实例的休眠策略。
- 准实时服务：匹配、排行榜、社交、部分反作弊检测，对秒级延迟不敏感但不能停，可以在区域内或邻近区域内调整。
- 可延迟与可迁移的非实时任务：日志分析、资产处理、补丁构建、AI推理批处理、内容生成、模型训练。它们对完成时间只有截止期要求，可以按碳强度、电价、机房空闲容量选择时间和地点。
绝大多数“搬到低碳区域”的收益，来自第三类，而不是第一类。这也是游戏服务器能不能跟着可再生能源“迁移”里的核心判断：实时游戏与后台任务的答案完全不同，混在一起讨论只会得出含糊的结论。
把目标写成问题：约束、目标与权重
一个可操作的写法是把“必须满足的”和“希望更好的”分开。必须满足的：各区域延迟SLA、机房可用容量与功率上限、热备冗余、数据驻留与合规要求、任务截止期。希望更好的：总能耗、碳排放、电费、网络传输量，有时还有用水。前者写成约束，后者写成目标，剩下的才是权衡。
权衡有两种常见做法：把多个目标加权成一个数，或者先固定其中一个目标的上限（比如碳预算或成本上限），再优化另一个，观察帕累托前沿上的取舍点。无论哪种，权重或预算不是数学推出来的，而是运营方的选择——愿意为少1%的碳多付多少钱，愿意让离线任务晚几个小时完成，这些需要业务和能源团队一起确认。九游会的设计取向是把这些权衡摆出来让人看见，而不是藏在一个“综合评分”里。
公开研究已经在往这个方向走。2026年5月，作者来自多家机构、在arXiv发表的一篇论文，把训练任务调度、可弹性路由的推理负载、本地发电与电池储能、电网双向交互和碳排放放进同一个混合整数线性规划里联合优化，约束涵盖延迟、连续性、功率平衡和碳预算；在合成实例上，比只优化算力或只优化能源的基线运营收益更高、排放更低。需要谨慎的是，这是合成实例的实验，不能当作真实数据中心的实测节能比例。2025年10月的另一项工作DCcluster-Opt则提供了开源仿真基准，把AI负载轨迹、电网碳强度、电价、多地区天气和网络延迟放进同一个环境，让调度智能体在碳排、能耗成本、SLA和用水之间取舍。关于这类“算力、网络、电力一起优化”的研究趋势，可以对照算力、网络和电力开始一起优化：九游会观察下一代数据中心调度模型。
九游会AI目前怎么处理，以及边界在哪
在九游会数据中心AI的设计里，调度问题被拆成几步：读取各区域的容量、利用率、PUE趋势、电价和碳强度预测，读取玩家在线分布与延迟测量，先按上面的分类划出可移动的负载，再在约束内给出若干候选方案，同时标出每个方案在延迟、能耗、碳排、成本上的差异。方案交给模拟环境检验容量和延迟影响，然后由运营人员确认。目前九游会大模型不直接改动真实的生产调度，这一点是设计上的有意为之：基础设施的错误动作代价太高，需要人和模拟环节把关。
另外要诚实地说明几件目前做不到、或不该期待的事：不会承诺具体的节能或减碳比例，因为这取决于每个项目自己的机房、电网和负载结构；不会因为某个机房PUE低就自动建议迁入；也不会为了压低碳排而牺牲实时对战的延迟底线。
结论什么时候会错
多目标调度的输出，比单指标更容易“看起来很严谨”，所以更需要列出失效条件。
- 碳强度预测偏差：预测的是未来几小时的电网结构，风光出力预报不准、机组检修、跨区输电变化都会让预测出错。用平均碳强度还是边际碳强度，会得出不同的“最优时段”。
- PUE不是常数：机房负载低时固定开销占比上升，PUE往往变差；夏季与冬季制冷负担不同。迁入大量任务后，目标机房的实际PUE可能与历史均值不同。
- 迁移本身的成本：数据搬运、镜像拉取、缓存重建都要耗电、耗时，任务很小的话，迁移的开销可能超过收益。
- 容量竞争：多个团队或多个调度器同时追逐同一个“低碳窗口”，会把窗口挤满，反而抬高该时段的实际碳强度和排队时间。
- 延迟测量的代表性：用平均延迟做决策会掩盖尾部玩家的体验；要看分位数和分区域、分运营商的数据。
- 合规与数据驻留：部分玩家数据不能跨区域处理，这类约束不在能源数据里，必须来自业务侧。
因此，比较稳妥的做法是：先用模拟数据和历史回放检验调度规则，再小范围灰度，并持续对比预测与实际的差距。把一个机房的PUE降下来很有价值，但它是工作的起点，不是终点；下一代绿色游戏基础设施需要的，是在延迟、容量、碳排、成本这些互相拉扯的目标之间，给出可以解释的取舍。跨地区选择时的细节，可继续参考同一局游戏放在两个地区运行，碳排放为什么可能完全不同。
