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 或高性能 RoCE（RDMA 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 技术栈的理解，已经跟以前完全不同了。
