perf(moonep): balance prefetch over shared QPs

[Kur0x]

## 背景
MoonEP PrefetchWeight 在 Ascend950 shared UDMA domain 中直接使用 logical worker index 作为 physical QP index。
固定 32-QP profile 中：

QP 0-15 使用六端口 CLOS
QP 16-31 使用两端口 CLOS

原实现的 4 个 worker 使用 QP {0,1,2,3}，流量全部落在六端口 CLOS，两端口 CLOS 未被利用，导致大数据量 PrefetchWeight 无法充分使用单卡 8 个外部端口。
修改内容
将 logical worker 与 physical QP 解耦：



Worker 数量
Shared domain physical QP




1
{0}


2
{0,1}


4
{0,1,2,16}


8
{0,1,2,3,4,5,16,17}



4-worker 映射按照 3:1 分配流量，与六端口/两端口 CLOS 的物理带宽比例一致。
具体改动：

在 Host layout 中生成 logical-worker-to-physical-QP 映射
使用一个私有 uint64_t 参数将最多 8 个 QP index 传入 Kernel
logical worker 继续负责原有 slot 分工
queue lookup、UDMA GET submit 和 CQ wait 改为使用 physical QP
非 shared UDMA domain 保持 identity mapping
增加独立 PrefetchWeight benchmark、统计单测和性能文档

未改变：

公共 MoonEP ABI 和 Python API
PrefetchWeight slot ownership
注册内存和 peer-memory 行为
WQE 在 UB 中构造并通过 MTE3 发布的流程
st_dev doorbell 和 CQ completion 语义
Dispatch、Combine 和 ReduceGrad

性能结果
测试环境：

TileXR base：c39c433
Native MoonEP：53e03002655d07cfc39e7e9ca2c2aa18583c6c0b
服务器：141.61.49.195
设备：8 x Ascend950PR，一卡一 rank
CANN：9.1.T560
Driver：25.1.rc1.b188

固定 workload：

EP8，32 experts
每 rank 4 local experts、4 remote slots
BF16
H=7168，Hf=2048
每个 projection row 28 MiB
每 slot 84 MiB
每 rank 每轮传输 336 MiB
3 x (5 warmup + 20 measured)
NPU event 计时，逐 iteration 取 8 rank 最大值
所有 BF16 目标 slot 精确校验




实现
P50
P99
有效带宽




TileXR main
1272.83 us
2662.19 us
276.80 GB/s


本 PR
986.99 us
1044.07 us
356.97 GB/s


Native MoonEP
7554.13 us
7810.42 us
46.64 GB/s



相较 TileXR main：

P50 降低 22.46%
有效带宽提升 28.96%
达到单卡 400 GB/s 理论单向带宽的 89.24%

相较 Native MoonEP：

PrefetchWeight P50 提升约 7.65x

优化版本三次 repeat 的 P50 分别为：
975.78 / 990.03 / 985.84 us</code></pre><h2>样本处理</h2><p>TileXR NPU event 偶发返回 <code dir="ltr">0.044 us</code>，该值不可能代表 336 MiB 数据传输。</p><p>benchmark 的处理方式：</p><ul><li>所有原始 event 样本均保留在 artifact 中</li><li><code dir="ltr">&lt;= 1 us</code> 的样本标记为 invalid</li><li>invalid 样本不参与 P50、P99 和带宽统计</li><li>高耗时样本不做过滤</li></ul><p>样本数量：</p><div><div><div>
实现 | 原始样本 | 有效样本 | Invalid event
-- | -- | -- | --
TileXR main | 60 | 55 | 5
本 PR | 60 | 52 | 8

</div></div></div><h2>验证结果</h2><ul><li>Ascend950 8 卡 BF16 slot 精确校验通过</li><li>CANN 9.1 Kernel 编译、嵌入、Host 铯接和安装通过</li><li>MoonEP CTest：<code dir="ltr">33/33</code> 通过</li><li>MoonEP Python：<code dir="ltr">243 passed, 2 subtests passed</code></li><li>PrefetchWeight benchmark 单测：<code dir="ltr">4/4</code> 通过</li><li>公共 ABI 测试通过</li><li><code dir="ltr">git diff --check</code> 通过</li><li>官方 HCCL AIV-only 环境基线通过</li><li>Ascend C Host/Kernel 关键路径审查无关键发现</li></ul><h2>文档</h2><p>本 PR 增加：</p><ul><li>PrefetchWeight benchmark 使用说明</li><li>shared-QP 设计和执行计划</li><li>完整性能对比</li><li>原始 artifact 路径</li><li>event 异常处理规则</li><li>无效实验和环境问题</li><li>下一阶段优化建议</li></ul><h2>后续工作</h2><ol start="1"><li>使用 msprof 和物理端口计数器分析距约 389 GB/s 实测 transport ceiling 的剩余差距。</li><li>增加长时间采样，定位 NPU event 偶发 <code dir="ltr">0.044 us</code> 的原因。</li><li>测试不同 slot 数量和 payload 分布，确认固定 <code dir="ltr">3:1</code> QP 映射在非均衡场景下仍然最优。</li><li>测量 registered UDMA 与 peer-memory 的数据量 crossover，小数据继续优先使用 memory，大数据使用 UDMA。</li><li>数据面接近饱和后，再评估固定 launch/status overhead。</li></ol><pre dir="ltr"><code></code></pre><!--EndFragment-->
</body>
</html>

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8e41b76f92

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".