企业官网建设流程全解析

白皮书我们内部叫它"黑皮书"，黑色封面，白色标题，从立项到定稿前后迭代了七个版本，才把AI云基础设施的核心架构讲到一个我们自己觉得能见人的程度。发布之后收到最多的私信不是夸内容，而是问设计决策的过程：算力池为什么这么切？网络为什么选无损方案而不是传统TCP？容错为什么不能简单靠多存几份检查点？这些问题其实比白皮书本身更有价值。所以这篇文章我就把核心架构背后那些"为什么"单独拆出来讲，适合正在搭建AI训练平台、扩容GPU集群、或者被分布式训练稳定性问题反复折磨的工程师和架构师参考。哪怕你还没有自己的集群，读完也能理解那些看起来平平无奇的架构选择，到底是在防什么。

1. 白皮书要解决的三个问题：算力闲置、故障放大与成本失控

1.1 三个问题其实是同一个问题

我刚接触AI基础设施时有一个很深的感触：大部分团队并不是不知道GPU算力贵，而是根本说不清楚算力到底浪费在哪里。最后统计出来的GPU利用率，一看挺高，训练时显存也是满的，但真正的有效计算时间可能只有一半。这个差距来自三个叠加的因素。

一是单卡利用率。很多人以为把代码搬到GPU上就是加速，实际上数据读取代价、通信等待、算子串行都会让单卡利用率打折扣。二是集群层面的资源碎片。卡闲着不是因为没有任务，而是任务调度不上来，有的等资源，有的等网络，有的等存储。三是故障导致的重算。训练已经跑到一大半，一次节点宕机把几十个小时的成果清零，这是最隐蔽也最致命的浪费。

这三个问题在我的观察里，其实是同一个问题：基础设施没有为"长时运行、强通信、大状态"的AI训练负载做过专门的架构设计。传统云基础设施是为微服务设计的，追求快速启停、弹性扩展和水平扩容，而AI训练恰恰相反，它需要的是稳定、连续、可恢复。这个错位，就是白皮书最想讲清楚的第一件事。

1.2 传统云架构为什么会错位

传统虚拟化架构把资源切成很小的单元，一个容器起一个进程，挂了就重启，流量分摊到多个副本，这套模型在Web服务场景里非常成熟。但训练任务不一样。大模型训练是一个有状态的长时间作业，参数分布在一堆卡上，彼此之间要做梯度同步，通信模式是全局的、同步的，任何一个卡掉了，整个任务就要卡死或者中断。

虚拟机热迁移、容器重建这套机制，在训练场景下不但帮不上忙，反而可能因为资源抢占、网络抖动引入新的不确定性。比如热迁移要拷贝内存状态，训练任务的内存里有大量的通信缓冲区，迁移过程会让训练卡住几分钟；再比如容器重建后，新进程要重新建立和所有其他节点的连接，期间其他节点都在空等。

所以白皮书后面的所有设计都遵循一条原则：把稳定性当第一公民，把弹性往后放。这句话听起来简单，做起来要推翻很多传统云平台的默认假设。后面几节讲的算力池化、网络组网、存储分层、容错设计，全部都是从这条原则长出来的。

2. 算力池化：从裸金属交付到统一资源抽象

2.1 三种池化形态的适用边界

AI云基础设施第一个要回答的问题是：算力怎么交付。早期很多平台直接做裸金属，把整台GPU服务器租给用户，简单直接，但碎片化严重。一个大模型训练要八张卡，一个推理服务只要半张卡，剩下的卡只能空转。一份白皮书如果只讲裸金属，那就没有存在的必要了。我们花了大量篇幅把算力交付分成三种形态。

表格：

我想特别强调容器级调度这一栏的性能损耗。它其实不是来自容器本身，而是来自调度策略。如果一台物理机上有两张卡被切给两个训练任务，共享了PCIe带宽和内存带宽，互相干扰造成的损耗可能远超虚拟化开销。所以白皮书给出的建议是：物理整卡优先保证训练作业，切片和容器级主要用于推理和辅助任务，并且不要混部在同一个NUMA节点上。

