MoE dispatch 的困难并不只是把 token 从一张卡搬到另一张卡，而是要在 Top-K 路由运行时才确定的前提下，同时解决槽位分配、跨核协作、远程写入、完成通知和接收端连续排布。如果只盯着某个拷贝循环，很容易忽略控制面和同步协议才是这份实现的骨架。

本文以 deepep_moe_dis_dispatch.h 的 4357 行 Ascend C 参考实现为对象，从 SIMT 线程模型和 Full-Mesh 通信窗讲起，沿“本地打包 → 生成并提交 URMA WQE → doorbell 触发 → flag/count 对账 → 前缀和定位 → 输出重排”还原完整执行路径。页面把关键函数、内存布局、时序约束和可验证的优化方向放到一张连续地图中，帮助初学者建立从源码行号到通信机制的对应关系。

这是一篇用于验证 HTML 正文文章接入 的站内测试文章。它保留 Markdown front matter 和简短导言，让 MkDocs Blog 能继续生成文章 URL、首页摘要、分类、标签和搜索索引；实际正文则由同名 .preview.html 在文章详情页中展示。

核心判断是：HTML 只是正文表现形式，Markdown 文件仍然是站内文章身份和索引入口。因此读者可以从笔记、分类或标签进入本文，也可以从本文返回对应索引页面。

一次 64 B 远端读取，数据在链路上只需要约 200 ns，端到端却可能超过 2 μs；当 1024 个本地发起上下文连接 1024 个远端端点时，按 Queue Pair（QP）组织的连接状态又会膨胀到约 537 MB。OpenURMA 认为这不是某个 RDMA Kernel 写得不够快，而是 QP over PCIe 这一抽象同时制造了状态乘积和外围设备往返。

OpenURMA 是 Unified Bus（UB）传输层与事务层的 clean-room 开放实现。它用 Jetty / TP Channel 拆开应用状态与可靠传输状态，把 UB Controller 放到片上总线，并为短同步操作提供绕过 Work Queue 的 Load/Store 路径。本文沿这条依赖链解释方案，同时把 500 ns / 2186 ns 放回论文的模拟条件：这组结果证明新抽象值得继续做成硅，不等于 Ascend 950 或任意商用 UB 产品已经交付同样数字。

我面对的是一个很具体、也很容易被“理论带宽”带偏的问题：Ascend DeepEP 的 MoE dispatch 吞吐只有硬件理论值的一半，128P 跨机场景尤其明显，而且系统里还有两层路由。麻烦在于，我既不熟悉 MoE dispatch 的接口与数据协议，也没写过典型 URMA/UDMA 算子，更不知道应该在哪里计时、打印和判断瓶颈。

这篇文章不从零散优化技巧出发，而是沿一条 token 的真实旅程，依次读懂 Python 接口、Host 侧 workspace/notify、Device 侧 AIV/UDMA/QP、目标 rank 的接收布局与反向 combine；再把 ascend_deepep、海思 hierarchy 和 MoonEP 的 peer 调度放进同一张拓扑图。最终目标不是立即猜出一个“神奇参数”，而是建立一条可证伪的优化路线：先区分数据面、控制面和同步面，再判断 128P 下真正撞到的是字节带宽、WQE 提交率、P 维路由扫描、拓扑扇出还是最慢 rank 的尾延迟。

我之前在 verl 里见过两种 vLLM offload 级别，后来又接触到 vLLM 的 KV offloading。再往 Mooncake 看，项目里似乎已经有 GDS。于是看到 vLLM Issue #48504 还要做 “GDS + KV offloading” 时，一个很自然的困惑出现了：这些机制是不是在重复做同一件事？

真正需要拆开的不是两个实现，而是三种不同的 offload 语义，以及两类不同的 GPU Direct。本文沿着实际数据路径，解释当前 vLLM 会自动做什么、Mooncake 怎样通过 Connector、Store 与 Transfer Engine 的解耦透明接入 GDS，以及 #48504 为什么仍然有独立价值。

