CANN SHMEM 算子性能采集与对比三阶段工作流与基线达标实践【免费下载链接】shmemCANN SHMEM 是面向昇腾平台的多机多卡内存通信库基于OpenSHMEM 标准协议实现跨设备的高效内存访问与数据同步。项目地址: https://gitcode.com/cann/shmem本文以.agents/skills/shmem-ops-performance-eval/references/perf-workflow.md为骨架融合同 skill 的 timing-and-metrics-standard.md、baseline-compare-workflow.md、performance-eval-guide.md 等文档以及仓库源码整理成一篇面向开发者的完整实操指南。本篇技术指南讲解在 CANN SHMEM 仓库生态下对基于 OpenSHMEM 标准实现的多机多卡内存通信算子collective 通信算子、dispatch/combine 等路由型算子进行性能采集与基线对比的完整方法论。你将掌握三阶段分时采集HCCL baseline → SHMEM → 离线对比的标准命令、日志标签与产物布局约定、kernel_bus_bandwidth_GBps达标口径、双指标e2e_us/kernel_us打点规范以及 Docker 环境下的隔离执行规则可直接复用于算子开发与性能报告生成。1. 适用范围与前置约定该性能采集工作流面向.agents/skills/shmem-ops-performance-evalskill 生成的custom-ops/交付树以custom-ops/op_name/为算子根目录而非 SHMEM upstream 自带目录。规范要点perf 封装位置custom-ops/scripts/skill 生成交付物以 perf-workflow.md 中的命令代码段为准磁盘文件由对应阶段生成或同步Skill 形态约束命令以 Markdown 代码段形式维护禁止在.agents/skills/下放置 skill 附属的.sh/.py脚本SHMEM 原生部分仅环境链如install/set_env.sh、scripts/build.sh -examples等来自 upstreamHard Gate硬隔离HCCL baseline 与 SHMEM perf绝对禁止在同一 shell 或同一次docker exec中混跑必须分阶段、分 shell 执行对比在离线阶段完成。环境准备参考 custom-ops-entrypoints.md先 source CANN 与 SHMEM 环境再设置LD_LIBRARY_PATH指向${SHMEM_REPO}/build/lib并在采集 baseline 时设置HCCL_WHITELIST_DISABLE1。2. 三阶段分时采集核心工作流整个性能采集被拆成三个彼此隔离的阶段阶段 A 仅跑 HCCL baseline→阶段 B 仅跑 SHMEM→阶段 C 离线对比。这样设计是为了规避 HCCL 与 SHMEM 在同一进程中混跑导致的资源抢占与初始化状态污染确保两侧数据各自独立可信。2.1 阶段 A — 仅采集 HCCL baseline在独立 shell 中执行以下命令日志写入data/perf/baseline_*.logOPop_name DEVICE_LIST0,1,2,3,4,5,6,7 BASE_COUNT8388608 DTYPEfloat16 WARMUP10 MEASURE40 ITERS$((WARMUP MEASURE)) # 50 total mkdir -p ${SHMEM_REPO}/custom-ops/${OP}/data/perf LOG${SHMEM_REPO}/custom-ops/${OP}/data/perf/baseline_${BASE_COUNT}_${DTYPE}.log bash ${SHMEM_REPO}/custom-ops/${OP}/baseline/scripts/run_baseline.sh \ ${DEVICE_LIST} ${BASE_COUNT} ${DTYPE} ${ITERS} \ 21 | tee ${LOG}参数语义参数含义示例取值OP算子名custom-ops/op_name/目录名alltoallv、allgatherDEVICE_LIST参与性能测试的设备列表0,1,2,3,4,5,6,78 卡标准配置BASE_COUNT单 PE 基础数据量元素数83886088×1024×1024fp16 时单 PE 16MBDTYPE数据类型float16/float32等WARMUP预热轮数不计入统计10MEASURE统计轮数40ITERS总轮数 warmup measure50baseline 侧由baseline/scripts/run_baseline.sh驱动输出以[BASELINE_PERF]前缀标记详见下文 §4 日志标签约定。2.2 阶段 B — 仅采集 SHMEM阶段 A 完成后间隔 ≥30 秒新开一个 shell不可复用阶段 A 的进程上下文执行 SHMEM 采集日志写入data/perf/shmem_*.logOPop_name DEVICE_LIST0,1,2,3,4,5,6,7 BASE_COUNT8388608 DTYPEfloat16 WARMUP10 MEASURE40 ITERS$((WARMUP MEASURE)) # 50 total mkdir -p ${SHMEM_REPO}/custom-ops/${OP}/data/perf LOG${SHMEM_REPO}/custom-ops/${OP}/data/perf/shmem_${BASE_COUNT}_${DTYPE}.log bash ${SHMEM_REPO}/custom-ops/${OP}/scripts/perf.sh \ ${DEVICE_LIST} ${BASE_COUNT} ${DTYPE} ${ITERS} \ 21 | tee ${LOG}SHMEM 侧由算子目录内scripts/perf.sh驱动或 in-tree example 使用scripts/run.sh --perf输出以[PERF]前缀标记。预热轮WARMUP不计入统计统计轮MEASURE内多 PE 结果取平均具体规范见 profiling-tools.md。2.3 阶段 C — 离线对比两阶段日志落盘后使用custom-ops/scripts/lib/perf_compare.py离线解析并对比禁止手工抄数OPop_name BASE_COUNT8388608 DTYPEfloat16 SHMEM_LOG${SHMEM_REPO}/custom-ops/${OP}/data/perf/shmem_${BASE_COUNT}_${DTYPE}.log BASE_LOG${SHMEM_REPO}/custom-ops/${OP}/data/perf/baseline_${BASE_COUNT}_${DTYPE}.log python3 ${SHMEM_REPO}/custom-ops/scripts/lib/perf_compare.py \ --shmem-log ${SHMEM_LOG} --baseline-log ${BASE_LOG}对比通过 grep[PERF]与[BASELINE_PERF]两行 脚本解析完成。时延类算子可使用custom-ops/scripts/perf_compare_latency.py对比kernel_us/comm_only_us字段。S 档采集说明Round 0 与最终轮需要额外采集 S 档规模。做法是将BASE_COUNT替换为 S 档规模分档标准见 testcase-scale-standard.md其余流程与 L 档完全相同中间优化轮次仅采 L 档。3. 产物布局与隔离规则3.1 目录结构约定custom-ops/下性能相关产物布局如下所有日志与脚本路径都必须遵守custom-ops/ ├── scripts/lib/perf_compare.py # 带宽离线对比脚本 ├── scripts/perf_compare_latency.py # 时延离线对比脚本可选 └── op_name/ ├── baseline/scripts/run_baseline.sh # HCCL baseline 入口 ├── scripts/perf.sh # SHMEM perf 入口 └── data/perf/ # baseline_*.log / shmem_*.logbaseline 的实现约束来自 baseline-compare-workflow.mdbaselineMUST以 C 可执行文件方式实现禁止用 Python/torch 脚本充当 baselinebaseline 源码与 CMake 必须放在baseline/子目录禁止混入算子src/或根CMakeLists.txt算子根CMakeLists.txt末尾通过add_subdirectory(baseline)集成baseline 的CMakeLists.txt将CMAKE_RUNTIME_OUTPUT_DIRECTORY设为${CMAKE_BINARY_DIR}/../bin与主程序同目录同一gen_data.py输出、同一 sendcounts/shape/dtype/PE 数保证与 SHMEM 完全同 case。3.2 HCCL 与 SHMEM 隔离Hard GateHCCL baseline 与 SHMEM perfNEVER同 shell / 同docker exec混跑且每阶段使用独立的docker exec见 docker-exec-contract.md。典型执行方式是两次独立docker exec容器内分别粘贴阶段 A/B 命令再在第三处执行阶段 C 离线对比。4. 日志标签与指标口径4.1 日志标签约定两边的性能日志以统一前缀输出便于脚本 grep 与离线解析实现输出前缀必含字段SHMEM 算子[PERF]e2e_us,kernel_us,e2e_bus_bandwidth_GBps,kernel_bus_bandwidth_GBps,payload_bytesHCCL/aclnn baseline[BASELINE_PERF]同上额外含apiHcclAlltoAllV等关键判定原则kernel_bus_bandwidth_GBps是达标对比 MUST 使用的字段e2e_bus_bandwidth_GBps仅作参考NEVER作为 Round 间对比或达标主指标。4.2 达标口径带宽SHMEM kernel_bus_bandwidth_GBps / HCCL kernel_bus_bandwidth_GBps时延HCCL / SHMEM使用comm_only或kernel_us有 baseline 时默认达标线为current ≥ baseline 的 80%无 baseline 时metric_only通信算子带宽利用率NEVER 低于 20%完整达标线与判定规则见 timing-and-metrics-standard.md。4.3[PERF]行字段语义SHMEM 算子--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字段说明e2e_us端到端时延做法 Akernel 内放置≈kernel_us做法 Bkernel 外放置含aclrtMemcpy barrier kernelkernel_us仅 kernel 执行时间algo_bandwidth_GBpslogical_payload_bytes / e2e_us / 1e9e2e 口径算法带宽e2e_bus_bandwidth_GBpsalgo_bandwidth_GBps × bus_factor仅作参考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/拓扑取值HCCL baseline 输出格式与之类似前缀为[BASELINE_PERF]并追加api字段指明调用的 HCCL API。5. 公平对比双指标与执行模型对齐timing-and-metrics-standard.md规定每个 SHMEM 算子MUST报告两个时延指标这是保证与 HCCL 公平对比的基础指标含义起点终点用途e2e_latency_us端到端延迟覆盖从用户 input(GM) 到结果 output(GM) 的全部数据搬运做法 Akernel launch 前做法 BaclrtMemcpy前stream sync 后与 HCCL baseline 公平对比kernel_latency_uskernel 执行时间kernel launch 前stream sync 后内部优化定位5.1 两种数据放置模型由于远端 PE 只能访问对称内存aclshmem_malloc分配而用户input在普通 Device GMaclrtMalloc数据放置方式取决于通信引擎对地址类型的支持引擎put_nbi src 能否是用户 GMget_nbi dst 能否是用户 GM放置方式MTE能能做法 Akernel 内直接用put_nbi(symm, user_gm, ...)SDMA能能同 AUDMA能能同 ARDMA不能不能做法 BHost 侧aclrtMemcpy(user_gm → symm)再进 kernel约束要点MTE/SDMA/UDMA 下SHOULD选用做法 A直接在 kernel 内搬运避免无意义的 kernel 外循环代码中 MUST 在注释中说明引擎选择如// MTE put_nbi srclocal GM, no Host-side memcpy neededRDMA 下MUST选用做法 B——双方数据都必须位于对称内存做法 A 下e2e_us ≈ kernel_us是正常现象而非问题做法 B 下e2e_us MUST kernel_us差值即 kernel 外的搬运时间禁止为制造e2e_us kernel_us的假象而在做法 A 路径上增加无意义的 kernel 外搬运设计 DSLschedule中MUST标注使用的引擎和对应放置方式A 或 B。5.2 公平对比原则HCCL API 调用时间包含其内部全部 staging 开销因此 SHMEM 的 e2e 计时必须覆盖从用户 input(GM) 到结果 output(GM) 的全部搬运两侧计时边界对齐边界HCCLSHMEM计时起点数据在 Device GM数据在 Device GM用户 input 尚未被搬运触碰计时终点结果在 Device GM结果在 Device GM5.3 perf 循环结构示例做法 B以 all-to-alltransport, fp16为例phase 分解为stagingaclrtMemcpyAsync→ barrieraclshmem_barrier_all→ kernelLaunchAlltoallHalf→ sync。推荐的双循环打点结构// 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 属于后续优化范畴。6. 指标计算从逻辑载荷到带宽利用率6.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 拉回量6.2 algo_bandwidth 与 bus_bandwidthalgo_bandwidth_GBps logical_payload_bytes / latency_s / 1e9 kernel_bus_bandwidth_GBps algo_bandwidth_GBps(kernel) × bus_factor bandwidth_utilization_percent kernel_bus_bandwidth_GBps / peak_bandwidth_GBps × 100注意algo_bandwidth不乘 2统一按 input size 计算遵循 NCCLalgBw惯例。6.3 bus_factor 参照表bus_factor唯一参照源为 timing-and-metrics-standard.md §4.3各 skill 中的取值 MUST 以该表为准算子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同上AllToAll / Shuffle(n_pes - 1) / n_pes每个 PE 发送 (n-1)/n 数据到远端Broadcast1单源广播发送方带宽不放大P2P1点对点无集合通信放大因子dispatch(n_pes - 1) / n_pes近似均匀路由假设路由不均匀时按实际远端搬运量推导combine(n_pes - 1) / n_pes近似同 dispatch6.4 peak_bandwidth 决策表peak_bandwidth_GBpsMUST 记录来源SoC、链路类型、PE 数、拓扑按决策表取值通信模式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 口径路由不确定算子通算融合按通信阶段选 P2P 或集合通信值fused_compute_comm 的通信阶段utilization 超过 100% 时应在报告中注释可能原因bus_factor 高估、链路实际带宽超出标称值。6.5 计算示例all-to-all, fp16, 8 PE, shard_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) ratio: 111.85 / 106.77 104.8% 80% - PASS7. Baseline 选择策略性能采集需要明确的 baseline 作为对比基准详见 baseline-selection.md按优先级选择7.1 优先级 1HCCL / aclnn 算子库声称无 baseline前 MUST 逐一排查 HCCL 集合通信算子清单SHMEM 算子HCCL BaselineHCCL APIAllGatherHcclAllGatherHcclAllGather(sendBuf, recvBuf, count, dataType, comm, stream)AllReduceHcclAllReduceHcclAllReduce(sendBuf, recvBuf, count, dataType, op, comm, stream)ReduceScatterHcclReduceScatterHcclReduceScatter(sendBuf, recvBuf, count, dataType, op, comm, stream)AllToAllHcclAlltoAllHcclAlltoAll(sendBuf, sendCount, sendType, recvBuf, recvCount, recvType, comm, stream)BroadcastHcclBroadcastHcclBroadcast(buf, count, dataType, root, comm, stream)ReduceHcclReduceHcclReduce(sendBuf, recvBuf, count, dataType, op, root, comm, stream)ScatterHcclScatterHcclScatter(sendBuf, recvBuf, count, dataType, root, comm, stream)GatherHcclGatherHcclGather(sendBuf, recvBuf, count, dataType, root, comm, stream)aclnn 扩展算子AllToAllV 对应aclnnAlltoAllV当 CANN 无独立aclnnAlltoAllV头文件时 MUST 回退HcclAlltoAllVhccl/hccl.h参考custom-ops/alltoallv/baseline/实现。7.2 优先级 2指标测试metric_only既无 HCCL 对应算子也无 aclnn 扩展算子时使用 metric_only但 MUST 先记录已逐一排查 HCCL 清单、aclnn 扩展、已有 SHMEM example、用户参考实现的过程。测试策略包括时延测试、带宽测试与带宽利用率测量能计算时 MUST 输出 utilization且 NEVER 低于 20%。7.3 选择决策树Step 1: 查找 HCCL 集合通信算子清单 ├─ 有完全对应 → 使用 HCCL 算子作为 baseline └─ 无 → Step 2 Step 2: 查找 aclnn 扩展算子 ├─ 有对应算子 → 使用 aclnn 算子作为 baseline └─ 无 → Step 3 Step 3: 使用指标测试metric_only └─ 带宽利用率 ≥ 20%HCCL baseline 采集示例AllToAll 打点模式for (int i 0; i warmup; i) { LaunchHcclBaseline(sendBuf, recvBuf, count, comm, stream); } aclrtSynchronizeStream(stream); aclrtRecordEvent(startEvent, stream); for (int i 0; i iters; i) { LaunchHcclBaseline(sendBuf, recvBuf, count, comm, stream); } aclrtRecordEvent(endEvent, stream); aclrtSynchronizeStream(stream); float elapsed_ms; aclrtEventElapsedTime(elapsed_ms, startEvent, endEvent); float avg_us elapsed_ms * 1000.0f / iters; printf([BASELINE_PERF] pe%d e2e_us%.2f kernel_us%.2f ..., ...);8. 性能 Case 规模要求与报告输出8.1 规模分档性能采集 MUST 覆盖8PE S 档 8PE L 档两种规模NEVER 只采 L 档分档标准见 testcase-scale-standard.md分档每 PE 数据量典型 shapefp16用途XS 64KB(64, 32), (128,), (256,)边界测试、启动开销S64KB ~ 1MB(256, 128), (512, 256)smoke 正确性验证M1MB ~ 64MB(1024, 1024), (2048, 2048)常规性能测试L≥ 64MB全 PE 总量 ≥ 256MB(8192, 8192), (16384, 4096)性能达标测试性能前置条件编译成功、correctness contract 通过、中等规模 case 通过NEVER 只依赖 smoke 小 shape。correctness 未通过时性能数据无效。8.2 聊天与报告输出采集完成后 MUST 在聊天界面自动输出不等待用户追问见 perf-chat-output-spec.md块 A — S 档 L 档性能表| 规模 | case_id | e2e_us | kernel_us | kernel_bus_bandwidth_GBps | utilization% | |------|---------|--------|-----------|---------------------------|--------------| | S 档 | ... | ... | ... | ... GB/s | ...% | | L 档 | ... | ... | ... | ... GB/s | ...% |块 B — SHMEM vs Baseline 对比表达标判定| 指标 | SHMEM | HCCL baseline | SHMEM/baseline | 达标 | |------|-------|---------------|----------------|------| | kernel_bus_bandwidth_GBps | ... | ... | ...% | PASS/FAIL | | e2e_us | ... | ... | ... | — | | kernel_us | ... | ... | ... | — |达标线有 baseline 时默认 ≥ baseline 80%无 baseline 时通信算子带宽利用率 ≥ 20%。同时 MUST 将对比表写入docs/performance_report.md§3.5含kernel_bus_bandwidth_GBps对比§7 说明达标/未达标原因NEVER 只输出 SHMEM 单边[PERF]数据。8.3 Device 侧片段打点性能采集 MUST 同时覆盖端到端指标和关键 Device 片段指标优化判断 NEVER 只依赖总耗时。kernel 中按 phase 插入SHMEMI_PROF_START(frame_id)/SHMEMI_PROF_END(frame_id)宏定义位于 shmemi_prof.hHost 侧在 stream 同步后调用aclshmemx_get_prof(nullptr, true)导出各 PE、block、frame 的 cycles、count 与平均耗时。frame map 至少覆盖copy_in/copy_out、remote_put_get、signal_or_barrier_wait、local_compute、finalize等主要耗时来源。参考仓库中的 profiling 模式如 tp_allreduce_perf_host.h 中[PERF]行的 host_total 与 frame 级输出方式。采集 MUST 记录命令、workdir、环境变量、case、重复次数和日志路径保证可复现默认性能路径 NEVER 永久打开 printf、DumpTensor 或重型 debug 日志。9. 反模式清单以下行为被明确禁止实践中应逐条规避❌ 同一 shell / 同一次docker exec内先 SHMEM 再 HCCL必须分阶段 离线 compare❌ 同一流程内嵌启动 baseline shmem❌ baseline 用 Python dist 代替 C HCCL 程序❌ 对比表只写文件路径、聊天无表格❌ 在宿主机无 NPU 环境伪造 perf 数据❌ 用 smoke 小 shape 作为性能结论❌ 只报 SHMEM[PERF]不报 baseline[BASELINE_PERF]及对比表❌ 只输出 algo_bandwidth 不输出 bus_bandwidth 与 utilization❌ 用 e2e 带宽作 Round 间对比固定开销导致虚假提升❌ baseline 与 SHMEM 使用不同 gen_data / sendcounts❌ 性能测试完成后不在聊天中自动输出结果等用户追问。10. 相关文档索引timing-and-metrics-standard.md时间打点、双指标方案、指标计算与 bus_factor 唯一参照源baseline-compare-workflow.mdbaseline 接入流程、日志标签、离线对比baseline-selection.mdHCCL/aclnn baseline 清单与决策树performance-eval-guide.md采集流程概览、contract 字段、结果表格式perf-chat-output-spec.md聊天自动输出规范device-profiling-guide.mdSHMEMI_PROF完整操作指南testcase-scale-standard.mdS/L 档规模定义custom-ops-entrypoints.md环境链与编译/运行入口仓库内 profiling 参考实现shmemi_prof.h、tp_allreduce_perf_host.h【免费下载链接】shmemCANN SHMEM 是面向昇腾平台的多机多卡内存通信库基于OpenSHMEM 标准协议实现跨设备的高效内存访问与数据同步。项目地址: https://gitcode.com/cann/shmem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考