华为云用户手册

配置SWR组织权限 IAM 用户创建后，需要管理员在组织中为用户添加授权，使IAM用户对组织内所有镜像享有读取/编辑/管理的权限。 只有具备“管理”权限的账号和IAM用户才能添加授权。 登录 容器镜像服务 控制台。 在左侧菜单栏选择“组织管理”，单击组织名称。 在“用户”页签下单击“添加授权”，在弹出的窗口中为IAM用户选择权限，然后单击“确定”。 SWR授权管理详情可参考授权管理。 如果给子用户的SWR授权不是SWR Admin权限，则需要继续配置SWR组织权限。 父主题： 权限配置

配置ModelArts委托权限 给用户配置ModelArts委托授权，允许ModelArts服务在运行时访问OBS等依赖服务。 使用华为云账号登录ModelArts管理控制台，在左侧导航栏单击“权限管理”，进入“权限管理”页面，单击“添加授权”。 在弹出的“添加授权”窗口中，选择： 授权对象类型：所有用户 委托选择：新增委托 权限配置：普通用户 选择完成后勾选“我已经详细阅读并同意《ModelArts服务声明》”，然后单击“创建”。 图1 配置委托访问授权 完成配置后，在ModelArts控制台的权限管理列表，可查看到此账号的委托配置信息。 图2 查看委托配置信息 父主题： 权限配置

falcon-11B模型 在训练开始前，针对falcon-11B模型中的tokenizer文件，需要替换代码。替换文件{work_dir}/tokenizers/falcon-11B/config.json，具体步骤如下： 复制代码包目录下config.json至falcon-11B的tokenizer目录下，样例命令： 进入到代码目录下{work_dir}/llm_train/LLaMAFactory/ascendcloud_patch/models/falcon2/如： cd /home/ma-user/ws/llm_train/LLaMAFactory/ascendcloud_patch/models/falcon2/ 复制config.json文件至加载的权重文件/tokenizer目录下，参考路径上传代码和权重文件到工作环境中的步骤3。 cp -f config.json {work_dir}/tokenizers/falcon-11B/

模型NPU卡数取值表 不同模型推荐的训练参数和计算规格要求如表1所示。规格与节点数中的1*节点 & 4*Ascend表示单机4卡，以此类推 表1 模型NPU卡数取值表 支持模型 支持模型参数量 文本序列长度 训练类型 Zero并行 规格与节点数 llama3 70B cutoff_len=4096 lora per_device_train_batch_size=1 2*节点 & 8*Ascend sft per_device_train_batch_size=1 8*节点 & 8*Ascend cutoff_len=8192 lora per_device_train_batch_size=1 2*节点 & 8*Ascend sft per_device_train_batch_size=1 8*节点 & 8*Ascend 8B cutoff_len=4096/8192 lora sft per_device_train_batch_size=1 1*节点 & 1*Ascend 1*节点 & 4*Ascend Qwen2 72B cutoff_len=4096 lora sft per_device_train_batch_size=1 2*节点 & 8*Ascend 4*节点 & 8*Ascend cutoff_len=8192 lora sft per_device_train_batch_size=1 2*节点 & 8*Ascend 8*节点 & 8*Ascend 7B cutoff_len=4096 lora/sft per_device_train_batch_size=1 1*节点 & 4*Ascend cutoff_len=8192 lora/sft per_device_train_batch_size=1 1*节点 & 8*Ascend 0.5/1.5B cutoff_len=4096/8192 lora/sft per_device_train_batch_size=1 1*节点 & 1*Ascend Qwen1.5 0.5B/1.8B cutoff_len=4096/8192 lora/sft per_device_train_batch_size=1 1*节点 & 1*Ascend 4B cutoff_len=4096/8192 sft per_device_train_batch_size=1 1*节点 & 4*Ascend cutoff_len=4096/8192 lora per_device_train_batch_size=1 1*节点 & 1*Ascend 7B cutoff_len=4096/8192 lora per_device_train_batch_size=1 1*节点 & 1*Ascend cutoff_len=4096/8192 sft per_device_train_batch_size=1 1*节点 & 8*Ascend 14B cutoff_len=4096/8192 sft per_device_train_batch_size=1 1*节点 & 8*Ascend cutoff_len=4096/8192 lora per_device_train_batch_size=1 1*节点 & 1*Ascend falcon2 11B cutoff_len=4096/8192 sft per_device_train_batch_size=1 1*节点 & 8*Ascend cutoff_len=4096/8192 lora per_device_train_batch_size=1 1*节点 & 1*Ascend Yi 6B cutoff_len=4096/8192 sft per_device_train_batch_size=1 1*节点 & 4*Ascend cutoff_len=4096/8192 lora per_device_train_batch_size=1 1*节点 & 1*Ascend 34B cutoff_len=4096 sft lora per_device_train_batch_size=1 2*节点 & 8*Ascend 1*节点 & 2*Ascend cutoff_len=8192 sft lora per_device_train_batch_size=1 2*节点 & 8*Ascend 1*节点 & 4*Ascend 父主题： 训练脚本说明

