为什么「选哪套 SDK」是云游戏项目的第一块基石

你有没有过这种经历：在编辑器里把一盏霓虹灯调到满意，颜色、辉光半径、雾的浓度都刚好，然后点开浏览器里的云端画面，那一瞬间你怀疑自己色盲了。红色变成带紫边的色块，暗部的雾变成一圈一圈的台阶，远处招牌上的小字糊成一团彩色马赛克。

这不是你调得不对，是画面在出门前被扒了一层皮。

本地渲染，美术调完是什么样，玩家看到的就基本是什么样，中间只隔着一块屏幕的色彩管理。到了云上，中间凭空插进来三道人：编码器、网络、解码器。这三个人不认识你的美术总监，也不知道这片雾是你熬了两个通宵调出来的。他们只认两件事：码率和时间。你要么给他们更多码率，要么替他们把画面收拾干净。

而「选哪套 SDK」这件事，本质上就是选这三道关卡由谁来把守、你能改到什么程度。绝大多数团队的选型过程是这样的：打开三家官网，看看功能列表都写着支持 4K、支持 WebRTC、支持弹性扩容，然后比价格，选最便宜的。三个月后上线，第一批用户进来，论坛上第一条差评是「画面像十年前的优酷」。这时候你才发现，功能列表上的那些勾，一个都没告诉你画质会在哪里烂掉。

这篇不写参数说明书。我想聊的是三件事：UE 的 Pixel Streaming、Unity 的 Render Streaming、以及 AWS GameLift Streams 这类托管化方案，它们的责任边界到底切在哪里；这条边界线上，哪些是我们做美术和 TA 的人真正会疼的地方；以及在你决定掏钱之前，有哪些数字必须先算清楚。

先说结论，省得你等：这三者根本不是同一层的竞品。UE 和 Unity 那两套是软件栈，GameLift Streams 是基础设施。把它们摆在一起比「谁更好」，就像拿炒锅比燃气灶。真正的问题只有一个——哪一层你自己做，哪一层你花钱买。

第一层：三条路的真正分野，不是功能表，是「谁替你背运维」

先把结构讲清楚，因为后面所有的取舍都是从结构里长出来的。

UE 的 Pixel Streaming是一个引擎内置的插件体系。你在项目设置里勾上它，打包出一种特殊构建，这个构建启动之后不是全屏跑游戏，而是蹲在那里等浏览器来敲门。中间站着一个信令服务器（Epic 官方给了一个用 Node 写的示例，你可以直接拿去部署），负责让浏览器和那台机器牵上手。牵上之后，画面走 WebRTC 出去，前端是一个 JS 播放器库，塞进网页里就是一块视频画布。UE 5.5 之后 Epic 把这套东西重新梳了一遍，也就是现在说的 Pixel Streaming 2，主要解决了一个实例怎么服务多个连接、架构上更清爽的问题。

这条路最舒服的地方是游戏侧几乎不用改。开个插件，加几个启动参数，收工。你的 Lumen、Nanite、后处理堆栈原样出去，渲染和逻辑还是在同一个进程里，不存在「为了上云把画面阉一遍」这种糟心事。代价也很直白：它默认假设你不在乎钱，一个人一台 GPU 实例，一个实例就跑一路。这是给「给客户演示一个汽车配置器」设计的思路，不是给「同时在线五千人」设计的。

Unity 的 Render Streaming走的是另一条哲学。它是一个 UPM 包，底下压着 WebRTC for Unity 这个底层包，官方还给了一个模板工程让你先跑起来看效果。信令服务器官方给了示例实现，但你要真上生产，基本得自己写。这条路的好处是可嵌入——你的项目已经长成什么样了都能塞进去，不用为了串流重开一个工程。坏处是它把所有运维责任原封不动推回给你，而且，官方文档里有一张 WebRTC 包与 Unity 版本的兼容矩阵，那张表是真的会让你疼。

我自己就翻过这个车。项目做着做着，主程说引擎得升一个小版本修个渲染 bug，升完当天一切正常，第二天打开工程，串流模块编译报红一片，报错信息还特别不友好。查了半天是底层包没跟上新版本。最后的选择是：要么不升引擎，要么等包更新，要么自己啃代码改兼容。这事跟技术能力没关系，纯粹是这条路上必须交的过路费。

