百万卡AI超级单体：从千卡集群到大模型训练基础设施跃迁

各位读者朋友，大家好。

当大家还在讨论千卡集群怎么调参、万卡集群怎么组网的时候，一个更震撼的变量已经出现了——百万卡级别的 AI“超级单体”集群开始落地。这不是简单地把 GPU 数量堆到一百万张，而是把计算、网络、存储、调度、功耗和稳定性全部揉进一个“单体系统”里，以接近超算工程的方式重新组织 AI 基础设施。

本文不讨论舆情，也不做地域性评论，而是纯粹从技术工程视角，拆解“百万卡时代”背后的核心概念、系统架构、关键挑战和落地思路。无论你是做大模型训练、AI Infra、分布式系统，还是做算力规划，这篇文章都能帮你建立一套完整的认知框架。

1. 什么是“百万卡”和 AI“超级单体”

1.1 从千卡、万卡到百万卡

在 AI 大模型发展初期，一张 A100 显卡的训练算力已经非常可观。到了 GPT-3 时代，训练一次需要上千张显卡连续运行数周；进入 GPT-4、Llama-3 这类超大模型阶段后，万卡集群成为标配。现在，头部智算中心开始规划十万卡甚至百万卡级别的集群。

这里所说的“卡”，通常指 GPU 加速卡，比如 NVIDIA H100、H200、A100，以及国产加速卡。百万卡集群意味着十万亿亿次甚至更高量级的算力集中在一个物理园区内，通过高速网络互联。

1.2 什么是“超级单体”

“超级单体”这个概念来自气象学中的“超级单体风暴”，指的是一种结构完整、持续很长时间、能量巨大的雷暴系统。

在 AI 基础设施里，超级单体被借用来描述一种高度集中、一体化设计的超大规模 AI 计算集群。它不像传统数据中心那样由多个独立集群拼凑，而是从建设之初就按单一系统来设计：

• 统一的算力池；
• 统一的存储空间；
• 统一的调度平台；
• 统一的网络拓扑；
• 统一的运维体系。

也就是说，百万张卡不是一个松散的“卡仓库”，而是一个可以灵活切分、动态调度、全局协同的“一台超级计算机”。

1.3 为什么要做成“单体”而不是“多集群”

有人会问：把 10 个 10 万卡集群放在不同地方，然后通过网络连起来，不也一样吗？

从应用角度看，差别非常大。大模型训练有一个关键特性——同步并行。在数据并行、张量并行、流水线并行等模式下，GPU 之间每一轮迭代都要做梯度同步或张量通信。跨地域的网络延迟通常在几十毫秒以上，而单个数据中心内部的光通信延迟可以控制在微秒级别。如果训练流量跨地域传输，训练效率会急剧下降，甚至无法收敛。

所以，为了追求极致的训练性能，就必须把大规模算力集中在同一个物理域内，用超低延迟、超高带宽的网络把它们连成整体。这就是“超级单体”存在的核心原因。

2. 百万卡集群到底解决什么问题

2.1 大模型参数量持续膨胀

从 GPT-3 的 1750 亿参数，到业界探索的万亿甚至十万亿参数模型，模型规模增长的速度远超单卡显存和单机算力的提升速度。以当前主流 GPU 为例，单卡显存通常在 80GB 到 192GB 之间，一个万亿参数模型仅参数就需要数十 TB 显存。这意味着必须有大量 GPU 协同工作，才能把模型装下。

2.2 训练效率的平方级收益

大模型训练有一个“规模效应”：集群规模越大，每张卡发挥的效率越高，单位算力成本越低。原因是模型规模变大后，计算密度增加，通信占比相对下降，张量并行等策略可以更充分地利用卡间带宽。同时，更大的集群允许研究者使用更大的 batch size，从而减少迭代次数。

2.3 支撑多模态和长序列任务

除了纯文本大模型，多模态模型（图像、视频、音频）、长上下文模型、多智能体系统都需要极大的算力。百万卡集群提供的不只是“能做”，更是“快速迭代试错”的能力。研究者可以在几小时内完成原本需要数周的实验，大大加快模型迭代速度。

3. 百万卡“超级单体”的核心技术拆解