各个模型深度学习训练加速框架的选择 LlamaFactory框架使用两种训练框架： DeepSpeed和Accelerate都是针对深度学习训练加速的工具，但是它们的实现方式和应用场景有所不同。 DeepSpeed是一种深度学习加速框架，主要针对大规模模型和大规模数据集的训练。DeepSpeed的核心思想是在单个GPU上实现大规模模型并行训练，从而提高训练速度。DeepSpeed提供了一系列的优化技术，如ZeRO内存优化、分布式训练等，可以帮助用户更好地利用多个GPU进行训练 Accelerate是一种深度学习加速框架，主要针对分布式训练场景。Accelerate的核心思想是通过模型并行和数据并行来实现分布式训练，从而提高训练速度。Accelerate提供了一系列的优化技术，如模型切分、梯度累积等，可以帮助用户更好地利用多个节点进行训练。 各个模型选用加速框架 表1 模型加速框架建议表 序号 模型参数量 文本序列长度 优化工具(Deepspeed&Accelerator) 0 小于4B cutoff_len=4096 Deepspeed-ZeRO-0 cutoff_len=8192 Deepspeed-ZeRO-0 1 小于7B cutoff_len=4096 Deepspeed-ZeRO-1 cutoff_len=8192 Deepspeed-ZeRO-1 2 7B至13B cutoff_len=4096 Deepspeed-ZeRO-2 cutoff_len=8192 Deepspeed-ZeRO-2 3 14B-72B cutoff_len=4096 Deepspeed-ZeRO-3 cutoff_len=8192 Deepspeed-ZeRO-3 以上为建议值，上述参数值仅供参考，如需配置其他加速框架或ZeRO (Zero Redundancy Optimizer)优化器用户可自行选用配置。 父主题： 训练脚本说明

附录：基于vLLM不同模型推理支持最小卡数和最大序列说明 基于vLLM（v0.5.0）部署推理服务时，不同模型推理支持的最小昇腾卡数和对应卡数下的max-model-len长度说明，如下面的表格所示。 以下值是在gpu-memory-utilization为0.9时测试得出，为服务部署所需的最小昇腾卡数及该卡数下推荐的最大max-model-len长度，不代表最佳性能。 以llama2-13b为例，NPU卡显存为32GB时，至少需要2张卡运行推理业务，2张卡运行的情况下，推荐的最大序列max-model-len长度最大是16K，此处的单位K是1024，即16*1024。 测试方法：gpu-memory-utilization为0.9下，以4k、8k、16k递增max-model-len，直至达到能执行静态benchmark下的最大max-model-len。 表1 基于vLLM不同模型推理支持最小卡数和最大序列说明 序号 模型名 32GB显存 64GB显存 最小卡数 最大序列(K) max-model-len 最小卡数 最大序列(K) max-model-len 1 llama-7b 1 16 1 32 2 llama-13b 2 16 1 16 3 llama-65b 8 16 4 16 4 llama2-7b 1 16 1 32 5 llama2-13b 2 16 1 16 6 llama2-70b 8 32 4 64 7 llama3-8b 1 32 1 128 8 llama3-70b 8 32 4 64 9 qwen-7b 1 8 1 32 10 qwen-14b 2 16 1 16 11 qwen-72b 8 8 4 16 12 qwen1.5-0.5b 1 128 1 256 13 qwen1.5-7b 1 8 1 32 14 qwen1.5-1.8b 1 64 1 128 15 qwen1.5-14b 2 16 1 16 16 qwen1.5-32b 4 32 2 64 17 qwen1.5-72b 8 8 4 16 18 qwen1.5-110b -- 8 128 19 qwen2-0.5b 1 128 1 256 20 qwen2-1.5b 1 64 1 128 21 qwen2-7b 1 8 1 32 22 qwen2-72b 8 32 4 64 23 chatglm2-6b 1 64 1 128 24 chatglm3-6b 1 64 1 128 25 glm-4-9b 1 32 1 128 26 baichuan2-7b 1 8 1 32 27 baichuan2-13b 2 4 1 4 28 yi-6b 1 64 1 128 29 yi-9b 1 32 1 64 30 yi-34b 4 32 2 64 31 deepseek-llm-7b 1 16 1 32 32 deepseek-coder-instruct-33b 4 32 2 64 33 deepseek-llm-67b 8 32 4 64 34 mistral-7b 1 32 1 128 35 mixtral-8x7b 4 8 2 32 36 gemma-2b 1 64 1 128 37 gemma-7b 1 8 1 32 38 falcon-11b 1 8 1 64 父主题： 主流开源大模型基于Lite Server适配PyTorch NPU推理指导（6.3.907）

Git下载代码时报错 在执行scripts/install.sh安装命令或使用Dockerfile构建镜像时，如遇到git下载代码出现以下类似的报错信息，关闭git验证即可。 报错信息： fatal: unable to access 'https://gitee.com/ascend/ModelLink.git/': error setting certificate verify locations: CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none 关闭git验证命令如下： git config --global http.sslverify false 父主题： 常见错误原因和解决方法

网卡名称错误 当训练开始时提示网卡名称错误。或者通信超时。可以使用ifconfig命令检查网卡名称配置是否正确。 比如，ifconfig看到当前机器IP对应的网卡名称为enp67s0f5，则可以设置环境变量指定该值。 图1 网卡名称错误 export GLOO_SOCKET_IFNAME=enp67s0f5 # 多机之间使用gloo通信时需要指定网口名称， export TP_SOCKET_IFNAME=enp67s0f5 # 多机之间使用TP通信时需要指定网口名称 export HCCL_SOCKET_IFNAME=enp67s0f5 # 多机之间使用HCCL通信时需要指定网口名称 关于环境变量的解释可以参考：Distributed communication package - torch.distributed — PyTorch 2.3 documentation 父主题： 常见错误原因和解决方法

