Three.js / Cesium 卡顿怎么办？把三维渲染搬到 GPU 服务器

一、先定边界：这是远程图形渲染，不是网页 SSR

传统三维应用把模型、纹理、地形和业务数据交给浏览器，由客户端执行场景更新与绘制。远程渲染则在 GPU 服务器上运行应用，编码生成的画面，通过实时连接传给浏览器；键鼠和触摸输入沿相反方向返回。Pixel Streaming 是这类架构的典型实现。1

浏览器仍然需要解码视频、合成页面和处理本地 UI，因此"远程渲染"不等于"客户端零开销"。也不要把它与生成 HTML 的服务端渲染混为一谈。

对于已有项目，建议优先评估下面这条路线：

保留三维引擎 → 在独立 GPU 图形会话中运行 Chromium → 捕获与硬件编码 → WebRTC 传输 → 本地业务 UI。

这是一种低迁移成本的候选方案，不是所有场景都适用的"性能最优解"。如果本地卡顿主要来自低效 JavaScript、不断重建对象或过多绘制调用，把应用搬上服务器并不会自动修好这些问题。

二、技术栈怎么分工，哪些组件不用重复造？

层次	建议选择	负责什么
客户端业务界面	Vue 3 / React + TypeScript	登录、搜索、表格、面板、业务交互
三维应用	原有 Three.js / CesiumJS	场景、相机、图层、实体拾取
应用运行环境	Linux + GPU Chromium	在服务器执行已有三维代码
显示与采集	隔离的 X11 / 已验证的 Wayland 会话 + Selkies	提供可捕获的画面与输入入口
视频编码	pixelflux + NVENC	在支持的 NVIDIA 硬件上编码
传输	WebRTC，按网络条件保留 WebSocket 路径	发送画面、接收交互
控制服务	Go + Gin，或沿用现有后端	鉴权、分配实例、心跳、回收、审计
状态与部署	Redis + 现有数据库 + 容器	会话状态和生命周期管理

2.1 先辨认 Selkies 的版本与传输模式

本文以官方已发布的 Selkies 2.1.0 为部署参考，实际生产应固定镜像摘要和配套驱动版本，避免直接跟随 main。2

文中采用的 2.x 架构使用 Rust 编写的 pixelflux 处理画面采集和编码；运行时并不是纯 Rust 或纯 Go，外围服务仍包含 Python。它默认使用 WebSocket + WebCodecs ，WebRTC 是需要显式开启的选项。旧版 Selkies-GStreamer 的管线配置不能直接套用。34

第一版没有必要再叠加一套 Pion 媒体服务、GStreamer 编码管线和独立信令协议。先把现成链路跑通，只有在它无法满足自定义采集、业务输入协议或分发需求时，再考虑替换对应模块。

**Go 在这里解决的是控制与调度，不是让 Chromium 的绘制速度凭空变快。**已有 Java 后端完全可以继续承载业务，不必为了远程渲染整体重写。

2.2 一个容易部署错的细节：显示会话不等于 Headless 浏览器

Selkies 的桌面采集路线需要应用画面出现在它捕获的显示会话中。服务器可以没有物理显示器，但 Chromium 仍应作为有窗口的图形应用，运行在对应的虚拟显示会话内。4

例如，采用 Puppeteer 管理该浏览器时，通常使用：

// 运行在已经准备好的、可被 Selkies 捕获的图形会话中。
// DISPLAY / Wayland 环境、浏览器沙箱与用户权限由容器启动层配置。
import puppeteer from "puppeteer";

const browser = await puppeteer.launch({
  headless: false,
  defaultViewport: null,
  args: ["--kiosk", "--window-size=1920,1080"]
});

headless: false 是 Puppeteer 的有窗口模式。5 这段代码只说明运行模式，不负责创建显示服务器，也不保证启用硬件渲染。必须另外检查实际图形后端；Chromium 官方明确说明 Linux GPU 加速依赖显示、驱动与图形后端的组合。6

三、WebRTC 与 WebSocket，不要只凭协议名选型

两条路线都可以传输画面，但部署约束不同。

