假设某个玩家的网络稳定可用带宽只有20Mbps，云端却仍在为他渲染一帧一帧最高画质的画面。这些画面要先经过视频编码器，而编码器手里的比特是有限的。渲染得再细，进不了码流的部分就等于没有渲染。这篇文章不讨论原理，只做一件事：把20Mbps这个数字摊开来算一遍。需要说明，文中所有数值都是示例设定，实际结果取决于编码器、分辨率和画面内容。

20Mbps摊到每一帧、每个像素上是多少？

先做扣除。带宽不能全部拿来传视频，音频、控制信令、重传余量都要占一块。假设留出四分之一作安全余量，实际给视频的大约是15Mbps。若游戏以每秒60帧运行，平均每帧约250千比特，也就是三万多字节。这是一个平均值，关键帧会大得多，普通预测帧则小得多，编码器在它们之间腾挪。

再看分辨率。1080p一帧约207万个像素，摊下来每个像素约0.12比特；如果同样的预算用来传4K，一帧约830万个像素，每个像素只剩约0.03比特。这个差别很直观：同一笔带宽，要么把较少的像素表达得比较完整，要么把很多像素表达得非常粗糙。所谓“最高画质”在这里有两层含义，一层是渲染质量（阴影、光照、纹理、特效），另一层是输出分辨率，它们和码率是三个互相牵制的变量，不能只盯着其中一个。

编码器在这笔预算下会先舍弃什么？

视频编码本质上是“先预测、再量化”。量化参数（QP）一旦被迫调高，最先被抹平的是高频信息：细密的纹理、远处的小物体轮廓、细小的噪点。这些恰好也是最高渲染档位最擅长制造的东西，比如高精度的法线细节、密集的植被、微小的反射高光。渲染端花了大量算力算出来的东西，压缩端因为预算不够，在量化时把它们涂平了。

同时还有一个不太被注意的副作用：细碎而随机的内容很难预测，会让编码器更“费比特”。为了给这些难压缩的内容留出预算，编码器往往要把整体量化调得更粗，结果连原本清晰的边缘也一起变糊。也就是说，过度丰富的细节不仅自己传不过去，还会拖累其他部分。

哪些渲染开销在这个码率下几乎看不出来？

不同的渲染项对压缩的态度并不一样。下面的表格把常见的几类放在一起，可见度与建议均为示例性判断，具体要以画面内容和实测为准。

渲染项（示例）对码流的影响 20Mbps下的可见差异 处理思路
高精度细纹理 增加高频信息，难压缩 细节被量化抹平，差异很小 可降一档，收益较大
胶片颗粒、随机噪点特效 制造不可预测内容，抬高码率 常表现为糊成一片或块状闪烁 优先关闭，省GPU也省码率
景深、运动模糊 让画面更平滑，利于压缩 可能提升整体观感 可保留，视游戏类型而定
抗锯齿让边缘平滑，降低边缘闪烁 边缘抖动在压缩后会被放大 不宜随意砍掉
界面与文字 边缘锐利，对量化敏感 模糊会直接影响可读性 保护优先

这张表里有一个反直觉的地方：某些看似“高级”的特效对码流是负担，关闭它既节省渲染开销，又让编码器有余量把画面主体处理得更干净；而另一些看似不起眼的处理，比如抗锯齿和界面文字，在低码率下反而是玩家能感知到的部分。因此“把所有质量项统一降一档”并不是九游会AI的做法，它的设计思路是逐项判断：这一项在当前码率下还能不能被玩家看见，看不见就降，看得见就留。

省下来的GPU开销大概怎么估？

不同渲染质量预设的单帧耗时差异其实相当可观。据 arXiv 论文 Stimpack，其测得不同渲染质量预设的单帧渲染耗时差异可达约3.6倍，论文的思路是：当画面经有损压缩传输后，过高的渲染质量未必能提升用户感知质量，因此可以用回归模型由渲染质量与压缩参数预测感知画质（VMAF），在感知质量不受明显影响时降低渲染成本。需要强调，该论文关注的是服务器渲染成本与用户感知质量的平衡，并没有讨论能耗，本文也不会把它写成节能数字。

具体到我们的20Mbps示例：假设最高渲染预设一帧要花约5毫秒，而某一档只需要约2毫秒（示例数值），那么同一块GPU在单位时间里能同时服务的画面数就会明显不同。这里省下的是“单位画面占用的GPU时间”，它最终能不能转化成更低的电耗，要看这块GPU随后是被安排去服务更多玩家，还是进入低负载状态。这一层账需要和数据中心的调度一起算，可以参考《网速变差以后，为什么云端GPU还在拼命渲染4K》里对整体思路的梳理，本文只关注带宽这一条线。

什么情况下，即使只有20Mbps也不该降渲染？

第一类是画面本身很“简单”。回合制游戏的菜单界面、静态场景，内容复杂度低，码率反而绰绰有余，此时降低渲染质量省不了多少，还会白白损失清晰度。第二类是终端屏幕很小，分辨率本来就低，摊到每个像素的比特比想象中充裕，压缩后的损失更少，可以把预算留给渲染质量。第三类是玩家自己指定了偏好，比如明确要求“画面优先”，那么系统应当尊重这个选择，最多把“带宽不够会出现画质下降”这件事说清楚。

还有一个容易被忽略的方向是“换个花法”：不是降低渲染质量，而是调整分辨率与帧率的组合。比如在帧率预算上做取舍，可以看《60帧和120帧什么时候玩家真的能感觉出来》，那里讨论了帧率和码率如何在同一个预算里此消彼长。

降下去以后，怎么知道没有降过头？

九游会AI的设计里，降档必须有验证。最直接的方式是同时看客观指标与玩家行为：感知画质估计值是否掉到预设下限，卡顿是否增加，玩家是否手动把画质调回去。如果玩家在系统降档之后立刻手动拉高，这本身就是一个信号：这一档的判断过于激进。当网络恢复时，也要逐级抬升而不是一次跳回最高，以免画质来回震荡。这些机制在前一篇已经展开，这里不再重复。

还有一点值得补充：验证不能只在实验室里做。同一份渲染配置在办公室的有线网络和地铁里的移动网络下，玩家的容忍度完全不同；同一段码率在快节奏射击和慢节奏解谜里，能被看见的细节也不同。所以九游会AI规划的做法，是把游戏类型、终端和网络一起作为条件去评估，而不是只拿一个平均带宽数字去套所有人。

最后留一个没有标准答案的问题：20Mbps只是一条平均线，实际网络会在几秒之内上下跳动。渲染档位每次切换都有代价，切得太勤会让画质忽明忽暗，切得太慢又跟不上网络。在这两者之间，多长的观察窗口才算合适，取决于游戏类型和玩家的容忍度，这正是九游会AI仍在设计和验证的部分。