从“堵车”到“一路绿灯”：国内首例300亿参数大模型超 4000 公里跨域混训技术解析

随着 Scaling Law 的持续推进，模型的参数量从十亿级跃升至万亿级，训练数据量从 TB 级迈向 EB 级，对底层算力的渴求已经达到了前所未有的高度。单数据中心的算力上限已难以支撑模型的扩张规模，同时训练的 GPU 资源还在持续被推理业务挤占，传统单点堆砌算力的训练模式已无法适配当下大模型的发展，从多个地理位置分散的数据中心聚合 GPU 的跨数据中心训练，正在从“可选方案”变成“现实需求”。

然而，虽然理论上我们可以把全世界的 GPU 都连起来用，但跨数据中心的网络就像一条又窄又堵的高速公路，网络带宽受限、延迟高且波动大的特性成为制约整体训练效率的核心瓶颈。和在同一个机房里训练相比，跨域训练时 GPU 大部分时间都在等数据，算力根本跑不满，严重的时候遇到网络堵塞，整个训练任务甚至会直接宕机。

怎么才能让跨域训练跑得又快又稳，让 GPU 少等待，让有限显存能调动更多更大的任务？

无问芯穹的技术团队构建了一套网络感知的训练加速系统，在仿真网络中最高实现了 2.65 倍加速。2026年3月，这一系统在现网中迎来关键验证——无问芯穹携手中国电信研究院、中国电信广东分公司及中国电信新疆分公司，在现网环境下成功完成国内首例实际传输距离超 4000 公里的大模型跨域混训技术验证，圆满落地从哈密训练集群至深圳推理集群的跨域训练任务，实现 300 亿参数模型的高效、稳定训练，在真实跨数据中心部署中最高实现 1.75 倍加速，让分散在不同地点的 GPU 能像在同一个机房里一样更稳定、更高效地协同工作。

01 背景：打破单机房算力天花板，重塑训练基础设施

当前，跨数据中心训练的最核心驱动力，在于打破单体物理机房的算力与扩容极限。随着下一代大模型向十万亿参数规模演进，训练任务对算力的需求呈指数级爆炸。单一数据中心在电力、机柜空间、散热以及网络架构等物理层面，往往难以支撑数万乃至十万级 GPU 集群的集中式部署。因此，打破地域限制，将分散在不同机房的 GPU 联结成一个超大规模的统一算力池，已经成为支撑前沿大模型预训练和重负载并行任务的唯一解。

在突破核心算力瓶颈的同时，这种“跨域聚合”的新型训练基础设施，也顺势为大模型的商业化落地解锁了两项关键的附加红利：

兼顾成本优化（盘活闲置算力）：在算力昂贵的当下，跨域调度能力让我们可以有效利用云端分布在不同地域、不同时段的低成本弹性 Spot 闲置 GPU。对于 SFT 微调、行业模型适配等常态化迭代任务，这能大幅拉高整体资源利用率，极致压缩全链路的硬件开销。
兼顾数据合规（云边协同训练）：针对医疗、政务、金融等对隐私要求极高的强监管行业，跨域架构允许将敏感数据保留在本地基础设施中，仅将部分梯度或非敏感计算任务卸载至云端大数据中心。这种“数据不出域、算力跨域化”的协同模式，在严守数据合规红线的前提下保障了训练效率。

可以说，跨数据中心训练已经演进为大模型时代不可或缺的基础设施形态。然而，在算力池化、成本优化与合规落地的宏大蓝图下，跨域传输的网络短板却成为了最棘手的拦路虎。

02 问题定位：跨数据中心训练为什么低效？

早期跨域分布式机器学习中，数据并行更常见：不同数据中心处理不同数据分片，各自保留完整模型，并在每轮训练后同步模型更新。但在现代大模型训练中，模型参数规模已经非常庞大，数据并行需要在每个 global batch 后跨数据中心阻塞式同步梯度，通信量会随模型规模快速增长。

以 LLaMA2-70B 训练为例（global batch size = 256，PP = 8，DP = 2，TP = 4，H200 GPUs），如果使用数据并行跨数据中心同步，每轮至少需要传输约 140GB 梯度数据。在 10Gbps 的广域网（WAN）上，这部分通信约需 112 秒，而同一轮 GPU 计算本身约 24 秒，大量训练时间会被跨域梯度同步吞掉。

