超大规模智算中心GPU集群建设运维教程

一、教程目标

某超大型智算中心一期在 2024 年投产，规模约为 23 万枚图形处理器，与规划中的二期共用同一站址，并通过向外部企业客户出租算力来摊销巨额投入。本教程把这类项目的工程实践抽象成一条可复用的实施路径，最终交付目标是：

1. 建成一个可在万卡级到十万卡级规模上稳定运行训练的 GPU 集群，并支持在线扩容；
2. 具备多租户隔离、配额管理、用量计量与计费能力，使集群可以以算力服务的形式对外提供；
3. 建立可量化的验收基线（通信带宽、存储吞吐、扩展效率、能效比），使”是否建成”成为可测量的结论而非主观判断；
4. 形成一套面向大规模失效环境的运维与排障流程，以及供电与降噪等合规治理动作。

二、适用场景与读者对象

• 自建智算中心/数据中心：需要完成从选址到投产全流程规划的技术负责人与项目经理；
• GPU 集群运维与平台工程师：负责调度、网络、存储、监控与故障处置的一线人员；
• 算法平台/训练平台开发者：需要在既有集群上稳定跑起大模型训练任务的工程团队；
• 算力运营方：需要把训练集群包装成可计量、可结算、可承诺 SLA 的对外服务。

如果你的目标只是在公有云上申请几台带加速卡的实例跑通一个脚本，本教程的复杂度远超需求；若你使用的是托管型容器平台或托管训练服务，可将本文中的组网、存储、调度章节视为原理与验收参考，具体的开通与配额操作以对应平台的通用功能页面说明为准。

三、前置准备

3.1 场地与基础设施条件

万卡级集群的本质是一个高功率密度、高网络复杂度、高故障率的联合系统。开工前必须确认：

• 电力接入容量：单台配备 8 枚加速卡的服务器功耗通常在数千瓦量级，加上网络设备与制冷，单个机柜的功率密度可达数十千瓦。因此必须提前锁定变电站容量、双路市电与并网进度，并明确”电力分期到位节奏”——集群建设节奏应当由供电与制冷的分期能力反向决定，而不是相反。
• 制冷方案选型：功率密度决定散热形态。风冷更适合中低密机柜，高密机柜则需要冷板式或浸没式液冷，同时要考虑冷却水/冷却液的接口预埋、二次侧管网与漏液检测。
• 网络与承重：需要预置高速网络布线通道、机柜承重与地板/抗震设计，后期改造代价极高。
• 临时供电的合规治理：建设期市电未完全到位时，业界常见做法是部署移动式发电设备过渡。这会带来噪声、排放与社区投诉风险（某超大型智算中心一期投用初期即因现场临时发电设备引发大量周边居民投诉，并在次年年初拆除部分设备）。因此务必在部署前完成：噪声与排放的环保审批、设备加装消声/隔声与尾气处理、机组远离居民区侧布置、限定夜间运行与运行时段、建立投诉响应与监测公示机制。这一项不是”公关问题”，而是决定项目能否按期投产的合规前置条件。

3.2 软硬件与权限准备

• 加速卡与服务器：明确型号代际、显存容量、单机卡数与卡间互联带宽，形成统一机型的”标准节点池”，避免混型导致调度与性能抖动。
• 基础软件栈：主流深度学习框架、集合通信库、驱动与固件基线、镜像仓库、配置管理工具。所有版本必须固化为基线清单，禁止节点间漂移。
• 平台能力清单（使用通用能力类目规划即可）：容器编排平台、任务调度器、分布式存储与并行文件系统、对象存储、镜像仓库、日志服务、监控告警、指标与链路追踪、身份认证与权限系统、密钥管理、配额与计量服务。
• 权限与账号体系：按”平台管理员 / 网络管理员 / 存储管理员 / 租户管理员 / 普通用户”分离角色，租户之间默认互不可见。

四、实施步骤

步骤一：容量规划与分期设计

做什么：以目标模型规模和训练时长反推所需的加速卡总量、聚合算力、聚合通信带宽、检查点存储容量与写入带宽，再折算成机柜数、网络层数、电力与制冷需求。

为什么：分期建设是控制风险的核心手段。一次性建设十万卡会造成供电、网络、运维能力的三重瓶颈叠加；正确做法是按”最小可交付训练单元”切分。

注意：预留 15%~25% 的容量余量用于故障替换与灰度升级，不要用满所有机柜位。

步骤二：网络组网设计（决定集群上限）