一个百万卡集群并不是简单地把设备堆在一起，它的技术复杂度远超传统数据中心。下面从计算、网络、存储、调度、供电散热五个维度展开拆解。

3.1 计算层：异构并行与大规模并行策略

百万卡集群的核心是 GPU 加速卡。为了让这些卡协同训练一个大模型，必须采用多种并行策略的组合：

在实际训练中，通常不是单一策略，而是多种策略组合。例如“DP + TP + PP + EP”的 4D 并行。调度器必须根据模型结构和卡间拓扑，自动决定每一层使用哪种并行策略，这是百万卡集群软件栈的核心能力之一。

3.2 网络层：无阻塞低延迟互联

网络是百万卡集群最关键的“血管”。

当前主流方案是InfiniBand（IB）或RoCE（RDMA over Converged Ethernet）。IB 网络在 AI 集群中的优势是低延迟、高带宽、无损传输。一个典型的万卡集群已经需要采用胖树或多级 Clos 网络拓扑。当规模达到百万卡时，纯胖树拓扑所需的交换机和光模块数量会爆炸式增长。

因此，业界开始探索更高效的拓扑，例如：

• 轨道优化（Rail-Optimized）拓扑：把 GPU 的网卡按照特定“轨道”连接到不同交换机层，减少跨交换机跳数；
• 分层 Clos 拓扑：将集群划分为多个 Pod（例如 64 卡或 128 卡一个 Pod），Pod 内高速互联，Pod 间通过核心交换机连接；
• 光交换技术：通过光电路交换机（OCS）动态调整连接路径，减少多跳转发。

对一个百万卡集群来说，网络设计要求是端到端无阻塞带宽。通俗地讲，就是任何两张卡之间的通信带宽，不能因为网络争抢而明显下降。这在规模变大后变得极其困难。

3.3 存储层：高性能并行文件系统

大模型训练的数据读取、检查点保存、日志写入都需要高吞吐存储系统。传统的数据中心 NAS 架构无法满足百万卡集群的并发读写需求。

百万卡集群存储层一般分为多级：

关键指标是聚合带宽。百万卡集群训练时，检查点文件可能达到 TB 甚至 PB 级。如果保存一次检查点需要几十分钟，训练效率会受到严重影响。因此，存储系统必须设计成支持瞬时高带宽写入，通常采用分布式数据布局和异步检查点机制。

3.4 调度层：从排队到秒级弹性

百万张卡如何分配给不同团队、不同任务？这里需要强大的算力调度系统。

传统任务调度器（如 Slurm）可以管理数万卡集群，但百万卡集群对调度器的要求更高：

• 毫秒级资源感知：实时知道每张卡的利用率、温度、故障状态；
• 拓扑感知调度：一个训练任务尽量分配在同一网络域内，避免跨区域通信；
• 弹性伸缩：任务可以动态增减卡数，而不需要重启训练任务；
• 故障自动迁移：单卡故障时，自动把任务迁移到健康卡上，而不是整个任务失败。

调度系统的设计可以类比“操作系统”，只不过它管理的资源不是 CPU 时间片，而是整个集群的 GPU、内存、网络带宽和存储带宽。

3.5 供电与散热：超级单体的物理底座

百万卡集群的功耗是极其惊人的。单张 H100 GPU 的功耗约 700W，加上服务器其他部件，单台 8 卡服务器的功耗可能达到 10kW 以上。百万卡集群的总功耗将达到数百兆瓦甚至吉瓦级别，相当于一座中型城市的用电规模。

供电方面需要：

• 高电压等级变电站；
• 高压直流（HVDC）供电架构，减少转换损耗；
• 锂电池储能和 UPS 系统，保证电网波动时训练不中断；
• 可再生能源配套，降低碳排放压力。

散热方面，传统的风冷已经无法支撑高密度 GPU 机柜。液冷技术成为百万卡集群的标配。冷板式液冷、浸没式液冷可以大幅提高散热效率，降低 PUE（电能利用效率）。百万卡集群的数据中心 PUE 通常要求低于 1.2。

4. 从工程角度看百万卡集群的构建

前面讲的是概念和架构，现在来看看如果要构建一个百万卡级别的 AI 超级单体，工程上要如何推进。这不仅仅是“买卡、插电、组网”这么简单。

