把 112 ms 拆成六段：云游戏的延迟不在网络，在编解码与显示

端到端预算：112 ms 是怎么被分掉的

云游戏的延迟是加法的，不是取最大的那一段。六段里只有传输一段能被加速改善，其余五段由终端与服务端的算力决定。理解这一点，就不会把卡顿全归到线路上。

六段耗时全表：哪一段值得优化

下表是三地实测的加总结果。第三列是最佳可达值，第四列是两者之差——差值大的段才值得动手。

表 1 的差值列很说明问题：网络传输只占 9 ms 的可优化空间，而显示与解码合计有 17 ms。这也是为什么把线路从中位 33 ms 压到 24 ms，端到端只从 112 ms 降到 103 ms，而换一台支持硬解的设备能直接省 8 ms。

三列数据卡：云游戏的三条体验线

云游戏的体验是阶跃的：跨过某条线之后，同一款游戏从「能玩」变成「不想玩」。三条线的位置在三地实测里相当稳定。

• 舒适

  端到端 ≤ 120 ms · 帧间隔 ≤ 20 ms

  120ms

  广州移动到 HK-03 的 112 ms 落在这一档。动作类游戏可以正常游玩，射击类仍会有轻微迟滞感。

• 可用

  端到端 120–150 ms · 帧间隔 ≤ 33 ms

  150ms

  上海电信到 JP-02 接近这一档。角色扮演与策略类没问题，动作类需要在设置里降低画质换取帧间隔稳定。

• 不可用

  端到端 > 150 ms 或帧间隔 > 40 ms

  40ms

  超过这条线，输入与画面的错位已经能被明显察觉。继续加码率只会让帧间隔更差，正确动作是降码率与分辨率。

码率的三档：画面与帧间隔的取舍

码率的边际效益递减得很快：从 15 Mbps 提到 25 Mbps 画质提升明显，从 25 提到 35 只在高动态场景有区别，而帧间隔的稳定性反而下降。

画质评分由三名评测者独立打分后取中位，评分项包括纹理清晰度、动态拖影与色带。从 25 Mbps 到 35 Mbps，评分只涨 0.8 分，卡顿次数却翻了 2.4 倍，这就是「码率不是越高越好」的量化依据。

为什么要看帧间隔 p95 而不是平均帧率

平均帧率是 60 fps 并不能说明每一帧都按时到达。实测 25 Mbps 档的帧间隔 p95 是 23 ms，意味着每十秒左右会出现一次明显的节奏断点；而 15 Mbps 档的 p95 只有 18 ms，观感反而更顺。平均帧率把这类断点完全掩盖了。

解码延迟：同一台机器上差 30 ms 的三条路径

解码是整条链路里最容易失控的一段：同一台机器，硬解与软解的差距可以到 30 ms 以上，而这段延迟在客户端的延迟显示里往往看不见。

表 3 里 AV1 硬解比 H.264 硬解慢 6–8 ms，但码率低 30%，在带宽紧张时值得换；在带宽充足时反而是负优化。判断标准是看当前是否卡在码率上限，而不是看编码格式本身是否更新。

怎么确认自己在用硬解

客户端设置里勾选硬件解码后，用系统的性能监视器看播放串流时的 CPU 占用：占用低于 20% 基本可以确认走的是硬解，超过 60% 则是软解。这一步比读延迟数字更直接。

三个容易搞错的要点：码率、抖动补偿与显示

云游戏的问题经常被归到「网络不好」，但实测里多数案例的瓶颈在终端。以下三点按影响面从大到小排。

码率上限与线路带宽不是同一件事

线路有 600M 下行，不代表串流能用 35 Mbps 而不卡。串流对带宽的要求是「稳定的可用带宽」，一路上任何一处排队都会让帧间隔抖动。实测里 35 Mbps 档卡顿翻倍，但下行平均占用只有 36 Mbps，远低于线路能力。

抖动补偿段是隐形的延迟

客户端为了让画面平滑，会保留 3–5 帧的缓冲，这段补偿在读数里通常被算进「网络延迟」，实际是端侧策略。把补偿从 5 帧调到 3 帧能省 8–13 ms，代价是抗抖动能力下降，适合线路稳定的场景。

显示段最被低估

60 Hz 显示器的帧间隔是 16.7 ms，意味着画面最多要等一整个刷新周期才被看见。换成 144 Hz 能把这段压到 6.9 ms，收益接近把线路从 33 ms 压到 24 ms。三地实测里显示段的差值就有 9 ms。

