A Craftsman
我的第一项专利：用「95 区间」把 CDN 带宽成本分得更准
这是我在字节跳动做 CDN 成本分摊时设计的一套算法，后来申请了专利，并在中国和美国都拿到了授权。我是第一发明人。这篇文章不讲法律文本，用大白话说清楚它解决了什么问题、是怎么做的。
专利信息
| 中国 | 美国 | |
|---|---|---|
| 名称 | CDN中的信息处理方法、系统、设备和存储介质 | Method and system for processing information in CDN, device, and storage medium |
| 专利号 | CN117061354B | US12375742B2 |
| 申请日 | 2023-10-10 | 2024-10-10 |
| 授权日 | 2024-01-12 | 2025-07-29 |
| 专利权人 | 北京火山引擎科技有限公司 | Beijing Volcano Engine Technology Co., Ltd. |
| 原文 | 下载 PDF | 下载公开文本 PDF · USPTO 授权全文 |
一、问题：一份带宽账单，怎么分给很多用户？
CDN 厂商（或者一家公司内部采购 CDN 的平台）买的是一整份带宽，再给很多用户、很多域名共享着用。月底付给上游的带宽费用，业内最常见的计费方式是 95 峰值：
一个月里每 5 分钟采一个总带宽点，30 天共 8640 个点。从大到小排序，去掉最高的 5%（432 个点），剩下的最大值，也就是第 433 个点，就是「95 带宽值」，按它计费。
钱是按总带宽付的，接下来要回答的问题是：这笔钱里，每个用户该承担多少？ 这就是成本分摊，它直接决定了每个客户的毛利、每个内部业务该被收多少钱。
二、传统做法：只看 95 那一个时间点
常见的做法很直接：找到 95 带宽值对应的那个时间点（「95 时间点」），看每个用户在这个时间点用了多少带宽，按比例分。
比如 95 带宽值是 300，用户 A 在 95 时间点用了 100，那 A 就承担三分之一的成本。
简单，但有两个硬伤。
1. 只看一个点，不能代表整个月。 假设 95 时间点落在第 15 天，用户 A 那一刻恰好没用带宽，但第 16 到 25 天用得很猛。按这种算法，A 一分钱不用分摊，可实际上正是 A 这些天的高用量把整体带宽和成本推高了。
2. 选哪个点，结果就不一样。 总带宽曲线一天里通常有早晚两个高峰，一条水平线（95 带宽值）会和曲线交出好几个点，这几个点的总带宽都等于 95 值。随便挑一个，分摊结果可能天差地别：在 a 点 A 没用带宽，不用分摊；换成 b 点 A 用了，就要分摊。同一份账单，结果取决于运气。
三、我的做法：把「一个点」换成「一段区间」
核心想法一句话：不看单个时间点，而是看 95 值附近的一段带宽区间里，各用户整体用了多少。
具体分四步：
- 采样排序：取管理周期（比如一个月）内每个采样点的总带宽值，按时间排好。
- 划出管理区间：在 95 带宽值附近定一个下界 A 和一个上界 B（比如 95 值上下各取一个总带宽值），总带宽曲线落在 A 到 B 之间的那些时间段，就是「管理区间」。一个月里通常会有很多段。
- 算占比：统计每个用户在所有管理区间里用掉的带宽，除以全部用户在这些区间里用掉的总带宽，得到这个用户的使用占比。
- 按占比分摊：成本按这个占比分给各个用户。
下面是专利中的图 7，说明管理区间是怎么划出来的：
95 带宽值是图中的实线，A、B 是它下方和上方的两个阈值。总带宽曲线每次穿过 A、B 之间这条带，就形成一段管理区间。一天有早晚两个高峰，每个高峰的上坡和下坡各穿过一次，所以这里有 a1–a2、b1–b2、c1–c2、d1–d2 四段；一个月下来，就是几十上百段。
第 3 步有两种算法，可以按需选择：
- 累加法：直接把区间内各采样点的带宽值加起来。用户 A 的占比 = A 在区间内各点带宽之和 ÷ 区间内各点总带宽之和。计算简单，省算力，工程上最常用。
- 积分法：把总带宽和每个用户的带宽分别拟合成曲线，用区间内曲线下的面积来算占比。精度更高。
专利中的图 6 把积分法画得很直观：
- 最下面的曲线是用户 A 的带宽；中间是 A 和 B 叠加；最上面是 A、B、C 三者叠加，也就是总带宽；
- 顶部横着的浅灰色带，就是 95 值附近的阈值带，竖向的四根条带就是管理区间；
- 在每根条带里，从下往上三种灰度，分别是 A、B、C 在这段时间里的用量（曲线下的面积）；
- 某个用户的使用占比 = 他在所有条带里的面积之和 ÷ 所有条带的总面积。
这就像微积分里用面积来累计一段时间内的量：看的不是某一个瞬间谁用得多，而是整段高峰期里，每个人贡献了多少。
另外还有一个约束：区间内的采样点数量，占整个周期采样点的比例不能低于某个阈值。区间太窄、点太少，结果又会退化成「只看几个点」。
四、为什么这样更准
回到前面的两个例子：
- 用户 A 在 95 时间点没用带宽，但在区间里其他时间点用了：传统做法判定 A 不用分摊，区间法会把 A 的用量算进去。
- 有好几个点都等于 95 值：区间法本来就把这些点都包含在内，不存在「挑哪个点」的问题，结果是稳定的。
还有一个实际业务中很常见、单点法处理不好的情况：按流量计费的客户，以及月中才接入的客户。
CDN 厂商和上游运营商结算带宽，通常是按所有客户叠加后的总带宽取 95 值。但下游客户的计费方式各不相同：有的客户和我们按带宽结算，有的按流量结算。按流量计费的客户，他付给我们的钱和 95 无关，可他的带宽一样叠加在总带宽曲线上，一样抬高了我们付给运营商的 95 值，理应分摊这部分成本。
单点法在这里很容易失真：
- 一个月中才接入的客户，如果 95 时间点落在他接入之前，他在那一刻的带宽是 0，就一分钱成本都分不到；
- 按流量计费的客户用量往往不规律，95 时间点恰好赶上他的低谷，分到的成本也会远低于实际。
但他们在月内的其他高峰期，确实贡献了相当一部分 95 值以上的打点。区间法覆盖的是整个月里所有的高峰区间，只要客户在这些时段有用量，就会按比例分到成本。这样算出来的客户毛利更真实，能减少「看起来很赚钱、其实在亏钱」的误判。
同时，区间是围绕 95 值划定的，保留了 95 计费的业务含义：分摊的依据依然是决定账单的那段高峰期用量，而不是全天的平均用量。
简单说，它既延续了 95 计费的逻辑，又解决了单点分摊不准、不稳的问题，对各种计费方式、各种接入时间的客户都能给出合理的成本。
五、落地情况
这套算法最早是我在字节做火山 CDN 经营分析时设计的。验证的方式很朴素：和数据工程团队一起，用全量客户的计费打点数据，把几种分摊方式都跑一遍，在 Grafana 上并排对比结果，用数据说服团队采用。
后来它的使用范围不断扩大：
- 火山 CDN 经营分析：每天定时产出客户、域名维度的成本，进一步算出收入和毛利率。
- 融合 CDN 内部结算：字节内部各业务（头条、抖音点播直播等）按这套方法分摊二三十家 CDN 厂商的采购成本。
- 火山多云 CDN 的 FinOps 能力：作为商用功能，帮客户把多家厂商的账单拆到域名。
数据团队后续的带宽成本分摊，也都基于这套算法实现。
六、原文下载
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！