像素流送是什么：什么时候该用、什么时候是坑

本文讲通用机制与判断方法；具体三维引擎、编码方案、服务器与网络条件以实际方案评估和实测为准，不针对任何单一品牌硬编参数。

一个园区孪生项目谈到中段，甲方提了个听起来很合理的要求：领导出差在外，用手机也要能打开看。技术负责人当场答应了——场景都做好了，加个”网页版”应该不难。等真排方案才发现，这句话背后是另一条技术路线，预算口子还是按人头开的。

像素流送最容易被误判的地方，在于它看起来是”给已有场景加个访问方式”，实际上是”给每个访问者配一份渲染资源”。 前者是一次性开发，后者是持续支出，两者不是一回事。

这篇讲清它的完整链路、真正解决了哪些问题、代价落在哪四处、什么场景该用、什么场景是坑，以及展厅语境下怎么判断。想先弄清孪生本身的定义与能力分级，看数字孪生是什么；这个方向的全部内容在数字孪生专题。

像素流送到底在做什么

一句话：三维场景在服务器上渲染，画面编码成视频流推给客户端，客户端只负责播放和回传操作指令。

完整链路拆开是六步，理解这六步，后面所有优点和代价都能自己推出来：

1. 服务器渲染——场景跑在配了显卡的服务器上，由 UE5、Unity 这类引擎实时渲染每一帧。
2. 视频编码——渲染出的帧编码成视频流，常见是 H.264 或 H.265。
3. 网络传输——通过 WebRTC 之类的实时通道推到客户端。
4. 客户端解码——浏览器或播放端把视频流解码成画面。
5. 画面显示——用户看到的其实是一段实时视频，不是本地渲染的三维。
6. 指令回传——鼠标、触摸、键盘操作采集回传，服务器据此改变相机或场景状态，进入下一轮。

这和云游戏是同一套思路。客户端不持有场景，它只是一个带交互能力的播放器——这既是它全部优势的来源，也是它全部代价的来源。

它真正解决的四个问题

第一，客户端不需要高性能显卡。 大体量场景对本地渲染要求很高，办公电脑、老笔记本、平板往往带不动。像素流送把压力挪到服务器，客户端能解码一路视频就行。

第二，不需要装客户端。 点开网页链接就能看，没有安装包、没有版本号、没有”我这边打不开”。要发给外部人员看时价值很大。

第三，浏览器和移动端也能承载重场景。 纯前端的 WebGL 是另一条路线，但同样受限于用户设备算力，场景一重就掉帧。像素流送绕开了这个限制——场景多重取决于服务器，而不是用户手上那台设备。

第四，模型资产不下发。 用户拿到的是视频流不是模型文件，对有保密要求的项目是实在的好处。但边界要说清：它防的是”直接拿到源文件”，防不住录屏，也防不住对着画面重建。 当成一层合理保护，别当加密。

它的四项代价

优点讲完了，接下来这部分才是选型时真正要盯的。

代价一：并发不是软件问题，是硬件账

这是最大的成本陷阱，也是最容易在方案阶段被跳过的一笔账。

本地渲染的场景，一百个人在各自电脑上跑，成本还是那一份开发费。像素流送不是——每一个正在观看的用户，都在服务器上独占一份渲染资源。第二个人进来多渲一路，第十个人进来多渲十路。

一块显卡能同时带多少路，取决于分辨率、帧率、场景复杂度和编码设置，任意一项变化都会改变结果，没有可以照抄的数字。能确定的只有方向：并发数上去，硬件投入跟着涨，涨到一定程度就要加机器。

所以成本估算必须从”预计同时在线多少人”开始，而不是从”场景做多大”开始。顺序反了后面全是返工。

代价二：延迟是链路叠加出来的

本地渲染的操作反馈只经过”渲染—显示”两步。像素流送的每一次操作，要走完整的一圈：

环节	说明
操作采集与回传	鼠标/触摸事件送到服务器
服务器渲染	引擎按新状态渲染下一帧
视频编码	帧压成视频数据
网络传输	数据推到客户端
客户端解码	还原成画面
显示	画面上屏

这六段延迟是叠加的，任何一段都压不到零。 结果是操作反馈天然不如本地渲染跟手，拖视角时有轻微的”跟不上手”，快速连续操作更明显。

不同交互类型感受差别很大。慢节奏的浏览、点选、切视角，用户基本不会察觉；连续精确拖拽、实时对位会明显别扭。 判断标准不是延迟多少毫秒，而是这个场景的交互对跟手有多敏感。

代价三：画质受码率和编码约束

用户看到的是被压缩过的视频。编码时会优先保住大面积色块和运动趋势，对高频细节保留有限。

具体表现是：细小文字、细线条、密集栅格容易糊。这几样恰好是孪生场景的常客——设备标签、管线编号、看板小字、结构线框。

缓解方向有三个：提高码率、把关键文字做成客户端叠加的二维图层而不塞进三维场景、字号比本地渲染版本大一号。但要有心理准备：同等观感下它对码率要求更高，而码率直接换算成带宽支出。

代价四：网络质量直接变成体验

