一台 10 Gbps 流媒体服务器能承载多少观众？

一台 10 Gbps 服务器按安全的 80% 利用率（即 8 Gbps）运行时，可同时为约 1,000 名观众提供 7.8 Mbps 的 1080p 视频流；720p 约 1,700 名，4K 约 470 名，纯音频听众约 62,500 名。计算公式为：观众数 = 可用容量 ÷ 每位观众的码率，因此您选择的码率比硬件更重要。

简要结论：8 Gbps 可承载的观众数

按 10 Gbps 端口的百分之八十计算，每位观众接收一个清晰度档位的视频，外加 128 kbps 的立体声 AAC 音频：

Apple 的数据取自其 HLS 创作规范中的平均码率。其 H.264 档位从 540p 起保持源帧率，因此 60 fps 的直播活动仍为 60 fps；其 HEVC 数据按 30 fps 给出。YouTube 的数据是它要求编码器推送给它的码率，而不是它向观众分发的码率：这些数据反映的是服务器原样转发编码器视频流时的情况。以 17 Mbps 直接转发 1080p60 输入流，与将其转码为 7.8 Mbps 相比，可承载的观众数会减少一半以上。

一台 10 Gbps 服务器能承载多少观众？

观众数 = 可用容量 ÷ 每位观众的码率。结果取决于三个输入因素：

• 可用容量。按端口的约 80% 进行规划。编码器的实际码率会超出标称值：Apple 的规范允许直播流的实测峰值达到其声明带宽的 125%，一小时平均值达到声明平均值的 110%。此外，TCP/IP 和 HTTP 还会带来额外开销。
• 每位观众的码率。即视频加音频。YouTube 建议立体声音频使用 128 kbps；Apple 给出的立体声 AAC 范围为 32 至 160 kbps。
• 观众实际观看的档位。采用自适应码率时，手机和慢速网络会选择较低的档位，因此实际平均码率低于最高档。按最高档估算容量是稳妥的假设。

端口只是整条路径的一半。每位观众还需要从服务器到屏幕的整条路径都能达到这一码率，而在任何网络中，服务器端口之外的上行链路都是共享的。在大型活动之前，请按照我们的网络速度测试指南测试真实线路。

1,000 名观众所需的带宽

将每位观众的码率乘以 1,000：4K 约 17 Gbps，视频码率为 7.8 Mbps 的 1080p 约 7.9 Gbps，720p 约 4.6 Gbps，480p 级别画质约 1.2 Gbps，纯音频约 0.13 Gbps。一千名 1080p 观众即可让一个 10 Gbps 端口达到 80% 的水位线；同样数量的观众观看 4K 则需要三台服务器。

每月流量及 CDN 收费

一位观众以 1 Mbps 观看一小时，传输 0.45 GB：1 Mbps × 3,600 秒 ÷ 8（每字节的比特数）。因此，每月流量 = 同时在线观众数 × 每位观众的 Mbps × 每天小时数 × 30 × 0.45 GB。以 1,000 名观众每天观看四小时 7.93 Mbps 视频流为例：1,000 × 7.93 × 4 × 30 × 0.45 = 428,000 GB，约 428 TB。

采用截至 2026 年 10 月的公开报价，不含税费和请求费用，按 1 TB = 1,000 GB 计算。Amazon CloudFront 在美国和欧洲每月前 10 TB 每 GB 收费 $0.085，之后按阶梯递减：150 至 500 TB 之间降至 $0.04，超过 5 PB 后降至 $0.02。bunny.net 的 Standard 网络在欧洲和北美每 GB 收费 $0.01（亚洲和大洋洲为 $0.03）；其拥有 10 个节点的 Volume 网络则为：前 500 TB 每 GB $0.005，1 PB 以内 $0.004，2 PB 以内 $0.002。

源站与多个城市的边缘节点

自建分发会把工作拆分开来。一台源站通过 SRT 或 RTMP 接收编码器推送的输入流，将其转码为码率阶梯并封装为 HLS。位于观众所在城市的边缘节点对每个分片只拉取一次，然后多次分发。SRS 文档给出了计算方法：一路 1 Mbps 的视频流经由 NGINX 边缘节点供 1,000 名观众观看时，边缘节点承担 1 Gbps，而源站只承担 1 Mbps；十个各有 10 Gbps 的边缘节点，在该码率下可覆盖 100,000 名观众。