Yi模型 在使用Yi模型的chat版本时，由于transformer 4.38版本的bug，导致在读取tokenizer文件时，加载的vocab_size出现类似如下尺寸不匹配的问题。 RuntimeError: Error(s) in loading state_dict for VocabParallelEmbedding: size mismatch for weight: copying a param with shape torch.Size([64000, 4096]) from checkpoint, the shape in current model is torch.Size([63992, 4096]). 需要在训练开始前，修改llm_train/AscendSpeed/yi/3_training.sh文件，并添加--tokenizer-not-use-fast参数。修改后如图1所示。 图1 修改Yi 模型3_training.sh文件

ChatGLMv3-6B 在训练开始前，针对ChatGLMv3-6B模型中的tokenizer文件，需要修改代码。修改文件chatglm3-6b/tokenization_chatglm.py 。 文件最后几处代码中需要修改，具体位置可根据上下文代码信息进行查找，修改后如图所示。 图2 修改ChatGLMv3-6B tokenizer文件 图3 修改ChatGLMv3-6B tokenizer文件

ChatGLMv3-6B 在训练开始前，针对ChatGLMv3-6B模型中的tokenizer文件，需要修改代码。修改文件chatglm3-6b/tokenization_chatglm.py 。 文件最后几处代码中需要修改，具体位置可根据上下文代码信息进行查找，修改后如图所示。 图1 修改ChatGLMv3-6B tokenizer文件 图2 修改ChatGLMv3-6B tokenizer文件

Alpaca数据集 本教程使用Alpaca数据集，数据集的介绍及下载链接如下。 Alpaca数据集是由OpenAI的text-davinci-003引擎生成的包含52k条指令和演示的数据集。这些指令数据可以用来对语言模型进行指令调优，使语言模型更好地遵循指令。 预训练使用的Alpaca数据集下载：https://huggingface.co/datasets/tatsu-lab/alpaca/resolve/main/data/train-00000-of-00001-a09b74b3ef9c3b56.parquet，数据大小：24M左右。 SFT和LoRA微调使用的Alpaca数据集下载：https://huggingface.co/datasets/QingyiSi/Alpaca-CoT/blob/main/alpacaGPT4/alpaca_gpt4_data.json，数据大小：43.6 MB。

自定义数据 用户也可以自行准备训练数据。数据要求如下： 使用标准的.json格式的数据，通过设置--json-key来指定需要参与训练的列。请注意huggingface中的数据集具有如下this格式。可以使用–json-key标志更改数据集文本字段的名称，默认为text。在维基百科数据集中，它有四列，分别是id、url、title和text。可以指定–json-key 标志来选择用于训练的列。 { 'id': '1', 'url': 'https://simple.wikipedia.org/wiki/April', 'title': 'April', 'text': 'April is the fourth month...' }

上传数据到指定目录 将下载的原始数据存放在/home/ma-user/ws/training_data目录下。具体步骤如下： 进入到/home/ma-user/ws/目录下。 创建目录“training_data”，并将原始数据放置在此处。 mkdir training_data 数据存放参考目录结构如下： ${workdir}（例如/home/ma-user/ws ） |── training_data |── train-00000-of-00001-a09b74b3ef9c3b56.parquet # 训练原始数据集 |── alpaca_gpt4_data.json # 微调数据文件

附录：大模型推理常见问题 问题1：在推理预测过程中遇到NPU out of memory 解决方法：调整推理服务启动时的显存利用率，将--gpu-memory-utilization的值调小。 问题2：在推理预测过程中遇到ValueError:User-specified max_model_len is greater than the drived max_model_len 解决方法： 修改config.json文件中的"seq_length"的值，"seq_length"需要大于等于 --max-model-len的值。 config.json存在模型对应的路径下，例如：/data/nfs/benchmark/tokenizer/chatglm3-6b/config.json 父主题： 主流开源大模型基于Lite Server适配PyTorch NPU推理指导（6.3.906）

ChatGLMv3-6B 在训练开始前，针对ChatGLMv3-6B模型中的tokenizer文件，需要修改代码。修改文件chatglm3-6b/tokenization_chatglm.py 。 271行要添加注释，修改后如图1所示。 图1 修改ChatGLMv3-6B tokenizer文件（1） 291至300行要修改，修改后如图2所示。 图2 修改ChatGLMv3-6B tokenizer文件（2）

Alpaca数据集 本教程使用Alpaca数据集，数据集的介绍及下载链接如下。 Alpaca数据集是由OpenAI的text-davinci-003引擎生成的包含52k条指令和演示的数据集。这些指令数据可以用来对语言模型进行指令调优，使语言模型更好地遵循指令。 预训练使用的Alpaca数据集下载：https://huggingface.co/datasets/tatsu-lab/alpaca/resolve/main/data/train-00000-of-00001-a09b74b3ef9c3b56.parquet，数据大小：24M左右。 SFT和LoRA微调使用的Alpaca数据集下载：https://huggingface.co/datasets/QingyiSi/Alpaca-CoT/blob/main/alpacaGPT4/alpaca_gpt4_data.json，数据大小：43.6 MB。

