为什么延迟是云游戏的第一块基石

我经历过一次挺尴尬的复盘。编码组花了两个月，把服务端的编码延迟从 13ms 压到 5ms，庆功饭都吃了。一周后用户调研回来，热评第一条四个字：“还是有点飘。”

老板拿着报告问：你们不是说优化了 8 毫秒吗？

问题就在这儿。8ms 放进一条总长 130ms 的链路里，占 6%。而且玩家压根感知不到“编码延迟”这种孤立的东西，他感知的是“我按下跳跃，角色什么时候起跳”。这中间隔着七个环节，你优化的是其中一个，还是偏短的那个。

所以这篇文章我想讲清楚一件事：延迟是加法问题，不是乘法问题。加法意味着，你砍最短的那一段，账面好看，手感不动；加法也意味着，你永远得去砍最长的那一段——而最长的那一段，大概率不在你以为的地方。

先抛三个可能让你不太舒服的判断，后面慢慢拆：

• 云游戏延迟的大头，往往不在网络，在服务端渲染和显示设备。很多人家里的电视，输入延迟 30ms 起步，比你整个网络往返还贵。
• 厂商宣传的“40ms 延迟”，绝大多数说的是网络往返。和玩家体感的端到端延迟差 3 到 5 倍。这不是撒谎，是两套语言。
• “云游戏能不能玩某类型”这个问题本身没答案。回合制和竞技射击的容忍阈值差了七八倍，你把它们放一个问题里讨论，永远吵不出结果。

这三条如果只能记住一条，记第一条。因为它能解释你 80% 的困惑：为什么我们技术指标都达标了，玩家还是说卡。

第 1 层：把“延迟”这两个字拆成七个能测量的数字

圈内说“延迟”，其实在不同场合指代完全不同的东西。产品经理说的是端到端体验，网络工程师说的是 RTT，引擎程序员说的是帧时间，玩家说的是“手感”。这四个词之间能差五倍。所以第一步不是优化，是统一语言：把整条链路切成七段，每段都能单独测、单独定预算。

加一下：理想情况 50–70ms，普通家用 90–130ms，网络糟糕或者电视没调好，200ms 往上。这就是玩家真实拿到手的东西。

挨段说几个外行容易忽略的点。

第 1 段，手柄。很多人没意识到，云游戏下你的手柄要走两段无线：手柄到手机蓝牙（10–20ms），手机到服务器。蓝牙那段的延迟，比你想象得贵。同一台手机，插有线手柄能省一半。这就是为什么硬核云游戏玩家会专门买个 OTG 线。

第 2 段，光速。光纤里光速大约 20 万公里每秒，1000 公里单程 5ms。北京到广州直线 2100 公里，理论单程 10.5ms、往返 21ms，但实际加上路由绕行、跨网互联、排队，经常跑出 35–50ms 的往返。所谓“边缘节点”，本质上就是在跟这段物理定律讨价还价，这也是第 05 篇要专门算的账。

第 3 段，排队。这段最容易在设计阶段被漏掉。会话刚建立、虚拟机冷启动、GPU 池排队，都可能突然跳出十几毫秒。Stadia 早期的“排队进场”就是这段的极端版本，只不过它排的是分钟级。

第 4 段，渲染。这段通常是最大的一块，也是最容易被无视的一块。帧率直接决定下限：60fps 一帧 16.7ms，引擎从采样输入到出画面通常还要再压 1–3 帧，所以实际是 33–50ms；30fps 直接翻倍。后面讲 xCloud 换刀片，就是这段的病根。

第 5 段，编码。硬编和软编差一个数量级。GPU 硬编在最低延迟预设下能压到 3–5ms，代价是画质效率。这段的调优空间和代价会在第 2 层细讲。

第 6 段，下行。很多人以为下行带宽大就没问题，其实下行的拥塞比上行更常见——家里有人同时在刷 4K 视频，你的云游戏帧就在路由器队列里慢慢排队。

