各位读者朋友大家好。当大家还在讨论千卡集群怎么调参、万卡集群怎么组网的时候一个更震撼的变量已经出现了——百万卡级别的 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每张卡持有完整模型副本处理不同 batch 数据梯度 AllReduce 通信张量并行TP把模型层内矩阵切分到多张卡每层前向/反向都有密集通信流水线并行PP把模型层按顺序切分到多张卡层间激活传递序列并行SP对长序列切分到多卡通信模式接近 TPMoE 专家并行EP把专家网络分布到不同卡Token 动态路由All-to-All 通信在实际训练中通常不是单一策略而是多种策略组合。例如“DP TP PP EP”的 4D 并行。调度器必须根据模型结构和卡间拓扑自动决定每一层使用哪种并行策略这是百万卡集群软件栈的核心能力之一。3.2 网络层无阻塞低延迟互联网络是百万卡集群最关键的“血管”。当前主流方案是InfiniBandIB或RoCERDMA over Converged Ethernet。IB 网络在 AI 集群中的优势是低延迟、高带宽、无损传输。一个典型的万卡集群已经需要采用胖树或多级 Clos 网络拓扑。当规模达到百万卡时纯胖树拓扑所需的交换机和光模块数量会爆炸式增长。因此业界开始探索更高效的拓扑例如轨道优化Rail-Optimized拓扑把 GPU 的网卡按照特定“轨道”连接到不同交换机层减少跨交换机跳数分层 Clos 拓扑将集群划分为多个 Pod例如 64 卡或 128 卡一个 PodPod 内高速互联Pod 间通过核心交换机连接光交换技术通过光电路交换机OCS动态调整连接路径减少多跳转发。对一个百万卡集群来说网络设计要求是端到端无阻塞带宽。通俗地讲就是任何两张卡之间的通信带宽不能因为网络争抢而明显下降。这在规模变大后变得极其困难。3.3 存储层高性能并行文件系统大模型训练的数据读取、检查点保存、日志写入都需要高吞吐存储系统。传统的数据中心 NAS 架构无法满足百万卡集群的并发读写需求。百万卡集群存储层一般分为多级存储层级典型介质用途内存级缓存GPU 显存、主机内存训练数据预取、激活缓存本地 NVMe每台服务器本地 SSD临时数据缓存、检查点临时写入并行文件系统Lustre、GPFS、WEKA、JuiceFS全局共享数据集、检查点存储冷存储对象存储历史数据集、模型归档关键指标是聚合带宽。百万卡集群训练时检查点文件可能达到 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 第二步集群网络设计网络设计是百万卡集群最核心的工程之一。以下是一个简化的网络规划思路每个计算 Pod128 张 GPU 每个 Pod 内GPU 通过 NVLink 全互联 Pod 内网卡通过 Leaf 交换机互联 Leaf 交换机上行连接到 Spine 交换机 Spine 交换机再连接到核心交换机对于百万卡规模需要将集群划分为若干个大区大区之间通过超高速骨干网连接每个大区内保持高带宽低延迟。在设计时要重点考虑以下问题单台服务器的 GPU 数量和网卡数量每张 GPU 对应的网卡带宽例如 400Gbps 或 800Gbps交换机端口密度和线速转发能力端到端拥塞控制策略故障域隔离和冗余路径。4.3 第三步软件开发栈选型百万卡集群的软件栈必须做到“全栈优化”。常见的软件栈包括层级典型组件集群管理Kubernetes、Slurm、Volcano任务调度Ray、Volcano、YuniKorn分布式训练框架PyTorch、Megatron-LM、DeepSpeed、MindSpore通信库NCCL、RCCL、MPI存储驱动JuiceFS、Lustre、GPFS监控运维Prometheus、Grafana、Ganglia在百万卡规模下PyTorch 默认的分布式训练配置并不能直接拿来用。需要深度定制 NCCL 通信算法、调整超时时间、优化集合通信图执行顺序。4.4 第四步仿真验证与调优在真实集群建成之前必须先进行大规模仿真验证。业界普遍使用两类工具网络仿真模拟不同拓扑下的通信时延和带宽找出瓶颈训练模拟用真实模型的简化版本在较小规模上验证并行策略再外推到大集群。一个常见的做法是先在 64 卡环境中验证算法再扩展到 1024 卡验证并行策略逐步放大。直接上百万卡做全量调试风险极高。5. 百万卡训练常见问题与排查思路超大规模训练的过程不会一帆风顺以下是一些常见问题和排查思路。5.1 NCCL 通信超时问题现象常见原因解决思路NCCL 超时错误网络拥塞、链路闪断、NCCL 版本不匹配检查网卡状态、交换机错误计数器统一 NCCL 版本增大超时时间AllReduce 速度下降多任务共享同一网络路径启用拓扑感知调度调整网络 QoS 策略部分卡显存溢出并行策略配置不合理重新计算显存占用使用重计算、优化器状态切片等显存优化手段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(backendnccl) # 构建模型 model torch.nn.Transformer( d_model4096, nhead32, num_encoder_layers24, num_decoder_layers24 ) # 包装为分布式模型 from torch.distributed.fsdp import FullyShardedDataParallel as FSDP model FSDP(model) # 使用 Distributed Checkpoint 保存检查点 state_dict {model: model.state_dict()} dcp.save( state_dict, checkpoint_idfile:///mnt/checkpoints/iter_1000, ) # 恢复检查点 dcp.load( state_dict, checkpoint_idfile:///mnt/checkpoints/iter_1000, ) model.load_state_dict(state_dict[model])使用分布式检查点的好处是每个 rank 只需要保存自己持有的分片不需要把所有参数集中到 CPU 再写入节省大量内存和时间。5.3 故障卡处理策略当检测到 GPU 故障或网络异常时调度系统应自动完成以下动作隔离故障设备避免影响其他任务释放已分配的资源重新调度任务到健康设备从上一个检查点恢复训练记录故障日志触发告警和维修工单。这里的关键是不要依赖人工干预。百万卡集群上每天可能发生多次故障人工排查不现实。5.4 性能瓶颈定位常用命令训练出现性能下降时可以依次执行以下检查# 查看 NVLink 连接状态 nvidia-smi nvlink -s # 查看网络端口状态与速率 ibstat # 查看存储写入延迟 df -h /mnt/checkpoints fio --namewrite-test --rwwrite --size1G --numjobs16 # 查看 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 通信优化实践网络通信是百万卡训练的“放大镜”一旦有优化不到位性能会被放大为严重瓶颈。具体实践包括开启 NCCL 拓扑感知export NCCL_TOPO_FILE/etc/nccl-topo.xml设置合理的通信超时export NCCL_TIMEOUT1800启用 NCCL 低延迟模式export NCCL_IB_TIMEOUT22 export NCCL_IB_RETRY_CNT7使用梯度压缩或梯度延迟同步在通信带宽有限的场景下可以考虑将梯度量化后再同步。但注意压缩率过高会影响收敛精度需要实验验证。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 可能只需要跑通单卡训练但未来接触大模型训练分布式并行将是基本功。建议按以下顺序学习掌握 PyTorch 分布式基础init_process_group、dist.all_reduce、DistributedDataParallel学习混合精度训练AMP、BF16、损失缩放学习显存优化梯度检查点、优化器状态切分、ZeRO深入 FSDP 与 Megatron 并行策略学习集群资源管理与调度Slurm、Kubernetes学习网络与通信原理NCCL 原理、RDMA、InfiniBand 基础最后再研究大规模训练稳定性、检查点与容错。以下是结合 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(), lr0.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(fworker 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( fworker{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(fworker{rank}, rankrank, world_sizeworld_size) rpc.shutdown() if __name__ __main__: world_size 3 mp.start_processes( run_worker_process, args(world_size, 32), nprocsworld_size, joinTrue, )这段代码展示了“参数服务器-工作者”模式的基本结构工作者计算梯度并发送给服务器服务器更新全局参数工作者再拉取最新参数。实际大模型训练虽然远不止这个复杂程度但通信与协作的思想是相通的。8. 总结与下一步百万卡“超级单体”是 AI 基础设施演进的一个重要方向它体现的是算力从“多重集群”到“单一系统”的转变。我们在这篇文章中系统梳理了以下几个关键点百万卡级集群的定义和出现背景它要解决的大模型训练核心问题计算、网络、存储、调度、供电散热五大层面的技术架构构建百万卡集群的工程路径大规模训练中的常见故障和排查方法对开发者自身技能路线的影响。对于后端开发者、AI 工程师和分布式系统工程师来说百万卡时代最大的启示是系统设计能力变得比单点优化能力更重要。无论是并行策略、通信拓扑、存储分层还是故障恢复都是系统层面的设计与取舍。下一步可以实践的方向在你的服务器上用多卡跑一遍 DDP 和 FSDP 训练比较通信开销学习 NCCL 的allreduce性能测试工具直观感受网络对训练的影响用 Slurm 或 Kubernetes 管理一个小型 GPU 集群理解资源调度的基本逻辑阅读 Megatron-LM 和 DeepSpeed 源码逐步掌握混合并行策略的实现方式。AI Infra 这条路很长但只要你愿意从一个小集群开始动手调试百万卡时代的技术底层逻辑并不神秘。希望这篇文章能给你一个相对完整的起点我们下次遇到具体问题时再继续深入拆解。