上传数据到指定目录 将下载的原始数据存放在/home/ma-user/ws/training_data目录下。具体步骤如下： 进入到/home/ma-user/ws/目录下。 创建目录“training_data”，并将原始数据放置在此处。 mkdir training_data 数据存放参考目录结构如下： ${workdir}（例如/home/ma-user/ws ） |── training_data |── train-00000-of-00001-a09b74b3ef9c3b56.parquet # 训练原始数据集 |── alpaca_gpt4_data.json # 微调数据文件

自定义数据 用户也可以自行准备训练数据。数据要求如下： 使用标准的.json格式的数据，通过设置--json-key来指定需要参与训练的列。请注意huggingface中的数据集具有如下this格式。可以使用–json-key标志更改数据集文本字段的名称，默认为text。在维基百科数据集中，它有四列，分别是id、url、title和text。可以指定–json-key 标志来选择用于训练的列。 { 'id': '1', 'url': 'https://simple.wikipedia.org/wiki/April', 'title': 'April', 'text': 'April is the fourth month...' }

精度调优总体思路 PyTorch大模型训练的精度问题的分析、定位可以参考如下思路： 大模型训练通常使用多机训练，鉴于多机训练复现问题的成本较高，且影响因子较多，建议用户先减少模型层数，使模型能够单机训练，确认单机训练是否也存在精度问题，若存在，则使用下述手段定位精度问题，使得单机精度达标，然后再恢复层数拉起多机训练。 若单机精度正常但多机精度异常，有可能是多机通信造成的精度问题，此时可以用精度工具的通信精度检测功能进行定位。部分集合通信算子要求通信域内各rank结果一致，如AllReduce、AllGather等，利用这一特性，工具将多机模型训练中产生的通信输出存盘，并传输到同一节点来比较其一致性，从而确定模型中通信算子的精度是否存在问题。若已排除通信算子异常，则可能是由于网络层数增加放大了累积误差，需要使用精度比对等工具进一步分析。 图1 精度调优流程 父主题： PyTorch迁移精度调优

训练网络迁移总结 确保算法在GPU训练时，持续稳定可收敛。避免在迁移过程中排查可能的算法问题，并且要有好的对比标杆。如果是NPU上全新开发的网络，请参考PyTorch迁移精度调优排查溢出和精度问题。 理解GPU和NPU的构造以及运行的差别，有助于在迁移过程中分析问题并发挥NPU的优势。由于构造和运行机制的差别，整个迁移过程并非是完全平替，GPU在灵活性上有其独特的优势，而NPU上的执行目前还是依赖于算子的下发，对于NPU构造的理解是昇腾训练迁移中必备的知识，只有对于昇腾有基础理解，配合一些诊断工具，面对复杂问题时，才能进行进一步诊断与定位，进而发挥NPU的能力。 性能调优可以先将重点放在NPU不亲和的问题处理上，确保一些已知的性能问题和优化方法得到较好的应用。通用的训练任务调优、参数调优可以通过可观测数据来进行分析与优化，一般来说分段对比GPU的运行性能会有比较好的参考。算子级的调优某些情况下如果是明显的瓶颈或者性能攻坚阶段，考虑到门槛较高，可以联系华为工程师获得帮助。 精度问题根因和表现种类很多，会导致问题定位较为复杂，一般还是需要GPU上充分稳定的网络（包含混合精度）再到NPU上排查精度问题。常见的精度调测手段，包含使用全精度FP32，或者关闭算子融合开关等，先进行排查。对于精度问题，系统工程人员需要对算法原理有较深入的理解，仅从工程角度分析有时候会非常受限，同时也可联系华为工程师进行诊断与优化。 父主题： GPU训练业务迁移至昇腾的通用指导

性能调优总体原则和思路 PyTorch在昇腾AI处理器的加速实现方式是以算子为粒度进行调用（OP-based），即通过Python与C++调用CANN层接口Ascend Computing Language（AscendCL）调用一个或几个亲和算子组合的形式，代替原有GPU的实现方式，具体逻辑模型请参考PyTorch自动迁移。 在PyTorch模型迁移后进行训练的过程中，CPU只负责算子的下发，而NPU负责算子的执行，算子下发和执行异步发生，性能瓶颈在此过程中体现。在PyTorch的动态图机制下，算子被CPU逐个下发到NPU上执行。一方面，理想情况下CPU侧算子下发会明显比NPU侧算子执行更快，此时性能瓶颈主要集中在NPU侧；另一方面，理想情况下NPU侧算子计算流水线一直执行，不会出现NPU等待CPU算子下发即NPU空转的场景，如果存在，则CPU侧算子下发存在瓶颈。 图1 Host算子下发和Device算子执行 综上所述，性能优化的总体原则为：减少Host算子下发时间、减少Device算子执行时间。 训练代码迁移完成后，如存在性能不达标的问题，可参考下图所示流程进行优化。建议按照单卡、单机多卡、多机多卡的流程逐步做性能调优。 图2 性能调优总体思路 为了便于用户快速进行迁移调优，降低调优门槛，ModelArts提供了MA-Adivisor性能自动诊断工具。用户采集性能profiling数据后，可通过该工具自动扫描profiling数据，工具分析完数据后会给出可能的性能问题点及调优建议，用户可以根据调优建议做相应的修改适配。目前该工具对CV类模型给出的调优建议较多，LLM类建议稍少，但是总体都有性能提升，实测大约可提升10%~30%的性能，并且已经在多个迁移性能调优项目中实际应用。 父主题： PyTorch迁移性能调优

