为什么「把码率花在人看的地方」是云游戏画质的第一块基石

我做云游戏那几年，最常被问到的一个问题是：「你们能不能只把玩家看的地方传清楚，别的地方糊一点？」问的人通常觉得自己提了个天才想法，还特别省钱。我说能，我们真做了。然后他们会问第二个问题：「那为什么我玩起来还是觉得糊？」

这两个问题之间，隔着整个 ROI 编码（Region of Interest，感兴趣区域编码）的全部工程真相。

得先把人眼那点事说清楚。视网膜上真正能干活的感光细胞（视锥细胞）密度最高的地方叫中央凹，覆盖的视角大概只有 2 度——你伸直手臂举起大拇指，指甲盖那么大。这个圈之外，视力断崖式下跌，到视野边缘几乎只能分辨明暗和运动。你的大脑之所以觉得「我什么都看得清」，是因为它每秒把眼球弹射三四次，每次 20 到 40 毫秒，然后用记忆把画面拼起来。这个动作叫扫视，英文 saccade。

说句不客气的：你以为你在看世界，其实你的大脑在给你放 PPT，还是每秒换四页那种。

所以从理论上说，把码率按人眼分辨率分布来分配，收益巨大。业界普遍的估算是在同等主观质量下能省掉 40% 到 60% 的码率。听着像白捡钱。但这里有个被反复忽略的前提：本地凹视渲染省的是 GPU 算力，云游戏的 ROI 编码省的是网络带宽，这两件事的失败模式完全不一样。

本地渲染把边缘糊了，玩家可以在设置里关掉，骂两句引擎就完了。云端把边缘糊了，玩家关不掉，他只会得出一个结论：「这平台画质真烂」——然后把锅甩给整个云游戏行业。你省下的那点带宽，换来的是用户对整个品类的信任折损。这笔账，比码率账难算多了。

这篇想聊的就是这笔账怎么算。ROI 编码的收益到底从哪来、三条实现路径各自的成本、眼动追踪在云游戏里撞上的那道物理墙，以及内容分析自动建模为什么总在看错地方。

第一层：码率是零和的——注意力分布决定了画质分配的天花板

先破除一个幻想：ROI 编码不创造码率，它只是重新分配码率。总预算 15 Mbps 就是 15 Mbps，给中心多一兆，边缘就少一兆。这是零和的。

用感知编码的框架写出来，目标函数大概是这样一句话：总失真等于每个图像块的失真乘上它对应的注意力权重，然后全部加起来。编码器的任务是让这个加权和最小。整个 ROI 理论的重量，全压在「注意力权重」这五个字上。权重分布错了，你优化得再狠也是在错误的方向上狂奔。

而且人眼对失真有个阈值特性。某块区域的画质低于某个门槛，你会立刻注意到「这里有块糊的」；一旦过了这个门槛，继续往上堆码率，主观感受的提升就急剧衰减。这跟游戏里加属性点一模一样：先保证没有短板，再把余粮喂给最显眼的那条属性。

这是第一层最关键的结论，也是最多人算错的地方：ROI 编码不是「把中心做到极致」，而是「把所有区域抬到刚过可见阈值，剩下的全给中心」。前者会让边缘烂穿，后者才是真正的帕累托改进。

那「中心区到底该多大」？这里有个简单的数学。假设 ROI 面积占画面比例为 A，中心与边缘的码率密度比为 k，总码率固定为 1，那么中心区实际能拿到的码率密度是 k 除以（A×k + 1 − A）。代进去看：

看第四行。面积开到一半，你忙活半天，中心只比均匀分配多拿 50% 的码率密度，而边缘却实实在在地掉了一档画质。这就是为什么很多「我们上了 ROI」的项目，用户感知反而变差了——收益没拿到，代价全额付了。

还有个更隐蔽的问题：注意力权重是随时间变化的。你打游戏的时候，视线在准星、血条、小地图、远处敌人之间来回跳。如果一个系统每小时重算一次 ROI，那它平均下来是对的；但如果它每帧重算且没有平滑，ROI 就会在画面里疯狂游走，编码器跟着抖，画质反而比不做还差。这个坑后面单独讲。

