企业官网建设流程全解析

1. 为什么我建议大家系统性梳理一遍AI基础设施

先把这个标题拆开说。AI Infra，也就是AI基础设施，这两年几乎成了技术社区里出现频率最高的词之一。只要你在做模型训练、推理部署、GPU集群管理、数据Pipeline，或者哪怕只是负责给算法同学调配资源，都会发现一个共同的现状：传统后端的基础设施经验，很多地方已经不适用了；而算法侧的思路，又解决不了工程层面的效率问题。中间这块灰色地带，恰恰是AI Infra要回答的核心命题。

我最早接触这个概念的时候，以为它就是"服务器加GPU加K8s"，后来踩了不少坑才明白，真正的AI Infra至少覆盖了计算、存储、网络、调度、数据流、模型服务化、可观测性这七八个子领域，而且每个方向都有自己独特的约束条件。比如训练任务和普通Web服务完全不同，它对吞吐、延迟、容错的要求千差万别，通信模式以集合通信为主，数据读取又是大文件连续读加小文件随机混读，整个技术栈跟传统互联网后端是两套逻辑。

这篇学习笔记，就是把我自己从零搭起来的一整套AI Infra知识框架沉淀下来，按模块拆开讲清楚。它能帮你做什么？如果你刚入行，可以拿它当知识地图，知道该从哪入手；如果你已经在做相关岗位，可以对照查漏补缺；如果你是团队负责人，可以拿它来设计内部培训的课程主线。总之，这是一篇面向真实工程场景的整理，不是名词堆砌。

另外说个题外话，这类知识光看文档是学不深的。我强烈建议你在读这篇文章时，旁边放一台有GPU的机器，哪怕是云上租一台最小的实例，边读边验证几个关键点，效果会好非常多。

2. 构建AI Infra的知识全景：两条主线加一张地图

2.1 纵向主线：从数据到模型服务的完整链路

学AI Infra最忌讳的就是东一榔头西一棒子。今天看容器调度，明天看RDMA，后天的兴趣又跑到推理优化上去了，最后什么都了解一点，但串不起来。我自己的经验是，先建立一条纵向主线，这条主线就是一条数据从原始素材变成线上服务的完整通路。

你可以把任何AI业务画成一条流水线。最开始是数据采集和清洗，原始数据进入对象存储，然后经过预处理和特征工程，生成训练样本集；样本集通过数据加载器喂给训练集群，训练集群里有成百上千块GPU在做分布式并行计算，期间会产生模型权重、日志、指标；训练完成后，得到的基础模型要经过评估、压缩、量化和格式转换，最终部署成推理服务，对外提供预测能力。这整条链路里每一步都涉及基础设施的选型和设计。数据要不要缓存、训练要不要多机多卡、推理要不要动态批处理，都是在这条链路的约束下做取舍。

把这条纵向链路刻进脑子之后，你会发现所有知识都不是孤立的。比如你学并行文件系统的时候，会自然想到它服务的对象是数据加载器；你学调度器的时候，会自然想到训练作业的生命周期；你学推理加速的时候，会自然想到它跟训练精度之间的微妙关系。

2.2 横向主线：计算、存储、网络、平台四层协同

纵向链路决定了业务的完整流程，但你真正要去搭建和维护的系统，还是得靠分层来拆解。我习惯把AI Infra横向分成四个层次：计算层、存储层、网络层、平台层。

• 计算层负责提供算力，主要涉及GPU、AI加速芯片的选型，异构计算的管理，显存分配和调度，以及容器的算力隔离。
• 存储层负责解决数据怎么放、怎么读、怎么缓存的问题，从底层的文件系统，到中间的数据缓存，再到上层的数据版本管理，都在这一层。
• 网络层解决的是分布式场景下数据怎么传输的问题，包括物理网络、RDMA、集合通信库、拓扑感知调度等。
• 平台层是把前三层封装成产品能力的地方，包括任务编排、弹性伸缩、监控告警、权限管理、模型部署平台等。