第 7 段，显示。这段是玩家最容易忽略、平台最容易甩锅的一段。一台没开“游戏模式”的 4K 电视，输入延迟 40ms 很常见，高的能到 60–80ms。你现在拿它玩 PS5，也是这个延迟，只是你从来没测过。但云游戏一出问题，玩家第一反应就是“云不行”。

记住这个结构：七段求和。玩家体感 = 七段之和，不是某一段。你手里的技术指标如果只覆盖了第 5 段，那它和玩家体验的相关性约等于零。

第 2 层：七段里哪几段你真能动手，哪几段动不了

把七段摆出来之后，第一件事不是挨个优化，而是认清哪些是你的地盘。第 1 段和第 7 段在玩家手里，第 2 段和第 6 段在运营商和物理定律手里。平台真正能碰的只有第 3、4、5 段，其中第 4 段还受游戏引擎牵制。

按投入产出比排个序，我个人的经验排序是这样的：

第一名：显示端（第 7 段）。让玩家把电视切到游戏模式，等于白捡 30–40ms。这是整条链路上性价比最高的一刀，但完全不归平台管，只能靠产品引导。我见过做得好的平台会在首次启动时跑一个“延迟体检”，把用户的电视型号、是否开游戏模式、Wi-Fi 信号强度过一遍，给出一个预估的端到端延迟。大部分用户直接跳过。做不做是产品问题，不是技术问题。

第二名：服务端帧率（第 4 段）。把 30fps 提到 60fps，渲染段直接省 16–33ms。这是所有优化里幅度最大、最确定、最不依赖运气的。xCloud 换刀片就是靠这一刀起死回生的，后面细说。

第三名：输入采样时机（第 4 段内部）。行业里叫 late-latching，意思是把输入采样放到渲染提交前的最后一刻，而不是帧开始时。玩家在那一帧内多按的那几下，就能被塞进当前帧，而不是等下一帧。格斗游戏早就这么干了，云游戏是顺理成章地继承。

第四名：编码器低延迟预设（第 5 段）。关 B 帧、关 look-ahead、GOP 缩短、用最低延迟档。能省 3–8ms，代价是码率效率降 20–40%，同画质你要多给一截带宽。这笔账要算进整体带宽预算里，不能只看延迟数字好看。这也是第 02 篇和 06 篇交叉的地盘。

第五名：渲染队列深度（第 4 段尾部）。减少缓冲帧数，能省 1–2 帧。代价是帧时间抖动更容易暴露成卡顿。这就是第 15 篇说的“云游戏放大帧时间不稳定性”——你为了省 16ms 把缓冲砍掉，可能换来的是玩家每十秒感受到一次抽搐。这笔买卖不一定划算。

第六名：网络选路（第 2、6 段）。你能做的主要是选对节点、做好就近接入，这属于第 05 篇的战场。在同城节点下，你能优化的空间也就几个毫秒。

然后我要讲一个大家特别爱提、但机制上其实很尴尬的东西：Reflex。

NVIDIA Reflex 在本地游戏里的原理，是让游戏引擎主动等待 GPU 追上来，同时把 CPU 和 GPU 的工作节奏对齐，减少渲染队列里积压的帧。在本地，这是一套端到端机制，能实打实砍掉 20–40ms。

但到了云游戏，这套机制的一半直接失效了。因为 Reflex 需要客户端的渲染管线参与——它要知道“玩家的输入什么时候到、GPU 什么时候画完”，然后动态调整。云游戏的客户端根本没有渲染管线，只有一块屏幕和一个解码器，它唯一能做的是“等一个已经画好的帧”。所以所谓的“云端 Reflex”，只能优化服务器内部那一截队列，省下的 1–3 帧扔进 130ms 的总链路里，基本就是背景噪音。

我说这话不是要贬低 NVIDIA。GeForce NOW 真正做对的事是另外三件：节点铺得密、编码器调得激进、游戏跑在能稳 60fps 以上的硬件上。这三件事加起来比任何花哨的低延迟技术都管用。这也印证了那个排序：先解决大头的段，再谈精细活儿。