AWS GameLift Streams 又是另一个物种。2025 年正式可用之后，它把整个链路打包成了三个概念：你上传一个「应用」（能跑的可执行包，Windows 应用可以靠 Proton 兼容层跑在 Linux 上），配一个「流组」（指定地域、GPU 档位、最大容量），用户连进来就开一个「会话」。信令、编码、传输、弹性扩缩容，全在平台里面。你唯一需要操心的是那个应用包本身。

听起来很美好对不对？先别急，往下看第三层。

看这张表你会发现一件事：定制深度和运维负担是一根绳上的两头，你不可能两头都占。而做美术的应该特别敏感一件事——画质手感恰恰落在「定制深度」那一侧。码率给多少、关键帧多久一个、抖动缓冲留几帧、锐化开不开，这些直接决定玩家眼睛里那幅画长什么样，而它们全都是「可调参数」。托管平台替你把这些螺丝拧紧了，你得到的是省心，失去的是画面。

第二层：画质链路——美术预算真正被吃掉的地方

这一层是本文的重点，因为我发现市面上讲云游戏 SDK 的文章，几乎没有一篇是从「画面到底怎么烂的」角度写的。大家都在聊延迟、聊并发、聊成本，好像画质是个附赠品。但对很多品类来说，画质就是留存率。

先把链路摊开：你的渲染结果是一张 8 位、每像素三通道的图，编码器把它从 RGB 转成一个亮度通道加两个色度通道，然后把色度通道砍掉一半分辨率（这就是常说的 4:2:0 色度采样），压缩，打成包发出去。砍这一刀的依据是人眼对亮度敏感、对颜色迟钝。这个假设在拍风光片的时候成立，在玩游戏的时候经常不成立。

出血点一：高饱和色块的边缘渗色。4:2:0 意味着颜色的分辨率只有亮度的四分之一。你觉得这没什么，直到你把一个纯红色的血条放在深色背景上——红色边缘会渗出紫色或橙色的毛边。赛博朋克风格的场景是重灾区，霓虹粉、霓虹青、饱和红大面积堆在一起，低码率下就是一锅彩色粥。我见过一个团队为了这个把整套 UI 的饱和度整体压了 15%，美术总监气得三天没跟技术说话。后来他们换了个思路，把纯色改成带细微噪点纹理的近似色，问题解决了一大半，画面还更有质感了。这算是被逼出来的好设计。

出血点二：暗部渐变变成台阶。8 位色深在暗部本来就只有很少的灰阶可用，编码器的量化再一压，夜间雾、体积光、天空盒渐变就变成一圈一圈的等高线。这个在写实风格的游戏里极其刺眼，因为写实风格最依赖的就是柔和的明暗过渡。

出血点三：高频细节变成蠕动。草、雨丝、粒子、胶片颗粒，这些在本地看是「细节」，在编码器眼里是「噪声」，是最先被牺牲的东西。牺牲的方式有两种：要么糊掉，要么变成一块一块的色块，而且因为每帧的块位置不一样，看起来像有东西在画面里爬。

出血点四：TAA 留下的后续问题。抗锯齿的亚像素抖动在本地是好事，画面更平顺。但抖动意味着相邻两帧有细微差别，编码器会认为这是运动，花掉额外的码率去描述它，结果就是「静止画面也在吃码率」。很多团队发现流里画面比本地模糊，查了半天不是编码器问题，是把抗锯齿开太狠了。

讲三个真实案例，看看这些理论在玩家眼里长什么样。

《赛博朋克 2077》在 GeForce NOW 上。这是观察云游戏画质问题的最佳样本，因为它的美术选择把每一个出血点都踩满了：夜之城的霓虹、雨夜街道、全息广告、大面积暗部加高饱和光源。在 GFN 的高档位（RTX 4080 级别、AV1 编码、4K HDR）上，这套东西是能看的，社区里对画质的评价也普遍正面；但切到免费档，1080p 加相对保守的码率，社区里最常见的抱怨就是「夜景糊成一片」「雨丝看起来像贴图撕裂」「广告牌上的字看不清」。有意思的是，同一个游戏在同一个平台上，白天场景的观感明显好于夜晚——因为白天是低对比、低饱和、大面积平滑渐变，正好是编码器最擅长的题型。这说明一件事：云游戏的画质不是均质的，它是随内容复杂度剧烈波动的。你不能用一个「支持 4K」的标签概括它。

