【HCIE-AI】10.昇腾 模型迁移分析

一、迁移分析前置工作

概述：迁移分析不是直接从GPU代码跳到NPU代码，而是需要先在第三方平台（GPU）上建立"基线"，再在昇腾平台上进行对标验证。没有基线，后续所有分析都缺少参照系。

1.1 三方平台获取基线

精度基线记录示例：

{ "model": "GLM-4-9B", "device": "NVIDIA A100 80G", "framework": "PyTorch 2.1 + transformers 4.36", "precision": { "fp32": { "loss": 2.341, "acc_top1": 0.7234 }, "fp16": { "loss": 2.345, "acc_top1": 0.7228 } }, "performance": { "throughput": 420.5, "latency_p50": 8.2, "peak_memory_gb": 58.2 } }

1.2 昇腾环境搭建

# 1. 确认昇腾驱动和 CANN 版本 npu-smi info # 查看芯片型号、显存、驱动 cat /usr/local/Ascend/version.cfg # 查看 CANN 版本 # 2. 安装 torch_npu（与 PyTorch 版本严格对应） pip install torch_npu==2.1.0 # 对应 PyTorch 2.1

芯片与 CANN 版本对应关系：

环境验证脚本（env_check.py）：

import torch import torch_npu print(f"PyTorch: {torch.__version__}") print(f"NPU available: {torch.npu.is_available()}") print(f"NPU count: {torch.npu.device_count()}") print(f"Device name: {torch.npu.get_device_name(0)}") # 基础算子测试 x = torch.randn(100, 100).npu() y = torch.randn(100, 100).npu() z = torch.mm(x, y) print(f"MatMul test passed: {z.shape}") print(f"Memory: {torch.npu.memory_allocated(0)/1024**3:.2f} GB")

二、算子支持情况分析

msFmkTrans（华为官方迁移分析工具）

概述：这是迁移分析最核心的一步——扫描训练脚本中所有的 torch API 和 CUDA API，逐一判断在昇腾上是否支持。支持状态分为四级，并给出精度和性能的专家调优建议。

2.1 工具与用法

• 工具：msFmkTrans（华为官方迁移分析工具）
• 安装：pip install msfmktrans
• 说明：用户提供待分析的PyTorch训练脚本，可快速获得该训练脚本中不支持的torch API和cuda API信息，并输出训练脚本中API精度和性能调优的专家建议

msfmktrans --input=train.py \ --output=./analysis \ --framework=pytorch

2.2输出产物

2.3 API 支持状态四级分类

2.4 报告内容示例

2.5 专家建议示例

## 精度优化建议 ### LayerNorm（6处使用） - 问题：fp16混合精度下，昇腾LayerNorm与GPU存在 ±1e-3 偏差 - 建议：在 autocast 中排除 LayerNorm ```python with autocast(): ... with autocast(enabled=False): x = self.layer_norm(x) # 强制 fp32

性能优化建议

MatMul（占总耗时42.3%）

• 预期收益：30-50%

--- ## 三、三方库套件分析 > **概述：** 现代 PyTorch 项目通常依赖 transformers、deepspeed、accelerate 等三方库。这些库内部可能含有不兼容的 API 调用，需要单独扫描和分析。 ### 3.1 工具与用法 ```bash # 方式一：自动扫描依赖目录 msfmktrans --input=./my_project \ --third-party-dir=./venv/lib/python3.10/site-packages \ --output=./tp_analysis # 方式二：手动指定需要分析的库 msfmktrans --input=./my_project \ --third-party-list=transformers,deepspeed,accelerate \ --output=./tp_analysis

三：常见三方库兼容性速查

原理： msFmkTrans 内置了主流三方库的API映射表，不止扫描你自己的代码，还扫描 import 进来的库。

对应工具：msFmkTrans + 自定义规则扩展

说明：用户提供待分析的三方库套件源码，可快速获得源码中不支持的三方库API和cuda信息。

3.3 输出示例

{ "library": "transformers", "version": "4.36.0", "status": "partial", "incompatible_modules": [ { "module": "LlamaFlashAttention2", "reason": "flash_attn 依赖不存在于昇腾", "fix": "替换为 transformers 默认 attention" } ] }

四、动态Shape分析

概述：昇腾 NPU对动态 Shape 的容忍度远低于 GPU。每次输入 Shape 变化都可能触发算子重新编译（JIT编译），导致性能断崖式下跌。因此迁移前必须识别并消除动态 Shape 来源。

用户提供待分析的PyTorch训练脚本，可快速获得该训练脚本中包含的动态shape信息

4.1 动态Shape的四大来源

4.2 静态分析（代码层面）