相比之下，流水线并行是更适合作为跨数据中心训练的基础方案。它把模型层切成多个连续阶段，不同 GPU 负责不同阶段，并通过 micro-batch 像流水线一样推进。这样跨 DC 边界只需要在相邻阶段之间传递中间结果和反向梯度，不需要每轮同步完整模型梯度。同样以 LLaMA2-70B 为例，流水线并行可以把跨域通信降到每个 micro-batch 约 128MB，跨域通信约占整体训练时间的 38.8%。

但流水线并行只能降低通信量，无法直接消除跨数据中心网络带来的性能损失。

在 10Gbps、约 2000km 的广域网条件下，百卡 H200 训练 70B 模型时，仿真分析表明如果直接使用面向机房内部网络设计的流水线并行方案，训练吞吐会下降到同机房理想吞吐的 56.4%。在哈密至深圳、实际传输距离超过 4000 公里的跨域混训真实场景中，这一问题进一步放大：300 亿参数模型跨机房训练吞吐只有同机房下的 42%，GPU 会因等待远端中间结果而长时间空闲，利用率严重不足。这意味着，如果缺少系统优化，跨数据中心训练很难真正发挥聚合碎片化GPU资源的价值。

结合新疆-北京、新疆-深圳等真实长距离跨域训练中的观察，造成这一问题的原因主要有两类：

1. 跨域通信时间显著变长

在单个数据中心内部，GPU 通常处在高度优化的专用网络里：单机内部有 NVLink、Infinity Fabric / xGMI 或 PCIe 等 GPU 互联，机间有 InfiniBand 或 RoCE 等高速 scale-out 网络，通信通常具备微秒级延迟、数百 Gbps 级带宽。跨数据中心之后，GPU 可能分布在不同城市甚至不同省份，相隔数百到数千公里，传播延迟会从微秒级上升到毫秒级，跨省场景下甚至达到数十毫秒。与此同时，可用带宽也可能从数百 Gbps 下降到数十 Gbps，甚至数 Gbps。原本近乎可以忽略的通信开销，会在跨域场景中被显著放大。

2. 跨域网络更容易出现突发拥塞和带宽利用不足

数据中心内部网络通常会尽量设计成无收敛或低收敛；而跨域链路的收敛比往往更高，可能达到 1:8 甚至更高。多个训练节点的传输会共享同一条瓶颈链路，一旦它们在相近时间发起通信，多对一突发流量的聚合发送速率就可能超过链路带宽，在瓶颈链路处形成排队。而跨域网关设备缓存有限，难以承载大量排队，进而引发丢包和重传，进一步拉长通信完成时间。另一方面，跨域链路延迟高，带宽也会波动，发送端很难及时调整速率：发得太激进会造成拥塞，发得太保守又会浪费带宽。

因此，跨数据中心训练的优化关键在于：如何尽可能降低跨域通信对训练吞吐的影响。

一方面，系统需要在动态、高收敛比的广域网中维持高带宽利用率，同时避免突发拥塞、丢包和重传；

另一方面，也需要把不可避免的跨域通信时间尽可能隐藏到 GPU 计算之后，减少流水线等待空泡。

后续系统设计正是围绕这两点展开：让跨域传输更快速和稳定，让通信与计算更充分地重叠。

03 核心思路：让训练系统具备网络实时感知能力

为了让流水线并行真正适配高延迟、低带宽、易拥塞的跨数据中心网络，我们从网络传输、流水线编排和显存管理三个维度进行了系统优化。核心目标很直接：让跨域通信更稳定，让 GPU 少等待，让有限显存支撑更大的调度空间。

1. 更稳定的跨域传输：应用层轻量 Proxy 抑制突发拥塞

在哈密至深圳这样的长距离跨域训练场景中，训练任务不是偶尔跨域传一次数据，而是在每轮迭代中持续产生大量跨 DC 边界传输。如果多个发送端在相近时间把中间结果推向同一条瓶颈链路，就容易形成多对一突发传输，带来通信长尾。由于 WAN 反馈链路长、带宽又会波动，仅依赖每个发送端各自根据拥塞反馈实时调速，往往很难同时做到高带宽利用率和低拥塞。

