我在上一篇博客说了一堆流水线并行的不好，这一篇来填坑：不用 PP，参数怎么放，长上下文怎么切，跨机通信又怎么办？

在讨论这个话题之前，我们先做一些假设和限制，以此来收缩我们的设计空间。要不然的话，什么功能都往上加，就又变成 Megatron 了，还不如直接把 Megatron 拿来用。

约束条件

• 支持万亿级别参数量（1T+ params）
• 支持一百万上下文长度
• NVL72 集群
• 不依赖 CPU offload 存放模型状态和激活值。

最近我的工作重心从推理系统的开发转移到了后训练系统的开发。看着原本推理引擎里面干净利落的代码，落在训练框架中却变成了弯弯绕绕，我的川字纹加深了。它跑起来很慢，用起来很不灵活，埋伏着各种陷阱，维护起来也很困难。这个训练框架本意是一个精简的系统，然而却朝着 Megatron 的复杂度发展了。

同事们和我几番尝试了重构，总是有些脏东西在阻碍我们把代码变得优雅。渐渐地，越来越多的线索指向了同一个方向——流水线并行（Pipeline Parallelism, PP）。

上周我们公司把最近对大语言模型中点对点通信的一些成果总结了一下，写了一篇论文挂在了 arXiv 上面，同时也在 GitHub 上面开源了代码。

我们构建了一套基于“无序可靠数据报传输（Unordered Reliable Datagram）”语义的 RDMA 通信库，既能跑在 AWS EFA，又能跑在 NVIDIA ConnectX。我们把这套 RDMA 通信库应用在了三个场景下面：分离式推理的 KvCache 传输、强化学习后训练中的模型参数更新、以及 MoE 通信。这个 MoE kernel 在 ConnectX-7 上面跑 decode 甚至比 DeepEP 还快一点点，在 EFA 上也是首次达到了可用的性能。

这篇文章我跟大家讲讲其中的来龙去脉，更多的是想分享一下做这些工作的动机以及背后的故事。对具体的技术细节感兴趣的读者可以在文章末尾的链接里面找到我们的论文、代码、以及相关的博客。

上一篇博客介绍了我们如何实现跨机秒传RL模型参数更新。这一篇博客简单补充一些后续：

1. Kimi-K2 (1T params)，256卡BF16训练，128卡FP8推理，参数更新只需要不到 1.3 秒。
2. 参数更新的流水线稍微再优化了一些，增加了两个可以并行的项目：H2D Memcpy 和全局通讯屏障。
3. 跑了一遍 PyTorch Profiler，方便直观地分析参数更新流水线，看看时间都花在哪里了。
4. 加了一些图方便理解。

我最近花了两周时间把 Qwen3-235B （BF16 训练，FP8 推理）的跨机（128卡训练，32卡推理）参数更新跑通了，只需要2秒。这篇博客我打算不单单是给读者呈现一个解决方案，而是记录一下我的探索过程，以及我的一些思考。过几天也会在公司博客上发一篇精简版。