业务量上升，不一定意味着算力需求按同一比例上升。缓存命中率提高、任务改批处理，或模型更换，都可能改变单位业务消耗。做好算力资源池容量预测与业务增长测算，应先拆开“业务会增长多少”和“每单位业务需要多少资源”，再核对峰值与供给时间。
1. 用可比负载建立基线
先选取能代表常态运行的时间窗口，按小时或更细粒度整理到达量、任务时长、资源占用和失败重试。突发活动、故障恢复、版本发布等特殊时段单独标注，不要直接当成日常基线，也不要简单删除：若这类场景会重复发生，就应另做峰值情景。
基线至少区分工作日与休息日；负载变化快的服务，采样间隔应足以看见短时尖峰，过度汇总会掩盖拥塞。数据口径要一致，例如同时确认统计的是成功请求还是全部请求，以及资源用量是否包含预留但闲置的部分。
2. 按工作类型拆分需求
不要把在线推理、模型训练和离线批处理合成一个平均负载。在线推理通常更关注响应时延与峰值并发；训练任务可能长时间占用加速器和显存；批处理则较容易错峰，但会受完成时限约束。同一台机器也可能因显存、内存、网络或存储瓶颈而无法互相替代。
建立分池或分队列清单，标明可共享的资源类型、任务优先级和可中断条件。共享池的好处是提高资源利用率，代价是高峰时竞争更明显；隔离资源能保障关键任务，却可能留下闲置容量。
3. 把增长假设拆成可验证驱动
将预测期内的业务量拆成用户数、单用户使用频次、单次处理规模等变量；只有能说明因果关系的变量才纳入模型。业务计划、产品发布和历史趋势应分别记录，避免把计划目标误写成已经发生的增长。
算力需求可按“业务量×单位业务资源消耗”估算。若业务量预计增加，但代码优化、模型压缩或缓存也会降低单次消耗，应分别列出两者的假设，不要只放一个净增长率。算力资源池容量预测与业务增长测算可据此形成低、中、高三种情景，并注明每种情景成立的条件。
4. 实测单位业务消耗，而非套用平均数
选取代表性请求或作业，在相同软件版本、输入规模和资源配置下重复运行，记录每单位业务占用的加速器时间、显存、内存及网络和存储读写。对输入长度差异明显的任务，按长度或复杂度分档；用单一平均值会低估大任务带来的资源需求。
预测时可先计算“单位业务资源消耗×预测业务量”，再按资源类型分别汇总。对关键服务做负载测试，观察吞吐增加后时延和排队是否明显恶化；资源使用率高，不代表还能线性承接更多业务。
5. 单独校准峰值并发与弹性余量
容量规划看的是同一时段可能同时发生的负载，而不是把每类任务各自的最高值直接相加。检查发布、批任务和在线流量是否会重叠，并依据真实运行安排判断错峰是否可行。峰值并发越集中，通常越需要保留弹性余量。
对于时延敏感服务，可把约20%至30%的可用容量余量作为初步测算区间，再通过压测和服务目标调整；这不是通用标准。批任务可接受延后时，优先评估排队和错峰能否替代新增资源。明确标注这两种策略的服务影响，避免把“可排队”误认为没有容量需求。
6. 把扩容周期纳入情景复核
扩容不只涉及设备到货，还可能包括机房、电力、网络、驱动兼容、验收和调度配置。逐项向负责团队确认周期；供应紧张、硬件更换或新资源池建设时，周期可能明显不同。预测窗口应覆盖从提出需求到资源可用的全过程。
每月或每季度用实际业务量和单位消耗回算预测，记录误差来自增长偏差、任务结构变化还是效率变化。偏差持续存在时，先修正相应假设，再决定是否扩容。这样算力资源池容量预测与业务增长测算才会成为可复查的计划，而不是一次性的增长外推。
常见问题
预测期该选多长？
至少覆盖扩容全周期；若需求季节性明显，还要纳入一个完整的业务周期。周期越长，不确定性越大，应更多使用情景而非单点数字。
资源利用率越高越好吗？
不一定。高利用率可减少闲置，但在线服务可能更易排队或出现时延波动。应结合服务目标和压测结果设定安全边界。
业务增长预测可靠性不高，怎么做？
先分情景，再设触发条件，例如业务量或排队情况达到预设阈值时启动采购与扩容评估。最终以持续回算的算力资源池容量预测与业务增长测算指导决策，避免单一增长假设带偏扩容。
