云游戏最容易浪费的算力，可能恰恰是玩家根本看不到的那些像素。要让模型学会分辨“看得到”和“看不到”，先得回答一个更朴素的问题：它到底该看哪些数据？九游会AI在设计绿色游戏大模型时，把这个问题放在模型结构之前，因为数据决定了模型能回答什么，也决定了它会在哪里出错。

一条渲染档位建议，背后要回答哪三个问题？

九游会大模型的输出设想得很克制：它不下达“把画质降到多少”的命令，而是给出一个带理由的渲染档位建议，包括分辨率区间、帧率区间和编码码率区间，再交给规则层按体验约束复核。要给出这样的建议，模型必须回答三个问题：这条链路现在能传多少内容？云端渲染一帧要付出多少代价？玩家的屏幕上最终能看清多少？

这三个问题分别对应网络、GPU与编码、终端三类数据，缺任何一类，建议都会偏。只看网络，遇到终端能力很强的玩家会过度保守；只看GPU，服务器省下的算力可能变成更高的码率和更多的重传；只看终端，则对链路拥塞视而不见。服务端省一点、整条链路反而多耗一点，正是云游戏节能为什么不能只盯GPU里讨论的系统边界问题，数据设计要从一开始就把这条链路整体装进来。

网络数据：带宽只是一项，抖动和丢包常常更要命

网络侧至少需要五项：可用带宽、往返延迟、抖动（延迟的波动幅度）、丢包率和重传次数。举个假设的例子：某条链路标称带宽为50Mbps，但每隔几秒就出现一次丢包突发，玩家感受到的流畅度，可能还不如一条稳定的20Mbps链路。丢包之后，视频流要么重传、要么花屏，重传会抬高延迟，玩家看到的就是卡顿。

所以模型吃进去的不该是“一次测速的结果”，而是一段时间窗口内的分布：中位数、偏高分位和波动幅度。同样是丢包，有线网络里多为偶发，无线网络里往往带有周期性，与干扰源有关，因此连接类型也要作为标签一并记录。还有一个容易被忽略的成本：测量本身不能占用玩家的带宽。九游会的设计倾向于复用传输过程中自带的统计，只在必要时才做短时主动探测。

GPU与编码数据：渲染一帧到底值多少

服务器侧要看的是GPU利用率、显存占用、单帧渲染耗时、编码器占用、编码耗时，以及同一块GPU上同时承载了多少路会话。据arXiv论文Stimpack，其思路是当画面经有损压缩传输后，过高的渲染质量未必能提升用户感知质量；论文测得不同渲染质量预设的单帧渲染耗时差异可达约3.6倍。这个数字说明，“档位”与“代价”的对应关系是可以被测量的，不应靠经验假定。需要说明的是，该论文讨论的是渲染成本与感知质量的平衡，并未给出能耗数字。

另有两点容易出错。第一，GPU负载要看“余量”而不是瞬时值：多路会话共享一块GPU时，某位玩家降档释放出的余量，才是别人能用上的算力，也是算力得以节省的来源。第二，CPU负载同样要采集：如果瓶颈在游戏逻辑而不在渲染，降低分辨率对帧时间几乎没有帮助，档位建议就应该转向别处，而不是继续压画质。

终端数据：屏幕决定了多少像素有意义

终端侧需要屏幕尺寸、分辨率、刷新率、解码能力（支持的编码格式与解码耗时）、设备发热与电量状态，以及当前是否外接电源。同一路高分辨率画面，推给一块小尺寸手机屏，多出来的像素大概率分辨不出；推给大尺寸电视，情况则相反。解码能力同样关键，终端解码慢或者发热降频时，即便链路和服务器都富余，提高码率也可能只会换来更高的终端延迟。这类差异在手机、电视和高性能电脑玩同一个云游戏的讨论里有更细的拆解。

哪些数据不该采？

数据越多不等于模型越好，很多数据带来的只是隐私风险。九游会大模型的设计里，下面这些内容被明确排除在外：

  • 账号身份、好友列表与聊天内容：档位建议用不到。
  • 精确位置：区域节点的粒度已经足够，不需要精确到街道。
  • 游戏画面截图与录像：画质评估用服务端的渲染统计即可，不必留存玩家看到的内容。
  • 麦克风与摄像头内容：即便玩家启用了语音功能，语音内容也不进入节能模型。

保留下来的，是设备型号级别的能力标签和链路统计；先在本地聚合，再上传汇总值，原始明细的保留时间尽量短。这样做也有一个技术上的好处：模型被迫只依赖真正影响体验的信号，而不是记住某个玩家是谁。

采样频率与数据质量陷阱

不同信号变化的快慢差别很大，采样要分层。网络抖动和丢包是秒级甚至亚秒级变化；GPU与编码负载每秒数次；设备发热按分钟计；屏幕尺寸和解码能力几乎不变，启动时采一次即可。全部按最高频率采集，只会制造存储和传输负担。

比频率更麻烦的是数据质量。常见的陷阱有五个：其一是幸存者偏差，连不上服务的玩家没有数据，模型看到的世界比真实情况更好；其二是时钟不同步，客户端和服务端的延迟对不上；其三是把测速峰值当成常态；其四是训练数据集中在某几类网络，模型对小众网络表现失常；其五是不同型号GPU的计数器口径不一致，需要先归一化再喂给模型。这些问题不解决，模型再大也只是把噪声放大。同样的道理也适用于设备侧，设备大模型能不能判断显卡还能用几年会谈到，为什么年龄这类粗糙特征会误导判断。

输出必须能被检查，而不是一句“已优化”

输出的形式和输入同样重要。九游会的设计要求每条建议带三样东西：档位区间、主要依据、置信度。例如“近三十秒丢包出现突发，建议保持当前分辨率，下调码率上限”，玩家或运维人员一眼就能看懂它为什么这样建议。建议之后还有一道规则层：延迟、卡顿、帧率和视觉质量组成体验下限，低于下限的建议一律不执行。这样，模型学到的是在体验约束内减少无效算力，而不是简单地把所有玩家的帧率和码率一起压低。

怎么验证模型没有为了省算力伤害体验？

验证的办法是回放：把记录下来的网络轨迹、负载曲线原样重放给模型，与固定最高档位的基线对比，看卡顿次数、延迟分布、画质评分和GPU占用如何变化。指标必须按网络类型和终端类型分组，因为平均值会掩盖问题，整体成绩很好而某一类网络上的玩家体验变差，是这类模型最典型的失败方式。玩家手动设置的画质也要作为最高优先级保留，模型的建议不能覆盖它。

需要坦白的是，这些仍是设计阶段的思路，各项阈值需要在真实测试中确定。一个尚未解决的难题是：没有参考画面时，如何可靠估计玩家眼里的视觉质量。这决定了体验下限画在哪里，也决定了绿色游戏大模型的“绿色”能走多远。