华为云用户手册

自定义数据 用户也可以自行准备训练数据。数据要求如下： 使用标准的.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...' }

模型软件包结构说明 AscendCloud-3rdLLM代码包结构介绍如下： |──llm_train # 模型训练代码包 |──AscendSpeed # 基于AscendSpeed的训练代码 |──ascendcloud_patch/ # 针对昇腾云平台适配的功能补丁包 |──scripts/ # 训练需要的启动脚本 |──llama2 # llama2系列模型执行脚本的文件夹 |──llama3 # llama3系列模型执行脚本的文件夹 |──qwen # Qwen系列模型执行脚本的文件夹 |──qwen1.5 # Qwen1.5系列模型执行脚本的文件夹 |── ... |── dev_pipeline.sh # 系列模型共同调用的多功能的脚本 |── install.sh # 环境部署脚本 |──llm_inference # 推理代码包 |──llm_tools # 推理工具

上传代码和权重文件到工作环境 使用root用户以SSH的方式登录DevServer。 将AscendCloud代码包AscendCloud-3rdLLM-xxx-xxx.zip上传到${workdir}目录下并解压缩，如：/home/ma-user/ws目录下，以下都以/home/ma-user/ws为例，请根据实际修改。 unzip AscendCloud-3rdLLM-*.zip 上传代码之后需要修改llm_train/AscendSpeed/scripts/install.sh文件。具体为删除install.sh 的第43行 "git cherrypick 171ba0b3"。该问题会导致代码安装失败，会在后续版本修复。 上传tokenizers文件到工作目录中的/home/ma-user/ws/tokenizers/Llama2-{MODEL_TYPE}目录，如Llama2-70B。 具体步骤如下： 进入到${workdir}目录下，如：/home/ma-user/ws，创建tokenizers文件目录将权重和词表文件放置此处，以Llama2-70B为例。 cd /home/ma-user/ws mkdir -p tokenizers/Llama2-70B

工作目录介绍 详细的工作目录参考如下，建议参考以下要求设置工作目录。训练脚本以分类的方式集中在 scripts 文件夹中。 ${workdir}（例如/home/ma-user/ws ） |──llm_train #解压代码包后自动生成的代码目录，无需用户创建 |── AscendSpeed # 代码目录 |──ascendcloud_patch/ # 针对昇腾云平台适配的功能代码包 |──scripts/ # 各模型训练需要的启动脚本，训练脚本以分类的方式集中在scripts文件夹中。 # 数据目录结构 |── processed_for_input #目录结构会自动生成，无需用户创建 |── ${model_name} # 模型名称 |── data # 预处理后数据 |── pretrain # 预训练加载的数据 |── finetune # 微调加载的数据 |──converted_weights # HuggingFace格式转换megatron格式后权重文件 |── saved_dir_for_output # 训练输出保存权重，目录结构会自动生成，无需用户创建 |── ${model_name} # 模型名称 |── logs # 训练过程中日志（loss、吞吐性能） |—— saved_models |── lora # lora微调输出权重 |── sft # 增量训练输出权重 |── pretrain # 预训练输出权重 |── tokenizers #原始权重及tokenizer目录，需要用户手动创建，后续操作步骤中会提示 |── Llama2-70B |── training_data #原始数据目录，需要用户手动创建，后续操作步骤中会提示 |── train-00000-of-00001-a09b74b3ef9c3b56.parquet #原始数据文件 |── alpaca_gpt4_data.json #微调数据文件