4.1 第一步：算力规模与目标模型匹配

先明确目标：这个集群主要用来训练多大的模型？需要支撑多大的并发训练任务？

假设我们要训练一个 10 万亿参数的 MoE 模型，序列长度为 128K，那么对显存总量、内存带宽、网络带宽的要求是巨大的。工程团队需要根据模型结构、并行策略、目标吞吐量，反推所需的卡数、内存容量和网络规格。

这一步通常需要用到预估公式。例如，训练一个大模型所需的总显存约等于：

模型参数 × 参数字节数 × 优化器状态倍数 + 梯度 + 激活值

在混合精度训练（FP16/BF16）下，一个 10 万亿参数的模型，仅参数和优化器状态就可能需要数百 TB 显存。如果单卡 192GB，则至少需要数千张卡才能把模型装载，再加上数据并行维度，实际需求轻松超过十万卡。

4.2 第二步：集群网络设计

网络设计是百万卡集群最核心的工程之一。以下是一个简化的网络规划思路：

每个计算 Pod：128 张 GPU 每个 Pod 内：GPU 通过 NVLink 全互联 Pod 内网卡通过 Leaf 交换机互联 Leaf 交换机上行连接到 Spine 交换机 Spine 交换机再连接到核心交换机

对于百万卡规模，需要将集群划分为若干个大区，大区之间通过超高速骨干网连接，每个大区内保持高带宽低延迟。在设计时，要重点考虑以下问题：

• 单台服务器的 GPU 数量和网卡数量；
• 每张 GPU 对应的网卡带宽（例如 400Gbps 或 800Gbps）；
• 交换机端口密度和线速转发能力；
• 端到端拥塞控制策略；
• 故障域隔离和冗余路径。

4.3 第三步：软件开发栈选型

百万卡集群的软件栈必须做到“全栈优化”。常见的软件栈包括：

在百万卡规模下，PyTorch 默认的分布式训练配置并不能直接拿来用。需要深度定制 NCCL 通信算法、调整超时时间、优化集合通信图执行顺序。

4.4 第四步：仿真验证与调优

在真实集群建成之前，必须先进行大规模仿真验证。业界普遍使用两类工具：

• 网络仿真：模拟不同拓扑下的通信时延和带宽，找出瓶颈；
• 训练模拟：用真实模型的简化版本在较小规模上验证并行策略，再外推到大集群。

一个常见的做法是先在 64 卡环境中验证算法，再扩展到 1024 卡验证并行策略，逐步放大。直接上百万卡做全量调试，风险极高。

5. 百万卡训练常见问题与排查思路

超大规模训练的过程不会一帆风顺，以下是一些常见问题和排查思路。

5.1 NCCL 通信超时

5.2 训练中断与恢复

百万卡集群中，MTBF（平均无故障时间）比单机短很多。一张卡故障可能导致整个训练作业中断。解决方案是采用异步检查点 + 自动重启机制。

推荐在训练脚本中结合 PyTorch 的torch.distributed.checkpoint和torch.distributed.elastic来简化恢复流程。核心思路是周期性保存模型状态，节点故障后，调度系统重新分配资源，从最近检查点继续训练。

下面是一个简化的检查点保存伪代码：

# 文件路径：checkpoint_example.py import torch import torch.distributed as dist import torch.distributed.checkpoint as dcp # 初始化进程组 dist.init_process_group(backend="nccl") # 构建模型 model = torch.nn.Transformer( d_model=4096, nhead=32, num_encoder_layers=24, num_decoder_layers=24 ) # 包装为分布式模型 from torch.distributed.fsdp import FullyShardedDataParallel as FSDP model = FSDP(model) # 使用 Distributed Checkpoint 保存检查点 state_dict = {"model": model.state_dict()} dcp.save( state_dict, checkpoint_id="file:///mnt/checkpoints/iter_1000", ) # 恢复检查点 dcp.load( state_dict, checkpoint_id="file:///mnt/checkpoints/iter_1000", ) model.load_state_dict(state_dict["model"])

使用分布式检查点的好处是：每个 rank 只需要保存自己持有的分片，不需要把所有参数集中到 CPU 再写入，节省大量内存和时间。

5.3 故障卡处理策略