2.2 调度设计：成组调度与优先级抢占

算力池化之后，调度器就变成了核心中的核心。训练作业有一个关键特点：需要成组调度。一个训练任务需要同时拿到N张卡才能启动，只拿到一张卡毫无意义。如果调度器不感知这一点，就会出现大量任务被部分分配、互相等待的死锁情况。

我们最终采用了两层调度策略。第一层做应用级的成组判断，任务必须凑齐整组资源才能被投放到某个节点集合；第二层在节点内做拓扑感知，把同一任务的卡尽量放到同一个交换机域下，减少跨机通信。优先级抢占也做了设计，但不是简单的高优吃低优，而是支持"挂起再恢复"：被抢占的任务把显存状态冻结起来，等资源空出来再恢复，而不是直接杀掉重跑。这个改动让我们的抢占损耗降低了将近一半。

一个简化版的调度策略配置大概是这样的：

调度策略: 成组调度: 最小卡数: 8 最大等待时间: 30分钟 拓扑亲和: 同一接入交换机下优先 抢占规则: 允许抢占: true 抢占方式: 挂起-恢复 受保护的作业标签: ["critical", "paid"]

这里有几个细节值得展开。最小卡数如果设置太高，小任务永远等不到资源；设置太低又会导致成组意义消失。我们最后是按业务线分别配置，训练线默认8卡起步，数据预处理线只要2卡。受保护作业标签也很关键，付费用户和核心业务的作业不能被抢占，否则恢复流程再快，用户体验也是崩的。

3. 网络层：RDMA组网与拥塞控制的工程化落地

3.1 为什么网络是训练场景的命门

很多刚接触AI基础设施的人会低估网络的重要性，觉得训练就是算力的事。但实际上一旦模型规模上去，通信就变成真正的瓶颈。Transformer类模型在分布式训练中，每一轮迭代都要做梯度同步，模型规模越大，同步的数据量越大。如果用传统TCP网络，带宽上不去、延迟不稳定，训练效率会被通信彻底拖死。

白皮书里我们做了一个实测对比：在相同规模的训练集群里，用TCP组网和用无损网络组网，一个百亿参数模型的单次迭代时间差距接近三倍。这个差距不是玄学，是通信协议的机制决定的。TCP面向可靠传输，丢包就重传，重传就意味着毫秒级的等待，而梯度同步在高频次下根本经不起这种等待。每轮迭代多等几十毫秒，乘以上亿次迭代，就是灾难。

3.2 两种无损方案的选择与PFC风暴教训

无损网络有两条技术路线：专用无损网络和基于RoCEv2的承载方案。表格里的对比可以一目了然：

RoCEv2是成本和性能的平衡点，很多团队都会选它，但它的运维复杂度是最高的，高在拥塞控制上。RoCE想跑出接近专用网络的性能，前提是网络里不能丢包，一旦因为拥塞发生丢包，性能会断崖式下跌。为了做到不丢包，网络设备必须启用PFC和ECN，PFC负责链路级的流量暂停，ECN负责向发送端反馈拥塞信号。这两个参数要是没调好，就会引发PFC风暴——一个端口的流量暂停扩散到整条链路，最后整个集群的训练都在互相等待。

我们踩过这个坑。一次调整网络拓扑之后，某个交换机端口的PFC暂停帧计数持续飙升，整个集群的训练吞吐掉了一半。排查下来是ECN阈值配置不当，拥塞信号没有及时触发，发端依然在满速发送，接收端的缓冲区被打满，只能靠PFC硬停。调整阈值之后，暂停帧数量恢复正常，吞吐也回来了。这条经验后来被直接写进白皮书的运维章节：任何一次网络变更，都要同时检查PFC计数、ECN标记率和重传率三个指标。

注意：PFC风暴的典型症状是集群整体性能缓慢恶化，而不是直接宕机，所以很多团队发现不了。监控面板上一定要把这个指标单独拉出来看。

4. 存储与数据管道：把"等数据"的时间压到最低

4.1 检查点带来的读写压力模型

