★ FEATURED ARTICLE 1. 从“调包侠”到系统思维为什么AI Infra值得啃一遍刚入行做算法的那两年我的工作流基本就是“pip install 改配置文件 跑实验”。模型不收敛就调学习率显存爆了就砍batch size推理慢就换更小的模型。这套打法在单卡、小规模场景下确实能跑通但一旦面对多机多卡训练、千亿参数推理、异构硬件调度这些真实生产问题时我发现自己完全是个“黑盒操作员”——知道按哪个按钮但不知道按钮背后发生了什么。AI Infra人工智能基础设施这个词这两年从大厂内部的黑话逐渐变成了行业通用术语。它涵盖的东西非常杂从最底层的GPU驱动、CUDA算子到中间的通信库NCCL、Gloo、训练框架PyTorch、Megatron、推理引擎TensorRT-LLM、vLLM再到上层的资源调度Kubernetes、Slurm、存储系统、监控体系。你可以把它理解成AI时代的“操作系统电网物流系统”的集合体——算法是跑在上面的应用而Infra决定了这些应用能跑多快、多稳、多省钱。这篇笔记不是教科书式的知识罗列而是我自己从零搭建小型训练集群、优化推理服务、排查通信瓶颈的过程中一点点拼出来的知识地图。适合两类人看一是算法工程师想补Infra短板避免“模型写得溜一上规模就抓瞎”二是运维或后端工程师想切入AI方向但被各种框架和术语搞得无从下手。我会尽量用“人话”解释每个模块解决什么问题、核心原理是什么、实际踩过哪些坑以及如果你要动手学应该按什么顺序啃。提示AI Infra的知识更新极快本文涉及的版本号和工具选型以我写作时的稳定版为准具体落地时请以官方文档为准。2. 算力底座GPU、显存与算力单位的真实含义2.1 为什么你的模型“显存不够”不一定是显卡太小很多人第一次遇到OOMOut of Memory时第一反应是“换更大的卡”。但实际排查下来显存占用往往由四部分组成模型参数、梯度、优化器状态、激活值。以混合精度训练为例一个7B参数的模型FP16权重占14GBFP32主权重副本占28GBAdam优化器的动量和方差各占28GB光这三项就接近100GB。这还没算激活值和通信缓冲区。所以一张80GB的A100跑7B全量微调OOM是必然的跟卡“大不大”关系不大而是训练策略的问题。解决思路有几个方向一是用ZeRO系列优化DeepSpeed或FSDP把优化器状态、梯度、参数分片到多卡上二是用LoRA这类参数高效微调方法只训练少量新增参数三是用梯度检查点Gradient Checkpointing用计算换显存。我实测下来7B模型用LoRA梯度检查点单张24GB的消费级卡就能跑起来代价是训练速度下降约30%。这个取舍在实验阶段完全值得。2.2 算力单位TFLOPS、TOPS和实际利用率的差距厂商标称的算力单位经常让人迷惑。FP32用TFLOPSINT8用TOPS稀疏算力又是另一个数字。关键要记住标称算力是理论峰值实际利用率能到50%就算优秀。以A100为例FP16 Tensor Core理论算力312 TFLOPS但实际训练中由于内存带宽、通信开销、kernel启动延迟等因素有效算力往往在120-180 TFLOPS之间。推理场景更复杂batch size小的时候算力利用率可能只有10%-20%。这里有个经验公式实际吞吐 ≈ 理论算力 × 利用率 × 扩展效率。多卡扩展时8卡通常能到70%-80%的线性扩展效率32卡可能降到50%-60%再往上就要看通信拓扑和并行策略了。所以当你看到“千卡训练”的宣传时别只看卡数要问实际MFUModel FLOPs Utilization是多少。我见过不少项目千卡集群的MFU只有30%出头大量算力浪费在通信等待上。2.3 显存带宽被忽视的性能杀手大家选卡时盯着算力数字但显存带宽往往才是瓶颈。A100的HBM2e带宽是2039 GB/sH100升级到3350 GB/s。为什么带宽重要因为大模型推理是典型的memory-bound任务——每生成一个token都要把整个模型权重读一遍。以7B模型FP16为例权重14GB如果带宽是2000 GB/s理论最快生成速度是2000/14 ≈ 143 tokens/s。实际因为KV Cache、attention计算等开销能到一半就不错了。这也解释了为什么量化能大幅提升推理速度INT8量化后权重减半带宽需求减半速度理论上翻倍。但量化会损失精度需要做校准。我在实际项目里常用GPTQ或AWQ做4bit量化7B模型在单卡上的生成速度能从30 tokens/s提升到80 tokens/s左右精度损失在可接受范围内。3. 通信与并行多卡训练的真正难点3.1 集合通信原语AllReduce、AllGather和ReduceScatter多卡训练的核心是通信。数据并行用AllReduce同步梯度张量并行用AllGather和ReduceScatter传递中间激活流水线并行用Send/Recv传递层间数据。这些集合通信原语的性能直接决定训练效率。以AllReduce为例Ring AllReduce的通信量是2×(N-1)/N×数据量N是卡数。当N很大时通信量趋近于2倍数据量。这意味着梯度同步的通信开销与模型参数量成正比。一个7B模型FP16梯度是14GBAllReduce要传输约28GB数据。如果卡间带宽是200 GB/sNVLink理论耗时0.14秒如果是PCIe 4.0的32 GB/s耗时接近1秒。这就是为什么NVLink对大规模训练如此关键。3.2 并行策略的选择逻辑TP、PP、DP怎么组合实际训练大模型时很少只用一种并行策略。常见组合是TPPPDP。选择逻辑如下单层放不下时用TP张量并行层数太多放不下时用PP流水线并行还想扩大规模就用DP数据并行。TP通信量最大适合放在同一节点内用NVLinkPP通信量较小可以跨节点DP通信量中等但需要全局同步。我踩过的一个坑是TP8跨节点部署。当时节点内只有4张卡有NVLink另外4张走PCIe结果TP通信成了瓶颈训练速度比TP4还慢。后来调整为TP4节点内、PP2跨节点效率提升了40%。这个经验说明并行策略必须匹配硬件拓扑不能只看卡数。3.3 通信库选型NCCL不是唯一选择NCCL是NVIDIA的集合通信库在NVLink和InfiniBand环境下表现最好。但如果你的集群是混合硬件或者需要跨云通信Gloo和MPI也是选项。Gloo对CPU和普通以太网支持更好但GPU性能不如NCCL。实际项目中我通常用NCCL做GPU间通信用Gloo做CPU侧的协调。还有一个容易忽略的点NCCL的环境变量调优。比如NCCL_IB_HCA指定网卡NCCL_SOCKET_IFNAME指定socket接口NCCL_DEBUGINFO可以打印通信日志。有一次训练速度异常打开NCCL_DEBUG后发现走了错误的网卡调整后带宽利用率从30%提升到85%。这些细节在官方文档里都有但很容易被跳过。4. 训练框架与显存优化从Demo到生产的鸿沟4.1 PyTorch DDP与FSDP什么时候该换PyTorch DDPDistributedDataParallel是最常用的数据并行方案每个卡持有完整模型副本梯度AllReduce后更新。优点是简单稳定缺点是显存冗余——每张卡都存一份完整模型和优化器状态。7B模型用DDP单卡至少需要80GB显存。FSDPFully Sharded Data Parallel是PyTorch官方的分片方案把参数、梯度、优化器状态都分片到各卡显存占用大幅降低。代价是通信量增加因为每次前向传播前需要AllGather参数。我实测下来7B模型用FSDP单卡24GB就能跑全量微调但训练速度比DDP慢约20%-30%。这个取舍在显存受限时非常值得。选择建议如果单卡能放下完整模型优先用DDP简单稳定如果放不下用FSDP或DeepSpeed ZeRO。DeepSpeed的ZeRO-3和FSDP原理类似但生态更成熟配置更灵活适合大规模生产环境。4.2 梯度累积与微批次小显存跑大batch的技巧梯度累积Gradient Accumulation是显存不足时的经典技巧把一个大batch拆成多个微批次分别前向反向累积梯度后再更新。这样等效batch size不变但显存占用降低。比如目标batch size是64单卡只能跑8就设置accumulation steps8。但这里有个坑BatchNorm层在梯度累积下统计量会不准确。Transformer模型通常用LayerNorm不受影响但CNN模型要注意。另外梯度累积会增加训练时间因为前向反向次数变多了。我的经验是能通过优化显存解决的问题尽量不用梯度累积实在没办法时累积步数也不要超过8否则训练效率下降太明显。4.3 混合精度训练AMP的收益与风险自动混合精度AMP是标配技巧用FP16或BF16做前向反向FP32做参数更新。收益是显存减半、速度提升30%-50%。风险是数值溢出需要梯度缩放Gradient Scaling来防止下溢。BF16比FP16更稳定因为指数位和FP32一样多不容易溢出。A100及以上卡都支持BF16建议优先用。FP16在V100等老卡上更常见但需要仔细调缩放因子。我遇到过FP16训练loss突然变NaN的情况排查后发现是某个attention层的softmax输出溢出换成BF16后问题消失。所以如果硬件支持无脑选BF16。5. 推理优化从“能跑”到“跑得快、跑得省”5.1 KV Cache自回归生成的显存大户大模型推理时每生成一个token都要重新计算之前所有token的Key和Value。为了避免重复计算KV Cache把历史KV存下来。但KV Cache的显存占用随序列长度线性增长。以7B模型为例FP16精度下每个token的KV Cache约1MB序列长度2048时就是2GBbatch size16时就是32GB。这还没算模型权重。优化KV Cache的方法有几种一是PagedAttentionvLLM的核心技术把KV Cache分页管理减少碎片二是MQAMulti-Query Attention或GQAGrouped-Query Attention减少KV头数三是量化KV Cache到INT8。我实测vLLM的PagedAttention能把吞吐量提升2-4倍尤其在长序列场景下效果显著。5.2 连续批处理推理服务的吞吐利器传统推理服务是静态批处理凑够一个batch就推理推理完再凑下一个。问题是不同请求的生成长度不同短请求要等长请求GPU利用率低。连续批处理Continuous Batching让每个请求独立调度生成完就返回新请求随时插入。vLLM和TensorRT-LLM都支持这个特性。实测数据7B模型在A100上静态批处理吞吐约500 tokens/s连续批处理能到1500 tokens/s以上。提升主要来自GPU利用率的提高——静态批处理时GPU经常在等最慢的请求连续批处理让GPU始终有活干。5.3 量化推理INT8、INT4的精度与速度权衡量化是推理优化的终极手段。INT8量化把权重和激活从FP16降到INT8显存减半速度提升1.5-2倍。INT4进一步压缩速度提升2-3倍但精度损失更明显。实际选择取决于任务分类任务对精度不敏感INT4没问题生成任务对精度敏感建议INT8或FP16。量化方法上GPTQ是训练后量化需要校准数据集AWQ是激活感知量化对异常值更鲁棒SmoothQuant是平滑量化适合大模型。我常用AWQ做4bit量化7B模型在单卡24GB上能跑batch size32生成速度约80 tokens/s精度损失在1%以内。这个方案在成本敏感的场景下非常实用。6. 资源调度与集群管理让多个人共用一堆卡6.1 Kubernetes vs Slurm选哪个Kubernetes是容器编排的事实标准适合微服务、推理服务、多租户场景。Slurm是HPC领域的作业调度器适合大规模训练任务。两者定位不同K8s强在服务发现、弹性伸缩、生态丰富Slurm强在作业队列、资源预留、拓扑感知。实际选择如果团队以推理服务为主或者需要和现有微服务架构集成选K8s如果以大规模训练为主追求极致性能和调度效率选Slurm。也有混合方案K8s管推理Slurm管训练通过共享存储和网络打通。我见过不少公司这么干效果不错。6.2 GPU共享与隔离MIG、Time-Slicing和MPS多个人共用一张卡时隔离是个问题。NVIDIA提供了几种方案MIGMulti-Instance GPU把A100切成最多7个独立实例硬件级隔离但配置不灵活Time-Slicing是时间片轮转简单但性能波动大MPSMulti-Process Service允许多进程共享GPU适合小模型推理。我的经验MIG适合推理服务每个实例独立显存和算力互不干扰Time-Slicing适合开发测试大家轮流用MPS适合小模型高并发但要注意显存溢出风险。生产环境推荐MIG虽然配置麻烦但稳定性最好。6.3 监控体系GPU利用率、显存、温度、功耗没有监控的集群就是盲人摸象。基础监控包括GPU利用率SM Utilization、显存占用、温度、功耗、NVLink带宽、PCIe带宽。工具上DCGMData Center GPU Manager是NVIDIA官方方案配合Prometheus和Grafana做可视化。我踩过的坑只看GPU利用率忽略了显存带宽利用率。有一次训练速度慢GPU利用率只有40%但显存带宽利用率90%说明是memory-bound优化方向应该是减少显存访问而不是增加算力。所以监控要全面不能只看一个指标。7. 存储与数据管道被低估的瓶颈7.1 训练数据读取为什么你的GPU在等数据大规模训练时数据读取往往成为瓶颈。如果数据在远程存储如NFS、对象存储网络延迟和带宽限制会导致GPU空转。解决方案一是用本地NVMe缓存热数据二是用WebDataset或FFRecord等格式打包小文件三是用DALI做GPU加速的数据预处理。我实测过ImageNet训练时从NFS读取原始JPEGGPU利用率只有60%转成WebDataset格式并缓存到本地SSD后利用率提升到95%。这个优化不需要改模型但效果立竿见影。7.2 Checkpoint存储大模型训练的“存档”难题大模型训练动辄几天几周Checkpoint是保命手段。但7B模型的Checkpoint约14GB100B模型就是200GB。频繁保存会拖慢训练保存太少又怕丢进度。策略一是异步保存不阻塞训练二是只保存优化器状态和模型参数不保存中间激活三是用增量保存只存变化的部分。DeepSpeed和FSDP都支持异步Checkpoint。我通常设置每1000步保存一次保存到高速SSD再异步同步到对象存储。这样即使节点故障最多丢1000步的进度恢复时间在几分钟内。7.3 数据版本管理别让数据混乱毁掉实验数据版本管理是MLOps的重要一环。没有版本管理你无法复现实验结果也无法追溯数据变更。工具上DVCData Version Control是常用方案配合Git做代码和数据的联合版本管理。也可以自己用对象存储的版本控制功能。我的经验至少要做到“实验ID-代码commit-数据版本”三者关联。每次实验记录这三个信息复现时才能精确还原。这个习惯在团队协作时尤其重要否则别人根本不知道你用了哪版数据。8. 我的学习路径与踩坑复盘8.1 按什么顺序啃AI Infra如果你是从算法转Infra建议按这个顺序先搞懂单卡显存和算力第2节再学多卡通信和并行第3节然后深入训练框架和显存优化第4节接着是推理优化第5节最后是调度和存储第6、7节。这个顺序符合“先单机、再多机、先训练、再推理”的认知规律。每学一个模块最好动手跑一个最小Demo。比如学NCCL就写个AllReduce的测试脚本看不同卡数下的带宽和延迟学vLLM就部署一个7B模型测不同batch size下的吞吐。纸上得来终觉浅Infra这东西必须动手。8.2 三个让我印象深刻的坑第一个坑以为NVLink是万能的。实际上NVLink只在同一节点内有效跨节点还是走InfiniBand或以太网。有一次我把TP8跨节点部署以为NVLink能兜底结果通信成了瓶颈。后来才明白TP必须限制在NVLink域内。第二个坑忽略PCIe拓扑。GPU之间的PCIe连接有差异有的走CPU有的走PCIe Switch。用nvidia-smi topo -m可以查看拓扑。如果GPU间通信走了错误的路径带宽可能差好几倍。这个细节在买服务器时就要注意别只看卡数。第三个坑Checkpoint保存阻塞训练。早期我用同步保存每次保存时训练停几十秒。后来改用异步保存训练几乎无感。这个优化在大规模训练时非常关键否则Checkpoint频率上不去故障恢复时间就长。8.3 后续可以深入的方向AI Infra的边界在不断扩大。几个值得关注的方向一是异构计算如何调度GPU、CPU、NPU混合集群二是绿色计算如何降低训练和推理的能耗三是自动并行让框架自动搜索最优并行策略减少人工调参四是推理服务的SLA保障如何在延迟和吞吐之间做动态权衡。我个人最感兴趣的是自动并行和推理优化。自动并行能大幅降低大模型训练的门槛推理优化则直接关系到AI应用的落地成本。这两个方向都有很多实际问题没解决值得持续投入。最后分享一个小技巧遇到Infra问题时先看日志再看监控最后才改代码。我见过太多人一上来就改配置结果问题在网卡或存储上。Infra的问题往往跨层排查时要自底向上从硬件到驱动到框架逐层排除。这个思路能帮你省下大量时间。
阅读完成 · 觉得有帮助？