训练代码迁移 前提条件 要迁移的训练任务代码在GPU上多次训练稳定可收敛。训练业务代码和数据，应该确保在GPU环境中能够运行，并且训练任务有稳定的收敛效果。 本文只针对基于PyTorch的训练代码迁移。此处假设用户使用基于PyTorch的训练代码进行迁移。其他的AI引擎如TensorFlow、Caffe等不在本指导的讨论范围中。 已完成迁移环境准备，且代码、预训练模型、数据等训练必需内容已经上传到环境中。 约束和限制 安装插件后，大部分能力能够对标在GPU上的使用，但并不是所有行为和GPU上是一一对应的。例如在torch_npu下，当PyTorch版本低于2.1.0时，一个进程只能操作一张昇腾卡，不支持一个进程操作多卡的能力；在PyTorch2.1.0及以上版本中torch_npu才支持一个进程中使用多张昇腾卡。 基于PyTorch上的第三方开发库非常多，例如transformers、accelerate、deepspeed以及Megatron-LM等，这些三方库昇腾也做了类似PyTorch Adapter的适配插件库。您可以在Gitee的昇腾官方仓库按需使用插件库。部分三方库例如最新版本deepspeed已原生支持NPU，可以直接在昇腾设备上运行。 代码迁移基础知识 PyTorch 2.1以下版本时，PyTorch官方并不直接支持昇腾的后端，仅直接支持CUDA和AMD ROCm，因此PyTorch在GPU上的训练代码无法直接在昇腾设备运行。PyTorch 2.1版本提供了新硬件适配的插件机制，通过昇腾提供的Ascend Extension for PyTorch插件，NPU可以成为PyTorch支持的硬件直接使用。 Ascend Extension for PyTorch作为一个PyTorch插件，支持在不改变PyTorch表达层的基础上，动态添加昇腾后端适配，包含增加了NPU设备、hccl等一系列能力的支持。安装后可以直接使用PyTorch的表达层来运行在NPU设备上。 当前提供了自动迁移工具进行GPU到昇腾适配，原理是通过monkey-patch的方式将torch下的CUDA、nccl等操作映射为NPU和hccl对应的操作。如果没有用到GPU的高阶能力，例如自定义算子、直接操作GPU显存等操作，简单场景下可以直接使用自动迁移。 图1 torch_npu工作原理示意图 NPU（Neural Network Processing Unit）和GPU在构造结构上存在差异，因此迁移过程并不是完全平替的关系。昇腾训练芯片属于NPU的范畴，虽然在表达层可以通过torch.cuda和torch.npu的形式来替代，但是真实的算子下发、显存管理、集合通信等存在差异，用户需要了解NPU的运行机制才能更好的使用NPU设备，同时在遇到问题时快速找到原因。 代码迁移操作步骤 在训练任务启动的Python脚本入口初始化Ascend Extension for PyTorch（torch_npu）。 在torch_npu安装后，该部分并没有直接植入到PyTorch中生效，需要用户显式调用。 # torch npu初始化。 import torch_npu 调用后，前端会通过monkey-patch的方式注入到torch对象中，后端会注册NPU设备以及HCCL的参数面通信能力，这样就可以运行torch.npu相关接口。 图2 torch_npu导入 自动迁移完成GPU代码到昇腾的快速适配。 torch_npu初始化后，原则上需要用户将原来代码中CUDA相关的内容迁移到NPU相关的接口上，包含算子API、显存操作、数据集操作、分布式训练的参数面通信nccl等，手动操作修改点较多且较为分散，因此昇腾提供了自动迁移工具transfer_to_npu帮助用户快速迁移。 自动迁移的原理是：通过注入的方式将当前Python运行环境中，运行时的torch.cuda等需要适配的接口和操作都映射成为torch.npu对应的接口。所以理论上常见场景下的代码不需要额外手工适配就可以运行到昇腾设备上。 # 自动映射cuda API到NPU的代码。 from torch_npu.contrib import transfer_to_npu 图3 自动迁移后cuda映射为NPU相关的API 以chatGLM-6b为例，在使用自动迁移时，在开发环境中克隆对应的代码。假设数据和预训练权重已经配置好，可以直接在ptuning目录下，训练入口代码main.py中添加两行代码来完成昇腾适配。请注意添加位置为导入torch之后。启动训练脚本可以观察运行效果。 图4 chatGLM-6b pTuning训练入口导入自动迁移工具 自动迁移适合没有使用CUDA高阶能力的简单场景，如果涉及自定义算子、主动申请GPU显存等操作，则需要额外进行手动迁移适配。 手动迁移解决报错问题。 在完成代码自动迁移后，如果训练代码运行时还出现错误，则代表需要手动迁移适配。针对代码报错处，需要用户分析定位后将自动迁移未能迁移的GPU相关的代码调用修改为NPU对应的接口，请参考昇腾手工迁移文档进行操作。 常见问题 如何检测当前的torch_npu是否正确安装？ 您可以使用如下的python命令在对应的运行环境中初步校验torch_npu是否正常安装。 python3 -c "import torch;import torch_npu;print(torch_npu.npu.is_available())" torch_npu使用报错看不懂怎么办？应该怎么求助？ 如果报错可以首先在昇腾社区论坛以及Gitee的PyTorch Issues中查看是否有类似的问题找到相关线索。如果还无法解决，可以通过提交工单的形式从华为云ModelArts入口进行咨询以及求助对应的专业服务。 自动迁移似乎还要改很多脚本才能运行起来？ 因为自动迁移其实是对于torch运行环境中常用的GPU上的接口进行和昇腾设备的映射。原有的训练任务代码逻辑中例如数据集导入、预训练权重、GPU自定义算子的内容，以及对应的环境的超参数等内容都需要在实际的昇腾环境中进行调整。