训练场景的存储压力跟Web服务完全不同。Web服务读写小对象，追求低延迟，缓存命中率是第一指标；训练读的是大文件数据集，要的是高带宽顺序读。更麻烦的是检查点：训练到一半要定期把模型状态落盘，一个百亿模型的检查点，存储量能到几十TB量级。如果检查点太频繁，存储会被写爆；如果太稀疏，故障后的重算代价太大。

白皮书里给了一个很简单的计算模型：假设单次检查点写出量为S，检查点频率为f，每秒固定写带宽占用就是S×f。拿一个几TB的模型算一下，如果每十分钟存一次，平均写带宽需求就接近每秒几十GB。这个数字对任何存储系统都是压力。

所以架构上我们做了双轨设计：常规训练场景用并行文件系统承载大数据集的顺序读，检查点写入走另一条独立的高吞吐通道，避免两类IO互相干扰。检查点文件写完后，再做异步复制到远端，保证本地故障时数据不丢。这个分离设计，比在单一存储里反复调参要省心得多。

4.2 数据供给链的三层缓存设计

数据读取是另一个容易忽视的天花板。训练数据集往往放在对象存储里，但如果每个训练节点都直接去对象存储拉数据，带宽立刻被占满，而且延迟不稳定。白皮书给出的方案是三层缓存：热数据落在本地NVMe盘，温数据落在高速分布式缓存，冷数据才从对象存储拉取。数据加载器再加一层预取逻辑，把网络传输和模型计算重叠起来——GPU在算的时候，下一个batch的数据已经在路上了。

这个设计我在多个团队里见过变体，但大多数实现都卡在缓存一致性问题上。其实训练数据的缓存一致性比业务场景简单得多，因为训练数据集基本是只读的，唯一的变数就是shuffle顺序。所以我们干脆放弃了复杂的一致性协议，只在缓存层记录数据集的版本号，迭代版本就整批淘汰重拉。简单粗暴，但效果非常好，读性能稳定，代码量也少。

数据预取的细节也值得一提。预取的深度不能盲目加大，预取太深会占满内存，导致模型训练本身的显存和内存分配出问题。我们按batch大小和单batch处理时间做了一个简单的流水线预算：预取深度等于处理时延除以数据到达时延的比值向上取整，再乘以0.8的安全系数。这个参数我们测试了多种组合，最终固定为常用配置，不同业务线只需要调整batch大小即可。

5. 故障域与容错：一次断点续训事故的完整复盘

5.1 十七个小时训练只保住七个小时

白皮书里有一章专门讲故障，我最想写的就是这个复盘。事情发生在一个实验性训练任务上，模型规模不大，但我们把它同时跑在多个集群节点上，想验证跨集群训练的可行性。训练进行到第17个小时的时候，某个节点的存储盘出现IO错误，训练进程直接崩溃。按理说有检查点保护，从最近的检查点恢复就行，大家一开始也没太当回事。

但问题恰恰出在一个容易被忽略的细节上：检查点数据被写进了同一个故障存储域。更准确地说，有四个副本，分布在不同的故障域，按说足够安全。但恢复逻辑有缺陷——它读取检查点元数据的时候走了缓存，拿到的是过期版本，于是把后续几个小时的训练结果当成垃圾数据，直接回滚到了更早的检查点。

最后的结果是：十七个小时的训练，只保住了前七个小时的成果。复盘时我们发现，问题不在数据冗余不够，而在恢复路径上的数据一致性设计。白皮书专门加了一节，标题就叫"检查点不是存了就行，还要测恢复"。从那以后，每个版本的恢复流程都必须做一次完整的故障演练，演练内容包含元数据过期、副本损坏、网络分区三种情况。

5.2 三层容错体系的设计思路

那次事故之后，我们把容错体系分成了三层，每一层对应不同的故障范围和恢复目标。

我们真正想强调的是，容错设计不是把单点做结实，而是要让每一层都知道上一层会怎么兜底。任务层重启的时候，要知道节点层马上会做什么；节点层恢复的时候，要清楚集群层的数据冗余情况。这样层层配合，才不会出现各管各的、最后一堆问题抛回给用户的情况。