四层之间不是互相独立的。存储层设计得不好，网络再好也没用；网络拓扑不合理，GPU利用率直接跌一半；平台层调度策略不聪明，底层资源再充足也发挥不出来。所以我在学习的时候不求每个方向都钻研到算法级，但每个方向的原理和关键参数都得清楚，因为它们之间需要配合的地方太多了。

2.3 一张可以直接照抄的知识清单

为了不让自己迷失在碎片信息里，我把完整知识地图整理成了一个清单，后面每个章节都对应清单里的一块。你可以把它打印出来，每学完一个模块就去勾选。

这张清单也是后面几章内容的索引，我会按照从底层到上层的路径逐个展开，因为学习顺序上先理解底层约束，再看上层封装，会顺畅得多。

3. 算力层：GPU集群与异构计算的三个关键认知

3.1 芯片选型不能只看FLOPS，带宽和显存往往才是瓶颈

很多刚接触AI Infra的同学很容易被厂商的算力宣传带偏思路，盯着FLOPS不放。但真实的AI负载尤其是大模型训练，绝大多数时间都卡在显存带宽和数据搬运上，而不是纯计算力上。你可以做一个非常简单的类比：GPU算力强相当于一个厨师的刀工很快，但如果食材端不上来，出菜速度照样上不去。显存带宽就是那条传菜通道，通道窄了，刀工再快也白搭。

所以看一块AI芯片是否适合训练任务，我一般先看三个指标：显存容量、显存带宽、互连带宽。显存容量决定你能不能塞下大模型和大的batch，显存带宽决定每个step里的数据搬运动是否跟得上计算，互连带宽决定多卡之间交换梯度是否高效。至于FLOPS，放到第四位也不过分。

另外说一个很容易被忽略的点。你在云上租GPU实例时，看到的规格通常只标注了CPU核数、内存和GPU型号，但真正影响训练效率的卡间通信带宽，往往是隐藏在实例类型背后的。同样是八卡机器，有的型号卡间走高速互连总线，有的型号走PCIe交换机，实际多卡训练性能能差出一倍以上。有条件的话，租几台不同规格的机器跑同一个ResNet或小规模Transformer做基准测试，比看参数表靠谱得多。

3.2 GPU资源管理：从裸占用到精细化切片

传统后端管理CPU资源是一件很成熟的事，但GPU资源管理发展了这么多年，仍然有不少团队在用最原始的方式：一张卡给一个任务独占。深度学习任务真的都吃满一张卡吗？不一定。小模型的推理服务、单卡就能放下的微调任务、开发调试阶段的试跑，大部分时间GPU利用率不到百分之二十。

如果卡多无所谓，但大多数团队卡是稀缺资源。这时候就要引入GPU共享和切片技术。目前比较成熟的做法有几类：

• 基于硬件切分：把一张物理GPU按算力和显存切成多个实例，每块独立运行虚拟设备，互不干扰。这一方案质量高，但要求硬件和驱动支持。
• 基于算力限定：通过框架层的配置，限制某个容器能使用的算力百分比和显存大小。隔离性弱一些，但胜在灵活，任意卡都能用。
• 基于时间切片：多个任务轮流使用整张卡，每个任务运行极短的时间片。这对推理类短任务比较友好，但训练类长任务要慎重，涉及上下文切换开销。

我见过不少团队因为图省事，所有任务都独占GPU，结果集群利用率常年徘徊在百分之十几。从我自己的实践看，至少要做一个"大小任务分离"的策略：大训练任务走独占队列，小任务和开发调试走共享队列，队列之间用配额和优先级管理。这一条做下来，集群利用率基本能提升到30%以上。

3.3 算力环境管理的四个常见坑

算力环境管理是一项琐碎但不能马虎的工作，经验少的人很容易在几个坑里反复栽跟头。

第一个坑是驱动和容器运行时版本不匹配。GPU驱动、容器运行时、CUDA版本之间有复杂的兼容关系，升级任何一个都要全面验证。我建议在团队内部把版本组合固定下来，做成标准的镜像模板，不要允许各项目自由选版本。否则你会发现在排查问题的时候，同一个报错在不同机器上原因完全不一样。