最后是一个特别常见的工程自欺，我要单独拎出来说。

优化你最容易优化的那一段，而不是最长的那一段。编码器是软件，参数在自己手里，说改就改，一天能出十个版本；服务端换硬件要采购、要排期、要谈预算；玩家电视开不开游戏模式你根本管不着。于是所有人都不约而同地去优化编码器。这就是开头那个 13ms 压到 5ms 的故事。

但人的感知是非线性的。130ms 里砍掉 8ms，低于感知阈值，玩家真的感觉不到。同样这 8ms，如果你是从 40ms 砍到 32ms，在一台 240Hz 显示器的竞技玩家手里，那就是能感觉到的。所以正确的做法不是“哪里能改就改哪里”，而是先把七段测出来，找到最长的那根，然后想办法砍它——哪怕它归别人管，你至少可以去推动、去谈判、去在合同里写清楚。

第 3 层：三种测量法的原理、精度和各自的坑

延迟这个话题之所以常年吵架，一半原因是没有统一的测量口径。行业里主流有四种测法，测的是四种不同的东西。

高速摄像机法。原理朴素得可爱：用一台高帧率相机，同时拍下两件事——你手指按下的那一瞬间，和屏幕上角色开始动的那一瞬间。然后数中间隔了几帧。

精度取决于相机帧率。240fps 的相机每帧 4.17ms，理论误差 ±4ms；1000fps 的机器每帧 1ms，误差能压到 ±1ms。Digital Foundry 那帮人就是买了台千帧机、搭了个暗室架子，专门干这个，他们的公开数据集是业内最靠谱的来源之一。

局限也很明显。第一，它只能测端到端总数，拆不开内部分量——你知道是 120ms，但不知道这 120 里网络占多少、渲染占多少。第二，人的动作本身有抖动，按一次不准，得拍几十次取中位数和分布。第三，判定标准是主观的：屏幕上哪个像素变化算“开始动”？暗部变化和亮部变化不一样，不同游戏也不一样。第四，慢动作回放里那两帧的边界，不同人可能数出不同的结果。

闪光灯注入法。NVIDIA 的 LDAT 是这套的典型代表：鼠标里塞一个光电传感器，对准屏幕某个固定区域；你点击的瞬间，鼠标发出一个电信号；屏幕亮度变化被传感器捕捉到，发出另一个信号。两个信号的时间差就是延迟。

这套方法的优点是便宜、可重复、能自动跑几百次取分布。因为它比对的是电信号，精度能到 ±1ms 甚至更好。现在电竞显示器和外设评测基本都靠它。

局限呢？第一，只能测点击类输入，摇杆的模拟量、触屏的滑动手势都测不了。第二，传感器必须贴在屏幕固定位置，那个位置的画面必须有明显亮度变化，不然抓不到。第三，得针对面板类型做标定——LCD 的灰阶响应本身就要几毫秒到十几毫秒，OLED 快得多，你不标定，测出来的数字里混着面板的账。第四，也是最关键的一点：它测的是“屏幕亮了”，不是“人眼看见了”。这两者之间还隔着人眼的积分时间和大脑的处理延迟。

硬件探针法。在 HDMI 输出、USB 线路、网络链路上插探针或者逻辑分析仪，抓帧序号和时间戳，把整条链路拆开。这是唯一能告诉你“这 130ms 里，网络 40、渲染 50、编码 8”的方法。

它的命门是时钟同步。服务器和客户端的时钟差 5ms，你的分解结果就全废了，而且你还看不出来——它只是安静地错了。要做得准，得上 PTP 级别的同步，这不是一般团队玩得起的。另外，抓包本身会引入额外开销，你在测量的时候其实在扰动被测对象。所以这套只能在自建环境里用，测不了竞品，也测不了真实用户。

第四种，客户端打点。在客户端和服务器各埋一些时间戳，回传汇总。成本最低，所有平台都在用，能看到网络往返、卡顿率、断流率这些运营指标。但它受时钟同步误差影响，精度差，而且只能覆盖到它能打点的那些段。