传统方向通常依赖更强的网络硬件：例如用更大缓存的交换设备吸收突发流量，或通过专用拥塞反馈机制提前通知发送端降速。但这会带来更高硬件成本、更复杂的协议栈改造，也不利于跨云、跨地域的大规模部署。

我们的做法更轻量：只在应用层，也就是训练框架侧引入 Proxy 调度能力，从发送端控制跨域传输节奏：

根据实时估计的瓶颈带宽，为不同跨域传输分配发送时机；
将原本堆积在网关交换机 buffer 中的不可控排队，前移到分布在多台机器上的发送端有序调度；
不改变数据传输路径，也不依赖专有交换机能力。

从实验结果看，无论是专线还是公网链路，引入 Proxy 调度后，通信完成时间（FCT）分布都明显收窄，长尾完成时间降低。这说明发送端主动节奏控制能够有效抑制突发拥塞，让跨域传输更稳定、更高效。

2. 更高效的流水线编排：把跨域通信藏进计算里

前面提到，4000 公里跨域混训中最直观的问题，是 GPU 因等待远端中间结果而长时间空闲。流水线并行虽然降低了跨域通信量，但传统 1F1B、ZeroBubble 等调度主要面向机房内部低延迟网络。一旦相邻阶段被放到不同数据中心，跨域通信会把原本紧凑的执行节奏拉开，产生等待通信的流水线空泡。

一个自然思路是提前计算更多内容，让 GPU 在等待远端数据传输期间有其他计算任务可做，从而实现计算与通信重叠。但跨域流水线调度不只是“在 warmup 多算几个 Forward”。对于 ZeroBubble 一类调度而言，每个 micro-batch 涉及 F / B / W 三类计算阶段，它们的依赖关系、显存占用和对上下游阶段的影响都不同。因此，系统需要从全局视角编排所有可执行任务的顺序以达到最佳的计算通信重叠效果。

跨域网络的实时变化进一步放大了这个问题。在每轮训练迭代中，由于广域网带宽波动，不同 micro-batch 的通信时间可能出现明显差异。如果在训练开始前计算出一套固定执行的调度方案，就必然会落入两类失配：当实际延迟高于预期时，调度偏乐观，GPU 会因为远端数据未及时到而等待；当实际延迟低于预期时，调度偏悲观，关键数据可能已经到达，却被提前安排的低优先级任务挡住，同样会产生空泡。

因此，我们采用实时网络感知的流水线动态编排，不再依赖训练开始前生成的固定调度表，而是在运行过程中根据远端数据的预计到达时间、当前 GPU 上可执行的 F / B / W 任务，以及显存状态，动态决定下一步执行顺序：

通信还在路上时，系统会优先选择本地已经满足依赖的计算任务，用它们填补等待窗口，避免 GPU 空转；
关键数据即将到达时，系统会避免启动耗时较长或低优先级的任务，防止关键路径被挡住；
网络状态发生变化时，系统会根据新的带宽和延迟估计调整 F / B / W 的执行顺序，让调度持续贴合当前通信条件。

通过这种方式，流水线调度可以跟随 WAN 状态变化，把更多跨域通信时间隐藏在 GPU 计算之后，从而减少静态调度在动态网络下造成的空泡。

3. 更灵活的显存管理：用等待通信的窗口释放调度空间

在长距离跨域训练下，如果想让 GPU 少等，就需要提前执行更多可计算任务来覆盖通信时间；但提前计算越多，激活等中间结果占用的显存也越多，调度空间很快会被显存卡住。一旦显存不足，就可能触发 OOM，导致训练无法继续。

跨数据中心通信延迟虽然降低了执行效率，但也拉长了中间结果在 GPU 中的“等待时间”。在流水线训练中，激活等中间结果通常在前向计算后产生，并在后向计算时被消耗。如果前向和后向之间的时间间隔因为跨域通信被拉长，这些暂时用不到的数据就可以先 offload 到容量更大的 Host Memory，甚至 SSD 中，并在后向计算真正开始前 reload 回 GPU。

这相当于把原本的通信等待窗口，转化成显存优化窗口。

为了尽可能利用这个窗口释放显存，同时避免 offload 过多导致 reload 不及时、反而阻塞计算，我们的系统会根据实际网络情况动态调整 offload 策略：

