企业官网建设流程全解析

"AI Infra 知识全景学习笔记"——这是我给自己过去半年多从零学习AI基础设施（AI Infra）交的一份期中作业。与其说是一篇技术教程，不如说是我把踩过的坑、想通的点、验证过的方案按一条主线重新整理了一遍。为什么要写这份学习笔记？因为市面上的干货虽然多，但大多零散：今天看一篇讲GPU调度的文章，明天刷到一个讲分布式训练的PPT，知识全是碎片状的，很难形成体系。我也试过直接啃官方文档，效率更低，很多概念没有实际场景根本记不住。后来换了个思路：先搭出全景图，再顺着算力、数据、训练、推理、平台这条链路逐个击破。这篇文章就是这条学习路线的完整记录。如果你正在做AI Infra相关的工作，或者打算入坑这个方向，希望这份笔记能帮你少走一些弯路。

1. 先对齐认知：AI Infra到底在解决什么问题

1.1 为什么这两年AI Infra这么火

我身边不少改行的朋友，一开始对AI Infra的理解就是"给算法工程师装驱动、配GPU、搭环境"。这个理解不算错，但至少是不完整的。AI Infra的核心不是"装环境"，而是解决一个根本矛盾：模型越来越大，算力需求越来越猛，而单颗芯片的算力增长是有限的，怎么把一堆芯片高效组织起来，让几百甚至上千张GPU像一台机器那样协同工作。

这个矛盾的直接推动力是大模型的参数规模。几年前跑一个几亿参数的模型，单机四卡基本能搞定；到了千亿参数这个量级，单机已经完全吃不下，必须拆到几十台机器上，分布式的复杂性一下子全都涌出来了。神经网络结构怎么切分、梯度怎么同步、通信拓扑怎么设计、显存怎么平衡，这些问题已经不是算法工程师能在代码层面解决的，需要系统层专门的方案。

另一个推动力是成本。GPU的价格摆在那里，利用率上不去就是烧钱。很多公司的GPU集群跑大模型训练，实际利用率能过50%就算不错，大量算力浪费在等待、空转和通信上。AI Infra要做的就是把这些浪费挤出来，让每一块GPU的每一分钟都在干活。

所以我更愿意把AI Infra定义为：面向AI工作负载（训练、推理、数据加工）的计算、存储、网络与调度系统的总称。它不是某一个开源项目，也不是某一个云产品，而是一整套把AI规模化落地的工程能力。

1.2 AI Infra的五大核心板块

我在整理学习笔记的时候，把AI Infra拆成了五个板块，这样学习起来不至于像无头苍蝇：

这五个板块不是孤立的，它们之间有很强的依赖关系。训练层依赖算力层提供的GPU资源，也依赖数据层把数据送到训练节点上；推理层和训练层共享算力池，但两者的调度逻辑完全不同。学习的时候顺着这条依赖链走，思路会清楚很多。

我的个人体会：如果只记一个关键词，那就是"弹性"。AI Infra的一切设计都在追求弹性——算力可伸缩、数据可流转、任务可调度、服务可扩缩。想清楚这一点，很多方案选型就有了底层解题思路。

2. 算力层：GPU调度与资源池化的底层逻辑

2.1 从GPU直挂到资源池化

算力层是整个AI Infra的地基，也是我学习时花时间最多的地方。先说一个最常见的误区：很多人以为GPU调度就是把几张卡分给任务，但实际上资源池化要解决的是"碎片化"问题。

最原始的做法是GPU直挂——每台物理机插8张卡，任务分配到具体机器上。这种模式最大的问题是：如果某个任务只需要2张卡，而机器上只有一些零散的空闲卡位，这些卡就很难被充分利用。再加上不同业务对GPU型号的需求不同，有的要训练卡，有的要推理卡，直挂模式很难做灵活的全局调度。

资源池化的思路是把所有物理机的GPU抽象成一个逻辑上的大池子，任务提交的时候由调度器决定它跑在哪台机器的哪些卡上。这个抽象层通常会引入Kubernetes，用Device Plugin把GPU作为可调度资源暴露给集群，任务以Pod的方式申请GPU资源。理解这个机制的时候可以打个比方：传统模式像你把服务器整台租出去，哪怕对方只用其中一小部分算力，剩下的也不能给别人用了；资源池化则像把服务器按CPU、内存、GPU拆成一块块积木，按需组装给不同任务。