这四种方法测的是四样东西。所以看到任何一个延迟数字，先问一句：是 RTT？是单程？是输入到屏幕？还是服务器内部？这四个数能差 5 倍。这不是技术问题，是话术问题。你今天看任何云游戏的延迟宣传，都得先在脑子里做这道换算。

还有一个测量上的大坑，比口径问题更隐蔽：平均值 vs 长尾。

云游戏最伤的体验从来不是“平均 80ms”，而是“平均 80ms，但每 20 秒来一次 300ms 的尖峰”。玩家骂的永远是那个尖峰。所以延迟指标必须是分布，得看 P95、P99，甚至 P99.9，只看均值等于自欺。这条和第 09 篇讲抖动丢包是同一个道理：稳定比快更重要，因为人的肌肉记忆建立在稳定上，而不是建立在平均值上。

第 4 层：没有“云游戏延迟阈值”这回事，只有品类阈值表

“云游戏延迟多少才能玩？”这个问题问错了。正确的问法是：“你的游戏延迟多少才能玩？”因为不同品类的容忍阈值能差七八倍。

先统一口径：下表全部指端到端，输入到屏幕，不是 RTT。

为什么差这么多？根子在玩家的肌肉记忆是怎么建立的。

竞技 FPS 玩家在本地 240Hz 显示器上训练，输入到屏幕 8–12ms。他的每一次甩枪，都是围绕这个时间微调出来的。你给他 60ms，等于让他重新学走路的节奏。而回合制玩家根本不在信息通路上，他点完等三秒都不影响。

格斗更极端。一帧等于 16.7ms，很多连招的确认窗口只有 2–3 帧。延迟一大，帧数表整个失效，你背的连段全部打不出来。

但这里有个反转：游戏内部的补偿机制，可以改写阈值。

典型代表是格斗游戏的回滚网络。它的原理是：本地先执行你的输入，如果对手的输入晚到了、而且和你的预测不一致，就回滚到过去的那个时刻重新模拟一遍。玩家看到的是“对手偶尔瞬移一下”，网络延迟在体感上被压得接近本地。代价是画面偶尔要跳，而且在网络上行的稳定性差的时候会跳得很凶。

这套思路云游戏也能借，而且有人真的借过头——这就引到我今天想细讲的第一个案例。

案例一：Stadia 的 Negative Latency，一个被话术反噬的技术愿景。

2019 年 GDC，Google 宣布 Stadia 的时候抛出一个词：Negative Latency。大意是，系统根据你的历史输入预测你下一步要按什么，提前把画面渲染出来；你按对了，体感就是零延迟；你按错了，就回滚重新渲染。

批评当场就来了。在多人游戏里，你的输入不只是给你自己看的，还要发给别人。猜错了回滚，别人看到的你可能已经在别的位置了——这在竞技游戏里是不能接受的。更要命的是它把“稳定的延迟”换成了“概率性的错误”，而玩家对后者的容忍度远低于前者。一直慢 50ms 玩家能适应，偶尔抽一下玩家会摔手柄。

Digital Foundry 后来实测 Stadia 上若干游戏，端到端延迟在 100–180ms 区间浮动，具体看游戏和网络条件。而 Stadia 宣传里那些“低于 50ms”的数字，指的是网络往返。两套语言，严格说都没撒谎，但用户拿到手的是前者，宣传给的是后者。

Stadia 最终死于商业和内容，不是死于延迟。但它留下了这个行业最经典的一课：延迟的营销口径和体验口径，差了一个数量级。你至今看到的每一次“我们做到了 20ms”，都要先过这道换算。

案例二：xCloud 从 One S 刀片换到 Series X，一次教科书级的“砍大头”。

Xbox Cloud Gaming 2020 年正式上线时，服务器用的是定制版 Xbox One S 刀片。这个选择在当时很理性：单机成本低、功耗低、机架密度高，同一机柜能塞更多会话。但它有个致命问题——One S 的性能跑大多数 Xbox 游戏是 30fps，有些甚至更低。