做什么：设计面向集合通信的低时延、无损网络。常见做法是采用多级无阻塞胖树/折叠式拓扑 + 轨道优化（多轨）组网：每台服务器上的第 N 号加速卡统一接入第 N 个网络平面，使同轨通信路径最短。

为什么：大模型训练的主要开销来自集合通信（All-Reduce、All-Gather、Reduce-Scatter）。若随机接线，通信流量会跨多层级转发，带宽利用率与尾延迟都会显著恶化，直接表现为训练吞吐下降。

注意：

• 必须在交换机与网卡上启用优先级流控/拥塞控制等无损配置，否则大规模同步通信会因丢包触发重传，出现”吞吐剧烈抖动”；
• 严格控制故障域：单个 ToR/Leaf 交换机故障只应影响一个机柜或一个 Pod，不能导致全局任务中断；
• 为控制面、存储面、参数面划分独立网络或独立 VLAN/平面，避免存储流量挤占训练通信带宽。

步骤三：存储分层建设

做什么：建立”三层存储”——高速并行文件系统（读写训练数据与检查点）、大容量对象存储（数据集归档、模型产物、日志）、本地 NVMe 缓存（数据预取与暂存）。

为什么：训练任务的等待时间往往不花在计算上，而花在数据读取和检查点写入上。检查点是大流量、周期性、并发写，若写入带宽不足，会导致长时间”空转等待”。

注意：按”聚合写入带宽 ≥ 目标检查点体积 / 可接受停顿时间”来反推存储规格；开启检查点分片与异步落盘，把写盘时间从关键路径上摘除。

步骤四：调度与多租户平台搭建

做什么：部署容器编排与批调度能力，配置队列、配额、优先级、抢占与拓扑感知调度。

关键配置项语义（业界通用，非特定产品专有参数）：

• 成组调度（gang scheduling）：训练作业需一次性拿到全部卡才能启动，避免”部分资源被占、任务无法推进”的死锁式资源浪费；
• 拓扑感知：优先在同一 Pod/同一网络平面/同一轨道内分配资源，减少跨层通信；
• 配额与抢占：按租户分配保障配额与弹性上限，低优先级任务可被高优先级任务抢占，但需配合检查点以控制损失；
• 弹性与容错：设置最大重试次数、节点健康检查与自动隔离，故障节点先摘除再维修。

示意性作业描述（字段为通用语义，非任何产品专有格式）：

job:
  name: pretrain-demo
  queue: tenant-a-high
  priority: high
  resources:
    accelerators: 512          # 所需加速卡总数
    cpus: 2048
    memory_gb: 4096
  schedule:
    gang: true                 # 成组调度，避免资源部分占用
    min_members: 512
    topology_aware: true       # 优先同网络平面/同机柜分配
    max_restarts: 3
  network:
    fabric: rdma
    rail_aligned: true
  storage:
    - mount: /ckpt
      class: parallel-fs       # 高吞吐并行文件系统
      quota_tb: 100
    - mount: /data
      class: object-cache
  runtime:
    backend: container
    image: registry.internal/training-runtime:<pinned-tag>
  tenancy:
    namespace: tenant-a
    gpu_quota: 1024
  observability:
    metrics: scrape
    logs: centralized
    alert_on: [xpu_temp, ecc_error, fabric_crc, step_time_p99]

步骤五：多租户隔离与安全基线

做什么：为对外算力服务建立网络隔离（独立 VPC/子网 + 安全组）、身份认证与最小权限授权、镜像来源可信与签名校验、密钥与凭据集中托管、租户级资源配额与用量计量。

为什么：一旦集群对外开放，安全边界就从”内部网络”变为”多租户边界”。训练框架常以高权限方式访问设备与本地文件系统，隔离不足会导致跨租户数据泄露或资源挤占。

注意：默认拒绝跨租户通信；对镜像仓库、模型仓库等制品源做准入控制；审计日志留存周期与合规要求对齐。

步骤六：计量、计费与服务化交付

做什么：定义计量口径（加速卡·小时、显存·小时、存储 GB·月、网络流量）、采集间隔、结算粒度；定义服务等级（可用性、故障响应、赔偿）；提供配额自助申请与用量报表。

为什么：以出租算力摊销投入是这类超大规模中心的主要回收方式，计量不准确的代价是直接的收入损失与商务纠纷。

注意：计量数据要与调度器的资源占用记录、监控指标三方对齐并定期对账；计费规则变更需保留历史版本可追溯。

五、结果验证：如何判断”建成且可用”

不要以”任务能提交”作为验收标准。建议执行以下基线测试并留存报告：

