想进AI这行的人十有八九第一眼盯上的是模型结构、训练技巧很少有人一开始就想到“AI-Infra”这四个字。但等你真的在一线跟模型打交道凌晨三点被训练任务卡死的告警吵醒打开控制台发现GPU利用率是0%数据加载卡在IO上那一刻你就会明白——所谓AI能力根基全在基础设施上。我做了几年AI基础设施相关的工作从裸机装驱动、调NCCL通信到上Kubernetes调度GPU、搭推理服务大大小小的问题都碰过。这个系列我打算把自己的实践路线和踩坑记录整理出来第一章先聊最核心的东西AI-Infra到底管什么、选型怎么思考、生产环境怎么落地、出了问题怎么查。不写教科书式的理论全是实打实摸过一遍后的经验。1. AI-Infra到底管什么先别急着上K8s把边界画清楚1.1 从一次“卡死”事故说起我之前接过一个任务内部团队有几十张卡跑一个新模型的训练。数据科学家写好了代码自测没问题全量训练一跑十几个小时过去loss纹丝不动。他们怀疑是代码有bug查了两天没结果最后查到数据加载层——训练时每个step都在等文件读取GPU利用率长期贴着0%跑。这就是典型的AI-Infra问题模型代码没问题算法没问题但底层的数据管线、存储、网络、资源调度出了问题整个训练就废了。AI-Infra做的事情简单说就是“让模型能跑起来、跑得快、跑得省”。这里的“快”不只是单卡算得快而是从数据进来到模型更新落地的全链路时间。数据要能快速加载到GPU多卡之间通信要顺畅训练平台要能弹性伸缩推理服务要扛得住流量。任何一个环节掉了链子前面的算法再好看也白搭。1.2 AI-Infra和MLOps、DevOps的区别很多人容易把AI-Infra和MLOps混在一起。我的理解是这样MLOps更偏向“流程和生命周期”比如数据集版本管理、模型注册、实验追踪、CI/CD流水线这些偏软件工程的东西而AI-Infra偏向“算力、存储、网络、调度这些物理资源和系统层”解决的是“资源从哪来、怎么分配、怎么稳定跑”的问题。DevOps的底座是通用云原生技术但AI-Infra需要额外关心GPU驱动、CUDA版本、NCCL通信库、显存管理这些传统运维完全不需要碰的东西。用一张对比表能看更清楚维度AI-InfraMLOpsDevOps核心对象GPU、网络、存储、调度模型、数据、实验流程应用、服务、发布典型问题显存不足、NCCL超时、GPU掉卡模型版本混乱、实验不可复现部署失败、服务不可用关键工具Slurm、K8s、NCCL、并行文件系统MLflow、DVC、KubeflowJenkins、GitLab CI关注指标GPU利用率、通信带宽、训练吞吐实验精度、模型迭代效率部署频率、可用性实际工作里这些边界经常交叉但搞清楚自己的核心职责在哪一层遇到问题才知道往哪个方向排查。1.3 一线工程师AI-Infra能力地图我接触过不少想转AI-Infra的同行大家普遍不知道该学什么。我把日常用得最多的能力拆成四层硬件与资源层GPU型号和参数差异、NVLink/NVSwitch拓扑、高速网络InfiniBand和RoCE、并行文件系统、对象存储。这一层要懂但不需要成为硬件专家关键是理解瓶颈在哪。系统软件层Linux内核参数锁页内存、网络缓冲、GPU驱动和CUDA版本兼容性、nvidia-container-toolkit、NCCL环境变量调优。这里踩坑最多后面第三章详细讲。调度与编排层Slurm或者Kubernetes起码要熟练一个。现在企业里K8s生态更主流需要掌握GPU Device Plugin、显存配额、抢占式调度、节点亲和性这些概念。应用层要知道PyTorch DDP、DeepSpeed、Megatron这些分布式训练框架是怎么用通信库的也要知道推理引擎比如vLLM、Triton对显存和延迟的诉求。这四层不需要一开始就全精通但每一层都要有“能定位问题”的程度。我的建议是先把前两层打通因为后面所有软件层的问题最后都会落到资源层的物理限制上。2. 硬件与集群规划GPU之外最容易被低估的三块短板2.1 算力层选型从消费卡到企业卡到底差在哪很多刚起步的团队喜欢先买几张消费级显卡压压惊跑通了再上企业级。这个思路本身没错但一定要清楚消费级和企业级的差距不只是算力大小。我用表格整理一下我接触过的几个典型型号以单卡视角参数消费级RTX 4090为例数据中心级A100为例数据中心级H100为例显存24GB GDDR6X40/80GB HBM2e80GB HBM3显存带宽约1TB/s约2TB/s80G版本约1.9TB/s约3.35TB/s互联PCIe/NVLink有限支持NVLink 600GB/sNVLink 900GB/s适用训练场景小模型、微调、推理中大模型训练、推理大模型训练稳定性设计民用级企业级ECC、RAS企业级ECC、RAS显存带宽这个参数经常被忽略但对大模型训练来说它比算力更先成为瓶颈。Transformer结构是计算密集和访存密集并存的每个token都要反复读写权重和中间激活值显存带宽不够计算单元就空转等数据。选型时还有两个实操建议第一显存容量要按“最大单卡可承载的模型规模”去规划别卡得太死。第二多卡之间如果用NVLink机内通信会快很多如果预算有限只能用PCIe那你做分布式训练时通信开销会吃掉一截加速比。注意消费级显卡的“稳定”和企业级的“稳定”不是一个概念。跑7x24小时的训练任务民用卡出问题的概率明显高。如果任务很重要别拿生产数据赌便宜那点差价。2.2 网络NCCL通信才是真正的隐形瓶颈我见过一个团队买了8张A100组了个单机8卡欢天喜地开始训练。结果跟4卡比加速比只有1.6倍左右。查来查去瓶颈在PCIe switch带宽上。机内通信如果走PCIe而非NVLinkAllReduce的效率会大打折扣。跨机器就更敏感了——NCCL对网络延迟和丢包的容忍度非常低。做多机训练前先要明确通信模式。NCCL的AllReduce在每轮迭代里要做多次集合通信数据量越大对带宽要求越高。这里有个粗糙的估算方法假设你的模型每个step要同步的梯度量是M字节做N次AllReduce通信时间大致正比于M乘以节点数-1除以可用带宽。也就是说节点越多、模型越大网络带宽不够就越是灾难。网络选型上InfiniBand是首选但价格贵RoCEv2RDMA over Converged Ethernet是更常见的替代方案。RoCE要保证无损网络需要开启PFC优先级流控和ECN显式拥塞通知这对交换机和网卡的配置都有要求。普通以太网做TCP通信不是不能用但延迟高、CPU开销大NCCL很容易超时。实操记忆点做多机训练先跑一遍NCCL测试再跑你的模型。nccl-tests里的all_reduce_bench能直接测出节点间的实际带宽。如果数值离线速差很多先查网络别查模型代码。2.3 存储数据加载慢GPU就挨饿存储是最容易被低估的短板。很多团队买GPU眼睛都不眨存储却用一台NFS糊弄过去。训练数据一多NFS撑不住数据加载速度跟不上GPU消耗速度训练效率直线下降。训练场景的存储诉求要分两类看一类是大量小文件随机读比如读图片、读小文本样本另一类是超大文件顺序读比如读TFRecord、Safetensors这类合并好的数据文件。前者的痛点在IOPS和元数据性能后者的痛点在顺序吞吐。规划的优先级应该是先保证大文件顺序读的吞吐再优化小文件读的元数据性能。一线常用的方案组合是这样原始数据放对象存储容量大、便宜热数据缓存到并行文件系统或本地NVMe SSD训练节点在读数据时尽量走缓存。如果预算实在有限最低成本的做法是训练前把数据打包成大文件减少IO次数。这个习惯看起来简单但提升非常明显。2.4 基础设施规划参数参考我根据自己的实际经验给几个不同规模的参考配置以训练为主集群规模4~8卡单机16~32卡多机64卡以上网络要求机内NVLink/PCIe即可建议RoCE或IB25Gbps起步IB或RoCE100Gbps起步存储需求本地NVMe 中等NFSGPFS/并行文件系统 缓存层高性能并行文件系统 分级存储调度系统裸机或轻量脚本K8s或SlurmK8s或Slurm 配额管理典型瓶颈数据加载、驱动兼容网络通信、存储吞吐调度效率、故障自愈、容量规划这组数字不是金科玉律但可以做初期规划参考。核心思路是先想清楚你的任务形态是“单卡跑得动但想跑更多”还是“单卡根本装不下”两种形态对基础设施的要求完全不一样。3. 软件栈落地实操从裸机到能跑通训练任务3.1 环境准备GPU驱动与容器运行时我强烈建议所有训练环境都容器化。不在裸机里直接折腾Python环境和CUDA原因只有一个可复现性。今天在裸机里装好的一套Conda环境三个月后系统一升级可能就废了容器镜像把驱动依赖、CUDA版本、Python依赖全锁在里面扔到哪台机器上跑都一样。环境准备的第一步是装GPU驱动。以Ubuntu系统为例先确认硬件型号和内核版本然后安装匹配的驱动。装完后用nvidia-smi验证能看到GPU列表和驱动版本就说明基础层通了。第二步装容器运行时# 以Ubuntu/Debian为例安装nvidia-container-toolkit curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | sudo apt-key add - distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list | sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker装完之后用这条命令测试容器里能不能看到GPUdocker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi如果这条命令正常输出说明nvidia-container-toolkit已经把宿主机的GPU透传进容器了。这里有个最常见的坑宿主机驱动版本和容器内CUDA版本不匹配。一般来说只要宿主机驱动足够新容器内的CUDA小版本可以不匹配但大版本差异太大就会有兼容性问题。保险做法是查一下nvidia-smi右上角的CUDA Version确保容器的CUDA主版本不高于这个值。3.2 单机多卡训练环境搭建单机多卡是最容易快速见效的部署形态。8张卡在一台机器里机内通信走NVLink或PCIe延迟比跨机器低一个数量级。环境搭好后用PyTorch DDP做一次验证。DDP的核心是让每个进程绑定一张卡然后通过NCCL做梯度同步。启动方式一般有两种torchrun或者python -m torch.distributed.launch。前者更新推荐直接用torchrun# 单机8卡训练启动命令示意 torchrun --nnodes1 --nproc_per_node8 train.pytrain.py的关键部分长这样import torch import torch.distributed as dist def main(): dist.init_process_group(backendnccl) local_rank int(os.environ[LOCAL_RANK]) torch.cuda.set_device(local_rank) model MyModel().cuda(local_rank) model torch.nn.parallel.DistributedDataParallel( model, device_ids[local_rank] ) # 正常训练循环 ...这看起来简单但有几个环境变量值得手动确认。NCCL_P2P_LEVEL控制在节点内是否启用NVLink的P2P通信默认auto即可但如果驱动或拓扑识别有问题可以手动指定。跨机训练时NCCL_SOCKET_IFNAME要指定实际业务网卡千万别让它选到管理网口或Docker虚拟网桥上否则通信带宽差一个量级。NCCL_IB_DISABLE0是开启InfiniBand/RoCE的RDMA通信如果用普通以太网则需要设为1。提示单机多卡训练的加速比不是线性的。8卡能跑到6.5倍以上就算不错如果8卡只有3~4倍优先排查是不是有PCIe带宽瓶颈或者是不是数据加载成了串行瓶颈。3.3 调度层为什么选择Kubernetes加GPU调度器从单机走向多机以后靠人肉分配GPU不现实。这里的主流路线是Kubernetes加NVIDIA Device Plugin。整个架构的核心逻辑Device Plugin把GPU作为可调度的资源暴露给K8s用户通过YAML声明要几张卡调度器负责把Pod调度到有卡且资源够的节点上。NVIDIA官方Device Plugin的安装文档很完整我挑重点说。装完DaemonSet之后K8s节点上会多出一种资源nvidia.com/gpu。你的Pod就可以这样申请GPUapiVersion: v1 kind: Pod metadata: name: gpu-training-pod spec: containers: - name: train image: your-registry/train-image:latest resources: limits: nvidia.com/gpu: 2这里有件非常重要的事nvidia.com/gpu是按“整卡”分配的。也就是说你申请了2就是两张完整卡不能出现“一张卡的30%”这种用法。如果你想要显存细粒度切分需要额外引入显存虚拟化方案比如MIG或者vGPU之类的技术和产品。但整卡分配的好处是隔离彻底、性能可预期生产环境优先用这个。调度层另外一个实操要点是“节点标签和污点”。GPU节点一般要打上专门的标签比如gpu-nodetrue然后给普通业务Pod设置节点亲和性避免CPU任务挤占GPU节点的CPU和后端网络资源。还要配合污点Taints和容忍Tolerations机制确保只有需要GPU的Pod才能调度到GPU节点上。3.4 一个最小可跑的推理服务示例训练搞定后推理服务是另一个高频场景。早期很多人用TensorFlow Serving或者直接Flask包一个模型接口但在大模型时代vLLM这类专门优化的推理引擎已经是主流选择。vLLM的核心优势是PagedAttention——显存管理方式从“预分配最大长度”变成“按需分页”能显著提高显存利用率和并发吞吐。启动一个最简单的vLLM服务只需要一条命令# 以下载的模型为例启动OpenAI兼容的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-3-8b-instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --port 8000参数解释一下tensor-parallel-size是张量并行的卡数8B模型两张卡足够gpu-memory-utilization控制KV Cache能占用显存的比例留一点余量给模型权重和激活但不能太低太低并发上不去。服务起来后用标准的OpenAI接口就能访问from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( model/data/models/llama-3-8b-instruct, messages[{role: user, content: 介绍一下AI基础设施}] ) print(resp.choices[0].message.content)推理服务压测有一个容易踩的坑只看tokens/s会误判。实际要用并发请求去压看延迟和吞吐的平衡点。vLLM里--max-num-seqs参数控制同时处理的最大序列数调太高会导致单请求延迟飙升调太低吞吐上不去。我一般会做几次并发压测取P99延迟在可接受范围内的最大并发值。4. 生产环境的真实故障与排查思路4.1 GPU掉卡和XID错误GPU掉卡是最常见也最让人头疼的问题。典型表现是训练跑着跑着某张卡的利用率突然归零nvidia-smi里看不到那张卡dmesg里刷出XID错误。XID是NVIDIA驱动上报的错误码不同数值含义不同。比如XID 13表示GPU内存访问错误XID 43表示GPU从总线上掉线XID 79表示GPU已经挂起。排查思路我按顺序列一下先看dmesg -T | grep -i nvidia找到具体的XID错误码。检查GPU供电和散热nvidia-smi -q -d POWER可以看功耗nvidia-smi -q -d TEMPERATURE看温度。过热和供电不稳是掉卡的两大物理原因。检查PCIe链路是否降速nvidia-smi -q -d PCIE看当前链路速率。如果链路从Gen4降到Gen1甚至Gen0大概率是接触不良或PCIe槽位供电不足。如果是多卡机器用nvidia-smi topo -m看拓扑判断是不是NUMA或者PCIe switch配置导致某张卡的通信路径异常。临时恢复手段通常是重置nvidia-smi -r需要root权限或者直接重启节点。但注意重启后一定要看持久化日志确认是不是硬件问题反复出现。我见过一台机器一个月掉了三次卡最后排查发现是电源线接触不良换了之后半年再没出过问题。4.2 NCCL超时不一定是GPU的问题NCCL超时在分布式训练里是高频故障。典型报错类似NCCL timeout或者rank x failed to get response from rank y。很多人的第一反应是查GPU状态但我复盘过自己遇到的几十次NCCL超时根因在网络的占比远高于GPU本身。常见的根因和排查路径是这样的网络拥塞普通以太网跑NCCL时拥塞导致重传延迟飙高最终超时。用nccl-tests可以快速验证# 在每台机器上跑示例为4节点 mpirun -hostfile hostfile -np 32 \ /path/to/build/all_reduce_perf -b 128M -e 128M -f 2 -g 1如果带宽远低于预期说明网络层有问题。开启RoCE的ECN/PFC、保证交换机无丢包或者干脆换高带宽网卡是最直接的解法。防火墙或网卡多队列配置问题NCCL通信需要大量端口有些集群默认防火墙策略把相关端口挡了。还有网卡的Ring Buffer太小高流量下丢包严重。能用RDMA就走RDMA不能用就把socket buffer调大。训练脚本里某个rank卡死比如不同rank的步调不一致DataLoader在某个rank上报错但没同步退出导致其他rank等NCCL响应等到超时。解决思路是加dist.barrier()做同步检查并且每个rank的日志都要单独落盘方便定位卡在哪个rank。记住一个原则NCCL超时排查顺序——先网络再存储最后才怀疑GPU计算。因为前两者的问题远多于GPU本身。4.3 OOM不一定是显存不够训练时报CUDA out of memory大多数人的第一反应是模型太大了。但实际排查中还有两个高频原因经常被忽略。一是显存碎片化。PyTorch默认的显存分配策略是缓存机制频繁创建和释放Tensor会造成碎片。更稳妥的做法是开启扩展段expandable segments在启动训练脚本前设置环境变量export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True这个参数让PyTorch更灵活地利用显存碎片对训练和推理都有帮助。vLLM在较新版本里甚至默认启用类似策略。二是CPU内存不足的误报。有时候训练进程显示的是CUDA OOM实际上是CPU内存爆了DataLoader多进程加载数据时把系统内存吃满导致进程被OOM Killer杀死。排查方法是看dmesg -T | tail -50里有没有Out of memory: Kill process的记录。如果是这种解决的思路是调小num_workers、降低预取缓冲区而不是削模型。还有一个容易被忽略的nvidia-smi里显示的显存占用和PyTorch认为的显存占用不一样。因为PyTorch有缓存机制nvidia-smi看到的占用可能高于torch.cuda.memory_allocated()统计的值。排查时用torch.cuda.memory_summary()看详细分配情况别只看nvidia-smi。4.4 一线实操的几条铁律最后分享几条我在生产环境里用血泪换来的规则每一条都对应过一个真实的事故监控先行指标先于用户报障。GPU利用率、显存温度、NCCL通信带宽、存储延迟至少这四类指标在上生产前就要接好。很多故障的苗头在指标上早就能看出来只是当时没人看。变更要可回滚。升级驱动、换CUDA版本、改NCCL参数每一样都要记清楚“改前是什么样”。我在生产上做过最快的一次回滚就是靠改前留下的完整记录。镜像不可变环境一次构建到处跑。任何训练环境都用容器锁死。谁偷偷在宿主机上pip install了包谁就负责把所有环境拉齐。容器化能帮你省掉这个扯皮的麻烦。容量规划要留余量。GPU集群的峰值需求和均值需求差距极大容量规划如果贴着峰值来成本撑不住贴着均值来高峰期任务排队排到天荒地老。我习惯的做法是区分“必须立即执行”的优先级任务和“可等待弹性调度”的普通任务用调度策略分开处理。故障演练不是IT部门的独角戏。每季度把训练任务人为制造一次故障切掉一台节点、把存储断掉5分钟看告警链路和恢复速度能不能达标。真的出大事时演练过的团队和没演练过的团队反应速度完全是两个状态。我个人在实际操作中还有一个固执的习惯每到一个新集群我第一件事不是跑模型而是先跑一套基础设施体检——包括GPU算力测试、NCCL带宽测试、存储读写测试。这套体检报告花不了半小时但它能帮你把“环境问题”和“代码问题”的空间彻底隔开。后面模型跑挂了你才知道该查哪一边。如果你刚接手一套AI基础设施也建议先做这件事后面会省掉大量互相甩锅的时间。