企业官网建设流程全解析

前阵子团队把整套AI云基础设施的核心架构做了一次完整梳理，沉淀成了一份架构白皮书。很多朋友问我，AI云和传统云到底差在哪？为什么模型训练一跑就各种卡顿？资源池化怎么做才不浪费GPU？这份白皮书基本都能回答。今天我就把里面的核心思路、分层设计、关键选型和踩过的坑，从头到尾拆开讲一遍。

这份内容适合三类人看：一类是正在搭AI基础设施的架构师和平台工程师，另一类是天天跟训练任务打交道的算法工程师，还有一类是刚入行、想把AI云底层逻辑搞清楚的朋友。我尽量用大白话把复杂概念讲透，让不同基础的人都能收获一些东西。需要说明的是，白皮书里涉及的一些具体方案属于我在实际项目中的合理选型，你可以把它当作一个经过验证的参考模板，再结合自己的场景调整。

1. 为什么需要一张AI云基础设施架构图

1.1 传统云和AI云的差别到底在哪

很多人觉得AI云不就是"在云上装几个GPU嘛"，这个理解偏差挺大。传统云的核心资源是CPU、内存、磁盘，跑的是微服务、Web应用、数据库，这类负载的特点是"短小细碎"，高峰低谷波动大，靠弹性伸缩就能解决大部分问题。

AI云的核心资源变成了GPU、HBM显存、高速互联网络，跑的是大模型预训练、微调、推理服务。这类负载有几个跟传统云完全不同的特征：

第一，单个任务占用的资源量极大。一个大模型训练任务可能占用几十甚至上百张GPU卡，而且一跑就是几天甚至几周，中途不能随便停。

第二，任务对网络的要求极高。分布式训练需要频繁同步梯度，节点之间通信延迟稍微高一点，GPU利用率就会直线下降。

第三，数据访问模式完全不同。训练要反复读取海量样本，每次迭代都要把一批数据喂给GPU，数据管道的吞吐能力往往成为瓶颈。

所以，传统云架构里的虚拟化、网络模型、存储方案，搬到AI场景下很多都不适用。AI云基础设施需要从底层重新设计，这就引出了白皮书要解决的核心问题。

1.2 白皮书试图回答的几个核心问题

我们在梳理架构的时候，其实是在回答这几个非常具体的问题：

• 算力怎么池化？几十种不同型号、不同显存大小的GPU，怎么统一管理、按需分配，而不是一台台手工指派人去"抢卡"？
• 数据怎么高效流动？几百TB的训练数据，怎么让它们在正确的时间出现在正确的位置，不拖慢GPU计算？
• 任务怎么智能调度？用户提交一个需要64张卡跑一周的任务，系统怎么在几分钟内找到合适的资源、完成分配、启动运行？
• 故障怎么自动处理？GPU卡偶尔报错、网络闪断、节点宕机，系统怎么不影响用户任务，或者说尽量把影响压到最小？

这些问题的答案，最终都落到了分层架构上。

2. 整体架构设计的思路与取舍

2.1 分层模型：把复杂系统拆成清晰的边界

在这份白皮书里，我们把AI云基础设施从下往上分为五层，每一层各管一摊事，层与层之间通过标准接口对接。这个分法看起来很常规，但真要在落地时坚持住边界清晰，其实不太容易。

最底层是基础设施层，包括机房、供电、散热这些物理环境。这一层通常被忽略，但AI集群的功耗密度极高，单机柜跑到几十千瓦很常见，散热方案选不好，硬件性能就会降频，等于白花钱。

往上是硬件资源层，由GPU服务器节点、高性能存储节点、网络交换设备组成。这一层是物理资源的集合体，但还没有形成对外可用的"服务"。

再往上是资源池化层，这是整个架构里最核心的一层。它负责把分散的GPU、存储、网络资源包装成逻辑资源池，向上提供统一的资源视图。GPU驱动管理、设备虚拟化、资源隔离都在这一层实现。

再往上是平台服务层，包括作业调度、数据管理、监控告警、日志系统等。用户不直接接触物理资源，而是通过平台提交任务、分配资源、查看状态。

最顶层是业务应用层，跑的是各类训练框架、推理服务、数据处理流水线。工程团队在这一层跟算法团队对接。

这个分层有一个很大的好处：每一层都可以独立演进。比如底层GPU换新机型，只需要资源池化层适配驱动，上层调度和业务完全不用改；再比如调度策略要优化，也只需要改平台服务层，不碰底层硬件。

2.2 几条不能妥协的设计原则

分层结构只是骨架，真正决定架构好不好的，是设计原则。我们在白皮书里重点强调了这么几条。

