假设一位玩家在一段可用带宽为20Mbps的连接上玩竞技类射击游戏，服务器有两条省电路径：一条是把所有玩家的帧率和分辨率统一降一档，另一条是只削减这位玩家的网络本来就传不出去的那部分渲染。前者省得多，看起来更“绿”，可玩家会先觉得操作发黏；后者省得少，却没有碰玩家能感受到的东西。九游会官网把玩家体验放在节能模型的第一位，就是为了把这两条路径分开。

节能目标必须排在体验约束后面

先说明一个概念。QoE（体验质量）指玩家对一次游戏过程的整体感受，包括操作跟手不跟手、画面卡不卡、看得清不清楚。九游会官网的节能思路可以概括为QoE-Constrained Energy Optimization，即体验约束下的能耗优化。它在形式上分成两部分：约束是延迟、卡顿、视觉质量、操作响应不得低于事先定义的底线；目标是在满足这些底线的前提下，让渲染、编码、网络传输和终端的总能耗尽可能低。

这与常见的另一种写法恰好相反：先给定一个能耗预算，再在预算里“尽量提高体验”。两种写法在公式上只差一个位置，工程后果却差得很远。预算优先的系统会在负载高的时候悄悄牺牲体验，而且体验损失和电表读数不一样，它不会自己报警。玩家遇到卡顿，多数时候不会申诉，只会关掉游戏。所以在九游会的设计里，体验底线是硬边界，节能是在边界内部找空间，两者不能倒过来。

节能动作可以撤销，玩家的一次卡顿不能。

这也解释了为什么本站不把“降低所有玩家的帧率和分辨率”当作节能方案。那是最容易实现、也最容易伤人的办法：它没有区分哪些算力是浪费，哪些是玩家真正需要的。

最低体验要求怎么定，为什么不能全站共用一张表

底线不是一个数，至少要拆成四项，而且每一项对不同游戏的分量完全不同。

  • 延迟：从玩家输入到画面反馈的时间。竞技类射击游戏对它极度敏感，回合制游戏则宽松得多，这是同一套节能策略不能通用的第一个原因。
  • 卡顿：帧与帧之间时间间隔的不均匀。平均帧率看起来很高，但只要间隔忽长忽短，玩家依然会觉得画面在抖，所以要看的是波动而不只是均值。
  • 视觉质量：画面被压缩传输之后玩家实际看到的质量。同样的码率，静态场景和快速运动场景的观感差别很大，字幕、准星这类小而关键的元素还需要单独保障。
  • 操作响应：输入被识别、被执行的稳定程度，包括替代输入设备的响应，这一项由玩家的实际设备和设置决定。

四项之间还有相互换取的关系。假设某个回合制游戏能接受比竞技射击游戏更高的延迟，那么它就可以用略大的编码缓冲换取更平滑的码率，这是设想的例子，并不是某个已测得的数据。反过来，射击游戏往往要用更少的缓冲，把稳定的低延迟放在最前面，付出的是码率波动时画质更容易掉。这些取舍要写进每一类游戏的约束配置，而不是写进一个全局参数。

玩家自己声明的需求也进入约束。比如某位玩家把字幕可读性设置为必须保障，那么任何节能动作都不得让字幕区域的清晰度低于这个要求；这一点由玩家决定，系统不能替他省掉。这与官网把三条线放进同一体系的考虑是一致的，这里不再展开。

可调的旋钮很多，动哪一个有先后顺序

约束定好以后，才谈得上调什么。云游戏里可以省算力的地方大致有这几类：渲染质量预设和渲染分辨率，帧率上限，编码码率与编码参数，服务器上的多任务合并部署，边缘节点的选择，以及终端的解码与显示设置。每个旋钮对体验的影响不同，因此降级顺序不能随意。

