一、容量为什么总估偏

1.1 两种最常见的估法

第一种是按最高峰备。计划上线的是面向内部员工的问答入口，担心第一天访问集中，干脆照最忙那个时段的量配足算力。上线之后发现，除了每天上午那一两个小时，其余时间算力几乎空转，而这份空转要持续很久。

第二种是按平均备。把预计的日请求数除以一天的总秒数，得出每秒要处理多少个请求，再乘上一个看着合理的余量。这个算式本身没有错，错在它假设请求在一天之内均匀分布。真实业务是有人上班才用、开会才用、推送发出去才用，请求天然是成串到来的。

两种估法错在同一处：都用一个静态数字去描述一个动态过程。容量测算真正要得到的，不是一个精确到个位的数字，而是一个有依据的区间，以及什么时候该扩、扩多少的判断规则。

1.2 偏差通常来自三个地方

①把请求当成均匀到达。多数业务在一天里有两到三个高点，中间夹着明显低谷，高峰期速率可能达到日均速率的数倍。只看日均，等于用最平静的时刻去迎接最拥挤的时刻。

②只算输入不算输出。提问往往只有几十个字，回答却可能有几百上千字。更关键的是，这两段耗时在性质上完全不同，后面的名词部分会专门讲。

③忽略重试与重复提交。用户等待超时后会再点一次，接口调用失败后程序会自动重发。这些请求在统计口径里只算一次，在真实负载里却实实在在占了两份算力。

1.3 先把目标说清楚

容量测算要回答三个问题：平时需要多少、高峰需要多少、从平时到高峰用什么方式补上。第一个决定基础配置，第二个决定弹性上限，第三个决定伸缩策略。三个问题分开回答，比合成一个总数要清楚得多。

二、三个必须先弄懂的名词

2.1 请求速率与并发数

请求速率是每秒钟有多少个请求进来，常用每秒请求数来描述；并发数是同一时刻有多少个请求正在被处理。两者之间隔着一个“单个请求要占用多长时间”。粗略的换算是：并发数大致等于请求速率乘以单个请求的处理时长。

举个便于记住的例子：如果每秒进来十个请求，每个请求从进入到出结果平均占用两秒，那么平均有二十个请求同时在处理。这个换算关系是后面所有测算的骨架，因为它把“业务量”和“算力”这两件看起来不相干的事连在了一起。

2.2 输入长度与输出长度

2.2.1 为什么输出更占时间

输入是一次性交给模型的，可以整体并行处理，长度增加带来的时间增长相对平缓。输出不一样，它是一个字接一个字生成的，每多写一个字就要多做一步计算，前面的结果还是后面计算的前提。所以回答长度对耗时的影响，比问题长度大得多。这也解释了一个常被误解的现象：问一句话等很久，问题不在问题短，而在回答长。

2.2.2 怎么取到真实长度

不要凭印象估，从历史记录或试运行数据里抽样统计。抽样时要注意两点：一是按业务分开统计，内部问答、对外服务、报告生成这三类的长度分布差别很大，混在一起算没有意义；二是取较慢的那部分样本，而不是平均值，因为让用户不满的往往不是平均体验，而是慢的那几次。

2.3 峰值系数

峰值系数是高峰期速率与日均速率的比值。多数业务落在一个不算大的区间里，但带有明显活动属性、或者与固定作息强相关的业务会高出不少。这个系数没有通用答案，只能靠两类数据校准：同类业务的历史经验，以及自己试运行期间的实测曲线。先给一个保守估计，跑一段时间后用真实数据修正，比一开始就追求精确要务实。

三、四步测算的具体走法

3.1 第一步：把业务量换成请求速率

这一步的输出是“高峰时段每秒多少个请求”，需要三个小动作：

①先算日请求数。用使用人数乘以人均使用次数，得到一天的粗略总量。注意乘以实际活跃比例，而不是全部在册人数，否则结果会明显偏大。

②判断高峰落在哪个时段。多数办公类业务集中在上午开始工作后的一两个小时，对外服务类则与推送、活动、媒体曝光的时间点强相关。把一天切成若干段，找出最集中的那一段。

③按重试比例上浮。把超时重发、用户看到没反应又提交一次的因素加进去，通常留出一到三成的上浮空间。这一步看着琐碎，却常常是上线后“明明算过还是不够”的直接原因。

3.2 第二步：把长度换成单次计算量

有了每秒请求数，还要知道每个请求本身有多“重”。这里用抽样得到的输入长度与输出长度，估算单次请求占用的相对计算量，再乘以每秒请求数，得到一个总量参考。

估的时候要给输出长度更高的权重。一个实用的经验是：把输出长度按比输入长度更重的比例计入。这样算出来的总量虽然仍是估算，但方向上不会偏，足以支撑规格选择。

3.3 第三步：测出单份算力能承接多少

3.3.1 为什么这一步必须压测

同样一份算力，跑不同规模的模型、面对不同长度的请求、采用不同的精度设置，能承接的并发数可以相差数倍。仅靠理论推算，误差常常大到失去参考价值。可行的办法是搭一个小规模环境，用贴近真实的请求做一轮压测，逐步加压直到完成时间开始明显变长，这个拐点附近就是可承接的上限。

3.3.2 要同时看两个口径

第一个口径是第一个字出现的时间，它决定用户“觉不觉得卡”；第二个口径是整个回答完成的时间，它决定用户“愿不愿意等”。两个口径要分开记录，因为二者受不同因素影响：前者与排队和读入相关，后者与输出长度和生成速度相关。只优化其中一个，用户感受往往改善有限。