获取模型软件包和权重文件 本方案支持的模型对应的软件和依赖包获取地址如表1所示，模型列表、对应的开源权重获取地址如表2所示。 表1 模型对应的软件包和依赖包获取地址 代码包名称 代码说明 下载地址 AscendCloud-3rdLLM-6.3.905-xxx.zip 说明： 软件包名称中的xxx表示时间戳。 包含了本教程中使用到的模型训练代码、推理部署代码和推理评测代码。代码包具体说明请参见模型软件包结构说明。 AscendSpeed是用于模型并行计算的框架，其中包含了许多模型的输入处理方法。 获取路径：Support-E 请联系您所在企业的华为方技术支持下载获取。 表2 支持的模型类型和权重获取地址 序号 支持模型 支持模型参数量 权重文件获取地址 1 llama2 llama2-7b https://huggingface.co/meta-llama/Llama-2-7b-chat-hf 2 llama2-13b https://huggingface.co/meta-llama/Llama-2-13b-chat-hf 3 llama2-70b https://huggingface.co/meta-llama/Llama-2-70b-hf https://huggingface.co/meta-llama/Llama-2-70b-chat-hf (推荐) 4 llama3 llama3-8b https://huggingface.co/meta-llama/Meta-Llama-3-8B-Instruct 5 llama3-70b https://huggingface.co/meta-llama/Meta-Llama-3-70B-Instruct 6 Qwen qwen-7b https://huggingface.co/Qwen/Qwen-7B-Chat 7 qwen-14b https://huggingface.co/Qwen/Qwen-14B-Chat 8 qwen-72b https://huggingface.co/Qwen/Qwen-72B-Chat 9 Qwen1.5 qwen1.5-7b https://huggingface.co/Qwen/Qwen1.5-7B-Chat 10 qwen1.5-14b https://huggingface.co/Qwen/Qwen1.5-14B-Chat 11 qwen1.5-32b https://huggingface.co/Qwen/Qwen1.5-32B-Chat 12 qwen1.5-72b https://huggingface.co/Qwen/Qwen1.5-72B-Chat 13 Yi yi-6b https://huggingface.co/01-ai/Yi-6B-Chat 14 yi-34b https://huggingface.co/01-ai/Yi-34B-Chat 15 ChatGLMv3 glm3-6b https://huggingface.co/THUDM/chatglm3-6b 16 Baichuan2 baichuan2-13b https://huggingface.co/baichuan-inc/Baichuan2-13B-Chat

操作流程 图1 操作流程图 表2 操作任务流程说明 阶段 任务 说明 准备工作 准备环境 本教程案例是基于ModelArts Lite DevServer运行的，需要购买并开通DevServer资源。 准备代码 准备AscendSpeed训练代码、分词器Tokenizer和推理代码。 准备数据 准备训练数据，可以用本案使用的数据集，也可以使用自己准备的数据集。 准备镜像 准备训练模型适用的容器镜像。 预训练 预训练 介绍如何进行预训练，包括训练数据处理、超参配置、训练任务、断点续训及性能查看。 微调训练 SFT全参微调 介绍如何进行SFT全参微调。 LoRA微调训练 介绍如何进行LoRA微调训练。

训练支持的模型列表 本方案支持以下模型的训练，如表1所示。 表1 支持的模型 序号 支持模型 支持模型参数量 1 llama2 llama2-7b 2 llama2-13b 3 llama2-70b 4 llama3 llama3-8b 5 llama3-70b 6 Qwen qwen-7b 7 qwen-14b 8 qwen-72b 9 Qwen1.5 qwen1.5-7b 10 qwen1.5-14b 11 qwen1.5-32b 12 qwen1.5-72b 13 Yi yi-6b 14 yi-34b 15 ChatGLMv3 glm3-6b 16 Baichuan2 baichuan2-13b

场景介绍 本小节通过一个具体问题案例，介绍模型精度调优的过程。 如下图所示，使用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推理业务迁移至昇腾指导

单模型性能测试工具Mindspore lite benchmark 在模型精度对齐后，针对Stable Diffusion模型性能调优，可以通过AOE工具进行自助性能调优，进一步可以通过profiling工具对于性能瓶颈进行分析，并针对性的做一些调优操作。 可以直接使用benchmark命令测试mindir模型性能，用来对比调优前后性能是否有所提升。 # shell cd /home_host/work benchmark --modelFile=diffusers/scripts/mindir_models/text_encoder.mindir --device=Ascend 上述命令中：modelFile指定生成的mindir模型文件；device指定运行推理的设备。其他用法参考benchmark文档。 测试结果如下所示： 图1 测试结果 父主题： 性能调优

设置高精度并重新转换模型 在转换模型时，默认采用的精度模式是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精度误差的根因。通过下一小节可以进一步确认模型精度的差异。

模型推理适配 完成模型初始化后，需要将onnx模型推理的代码等价替换为对应的mindir模型推理接口。以vae_encoder模型为例，在pipeline代码中查找vae_encoder推理调用的地方，然后修改为对应的MindSpore Lite版本的推理接口模型。 使用MindSpore Lite Runtime接口替换onnx Runtime接口 # pipeline_onnx_stable_diffusion_img2img_mslite.py … # onnx模型 # init_latents = self.vae_encoder(sample=image)[0] # ----------------修改点----------------- # mslite模型 init_latents = self.vae_encoder_ms(sample=image)[0] ... 替换内嵌模型 # pipeline_onnx_stable_diffusion_img2img_mslite.py … # onnx模型 # image = np.concatenate([self.vae_decoder(latent_sample=latents[i : i + 1])[0] for i in range(latents.shape[0])]) # ----------------修改点----------------- # mslite模型 image = np.concatenate([self.vae_decoder_ms(latent_sample=latents[i : i + 1])[0] for i in range(latents.shape[0])]) ... 修改后的文件参考Gitee代码库中的如下两个文件： pipeline_onnx_stable_diffusion_img2img_mslite.py mslite_model_proxy.py