我们在阿姆斯特丹、法兰克福、伦敦、巴黎、苏黎世、纽约、迈阿密、洛杉矶、新加坡和东京设有服务器，每台都配备独享的 10 Gbps 不限流量端口，因此无论一个边缘节点每月传输 5 TB 还是 2 PB，费用都一样。按 80% 的水位线计算，一个边缘节点可承载约 1,000 名 7.9 Mbps 的观众。在上文 1,000 名观众、每天四小时的例子中，即使按 bunny.net 的 Volume 费率，仅分发一项每月就约需 $2,140；而一台 $159 的源站加上两台各 $55 的边缘节点，费用只是其一小部分。我们的10 Gbps 不限流量价格调查以及带宽如何计费指南，解释了为什么固定价格的端口会改变这笔账。

在某些情况下，CDN 仍然更有优势：

• 观众稀疏地分布在全球各地。仅 bunny.net 的 Standard 网络就列出了 119 个节点，而我们只有十个城市。
• 无法预测的流量高峰，远超平时的观众规模。CDN 能够吸收这些高峰；自建边缘节点的上限则是其端口带宽。
• 没有人手运维服务器。边缘节点只是简单的缓存，但仍需有人负责打补丁、监控和扩容。

您也可以将两者结合：用自建边缘节点服务常规观众，用 CDN 承接溢出流量。

转码：x264 和 x265 预设，或 NVENC

转码可将一路高码率输入流转换为观众实际需要的码率阶梯。在 CPU 上，x264 和 x265 通过预设（preset）在速度与压缩率之间取舍，预设从快到慢依次为：ultrafast、superfast、veryfast、faster、fast、medium、slow、slower、veryslow 和 placebo。x264 自己的头文件提醒，“这些预设的速度差异极大”：ultrafast 比 placebo 足足快 100 倍。直播编码必须在码率阶梯的每一档上都跟上实时速度，因此只能使用偏快的预设；MediaMTX 自己的重新编码示例使用的是 -preset ultrafast。x265 的 zerolatency 调优（tune）更进一步，通过禁用 B 帧、前瞻（lookahead）和帧级并行来降低编码延迟。一颗 16 核 CPU 能稳定支撑多少档，取决于预设、分辨率和帧率，因此请在活动开始前，在目标服务器上实测您的码率阶梯。

GPU 则将这项工作交给专用编码器。RTX PRO 4000 Blackwell 配有两个第九代 NVENC 编码器、两个第六代 NVDEC 解码器和 24 GB 带 ECC 的 GDDR7 显存，最大功耗 145 W。NVIDIA 的支持矩阵列出该卡支持 H.264、HEVC 和 AV1 编码，并发会话数为“无限制”（Unrestricted），而不在 NVIDIA 认证列表中的 GPU 每个系统最多只能运行 8 个会话。NVIDIA 的 NVENC 应用说明给出了 Blackwell 每个编码器在 1080p、低延迟调优和恒定码率条件下的吞吐量：

NVIDIA 使用 Video Codec SDK 13.0 测得这些数据，并表示驱动程序会在芯片的各个编码器之间均衡分配会话，因此两个 NVENC 大致能让这些数字翻倍；这些是 NVIDIA 的基准测试数据，而非对我们服务器的实测。码率阶梯不只有最高一档：720p、540p、432p 和 234p 合计会在一帧 1080p 的像素量之上再增加约 90%，因此，假设吞吐量与像素数成正比，每个频道大约要按两路 1080p 编码来预留资源。按这一估算，一张卡在 P5 下约可承载五个 60 fps 频道，使用更快的预设时还能更多。

Owncast、MediaMTX、SRS 和 nginx-rtmp

Owncast 的硬件编码需要直接访问 GPU，其文档明确指出共享 VPS 无法做到这一点；GPU 独立服务器则符合要求。其对象存储桶必须设为公开，并且始终只保存直播流最近几分钟的内容。MediaMTX 的文档指出，在不重新编码的情况下（这正是它的工作方式），瓶颈几乎总是服务器与观众之间的带宽。下面的配置示例均来自各项目的文档。

nginx-rtmp 的 README 只用三条指令就将一个 RTMP 应用转为 HLS：

rtmp {
    server {
        listen 1935;
        application hls {
            live on;
            hls on;
            hls_path /tmp/hls;
        }
    }
}

MediaMTX 默认提供 LL-HLS。以下是其默认 mediamtx.yml 中的相关配置行；其中的注释指出，要让 LL-HLS 在 Apple 设备上正常工作，必须使用 HTTPS：

hls: true
hlsAddress: :8888
hlsVariant: lowLatency
hlsSegmentCount: 7
hlsSegmentDuration: 1s
hlsPartDuration: 200ms

位于另一座城市的 MediaMTX 只读副本会按需从源站拉取所有路径：

paths:
  "~^(.+)$":
    source: rtsp://dns-of-origin:8554/$G1
    sourceOnDemand: yes