当检测到 GPU 故障或网络异常时，调度系统应自动完成以下动作：

1. 隔离故障设备，避免影响其他任务；
2. 释放已分配的资源；
3. 重新调度任务到健康设备；
4. 从上一个检查点恢复训练；
5. 记录故障日志，触发告警和维修工单。

这里的关键是不要依赖人工干预。百万卡集群上每天可能发生多次故障，人工排查不现实。

5.4 性能瓶颈定位常用命令

训练出现性能下降时，可以依次执行以下检查：

# 查看 NVLink 连接状态 nvidia-smi nvlink -s # 查看网络端口状态与速率 ibstat # 查看存储写入延迟 df -h /mnt/checkpoints fio --name=write-test --rw=write --size=1G --numjobs=16 # 查看 GPU 利用率与温度 nvidia-smi dmon -s pucvmet

如果 GPU 利用率长期低于 90%，需要重点检查数据加载、前置传输和通信是否存在瓶颈。

6. 百万卡集群的最佳实践与工程建议

6.1 训练框架与超参数实践

对于超大模型训练，推荐使用 Megatron-LM 与 DeepSpeed 的组合方式。Megatron 擅长处理张量并行和流水线并行，DeepSpeed 擅长优化 ZeRO 显存和 MoE 并行。两者配合可以实现大规模稀疏模型的稳定训练。

超参数设置建议：

• 使用 BF16 混合精度训练，避免 FP16 的精度溢出问题；
• 梯度裁剪阈值设置在 0.5 到 1.0 之间；
• 学习率调度使用余弦退火并结合 warmup；
• 大批量训练时，适当增大 warmup 步数，避免早期不稳定。

6.2 通信优化实践

网络通信是百万卡训练的“放大镜”，一旦有优化不到位，性能会被放大为严重瓶颈。具体实践包括：

1. 开启 NCCL 拓扑感知：

export NCCL_TOPO_FILE=/etc/nccl-topo.xml

2. 设置合理的通信超时：

export NCCL_TIMEOUT=1800

3. 启用 NCCL 低延迟模式：

export NCCL_IB_TIMEOUT=22 export NCCL_IB_RETRY_CNT=7

4. 使用梯度压缩或梯度延迟同步：在通信带宽有限的场景下，可以考虑将梯度量化后再同步。但注意压缩率过高会影响收敛精度，需要实验验证。

6.3 数据加载与存储实践

一个常见误区是只优化 GPU 计算，忽略数据加载。在百万卡集群中，数据读取速度必须跟上 GPU 计算速度。建议：

• 使用 WebDataset 或 TFRecord 格式存储数据，减少小文件数量；
• 开启预取（prefetch）和多进程加载（num_workers > 0）；
• 将高频数据集放在本地 NVMe 或高性能并行文件系统中；
• 使用内存映射方式读取大文件，避免反复 open/close。

6.4 可观测性与告警

百万卡集群必须建立完善的可观测性体系。核心指标包括：

• GPU 利用率、温度、功耗；
• 网络丢包率、重传率、带宽使用率；
• 存储延迟、带宽、IOPS；
• 任务排队时间、训练吞吐、卡时利用率；
• 作业失败率、MTBF、MTTR。

推荐统一接入 Prometheus + Grafana，并使用分布式追踪工具（如 OpenTelemetry）分析任务耗时分布。

6.5 安全与权限

百万卡集群通常是企业核心资产，必须严格管理权限：

• 使用统一身份认证，禁止共享账号；
• 按需分配集群访问权限，不同项目组隔离命名空间；
• 数据集加密存储，传输使用加密通道；
• 高危操作（如删除数据、修改集群配置）必须走审批，并在测试环境验证；
• 记录所有操作日志，以便审计和追溯。

7. 对开发者学习路线的建议

百万卡时代对普通开发者意味着什么？

首先是分布式训练能力越来越重要。过去做 AI 可能只需要跑通单卡训练，但未来接触大模型训练，分布式并行将是基本功。建议按以下顺序学习：

