直播平均码率波动大时，带宽峰值不能按平均码率乘观众数估算，而要基于“瞬时码率上限”和“并发观众峰值”的乘积，并预留至少30%冗余，否则极易卡顿。
为什么平均码率算不出真实峰值
很多运营者习惯用“平均码率 × 在线人数”来买带宽，这在码率平稳的影视类直播里勉强够用，但游戏、户外、演唱会这类画面变化剧烈的直播，平均码率只是个伪概念，一个画面快速切换的FPS游戏，某几秒编码器可能瞬间冲到12Mbps，下一秒静止画面又跌回2Mbps，平均下来是6Mbps，可瞬时码率峰值往往是平均值的2到3倍。
行业共识认为,直播卡顿的根因多半不是平均带宽不足，而是峰值瞬间撑爆了管道，CDN厂商看的是95月结或日峰值带宽，你按平均码率买，遇到高动态画面基本必卡。
带宽估值的核心公式很简单：
带宽峰值（Mbps）= 视频单路码率峰值（Mbps）× 同时观看人数峰值
问题在于,多数人把“码率峰值”填成了“平均码率”，正确做法是先抓取推流端的实际瞬时码率曲线，再乘以观察到的并发人数峰值，最后加上冗余。
三步估算带宽峰值，实操可验证
第一步：从推流端抓真实瞬时码率
不要看OBS或直播软件面板上的“平均码率”，那是个平滑后的数值，你需要看每一帧或每100ms的码率输出。
- 用OBS时,打开“视图 → 统计”，关注“比特率”那一栏的跳动区间，别记最高值，要记持续1秒以上的高值。
- 用ffprobe拉流采样,命令示例：
ffprobe -v trace -show_entries packet=size -select_streams v -of csv rtmp://你的推流地址，把输出导成文本，算每秒的字节数乘8。 - 多数直播平台在推流端会强制限制码率上限,比如抖音通常限制1080P在6Mbps左右，但自建源站或拉流转推时，上限可能由你自行设定，这时就必须实测。
建议连续录制
至少10分钟包含多人团战、爆炸、快速旋转等场景，从中提取最大瞬时码率，如果无法实测，参考经验值：1080P 30帧的H.264直播，动态内容码率峰值一般按8-12Mbps估算；高动态游戏或体育赛事，直接按15Mbps算，别嫌多。
第二步：并发人数峰值取“最高同时在线”，不是平均在线
人数波动和码率波动叠加时,峰值出现在“码率高峰”和“人数高峰”的重合区间，比如晚间8点人最多，但画面最激烈的是比赛最后5分钟，这时两者刚好撞上。
- 从后台拉取最近30天的“同时在线人数”分钟级数据，找出最高值。
- 若有大主播引流、广告投放计划，提前把预期新增人数叠加进去。
- 多次活动直播时,别拿上个月平均在线去算，必须用历史最大值乘以1.2的经验系数，因为每次活动的传播效果可能更强。
第三步：乘完再加30%冗余，并考虑转码链额外开销
假设实测单路码率峰值为10Mbps,并发人数峰值为5000人，那么基础峰值是50Gbps，但这只是观众拉流侧的带宽，如果直播流还做多码率转码、录制、截图审核，每路附加处理通常要另占单路码率的5%-10%。
TCP重传、跨地域调度不均、机房限速，都会吃掉一部分名义带宽，稳妥做法是在乘出来的数字上额外加30%，以上例而言，最终采购带宽应不小于65Gbps。
不同场景的估算结果可以参考下表：
| 直播类型 | 典型单路码率峰值 | 每千观众所需带宽 |
|---|---|---|
| 静态授课（PPT+头像） | 3-5 Mbps | 3-5 Gbps |
| 户外徒步（手持设备） | 6-8 Mbps | 6-8 Gbps |
| 游戏竞技（高动态） | 10-15 Mbps | 10-15 Gbps |
| 体育赛事（高速运动） | 12-18 Mbps | 12-18 Gbps |
注意,以上是单路原始码率，如果你买了转码服务，清晰度自适应会生成多路不同码率，观众实际取流可能是较低码率的子流，这时候按最大码率乘人数会偏高，但为了保障峰值体验，按高码率子流计算是更安全的策略；若想省钱，可以按不同清晰度的观众占比加权计算，但这需要精确的观众分档日志，大多数中小直播方不具备这个条件，不如按上限买。
码率波动大时，如何用“缓冲策略”降低实际带宽峰值
估算之外,你还可以主动削峰，让带宽需求更平缓，从而降低采购成本。
- 开启GOP缓存或关键帧间隔拉大：H.264的GOP从2秒增加到4秒，能略微降低瞬时码率尖峰，但会提高首开延时，代价是切流时花屏概率增加。
- 使用转码降帧率：把30帧降到25帧，码率峰值能降15%-20%，对画面流畅度影响不大。
- 应用层做流控：在推流端设置编码器输出“最大码率上限”，把12Mbps的尖峰钳制在8Mbps，虽然画质在剧烈运动时会略有软化，但带宽曲线变得平滑。
- 多CDN智能调度：不要只挂一家CDN，当某节点瞬时流量超过阈值时，自动把新进观众调度到空闲节点，这能避免单点带宽被打满。
这些操作理论上能把码率波动带来的峰值需求降低两到三成,但注意，编码器限码率会损伤画质，如果是大型商业直播，建议宁可多买带宽也不要砍画面质量。
预估带宽峰值时常见的两个坑
坑一：把“平均码率”当成“最大码率”填进公式。 很多云厂商的带宽计算器默认输入平均码率，你自己得先手动换成峰值，否则结果偏小一半甚至更多，正确流程是先测出最大瞬时码率，再填计算器。
坑二：忘记叠加“推流上行带宽”。 以上讨论的都是播放端下行带宽，如果你的推流端是单机直播，一台电脑同时推流到多个平台，上行带宽峰值同样需要按单路码率峰值乘以推流平台数计算，普通家庭宽带的上行通常只有20-30Mbps，推两个8Mbps的流加上其他开销可能刚好够，推三个就废了。
直播带宽峰值估算的常见问题
问：码率波动大，用平均码率加一个固定余量，比如加50%，这样可以吗？
不可以,平均码率加固定百分比仍然是近似方法，因为动态画面的瞬时峰值可能达到平均码率的3倍，而50%的余量远不够，必须使用实测的瞬时码率峰值，或者至少按经验值上限估算。
问：带宽峰值是看并发人数峰值还是日活用户？
并发人数峰值,也就是同时在线观看直播的人数，日活用户分散在不同时间打开直播间，不产生同时叠加的流量压力，从CDN账单看，计费带宽也是按并发取样的。
问：如果用的是平台自带的转码服务，带宽怎么算？而且我的直播码率波动大，用哪个码率去算？
平台转码后观众会拉到多个清晰度版本,此时每位观众的取流码率取决于播放器选择的清晰度，你无法直接控制每位观众的具体档位，最稳妥的方案是统计转码后各个档位的实际输出码率，并按其分别占同时在线人数的比例加权求和，如果没有分档统计数据，则按最高清晰度档位的码率峰值乘总人数计算，虽然买多，但不会卡。
问：直播时画面变化很剧烈但平均码率低，怎么判断够不够？
先看播放端是否卡顿,再看CDN监控面板里的带宽曲线有没有出现平台型尖峰，如果带宽曲线在某个时间点突然拉直或触顶，说明那段时间码率峰值已经顶到采购上限了，建议把带宽监控和直播画面关键帧做时间轴对齐，找出每次卡顿前3秒的带宽负载，如果负载超过90%持续了5秒以上，那么你的带宽峰值估算值偏低，需要上调20%以上。