• 先看帧间隔：p95 超过 33 ms 时，画质再好也救不回手感。
• 再看解码：软解占 CPU 60% 以上时，任何线路优化都白费。
• 最后看传输：传输只占 33 ms，压到 24 ms 已是三地实测的极限。
• 码率按场景选：动作类 25 Mbps 是平衡点，策略类 15 Mbps 足够。
• 显示不忽略：高刷新率屏幕与低响应面板合计能省 9–16 ms。
• 别叠设置：同时改码率、补偿帧数与解码方式，出问题后无法归因。

五步排查：先动端侧，再动线路

云游戏的排查顺序与游戏加速相反：端侧的收益更大，也更容易被忽略。下面五步按收益从高到低排。

1. 确认走的是硬解

   看串流时的 CPU 占用，低于 20% 为硬解。软解到 40 ms 时，线路再快也追不回来。

2. 把码率降到 25 Mbps

   观察帧间隔 p95 是否回落到 23 ms 以内。多数「画面一顿一顿」的问题到这一步就结束。

3. 检查显示器刷新率

   60 Hz 与 144 Hz 在显示段差 9.8 ms，属于不需要花钱就能验证的一项。

4. 再换落地区域

   传输段从 33 ms 压到 24 ms 已是极限，换落地区域是唯一手段，且必须换城市不是换节点。

5. 最后调抖动补偿帧数

   线路稳定时把补偿从 5 帧降到 3 帧，能省 8–13 ms；线路不稳定时不要动这一项。

什么时候换节点有效，什么时候换也没用

云游戏里，换节点能改善的只有传输段那 33 ms 的一部分。标「无效」的四类情形，换多少条线都不会变。

有效 · 传输段过长

落地区域与客户端距离远，传输段占到 45 ms 以上。换到更近的落地区域能压到 24–28 ms，端到端省 15 ms 左右。

有效 · 出口拥塞导致的帧间隔抖动

只在 21:00 之后出现帧间隔跳变，换落地区域通常能让 p95 从 32 ms 回到 23 ms。

部分有效 · 带宽临界

下行在 30 Mbps 上下浮动、开 35 Mbps 串流时，换线路能减少排队；但把码率降到 25 Mbps 更直接。

无效 · 软解

CPU 软解带来的 28–40 ms，与线路无关。换十次节点都是同一个数。

无效 · 显示器刷新率低

60 Hz 的 16.7 ms 帧间隔是硬件节拍，客户端改不了。

无效 · 服务端排队

同一时段所有用户都在卡时，是服务端算力排队，换线路只会增加握手时间。

三张补图：码率、落地区域与刻度

补图沿用同一批采样，把码率、距离与刻度三件事分开画，便于判断自己卡在哪一格。

• 卡顿分布图：用于选码率，看陡增的位置而不是看最高点。
• 落地区域图：用于判断传输段是否还有空间，24 ms 是实测下限。
• 帧刻度图：用于把数字换算成可感知的帧数，便于与其他场景横向比较。
• 共用口径：三张图与表 1、表 2 共用同一批采样。
• 复查：客户端版本与驱动更新都会影响解码段，跨版本对比需重测。
• 记录：把码率、帧间隔 p95 与卡顿次数写在一起，才能看出取舍位置。

一页速记：云游戏的六条判断

把整页压成六条，用于开串流前的三十秒自检。每条都对应上表里的具体读数。

一 · 端到端 120 ms 以内

超过 150 ms 动作类基本无法游玩，此时任何画质设置都救不回来。

二 · 传输只占三成

112 ms 里传输 33 ms，压到 24 ms 已是极限，别把希望全押在线路上。

三 · 解码先确认硬解

软解 28–40 ms 是硬解的 3 倍，先看 CPU 占用再谈其他。

四 · 码率 25 Mbps 是平衡点

再往上画质只涨 0.8 分，卡顿翻 2.4 倍。

五 · 看帧间隔 p95

平均帧率会掩盖断点，p95 超过 33 ms 就能被看出来。

六 · 显示段别忽略

60 Hz 的 16.7 ms 与 144 Hz 的 6.9 ms 相差 9.8 ms。

• 对应数据：表 1 的六段耗时、表 2 的三档码率、表 3 的五种解码路径。
• 使用顺序：先按速记自检端侧，再回表核对线路段是否还有空间。
• 交叉页：丢包对画面的影响见丢包页，网络侧读数见 FPS 页与总览页。
• 时效：解码性能随驱动变化，跨版本对比需重测。
• 边界：本页覆盖 1080p60 串流，4K60 的码率与解码开销需另测。
• 记录：每次调码率记一行帧间隔 p95 与卡顿次数，取舍位置自然浮现。

