企业官网建设流程全解析

我做AI-Infra差不多五年时间，从一个写业务接口的后端工程师，慢慢转成天天和GPU集群、分布式训练、推理加速打交道的一线干活的人。这个标题里的“第一章”，对我来说就是最开始那段从零开始、踩坑踩到怀疑人生的过程。很多朋友问AI-Infra到底做什么，怎么入门，日常工作是不是就是“看GPU利用率”，今天就用这篇把话聊透。

先说清楚“AI-Infra”是什么。它不是一个产品，也不是一个岗位能概括完的职责，而是支撑AI从模型训练到线上推理全链路的基础设施工程。拆开看就是四件事：算力供给、数据流转、训练调度、推理服务。换句话说，算法工程师负责设计模型结构、调整训练策略，我们负责让模型“有地方跑”“跑得快”“跑得稳”“上线了还不烧钱”。这篇面向两类人：一类是刚接触AI工程化、想搞清楚底层逻辑的新人，另一类是写代码很多年、想转方向但不知道从哪里入手的朋友。我会尽量把日常踩过的坑、验证过的方法、想明白的原理都写出来，不整虚的。

1. 我理解的AI-Infra到底在管什么

1.1 从一次训练任务看基础设施的全貌

假设算法同事递过来一个需求：要在一周内完成一个三十亿参数的语言模型微调，数据大概五个TB，训练集群需要至少八卡A100级别的资源，而且要求随时能看训练日志和loss曲线。

这个需求落到AI-Infra头上，不是“给他八张卡”这么简单。背后的链条是：先确认集群里有空闲的合规资源，安排调度器把任务排队并锁住资源，然后把五个TB的训练数据从对象存储高效拉近训练节点，同时保证多机多卡通信的带宽和延迟达到要求。训练启动后，还要持续监控显存占用、GPU利用率、通信占比、断点保存是否正常。中间任何一环出问题，比如某张卡散热异常导致降频、某根光纤抖动导致NCCL超时，算法同事看到的就是loss曲线断裂或者训练直接报错退出。

所以AI-Infra的日常，就是保证这条长链条里的每一个齿轮都顺畅转动。训练任务跑不起来是事故，跑得慢是慢性病，跑完效果不好还要帮算法排查是不是数据管道喂了错的样本。这就是为什么这个方向的人需要同时懂系统、懂硬件、懂一点模型训练和推理原理。

1.2 和传统后端基础设施的本质区别

传统后端基础设施追求的是“高并发、低延迟、高可用”，核心对象是用户请求和业务逻辑。AI-Infra的核心对象变成了“算力单元”和“模型状态”。区别体现在几个地方：

第一，资源形态完全不同。传统后端一台物理机可以虚拟出几十个容器，因为请求是短连接、状态轻；但训练任务一张GPU卡就被一个进程占住，显存一占可能就是几十GB，用完才能释放。第二，故障模型变了。传统领域一个节点挂了，负载均衡自动切流，用户几乎无感；训练集群一张卡挂掉，如果不做弹性容错，整个几百张卡的训练任务直接中断，前面的几十个小时白跑。第三，评估指标不一样。后端看QPS、RT、错误率，AI-Infra重点看MFU（模型算力利用率）、显存利用率、有效训练占比、推理吞吐和成本。

这些差异决定了AI-Infra工程师的思维模式。你不能用面向请求的架构去套算力调度，也不能用常规的监控告警思路应对训练中断。这些都是我在实际工作中慢慢体会到的，一开始也栽过不少跟头。

2. 算力层：和GPU打交道的第一回合

2.1 一个训练节点里到底有什么

很多新人以为GPU集群就是一批带显卡的服务器连起来，其实没那么简单。一个标准训练节点，硬件上包含CPU、内存、多张GPU卡、本地NVMe盘、高速网卡。卡和卡之间通过NVLink做机内互联，带宽可以到几百GB/s，比PCIe高一个数量级；节点之间则靠RDMA高速网卡走IB或RoCE网络互联，带宽通常是200Gbps或400Gbps起步。

