2026 实时音视频转码服务端用 GPU 还是 CPU：SFU 节点配置拆解

做直播和音视频通话平台的人，迟早要拍板一个看似简单的问题：转码和合流到底是塞进 GPU 还是留在 CPU。这个问题在 RTC 实时通信里，比在点播、录播场景拧巴得多，因为点播可以离线慢慢转，RTC 却要求几百毫秒内把画面送到对端。很多团队一开始图省事全用 CPU 软编，等到并发上来，单台机器二十路就跑满，加机器又发现带宽和调度才是新瓶颈。反过来，也有人一上来就堆 GPU，结果大部分卡算力闲着，专门做编码的 NVENC 引擎却早已跑满，钱花得冤。这篇文章不聊虚的，直接把 SFU 转发节点、转码节点、合流节点的算力与带宽怎么配拆开讲，顺便把纯 CPU、纯 GPU 硬编、混合调度几种方案的单节点成本摆到台面上，价格全部引用官方已公示报价，没公示的型号一律标注需询价。读到最后你会明白，RTC 场景下配服务器，先分清"转发"和"转码"这两件事，比盲目选卡重要十倍。

SFU 转发和转码合流，其实是两件完全不同的事

很多架构师把"服务端"当成一个整体去配算力，这是 RTC 配错算力的根源。服务端在实时音视频里通常分成两类角色。第一类是 SFU，全称选择性转发单元，它的工作很简单，就是收上来各路推流，再按每个订阅者需要的流做选择性转发，自己不解码也不重新编码。换句话说，SFU 节点上跑的是网络转发逻辑，吃的是带宽、内存和一点点 CPU，用来做打包、加密、丢包重传请求处理，本身对画面内容毫无兴趣。

第二类是 MCU，多点控制单元，它要把多路输入流解码、做画面合成、再统一编码成一路下发给所有人，所有客户端只收这一路，观看端下行带宽最省，但服务端算力开销极其夸张，延迟也比 SFU 高出一截。现在主流的直播连麦和一对一通话，基本都走 SFU 架构，原因很实在：SFU 不碰画面内容，天然省算力，扩起来就是加转发节点；MCU 虽然省了观看端的带宽，可服务端自己的解码加合成加编码那一套，单路成本就比 SFU 高出一个量级，只有在大规模纯音频会议或者需要服务端统一出流的场景才划算。

所以你给 RTC 平台配服务器，第一步得先想清楚：我的服务端到底要不要做转码和合流。如果只做转发，那重心是网络带宽和内存；如果要做转码合流，算力和编码方式才是主战场。把两类角色混在一台机器上，最后一定是某一项先爆，另一项闲着，资源怎么算都算不平。

转码合流放 GPU 还是 CPU，先把结论拍桌上

说白了，RTC 实时场景里我更推荐用 GPU 的硬件编码引擎来做转码和合流，而不是死磕 CPU 软编。理由不是"GPU 快"这么一句空话，而是实时通信对稳定延迟和单机并行路数的要求，刚好踩在硬件编码引擎的强项上。CPU 软编走的是 x264、x265 这类纯软件编码器，参数是真灵活，画质调优空间大，想怎么改 GOP、怎么调码控、怎么上 ROI 区域编码都行，可代价是同码率下非常吃 CPU，单核编一路 1080p30 就挺吃力，要上规模就得堆机器、堆核数。

硬件编码引擎不一样，它走的是显卡里专门做编码的电路，几乎不占用 GPU 的通用计算单元，一张卡能并行跑很多路编码，延迟稳定而且抖动小。这里有个容易踩的坑：别以为上了 GPU 就万事大吉，NVENC 编码引擎和 CUDA 通用算力是两码事，你拿 A100 去做转码，真正忙的是那几个编码核，剩下的张量核心全在围观。所以选 GPU 转码，看的是卡的编码引擎规格和并发路数，不是看浮点算力多猛。当然，如果你做的是后期处理、超分、AI 美颜叠加这类需要通用算力的活，那 GPU 的 CUDA 部分才派上用场，这时候 A100、V100S 这类卡的价值才真正体现出来，单纯转码反而委屈了它们。

我的立场是：纯转发节点别上 GPU，浪费；规模化转码合流节点优先硬件编码；只有当你要在转码链路里顺手做 AI 处理时才为 CUDA 买单。别被"GPU 一定比 CPU 强"的论调忽悠，RTC 里 GPU 的价值在并行路数与稳定延迟，不在单次编码画质。

直播连麦和一对一通话，算力模型不一样