运行pipeline代码 pipeline代码如下： # mslite_pipeline.py import os import requests import torch import numpy as np from PIL import Image from io import BytesIO from pipeline_onnx_stable_diffusion_img2img_mslite import OnnxStableDiffusionImg2ImgPipeline def setup_seed(seed): torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) np.random.seed(seed) torch.backends.cudnn.deterministic = True setup_seed(0) # 指定mindir和onnx模型路径 mindir_dir = "/home_host/work/static_shape_convert/mindir_models" onnx_model_path = "/home_host/work/runwayml/onnx_models" os.environ['DEVICE_ID'] = "0" os.environ['TEXT_ENCODER_PATH'] = f"{mindir_dir}/text_encoder.mindir" os.environ['VAE_ENCODER_PATH'] = f"{mindir_dir}/vae_encoder.mindir" os.environ['UNET_PATH'] = f"{mindir_dir}/unet_graph.mindir" os.environ['VAE_DECODER_PATH'] = f"{mindir_dir}/vae_decoder.mindir" os.environ['SAFETY_CHECKER_PATH'] = f"{mindir_dir}/safety_checker.mindir" pipe = OnnxStableDiffusionImg2ImgPipeline.from_pretrained(onnx_model_path, torch_dtype=torch.float32).to("cpu") url = "https://raw.githubusercontent.com/CompVis/stable-diffusion/main/assets/stable-samples/img2img/sketch-mountains-input.jpg" response = requests.get(url, verify=False) init_image = Image.open(BytesIO(response.content)).convert("RGB") init_image = init_image.resize((512, 512)) prompt = "A fantasy landscape, trending on artstation" images = pipe(prompt=prompt, image=init_image, strength=0.75, guidance_scale=7.5).images images[0].save("fantasy_landscape_npu.png") 在运行pipeline时，默认的加速卡为0号卡，当机器有多人使用时，可能存在资源占用而无法正常运行的情况，可以通过环境变量指定加速卡ID，如指定5号卡进行执行。 # mslite_pipeline.py … os.environ['DEVICE_ID'] = "5" … 最后执行python脚本进行推理： #shell python mslite_pipeline.py 图2 执行推理脚本 图3 MindSpore Lite pipeline输出的结果图片

修改代码依赖 新建并进入/home_host/work/pipeline目录。 mkdir -p /home_host/work/pipeline cd /home_host/work/pipeline 将onnx pipeline依赖的图生图源码“pipeline_onnx_stable_diffusion_img2img.py”复制到该目录下，名称改为“pipeline_onnx_stable_diffusion_img2img_mslite.py”，以便与源文件名称区分。但是这样也会导致无法正确找到源码中相对路径下的依赖，需要将对于diffusers包内的相对路径修改为绝对路径的形式。 图1 代码依赖修改前与修改后 将推理代码“modelarts-ascend/examples/AIGC/stable_diffusion/onnx_pipeline.py”也复制一份到该目录，名称改为“mslite_pipeline.py”，迁移后的推理代码中的pipeline需要修改为从复制的onnx pipeline文件导入： # onnx_pipeline.py from pipeline_onnx_stable_diffusion_img2img_mslite import OnnxStableDiffusionImg2ImgPipeline

