云游戏里的超分辨率，最容易被问成一个二选一的问题：放服务器还是放手机？真正的麻烦在于两边都有道理，而且它们各自省下的是不同的东西。服务器端超分省的是传输和画面质量的一致性，客户端超分省的是服务器的 GPU 时间，并且直接吃玩家自己的电池。把六个变量摆到一起：服务器 GPU（Server GPU）、客户端 NPU（Client NPU）、带宽（Bandwidth）、延迟（Latency）、电量（Battery）和成本（Cost），才能看出选择的逻辑。
两种部署的信息量不一样
先看数据。服务器上跑超分，输入是引擎内部的东西：低分辨率的颜色、深度、运动向量，以及 UI 与 3D 场景分开的图层。这是最理想的输入，因为超分模型知道哪些像素在动、往哪动。客户端上跑，输入通常只有解码后的视频帧，运动信息只能靠估计，UI 已经和画面压在一起，超分看到的是一张“已经压缩过的图”。同样的模型，在这两种输入下表现可能差得很远。这一点和超分辨率为什么在 UI 和高速移动上露馅直接相关：客户端超分越晚介入，信息丢得越多。
服务器端：省像素，但不一定省钱
金沙娱乐在讨论云游戏服务器渲染多少像素时的思路是：把渲染分辨率降下来，用超分补回来，让每块 GPU 服务更多玩家。但这里有个容易被忽略的账：超分本身也吃 GPU。假设原生 4K 渲染需要一份算力，先渲染较低分辨率再超分，节省的部分要扣掉模型推理的开销，净收益取决于模型多重、分辨率比例多大。更关键的是，超分后的 4K 画面仍要编码传输，码流并不会因为你少渲染了像素而变小。也就是说，服务器端超分省的主要是渲染成本，不是带宽。
客户端：省码流，但要过设备这一关
反过来，服务器只渲染并编码较低分辨率，玩家设备解码后再超分，能同时省下渲染成本和码流。代价落在设备上：神经处理单元（NPU）要不要跑得动、每帧推理占多长时间、连续玩一小时电池掉多少、机身会不会发热降频。近来的趋势正在让这条路变得更可行：Arm 已经公布了神经超采样（Neural Super Sampling，可从 540p 上采样到 1080p）、神经帧率上采样（30 到 60fps）以及超采样与降噪结合的方案，Mali G2-Ultra 首次把 AI 神经处理放进 Arm 移动 GPU；高通的 Adreno Neural Fusion 则把神经处理、AI 超分和帧生成整合进同一条图形管线，Imagination 也发布了面向移动端的 NSR 超分。神经处理离图形管线越近，客户端跑超分的能耗与延迟就越可控。但要注意，这些方案大多面向本地渲染的游戏，云游戏能否直接使用，还要看是否能拿到运动向量这类附加信息。
延迟预算该怎么拆
云游戏的延迟是一条链：输入上传、服务器渲染、编码、网络传输、解码、显示。超分放在哪里，就会在哪一段多出几毫秒。假设端到端预算是 80 毫秒，服务器超分在渲染之后增加一段推理时间，客户端超分则在解码之后增加一段。两者的总量相近，但客户端超分的耗时受设备波动影响，服务器的则相对稳定。另外要区分帧生成：DLSS 4 的多帧生成可以把 30fps 的渲染帧合成为 90 到 120fps 的观感，这提升的是视觉流畅度，基础帧率和输入响应并没有同比提升，参见帧生成与操作延迟的讨论。放在云游戏里，服务器渲染帧率决定响应，客户端帧生成只改善观感。
按场景选择的决策表
| 场景 | 倾向位置 | 理由 |
|---|---|---|
| 网络稳定的电视或主机，追求画质一致 | 服务器超分 | 输入信息完整，设备无需承担推理 |
| 弱网络的手机，带宽紧张 | 客户端超分 | 服务器只传较低分辨率，节省码流 |
| 低电量或发热明显的设备 | 服务器超分或关闭客户端增强 | 避免设备持续高负载 |
| 竞技类、高速移动为主的游戏 | 服务器超分，谨慎使用帧生成 | 需要运动向量，响应优先 |
| 服务器高峰期算力紧张 | 客户端超分 | 把推理成本转移到用户设备 |
更现实的做法：分层与自适应
把两种方案做成互斥选项，往往不如做成分层组合：服务器端做需要引擎信息的部分，比如运动向量参与的时域超分和 UI 分层；客户端做轻量的收尾，比如锐化和最后一档放大。再根据设备能力、电量和网络状况在会话开始时以及中途自动切换。金沙娱乐更倾向的设计是：先探测设备的 NPU 能力与电量，再决定客户端承担多少，探测失败或电量偏低时，退回服务器方案。
判断一个方案好不好，可以看五个数字：单位并发玩家的服务器 GPU 成本、平均码流、端到端延迟的 95 分位、设备连续游玩一小时的电量消耗，以及玩家在动态场景中看到伪影的频率。任何只汇报“平均画质提升”的方案，都不足以回答云服务器还是玩家设备这个问题。