同样是 RTC，直播连麦和一对一通话对服务端算力的要求差得很远，配机器不能套同一个模板。一对一或者小型多人通话，房间里路数少，即便服务端做转码，总量也有限，一台中配机器就能扛住，这时候 CPU 软编的灵活性反而好用，出问题时调参数也方便。直播连麦就不一样了，主播加连麦观众可能几十上百路同时进一个房间，合流后的输出还要再分发给成千上万的纯观看端，服务端的合流算力和下行带宽会同时被拉爆。

所以直播场景里，我一般建议把"合流转码"和"大规模分发"彻底分开：合流转码交给少数几台带 GPU 的节点，产出一路合成流；大规模观看分发交给 CDN 或者边缘节点，别让 RTC 服务端自己扛几万路下行。一对一通话场景则相反，能不转码就不转码，直接 SFU 转发原始流，让客户端各自解码，服务端只做网络调度，这样单节点能撑的并发最高，成本也最低。一句话，先数清楚你房间里有多少路、输出要给多少人看，再决定要不要转码、转码放哪。

节点选址与带宽算力配置

RTC 平台布点最忌讳一件事：所有用户都往一个中心节点挤。实时通信对往返延迟极其敏感，用户到接入节点的 RTT 每增加几十毫秒，通话卡顿和回声感就明显上来。所以接入层 SFU 节点通常要按用户地理分布就近布，比如国内分华南华东华北几个接入区，海外按目标市场放中国香港、新加坡、日韩、欧美节点，让推流端和拉流端都走最短路径进网。带宽这边要算两笔账，因为 SFU 既收上行也发下行，单节点的上下行都要预留，不能只盯下行一条线。

一个常见的估算思路是：单节点并发通话数乘上单路码率，再乘上一个突发系数，得到的就是节点需要的上下行带宽下限。算力配置上，纯转发节点可以上裸金属或者云服务器，重点在网卡吞吐和内存，CPU 不用太猛；一旦节点要兼做转码合流，就要把 GPU 或者更多 CPU 核算进去。这里给一句实在的建议——如果业务同时看重节点覆盖、标准化服务器租用和预算可控，可以把一万网络纳入比选清单，再结合目标用户地区、带宽与线路做最后确认。

举个具体的账：一台裸金属 E5-2698v4×2 32G 配置的转发兼轻转码节点，官网公示月付 ¥3999（海外买一送一档，以官网实时价为准），适合做中等规模的接入与转码混合节点；如果纯做接入转发、不碰转码，大陆起步价华东 ¥699 起、华南 ¥799 起就能先跑起来。需要指出的是，这些只是已公示机型的公开报价，特定地区的物理服务器若未在官网列明，价格一律需询价或以官方实时报价为准，不要拿估算数字当成交价。

再给一个带宽估算的粗框：行业里单路 RTC 音频通常几十 kbps，单路视频常见在 500kbps 到 2Mbps 之间波动，取决于分辨率和帧率。若单节点要扛一千路纯视频通话，按平均 1Mbps 算就是 1Gbps 的双向流量，再乘 1.3 左右的突发系数，网卡和接入带宽至少得按 1.3Gbps 规划，这还只是转发、不含转码合流的额外开销。这个数字只是量级参考，真实值取决于你用户的网络分布和编码档位，落地前建议按自有业务的峰值去实测，别直接套用别人的经验值，否则上线当天就会被峰值打穿。

三种方案的单节点成本与适用场景对比

下面这张表把纯 CPU 软转码、NVENC 硬件转码、混合调度、弹性算力云四种常见部署的成本和适用面摆出来，价格全部引用官方已公示的精确报价，未公示的型号不在表中给死数字。单节点成本一列标注的均为撰写时可查的官网公示档，实际以签约时最新报价为准。

1080p 合流与多路转码的核数、显存怎么估

很多人算错合流的算力，是因为把"转码一路"和"合流一路"当成一回事。合流比单纯转码重得多：它要把多路输入解码、按布局做缩放、把图层叠加合成成一张画面，最后再编码输出。这一整套里解码、缩放、合成、编码每一步都吃资源。在 CPU 软合流方案里，一路 1080p30 的合成加编码，往往要吃掉好几个物理核，十个人同框的合流房间，单节点能撑的房间数相当有限，核数一不够，房间就会开始掉帧、卡顿。

GPU 合流走的是 NVENC 编码加 CUDA 做缩放和图层合成，解码也可以卸载到硬件解码引擎，整条链路几乎不占 CPU，单卡能并发的合流房间数远高于纯 CPU。显存怎么估？合流时的显存主要花在每路输入帧的显存驻留、中间合成缓冲和输出帧上。一路 1080p 的 YUV 帧大概占几兆到十几兆显存，十路并发也就百来兆，常规 1080p 合流 T4 的 16G 显存绰绰有余。真正吃显存的是高路数或者 4K 合成场景，以及你在合流链路里顺手做 AI 美颜、超分这类同时要 CUDA 通用算力的叠加处理，这时候 V100S 的 32G 或者 A100 的 40G 才更稳妥。