静态shape模型转换 转换静态shape模型需要在模型转换阶段固定模型的输入shape，也就是说每个输入shape是唯一的。静态shape转换主要包括两种场景： 第一种是待转换onnx模型的输入本身已经是静态shape，此时不需要在转换时指定输入shape也能够正常转换为和onnx模型输入shape一致的mindir模型。 第二种是待转换onnx模型的输入是动态shape（导出onnx模型时指定了dynamic_axes参数），此时需要在转换时明确指定输入的shape。 转换时指定输入shape可以在命令行中指定，也可以通过配置文件的形式进行指定。 在命令行中指定输入shape。 命令行可以直接通过--inputShape参数指定输入的shape，格式为“input_name:input_shape”，如果有多个输入，需要使用“;”隔开，比如“input1_name:input1_shape;input2_name:input2_shape”。 converter_lite --modelFile=./text_encoder/model.onnx --fmk=ONNX --saveType=MINDIR --optimize=ascend_oriented --outputFile=./text_encoder --inputShape="input_ids:1,77" 在配置文件中指定输入shape。 配置文件中通过“[ascend_context]”配置项指定input_shape，格式与命令行一致，多个输入，需要使用“;”隔开；然后在命令行中通过--configFile指定对应的配置文件路径即可。 # text_encoder.ini [ascend_context] input_shape=input_ids:[1,77] 转换命令如下： converter_lite --modelFile=./text_encoder/model.onnx --fmk=ONNX --saveType=MINDIR --optimize=ascend_oriented --outputFile=./text_encoder --configFile=./text_encoder.ini 在使用converter_lite工具转换时，默认是将所有算子的精度转换为fp16，如果想要将固定shape的模型精度修改为fp32进行转换，需要在配置文件中指定算子的精度模式为precision_mode，配置文件的写法如下（更多精度模式请参考precision_mode）： # text_encoder.ini [ascend_context] input_shape=input_ids:[1,77] precision_mode=enforce_fp32 对于本次AIGC迁移，为了方便对多个模型进行转换，可以通过批量模型转换脚本自动完成所有模型的转换。 执行以下命令创建并进入static_shape_convert目录。 mkdir -p /home_host/work/static_shape_convert cd /home_host/work/static_shape_convert 在static_shape_convert目录下新建converter_onnx2mindir.sh文件并复制下面内容。其中，onnx_dir表示onnx模型的目录，mindir_dir指定要生成的mindir模型的保存目录。 # converter_onnx2mindir.sh # 设置onnx模型和mindir模型目录 onnx_dir=/home_host/work/runwayml/onnx_models mindir_dir=./mindir_models # 指定配置文件路径 config_dir=/home_host/work/modelarts-ascend/examples/AIGC/stable_diffusion/configs echo "================begin converter_lite=====================" sub_cmd='--fmk=ONNX --optimize=ascend_oriented --saveType=MINDIR' mkdir -p $mindir_dir # rm缓存,慎改 atc_data_dir=/root/atc_data/ # 通用转换方法 common_converter_model() { model_name=$1 echo "start to convert $model_name" rm -rf $atc_data_dir converter_lite --modelFile="$onnx_dir/$model_name/model.onnx" \ --outputFile="$mindir_dir/$model_name" \ --configFile="$config_dir/$model_name.ini" \ $sub_cmd printf "end converter_lite\n" } common_converter_model "text_encoder" common_converter_model "unet" common_converter_model "vae_encoder" common_converter_model "vae_decoder" common_converter_model "safety_checker" echo "================converter_lite over=====================" 转换结果如下，其中safety_checker模型转换成功了，但中间有ERROR日志，该ERROR属于常量折叠失败，不影响结果。 图2 转换结果

动态分档模型转换（可选） 如果迁移的模型有多个shape档位的需求，可以通过如下方式对模型进行分档转换。 动态分档是指将模型输入的某一维或者某几维设置为“动态”可变，但是需要提前设置可变维度的“档位”范围。即转换得到的模型能够在指定的动态轴上使用预设的几种shape（保证模型支持的shape），相比于静态shape更加灵活，且性能不会有劣化。 动态分档模型转换需要使用配置文件，指定输入格式为“ND”，并在config文件中配置ge.dynamicDims和input_shape使用，在input_shape中将输入shape的动态维度设为-1，并在ge.dynamicDims中指定动态维度的档位，更多配置项可以参考官方文档。 如果网络模型只有一个输入：每个档位的dim值与input_shape参数中的-1标识的参数依次对应，input_shape参数中有几个-1，则每档必须设置几个维度。 以text_encoder模型为例，修改配置文件text_encoder.ini如下所示： # text_encoder.ini [acl_build_options] input_format="ND" input_shape="input_ids:1,-1" ge.dynamicDims="77;33" 使用上述配置文件转换得到的模型，支持的输入shape为(1,77)和(1,33)。 然后使用converter lite执行模型转换，转换命令如下： converter_lite --modelFile=./onnx_models/text_encoder/model.onnx --fmk=ONNX --saveType=MINDIR --optimize=ascend_oriented --outputFile=./mindirs --configFile=./configs/text_encoder.ini 如果网络模型有多个输入：档位的dim值与网络模型输入参数中的-1标识的参数依次对应，网络模型输入参数中有几个-1，则每档必须设置几个维度。 以unet模型为例，该网络模型有三个输入，分别为“sample(1,4,64,64)”、“timestep(1)”、“encoder_hidden_states(1,77,768)”，修改unet.ini配置文件如下所示： # unet.ini [acl_build_options] input_format="ND" input_shape="sample:-1,4,64,64;timestep:1;encoder_hidden_states:-1,77,768" ge.dynamicDims="1,1;2,2;3,3" 转换得到的模型支持的输入dims组合档数分别为： 图3 组合档数 第0档：sample(1,4,64,64) + timestep(1) + encoder_hidden_states(1,77,768) 第1档：sample(2,4,64,64) + timestep(1) + encoder_hidden_states(2,77,768) 第2档：sample(3,4,64,64) + timestep(1) + encoder_hidden_states(3,77,768) 然后使用converter lite执行模型转换，转换命令如下： converter_lite --modelFile=./onnx_models/unet/model.onnx --fmk=ONNX --saveType=MINDIR --optimize=ascend_oriented --outputFile=./mindirs --configFile=./configs/unet.ini 最多支持100档配置，每一档通过英文逗号分隔。 如果用户设置的dim数值过大或档位过多，可能会导致模型编译失败，此时建议用户减少档位或调低档位数值。 如果用户设置了动态维度，实际推理时，使用的输入数据的shape需要与设置的档位相匹配。

