这篇笔记把 DeepEP v2 的对象、内存、同步和数据路径压缩成五张结构图。正文只补充图中不适合展开的语义边界。
架构总览
ElasticBuffer 管理 Dispatch / Combine 所需的通信与 Buffer 资源；EPHandle 保存一次 EP 数据传输的元数据，包括确定性模式、Dispatch 缓存和 GroupGEMM 的 Token Padding 信息。
ElasticBuffer：物理分段，虚拟连续
CPU 与 GPU 内存物理上分段，但通过 CUDA VMM 映射为连续虚拟地址，再注册为 NCCL Window。这里的 Window 提供跨 Rank 访问语义；它本身不等同于 NVSHMEM 原生的对称内存抽象。
Barrier 与通信计算重叠
图中展示的是全局 Barrier 的基本心智模型。Hybrid 分层 Barrier 的并行模式还存在一个容易误判的弱同步边界：A0 分别看到 B0 的 Scale-out 到达和 A1 的 Scale-up 到达，并不能推出 B1 已经到达。局部可见的两条同步事实不能自动合成为全局强 Barrier。
async_with_compute_stream 允许 Barrier 延迟返回 Event，在真正消费通信结果之前继续执行独立计算；prefer_overlap_with_compute 则通过减少通信占用的 SM，为计算留下资源。
Dispatch / Combine 数据路径
Direct 是单跳传输，不需要构造两跳的 Warp 生产消费流水；Hybrid 则由 Notify Warp、Scale-out Warp 和 Forward Warp 分别承担控制、RDMA 生产与 NVLink 消费。Combine 最终依赖 Metadata 恢复 Token-major 布局并完成 Reduce。
从 Legacy 到 Elastic
Elastic 的重点不是消除 LL 与 HT 的 Workload 差异，而是先统一 Buffer 和 Dispatch / Combine 接口，再让 AutoTune 与 JIT 根据场景确定 Kernel、Buffer、SM、QP 和 Channel 配置。统一抽象换来了更大的 Buffer、更多 QP 状态，以及 EP Kernel 和 EPHandle 的额外资源占用。