还有一个绕不开的概念叫显存隔离。多任务共享同一张GPU时，如果不做隔离，一个任务可能把整张卡的显存打爆，导致其他任务被系统杀掉。常见的隔离方式有两种：一种是时间片共享，多个任务轮流用GPU计算，利用率高但可能引入性能波动；另一种是显存隔离，每个任务只用自己那部分显存，互不干扰但隔离粒度有限。实际生产环境里，两种方案经常混合使用，需要在利用率和稳定性之间取平衡。

2.2 调度器选型：Kubernetes原生调度 vs 专用调度器

我在做某跨平台系统模拟项目的时候，卡在调度器选型上很久。用Kubernetes原生调度器，优点是生态成熟、文档丰富，但面对AI任务有两个痛点：一是原生调度器的队列抢占能力弱，大任务和小任务混跑时容易互相卡死；二是对GPU拓扑感知不够，无法感知同一台机器上8张卡是通过高速互联（比如NVLink）还是PCIe总线互连，而这直接影响多卡任务的通信性能。

后来我看了不少业界方案，发现主要有两条路线：一条是在Kubernetes之上做增强调度器，支持Gang Scheduling（全有或全无调度）——这是训练任务的核心需求，你想让8个Pod在8台机器上同时启动，缺一个就全等着，而不是让先启动的那几个在那里空转。另一条路线是引入独立的作业调度系统，负责复杂的排队和优先级管理，Kubernetes只做资源托管。

这里给一个可落地的建议：如果你的集群规模在几十张卡以内，直接用Kubernetes原生调度器再加一个简单的配额控制就够了，额外引入专用调度器的学习和运维成本都不划算；到了百卡以上，一定要认真考虑Gang Scheduling和任务排队机制，否则你会频繁遇到"大任务占着资源不动，小任务排队等死"的僵局。判断标准就一条：你的任务是单卡就能跑的小作业多，还是动不动就要求16卡、32卡的整体资源？前者轻量调度够用，后者必须上增强调度。

2.3 异构算力调度的核心矛盾

异构是算力层绕不开的话题。训练卡、推理卡、通用计算卡，型号不同、架构不同、性能不同，怎么统一调度？

这里的核心矛盾是"效率优先还是灵活优先"。严格按型号调度，任务只能跑在特定机器上，集群的灵活性就差了；完全混跑，性能较差的卡会拖累整个集群的吞吐。实际工程里常见做法是给GPU打标签，按型号和代次分池，池内共享、池间按策略调度。比如训练任务优先进入最新一代训练卡池，推理任务进推理卡池，某些紧急任务可以跨池调度但会做降级标记。

还有一个细节经常被忽略：GPU监控。一开始我以为GPU监控就是看利用率，后来发现远不止。要关注显存带宽、功耗、温度、高速互联收发速率这些指标，很多效率问题只有看细粒度指标才能定位。比如训练吞吐突然下降，如果你只能看到GPU利用率100%，你根本分不清是计算饱和还是通信等待；但如果能看到NVLink的等待比例，就能很快判断是通信瓶颈还是计算瓶颈。没有监控的算力池，等于闭着眼睛开车。

3. 数据层：训练数据的流转与管理

3.1 数据管道的三个环节

说到数据层，很多偏系统方向的同学容易忽略它，但实际训练中数据往往是最大的瓶颈。数据层要解决三个环节的问题：数据从哪来、怎么存、怎么送。

"从哪来"对应数据采集和预处理。在大模型训练场景里，原始数据通常是PB级的文本或图文，先要经过清洗、去重、格式化，变成可以直接喂给模型的样本。这一步是计算密集型的，往往需要单独的预处理集群。我见过不少团队把预处理和训练混在一个集群上跑，结果是预处理任务吃光了CPU和内存，训练任务反而等数据，整体效率反而下降。

"怎么存"对应存储系统的选型。这里有个很关键的原则：训练集和原始数据要分离。原始数据量大、访问频率低，用对象存储最划算；训练时需要高吞吐读，要用并行文件系统或者高性能缓存层。很多团队的教训就是"把训练数据丢在对象存储上直读，训练速度被IO卡死"。对象存储适合的是顺序读大文件，而训练数据加载往往是大量小文件的随机读，这两者的IO模型完全不一样。

"怎么送"对应数据管道和缓存策略。训练节点要从远端拉取数据，网络带宽和IO延迟都是瓶颈。常见的优化手段是数据预取——在GPU算力工作之前，先把下一批数据在本地缓存好，隐藏IO延迟。生产级框架的数据加载器都支持多线程预取，这个细节对训练吞吐影响巨大。我自己实测过：同一个训练任务，预取线程数从默认1调到4，数据加载耗时至少缩短一半。

3.2 存储选型：并行文件系统与对象存储的分工

