网站运营案例专业公司网站 南通

网站运营案例,专业公司网站 南通,如何用wordpress制作二级目录,小型建筑公司有哪些CANN 8 性能实测与优化#xff1a;通信算子变化带来了什么#xff1f; 一、一次性能“再平衡”的开始 每一次框架升级#xff0c;都意味着新的优化与新的挑战。 当 CANN 8 发布后#xff0c;很多团队第一时间完成了环境切换#xff0c;希望借此获得更高的训练性能与算子效…CANN 8 性能实测与优化通信算子变化带来了什么一、一次性能“再平衡”的开始每一次框架升级都意味着新的优化与新的挑战。 当 CANN 8 发布后很多团队第一时间完成了环境切换希望借此获得更高的训练性能与算子效率。然而在实际测试中我们发现一个现象同样的模型、同样的硬件环境下CANN 8 的表现与 CANN 7 并不完全一致。部分场景性能提升明显但在大规模分布式训练中却出现了不同程度的性能波动。 于是我们决定深入分析这背后的原因看看CANN 8 的通信算子变化到底带来了什么二、实验准备为了排除干扰我们搭建了两套完全一致的测试环境 唯一不同的是 CANN 版本号。项目CANN 7CANN 8Python3.103.10HDK23.0.623.0.6CANN7.0.1.38.0 RC2Torch2.1.02.1.0Torch_npu2.1.02.1.0post6Apexapex-0.1 torchairapex-0.1 torchair除 CANN 外所有环境保持一致确保对比结果只与框架版本差异相关。环境版本检查import torch import torch_npu print(PyTorch Version:, torch.__version__) print(torch_npu Version:, torch_npu.__version__) print(NPU Device Count:, torch.npu.device_count()) print(CANN Version:, torch_npu.get_cann_version())三、性能变化的信号在多轮测试后我们观察到以下规律单节点性能整体平稳节点数扩展到 4 或 8 后通信耗时明显增加日志中偶尔出现 HCCL 超时或通信等待。这并不是“性能退化”而更像是一次系统层面的性能再平衡 CANN 8 在通信层做了重构使算子调度更细粒度、更灵活但也引入了额外的同步成本。要进一步确认这一点我们决定通过Profile 日志深入分析。参考链接ModelLink: 昇腾LLM分布式训练框架 - Gitee.comModelLink 支持基于昇腾芯片采集完整的 Profiling 数据以帮助开发者更深入地分析模型的执行性能、算子分布与系统瓶颈。 通过命令行参数或配置文件即可灵活控制采样范围、采样级别与采样对象。下面是常用的 Profiling 相关参数说明参数功能描述--profile打开 Profiling 采集开关启用数据采集模式--profile-step-start 5指定从第 5 步开始采集--profile-step-end 6指定采集结束步不包含 end 步实际采集步数 end - start--profile-ranks 0,1,2,3,4指定要采集的卡号默认 -1 表示采集所有 rank--profile-level level2设置采集数据的级别支持 level1 / level2级别越高采集越详细默认 level1--profile-with-cpu是否同时采集 CPU 侧数据加入参数则启用--profile-with-stack是否采集算子运行堆栈信息用于分析调度路径--profile-with-memory是否采集内存使用信息分析显存占用与峰值变化--profile-record-shapes是否记录算子输入输出 shape 信息--profile-save-path ./profile_dir指定 Profiling 数据保存路径这些参数可以灵活组合使用例如以下命令python train.py \ --profile \ --profile-step-start 10 \ --profile-step-end 15 \ --profile-level level2 \ --profile-ranks 0,1 \ --profile-with-cpu \ --profile-with-memory \ --profile-save-path ./profiling_result/该命令将在第 1014 步采集 Profiling 数据仅针对 rank0 和 rank1 采集启用 CPU 与内存监测采集详细算子级信息level2并将结果保存到./profiling_result/目录下。在运行命令后加入如上图命令会在对应文件生成profile日志。注意每次生成前清理之前缓存否则产生的日志会较多导致无法区分是哪次训练采集到的。要获得可用的Profile 日志。 在昇腾生态中也可以使用ModelLink 工具链进行采集。 ModelLink 是昇腾 LLM 分布式训练框架的重要组成部分 在 MindSpeed-LLM、Megatron-Ascend 等上层框架中都已深度集成。ModelLink 简介ModelLink 的核心功能包括模型并行训练调度支持 PP、TP、DP 并行组合训练作业统一启动与监控性能 profile 采集与分析cluster 模式下的多节点同步日志聚合。在性能分析环节中它通过profiling模块自动记录各算子的运行耗时、通信时长、内存占用与下发延迟。获取 Profile 日志的流程1启用 Profiling 模式运行模型在启动命令中加入profiling_enable参数即可自动采集日志bash run_train.sh \ --data_path/data \ --pp2 --tp4 \ --profiling_enableTrue执行后ModelLink 会在每个训练节点的工作目录下生成对应的日志文件夹/path/to/output/profiler/{rank_id}/2清理缓存确保日志唯一性由于多次运行会生成多个 profile 文件 建议每次运行前清理缓存/path/to/output/profiler/{rank_id}/这样可以避免旧日志与新数据混杂。3日志汇聚与解析完成训练后将所有 rank 的日志目录拷贝至同一位置 使用以下命令进行聚合分析msprof-analyze cluster \ -d ./profiler/ \ -m analysis解析完成后会生成cluster_analysis_output/ ├── summary.csv ├── operator_time.csv ├── communication.csv └── timeline/这些文件即为后续导入 MindStudio 进行可视化分析的基础数据。与 MindSpeed-LLM 的联动在MindSpeed-LLM环境中ModelLink 已默认作为底层执行引擎使用 因此无需额外安装。只需在配置文件中开启 Profiling 开关即可例如args.enable_profiling True args.profiling_dir ./profiler这样在模型启动后Profile 日志将自动记录至指定目录。 相比传统环境变量方式ModelLink 的采集方式支持 step 控制 能在长时间大模型训练中捕获更精确的阶段性性能数据。常见问题问题场景可能原因建议解决方案无法生成完整日志profiling 未开启或路径错误检查参数与目录权限profile 数据量过大step 未限制设置profiling_steps10等采样间隔聚合时报错路径层级不一致确保 rank 日志目录结构统一日志混乱未清理旧缓存每次运行前执行rm -rf profiler/*四、在 MindSpeed-LLM 框架下采集 Profile由于 CANN 8 在通信算子与调度层做了大量架构更新 我们选择在MindSpeed-LLM 框架下进行性能采样与分析。MindSpeed-LLM 是昇腾官方推出的大模型训练与并行框架 它在模型层面实现了张量并行TP、流水线并行PP和数据并行DP的灵活组合 同时内置了对 CANN 8 通信算子的深度适配。在这个框架中我们可以更清晰地捕获通信与计算之间的调度关系。 以下为实际使用的采集流程msrun --nproc_per_node8 \ python train.py \ --enable_profilingTrue \ --use_mindspeedTrue \ --pp2 --tp4运行时MindSpeed-LLM 会调用底层 ModelLink 模块生成profile日志 日志包含以下关键信息每个算子的执行耗时与调度顺序通信算子HCCL AllReduce、AllGather、ReduceScatter 等耗时各卡的计算-通信重叠情况张量并行与流水线分区带来的调度延迟。这些信息共同组成了模型在 CANN 8 下的“性能画像”。采集完成后我们通过命令进行数据聚合msprof-analyze cluster \ -d ./profile_data \ -m analysis此时生成的cluster_analysis_output目录中 包含了 CSV、Timeline、Summary 等多种格式的统计结果可直接导入 MindStudio 进行可视化分析。msrun 启动脚本 终端日志截图msrun --nproc_per_node8 python train.py \ --enable_profilingTrue \ --pp2 --tp4 --use_mindspeedTrue五、CANN 8 的新调度逻辑在 MindStudio 的“计算/通信概览”界面中 我们对比了两组日志结果相当直观CANN 8 的通信算子数量显著增加HCCL 通信域中通信总时间占比更高某些“慢卡”在通信阶段的等待时间较长。进一步展开算子时间线发现CANN 8 将原本在 CANN 7 中融合的算子拆解为更细粒度的“计算算子 通信算子”结构。这一变化带来双重影响分析更灵活能更精确地定位通信瓶颈通信成本上升多节点同步等待时间被放大。六、结合 MindSpeed-LLM 的并行策略分析MindSpeed-LLM 在大模型训练中通常采用TPPP 混合并行 并通过多进程通信HCCL完成梯度同步。在该并行策略下通信开销会随着模型深度和节点数呈非线性增长。 在我们的实验中模型层数节点数通信算子耗时占比计算算子耗时占比32219%81%64427%73%96838%62%可以看到当层数和节点数增加时通信算子的执行时间被进一步放大。而在 CANN 8 中这种放大效应更加明显 因为其算子融合策略更细使得通信算子数量倍增。这也是为什么我们在前文观察到“单节点性能平稳但多节点训练性能波动。”七、融合算子与 mc2 模式为了解决通信算子数量增多的问题 CANN 8 与 MindSpeed-LLM 引入了mc2 融合模式Multi-Compute Communication Fusion。该模式通过将计算与通信阶段重新融合 以减少 HCCL 调用次数、降低同步开销。启用方法十分简单只需在启动脚本中添加以下配置args.use_mc2 True或者在训练命令行中直接指定--enable_mc2True启用 mc2 后部分关键算子如 LayerNorm、RMSNorm、Swiglu、FlashAttention 等 会自动切换为融合实现。实测数据显示启用 mc2 模式后通信开销平均降低约 20%–30% 多节点集群训练速度恢复至 CANN 7 同等水平甚至略优。八、常见问题在多轮验证中我们还遇到了几类常见问题及解决方式问题现象原因分析解决方案HCCL 集合操作超时默认超时时间较短或版本 Bug建议使用 CANN 8 RC2 并延长超时Profile 日志采集不完整环境变量方式不适合大模型使用 MindSpore Profiler 采集profile-ranks-1报错torch_npu 新版参数变动手动设置 rank 范围如 0–15节点数增多后性能下降通信算子增多融合度降低开启 mc2 模式恢复融合效果HCCL 超时检查import os print(HCCL_CONNECT_TIMEOUT , os.getenv(HCCL_CONNECT_TIMEOUT)) print(HCCL_EXEC_TIMEOUT , os.getenv(HCCL_EXEC_TIMEOUT))九、融合与调参的效果经过多轮调整我们采用了以下方案启用 mc2 融合模式恢复部分通信算子的融合执行降低通信等待。延长超时时间export HCCL_CONNECT_TIMEOUT1800 export HCCL_EXEC_TIMEOUT7200节点规模控制节点数使用 2 的幂次方如 2、4、8通信效率最佳。版本回退验证CANN 8 RC2 稳定性优于 RC3可作为推荐部署版本。经过优化后CANN 8 的通信耗时平均下降约28%整体性能恢复至与 CANN 7 持平甚至略优。基于多轮实验我们整理出一份CANN 8 MindSpeed-LLM 环境下的性能优化清单优化方向建议做法说明版本选择使用 CANN 8 RC2 或正式版RC3 通信稳定性略差Profiling 采集使用 MindSpore Profiler 而非环境变量可控制 step 与采样间隔mc2 模式启用融合算子模式通信效率显著提升并行策略PP、TP 值建议为 2 的幂次通信结构更规整超时参数HCCL_CONNECT_TIMEOUT1800、HCCL_EXEC_TIMEOUT7200适配大模型训练日志聚合定期清理缓存后采集避免旧日志干扰节点扩展建议逐步放大规模验证避免一次性扩容带来的通信瓶颈通过这份清单开发者可以在升级或迁移时快速排查性能差异来源 并结合 MindStudio 与 MindSpeed-LLM 工具实现精细化调优。十、变化CANN 8很多人看到算子拆分的第一反应是“变慢了” 但从系统设计角度看这是一次更大的架构调整。通信与计算的调度关系更透明Profiler 输出更完整算子融合策略更可控工具链如 MindStudio提供了更细粒度的性能洞察。CANN 8 不只是“另一个版本”而是为大规模分布式场景和自适应算子融合奠定的底层基础。算子数量对比import pandas as pd df7 pd.read_csv(cann7_ops.csv) df8 pd.read_csv(cann8_ops.csv) print(CANN7 operator count:, len(df7)) print(CANN8 operator count:, len(df8)) print(Increase:, len(df8) - len(df7))十一、总结优化是一场理解的过程CANN 8 的性能表现变化并非简单的“好”或“坏” 而是一种系统在重构后寻找新平衡点的过程。升级带来的不确定性正是我们理解系统、掌握底层逻辑的最好机会。只有深入分析、主动优化才能真正发挥出新版本的潜能。 在通信算子、调度策略、算子融合这些“看不见的角落” 往往隐藏着性能提升的关键。注明昇腾PAE案例库对本文写作亦有帮助。