第二个坑是缺少显存和算力的细粒度监控。只看节点空闲不空闲是不够的，要看到进程级别的显存占用和算力占用，才能发现"明明有一堆卡闲着，但任务就是排不进去"的情况。有条件的团队应当部署GPU监控组件，按容器维度采集显存申请量、实际占用率、显存温度和功耗。

第三个坑是任务退出后显存没有释放干净。这种情况在分布式训练里尤其常见，某个worker异常退出，但驱动层面的上下文没有被回收，导致显存碎片化，后续任务申请内存失败。遇到这种问题，简单粗暴的办法是重启节点，但更体系化的做法是配置定期巡检和自动清理。

第四个坑是忽略了CPU和内存的平衡。很多人给训练容器只申请了很少的CPU，却用满了GPU显存，结果数据加载阶段CPU成了瓶颈，GPU只能傻等着。给定训练任务配置CPU与GPU的比例，应该参考数据管道的吞吐能力，而不是随手填一个数字。建议在任务提交模板里把最小CPU配额和最大内存配额都做成必填项，并给出一套默认基线值。

4. 存储与数据层：让万亿字节的数据流畅地喂给GPU

4.1 训练数据流的存储特征为什么特殊

传统业务存储优化，主要盯着数据库的随机读写和延迟，但AI训练的数据访问模式完全不一样。训练过程中，数据加载器会持续读取大量训练样本，这些样本以小文件的形式散落在目录里，同时还要频繁地进行Shuffle、数据增强和批处理。这种模式既能触发大量小文件随机访问，又要求整体读吞吐高到能喂饱几十甚至几百块GPU。

我见过一个很典型的场景：训练集群有64张GPU，每张卡期望每秒处理几千个样本，理论上数据加载需要达到几十GB每秒的吞吐。结果存储系统用的是单机磁盘阵列，根本扛不住这个并发，训练进度条每走一个step就停顿一下，GPU利用率只有十多个百分点。后来换了并行文件系统，把数据预取机制也搭起来，问题才彻底解决。

所以说，AI训练存储设计的第一原则是：存储端到计算端的吞吐，要大于所有GPU合计的数据消费速度，而且最好留下两三倍冗余。很多团队在规划集群的时候只算了GPU的钱，没算存储的钱，最后训练跑不起来才急匆匆擦屁股，属于典型的预算规划失误。

4.2 文件系统选型：从本地盘到并行文件系统的路线判断

存储选型没有绝对的对错，关键是要匹配训练负载的规模和特征。我大致把存储路线分成三档。

第一档是小规模实验阶段，一两台机器，几块GPU。这时候直接上本地NVMe盘最省事，数据放在每台机器本地，再用数据加载接口做简单的分布式采样，完全够用。

第二档是中规模训练阶段，一个训练任务要用到几十台机器。这时候本地盘就没法满足数据全局可见的需求了，必须在集群层面做共享存储。便宜的方案是挂载一个网络文件系统（NFS）当共享盘，配置简单，但如果并发读取量大，很容易把NFS服务器打挂。稳妥一点的方案是上分布式并行文件系统，数据条带化到多个存储节点上，聚合吞吐和扩展性都强很多。

第三档是超大规模训练阶段，对外提供统一存储底座。这时候要考虑高性能并行文件系统和对象存储的混合架构：训练热数据放在高性能目录，冷数据和数据集归档放在成本更低的对象存储里，两者之间通过生命周期策略自动流转。

选型的时候，除了看性能指标，还要考虑运维复杂度。并行文件系统性能确实好，但它本身也是一个有状态的分布式系统，自建的话要付出不低的运维成本。如果你的团队只有两三个人，我倒是建议优先考虑云上的托管文件存储产品，别什么都自己搭，否则存储系统本身就成了让你脱不开身的项目。

4.3 数据缓存、版本管理与加载加速的实操要点

存储系统解决的是数据在哪里持久化的问题，但光有持久化层还不够。训练框架在读数据的时候，如果每次都直接打存储后端，哪怕后端再强，延迟和带宽成本都吃不消。所以中间一定要加缓存层。