msfmktrans --input=train.py \ --dynamic-shape-analysis \ --output=./dynamic_analysis

输出示例：

==================================== 动态Shape检测报告 ==================================== [来源1] DataLoader 批次不一致 文件: data_loader.py:35 代码: for batch in dataloader: 建议: 设置 drop_last=True [来源2] 序列长度不固定 文件: tokenizer.py:48 代码: tokens = tokenizer(texts, padding=True, truncation=True) 建议: 固定 max_length=512 [来源3] 动态mask 文件: attention.py:67 代码: causal_mask = torch.triu(...)[:seq_len, :seq_len] 建议: 将mask计算移到DataLoader预处理中 ==================================== 严重度评估: 高(3处) 中(2处) 低(1处) ====================================

4.3 运行时分析（实际执行）

# 开启Shape dump export ASCEND_DUMP_SHAPE=1 export ASCEND_DUMP_SHAPE_PATH=./shape_dump python train.py --epochs=1

输出示例：

诊断标准：如果同一个算子的count=1（只出现一次）且total_us远高于稳定值，说明 Shape 变化导致频繁重编译。

4.4 动态Shape修复策略

五、亲和API分析

概述："亲和API"指昇腾上经过硬件加速优化的 API 替换建议。保持接口语义一致的前提下，替换为昇腾专有算子可以获得显著的性能提升。不是强制要求，但值得关注。

用户提供待分析的PyTorch训练脚本，可快速获得该训练脚本中可替换的亲和API信息。

5.1 工具与用法

msfmktrans --input=train.py \ --affinity-api \ --output=./affinity_report

5.2 三级替换建议

🔥 高收益项（性能提升 > 20%）

⚡ 中等收益项（10-20%）

✅ 建议保持原样（昇腾已有隐式优化）

5.3 替换风险控制

# 替换前必须验证等效性 x = torch.randn(4, 128, 128).npu() # 原API out_old = torch.bmm(x, x.transpose(1, 2)) # 亲和API out_new = torch.matmul(x, x.transpose(1, 2)) # 验证 diff = (out_old - out_new).abs().max().item() assert diff < 1e-6, f"精度偏差过大: {diff}"

六、工具链全景

概述：整个迁移分析不是靠一个工具完成的，而是由一套工具链配合使用，覆盖不同阶段和不同维度。

6.1 工具清单

6.2 工具定位图

使用阶段 工具 解决的问题 ────────────────────────────────────────────────── 迁移前评估 ── msFmkTrans ── "能不能迁？改多少？" 环境验证 ── env_check ── "环境装好了吗？" 算子验证 ── 前向运行 ── "跑起来报错吗？" 精度对齐 ── Hook + adc ── "输出对得上吗？" 性能分析 ── msprof ── "哪里慢？为什么慢？" 持续优化 ── 环境变量调优 ── "还能再快吗？"

七、输出产物清单

概述：迁移分析最终会产出一系列结构化的文档和数据，作为后续实际迁移工作的依据和参考。

八、建议迁移分析工作流

概述：从拿到项目代码到产出迁移可行性报告，建议按以下五个步骤有序推进，每一步产出的结果决定是否进入下一步。

┌────────────────────────────────────────────────────────────┐ │ 步骤1：全面扫描 —— msFmkTrans │ │ 输入：训练脚本 │ │ 输出：API支持状态 + 三方库兼容 + 动态Shape + 亲和API │ │ 决策：如果有 >10% 的红色（不兼容）项，需评估是否值得迁移 │ └────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────┐ │ 步骤2：算子验证 —— 实际跑一次前向 │ │ 输入：固定输入张量（GPU 基线同款） │ │ 输出：是否跑通 + 是否报错 │ │ 决策：跑不通则需先解决算子报错 │ └────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────┐ │ 步骤3：精度对齐 —— Hook 脚本 / adc │ │ 输入：GPU 逐层输出 + NPU 逐层输出 │ │ 输出：逐层 cos_sim + max_diff │ │ 决策：cos_sim < 0.999 的层需要定位和修复 │ └────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────┐ │ 步骤4：性能分析 —— msprof + benchmark 脚本 │ │ 输入：完整训练/推理流程 │ │ 输出：算子级耗时分布 + 内存使用 + 通信开销 │ │ 决策：通过 环境变量调优 + 亲和API替换 优化性能 │ └────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────┐ │ 步骤5：输出迁移可行性报告 │ │ 内容： │ │ ├─ 能迁移（所有阻塞项已解决）→ 进入实际迁移 │ │ ├─ 有条件迁移（阻塞项可绕过）→ 列出workaround方案 │ │ └─ 不建议迁移（阻塞项过多或无法绕过）→ 说明原因 │ └────────────────────────────────────────────────────────────┘