第二层：三条实现路径，从「拍脑袋的中心加权」到「盯着你的眼睛」

「如何得到注意力权重」这件事，业内有三种做法，成本、精度、风险完全不在一个量级。

先看固定加权。这是绝大多数团队的第一站——画面上套一个椭圆形或高斯形的权重图，中心权重高，边缘低，完事。零成本、零延迟、零隐私问题。它的隐含假设是「玩家大部分时间在看画面中心」。这个假设在 FPS 和 TPS 里勉强成立，因为准星在中心，敌人通常也在中心附近。但在 MOBA 里就崩了——玩家每一波团战之间都会去瞟一眼左上角的小地图，那是完全独立的第二个注意区。你只做中心加权，小地图就成了「画面里最糊的那块」，而它偏偏是决策信息密度最高的地方。

这就是固定加权的天花板：它其实是在赌「所有游戏的注意力分布长得一样」，而游戏设计的第一课就是它们长得不一样。

真正让这件事有了工业级可行性的，是眼动追踪。这方面必须重点拆一个案例：PlayStation VR2 上的《地平线：山之呼唤》（Horizon Call of the Mountain）。

PSVR2 在每只眼睛前各塞了一颗红外摄像头专门看眼球，把注视点实时报给渲染管线。Guerrilla 和 Firesprite 在这款游戏里用的是分档的注视点渲染：中央一小块全分辨率，中间一圈降到大约一半的像素着色率，外围再降到四分之一。具体分几个环、每环多宽，官方没公开，但从画面观感反推，中央高分辨率区大概覆盖 10 到 15 度视角。配合 PS5 的可变速率着色（VRS），渲染负载能压下来一大截，省出来的算力拿去开更高的材质和阴影。

你得亲自戴上去看才明白那个反差有多大：站定不动环顾四周，画面是通透的，远处的机械兽毛发根根分明；一旦你开始快速转脖子，画面边缘会「刷」地糊一下，等你停下，糊的地方又清晰了。很多玩家的第一反应是「是不是我的头显坏了」，其实是眼动延迟加上面板刷新，在你转头的那几十毫秒里，渲染用的还是旧注视点。

关键在于——这是本地的。眼动数据从摄像头到渲染管线，走的是板上几十厘米的线，延迟个位数毫秒。玩家能感知到的那点瑕疵，来自眼动追踪本身的采样率和预测算法，跟网络一点关系没有。而这个方案一旦搬到云上，所有成本立刻重算。

Meta 那边走的是另一条路。Quest 2 时代因为没眼动追踪，Link 和 Air Link 串流里用的是固定凹视渲染（Fixed Foveated Rendering），玩家在社区里的经典抱怨就是「边缘一圈始终是糊的，像个望远镜」。到了 Quest Pro 加了眼动，云端串流才开始试水动态方案，但实际部署里依然保守——因为一旦眼动数据要走网络，收益模型就完全变了。

第三层：眼动追踪在云端撞上的一道墙，名字叫光速

这一层是本文最想说的话，也是最容易被 PPT 略过的地方。

「眼动追踪 + 云端凹视渲染」听起来是完美的组合拳：玩家看哪，云端就渲染哪，带宽省一半。问题是，从「玩家决定要看哪」到「那一块高清画面出现在屏幕上」，中间要走一条很长的路。把这条路的每一段拆开看：

再看人眼。一次扫视从启动到新目标稳定，20 到 40 毫秒。也就是说，等你把「眼睛刚转到左边」这个消息送到云端，玩家已经在左边看清楚了他想看的，甚至可能已经转回来了。

云端眼动 ROI 的本质是：用 100 毫秒前的注视点，去猜 100 毫秒后的画面。这不是工程问题，这是物理问题。

行业里试过的解法有几条，每条都有硬伤。第一条是预测：眼动仪检测到扫视启动的方向和速度，做线性外推，猜 100 毫秒后眼睛会在哪。听起来聪明，但玩家看东西不是匀速直线运动，一个急停或者回扫，预测直接翻车，而翻车的后果是「中心高清区糊在了错误的位置」——这比不做凹视还难看，因为画面里出现了一块移动的糊斑，人的视觉系统对移动的异常极其敏感。