场景介绍 本小节通过一个具体问题案例，介绍模型精度调优的过程。 如下图所示，使用MindSpore Lite生成的图像和onnx模型的输出结果有明显的差异，因此需要对MindSpore Lite pipeline进行精度诊断。 图1 结果对比 在MindSpore Lite 2.0.0版本中，Stable Diffusion的五个模型的精度都能够保证一致性，但是在最新的2.1.0版本中，会出现text_encoder模型精度不一致的情况。该问题后续会发布补丁进行修复。 父主题： 模型精度调优

常见问题 模型转换失败怎么办？ 常见的模型转换失败原因可以通过查询转换失败错误码来确认具体导失败的原因。Stable Diffusion新推出的模型在转换中可能会遇到算子不支持的问题，您可以到华为云管理页面上提交工单来寻求帮助。 图片大Shape性能劣化严重怎么办？ 在昇腾设备上，可能由于GPU内存墙导致在大shape下遇到性能问题。MindSporeLite提供了Flash Attention编译优化机制，您可以考虑升级最新版本的MindSporeLite Convertor来进行编译器的算子优化，在大Shape场景下会有明显的改善。 同样功能的PyTorch Pipeline，因为指导要求适配onnx pipeline，两个pipeline本身功能就有差别，如何适配？ 由于Diffusers社区的“single model file policy”设计原则，不同的pipeline是不同路径在独立演进的。请先确保应用输出符合预期后，再进入到MindSpore Lite模型转换的过程，否则迁移昇腾后还是会遇到同样的问题。 AOE的自动性能调优使用上完全没有效果怎么办？ 在MindSpore Lite Convertor2.1版本之前可能出现的调优不生效的场景，建议您直接使用MindSpore Lite Convertor2.1及以后的版本。配置文件指定选项进行AOE调优。使用转换工具配置config参数，具体如下所示，其中“subgraph tuning”表示子图调优，“operator tuning”表示算子调优。 其中，“ge.op_compiler_cache_mode”在该场景下必须设置为“force”，表示该场景下要强制刷新缓存，保证AOE调优后的知识库能够命中，实现模型调优。 # config.ini [ascend_context] aoe_mode="subgraph tuning, operator tuning" [acl_init_options] ge.op_compiler_cache_mode="force" 迁移后应用出图效果相比GPU无法对齐怎么办？ 扩散模型在噪音和随机数上的生成，本身就有一定的随机性，GPU和NPU（Ascend）硬件由于存在一定细小的差别，很难确保完全一致，较难达成生成图片100%匹配，建议通过盲测的方式对效果进行验证。 模型精度有问题怎么办？ 首先考虑通过FP16的方式进行转换和执行，再通过精度诊断工具来进行分析，更进一步可以到华为云官网上提交工单处理。 模型转换失败时如何查看日志和定位原因？ 在模型转换的过程，如果出现模型转换失败，可以参考以下步骤查看日志并定位原因： 设置DEBUG日志。 设置MindSpore日志环境变量。 # shell export G LOG _v=0 # 0-DEBUG、1-INFO、2-WARNING、3-ERROR 设置CANN日志环境变量。 # shell export ASCEND_GLOBAL_LOG_LEVEL=1 # 0：表示DEBUG、1：表示INFO、2：表示WARNING、3：表示ERROR 4: 表示NONE export ASCEND_SLOG_PRINT_TO_STDOUT=1 # 表示日志打印。 设置DUMP模型转换中间图。 设置DUMP中间图环境变量。 # shell export DUMP_GE_GRAPH=2 # 1：表示dump图全量内容。 2：表示不dump权重数据的基础图。 3：表示只dump节点关系的精简图。 export DUMP_GRAPH_LEVEL=2 # 1：表示dump图所有图。 2：表示dump除子图外的所有图。 3：表示只dump最后一张图。 问题分析。 配置以上的环境变量之后，再重新转换模型，导出对应的日志和dump图进行分析： 报错日志中搜到“not support onnx data type”，表示MindSpore暂不支持该算子。 报错日志中搜到“Convert graph to om failed”，表示CANN模块进行图编译存在保存，需要结合CANN的报错日志和dump图进行具体分析。 Stable Diffusion WebUI如何适配？ WebUI一般可以分为前端和后端实现两部分，后端的实现模式种类多样，并且依赖了多个的第三方库，当前在WebUI适配时，并没有特别好的方式。在对后端实现比较理解的情况下，建议针对具体的功能进行Diffusers模块的适配与替换，然后针对替换上去的Diffusers，对其pipeline进行昇腾迁移适配，进而替代原有WebUI的功能。针对很多参数以及三方加速库（如xformers）的适配，当前没有特别好的处理方案。 LoRA适配流是怎么样的？ 因为现在PyTorch-npu推理速度比较慢（固定shape比mindir慢4倍），在现在pth-onnx-mindir的模型转换方式下，暂时只能把lora合并到unet主模型内，在每次加载模型前lora特性就被固定了（无法做到PyTorch每次推理都可以动态配置的能力）。 目前临时的静态方案可参考sd-scripts， 使用其中的“networks/merge_lora.py”把lora模型合入unet和text-encoder模型。 数据类型不匹配问题如何处理？ 报错“data type not equal”时，按照堆栈信息，将对应的行数的数据类型修改为匹配的类型。 图1 报错信息 处理该问题时，pipeline_onnx_stable_diffusion_img2img_mslite.py文件的第454行修改如下： 图2 修改内容 父主题： 基于AIGC模型的GPU推理业务迁移至昇腾指导