30fps 意味着什么？渲染段光一帧就 33ms，加上管线深度，输入到出画面 50–80ms 就这么没了。再叠上网络、编码、解码、电视，端到端轻松破 150ms。你网络再好也救不回来，因为地板就在那儿。

2021 年微软开始把刀片换成 Xbox Series X。帧率从 30 上到 60，加载时间从几十秒压到几秒。实测端到端延迟普遍下降 30–60ms。这个幅度，比任何编码器参数调优都大，而且是一次性的、确定的、不依赖用户网络环境的。

这个案例的启示非常硬：云游戏延迟的第一战场是服务端算力，不是网络。你给玩家一台跑 30fps 的机器，等于开局就欠他 40ms，后面怎么补都补不回来。这也是为什么第 04 篇讲 GPU 虚拟化那么关键——你能不能给每个会话分到一块足够强的 GPU，直接决定了延迟的地板在哪，后面的所有优化都是在这个地板上做加法。

作为跨类对比，可以提一句自托管的 Sunshine + Moonlight。它延迟之所以经常打得过商业平台，很大一部分原因就在这里：你家里那台 4090 是裸金属直跑的，帧率管够、编码器独享、局域网往返只有 1ms 量级。它不是技术更先进，是它把七段里的两段直接删了。第 27 篇会细算这笔账。

一份可以照着分的延迟预算表

下面这三张表是我自己在做方案评估时会用的。第一张是预算分配，第二张是可调参数，第三张是网络段的实测区间参照。你可以直接拿去改。

表 A：端到端延迟预算分配（单位 ms）

注意 60ms 那一列，渲染只给 17ms，意味着 60fps、渲染队列几乎不留缓冲，这在真实环境里是很激进的，帧时间一抖玩家就感觉得到。90ms 那列才是大多数平台能稳定交付的档位。140ms 那列对应的是“服务端还在跑 30fps”的旧架构。

表 B：可调参数与建议区间

表 C：不同接入方式的网络段单程耗时参照

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

初级用户速览（五句话带走）

• 延迟是七段相加，不是某一段。你优化的是哪一段，得先知道。
• 大头通常不在网络，在服务端渲染和玩家那台电视。
• 厂商说的 40ms 一般是网络往返，端到端要乘 3 到 5。
• 不同品类的容忍阈值能差七八倍，先确认你做的是什么游戏。
• 让玩家开电视的游戏模式，是白捡的 30ms，但九成人不会做。

进阶深入（给要动手的人的清单）

• 先测，别猜。用分段探针把端到端拆开，找到最长的那一段。没有测量就没有优化，只有祈祷。
• 优化最长的那段，不是最容易的那段。编码器参数好改，但它在总链路里可能只占 5%。改它是在给自己做心理按摩。
• 看分布，不看均值。P95 和 P99 才是玩家骂你的原因。均值是写给投资人看的。
• 帧率是地板，先把 60fps 锁死。这条不解决，后面所有优化都白做。
• 编码器低延迟档的代价要算进带宽预算。省了 5ms，可能要多花 30% 带宽，这笔账在产品层面怎么算，提前想清楚。
• 显示端引导是产品问题。技术上你解决不了，但你可以设计一个不烦人、有说服力的引导流程。这比多砍 2ms 编码延迟更有价值。
• 不要相信任何没写测量方法的延迟数字。包括你自己团队报上来的。

争议与常见坑：几个大家都在踩的坑

坑一：“我们做到了 20ms”是最常见的话术陷阱。它大概率指网络单程，或者机房内往返，或者某个特定游戏在理想网络下的最好成绩。端到端的真实数字往往要乘 3 到 5。看到这种数字，第一反应应该是问“测的什么口径”，而不是惊叹。

坑二：用平均值汇报延迟。平均 80ms 听起来很美，但如果 P99 是 400ms，那一百个玩家里就有一个每分钟被卡三次。这个人的评论会挂在应用商店第一条。延迟指标必须带分布，这是底线，不是加分项。