PyTorch模型转换为Onnx模型（可选） 获取onnx模型有两种方式，方式一是使用官方提供的模型转换脚本将pytorch模型转换为onnx模型，方式二是对于提供了onnx模型的仓库，可以直接下载onnx模型。下面介绍方式一如何操作，如果采用方式二，可以跳过此步骤。 通过git下载diffusers对应版本的源码。 git clone https://github.com/huggingface/diffusers.git -b v0.11.1 在diffusers的script/convert_stable_diffusion_checkpoint_to_onnx.py脚本中，可以通过执行以下命令生成onnx模型，其中model_path指定pytorch的模型根目录，output_path指定生成的onnx模型目录。 cd /home_host/work python diffusers/scripts/convert_stable_diffusion_checkpoint_to_onnx.py --model_path "./runwayml/pytorch_models" --output_path "./pytorch_to_onnx_models"

获取模型shape 由于在后续模型转换时需要知道待转换模型的shape信息，这里指导如何通过训练好的stable diffusion pytorch模型获取模型shape，主要有如下两种方式获取： 方式一：通过stable diffusion的pytorch模型获取模型shape。 方式二：通过查看ModelArts-Ascend代码仓库，根据每个模型的configs文件获取已知的shape大小。 下文主要介绍方式1如何通过stable diffusion的pytorch模型获取模型shape。 在pipeline应用准备章节，已经下载到sd的pytorch模型（/home_host/work/runwayml/pytorch_models）。进入工作目录： cd /home_host/work 新建python脚本文件“parse_models_shape.py”用于获取shape，其中model_path是指上面下载的pytorch_models的路径。 # parse_models_shape.py import torch import numpy as np from diffusers import StableDiffusionPipeline model_path = '/home_host/work/runwayml/pytorch_models' pipeline = StableDiffusionPipeline.from_pretrained(model_path, torch_dtype=torch.float32) # TEXT ENCODER num_tokens = pipeline.text_encoder.config.max_position_embeddings text_hidden_size = pipeline.text_encoder.config.hidden_size text_input = pipeline.tokenizer( "A sample prompt", padding="max_length", max_length=pipeline.tokenizer.model_max_length, truncation=True, return_tensors="pt", ) print("# TEXT ENCODER") print(f"input_ids: {np.array(text_input.input_ids.shape).tolist()}") # UNET unet_in_channels = pipeline.unet.config.in_channels unet_sample_size = pipeline.unet.config.sample_size print("# UNET") print(f"sample: [{2}, {unet_in_channels} {unet_sample_size} {unet_sample_size}]") print(f"timestep: [{1}]") # 此处应该是1，否则和后续的推理脚本不一致 print(f"encoder_hidden_states: [{2}, {num_tokens} {text_hidden_size}]") # VAE ENCODER vae_encoder = pipeline.vae vae_in_channels = vae_encoder.config.in_channels vae_sample_size = vae_encoder.config.sample_size print("# VAE ENCODER") print(f"sample: [{1}, {vae_in_channels}, {vae_sample_size}, {vae_sample_size}]") # VAE DECODER vae_decoder = pipeline.vae vae_latent_channels = vae_decoder.config.latent_channels vae_out_channels = vae_decoder.config.out_channels print("# VAE DECODER") print(f"latent_sample: [{1}, {vae_latent_channels}, {unet_sample_size}, {unet_sample_size}]") # SAFETY CHECKER safety_checker = pipeline.safety_checker clip_num_channels = safety_checker.config.vision_config.num_channels clip_image_size = safety_checker.config.vision_config.image_size print("# SAFETY CHECKER") print(f"clip_input: [{1}, {clip_num_channels}, {clip_image_size}, {clip_image_size}]") print(f"images: [{1}, {vae_sample_size}, {vae_sample_size}, {vae_out_channels}]") 执行以下命令获取shape信息。 python parse_models_shape.py 可以看到获取的shape信息如下图所示。 图1 shape信息

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推理业务迁移至昇腾指导

