上周在机房盯着一个训练任务跑批同事发来消息说优刻得的国产千卡智算集群落地了而且已经在给智源研究院的千亿大模型训练提供算力。我当时的第一个反应不是兴奋而是下意识想问一句它到底跑得稳不稳在分布式训练圈子里待久了你会对“XX卡集群”这种字眼本能地警惕。一千张加速卡放进机房只是开始真正的考验是这一千张卡能不能在同一个训练任务里像一台机器一样协同工作并且在几十天的训练周期里保持稳定。这篇文章不打算复述新闻稿而是从实战角度拆解几个问题千亿模型训练为什么非千卡不可国产智算集群在工程上要比传统方案多付出什么从千卡到万卡后面的难点又会怎么变无论你是算法工程师、平台研发还是数据中心规划者只要对大规模AI基础设施感兴趣这篇都应该能给你一些参考。1. 千卡集群不是“一千张卡插在一起”算力与通信背后的硬约束1.1 千亿参数模型为什么必须上集群很多人对“千亿大模型”没有直观概念。拿175B这个量级的模型来说大约1750亿个参数。训练这类模型业界常用一个近似公式估算计算量在一次前向加反向传播中每个token每个参数大约需要6次浮点运算。假设训练数据规模是3000亿个token那总计算量就是6 × 1750亿 × 3000亿 3.15 × 10^23 FLOPs这是什么概念一张高端的AI加速卡标称算力可能到几百甚至上千TFLOPS但真实训练中因为访存瓶颈、算子开销、通信等待能稳定跑出300 TFLOPS已经很不错。按3×10^14 FLOP/s来算单卡跑完这一轮训练需要超过30年。哪怕凑出100张卡也要跑一百多天迭代一次实验的周期长得完全不可接受。所以千亿模型训练必须上大规模集群而且不是“能跑就行”是在合理时间窗口内跑完。千卡规模只不过是入场券。我记得有次做方案评审一个客户问“100张卡够不够训千亿模型”我们算了一遍之后直接否了显存放不下算力时间也不允许。千卡这个数字是需求和物理规律逼出来的。1.2 训练过程中的通信压力往往比算力更致命有了千卡下一个问题就是你打算怎么让它们协同工作。最朴素的做法是数据并行每张卡保存一份完整的模型参数各自吃不同的batch数据算完梯度后用AllReduce把梯度汇总、求平均再一起更新参数。这里就藏着一个巨大的工程坑。对175B参数规模的模型来说梯度本身就有350GB左右按BF16计算。千卡一起做一次AllReduce网络里要搬运的数据量接近700GB。就算给你100Gbps的高速网络理论传输时间也要将近一分钟。好在实际训练中会做梯度分桶、通信计算重叠让通信发生在反向传播的同时但通信带宽和延迟依然是决定训练效率的核心变量。换句话说千卡集群里最贵的不是卡而是那张网。很多团队用单机八卡训练时没有感觉因为卡间走NVLink带宽高、延迟低。一旦扩到跨节点走的就不再是NVLink而是RoCE或者InfiniBand网络。网络拓扑怎么设计、拥塞怎么控制、集合通信库能不能识别到具体拓扑每一项都直接决定你的千卡能不能跑出八卡线性扩展的效果。1.3 国产平台给工程提出的额外要求如果用的是成熟的进口方案底层有CUDA、NCCL这套非常完善的软件栈帮忙兜底应用层基本不用关心网络拓扑、集合通信这些细节。国产AI加速卡的处境更像“给你一堆高性能零件但装配工艺和调校逻辑得自己摸索”。驱动要适配、算子库要补齐、集合通信库要针对国产网络重新实现连PyTorch的版本兼容都可能踩坑。这不是说国产不行而是说国产平台需要投入更多工程力量去“打磨”。优刻得能把这个集群用到智源千亿大模型训练上说明他们至少跨过了从“硬件能点亮”到“训练能跑起来”再到“跑得高效稳定”这三道坎。这个过程外人很难从参数表上看出来。2. 优刻得这次国产千卡集群解的是算力底座的哪些题2.1 云厂商和研究院的组合为什么值得关注智源研究院是国内最早做大模型研究的机构之一他们训练千亿模型有非常具体的算力需求。而优刻得是中立云计算厂商做这件事的逻辑不是“造个硬件摆着看”而是要把算力变成可对外提供的服务。两个角色凑到一起等于把一个真实的训练负载放到一套国产化的基础设施上跑。这不是实验室里的POC概念验证是有业务压力的。我比较看重“中立云”这个定位。现在不少云厂商自己也在做大模型既做运动员又当裁判别的客户把模型和数据放上去多少有点顾虑。优刻得不碰大模型应用层专注做算力底座反而更容易和大模型研究机构建立信任。智源选它也有这层逻辑在里面。2.2 算力、网络、存储三大件怎么选怎么配千卡智算集群的核心就三块算力、网络、存储。任何一个环节掉链子训练效率都会大打折扣。先看算力。国产加速卡这几年进步很快但要跑千亿模型必须支持BF16/FP16混合精度并且要能在长时间高负载下维持稳定频率。很多卡“峰值算力”看着不错一跑长时间训练就降频、过热这是实际选型时最需要关注的点。再看网络。千卡规模下建议用25G/100G以上的RDMA网络并开启无损网络特性。RoCEv2方案在国产集群里比较常见但前提是交换机的PFC、ECN这些流控机制配置正确。曾经遇到过一次诡异现象训练速度时快时慢排查到最后发现是某个交换端口的ECN阈值设置不对拥塞信号没有及时触发导致网络延迟抖动剧烈。存储也不能忽视。千亿模型训练会定期保存checkpoint一次可能就是几百GB到数TB的数据量。如果存储的写带宽不够checkpoint保存期间训练就得停下来等等于白白浪费算力。分布式并行文件系统、足够的数据节点、万兆以上的客户端网络这些都是标配。核心组件关键诉求常见实现方案算力混合精度支持、长时间高负载稳定国产AI加速卡具备高速显存/HBM网络高带宽、低时延、无丢包RoCEv2无损网络或InfiniBand存储高并发写带宽、大容量、高可靠分布式并行文件系统横向扩展配套散热、供电、机房改造液冷/风冷结合模块化UPS这套东西单拎出来任何一项都不算新鲜难的是把三者揉成一个整体。尤其是国产软硬件生态还没有那么成熟很多兼容性问题要现场一点点调。2.3 落地验收看什么三个比参数更重要的指标新闻稿可以说“千卡集群落地”但做工程的人不能只看卡数。我会看三个指标。第一是加速比。从256卡扩展到1024卡算力理论翻四倍实际吞吐能不能到三倍以上通信占比一旦控制不好卡越多纸面算力越高实际收益反而越差。第二是MFU模型浮点利用率。这是衡量芯片算力被利用了多少的指标千亿模型训练能做到40%以上已经算优秀。MFU太低的话说明集群的设计存在明显瓶颈。第三是连续稳定运行时间。真正有价值的集群不是跑一个benchmark漂亮而是能撑住几十天不断。哪怕中间有卡故障也要能做到快速隔离、自动重启训练任务。优刻得这次支持的是智源千亿大模型训练这个负载本身就是在给集群做压力测试。3. 千亿参数训练如何在国产集群上跑起来并行策略与软件适配3.1 三种并行一起上数据、张量、流水线千亿模型放到千卡上跑通常不会只用单一并行策略而是把数据并行、张量并行、流水线并行组合起来用。数据并行前面说过每张卡持有完整模型副本适合扩大batch size。但千亿模型的参数和优化器状态加一起要几个TB单卡显存放不下所以必须在模型内部做切分。张量并行就是把Transformer某一层的矩阵按行或者按列切到多张卡上让一张卡只存一部分权重。流水线并行则是按层切分把不同层分给不同的计算节点减少单节点的显存压力。一个典型的切法可能是张量并行8卡处理单层计算流水线并行16组划分网络层数据并行跑8路整体用掉1024张卡。具体怎么切要根据模型结构、显存容量和网络拓扑去搜索。这里没有万能公式只能实际测。值得注意的是张量并行的通信量非常大因为它每个Transformer层都要做两次AllReduce通常只建议在节点内使用依赖高速卡间互联。跨节点还是尽量用流水线并行和数据并行减少网络通信量。这种“远近亲疏”的调度策略在千卡集群上非常影响最终效率。3.2 国产软件栈上容易“水土不服”的地方很多模型代码是PyTorch写的国产加速卡首先得接住PyTorch前端。单是这个兼容层就会遇到不少问题有的算子没实现跑起来才报错有的算子能跑但性能极差直接拖慢整个训练有的是反向传播图构建和进口方案不一致需要改代码来绕。更麻烦的是集合通信。数据并行里的AllReduce、张量并行里的AllGather、流水线并行的Point-to-Point通信这些操作在进口生态里有NCCL这种经过大规模验证的库。国产平台需要自己提供一套类似NCCL的集合通信库并且要能识别网络拓扑否则千卡规模下通信效率会非常难看。所以国产集群上的训练调优往往不是算法团队能独立搞定的。芯片厂商要提供稳定的底层库云平台要做调度和网络适配模型团队要配合改并行策略。三方一起联调才有可能把MFU拉上去。这个过程在新闻稿里通常就一句话背后其实是几个月的技术攻坚。3.3 从“能训”到“训得快”协同优化的几个细节智源这种有自研大模型能力的研究院和优刻得这种云厂商配合至少有三个层面的优化空间。第一是作业调度感知拓扑。把同一张量并行组的卡尽量放到同一个TOR交换机下减少跨机柜通信。如果调度器不知道网络拓扑随便分配节点通信路径一长性能立刻掉。第二是checkpoint路径优化。千亿模型的checkpoint写入并发量很大不能所有节点都去抢同一批存储目标。要按节点切分存储路径或者用存储侧的并行聚合能力把写放大控制住。第三是训练框架和底层加速库的版本要一起锁死。国产生态经常出现“驱动升级之后算子回归”这类问题训练环境不锁版本跑着跑着性能就变了。最好的做法是把整个训练镜像固定下来包括驱动、加速库、框架补丁才能保证可复现。4. 从“跑通”到“连续跑两周不崩”稳定性运维才是最大的门槛4.1 故障率是个绕不开的数学问题很多人第一次接触千卡集群时会对“故障率”没有概念。假设一张加速卡的年故障率是2%一千张卡一年下来的故障期望就是20次大约每18天就会坏一张卡。如果算上网络设备、电源、光模块这些部件整体故障间隔会更短。而千亿大模型训练动辄持续三十天以上中途遇到坏卡几乎是必然事件。所以集群设计的基本逻辑不是“如何不坏”而是“坏了怎么办”。硬件层面要有冗余软件层面要能自动隔离故障节点训练任务要能从最近的checkpoint恢复。谁把这套流程做顺了谁才能真正把千卡集群用起来。4.2 Checkpoint策略和断点续训训练的生命线千亿模型训练中每次保存的checkpoint不仅仅包含模型参数。它还包含优化器状态比如Adam的一阶二阶动量这对显存占用非常可观。一个175B模型加上优化器状态一次checkpoint的数据量轻松超过2TB。如果每两小时保存一次存储系统必须能扛住非常高的写入吞吐。如果为了省事拉长保存间隔一旦故障训练进度会回退好几个小时浪费算力。更合理的做法是异步checkpoint先把显存数据拷到主机内存再由后台线程慢慢写盘这样主训练循环不会被存储抖动拖住。恢复同样有讲究。从checkpoint加载2TB数据到显存本身就可能要几分钟。如果M个节点同时加载分布式存储要能扛住高并发读。经常看到有团队的训练任务在故障后“恢复得很慢”原因往往是存储并发能力不足而不是模型代码有问题。4.3 运维要盯哪些指标颗粒度要到什么程度千卡集群的监控不能只看CPU、内存、网络流量这些通用指标。加速卡的功耗、温度、显存ECC错误计数RDMA网络的丢包率、拥塞通知计数并行文件系统的写延迟和IO队列深度这些指标都必须在训练过程中实时可见。一个特别有用的习惯是每天自动跑一次集合通信基准测试。AllReduce带宽测试如果明显低于正常值大概率是网络或者驱动出了问题。这个时候主动排查比等训练任务中断了再去看日志要省力得多。我见过不少事故其实都是早期有征兆的只是监控没覆盖到。4.4 一次典型故障排查的完整链路假设监控发现训练吞吐下降了一半。第一件事不是去看模型代码而是先确认发生时间点然后查集群监控面板。优先看是不是有节点掉线或者卡被置红。如果看到某台机器某张卡出现ECC错误计数暴涨基本可以锁定是硬件问题。接着在控制节点跑一个局部的AllReduce测试把故障节点和健康节点对比如果带宽差一个量级就证明卡或者网络有问题。最后把这台机器从调度池里隔离训练任务自动从最近的checkpoint重启整个流程尽量在几分钟内完成。这套排障链路听起来很简单但真要做到自动化需要平台侧开发不少工具脚本。今天还能靠人肉盯屏等集群规模到了万卡人肉盯屏根本盯不过来。5. 跨过千卡之后国产智算集群还要闯几道关5.1 “首个国产千卡集群”这件事的分量标题里说的是“优刻得首个”国产千卡集群不是“全国首个”这个用词很严谨也反映出这只是一个起点。但它背后的含义不小国产加速卡、国产网络方案、国产云平台第一次被放到了一个千亿大模型的真实训练任务里接受检验。这些年国产算力经常被质疑的点是“能跑但跑不快”“演示可以生产不行”。优刻得这个集群既然能支持智源千亿模型训练至少说明在工程层面已经把很多原本是障碍的问题解决掉了。肉眼可见的价值是给后来者趟了一条路让其他想用国产算力做AI训练的单位少踩一些坑。5.2 从千卡到万卡新增的复杂度不在一个量级千卡集群解决的是“能不能训千亿模型”的问题万卡集群面对的则是“怎么训十万亿参数”“怎么训更大规模模型”的问题。网络首当其冲。千卡规模还可以用传统Fat-Tree拓扑到了万卡级别东西向流量会急剧增加胖树拓扑的带宽收敛比会变成瓶颈。业界已经在尝试更扁平的光交换网络、超节点架构、甚至内存语义的池化方案。国产网络如果只停留在“把RoCE调通”的水平很难支撑万卡。调度系统也要升级。万卡集群不可能一个任务独占所有资源必须支持多任务分时、资源抢占、弹性扩缩容。训练到一半被优先级更高的任务抢走资源又要能平滑缩容这对平台调度器的考验远超千卡。能耗也是绕不开的问题。千卡机房的功率密度已经很高了风冷勉强能压住。万卡集群如果用N卡或国产同级别加速卡液冷几乎必然。优刻得这次落地千卡集群后续往更大规模走机房改造、散热方案、电力配额都得提前规划好。另外国产软件生态还处在一个快速追赶的阶段。算子库的覆盖度、集合通信库在超大规模下的扩展性、分布式训练框架的成熟度都需要更多真实的业务场景去喂养。智源和优刻得这种合作最大的价值恰恰是为国产生态提供了一个“用起来”的机会只有被用才会被发现不足才会被改进。最后说一点个人体会。如果你所在团队正准备上国产千卡集群别急着把模型塞进去跑先花一段时间做三件事把网络通信基准摸透把checkpoint恢复流程完整演练几遍把监控告警的灵敏度调到合适的值。“跑通”和“跑满”之间隔着大量文档里不会写的工程细节。等这些基础打牢了再让千亿模型上去你会发现很多事情会顺利很多。