第一条，控制面和数据面分离。计算资源的健康状态采集、任务调度决策、系统配置管理，这些都是控制面的工作，走的是低频小流量通道。而训练数据搬运、梯度同步、检查点写入，这些是数据面的大流量业务，专用通道承载。两者混在一起，就会出现调度消息跟训练数据抢带宽的尴尬局面。

第二条，资源解耦和故障域隔离。GPU资源池、存储资源池、网络资源池要逻辑上独立，任何一个池子出现问题，不能拖垮整个平台。我们还在物理层面做了故障域设计，比如同一个训练任务的节点尽量分散在不同机柜，避免一个机柜的电源故障导致整个任务挂掉。

第三条，能扩展就不等优化。AI基础设施的规模增长很快，架构设计的第一要务是"加节点就能扩"，而不是"性能瓶颈了再重构"。底层模块全部设计成无状态或者可水平扩展的模式，数据层的分片策略也在早期就定好。

第四条，不绑定单一厂商。GPU选型、网络方案、存储方案都要留出多选余地。单一厂商的封闭方案在初期很省事，后期扩容时要价高、交付慢，非常被动。

3. 计算层：异构算力池的落地细节

3.1 GPU资源池化：从"抢卡"到按需分配

在传统方式下，用户申请GPU就是管理员手工分配一台或几台机器，谁的需求大谁就能多占。这种方式在小规模集群还能勉强运转，一旦到了上百台GPU节点，就必须做资源池化。

资源池化要解决两个问题：看得见和分得清。看得见是指所有GPU节点的心跳、剩余显存、当前利用率、健康状态都要实时上报到资源管理模块。分得清是指每张GPU卡都要有唯一的资源标识，并且能独立调度。

这里就涉及一个关键选项：到底按"整卡"调度还是按"算力切片"调度。

整卡调度简单可靠——一个任务要2张卡就分配2张完整的卡，GPU之间互不干扰，性能和隔离性最好。但缺点也很明显，如果任务只需要半张卡的算力，另外半张就浪费了。

算力切片能提高利用率，但实现复杂度上了一个台阶。它需要GPU硬件虚拟化或者MIG之类的底层支持，还要做显存隔离、算力配额、故障隔离。切片粒度太细还有性能损失，并不是所有任务都适合。

我们的实践经验是：对生产环境的大模型训练任务，默认整卡调度，追求稳定性和可预期性能；对推理服务、小规模微调任务，可以用切片模式，提升资源利用率。两种模式在资源池里共存，通过标签区分，调度器按任务类型自动选择。

3.2 调度器选型与配额管理

资源池化完成之后，下一个问题是任务来了，谁来决定跑到哪里。这就是调度器的工作。

调度器在AI云里的角色，类似于一个繁忙机场的塔台。每个训练任务是一架要起飞的航班，每张GPU卡是一条跑道，调度器要综合考虑任务优先级、资源需求、数据位置、故障域要求，在几秒钟内做出分配决策。

我们采用的调度策略包含三个核心组件：队列管理、配额控制和优先级抢占。

队列管理是把用户或项目划分成不同的共享队列，每个队列有自己的资源上限。好比一个单位食堂分成几个窗口，每个窗口的菜量是固定的，互不挤占。

配额控制则是防止单个用户吃光所有资源。我们给每个队列设定CPU、内存、GPU三类配额，并且区分"已分配"和"已使用"两个维度，避免用户申请了资源不跑任务一直占着。

优先级抢占是提升资源利用率的有效手段。高优先级的任务可以排队等资源，也可以选择抢占低优先级任务的资源。这里注意，抢占不是简单粗暴地杀掉低优先级任务，而是先给低优任务一个宽限期保存状态、写检查点，然后再释放资源，尽可能减少损失。

4. 存储层：让数据跟得上训练速度

4.1 三种存储角色的分工

AI训练的数据流其实分成三条线：原始数据集、中间检查点、训练日志和产物。它们对存储的要求完全不同，用一套存储打天下肯定不行。我们在架构里设计了三种存储角色，各司其职。

高性能并行文件系统负责承载需要频繁随机读写的训练数据，比如样本集、检查点。它要有很高的聚合带宽和IOPS，能够同时支撑几百个训练进程并发读取。这种系统通常部署在独立的存储节点上，用高速网络跟计算节点互联。

对象存储负责大规模归档型数据，比如原始数据集、历史模型、日志备份。它的特点是容量大、成本低，但延迟较高、不适合频繁读写。训练之前，数据会从对象存储预取到高性能文件系统或者本地缓存，相当于把"冷数据"预热成"热数据"。

本地NVMe缓存是最靠近GPU的一层。每台训练服务器都配一块大容量NVMe盘，常用的数据样本可以直接从本地读，速度比走网络快一个数量级。这个缓存层不需要预先分配，命中率高了，整个训练管道的性能会明显改善。