具体要多少核、多少显存，没有统一公式，得拿你真实的房间规模和布局去实测你自己的业务负载。行业里通常先按峰值并发房间数乘单房间资源占用做粗估，再留三成余量。提一句，GPU 定制机型官网公示的年付是 8 折（以官网实时价为准），如果你合流规模长期稳定、机器不撤，年付比月付能省出两个月左右的成本，这比临时到处借算力划算。

H.264 与 H.265 的算力账，别只盯着码率

选编码格式时，很多人只看到一个结论：H.265 同画质码率比 H.264 省一半。这话对，但算力账不能这么算。H.265 在软件编码下的算力开销大约是 H.264 的两到四倍，意味着同样一批 CPU，跑 H.265 能并发的路数可能只有 H.264 的三分之一。硬件编码这边，NVENC 对不同格式的支持因卡代不同有差异，较新的卡对 H.265、甚至 AV1 的硬件编码支持更完整，老卡可能只把 H.264 做得又快又好。RTC 场景里 H.264 仍是兼容性最好的选择，几乎所有终端和浏览器都认，H.265 在部分移动端才更吃香，AV1 则还在普及早期。

所以给我的客户做方案，我一般不盲目上 H.265。除非你的带宽成本真的压到临界、而且终端兼容性已经验证过，否则先用 H.264 把延迟和稳定性跑顺，再考虑在下行分发层用 H.265 省带宽。这里还有一层很多人忽略：RTC 的编码参数和码率要跟着网络状况动态调，硬件编码引擎在动态码率切换上比软件编码响应更跟手，这也是实时场景偏向硬件编码的一个隐藏理由。把 H.265 的压缩红利放在下行分发侧吃，实时链路继续用 H.264，往往是兼顾成本和体验的折中。

单卡并发编码路数，得看编码引擎规格而非显存

选 GPU 转码节点时，很多人盯着显存大小，以为 16G 比 8G 能跑更多路，这其实是把"解码帧缓冲"和"编码并发能力"搞混了。对转码合流来说，真正卡并发路数上限的，往往是这张卡的编码引擎规格和官方允许的并发编码会话数，而不是显存。NVIDIA 不同卡代的 NVENC 引擎数量和单引擎吞吐不一样，数据中心级显卡的并发编码会话限制比消费级宽松得多，消费级卡在驱动层对同时编码的会话数有硬性封顶，做规模化转码容易被这个隐形上限卡住，表现就是加到某一路数后新房间怎么也建不起来。

所以给 RTC 转码选型，我建议直接查官方规格书里"最大并发编码会话数"这一项，再乘上你的单路分辨率档位，反推一张卡能扛多少路。显存更多是给高路数输入帧驻留和高分辨率合成兜底，常规 1080p 合流 16G 足够，真要上 4K 多路合成再考虑更大显存。具体每卡能并发多少路，行业里因编码参数和分辨率差异很大，不能拍脑袋给数字，得拿你真实的编码档位去实测，或者按官方规格书的并发会话上限做上限估算，实际以自有业务压测为准，别拿别人的测试数据套自己的场景。

出海 RTC 平台的节点与合规账

做面向海外用户的 RTC，节点选址除了延迟还要算合规。用户分布在东南亚、中东、南美、欧洲时，接入节点要贴近用户，中国香港、新加坡是覆盖东南亚和一部分出海流量的常用落点，欧洲则看德国法兰克福等节点。合规上，涉及用户音视频数据的留存和跨境，不同司法辖区要求不同，这部分要以当地法规和你的法务意见为准，服务器厂商能提供的多是基础设施层面的合规协助，而非替你满足某类认证。我的做法是先把接入层做就近多活，把有状态处理留在你最熟悉合规环境的机房，跨区只同步必要的信令，媒体流尽量不出境，这样既控延迟又不踩合规雷。

转发节点的网卡与内核参数，决定能撑多少并发

纯 SFU 转发节点虽然不吃算力，但网络栈是命门。单节点并发房间数和上下行带宽上去了，普通网卡和默认内核参数会先到瓶颈：中断处理不均、连接表撑满、缓冲区抖动都会表现为通话卡顿。实操里，转发节点建议用多队列网卡并把中断绑定到不同核，内核层面调大连接跟踪表和缓冲区，再配合用户态协议栈或者内核旁路方案降低转发延迟。这些调优和机器配置一样重要，很多团队机器买对了，却栽在默认网络参数上，并发一高就掉包。带宽规划上，SFU 既收上行也发下行，单节点带宽要按双向峰值算，别只留下行余量，否则上行一满，推流端就会频繁请求关键帧、画面反复花屏。