数据缓存的常规做法是本地缓存加分布式缓存两层。本地缓存通常放在每台训练节点的NVMe盘上，第一次读取时从共享存储拉取，后续全部命中本地；分布式缓存则可以用开源缓存框架搭建，几个节点组成一个缓存池，共享一份热数据。缓存策略上优先缓存频繁使用的数据集，比如验证集、公共预训练语料，而训练主数据通常不断流式读取，缓存命中率反而不高。

数据版本管理也是AI Infra里一个容易被忽略但非常重要的点。训练样本集是实时更新的，模型要在不同的数据集版本上做对比实验，没有版本管理的话，你根本无法确认某个实验用的是哪批数据，对不上结果的时候就会非常痛苦。最简单的方案是给每个数据集建一个不可变的版本号，元数据记录数据的生成时间、来源、处理脚本版本和文件列表。复杂一点的方案，就是直接上数据集管理平台，自动完成打包、校验和元数据记录。

关于数据加载加速，有一个性价比很高的技巧：使用内存映射文件来代替常规的逐条读取接口。尤其在数据样本较大、预处理逻辑复杂的场景下，内存映射方式能省掉很多系统调用开销。配合多线程预取和解码，数据管道的吞吐能翻一倍。这个优化本身不复杂，却常常被团队忽略。

5. 网络与通信层：分布式训练的性能命脉

5.1 为什么传统TCP在AI训练里不够用

如果说存储是喂饭的通道，那么网络就是肌肉间的神经传导通道。模型参数动辄几十亿上百亿，每次迭代都要在成百上千张卡之间同步梯度，如果网络延迟高、带宽低，整个训练过程会变成"大部分时间在等通信，小部分时间在计算"的状态。

传统TCP协议栈的致命问题在于端点CPU开销太大。每传一个数据包，CPU都要参与复制、校验和确认，数据量一大，CPU直接被网络协议栈打满，反而没法处理计算任务。而RDMA（远程直接内存访问）技术的核心思路是绕过CPU，让网卡直接把数据从一台机器的内存搬到另一台机器的内存，既降低延迟又释放CPU。所以现代AI数据中心网络，基本都以支持RDMA的网卡和交换机为核心。

RDMA有两种常见落地形式。一种是InfiniBand，专用网络，性能和稳定性最好，但成本高，通常用在头部玩家的核心集群里；另一种是RoCE，在以太网基础上通过配置实现RDMA能力，成本更低，被更多普通团队接受。RoCE部署的难点在于它对网络无损传输有很高要求，一旦丢包，性能会暴跌，所以端到端的流控和拥塞控制必须仔细调优。

5.2 集合通信库：分布式训练的幕后功臣

你训练一个8卡模型，每一次梯度同步，卡与卡之间要做大量的数据交换，这些交换不是随意的点对点消息，而是有固定模式的集合通信操作。最典型的是全规约操作，每张卡计算好本卡的梯度后，通过网络把所有梯度分片加起来，最后每张卡拿到一份完整梯度。还有一个典型是全收集操作，每张卡把各自的结果广播给全体。这些集合通信操作性能的优劣，直接决定了分布式训练的上限。

集成了这些集合通信操作的库，目前事实标准就是NCCL（NVIDIA Collective Communications Library），AMD平台也有对应的开源实现。NCCL会根据GPU拓扑自动选择通信路径，能走卡间高速互连就不走PCIe，能走PCIe就不走网络，这套拓扑感知逻辑是NCCL性能强劲的核心原因之一。

但在大规模训练里，NCCL的默认策略不一定是最优的。它有时选择在单机内部先做规约，再走网络跨机传输，从而减少跨机数据量；有时又会选择两端直接走网络，减少内部聚合的延迟。你需要了解这些策略的存在，并且通过环境变量调节通信算法和并行度，才能压榨出更好的性能。这也是网络层学习和平台层调度结合最紧密的地方：调度的时候如果知道任务要跨多少台机器，就可以提前把网卡资源和拓扑规划好，避免通信路径绕路。