这三层之间的关系，类似中央厨房、冷链仓库和炒锅边的调料盒：调料盒放常用的，冷链仓库放大批备货，中央厨房负责集中加工，各管一段。

4.2 数据集加速与检查点优化

很多训练任务跑不快，问题不在GPU而在数据管道。GPU算完一个batch的数据，下一次要用的数据还没准备好，GPU就只能空转等待。我们的经验是，必须有一条完整的数据加速链路。

第一步是数据集预热。训练任务提交时，平台自动把该任务用到的数据集从对象存储预取到高性能文件系统，如果数据集太大，则优先预取最近要用到的分片。

第二步是本地缓存预加载。工具会在每个计算节点启动时，根据数据访问特征把热数据拉一份到本地NVMe盘。这一步让数据读取从"网络IO"变成了"本地IO"，延迟大幅下降。

第三步是检查点写入优化。大模型训练经常要保存检查点，模型文件动辄几十GB甚至上百GB，同步写入共享存储会出现明显的IO风暴。我们采用的方案是异步检查点：训练进程把检查点先写到本地临时目录，由后台线程异步上传到共享存储，避免阻塞主训练流程。

5. 网络层：高性能互联的工程实践

5.1 为什么必须上RDMA

没有真正跑过分布式训练的人，很难理解网络对AI任务的影响。这里有个简单的概念：用多机训练一个大模型时，每算完一步，所有节点都要交换梯度数据。假设模型有100亿参数，每个参数是4字节，一次通信就要同步400亿字节，也就是40GB的数据。如果网络带宽只有25Gbps，一次通信要十几秒；换成100Gbps的RDMA网络，时间能缩短到十分之一以内。

所以AI云里的网络不是普通云的网络，它必须具备几项关键能力：高带宽、低延迟、低CPU开销。提到低CPU开销，就自然绕不开RDMA技术。传统TCP通信，数据收发要经过CPU多次拷贝和处理，CPU会被通信任务拖累，影响计算效率。RDMA允许数据直接在网卡和内存之间传输，CPU几乎不参与，训练时宝贵的CPU资源可以用来做数据预处理和其他辅助工作。

RDMA要跑得好，底层网络必须是无损网络。普通以太网在拥塞时会丢包，丢一个包就可能让RDMA通信重传一大段数据，性能断崖式下跌。所以网络设备要开启流控和拥塞通知机制，让交换机能感知拥塞并调节发送速率，做到"尽量不丢包"。

5.2 网络拓扑与故障域隔离

网络拓扑方面，大规模AI集群普遍采用叶脊（Leaf-Spine）架构。这个架构的好处是任意两个计算节点之间的网络跳数基本固定，不会因为接入位置不同导致通信延迟差异很大。在AI训练里，节点间通信延迟的一致性非常重要，试想同一个训练任务里，部分节点通信快、部分通信慢，快的节点就要一直等待慢的节点，整体训练效率被拉回到最慢节点水平。

叶脊架构的另一个好处是扩展性好。增加一组脊交换机，网络容量就能翻倍，扩容不需要改动现有布线，这对规模增长的AI集群非常友好。

故障域隔离是网络设计里容易被忽略的点。训练任务最好分布在同一个故障域内，这样内部通信快；但故障域也不能太小，否则一个交换机宕机，整个任务就挂了。我们的折中方案是：普通训练任务分布在同一个小网络区域，重要性高的任务则跨区域分布，依赖全局调度器做容错处理。每个任务都可以通过标签指定故障域策略，平台默认使用"同区域优先"。

6. 平台层：从资源到任务的调度链路

6.1 容器化与节点纳管

资源池化完成之后，还要解决"怎么把资源交付给用户"的问题。我们选择了容器作为资源交付的载体，而不是虚拟机。原因很简单：容器启动快、占内存少、性能损耗低，特别适合训练和推理这类对性能和启动速度敏感的工作负载。

容器在GPU节点上的运行，依赖一套设备插件机制。计算节点启动时，设备插件会向容器编排系统上报节点上有哪些GPU卡、显存多大、健康状态如何，编排系统才知道怎么调度。这一层如果出问题，典型的症状就是"节点显示Not Ready"或者"明明有卡但调度不上去"。

节点纳管还需要注意标签管理。我们会对每台节点打上多维标签：GPU型号、显存大小、驱动版本、所在机柜、所属网络区域。调度器在做决策时，通过标签匹配快速筛选出满足条件的节点集合，避免遍历整个集群。标签设计直接影响调度效率，这里建议大家在集群建设初期就制定统一的标签规范。

6.2 任务编排与弹性策略

用户在平台上提交的任务，通常需要经过三个阶段：排队、调度、运行。排队阶段看队列配额和优先级，调度阶段看资源和约束匹配，运行阶段看监控和容错。