迁移环境准备 迁移环境准备有以下两种方式： 方式一 ModelArts Notebook：该环境为在线调试环境，主要面向演示、体验和快速原型调试场景。 优点：可快速、低成本地搭建环境，使用标准化容器镜像，官方notebook示例可直接运行。 缺点：由于是容器化环境因此不如裸机方式灵活，例如不支持root权限操作、驱动更新等。 环境开通指导参考：Notebook环境创建。 样例演示可参考Notebook样例：Stable Diffusion模型迁移到Ascend上进行推理。 方式二 ModelArts Lite DevServer：该环境为裸机开发环境，主要面向深度定制化开发场景。 优点：支持深度自定义环境安装，可以方便的替换驱动、固件和上层开发包，具有root权限，结合配置指导、初始化工具及容器镜像可以快速搭建昇腾开发环境。 缺点：资源申请周期长，购买成本高，管理视角下资源使用效率较低。 环境开通指导参考：DevServer资源开通 环境配置指导参考：Snt9B裸金属服务器环境配置指南 本文基于方式二的环境进行操作，请参考方式二中的环境开通和配置指导完成裸机和容器开发初始化配置。注意业务基础镜像选择Ascend+PyTorch镜像。 配置好的容器环境如下图所示： 图1 环境配置完成 父主题： 基于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推理业务迁移至昇腾指导

Step1使用tensorRT量化工具进行模型量化 使用tensorRT 0.9.0版本工具进行模型量化，工具下载使用指导请参见https://github.com/NVIDIA/TensorRT-LLM/tree/v0.9.0。 执行如下脚本进行权重转换生成量化系数，详细参数解释请参见https://github.com/NVIDIA/TensorRT-LLM/tree/main/examples/llama#int8-kv-cache） python convert_checkpoint.py \ --model_dir ./llama-models/llama-7b-hf \ --output_dir ./llama-models/llama-7b-hf/int8_kv_cache/ \ --dtype float16 \ --int8_kv_cache 运行完成后，会在output_dir下生成量化后的权重。量化后的权重包括原始权重和kvcache的scale系数。

Step3 启动kv-cache-int8量化服务 参考Step3 启动推理服务，启动推理服务时添加如下命令。 --kv-cache-dtype int8 #只支持int8，表示kvint8量化 --quantization-param-path kv_cache_scales.json #输入Step2 抽取kv-cache量化系数生成的json文件路径; 如果只测试推理功能和性能，不需要此json文件，此时scale系数默认为1，但是可能会造成精度下降。

使用SmoothQuant量化工具转换权重 SmoothQuant(W8A8)量化方案能降低模型显存以及需要部署的卡数。也能同时降低首token时延和增量推理时延。支持SmoothQuant(W8A8)量化的模型列表请参见表1。 本章节介绍如何在Notebook使用SmoothQuant量化工具实现推理量化。 SmoothQuant量化工具使用到的脚本存放在代码包AscendCloud-LLM-x.x.x.zip的llm_tools目录下。 代码目录如下: AutoSmoothQuant #量化工具 ├── ascend_autosmoothquant_adapter # 昇腾量化使用的算子模块 ├── autosmoothquant # 量化代码 ├── build.sh # 安装量化模块的脚本 ... 具体操作如下： 配置环境。 cd llm_tools/AutoSmoothQuant/ sh build.sh 配置需要使用的NPU卡，例如：实际使用的是第1张和第2张卡，此处填写为“0,1”，以此类推。 export ASCEND_RT_VISIBLE_DEVI CES =0,1 NPU卡编号可以通过命令npu-smi info查询。 执行权重转换。 cd autosmoothquant/examples/ python smoothquant_model.py --model-path /home/ma-user/llama-2-7b/ --quantize-model --generate-scale --dataset-path /data/nfs/user/val.jsonl --scale-output scales/llama2-7b.pt --model-output quantized_model/llama2-7b --per-token --per-channel 参数说明: --model-path：原始模型权重路径。 --quantize-model：体现此参数表示会生成量化模型权重。不需要生成量化模型权重时，不体现此参数 --generate-scale：体现此参数表示会生成量化系数，生成后的系数保存在--scale-output参数指定的路径下。如果有指定的量化系数，则不需此参数，直接读取--scale-input参数指定的量化系数输入路径即可。 --dataset-path：数据集路径，推荐使用：https://huggingface.co/datasets/mit-han-lab/pile-val-backup/resolve/main/val.jsonl.zst。 --scale-output：量化系数保存路径。 --scale-input：量化系数输入路径，若之前已生成过量化系数，则可指定该参数，跳过生成scale的过程。 --model-output：量化模型权重保存路径。 --smooth-strength：平滑系数，推荐先指定为0.5，后续可以根据推理效果进行调整。 --per-token：激活值量化方法，若指定则为per-token粒度量化，否则为per-tensor粒度量化。 --per-channel：权重量化方法，若指定则为per-channel粒度量化，否则为per-tensor粒度量化。 启动smoothQuant量化服务。 参考Step3 启动推理服务，启动推理服务时添加如下命令。 -q smoothquant 或者 --quantization smoothquant 父主题： 推理模型量化