《微软飞行模拟》在 Xbox Cloud Gaming 上。这个案例几乎是为「小字号 UI」量身定做的反面教材。飞行模拟的座舱仪表盘上全是小字号数字和细刻度线，本地 4K 下清晰可读，串流到 1080p 之后经常变成一片模糊的白色斑点，玩家得靠记忆判断高度。地面纹理更惨，从高空看下去本来是大面积低细节，问题不大，一旦降低高度，机场跑道标线、建筑窗格这些高频细节立刻开始「沸腾」。这个案例告诉我们，UI 和 HUD 的设计必须为串流单独做一版，不能直接用本地的排版。

反过来看《云·原神》。这个案例特别值得美术琢磨，因为它是证明「风格决定抗压能力」的最好证据。卡通渲染的画面特征是：大色块、硬边缘、少噪点、渐变短、几乎没有写实材质的高频细节。这恰好是编码器最喜欢的题型。所以同样是低码率，云·原神的观感衰减远比写实 3A 温和，玩家抱怨的更多是远景糊和加载，而不是「画面烂」。这不是技术优势，是美术风格带来的天然带宽红利。

那美术侧能做什么？能做的比你想的多。给一份我实际用过的清单：UI 最小字号在 1080p 输出下不要低于 20 像素，描边至少 2 像素且用深色不用黑色；大面积高饱和色不要用纯色，加 5% 到 10% 的明度抖动或者一层淡淡噪点；暗部不要压到最黑那几档，整体提亮一点点，牺牲一点对比度换掉台阶；所有长渐变加抖动处理；胶片颗粒、暗角、色差这些全屏后处理要么做成可关闭，要么强度砍半。

我印象最深的一次，是帮一个团队改云端 UI。他们在论坛上被骂「字看不清」，第一反应是加码率，加了三成，投诉少了但成本涨了。后来我们把正文字号从 18 加到 22、把 1 像素描边改成 2 像素、把纯红血条换成偏橙的红，码率调回原来的值，投诉量掉了一半多。这件事让我确信：云端画质优化，一半的活儿在美术这边，不在带宽那边。

第三层：托管化的甜与苦——GameLift Streams 给你什么，拿走了什么

现在回到选型。如果你是个独立团队，或者是个非游戏行业但要做交互展示的团队，「自己搭一套」这件事的诱惑力其实不大。你要买机器、写扩缩容、维护信令、配 TURN 服务器、被 DDoS 打的时候自己扛。GameLift Streams 这类托管方案最大的价值就是把这堆东西一次性拿走。

它给你的东西很实在。你不用管信令，不用管会话管理，不用管机器挂了怎么迁移，不用管高峰期怎么加机器。你只要把打好的包传上去，选一个 GPU 档位（入门档的定位大致是 1080p 六十帧，往上是更强的卡，也能声明一个实例跑多路流），选地域，然后就有一个可以连的地址了。对一个五个人以内的团队来说，这个省心程度值得花钱。

它拿走的东西也很实在，而且是那种你在签合同之前不会意识到的。

第一，编码参数基本摸不到。码率、关键帧间隔、速率控制模式，这些在 UE 的 Pixel Streaming 配置面板里是明明白白摆着的旋钮，在托管平台上变成了「档位」。档位之间的差距可能是断崖式的：你可能发现某个档位对你这游戏来说码率不够，但下一个档位又贵得离谱，中间没有过渡。

第二，拥塞控制和抖动缓冲策略是黑盒。这两个东西直接决定「网络差的时候画面怎么烂」——是降分辨率、是降帧率、还是卡住等。三种策略对玩家的感受完全不同。自建的时候你可以按自己的游戏类型调，比如格斗游戏宁可掉画质也不能掉帧，反过来某些慢节奏游戏可以接受短暂卡顿。托管平台是一套策略服务所有客户。

第三，出问题时你没有可观测性。玩家说「糊」，你只能看到平台给你的那几个指标。是自己画面太重？是客户端网络差？是某个地域节点的问题？这些在自建链路里看一眼日志就知道的事，在托管里得靠猜和提工单。

对比一下 Unity 生态里的 Furioos 这类云渲染平台，你会看到另一种取舍。它把 Unity 工程的云端部署做得很顺，上传工程、选机器、出链接，几步搞定，对建筑可视化、工业展示、以及一部分游戏 Demo 的云试玩非常友好。但你同样会遇到那个老问题：它替你决定的那部分，正好是你最想改的那部分。而且这类平台往往还绑着引擎版本、渲染管线的一堆前提——用了自定义 Shader 或者特殊后处理，能不能跑通要试了才知道。

