本文定位：面向准备建设或扩容大规模 GPU 集群的平台、网络、存储和算法团队，提供规划评审材料、验收证据和失败条件清单，不给未经验证的性能或成本承诺。
万卡集群算力规划进入评审阶段时，问题不再是“要买多少卡”，而是这些卡能否按资源池、网络、存储和调度策略被稳定交付。本文从联审材料出发，帮助团队在扩容前确认哪些证据足以证明规划可实施、可验收、可复盘。
图1：万卡集群算力联审需要把资源池、网络存储和调度证据放在同一
评审材料应先回答五个问题
万卡级规划评审不能只展示硬件清单。结合 NVIDIA 官方文档 对 GPU 软件栈和加速能力的说明，硬件清单只能说明投入规模，不能证明训练任务能稳定运行、故障能被隔离、扩容能被复盘。
评审材料开头建议先回答：
- 业务任务是什么：预训练、微调、评测、推理保障和实验任务各自占比如何。
- 资源池怎么分：不同 GPU 代际、显存规格、网络位置和故障域如何组织。
- 数据路径在哪里：训练样本、Checkpoint、镜像分发和日志指标分别走什么路径。
- 调度如何证明有效：队列、配额、优先级、抢占和失败反馈如何形成闭环。
- 失败如何判定：哪些指标恶化时说明规划不可接受，需要回滚、降级或重新设计。
这些问题能让评审从“规模描述”转向“交付证据”。如果团队还在梳理资源池基本分层，可结合 GPU 资源池规划作为前置材料；本文关注的是更大规模下的联审口径。
资源池拓扑需要用证据证明
资源池拓扑不是一张示意图。评审时应证明每个资源池为什么这样划分、它适合承载哪些任务、它的边界是否能被调度和运维系统识别。
| 评审输入 | 验证方法 | 责任团队 | 失败信号 |
|---|---|---|---|
| GPU 代际、显存和互联拓扑清单 | 抽样核对节点标签、设备发现和拓扑信息 | 平台团队、硬件运维 | 调度标签与真实硬件不一致 |
| 机架、网络域和故障域映射 | 用拓扑图关联交换机、机架和资源池 | 网络团队、平台团队 | 多机训练跨越高风险故障域 |
| 训练、推理、评测资源池边界 | 用典型任务提交验证资源匹配 | 算法团队、平台团队 | 任务频繁进入不匹配资源池 |
| 保底与弹性资源范围 | 对照队列配额和借用记录 | 平台团队、业务负责人 | 弹性借用长期挤占保底资源 |
| 异常节点隔离流程 | 模拟节点异常或健康检查失败 | 运维团队、平台团队 | 故障节点继续进入调度候选 |
拓扑证据要能被调度系统消费
拓扑图如果只存在于评审 PPT 中，对调度没有帮助。节点标签、资源池定义、队列约束、网络域和故障域需要进入调度和观测系统，才能让平台解释“为什么某个训练任务不能跨这些节点运行”。
网络与存储必须和训练任务一起联审
大规模训练的瓶颈经常出现在 GPU 之外。网络通信、样本读取、Checkpoint 写入、镜像分发和日志采集任何一环不稳定，都会让可用算力下降。评审时应让网络、存储和平台团队共同确认任务路径。
联审时建议至少验证：
- 多机多卡训练是否跨越预期网络域，跨域时是否有明确约束。
- 训练样本读取是否能支撑并发任务启动和持续迭代。
- Checkpoint 写入和恢复路径是否与抢占、失败重试策略匹配。
- 镜像、日志、指标和控制面流量是否与训练通信隔离。
- 网络或存储异常时，任务失败原因能否回写到调度和观测系统。
这里的重点不是给出统一性能数字，而是让每个训练阶段都有可验证路径。若任务已经运行在容器平台上，训练任务如何排队、绑定和失败反馈，可参考 AI 训练调度相关实践；本文强调的是万卡级规划联审如何把这些机制纳入验收。
图2：训练任务从队列到资源绑定时需要同时验证网络、存储和失败反
调度和容量要提前定义失败条件
万卡集群算力规划最容易出现的误区，是只定义目标状态，不定义失败条件。没有失败条件，验收就容易变成“集群已经建好、任务也能跑”，但平台仍然解释不了排队、碎片、抢占和故障恢复问题。
建议在评审阶段写明失败条件：
- 排队失败：关键队列等待时间持续恶化，且不是单次业务峰值造成。
- 分配失败：资源空闲但任务因标签、拓扑或碎片长期无法启动。
- 恢复失败：节点异常、抢占或作业失败后，Checkpoint 和重试不能按预期恢复。
- 隔离失败：单个网络域、机架或存储域异常影响超出规划边界。
- 治理失败：借用资源无法归还，人工干预成为主要调度方式。
这些失败条件应进入验收清单，而不是上线后再讨论。与 GPU 利用率、显存、容量风险相关的观测口径，可参考 GPU 集群观测作为复盘指标来源。
扩容决策如何复盘
扩容评审结束并不代表规划结束。万卡集群通常会分阶段建设，第一阶段的运行证据应反馈到下一阶段扩容。否则平台会不断重复同样的网络、存储和调度问题。
扩容复盘建议分四类记录：
- 需求偏差：实际训练、评测、推理和实验任务比例是否符合规划。
- 资源偏差：哪些资源池长期空闲，哪些资源池长期排队。
- 路径偏差：网络、存储、镜像和日志链路是否出现非预期瓶颈。
- 治理偏差：队列、配额、借用、抢占和人工干预是否按预期发生。
复盘结论应直接影响下一批采购、资源池拆分、网络域设计和调度策略。如果复盘只汇总利用率，而不解释失败原因，扩容很可能继续放大旧问题。
图3：万卡集群扩容前后持续复盘容量、网络、调度和失败信号的成熟
谁来参与万卡集群联审
万卡集群不是单一团队项目。平台团队可以设计队列和资源池，但无法独自证明网络路径、存储吞吐、任务画像和业务优先级都合理。
建议明确这些责任边界：
- 算法团队：提供真实任务画像、训练框架、数据读取方式和 Checkpoint 需求。
- 平台团队：负责资源池、队列、配额、任务生命周期和观测反馈。
- 网络团队：确认拓扑、拥塞隔离、故障域和通信路径。
- 存储团队：确认数据集读取、Checkpoint、对象存储和恢复能力。
- 运维团队：负责节点健康、故障隔离、变更窗口和容量报表。
- 业务负责人：确认优先级、交付窗口、预算边界和风险接受条件。
这些角色不只是参会人员，而是验收证据的责任方。评审通过后，每个失败信号都应该能找到对应责任团队。
小结
万卡集群算力规划应以联审证据为核心，而不是只汇报硬件规模。评审材料要回答任务画像、资源池拓扑、网络存储路径、调度失败条件和扩容复盘口径。只有平台、网络、存储、算法和业务团队共同定义验收证据，万卡规模才可能转化为稳定可用的训练能力。
权威参考资料
常见问题
1. 万卡集群算力评审和普通 GPU 集群规划有什么不同？
普通 GPU 集群规划更多关注资源够不够、任务能不能跑；万卡级评审还要证明资源池拓扑、网络域、存储路径、故障隔离和调度治理能协同工作。规模越大，单点假设越容易被放大成系统性问题。
2. 万卡集群算力规划是否一定先采购再做调度治理？
不建议。调度治理应在采购和拓扑设计阶段就参与，因为资源池边界、网络域和故障域会影响后续队列、配额和任务放置。如果等硬件落地后再补策略，可能发现很多约束已经很难调整。
3. 如何证明资源池拓扑设计合理？
需要同时提供硬件清单、节点标签、网络域、故障域、任务画像和调度验证结果。只画拓扑图不够，关键是证明调度系统能识别这些边界，并且典型训练任务会被放到符合预期的资源池中。
4. 万卡集群扩容前最应该看哪些信号？
建议看关键队列等待时间、资源分配失败原因、资源碎片分布、网络或存储瓶颈、Checkpoint 恢复结果、人工干预次数和业务任务画像变化。如果瓶颈不是 GPU 数量，直接扩容可能只是扩大复杂度。
5. 联审没有完整数据时能否先启动建设？
可以分阶段启动，但应明确哪些假设尚未验证，以及对应的灰度范围和回滚条件。例如先建设一个受控资源池，跑真实训练任务，收集网络、存储、调度和失败反馈，再决定下一阶段扩容。
6. 万卡集群是否需要独立于推理资源？
通常建议至少在资源池和调度策略上区分训练、推理和实验任务。是否物理隔离取决于稳定性、延迟、成本和资源利用目标。若推理服务有明确稳定性要求，应避免被大规模训练任务的网络、显存或故障恢复行为影响。
