1. 十万亿参数时代的算力焦虑到底卡在哪1.1 从千卡到万卡规模膨胀带来的不是线性增长大模型参数从百亿级跳到万亿级再到十万亿级很多人第一反应是“堆卡就行了”。但真正在集群里调过任务的人都知道卡的数量翻十倍系统复杂度翻的绝不止十倍。千卡规模下你还能靠人工经验去调拓扑、排故障、盯带宽到了万卡级别网络抖动、光模块失效、显存碎片、通信拥塞这些问题的出现频率会呈指数级上升。我见过太多团队在千卡集群上跑得好好的模型一上到三千卡以上就开始出现各种玄学问题loss曲线突然毛刺、all-reduce耗时忽高忽低、某些节点莫名其妙掉线。排查一圈发现往往不是计算卡本身的问题而是互联网络在高压下的稳定性不够。这就是“万卡协同”被叫做噩梦的根本原因——算力不是简单加总协同效率才是真正的瓶颈。十万亿参数是什么概念以FP16精度估算仅模型权重就需要约20TB显存。假设单卡64GB显存光把模型装进去就要300多张卡这还没算优化器状态、梯度、激活值这些训练必需的额外开销。实际训练中显存占用通常是模型权重的4到6倍这意味着十万亿参数模型的训练至少需要上千张高显存卡同时在线而且它们之间必须保持高速、低延迟的通信。1.2 万卡协同的三大拦路虎通信墙、故障墙、调度墙通信墙是最直观的。分布式训练中数据并行需要做梯度all-reduce模型并行需要做激活值传递流水线并行需要做stage间通信。当卡数达到万级任何一次全局通信的延迟都会被放大到不可接受的程度。传统以太网在万卡规模下的有效带宽利用率可能只有理论值的30%到40%这意味着你花大价钱买的算力有六成浪费在等数据上。故障墙同样致命。万卡集群里单卡故障率哪怕只有0.1%整个集群每天也会有十张卡出问题。更麻烦的是光模块和交换机端口的故障率远高于计算卡本身。一个万卡集群里光模块数量可能超过十万个按年故障率2%算每天就有五六个光模块需要更换。每次故障都可能导致训练任务中断而大模型训练checkpoint动辄几十GB恢复一次少则十几分钟多则半小时。调度墙则是软件层面的挑战。万卡集群不可能只跑一个任务多个训练任务、推理任务、数据处理任务需要共享资源。如何在保证高优先级任务不被打断的前提下最大化整体利用率这需要非常精细的调度策略。传统Kubernetes调度器在这种规模下基本不可用必须定制化开发。1.3 超节点架构为什么成了破局关键超节点SuperPod这个概念的核心思路是把大规模互联问题拆解成多个小规模高速域再在域间做层次化互联。华为昇腾960超节点的做法是在一个机柜或相邻几个机柜内通过高速总线把几十到上百张加速卡连成一个高带宽、低延迟的“计算域”域内通信走专用高速链路域间通信走标准网络。这样做的好处非常明显。域内通信延迟可以做到纳秒级带宽可以做到TB/s级别完全满足张量并行和专家并行的通信需求。域间通信虽然带宽和延迟稍差但数据并行和流水线并行的通信模式对延迟相对不敏感标准高速网络就能胜任。这种层次化设计把万卡协同的复杂度从O(N²)降到了O(N log N)级别。昇腾960超节点具体采用了NPO光互联技术这是华为自研的一种近封装光学互联方案。传统光模块是插在交换机或网卡上的电信号从芯片出来要经过PCB走线、连接器、再到光模块这段电链路在高频下损耗很大。NPO把光引擎直接封装在靠近芯片的位置大幅缩短了电链路长度从而降低了功耗和延迟同时提升了信号完整性。2. 昇腾960超节点的核心技术拆解2.1 NPO光互联把光引擎搬到芯片旁边NPO全称Near-Package Optics中文叫近封装光学。要理解它的价值得先知道传统光互联的痛点。在传统架构里交换芯片和光模块之间隔着长长的PCB走线信号在铜线上跑频率越高衰减越严重。到了112Gbps这个速率铜线传输距离超过十几厘米就开始明显劣化必须加retimer芯片来整形信号而retimer又带来额外功耗和延迟。NPO的做法是把光引擎直接放在交换芯片或计算芯片的封装基板上电信号从芯片出来只需要走几毫米就能进入光引擎转换成光信号。这样一来电链路损耗几乎可以忽略功耗大幅下降延迟也显著降低。根据华为公开的技术资料NPO方案相比传统可插拔光模块功耗降低约30%延迟降低约40%。具体到昇腾960超节点NPO光互联主要用在两个地方一是计算节点之间的高速互联二是计算节点到交换机的上行链路。在超节点内部多张昇腾计算卡通过NPO光互联组成一个全互联或胖树拓扑的高速域任意两张卡之间的通信只需要经过一跳或两跳光交换延迟控制在百纳秒级别。注意NPO光互联虽然性能优越但对散热和封装工艺要求极高。光引擎靠近芯片意味着它要承受芯片附近的高温环境这对光器件的可靠性是巨大考验。华为在这方面做了大量可靠性验证但实际部署时仍需确保机柜散热达标。2.2 超节点内部拓扑胖树还是全互联昇腾960超节点内部采用的是改进型胖树拓扑。胖树的好处是任意两点间通信路径等长带宽收敛比可控。在传统胖树中汇聚层和核心层的交换机数量随节点数增加而快速膨胀但昇腾960通过NPO光互联把交换层级压缩了用更少的光交换芯片实现了更大的互联规模。具体来说一个典型昇腾960超节点可以支持数十张计算卡全互联任意两张卡之间的单向带宽可达数百GB/s。这个带宽是什么概念对比一下传统InfiniBand HDR单端口带宽是200Gbps约25GB/s。昇腾960超节点内部带宽是它的十倍以上。这意味着张量并行时卡间传输激活值的耗时可以忽略不计计算单元几乎不会因为等数据而空转。域间互联则通过标准高速以太网或InfiniBand实现。虽然域间带宽低于域内但数据并行和流水线并行的通信模式对带宽需求相对较低。以数据并行为例每轮迭代只需要做一次梯度all-reduce通信量等于模型参数量而计算量是参数量乘以batch size乘以序列长度计算通信比很高域间网络完全能扛住。2.3 算力精度与显存配置的平衡术十万亿参数模型训练不可能全用FP16或BF16那样显存根本不够。实际训练中通常采用混合精度策略前向和反向计算用BF16或FP16优化器状态和主权重用FP32梯度累积和通信可以用FP16压缩。昇腾960支持FP32、FP16、BF16、INT8等多种精度并且支持在片上进行精度转换。显存配置方面昇腾960单卡显存容量相比上一代有大幅提升。具体数字华为没有完全公开但根据业内推测单卡HBM容量应该在64GB到128GB之间。即便如此十万亿参数模型仍然需要模型并行。常见的做法是张量并行加流水线并行加数据并行的三维并行策略。张量并行把单个Transformer层的矩阵运算切分到多张卡上每张卡只计算一部分然后通过all-reduce合并结果。这种并行方式通信频繁必须放在超节点内部的高带宽域内。流水线并行把不同层分配到不同卡上卡间只传递激活值通信量小但需要处理流水线气泡。数据并行复制多份模型每份处理不同数据定期同步梯度。昇腾960超节点的设计正好匹配这种三维并行策略域内高带宽支撑张量并行域间标准网络支撑数据并行流水线并行则可以根据模型结构灵活放置。这种软硬件协同设计才是万卡协同从噩梦变标配的关键。3. 万卡协同的实操落地从环境搭建到任务调优3.1 集群初始化与网络配置要点拿到一个昇腾960超节点集群第一步不是急着跑训练而是做全面的健康检查和基准测试。我踩过的坑告诉我跳过这一步后面会付出十倍代价。具体流程是这样的首先检查所有计算卡的固件版本和驱动版本是否一致。万卡集群里哪怕有一张卡的驱动版本差一个小版本都可能导致集合通信库行为异常。用npu-smi info命令可以批量查看所有卡的状态建议写个脚本遍历所有节点把输出汇总成表格逐项核对。然后是网络连通性测试。超节点内部NPO光互联的连通性通常由华为的管理软件自动检测但域间网络需要手动验证。用ib_send_bw和ib_send_lat测试任意两个节点之间的带宽和延迟确保没有异常节点。我一般会随机抽取100对节点做测试如果发现某对节点带宽只有正常值的一半那大概率是光模块或线缆有问题。集合通信库的配置是另一个关键点。昇腾960使用华为自研的HCCLHuawei Collective Communication Library类似英伟达的NCCL。HCCL的配置参数直接影响all-reduce等操作的性能。关键参数包括HCCL_ALGO选择集合通信算法通常用ring或tree具体取决于消息大小和拓扑HCCL_BUFFSIZE通信缓冲区大小太小会导致频繁同步太大会浪费显存HCCL_INTRA_PCIE_ENABLE是否启用PCIe内通信超节点内部通常走NPO光互联这个要关掉实操心得HCCL_BUFFSIZE不是越大越好。我实测下来对于百GB级别的all-reduce缓冲区设为128MB到256MB比较合适。设成1GB反而会因为内存拷贝开销导致性能下降。3.2 三维并行策略的配置与调参假设我们要训练一个十万亿参数的MoE模型总共有64个专家层每个专家层参数量约1500亿。硬件资源是8个昇腾960超节点每个超节点64张卡总共512张卡。怎么切分首先确定流水线并行度。MoE模型通常按专家分组做流水线64个专家层可以分成8个流水线阶段每个阶段8个专家层。这样流水线并行度PP8。每个流水线阶段需要放置8个专家层每个专家层1500亿参数8个就是1.2万亿参数。单卡显存放不下需要张量并行。张量并行度TP怎么定超节点内部64张卡如果TP8那么每个流水线阶段占用8张卡做张量并行8个流水线阶段就是64张卡正好一个超节点。但这样数据并行度DP1训练吞吐上不去。所以需要跨超节点做数据并行。最终配置可以是TP8PP8DP8。总卡数8×8×8512。每个超节点内部署一个完整的流水线PP8TP88个超节点之间做数据并行。这样张量并行的通信全部在超节点内部走NPO光互联数据并行的梯度同步走域间网络。配置好并行策略后还需要调整micro-batch size。流水线并行中micro-batch越多流水线气泡越小但显存占用越大。通常从4开始试逐步增加到8或16观察显存和吞吐的变化。昇腾960的显存管理比较激进会尽量把显存用于缓存而不是预留所以实际可用显存比标称值要灵活。3.3 训练过程中的监控与故障自愈万卡集群跑起来之后监控比调优更重要。我一般会盯这几个指标每张卡的利用率和显存占用任何一张卡利用率持续低于80%都值得排查HCCL集合通信的耗时如果all-reduce时间突然翻倍说明网络有问题光模块的温度和光功率NPO光引擎对温度敏感超过阈值会降速训练loss曲线毛刺不一定代表有问题但持续上升肯定有问题昇腾960配套的MindX工具链提供了集群级监控面板可以实时查看这些指标。但工具归工具我建议自己写一套告警脚本把关键指标推送到即时通讯工具这样半夜出问题也能第一时间知道。故障自愈方面昇腾960支持计算卡的热插拔和任务迁移。如果某张卡故障调度器可以把上面的任务迁移到备用卡上训练任务不需要完全重启。但这个功能需要提前配置好备用节点池并且checkpoint频率要足够高。我通常设置每100步存一次checkpoint这样即使需要重启损失的计算时间也控制在几分钟以内。常见问题训练过程中出现HCCL timeout怎么办先别急着重启任务。用hccn_tool检查所有节点的网络状态看是否有节点掉线。如果只是个别节点网络抖动可以尝试调大HCCL的超时阈值让任务继续跑。如果多个节点同时掉线那大概率是交换机或光模块问题需要人工介入。4. 常见问题排查与性能调优实录4.1 集合通信性能不达标的排查思路集合通信是万卡协同中最容易出问题的环节。我整理了一个排查清单按顺序执行基本能定位到根因排查步骤检查内容正常表现异常处理1节点间网络连通性所有节点两两互通检查光模块和线缆2HCCL版本一致性所有节点版本相同统一升级到最新版3网卡配置速率和双工模式正确重新配置网卡4集合通信算法匹配当前消息大小调整HCCL_ALGO5缓冲区大小与消息大小匹配调整HCCL_BUFFSIZE6CPU亲和性通信线程绑定到正确NUMA节点调整绑核策略我遇到过最诡异的一次性能问题是某台服务器的CPU频率被BIOS设置成了节能模式导致HCCL的通信线程调度延迟增大all-reduce耗时比正常高出30%。这种问题从计算卡和网络层面完全看不出来最后是用perf工具抓CPU调度才发现的。所以万卡集群的调优不能只盯着加速卡和网络服务器本身的配置也要纳入检查范围。4.2 显存碎片与OOM的预防策略十万亿参数模型训练中显存OOM是家常便饭。但很多时候OOM不是因为显存不够而是因为碎片太多。昇腾960的显存分配器默认采用best-fit策略长时间运行后会产生大量小碎片导致明明有足够空闲显存却分配不出连续大块。预防显存碎片有几个实用技巧。第一尽量使用静态显存分配在训练开始前就把所有需要的显存申请好避免训练过程中动态申请释放。第二如果必须动态分配定期调用显存整理接口把碎片合并。第三合理设置checkpoint保存策略保存checkpoint时会申请大块显存如果此时碎片多就容易OOM可以先把模型参数卸载到主机内存再保存。还有一个容易被忽视的点是通信缓冲区。HCCL的通信缓冲区是预分配的如果设得太大留给模型计算的显存就少了。我一般会先跑一个显存profiling看看模型计算实际需要多少显存然后反推通信缓冲区能设多大。昇腾960提供了显存profiling工具可以精确到每个算子的显存占用。4.3 训练中断恢复的加速技巧万卡集群训练中断是常态。关键不是避免中断而是中断后能快速恢复。影响恢复速度的主要因素是checkpoint的大小和加载速度。十万亿参数模型的checkpoint可能有几十TB从存储加载到显存需要很长时间。加速恢复有几个方向。一是使用分层checkpoint把模型参数、优化器状态、随机数状态分开存储恢复时优先加载模型参数优化器状态可以异步加载。二是使用内存缓存把最近的checkpoint缓存在主机内存或本地NVMe盘上避免每次都从远端存储拉取。三是使用增量checkpoint只保存变化的参数但这个需要框架层面支持。昇腾960配套的MindSpore框架支持异步checkpoint保存和加载实测可以把恢复时间从半小时压缩到五分钟以内。具体配置是在checkpoint配置里开启async_save和async_load选项并设置合适的内存缓存大小。实操心得checkpoint保存频率不是越高越好。保存太频繁会占用大量I/O带宽影响训练吞吐。我一般根据任务稳定性来定稳定期每500步存一次不稳定期每100步存一次。另外保存checkpoint时最好错开所有节点的I/O高峰可以设置不同的保存延迟。5. 从万卡到十万卡超节点架构的扩展边界5.1 超节点规模受什么限制昇腾960超节点当前支持数十到上百张卡的全互联但不可能无限扩展。限制因素主要有三个光交换芯片的端口数、机柜的供电和散热能力、以及封装工艺的良率。光交换芯片的端口数决定了单个超节点能连多少张卡。NPO光互联虽然把光引擎做小了但交换芯片的端口密度仍然受限于硅光工艺。目前单颗光交换芯片的端口数在几十到一百多这个量级要连更多卡就需要多级交换而多级交换会增加延迟和成本。供电和散热是物理限制。一张昇腾960计算卡的功耗在300W到400W之间一个机柜塞64张卡就是20kW以上的功耗传统风冷根本压不住必须上液冷。液冷系统的部署和维护成本很高而且对机房改造要求大。这也是为什么超节点通常以机柜为单位部署跨机柜的全互联成本太高。封装良率则影响成本。NPO把光引擎和计算芯片封装在一起任何一个环节出问题整个封装就报废。目前这种先进封装的良率还在爬坡阶段导致单卡成本居高不下。不过随着工艺成熟良率提升是必然趋势。5.2 多超节点组网的最佳实践当单个超节点不够用时就需要多个超节点组网。组网方式决定了跨超节点通信的性能。目前主流方案有两种一是通过核心交换机做全互联二是通过汇聚交换机做层次化互联。全互联方案适合超节点数量较少的情况比如4到8个超节点。每个超节点通过上行链路连接到核心交换机任意两个超节点之间的通信只需要经过核心交换机一跳。这种方案延迟低但核心交换机的端口数和交换容量要求高。层次化互联适合超节点数量多的情况。多个超节点先连接到汇聚交换机汇聚交换机再连接到核心交换机。跨汇聚组的通信需要经过核心交换机同组内通信只经过汇聚交换机。这种方案扩展性好但通信路径变长延迟增加。实际部署中我建议根据训练任务的通信模式来选择。如果任务以数据并行为主跨超节点通信量不大层次化互联完全够用。如果任务需要频繁的跨超节点张量并行那最好用全互联方案或者重新设计并行策略把张量并行限制在超节点内部。5.3 十万卡集群的运维挑战从万卡到十万卡运维复杂度不是线性增长而是指数增长。万卡集群可能只需要几个人运维十万卡集群需要一个几十人的专业运维团队而且需要高度自动化的运维工具。自动化故障发现和自愈是必须的。十万卡集群每天可能有几十次各种类型的故障靠人工响应根本来不及。需要建立一套完整的监控告警体系能够自动发现故障、自动隔离故障节点、自动重新调度任务。昇腾960配套的MindX平台提供了这些能力但需要根据实际业务做大量定制化开发。能耗管理也是十万卡集群的大问题。十万张卡同时运行功耗可能达到几十兆瓦电费是天文数字。需要精细化的功耗管理策略比如根据任务优先级动态调整卡频率和电压在训练间隙让部分卡进入低功耗状态。昇腾960支持动态调频调压但需要软件层面配合才能发挥效果。最后是存储系统。十万卡集群每天产生的checkpoint和数据量是PB级别的存储系统的带宽和容量必须跟上。通常采用分层存储架构本地NVMe做缓存并行文件系统做热存储对象存储做冷备。存储系统的设计要和训练框架深度集成才能保证checkpoint保存和加载不成为瓶颈。我个人在实际操作中的体会是万卡协同的难点从来不在单点技术而在系统集成和运维。昇腾960超节点通过NPO光互联和层次化架构把硬件层面的互联问题解决得不错但软件生态和运维工具还需要持续完善。对于准备上大规模集群的团队我的建议是先把千卡集群跑稳把运维流程和工具链打磨好再逐步扩展规模。步子迈太大容易扯着。