我整理了一个简单的选型对照，基本能覆盖大多数训练场景的需求：

实际项目中，数据管道的设计通常是三级：原始数据放对象存储，中间处理后的样本放并行文件系统，训练节点本地NVMe做预取缓存。三者通过数据编排工具联动，数据从一个层级流向另一个层级时，由编排工具负责触发和校验。

这里有一个我踩过的坑：checkpoint（模型检查点）的写入。大模型训练每隔一段时间就要写一次checkpoint，动辄几百GB，如果直接写到远程存储，训练要暂停很久，甚至导致集群网络拥堵。后来学到的方案叫"异步checkpoint"：先写本地NVMe，再由后台线程异步推到远端存储，让训练流程不阻塞。这个细节看着小，但对长时间训练任务的稳定性和故障恢复效率影响非常大——写一次checkpoint如果能从5分钟压到30秒，一个跑一个月的训练任务能省下好几个小时的停工时间。

3.3 数据版本管理与一致性

还有一个很多人不重视的问题：数据版本管理。模型训练需要可复现性，如果数据在训练过程中被改动，跑出来的结果就说不清楚了。代码要用版本管理软件管，数据同样要管理版本。业界常用做法是在数据目录上做快照或维护清单文件，每次训练记录数据集的ID、哈希和路径。这样即使三个月后要重新复现当时的效果，也能精确找回当时用的数据。

更进一步是数据血缘。在流水线里，上游数据变更要能触发下游任务的重新执行，出问题时要能顺着链条快速定位是数据处理BUG还是模型代码BUG。我在搭建模拟流水线时，因为没有做数据血缘，一次数据清洗逻辑的变动导致模型评估指标异常，排查了两天才发现是数据问题而不是模型问题。从那之后，我把数据血缘当作和代码版本管理同等重要的事情来对待。

4. 训练层：分布式训练的关键点

4.1 分布式训练的三种并行模式

训练层是AI Infra最硬核的部分。分布式训练的核心问题是：怎么把一个大模型拆到多张GPU上，同时让它们协调一致地训练。常见的拆法有数据并行、模型并行、流水线并行三种。

数据并行最好理解：每张卡持有完整的模型副本，喂不同的数据，定期同步梯度。优点是实现简单，张卡越多理论上训练越快；缺点是模型必须能放进单卡显存，一旦模型超过单卡显存，数据并行就走不通了。

模型并行是把模型按层或按算子切到多张卡上，每张卡只负责一部分计算。按层切叫流水线并行，各卡像工厂流水线一样依次处理一个batch的数据；按算子切叫张量并行，多卡共同计算同一个层的结果。实际大模型训练几乎都会混合使用这三种并行，这就是常说的3D并行。

具体怎么切，讲究很多。张量并行为了提高计算效率，通常会放在同一台物理机上——同一台机器内高速互联的带宽是跨机器的好几倍，所以做张量并行的卡尽量落在同一台机器内；流水线并行则相反，它更需要微批量调度和负载均衡的配合，避免某一段成为瓶颈。学习这部分时建议动手画一张并行切分图，把一个Transformer模型具体切成块分配到卡上，比死记概念有效得多。

4.2 网络拓扑与集合通信

如果说并行策略是训练层的"软件设计"，那集合通信就是"硬件和软件的接口"。分布式训练中，梯度同步、参数传播都依赖集合通信库的AllReduce、Broadcast等操作。通信效率直接决定训练加速比。

我见过太多次"明明加了GPU，训练时长没怎么降"的案例，根因基本都是通信瓶颈。通信瓶颈和网络拓扑强相关：同一台机器内部的高速互联，和机器之间的以太网或高性能网络，延迟和带宽差了一个数量级。设计集群时，要尽量把通信频繁的并行组放在同一台机器内部，把跨机通信量控制到最小。

这里可以做一个粗略的估算。假设一次梯度同步需要传输100GB数据，机器间网卡带宽是100Gbps（换算成字节约12.5GB/s），理论最短通信时间就是8秒；如果训练一个step总耗时是16秒，通信就占了50%，加卡几乎不会带来线性加速。估算扩展效率的方法很简单：先算出通信时间占一个step总时间的比例，这个比例越小，加卡越值。很多人不做这个预估，盲目把任务从32卡扩到128卡，结果发现吞吐没涨多少，成本和复杂度倒上去了。

4.3 训练任务的弹性与稳定性

训练任务往往是长时任务，一个小故障可能导致整个训练从头再来。所以弹性训练很重要——任务运行中某个节点掉线，要被自动替换并恢复。这里涉及checkpoint机制和资源预留策略的配合。