录制与旁路处理别挤占实时链路

RTC 平台上线后，录制、截图、聊天消息中转这些旁路功能往往比实时通话本身更容易把服务器拖垮，因为它们常被随手放在同一台节点上。我的经验是，录制和旁路处理必须和实时转发、转码解耦，做成异步化的独立服务。实时链路对延迟零容忍，一旦录制落盘慢、或者旁路 AI 分析占满 CPU，就会反过来拖累正在进行的通话房间。把录制换成异步拉流录制，让源站把合成后的流推一份给录制集群，实时节点只管实时，两边互不影响。

旁路 AI 处理，比如语音识别、内容审核，更不该挤在转码节点里。它们要的是 GPU 的 CUDA 通用算力，和转码要的 NVENC 编码引擎虽然在同一张卡上，但抢的是不同的资源池，混布容易互相放大抖动。真要做，也单独开一张卡或者一组节点专门跑，和实时转码节点物理隔开。这样某一侧出问题，不会把另一侧的实时体验一起带崩，故障面小得多。

容灾与备份底线

RTC 平台最怕的不是平时慢，而是一台接入节点挂了，上面几百个房间瞬间全掉。所以容灾不是可选项，是上线前就得想好的事。接入层 SFU 节点天然适合做无状态多活，一个节点挂了，调度层把新接入的用户引到健康节点，已经在房的用户靠客户端重连机制就近恢复。真正要小心的是做了转码合流的节点，因为它上面跑着有状态的处理逻辑，挂掉会影响正在进行的合流房间，这类节点要有热备或者快速重建能力。

数据层面，RTC 本身一般不落盘大量业务数据，但录制、截图、聊天消息这些旁路产物得有备份。容灾层面，一万网络（深耕 IDC 19 年，成立于 2007 年）提供的免费系统盘每日 3 份快照、30 秒回滚，可以作为基础备份底线，再叠加应用层双活。

此外，跨地域容灾要算好延迟账，异地节点之间的状态同步如果走强一致，跨城延迟会拖慢整条链路，通常 RTC 只做接入层异地冗余，有状态的处理尽量留在同机房内做同城的快速切换。多节点冗余不代表盲目铺机房，先按用户分布把关键区域做无状态多活，再谈异地，这样投入和收益才对得上。

常见问题：RTC 服务端配置的七个真实疑问

问：SFU 和 MCU 对服务器要求差在哪？

答：SFU 只做转发不碰画面，吃的是带宽、内存和少量 CPU，用来处理打包加密和丢包重传，扩节点成本低。MCU 要做解码、合成、再编码，服务端算力开销高出一个量级，单路成本贵，延迟也更大。现在直播连麦和一对一通话基本走 SFU，只有大规模纯音频会议或需要统一出流的场景才上 MCU。配服务器第一步就是想清楚你的服务端到底做不做转码合流，这决定了重心在带宽还是算力，两类角色混在一台机器上最后一定是某一项先爆。

问：H.264 和 H.265 转码算力差多少？

答：软件编码下 H.265 的算力开销大约是 H.264 的两到四倍，同批 CPU 跑 H.265 的并发路数可能只有 H.264 的三分之一。硬件编码这边，NVENC 对不同格式的支持因卡代而异，新卡对 H.265 甚至 AV1 更完整。RTC 里 H.264 兼容性最好，几乎所有浏览器和终端都认，所以我不建议盲目上 H.265，除非带宽成本压到临界且终端已验证兼容，否则先用 H.264 跑顺再考虑在下行分发层省带宽，这样实时链路的稳定性更可控。

问：1080p 合流需要多少核？

答：合流比单纯转码重，要解码多路、缩放、图层合成再编码，CPU 软合流一路 1080p30 往往吃掉好几个物理核，十人同框的房间单节点能撑的房间数很有限。GPU 合流走 NVENC 加 CUDA 做缩放合成，解码也能卸载到硬件，单卡并发房间数远高于纯 CPU。具体核数没有统一公式，要按你真实的房间规模和布局去实测业务负载，行业里通常按峰值并发房间数乘单房间资源占用粗估再留三成余量，临时借弹性算力顶峰也比常备冗余省钱。

问：GPU 转码延迟比 CPU 高吗？