5.3 拓扑感知调度：让你的网络设计发挥真正价值

很多人在搭建AI训练集群时只关注带宽数字，忽略了物理拓扑。举个例子，如果一个训练任务被分配到两批机器，这两批机器位于不同的机柜和交换机之下，跨机柜通信的延迟和拥塞风险都会显著增加。跑单卡任务无所谓，但跑八卡甚至十六卡的分布式训练，网络拓扑就成了性能分水岭。

所以成熟的调度器会做拓扑感知：提交任务的时候带上GPU数量需求，调度器优先把任务分配到能够满足卡间高速互连的同一台物理机，放不下再扩展到同一接入交换机下的相邻机器，实在不行才跨交换机调度。这样既能保证性能，也提高了整机资源利用率。

如果条件允许，还可以在物理网络层面做隔离设计。把训练集群和推理集群放在不同的网段，训练流量和推理流量互不干扰。有人可能会觉得这不就是把交换机多划几个VLAN的事，但实际做起来，涉及到路由策略、流控参数和告警阈值的独立配置，并不简单。这个设计在业务规模大了以后价值非常明显，值得提前规划。

6. 平台与调度层：让整个集群高效运行的框架能力

6.1 容器化与GPU资源调度的落地路径

底层算力、存储、网络都准备好之后，接下来要解决的是"任务怎么提交、怎么排队、怎么分配资源"。这个环节是AI Infra里离普通工程团队最近的一层，也是问题最多的一层。

现阶段主流方案毫无悬念是Kubernetes加容器运行时。Kubernetes负责管理和调度CPU、内存等常规资源，而GPU这种扩展资源则通过设备插件机制上报给Kubernetes。任务提交层面，你可以用原生API直接定义容器组资源，也可以用更上层的框架来做作业编排。

这里有一个很多团队纠结的点：到底要不要用Kubernetes原生的调度器调度训练任务？我的建议是，规模不大、任务形态单一的时候，原生调度器够用；但一旦训练任务类型多了，有长耗时训练、有短任务、有交互式调试、有定时任务，原生调度器的公平性和优先级策略就不太够用了。这时候要么引入支持队列、优先级、抢占的批量调度组件，要么直接考虑更贴合AI场景的专业编排框架。

6.2 弹性训练与多租户资源的平衡

资源池是有限的，不同团队、不同项目都在抢算力，没有一套合理的配额和调度策略，集群迟早会陷入"谁嗓门大谁用卡"的混乱局面。我见过的比较成熟的方案是分层配额管理：管理员给每个业务团队设置总配额，团队内部再按项目设置子配额，训练任务提交到某个队列里，调度器根据队列的优先级和当前占用率决定是否立即执行。

弹性训练也是一件值得做的事。很多训练任务虽然申请了大量GPU，但模型收敛到后期时，通过适当增大batch、减少梯度同步频率，可以用更少的卡维持相近的训练速度。平台如果能支持任务级别的动态缩容，把释放出来的卡让给其他任务，整体吞吐会明显提升。这个功能实现起来有一些复杂度，因为训练框架要能感知资源变化并完成checkpoint保存，但长期来看收益特别大。

还有一点是租户隔离。多租户场景下，A团队的任务绝对不能占满集群导致B团队的任务饿死。调度器层面要配置抢占策略：低优先级任务在高优先级任务到达时，可以被安全地挂起并让出资源。这要求任务本身支持断点续训，否则被抢占等于白跑，所以本质上还是跟训练框架的配合问题。

6.3 可观测性：运维AI集群的第三只眼睛

AI集群的监控不能只看CPU和内存这几个常规指标。GPU维度至少要看利用率、显存占用率、温度、功耗、PCIe链路状态；网络维度要看RDMA流量、丢包重传率、队列堆积；存储维度要看IOPS、吞吐、元数据操作延迟。这些指标之间的因果关系也要梳理清楚。比如GPU利用率为0，可能是代码确实在等待IO，也可能是集合通信卡在哪台机器上，还可能是数据加载进程已经崩溃但没有被任务系统感知到。