Step2 权重格式转换 AutoAWQ量化完成后，使用int32对int4的权重进行打包。昇腾上使用int8对权重进行打包，需要进行权重转换。 进入llm_tools代码目录下执行以下脚本： 执行时间预计10分钟。执行完成后会将权重路径下的原始权重替换成转换后的权重。如需保留之前权重格式，请在转换前备份。 python awq/convert_awq_to_npu.py --model /home/ma-user/Qwen1.5-72B-Chat-AWQ 参数说明： --model：模型路径。

静态benchmark 运行静态benchmark验证脚本benchmark_parallel.py，具体操作命令如下，可以根据参数说明修改参数。 Notebook中进行测试： cd benchmark_tools python benchmark_parallel.py --backend vllm --host 127.0.0.1 --port 8080 --tokenizer /path/to/tokenizer --epochs 10 --parallel-num 1 2 4 8 --output-tokens 256 256 --prompt-tokens 1024 2048 --benchmark-csv benchmark_parallel.csv 生产环境中进行测试： python benchmark_parallel.py --backend vllm --url xxx --app-code xxx --tokenizer /path/to/tokenizer --epochs 10 --parallel-num 1 2 4 8 --output-tokens 256 256 --prompt-tokens 1024 2048 --benchmark-csv benchmark_parallel.csv 参数说明： --backend：服务类型，支持tgi、vllm、mindspore、openai等。本文档使用的推理接口是vllm。 --host：服务IP地址，如127.0.0.1。 --port：服务端口，和推理服务端口8080。 --url：若以vllm接口方式启动服务，API接口公网地址与"/generate"拼接而成；若以openai接口方式启动服务，API接口公网地址与"/v1/completions"拼接而成。部署成功后的在线服务详情页中可查看API接口公网地址。 图1 API接口公网地址 --app-code：获取方式见访问在线服务（APP认证）。 --tokenizer：tokenizer路径，HuggingFace的权重路径。若服务部署在Notebook中，该参数为Notebook中权重路径；若服务部署在生产环境中，该参数为本地模型权重路径。 --served-model-name：仅在以openai接口启动服务时需要该参数。若服务部署在Notebook中，该参数为Notebook中权重路径；若服务部署在生产环境中，该参数为服务启动脚本run_vllm.sh中的${model_path}。 --epochs：测试轮数，默认取值为5。 --parallel-num：每轮并发数，支持多个，如 1 4 8 16 32。 --prompt-tokens：输入长度，支持多个，如 128 128 2048 2048，数量需和--output-tokens的数量对应。 --output-tokens：输出长度，支持多个，如 128 2048 128 2048，数量需和--prompt-tokens的数量对应。 脚本运行完成后，测试结果保存在benchmark_parallel.csv中，示例如下图所示。 图2 静态benchmark测试结果（示意图）