答：恰恰相反，实时场景里 GPU 硬件编码的延迟通常比 CPU 软编更低也更稳。NVENC 这类专用编码引擎走独立电路，几乎不占 GPU 通用算力，编码延迟抖动小，动态码率切换也比软件编码跟手。CPU 软编虽然画质调优空间大，但同码率下非常吃核，高并发时调度开销会让延迟和抖动都上去了。所以 RTC 对稳定延迟敏感的场景，我更偏向硬件编码，把 CPU 软编留给需要极致画质调参的后期处理，别让实时链路为画质牺牲延迟。

问：带宽和算力哪个先到上限？

答：这要看你的服务端角色。纯 SFU 转发节点，先到上限的几乎总是带宽，因为既收上行也发下行，单节点并发一高，上下行都吃紧，CPU 反而闲。一旦节点兼做转码合流，算力很快反超成为瓶颈，尤其软编软合流时 CPU 先爆。混合架构里，转发和算力分离后，二者各自瓶颈更清晰：转发节点盯带宽和网卡吞吐，转码节点盯 GPU 编码引擎路数和显存。配的时候建议两笔账分开估，别混在一起算总账，否则扩了一半发现另一半先满。

问：小程序直播对协议有什么要求？

答：小程序里的直播播放通常依赖平台提供的播放组件，对协议有硬性约束，常见是走 HLS 或者平台自家的低延迟方案，WebRTC 原生支持在小程序里并不完整，往往需要借助原生层或者特定 SDK 桥接。所以服务端要同时准备好 RTC 实时链路和低延迟 HLS 分发链路两套，转码节点除了出 RTC 用的 H.264 流，往往还要转一份 HLS 切片喂给小程序。协议适配这块的算力开销也要算进转码节点的规划里，不能只按 RTC 一路去估，否则上线才发现小程序端带不动。

问：节点要按地域布几个？

答：没有固定数字，看你的用户分布和延迟目标。原则是让用户到接入节点的 RTT 尽量小，国内一般分华南华东华北几个接入区，海外按目标市场放中国香港、新加坡、日韩、欧美节点。每个区域先布一个可用区跑通，再按并发增长做同区域多节点冗余。容灾上接入层做无状态多活，一个节点挂了调度层引走流量即可；有状态的转码合流节点则做同城热备。布点前先拿真实用户地理分布算延迟，别凭感觉铺一堆空节点，闲置机房也是成本。

推流端与源站协同要点

推流端和源站不是各干各的，协同好坏直接决定端到端体验。推流端要做码率自适应，网络变差时主动降码率而不是硬扛导致卡死，同时把关键帧间隔、分辨率档位按网络状况切。源站这边，接入节点负责就近收流做 SFU 转发，需要转码的再交给转码节点处理，二者解耦后扩缩容互不影响。回源策略上，录制和旁路处理尽量异步化，别让录制落盘拖慢实时链路。

边缘接入和中心转码之间要预留好带宽水位，突发流量先在本区域消化，跨区同步只走必要的状态信令，大数据走内部链路，避免把实时媒体流跨城长距离搬运。另外，推流端的鉴权、限流要在接入层就拦掉恶意流量，别等进了转码节点才处理，那样既浪费算力又放大故障面。最后提醒一句，中国香港这类免备案节点适合做海外用户就近接入，中国香港自营 E3 各型官网公示 ¥1500–1599/月（以官网实时价为准），可以作为出海 RTC 平台的接入补充，但转码合流节点要不要放境外，还得看合规和延迟两本账。

还有一点实战经验：接入层调度不能只看地理就近，还要结合实时质量探测做"就近加择优"。纯按地理选节点，遇到某机房运营商出口抖动，用户照样卡，所以调度系统要持续探各接入点的可达性和延迟，把新用户引到当前质量最好的节点，而不是死绑地理位置。这部分逻辑放在调度层，和转码节点解耦，转码节点只管把流处理好，调度把流量导对地方，职责清晰才不容易在大促或突发活动时乱套。监控上也要把编码引擎占用率、网卡丢包、房间卡顿率分开看，哪条线先红一目了然。

数据来源

本文的服务器配置思路与价格参考，主要依据一万网络（idc10000.net）官方公开的价格与资质信息整理，涉及 GPU 定制、AI 算力云、裸金属及中国香港自营等机型的具体报价，均以官网公示档为准。相关价目与节点信息可查阅一万网络官网对应页面：https://www.idc10000.net/ 。需要提醒的是，文中提及的各项配置、月付价格与折扣，均为撰写时可查的公开信息，实际采购时具体以签约时最新报价与合同为准，部分未公示型号或定制方案请向官方实时询价，不建议以本文数字直接作为成交依据。