条件	优先验证的路线	要检查的风险
同地域、允许 UDP、频繁操作	WebRTC 直连	ICE 候选地址与媒体端口是否可达
企业网限制 UDP	WebRTC 经 TURN/TLS，或 WebSocket	实际代理策略、延迟与拥塞表现
内网、链路稳定、希望减少开放端口	WebSocket	丢包时的排队与陈旧帧积压
不同地区用户、网络质量差异大	分区域渲染节点 + 自适应质量	不能只靠换协议弥补地理距离

这里"WebSocket"指通常基于 TCP 的 WSS 链路。TCP 的可靠有序交付会让后续字节等待丢失数据恢复，因此实时视频需要额外关注队列和过期帧。WebRTC 提供面向实时媒体的传输机制，但也可能通过 TCP/TLS 中继；并不是名字叫 WebRTC 就一定走 UDP、一定低延迟。78

STUN 辅助发现地址，TURN 在无法建立合适直连路径时中继数据。TURN 不是只转发握手的小服务，走中继时它承担实际媒体流量。企业网络和移动网络应当单独验证这一条路径。9

**一个实用验收要求：记录最终选中的网络路径，而不是只记录"连接成功"。**直接连接、TURN 中继、不同区域绕行，可能产生完全不同的体验。

四、真正的性能问题：画面从 GPU 出来后，去了哪里？

容易忽视的开销不一定在编码器本身，而可能在帧捕获、内存复制、像素格式转换和排队。

4.1 原始画面复制量，比视频码率大得多

假设每帧画面以 4 字节/像素的 RGBA 或 BGRA 形式存在，分辨率为 1920 × 1080，帧率为 60：

原始帧数据率 = 1920 × 1080 × 4 × 60
             = 497,664,000 字节/秒
             ≈ 497.7 MB/s

这是一次完整原始帧搬运涉及的数据量，不是最终的网络视频码率。

分辨率	60 FPS、4 字节/像素的原始数据率
1920 × 1080	约 497.7 MB/s
2560 × 1440	约 884.7 MB/s
3840 × 2160	约 1,990.7 MB/s

如果先从 GPU 读回 CPU，又把同等大小的数据上传到 GPU 编码，总搬运量还会增加。实际路径可能涉及压缩表面、不同像素格式和硬件转换，因此上表是用于理解量级的算术测算，不是 PCIe 实测。

这也是为什么需要检查"零拷贝或低拷贝采集路径"。pixelflux 的零拷贝能力取决于显示后端、驱动、缓冲区互操作和编码设备的组合，选择 NVENC 并不自动证明整条路径没有 CPU 回读 。10

建议分别记录渲染、捕获、格式转换、编码和网络发送耗时，避免把它们合并成一个无法定位的"推流耗时"。

4.2 公开测试说明了什么，又不能说明什么？

Epic 官方 Pixel Streaming 参考文档给出 H.264 在 1080p 和 4K 下的近似编码耗时，分别为 8.97 ms 和 24.17 ms ；文档将该组 GPU 编码测试硬件列为 RTX 3060。11

图 1：依据 Epic 官方公开数据绘制。不是本文实测，也不是 Selkies 的测量结果。

在这组参考数据中，4K 的像素数是 1080p 的 4 倍，所报告的编码耗时约为 2.69 倍。这说明分辨率是需要单独评估的成本变量，而不是可以随意提高的显示参数。

但不能据此推导"这张卡一定能同时带多少人"，也不能简单用 1000 ÷ 编码耗时 当作多路编码能力。编码延迟、管线吞吐、会话限制和渲染负载是不同指标。

**采购时也不要只看 AI 算力或显存。**NVIDIA 官方矩阵列出的 A100、H100 没有 NVENC 编码器，而 L4、L40S 具备对应编码能力。型号是否支持目标编码格式、编码引擎数量与会话限制，必须逐项核实。12

五、操作到底有多"跟手"？用延迟预算拆开分析

远程渲染的核心指标是 input-to-photon：从发出操作，到看到它改变画面的时间。

可以将一次交互拆成：

输入采集 + 上行传播 + 等待更新 + 场景渲染 + 捕获与编码 + 下行传播 + 缓冲、解码与显示。

下面建立一组明确的假设，不把它当成实测：

