云游戏最容易浪费的算力，可能恰恰是玩家根本看不到的那些像素。设想一位玩家的家庭网络突然变得拥挤，云端GPU却仍在按最高质量渲染每一片树叶和每一道反光，而这些细节在进入视频编码器的那一刻，就被压成了一团模糊的色块。算力花出去了，屏幕上没有任何回报。九游会AI想处理的，正是这种“渲染得起、却传不过去”的错位。
一帧画面从渲染到被看见，中间被拿走了什么
先把链路摊开。云端GPU渲染出一帧完整画面，交给编码器压成视频流，经过互联网和玩家家里的路由器到达终端，再由终端解码、显示。整条链路里，编码器是一道很少被谈起的“闸门”：它每秒只能输出玩家网络承受得住的那么多数据，而一帧画面里细节越多、运动越剧烈，需要的数据就越多。当数据预算不够时，编码器只有一个办法，就是把量化参数（QP，决定压缩力度的一个数值）调高，让图像里的高频细节先被抹掉。
高频细节恰恰是高质量渲染里最贵的部分：细密的植被、远处的建筑轮廓、精细的阴影边缘、抗锯齿之后的锐利线条。这些东西在本地显卡直接输出到显示器时，人眼看得清清楚楚；可一旦经过一条吃紧的码率通道，它们就成为编码器最先放弃的内容。也就是说，同一帧画面在云端花了很高的渲染代价，玩家最终看到的，可能与低一档渲染再压缩之后的结果几乎没有区别。
这并不意味着高质量渲染没有价值。带宽充裕、码率宽松的时候，这些细节能够完整地穿过编码器，玩家看得见，也值得为它付出算力。真正要问的是“这一刻”值不值得，而不是“要不要高画质”。判断值不值得，需要同时知道两件事：渲染质量的高低会带来多少感知差异，以及此刻的网络会把多少差异保留下来。
画面内容本身也会改变这笔账。镜头快速转动、爆炸特效满屏的时刻，每一帧与上一帧差异巨大，编码器很难借助前后帧的相似性来节省数据，需要的码率陡然上升；而人眼在高速运动时，本来就来不及看清细节。这两件事叠在一起，意味着在剧烈运动的场景里，高档渲染的细节最容易被压缩抹掉，也最不容易被玩家察觉。相反，一个静止的菜单或对话界面，编码器压缩得很轻松，玩家又会盯着细节看，此时的高质量渲染才真正“看得见”。同一局游戏里，值不值得渲染高档位，是随着场景变化的。
渲染质量预设和编码QP，到底是谁在决定画面
渲染质量预设与编码QP是两个不同的旋钮，却共同决定玩家看到的画面。渲染这一侧的旋钮决定云端GPU要画多少东西：分辨率缩放、阴影精度、后处理、光照细节，档位越高，单帧耗时越长。编码这一侧的旋钮决定压缩多狠：QP越高，数据量越小，细节越少。两者在感知质量上存在重叠区，渲染档位抬高带来的收益，会被压缩吃掉一部分，带宽越紧，被吃掉的比例越大。
据 arXiv 论文 Stimpack，其思路正是抓住这块重叠区：当画面经过有损压缩传输之后，过高的渲染质量未必能提升用户感知质量。论文用回归模型，由渲染质量和网络压缩参数去预测 VMAF（一种常用的视频感知质量评分），再据此在服务端选择渲染质量。论文测得不同渲染质量预设的单帧渲染耗时差异可达约3.6倍，说明渲染档位的选择对服务器成本有实质影响；摘要还称，与基线相比可提升最多24%的服务质量，或在相同资源下服务两倍用户，这些数字都来自论文的实验设定，不能当作任何平台的通用效果。
还要交代一个边界：Stimpack 讨论的是服务器渲染成本与用户感知质量之间的平衡，论文并没有测量能耗，所以不能把它写成节能成果。九游会借用的是它的问题框架，也就是把“渲染质量”和“压缩后的感知质量”绑在一起看；至于这种做法在具体机房里能省下多少电，需要在自己的环境里另行测量，本文不给数字。
网络开始变差时，哪些信号值得相信
让渲染等级跟着网络走，第一步是知道网络到底怎么了。可用于判断的信号至少有四类：可用带宽的估计值、丢包率、往返延迟、延迟抖动。它们各有陷阱。带宽估计通常是滞后的，等估计值下降时，拥塞往往已经发生了几百毫秒；丢包既可能来自真正的拥塞，也可能来自无线信号的短暂干扰，两者的正确应对完全不同；往返延迟持续上升，常常是路由器缓冲区正在堆积的早期征兆，比丢包更早出现；抖动大的网络，即使平均带宽不低，也会让码率控制频繁失灵。
只看网络还不够，因为同样的带宽对不同内容意味着不同的画质。九游会AI的设计里，还会把游戏类型、画面复杂度和终端屏幕纳入判断。快节奏的竞技类射击游戏，画面剧烈运动，单帧数据量大，对码率更敏感，同时对延迟和帧率的下限要求也更严；回合制游戏静态画面多，同样的带宽下细节保留得更好，渲染高档位的收益更容易被看见。屏幕很小的终端，本来就看不清一部分细节，降低渲染精度的代价也小得多。
把这些信号合在一起，才能回答“渲染一个更高档位，玩家能多看到多少”。如果想看一个更具体的算账过程，可以读网络只有20Mbps时，最高画质还有意义吗，那里用一个假设的带宽预算把码率、细节和渲染开销逐项对应了起来。这里只强调一点：信号越多，越要避免把任何单一指标当成真相，系统输出的应当是“建议渲染档位”和一个置信程度，而不是一条不容置疑的指令。
决策的节奏也要分层。丢包与延迟抖动的变化很快，适合用短周期的监测去触发保护动作，比如立刻暂缓码率上调；带宽趋势、游戏场景和终端状态的变化较慢，可以用更长的周期去决定渲染档位。把快慢两种信号混在同一个周期里，要么反应迟钝，要么过度敏感。九游会AI的设计是让快信号只负责“紧急刹车”，慢信号才负责“换挡”，换挡的动作一律要经过下一节讲的防震荡规则。
为什么画质不能来回跳，网络恢复后又该怎么升回去
动态调整最容易出的事故，是调得太勤。假设网络在临界值附近上下波动，系统每次一看到带宽下降就降一档，一看到回升就立刻升一档，玩家看到的会是画面清晰度在几秒钟之内反复变化，像是一种“呼吸感”。这种波动本身就是糟糕的体验，有时比一直稳定在中等画质还令人难受。更麻烦的是，渲染档位切换会改变单帧耗时，影响帧间隔的均匀程度，可能顺带带来新的卡顿。
所以调节策略要对“降”和“升”区别对待。Stimpack 采用了指数退避来稳定渲染质量：思路是降档可以及时一些，升档则要谨慎，而且每次升档之后如果又很快被迫降回去，下一次再升之前的等待时间就要拉长，指数式地拉长。九游会AI的方案沿用这个原则并加以扩展：降档时留出足够的安全余量，保证体验下限；网络恢复后，不一步跳回最高档，而是逐级抬升，每抬一级都观察一段时间，确认码率、丢包和延迟都稳住了，再进入下一级。
用一个示例说明。假设某位玩家的网络在一分钟内两次短暂拥塞，系统第一次降了一档，等待较短就尝试回升；回升后不久又出现拥塞，被迫再次降档，这一次等待时间就翻倍；再来一次，再翻倍。几轮之后，系统会自动稳定在一个网络能够支撑的档位，而不是不断试探。这个思路很朴素，价值在于用一点点“保守”换取画质稳定，玩家能感受到的是画面始终一致，而不是忽好忽坏。
九游会的体验下限：哪些线是省算力也不能碰的
“云游戏节能”一旦被理解成降低画质，就会滑向一个危险的方向：为了让数字好看，把所有玩家的分辨率、帧率一起压低。九游会的设计明确不走这条路。判断的顺序是先定体验下限，再谈省算力。体验下限至少包括几项：操作延迟不能超过该游戏类型可接受的范围；帧率不能低于该类型的最低要求，竞技类射击游戏和回合制游戏要分别对待；分辨率不能低到让游戏内文字、小地图和字幕难以辨认；视觉质量不能出现玩家能明显觉察的块状伪影。
在这些下限之上，系统才可以按照一个大致的次序削减无效计算：
- 先削减在当前码率下几乎不可见的渲染开销，比如高频纹理精度、部分后处理与远景细节。
- 再考虑在小屏终端上适当下调渲染分辨率，让终端的缩放和显示来补上。
- 只有前两步仍不足以适应网络，才在下限范围内调整帧率或码率，并明确告知玩家画质因何变化。
- 如果继续调整就会跌破体验下限，系统保持下限不变，转而提示网络问题，而不是悄悄降低体验。
还有一条线属于玩家本人。玩家手动设定的画质偏好，比如“我更愿意牺牲一点流畅度换取清晰度”，优先于自动决策。对低视力玩家来说，界面文字与高对比度元素比风景细节重要得多，为了省算力糊掉这些内容，等于把无障碍问题带进了节能方案。不同终端如何分配计算预算，可以进一步参考同一个云游戏，为什么不该给手机和电视同样的画面。
这套思路的局限：感知指标会骗人，实验结果别照搬
最后要说明几处不确定的地方。第一，VMAF 这类指标只是人眼感受的近似，不同游戏画面风格、不同人的敏感度下，评分与主观感受之间会有偏差；用它做决策的系统，需要定期用真实玩家的评价去校准，否则会在自己的评分里越走越偏。第二，论文里的24%和两倍，是特定实验条件下的结果，换一批游戏、换一种编码器、换一种网络环境，可能大不相同，不应当被当作九游会的承诺。第三，动态调整本身需要监测和决策，这些开销要算进去，如果为了省下一点渲染开销而引入大量额外计算，得不偿失。
第三点之外还有一层：验证本身的成本。想知道玩家到底看没看见某个细节，最可靠的办法是让真实玩家做盲测，也就是在不告诉对方档位的前提下，对比不同渲染等级下的画面，看能否分辨。盲测费时费力，不可能覆盖所有游戏和所有网络条件，于是只能靠客观指标做日常判断、靠抽样盲测做定期校准。这两者之间的差距，就是任何“自适应渲染”系统需要持续盯住的误差来源。
第四，也是最容易被忽略的：渲染省下来的算力，不等于整体省下来的能耗。渲染降档以后，编码器可能因为画面变化模式不同而消耗不同，网络与终端也有各自的能耗，这些需要放在一起算，相关讨论见云游戏节能为什么不能只盯GPU。在把任何一个渲染策略称为“节能”之前，先做三件事：在相同网络条件下对比玩家的主观评价，确认没有跌破体验下限；记录切换频率，确认没有画质震荡；测量整条链路的能耗变化，而不只是GPU那一段。这三项都通过，才有资格谈“无效计算被减少了”。
