白皮书我们内部叫它黑皮书黑色封面白色标题从立项到定稿前后迭代了七个版本才把AI云基础设施的核心架构讲到一个我们自己觉得能见人的程度。发布之后收到最多的私信不是夸内容而是问设计决策的过程算力池为什么这么切网络为什么选无损方案而不是传统TCP容错为什么不能简单靠多存几份检查点这些问题其实比白皮书本身更有价值。所以这篇文章我就把核心架构背后那些为什么单独拆出来讲适合正在搭建AI训练平台、扩容GPU集群、或者被分布式训练稳定性问题反复折磨的工程师和架构师参考。哪怕你还没有自己的集群读完也能理解那些看起来平平无奇的架构选择到底是在防什么。1. 白皮书要解决的三个问题算力闲置、故障放大与成本失控1.1 三个问题其实是同一个问题我刚接触AI基础设施时有一个很深的感触大部分团队并不是不知道GPU算力贵而是根本说不清楚算力到底浪费在哪里。最后统计出来的GPU利用率一看挺高训练时显存也是满的但真正的有效计算时间可能只有一半。这个差距来自三个叠加的因素。一是单卡利用率。很多人以为把代码搬到GPU上就是加速实际上数据读取代价、通信等待、算子串行都会让单卡利用率打折扣。二是集群层面的资源碎片。卡闲着不是因为没有任务而是任务调度不上来有的等资源有的等网络有的等存储。三是故障导致的重算。训练已经跑到一大半一次节点宕机把几十个小时的成果清零这是最隐蔽也最致命的浪费。这三个问题在我的观察里其实是同一个问题基础设施没有为长时运行、强通信、大状态的AI训练负载做过专门的架构设计。传统云基础设施是为微服务设计的追求快速启停、弹性扩展和水平扩容而AI训练恰恰相反它需要的是稳定、连续、可恢复。这个错位就是白皮书最想讲清楚的第一件事。1.2 传统云架构为什么会错位传统虚拟化架构把资源切成很小的单元一个容器起一个进程挂了就重启流量分摊到多个副本这套模型在Web服务场景里非常成熟。但训练任务不一样。大模型训练是一个有状态的长时间作业参数分布在一堆卡上彼此之间要做梯度同步通信模式是全局的、同步的任何一个卡掉了整个任务就要卡死或者中断。虚拟机热迁移、容器重建这套机制在训练场景下不但帮不上忙反而可能因为资源抢占、网络抖动引入新的不确定性。比如热迁移要拷贝内存状态训练任务的内存里有大量的通信缓冲区迁移过程会让训练卡住几分钟再比如容器重建后新进程要重新建立和所有其他节点的连接期间其他节点都在空等。所以白皮书后面的所有设计都遵循一条原则把稳定性当第一公民把弹性往后放。这句话听起来简单做起来要推翻很多传统云平台的默认假设。后面几节讲的算力池化、网络组网、存储分层、容错设计全部都是从这条原则长出来的。2. 算力池化从裸金属交付到统一资源抽象2.1 三种池化形态的适用边界AI云基础设施第一个要回答的问题是算力怎么交付。早期很多平台直接做裸金属把整台GPU服务器租给用户简单直接但碎片化严重。一个大模型训练要八张卡一个推理服务只要半张卡剩下的卡只能空转。一份白皮书如果只讲裸金属那就没有存在的必要了。我们花了大量篇幅把算力交付分成三种形态。表格交付形态隔离粒度性能损耗参考适用场景物理整卡/整机物理隔离无损耗大规模训练、对稳定性要求极高的场景虚拟化切片细粒度5%-15%推理、小规模微调、开发测试环境容器级动态调度动态调配1%-3%混合负载、弹性扩缩容、数据处理任务我想特别强调容器级调度这一栏的性能损耗。它其实不是来自容器本身而是来自调度策略。如果一台物理机上有两张卡被切给两个训练任务共享了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承载无损网络高低中高传统TCP以太网中高低低RoCEv2是成本和性能的平衡点很多团队都会选它但它的运维复杂度是最高的高在拥塞控制上。RoCE想跑出接近专用网络的性能前提是网络里不能丢包一旦因为拥塞发生丢包性能会断崖式下跌。为了做到不丢包网络设备必须启用PFC和ECNPFC负责链路级的流量暂停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 配额如何与成本账单联动多租户治理里还有一个容易被忽略的配套系统配额和账单必须联动。我们按占用量乘以时长计算配额占用成本而不是按实际有效计算量。这样做的原因是如果按有效计算量计费大家都会倾向于占住资源不用反正高峰期闲着也不花钱。而按占用计费之后团队会主动释放不再需要的算力资源利用率的提升是立竿见影的。当然这个策略也不能一刀切否则夜间批量训练任务就没人愿意跑了。我们又加了一个时间段折扣工作时段按标准价夜间和周末按折扣价把非紧急的训练任务引导到低峰期。上线这个策略之后白天高峰期的资源争抢明显减少夜间集群的空置率也大幅下降图纸上算的账落到实处是真能省钱的。写在最后的一个小建议写完这套架构我最想给后来者的建议其实很小不要一开始就追求完美的调度器和复杂的容错体系。先跑通一个最小可复现的架构——一台机器、两张卡、一套最基础的检查点和恢复流程然后在一次真实故障里验证恢复时间。白皮书里的每一章在我看来都是从这个最小闭环里长出来的。你先把挂了能恢复、恢复不丢数据、数据有地方放这三件事做扎实再谈池化、谈多租户、谈成本治理都不迟。如果非要给一个优先级我的建议是容错优先于弹性数据管道优先于调度策略可观测性优先于优化。这是我踩过太多坑换来的体会也是这份白皮书最想传递的东西。