网络较慢、等待窗口更长时，更积极地迁移中间数据，释放 GPU 显存；
网络较快、窗口较短时，更保守地迁移，确保数据能在后向计算前及时加载回 GPU。

通过将跨域通信带来的等待窗口转化为显存优化窗口，系统在不增加任何额外计算开销的前提下——无需增大张量并行度或开启激活重计算——即可释放出足够的 GPU 显存空间，支撑流水线调度在同等硬件条件下获得更大的自由度，从而进一步降低流水线空泡率、提升端到端训练吞吐。

04 性能验证：从“能跑”，到“又快又稳地跑”

为了验证上述优化是否真正有效，我们分别在 trace-driven 仿真环境和真实跨数据中心专线部署中进行了测试。前者用于评估系统在不同 WAN 带宽、延迟和波动条件下的稳定性；后者则进一步覆盖真实跨域传输、异构 GPU、浅缓存交换机以及超长距离专线等现网因素，其中包括哈密至深圳、实际传输距离超过 4000 公里的 300 亿参数模型跨域混训场景。对比对象包括：

机房内常用流水线调度：1F1B、ZeroBubble；
面向跨域训练的离线调度方案：Crosspipe(ATC'25), JEEVEs (Hotnets'25), PipeMorph(NSDI'26).这类方法通常根据预估网络状态，在训练前生成一套固定执行计划；
我们的网络感知训练系统：同时优化跨域传输、流水线编排和显存管理。

真实网络 Trace 回放：在动态 WAN 下保持稳定加速

首先，我们使用从 Google Cloud Platform 和本地到云端链路采集到的真实 WAN 带宽 trace，构建 trace-driven 仿真环境。测试覆盖三类典型跨域链路：

跨区域云间链路：网络传播延迟约 60ms，平均带宽约 12.38Gbps；
跨洲云间链路：网络传播延迟约 180ms，平均带宽约 5.53Gbps；
本地到云端链路：网络传播延迟约 30ms，平均带宽约 1.63Gbps。

这些 trace 体现了真实 WAN 中常见的带宽波动和突发变化。实验结果显示，相比现有方案，我们的方法在三类链路上都取得了稳定加速：在跨区域云间链路、跨洲云间链路、本地到云端链路场景下，分别实现最高 1.87×、2.22×、1.62× 加速。

随着链路带宽下降、波动增强，静态调度方案更容易出现通信等待或计算安排失配；网络感知系统能够根据实际网络状态调整传输和流水线执行，因此在多种动态链路下保持稳定收益。其中Ours w.o. CommOpt指去除了Proxy 通信调度优化的系统，其通过更灵活的流水线编排和显存优化相比现有做法仍能取得显著收益。

真实跨数据中心部署：异构 GPU + 长距离专线下依然有效

为了进一步验证系统在真实环境中的可用性，我们还在多组真实跨数据中心专线部署中进行了端到端测试，覆盖不同距离、带宽和 GPU 组合：

哈密-北京 10Gbps / 60ms RTT 专线，连接高端数据中心训练 GPU 与 NVIDIA H20 异构集群，测试 LLaMA2-13B 和 LLaMA2-70B；
新疆-广东（哈密-深圳）4Gbps / 90ms RTT 专线，实际传输距离超过 4000 公里，连接高端数据中心训练 GPU 与 RTX 4090 异构集群，完成 LLaMA2-7B 和 LLaMA2-30B 跨域混训验证。

这两组部署包含真实跨域传输、异构 GPU、浅缓存交换机、长 RTT 和受限带宽等仿真环境中难以完全覆盖的因素。其中，部署 B 的链路距离更长、带宽更低，是更严苛的现网跨域训练场景：在直接跨机房训练时，300 亿参数模型吞吐只有同机房下的 42%，GPU 因等待远端中间结果而长时间空闲，对跨域传输稳定性和流水线调度提出了更高要求。

结果显示，我们的方法在真实部署中依然稳定超过 1F1B、ZeroBubble 以及离线跨域调度方案，最高实现 1.75× 加速；相比现有跨域优化方案，最高也有 1.48× 提升。在新疆-广东超 4000 公里现网验证中，这套系统也支撑 300 亿参数模型完成稳定跨域混训，说明其不仅能在常规跨数据中心专线中取得收益，也能适配更长距离、更强网络约束下的真实训练场景。