非网络环节	假设预算
输入采集与处理	2 ms
等待应用更新	5 ms
GPU 绘制	11 ms
采集与格式处理	2 ms
视频编码	5 ms
客户端缓冲、解码和显示	19 ms
合计	44 ms

在上下行传播合计近似网络 RTT、没有额外排队的简化条件下：

操作到画面的预算 ≈ 44 ms + 网络 RTT

图 2：假设模型，未计入额外丢包恢复和队列积压；不是实测，也不是 P95 结果。

同一套渲染服务，RTT 从 30 ms 增加到 100 ms，模型里的交互预算便从 74 ms 变成 144 ms。即便把编码从 5 ms 优化到 2 ms，也只能减少 3 ms。

**因此，远程三维的第一条低延迟策略，是让 GPU 节点靠近用户；不是无限追求编码器快零点几毫秒。**这是由上述预算模型得出的工程判断。

还要注意排队。60 FPS 下每帧间隔约 16.7 ms，积压 3 帧就多出约 50 ms。建议对采集和编码前的队列设上限，必要时合并或丢弃过时任务；已编码视频有帧间依赖，不能任意丢弃压缩帧。

最后，各环节的 P95 不能简单相加当成整条链路的 P95。端到端分位数应来自同一次交互链路的观测。

六、一张 GPU 能支撑多少人？先区分两种并发

6.1 共享观看与独立交互不是同一个问题

100 人观看同一个相机画面，可以设计共享渲染与视频分发。100 人分别旋转地图、切换图层，则需要不同的视图更新和画面输出。

SFU 解决媒体转发，不替应用计算 100 个不同的相机视角。因此不能把"100 名观众"的测试结果当成"100 个独立三维会话"的容量。

对 Selkies 这样的现成流送系统，接入 SFU 也不是简单加一个服务器：还需要确认发布方式、协商过程、输入权限和编码流复用策略。第一版独立交互场景没有必要先引入 SFU。

6.2 用最短板建模，再用并发压测确认

可以用下面的模型组织容量评估：

独立会话容量 ≤ min(
  显存允许的会话数,
  达到目标画质与帧时间的渲染会话数,
  编码吞吐和会话限制允许的数量,
  CPU / 内存允许的数量,
  网络出口允许的数量
)

举一组与具体 GPU 型号无关的假设：

约束	假设条件	计算上限
显存	48 GiB，预留 6 GiB，每会话 3 GiB	14
渲染	假设并发测试最多允许 8 路达到目标帧时间	8
编码	假设目标分辨率下最多满足 12 路	12
CPU / 内存	假设可容纳 16 路	16
出口	300 Mbps，每路按 12 Mbps × 1.15 规划	21

这里决定上限的是渲染侧的 8 路，不是显存侧的 14 路。如果再按 20% 运行余量向下取整，可以暂按 6 个调度名额规划，最终仍需混合场景压测。

这些数值仅用于演示计算，不能作为采购依据。实际多会话性能也可能非线性恶化：相机同时飞行、模型同时加载、编码器同时请求关键帧，都可能产生尖峰。

建议调度器使用"经压测确认的场景容量档位"，而不是简单看到 GPU 利用率没有到 100% 就继续塞会话。

七、带宽账：100 人的远程三维，意味着多少流量？

设定一个可复算的场景：100 人持续在线，每路平均视频码率 12 Mbps，每人每天使用 8 小时，每月使用 22 天。

持续视频出口：

100 × 12 Mbps = 1.2 Gbps

每用户每小时的视频数据量：

12,000,000 ÷ 8 × 3600 = 5.4 GB

每月纯视频数据量：

100 × 5.4 GB × 8 × 22 = 95,040 GB = 95.04 TB

这里使用十进制 GB / TB。再预留 15% 的传输开销，规划出口约为 1.38 Gbps ，月数据量约为 109.30 TB。15% 是预算假设，不是 WebRTC 固定开销率。

图 3：不同平均码率下的月出口数据量。全部为给定假设下的测算，不含音频、额外中继链路与云厂商计费差异。

TURN 会增加中继链路的吞吐负担，但不能直接说"流量费用固定翻倍"。是否计费、在哪一段计费，取决于部署区域、网络路径以及实际账单规则。

