手机、电视和高性能电脑玩同一个云游戏，为什么服务器不该给它们同样的画面？

想象周六晚上的一间屋子：孩子用手机玩一款云游戏，父亲在客厅电视上玩同一款，房间里一台高性能电脑也刚刚连上服务器。三台终端的画面从同一批云端GPU里出来，如果规格完全一样，三个人里至少有两个是在为自己用不上的东西买单。九游会AI关心的是另一种做法：先弄清每台终端到底能呈现什么，再决定云端该为它花多少算力。

同一个画面，三块屏幕上的“有效像素”差多少

先说最直观的一项：分辨率并不等于清晰度，真正决定看起来是否细腻的，是屏幕像素密度和观看距离的组合。手机屏幕不大，但握在手里，眼睛离它只有二三十厘米；电视屏幕很大，坐在两三米外看，每一个像素所占据的视角其实更大。人眼有一个大致的分辨极限，当像素小到一定程度，再多的像素只是数字，看起来没有区别。手机的屏幕尺寸小，多数场景里，在屏幕上再加渲染分辨率，收益很快就被人眼的极限吃掉；电视则不同，大尺寸、远视距，要维持“看起来清楚”，需要较高的渲染分辨率和足够的码率。

所以“手机未必需要持续最高4K渲染”并不是在为节能找借口，而是一个可以用光学常识解释的判断。反过来也成立：一台接在大电视上的设备，如果被系统当作“手机”处理，画面会显得模糊，这是系统的错误，不是节能。九游会的设计里，终端的物理屏幕尺寸、原生分辨率、常用观看距离的粗略估计，都是决定渲染分辨率上限的输入。观看距离无法精确得知，系统只做保守的分类，比如“手持”“桌面”“客厅”，允许玩家自己纠正。

刷新率是另一个常被忽视的差别。屏幕最高只能刷新到60次每秒，云端却按120帧渲染，多出来的那些帧根本没有机会被显示；一块高刷新率的电脑显示器，又确实能从更高帧率中受益，尤其是玩竞技类游戏的人。帧率与刷新率的关系，在60帧和120帧什么时候玩家真的能感觉出来里有更详细的推演，这里只需要记住：终端能显示什么，是云端渲染上限的一部分。

有一个反例值得单独说。文字密集的游戏，比如带有大量属性面板、聊天窗口和小字号提示的角色扮演类游戏，即使在手机上，也对分辨率格外敏感：风景类画面降低一些精度，玩家几乎无从察觉；而一行小字一旦糊掉，玩家会立刻觉得画质很差。所以设备感知不能只按“屏幕多大”一刀切，还要看画面里最不能糊的元素是什么。九游会的设计思路是把界面层与场景层分开考虑：场景里的细节可以按屏幕与视距适度收紧，界面文字和关键图标则要保证在这块屏幕上依然清晰。

解码器才是终端真正的门槛

屏幕之外，还有一个更硬的约束：解码能力。云端把画面压缩成视频流，终端必须把它还原出来。不同终端支持的编码格式不同，硬件解码单元能承担的分辨率和帧率也不同。一台较老的设备，可能只有硬件的老编码格式解码能力，遇到新格式就只能交给CPU做软件解码，结果是发热明显、延迟增加，甚至掉帧。如果云端不问情况，统一推送最新、压缩率最高的格式，压缩率是上去了，终端却撑不住。

解码延迟同样不能忽略。从终端收到一帧数据，到画面真正显示出来，中间的解码时间会叠加在总延迟里。对于竞技类射击游戏，几毫秒的差别玩家未必意识得到，但持续累积的抖动会影响手感；对回合制游戏，这点影响几乎可以忽略。因此，九游会的方案里，终端能力检测要包括：支持的编码格式、硬件解码的最大分辨率与帧率、实际测得的解码耗时，而不是只读一个设备型号就下结论。型号相同的设备，在不同系统版本、不同驱动下，表现也可能不同，实测比查表可靠。

这里还有一个反直觉的地方：压缩率高，不一定更省。更高压缩率的编码格式，云端编码的计算量往往也更大，终端解码的负担也更重。省了网络流量，却多耗了服务器与终端的算力，整体账要算清楚，才能说得上“节省”。

屏幕之外，还有色彩与亮度这类显示特性。有的终端支持更宽的色域与更高的亮度范围，有的则明显受限，把为宽色域准备的画面推给一块普通屏幕，颜色反而会显得发灰，等于额外做了无用功。终端把这些特性报告给系统之后，云端才能判断哪些画面处理是这块屏幕真正用得上的。

手机会发烫，电视插着电：发热与电量也是预算

手机与电视的另一个差别，在于能源与散热条件。手机靠电池供电，长时间高负载解码会明显升温，系统为保护硬件会自动降频，玩家看到的是卡顿突然出现；电视和台式电脑插着电源，散热空间大，可以长时间稳定运行。如果云端对手机与电视采用相同的高码率、高帧率，手机会更快发烫、更快掉电，玩家为了续航被迫提前结束游戏，体验就不算好。

