1. 先聊清楚AI Infra 到底是个什么东西我刚开始接触 AI Infra 这个概念的时候也踩过不少认知上的坑。很多人一听AI 基础设施第一反应是不就是买几台 GPU 服务器嘛或者不就是搭个 Kubernetes 集群吗。真做下去才发现这事儿远比想象中复杂而且跟传统后端基础设施的思路有本质区别。AI Infra全称是 AI Infrastructure指的是支撑人工智能应用全生命周期运转的底层技术体系。这个全生命周期不只是训练一个模型那么简单它涵盖数据准备、开发调试、大规模训练、模型评估、部署上线、在线推理、监控运维甚至包括成本治理和资源优化。换句话说从数据进来到模型对外提供服务中间所有环节依赖的硬件资源、软件平台、调度系统、网络存储、工具链全部属于 AI Infra 的范畴。我在和一个做推荐系统的朋友聊的时候他打了个比方我觉得特别贴切传统 Infra 是给一家餐厅装修后厨你只需要保证水电气通、厨具齐全就行AI Infra 相当于给一条食品加工生产线做自动化改造不仅设备要到位还要考虑原料怎么进、半成品怎么流转、质量怎么检测、废料怎么处理、产能怎么弹性调节。这套系统牵一发而动全身任何一个环节掉链子都会直接体现在模型训练速度和推理延迟上。这篇文章就是我做 AI Infra 相关知识全景梳理时的学习笔记把分散在各类文档、源码、实践分享里的核心内容整理成一条完整的认知链路。不管你是刚转岗做 ML Infra 的开发者还是团队里负责搭建训练平台的工程师亦或是算法团队里被各种环境问题折磨到怀疑人生的同学这篇文章应该能帮你把 AI Infra 的版图看清楚省掉自己从头摸索的大把时间。2. 全景拆解AI Infra 的五大核心板块AI Infra 体系庞大如果眉毛胡子一把抓很容易迷失方向。我习惯把它拆成五个相互关联但又可以独立研究的板块算力层、网络层、存储层、平台层、服务层。下面逐个说清楚每个板块解决什么问题、包含哪些核心组件、有哪些关键决策点。2.1 算力层一切性能的起点算力层是 AI Infra 的物理底座核心成员就是 GPU、NPU 这类加速卡加上承载它们的服务器整机。这个层面最直观的指标是总算力但真正懂行的人不会只看峰值算力还会关注几个容易被忽视的维度。第一个是显存容量。大模型训练和推理都是显存饥饿型任务。以目前主流的 70B 参数级别模型为例光是把参数加载进来就需要 140GB 左右的显存FP16 精度下再加上优化器状态、梯度、中间激活值单卡跑到全参微调根本不现实这也是为什么混合精度训练、ZeRO 优化器、梯度检查点这些技术会被广泛使用。选卡的时候一定要结合你的模型规模和训练策略来看显存够不够光看算力峰值是会被坑的。第二个是显存带宽。计算单元要从显存里读数据带宽决定了喂数据的速度。像 H 系列显卡在带宽上做了很大投入是因为 Transformer 这类模型的计算密度和访存密度都极高带宽低的话计算单元再强也会被饿死。如果因为省成本选了一款算力不错但带宽缩水的卡实际训练吞吐可能比预期差一大截这个账必须提前算清楚。第三个是卡间通信能力。多卡训练时梯度同步和 Tensor 并行都需要在卡之间疯狂传输数据。卡间通信走的是 NVLink 这类高速互联拓扑结构也有讲究。做 8 卡节点内部通信还好一旦跨节点通信开销会成倍增加这时就轮到网络层上场了。2.2 网络层大规模训练的隐形命脉很多人规划 AI Infra 时容易低估网络的重要性我就吃过这个亏。最开始图省事用普通的以太网跑多节点训练结果扩展性一塌糊涂加机器不线性提速反而通信瓶颈越来越严重。训练集群里网络主要有三种角色。第一种是计算网络也就是 GPU 之间交换梯度、同步参数用的通常采用 InfiniBand 或高性能 RoCERDMA over Converged Ethernet。第二种是存储网络计算节点要高频访问分布式存储读写数据和 checkpoint这个网络对带宽和时延同样敏感。第三种是管理网络承载 SSH 登录、监控采集、管理面通信要求相对低一些。组网架构上业界主流做法是胖树拓扑核心层和汇聚层用高带宽交换机每个计算节点通过多条链路接入保证任意两点之间的通信带宽可预期。这一步省不得因为在万卡规模下网络抖动一点点都会被放大成整体训练效率的大幅波动。做预算的时候千万别只盯着 GPU 的价格网络设备这块往往占总成本的 20% 到 30%省了后面就是要加班。2.3 存储层喂给模型的数据粮仓存储这块我见过太多团队把它当成买几块大硬盘挂 NFS就完事儿的活儿结果模型训练一跑起来全是坑。AI 场景的数据访问模式跟传统业务差别很大是典型的读多写少、大文件顺序读、高并发随机读。训练数据集动辄几个 TB 甚至几十个 TB如果放在普通的 NFS 上几百个训练进程同时打过去单点瓶颈立刻暴露IO 等待能把 GPU 利用率拖到惨不忍睹。更现实的问题是 checkpoint 写入。大模型训练一般每隔一段时间就要保存一次模型状态一个 checkpoint 可能上百 GB如果存储带宽不行保存过程会让训练停滞几分钟这种频繁的假死对大规模训练来说是灾难。目前主流的方案是上并行文件系统像 GPFS 这类老牌选手也有开源社区常用的一些高性能分布式存储方案。核心要点是数据平面和控制平面分离把元数据服务做高可用和高并发数据面用多副本策略保证可靠性。另外还有个细节训练数据的本地缓存设计。把高频读取的数据集预热到节点本地 NVMe 盘上能大幅减少训练启动和数据加载时间这个优化性价比极高。2.4 平台层把资源变成好用的服务有了算力、网络、存储这些原材料还需要一层操作系统把它们管起来按需分配给不同的训练任务和推理服务这就是平台层的职责。这个层面最常见的技术选型是 Kubernetes。Kubernetes 能成为 AI Infra 平台层的绝对主流原因是它把资源调度和应用编排这两件事做成了通用标准。AI 团队只需要把训练任务封装成容器镜像声明需要多少 GPU、多少内存剩下的调度、重启、扩缩容都由平台自动搞定。不过在 Kubernetes 上跑 AI 负载远不止部署几个 Pod 那么简单。GPU 资源需要专门的设备插件来识别和调度否则 Pod 根本看不到显卡。调度器要支持 GPU 显存维度的调度比如一张卡 80G能不能把一张卡切成多个小份分给不同的小任务用这就需要 GPU 虚拟化或显存切分方案。还有任务排队机制多人同时提任务时按什么策略分配资源是搞先到先得还是按优先级加配额这些都要在平台层解决。多租户隔离也是平台层的重头戏。算法团队之间要共享集群但开发环境要隔离数据要隔离权限要隔离资源配额要隔离。用 Namespace 加 ResourceQuota 做基本隔离用网络策略做访问控制再配上审计日志这才算是一个能放心给多人使用的平台。2.5 服务层让模型真正跑起来模型训练完不算结束真正产生价值的是把它部署成服务对外提供推理能力。服务层要解决的核心问题有两个第一个是快模型加载要快、响应要快第二个是省GPU 资源利用率要高不能一堆卡闲着。推理服务的部署架构里几个细节特别关键。一个是模型版本管理线上跑着 V1开发那边已经调好了 V2怎么平滑切换又不能中断服务这就需要设计好模型仓库和灰度发布流程。另一个是推理引擎选型同样的模型在不同引擎上的吞吐和延迟差别巨大经过专门优化过的推理后端通常能带来数倍的性能提升值得花时间去压测对比。还有一个是弹性伸缩的触发策略推理服务的流量波动往往很剧烈搞活动时流量翻倍平时又很平稳如何设定伸缩阈值不让服务频繁抖动也是一门学问。3. 核心组件逐一解析那些绕不开的关键技术全景图有了之后我把每个板块最核心的几个组件和技术单独拎出来深挖一下。这些都是在实际搭建 AI Infra 时绕不开的硬骨头把这些吃透了整个体系的脉络基本就清晰了。3.1 容器与镜像AI 负载的最小载体容器技术是整个 AI Infra 软件栈的地基。为什么 AI 场景非要用容器核心原因是环境一致性。一个训练任务依赖 Python 版本、CUDA 版本、cuDNN 版本、一堆 pip 包互相之间的兼容关系非常脆弱。容器把整套运行环境打包成镜像在任何节点上都能复现同样的环境从根源上消灭了在我机器上能跑这种经典问题。AI 场景下做镜像有一些需要特别注意的实践。基础镜像要选好推荐从官方维护的 CUDA 镜像作为底再叠加自己的 Python 环境和依赖库这样既能保证 GPU 驱动兼容性又能控制镜像体积。镜像分层有讲究把变动频繁的代码依赖放上层不太变动的系统库放下层这样迭代时能充分利用缓存构建速度快很多。还有镜像仓库的选型和管理多租户场景下要对命名空间做规划配合权限控制保证谁都能拉自己需要的镜像但动不了别人的。3.2 资源调度器集群的大脑资源调度是平台层最核心的模块也是 AI Infra 里技术含量最高的部分之一。Kubernetes 是事实标准但直接拿原生调度器跑 AI 负载会出现很多问题。一个典型问题是调度性能和规模化能力。原生调度器的调度逻辑是逐个 Pod 依次处理的当集群规模上千节点、任务提交频率又很高时调度时延就会明显增加任务排队半小时排不上卡不是新鲜事。这时候就得引入更高效的调度框架或者对调度器做定制化改造支持批量调度、抢占式调度、拓扑感知调度等增强特性。另一个问题是 GPU 资源的精细化调度。原生 Kubernetes 只能按张来调度 GPU一张卡要么整个给一个任务要么空着。但实际场景里有很多小任务一个跑数据预处理的任务只需要几个 G 显存为它占一整张卡太浪费了。解决思路是引入 GPU 显存切分能力把一张物理卡虚拟成多个小设备分配给不同 Pod。这背后涉及显存隔离、故障隔离、计算能力强隔离等多个层面的技术选型时要仔细评估方案的稳定性和性能损耗。3.3 任务编排从单机脚本到分布式训练模型训练尤其是大模型训练很少是单机单卡能搞定的几乎都是多机多卡分布式并行。任务编排层要做的就是把这些分布式训练任务的状态管理起来让它们稳定可靠地跑完。业界最通用的做法是用 Kubernetes 的 Job 或专门的 Operator 来管理训练任务。以 PyTorch 为例分布式训练通常需要启动一个 master 节点和多个 worker 节点每个节点跑在不同的 Pod 里它们之间需要互相发现、建立通信。如果手动管理这些 Pod 的生命周期出错概率太高了。有了 Operator 之后你只需要声明任务类型是 PyTorchJob填好副本数、镜像、资源需求剩下的创建、监控、异常重启都由它自动处理。任务编排和调度结合起来还有个关键点就是弹性训练。训练过程中某个节点挂了Kubernetes 会自动把它的 Pod 重新调度到别的机器上拉起但这跟分布式框架之间的配合有关系。以 AllReduce 架构为例任何一个节点挂掉整个训练任务就得重来。现在业界有一种趋势是把训练任务设计成支持弹性容错的模式比如某个节点挂了只触发局部数据并行组的重新分配而不影响整体任务这样能把硬件故障带来的损失控制到最小。3.4 监控与观测不做睁眼瞎AI Infra 的监控体系和传统 IT 监控有很大区别既要看底层硬件的健康状态又要看上层训练的收敛情况链路长、维度多、数据量大。硬件层面需要关注 GPU 的温度、功耗、显存使用率、卡间通信带宽。这些数据可以通过标准接口直接采集采集频率要够高才能捕捉到瞬时异常。软件层面关注队列里任务排队时长、GPU 利用率、训练吞吐每秒处理的样本数、模型 loss 曲线。其中 GPU 利用率是个很有意思的指标不是越高越好任务之间频繁切换反而会把利用率刷高但实际吞吐下降要结合 effective throughput 综合判断。日志和追踪是排查问题的左膀右臂。训练任务跑挂了第一件事是看日志所以要保证日志能集中收集、快速检索、按任务聚合。链路追踪在推理服务场景特别有用一个请求经过网关、鉴权、模型推理、后处理等多个环节哪一步慢了一眼就能定位。监控的价值不在于能看而在于能预警和能排查做告警规则时一定要结合自己的业务场景宁可规则少而精也不要一堆无效告警把真正的信号淹没掉。4. 从零搭建一套 AI Infra我的实操复盘理论讲再多不如动手做一遍。这一节我完整复盘一次从零搭建一套面向中小规模团队约 20 人的 AI Infra 的过程。这个规模很适合作为学习参考麻雀虽小五脏俱全覆盖了大多数核心模块。4.1 资源规划和硬件选型实录先说明一下这个方案建立在预算有限、不考虑自建机房的前提下以租用物理服务器的方式在数据中心部署。团队要做的事情包括微调几个开源大模型、跑一些日常的训练实验、给内部业务提供模型推理服务。硬件是这套系统的成本大头选型思路是控制节点和数据节点尽可能复用计算节点单独规划。最终敲定的配置是 10 台计算节点每台双路 CPU、512GB 内存、8 张 GPU 卡这个配置是为了同时满足训练和推理的算力需求。管理节点用 3 台中等配置的服务器做高可用跑 Kubernetes 控制面和调度组件。存储这块单独规划了 3 台存储节点每台挂多块 NVMe 固态盘组分布式存储集群。网络方面计算节点之间用高速交换机构建独立网络保证多机训练时的通信带宽。这个配置的学习价值在于总量不大但该有的组件都有了每一步决策都可以推导出理由。4.2 软件栈搭建踩坑记录全公开硬件就位后的第一件事是装操作系统、配置基础环境然后是部署 Kubernetes 集群。这一步我踩了不少坑挑几个典型的说说。第一个坑是版本兼容性问题。Kubernetes 生态的组件版本之间有严格的兼容矩阵尤其是 kubelet 和容器运行时之间、控制器和 API Server 之间。第一次装的时候没仔细核对版本装完发现节点一直处于 NotReady 状态排查了很久才发现是容器运行时版本太新和 kubelet 不兼容。后来我养成了习惯装任何组件之前先查官方兼容性文档锁定一套经过验证的版本组合。第二个坑是 GPU 设备插件的部署。装完 Kubernetes 后节点上并没有自动出现 GPU 资源需要在每个计算节点上部署 NVIDIA 的设备驱动、容器运行时和对应的 Kubernetes 设备插件。这里有个很容易忽略的细节设备插件是以 DaemonSet 方式部署的它必须在 GPU 驱动装好之后才能正常工作如果先部署插件后装驱动插件会起不来需要重新创建 Pod 才能恢复。软件栈的基本流程是先装操作系统和 GPU 驱动再装容器运行时和 Kubernetes然后部署存储方案、监控组件、日志组件最后部署训练任务编排组件和推理服务组件。每一层之间有依赖关系顺序不能乱否则会引发连锁反应。4.3 第一个训练任务跑起来的完整过程平台搭好后我拿一个小规模的图像分类训练任务做了全链路验证。这个任务的数据集不大模型也比较小非常适合用来测试平台功能而不是烧 GPU。整个过程是这样的先构建一个包含训练代码和依赖的容器镜像推送到镜像仓库。然后编写一个训练任务的声明文件指定使用 2 个 worker 并行训练每个 worker 申请 1 张 GPU。提交任务后平台的调度器把任务调度到有空闲 GPU 的节点上自动拉取镜像、创建 Pod、启动训练进程。通过日志页面能看到训练输出通过监控面板能看到 GPU 利用率的实时曲线。这一步验证通过后整个平台的核心链路就走通了。在这个过程中我特别记住了一个教训任务里的代码日志一定要打到标准输出不要只写到文件里。因为日志组件收集的是标准输出如果代码把日志写到容器里的文件Pod 一旦被重新创建日志就全丢了。这个看似无关紧要的小习惯在实际排查问题时会救你一命。5. 训练任务的全生命周期管理实践平台搭起来只是开始真正考验功力的是把训练任务管好。这一节聊训练任务从提交到结束的完整生命周期里那些容易被忽视但影响巨大的细节。5.1 提交前资源预估与队列规划训练任务提交之前最重要的是搞清楚这个任务需要多少资源。资源预估不是拍脑袋而是根据模型参数量、数据量、batch size、并行策略综合计算出来的。比如一个 7B 参数的模型如果用全参数微调单卡显存基本扛不住必须拆到多卡甚至多机。这就要算清楚是用流水线并行把模型层切到不同卡上还是用数据并行每张卡放一份完整模型还是用张量并行把矩阵计算拆开。不同的并行策略资源需求和通信开销完全不同。任务提交方式和排队机制也要提前规划好。多人共用集群时如果没有排队机制大家同时提交任务会把资源一抢而空后面提交的只能干等。合理的做法是引入队列系统任务不是直接提交给 Kubernetes而是先进入一个任务队列由队列控制器按预设的策略先到先得、优先级抢占、按项目配额决定何时真正调度。这样资源分配有章可循不会一团乱麻。5.2 运行中做对这几件事让任务更稳任务跑起来之后不是撒手不管就完事了。我总结了几个有经验的人都会做的实操细节。第一是 checkpoint 保存策略。大模型训练动辄几十个小时中间随时可能出故障如果不定期保存 checkpoint一挂就前功尽弃。checkpoint 的保存频率需要权衡太频繁存储 IO 占用大、训练变慢太稀疏故障恢复时丢失的进度太多。我的经验是在训练稳定期可以适当放宽保存间隔但在学习率调整、数据分布切换这些关键时刻一定强制保存一次这些节点往往是模型变化最剧烈的地方。第二是日志的可观测性。训练日志除了让开发者看报错信息更重要的价值是提供远程诊断的依据。日志里要包含关键指标的信息loss、学习率、吞吐量。这些指标不是随便打打要格式化输出方便脚本自动解析和绘图。很多训练问题都是渐进出现的loss 在某个区间缓慢攀升如果不做可视化监控等注意到的时候往往已经跑偏很久了。第三是故障自愈设计。任务挂了不可怕可怕的是挂完没人管白白浪费时间。Kubernetes 本身提供了重启机制Pod 崩溃会自动重新拉起。但分布式训练任务的故障处理要更复杂单个 worker 挂了是只重启它自己还是整个任务回滚到上一个 checkpoint 重新开始这需要结合训练框架的能力和平台配置统一考虑。高可用方案不是越复杂越好关键是和训练框架的容错能力匹配。5.3 结束后资源回收与成本核算训练任务跑完后的资源清理是个容易被忽略但影响集群健康度的环节。任务结束后如果相关的存储卷、日志、临时文件不清理磁盘空间会被慢慢蚕食。我见过不止一次因为磁盘写满导致新的任务调度失败的情况排查到最后全都是历史任务遗留的垃圾文件。成本核算是平台运营里躲不开的话题。每个任务消耗了多少 GPU 时、多少存储空间、多少网络流量这些都要能算清楚。核算的目的不是给谁找麻烦而是给团队做资源规划提供依据。比如发现某个类型的实验平均每个跑 20 个小时 GPU 时就能评估这块业务在总预算中的占比是否合理进而决定是否要优化实验设计或改用更高效的训练方式。6. 推理服务化从训练完成到稳定上线模型训练完接下来的关键一跃是把它变成稳定、高效的线上服务。这一节聚焦推理部署的实操经验这块踩坑比训练环节更多也更贴近生产环境。6.1 推理架构的核心决策点部署推理服务时第一个要决策的是推理引擎。同一个模型在原生深度学习框架里直接做推理和经过专门推理引擎优化之后性能差距可以达到数倍。这类引擎在算子融合、显存管理、批处理策略上都做了大量优化。选型时不要只看基准测试报告里的数字最好拿自己的真实模型和真实请求流量做一次压测对比。第二个决策点是并发和批处理策略。推理服务的请求到达模式是不均匀的有的时段请求稀疏有的时段突然洪峰。GPU 推理有个特性单条请求时延低但吞吐也低把多条请求攒在一起做动态批处理吞吐能大幅提升。合理设置最大批处理大小和最大等待时间是推理服务调优的核心手法。第三个决策点是冷启动问题。新拉起的推理实例需要从存储加载模型文件到显存这个过程可能耗时几十秒甚至几分钟。如果流量突增触发了扩容新实例要很久才能就绪这段时间请求会大量超时。解决方案无非几种预先设置最小副本数防止burst、用模型预热技术加速加载、或者在流量低峰周期提前做模型的热缓存。具体选哪种要看业务对延迟的敏感度。6.2 推理服务的高可用与弹性策略推理服务直接面对业务流量稳定性要求比训练任务高一个量级。高可用层面至少要做两件事。第一是多副本部署在多个节点上避免单点故障。副本之间无状态请求可以均匀分摊任何一个节点出问题流量自动切到其他副本。第二是健康检查要内行不只是检查进程在不在而是检查服务是否真正能正常处理请求。做法是暴露一个专门的健康检查接口返回有价值的业务状态信息让负载均衡器基于真实状态做流量切换。弹性伸缩层面核心是选对伸缩指标。CPU 利用率在推理场景里不是好指标因为 GPU 推理的性能瓶颈在显存带宽和计算核心CPU 可能只有个位数的利用率但 GPU 已经打满。更合理的伸缩指标是 GPU 利用率、队列深度、请求延迟。伸缩策略还要注意最小冷却时间的设置避免请求抖动时服务副本数也跟着剧烈震荡这会让整个系统的稳定性变差。6.3 灰度发布与模型更新线上模型不是一成不变的新版本要上线旧版本要退役这个过程处理不好就会引发线上事故。我在实践中养成的习惯是每次模型更新都走正式发布流程哪怕只是调了几个超参。具体做法是新版本模型和旧版本同时部署通过流量分配机制把一小部分流量切到新版本上观察错误率和延迟表现确认无误后再逐步把流量全部切过去。切换过程中要持续关注监控指标一旦发现异常能立刻回滚。这套逻辑跟互联网应用常见的灰度发布思想一致但落地时有一些 AI 特有的细节新旧模型在同一个推理服务实例里做热切换会涉及显存的管理和释放做得不好会发生显存碎片化导致新模型加载失败不同版本的模型依赖的推理引擎版本可能不同升级关联要一起考虑。7. 实战避坑AI Infra 高频问题排查手册最后这部分我把这些年遇到的高频问题整理成一份排查速查表每个问题都附上典型的排查路径和我的个人心得。这些问题未必每个人都会遇到但只要做 AI Infra大概率会碰到其中几个。7.1 GPU 资源相关的常见问题问题一任务调度不上去一直处于 Pending 状态。第一件事是查资源是否充足看集群里有没有空闲的 GPU、显存是否足够、有没有配额限制。第二件事查调度器日志看调度失败的具体原因是什么。很多时候问题是节点有 GPU 但显存不足因为多任务共享节点时显存量比卡数量更容易成为瓶颈。问题二任务在容器里看不到 GPU 设备。这个问题的原因通常是容器运行时没有启用 GPU 支持或者设备插件没有正常工作。先确认宿主机的 GPU 驱动是否正常再看容器运行时的配置是否正确最后检查设备插件的运行状态。排查链路不算长但每一层都可能出问题。问题三GPU 利用率忽高忽低吞吐上不去。这个问题的根源基本不在 GPU 本身而在数据供给链路。最常见的情况是数据加载太慢GPU 在等数据。排查思路是看数据加载线程的耗时看存储系统的 IO 延迟看数据预处理是不是在 CPU 上形成了瓶颈。7.2 分布式训练相关的常见问题问题一多机训练时 NCCL 通信超时或报错。这是分布式训练里最常见也最让人头大的问题。排查顺序通常是先看网络连通性节点之间能不能互相 ping 通再看网络性能节点间通信带宽是否达到预期再看通信库的报错信息确定是拓扑问题还是网卡问题。有次排查了半天最后发现是一台机器的网卡固件版本偏旧导致通信性能不稳定属于很隐蔽的硬件问题。问题二训练过程中某个节点挂掉整个任务崩溃。前面提到过AllReduce 架构对节点故障很敏感。遇到这类问题短期靠平台自动重启任务换回进度长期要靠训练框架的容错能力升级。实操中还有一个临时缓解手段在训练脚本里加上异常自动重启和恢复机制虽然不一定能完全无缝但至少能把人工干预成本降下来。问题三多机训练性能不如单机加机器反而变慢。这是典型的通信瓶颈问题计算时间被通信时间掩盖了。大模型里张量并行对通信带宽非常敏感如果网络条件不够好通信开销会超过并行带来的计算加速收益。解决思路是检查网络配置确认计算节点的网络是否跑在预期速率同时审视并行策略是不是把通信量大的并行方式用在了不适合的场景。7.3 存储与数据相关的常见问题问题一训练时数据加载特别慢GPU 大量空闲。前面提到过这是最常见也最好解决的一类问题。先用缓存把数据集里的高频热点数据放在本地 NVMe 盘上再检查数据读取的格式和预处理逻辑是不是有冗余计算。数据格式的选择也很有讲究像 TFRecord、WebDataset 这样的大文件顺序读取格式比大量小文件随机读取的效率高得多这背后是机械硬盘和分布式文件系统对小文件的 IO 处理天然不友好的原理。问题二checkpoint 保存非常慢训练频繁卡顿。checkpoint 写入本质上是大文件写操作慢的原因通常有两个存储系统写入带宽不够或者写入路径设计不合理。优化思路包括把 checkpoint 先写到节点本地盘后台异步同步到集中存储或者把 checkpoint 按分片并行写入充分利用存储集群的写带宽。问题三磁盘空间被莫名占满。排查方法很简单按目录统计空间占用一层层往下找。通常会发现是历史任务的日志、临时文件、镜像缓存堆积导致的。正则式的清理脚本很有必要但更重要的是在平台层建立自动清理机制比如日志定期轮转、临时文件生命周期管理、镜像仓库定期清理无用 Tag把问题消灭在源头。8. 最后说几句实在话说实话AI Infra 这个领域范围太广了单靠一篇文章不可能覆盖全部细节我这篇笔记也只是把整体框架和关键节点梳理出来给想入行的同学一张地图、给已经在做的人一些可参考的实践思路。学 AI Infra 有个很深的感触别一头扎进底层硬件细节里出不来也别只飘在上层平台概念上空谈。最好的路径是上下游都摸过一遍知道 GPU 驱动的安装方式也懂训练任务怎么编排会看网络拓扑图也写得来调度器的配置。这个领域的知识体系是T字形的横线是整个体系的广度竖线是自己主攻方向上的深度。先把横线拉起来再慢慢挖竖线是我自己觉得比较舒服的学习节奏。如果你打算动手搭一套属于自己的 AI Infra不用一上来就追求万卡集群先从两三台机器开始把容器化、调度、存储、监控这条链路完整跑一遍再逐步扩展规模。过程中的坑会很多但每踩一个坑你收获的经验都比十篇文档来得扎实。这套体系真正跑通的那一刻你会发现自己对整个 AI 技术栈的理解已经跟以前完全不同了。