云算力专业课 · C2
需求预测
云算力的预测对象不是「这个月卖多少卡时」，而是「未来 2 小时、24 小时、7 天、30 天各时间窗里，什么卡型、多大并发、多长周期的作业会到达」。因为卡时不可储存，且大模型训练往往一次性索要几十上百张同拓扑卡，预测错卡型结构比预测错总量更致命。
核心要点
四条要记住的
- 分层预测，四个时间窗各管一件事。实时（分钟–2 小时）用排队队列与在跑作业外推，服务调度；短期（24–72 小时）驱动分时定价与抢占池上限；中期（7–30 天）驱动容量分区与承诺审批；长期（季度）驱动采购、机房扩容与长租定价。
- 关键驱动变量要固定成清单。大模型训练窗口（预训练 / SFT / 对齐）、推理日活与大促流量、论文与产品发布周期、卡型迁移节奏（H 系到国产卡）、客户预算年末冲量、电价峰谷与机房投产计划、补贴与算力券发放节奏。
- 事件驱动是主要误差源。大模型训练窗口是阶跃式需求（一次吃掉数百卡数周），节假日与电商大促是推理尖峰，开学季与结题季是科研尖峰，必须用事件日历显式建模，而不是靠历史均值外推。
- 用分位数预测，不用单点预测。少备卡的代价是排队与永久流失，多备卡的代价是闲置折旧，两者不对称；应同时输出 P50（基线调度）与 P90（容量预留与应急采购），并给出按卡型成本加权的误差指标。
要点对照
核心指标一览
| 指标 | 定义 / 公式 | 说明 |
|---|---|---|
| 作业到达率 | 单位时间提交的作业数，按卡型 × 卡数分桶统计 | 总量预测没用，训练与推理的卡数分桶完全不同 |
| 卡型需求结构 | 各卡型需求卡时 ÷ 总需求卡时 | 结构错配比总量错配更致命，直接导致排队 |
| 在手承诺消耗 | 已售承诺卡时 ÷ 承诺总卡时（类比 on-book 与 pickup） | 承诺消耗速度是中期容量分区的核心输入 |
| 训练窗口日历 | 客户已申报的大模型训练起止时间与规模 | 阶跃式需求，必须显式建模而非均值外推 |
| 推理流量曲线 | 按小时统计的请求量 / 日活曲线，含节假日系数 | 决定分时定价与抢占池上限 |
| 排队时长 P50 / P95 与放弃率 | 排队时长分位数；放弃率 = 排队超时取消作业数 ÷ 提交作业数 | 预测偏差的最终体感出口，也是校准信号 |
常见错误
这个行业容易踩的坑
- 用月度总卡时做预测——掩盖小时级尖峰，而排队、电力需量与调度冲突全部发生在小时级。
- 只预测卡时总量不预测卡型与拓扑结构——结果是有闲置卡、客户还在排队。
- 把承诺需求重复计入自由需求——同一批卡算了两遍需求，导致过度采购。
- 用历史均值外推——忽略大模型训练窗口这类阶跃变化，一到旺季预测全线失守。
自测
两道题
第 1 题 云算力需求预测中，为什么必须做分位数预测（P50 / P90）而不是单点预测？
解析 · 卡时不可储存，预测偏差的两个方向代价完全不同：低估造成排队、客户流失与口碑损伤，高估造成折旧与电力空耗。因此 P50 用于日常调度与抢占池设置，P90 用于容量预留、应急采购与承诺审批上限，两套数字服务两类决策。GPU 卡时恰恰是典型的不可储存产能，说它可储存是概念错误。
第 2 题 某智算中心预测下月总卡时需求充足，但客户排队 P95 仍在恶化。最可能的原因是？
解析 · 总量对而排队恶化，是典型的结构错配：大模型训练要求同机同域、NVLink/RDMA 拓扑一致、显存规格一致，集群虽然空闲卡很多，却被打散成无法拼装的碎片。正确动作是做拓扑感知装箱、碎片整理与卡型结构预测，而不是继续盲目扩容——扩容只会把碎片变得更大。
关联
对应通用内核：K01 需求预测 · K02 动态定价 · K03 库存控制 · K04 渠道管理 | 行业：云算力详解