这也解释了为什么不建议所有用户无条件切到云端：对于本地就能流畅运行的普通场景，远程渲染会引入持续的资源消耗。更合理的默认策略通常是 本地优先，重场景或弱终端使用远程资源。

八、Three.js / Cesium 接入时，真正要改的业务边界

8.1 把界面拆成"本地业务 UI"和"远端三维视图"

建议让搜索、表格、表单、菜单和普通弹窗继续在本地网页渲染。远程视频主要承载三维场景。

这是一种架构选择：它可以让文字界面保持清晰，业务操作不必全部经过视频交互链路；代价是需要同步远端场景状态、拾取结果和权限。

世界坐标绑定的标签要更谨慎。标签在本地，三维画面在远端，网络延迟可能造成两者短暂错位。第一版可以保留需要严格贴合模型的标签在远端，只把独立业务面板放在本地。

8.2 点击一个建筑，不能只发浏览器窗口坐标

应把点击位置转换成实际视频内容区域内的归一化坐标，扣除 object-fit: contain 产生的黑边，再映射到远端渲染视口。

随后由远端 Three.js / Cesium 完成拾取，返回实体 ID 和经过授权的业务信息。本地再展示详情。

在动态场景中，用户点击的是"刚刚看到的那一帧"，服务器可能已经推进了相机状态。要求精确拾取的系统，应关联输入序号、画面时间或帧标识，必要时保留对应相机状态，而不是默认用最新相机做射线检测。

8.3 连续输入和关键操作分开处理

自定义输入协议时，持续鼠标移动可以采用"新状态覆盖旧状态"的设计；点击、按键按下/抬起、确认和删除则需要可靠交付与结果确认。WebRTC DataChannel 提供相关传输配置，但不替业务定义消息语义。13

特别注意：如果发送的是相对位移，随意丢包会损失累计移动量。需要改成带序号的状态、累计量，或明确的合并规则。使用 Selkies 内置输入协议时应先复用它，不要盲目另造一套。

8.4 原来的三维优化仍然要做

Three.js 的实例化可以减少重复模型的绘制调用；Cesium 的按需渲染可以减少静止画面下不必要的绘制。1415

远程部署后，这些优化的意义不只是单用户更流畅，还可能降低每会话资源占用。与此同时，渲染帧率和流送帧率必须分开记录：编码器发送 60 FPS，不证明应用生成了 60 个不同的新画面。

九、如何做第一轮部署验证？

第一轮验证建议限定为：**一名用户、一个真实业务场景、1080p 输出、完整键鼠交互、可观测的渲染与编码链路。**不要第一天就加入多租户、SFU 和 Kubernetes。

下面是采用外部 TURN 的 PoC 容器示例。前提是 GPU 驱动和 NVIDIA Container Toolkit 已准备好，TURN 已正确部署，变量中填写的是实际可用的域名与认证信息。它未经实际环境验证，不是生产脚本。316

# 在当前 shell 预先安全地设置这些变量，不要把密码提交到代码仓库。
: "${SELKIES_PASSWORD:?请设置远程会话密码}"
: "${TURN_HOST:?请设置可达的 TURN 域名}"
: "${TURN_USER:?请设置 PoC 专用 TURN 用户名}"
: "${TURN_PASSWORD:?请设置 TURN 密码}"

docker run -d --name web3d-render \
  --gpus 1 --runtime nvidia \
  --shm-size=2g \
  -p 127.0.0.1:8080:8080 \
  -e PASSWD="$SELKIES_PASSWORD" \
  -e SELKIES_MODE=webrtc \
  -e SELKIES_ENCODER=h264enc \
  -e SELKIES_STUN_HOST="$TURN_HOST" \
  -e SELKIES_STUN_PORT=3478 \
  -e SELKIES_TURN_HOST="$TURN_HOST" \
  -e SELKIES_TURN_PORT=3478 \
  -e SELKIES_TURN_PROTOCOL=udp \
  -e SELKIES_TURN_USERNAME="$TURN_USER" \
  -e SELKIES_TURN_PASSWORD="$TURN_PASSWORD" \
  ghcr.io/selkies-project/selkies/desktop:2.1.0-ubuntu26.04