1. 掌握 PyTorch 分布式基础：init_process_group、dist.all_reduce、DistributedDataParallel；
2. 学习混合精度训练：AMP、BF16、损失缩放；
3. 学习显存优化：梯度检查点、优化器状态切分、ZeRO；
4. 深入 FSDP 与 Megatron 并行策略；
5. 学习集群资源管理与调度：Slurm、Kubernetes；
6. 学习网络与通信原理：NCCL 原理、RDMA、InfiniBand 基础；
7. 最后再研究大规模训练稳定性、检查点与容错。

以下是结合 PyTorch 编写的一段官方风格的分布式参数服务器示例，供需要实践的同学参考。该示例演示了如何使用torch.distributed.rpc同时训练多个模型，麻雀虽小，却能体现参数服务器架构的思想，是理解分布式训练启蒙中常见的一段素材。示例思路来自 PyTorch 官方教程中大量出现过的”Distributed RPC”示例：

# 文件路径：rpc_ps_example.py import os import threading import torch import torch.distributed.rpc as rpc import torch.multiprocessing as mp import torch.nn as nn import torch.optim as optim # 参数服务器类，负责保存参数并更新 class ParameterServer(nn.Module): def __init__(self, num_features: int): super().__init__() self.param = nn.Parameter(torch.randn(num_features, 1)) def get_param(self): return self.param.detach() def update_param(self, grad): with torch.no_grad(): self.param -= 0.01 * grad def run_worker(ps_rref, num_features): model = nn.Linear(num_features, 1) optim = optim.SGD(model.parameters(), lr=0.01) data = torch.randn(64, num_features) target = torch.randn(64, 1) for step in range(10): pred = model(data) loss = ((pred - target) ** 2).mean() optim.zero_grad() loss.backward() # 把梯度推送给参数服务器 ps_rref.rpc_sync().update_param(model.weight.grad.t()) # 从参数服务器拉取最新参数 param = ps_rref.rpc_sync().get_param() model.weight.data = param.t().data print(f"worker step {step} loss {loss.item():.4f}") def run_master(num_workers: int, num_features: int): ps_rref = rpc.RRef(ParameterServer(num_features)) futs = [] for worker_id in range(1, num_workers + 1): futs.append( rpc.rpc_async( f"worker{worker_id}", run_worker, args=(ps_rref, num_features), ) ) for fut in futs: fut.wait() def run_worker_process(rank, world_size, num_features): os.environ["MASTER_ADDR"] = "localhost" os.environ["MASTER_PORT"] = "29500" rpc.init_rpc(f"worker{rank}", rank=rank, world_size=world_size) rpc.shutdown() if __name__ == "__main__": world_size = 3 mp.start_processes( run_worker_process, args=(world_size, 32), nprocs=world_size, join=True, )

这段代码展示了“参数服务器-工作者”模式的基本结构：工作者计算梯度并发送给服务器，服务器更新全局参数，工作者再拉取最新参数。实际大模型训练虽然远不止这个复杂程度，但通信与协作的思想是相通的。

8. 总结与下一步

百万卡“超级单体”是 AI 基础设施演进的一个重要方向，它体现的是算力从“多重集群”到“单一系统”的转变。我们在这篇文章中系统梳理了以下几个关键点：

• 百万卡级集群的定义和出现背景；
• 它要解决的大模型训练核心问题；
• 计算、网络、存储、调度、供电散热五大层面的技术架构；
• 构建百万卡集群的工程路径；
• 大规模训练中的常见故障和排查方法；
• 对开发者自身技能路线的影响。

对于后端开发者、AI 工程师和分布式系统工程师来说，百万卡时代最大的启示是：系统设计能力变得比单点优化能力更重要。无论是并行策略、通信拓扑、存储分层，还是故障恢复，都是系统层面的设计与取舍。

下一步可以实践的方向：

• 在你的服务器上用多卡跑一遍 DDP 和 FSDP 训练，比较通信开销；
• 学习 NCCL 的allreduce性能测试工具，直观感受网络对训练的影响；
• 用 Slurm 或 Kubernetes 管理一个小型 GPU 集群，理解资源调度的基本逻辑；
• 阅读 Megatron-LM 和 DeepSpeed 源码，逐步掌握混合并行策略的实现方式。

AI Infra 这条路很长，但只要你愿意从一个小集群开始动手调试，百万卡时代的技术底层逻辑并不神秘。希望这篇文章能给你一个相对完整的起点，我们下次遇到具体问题时，再继续深入拆解。