理解 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 的尾延迟。

Kimi K3 是一个面向长时程智能体任务的原生多模态混合专家模型：总参数量 2.78T，每个词元激活 104.2B 参数，训练上下文最长 100 万词元。它把 Kimi Delta Attention（KDA）、Block Attention Residuals（AttnRes）和 Stable LatentMoE 放进同一套训练系统，并进一步连接原生多模态预训练、分档推理投入强化学习、量化感知后训练与大规模并行基础设施。

本文按照论文的段落和小段落顺序进行逐句翻译，保留全部 16 幅图、5 张表、编号公式、交叉引用和技术附录。为帮助第一次接触相关概念的读者，额外说明均放在明确标记的“小白提示”中，不与原论文观点混写。