GPU集群容量规划最容易被一张“当前还有多少张卡”的快照带偏。训练任务可能在某个时间段集中启动，在线推理则需要持续保留可用容量；两者放进同一资源池后，真正的风险不是总量不足，而是关键窗口重叠、任务保护规则不清和容量状态无法解释。平台负责人需要先回答：推理基线是否必须持续保障，训练批次能否等待或暂停，故障时要保留多少恢复空间，哪些资源允许被临时借用。

适用场景：企业计划让训练、推理、评测和实验共用GPU集群，或者已经出现训练排队、推理延迟波动、扩容决策争议和资源长期预留却无法说明用途的情况。

先在时间轴上找出训推真正冲突的窗口

容量规划不能只按月平均用量做。月平均会把一段突发推理峰值和一批集中训练任务抹平，最后得到一个看似充足、实际无法满足关键请求的数字。建议先选取几个有代表性的时间窗口：业务高峰、训练集中提交时段、模型发布或评测窗口、节点维护窗口，以及历史上发生过排队或失败的时段。

时间轴至少要记录五类事件：推理请求量和副本基线、训练任务提交与启动、资源绑定与释放、节点维护或异常、容量借用和归还。事件要关联项目、任务类型、资源规格和保护等级。这样才能区分“没有容量”“有容量但不满足拓扑或规格”“容量被实验占用”和“容量被故障隔离”这几种完全不同的情况。

下图把推理基线、训练批次和两次重叠峰值放在同一张时间轴上。阅读时先找重叠窗口，再讨论资源池应该怎么切分。

推理基线如果没有独立标注，训练团队很容易把全部空闲容量视为可借用；训练批次如果没有预计释放时间，平台也无法判断借用什么时候结束。容量规划的第一项产出不是“还要买多少卡”，而是一张带时间、任务和责任人的容量账本。

容量账本要把“总量”拆成四种状态

同一批GPU在不同时间可能具有不同管理状态。建议把容量拆成保障容量、共享容量、弹性容量和不可用容量，而不是只保留总量与已用量两个字段。

• 保障容量：为在线推理、关键服务或不可中断任务保留的资源，除非触发明确的故障策略，否则不进入普通训练队列。
• 共享容量：可以在任务规则允许时被训练、评测或实验借用，但必须有项目、期限、归还条件和抢占边界。
• 弹性容量：需要顺利获得预热、临时资源或其他方式取得，是否可用取决于供应、启动时间、镜像与模型加载，不应在账面上当作即时可用。
• 不可用容量：维护、异常、隔离、拓扑不满足或正在恢复的资源，不能因为设备仍在线就计入可分配容量。

容量账本还要保留申请与实际消耗的差异。一个训练任务申请多卡但长期等待数据，可能占用保障或共享容量却没有有效进展；一个推理服务保留副本但请求低谷，可能是合理的业务保护，也可能是缺少缩容规则。判断不能脱离任务类型、延迟目标、恢复方式和观察窗口。

表格中的“状态”不是永久分类。一个共享资源可能在在线服务发布前转为保障容量，一个故障节点也可能经过验证后重新进入共享池。状态变化必须有事件和责任人，否则容量曲线会在复盘时失去解释力。

训推共池的关键不是平均公平，而是保护规则可执行

训练和推理对资源的容忍度不同。在线推理通常需要关注请求等待、并发、实例就绪和故障切换；长时间训练可能更关心检查点、重试和批任务完成；评测与实验可以等待，但要有期限和回收条件。把它们都放进同一个队列，再用一个优先级字段解决，通常会让规则过于粗糙。

可以先为每类任务写出三条边界：最低保障是什么，允许借用什么，冲突时可以牺牲什么。推理服务的最低保障可能是保持现有实例和恢复空间，训练任务的边界可能是只在检查点完成后暂停，实验任务则可以接受到期回收。这里不需要先确定统一数值，但需要明确规则如何映射到任务状态和调度事件。

冲突发生时，平台应按顺序执行而不是临时协调：先保护已承诺的服务基线，再判断训练任务是否可以排队、暂停或迁移，随后检查共享资源是否到期，最后才考虑临时扩容。每一步都要记录触发原因、受影响任务、责任人和恢复条件。扩容不是冲突处理的唯一动作，扩容迟到时更要先保护业务和解释队列。

用四种演练验证容量规划是否可信

容量规划必须在事件中验证。只看静态容量和正常任务成功，无法证明资源池在共同峰值时仍可控。建议用脱敏或可控工作负载做四类演练。

演练一：训练批次与推理峰值同时到达

固定推理基线，逐步提交训练批次，观察训练进入队列的原因、推理请求的等待和服务保护是否生效。重点不是追求所有任务都成功，而是确认关键任务不被无规则挤压，普通任务能看到可解释的等待原因。

演练二：共享容量借用到期

让实验或评测任务借用一段共享容量，设置期限、提醒和延长审批。演练到期时责任人不响应、任务正在写产物和关键服务突然进入三种情况，观察系统是通知、暂停、释放还是升级人工处理。

演练三：推理节点异常与训练恢复