第一类是玩家看不到的部分。网络可用带宽只有20Mbps，却仍在服务器上以最高质量渲染，画面经过有损压缩后，很多细节根本传不到玩家那里，这部分渲染就是“无效算力”。据arXiv论文Stimpack，其思路正是：当画面经有损压缩传输后，过高的渲染质量未必能提升用户感知质量。论文测得不同渲染质量预设的单帧渲染耗时差异可达约3.6倍，说明渲染这一段有相当大的调整空间。需要提醒的是，这篇论文讨论的是渲染成本与用户感知质量的平衡，并没有讨论能耗，不能把它写成节能成果，只能说它给出了“减少无效渲染”这条思路的依据。具体到20Mbps的场景，可以看网速变差时云端GPU为什么还在渲染4K。

第二类是玩家看得到、但不影响当前任务的部分，比如远处背景的细节，或者静态场景里的过高帧率。60帧与120帧什么时候能被感觉出来，取决于游戏类型和画面运动量，这是一个要单独建预算的问题，可以参考动态帧率预算的讨论。

第三类才触及体验，比如降低分辨率或让码率波动，这一步需要有可恢复的机制，并且被玩家察觉时要能立刻撤回。最后一类是延迟与操作响应，在降级顺序里它们不是旋钮，而是不允许触碰的约束。

还有一个容易被忽略的问题：震荡。如果网络在临界点附近上下波动，系统一会儿升质量一会儿降质量，这本身就会破坏观感。Stimpack论文用指数退避来稳定渲染质量，避免来回跳动，这个细节说明“稳定”也是体验的一部分，不只是工程上的优雅。

违反约束时，宁可少省一点

再周密的模型也会遇到约束被突破的时候：网络突然抖动，终端负载突然升高，或者服务器上出现了预料之外的峰值。这时的原则很简单，先撤回节能动作，再考虑别的补救。具体的顺序可以这样理解。

如果延迟接近底线，系统首先取消最近一次省算力的调整，恢复渲染质量或帧率，而不是继续想办法在别处挤出空间；如果网络带宽下降，就把渲染质量与码率联动下调，避免GPU为传不出去的像素继续工作；如果两者同时恶化，仍然无法满足约束，就不再降低体验要求，而是提示玩家当前网络不足以支撑目前的设置，由玩家选择切换网络、换一个节点，或者接受一次明确告知的画质降低。这里的关键是：降低的决定属于玩家，而不是静悄悄地发生。

这也意味着一些节能机会会被主动放弃。峰值时段少省一点电，比让玩家多一次卡顿更可以接受，因为节能可以在下一个时段补回来，玩家流失的体验却补不回来。至于这样放弃的部分是否值得，要看放弃了多少，这需要实测，而不是靠推理，本文没有也不会给出一个自己的数字。

验证：客观指标和主观感受之间还有一道缝

怎样知道约束确实被满足了？工程上常见的办法是用客观指标估计感知质量。VMAF（视频多方法评估融合）就是其中一种，它试图用算法预测人眼对压缩后视频的评价。Stimpack用回归模型，根据渲染质量和网络压缩参数来预测VMAF。论文摘要称，与基线相比可提升最多24%的服务质量，或在相同资源下服务两倍用户，这些都是论文实验设定下的结果，不能当作通用的平均效果。

客观指标好用，却有几处覆盖不到：它不直接反映延迟带来的“手感”，不专门评估字幕这类小元素的可读性，也很难体现个体差异，比如有人对运动模糊特别敏感，有人则对色彩更在意。所以九游会的设计里，客观指标只是第一道筛选，还需要用小规模的主观评价来核对：让不同类型的玩家在相同网络条件下盲测，比较开启与关闭节能策略时的感受，看指标好看的方案，玩家是否也真的觉得没有差别。

还要承认几个难处。端到端能耗本身就很难测全，终端和网络设备的用电往往拿不到；体验模型可能对某类游戏或某类终端有偏差；节能策略上线后，网络环境和游戏内容也会变化，验证不是做一次就结束。九游会官网在这里展示的是方案设计，没有已完成的实测结果可以引用。

如果要检验一套云游戏节能方案是否真的把体验放在第一位，可以问四个问题：底线是否按游戏类型分别定义；降级顺序里延迟和操作响应是否被排除在外；触碰约束时是先撤回节能还是继续压榨；节能策略有没有经过实际玩家的对照评价，而不只是看指标曲线。四个问题只要有一个答不上来，这套方案的“节能”就还没有站稳。