本例仅把 Web 入口绑定到宿主机回环地址，应通过受控的 HTTPS 反向代理或测试隧道访问。官方桌面镜像默认入口为 HTTPS，反向代理上游协议也要匹配。3

这里选择 3478/UDP 是明确的 PoC 假设；TURN 若使用其他端口或 TLS，必须同步修改。Web 入口可访问不代表媒体路径可用，TURN 的监听端口、分配的中继端口、候选地址和证书都需要验证。16

进入远程桌面后，在该会话中打开真实 Three.js / Cesium 页面，再做以下检查：

检查项	需要的证据
Chromium 硬件渲染	实际图形后端，不是 SwiftShader / 软件回退
NVENC 编码	流送日志中的实际编码引擎，加 GPU 编码指标交叉验证
三维更新	应用自身的渲染计数和帧时间，不只看播放器 FPS
网络路径	选中候选对、是否走 TURN、实际连接协议
交互	拖动、缩放、点击拾取、窗口缩放和断线恢复
资源回收	退出后进程、内存、显存和会话许可得到释放

GPU 侧可用 nvidia-smi dmon -s u -d 1 观察利用率；不同硬件和驱动暴露的字段可能不同，出现 N/A 不应被当作 0。17

十、怎样做一份可信的性能报告？

10.1 对照组不要缺失

至少保留四条路径：优化后的本地渲染、远程 WebSocket、远程 WebRTC 直连、远程 WebRTC 经 TURN。若评估 AV1，再增加对应组，不要在更换编码器时同时更换分辨率和画质目标。

场景建议覆盖静止观察、连续环绕、快速飞行、跨区域跳转以及动态目标更新。固定数据版本和相机路线，冷热缓存分开统计。

并发可以从 1、2、4、6、8 个独立视图递增；网络采用不同 RTT、带宽和丢包条件。这里的档位是压测设计建议，不是已经测得的容量。

10.2 采集指标时，避免平均值掩盖卡顿

指标	说明
应用帧时间 P50 / P95 / P99	确认三维渲染是否稳定
捕获、编码耗时和队列深度	定位发送前的瓶颈
实际接收、解码与显示帧率	确认客户端真正看到的内容
冻结次数、持续时间和降画质次数	衡量用户感知
输入到显示的端到端延迟	判断是否跟手
每会话 CPU、内存、显存与出口	计算独立会话成本
首帧时间、重连时间、回收时间	衡量完整会话体验

浏览器的 RTCPeerConnection.getStats() 可以提供 RTP、网络候选与解码相关统计。累计量应按时间窗口做差，例如：18

窗口平均解码耗时 = 1000 × ΔtotalDecodeTime / ΔframesDecoded
窗口平均抖动缓冲 = 1000 × ΔjitterBufferDelay / ΔjitterBufferEmittedCount

分母为 0、计数器重置或字段不存在时，不应强行计算。以上两项也不是完整的操作到画面延迟。

真正测端到端时，可以让服务端收到测试输入后改变画面上的标记，通过可校准的客户端显示观测或高速摄影验证。只收到 DataChannel 的响应，最多证明命令已被处理，不能证明对应画面已经显示。

10.3 报告应给"容量曲线"，不是一句"很流畅"

最终应能回答：在指定网络、指定画质、指定业务场景下，增加到第几个会话时，P95 帧时间、冻结率或端到端延迟开始超过门槛？

这个临界点，比"服务器上还有多少空闲显存"更适合用来配置调度器。

十一、上线前最后一道关：隔离、安全与降级

建议把每个独立租户会话的显示环境、浏览器资料目录、临时文件和凭证隔离。多个标签页不应被视作充分的多租户安全边界；高隔离要求的场景应进一步评估虚拟机等方案。

远程浏览器能够访问的内网地址、下载能力、剪贴板、上传入口和开发者调试端口，都应按最小权限开放。不要把 Docker socket 或主控密钥暴露给客户端，也不要为了省事关闭 Chromium 沙箱。

Selkies 提供由编排服务分配 controller / viewer 令牌的 Secure Mode；跨域嵌入还需要正确配置允许的 frame-ancestors。这些能力可以接入业务会话，但不能替代业务层的实体访问权限。19