设置高精度并重新转换模型 在转换模型时，默认采用的精度模式是fp16，如果转换得到的模型和标杆数据的精度差异比较大，可以使用fp32精度模式提升模型的精度（精度模式并不总是需要使用fp32，因为相对于fp16，fp32的性能较差。因此，通常只在检测到某个模型精度存在问题时，才会考虑是否使用fp32进行尝试）。使用fp32精度模式的配置文件如下： 配置文件： # config.ini [ascend_context] precision_mode=enforce_fp32 # 使用fp32。

逐个替换模型，检测有问题的模型 该方式主要是通过模型替换，先定位出具体哪个模型引入的误差，进一步诊断具体的模型中哪个算子或者操作导致效果问题，模型替换原理如下图所示。通过设置开关选项（是否使用onnx模型），控制模型推理时，模型使用的是onnx模型或是mindir的模型。 图1 精度诊断流程 一般情况下，onnx模型推理的结果可以认为是标杆数据，单独替换某个onnx模型为MindSpore Lite模型，运行得到的结果再与标杆数据做对比，如果没有差异则说明pipeline的差异不是由当前替换的MindSpore Lite模型引入。 如果有差异，则说明当前模型与原始onnx的结果存在差异。依次单独替换onnx模型为对应的MindSpore Lite模型，从而定位出有差异的模型。在模型初始化的代码块已经添加了use_ascend参数，修改参考如下： 图2 代码修改 以上述现象为例，通过修改use_ascend参数值对模型替换，可以发现：当text_encoder模型为onnx模型，其余模型为mindir模型时，能够得到和标杆数据相同的输出，因此可以判断出转换得到的text_encoder模型是产生pipeline精度误差的根因。通过下一小节可以进一步确认模型精度的差异。

pipeline应用准备 当前迁移路径是从ONNX模型转换到MindIR模型，再用MindSpore Lite做推理， 所以迁移前需要用户先准备好自己的ONNX pipeline。下文以官方开源的图生图的Stable Diffusion v1.5的onnx pipeline代码为例进行说明。 进入容器环境，创建自己的工作目录。 由于在Snt9B裸金属服务器环境配置指南的配置环境步骤中，在启动容器时将物理机的home目录挂载到容器的“/home_host”目录下，该目录可以直接使用上传到物理机“home”目录下的文件。本文中，将基于容器的“/home_host”目录创建工作目录。 mkdir -p /home_host/work cd /home_host/work 在迁移onnx pipeline前，首先需要确保原始的onnx pipeline能在昇腾机器的ARM CPU上正常执行。进入容器环境后，安装依赖包。 pip install torch==1.11.0 onnx transformers==4.27.4 accelerate onnxruntime diffusers==0.11.1 下载git lfs，用于下载git仓中的大文件。 由于欧拉源上没有git-lfs包，所以需要从压缩包中解压使用，在浏览器中输入如下地址下载git-lfs压缩包并上传到服务器的/home目录。 https://github.com/git-lfs/git-lfs/releases/download/v3.2.0/git-lfs-linux-arm64-v3.2.0.tar.gz 安装git lfs。 tar -zxvf git-lfs-linux-arm64-v3.2.0.tar.gz cd git-lfs-3.2.0 sh install.sh rm -rf git-lfs-linux-arm64-v3.2.0.tar.gz git-lfs-3.2.0 通过git下载sd PyTorch模型。 该模型用于获取模型shape，也可以转换生成onnx模型。后文中的modelarts-ascend仓库已经给出了模型shape，可以直接使用，onnx模型也可以单独下载。 # git clone sd模型。 git lfs install mkdir -p /home_host/work/runwayml cd /home_host/work/runwayml git clone https://huggingface.co/runwayml/stable-diffusion-v1-5/ -b main # 将下载的文件夹重命名，以便后续脚本中引用。 mv stable-diffusion-v1-5 pytorch_models 此处由于Huggingface网站的限制以及模型文件的大小原因，很可能会下载失败。您可以登录Huggingface网站，从浏览器下载模型后，再手动上传到物理机/home/pytorch_models目录下。 通过git下载sd onnx模型。 # git clone sd模型。 git lfs install cd /home_host/work/runwayml git clone https://huggingface.co/runwayml/stable-diffusion-v1-5 -b onnx # 将下载的文件夹重命名，以便后续脚本中引用。 mv stable-diffusion-v1-5 onnx_models 此处由于Huggingface网站的限制以及模型文件的大小原因，很可能会下载失败。您可以登录Huggingface网站，从浏览器下载模型后，再手动上传到物理机/home/onnx_models目录下。 下载好模型后，需要编写推理脚本。为了便于操作，本指导中所需的代码已发布在ModelArts代码仓，可以使用如下命令下载推理脚本样例代码： cd /home_host/work git clone https://gitee.com/ModelArts/modelarts-ascend.git ll modelarts-ascend/examples/AIGC/stable_diffusion 代码目录如下图所示，onnx_pipeline.py是图生图推理脚本。mslite_pipeline.py、mslite_model_proxy.py、pipeline_onnx_stable_diffusion_img2img_mslite.py是迁移后的文件，其中mslite_model_proxy.py是代理模型类，pipeline_onnx_stable_diffusion_img2img_mslite.py是从Stable Diffusion源码中的pipeline复制并修改的，这些文件在后续的章节中会使用并进一步介绍。 图1 代码目录 将“modelarts-ascend/examples/AIGC/stable_diffusion/onnx_pipeline.py”文件中的“onnx_model_path”改为步骤6中下载的onnx_models地址“/home_host/work/runwayml/onnx_models”。执行推理脚本进行测试，此处使用的推理硬件是CPU。由于CPU执行较慢，验证待迁移的代码可能需要大约15分钟左右才能完成。 cd modelarts-ascend/examples/AIGC/stable_diffusion # 必须执行该命令，否则会报错找不到sketch-mountains-input.jpg python onnx_pipeline.py 生成的图片fantasy_landscape.png会保存在当前路径下，该图片也可以作为后期精度校验的一个对比。 图2 生成图片 父主题： 基于AIGC模型的GPU推理业务迁移至昇腾指导