最初的问题很直接：Mooncake 管理 KV Cache，那么“KV Cache 的元数据”能否选择放在内存或 SSD？继续追问后才发现，元数据这个词把几种完全不同的东西揉在了一起：PagedAttention 的 Block Table、Master 保存的全局副本目录、SSD backend 保存的文件位置索引，以及为了故障恢复生成的 snapshot。

只有先回答“哪一种元数据真正负责定位 KV Cache 数据页”，才有可能讨论它应该放在哪里。本文基于 Mooncake 固定版本 0518784d，沿代码中的两级定位链路展开，再解释 Master snapshot 如何以较短在线停顿保存控制面状态，以及它为什么不能替代 KV payload 的持久化。

一台服务器装有八张 400 Gbps NIC，不等于任意一张 GPU 都能拿到八张网卡的总带宽。现有 GPU 集群通常把 GPU 与“最近的”NIC 静态绑定；当 LLM 推理请求、MoE token 或推荐模型 embedding 产生不均衡流量时，热点 GPU 会堵在一张 NIC 上，旁边的 NIC 却可能空闲。

OSDI 2025 论文 FuseLink 的核心思想，是把 NVLink/NVSwitch 从“服务器内部的 GPU 互连”重新解释为“跨服务器网络的数据路径延伸”：流量先经 NVLink 到达更适合访问空闲 NIC 的中继 GPU，再通过 RDMA 发往远端。本文沿论文 Figure 1、2、3、4、5、8 还原这条设计链，并用其余实验结果说明收益、代价与边界。

GPUDirect Storage 已经能让 NVMe 和 GPU Memory 直接 DMA，为什么 NVIDIA 还要再做一套 SCADA？答案藏在“谁在运行时才知道下一块数据在哪里”这个问题里。

cuFile 适合由 CPU 或上层运行时提交已经成形的文件 I/O；图遍历、GNN 采样和磁盘型向量索引却可能让数十万个 GPU 线程各自发现下一个 offset。SCADA（SCaled Accelerated Data Access）试图把这些细粒度、数据依赖型请求留在 GPU 内核中：先经过 HBM 软件缓存与请求合并，再交给可信服务器访问本地或远端 NVMe。

一句话判断：SCADA 改变的首先是存储控制路径，其次才是数据路径。 它不是 GDS 的新名字，也还不是一个可直接下载部署的通用产品。公开论文已经证明 GPU-initiated storage 的基本机制，2024—2026 年的演讲和硬件演示展示了 SCADA 的扩展方向；但 API、部署要求和端到端生产数据仍处于有限公开阶段。

“GPU-aware” 很容易让人产生一个错觉：只要通信库能够接收 GPU buffer，数据就会完全绕开 CPU，通信也已经由 GPU 自主推进。现实并没有这么整齐。API 可能从 CPU 发起，数据却直接流向 NIC；GPU 也可能负责触发传输，但报文仍由 CPU 预先构造。

The Landscape of GPU-Centric Communication 给出的关键视角，是把通信拆成 API、报文构造、触发和数据路径，再观察每项责任究竟落在 CPU、GPU 还是 NIC。沿着这套坐标回看二十年演进，会发现主线不是“带宽越来越高”，而是先消除冗余拷贝，再缩短数据路径，最后把控制权逐步迁到 GPU。

把 SSD 数据送进 GPU，最直观的优化似乎是“绕过 CPU”。但这句话混合了两个不同问题：数据是否经过 CPU 内存，以及 I/O 请求究竟由 CPU 还是 GPU 发起。NVIDIA GDS 解决前者，BaM 进一步改变后者；代价是原本由 CPU 承担的队列管理、并发和缓存压力转移到了 GPU。

本文整理 DaMoN 2025 论文 Path to GPU-Initiated I/O for Data-Intensive Systems：先沿 Figure 1 比较五条 GPU-centric Storage 路径，再还原 BaM、GDS 与 SPDK 的实验边界。核心结论不是“GPU 发起一定更快”，而是系统应根据 CPU、GPU、PCIe、SSD 与数据复用状态，选择由谁支付 I/O 控制成本。