PoC 使用的 TURN 长期账号也不应直接成为多人生产方案。coturn 支持基于共享密钥生成临时凭证；共享密钥保留在可信服务端，客户端仅拿到受限凭证。20

最后保留降级路径：降低输出分辨率、关闭高成本效果、回到本地简化场景，或者在资源池不足时排队。关键业务状态应保存为可重建的数据，不能只存在于某个 Chromium 进程的内存里。

远程渲染也不是"防泄露魔法"：不向客户端分发完整模型，不等于能够阻止截图、录屏或越权业务查询。

十二、结论：最佳方案不是最复杂的技术栈

对已有 Three.js / Cesium 系统，值得优先验证的组合是：

原有三维代码 + GPU Chromium + Selkies + 硬件编码 + WebRTC；业务控制层沿用现有服务，或由 Go 承担会话调度。

是否采用它，取决于三个结果：弱终端确实得到更好的体验，交互延迟符合业务要求，每个有效会话的成本可以接受。

它适合复杂三维场景、终端性能受限、算力集中管理的需求；但对于本地已经流畅、使用频繁且用户量大的普通三维页面，持续占用服务器和视频出口未必划算。

本文的计算给出了两个直观提醒：RTT 增加 70 ms，优化编码几毫秒无法抵消；100 个持续观看的 12 Mbps 会话，每月纯视频数据量可以达到 95 TB。它们不是劝退，而是提醒架构设计必须同时考虑网络和资源账。

先用真实场景测出延迟与容量曲线，再决定哪些用户、哪些视图值得占用远程 GPU。让远程渲染成为按需能力，通常比把所有用户强制迁上云更稳妥。

参考资料与图表说明

全部外部资料来自项目官方、标准组织或相关厂商。图 1 是对公开数据的重新绘图；图 2、图 3 是明确假设下的算术模型。本文没有执行 GPU 部署或真实用户并发压测。

1 AWS：Amazon EC2 Pixel Streaming 入门与架构图

https://aws.amazon.com/jp/builders-flash/202409/ec2-unreal-engine-pixel-streaming/

2 Selkies 2.1.0 Release

https://github.com/selkies-project/selkies/releases/tag/2.1.0

3 Selkies Getting Started

https://docs.selkies.io/latest/start

4 Selkies Design

https://github.com/selkies-project/selkies/blob/main/docs/design.md

5 Puppeteer Headless mode

https://pptr.dev/guides/headless-modes

6 Chromium GPU Hardware in Headless Chrome

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/gpu/using-gpu-hardware-in-headless-chrome.md

7 RFC 6455：WebSocket

https://www.rfc-editor.org/rfc/rfc6455.html

8 RFC 8835：WebRTC Transports

https://www.rfc-editor.org/rfc/rfc8835.html

9 Epic Pixel Streaming Hosting and Networking

https://dev.epicgames.com/documentation/en-us/unreal-engine/hosting-and-networking-guide-for-pixel-streaming-in-unreal-engine

10 pixelflux：捕获、编码与零拷贝路径

https://github.com/selkies-project/pixelflux

11 Epic Pixel Streaming Reference：编码参考数据

https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-pixel-streaming-reference

12 NVIDIA Video Encode and Decode Support Matrix

https://developer.nvidia.com/video-encode-decode-support-matrix

13 MDN：WebRTC DataChannel

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels

14 Three.js InstancedMesh

https://threejs.org/docs/pages/InstancedMesh.html

15 Cesium Explicit Rendering

https://cesium.com/blog/2018/01/24/cesium-scene-rendering-performance/

16 Selkies Firewall and TURN

https://github.com/selkies-project/selkies/blob/main/docs/firewall.md

17 NVIDIA nvidia-smi 文档

https://docs.nvidia.com/deploy/nvidia-smi/index.html

18 W3C WebRTC Statistics API

https://www.w3.org/TR/webrtc-stats/

19 Selkies Secure Mode

https://docs.selkies.io/latest/secure-mode

20 coturn turnserver 配置参考

https://github.com/coturn/coturn/blob/master/README.turnserver