为什么要这么复杂的互联？因为分布式训练的本质，是把一个大模型拆到多张卡上并行计算，每轮迭代结束都要做梯度同步。梯度同步的数据量和模型参数规模直接相关，一次all-reduce操作就要把每张卡上算出的梯度汇总广播到所有卡。如果卡间通信带宽不够，训练速度就会被通信瓶颈卡死，GPU再快也发挥不出来。

所以对AI-Infra工程师来说，看懂机器配置和第二天的硬件架构图是基本功。看到一张卡的时候，脑子里要知道它的显存多大、算力是什么级别、和谁连在一起、走什么协议，这样才能判断它适合哪种并行策略。

2.2 显存和算力之间的平衡艺术

训练大模型最直接的约束是显存。三十亿参数的FP16模型，光参数就要6GB，但训练状态不只是参数，还有优化器状态、梯度、激活值、中间计算结果。算下来需要的显存往往远超参数本身的几十倍。我见过不少人第一次跑大模型，直接OOM，然后以为写代码的人粗心，其实大概率是显存规划没做好。

显存不够有几个常规解法，各有代价：

• 梯度检查点：不保存每一层的激活值，反向传播时重新算。省显存但增加计算量，一般能省50%以上的激活显存。
• 混合精度训练：参数和梯度用FP16或BF16存，优化器状态用FP32。速度提升和显存节省都很明显，但要小心精度溢出。
• ZeRO优化器：把优化器状态、梯度、参数切分到多张卡上，谁需要谁拉。这是现在大模型训练的基本操作。

这几招不是选一个就完事，而是要组合使用。实际训练的时候，要一边看显存监控一边调配置，比如Batch Size开多大、序列长度多少、模型并行的切分维度如何设置，每动一个参数都可能影响整体显存水位和计算效率。这就是“工程感”的来源。

2.3 理解MFU，别被GPU利用率骗了

监控面板上GPU利用率100%不一定代表训练高效，这是我反复跟算法同事解释的事情。利用率只说明GPU有活干，但干的活里有多少是有效计算，多少是在等数据、等通信，只有MFU能告诉你答案。

MFU是实际算力输出除以理论峰值算力的比值。一个训练任务MFU只有30%，说明GPU大部分时间在空转或等待。提升MFU的方向包括调大Batch Size减少通信次数、优化数据加载消除等待、用NCCL的拓扑感知通信、调整并行策略减少跨节点通信。我在实际项目中曾经把一个模型的MFU从38%提到57%，训练时间直接缩短三分之一，没有改任何模型代码，全是基础设施侧的动作。

这也是AI-Infra工作的价值所在：表面看起来是偏运维的活，实际上是通过底层系统优化直接缩短业务时间、降低算力成本。

3. 分布式训练的工程底色：网络、存储、调度

3.1 网络：为什么通信比你想的更关键

分布式训练场景里，通信效率直接决定训练效率。以数据并行为例，每轮迭代每张卡都要把梯度广播给所有其他卡，通信量随卡数线性增长。八卡机内通信还好，到了跨机训练，比如四机三十二卡，一次梯度同步的数据量就非常可观。

实际遇到过最痛的问题之一就是NCCL超时。第一次遇到时，算法同事跑着跑着日志里冒出一句“timeout at ...”，整个任务挂了。排查半天，发现一块网卡固件版本和驱动不兼容，导致通信性能突然掉到原有水平的十分之一。之后我们把网卡固件升级和驱动校验写进了集群入网规范，再没因为这个原因跪过。

网络层面的基础设施工作主要是三块：保证节点间RDMA网络质量，监控NVLink/NCCL通信性能和拓扑，排查交换机拥塞、丢包、光模块异常。这些日常不被看见，一旦出事就是事故级别。做AI-Infra的人必须有这个意识：哪个环节弱，整条训练链就卡在哪里。

3.2 存储：训练数据进门的速度

算力再强，数据进不来等于空转。训练数据一般放在对象存储或并行文件系统里，训练节点本地只有少量高速盘做缓存。如果数据加载链路设计得不好，每轮迭代都要等数据从远端拉取，GPU就在那儿干等着。

我把数据加载的问题分成三类：首次拉取慢、迭代中读取慢、checkpoint读写影响训练。

首次拉取慢，通常是数据量太大、带宽不够，或者并发拉取的通道太少。我们一般做两件事：按训练周期预先把数据同步到靠近计算节点的缓存，以及用高并发分段下载减少单文件瓶颈。

