SHMEM 算子时间打点与指标计算标准e2e/kernel 双指标、带宽利用率与 Device 打点全解析【免费下载链接】shmemCANN SHMEM 是面向昇腾平台的多机多卡内存通信库基于OpenSHMEM 标准协议实现跨设备的高效内存访问与数据同步。项目地址: https://gitcode.com/cann/shmem导读本文是 CANN SHMEM基于 OpenSHMEM 标准的多机多卡内存通信库算子性能评估的唯一时间打点与指标计算标准用于指导 all-to-all、reduce-scatter、dispatch、combine 等 SHMEM 算子在昇腾平台上的性能采集、HCCL baseline 对比与瓶颈分析。读完本文你将掌握SHMEM 与 HCCL 执行模型的本质差异对称内存与数据放置方式、e2e_latency_us/kernel_latency_us双指标方案及其打点位置、logical_payload_bytes/algo_bandwidth/bus_bandwidth/bandwidth_utilization的完整计算公式与 bus_factor 参照表、[PERF]输出格式与达标判断规则以及基于SHMEMI_PROF_START/ENDaclshmemx_get_prof的 Device 侧分帧打点方法。标准原文位于 .agents/skills/shmem-ops-performance-eval/references/timing-and-metrics-standard.md并与其所属的 .agents/skills/shmem-ops-performance-eval/SKILL.md性能采集/评估 skill配套使用。1. SHMEM 与 HCCL 的执行模型1.1 HCCL 执行模型黑盒 APIHCCL 集合通信对用户是黑盒用户只提供 input/output 的 Device buffer内部的所有 staging、路由、通信和规约对用户不可见最终结果写回 Device GM。用户数据在 Device GM │ ▼ ┌─────────────────┐ │ HcclCollective │ ← 用户调用点 │ (内部完成全部 │ │ staging/路由/ │ ← 所有内部开销对用户不可见 │ 通信/规约) │ └────────┬────────┘ │ ▼ 结果在 Device GM因此 HCCL 的时间打点只需覆盖 API 调用本身H2D 拷贝不计时H2D copy (不计时) → [startEvent] → HcclCollective × iters → [endEvent]1.2 SHMEM 执行模型对称内存与数据放置方式SHMEM 模型下远端 PE 能访问的只有本 PE 的对称内存由aclshmem_malloc分配。用户的input通常位于普通 Device GMaclrtMalloc分配必须先搬到对称内存后才能被远端 PE 读取。具体搬运方式取决于通信引擎对地址类型的支持引擎put_nbi src 能否是用户 GMget_nbi dst 能否是用户 GM放置方式MTE能能做法 Akernel 内直接用put_nbi(symm, user_gm, ...)搬运SDMA能能同上UDMA能能同上RDMA不能不能做法 BHost 侧aclrtMemcpy(user_gm → symm)再进 kernel做法 Akernel 内放置— MTE / SDMA / UDMAinput(GM) ──[kernel launch]──▶ kernel 内 put_nbi(GM→对称) ──▶ 远端 get/计算 ──▶ output(GM)所有数据搬运都在 kernel 内部完成因此e2e_us的起点就是 kernel launch做法 A 下e2e_us ≈ kernel_us是正常的——数据搬运在 kernel 内被自然覆盖这不是问题。代码中MUST在注释中说明引擎选择例如// MTE put_nbi srclocal GM, no Host-side memcpy needed。做法 Bkernel 外放置— RDMAinput(GM) ──[aclrtMemcpy D2D: GM→对称内存]──▶ 对称内存 │ [barrier] │ ──[kernel launch]──▶ kernel 内通信/计算 ──▶ output(GM)此时e2e_us起点为aclrtMemcpy之前kernel 外的搬运MUST计入 e2e 循环因此e2e_usMUSTkernel_us差值即 kernel 外的搬运时间。约束MUST/SHOULDMTE/SDMA/UDMA 下SHOULD选用做法 A——直接在 kernel 内搬运避免无意义的 kernel 外循环RDMA 下MUST选用做法 B——双方数据都必须在对称内存上设计 DSLschedule中MUST标注使用的引擎和对应的放置方式A 或 B禁止为制造e2e_us kernel_us的假象而在做法 A 路径上增加无意义的 kernel 外搬运。1.3 公平对比原则HCCL API 调用时间已包含内部 staging 操作SHMEM 的 e2e 计时则覆盖从用户 input(GM) 到结果 output(GM) 的全部搬运。要实现公平对比两侧计时边界MUST对齐边界HCCLSHMEM计时起点数据在 Device GM数据在 Device GM用户 input 尚未被任何搬运操作触碰计时终点结果在 Device GM结果在 Device GM2. 双指标方案每个 SHMEM 算子MUST报告两个延迟指标指标含义起点终点用途e2e_latency_us端到端延迟——覆盖从用户 input(GM) 到结果 output(GM) 的全部数据搬运做法 Akernel 内放置kernel launch 前做法 Bkernel 外放置aclrtMemcpy 前stream sync 后与 HCCL baseline 公平对比kernel_latency_uskernel 执行时间kernel launch 前stream sync 后内部优化定位与 HCCL 对比时使用e2e_latency_us内部优化分析时使用kernel_latency_us做法 AMTE/SDMA/UDMA下e2e_us ≈ kernel_us是正常的——数据搬运在 kernel 内部完成无需额外 staging 步骤做法 BRDMA 或显式 Host 侧搬运下e2e_usMUST kernel_us——差值即 kernel 外的搬运时间。仓库中可看到与此对应的 Host 侧实现模式例如 examples/shmem_mega_moe/main.cpp 使用std::chrono::steady_clock包裹整个 e2e 循环并统计e2e_avg_ms / e2e_min_ms / e2e_max_ms / e2e_samples体现了端到端计时 多轮采样的通用结构。3. 各算子 phase 分解与时间打点以下示例使用做法 BHost 侧aclrtMemcpy把用户 GM 搬到对称内存。若使用 MTE/SDMA/UDMA数据放置可在 kernel 内部完成做法 A无需 Phase 1 的 Host 侧搬运——perf 循环直接 kernel launch 即可e2e_us和kernel_us共享同一个循环。3.1 all-to-alltransportfp16— 做法 B 示例Phase 1 [staging] aclrtMemcpyAsync(stagingSym, inputDev, D2D, stream) Phase 2 [barrier] aclshmem_barrier_all() Phase 3 [kernel] LaunchAlltoallHalf(...) Phase 4 [sync] aclrtSynchronizeStream e2e_latency Phase 1 Phase 2 Phase 3 Phase 4 kernel_latency Phase 3 Phase 4推荐 perf 循环结构// e2e timing — 每轮包含 staging barrier kernel aclrtRecordEvent(e2eStart, stream); for (int i 0; i iters; i) { aclrtMemcpyAsync(stagingSym, totalBytes, inputDev, totalBytes, ACL_MEMCPY_DEVICE_TO_DEVICE, stream); aclshmem_barrier_all(); LaunchAlltoallHalf(blockDim, stream, ...); } aclrtRecordEvent(e2eEnd, stream); // kernel-only timing — staging 已在 e2e 阶段完成 aclshmem_barrier_all(); aclrtRecordEvent(kernelStart, stream); for (int i 0; i iters; i) { LaunchAlltoallHalf(blockDim, stream, ...); } aclrtRecordEvent(kernelEnd, stream);e2e 循环中每轮重新 staging barrier 是为了模拟真实调用模式。staging 与 kernel 的 overlap 属于后续优化方向。3.2 reduce-scattercollective reducefloat32Phase 1 [staging] aclrtMemcpyAsync(stagingSym, inputDev, D2D, stream) Phase 2 [barrier] aclshmem_barrier_all() Phase 3 [kernel] LaunchReduceScatterFloat(...) Phase 4 [sync] aclrtSynchronizeStream e2e_latency Phase 1 Phase 2 Phase 3 Phase 4 kernel_latency Phase 3 Phase 43.3 dispatch-combinetransportfp16 payload int32 routedispatch/combine 的 staging 包含多个 bufferpayload、路由目标、路由槽位Phase 1a [staging payload] aclrtMemcpyAsync(payloadSym, inputDev, D2D, stream) Phase 1b [staging route_dst] aclrtMemcpyAsync(routeDstSym, routeDstDev, D2D, stream) Phase 1c [staging route_slot] aclrtMemcpyAsync(routeSlotSym, routeSlotDev, D2D, stream) Phase 2 [barrier] aclshmem_barrier_all() Phase 3a [route prefetch] LaunchDispatchRoutePrefetch(...) 仅 dispatch Phase 3b [kernel] LaunchDispatchHalf / LaunchCombineHalf Phase 4 [sync] aclrtSynchronizeStream e2e_latency Phase 1a 1b 1c Phase 2 Phase 3a 3b Phase 4 kernel_latency Phase 3a 3b Phase 4仓库中的 examples/dispatch/dispatch_classic/dispatch_kernel.cpp 与 examples/combine/combine_classic/combine_kernel.cpp 正是按comm_frame_id与full_frame_id两档对通信与整帧做分段打点的参考实现。3.4 HCCL baselinePhase 1 [H2D] aclrtMemcpy(inputDev, hostInput, H2D) ← 不计时 Phase 2 [collective] HcclCollective(inputDev, outputDev) ← 计时 Phase 3 [sync] aclrtSynchronizeStream ← 计时 hccl_latency Phase 2 Phase 3对比时e2e_latency_us对标hccl_latency。4. 指标计算4.1 logical_payload_bytes统一按单 PE 语义数据量计算MUST在输出中标注口径。算子logical_payload_bytes口径all-to-alln_pes × shard_elems × sizeof(dtype)单 PE 输入 单 PE 输出reduce-scattern_pes × shard_elems × sizeof(dtype)单 PE 输入全量dispatchlocal_tokens × hidden × sizeof(half)单 PE 发送量combinelocal_tokens × hidden × sizeof(half)单 PE 拉回量4.2 algo_bandwidthalgo_bandwidth_GBps logical_payload_bytes / latency_s / 1e9与 Baseline带宽达标、Round 间对比使用kernel_bus_bandwidth_GBpsNEVER用 e2e 带宽作达标主指标与 Baseline时延参考使用e2e_latency_us内部分析使用kernel_latency_us推算 kernel 口径 algo/bus 带宽报告中标注使用的是哪个 latency不乘 2统一按 input size 计算遵循 NCCLalgBw惯例。4.3 bus_factor 和 bus_bandwidth本表是 bus_factor 的唯一参照源。code-gen、code-review、perf-eval 等 skill 中的 bus_factor 取值MUST以本表为准禁止在其他文件中重复定义或使用 deviating 值。kernel_bus_bandwidth_GBps algo_bandwidth_GBps(kernel) × bus_factor算子bus_factor推导AllReduce2 * (n_pes - 1) / n_pesReduceScatter AllGather 两阶段每阶段(n-1)/nReduceScatter(n_pes - 1) / n_pes每步搬运 1/n 数据共 (n-1) 步AllGather(n_pes - 1) / n_pes每步搬运 1/n 数据共 (n-1) 步AllToAll / Shuffle(n_pes - 1) / n_pes每个 PE 发送 (n-1)/n 的数据到远端Broadcast1单源广播发送方 bandwidth 不放大P2P1点对点无集合通信放大因子dispatch(n_pes - 1) / n_pes近似均匀路由假设路由不均匀时按实际远端搬运量推导combine(n_pes - 1) / n_pes近似同 dispatchdispatch-combine 的 bus_factor 取决于路由分布。路由不均匀时按实际远端搬运 bytes / logical_payload_bytes计算并在报告中说明。4.4 bandwidth_utilizationbandwidth_utilization_percent kernel_bus_bandwidth_GBps / peak_bandwidth_GBps × 100peak_bandwidth_GBpsMUST记录来源SoC、链路类型、PE 数、拓扑。按以下决策表取值参考 .agents/skills/shmem-ops-design/references/hardware-architecture.md通信模式peak_bandwidth_GBps适用算子P2P单条 HCCS 链路单向28 GB/sP2P put/get、非对称点对点搬运集合通信8PE full-mesh 聚合196 GB/s 7 × 28AllReduce、ReduceScatter、AllGather、AllToAll 等对称集合通信dispatch / combine稀疏路由28 GB/sP2P 口径远端搬运量不确定dispatch、combine 等路由不确定算子通算融合通信计算按通信阶段选 P2P 或集合通信值fused_compute_comm 算子的通信阶段utilization 100% 时在报告中注释可能原因bus_factor 高估、链路实际带宽超出标称值。上述 28 GB/s / 196 GB/s 的硬件口径与硬件架构文档 .agents/skills/shmem-ops-design/references/hardware-architecture.md 中记录的 HCCS P2P 单链路带宽单向~28 GB/s、910C 不同卡上 DIE 之间 196 GB/s 一致取值时需注意 SoC 与拓扑差异910B/910C 的单链路标称值与 full-mesh 聚合值不同。5. 性能输出格式5.1 SHMEM main.cpp --perf 输出[PERF] peid e2e_usval kernel_usval algo_bandwidth_GBpsval e2e_bus_bandwidth_GBpsval kernel_bus_bandwidth_GBpsval bandwidth_utilization_pctval payload_bytesval bus_factorval peak_bandwidth_GBpsval注意bus_factor在 PERF 行中输出以供调试和公式验证但不作为性能结果表的主列输出详见 .agents/skills/shmem-ops-performance-eval/SKILL.md 和 §4.3。字段说明e2e_us做法 A≈kernel_us数据搬运在 kernel 内完成做法 B含 aclrtMemcpy barrier kernelkernel_us仅 kernelalgo_bandwidth_GBpslogical_payload_bytes / e2e_us / 1e9e2e 口径算法带宽e2e_bus_bandwidth_GBpsalgo_bandwidth_GBps × bus_factore2e 口径总线带宽仅作参考kernel_bus_bandwidth_GBpslogical_payload_bytes / kernel_us / 1e9 × bus_factor达标对比 MUST 用此字段bandwidth_utilization_pctkernel_bus_bandwidth_GBps / peak_bandwidth_GBps × 100payload_bytes单 PE 语义数据量bus_factor数值及来源peak_bandwidth_GBps硬件峰值带宽按 SoC/拓扑取值5.2 HCCL baseline 输出[BASELINE_PERF] peid e2e_usval kernel_usval algo_bandwidth_GBpsval e2e_bus_bandwidth_GBpsval kernel_bus_bandwidth_GBpsval payload_bytesval bus_factorval apiHcclAlltoAllV|...5.3 性能报告对比表对比表格式和字段定义见 .agents/skills/shmem-ops-performance-eval/SKILL.md 的性能对比表、.agents/skills/shmem-ops-performance-eval/references/perf-chat-output-spec.md 和 .agents/skills/shmem-ops-performance-eval/templates/performance-report.md 模板。此处仅列出核心结构列名带宽达标metric | SHMEM kernel_bus_bandwidth_GBps | Baseline kernel_bus_bandwidth_GBps | delta | 达标时延参考列可并列e2e_us、kernel_us、e2e_bus_bandwidth_GBpsBaseline列适用 hccl / aclnn / stitched不限 HCCL达标判断 MUST 使用kernel_bus_bandwidth_GBps与 baseline 对比有 baseline 时默认 ≥ baseline80%无 baseline 时通信算子带宽利用率 ≥ 20%e2e_us/e2e_bus_bandwidth_GBps仅作参考NEVER作为 Round 对比或达标主指标kernel_us列用于内部优化分析。6. 计算示例6.1 all-to-allfp168 PEshard_elems 8388608logical_payload_bytes 8 × 8388608 × 2 134,217,728 (128 MiB per PE) bus_factor (8 - 1) / 8 0.875 # 假设测量值 e2e_us 1200.0 kernel_us 1050.0 algo_GBps (e2e) 134217728 / (1200.0 × 1e-6) / 1e9 111.85 algo_GBps (kernel) 134217728 / (1050.0 × 1e-6) / 1e9 127.83 bus_GBps (e2e) 111.85 × 0.875 97.87 bus_GBps (kernel) 127.83 × 0.875 111.85 # HCCL baseline: hccl_us 1100.0 algo_GBps (hccl) 134217728 / (1100.0 × 1e-6) / 1e9 122.02 bus_GBps (hccl) 122.02 × 0.875 106.77 # 达标判断 (kernel_bus_bandwidth_GBps vs hccl baseline) bus_GBps (kernel, SHMEM) 127.83 × 0.875 111.85 bus_GBps (hccl) 106.77 ratio: 111.85 / 106.77 104.8% 80% - PASS # e2e 带宽仅参考不作达标主指标 # bus_GBps (e2e): 97.87 / 106.77 91.7% ← 不可单独用于 PASS/FAIL6.2 reduce-scatterfloat328 PEshard_elems 8388608logical_payload_bytes 8 × 8388608 × 4 268,435,456 (256 MiB per PE input) bus_factor (8 - 1) / 8 0.875 algo_GBps logical_payload_bytes / latency_s / 1e9 bus_GBps algo_GBps × 0.8756.3 dispatchfp168 PElocal_tokens1024hidden4096logical_payload_bytes 1024 × 4096 × 2 8,388,608 (8 MiB per PE) bus_factor ≈ (8 - 1) / 8 0.875 (均匀路由假设) algo_GBps logical_payload_bytes / latency_s / 1e9 bus_GBps algo_GBps × bus_factor6.4 combinefp168 PElocal_tokens1024hidden4096logical_payload_bytes 1024 × 4096 × 2 8,388,608 (8 MiB per PE) bus_factor ≈ 0.875 (同 dispatch)7. Device 侧关键片段打点完整操作指南.agents/skills/shmem-ops-performance-eval/references/device-profiling-guide.md —— 涵盖宏实现原理、kernel 侧打点规范、Host 侧aclshmemx_get_prof操作、数据结构、cycle2us 换算、从 broadcast/mte_perftest 等 benchmark 提取的完整工作示例。性能采集MUST同时覆盖端到端指标和关键 Device 片段指标。优化判断NEVER只依赖总耗时MUST能回答时间主要花在 copy、remote put/get、signal/wait、barrier、local compute 还是 finalize。参考 SHMEM examples 的 profiling 模式在 kernel 中按 phase 插入SHMEMI_PROF_START(frame_id)/SHMEMI_PROF_END(frame_id)Host 侧在 stream 同步后调用aclshmemx_get_prof(nullptr, true)导出每个 PE、block、frame 的 cycles、count 和平均耗时。宏的实现位于 src/device/utils/prof/shmemi_prof.hSHMEMI_PROF_START在入口通过AscendC::GetSystemCycle()读取系统 cycle 并对block_prof[block_idx].cycles[frame_id]做减法累加起点SHMEMI_PROF_END在出口做加法并递增ccount[frame_id]二者均通过aclshmemi_get_state()获取 Device 侧 profs 状态、按 PE 过滤并对pipe_barrier(PIPE_ALL)保证跨 pipe 的时序一致性。Host 侧对应的导出接口aclshmemx_get_prof/aclshmemx_show_prof实现于 src/host/init/shmem_init.cpp底层调用prof_data_print输出每个 PE/block/frame 的统计。基本要求kernel 包含 src/device/utils/prof/shmemi_prof.h每个关键执行片段分配稳定的frame_id并在 README 或性能报告中给出 frame mapframe map 至少覆盖当前算子的主要耗时来源copy_in/copy_outGM、UB、symmetric buffer 搬运remote_put_getMTE/SDMA/RDMA put/get 或 collective transportsignal_or_barrier_waitsignal wait、barrier、quiet、handle waitlocal_computematmul、reduce、layout transform、packing/unpacking 等计算finalize写回、metadata、tail/final reduce 等收尾采集结果MUST记录每个 frame 的cycles、count、avg_us、max_core_us、占端到端时间比例以及长尾 block/PE优化优先从占比最大的 frame 或长尾最明显的 frame 入手profiling 编译开关、环境变量和日志路径MUST可复现默认性能路径NEVER永久打开 printf、DumpTensor 或重型 debug 日志。示例打点形态kernel 侧#include utils/prof/shmemi_prof.h constexpr int32_t kProfRemotePut 0; constexpr int32_t kProfSignalWait 1; constexpr int32_t kProfLocalCompute 2; SHMEMI_PROF_START(kProfRemotePut); aclshmemx_mte_put_nbi(dst, src, ub, bytes, elems, peer, EVENT_ID0); SHMEMI_PROF_END(kProfRemotePut); SHMEMI_PROF_START(kProfSignalWait); aclshmem_signal_wait_until(signal, ACLSHMEM_CMP_EQ, expected); SHMEMI_PROF_END(kProfSignalWait);Host 侧形态参考ACL_CHECK(aclrtSynchronizeStream(stream)); aclshmemx_get_prof(nullptr, true);仓库中的实际用法可对照kernel 侧打点见 examples/aclgraph_demo/aclgraph_demo_kernel.cpp、examples/allgather/allgather_kernel.cpp、examples/shmem_perftest/mte_perftest/mte_perftest_kernel.cppHost 侧导出见 examples/aclgraph_demo/main.cpp、examples/shmem_perftest/mte_perftest/main.cpp、examples/hccs_sio_link/main.cpp同一采集点同时以nullptr与out_profs两种方式调用分别用于打印与后续离线统计。8. 计算指标通信算子中计算阶段的算力使用率如适用MAY计算有效算力和算力使用率并与硬件峰值对比。纯搬运算子标注 N/A。公式compute_latency_s compute_frame_us / 1e6 effective_flops op_count_flops / compute_latency_s compute_utilization_percent effective_flops / peak_flops_for_dtype_and_soc * 100字段定义op_count_flops按算子语义统计的有效 FLOPsMUST给出公式。例如 GEMM 通常为2 * M * N * Kcompute_frame_us优先来自 Device profiling 的 compute frame没有分段打点时可用端到端时间但MUST标注该值包含通信/等待开销peak_flops_for_dtype_and_soc硬件峰值算力MUST记录 SoC、dtype、数据格式、是否使用 cube/vector 单元以及来源参考 .agents/skills/shmem-ops-design/references/hardware-architecture.md 的核数与算力表如 910B2 FP16 ~376 TFLOPS、910C ~800 TFLOPS 等输出通信阶段时间占比NEVER只给整体时间。9. 采集方法选择按场景选择场景推荐方法API/example 级通信example 内部 repeats SHMEM cycle profilingkernel 内片段定位SHMEMI_PROF_START/ENDaclshmemx_get_prof算子级端到端msprof 或 torch_npu profilerPython/PyTorch 集成torch_npu profiler 输出文件 correctness check跨机/RDMA同时记录 control barrier、handle wait、网络路径和 PE 拓扑采集MUST记录命令、workdir、环境变量、case、重复次数和日志路径。总结与落地指引这套时间打点与指标计算标准贯穿 SHMEM 算子性能评估的全流程先按引擎选择数据放置方式做法 A/B并对齐与 HCCL 的计时边界再以e2e_latency_us对时延、kernel_bus_bandwidth_GBps对带宽达标配合 bus_factor 参照表与 peak_bandwidth 决策表计算带宽利用率最后用SHMEMI_PROF_START/ENDaclshmemx_get_prof定位 kernel 内瓶颈 frame。落地时可进一步参阅采集流程与结果表格式.agents/skills/shmem-ops-performance-eval/references/performance-eval-guide.mdbaseline 选择与对比工作流.agents/skills/shmem-ops-performance-eval/references/baseline-selection.md、.agents/skills/shmem-ops-performance-eval/references/baseline-compare-workflow.md三阶段采集命令与离线对比.agents/skills/shmem-ops-performance-eval/references/perf-workflow.mdDevice 打点完整指南.agents/skills/shmem-ops-performance-eval/references/device-profiling-guide.md性能报告模板.agents/skills/shmem-ops-performance-eval/templates/performance-report.md【免费下载链接】shmemCANN SHMEM 是面向昇腾平台的多机多卡内存通信库基于OpenSHMEM 标准协议实现跨设备的高效内存访问与数据同步。项目地址: https://gitcode.com/cann/shmem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SHMEM 算子时间打点与指标计算标准：e2e/kernel 双指标、带宽利用率与 Device 打点全解析
SHMEM 算子时间打点与指标计算标准e2e/kernel 双指标、带宽利用率与 Device 打点全解析【免费下载链接】shmemCANN SHMEM 是面向昇腾平台的多机多卡内存通信库基于OpenSHMEM 标准协议实现跨设备的高效内存访问与数据同步。项目地址: https://gitcode.com/cann/shmem导读本文是 CANN SHMEM基于 OpenSHMEM 标准的多机多卡内存通信库算子性能评估的唯一时间打点与指标计算标准用于指导 all-to-all、reduce-scatter、dispatch、combine 等 SHMEM 算子在昇腾平台上的性能采集、HCCL baseline 对比与瓶颈分析。读完本文你将掌握SHMEM 与 HCCL 执行模型的本质差异对称内存与数据放置方式、e2e_latency_us/kernel_latency_us双指标方案及其打点位置、logical_payload_bytes/algo_bandwidth/bus_bandwidth/bandwidth_utilization的完整计算公式与 bus_factor 参照表、[PERF]输出格式与达标判断规则以及基于SHMEMI_PROF_START/ENDaclshmemx_get_prof的 Device 侧分帧打点方法。标准原文位于 .agents/skills/shmem-ops-performance-eval/references/timing-and-metrics-standard.md并与其所属的 .agents/skills/shmem-ops-performance-eval/SKILL.md性能采集/评估 skill配套使用。1. SHMEM 与 HCCL 的执行模型1.1 HCCL 执行模型黑盒 APIHCCL 集合通信对用户是黑盒用户只提供 input/output 的 Device buffer内部的所有 staging、路由、通信和规约对用户不可见最终结果写回 Device GM。用户数据在 Device GM │ ▼ ┌─────────────────┐ │ HcclCollective │ ← 用户调用点 │ (内部完成全部 │ │ staging/路由/ │ ← 所有内部开销对用户不可见 │ 通信/规约) │ └────────┬────────┘ │ ▼ 结果在 Device GM因此 HCCL 的时间打点只需覆盖 API 调用本身H2D 拷贝不计时H2D copy (不计时) → [startEvent] → HcclCollective × iters → [endEvent]1.2 SHMEM 执行模型对称内存与数据放置方式SHMEM 模型下远端 PE 能访问的只有本 PE 的对称内存由aclshmem_malloc分配。用户的input通常位于普通 Device GMaclrtMalloc分配必须先搬到对称内存后才能被远端 PE 读取。具体搬运方式取决于通信引擎对地址类型的支持引擎put_nbi src 能否是用户 GMget_nbi dst 能否是用户 GM放置方式MTE能能做法 Akernel 内直接用put_nbi(symm, user_gm, ...)搬运SDMA能能同上UDMA能能同上RDMA不能不能做法 BHost 侧aclrtMemcpy(user_gm → symm)再进 kernel做法 Akernel 内放置— MTE / SDMA / UDMAinput(GM) ──[kernel launch]──▶ kernel 内 put_nbi(GM→对称) ──▶ 远端 get/计算 ──▶ output(GM)所有数据搬运都在 kernel 内部完成因此e2e_us的起点就是 kernel launch做法 A 下e2e_us ≈ kernel_us是正常的——数据搬运在 kernel 内被自然覆盖这不是问题。代码中MUST在注释中说明引擎选择例如// MTE put_nbi srclocal GM, no Host-side memcpy needed。做法 Bkernel 外放置— RDMAinput(GM) ──[aclrtMemcpy D2D: GM→对称内存]──▶ 对称内存 │ [barrier] │ ──[kernel launch]──▶ kernel 内通信/计算 ──▶ output(GM)此时e2e_us起点为aclrtMemcpy之前kernel 外的搬运MUST计入 e2e 循环因此e2e_usMUSTkernel_us差值即 kernel 外的搬运时间。约束MUST/SHOULDMTE/SDMA/UDMA 下SHOULD选用做法 A——直接在 kernel 内搬运避免无意义的 kernel 外循环RDMA 下MUST选用做法 B——双方数据都必须在对称内存上设计 DSLschedule中MUST标注使用的引擎和对应的放置方式A 或 B禁止为制造e2e_us kernel_us的假象而在做法 A 路径上增加无意义的 kernel 外搬运。1.3 公平对比原则HCCL API 调用时间已包含内部 staging 操作SHMEM 的 e2e 计时则覆盖从用户 input(GM) 到结果 output(GM) 的全部搬运。要实现公平对比两侧计时边界MUST对齐边界HCCLSHMEM计时起点数据在 Device GM数据在 Device GM用户 input 尚未被任何搬运操作触碰计时终点结果在 Device GM结果在 Device GM2. 双指标方案每个 SHMEM 算子MUST报告两个延迟指标指标含义起点终点用途e2e_latency_us端到端延迟——覆盖从用户 input(GM) 到结果 output(GM) 的全部数据搬运做法 Akernel 内放置kernel launch 前做法 Bkernel 外放置aclrtMemcpy 前stream sync 后与 HCCL baseline 公平对比kernel_latency_uskernel 执行时间kernel launch 前stream sync 后内部优化定位与 HCCL 对比时使用e2e_latency_us内部优化分析时使用kernel_latency_us做法 AMTE/SDMA/UDMA下e2e_us ≈ kernel_us是正常的——数据搬运在 kernel 内部完成无需额外 staging 步骤做法 BRDMA 或显式 Host 侧搬运下e2e_usMUST kernel_us——差值即 kernel 外的搬运时间。仓库中可看到与此对应的 Host 侧实现模式例如 examples/shmem_mega_moe/main.cpp 使用std::chrono::steady_clock包裹整个 e2e 循环并统计e2e_avg_ms / e2e_min_ms / e2e_max_ms / e2e_samples体现了端到端计时 多轮采样的通用结构。3. 各算子 phase 分解与时间打点以下示例使用做法 BHost 侧aclrtMemcpy把用户 GM 搬到对称内存。若使用 MTE/SDMA/UDMA数据放置可在 kernel 内部完成做法 A无需 Phase 1 的 Host 侧搬运——perf 循环直接 kernel launch 即可e2e_us和kernel_us共享同一个循环。3.1 all-to-alltransportfp16— 做法 B 示例Phase 1 [staging] aclrtMemcpyAsync(stagingSym, inputDev, D2D, stream) Phase 2 [barrier] aclshmem_barrier_all() Phase 3 [kernel] LaunchAlltoallHalf(...) Phase 4 [sync] aclrtSynchronizeStream e2e_latency Phase 1 Phase 2 Phase 3 Phase 4 kernel_latency Phase 3 Phase 4推荐 perf 循环结构// e2e timing — 每轮包含 staging barrier kernel aclrtRecordEvent(e2eStart, stream); for (int i 0; i iters; i) { aclrtMemcpyAsync(stagingSym, totalBytes, inputDev, totalBytes, ACL_MEMCPY_DEVICE_TO_DEVICE, stream); aclshmem_barrier_all(); LaunchAlltoallHalf(blockDim, stream, ...); } aclrtRecordEvent(e2eEnd, stream); // kernel-only timing — staging 已在 e2e 阶段完成 aclshmem_barrier_all(); aclrtRecordEvent(kernelStart, stream); for (int i 0; i iters; i) { LaunchAlltoallHalf(blockDim, stream, ...); } aclrtRecordEvent(kernelEnd, stream);e2e 循环中每轮重新 staging barrier 是为了模拟真实调用模式。staging 与 kernel 的 overlap 属于后续优化方向。3.2 reduce-scattercollective reducefloat32Phase 1 [staging] aclrtMemcpyAsync(stagingSym, inputDev, D2D, stream) Phase 2 [barrier] aclshmem_barrier_all() Phase 3 [kernel] LaunchReduceScatterFloat(...) Phase 4 [sync] aclrtSynchronizeStream e2e_latency Phase 1 Phase 2 Phase 3 Phase 4 kernel_latency Phase 3 Phase 43.3 dispatch-combinetransportfp16 payload int32 routedispatch/combine 的 staging 包含多个 bufferpayload、路由目标、路由槽位Phase 1a [staging payload] aclrtMemcpyAsync(payloadSym, inputDev, D2D, stream) Phase 1b [staging route_dst] aclrtMemcpyAsync(routeDstSym, routeDstDev, D2D, stream) Phase 1c [staging route_slot] aclrtMemcpyAsync(routeSlotSym, routeSlotDev, D2D, stream) Phase 2 [barrier] aclshmem_barrier_all() Phase 3a [route prefetch] LaunchDispatchRoutePrefetch(...) 仅 dispatch Phase 3b [kernel] LaunchDispatchHalf / LaunchCombineHalf Phase 4 [sync] aclrtSynchronizeStream e2e_latency Phase 1a 1b 1c Phase 2 Phase 3a 3b Phase 4 kernel_latency Phase 3a 3b Phase 4仓库中的 examples/dispatch/dispatch_classic/dispatch_kernel.cpp 与 examples/combine/combine_classic/combine_kernel.cpp 正是按comm_frame_id与full_frame_id两档对通信与整帧做分段打点的参考实现。3.4 HCCL baselinePhase 1 [H2D] aclrtMemcpy(inputDev, hostInput, H2D) ← 不计时 Phase 2 [collective] HcclCollective(inputDev, outputDev) ← 计时 Phase 3 [sync] aclrtSynchronizeStream ← 计时 hccl_latency Phase 2 Phase 3对比时e2e_latency_us对标hccl_latency。4. 指标计算4.1 logical_payload_bytes统一按单 PE 语义数据量计算MUST在输出中标注口径。算子logical_payload_bytes口径all-to-alln_pes × shard_elems × sizeof(dtype)单 PE 输入 单 PE 输出reduce-scattern_pes × shard_elems × sizeof(dtype)单 PE 输入全量dispatchlocal_tokens × hidden × sizeof(half)单 PE 发送量combinelocal_tokens × hidden × sizeof(half)单 PE 拉回量4.2 algo_bandwidthalgo_bandwidth_GBps logical_payload_bytes / latency_s / 1e9与 Baseline带宽达标、Round 间对比使用kernel_bus_bandwidth_GBpsNEVER用 e2e 带宽作达标主指标与 Baseline时延参考使用e2e_latency_us内部分析使用kernel_latency_us推算 kernel 口径 algo/bus 带宽报告中标注使用的是哪个 latency不乘 2统一按 input size 计算遵循 NCCLalgBw惯例。4.3 bus_factor 和 bus_bandwidth本表是 bus_factor 的唯一参照源。code-gen、code-review、perf-eval 等 skill 中的 bus_factor 取值MUST以本表为准禁止在其他文件中重复定义或使用 deviating 值。kernel_bus_bandwidth_GBps algo_bandwidth_GBps(kernel) × bus_factor算子bus_factor推导AllReduce2 * (n_pes - 1) / n_pesReduceScatter AllGather 两阶段每阶段(n-1)/nReduceScatter(n_pes - 1) / n_pes每步搬运 1/n 数据共 (n-1) 步AllGather(n_pes - 1) / n_pes每步搬运 1/n 数据共 (n-1) 步AllToAll / Shuffle(n_pes - 1) / n_pes每个 PE 发送 (n-1)/n 的数据到远端Broadcast1单源广播发送方 bandwidth 不放大P2P1点对点无集合通信放大因子dispatch(n_pes - 1) / n_pes近似均匀路由假设路由不均匀时按实际远端搬运量推导combine(n_pes - 1) / n_pes近似同 dispatchdispatch-combine 的 bus_factor 取决于路由分布。路由不均匀时按实际远端搬运 bytes / logical_payload_bytes计算并在报告中说明。4.4 bandwidth_utilizationbandwidth_utilization_percent kernel_bus_bandwidth_GBps / peak_bandwidth_GBps × 100peak_bandwidth_GBpsMUST记录来源SoC、链路类型、PE 数、拓扑。按以下决策表取值参考 .agents/skills/shmem-ops-design/references/hardware-architecture.md通信模式peak_bandwidth_GBps适用算子P2P单条 HCCS 链路单向28 GB/sP2P put/get、非对称点对点搬运集合通信8PE full-mesh 聚合196 GB/s 7 × 28AllReduce、ReduceScatter、AllGather、AllToAll 等对称集合通信dispatch / combine稀疏路由28 GB/sP2P 口径远端搬运量不确定dispatch、combine 等路由不确定算子通算融合通信计算按通信阶段选 P2P 或集合通信值fused_compute_comm 算子的通信阶段utilization 100% 时在报告中注释可能原因bus_factor 高估、链路实际带宽超出标称值。上述 28 GB/s / 196 GB/s 的硬件口径与硬件架构文档 .agents/skills/shmem-ops-design/references/hardware-architecture.md 中记录的 HCCS P2P 单链路带宽单向~28 GB/s、910C 不同卡上 DIE 之间 196 GB/s 一致取值时需注意 SoC 与拓扑差异910B/910C 的单链路标称值与 full-mesh 聚合值不同。5. 性能输出格式5.1 SHMEM main.cpp --perf 输出[PERF] peid e2e_usval kernel_usval algo_bandwidth_GBpsval e2e_bus_bandwidth_GBpsval kernel_bus_bandwidth_GBpsval bandwidth_utilization_pctval payload_bytesval bus_factorval peak_bandwidth_GBpsval注意bus_factor在 PERF 行中输出以供调试和公式验证但不作为性能结果表的主列输出详见 .agents/skills/shmem-ops-performance-eval/SKILL.md 和 §4.3。字段说明e2e_us做法 A≈kernel_us数据搬运在 kernel 内完成做法 B含 aclrtMemcpy barrier kernelkernel_us仅 kernelalgo_bandwidth_GBpslogical_payload_bytes / e2e_us / 1e9e2e 口径算法带宽e2e_bus_bandwidth_GBpsalgo_bandwidth_GBps × bus_factore2e 口径总线带宽仅作参考kernel_bus_bandwidth_GBpslogical_payload_bytes / kernel_us / 1e9 × bus_factor达标对比 MUST 用此字段bandwidth_utilization_pctkernel_bus_bandwidth_GBps / peak_bandwidth_GBps × 100payload_bytes单 PE 语义数据量bus_factor数值及来源peak_bandwidth_GBps硬件峰值带宽按 SoC/拓扑取值5.2 HCCL baseline 输出[BASELINE_PERF] peid e2e_usval kernel_usval algo_bandwidth_GBpsval e2e_bus_bandwidth_GBpsval kernel_bus_bandwidth_GBpsval payload_bytesval bus_factorval apiHcclAlltoAllV|...5.3 性能报告对比表对比表格式和字段定义见 .agents/skills/shmem-ops-performance-eval/SKILL.md 的性能对比表、.agents/skills/shmem-ops-performance-eval/references/perf-chat-output-spec.md 和 .agents/skills/shmem-ops-performance-eval/templates/performance-report.md 模板。此处仅列出核心结构列名带宽达标metric | SHMEM kernel_bus_bandwidth_GBps | Baseline kernel_bus_bandwidth_GBps | delta | 达标时延参考列可并列e2e_us、kernel_us、e2e_bus_bandwidth_GBpsBaseline列适用 hccl / aclnn / stitched不限 HCCL达标判断 MUST 使用kernel_bus_bandwidth_GBps与 baseline 对比有 baseline 时默认 ≥ baseline80%无 baseline 时通信算子带宽利用率 ≥ 20%e2e_us/e2e_bus_bandwidth_GBps仅作参考NEVER作为 Round 对比或达标主指标kernel_us列用于内部优化分析。6. 计算示例6.1 all-to-allfp168 PEshard_elems 8388608logical_payload_bytes 8 × 8388608 × 2 134,217,728 (128 MiB per PE) bus_factor (8 - 1) / 8 0.875 # 假设测量值 e2e_us 1200.0 kernel_us 1050.0 algo_GBps (e2e) 134217728 / (1200.0 × 1e-6) / 1e9 111.85 algo_GBps (kernel) 134217728 / (1050.0 × 1e-6) / 1e9 127.83 bus_GBps (e2e) 111.85 × 0.875 97.87 bus_GBps (kernel) 127.83 × 0.875 111.85 # HCCL baseline: hccl_us 1100.0 algo_GBps (hccl) 134217728 / (1100.0 × 1e-6) / 1e9 122.02 bus_GBps (hccl) 122.02 × 0.875 106.77 # 达标判断 (kernel_bus_bandwidth_GBps vs hccl baseline) bus_GBps (kernel, SHMEM) 127.83 × 0.875 111.85 bus_GBps (hccl) 106.77 ratio: 111.85 / 106.77 104.8% 80% - PASS # e2e 带宽仅参考不作达标主指标 # bus_GBps (e2e): 97.87 / 106.77 91.7% ← 不可单独用于 PASS/FAIL6.2 reduce-scatterfloat328 PEshard_elems 8388608logical_payload_bytes 8 × 8388608 × 4 268,435,456 (256 MiB per PE input) bus_factor (8 - 1) / 8 0.875 algo_GBps logical_payload_bytes / latency_s / 1e9 bus_GBps algo_GBps × 0.8756.3 dispatchfp168 PElocal_tokens1024hidden4096logical_payload_bytes 1024 × 4096 × 2 8,388,608 (8 MiB per PE) bus_factor ≈ (8 - 1) / 8 0.875 (均匀路由假设) algo_GBps logical_payload_bytes / latency_s / 1e9 bus_GBps algo_GBps × bus_factor6.4 combinefp168 PElocal_tokens1024hidden4096logical_payload_bytes 1024 × 4096 × 2 8,388,608 (8 MiB per PE) bus_factor ≈ 0.875 (同 dispatch)7. Device 侧关键片段打点完整操作指南.agents/skills/shmem-ops-performance-eval/references/device-profiling-guide.md —— 涵盖宏实现原理、kernel 侧打点规范、Host 侧aclshmemx_get_prof操作、数据结构、cycle2us 换算、从 broadcast/mte_perftest 等 benchmark 提取的完整工作示例。性能采集MUST同时覆盖端到端指标和关键 Device 片段指标。优化判断NEVER只依赖总耗时MUST能回答时间主要花在 copy、remote put/get、signal/wait、barrier、local compute 还是 finalize。参考 SHMEM examples 的 profiling 模式在 kernel 中按 phase 插入SHMEMI_PROF_START(frame_id)/SHMEMI_PROF_END(frame_id)Host 侧在 stream 同步后调用aclshmemx_get_prof(nullptr, true)导出每个 PE、block、frame 的 cycles、count 和平均耗时。宏的实现位于 src/device/utils/prof/shmemi_prof.hSHMEMI_PROF_START在入口通过AscendC::GetSystemCycle()读取系统 cycle 并对block_prof[block_idx].cycles[frame_id]做减法累加起点SHMEMI_PROF_END在出口做加法并递增ccount[frame_id]二者均通过aclshmemi_get_state()获取 Device 侧 profs 状态、按 PE 过滤并对pipe_barrier(PIPE_ALL)保证跨 pipe 的时序一致性。Host 侧对应的导出接口aclshmemx_get_prof/aclshmemx_show_prof实现于 src/host/init/shmem_init.cpp底层调用prof_data_print输出每个 PE/block/frame 的统计。基本要求kernel 包含 src/device/utils/prof/shmemi_prof.h每个关键执行片段分配稳定的frame_id并在 README 或性能报告中给出 frame mapframe map 至少覆盖当前算子的主要耗时来源copy_in/copy_outGM、UB、symmetric buffer 搬运remote_put_getMTE/SDMA/RDMA put/get 或 collective transportsignal_or_barrier_waitsignal wait、barrier、quiet、handle waitlocal_computematmul、reduce、layout transform、packing/unpacking 等计算finalize写回、metadata、tail/final reduce 等收尾采集结果MUST记录每个 frame 的cycles、count、avg_us、max_core_us、占端到端时间比例以及长尾 block/PE优化优先从占比最大的 frame 或长尾最明显的 frame 入手profiling 编译开关、环境变量和日志路径MUST可复现默认性能路径NEVER永久打开 printf、DumpTensor 或重型 debug 日志。示例打点形态kernel 侧#include utils/prof/shmemi_prof.h constexpr int32_t kProfRemotePut 0; constexpr int32_t kProfSignalWait 1; constexpr int32_t kProfLocalCompute 2; SHMEMI_PROF_START(kProfRemotePut); aclshmemx_mte_put_nbi(dst, src, ub, bytes, elems, peer, EVENT_ID0); SHMEMI_PROF_END(kProfRemotePut); SHMEMI_PROF_START(kProfSignalWait); aclshmem_signal_wait_until(signal, ACLSHMEM_CMP_EQ, expected); SHMEMI_PROF_END(kProfSignalWait);Host 侧形态参考ACL_CHECK(aclrtSynchronizeStream(stream)); aclshmemx_get_prof(nullptr, true);仓库中的实际用法可对照kernel 侧打点见 examples/aclgraph_demo/aclgraph_demo_kernel.cpp、examples/allgather/allgather_kernel.cpp、examples/shmem_perftest/mte_perftest/mte_perftest_kernel.cppHost 侧导出见 examples/aclgraph_demo/main.cpp、examples/shmem_perftest/mte_perftest/main.cpp、examples/hccs_sio_link/main.cpp同一采集点同时以nullptr与out_profs两种方式调用分别用于打印与后续离线统计。8. 计算指标通信算子中计算阶段的算力使用率如适用MAY计算有效算力和算力使用率并与硬件峰值对比。纯搬运算子标注 N/A。公式compute_latency_s compute_frame_us / 1e6 effective_flops op_count_flops / compute_latency_s compute_utilization_percent effective_flops / peak_flops_for_dtype_and_soc * 100字段定义op_count_flops按算子语义统计的有效 FLOPsMUST给出公式。例如 GEMM 通常为2 * M * N * Kcompute_frame_us优先来自 Device profiling 的 compute frame没有分段打点时可用端到端时间但MUST标注该值包含通信/等待开销peak_flops_for_dtype_and_soc硬件峰值算力MUST记录 SoC、dtype、数据格式、是否使用 cube/vector 单元以及来源参考 .agents/skills/shmem-ops-design/references/hardware-architecture.md 的核数与算力表如 910B2 FP16 ~376 TFLOPS、910C ~800 TFLOPS 等输出通信阶段时间占比NEVER只给整体时间。9. 采集方法选择按场景选择场景推荐方法API/example 级通信example 内部 repeats SHMEM cycle profilingkernel 内片段定位SHMEMI_PROF_START/ENDaclshmemx_get_prof算子级端到端msprof 或 torch_npu profilerPython/PyTorch 集成torch_npu profiler 输出文件 correctness check跨机/RDMA同时记录 control barrier、handle wait、网络路径和 PE 拓扑采集MUST记录命令、workdir、环境变量、case、重复次数和日志路径。总结与落地指引这套时间打点与指标计算标准贯穿 SHMEM 算子性能评估的全流程先按引擎选择数据放置方式做法 A/B并对齐与 HCCL 的计时边界再以e2e_latency_us对时延、kernel_bus_bandwidth_GBps对带宽达标配合 bus_factor 参照表与 peak_bandwidth 决策表计算带宽利用率最后用SHMEMI_PROF_START/ENDaclshmemx_get_prof定位 kernel 内瓶颈 frame。落地时可进一步参阅采集流程与结果表格式.agents/skills/shmem-ops-performance-eval/references/performance-eval-guide.mdbaseline 选择与对比工作流.agents/skills/shmem-ops-performance-eval/references/baseline-selection.md、.agents/skills/shmem-ops-performance-eval/references/baseline-compare-workflow.md三阶段采集命令与离线对比.agents/skills/shmem-ops-performance-eval/references/perf-workflow.mdDevice 打点完整指南.agents/skills/shmem-ops-performance-eval/references/device-profiling-guide.md性能报告模板.agents/skills/shmem-ops-performance-eval/templates/performance-report.md【免费下载链接】shmemCANN SHMEM 是面向昇腾平台的多机多卡内存通信库基于OpenSHMEM 标准协议实现跨设备的高效内存访问与数据同步。项目地址: https://gitcode.com/cann/shmem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考