3. 容量规划与需求预测

GPU 集群的容量规划不是“买卡”这么简单，它要回答三个问题：未来一段时间需要多少张什么型号的 GPU、这些 GPU 应该以什么方式获得（自建、预留、按需）、以及当需求回落时如何安全地把资源还回去。需求预测是这一切的起点，而预测的输入主要来自三类信号：历史负载、业务增长、模型训练/推理趋势。

一、三类预测信号与它们的粒度

历史负载是最可靠的基线。它通常来自调度器与监控系统，例如每张卡的 GPU 利用率（SM 占用率）、显存占用、任务排队时长、作业提交量。做预测时不要只看平均值，要按队列、按团队、按 GPU 型号分别统计，因为 A100 的排队和 T4 的排队是两回事。一个实用的做法是取过去 8～12 周的按小时利用率序列，先做工作日/周末、白天/夜间的分层，再叠加趋势项。

业务增长信号来自业务侧：新上线的推理服务、DAU 增长目标、新模型版本的上线计划。它决定了“基线之上还要加多少”。模型训练/推理趋势则来自算法侧：训练任务从 7B 走向 70B、上下文长度从 4K 走向 128K、推理从单卡走向多卡张量并行，都会显著改变单任务占用的卡数和时长。这三类信号必须放在同一张时间轴上对齐，否则预测会失真。

二、一个可落地的预测方法：基线 + 增量 + 缓冲

推荐用“基线 + 增量 + 缓冲”的结构做需求预测，公式可以写成：

预测需求(卡) = 基线负载(卡) × (1 + 业务增长率) + 新模型增量(卡) + 安全缓冲(卡)

其中：
  基线负载 = 过去8周 P95 同时占用卡数（按型号分别统计）
  业务增长率 = 未来季度业务量增幅，例如 20%
  新模型增量 = Σ(新任务数 × 单任务卡数 × 并发系数)
  安全缓冲 = 基线 × 缓冲比例（训练队列建议 15%~25%，推理建议 10%~15%）

举例说明（以下为教学示例，非实测数据）：某集群 A100 队列过去 8 周 P95 同时占用为 320 卡，下季度业务预计增长 20%，将上线 2 个 70B 训练任务，每个任务 32 卡、并发系数 1.5，训练缓冲取 20%。则：

基线 = 320 卡
业务增量 = 320 × 20% = 64 卡
新模型增量 = 2 × 32 × 1.5 = 96 卡
缓冲 = (320 + 64 + 96) × 20% ≈ 96 卡
预测需求 ≈ 320 + 64 + 96 + 96 = 576 卡

这个结果不是让你直接买 576 卡，而是告诉你“缺口约 256 卡”。接下来才是策略选择。

三、扩容、缩容与预留的组合策略

扩容不是只有“买”一种。按响应速度和成本，可以把供给分成三层：预留实例（长期、便宜、但不够灵活）、按需实例（灵活、贵）、竞价/抢占实例（最便宜、可被回收，适合容错训练）。合理的组合是：用预留覆盖基线负载的 70%～80%，用按需覆盖业务增量与短期峰值，用抢占实例承接可中断的训练任务和离线批处理。

缩容同样需要策略。当利用率连续多周低于阈值时，优先缩容的对象应该是：可被抢占的临时容量、空闲的按需实例、最后才是预留。缩容前要确认没有长周期训练任务正在使用这些卡，并设置“冷却期”，例如连续 7 天 P95 利用率低于 40% 才触发缩容，避免把短期波动误判为长期回落。

四、把预测变成可执行的容量计划

预测结果要落到一张容量计划表上，至少包含：时间窗口、GPU 型号、预测需求、现有容量、缺口、建议动作（扩容/缩容/预留）、负责人、触发条件。下面是一个可直接参考的示例结构：

这张表的关键在于“触发条件”一列：它把静态预测变成了动态决策规则。当监控指标越过阈值时，容量动作自动进入评审流程，而不是等到业务方投诉才临时扩容。

五、预测的校准与复盘

预测不可能一次做准，必须建立校准机制。建议每月做一次“预测 vs 实际”的偏差分析，记录预测值、实际峰值、偏差率、偏差原因（业务增长超预期、模型规模变化、任务调度效率变化等）。如果连续两个月偏差超过 20%，就要调整基线窗口或缓冲比例。校准的目标不是让预测完美，而是让偏差可解释、可收敛。

把这张图当作日常容量评审的检查清单：左侧三类信号是否都更新了、中间四项计算是否都有数据支撑、右侧策略是否与业务优先级匹配、底部校准回路是否在运转。只要这四步持续执行，GPU 容量就能从“拍脑袋”变成“可解释、可调整、可复盘”的工程决策。