迭代中读取慢，多半是数据格式问题。比如几百张小的图片文件一个个地按文件名读，比合并成TFRecord或WebDataset格式慢一两个数量级。数据格式优化这件事经常被算法忽略，但收益非常大，有时能把训练速度提升一倍。

checkpoint读写也很容易被忽视。大模型每过一定步数就要保存一次权重，几十GB的数据写入慢或写入频繁，会显著挤占训练时间。我们后来把异步保存和更合理的保存频率结合起来，大幅降低了对训练循环的影响。

3.3 调度：资源池怎么分才不吵架

多人共用训练集群的团队，资源分配永远是矛盾集中点。A项目要跑大实验，B项目要快速出一版结果，谁先谁后、各拿多少卡，如果没有清晰的调度策略，大概率天天撕。

我们用的方案是基于队列的调度器。每个项目组有独立队列，队列有配额限制和优先级。提交训练任务的时候带上资源需求和优先级，调度器会根据当前集群状态分配空闲卡。同时支持弹性配额，非高峰时段允许项目组多用，高峰时段自动收紧。这些策略都是可以配置的，不同团队可以按自己的节奏调整。

调度系统上线前后对比很直观：上线前人工协调一周，命令靠私聊；上线后任务提交自助完成，资源分配自动执行，排队原因一目了然。作为AI-Infra工程师，调度能力是必须掌握的硬技能。

3.4 一个可以抄作业的调度方案示例

如果你所在团队还没有做训练任务的管理，最简单的方案是用现有容器调度平台加一个训练任务控制器。思路是做一个任务定义文件，里面写明镜像、卡数、数据集、训练脚本，调度平台负责申请资源、运行任务、回收资源。

下面是一个使用容器方式和调度配置的示意，可以参考：

apiVersion: example.ai/v1 kind: TrainingJob metadata: name: finetune-demo namespace: ai-team spec: queue: "alg-fin" priority: "high" resources: gpu: 8 cpu: 64 memory: 512Gi maxRetries: 2 image: registry.internal/ai/trainer:latest datasetPath: s3://data/finetune-pack command: ["torchrun", "--nproc_per_node=8", "train.py", "--model_size", "3b"]

这个方案的好处是任务状态、日志、资源使用都能统一管理，和公司已有的监控告警平台集成也方便。新人可以拿这个思路当起点，再从队列、抢占、优先级这些方向慢慢做深。

4. 推理侧的基础设施：成本是一道绕不过去的坎

4.1 训练和推理是两种完全不同的物种

训练阶段关注吞吐与稳定性，推理阶段关注延迟、吞吐和成本。大模型在线推理服务，每秒处理的请求量直接决定机器数量，成本可以高到吓人。我见过一个模型服务，高峰期需要几十张A100同时跑，每月的算力成本高到让管理层专门开会讨论。

推理侧的优化核心是把单个请求的成本压下来，同时保证延迟在可接受范围。这里面有几个关键手段值得展开。

4.2 量化、连续批处理、KV Cache

量化是把模型权重从FP16压到INT8甚至INT4，用精度换速度与显存。对大模型来说，量化后显存占用可以减少一半以上，吞吐提升也很可观。但量化不是无脑上的，要评估精度损失，尤其是在需要高质量生成的场景。

连续批处理（Continuous Batching）是提升推理吞吐的关键技术。传统批处理要等一批请求全部完成才释放资源，短请求被长请求拖住；连续批处理允许一个请求生成完就立即释放，让新请求进来，资源利用率大幅提高。很多主流推理框架都已经内置了这个能力。

KV Cache对大模型推理的显存占用影响巨大。它缓存了已生成部分的注意力键值，避免重复计算，但代价是显存跟着序列长度增长。做推理服务时，要监控KV Cache的占用情况，合理设置最大生成长度和并发数，防止OOM。

4.3 一个推理服务的部署要点

部署大模型推理服务，我一般会先问清楚场景：是内部工具、面向少量用户的辅助服务，还是高并发线上产品。不同场景的技术选型差别很大。内部工具可以牺牲一些并行度，减少排队等待；高并发场景则要引入多副本、负载均衡和弹性伸缩。