1. 单卡与单机基准：显存带宽、卡间互联带宽（同机 P2P 读写）、单机到网络的有效带宽；
2. 网络基线：跨机柜、跨层级的小消息时延与大消息有效吞吐，检查无损配置是否生效（是否出现暂停帧、重传计数增长）；
3. 集合通信基线：全集群规模下的 All-Reduce 有效带宽与随规模变化的效率曲线；
4. 存储基线：顺序读/写聚合带宽、随机 IOPS、小文件元数据操作吞吐、检查点端到端耗时；
5. 扩展效率验证：用固定全局批量、逐步增加卡数的方式跑同一模型若干步，观察单卡吞吐与扩展效率是否接近线性；若扩展效率明显下滑，问题通常在网络拓扑或并行策略，而非算力不足；
6. 故障注入演练：随机断电/摘除若干节点、断开单条链路、杀掉部分进程，验证任务能否自动重调度并从检查点恢复，记录恢复耗时（MTTR）；
7. 能效与热测试：满载下的实测 PUE、进风温度分布、热点告警是否触发；
8. 多租户验证：以两个测试租户并发提交，验证配额生效、隔离有效、计量数据准确。

任一项不达标都不应放行至生产租户。

六、常见问题与排查

现象	常见原因	排查思路
整体训练吞吐低于预期，且波动大	无损网络未生效导致丢包重传；存在慢节点	先比对通信基准与基线报告；用性能指标定位单卡/单机离群点，隔离后复测
扩展效率随卡数上升快速下降	跨层级通信占比过高；轨道未对齐；并行策略不匹配	检查资源分配的拓扑分布；调整张量并行/流水并行/数据并行的切分比例
任务长时间处于”资源不足”等待	未启用成组调度；配额被零散占用	检查碎片化程度，启用成组调度与队列优先级，必要时回收闲置配额
检查点阶段长时间停顿	存储写带宽不足；未做异步落盘	测量聚合写带宽，启用分片写入与异步/分级落盘
周期性 GPU 温度或频率异常	进风温度过高、局部热点、风道堵塞	结合机房热分布调整送风与机柜布局，检查液冷流量与滤网
训练脚本单机能跑、多机失败	环境变量、网络平面、镜像版本不一致	用统一基线镜像与配置管理消除节点漂移，先跑小规模通信自检
租户间相互干扰或越权访问	隔离边界缺失、权限过宽	复核网络隔离策略与最小权限授权，补齐镜像准入与密钥托管
临时发电设备引发投诉或被要求整改	噪声/排放未达许可要求	加装消声隔声与尾气处理、调整布置与运行时段、建立噪声监测与公示、尽快推进市电并网以减少临时发电依赖

排障通用原则：先分层定位（应用→调度→存储→网络→硬件→机房环境），再用基线对比确认异常点，最后单点隔离复测。永远不要在没有基线的集群上”凭感觉调参”。

七、优化建议

• 性能：拓扑感知调度 + 通信与计算重叠 + 并行策略与网络层级匹配；对算子与框架版本做定期回归测试，避免升级导致吞吐回退。
• 稳定性：建立节点健康检查与自动隔离机制，把”发现坏卡”的时延压到分钟级；提高检查点频率以缩短故障损失，但通过异步落盘避免拖慢主训练。
• 能耗与成本：提升上架率与装箱率、优先使用液冷与高环境温度运行策略、复用余热、按闲时/低优先级队列提供折扣资源以提升整体利用率；建立单位算力成本（每卡·小时成本）看板，把成本优化落到具体机柜与网络层。
• 可维护性：全量基础设施即代码化，节点出厂即带统一基线镜像；变更走灰度（先 1 个机柜 → 1 个 Pod → 全集群）。
• 服务化：把监控与计量数据打通，形成对外可展示的可用性与性能报表，这是算力出租业务能持续议价的基础。
• 合规：新增临时供电或增容改造前，先完成环保、消防与并网审批，把社区沟通前置到施工之前。

八、总结

超大规模 GPU 集群的难点不在于堆卡，而在于供电与制冷的分期节奏、网络拓扑的确定性、存储带宽与检查点路径、调度的成组与拓扑感知、多租户的隔离与计量这五件事能否同时成立。本文给出的路径是：容量规划 → 网络组网 → 存储分层 → 调度与多租户 → 安全基线 → 计量服务化 → 基线验收 → 运维排障与优化。后续可继续深入的方向包括：面向超长上下文的并行策略优化、检查点与恢复的进一步加速、故障预测与自动化运维、液冷能效调优，以及算力资源的跨中心调度与统一编排。