云游戏节能为什么不能只盯GPU？九游会AI开始同时计算渲染、编码、网络和终端

假设某次优化让云端GPU的渲染负载下降了一成，服务器那一栏的用电账单确实变薄了。但这一成能不能算作云游戏整体节能，取决于另一个问题：为了保住画面质量，编码器有没有多花力气，网络有没有多传数据，玩家的终端有没有多做功。服务器少耗10%，并不等于整条链路少耗10%。九游会AI把渲染、编码、网络和终端放在同一张账里，出发点就在这里。

先回答：这笔账从哪里开始，到哪里为止

核算能耗的第一步不是测量，而是画边界。“一局云游戏的能耗”这句话，在不同人嘴里可能指完全不同的东西：只算云端服务器的功耗？加上机房的冷却与配电损耗？再加上把数据送到玩家家门口的网络设备？还是连玩家自己的路由器、终端和显示器也算进去？边界画得越宽，需要的数据越多，不确定性也越大，但结论越接近玩家的真实处境。边界画得越窄，数据越容易得到，可省下来的部分很可能被挪到了边界之外。

九游会AI采用的是最宽的一种画法：从游戏画面在云端被渲染的那一刻，到玩家眼前的显示器亮起为止，把中间每一个耗电环节都作为独立分项列出。这样做并不意味着每一项都能精确测得，而是保证任何一项优化，都必须回答“别处有没有反向增加”。这是一种记账习惯，不是一个已经算出来的数字。

用一个纯属示例的小算术看看边界的作用。假设一局游戏的整条链路能耗为100个相对单位，其中云端渲染40、编码10、机房冷却与闲置20、网络15、终端15。某项优化把渲染能耗降低了四分之一，也就是省下10个单位，如果只看渲染这一栏，这是一个漂亮的25%；可若为了保住画质，编码与网络合计增加了6个单位，终端多做功增加了2个单位，净节省只剩2个单位，占整条链路的2%。数字是虚构的，想说明的只是：账本怎么翻，决定了同一项优化被写成“节能四分之一”，还是“几乎持平”。

云端的三笔账：渲染、编码与机房

云端的第一笔账是GPU渲染。渲染档位越高，单帧耗时越长，GPU的占用与功耗随之上升，但两者并非简单的线性关系，还取决于GPU是否被充分利用：一块没有满载的GPU，闲置状态下的基础功耗依然存在，所以少渲染一点，节省的是可变的那部分，而不是整块卡的功耗。

第二笔账是视频编码。编码可以由GPU上的专用单元完成，也可以由CPU软件完成，两者的能耗特征很不一样。更高的压缩率意味着更少的数据，却常常需要更复杂的编码计算。一个只优化渲染的方案，如果让画面内容变得更“难压缩”，比如引入更多随机的高频噪点，就会把成本从渲染挪到编码和网络里。这是一种典型的“账面上看不见的转移”。

第三笔账是机房本身：冷却、配电、以及没有玩家时的闲置。云端服务器的功耗最终会变成热量，需要冷却系统带走，机房整体的效率通常用能效比来描述。闲置更容易被忽视：一台空转的服务器依然要耗电，如果机房里有很多低利用率的节点，那么平摊到每一局游戏上的“闲置成本”就会变高。这也是为什么服务器利用率与延迟必须放在一起考虑，相关取舍在边缘节点离玩家更近就一定更节能吗里有专门讨论。

网络这一段：谁的电，怎么摊

网络是最难算清的一段。数据从机房出发，要经过多层路由与交换设备，最后经运营商的接入网络到达玩家家里。这些设备同时承载着大量别的业务，并不专为某一局游戏运转，所以它们的耗电只能按流量或使用时间去分摊，这本身就是一个有争议的假设。分摊方法不同，结果可以差别很大。

即使分摊方式无法精确，趋势还是可以推理的：传输的数据越多，网络设备的负担越重；发生丢包和重传，等于同一份数据传了不止一遍。一个方案如果为了保住画质，把码率提高一截，或者因为网络不稳定引入更多的重传与前向纠错，网络这一段的“额外成本”会明显上升。反过来，如果在网络拥塞时让渲染与码率配合地降低，既避免了终端卡顿，也减少了无效数据。九游会AI要做的，是让渲染、编码、网络这几段的调整方向一致，而不是各自为政。

帧率与码率还会同时作用于三段。帧率越高，渲染要做的工作按比例增加，编码要处理的帧数增加，网络要传的数据也往往增加，终端解码与显示的工作量同样增加，一个帧率设定牵动整条链路。也正因如此，帧率预算不应当只是渲染团队的内部参数，它是一个需要各环节共同核算的决策。

终端这一头：解码、显示器和被忽略的部分

玩家一侧的能耗常常被写成“反正是玩家自己的电”，不进任何统计。但从整条链路的角度，这一段并不小。终端要解码视频流，硬件解码的效率高，软件解码则耗电、发热；显示器的亮度、刷新率与屏幕尺寸直接影响功耗，一块大屏电视点亮一小时的耗电，可能远远超过一部手机；再加上家里的路由器和光猫始终通电，这些设备的能耗，本来就是玩游戏这件事的一部分。