无线网络的能耗也要算进来。手机在蜂窝网络或较弱的Wi-Fi环境下，收发数据的功耗比稳定的有线连接高得多，码率越高，射频模块越忙。适度降低手机的码率，既是网络条件的要求，也在延长电池时间。但这里同样有边界：降低码率不能让文字变得难以辨认，也不能让操作响应变慢。九游会App的规划里，发热和电量状态是可选的输入，玩家可以选择是否允许应用读取，并且随时关闭；读到发热偏高时，系统给出的是“建议降低画质档位以延长游戏时间”的提示，最终由玩家决定是否采纳。

“体验感知的计算预算”是怎么定出来的

把上面几项合起来，可以得到一个核心思路，九游会称它为“体验感知的计算预算”（Experience-aware Compute Budget）：先为每一类游戏、每一类终端确定体验下限，再在下限之上，给每个玩家分配一份云端计算预算。顺序不能颠倒。如果先把预算砍到一个固定的比例，再看玩家能不能忍受，那就成了一刀切的降配；先定体验下限，才能保证省下来的确实是多余的部分。

预算的输入大致有四类：终端的屏幕与解码能力，网络条件，游戏类型的敏感程度，以及玩家的手动设置。其中玩家的手动设置优先级最高，如果玩家在设置里明确选择“始终保持最高清晰度”，系统应当尊重，同时如实告知可能的后果，比如网络不佳时可能出现卡顿。下面这个表格是示例，只用来说明预算分配的思路，不是任何实测结果：

这张表最要紧的一点，是每一行的“预算倾向”都是从“下限考虑”推出来的，而不是反过来。比如旧设备，问题不在于它不配用高画质，而在于解码能力是它的短板，所以预算花在稳定与延迟上，而不是花在更多像素上。

预算也不是一次定下就不变的。玩家在同一局游戏里，场景会变、网络会变、手机也会越用越热，预算需要随之滚动调整：进入激烈战斗时，优先保证帧率和响应；进入静态剧情或菜单，可以把多出来的预算花在清晰度上；设备发热到一定程度，就提前收紧，而不是等系统强制降频之后再被动应对。调整的幅度要小、节奏要稳，避免让玩家感到画面在“喘气”，这一点与网络变差时的防震荡原则是一致的。

玩家自己的设置和系统的判断冲突时，听谁的

设备感知最容易被诟病的一点，是系统自作主张。设想一位玩家用手机连接了一块外接显示器，系统检测到的是“手持设备”，就给了较低的渲染分辨率，玩家却发现画面模糊，找不到原因。这类错误很常见，因为终端并不总能准确报告自己接了什么、坐在多远的地方看。所以在九游会的设计里，自动判断只是默认值，玩家在设置里的选择永远优先：可以手动指定“我在用大屏”，可以选择“优先清晰度”或“优先流畅度”，也可以关闭自动调整。

更进一步，系统需要告诉玩家它做了什么。画面被调整以后，应用应当能显示“当前渲染分辨率、帧率与调整原因”，比如“检测到设备发热，已降低一档”。这样，玩家看到画质变化时，能分清是网络问题、设备保护，还是自己的设置生效。当玩家不同意系统的判断时，可以一步撤销，撤销之后系统在这次游戏里不再重复同样的调整，否则就会变成反复打扰。

多个玩家共用一批GPU时，预算怎么分才不亏待谁

在云端，预算不是无限的。同一个机房里的GPU要同时服务很多玩家，每个玩家的预算之和不能超过总容量。最省事的做法是平均分，但这不公平也不高效：给手机玩家和电视玩家一样多的算力，前者用不完，后者不够用。更合理的思路是边际收益：把算力优先放到“多给一点就能明显提升体验”的玩家身上，从“再给也看不出差别”的玩家那里收回。

用一个假设的小例子来看。假设某个机房节点当前同时服务三位玩家：一位用手机，一位用电视，一位用高刷新率显示器，且三人的网络条件都不错。如果三人都按最高规格渲染，总算力吃紧，第三位玩家的高帧率反而可能因为排队而不稳定。按边际收益重新分配之后，手机玩家的渲染分辨率适度收紧，让出来的算力交给那位高刷新率玩家，保证他的帧率与延迟。三个人都没有跌破各自的体验下限，但整体算力用得更合理。这里的数字与场景都是设想，重点是分配的逻辑，而不是某个具体比例。

可这里必须设一道防线：体验下限对所有人生效，节省不能建立在牺牲某类终端或某类玩家的基本体验之上。对依赖高对比度界面的低视力玩家，或对延迟特别敏感的玩家，需要有的保护，不能因为“边际收益低”就被系统悄悄压低。忙时与闲时也不同：高峰期资源紧张，预算分配更依赖优先级；低谷期资源充裕，没有必要刻意压缩，玩家应当获得更好的画质。

这套思路目前仍是设计层面的方案，它的可行性取决于很多现实条件：终端能力检测是否准确，玩家是否愿意开放必要的信息，机房调度是否能实时响应。想让预算方案落地，至少要先回答三个问题：这台终端真正的显示与解码瓶颈是什么？玩家的手动设置是否被优先尊重？下限之上省下的算力，是否真的没有被别处的额外开销抵消？三个问题都能回答，才能谈得上“不该给它们同样的画面”。此外，渲染策略如何随网络动态变化，可以对照网速变差以后云端GPU为什么还在渲染4K一起阅读。