场景介绍 阅读本文前建议您先了解以下内容： Stable Diffusion的基础知识，可参考Stable Diffusion github、Stable Diffusion wikipedia、diffusers github、Stable Diffusion with diffusers。 推理业务迁移到昇腾的通用流程，可参考GPU推理业务迁移至昇腾的通用指导。 由于Huggingface网站的限制，访问Stable Diffusion链接时需使用代理服务器，否则可能无法访问网站。 在Stable Diffusion迁移适配时，更多的时候是在适配Diffusers和Stable Diffusion WebUI，使其能够在昇腾的设备上运行。其中，Diffusers遵循了Huggingface的“single-file policy”的设计原则，它的三个主要模块Pipeline、Schedulers和预训练模型中，Pipeline和Schedulers都完全遵循了“single-file policy”原则。该设计原则更推荐直接复制粘贴代码，而不是进行抽象处理。因此，与模型前向运算相关的所有源代码都被直接复制粘贴到同一个文件中，而不是调用某些抽象提取出的模块化库。Diffusers的这种设计原则的好处是代码简单易用、对代码贡献者友好。然而，这种反软件结构化的设计也有明显的缺点。由于缺乏统一的模块化库，对于昇腾适配而言变得更加复杂，必须针对每个不同业务的Pipeline进行单独适配。 本文以Stable Diffusion v1.5的图生图为例，通过可以直接执行的样例代码介绍Diffusers的昇腾迁移过程。对于其他pipeline的迁移，可以在充分理解其代码的基础上，参考本文的思路进行举一反三。Stable Diffusion WebUI的迁移不包含在本文中，具体原因详见Stable Diffusion WebUI如何适配。 AI推理应用运行在昇腾设备上一般有两种方式： 方式1：通过Ascend PyTorch，后端执行推理，又称在线推理。 方式2：通过模型静态转换后，执行推理，又称离线推理。 通常为了获取更好的推理性能，推荐使用方式2的离线推理。下文将以Diffusers img2img onnx pipeline为示例来讲解如何进行离线推理模式下的昇腾迁移。迁移的整体流程如下图所示： 图1 迁移流程图 父主题： 基于AIGC模型的GPU推理业务迁移至昇腾指导

准备Notebook ModelArts Notebook云上云下，无缝协同，更多关于ModelArts Notebook的详细资料请查看Notebook使用场景介绍。本案例中使用ModelArts的开发环境Notebook部署推理服务进行调试，请按照以下步骤完成Notebook的创建。 登录ModelArts控制台，在贵阳一区域，进入开发环境的Notebook界面，单击右上角“创建”，创建一个开发环境。创建Notebook的详细介绍可以参考创建Notebook实例，此处仅介绍关键步骤。 创建Notebook时，选择自定义镜像，并选择Step8 注册镜像章中注册的镜像。 图1 选择自定义镜像 资源类型推荐使用专属资源池，规格选到Ascend snt9b，显存规格建议选择64G以上的规格，磁盘规格建议选择500GB及以上。 创建完Notebook后，待Notebook状态变为“运行中”时，打开Notebook，可参考后续章节在Notebook调试环境中部署推理服务。 父主题： 准备工作