第二条是加保护带：既然预测不准，那就把高分辨率区做大一点，覆盖住误差范围。问题是这笔账很残酷。假设 100 毫秒延迟下注视点预测误差的标准差是 8 度，要覆盖 95% 的情况得往外扩 16 度。原本 12 度的高清区，加上保护带变成 44 度，面积涨了十倍以上。省下来的带宽全填回去了，收益归零，还白搭了一套眼动硬件和一条上行链路。

第三条，也是我认为现阶段唯一务实的：把眼动从「每帧跟着跳」降频成「粗粒度、慢变化」的区域加权。不问「玩家正盯着哪个像素」，只问「玩家这半秒主要在画面的左半边还是右半边」。ROI 每 200 到 300 毫秒调整一次位置，权重变化用平滑过渡，绝不硬切。这样它抓的是宏观注意力——玩家在看过场动画的哪一侧、在赛车游戏里盯的是哪个弯道——而不是微观注视点。收益会从理论上的 50% 缩水到 10% 到 20%，但它是稳的，不会翻车。

顺便说个我自己的判断：眼动驱动 ROI 在云游戏里最靠谱的场景，其实是企业级的云 XR（培训、设计评审这类），因为那边常常是专网甚至专线，RTT 能压到 20 毫秒以内，物理墙矮了一大截。消费级公网云游戏想用上这套，得先等网络时延再降一个大台阶，而这个台阶不是靠协议优化能迈过去的。

第四层：自动注意力建模，为什么模型总在看错地方

既然眼动追踪在云端被物理墙卡住，那退一步——让算法自己看图，判断「哪里重要」，这就是内容驱动的显著性检测。这条路听着最优雅：不需要额外硬件，不需要上行链路，纯服务端计算。

但把它丢到真实游戏画面上，你会发现模型有一种惊人的、稳定的、每次都犯的错。

原因很直接：绝大多数显著性模型是在自然照片上训练的，而游戏画面是人工构图的。自然照片里，显著的东西通常是高对比、色彩突出、位于构图中——这些规律在游戏里全被设计师推翻了一遍。

最典型的例子是 HUD。血条、蓝条、小地图、技能冷却、任务提示——这些元素被 UI 设计师刻意做成了高饱和、高对比、边缘锐利，因为它们的设计目标就是「抢你的注意力」。显著性模型看到这一屏，会兴奋地把它们全部标红成「超重要区域」。结果就是：ROI 跟着血条跑，画面正中央那个正在朝你冲过来的 Boss 反倒被降了码率。

你说这不是挺讽刺的：UI 设计师花半年时间研究怎么让界面更抢眼，编码器的算法老老实实上当了。

第二个坏消息是时域抖动。相邻两帧的显著性图往往差异很大——镜头一转、特效一炸、粒子一飞，权重图全变。如果编码器每帧都跟着这张图调整，码率分配就会剧烈震荡，宏块级别的 QP 忽高忽低，观感上会出现一种很难描述但绝对能察觉的「画面在呼吸」。用户不会说「你们的 ROI 抖动」，他会说「这游戏画面怎么一直闪」。

第三个是成本。在已经满载的云 GPU 上，每帧跑一次检测模型是奢侈品。降到每 6 到 12 帧跑一次，又跟不上快速镜头运动——《Apex 英雄》里一个滑铲转视角，8 帧就是 130 毫秒，注意力早就换地方了。

所以我的主张很明确：与其训练一个视觉模型去「猜」哪里重要，不如让游戏引擎直接把答案告诉你。

现代引擎里，这些信息全是现成的：UI 层的渲染标记（哪些是 HUD）、深度缓冲（近处物体通常更重要）、运动矢量（快速移动的物体吸引目光）、玩家角色的屏幕坐标、敌人的世界坐标投影到屏幕的位置。这些东西不需要任何机器学习，准确率还 100%。真正困难的不是「怎么算」，而是「怎么说服引擎团队为云版本多吐一路元数据」——这是一场组织协调战，不是算法战。这也是很多云游戏平台和引擎方谈不拢的地方，我见过项目在这上面耗了大半年。