坑三：把带宽问题当延迟问题。Wi-Fi 是延迟的隐形杀手，而它杀的往往不是带宽，是抖动。你测速跑出 500Mbps，照样可能每两秒抖一次 80ms。玩家看到的“卡”很多时候来自抖动，带宽反而背了锅。

坑四：玩家嘴里的“延迟”不一定是延迟。可能是帧时间抖动，可能是音画不同步，可能是画面糊导致的“感觉不跟手”。这四件事的修法完全不同。做用户调研的时候一定得把问题拆细，不然你修错了地方，玩家还会回来骂。

坑五：延迟适应现象会让你误判。玩家玩十分钟之后会适应更高的延迟，主观评分会回升。但适应不等于体验好，只等于他忍了。用“玩十分钟后的评分”去评估延迟优化，你会系统性地高估自己的水平。这条的神经科学解释在第 29 篇。

还有一个更微妙、但我觉得最值得吵的争议：端到端延迟该不该把显示设备算进去？

平台方的立场是：电视的 40ms 是玩家自己的问题，跟我无关。玩家方的立场是：我买你的服务，体感不好就是你的问题。两边都有道理，但结果是没人去解决。我的看法是，从产品角度必须算进去——因为玩家买的是完整体验，不是你的链路。你不去引导，这 40ms 就永远记在你账上。这是商业问题，装看不见只会更亏。

FAQ

Q1：我在家用 GeForce NOW 测出网络延迟只有 20ms，为什么手感还是明显有延迟？

因为 20ms 只是七段里的一段。剩下的：手柄蓝牙 15ms、服务端渲染 30ms、编码 6ms、解码 6ms、电视 30ms，加起来已经 107ms 了。你测的那个数字是整条链路上最短的一段，自然看起来漂亮。想搞清楚，得做端到端测量，拿高速摄像机或者闪光灯法，别信客户端那个数字。

Q2：云游戏能玩音游吗？

技术上很难，但不是因为延迟高，是因为音画同步。音游对“听觉和视觉的偏差”比对“绝对延迟”敏感得多，而云游戏的音频和视频走的是两条不同的路（音频通常单独封装、单独抖动缓冲），很容易差出几十毫秒。这个偏差在本地几乎不存在，在云端是结构性的。具体机制第 29 篇会讲。

Q3：换了 Wi-Fi 6 就能解决延迟问题吗？

能改善，但别指望根治。Wi-Fi 6 的主要贡献是降低高负载下的排队延迟和提升多设备并发表现，它解决不了你和边缘节点之间的物理距离。而且 5GHz 的穿墙能力比 2.4G 差，隔两堵墙之后的实际体验可能比老路由还差。优先级排序：有线 > 5GHz 近距离 > Wi-Fi 6 > 2.4G。网线是云游戏最好的配件，这话我说了不下一百遍。

Q4：120Hz 手机玩云游戏，延迟会比 60Hz 低吗？

会，但幅度没你想的大。它主要改善两段：触屏采样率翻倍（省 8ms 左右）和显示刷新更快（省几毫秒）。但如果服务端还是 60fps 输出，你的 120Hz 屏幕只是在重复显示同一帧，收益有限。要真正吃到这份收益，得服务端也能出高帧率流——这又回到了那句老话：帧率是地板。

Q5：为什么同一个游戏，我和朋友感受差那么多？

三个原因。一是硬件链不同：他用有线手柄和游戏模式显示器，你用蓝牙和电视默认模式，光这两项就差 50ms。二是游戏经验不同：老玩家对延迟的容忍阈值显著低于新手，因为他的肌肉记忆更精确。三是心理预期不同：他知道这是云游戏，会主动归因，你不知道，就全怪网络。所以做用户测试的时候，一定要把这三件事分开问，别混在一起做评分。

最后留个问题给你：如果一份延迟报告只告诉你一个数字，你会先问什么？我的答案永远是——“测的哪一段，什么方法，P99 多少”。这三个问题问出去，八成的宣传话术会当场露馅。