本地渲染的场景，网断了画面还在，最多是数据不更新。像素流送不是——网络抖动直接变成画面卡顿，断开就是黑屏。

这不是”网络好一点体验好一点”的量变关系，而是硬依赖。两类现场尤其要注意：出口被多方共用、上行带宽有限的场地，以及无线接入的移动端。必须实测目标网络下的观感，别拿内网效果承诺现场。

什么场景该用

把四项代价反过来看就清楚了——当”客户端带不动”或”客户端不该拿到模型”的代价，大于”多花硬件钱、多一点延迟”时，像素流送就是对的选择。 具体有几类：

• 多人同时在线的线上孪生——运行态要开放给多个部门、岗位随时查看，人分散在不同地点、用不同设备。
• 需要移动端访问——手机、平板要能打开重场景。移动端本地渲染上限低，这是它几乎无可替代之处。
• 客户端设备参差不齐——用户是外部单位、上级部门或客户，你无法要求也无法预知其设备。
• 模型资产不宜下发——厂区布局、设备排布等不希望以源文件形式流出的内容。
• 临时性对外开放——某阶段让一批外部人员看到场景、事后收回，比挨个装客户端现实。

什么场景是坑

第一坑：展厅现场的单点大屏。

现场就一块屏、一台机器，观众就在屏幕跟前。本地一台配置够的机器直接渲染，简单、稳定、跟手、不吃网络。硬套像素流送等于凭空加一条网络依赖和一段延迟，还多一台服务器要维护。展厅现场可靠性优先——能少一个环节就少一个环节。

第二坑：需要极致跟手的交互操作。

多点触控的连续拖拽、精细的构件定位、需要即时反馈的操作类展项。这类交互对延迟最敏感，代价二会放大到用户明确感知。

第三坑：并发规模不确定的项目。

这一坑最贵。合同里写着”支持在线访问”，没写同时在线多少人。上线后访问量超预期，要么临时加硬件、要么排队进不来；低于预期，按峰值备的机器就空转。并发说不清的项目成本是发散的，要在签合同前摊开谈。

第四坑：把它当成”给已有场景加个网页版”。 推流架构、会话管理、并发调度、断线重连、鉴权都是额外工程量，不是勾个选项就有，要单独立项估算。

展厅语境下怎么判断

展厅场景给一条相对明确的判断线：现场用本地渲染，线上延伸用像素流送。

现场的展项——大屏、沙盘联动、触摸交互——本地一台配置够的机器渲染更简单也更稳。设备可控、屏数固定、观众就在跟前，像素流送带不来什么，反倒引入了网络这个不可控因素。现场怎么把孪生场景和其他展项串成动线，看孪生展项与中控联动。

它在展厅项目里真正的位置，是**“展厅之外的人也要看”那部分需求**：领导在外地查看、合作方远程演示、总部随时调阅、市民端手机访问。

关键是方案阶段就把两块拆开：现场是现场的方案，线上是线上的方案，共用模型资产但不共用运行架构。 混在一起写，要么现场被线上架构拖累，要么线上被现场思路做成个没人用的半成品。整套展厅孪生怎么落地，配合数字孪生展厅怎么做一起看。

至于场景用哪个引擎做是另一个维度——像素流送解决”怎么送出去”，引擎选型解决”用什么做出来”，分开决策，这里不展开。

上马之前先摊开三件事

确实要用的话，三件事必须落到纸面：

• 并发口径——设计并发多少、峰值多少、超出之后排队还是拒绝。这直接决定硬件预算。
• 网络实测——在真实访问环境（含移动网络）下实测观感，而不是在内网演示环境验收。
• 降级预案——网络差时降到什么分辨率帧率、连不上时显示什么、要不要留二维视图兜底。没有预案，网络一抖就是白屏加投诉。

小结

像素流送的机制是：服务器渲染、编码成视频流、推给客户端播放、客户端回传操作指令。客户端不持有场景，只是个播放器。

它解决四个问题：客户端不需要高性能显卡、不需要装客户端、浏览器和移动端也能看重场景、模型资产不下发（防源文件流出，不防录屏）。代价也是四项：并发占服务器渲染资源、延迟六段叠加、画质受码率约束致细小文字线条易糊、强依赖网络。

该用的是多人在线孪生、移动端访问、设备参差不齐、资产不宜下发；是坑的是展厅现场单点大屏、极致跟手的交互、并发说不清的项目。展厅判断线：现场本地渲染，线上延伸用像素流送，两套架构分开。

最后回到那句最要紧的：先算并发账，再谈技术方案。并发数不确定的项目，像素流送的成本是发散的。

延伸阅读：数字孪生是什么、孪生展项与中控联动、数字孪生展厅怎么做，或看数字孪生专题。

---

要把孪生场景落到展厅现场的大屏上，还想让观众能上手点选、多屏联动？了解企服君自研 GoMagicWall 互动大屏——大屏可视化展示配多点触控交互，适配数据看板与展项联动，现场本地渲染无需依赖网络。也可以直接说说现场需求，我们帮你定制方案、聊聊对接。