世界模型越来越大，训练挑战也从「能不能跑起来」转向「能不能稳定 Scale」。

基于百度百舸 hpas.lgn7ib 实例（集群无 HPN、实例内无 NVLink），从 4 节点 32 卡扩展至 64 节点 512 卡，扩展效率达 97.48%，吞吐从 33.997 提升至 530.227 samples/s，近线性扩展成立，Loss 曲线与 4 节点完全对齐。

本次实践验证 AI Infra 工程优化的价值：在通用 GPU 集群上，通过训练框架、通信网络与工程体系的系统协同，同样可以高效支撑 64B 级别世界模型的大规模训练。

---

在上一篇文章《不用 NVLink，如何通过 AI Infra 工程优化拉满 Cosmos 3 训练吞吐》中，我们基于百度百舸平台 hpas.lgn7ib 实例（搭载国内主流 GPU 型号）完成了 16B 参数规模的 Cosmos3-Nano-Policy-DROID 训练任务调优：任务启动速度提升 89 倍、单机吞吐提升 99.3%、MFU 达到 0.42（超过官方基准的 0.23–0.3），并在 12 节点、96 卡规模下验证了 98.3% 的集群扩展效率。

这一次，我们将模型升级成 64B 参数规模的 Cosmos3-Super，并把基于 hpas.lgn7ib 实例的集群规模进一步扩大到 64 节点、512 张 GPU，希望在相同的平台条件下，回答一个更关键的问题：在通用 GPU 集群上，世界模型能否继续稳定扩展到更大规模？

1. 一次没有 NVLink 的 Scaling 验证

长期以来，大规模模型训练通常依赖高性能互联能力来降低参数同步和梯度通信开销，这也让很多人形成了一个印象：只有具备专用高性能网络互联的 GPU 集群，才能支撑世界模型训练。
而本次实践验证的，正是另一种可能。

整个实践基于百度百舸平台 hpas.lgn7ib 实例完成，实例间未部署 HPN 网络，实例内部也没有 NVLink。跨节点通信完全依托百度智能云的 ERI（弹性 RDMA 互联）网络能力，结合训练框架和并行策略优化，完成了一次完整的 Weak Scaling 验证。

Weak Scaling ：即每张 GPU 的 batch size 固定不变，仅随节点数增加而增加总的并行规模，理想情况下总吞吐应随节点数线性增长，因此 Weak Scaling 效率是衡量集群通信与调度开销是否随规模失控的核心指标。

官方参考方案采用 Cosmos3-Nano-Policy-DROID 进行 SFT，我们则将模型替换为 Cosmos3-Super，并沿用官方原有的并行策略配置。

Cosmos3 的 MoT 采用双模块架构： Reasoner 模块负责知识表达与推理，Generator 模块负责生成。这也是 Cosmos3 官方给出的 SFT 策略对具身智能行业的现实意义所在。具身智能公司可以用自己采集的场景数据，只对 Generator 模块相关的参数做 SFT，而不必触碰负责知识表达与推理的 Reasoner 模块，就能针对性提升自家机器人产品在具体任务上的表现。

需要说明的是，完整的 64B 参数仍会全部加载并参与前向计算，但只有部分参数参与反向传播与参数更新。本次训练并未更新全部 64B 参数，而是冻结了负责知识表达与推理的主体网络，仅对生成相关模块开放梯度更新，包括 moe_gen、time_embedder、vae2llm、llm2vae、action2llm、llm2action、action_modality_embed 等。

最终，共有 718 个 Tensor、约 31.26B 参数拥有梯度与 Optimizer State，真正参与参数更新。

在并行训练方面，实践采用 PyTorch FSDP2 对模型参数、梯度以及 Optimizer State 进行全量分片（data_parallel_shard_degree 随节点数从 16 一路扩展到 512），并结合 Torch Compile 对训练过程进行编译优化。整个实践按照 2、4、8、16、32、64 节点逐级扩展，通过 Weak Scaling（每卡固定 batch size = 32）持续验证平台的扩展能力。

Cosmos3 的 MoT 采用双模块架构： Reasoner 模块负责知识表达与推理，Generator 模块负责生成。这也是 Cosmos3 官方给出的 SFT 策略对具身智能行业的现实意义所在。具身智能公司可以用自己采集的场景数据，只对 Generator 模块相关的参数做 SFT，而不必触碰负责知识表达与推理的 Reasoner 模块，就能针对性提升自家机器人产品在具体任务上的表现。

需要说明的是，完整的 64B 参数仍会全部加载并参与前向计算，但只有部分参数参与反向传播与参数更新。本次训练并未更新全部 64B 参数，而是冻结了负责知识表达与推理的主体网络，仅对生成相关模块开放梯度更新，包括 moe_gen、time_embedder、vae2llm、llm2vae、action2llm、llm2action、action_modality_embed 等。

最终，共有 718 个 Tensor、约 31.26B 参数拥有梯度与 Optimizer State，真正参与参数更新。