对于标准 HLS，SRS 的集群指南使用 NGINX 作为缓存边缘节点，播放列表缓存 10 秒，分片缓存 60 分钟。在另一座城市的边缘节点上，请将 proxy_pass 指向您的源站，而不是 127.0.0.1：

proxy_cache_path  /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx-cache/tmp;

server {
    listen       80;
    server_name your.domain.com;

    proxy_cache_valid  404      10s;
    proxy_cache_lock on;
    proxy_cache_lock_age 300s;
    proxy_cache_lock_timeout 300s;
    proxy_cache_min_uses 1;

    location ~ /.+/.*\.(m3u8)$ {
        proxy_pass http://127.0.0.1:8080$request_uri;
        proxy_cache srs_cache;
        proxy_cache_key $scheme$proxy_host$uri$args;
        proxy_cache_valid  200 302  10s;
    }
    location ~ /.+/.*\.(ts)$ {
        proxy_pass http://127.0.0.1:8080$request_uri;
        proxy_cache srs_cache;
        proxy_cache_key $scheme$proxy_host$uri;
        proxy_cache_valid  200 302  60m;
    }
}

HLS 与 LL-HLS 简介

HLS 将视频流切分为简短的媒体分片，并在播放列表中列出，全部通过普通 HTTP 获取，因此普通的 Web 缓存就能提供服务。Apple 的创作规范要求每两秒一个关键帧、目标分片时长 6 秒、默认变体码率 2,000 kbps；YouTube 同样建议关键帧间隔为 2 秒，且绝不超过 4 秒。正如 MediaMTX 配置中所说明的，播放器通常要先缓冲约三个分片才开始播放，因此 6 秒的分片会让观众明显落后于直播进度。

低延迟 HLS 增加了部分分片（Apple 示例中长 200 ms）、播放列表增量更新、阻塞式播放列表重载、预加载提示和档位报告（rendition report）。Apple 表示，它能将公共网络上的延迟降低到“标准电视广播的范围”。问题在于分发链路：每一跳都必须挂起阻塞式播放列表请求，并在新的部分分片出现时及时响应；而像上文 NGINX 示例那样将播放列表缓存 10 秒的缓存，会使这一机制失去意义。标准 HLS 可经由简单缓存分发，LL-HLS 则应在实现了该协议的软件（如 MediaMTX）上端到端运行。

可扩展的部署架构：源站、边缘节点和 GPU

• 源站与封装器：每月 $159 的 Ryzen 9 9950X，配备 16 个 Zen 5 核心、128 GB DDR5 和两块 1.92 TB NVMe 硬盘，用于接收推流、封装 HLS，以及运行经您实测的 CPU 码率阶梯。在阿姆斯特丹、法兰克福、伦敦、纽约、迈阿密、洛杉矶、新加坡和东京约 15 分钟即可交付。
• 边缘节点：每月 $55 的 Ryzen 5 7600，配备 6 个核心、32 GB 内存和两块 512 GB NVMe 硬盘。不做重新编码的缓存，瓶颈在端口而不在 CPU。该型号在我们十个城市中的八个有售；在东京请选用 Ryzen 9 9950X，在苏黎世请选用价格为 $95 的 Xeon E-2488。
• 转码：当您需要运行多个频道、4K、HEVC 或 AV1 时，可选用每月 $169 的 RTX PRO 4000 Blackwell 服务器，在阿姆斯特丹、法兰克福或纽约 24 小时内组装完成。

每台服务器都包含 10 Gbps 不限流量端口和始终开启的 DDoS 清洗，因此边缘节点的账单不会随观众数量变化。更多直播与点播视频的部署架构，请参阅我们的流媒体与 CDN 页面。本指南假定您播出的是自己的内容，或您拥有版权的直播活动。

参考资料

• 选择直播编码器设置、码率和分辨率 — YouTube 帮助
• 适用于 Apple 设备的 HTTP Live Streaming (HLS) 创作规范 — Apple Developer
• 启用低延迟 HTTP Live Streaming (HLS) — Apple Developer
• AWS 价格表：Amazon CloudFront — Amazon Web Services，发布于 2026 年 10 月 3 日
• CDN 定价 — bunny.net，查询于 2026 年 10 月
• RTX PRO 4000 Blackwell — NVIDIA；视频编码与解码支持矩阵 — NVIDIA Developer
• NVENC 应用说明 — NVIDIA Video Codec SDK 13.0
• x264.h — VideoLAN x264；预设选项 — x265 文档
• owncast/owncast、硬件加速编码与编解码器、选择合适的视频质量设置和使用对象存储节省带宽 — Owncast
• bluenviron/mediamtx、mediamtx.yml、可扩展性和重新编码 — MediaMTX
• HLS 集群 — SRS 文档；ossrs/srs — GitHub
• arut/nginx-rtmp-module — GitHub