我的建议很直白：如果你做的是「给客户看的展示」或者「云试玩 Demo」，托管方案闭眼上，别自己造轮子。如果你做的是「要长期运营、要靠画质口碑留人的游戏」，先把自建链路的成本算明白，再决定要不要把命门交出去。中间地带也存在：用 UE 或 Unity 的软件栈自己搭，但把 GPU 和弹性扩容交给云厂商的基础设施层，这样编码参数还在你手里。

第四层：并发与扩缩容——从「能跑」到「能开张」的距离

前三层聊的是画面，这一层聊的是命。

云游戏和普通 Web 服务最大的差别在于：它不能慢慢启动。一个网页请求多等两秒，用户还在。一个游戏流请求多等二十秒，用户已经去刷短视频了。而一台云游戏实例的冷启动包含什么？拉镜像、起容器、启动游戏进程、加载引擎、加载关卡、初始化渲染管线、等第一帧稳定。这一套下来，三十秒是乐观估计，两分钟不稀奇。

所以所有做云游戏的人最后都会走向同一个答案：预热池。提前把机器起好、游戏跑起来、停在主菜单等着，用户点进来直接连，首帧能压到三到八秒。代价是这些机器在你没有用户的时候也在烧钱。

这里有一笔账，我觉得每个项目负责人都该手算一遍：

常驻方案的成本 = 峰值并发机器数 × 单价 × 二十四小时。
按需方案的成本 = 实际流小时数 × 单价 + 冷启动流失率 × 单个用户获取成本。

很多人只算前面两项，忘了第三项。而第三项往往是决定性的。假设你的获客成本是二十块，冷启动导致百分之十五的人第一次点进来就走了，那这一千个新用户你就白扔了三千块。把这三千块摊到机器成本上，很多时候你会发现「多养几台热机器」反而更划算。

我见过一个团队在这件事上翻车的完整过程。他们为了省钱，做成纯按需启动，冷启动平均五十秒。上线首周数据还行，因为是种子用户有耐心。第二周开始投量，转化率惨不忍睹，一看漏斗，百分之四十的人卡在加载页。他们后来改成常驻二十台，成本涨了，但转化率回来了，整体是赚的。这个故事没有技术含量，纯粹是算账顺序搞反了。

再说扩缩容的响应速度。这个词在宣传材料里很空，实测起来就三个数：从「检测到需要扩容」到「新机器可以接客」要多久；从「用户点击开始」到「看到第一帧」要多久；以及流量掉下来之后机器多久回收。第一个数决定了你能不能扛住突发，第二个数决定了转化率，第三个数决定了你的账单。托管平台通常把第一个和第三个做得比较好，第二个取决于你有没有用它的预热能力。自建方案三个都能调，但三个都得自己写。

还有一个容易忽略的点：单实例跑多路流是省钱利器，也是画质杀手。一张卡跑两路流，两路渲染互相抢 GPU 时间，帧时间开始抖。而帧时间抖动在云游戏里会被放大——本地抖一下你可能感觉不到，云上抖一下，编码器拿到的帧间隔不均匀，压缩效率下降，画面开始出现周期性的糊和卡。这一条在上一篇文章聊引擎适配的时候提过，这里再强调一遍：省钱省到帧时间不稳定，是捡了芝麻丢了西瓜。

一张能直接对着调的配置表

下面这张表是我自己项目里用过的起步值，不是金科玉律，但能让你少走两轮弯路。所有码率都是指恒定码率模式下的目标值，分辨率指输出给客户端的流分辨率。

再给一张「美术侧降码率求生清单」，这个比调参数见效快得多：

双路径：你是哪一类读者，从哪儿下手

初级路径（刚接触云渲染，想快速出个能看的东西）

如果你手上有 UE 工程，去项目设置里找到像素流那一页，先把默认码率改了——它给得相当保守，一兆每秒这个量级的默认值，你没动过它，画面糊是应该的。改成 12 到 15 兆，分辨率按 1080p，重新打包，找台带显卡的机器跑起来，浏览器连上去看效果。这一步能解决你八成的「怎么这么糊」的困惑。

如果你手上有 Unity 工程，先确认引擎版本和 WebRTC 那个底层包是否对得上，官方文档有兼容表，对不上就别往下走，先解决版本。然后拿官方模板工程跑通一遍，再往自己项目里搬。别一上来就往自己的正式工程里塞，模板跑通了再动，能省你两天。

如果只是想验证「云上能不能跑我的游戏」，别自己搭，直接上托管平台。传包、选档、出链接，半天搞定。先用它把内容侧的坑试出来——UI 能不能读、暗部会不会崩、加载要多久——这些东西跟平台无关，等你以后迁走也是要改的。