我学习时印象最深的是"预占式调度"：调度器保留一部分冗余节点，一旦主节点故障，备用节点立即顶上去，结合checkpoint恢复到最近的训练状态。这个设计让我意识到AI Infra其实也是可靠性工程，不只是性能优化。做训练平台的同学，建议从一开始就考虑故障恢复流程，不要等集群规模大了再补课——到那时节点类型、存储布局、数据依赖都已经固化，改起来代价非常大。

5. 推理与服务化：模型上线后的工程问题

5.1 推理优化的几个方向

训练是研发阶段，推理是上线阶段，两者的关注点完全不同。训练追求高吞吐和高资源利用率，推理追求低延迟和高并发。推理的瓶颈往往不是计算本身，而是模型体积、显存占用和请求调度。

推理优化的第一件事是模型压缩。常见手段有量化（把FP16模型转成INT8甚至更低精度）、剪枝（去掉不重要的参数）、蒸馏（用小模型学习大模型的能力）。量化是效果最直接的手段，性能提升通常是数倍。但量化也不是随便就能做的，模型训练算子的动态范围、激活值分布都会影响量化后的精度。

学习笔记里我特别标注了一个踩坑点：量化后的模型在部分算子上的精度回退。特别是涉及动态范围和异常值较多的算子，INT8量化很容易出现个别请求结果异常。后来采取的方案是"混合精度量化"——只对敏感性低的算子做8bit量化，对关键敏感算子保留16bit精度，推理速度和精度都兼顾了。这个案例很典型：优化不是一刀切，而是要看具体瓶颈和约束。

5.2 服务化架构与弹性伸缩

有了优化后的模型，下一步是把它封装成服务。业界主流方案是用模型服务框架托管模型，对外提供HTTP或RPC接口，自动处理请求排队、动态批处理和并发。动态批处理是推理服务最核心的技巧之一：把多个请求合并成一个大batch，提高GPU利用率。但batch太大会让响应延迟升高，所以需要根据实时流量动态调整batch大小和排队策略。

服务化之后必然面对弹性伸缩问题。推理服务有明显的潮汐特征，高峰期和低峰期流量差好几倍：按峰值扩容浪费资源，按均值扩容高峰时响应变慢。通用方案是基于GPU利用率或请求队列长度配置自动扩缩策略，同时保留一定量的预热实例，避免冷启动带来的超时。

冷启动问题是我踩过的坑。模型加载到GPU显存需要时间，新建Pod无法立即服务，所以每次扩缩时都会出现几十秒的延迟毛刺。后来通过"常驻模型镜像"和"预加载缓存"解决了大部分问题——提前把常用模型加载到备用实例上，流量一来就能立即响应。这个细节对线上推理服务的稳定性影响非常大，很多团队只关注扩缩策略本身的配置，却忽略了冷启动这个隐性成本。

5.3 推理服务的高可用与发布策略

推理服务直接面向线上流量，高可用要求比训练更高。要注意的是推理服务的无状态化设计：把模型文件、配置和运行时分离，这样才能快速扩容。同时要多版本发布能力，支持灰度发布和快速回滚。某次模拟项目里，新版模型效果评测时出现线上效果劣化，靠灰度发布快速回滚，保障了线上稳定。

这些工程能力看似"老生常谈"，但AI Infra语境下的实现细节差异很大。普通服务的版本管理管的是代码和配置，模型推理的版本管理要连同数据、环境、权重一起管，还要对模型本身的输入输出做评测比对。也就是说，模型上线不只是"部署一个新容器"，而是要回答"这个模型在真实流量下的表现是否真的更好"这个问题。没有灰度评测机制，模型迭代上线就是盲目的。

6. MLOps与平台化：把AI流程固化下来

6.1 端到端流水线

MLOps的核心目标是让AI流程可重复、可自动化。从数据准备、训练、评估、上线的全过程，都应该变成流水线中的一个环节，而不是靠人手动操作。流水线的设计逻辑是把每个环节封装成独立的组件，组件间通过输入输出接口连接。这样做的好处是：任何一个环节出问题，可以只重跑该环节，不必从头再来。

我学习时尝试搭建过一个模拟流水线，把数据清洗、训练、评估、推理服务几个步骤串了起来。最大的教训是：流水线设计时就要考虑失败恢复，而不是等失败后再补救。比如训练任务崩溃，流水线应该自动从最近的checkpoint恢复，而不是重新排队从零开始。这些细节如果不在设计阶段规划好，后面在每个组件里临时加逻辑，代码会变得一团糟。

6.2 可观测性建设

