百万卡时代来了全球最大 AI「超级单体」在中国点亮这两年做大模型训练的朋友应该都有一种很直观的感受单卡训练已经成了“过去式”万卡集群开始成为标配而当我们还在研究千卡规模下的并行策略和通信优化时“百万卡”这个词已经从科幻变成了现实。最近全球最大的 AI 超级单体在国内点亮这一消息在 AI 基础设施圈子里讨论度非常高。很多人第一次听到“超级单体”这个说法会误以为它只是一个更大的数据中心或者只是把几千台服务器堆在一起。但其实超级单体代表的是一种全新的 AI 算力架构思路——不是“把机器连起来”而是“让所有算力变成一台机器”。这篇文章我想围绕“百万卡时代”和“AI 超级单体”这两个关键词从技术架构、工程挑战、并行训练、调度优化、可观测性等几个维度展开。文章不会只停留在新闻层面而是会把超级单体背后的技术原理拆开来讲同时给出一些我们在实际训练场景中可以借鉴的工程实践思路。如果你是做 AI 训练、大模型推理、算力调度平台开发或者对 AI 基础设施感兴趣的开发者这篇文章值得收藏慢慢看。1. 超级单体是什么AI 算力的“一台机器”思维1.1 从“集群”到“超级单体”的转变在传统的高性能计算和 AI 训练场景中我们习惯把算力组织成“集群”。一个集群由几百台甚至几千台服务器组成每台服务器有独立的 CPU、内存、GPU 和本地磁盘服务器之间通过高速网络互连。这种模式的问题是虽然机器之间可以通信但每一台机器仍然是独立的计算单元。训练一个大模型时我们需要手动设计数据并行、模型并行、流水线并行等策略把模型拆开分配到不同机器上还要处理机器之间的同步、通信、故障恢复等问题。规模越大分布式训练的复杂度就越呈指数级上升。而“超级单体”的理念完全不同。它不再把一堆机器组织成“集群”而是把成千上万张 GPU 卡通过超高速、超低延迟的网络连接起来从系统层面做成一个统一的、无缝的算力资源池。对上层应用来说你面对的是一台拥有百万张卡的“超级计算机”而不是一个由几万台服务器拼起来的“机房”。更准确地说超级单体的核心特征包括统一资源池计算资源不按物理服务器划分而是按任务动态分配。超大规模互联卡间通信不再是“跨机器”的概念延迟和带宽接近单机内部通信。全局调度同一套调度系统管理百万级别的算力单元。统一存储训练数据不再分散到各节点本地磁盘而是通过并行文件系统统一访问。弹性伸缩资源可以按任务需求动态申请、释放不需要人工介入。1.2 为什么需要百万卡规模很多人会问现在训练一个 GPT-4 级别的模型几千张卡不也够用吗为什么一定要做到百万卡答案其实很直接因为模型还在变大数据还在变多。以多模态大模型为例训练数据已经不只是文本还有图片、视频、音频。视频数据的 token 数量远高于文本一个 10 秒的短视频片段转换成视觉 token 之后可能相当于几万甚至几十万个文本 token。要在这样的数据规模上训练出高质量模型算力需求是超乎想象的。更关键的是当模型参数量达到万亿级甚至十万亿级时单个训练任务可能需要同时使用数十万张 GPU 卡。如果没有超级单体这种统一调度架构靠人工把几十万张卡组织起来是不现实的。1.3 我们应该关注什么对于普通开发者和 AI 工程师来说超级单体不代表我们要立刻去搭建一个百万卡的集群而是意味着分布式训练的思路需要升级从“手动拆模型”转向“平台自动并行”。算力调度的价值会越来越高学会用调度平台管理异构资源比手动指定 GPU 更重要。通信优化成为关键技能网络拓扑、通信原语、梯度压缩这些知识将直接影响训练效率。可观测性必须前置集群规模越大故障定位越困难监控和追踪能力必须跟上。下面我们从技术角度逐个拆解超级单体背后的关键工程问题。2. 从万卡到百万卡架构演进中遇到的四个核心问题2.1 通信瓶颈网络不再是“够用就行”在千卡级别的训练中网络带宽通常不是主要瓶颈因为模型并行的通信量可以在设计时人为控制。但到了百万卡规模情况完全不同。以 AllReduce 操作为例这是数据并行训练中最常用的通信原语。假设我们有 100 万张卡每一轮梯度同步需要把每个 GPU 上的梯度数据汇总再分发回去。即便单卡通信带宽达到 400Gbps在百万卡规模下全局同步的通信量依然是天文数字。为了解决这个问题超级单体的网络架构一般会采用多层拓扑结构卡间互联单台服务器内的 8 张 GPU 通过 NVLink 全互联带宽极高。机柜内互联机柜内服务器通过高速交换机组网。跨机柜互联通过 Spine-Leaf 架构或更高阶的 Fat-Tree 拓扑保证任意两张卡之间都有多条可用路径。全局互联不同机房或不同区域之间通过长距离光纤互联。对于普通开发者来说理解网络拓扑的意义在于设计并行策略时要考虑通信数据的“局部性”。让通信尽量发生在带宽高、延迟低的相邻节点之间可以显著提升训练效率。2.2 故障容错百万张卡每天都有卡在坏这是很多文章不会讲、但实际工程中最头疼的问题。一张 GPU 卡的 MTBF平均无故障时间通常只有几万小时。在百万卡规模下几乎每天都会出现 GPU 故障、网络闪断、内存错误、磁盘损坏等硬件问题。如果按照传统方式训练任务因为某一张卡故障就中断然后人工重启那么百万卡集群根本无法完成任何长周期训练任务。所以超级单体的容错能力必须做到故障自动检测通过健康检查、心跳机制、硬件监控快速发现故障节点。任务无缝迁移故障节点的计算任务可以自动迁移到其他空闲节点。训练状态持久化定期保存 checkpoint在故障恢复时从最近的 checkpoint 继续训练。无感重训练对于数据并行任务单个节点故障后其他节点可以继续训练新节点加入时自动同步状态。在工程实践上这意味着我们需要一个强大的集群管理平台而不是靠 shell 脚本和人工盯监控。2.3 能耗与散热算力的物理极限百万张 GPU 卡的功耗非常恐怖。以单卡功耗 350W 计算一百万张卡同时满载运行的功耗就是 350MW这还不包括网络设备、存储设备和制冷系统的功耗。所以大规模算力中心一般会选址在水电资源丰富、气候凉爽的地区同时大量采用液冷散热方案。液冷比风冷的散热效率高数倍而且更安静、更节能。对于上层应用开发者来说能耗优化的一个重要思路是提高 GPU 利用率。GPU 空转和低利用率造成的浪费比硬件本身更值得关注。这也反过来推动了调度系统在做资源分配时不只是“分卡”而是要考虑任务的 GPU 利用率、内存占用、通信带宽等综合因素。2.4 训练稳定性Loss 发散和性能波动模型训练到一半 Loss 突然发散是分布式训练中最常见的噩梦。集群规模越大引入的不确定性就越多。常见的稳定性问题包括数据加载抖动某个节点的数据读取速度变慢导致整个训练步长变长。通信超时某条网络链路拥塞导致 AllReduce 超时。时钟不同步节点间时钟偏移影响梯度同步。显存碎片化长期运行后显存碎片增多导致后续内存申请失败。这些问题在万卡规模下可能一周出现一次但在百万卡规模下几乎每天都在发生。因此超级单体的训练平台通常会在框架层加入大量自动恢复机制而不是像传统分布式训练那样依赖人工介入。3. AI 超级单体的关键系统设计拆解3.1 统一资源管理把“卡”变成可调度的资源在超级单体架构中GPU 不再属于某台服务器而是属于整个资源池。实现这一点的核心是资源管理系统。以 Kubernetes 生态为例我们通常通过 Device Plugin 和 Node Resource Manager 来管理 GPU 资源。但在百万卡规模下Kubernetes 默认的调度性能会遇到瓶颈需要引入更高效的调度器。一个简化的资源管理架构如下用户提交任务声明需要的 GPU 数量、内存、网络带宽 ↓ 全局资源调度器根据资源空闲情况、任务优先级、数据位置进行调度 ↓ 节点级资源管理器在物理节点上创建容器、挂载 GPU、配置网络 ↓ 任务执行器启动训练脚本、监控运行状态、上报心跳这里的关键点在于调度器不能只看“哪台机器有空闲 GPU”还要考虑数据是否在附近、网络拓扑是否最优、任务之间的亲和性等。3.2 并行策略自动化的必要性对于大模型训练常见的并行策略包括数据并行Data Parallelism每张卡持有完整的模型副本处理不同的数据批次。张量并行Tensor Parallelism把一层网络的参数切分到多张卡上协同计算同一个操作。流水线并行Pipeline Parallelism把模型的不同层分配到不同卡上像流水线一样依次执行。序列并行Sequence Parallelism针对长序列输入把序列维度切分到多张卡上。在千卡时代这些并行策略通常需要开发者手动配置。但在百万卡时代手动配置已经不现实了。超级单体平台需要在框架层自动分析模型结构、显存占用、通信开销然后自动选择最优的并行方案。这也正是 PyTorch 中 FSDPFully Sharded Data Parallel、DeepSpeed、Megatron-LM 等框架不断演进的原因。它们的目标都是让开发者用更少的精力获得更高的训练效率。3.3 存储架构训练数据不再“本地化”传统分布式训练中训练数据通常存储在每台机器的本地磁盘上或者通过 NFS 共享。但在百万卡规模下NFS 的吞吐量远远不够。超级单体中的存储层一般采用分布式并行文件系统比如 Lustre、GPFS 或自研的存储系统。所有计算节点通过高速网络访问统一的存储池训练数据只需要一份所有节点都能并发读取。对于开发者来说这种架构的好处是数据管理非常简单不需要把数据分发到每个节点只需要在训练脚本中指定数据集路径即可。但需要注意的是数据读取的瓶颈从“网络传输”转移到了“存储系统的 IOPS 和带宽”所以数据预处理和缓存策略依然很重要。3.4 任务调度与弹性伸缩超级单体的一个典型特征是“任务排队”和“资源抢占”。当多个训练任务同时提交时调度器会根据优先级、资源需求量、预计运行时间等因素决定任务执行的先后顺序。对于高优先级任务系统可以动态抢占低优先级任务的资源。这种调度策略在实践中有几个关键参数需要关注任务优先级决定资源竞争的胜出顺序。资源配额每个团队或项目可以使用的最大资源量。抢占策略高优先级任务是否可以强制回收低优先级任务的 GPU。排队机制当资源不足时任务是排队等待还是直接失败。4. 百万卡时代我们如何参与从单机到分布式训练工程如果你现在还没有条件使用超级单体规模的算力不要紧。百万卡时代的核心思想——资源池化、并行自动化、弹性调度、可观测性——完全可以落地到中小规模的分布式训练中。下面我们来看一个实际的工程示例。4.1 基于 PyTorch 的分布式训练基础示例假设我们有一个简单的深度学习模型希望在多张 GPU 上做数据并行训练。首先安装必要的依赖pip install torch torchvision然后写一个最小化的分布式训练脚本# 文件路径train_ddp.py import os import torch import torch.distributed as dist import torch.nn as nn import torch.optim as optim from torch.nn.parallel import DistributedDataParallel as DDP from torch.utils.data import DataLoader, TensorDataset from torch.utils.data.distributed import DistributedSampler def setup(): # 初始化分布式环境 dist.init_process_group(backendnccl) torch.cuda.set_device(int(os.environ[LOCAL_RANK])) def cleanup(): dist.destroy_process_group() class SimpleModel(nn.Module): def __init__(self): super().__init__() self.fc nn.Sequential( nn.Linear(128, 256), nn.ReLU(), nn.Linear(256, 10), ) def forward(self, x): return self.fc(x) def train(): setup() local_rank int(os.environ[LOCAL_RANK]) global_rank dist.get_rank() # 构造随机数据 data torch.randn(10000, 128) labels torch.randint(0, 10, (10000,)) dataset TensorDataset(data, labels) # 分布式采样器保证每个进程处理不同的数据 sampler DistributedSampler(dataset) dataloader DataLoader(dataset, batch_size64, samplersampler, num_workers4) model SimpleModel().cuda(local_rank) model DDP(model, device_ids[local_rank]) optimizer optim.Adam(model.parameters(), lr1e-3) loss_fn nn.CrossEntropyLoss() for epoch in range(5): sampler.set_epoch(epoch) model.train() total_loss 0.0 for x, y in dataloader: x x.cuda(local_rank) y y.cuda(local_rank) optimizer.zero_grad() output model(x) loss loss_fn(output, y) loss.backward() optimizer.step() total_loss loss.item() if global_rank 0: print(fEpoch {epoch}, Loss: {total_loss / len(dataloader):.4f}) cleanup() if __name__ __main__: train()启动命令# 单机 4 卡训练 torchrun --nproc_per_node4 train_ddp.py在这个示例中有几个关键点值得注意LOCAL_RANK表示当前进程在单机内的 GPU 编号GLOBAL_RANK表示全局进程编号。DistributedSampler确保每个进程读取的数据不重复同时每个 epoch 会重新打乱数据。DDP包装后的模型会自动执行梯度 AllReduce开发者不需要手动同步梯度。4.2 使用 DeepSpeed 进一步降低显存占用当模型大到单张 GPU 放不下时就需要使用 ZeRO 等显存优化技术。下面是一个最小的 DeepSpeed 配置和使用示例# 文件路径train_deepspeed.py import torch import deepspeed import torch.nn as nn import torch.optim as optim from torch.utils.data import DataLoader, TensorDataset class BigModel(nn.Module): def __init__(self): super().__init__() self.fc nn.Sequential( nn.Linear(4096, 8192), nn.ReLU(), nn.Linear(8192, 1024), ) def forward(self, x): return self.fc(x) def main(): # 构造大模型 model BigModel() data torch.randn(1024, 4096) labels torch.randint(0, 1024, (1024,)) dataset TensorDataset(data, labels) dataloader DataLoader(dataset, batch_size16) # DeepSpeed 配置 ds_config { train_batch_size: 16, gradient_accumulation_steps: 1, optimizer: { type: Adam, params: { lr: 1e-4 } }, zero_optimization: { stage: 2 }, fp16: { enabled: True } } model_engine, optimizer, _, _ deepspeed.initialize( modelmodel, configds_config ) loss_fn nn.CrossEntropyLoss() for step in range(100): x, y next(iter(dataloader)) outputs model_engine(x) loss loss_fn(outputs, y) model_engine.backward(loss) model_engine.step() if step % 10 0: print(fStep {step}, Loss: {loss.item():.4f}) if __name__ __main__: main()这里zero_optimization.stage2表示使用 ZeRO Stage 2将优化器状态切分到多张 GPU 上显著降低单卡显存压力。如果要进一步切分梯度和模型参数可以配置stage: 3。4.3 训练任务的容器化提交方式在真实的算力平台上训练任务通常以容器方式提交。下面是一个 Kubernetes GPU 任务的 YAML 示例# 文件路径gpu-training-job.yaml apiVersion: v1 kind: Pod metadata: name: gpu-training-pod labels: app: ai-training spec: restartPolicy: OnFailure containers: - name: trainer image: registry.example.com/ai-training:v1.0 command: [torchrun, --nproc_per_node8, train_ddp.py] resources: limits: nvidia.com/gpu: 8 volumeMounts: - name: data mountPath: /data - name: output mountPath: /output volumes: - name: data persistentVolumeClaim: claimName: training-data-pvc - name: output persistentVolumeClaim: claimName: training-output-pvc在实际的超级单体平台上提交任务的系统可能不是 Kubernetes而是自研的调度系统。但核心概念是相通的容器、资源声明、数据卷挂载、启动命令。如果你在多卡集群上做过训练可以把“从单机到双机、双机到多机”的过程中遇到的通信、同步、资源竞争问题记录下来这些经验在百万卡时代同样适用。5. 算力调度的技术拆解从手动分配走向全局优化5.1 传统调度方式的局限在没有调度平台的时代很多团队是这样分配 GPU 的管理员查一下哪台机器有空闲 GPU。手动设置CUDA_VISIBLE_DEVICES。直接在 shell 里启动训练脚本。这种方式的缺点非常明显容易出现资源竞争两个任务同时占用同一批 GPU。无法感知任务状态任务崩溃后GPU 资源不会自动释放。资源利用率低静态分配后即使任务没有满载运行GPU 也无法被其他任务使用。缺少优先级机制紧急任务无法插队。5.2 超级单体中的两级调度模型在百万卡规模的算力平台上调度系统通常采用两级模型第一级全局调度决定任务应该被分配到哪个“资源分区”。第二级分区调度在一个资源分区内部决定任务应该运行在哪几张卡上。这种两级模型的好处是全局调度不需要感知每一张卡的实时状态只需要管理分区级别的资源余量调度压力大大降低。分区内部可以针对不同类型任务做差异化优化例如训练任务可以做拓扑感知调度推理任务可以做延迟优化调度。故障隔离更容易一个分区出现故障不会影响其他分区的任务。5.3 抢占式调度的代价在多租户环境中抢占式调度几乎是必须的。高优先级任务可以挤掉低优先级任务但这就带来一个问题被抢占的任务如何善后如果不做 checkpoint被抢占的任务只能从头开始训练这是巨大的浪费。所以在超级单体平台上自动 checkpoint 不是一个“可选功能”而是基础设施级的标配。作为开发者我们在使用算力平台时也应该养成“训练脚本定期保存 checkpoint”的习惯。一个简单的 checkpoint 保存示例# 文件路径checkpoint_example.py import torch import os def save_checkpoint(model, optimizer, epoch, loss, filepath): checkpoint { model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), epoch: epoch, loss: loss, } torch.save(checkpoint, filepath) def load_checkpoint(model, optimizer, filepath): checkpoint torch.load(filepath) model.load_state_dict(checkpoint[model_state_dict]) optimizer.load_state_dict(checkpoint[optimizer_state_dict]) return checkpoint[epoch], checkpoint[loss]在实际训练中建议每隔一定步数保存一次 checkpoint并只保留最近几个版本避免磁盘被写满。6. 百万卡集群的可观测性故障定位的生命线6.1 算力集群的可观测性分层集群规模越大“看不见”的问题就越多。可观测性建设需要覆盖几个层面硬件层GPU 温度、功耗、显存利用率、PCIe 链路状态。系统层CPU 负载、内存使用、磁盘 IO、网络吞吐。框架层训练吞吐、Loss 趋势、梯度范数、通信耗时。任务层任务状态、失败原因、重启次数、排队时长。这些数据需要统一采集、存储和展示。常用的开源方案包括 Prometheus Grafana以及用于日志采集的 ELK/EFK 栈。6.2 训练任务的自定义指标上报除了平台层面的监控训练任务本身也应该上报关键指标。下面是一个简单的指标上报示例使用 Prometheus 客户端库# 文件路径metrics_example.py import torch import time from prometheus_client import start_http_server, Gauge import random # 定义指标 train_loss Gauge(train_loss, Current training loss) train_throughput Gauge(train_throughput, Samples per second) gpu_utilization Gauge(gpu_utilization, GPU utilization percent) def train_step(): # 模拟训练 time.sleep(0.1) loss random.uniform(0.1, 2.0) throughput random.uniform(100, 500) util random.uniform(70, 99) return loss, throughput, util def main(): # 启动 Prometheus HTTP 服务 start_http_server(9000) for step in range(1000): loss, throughput, util train_step() train_loss.set(loss) train_throughput.set(throughput) gpu_utilization.set(util) print(fStep {step}, Loss: {loss:.4f}) if __name__ __main__: main()在大规模训练中指标上报的频次需要控制避免指标采集本身成为性能瓶颈。一般建议Loss 等低频指标每个 step 上报。GPU 温度、功耗等高频指标每 10 秒上报一次。日志输出每 N 个 step 输出一次不要每次都打印。7. 常见问题与排查思路下面整理了大模型训练和算力平台使用中常见的问题以及对应的排查思路。问题现象常见原因解决思路训练启动时提示 NCCL 超时多卡通信端口不通或防火墙拦截检查节点之间的网络连通性确认 NCCL 所需端口开放显卡显存明明够用但训练时报 OOM显存碎片化或 PyTorch 内存缓存未释放使用torch.cuda.empty_cache()或调整 batch size多卡训练速度不随卡数提升通信开销占比过高数据加载成为瓶颈检查数据加载是否高效尝试增大 batch size 减少通信频次训练到中途 Loss 变成 NaN学习率过大、梯度爆炸、混合精度开关异常降低学习率开启梯度裁剪检查 fp16 配置任务被调度后长时间处于 Pending 状态资源配额不足或任务优先级过低检查资源配额和集群空闲资源调整优先级节点故障导致训练中断硬件故障或网络闪断配置自动重启策略使用 checkpoint 恢复训练数据加载速度慢存储带宽不足或数据预处理没有并行使用高性能并行文件系统增加 DataLoader 的 num_workers训练过程 GPU 利用率忽高忽低数据加载和计算没有流水线重叠开启 DataLoader 的prefetch_factor或使用异步数据加载8. 最佳实践与工程建议结合百万卡超级单体的技术方向我想给正在做 AI 训练相关工作的同学一些具体建议。8.1 训练代码层面永远不要在训练脚本里硬编码 GPU 编号使用环境变量读取LOCAL_RANK和GLOBAL_RANK。训练启动统一使用torchrun不要手写multiprocessing.spawn来启动分布式任务。checkpoint 一定要包含 epoch、step、optimizer 状态和随机数生成器状态否则恢复训练后结果可能不一致。建议开启自动混合精度AMP在绝大多数场景下AMP 可以显著提升训练速度并降低显存占用。定期记录梯度范数梯度范数异常波动往往是 Loss 发散前的征兆。8.2 算力资源使用层面申请资源前先估算显存需求不要盲目申请超大显存的卡。使用容器镜像时尽量把训练依赖固化到镜像中避免每次启动都现场安装。训练任务设置合理的 resource limit 和 request避免资源浪费。了解平台的抢占策略对自己任务的优先级要有清晰预期。对长时间运行的任务务必开启自动重启和 checkpoint 机制。8.3 可观测性层面关键指标使用 Prometheus 等标准化方式上报不要只靠 print。日志要包含时间戳、rank、module 信息方便定位是哪个节点、哪张卡出了问题。网络监控和 GPU 监控同样重要很多训练异常是从“网络抖动”开始的。8.4 平台建设层面优先选择经过大规模验证的开源项目例如 Kubernetes、Prometheus、PyTorch、DeepSpeed而不是重复造轮子。引入优先级和配额机制避免训练任务相互干扰。重视故障恢复流程的演练定期模拟“GPU 掉线”“节点宕机”等场景验证容错能力是否真正生效。9. 总结与学习路线百万卡超级单体的点亮标志着 AI 算力基础设施进入了一个新阶段。对于 AI 工程师来说这既是挑战也是机会。挑战在于分布式训练的复杂度和工程化要求越来越高机会在于能够掌握大规模训练平台建设和优化能力的人才会成为未来 AI 基础设施领域的稀缺资源。如果你希望跟上这个趋势建议按以下路径循序渐进地学习掌握单机多卡训练理解 DDP、AMP、梯度累积能把一个模型从单卡训练改造成多卡训练。学习显存优化技术掌握 ZeRO、张量并行、流水线并行的基本原理至少能使用 DeepSpeed 或 FSDP 跑通一个模型。了解调度系统学习 Kubernetes 的 GPU 资源管理、任务调度、优先级和抢占逻辑。深入通信优化学习 NCCL 的原理、通信拓扑与 AllReduce 的实现细节。实践可观测性搭建一套监控体系为训练任务添加指标上报和日志采集。关注行业前沿跟踪超大规模集群的技术方案和工程分享理解不同架构设计的取舍。超级单体离我们很远但它背后的技术思路并不遥远。资源池化、自动并行、弹性调度、可观测性这些能力在小规模集群中同样可以落地和演练。与其感叹百万卡集群的规模之巨不如先把这些基本功练扎实。等你真正遇到大规模分布式训练需求时会发现很多问题已经在掌握之中。