动态benchmark 获取测试数据集。 动态benchmark需要使用数据集进行测试，可以使用公开数据集，例如Alpaca、ShareGPT。也可以根据业务实际情况，使用generate_datasets.py脚本生成和业务数据分布接近的数据集。 公开数据集下载地址： ShareGPT: https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json Alpaca: https://github.com/tatsu-lab/stanford_alpaca/blob/main/alpaca_data.json 使用generate_datasets.py脚本生成数据集方法： generate_datasets.py脚本通过指定输入输出长度的均值和标准差，生成一定数量的正态分布的数据。具体操作命令如下，可以根据参数说明修改参数。 cd benchmark_tools python generate_datasets.py --datasets custom_datasets.json --tokenizer /path/to/tokenizer \ --min-input 100 --max-input 3600 --avg-input 1800 --std-input 500 \ --min-output 40 --max-output 256 --avg-output 160 --std-output 30 --num-requests 1000 generate_datasets.py脚本执行参数说明如下： --datasets：数据集保存路径，如custom_datasets.json。 --tokenizer：tokenizer路径，可以是HuggingFace的权重路径。 --min-input：输入tokens最小长度，可以根据实际需求设置。 --max-input：输入tokens最大长度，可以根据实际需求设置。 --avg-input：输入tokens长度平均值，可以根据实际需求设置。 --std-input：输入tokens长度方差，可以根据实际需求设置。 --min-output：最小输出tokens长度，可以根据实际需求设置。 --max-output：最大输出tokens长度，可以根据实际需求设置。 --avg-output：输出tokens长度平均值，可以根据实际需求设置。 --std-output：输出tokens长度标准差，可以根据实际需求设置。 --num-requests：输出数据集的数量，可以根据实际需求设置。 执行脚本benchmark_serving.py测试动态benchmark。具体操作命令如下，可以根据参数说明修改参数。 Notebook中进行测试： cd benchmark_tools python benchmark_serving.py --backend vllm --host 127.0.0.1 --port 8080 --dataset custom_dataset.json --dataset-type custom --tokenizer /path/to/tokenizer --request-rate 0.01 1 2 4 8 10 20 --num-prompts 10 1000 1000 1000 1000 1000 1000 --max-tokens 4096 --max-prompt-tokens 3768 --benchmark-csv benchmark_serving.csv 生产环境中进行测试： python benchmark_serving.py --backend vllm --url xxx --app-code xxx --dataset custom_dataset.json --dataset-type custom --tokenizer /path/to/tokenizer --request-rate 0.01 1 2 4 8 10 20 --num-prompts 10 1000 1000 1000 1000 1000 1000 --max-tokens 4096 --max-prompt-tokens 3768 --benchmark-csv benchmark_serving.csv --backend：服务类型，支持tgi、vllm、mindspore、openai等。本文档使用的推理接口是vllm。 --host：服务IP地址，如127.0.0.1。 --port：服务端口。 --url：若以vllm接口方式启动服务，API接口公网地址与"/generate"拼接而成；若以openai接口方式启动服务，API接口公网地址与"/v1/completions"拼接而成。部署成功后的在线服务详情页中可查看API接口公网地址。 图3 API接口公网地址 --app-code：获取方式见访问在线服务（APP认证）。 --datasets：数据集路径。 --datasets-type：支持三种 "alpaca"，"sharegpt"，"custom"。custom为自定义数据集。 --tokenizer：tokenizer路径，可以是huggingface的权重路径。若服务部署在Notebook中，该参数为Notebook中权重路径；若服务部署在生产环境中，该参数为本地模型权重路径。 --served-model-name：仅在以openai接口启动服务时需要该参数。若服务部署在Notebook中，该参数为Notebook中权重路径；若服务部署在生产环境中，该参数为服务启动脚本run_vllm.sh中的${model_path}。 --request-rate：请求频率，支持多个，如 0.1 1 2。实际测试时，会根据request-rate为均值的指数分布来发送请求以模拟真实业务场景。 --num-prompts：某个频率下请求数，支持多个，如 10 100 100，数量需和--request-rate的数量对应。 --max-tokens：输入+输出限制的最大长度，模型启动参数--max-input-length值需要大于该值。 --max-prompt-tokens：输入限制的最大长度，推理时最大输入tokens数量，模型启动参数--max-total-tokens值需要大于该值，tokenizer建议带tokenizer.json的FastTokenizer。 --benchmark-csv：结果保存路径，如benchmark_serving.csv。 脚本运行完后，测试结果保存在benchmark_serving.csv中，示例如下图所示。 图4 动态benchmark测试结果（示意图）

约束限制 创建在线服务时，每秒服务流量限制默认为100次，若静态benchmark的并发数（parallel-num参数）或动态benchmark的请求频率（request-rate参数）较高，会触发推理平台的流控，请在ModelArts Standard“在线服务”详情页修改服务流量限制。 同步请求时，平台每次请求预测的时间不能超过60秒。例如输出数据比较大的调用请求（例如输出大于1k），请求预测会超过60秒导致调用失败，可提交工单设置请求超时时间。

benchmark方法介绍 性能benchmark包括两部分。 静态性能测试：评估在固定输入、固定输出和固定并发下，模型的吞吐与首token延迟。该方式实现简单，能比较清楚的看出模型的性能和输入输出长度、以及并发的关系。 动态性能测试：评估在请求并发在一定范围内波动，且输入输出长度也在一定范围内变化时，模型的延迟和吞吐。该场景能模拟实际业务下动态的发送不同长度请求，能评估推理框架在实际业务中能支持的并发数。 性能benchmark验证使用到的脚本存放在代码包AscendCloud-LLM-x.x.x.zip的llm_evaluation目录下。 代码目录如下: benchmark_tools ├── benchmark_parallel.py # 评测静态性能脚本 ├── benchmark_serving.py # 评测动态性能脚本 ├── generate_dataset.py # 生成自定义数据集的脚本 ├── benchmark_utils.py # 工具函数集 ├── benchmark.py # 执行静态，动态性能评测脚本 执行性能测试脚本前，需先安装相关依赖。 pip install -r requirements.txt