可观测性是我认为最容易"知道但做不到"的部分。GPU集群、训练任务、推理服务、数据管道，每个层级都要有监控指标、日志和链路追踪。监控不只要看"它挂了没有"，更要在"它没挂但变慢了"时能快速定位。

学会看训练任务的时间线拆分——数据加载占比、计算占比、通信占比——是我学AI Infra以来最有收获的一个技能。有一次训练任务吞吐下降，看整体监控全是绿的，只有拆了时间线之后才发现通信占比从10%飙到了45%，原因是另一个业务的流量占满了机器之间的网卡。这种问题如果不拆时间线，基本只能靠猜。

好的做法是建立统一的指标体系：把GPU利用率、显存占用、网络吞吐、训练吞吐、推理延迟这些指标打到同一个监控大盘上。出问题时，先看全局指标的变化趋势，再逐层下钻定位根因。这套方法论跟传统运维是相通的，但指标含义完全不同——比如网络吞吐高不一定是好事，可能是集合通信效率低导致的无效传输。

6.3 多租户与资源配额管理

平台化必然要考虑多人使用的问题。不同团队、不同项目共享同一个算力池，怎么避免"邻居吵到自己"？资源配额管理和多租户隔离就是解决方案。

我在学习时发现，配额管理不只是"给每个团队分多少卡"这么简单，还涉及优先级、抢占、资源预留这些策略的搭配。比如离线训任务和在线推理任务混跑，在线推理的SLA要求高，就需要在调度层面给推理任务更高的优先级，或者让推理任务独占一部分资源。如果配额管理只做数字分配，不做策略分层，整个集群一旦忙起来，线上服务立刻会被训练任务拖垮。

7. 学习路径与踩坑实录

7.1 我建议的学习顺序

最后这部分是我学习AI Infra的路径总结，给准备入坑的同学一个参考框架。我的建议顺序是：

1. 先跑通一个小规模的深度学习训练任务，亲身体会模型训练的基本流程、显存消耗和数据加载过程。
2. 再学Kubernetes基础，理解Pod、调度、资源配置这些核心概念，不碰AI相关内容。
3. 然后在Kubernetes上部署GPU运行环境，研究设备插件的原理，理解GPU是如何变成可调度资源的。
4. 尝试用多卡跑分布式训练，对比不同并行策略的通信开销和加速效果。
5. 逐步深入数据管理和推理优化，形成对全链路的认知。
6. 最后尝试构建端到端MLOps流水线，把前面学的全部串起来。

这个顺序的关键是"先有深度再有广度"——先把训练这条主链路跑顺，再横向扩展。太多人一上来就散着学各种组件，结果每个都是半吊子。

我踩过的一个大坑就是顺序反了：一上手就死磕Kubernetes网络插件和调度器源码，结果很多概念因为没有上下文而完全无法理解。后面调整成从业务需求出发，遇到什么问题就解决什么问题，才真正入了门。学习AI Infra最怕"只见树木不见森林"，先有全景图，再逐块深入，效率会高很多。

7.2 资源清单与实践建议

资料方面，我学习时主要依赖几类来源：官方文档（特别是Kubernetes和深度学习框架的官方手册）、知名公司的技术博客、开源项目的源码与Issue讨论。我的习惯是遇到问题先翻Issue而不是先搜解析文章，因为Issue里往往有最真实的踩坑记录，比二手转述靠谱得多。

实践建议只有一个核心：一定要自己动手搭一个最小闭环系统。哪怕只是"单机Kubernetes + 一张GPU + 一个小模型训练任务"的Demo，也比只读几十篇文章有用。我自己是在搭某个最小演示环境时，才真正弄懂了容器如何声明GPU资源、调度器如何分配显存、多Pod之间如何共享算力这些核心概念。不亲手部署一遍，看再多的架构图都只是纸上谈兵。

另外建议养成记录复盘的习惯。AI Infra的调试往往要跨多个子系统，不把排查过程记下来，下次遇到类似问题还是要从头开始。我的笔记里专门有一页记录"异常现象→可能原因→排查步骤→最终根因"的对照表，排查效率提升非常明显。这份内部沉淀，比在网上写再多的技术总结都更值钱。

最后再分享一个学习心态：AI Infra这个领域变化太快，今天的主流方案明天可能就被新项目取代，所以不要指望"学完"这件事，更不要因为某个技术没学会而焦虑。把每次遇到的新问题当作补全自己知识图谱的机会，等全景图补到一定程度，你会发现解决问题的能力会有一个质的飞跃。这些内容后续如果大家感兴趣，我大概率会先深入写调度器原理和推理优化的细节，到时再和大家继续聊。