欧洲开放七个 AI“超级工厂”招标、计划投入约 300 亿欧元提升本地 AI 算力供给能力的消息让很多人开始重新理解一个事实AI 大模型竞争的背后是算力基础设施的工程竞争。所谓“AI 超级工厂”并不是一个普通的数据中心而是专门为大规模模型训练、微调和推理而设计的高密度计算集群。它把 GPU、高速网络、分布式存储、任务调度、监控告警和模型服务串成一条完整流水线最终“生产”出可用的大模型能力。对普通团队来说直接参与这种级别的基础设施建设并不现实。但完全可以用一台或多台带 GPU 的机器搭建一个“单机多卡”的 AI 算力测试平台把超级工厂里的核心工程问题压缩到最小规模跑一遍环境配置、分布式训练、GPU 监控、故障排查、调度思路、存储与成本控制。这篇文章就从这里切入先讲清楚 AI 超级工厂的组成再给出一个最小项目从零到能跑多卡训练最后补充生产级扩展和排错建议。1. 从 AI 超级工厂招标看算力基础设施要解决什么1.1 AI 超级工厂是什么“AI 超级工厂”可以理解为一套把算力资源变成模型能力的生产线。这里的“生产”并不指制造芯片或服务器而是指加载数据、训练模型、评估效果、部署推理服务这一整套流程。它的核心目标有两个为大规模训练提供稳定算力大模型参数量从几十亿到上千亿单张 GPU 放不下必须多卡多机协同训练。为在线服务提供低延迟推理模型训练完成后还要被业务系统持续调用需要 GPU 服务集群支撑。因此AI 超级工厂不是“买了一堆显卡”就完成了而是要解决显卡怎么被组织起来、怎么被高效使用、出了问题怎么恢复、任务怎么排队和审计等问题。1.2 一个典型 AI 算力集群的四层结构把一个 AI 算力集群拆开看通常可以分成四个层面。下面这张表概括了每一层的作用以及本文后面会涉及的最小化实现。层级典型组件核心作用单机多卡测试中的对应物计算层GPU 服务器、AI 加速卡提供矩阵计算和并行算力2 到 4 张 NVIDIA GPU网络层InfiniBand、RoCE、高速以太网连接多机多卡完成梯度同步本机 PCIe/NVLink 通信存储层并行文件系统、对象存储、本地 SSD保存训练数据、checkpoint、模型产物本地磁盘和共享目录调度与服务平台Slurm、Kubernetes、训练框架排队、分配资源、监控任务、暴露服务torchrun、Docker、Python 训练脚本学习阶段不需要完整的 InfiniBand 和并行文件系统单机多卡场景已经能覆盖计算层和调度层的核心逻辑。但必须知道在大型集群中网络和存储往往比 GPU 更容易成为瓶颈。1.3 算力利用率比显卡数量更重要很多团队评估算力平台时第一反应是“有多少张卡”。真正影响训练效率的是这些卡在真实任务中的利用率和有效吞吐。大模型训练中常见的时间浪费点包括GPU 计算很快但数据加载慢导致 GPU 空转。多卡训练时梯度同步和通信时间占比过高。显存不足导致频繁 swap 或 OOM 重试。任务排队策略不合理空闲 GPU 无法被其他任务使用。业界常用 MFUModel FLOPs Utilization来评估算力利用率它表示“模型实际完成的计算量”和“硬件理论上限”的比值。一个 AI 工厂如果只买卡却没有做好存储、网络、调度和容错MFU 可能长期停留在一个很低的水平。这也是“AI 超级工厂”这种名称背后真正值得关注的工程挑战如何把昂贵算力变成有效产出。2. 搭建单机多卡 AI 算力测试平台环境准备2.1 硬件与系统选型为了复现多卡训练至少需要一台带 2 张 NVIDIA GPU 的 Linux 机器。显卡型号不必是 A100 或 H100RTX 3090、RTX 4090、A5000 等都能用来学习分布式训练的基本机制。关键是几张卡最好型号一致避免性能差异导致训练速度不均。操作系统推荐 Ubuntu 22.04 LTS因为 NVIDIA 驱动、CUDA、PyTorch 在 Ubuntu 上的兼容性通常最好。如果手头只有 Windows也可以使用 WSL2 或云主机上的 GPU 实例作为替代但命令和兼容性需要额外确认。下面这份配置表用于学习环境参考生产环境还需要根据实际业务调整。组件学习环境建议生产环境额外要求GPU2 张同型号 NVIDIA 卡明确训练和推理的型号、显存、功耗CPU8 核以上需评估数据预处理和 DataLoader 并发内存32GB 以上根据模型和数据集大小预留磁盘500GB SSD并行文件系统、对象存储、高吞吐缓存网络本机 PCIe/NVLinkInfiniBand 或 RoCE跨机通信低延迟OSUbuntu 22.04 LTS统一镜像、内核驱动固化2.2 确认 GPU、驱动和 CUDA 环境安装任何训练框架之前先确认系统能看见 GPU并且驱动工作正常。打开终端执行nvidia-smi正常输出会列出 GPU 型号、显存、驱动版本和 CUDA 版本。如果输出No devices were found说明驱动未正确安装或者 GPU 没有被系统识别。还可以用下面的命令查看更精确的信息lspci | grep -i nvidia nvidia-smi --query-gpuname,memory.total,driver_version --formatcsv这里的逻辑是先确认物理设备存在再确认驱动能访问设备最后再安装与驱动匹配的 CUDA 运行库。不要把“安装了 CUDA Toolkit”等同于“GPU 可用”驱动和 CUDA 是两层关系。驱动安装方式因系统不同而不同。常见做法是用ubuntu-drivers devices查看推荐驱动再安装对应版本。安装完成后重启执行nvidia-smi验证。要注意驱动版本、CUDA Toolkit 版本、PyTorch 的 CUDA 版本三者需要匹配否则训练时会出现CUDA error: no kernel image is available这类问题。2.3 创建 Python 虚拟环境并安装 PyTorch训练代码应该运行在独立的 Python 虚拟环境中避免污染系统 Python。命令如下python3 -m venv venv source venv/bin/activate pip install --upgrade pip然后安装 PyTorch。以 CUDA 12.1 为例pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121安装完成后用以下命令检查 PyTorch 是否能看到 GPUpython -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.device_count())期望输出中torch.cuda.is_available()为Truetorch.cuda.device_count()大于等于 2。如果device_count()显示只有 1要检查是不是同一张卡被重复映射或者CUDA_VISIBLE_DEVICES环境变量限制了可见设备。2.4 为什么推荐用容器而不是裸机在只有一两台机器做实验时直接在虚拟环境里跑也可以。但如果要扩展到多台机器或者要复现团队里其他人的训练环境强烈建议使用容器。容器可以把 CUDA 库、PyTorch 版本、系统依赖一次性打包。即使主机驱动版本不同只要 GPU 驱动能工作容器内环境也可以保持稳定。NVIDIA 官方提供了包含 PyTorch 的容器镜像基本命令如下docker run --rm --gpus all -it nvcr.io/nvidia/pytorch:24.01-py3 bash执行前需要确保 Docker 已安装并配置好 NVIDIA Container Toolkit。否则--gpus all参数会报错。容器环境的好处有三个环境一致训练代码在开发机、测试机、生产机上行为一致。权限隔离不同项目用不同镜像避免依赖冲突。快速回滚镜像一旦损坏或升级失败可以回到旧版本。对于单人学习虚拟环境足够对于团队协作容器更接近生产形态。3. 用最小 DDP 项目跑通单机多卡训练3.1 项目结构本节用 PyTorch 的 DistributedDataParallelDDP实现一个最小多卡训练程序。项目结构如下ai-factory-lab/ ├── train.py ├── requirements.txt └── README.mdtrain.py是核心训练脚本。requirements.txt中只需固定 torch 版本即可例如torch2.0代码不依赖额外模型权重也不使用真实数据集而是随机生成一份张量数据。这样做的目的是把注意力集中在“多卡如何协作”上而不是模型本身的精度。3.2 DDP 最小训练代码下面是完整的train.pyimport 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 class MLP(nn.Module): def __init__(self): super().__init__() self.net nn.Sequential( nn.Linear(64, 128), nn.ReLU(), nn.Linear(128, 10), ) def forward(self, x): return self.net(x) def train(): dist.init_process_group(nccl) rank dist.get_rank() world_size dist.get_world_size() torch.cuda.set_device(rank) device torch.device(fcuda:{rank}) print(frank{rank}, world_size{world_size}, device{device}) torch.manual_seed(0) x torch.randn(4096, 64) y torch.randint(0, 10, (4096,)) dataset TensorDataset(x, y) sampler DistributedSampler( dataset, num_replicasworld_size, rankrank, shuffleTrue, ) loader DataLoader( dataset, batch_size64, samplersampler, num_workers0, pin_memoryTrue, ) model MLP().to(device) ddp_model DDP(model, device_ids[rank]) optimizer optim.SGD(ddp_model.parameters(), lr0.01) criterion nn.CrossEntropyLoss() for epoch in range(3): sampler.set_epoch(epoch) total_loss 0.0 for xb, yb in loader: xb xb.to(device) yb yb.to(device) optimizer.zero_grad() out ddp_model(xb) loss criterion(out, yb) loss.backward() optimizer.step() total_loss loss.item() avg_loss total_loss / len(loader) if rank 0: print(fepoch{epoch}, avg_loss{avg_loss:.4f}) dist.destroy_process_group() if __name__ __main__: train()这段代码的关键点有四个dist.init_process_group(nccl)初始化分布式进程组nccl是 NVIDIA GPU 训练常用的通信后端。torch.cuda.set_device(rank)每个进程使用不同的 GPU否则多个进程会挤在同一张卡上。DistributedSampler负责把数据集按进程数切分每个进程读到不同的数据分片。DDP(model, device_ids[rank])对模型做分布式封装训练时自动同步梯度。代码中torch.manual_seed(0)保证每个进程生成相同的数据再由DistributedSampler划分出不同子集。这样模拟的是“同一个数据集在不同 GPU 上并行训练”结果更接近真实场景。3.3 为什么不用 DataParallelPyTorch 里还有一个更早的多卡方案叫DataParallel写法更简单但它有几个明显问题它是单进程多线程模型受到 Python GIL 影响扩展性有限。它把每次 forward 的输入在各卡之间来回复制通信开销大。多卡负载容易不均衡尤其小 batch 场景下收益很低。DDP 采用多进程方式每个进程持有独立的 Python 解释器、模型和优化器只通过集合通信在反向传播时同步梯度。这种做法更适合大规模训练也是当前主流方案。对比项DataParallelDistributedDataParallel进程模型单进程多线程多进程适用场景单机小规模快速验证单机多卡、多机多卡通信效率较低较高生产推荐度不推荐推荐3.4 用 torchrun 启动训练DDP 脚本不能用python train.py直接跑需要用 PyTorch 自带的启动器torchrun。它会设置分布式训练需要的环境变量并启动多个进程。在 2 张 GPU 的机器上执行torchrun --nproc_per_node2 train.py参数含义如下--nproc_per_node2每台节点启动 2 个训练进程对应 2 张 GPU。--master_port分布式通信端口默认 29500。端口被占用时可以用--master_port29501修改。--nnodes跨节点训练时指定节点数单机默认是 1。如果你的机器有 4 张卡只需把参数改为--nproc_per_node4。注意不要盲目超过实际 GPU 数量否则会报CUDA out of memory或无法分配设备。4. 验证训练结果日志、GPU 利用率与排查链路4.1 预期输出在 2 卡环境运行torchrun --nproc_per_node2 train.py后终端会看到类似下面的输出rank0, world_size2, devicecuda:0 rank1, world_size2, devicecuda:1 epoch0, avg_loss2.4841 epoch1, avg_loss2.3117 epoch2, avg_loss2.2834因为数据集是随机生成的分类问题的最优 loss 接近ln(10) ≈ 2.3026所以 loss 稳定在 2.30 附近是正常的。这里真正要验证的是两件事两个进程分别使用cuda:0和cuda:1。两个进程能完成通信并且rank0能汇总打印平均 loss。如果输出只有一行rank0说明nproc_per_node设置不对或者两个进程没有真正并行。4.2 用 nvidia-smi 确认 GPU 正在工作训练过程中打开另一个终端执行nvidia-smi正常情况下应该能看到两个 Python 进程分别占用两张 GPU每张卡的显存使用明显上升利用率出现波动。还可以用动态监控命令查看更细粒度的指标nvidia-smi dmon -s pucvmet -d 1-s pucvmet表示显示 power、utilization、clock、memory、temperature 等指标-d 1表示每秒刷新一次。多卡训练时如果某张卡利用率长期为 0%说明任务没有真正分配到那张卡上。4.3 对比单卡和多卡的差异为了验证多卡是否有效果可以分别运行 1 卡和 2 卡任务并用time统计耗时time torchrun --nproc_per_node1 train.py time torchrun --nproc_per_node2 train.py但要提醒的是这个随机小模型的计算量很小2 卡不一定比 1 卡快甚至可能因为通信同步而更慢。这是正常现象也是理解“并行不是万能药”的好例子。多卡训练要在大模型、较大 batch、较长训练时长下才有明显收益。如果发现 2 卡时 loss 波动异常比如每个 epoch 结果完全一样可能因为DistributedSampler没有正确划分数据或者每个进程的模型初始权重不一致。4.4 多卡训练常见错误排查CUDA error: device not set这个错误通常是因为进程没有调用torch.cuda.set_device(rank)。多进程启动后每个进程默认看到的还是cuda:0不手动指定就会造成多个进程抢占同一张卡。NCCL error: unhandled cuda error检查nvidia-smi是否显示卡被其他任务占用或者驱动版本异常。可以先杀掉异常进程释放显存再重新运行。RuntimeError: Address already in use分布式通信默认端口被占用。解决方式是换一个端口torchrun --nproc_per_node2 --master_port29501 train.py下面的表格汇总了几种常见情况问题现象常见原因检查方式处理建议torch.cuda.is_available()为 False驱动或 PyTorch 版本不匹配执行nvidia-smi安装匹配驱动重装对应 CUDA 版本的 PyTorch多个进程都使用 cuda:0忘记set_device日志中 device 地址相同在init_process_group后调用set_device(rank)训练初始化卡住多进程通信异常查看端口、网卡、防火墙换 MASTER_PORT检查多机网络连通性显存 OOMbatch size 过大或进程占用卡过多nvidia-smi查看显存调小 batch确保每进程单独一张卡loss 不下降随机数据无真实模式观察任务类型学习阶段正常重点看多卡协同是否成功5. 从单机测试到生产集群调度、存储、监控与成本5.1 调度系统Slurm 还是 Kubernetes单机多卡测试用torchrun就够了。但生产集群往往有几十台甚至上百台 GPU 节点这时必须引入调度系统。两种主流选择Slurm传统高性能计算领域常用适合批量训练任务。用户提交任务Slurm 分配节点和 GPU队列机制能避免资源抢占。Kubernetes更适合容器化服务和动态伸缩尤其是模型推理、AI Agent 这类在线服务。实际 AI 工厂里两种系统经常同时存在训练任务走 Slurm推理服务走 Kubernetes。选型时不要先入为主要看任务形态和团队现有运维能力。5.2 高速网络和分布式存储多机训练时GPU 之间的消息交换不能走普通千兆以太网。生产环境一般使用 InfiniBand 或 RoCE 网络延迟更低、带宽更高。如果没有高速网络多机 DDP 的通信时间会淹没计算收益甚至比单机还慢。存储同样关键。训练数据如果存在远端对象存储每次 epoch 都重新拉取会造成大量等待。常见做法是训练前把数据缓存到节点本地 SSD。checkpoint 定期写入分布式文件系统或对象存储。大模型权重文件使用高吞吐并行文件系统。在进入生产之前至少要做一次数据读取压测从存储中读取一个 epoch 的数据看耗时是否远小于训练耗时。如果数据读取成为瓶颈再多的 GPU 也发挥不出来。5.3 监控、日志、检查和失败恢复生产 AI 平台必须有监控。不是看“进程是否在跑”而是看GPU 利用率显存使用和温度网络吞吐数据加载耗时训练 loss 是否异常任务排队时间常用的开源组合是 Prometheus 采集指标Grafana 展示面板。训练任务本身也要记录日志包括启动参数、每轮 loss、保存的 checkpoint 路径。失败恢复是 AI 工厂最容易忽略的部分。大模型训练一次可能跑几天甚至几周任何节点故障都会导致进度丢失。推荐做法是在每个 epoch 结束时保存 checkpointcheckpoint 中至少包含模型权重、优化器状态、epoch 编号和随机数生成器状态。任务失败后从最近的 checkpoint 恢复而不是重新开始。5.4 成本控制排队、混部和分时调度GPU 成本高昂长期闲置是最大的浪费。生产环境需要建立资源配额和排队机制。例如普通训练任务排队执行不允许多个任务同时抢占同一张卡。优先级高的推理服务预留固定资源。夜间训练批量任务白天运行在线推理。大任务失败后自动回滚到上一版本镜像缩短故障时间。这些策略听起来像管理问题实际上都需要调度系统和脚本实现。没有资源管理和成本控制AI 集群规模越大浪费越严重。5.5 对普通开发者的启发欧洲 AI 超级工厂的招标给普通团队的启发不在于“买多少卡”而在于工程能力分层第一层会写模型训练代码。第二层会跑多卡训练理解分布式通信和资源分配。第三层会容器化、调度、监控、checkpoint 恢复。第四层能把训练好的模型封装成 API、Agent 或应用服务。现在很多团队都在做 AI Agent 开发、用 Spring AI 这类框架把模型接入业务也有人用 AI 编程工具加速写代码。这些上层应用看起来热闹但底层基础一旦不稳模型训练和推理就会成为瓶颈。先掌握好单机多卡、容器、监控、调度这些基本功再往上层扩展路径会更扎实。6. 落地前必须避开的坑和检查清单6.1 坑一裸机直接装 CUDA导致环境冲突很多初学者会在物理机上直接安装 CUDA Toolkit之后换项目时发现 PyTorch 版本和 CUDA 版本对不上又舍不得卸载重装最后整个环境一团乱。推荐做法尽量用虚拟环境管理 Python 包用容器管理 CUDA 和 PyTorch 组合。物理机上只保留 GPU 驱动。版本冲突时容器是最容易回退的方案。6.2 坑二DDP 脚本没有设置当前进程 GPU写 DDP 时最容易漏掉的是torch.cuda.set_device(rank) device torch.device(fcuda:{rank})漏掉之后多个进程会默认使用cuda:0轻则显存不够重则表现上“多卡训练”实际只用了单卡。判断方法是看日志里每个进程的 device 是否各不相同。6.3 坑三小模型也强上多卡性能不升反降多卡训练不是万能的。模型很小、batch 很小、训练时间很短时通信和进程调度的开销可能超过计算收益。正确判断方式先用单卡跑通记录耗时和吞吐再切到多卡。如果多卡没有显著提升不要强行优化卡数而是先考虑增大 batch、增大模型、增加数据量让通信成本占比下降。6.4 坑四数据加载和存储成了隐藏瓶颈用nvidia-smi看 GPU 利用率很高不代表效率高。如果 GPU 每个 step 的等待时间很长说明数据加载速度跟不上。排查方式在训练代码中分别记录“数据读取时间”和“计算时间”或者使用 PyTorch Profiler。发现数据加载耗时占比高时优先增加num_workers、使用pin_memoryTrue、把数据复制到本地 SSD而不是急着加 GPU。6.5 坑五没有 checkpoint任务失败全重来训练是长任务任何一句CtrlC、电源故障、显卡驱动崩溃都可能中断。没有 checkpoint 意味着前面的算力和时间全部浪费。最少要在每个 epoch 结束后保存一次模型if rank 0: torch.save({ model: model.state_dict(), optimizer: optimizer.state_dict(), epoch: epoch, }, fcheckpoint-{epoch}.pt)恢复时加载state_dict再继续训练。多卡 DDP 中通常只由rank0保存文件避免多个进程写同一个路径。6.6 可复用的部署前检查清单下面的清单可以直接用在单机多卡实验或小型生产集群上线前[ ]nvidia-smi能正确显示所有 GPU驱动版本正常。[ ] PyTorch 的 CUDA 版本与驱动兼容torch.cuda.device_count()等于实际卡数。[ ] 训练代码在单卡环境下能完整跑通。[ ] 多卡启动命令中nproc_per_node与实际卡数一致。[ ] 每个 DDP 进程使用不同的cuda:rank。[ ] 数据采样使用DistributedSampler并且每个 epoch 调用set_epoch。[ ] 日志中能确认每个进程的 rank 和 world_size。[ ] 训练过程中用nvidia-smi确认每张卡都有负载。[ ] checkpoint 保存路径存在而且有权限写入。[ ] 长期训练任务配置了日志监控和失败告警。[ ] 容器镜像版本固定团队内统一使用。[ ] 生产环境确认网络、存储、队列策略不会成为新的瓶颈。AI 超级工厂招标反映的是整个行业对算力基础设施的重视。对开发者而言真正能带走的不是新闻里的数字而是一套可以验证、可以排查、可以扩展的工程方法。从单机多卡训练开始把环境、分布式通信、监控、checkpoint 这些基础环节逐一跑通再往集群调度和模型服务方向扩展这条路比单纯追热点要稳妥得多。