值得单独拿出来说的是本地游戏与云游戏的对比基准。如果玩家本来就要买一台高性能主机，那么制造这台主机的排放、它运行时的用电，也都要被放进对比。云游戏把一部分算力放到了云端，玩家终端可以更轻、更便宜，但如果终端因为软件解码而长时间高负载，这份“轻”就没有兑现。终端能力的差异如何影响云端的预算，可以参考手机、电视和高性能电脑为什么不该拿到同样的画面。

边界画法怎么改变结论：两份公开研究的启发

公开研究给了两个有启发的例子，说明系统边界怎么画会左右结论。第一个来自劳伦斯伯克利国家实验室（LBNL）的绿色游戏研究页面。据该页面，云游戏在数据中心与网络侧的额外用电，在最极端的情形下可达本地游戏的三倍。这是一项较早期的研究，其情景预测面向的是2016至2021年前后，并且它同时给出了不同云游戏普及程度的假设情景。它提醒人们：如果只看云端，云游戏可能显得很耗电，但结论强烈依赖于假设的普及率、利用率和电网结构，不能当作当前现状，也不能推广成“云游戏一定更耗电”。

第二个来自 Hazas 等人估算的 Hot Games 论文，该研究估算了2024至2025年全球电子游戏的排放，并把云游戏运行、PC制造、主机制造、显示器制造等分项列出。据其估算，硬件制造排放合计明显大于云游戏运行排放；这份估算不包括手机游戏，也不含回收处置阶段。如果把边界从“运行用电”扩大到“含制造”，讨论的重点就会转向设备寿命与更换频率，而不是数据中心的那几百瓦。

把两份研究放在一起，能得到一个朴素的结论：不同的边界，会得到不同的答案，都不算错，只是回答的问题不同。九游会不会用这两份研究去断言“云游戏更省”或“更费”，而是借它们提醒自己：任何节能主张，都要说明边界，并且允许别人在另一个边界下检验。

耗电不等于排放：时间和电网也要进账

还有一层容易混在一起：用电量与碳排放并不是同一个数。同样一度电，在以水电、风电为主的电网里对应的排放较低，在以煤电为主的电网里则较高；同一个机房，白天与深夜的电力来源构成也可能不同。这意味着两个相同能耗的方案，排放结果可能相差很大，把“节电”直接写成“减碳”并不严谨。九游会的方案里，能耗与排放是两列独立的数据：先把用电量算清，再在有可靠电网数据的前提下换算排放，没有可靠数据时，就只报告用电量，不报告排放。

时间维度同样重要。云游戏的负载有明显的峰谷，晚间高峰时机房利用率高，每一局游戏摊到的闲置成本较低；凌晨低谷时利用率低，同样一局游戏要承担更多的空转损耗。如果调度系统能在低谷期把负载集中到更少的节点，让其余节点休眠，账面上的整体能耗会下降，但这可能牺牲一部分延迟。什么时候该集中、什么时候该分散，本身就是一个需要在体验约束下求解的问题，不能靠单一指标一锤定音。

哪些能测，哪些只能估

把各段合在一起，还要面对一个现实：并非每一项都测得到。下面的表格是一份示例性的分项清单，用来说明测量思路，其中的可获得程度是设想，并非九游会的实测记录：

这张表里，越靠下的项目越依赖假设，也越容易引起争论。一种实际的处理办法，是给每个分项标注“实测”“折算”“假设”，并在结果里把这三种来源分开展示，而不是合成一个看起来很精确的总数。数据从哪里来、精度如何，本身就是结论的一部分。至于系统需要采集哪些数据、哪些不该采集，可以看绿色游戏大模型到底需要哪些数据。

一项优化要通过哪些关口，才配叫端到端节能

回到开头的问题。当一个团队宣布某种渲染或编码策略“节能”，可以用下面几个问题去检验，它们也是九游会内部对方案的自我审查清单：

• 体验有没有守住：延迟、卡顿、视觉质量是否仍在下限之上，玩家主观评价有没有变差。
• 码率和重传有没有反向增加：省下的渲染开销，是否被更高的码率、更多的重传抵消。
• 终端有没有被拖累：是否触发了软件解码、更高的发热或更快的电量消耗。
• 利用率有没有被考虑：节省的算力是真的被释放出来，还是只是让服务器空转得更多。
• 边界是否写明：结论适用于哪一段，数据是实测、折算还是假设。

这份清单没有给出“云游戏到底省多少电”的数字，因为在没有实测的前提下，任何数字都是猜测。它能做的是让讨论更有秩序：一项优化只有在整条链路的账上是正数，才算得上节能；只在某一个环节里是正数，只能说是“成本转移”。这也是九游会AI同时计算渲染、编码、网络和终端的根本理由。目前方案仍处于设计与验证阶段，尚待解决的问题包括：网络这一段的分摊方式怎样才算公允，终端能耗数据在保护隐私的前提下如何汇总，以及不同地区电网结构的差异该怎样纳入比较。渲染层面的动态调整思路，则可参考网速变差以后云端GPU为什么还在拼命渲染4K。