2026年，有一件事挺反直觉的。
训练一个万亿参数规模的大模型,把它的权重从美国一个数据中心传到另一个数据中心,居然要花87.5分钟。这还不是什么奇怪的网络环境,就是两个AWS区域之间的正常传输。听起来很荒唐对吧,数据传输不是应该很快吗?
问题出在哪呢?模型太大了。一个万亿参数的模型,哪怕只用BF16这种比较省空间的格式存,也要占掉差不多2.2TB的空间。而现在做强化学习训练大模型,有个躲不开的环节叫refit,就是把训练集群算出来的最新权重,同步给专门负责生成文本的rollout集群。这个过程必须在每一批新的推理任务开始前完成,等于说,每一次模型更新,都得完整地把这么大的文件搬一遍家。
这就是这篇论文要解决的问题。
### 当99%的数据都是在做无用功
先说一个真正让人意外的发现。
研究者们测了六个不同规模的模型,从5亿参数的小模型到300亿参数的混合专家模型,每次训练迭代之后,去对比权重更新前后哪些数值真的发生了变化。结果是,每一步训练下来,平均只有0.6%到1.2%的权重数值会真正改变。
这个数字有点反常识。我们一般觉得,神经网络训练嘛,每一步都在"学习",理应是大部分参数都在微调才对。但实际情况是,BF16格式*(一种16位的浮点数表示方式,用8位存储有效数字,精度不算高)*只有8位有效数字,这意味着大部分优化器算出来的那一点点更新量,根本不足以让存储的数值发生变化,直接被舍入掉了。
换句话说,你辛辛苦苦训练一步,算出了一大堆梯度更新,但落到存储层面,99%的比特位根本没动。
这就好比你每天给一个仓库盘点,仓库里有一万件商品,但实际上每天真正发生变化的,可能只有一百件商品的数量或位置。如果你的盘点方式是每天把整个仓库的清单重新打印一遍寄给总部,那浪费的纸张和邮费是惊人的。如果不改进这个流程会怎样?答案就是开头那个数字:87.5分钟,每一次模型更新都要等这么久。
### 三道坎:知道哪里改、改得准、改得快
研究者们意识到,既然只有百分之一左右的权重真的变了,那完全没必要把整个模型重新传一遍,只传变化的部分不就行了吗?这个想法听起来简单,但做起来有三道实实在在的坎。
第一道坎是放置问题。训练集群和推理服务集群存储权重的方式完全不一样,它们各自为了性能优化,会把同一个参数切分、合并、换位置存储。训练那边一个分片里的某个数据,传到推理那边可能分散在好几个不同节点上,这中间的映射关系非常复杂。有些系统选择重新写一套映射规则,有些系统则是先把权重完整拼出来再转换格式,两种做法都挺费劲。
第二道坎是精确性。强化学习这种训练方式对训练和推理之间的数值差异特别敏感,哪怕有一点点浮点数误差,都可能让整个训练过程变得不稳定。如果用数学方式重新推算更新后的数值(比如根据优化器公式反推),很容易在计算过程中引入舍入误差。但如果图省事,把变化了的那个参数所在的整个数值块全部重新发送一遍,又会浪费带宽,因为同一个数值里其实大部分比特位根本没变。
第三道坎是容错。跨集群传输这种事,中途出故障是常态,不是意外。如果更新过程中途失败了,接收端可能留下一部分新权重、一部分旧权重混在一起,这种混合状态对训练策略来说是致命的,既不是旧版本也不是新版本,会直接破坏训练的正确性。
研究者们评估了现有系统,发现没有一个能同时解决这三个问题。要么送了精确的数据但是送的是全量数据,要么用稀疏传输但精度打了折扣,要么精度和稀疏都做到了但是接入了横跨两个集群的通信,一旦哪边网络抖动就直接卡死。
### 用"坐标系"而不是"位置编号"来描述变化
NeMo-DCR给出的核心思路,是引入一套叫做"canonical coordinates"*(规范坐标,指的是Hugging Face检查点格式里统一的张量命名和索引方式,不管训练端还是推理端怎么切分权重,都能映射回这套统一坐标)*的中间表示。
这个设计的巧妙之处在于,它不去直接对比训练端存储位置和推理端存储位置,而是先把两边都映射到这套中立的坐标系统上。训练端哪个分片负责维护哪部分权重,推理端的加载器会自动把这些规范坐标的数据塞到它自己的存储结构里去,就跟操作系统的页表把虚拟地址映射到物理地址一样。
这就好比一家跨国公司,总部用的是北京时间排班,海外分部用的是当地时间排班,如果每次沟通都要互相换算时区,效率低还容易出错。更好的办法是大家都统一用UTC*(协调世界时,一种全球统一的时间标准)*时间来记录,各自再按需转换成本地时间。如果不这样做,每次权重同步都要重新推导一遍复杂的位置映射关系,出错概率会直线上升,而且每次推理端换一种并行方式,整套映射逻辑可能都要推倒重来。
### 分片负责人,只盯自己管的那一块
具体实现上,系统给训练端每个数据分片指定了一个唯一的"owner"*(所有者,指的是负责检测某个数据分片是否发生变化的那个训练节点)*。
因为数据并行训练的时候,多个副本理论上存的是完全一样的数据,所以没必要每个副本都重复检测一遍变化,派一个代表去检测就够了。这个owner负责把自己管辖范围内的权重,和上一次确认过的基线版本做逐比特对比。
这里有个细节值得展开说说。对比的时候,系统比较的是存储的比特模式,而不是浮点数值本身是否相等。这个区别看起来很学究气,但其实很重要。举个例子,浮点数里的正零和负零,数学上被认为是相等的,但它们的存储比特是不一样的。如果用数值相等来判断变化,符号位的改变会被漏掉,接收端就会保留错误的符号位。NeMo-DCR选择了更严格的比特级对比,确保这种细微差异也不会被漏掉。
对于那些可以用固定数学公式直接算出新位置的变化,系统用了叫"direct projection"*(直接投影,指的是用预先定义好的固定规则,直接计算出某个变化在统一坐标系里的目标位置,不需要先把整个张量组装出来)*的办法,省去了组装完整张量再转换格式的开销。论文里给出的数据是,在Qwen3模型上,这种直接投影方式让变化检测这一步快了1.08到1.16倍。
但不是所有的变化都能靠简单公式直接算出来。有些情况,比如融合的Q/K/V投影层*(注意力机制里查询、键、值三个矩阵,很多推理框架会把它们拼在一起存储以提升效率)*,或者共享的缩放因子发生变化时会牵连到好几个输出,这类情况没法用固定公式直接映射,系统会退回到更保守的办法:先把受影响的张量重新转换出来,再跟上一次的基线比对,找出真正变了的部分。这部分在论文里叫residual conversion*(残差转换,处理那些不能用简单公式直接映射的权重变化)*。
### 异或还是覆盖,两种方式都保证字字精确
光知道哪里变了还不够,怎么把变化告诉接收端也有讲究。
NeMo-DCR给出了两种编码方式。第一种是XOR掩码*(异或运算,把旧的比特值和新的比特值做异或操作,得到一个只在发生变化的位上才不为零的掩码)*。接收端拿到这个掩码之后,只需要跟自己手里存的旧值做一次异或,就能精确恢复出新值,不会有任何精度损失。第二种是直接覆盖,把新值完整发过去,接收端直接替换。
为什么要搞两种方式,而不是干脆都用覆盖算了?因为XOR掩码在压缩上有个很大的优势。大多数数值的更新幅度都很小,这意味着新旧两个数值的高位比特大部分是一样的,只有低位有差异。异或运算之后,高位全变成零,这种大片连续零的数据,用压缩算法一压能压掉很多。论文里的实测数据是,XOR方式编码出来的数据,比直接覆盖方式压缩后的体积小1.7到2.2倍。
但XOR方式有个前提条件,必须保证这条链路从训练端到接收端,中间的格式转换和加载过程完全不改变存储的比特模式,否则异或出来的掩码就是错的。对于那些转换过程会改变比特模式的情况,比如前面提到的缩放和类型转换,系统就老老实实地用覆盖方式,保证结果一定是对的。
这套混合策略让Qwen3模型的传输数据量比纯用覆盖方式减少了38%到40%。
这里有个很现实的担忧,就是XOR掩码这种东西,重复应用两次是会出问题的。想象一下你有一盏灯,开关是触发式的,按一下灯亮,再按一下灯灭。XOR掩码就是这种触发式的,异或两次等于什么都没做,甚至会把本来对的值又改错了。如果网络传输过程中出现重复的数据包,接收端误把同一个掩码应用了两次,权重就被改坏了。所以系统专门设计了去重机制,靠传输时附带的唯一标识符来确保每个变化只被应用一次。
### 不留底本,直接往原地改
接下来是容错问题。
NeMo-DCR的做法是让接收端直接在原地修改权重,而不是先维护一份独立的副本当作安全网。这个决定乍一听有点冒险,毕竟原地修改,一旦中途出错不是很难收场吗?
但研究者们想明白了一件事:如果每次更新都要先备份一份完整权重再动手,那就相当于每次refit都要在显存里多占一份完整模型的空间,万亿参数模型光这一份备份就要再多出两万多亿字节的空间,这代价太大了。
他们的解法是,万一中途失败,重试的时候不再区分哪些是异或、哪些是覆盖,统一都用覆盖方式重新发一遍完整的变化集合。为什么这样就安全了?因为覆盖操作不管重复几次结果都是一样的,这跟异或的"触发式"开关完全不同,覆盖更像是直接把墙上的海报换成新的,换多少次结果都是同一张新海报。用这种"幂等"*(数学概念,指一个操作不管执行一次还是多次,产生的结果都一样)*的特性来兜底,就不需要额外维护一份备份数据。
最后,系统设计了一个叫joint commit*(联合提交,指的是等所有需要更新的接收端都确认收到并应用完变化之后,才正式把新版本标记为生效版本)*的机制。只有当所有该更新的接收端都确认应用完毕,系统才会把这次更新标记为正式生效,训练端的基线数据也是在这之后才同步更新。这样一来,任何一个环节出了问题,整个系统还是能回退到上一个明确的、完整的版本,不会卡在半新半旧的中间状态。
论文里做了一个很有说服力的实验。他们在训练过程中故意随机杀掉接收端的进程,模拟真实环境里的故障,然后观察训练的奖励曲线和KL散度*(衡量两个概率分布差异的指标,这里用来衡量推理策略和训练策略之间的偏差)*变化。结果显示,不管用对象存储还是用点对点的传输树,即使频繁遭遇进程被杀,整个训练过程的表现曲线跟完全没有故障、用传统方式做全量同步的训练几乎一模一样。
### 传输这一步,不用绕远路也能提速
最后一个问题是怎么把这些变化数据真正送到千里之外的推理集群。
论文里提了两种传输方案。一种是通过对象存储*(类似亚马逊S3这样的云存储服务)*中转,训练端把数据传上去,推理端的各个节点各自去下载。另一种是relay tree*(中继树,数据从训练端出发,先到推理集群里的一个根节点,再像树状结构一样逐级转发给其他节点)*,靠集群之间的直连链路,数据只跨越集群边界一次,然后在推理集群内部通过本地链路层层转发出去。
这两种方案都有一个共同的特点,就是不依赖那种横跨训练和推理两个集群的集体通信操作。为什么要刻意避开这种集体通信?因为这类操作会把推理集群的节点成员关系和训练集群死死绑在一起,一旦某个节点掉线,整个通信就可能超时卡死,排查起来也麻烦。
为了进一步提速,NeMo-DCR把数据构建过程和传输过程做了流水线化处理。权重变化的检测和打包,跟数据的网络传输是同步进行的,而不是等全部打包完才开始传。论文里用了个很形象的比喻场景:就像工厂的流水线,一边有工人在组装零件,一边已经有组装好的半成品被送上运输车,而不是等所有零件都装好了才一起装车运走。如果不这样做,整个refit的延迟会是构建时间加上传输时间的简单相加,而不是两者重叠之后的较大值。
### 数字说话:从30B到1T,到底快了多少
论文的实验部分给出了相当扎实的数据支撑。
在1200亿参数模型上,传统的全量传输方式需要750秒,NeMo-DCR用relay tree在3%变化率的压力测试条件下,只用了22.6秒,快了33倍。
到了万亿参数规模,传统方式需要87.5分钟,NeMo-DCR只用150秒,快了35倍。
研究者们还专门测试了从300亿参数到1万亿参数这个跨度上,系统表现是否稳定。结果显示,在3%和5%这两种元素变化率的压力测试场景下,不管模型规模怎么变,NeMo-DCR始终保持在传统方案的12到40倍速度区间。而且relay tree传输方式随着模型变大,优势会越来越明显,在5%变化率下,300亿参数时relay tree只比对象存储快1.13倍,到了万亿参数时这个优势扩大到1.36倍。
更细致的分析显示,在压力测试场景下,整个refit的延迟里,有77%到94%的时间其实是花在网络传输这个硬指标上,而不是数据构建或者其他环节。这说明NeMo-DCR已经把能优化的其他环节压缩得差不多了,真正的瓶颈回到了物理层面的带宽限制,这反而是个好消息,因为这意味着系统设计本身已经接近效率的上限,剩下的提升空间取决于网络基础设施本身。
| 模型规模 | 变化率 | 传统全量传输 | NeMo-DCR relay tree | 加速比 |
|---|---|---|---|---|
| 120B | 3% | 750秒 | 22.6秒 | **33倍** |
| 120B | 5% | 750秒 | 41.6秒 | 18倍 |
| 1T | 3% | 87.5分钟 | **150秒** | **35倍** |
### 这个思路为什么值得关注
这篇论文发表的时间点挺有意思。智能体强化学习*(Agentic RL,指让AI模型在真实或模拟环境中执行多步骤任务并通过奖励信号学习的训练方式)*正在从实验室走向实际应用,模型规模也一路水涨船高,万亿参数级别的模型已经不是稀罕事。在这个背景下,训练和推理分离部署*(把负责学习的训练集群和负责生成结果的推理集群物理上分开,各自用最适合的硬件配置)*成了标配做法,因为这样能让两边各自用最适合的硬件配置,整体效率更高。
但分离部署带来的副作用就是这篇论文要解决的同步难题。如果同步跟不上,模型规模越大,这个瓶颈就越致命。往前看,这类系统设计思路,利用数据本身的稀疏性去压缩传输,同时保证数学上的精确性,很可能会被更多需要频繁同步大规模状态的分布式系统借鉴,不只是强化学习训练这一个场景。
### 写在后面
读完这篇论文,最让我意外的不是加速比有多高,而是那个0.6%到1.2%的数字。
我们平时聊深度学习,总是默认"训练"等于"大规模参数更新",脑海里的画面是梯度信号哗啦啦地冲刷过每一个权重。但实际情况是,在BF16这种低精度存储格式下,绝大多数的学习信号根本没能留下任何痕迹,就这么被舍入运算吃掉了。这让我重新想了一下,我们平时说的"模型在学习",到底是在学什么。可能真正有效的信息量,远比参数总数要小得多。
还有一个细节我觉得挺值得单独说一说,就是正零和负零那个例子。浮点数里+0.0和-0.0在数学上被认为相等,但存储的比特是不一样的。这种细节如果处理不好,放在一个日常的程序里可能无伤大雅,但放在一个要求"bit-exact"*(比特级精确,要求接收端得到的数据和发送端完全一致,连每一个比特位都不能有差异)*的分布式系统里,就是个真实的bug来源。这提醒我,很多时候系统设计的难度不在于想出一个聪明的大方向,而在于把这种犄角旮旯的边界情况一个个排查干净。
这篇论文也留了一些没有完全展开的问题。比如它现在的方案是针对特定的检查点格式和特定的推理框架做的深度适配,如果换一套完全不同的模型架构或者推理引擎,这套直接投影的映射规则是不是还能顺利复用,论文里没有细说。另外,0.6%到1.2%这个变化率是在相对保守的学习率和早期训练步数下测出来的,如果训练到后期学习率调整、或者遇到比较激进的优化策略,这个比例会不会显著升高,进而影响整套系统的加速效果,也是个值得继续追问的点。
Q&A
Q1：NeMo-DCR是什么?
A：NeMo-DCR是NVIDIA提出的一套跨集群权重同步系统,专门用于智能体强化学习训练中,把训练集群算出的最新模型权重快速、精确地同步给负责推理生成的rollout集群,只传输真正变化的部分而不是整个模型。
Q2：NeMo-DCR能把同步速度提升多少?
A：论文实验显示,在3%和5%变化率的压力测试场景下,NeMo-DCR比传统全量传输方案快12到40倍。在万亿参数模型上,传统方式需要87.5分钟,NeMo-DCR用relay tree传输只需150秒。
Q3：NeMo-DCR为什么能保证传输结果完全精确?
A：系统用XOR掩码和直接覆盖两种编码方式,确保接收端恢复出的权重和完整重新计算得到的结果逐比特一致。同时通过联合提交机制,只有所有接收端都确认应用完变化才正式生效,避免中途故障导致新旧权重混杂。