为了实现这个目标，白皮书里设计了一个统一的故障上报接口：所有容错事件都带上故障域标识和影响范围，调度器和恢复控制器订阅这个事件流，各自做各自的动作。这个事件流只做记录和通知，不做强一致保证，因为容错动作本身已经由各层负责了。事实证明，把接口设计得比想象中更简单一些，反而让整个容错链路更容易维护。

6. 多租户与成本治理：共享集群里的分蛋糕法则

6.1 配额加加权公平共享，怎么落地不吵架

AI云基础设施对外提供服务之后，一个躲不开的问题就是多租户。不同团队都想要算力，但资源就这么多，怎么分永远会吵。白皮书里的方案是配额加加权公平共享。每个团队有一个基础配额，这是保底；配额用不满的时候，可以共享弹性的"空闲算力池"。使用量越少的团队在空闲池里的权重越高，避免大团队永远霸占空闲资源。

这个机制听起来公平，实际落地时最难的却是另一件事：怎么定义"使用量"。我们最后决定用"配额占有率"而不是绝对值，因为不同团队申请的配额本身差异就很大。某团队申请了一百张卡用了五十张，占有率是50%；另一个团队申请十张卡用了十张，占有率是100%。在空闲池的调度上，后者的优先级更高。这套规则上线之后，关于资源分配的争论明显变少了，因为所有人都知道规则是公开的、可解释的。

6.2 AI场景下的弹性伸缩，究竟该伸缩什么

最后说成本治理里一个反直觉的地方。很多人以为AI云平台也要像Web服务那样做秒级弹性伸缩，实际上训练作业的伸缩非常痛苦，动不动就涉及检查点迁移和状态重分布。几分钟的弹性周期在训练任务里毫无意义——训练一次迭代可能就要几十秒，等你把资源调配好了，大批训练已经结束了。

白皮书的结论是：把弹性放在作业维度，而不是实例维度。具体做法是，当一个训练任务结束后，下一批任务自动根据当前的空闲资源、优先级和预估时长做组合投放；运行中的任务不做频繁伸缩，为了省一点资源去打断一个正在稳定迭代的训练任务，往往得不偿失。这个策略让我们的整体资源利用率稳定提升了十几个百分点。

注意：AI集群的成本治理，最大的敌人不是碎片，不是弹性不足，而是频繁无意义的启停。每停一次任务，前面的累积计算收益都在归零。

6.3 配额如何与成本账单联动

多租户治理里还有一个容易被忽略的配套系统：配额和账单必须联动。我们按"占用量乘以时长"计算配额占用成本，而不是按实际有效计算量。这样做的原因是，如果按有效计算量计费，大家都会倾向于占住资源不用，反正高峰期闲着也不花钱。而按占用计费之后，团队会主动释放不再需要的算力，资源利用率的提升是立竿见影的。

当然，这个策略也不能一刀切，否则夜间批量训练任务就没人愿意跑了。我们又加了一个时间段折扣：工作时段按标准价，夜间和周末按折扣价，把非紧急的训练任务引导到低峰期。上线这个策略之后，白天高峰期的资源争抢明显减少，夜间集群的空置率也大幅下降，图纸上算的账，落到实处是真能省钱的。

写在最后的一个小建议

写完这套架构，我最想给后来者的建议其实很小：不要一开始就追求完美的调度器和复杂的容错体系。先跑通一个最小可复现的架构——一台机器、两张卡、一套最基础的检查点和恢复流程，然后在一次真实故障里验证恢复时间。

白皮书里的每一章，在我看来都是从这个最小闭环里长出来的。你先把"挂了能恢复、恢复不丢数据、数据有地方放"这三件事做扎实，再谈池化、谈多租户、谈成本治理都不迟。如果非要给一个优先级，我的建议是容错优先于弹性，数据管道优先于调度策略，可观测性优先于优化。这是我踩过太多坑换来的体会，也是这份白皮书最想传递的东西。