任务编排层面，我们主要参考了批处理系统的作业模型，每个训练任务被封装成一个作业单元，支持依赖关系、重试策略、失败回滚等语义。这样用户在提交一个包含多个阶段的任务链（比如先预处理数据、再训练、再评估）时，平台能自动衔接，不需要人工干预。

弹性策略方面，传统的弹性伸缩在AI场景里并不完全适用。大模型训练任务通常需要固定数量的GPU卡，不能随意伸缩，缩小卡数模型就会报错。但推理服务非常适合弹性伸缩，可以根据请求量自动增减副本数，在流量波峰前提前扩容，波谷时回收闲置副本，节省成本。

7. 实践中的踩坑记录与排查思路

7.1 GPU利用率上不去的常见根因

GPU利用率低是运维同学最常见的困扰。你以为买了几百张卡在满负荷跑业务，一查监控发现平均利用率不到30%，钱全是白花的。

第一类原因是数据读取瓶颈。样本文件太大、读取路径不合理、缓存命中率太低，都会让GPU等着CPU喂数据。排查方法是观察数据管道的耗时占比，看GPU的等待时间是不是远超计算时间。如果是，优先优化数据集格式，把大量小文件打包成二进制大文件，并开启多线程预取。

第二类原因是通信瓶颈。多机训练比单机慢很多，通常都是互连网络顶不住了。排查方法是看训练日志里的通信耗时，如果通信时间占单步时间的比例超过20%，就要优化通信策略，比如梯度压缩、混合精度通信、通信与计算重叠。

第三类原因是负载不均衡。数据划分不均匀或者模型并行策略不当，会导致部分GPU在干活、部分GPU在等待。排查方法是看每个GPU的实际利用率曲线，如果曲线差别很大，就要调整数据切分策略或者重新设计并行方案。

7.2 存储系统的隐性陷阱

存储这块最坑的是元数据瓶颈。很多团队在存储选型时只看带宽和IOPS，忽略了元数据性能，结果一跑真实负载就暴露问题了。

典型场景是这样的：训练任务要读取一万个文件，每个文件不大，但数量极多。文件系统需要为每次文件打开操作处理元数据请求，这一万个请求一起来，元数据服务器直接过载，数据带宽再高也没用。这种现象在做数据集预处理或者加载检查点时特别常见。

我们的应对办法是：尽量让训练直接读取少量大文件，把海量小文件打包成一种专门的样本格式；元数据操作尽量异步化、批量化，不要逐个请求；访问热点目录时做目录缓存。这些优化加到一起，存储瓶颈问题能缓解一大半。

7.3 网络拥塞排查要抓的几个关键指标

RDMA网络出问题时，通常不会直接报错，而是表现为训练变慢、单步时间长。排查时要重点看三个指标：丢包率、流控计数、队列长度。

网络设备里，交换机端口的丢弃计数和流控计数能反映网络是否拥塞。如果某个端口的流控次数持续增加，说明这个端口的发送速率超过了接收端处理能力，需要检查是不是有多个节点同时在向同一个节点发数据。哈希不均也是常见原因：网络流被哈希到同一条链路上，导致某条链路拥塞而另外的链路空闲。解决办法是启用更均匀的流哈希算法，或者调整流的数量分布。

我把这些常见问题整理成了一个速查表，遇到类似情况可以直接对照排查：

7.4 一个值得注意的容错细节

最后分享一个比较容易忽略的容错细节：检查点保存的原子性。大模型训练跑了好几天，如果因为保存检查点过程中断而没能恢复，这个损失是无法接受的。检查点保存时如果直接把新文件覆盖旧文件，万一写一半系统崩溃，旧文件也没了，新文件也不可用，整个训练等于前功尽弃。

我们采用的方案是两阶段保存：先把检查点写到临时文件，完整写入并校验后，再通过原子重命名替换旧检查点。这样无论任何时候系统崩溃，至少有一个完整的检查点文件存在，训练可以从最近一次成功的保存点恢复。经验证，这个小改动是大模型训练稳定性最关键的保障之一，强烈建议每个AI平台都默认开启。

从整套架构的梳理到最终白皮书成型，我们在实际运营中走了不少弯路，也积累了不少心得。早期我们一度倾向于接入各种厂商的解决方案，之后慢慢发现真正决定AI基础设施成败的，往往不是某一项炫酷技术选型，而是像故障域设计、数据加速路径、检查点保障这些基础工程细节。如果你正准备搭建或者已经运行着类似的AI云平台，建议先别急着追新概念，把分层边界理清楚，把资源池化、存储链路、网络无损这几块地基打牢固，上层业务扩展都会顺畅很多。