在不影响正式业务的环境中隔离一部分节点，确认推理服务的保护容量、训练任务的检查点和重新排队是否能被分别观测。若恢复依赖人工，应把人工动作和判断依据写入验收记录，不能只写“已恢复”。

演练四：容量账本与实际状态对账

选定一个观察窗口，把资源分配、任务状态、队列事件和服务指标进行对账。重点寻找已完成未释放、故障仍计入可用、借用已到期但仍占用、服务已缩容但容量未更新等差异。

每场演练都应留下输入条件、时间线、任务清单、容量状态、告警、处置动作和回退结果。若演练过程中发现容量数据与任务状态不一致，应先修复观测和责任链，再讨论增加硬件。

什么时候应该扩容，什么时候先改规则

扩容适合解决经过验证的结构性缺口，例如推理基线与训练最低保障在多个业务窗口持续重叠，且任务规格、回收和共享规则已经稳定；如果排队主要由遗留任务、申请过大、拓扑碎片、模型加载迟到或节点维护造成，直接增加GPU未必能解决问题。

可以用以下问题形成扩容触发记录：

• 关键服务在多个观察窗口都触及保护边界，且原因不是异常占用；
• 训练任务的等待来自真实容量不足，而不是申请规格和资源池不匹配；
• 共享池已经有清晰借用与回收记录，仍然无法覆盖确定的业务窗口；
• 故障演练所需恢复容量长期缺口明确，且业务责任人确认保护目标；
• 扩容后的资源有明确项目、任务类型、维护和运营责任。

相反，若容量账本中有大量不可归属资源、任务完成后未释放、借用无期限或服务基线没有定义，优先做规则治理。在无法解释资源去向时扩容，只会把不可解释的占用扩大。扩容决策还应记录观察窗口、替代方案、影响面和回退条件，避免把一次异常峰值变成永久采购口径。

下一步先做一次峰值回放

建议选择一段真实但可控的时间线，标出推理基线、训练批次、共享借用、节点状态和资源释放。然后回放一次共同峰值，验证保障、共享、弹性和不可用四类容量是否能被区分，冲突时的队列、降级、暂停和回收是否有证据。完成初步盘点后，可以继续查看 AI基础设施分类；若需要进一步评估企业AI算力建设路径，再查看 AI解决方案，发布前应核验页面状态。

GPU集群容量规划最终要回答的是“在什么窗口、为哪类任务、以什么保护级别保留多少可解释容量”，而不是给出一个脱离工作负载的卡数比例。建议先完成一次训推共池冲突演练，再根据证据决定调整队列、拆分资源池、补充弹性还是扩容。所有固定比例、阈值和周期都应回到真实任务与组织责任中验证。

常见问题

训推共池必须预留多少GPU才安全？

没有一个可以跨企业直接套用的安全预留比例。预留容量取决于在线推理的最低服务基线、训练任务是否可暂停、模型加载时间、故障恢复目标、节点拓扑、维护窗口和业务允许的排队时间。相同的GPU总量，在一种环境中可能足够，在另一种环境中却因规格不匹配或恢复空间不足而持续冲突。

更稳妥的做法是先按时间窗口建立容量账本，分别记录保障、共享、弹性和不可用容量，再用推理峰值、训练提交和节点异常做回放。预留结论应写明观察窗口、任务类型、保护对象、允许的降级方式和失败后的回退动作。如果只知道总卡数，不知道哪些任务能够等待、哪些资源可借用，就不应把一个比例写成安全承诺。

容量不足时应该扩容还是调整排队规则？

先区分结构性容量缺口和治理性占用问题。若关键推理在多个独立窗口都触及最低保障，训练等待原因也确实是可用容量不足，而且任务申请、回收、共享和故障状态都能解释，扩容才有较清晰的依据。若排队来自已完成任务未释放、申请规格过大、拓扑碎片、借用逾期或容量账本失真，先改规则更有可能解决问题。

可以把一次扩容决策拆成“证据、替代、影响、回退”四栏：证据说明缺口持续多久、影响哪些任务；替代方案说明是否能顺利获得分池、排队、暂停或弹性处理；影响说明成本、维护和团队责任；回退说明扩容未解决问题时如何停止继续投入。这样不会因为一次峰值就永久改变容量，也不会用调度规则掩盖真实的业务保障不足。

GPU集群容量规划多久复盘一次？

复盘频率不应只按日历固定，而应与负载变化和重大事件结合。稳定期可以按约定周期查看基线、峰值、借用、释放和故障恢复；模型发布、业务活动、训练批次变化、资源池调整、网络或存储变更后，应立即增加一次专项复盘。复盘的重点不是追求某个利用率数字，而是确认容量状态、任务状态和业务保护是否仍然一致。

每次复盘至少保留一段可对账的时间线：资源何时分配和释放、任务为何排队或失败、推理是否触及保护边界、共享容量是否按期归还、不可用资源何时恢复。若发现状态字段长期缺失、责任人无法确认或规则变更没有版本，应把它列为容量治理问题。复盘结果可以是维持、调整规则、补观测、拆分资源池或启动POC，而不是默认导向扩容。