跨类对照可以看 Netflix 的思路。他们做 per-title 编码（每部片子单独分析复杂度、单独定制码率阶梯），从来没有去预测「观众在看画面哪里」。他们的逻辑是：与其猜人看哪，不如把内容本身算清楚。这个思路迁移到云游戏，对应的就是上面说的「让引擎上报语义」，而不是「让 AI 看画面猜语义」。方向对了，成本低一个数量级。

还有一个反直觉的发现，是我自己踩过坑才明白的：不是所有游戏都适合做 ROI。早年我给一个 2D 横版像素动作游戏做云端串流，想当然上了中心加权，测试同学玩了两分钟回头说：「为什么主角的剑边缘一直在抖？」因为那游戏是像素美术，全屏都是硬边和 1 像素宽的线条，任何非均匀处理都会让线条粗细在屏幕上产生周期性变化——这比全屏均匀糊一档难看得多。从那以后我给自己立了个规矩：任何 ROI 方案上线前，先拿视觉上最「刁钻」的那个游戏去测，别拿 3A 大作测。3A 有大量柔和渐变和景深，是最好的掩护；像素游戏和卡通渲染才是照妖镜。

一张能直接抄的 ROI 配置表（含品类模板）

下面这些参数是我根据公开资料、几个项目的实测经验和编码器的一般行为反推出来的建议区间，不是金科玉律，但拿来当起点足够。真要落地，务必用自己的内容跑主观测试。

最后一条特别值得单独说。很多团队做 ROI 只想着「中心给多码率」，忘了看码率控制模式。CBR（固定码率）下，编码器的缓冲区是有硬上限的，你突然给中心区灌一大笔码率，缓冲立刻被吃掉，接下来几秒编码器只能拼命省，边缘区雪崩。用户的体感是：画面每隔一会儿就糊一次，规律得像心跳。这不是 ROI 的错，是模式选错了。做 ROI 必须配 VBR 加峰值封顶，让码率在时间维度上有呼吸空间。

再给一张按品类走的模板，因为「注意力分布」这件事，本质上是设计问题不是技术问题：

这张表的核心意思是：ROI 参数应该跟着游戏品类走，甚至跟着具体某一款游戏走，而不是全平台一套模板。如果你的云平台只有一套 ROI 配置覆盖所有游戏，那你大概率在某些品类上是负收益——只不过没人会告诉你，因为用户流失的原因是「玩着不舒服」，说不出所以然。

双路径：初级用户速览 / 进阶深入

如果你只是想搞懂这事儿在说什么（3 分钟版）

• 一句话原理：人眼只有中心 2 度是真高清，其余靠大脑脑补。所以理论上可以只把码率给中心，边缘糊一点，省一半带宽。
• 一句话现实：边缘糊是会被人看见的，而人看见了就会说「这平台画质烂」，把锅算在云游戏头上，不会算在你的 ROI 算法头上。
• 三条路怎么选：固定中心加权，零成本，适合 FPS 这类准星主导的游戏；内容自动分析，模型容易上当，看见血条就当宝贝；眼动追踪，最准，但在云端被网络延迟按在地上摩擦。
• 最容易踩的坑：ROI 面积开太大。开到画面一半，中心只多拿 50% 码率，边缘却实打实掉一档，纯亏。
• 最反直觉的一条：像素风、卡通渲染这类高锐度美术，做 ROI 往往比不做还难看。3A 大作因为画面柔和，反而是最好的掩护。

如果你要动手实现（工程视角）

顺序建议是这样：先做固定加权，把 RoI 面积和 k 两个参数在真实内容上扫一遍，把收益曲线画出来，看清楚你的内容到底吃不吃这套。这一步花不了几天，但能帮你排除掉一半的品类。

然后接引擎元数据，让游戏侧上报 UI 层标记、玩家坐标、敌人坐标、深度信息。这一步的价值远超任何视觉模型，但在组织上最难推——它需要引擎团队为云版本开一条特供的数据通道。我的经验是：别一开始就要全套，先只要能区分「UI 层」和「场景层」这一个信号，ROI 的准确率就能上一个台阶。