进阶路径（要做长期运营，得自己把控画质链路）

先做一件事：把你的游戏画面按「编码器友好度」重新审一遍。挑三个代表性场景——最暗的、最花的、UI 最密的——在目标码率下看它们怎么烂。这三个场景会告诉你项目真正的码率底线在哪，比任何测试报告都准。

然后测首帧。不要测「平均首帧」，要测「百分位」——第九十个百分位是多少秒。平均值好看但长尾很长的系统，用户体验是灾难性的，因为用户记住的永远是他等得最久的那次。

再然后算那笔账：常驻多少台能覆盖你峰值的一天里的多少比例。我的经验是，覆盖百分之七十到八十的峰值通常是最优点，剩下的靠排队和临时扩容兜底。全覆盖太贵，覆盖太少转化率崩。

最后，如果你的团队有 TA 资源，去啃一遍编码参数和拥塞控制策略。这块的知识回报率极高，因为它是那种「改一次管一年」的投入。反过来，如果你没有这个资源，就老老实实接受托管的黑盒，把精力全押在美术侧的降码率优化上——那条路的性价比比任何一个参数都高。

争议与常见坑：几个我见过太多次的误区

还有一个争议我想单独说：自建到底值不值？行业里有两派。一派认为云游戏的技术门槛正在被托管平台抹平，自己搭就是浪费钱；另一派认为画质和延迟的护城河恰恰藏在自建链路里，托管永远做不出差异化。我的看法偏中间，但有个明确的判断标准：如果你的竞争力包含「画面比别人好看」，那就必须有定制能力；如果你的竞争力是「内容比别人好玩」，那就把钱省下来做内容。别为了技术自尊心烧钱，也别为了省事把命门交出去。

FAQ

问：我们是 Unity 项目，是不是注定画质不如 UE 那套方案？

不是，这是个流传很广的误解。串流的画质上限主要由编码参数、码率、以及内容本身的抗压能力决定，引擎只决定「渲染出来那一帧有多好」。一个做了美术优化的 Unity 项目，在同样的码率下完全可能比一个堆满后期特效的 UE 项目观感更好。Unity 那条路真正的麻烦在工程侧——版本兼容、运维责任、底层包的黑盒程度——不在画质天花板。

问：为什么我在 4K 显示器上看着比 1080p 屏还糊？

因为流本身还是 1080p，到了 4K 屏上被放大了一层，而浏览器的缩放算法通常不带锐化，放大的结果就是软。同理，在手机上用小窗口看同一个流会觉得特别清晰。如果你想真的用上 4K，先确认三件事：码率给够了吗（四十兆起步）、客户端解码扛得住吗、以及你的内容有没有那么多细节值得这个码率。三者缺一，上 4K 就是纯亏。

问：自建和托管，什么规模是分水岭？

我的经验是看两件事：你有没有专职的运维或后端，以及你的并发曲线是不是有剧烈尖峰。有专职的人、曲线平稳，自建划算；没专职的人、或者尖峰明显，托管省心。中间态是最常见的：用引擎的软件栈自己搭串流层，把 GPU 和弹性扩容交给云厂商的基础设施。这条路麻烦一点，但编码参数还在你手里。

问：单实例多流到底能不能省到钱？

能省，但有前提。前提是你的游戏在 GPU 满载的时候帧时间依然稳定。很多项目一做多流就出现周期性卡顿，原因是两路渲染互相抢资源，帧间隔开始抖，编码器压缩效率下降，然后就进入恶性循环。真要上多流，先做压力测试，看帧时间的第九十九百分位，别看平均值。

问：现在要不要上 AV1？

看你的用户在哪。AV1 在同画质下确实能省下可观的码率，服务端编码也不是问题了，真正的瓶颈在客户端解码——低端安卓机、老笔记本的硬解支持参差不齐，软解又吃 CPU 吃电。比较稳的做法是双编码并行，能解 AV1 的走 AV1，不能的退回上一代，代价是服务端要同时准备两路编码，机器成本上去了。这笔账得自己算。

最后一个问题留给你自己想：如果明天所有云游戏平台都把默认码率翻一倍，你的画面问题会消失吗？我的答案是不会——因为大部分「云上难看」的问题，根子在我们自己做画面的时候，从来没把「这一帧要经过一次有损压缩」这件事算进去。带宽会涨，编码会进步，但美术选择造成的信息量差异永远存在。这个认知，可能比选哪套 SDK 重要得多。