[Performance] Orchestrator避免频繁的内存分配和释放

[QuteMiao]

Platform

a5 (Ascend 950 hardware)

Runtime Variant

host_build_graph

Summary

实测结果（本次运行，PASSED）

host-orch: orch=3678950 ns H2D=107075660 ns (graph=105716560 ns sm=1359100 ns) alloc=66488960 B copy=5543943 B bw=51 MB/s sm_bw=172 MB/s

┌─────────────────────────┬───────────────────────────────────────────┐
│ 指标 │ 值 │
├─────────────────────────┼───────────────────────────────────────────┤
│ orch（host 建图） │ 3.68 ms │
├─────────────────────────┼───────────────────────────────────────────┤
│ H2D（合计） │ 107.08 ms（graph 105.72 ms + sm 1.36 ms） │
├─────────────────────────┼───────────────────────────────────────────┤
│ alloc（设备分配） │ 66.49 MB │
├─────────────────────────┼───────────────────────────────────────────┤
│ copy（H2D 拷贝） │ 5.54 MB │
├─────────────────────────┼───────────────────────────────────────────┤
│ bw（有效 H2D 带宽） │ 51 MB/s │
├─────────────────────────┼───────────────────────────────────────────┤
│ sm_bw（纯 SM 拷贝带宽） │ 172 MB/s │
└─────────────────────────┴───────────────────────────────────────────┘

关键发现

• 有效带宽只有 51 MB/s：5.54 MB 的拷贝摊到 107 ms（大头是 66 MB 的 device_malloc/acquire_graph_execution_buffer 分配耗时），说明 H2D 阶段的瓶颈是设备侧分配，不是 PCIe/DMA 搬运。
• 纯 SM 拷贝带宽 172 MB/s：反推 SM 段拷贝量 ≈ 228 KB（sm_copy_bytes = sm_bw × sm_time / 1000 ≈ 172×1.36M/1000 ≈ 233 KB），在 1.36 ms 内完成——这个值仍是小拷贝（228
  KB）的延迟主导速率，不代表峰值 DMA 吞吐；但已与 51 MB/s 拉开 3.4 倍差距，定量印证了「分配拖慢有效带宽」。

Git Commit ID

3f4686c

CANN Version

No response

Driver Version

No response

Host Platform

Linux (aarch64)

Reproduction

task-submit --device 6 --run \
     "python examples/a5/host_build_graph/qwen3_14b_decode/test_qwen3_14b_decode.py \
      --platform a5 --device 6 --manual include --runtime host_build_graph"

Expected Performance

预分配内存，Orchestrator中无DEVICE内存分配耗时

Actual Performance

实测结果（本次运行，PASSED）

host-orch: orch=3678950 ns H2D=107075660 ns (graph=105716560 ns sm=1359100 ns) alloc=66488960 B copy=5543943 B bw=51 MB/s sm_bw=172 MB/s

┌─────────────────────────┬───────────────────────────────────────────┐
│ 指标 │ 值 │
├─────────────────────────┼───────────────────────────────────────────┤
│ orch（host 建图） │ 3.68 ms │
├─────────────────────────┼───────────────────────────────────────────┤
│ H2D（合计） │ 107.08 ms（graph 105.72 ms + sm 1.36 ms） │
├─────────────────────────┼───────────────────────────────────────────┤
│ alloc（设备分配） │ 66.49 MB │
├─────────────────────────┼───────────────────────────────────────────┤
│ copy（H2D 拷贝） │ 5.54 MB │
├─────────────────────────┼───────────────────────────────────────────┤
│ bw（有效 H2D 带宽） │ 51 MB/s │
├─────────────────────────┼───────────────────────────────────────────┤
│ sm_bw（纯 SM 拷贝带宽） │ 172 MB/s │
└─────────────────────────┴───────────────────────────────────────────┘

关键发现

• 有效带宽只有 51 MB/s：5.54 MB 的拷贝摊到 107 ms（大头是 66 MB 的 device_malloc/acquire_graph_execution_buffer 分配耗时），说明 H2D 阶段的瓶颈是设备侧分配，不是 PCIe/DMA 搬运。
• 纯 SM 拷贝带宽 172 MB/s：反推 SM 段拷贝量 ≈ 228 KB（sm_copy_bytes = sm_bw × sm_time / 1000 ≈ 172×1.36M/1000 ≈ 233 KB），在 1.36 ms 内完成——这个值仍是小拷贝（228
  KB）的延迟主导速率，不代表峰值 DMA 吞吐；但已与 51 MB/s 拉开 3.4 倍差距，定量印证了「分配拖慢有效带宽」。

至此 orch / H2D（graph+sm）耗时、alloc/copy 字节量、bw/sm_bw 带宽已全部在一次 LOG_TIMING 行里输出。

需要我把这一整套（H2D 字节量 + 带宽）同步进 docs/dfx/qwen3-14b-decode-hbg-perf.md，或进一步把 graph 段的 device_malloc 与 copy_to_device 拆开计时来直接量化分配耗时吗？

Profiling Data (Optional)

No response

Additional Context

No response