3.4 第四步：留余量、按增长分期

压测得到上限之后，不要把这个上限直接当成可用容量。留出三到五成的余量，用于应对突发访问、模型版本切换期间的并行运行，以及效果比预期更好带来的额外用量。

然后按增长分期。第一期只满足试运行与首批用户，第二期按实际增长扩，第三期再考虑多业务共用。每一期都把扩容触发条件写成明确的数字，例如较慢那部分请求的等待时间持续超过某个阈值，或者算力使用率在高峰时段连续多日高于某个水平。写成数字，扩容就不再依赖“感觉变慢了”这种判断。

四、四类业务的估算差别

4.1 内部问答类

使用人数相对固定，高峰集中且规律，请求长度偏短，回答也以简短结论为主。这类业务的容量曲线平稳，估算误差的影响可控，重点应放在响应即时与答案准确上，算力配置不必追求宽裕，留出适度余量即可。

4.2 面向公众的服务类

访问量受时段、活动与外部因素影响明显，峰值系数往往偏高，重试比例也更高。这类业务的关键不是平时够不够，而是高峰会不会塌。估算时应把峰值系数取大一些，并优先保证高峰期的弹性上限，而不是平峰期的配置规模。

4.3 批处理类

这类任务不需要即时响应，可以排队、可以错峰、可以分批推进。估算的重点从“每秒多少请求”转成“总量多久能跑完”，判断依据是整体完成时间而不是单次延迟。给这类业务留容量的方式也更灵活，把夜间与低谷时段的算力用起来，往往比单纯扩容更有效。

4.4 长文生成类

输出长度远超其他类型，单个请求占用算力的时间也长得多。这类业务的并发需求未必高，但单请求的资源占用大，一旦中途被打断，已经生成的部分就白费了。估算时应以单请求的完成时间为主要依据，同时把不被打断作为一项明确要求写进容量判断里。

五、天翼云息壤平台推理服务如何支撑这套测算

5.1 规格可选，先匹配再谈数量

息壤平台推理服务提供多种算力规格，可以按模型规模与并发需求选择。这一步看着简单，实际影响很大：规格选小了，靠堆数量补不上单请求的完成时间；规格选大了，单位算力的利用率又上不去。先按模型规模定规格，再按并发需求定数量，顺序不能反。

5.2 推理加速与请求合并，提升单位算力的产出

平台内置推理加速能力，并可把多个同时到达的请求合并处理。对容量测算来说，这一项的意义是改变分母：同样的算力能承接更多请求，前期估出的总量需求就可能相应下调。压测时若把这个因素算进去，结论会更接近实际。

5.3 弹性伸缩，把按峰值备变成按需取用

既然高峰与平峰的差距是客观存在的，就不必用一份固定配置去覆盖全天。弹性伸缩让高峰自动扩、低谷自动收，容量的实际形态从一条直线变成一条跟随业务起伏的曲线。这也是前面反复强调分开回答“平时多少、高峰多少”的原因：两者的补法本来就不一样。

5.4 用量与等待情况可见，边跑边校准

平台提供请求量、完成时间、排队情况等观测信息。这些数据除了用于日常运维，还有一个容易被忽略的用途：回头校验当初的估算。试运行一到两周后，把实测的峰值系数、平均长度、命中上限与当初的假设逐项对照，偏差大的那一项单独修正，下一轮估算就会明显更准。

5.5 从试运行到扩容的平滑路径

从少量用户试运行起步，逐步扩大范围，是这套测算方法能落地的前提。试运行期间既验证效果，也验证容量假设；确认之后按分期计划扩容，比一次性铺开风险小得多。作为天翼云一体化智算服务平台面向企业与开发者的服务化出口，息壤平台推理服务向下纳管各类智算资源、向上提供标准化调用方式，这套结构使规格调整与容量扩展都不必重做业务侧改造。

天翼云在智算与调度方向的持续投入也获得过公开认可，包括央企十大超级工程、算力中国·年度突破成果、十大硬核科技、世界互联网大会杰出贡献奖等评价，均可通过官网与官方渠道查询。这些信息对容量规划的直接帮助有限，但它说明平台的底座能力经过了较长时间的检验，对于需要按年度做资源安排的单位来说，是一个可以参考的侧面。

六、三条落地建议

1、先跑一段试运行再定容量。任何纸上估算都比不上两周真实数据，用试运行校准峰值系数与平均长度，再据此定第一期配置，误差会小得多。

2、把长度与并发当成两个独立变量分别记账。很多估算失准，是因为把二者混成一个“请求量”指标。分开记录之后，长回答增多、并发突然上升这类变化就能被及时识别，而不是等到整体变慢才发现。

3、把扩容条件写成明确数字。较慢那部分请求的等待时间、高峰时段的算力使用率、排队长度，任选两三个作为触发条件，写进运维手册。这样扩容就不再取决于谁的感受更强烈，而是取决于数据。

回到最初的问题：一套推理服务该备多少算力，答案不是一个数字，而是四步走下来得到的一个区间，加一套随业务变化调整的规则。测算的价值不在于第一次就估得准，而在于让每一次偏差都能被解释、被修正。当一个团队能说清自己为什么这么配、什么时候该扩，容量就不再是上线前的一次赌博，而是一项可以持续经营的工作。