任务是用 msprof 测量 elastic_dispatch.cpp 的通信性能，再用 MindStudio Insight 分析 icache miss 等问题。实际环境是 昇腾 950、最新 CANN、多机多卡。第一次接触这套工具，最容易卡住的不是参数，而是分不清“整个分布式调用慢”“某个核慢”和“某类指令停顿”分别需要什么证据。

本文按 确认 V2 调用入口 → 建立延迟基线 → 采集系统时间线 → 检查 ICache 与 SIMT 停顿 → 对照实验展开。内容来自截至 2026-09-16 的公开官方文档和固定版本源码，没有在目标 950 集群实测；涉及通信重放的命令是能力探测模板，不承诺该自定义算子已被工具支持。

之前学习 Data-as-Flag 时，我们讨论过把 flag 塞进数据块：每个 512 B 块中，480 B 是有效数据，32 B 用来证明“这一块已经到达”。现在希望减少这部分控制开销，改成“前面 relaxed order 发送，最后一个 strong order”。

这个改动的核心，是把“每块都带证明”改成“用队列末尾的有序操作，为前面一批传输提供完成证明”。 但必须解释清楚：最后一个是什么、保证覆盖哪条队列、接收方如何得知完成，以及何时可以复用 buffer。本文沿实际代码逐层回答。

理解 elastic dispatch，需要把 Python 接口、native 调用链、对称内存申请和 device kernel 放在同一条执行路径中阅读。本页基于源页面收录的 cf9f87a51854ac20d608f683979171cb1fc65c69 版本证据，通过交互式 DAG、函数下钻和源码定位建立这些层次之间的对应关系。

核心边界是：host 路径与容量预算不代表 device 数据搬运已经实现。页面保留占位 kernel、缺失的数据布局与同步风险提示，帮助读者辨认已有实现和待补齐部分。

阅读 4357 行 deepep_moe_dis_dispatch.h 时，最大的困难不是找到某个函数，而是持续维护 E2E 阶段、函数调用和具体源码行之间的对应关系。静态长文适合建立概念框架，却不便于在多条并行执行路径之间反复定位。

本页将同一份 Ascend C 参考实现组织为三轨联动工作区：左侧展示 Full-Mesh dispatch 的端到端执行 DAG，中间拆解当前函数的调用和分段逻辑，右侧保留完整源码。读者可以从阶段进入函数、从调用跳转到被调函数，也可以通过搜索和行号反向追踪同步协议与数据流。

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

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

我面对的是一个很具体、也很容易被“理论带宽”带偏的问题：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 的尾延迟。