视觉显著性模型可以放在最后，作为兜底。如果一定要用，记住两条：训练数据必须换成游戏截图，别用自然图像；推理频率压到每 8 帧左右，并且给权重图加时间平滑。

验证方法也别偷懒。别只看 PSNR 和 VMAF，那些指标在 ROI 场景里会骗你——它们做的是全画面平均，正好把 ROI 的效果抹平了。要用加权指标，权重来自你的 ROI 图；或者干脆做 A/B 主观测试，让玩家在两个版本里选「哪个更清楚」。你会惊讶地发现，很多人选的不是客观指标更好的那个。

争议与常见坑：ROI 不是万能药，它是个放大器

争议一：商业云游戏平台为什么几乎不宣传 ROI？

我听到过两种解释。一种是「他们做了但不说，因为这是负面卖点——说出来等于承认画面不均匀」。另一种更实在：ROI 做对了用户感知不到，做错了用户直接骂街，宣传风险远大于收益。这个不对称性决定了它在商业上注定是个「藏在引擎里的脏活」，不会有发布会 PPT。

争议二：眼动追踪到底是不是未来？

本地场景我很看好，PSVR2 已经证明了它能实打实换来画质。云端场景我持保留态度——不是技术不够好，是物理规律不让。谁要说 5G 低延迟能解决这个问题，你可以反问他：从眼睛到服务器再回到屏幕，光在光纤里跑一个来回要多久？

FAQ

Q1：我们是个小团队，游戏还没上线，要不要现在就考虑 ROI？

先问自己一句：你的游戏美术是柔和渐变为主，还是硬边像素为主？如果是后者，直接跳过，这事儿对你就是负收益。如果是前者，也别急着做完整 ROI，先把「码率控制从 CBR 换成 VBR」这一件事做了，收益可能比 ROI 还大。ROI 是优化里比较靠后的一环，别本末倒置。

Q2：眼动追踪能不能等 Vision Pro、Quest 4 这波硬件普及了再说？

硬件普及不等于云游戏能用。问题的瓶颈在网络上，不在设备上。你可以这么估：如果端到端往返延迟压不到 40 毫秒以内，眼动驱动的凹视渲染在云端就只能是粗粒度版本。而这个门槛，乐观估计还得几年。所以答案是：可以做技术储备，但别把产品路线图压在它上面。

Q3：ROI 和 AI 超分辨率能叠加吗？

能，而且叠加顺序很讲究。正确顺序是编码端做 ROI 分配，解码端做超分增强，两者互不干扰。但如果超分模型训练时用的全是均匀质量的素材，遇到 ROI 编码出来的画（中心清晰边缘模糊）会产生奇怪的行为——它可能会试图把边缘「修」得更糊，或者反过来在边缘造出不存在的细节。要给超分模型喂 ROI 编码的样本做微调，否则别叠。

Q4：用户投诉「画面中心清楚，边缘一圈模糊」，怎么判断是不是 ROI 的锅？

三步排查。第一步，关掉 ROI 再跑一遍，如果投诉消失，那就是它。第二步，如果关掉后还有轻微模糊，那是编码器本身的位深或者色度采样问题。第三步，如果两种情况下边缘都糊，但那圈模糊区域的位置会跟着镜头动，那就是凹视渲染或者超分模型的锅，跟 ROI 无关。顺序别搞反，不然会浪费好几天。

Q5：如果只能加一个参数来提升感知画质，你会加哪个？

我会加「过渡带宽度」，而不是「中心码率」。因为人眼对突变边界极其敏感，一档平滑的渐变能骗过大多数人，一个硬边界则会被所有人一眼看穿。这也是所有画质优化里最被低估的一条：瑕疵的可接受度，取决于它的形状，而不是它的大小。

最后留个问题给你。如果 ROI 的本质是「按注意力分配资源」，那这个逻辑是不是也能反过来用——不是根据玩家在看哪来决定传什么，而是根据传什么来影响玩家看哪？换句话说，云平台有没有可能通过码率分配，悄悄把玩家的注意力引导到画面的某个区域？这个做法在技术上完全可行，但在体验伦理上，它到底算优化，还是算操纵？我到现在也没想明白，你怎么看。