在并行训练方面，实践采用 PyTorch FSDP2 对模型参数、梯度以及 Optimizer State 进行全量分片（data_parallel_shard_degree 随节点数从 16 一路扩展到 512），并结合 Torch Compile 对训练过程进行编译优化。整个实践按照 2、4、8、16、32、64 节点逐级扩展，通过 Weak Scaling（每卡固定 batch size = 32）持续验证平台的扩展能力。

2. 从 4 节点到 64 节点，训练性能近乎线性扩展

在正式扩展之前，我们先验证了运行 Cosmos3-Super 所需的最小集群规模，并观察了从 2 节点扩展到 4 节点、同时启用完整 Compile 配置后的吞吐变化。

按照官方配置，为了对 Cosmos3-Super 进行 SFT 训练，需要同时开启 VAE Compile 与 MoT Language Compile。但在 2 节点环境下，Language Compile 在编译阶段会额外占用显存，训练初始化便触发 OOM。这意味着 2 节点已经是该硬件规格下运行 Cosmos3-Super 的最小集群规模，且受限于显存，只能关闭 Language Compile、仅保留 VAE Compile Only 才能避免初始化阶段的 OOM，实测整机吞吐约 14.76 samples/s（median step time 34.68s）。

当训练扩展到 4 节点后，VAE Compile 与 Language Compile 得以同时开启，整机训练吞吐从约 14.76 samples/s 跃升至 33.997 samples/s（median 口径）。需要说明的是，这一跃升同时包含了节点数翻倍和 Compile 配置变化两个因素，并非严格的 Compile A/B 对照；涨幅（2.3x）超过了节点翻倍本身的理论涨幅（2x），说明 Language Compile 的开启带来了额外的性能收益，方向性印证了编译优化能够有效释放 GPU 算力。

随后，我们以 4 节点为基准继续扩大训练规模，结果如下（10–50 step 窗口，median 口径）：

从 4 节点到 64 节点，节点规模扩大 16 倍，median step time 仅从 30.12s 增加到 30.90s，训练吞吐从 33.997 samples/s 提升到 530.227 samples/s，扩展效率保持在 97.48%（mean 口径同样为 97.43%，两种统计口径结论一致），没有因为节点增加出现明显性能拐点。

更重要的是，这一扩展结果并不依赖具备高性能机内与机间互联能力（NVLINK + HPN）的算力平台，而是在 hpas.lgn7ib 这类实例间无 HPN、实例内无 NVLink 的通用 GPU 集群基础上，基于 FSDP2 通过 AI Infra 工程优化以及 ERI 网络协同完成。

在训练从 16 节点扩展到 32/64 节点过程中，FSDP2 对小参数切分时产生了合法的 Empty Local Shard，暴露出 NormMonitor 和 FusedAdam 对空分片支持不足的问题。我们为两者统一补充了空分片兼容逻辑：NormMonitor 将空分片的范数贡献按 0 处理，FusedAdam 在执行 fused kernel 前跳过 numel()==0 的分片，并在更新后恢复梯度引用。由于空分片不包含任何参数元素，这些处理不会改变参数更新的数学语义。修复后，32 节点和 64 节点训练均可稳定运行。

与此同时，我们也对比了不同节点规模下的 Loss 曲线：4 节点和 64 节点的 Loss 走势基本一致，均从约 26 起步，50 step 后收敛至 1.7–2.1 区间同一量级，验证了工程优化对训练收敛无影响。


这些实践结果表明，世界模型的大规模高效训练不仅依赖硬件互联，更依赖训练框架、通信网络与基础设施之间的系统协同。

3. 从一次实践，到一套 AI Infra 工程优化体系

随着世界模型从 16B 扩展到 64B 乃至更大规模，分布式训练面临的显存、通信、并行策略和系统稳定性等方面的挑战进一步加剧，AI Infra 工程优化的重要性愈发凸显。谁能在训练框架、通信网络和工程体系上做得更扎实，谁就能用更低的成本训练更大的模型。

这次实践证明，百度百舸具备一套可复用的 AI Infra 工程能力。这套能力基于国内主流 GPU 集群（以 hpas.lgn7ib 实例为代表，集群无 HPN、实例内无 NVLink），覆盖了从单机到大规模集群的全链路优化：单机场景下的数据加载优化、I/O 流水线重构、Compile 适配与显存调优，大规模集群场景下的 FSDP2 全量分片、ERI 网络协同。结果表明，百度百舸能够确保 64B 级别的 Cosmos3-Super 模型在此类通用 GPU 集群上高效、稳定地训练。

未来，百度百舸将继续围绕训练效率、集群扩展能力和系统稳定性持续演进，为 WM、VLM、VLA 等更多新一代基础模型提供高效、稳定、可扩展的训练平台。

更多关于 Cosmos3 集群训练优化、模型效果评测的全方位解读，敬请期待后续文章。