网络侧读数：云游戏与其他场景的阈值并不相同

同一套线路读数，在 FPS 里是「可打」，在云游戏里可能是「不能玩」。原因在容错方式不同：FPS 靠服务端回溯，云游戏靠端侧缓冲。

表 4 里最容易被忽略的是第四行：云游戏需要的是「码率乘 1.3 的稳定可用带宽」，峰值带宽毫无意义。线路标称 600M 但在 21:00 可用带宽掉到 20 Mbps 时，25 Mbps 的串流就会开始排队。

可用带宽与峰值带宽的差别

峰值带宽是测速软件在理想条件下跑出来的数，可用带宽是一段时间内能稳定维持的数。串流对后者的要求比前者严格得多：实测中峰值 620 Mbps 的线路在 21:30 的可用带宽只有 24 Mbps，恰好卡在 25 Mbps 串流的边上，表现为每隔几分钟卡一次。

4K60 与 1080p60：码率与解码开销的翻倍关系

4K 不是把 1080p 的码率乘三那么简单：解码开销大约翻四倍，对终端的要求也随之升高。下表把两档放在一起对照，便于判断自己的设备能不能承接。

端到端这一行是结论：把分辨率提到 4K，端到端会多出 12–26 ms，主要来自解码段。原本在 120 ms 舒适线附近的配置，切到 4K 后就会越线，体验从「能玩」掉到「不想玩」。

六个常见误区：云游戏里最容易踩的判断坑

这六条在实测里都有反例。列出来是为了让排查时少绕两圈，也为了让「升级套餐」这类动作排在正确的位置上。

误区一 · 带宽够就能开满码率

串流要的是稳定可用带宽，峰值 620 Mbps 的线路在 21:30 可能只剩 24 Mbps。

误区二 · 码率越高画质越好

从 25 提到 35 Mbps 画质只涨 0.8 分，卡顿翻 2.4 倍，净收益为负。

误区三 · 卡就是线路问题

112 ms 里传输只占 33 ms，软解与低刷新率屏幕各自能吃掉 8–30 ms。

误区四 · 换个节点就流畅

传输段的可行区间由物理距离决定，24 ms 是实测下限，换节点改变不了距离。

误区五 · 平均帧率 60 就没问题

帧间隔 p95 到 32 ms 时，平均帧率仍是 60，观感已经一顿一顿。

误区六 · 4K 只是更清晰

4K60 的解码开销约为 1080p60 的 2.6 倍，端到端多 12–26 ms。

• 对应数据：表 1 的六段耗时、表 2 的三档码率、表 5 的分辨率对照。
• 方向判断：画面顿挫先看帧间隔，动作迟滞先看端到端，花屏先看丢包。
• 交叉页：丢包对画面的影响见丢包页，网络侧读数见 FPS 页。
• 记录：每次调整记一行码率、帧间隔 p95 与端到端，趋势比单次更重要。
• 边界：本页覆盖 1080p60 与 4K60，云端录制与直播推流不在范围内。
• 时效：解码性能随驱动与固件变化，跨版本对比需重测。

相邻场景：换一个角度核对同一组数据

四类场景的瓶颈不在同一处：FPS 卡在服务器判定，主机联机卡在 NAT，语音卡在抖动缓冲，云游戏卡在解码与码率。下面六个入口按排查顺序排好，从一个场景读进另一个场景最快。

快喵VPN 用 240 帧高速摄影为六段耗时各自取了一次独立读数，避免把编解码与网络混成同一个数字。

• FPSFPS 竞技：tickrate 与服务器判定64 tick 与 128 tick 的判定窗口差 7.8 ms，比你换节点省下的还多。
• Console主机联机：NAT 类型与端口PS5、Xbox、Switch 三类 NAT 判定，先看类型再谈加速。
• Voice语音会议：抖动缓冲的深度取舍缓冲 20 ms 省延迟但吃抖动，60 ms 稳却吃掉轮流发言的间隙。
• Loss丢包 1%、3%、5% 三档感受同样是 3%，FPS 里是回拉，语音里是一声金属音。
• Updates线路与客户端更新记录每条标注影响面与是否可以回退，9 条按日期倒序。
• FAQ判定问答：换节点有没有用42 问按延迟、抖动、丢包、主机四组分开答。