1. 从零搭建AI Infra知识全景一个后端工程师的踩坑式学习路线这两年AI应用层卷得飞起但真正把模型跑起来、跑稳、跑便宜的那批人反而越来越稀缺。我自己是从传统后端转过来的一开始以为AI Infra就是装个驱动、跑个推理脚本结果第一次上手就被显存碎片、通信瓶颈、调度排队三连击教做人。后来花了小半年时间把整个AI基础设施的知识体系从头到尾捋了一遍形成了这份知识全景学习笔记。它不是什么官方教程而是我自己踩坑、查资料、动手验证之后沉淀下来的一张地图覆盖从硬件选型、集群组网、训练框架、推理引擎到调度平台、监控运维的完整链路。适合谁看如果你是后端、运维、算法工程师想搞清楚模型到底是怎么被伺候起来的或者你正准备从应用层往底层走这份笔记能帮你少走至少三个月的弯路。下面我按自己理解的逻辑顺序把每个环节的核心问题、关键技术和实操要点拆开讲。2. AI Infra到底在解决什么问题先搞清楚这张地图的边界2.1 一句话定义与三层结构AI InfraAI Infrastructure说白了就是让AI模型能高效训练和推理的一整套软硬件基础设施。它不像算法那样直接产出效果但没有它再好的模型也只能躺在论文里。我习惯把它分成三层来看最底层是硬件与集群层包括GPU、NPU、高速网卡、存储、机房供电散热中间是系统与框架层包括驱动、CUDA、通信库、训练框架、推理引擎、容器运行时最上层是平台与调度层包括资源调度、任务编排、监控告警、成本核算。这三层不是孤立的任何一层的短板都会成为整个系统的瓶颈。比如你GPU再好网络是千兆以太多机训练照样卡成狗调度平台再花哨底层显存管理没做好照样OOM。我刚开始学的时候犯过一个典型错误只盯着训练框架看觉得PyTorch会用就行了。结果实际部署时发现模型加载慢、推理延迟高、多卡利用率上不去问题全在框架之外。所以这份笔记的第一个核心观点就是AI Infra是系统工程不能只学一个点。你得知道数据从磁盘到显存经过了哪些环节每个环节的带宽和延迟大概是什么量级才能定位问题。2.2 为什么现在AI Infra这么热需求侧的原因很直接模型越来越大从几亿参数到几千亿参数单卡根本放不下推理请求越来越多从实验室demo到线上服务QPS和延迟要求完全不是一个量级成本压力越来越重一张高端卡几万块集群动辄几百张利用率每提升10%都是真金白银。供给侧则是硬件和软件都在快速迭代新的卡、新的互联、新的框架层出不穷知识更新速度极快。这就导致一个现象懂算法的人很多懂怎么把算法高效跑起来的人很少供需失衡自然就热了。从我的观察看AI Infra的岗位要求通常包含几块熟悉至少一种训练框架的分布式机制、懂通信原语和并行策略、会做推理优化量化、蒸馏、算子融合、能搭监控和调度。这几块不需要每样都精通但必须有一块特别深其他能串起来。下面我就按这个能力模型逐层展开。3. 硬件与集群层别被参数表忽悠看懂真实瓶颈3.1 GPU选型算力、显存、互联三者怎么权衡选卡是第一个坑。很多人只看浮点算力TFLOPS觉得数字越大越好实际上显存容量和互联带宽往往比纯算力更关键。我整理了一个简单的权衡表基于常见实践维度为什么重要常见误区显存容量决定单卡能放多大模型或batch只看算力结果模型放不下显存带宽决定数据搬运速度影响利用率忽略带宽算力再高也喂不饱卡间互联决定多卡通信效率用低速互联做张量并行通信成瓶颈算力精度FP16/FP8/BF16支持情况只关注FP32实际训练多用混合精度我的经验是先确定模型规模再倒推显存需求最后看互联。比如一个70B参数的模型FP16下光权重就要140GB单卡放不下必须多卡。这时候如果卡间互联带宽不够张量并行的通信开销会吃掉大部分收益。所以选型顺序应该是显存够不够 → 互联快不快 → 算力足不足。3.2 集群组网为什么说网络是隐形杀手多机训练时网络的重要性怎么强调都不过分。我踩过最惨的一次坑用普通以太网做多机训练理论带宽看着还行但实际有效带宽只有标称的30%训练速度比单机还慢。后来才明白分布式训练的通信模式对网络延迟和丢包极其敏感。All-Reduce这种操作需要所有节点同步任何一个节点慢整个集群都在等。常见的组网方案里高速互联如InfiniBand或RoCE是主流选择核心优势是低延迟、高带宽、支持RDMA远程直接内存访问能让数据绕过CPU直接进显存。这里的关键参数是带宽和延迟带宽决定吞吐延迟决定同步效率。我的建议是如果做大规模训练网络投入不能省否则前面省的卡钱全被低利用率吃回去。另外拓扑结构也很重要胖树、轨道优化等不同拓扑对通信模式的影响很大这个后面讲并行策略时再展开。3.3 存储与数据供给别让IO拖后腿训练时GPU利用率上不去很多时候不是算力问题而是数据供给跟不上。我遇到过一种情况GPU利用率长期在40%徘徊查了半天发现是数据加载成了瓶颈磁盘IO随机读太慢CPU预处理也慢。解决办法通常是用高性能并行文件系统、把数据预处理放到GPU或专用加速器上、用多进程/多线程预取。核心思路是让数据管道和计算管道解耦并且数据管道要能跑赢计算管道。这里有个容易忽略的点小文件太多会严重拖慢IO。我习惯在训练前把数据打包成少数大文件如TFRecord、WebDataset格式配合顺序读吞吐能提升好几倍。另外缓存策略也很关键热数据放内存或高速缓存冷数据放慢速存储分层管理。4. 系统与框架层并行策略是核心中的核心4.1 数据并行、张量并行、流水线并行怎么选这是AI Infra最核心的知识点之一。简单说数据并行是每个卡放完整模型喂不同数据梯度同步张量并行是把单层拆到多卡适合单层就很大的情况流水线并行是把不同层放到不同卡像流水线一样传递。实际大规模训练往往是三者混合叫3D并行。我自己的理解是选择依据主要是模型规模和互联条件。数据并行实现简单但显存占用不降模型大了放不下张量并行能降显存但通信极其频繁对互联要求极高一般只在节点内NVLink域内用流水线并行通信少但有气泡bubble问题需要精心设计微批次。一个常见的组合是节点内用张量并行节点间用流水线并行最外层再套数据并行。注意并行策略不是拍脑袋定的要结合模型结构、集群拓扑、互联带宽一起算。我见过有人在小带宽集群上硬上张量并行结果通信时间占了大头得不偿失。4.2 通信原语与集合通信All-Reduce为什么这么重要分布式训练里最常打交道的通信操作就是集合通信包括Broadcast、All-Reduce、All-Gather、Reduce-Scatter等。其中All-Reduce是数据并行的核心作用是把所有卡的梯度求平均。它的实现算法有Ring All-Reduce、Tree All-Reduce等不同算法在不同规模下效率不同。Ring的优势是带宽利用率高适合大消息Tree的延迟低适合小消息。理解这些的意义在于当训练变慢时你能判断是计算慢还是通信慢。我常用的方法是看通信占比如果All-Reduce耗时超过计算耗时那就要考虑优化通信比如用梯度压缩、通信重叠把通信和计算重叠起来、或者调整并行策略。通信重叠是个很实用的技巧原理是让反向传播算完一层的梯度就立刻开始通信而不是等全部算完这样通信时间被计算时间掩盖。4.3 训练框架的分布式能力对比主流训练框架在分布式支持上各有侧重。PyTorch的DistributedDataParallelDDP和FullyShardedDataParallelFSDP是常用方案DDP适合模型能单卡放下的场景FSDP通过分片参数、梯度、优化器状态来降显存适合大模型。DeepSpeed则提供了ZeRO系列优化把显存优化做到了极致还集成了流水线并行。Megatron-LM专注张量并行和流水线并行适合超大规模。我的实操建议是中小规模优先用DDP模型大了上FSDP或ZeRO超大规模再考虑Megatron风格的3D并行。不要一上来就追求最复杂的方案调试成本很高。另外要注意框架版本和CUDA版本的兼容性这个坑我踩过不止一次版本不匹配会导致各种莫名其妙的错误。5. 推理引擎与优化把模型跑快跑省的实战技巧5.1 推理和训练的差异为什么不能直接复用很多人以为训练完的模型直接拿来推理就行实际上推理有完全不同的优化目标。训练追求吞吐和收敛推理追求低延迟、高吞吐、低显存。推理时没有反向传播所以可以做很多训练时不能做的优化比如算子融合、量化、KV Cache复用等。而且推理的batch通常更小对延迟更敏感。我刚开始做推理时直接拿训练脚本改结果延迟高得离谱。后来才明白推理引擎做了大量针对性优化比如把多个小算子合并成一个大算子减少kernel启动开销用PagedAttention管理KV Cache减少显存碎片用连续批处理continuous batching提升吞吐。这些优化自己手写很难所以选对推理引擎比什么都重要。5.2 量化精度换速度的取舍量化是推理优化里最立竿见影的手段之一核心思路是用更低比特表示权重和激活减少显存占用和计算量。常见的有INT8、INT4甚至更低。量化的关键是在精度损失可接受的前提下尽量压缩。我实测下来INT8量化通常精度损失很小速度提升明显INT4则要看模型和任务有些任务掉点严重有些几乎无损。量化分训练后量化PTQ和量化感知训练QAT。PTQ简单直接对训练好的模型做校准QAT在训练时就模拟量化误差精度更好但成本高。我的经验是先试PTQ掉点严重再考虑QAT。另外要注意不是所有层都适合量化比如某些归一化层和注意力层对量化敏感可能需要保留高精度。5.3 KV Cache与批处理吞吐优化的两个关键自回归生成模型推理时每生成一个token都要用到之前所有token的Key和Value如果每次都重算计算量巨大。KV Cache就是把历史KV存下来复用避免重复计算。但KV Cache会占显存序列越长占得越多所以有了PagedAttention这种分页管理方案像操作系统管理内存一样管理KV Cache减少碎片。批处理方面传统静态批处理要等一个batch凑齐才处理延迟高。连续批处理则是一个请求生成完就立刻换下一个进来GPU利用率大幅提升。这两个技术配合起来推理吞吐能有数倍提升。我在实际部署时会先确认推理引擎是否支持这些特性再根据业务延迟要求调整batch策略。6. 平台与调度层让资源利用率从30%到70%6.1 资源调度Kubernetes还是专用平台AI任务的调度和普通微服务很不一样需要GPU资源、需要拓扑感知把通信密集的任务放到互联好的节点、需要排队和优先级、需要弹性伸缩。Kubernetes通过device plugin和调度器扩展能支持GPU调度但原生调度器对AI场景支持有限所以有了Volcano、Kueue这类专用调度器。也有公司自研调度平台。我的看法是小规模用K8s加扩展就够大规模或对调度策略有精细要求再上专用方案。关键要解决的问题包括GPU共享多个小任务共用一张卡、gang scheduling所有worker同时启动避免死锁、队列和配额管理。gang scheduling特别重要分布式训练如果部分worker起来了部分没起来会一直等浪费资源。6.2 监控与可观测性看不见就管不好AI集群的监控比普通服务复杂因为要监控的指标多GPU利用率、显存占用、温度、功耗、通信带宽、训练loss、推理延迟等。我习惯分三层监控硬件层看GPU和网络状态任务层看训练/推理进度和资源使用业务层看服务质量和成本。常用工具包括Prometheus采集指标、Grafana展示、DCGM采集GPU指标。这里有个实用技巧给每个任务打标签按任务聚合资源使用这样能快速定位哪个任务在浪费资源。另外要设置合理的告警阈值比如GPU利用率长期低于某个值就告警可能是数据瓶颈或代码问题。6.3 成本核算与利用率提升成本是AI Infra绕不开的话题。一张高端卡每小时成本不低集群规模大了浪费的都是钱。提升利用率的手段包括任务排队和抢占低优先级任务让位高优先级、GPU共享、弹性伸缩闲时缩容、混合部署训练和推理混跑填谷削峰。我见过一个案例通过混合部署和合理调度整体利用率从30%提升到70%成本直接减半。核算成本时要算总拥有成本TCO不只是卡钱还包括网络、存储、电力、运维人力。我习惯用每有效计算小时成本这个指标把浪费的部分也算进去这样更能反映真实效率。7. 常见问题与排查技巧实录7.1 训练类问题速查现象可能原因排查方向GPU利用率低数据瓶颈、通信瓶颈、代码串行看数据加载耗时、通信占比、profileLoss不收敛学习率、并行策略、数值精度检查梯度、对比单卡结果OOMbatch太大、显存碎片、缓存未释放减小batch、检查显存分配多机训练慢网络带宽、拓扑、通信算法测网络带宽、看通信时间7.2 推理类问题速查现象可能原因排查方向延迟高批处理策略、算子未融合、KV Cache看引擎配置、profile算子吞吐低batch小、并发低、显存不足调batch、开连续批处理精度掉点量化、算子替换对比原模型输出、逐层排查7.3 我踩过的几个典型坑第一个坑是版本地狱。CUDA、驱动、框架、通信库版本必须匹配否则各种诡异错误。我的做法是固定一套验证过的版本组合不轻易升级。第二个坑是显存碎片。长时间运行后显存碎片会导致明明有空闲显存却OOM解决办法是用显存池或定期重启。第三个坑是通信死锁。分布式训练时如果某个进程挂了其他进程可能一直等需要设置超时和健康检查。提示遇到问题先别急着改代码先看监控和日志定位是计算、通信、IO还是调度问题方向对了再动手。8. 学习路径与资源组织怎么把这张地图装进脑子8.1 分阶段学习建议我自己的学习顺序是先搞懂单卡训练和推理再学多卡数据并行然后学显存优化和混合并行最后学调度和运维。每个阶段都要动手跑通一个最小例子不要只看书。比如学数据并行就写一个最简单的DDP脚本观察通信行为学量化就拿一个小模型做PTQ对比精度和速度。资源方面官方文档永远是最准的但往往不够通俗。我的做法是官方文档打底配合一些高质量的工程博客和开源项目源码。看源码时不要逐行读带着问题看比如它怎么实现通信重叠的这样效率高。8.2 动手项目建议光看不动手等于没学。我建议做几个小项目用DDP训练一个图像分类模型观察多卡加速比用FSDP或ZeRO训练一个稍大的语言模型体会显存优化部署一个推理服务调优延迟和吞吐搭一个简易调度平台管理几个训练任务。这几个项目做下来整个链路就串起来了。最后分享一个我个人的体会AI Infra的知识更新很快但底层原理相对稳定。把通信、并行、显存管理这些核心原理吃透上层工具换了一茬又一茬你也能快速上手。反过来只追新工具不学原理永远在追尾巴。这份笔记我会持续更新把自己新踩的坑和新验证的方案补进去也欢迎同行交流指正。