如果你和我一样有过一个模型跑了半个月发现显存碎片导致训练中断或者花了大几千卡时算力却被权限和排队浪费了一半的经历你会理解为什么AI Infra现在成了很多团队最头疼也最值得投入的地方。今天这篇笔记算是我过去一段时间梳理AI基础设施知识的一份全景式复盘从GPU集群、数据管道、调度平台到成本治理尽量讲清楚每条线上有什么、为什么、怎么落地。适合刚接触分布式训练的同学也适合已经在维护训练平台但想系统整理知识体系的工程师里面的经验都是我实际踩过坑之后沉淀下来的。1. AI Infra 的边界与全景地图1.1 AI Infra 不只是 GPU 机房很多人提到AI Infra第一反应是买卡、装机、跑起来。但真正把模型训练和推理跑得又稳又省事情远不止硬件采购这么简单。我的理解是AI Infra是为了支撑人工智能模型开发、训练、部署和持续迭代而存在的整套基础能力它至少包括算力资源、网络拓扑、存储与数据管理、容器化与调度、训练框架适配、推理服务网关、监控告警、成本计量等若干层。每一层单独看都不算新鲜但组合在一起就成了决定模型上线速度的关键。打个比方模型算法像一辆赛车AI Infra是赛道、维修站、加油系统还有调度中心。赛车发动机再好如果赛道经常堵车、维修站安排不合理比赛一样赢不了。放在实际业务里模型效果再优秀如果数据读不出来、显存不够用、显卡利用率低、排队等不到资源最终就是论文里的指标和线上实际的差距。所以我在梳理这份笔记的时候刻意把它当作一张地图而不是一叠零散知识。先搞清楚边界再往里面填细节。AI Infra的边界大致划在“模型算法之下业务应用之上”。模型训练代码和推理业务属于上层底层的物理机、虚拟化、网络、存储、调度以及为了训练和推理而抽象出来的平台服务都属于Infra的范畴。如果某天你发现一条数据链路从日志到训练样本需要十几个小时或者GPU利用率总是忽高忽低问题大概率出在Infra而不是模型代码本身。1.2 一条AI链路里的基础设施分工为了把全景地图具体化我习惯用一条典型的端到端链路来拆解。假设团队要训练一个中文文本生成模型从数据到最终上线会经过这样几个大环节数据采集与清洗原始日志或语料入库做去重、过滤、脱敏生成统一格式的训练样本。这一步的基础设施是数据管道与存储系统。数据预处理与分发把样本打乱、切分、重采样转成适合框架读取的格式再放到训练集群能高效访问的位置。这里牵涉到对象存储、并行文件系统、分布式缓存、数据加载器。分布式训练集群多机多卡协同训练每张卡负责一部分数据和模型分片通信网络承担梯度同步和参数交换。这里包括GPU/NPU、高速网络、RDMA、并行策略、弹性容错。模型产物管理训练过程中定期保存checkpoint训练结束后做模型评估、量化、蒸馏推到模型仓库。在线推理服务模型加载到推理引擎对外提供接口根据请求量做弹性伸缩和批处理。这里涉及推理框架、网关、动态批处理、显存管理。可观测与运维把集群状态、作业日志、性能指标、成本账单统一采集和展示支撑排障和优化决策。你会发现这条链路上任何一环慢一拍整个模型的迭代周期就会被拉长。所以AI Infra的自然属性是“系统性的”不能像以前写单机脚本那样头疼医头。做全景学习笔记本质上是建立这种端到端的系统观。有了这个骨架后面钻研具体技术时才知道它到底在解决链路哪个位置的问题。2. 从硬件到集群算力基础设施选型与实操2.1 算力芯片、服务器与互联拓扑的搭配思路算力基础设施最核心的资源是加速卡目前主流的方案是GPU也有不少场景在尝试专用AI芯片。选型的时候我建议不要只盯着一张卡的浮点算力而是要连服务器整机、卡间互联、跨机网络一起看。因为实际训练中单卡算力只是理论峰值真正让你模型跑得快的是“集群有效算力”也就是考虑通信开销和资源调度损耗之后的数据。这张表记录了我常用的对比维度对比维度需要关注的内容我的经验加速卡性能单卡算力、显存容量、显存带宽、功耗显存容量往往比算力更早成为瓶颈尤其是长文本和大Batch训练单机拓扑卡间互联带宽、PCIe通道、NVSwitch/NVLink拓扑单机内8卡通信是否全连接决定单机训练效率跨机网络InfiniBand、RoCE、以太网速率千卡规模时跨机通信决定扩展效率不能只看带宽还要看延迟供电与散热单机柜功率、风冷/液冷、噪音高功率密度下散热不到位会触发降频算力直接打折整机搭配上通用经验是一台机器放8张加速卡CPU核心数和内存容量按卡的显存和型号来匹配。比如显存密集型任务需要更多CPU核心做数据预处理和算子下发一般8卡服务器建议CPU逻辑核数不小于卡数的一半内存不少于512GB。网络方面单机内卡间通过NVLink这类高速总线互联跨机之间用RDMA网络。为什么这么复杂因为分布式训练每迭代一次都要做梯度同步通信数据量大、频次高。以AllReduce操作为例如果跨机走传统以太网并经过CPU转发延迟和丢包会让千卡集群的加速比变得很难看。我自己做过一次简单测试同样的通信数据量走了RDMA之后集合通信时间能缩短一半以上。训练显存的估算也没有想象中那么玄。粗略的公式是训练时消耗的显存大约等于“模型参数占用的空间优化器状态占用的空间梯度激活值”。以一个7B参数规模的模型为例如果按BF16格式保存模型权重光权重就是14GB再加上Adam优化器的状态通常一阶、二阶动量加主权重是参数量的十几倍甚至更高不做任何显存优化手段时单卡很容易爆显存。这也是为什么现在分布式训练普遍用ZeRO、FSDP等策略把参数和状态切到多张卡上。实操中我的建议是先做一次最小化单机实验用nvidia-smi和训练框架的profiler观察显存占用曲线确认激活值和通信缓冲区占了多大再决定要不要买更大显存的卡不要一上来就按理论峰值去买。算力预算和物理资源的平衡必须用实际负载来校验。2.2 千卡集群搭建中容易翻车的三件事搭建多机集群的时候最容易被忽略的往往不是服务器本身而是环境配置。我第一次搭集群机器上架后跑单机多卡训练一切正常一上分布式AllReduce就变成龟速。查了半天发现是跨机网络的RoCE优先级和流控没配好拥塞导致大量丢包重传。后来整理了一套检查顺序很大程度上避免了这类问题。第一网络配置。RDMA网络需要开启正确流控并保证拥塞通知在交换机上生效。检查方法包括看端口的MTU是否一致、PFC/Congestion Control配置是否正确、是否有交换机端口drop。最简单的先跑一个通信测试工具比如nccl-tests看看AllReduce带宽是否稳定。如果性能忽高忽低大概率是网络拥塞或流控问题。第二电源与散热。GPU服务器功率密度高一个机柜放满之后很容易突破机房单柜供电上限。我踩过供电不足导致GPU识别不到或训练中途宕机的坑。上架前一定要和机房确认供电标签做好设备功率清单。散热也一样GPU长时间高温会主动降频跑出来的性能可能只有标称的七成。训练前观察温度曲线如果超过温度墙一大截优先查风扇策略和机房空调。第三拓扑识别和资源绑定。多机集群中服务器之间的物理网络拓扑不一定和操作系统看到的顺序一致。分布式训练时如果不把进程和GPU、网卡做绑定通信流量可能全挤在同一条路径上。我建议先用系统工具检查当前节点GPU的NUMA亲和性、网卡所在位置再在启动命令里设置好环境变量让每个进程使用距离最近的GPU和网卡。不要小看这一步在千卡规模下拓扑感知调度带来的性能差异能超过20%。3. 数据与存储让数据管线不拖后腿3.1 数据预处理分发链路的核心节点模型训练里有一句经典吐槽GPU在等数据CPU在生产数据。数据链路设计不好再贵的加速卡也跑不出应有的吞吐。我把这条链路拆成几个关键节点每个节点都有自己的瓶颈。原始数据集打包大量小文件是存储系统的天敌。比如几百万张图片每张几十KB如果直接以文件形式放在普通存储上训练时随机读取的速度会非常慢。我处理过一个小文件严重的案例单节点读取速度只有几十MB/s后来把样本打包成WebDataset这种大文件格式配合索引顺序读取速度提升了十倍以上。所以进入训练链路前最好把数据整理成适合顺序读的大文件或者先做一次数据预处理转换。分布式缓存当多机多卡同时读数据源存储的吞吐量可能成为瓶颈。最直接的手段是加一层分布式缓存常用工具包括Redis或更聚焦文件场景的内存文件系统。训练前把高频数据预热到本地NVMe盘或分布式缓存中让数据访问尽量发生在离计算近的地方。数据访问路径越短IO延迟越低越不容易让GPU等待。数据加载器参数很多人调模型的时候忽视DataLoader其实这里有很多可以优化的空间。num_workers太少CPU来不及生产数据prefetch_factor太小内存队列会空转pin_memory没有打开数据从CPU传到GPU要多一次拷贝。按我的经验数据加载的优化顺序是先开大num_workers到CPU核心数附近再调大prefetch最后考虑用共享内存做IPC。每一步都要实测不要盲调。还有一个容易被忽略的问题是数据版本和校验。训练数据经常迭代样本分布变化会直接影响模型效果。我见过团队训练到一半发现某个业务数据重复了多个batch导致模型过拟合。规范做法是给每个数据集一个版本号或者内容哈希训练任务里记录数据版本出现异常时可以快速回溯。数据一致性是Infra里最基础也最容易欠债的部分越早做越省心。3.2 存储选型与缓存策略的实操笔记存储选型没有银弹只有“这个场景下合不合适”。我的通用判断方法是数据集和处理临时文件用本地盘或高速缓存大规模样本归档用对象存储需要高吞吐顺序读的多机训练用并行文件系统或分布式缓存。经常有人问我为什么不建议所有数据都放对象存储。对象存储的优势是容量大、成本低、可用性高但小对象随机读性能一般而且训练场景的访问模式是大量并发顺序读对象存储的元数据开销会很重。并行文件系统类似Lustre这类虽然性能好但运维成本高需要专业的人盯。折中的方案是“热数据缓存冷数据归档”用高性能缓存层承接训练突发流量把不常访问的数据下沉到低成本存储。Checkpoint的存储策略也值得单独记一条。训练过程中定期保存模型状态如果每个节点都把checkpoint文件写到同一份网络存储很容易出现IO抖动。我踩过checkpoint写入把训练数据读取带宽抢占的坑导致训练波动剧烈。后来处理方法是把checkpoint放到独立的高性能存储目录并且开启异步保存写checkpoint不阻塞训练迭代。另外要保证checkpoint的原子性先写临时文件再rename避免意外中断导致文件损坏。恢复训练的时候可以先读checkpoint到本地再加载减少网络存储压力。缓存策略上我的经验是缓存KV要显式管理不要依赖系统默认Page Cache。因为训练数据往往是几百GB甚至TB级别Page Cache很容易被冲掉下一次读取又要重新走网络。比较好的模式是训练开始前预热缓存训练过程中监控缓存命中率如果命中率连续偏低就调整缓存容量或更换存储方案。4. 训练与推理平台调度、镜像与弹性伸缩4.1 算力调度的主流方案与选型依据算力到了集群规模之后裸机管理近乎不可行容器化加调度器就成了标配。目前业界事实标准是Kubernetes但你不会直接在原生K8s上跑深度学习任务至少要补上三样东西GPU资源感知、队列配额管理、任务生命周期管理。原生K8s在处理GPU调度时很粗糙默认只是把显卡当作一种资源按张卡的数量做申请和分配。而现实中的GPU任务需求差异巨大一个推理服务可能要0.5卡或者0.25卡一个分布式训练任务可能要几十张卡而且这些卡最好在拓扑上连续尽量避免跨交换机通信。主流做法是对K8s做调度扩展让调度器能看到GPU的型号、显存、健康状态、NUMA拓扑再按binpack或spread策略分配。分布式训练还有一个特殊问题叫Gang Scheduling即一个训练任务的所有节点必须同时获得资源才能开始如果只分配到一半任务只能等待甚至会导致资源碎片加剧。就好比一群人要上一个只能集体进入的电梯如果只有一半人上去了整个电梯都空等。为了一站式解决这类问题社区出现了Kueue、Volcano这类调度组件。选型的时候我建议把团队规模和技术栈纳入判断如果本身已经比较依赖K8s生态就用K8s原生扩展如果对调度策略要求极其复杂可以考虑单独部署调度器。平台层还要把队列和配额抽象出来。不同团队共享一套集群时如果没有配额可能出现一个团队把资源占满另一个团队永远等不到卡。设置合理的Queue和ResourceQuota再加优先级抢占才能在资源有限的情况下保证核心训练任务先跑。我个人还会给每个任务加超时限制长时间卡住的任务自动释放资源避免故障任务占着茅坑不拉屎。4.2 平台建设中的镜像、队列与弹性细节容器化带来的一个好处是环境一致性但也带来镜像管理问题。不同框架版本、CUDA版本、Python依赖经常冲突。我的习惯是尽量用基础镜像每次训练时挂载依赖的方式而不是把整个世界塞进一个镜像。镜像越胖拉取越慢节点启动越慢。给镜像仓库配置一个本地缓存或镜像加速器能显著减少节点扩容时的等待时间。推理侧和训练侧的平台逻辑不太一样。训练平台追求高吞吐和稳定性推理平台则要兼顾延迟和成本。在线推理通常要走网关–推理引擎–模型仓库的路径。推理引擎里最关键的参数包括最大Batch、最大并发数、最长等待时间。动态批处理Dynamic Batching能把多个小请求拼成大Batch一起跑提升GPU利用率但同时会增加延迟所以需要根据业务容忍的p99延迟来调。还有人经常忽略模型加载时间如果冷启动时模型需要几十秒才能加载完那么弹性扩容就不能等CPU满了才扩而要提前预扩容或提前加载模型副本。弹性伸缩不是只有K8s的HPA一种做法。GPU推理的弹性伸缩比较特殊因为显存是稀缺资源一个节点可以塞下多少实例不只是看CPU还要看显存。HPA按QPS或者GPU利用率做指标缩放之外最好再结合请求队列长度来触发。我自己比较推荐按队列深度扩缩容因为队列深度能真实反映积压的请求量比单纯的CPU忙闲更直接。此外推理服务还要考虑显存碎片化。连续调度大量小模型后显存可能被碎片占满但总利用率不高。解决手段是模型分组和实例合并或者定时做GC。平台层的坑在于如果只盯着单个实例的指标很容易忽略整体碎片化这一点需要平台运维同学定期看集群级别的显存分配图。5. 可观测性与成本治理5.1 可观测性三件套指标、日志、链路追踪AI Infra的可观测性比普通微服务更复杂因为指标来源多、数据维度多还要把物理资源状态和训练作业状态关联起来。我建议把基础设施监控做成三件套指标、日志、链路追踪。指标层面除了常规的CPU、内存、磁盘、网络还要格外关注GPU相关的指标。通过DCGM这类工具可以拿到GPU利用率、显存占用、温度、功耗、SM占用率、显存带宽利用率。只看显存占用是不够的比如某些操作显存占用很高但计算很少GPU利用率反而不高这说明可能在做大量数据搬运。所以要把计算型指标和传输型指标放在一起看才能定位瓶颈。日志层面最怕的是找不到日志。容器生命周期短作业一旦失败容器被清理后日志就没了。所以训练和推理的日志必须集中收集。训练日志里除了普通的print还要记录每轮的loss、学习率、每个节点的吞吐。出现卡死时有个好习惯是先打印每个rank的心跳比如每隔一段时间输出rank编号和GPU忙碌标志这样可以快速发现是哪个节点失联。链路追踪在AI场景里会被很多人忽略其实很有效。给一个训练作业从提交、调度、拉取镜像、启动进程、读取数据、迭代训练、保存checkpoint到结束的每个阶段打上时间戳出现慢作业时一眼就能看出时间耗在哪个环节。对推理服务同样适用从客户端请求到网关、推理引擎、模型推理、响应返回链路追踪可以定位延迟高在哪个子阶段。告警配置不要只盯着“挂了才报警”。更值得关注的是慢化和漂移。比如GPU利用率从90%掉到70%可能是数据链路出现了隐性退化Loss不再下降可能是数据管道重复。这类告警需要设置不同阈值并通过历史数据做基线避免频繁误报。5.2 算力成本治理的记账方法与现实技巧AI Infra的账单往往是技术部门最大的一笔开支。很多公司不做成本治理只知道资源总在满负荷跑但不知道哪些任务花掉了大头。我的经验是把成本治理做成一门“记账”工作至少包括以下步骤。第一步给每一个资源申请打标签。标签要覆盖项目、任务类型、负责人、队列、业务线等维度。训练任务、推理服务、开发调试、数据预处理要分开统计。没有标签成本就是一种“黑盒”根本讲不清钱花在哪。第二步统计真实的资源利用率。同一个集群里跑训练和跑推理的成本结构不一样。训练任务按卡时计算推理任务按实例运行时间和QPS算单位成本。可以做一个简单的成本模型把GPU能耗、机房租金、存储占用按比例分摊。这里有个容易被忽略的点排队等待的作业虽然没在跑但可能占用了预留资源和配额产生隐性成本。所以我喜欢对排队超过一定时间的作业自动降级或提醒。第三步持续优化资源水位的低效点。最常见的是长尾任务一个推理服务为了峰值流量常年占着10张卡但平均利用率只有20%。对这种服务可以开启自动缩容或改走无服务器推理模式。另一个是开发调试环境很多人喜欢在调试时申请大规格资源然后挂着一晚上不用。解决手段是设定空闲自动回收策略比如超过30分钟没有GPU计算就自动释放。我给所有现象排了一个优先级清单从成本收益看是这样先治理“空闲未使用”的卡最浪费再治理“利用率低”的任务第二浪费最后优化“超额申请”的作业比如申请了8卡实际只用4卡。逐步治理下来集群的“有效算力成本”会明显下降这是最能看到效果的Infra优化方向之一。6. 学习路径与避坑清单6.1 给新人的一条可实操学习路径很多人问怎么系统性学习AI Infra我的回答是别先从论文读起先动手把一个模型甘愿跑起来。建议按下面这条路径推进。第一步熟悉Linux和容器基础。学会看系统资源、管理进程、打网络包理解镜像和容器的区别。用Docker把一个小模型训练脚本容器化跑通一次单机训练。第二步做一次真实的多机多卡训练。哪怕只有两台机器也值得亲手配一次分布式环境。在这个过程中你会接触到分布式训练框架的初始化、网络通信、集合通信库以及GPU资源上报。遇到通信报错时自己去查日志、找根因这一步学到的东西比读十本书都管用。第三步系统学习Kubernetes和调度。部署一个小型K8s集群学会写GPU资源请求、节点标签、调度器扩展再尝试接入一个队列调度器体验一下抢占和排队。这个阶段不用太深但要做到能看懂平台里的作业为什么被调度到某台机器上。第四步研究分布式训练框架和显存优化。看FSDP、ZeRO这类方案的设计思路自己用一个小模型在单机多卡上做显存优化对照实验。目标不是背概念而是理解为什么通信开销会增加、为什么要做模型并行、激活重计算到底省了什么。第五步扎进推理优化。跑一个推理服务压测它的延迟和吞吐尝试动态批处理和量化。如果环境允许再对比一下不同推理引擎在相同模型上的性能差异记录影响最大的几个参数。最后如果还有精力去读调度器和分布式框架的源码。AI Infra的知识网特别广与其到处看零散文章不如围绕一条主线“数据-算力-调度-服务”把自己关心的问题挨个突破。学习过程中一定要做笔记记录自己每一步的测量数据、决策理由和教训笔记本身就是你的Infra知识库。6.2 我整理的高频故障排查清单这些年在维护训练和推理平台的过程中我积累了一张比较实用的排查清单同事也经常照着查。我把它贴在下面希望能省掉你一些排查时间。现象可能原因常用排查手段GPU利用率低训练速度上不去数据加载慢、CPU worker不足、网络通信等待先看数据加载耗时和IO用profiler看算子耗时再查网络带宽显存OOM模型太大、BatchSize过大、激活值太多、显存碎片打印模型显存占用曲线调小BatchSize尝试梯度累积或激活重计算分布式训练卡死或超时某个rank失联、网卡故障、参数初始化不一致检查心跳日志看TCP/RDMA连接数用通信测试工具定位异常节点节点突然离线电源故障、驱动崩溃、内存问题查系统日志和BMC日志重启恢复检查硬件健康状态推理服务延迟飙升动态批处理参数不合理、模型加载抖动、后端CPU/GPU跑满看链路追踪压测单实例确定基准检查是否频繁扩容Checkpoint损坏写入中断、多节点同时写同一文件、存储异常开启临时文件rename保存多个版本恢复时校验文件哈希Pod可以运行但调度失败GPU资源不足、selector不匹配、污点容忍度问题查看调度器事件查看资源可分配量确认标签和污点网络性能断崖式下跌RDMA拥塞控制失效、交换机drop、PFC死锁检查端口drop计数关闭自动协商重测对比路径延迟排查时我有一个习惯先复现最小化问题再逐步扩大。比如分布式训练慢先在一台机器上测单机通信再测两台机器最后再上全集群能更快缩小范围。最后分享一个我自己的小习惯每次新接手一套AI基础设施我第一件事不是急着跑模型而是先采集环境基线记录GPU型号与驱动版本、网络拓扑和带宽、存储性能、系统关键参数把所有结果整理成一份基线文档。后续再遇到“性能变慢”“随机故障”我会拿新采集的数据和基线对比。很多莫名其妙的问题其实都是改动之后没有基线参照导致判断全靠猜。还有一个小技巧训练任务启动时把关键信息写到任务日志的第一行比如数据集版本、模型结构、BatchSize、分布式并行策略、节点数。这样问题排查时不用翻无数个提交记录一眼就知道这次跑的是什么环境。AI Infra是一个“慢工出细活”的领域稍微做一点规范化和记录能节省后面大量的重复排障时间这也是我对这份学习笔记最真切的体会。