监控数据的采集链路建议做到组件级和任务级两层。组件级监控覆盖物理设备状态，所有机器统一上报，方便运维发现硬件问题；任务级监控则记录每个训练任务的实时进度、吞吐、loss收敛曲线，方便训练工程师定位性能问题。两条链路各有分工，缺一不可。

日志和链路追踪也不能省。分布式训练任务的日志是分散在多台机器上的，要建立统一的日志采集和检索系统，否则排查问题的时候你只能一台一台机器登录，效率极低。特别要留个心思把训练框架的日志时间戳对齐到统一时钟，跨机器的因果推断就会变得可行。

7. 模型服务化与推理优化：练出来的模型只是前半程

7.1 从训练产物到线上服务要过几道关

模型训练完成只是生命周期的一半，真正考验工程能力的是把它变成稳定、低延迟、可扩展的在线服务。

第一道关是模型格式转换与压缩。训练框架产出的权重文件通常体积很大、格式特定，不适合直接加载到生产环境。常见做法是先做模型量化，把浮点权重转成16位甚至8位整数精度，在不明显掉点的情况下占用的显存和带宽都大幅下降。再配合蒸馏、剪枝等手段，模型规模能进一步缩小。

第二道关是部署形态设计。同一个模型可能同时服务多个业务方的请求，每个业务方的QPS和延迟要求都不同。可以把模型打包成若干个副本池，不同池配置不同的批处理大小和并发能力，按流量配比路由请求。对于超大模型，单卡放不下，还得做模型并行部署，把模型切到多张卡上，每张卡只负责一部分计算，这对推理框架提出了更高的要求。

第三道关是安全性。模型权重是团队的核心资产，线上接口又直接暴露给客户端。要配置网络访问控制、请求频率限制和异常流量告警，同时确保模型的推理输入输出不会引入无意义的资源消耗。这个领域比较新，但绝对不能等到出了事再补。

7.2 推理加速的常用手段与效果对比

推理延迟和吞吐是服务端的核心指标，加速手段单靠换GPU是不够的，工程上可以做的优化非常多。

动态批处理是最容易落地的一个优化。推理请求连续到达，如果来一个请求就推一次，GPU算力浪费会非常严重。合理的做法是把短时间窗口内的多个请求拼成一个batch统一推理，用延迟换吞吐。这个逻辑跟训练里加大batch完全一样，核心难点是服务框架要能优雅地管理排队和超时。

模型量化是第二个性价比极高的优化。把模型从32位浮点降到8位整数，显存占用直接除以四，推理速度通常也能翻倍以上。难点在于量化之后精度会下降，需要在离线阶段评估量化误差，决定哪些层可以量化、哪些层必须保持原精度。

近两年还出现了一种新的加速思路，就是投机解码。让一个小模型先快速生成候选结果，再由大模型验证这些结果，如果验证通过就一次输出多个token，等效地把生成速度提升好几倍。这个技术在在线推理场景已经很常用，但要注意它只适用于自回归式的生成任务，未必适合所有模型形态。

7.3 延迟、吞吐和成本的三角平衡

做推理架构设计，最核心的一个权衡是延迟、吞吐和成本。三者的关系简单说就是：体验要更好，成本基本必然上升；成本要更低，延迟或吞吐基本要松一个口子。没有免费的午餐，我见过太多团队在推理优化初期追求极致低延迟，结果成本高到无法接受，又被迫回头做折中。

比较务实的做法是分层分级设计。对内部调试请求和外部用户请求走不同集群；对高优先级在线请求走动态批处理小窗口、低延迟集群；对离线批处理任务走大batch、高吞吐集群。这样既为关键用户保住了服务质量，又用离线任务填满了计算资源，整体成本能优化很多。

另外强烈建议在项目一开始就把成本指标纳入监控面板。很多团队直到月底收到账单才发现GPU费用超支，再回头看，往往是某一个服务的副本数或实例规格配多了。平台层如果支持按模型服务维度的成本核算，把每个服务的推理量、GPU小时数、平均延迟做成日报，问题就能早发现早解决。