比较稳的起步方式是：用主流推理框架部署模型，开启连续批处理，设定合理的最大并发数，前置监控告警。线上稳定后再逐步加量化、蒸馏、路由缓存等进阶优化。不要一上来就追求花哨功能，先把延迟和成本的基础指标测清楚，再针对瓶颈做专项优化。

5. 排障实录：一段崩溃式成长

5.1 显卡被神秘占满

有一次集群明明空闲，新任务却一直排队等待资源。排查调度器显示“内存不足”，但看每台机器的物理内存都够。折腾了很久才发现，是有个进程在崩溃前没有释放GPU显存，僵尸进程把显存占住了，调度器基于显存判断资源是否可用，结果认为集群满了。

教训是：训练集群的监控必须同时覆盖GPU显存和物理内存，并且要加僵尸进程清理机制。从那以后，我们给所有训练节点加了一个巡检脚本，定时清扫异常进程。这类问题在文档里很少被提及，但现实中非常常见。

5.2 NCCL通信超时，训练突然挂掉

多机训练最怕的就是NCCL报错。有一次训练任务跑到中途，日志里出现通信超时，损失函数还没收敛就彻底中断。从网络监控看，节点间延迟正常，TCP没问题，但RDMA通信失败。最终定位到交换机光模块故障，虽然TCP能走，但RDMA专用通道受影响，导致NCCL通信超时。

这个案例给我的经验是：RDMA网络和传统TCP网络的健康指标不同，必须建立专门的监控体系，包括重传率、丢包率、链路质量，并且要在新节点上线前做全链路通信测试。依赖TCP通就认为网络好的思路，在AI-Infra里面会吃大亏。

5.3 一张卡显存OOM拖垮整个训练

数据并行训练时，如果某张卡的显存比其他卡小一点，或者分配到的数据批次略微不均衡，就可能出现单卡OOM，整个训练任务失败。第一次遇到时觉得莫名其妙，明明总显存是够的。

后来查了训练框架的内存分配逻辑，发现模型并行场景下，显存分配需要整体考量，不能只看单卡。我们调整了训练配置，让Batch Size和模型并行切分更均匀，并且启用显存预分配，避免训练过程中动态分配导致碎片化。这一套调整之后，OOM出现的频率大幅下降。

6. 给想入坑的人一些建议

6.1 你们先补哪些基础

AI-Infra需要的知识面确实有点广，但如果从零开始，优先级大概是：Linux系统管理、Python开发、计算机网络基础、GPU和CUDA编程基础、分布式训练原理、容器化技术。这些不是要先学完再上手，而是边做边补。

我的建议是先找一台带GPU的机器，跑通一个简单的图像模型训练，然后尝试把单卡训练改成多卡数据并行。在这个过程中你会自然遇到显存、通信、数据加载、版本兼容等问题，每处理一个问题，你对整个系统的理解就加深一层。

6.2 硬件手感和软件直觉同样重要

现在很多资料都在讲算法和框架，但AI-Infra的很多坑出在硬件层。你需要对GPU型号、显存大小、带宽指标、NVLink拓扑有基本的识别能力。不一定非要会修硬件，但要知道什么指标影响什么性能，这样遇到问题才能判断是硬件的锅还是软件的锅。

软件层面要培养的能力是定位瓶颈。训练慢，先看GPU利用率、看通信占比、看数据加载耗时，用数据定位瓶颈，而不是凭感觉乱调。做AI-Infra最重要的素质不是懂多少工具，而是能在复杂链路里快速定位问题。

6.3 一个值得长期深耕的方向

AI-Infra这几年变化很快，但有两个方向我觉得会持续有价值：一是推理侧的成本优化，这个直接关系到AI产品能否规模化落地；二是训练侧的稳定性和效率，集群规模越大，稳定性挑战越突出。想深耕的朋友可以从这两个方向选一个切入。

我个人在实际工作中的体会是，这个领域的成长速度取决于踩坑的密度。多做一些真实业务场景的任务，多处理几次线上事故，比看多少文档都管用。把每次“莫名其妙”的问题记录下来，沉淀成自己的排查手册，这条路会越走越顺。