8. 学习路径与实战避坑实录

8.1 按目标分层选路，别一上来就啃协议

AI Infra内容量太大了，什么方向都学一遍既不现实也不必要。按自己的职业目标选路径会更高效。

如果你是想往AI平台开发方向走，重点放在平台层和调度层，把Kubernetes、任务编排、弹性容错、监控体系吃透，再补一些存储和网络的基础概念就够用了。如果你是想做训练性能优化，重点放在计算层和网络层，NCCL调优、拓扑感知、数据管道的吞吐分析是你的必修课。如果你是给业务团队搭内平台，那存储选型、资源配额、服务化部署这几块要着重积累，因为这些直接决定日常使用的体感。

零基础入门的读者，我会劝你不要直接从分布式论文开始读。很多论文里的假设在真实环境里不一定成立，读倒是能读，就是记不住也练不了。建议按这条路径走：先在一台单机GPU上完整跑通一个小模型，理解训练流程；然后扩展到两台机器做分布式训练，感受通信开销；再尝试搭一个完整的Kubernetes GPU集群，把调度、监控、日志串起来；最后再做推理服务，把延迟和成本数据埋起来分析。每一步都动手，效果比读十篇文章都强。

8.2 一套可以直接复用的上手实验路径

动手是学好AI Infra的唯一捷径。我建议你认真做一遍下面这条路径，每一步都尽量自己完成。

第一步，租一台带GPU的云主机，装好驱动和常见深度学习框架，跑通一个最小训练脚本，确认能够利用GPU训练。第二步，在这台机器上启动一个容器化运行时，配置GPU资源，体验容器内使用GPU的流程。第三步，用两台GPU机器搭一个最小Kubernetes集群，安装设备插件组件，提交一个示例训练作业。第四步，尝试提交一个多节点分布式训练任务，手动调节几个关键的集合通信参数，观察训练吞吐的变化。第五步，给集群搭上监控告警系统，配置GPU利用率和内存指标，模拟一个故障确认告警能正常触发。第六步，把一个训练完成的模型导出并部署成推理服务，对比不同动态批处理参数下的延迟和吞吐。

整个过程不保证一次顺利，但只要你按这个顺序走完，AI Infra的骨架就在脑子里了。之后再遇到具体的协议、配置、参数，你都懂得该往哪个方向查。

8.3 常见问题与排查思路速查

把我在实际操作中碰到过的高频问题整理成一张表，很多问题看起来吓人，其实排查链路是有规律可循的：

8.4 我的几条实操体会

最后说几条没法写成步骤、只能靠长期实践得到的体会。

第一，AI Infra工程里没有一个决策是纯技术决策。每当你觉得某个方案很先进、想直接上的时候，先问三件事：团队有没有人能维护好？出问题了有没有人能排障？长期成本预算能不能承受？三个问题只要有一个是否，再先进的方案都要打折扣。

第二，排查问题的时候一定要坚持看指标而不是猜原因。AI集群的故障往往是一果多因，GPU利用率低可能是代码问题、网络问题、存储问题、资源竞争问题中的任何一种。没有完善的监控数据，排查就是碰运气。所以不管你正在做什么，先把监控体系搭起来永远不亏。

第三，多关注社区里关于训练框架和调度器的更新。AI Infra这块技术迭代速度非常快，一年前的主流方案，明年可能就有明显替代品出现。保持学习的节奏，比死守某一套熟练的配置更重要。

第四，如果你带团队，建议培养一个"全链路视角"的工程师。一个懂数据管道、又懂网络通信、还能独立配置调度策略的人，价值远超三个只擅长单个组件的工程师。培养这种人最好的方式，就是按这篇文章的知识地图，让他在模拟环境里把整条链路亲手搭一遍。搭过一次，之后再遇到问题，他心里就有一张完整的地图了。

AI Infra不是某个单一技术的代名词，它是由一群互相咬合的工程组件拼接而成的完整学科。愿你借着这篇笔记搭好自己的知识框架，少走一些我当年走过的弯路。