华为云用户手册

设置高精度并重新转换模型 在转换模型时，默认采用的精度模式是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

修改代码依赖 新建并进入/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

运行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输出的结果图片

动态分档模型转换（可选） 如果迁移的模型有多个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需要与设置的档位相匹配。

静态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 转换结果

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大小。 下文主要介绍如何通过方式一获取模型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推理业务迁移至昇腾指导

迁移环境准备 迁移环境准备有以下两种方式： 表1 方式说明 序号 名称 说明 方式一 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：模型路径。

约束限制 创建在线服务时，每秒服务流量限制默认为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

静态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测试结果（示意图）

Step1 配置精度测试环境 获取精度测试代码。精度测试代码存放在代码包AscendCloud-LLM的llm_tools/llm_evaluation目录中，代码目录结构如下。 benchmark_eval ├──opencompass.sh #运行opencompass脚本 ├──install.sh #安装opencompass脚本 ├──vllm_api.py #启动vllm api服务器 ├──vllm.py #构造vllm评测配置脚本名字 确保Notebook内通网，已通网可以跳过这一步，未通网需要配置$config_proxy_str，$config_pip_str设置对应的代理和pip源，来确保当前代理和pip源可用。 精度评测新建一个conda环境，确保之前启动服务为vllm接口，进入到benchmark_eval目录下，执行如下命令。命令中的$work_dir 是benchmark_eval的绝对路径。 conda activate python-3.9.10 #如果没有该conda环境需要手动建立一个 export work_dir=${work_dir} #指定work_dir路径 bash install.sh 在benchmark_eval目录下安装依赖。 cd opencompass #在benchmark_eval目录下 pip install -e . #下载对应依赖 cd ../human-eval #在benchmark_eval目录下 （可选，如果选择使用humaneval数据集） pip install -e . # 可选，如果选择使用humaneval数据集 （可选）如果需要在humaneval数据集上评估模型代码能力，请执行此步骤，否则忽略这一步。原因是通过opencompass使用humaneval数据集时，需要执行模型生成的代码。请仔细阅读human_eval/execution.py文件第48-57行的注释，内容参考如下。了解执行模型生成代码可能存在的风险，如果接受这些风险，请取消第58行的注释，执行下面步骤6进行评测。 # WARNING # This program exists to execute untrusted model-generated code. Although # it is highly unlikely that model-generated code will do something overtly # malicious in response to this test suite, model-generated code may act # destructively due to a lack of model capability or alignment. # Users are strongly encouraged to sandbox this evaluation suite so that it # does not perform destructive actions on their host or network. For more # information on how OpenAI sandboxes its code, see the accompanying paper. # Once you have read this disclaimer and taken appropriate precautions, # uncomment the following line and proceed at your own risk: # exec(check_program, exec_globals) #第58行 执行精度测试启动脚本opencompass.sh，具体操作命令如下，可以根据参数说明修改参数。请确保${work_dir} 已经通过export设置。 vllm_path=${vllm_path} \ service_port=${service_port} \ max_out_len=${max_out_len} \ batch_size=${batch_size} \ eval_datasets=${eval_datasets} \ model_name=${model_name} \ benchmark_type=${benchmark_type} \ bash -x opencompass.sh 参数说明: vllm_path：构造vllm评测配置脚本名字，默认为vllm。 service_port：服务端口，与启动服务时的端口保持，比如8080。 max_out_len：在运行类似mmlu、ceval等判别式回答时，max_out_len建议设置小一些，比如16。在运行human_eval等生成式回答（生成式回答是对整体进行评测，少一个字符就可能会导致判断错误）时，max_out_len设置建议长一些，比如512，至少包含第一个回答的全部字段。 batch_size：输入的batch_size大小，不影响精度，只影响得到结果速度。 eval_datasets：评测数据集和评测方法，比如ceval_gen、mmlu_gen 。 model_name：评测模型名称，不需要与启动服务时的模型参数保持一致。 benchmark_type：评测数据集类型，分为eval、static、awq，也就是精度、静态和量化数据集，默认eval。 参考命令： vllm_path=vllm service_port=8080 max_out_len=16 batch_size=2 eval_datasets=mmlu_gen model_name=llama_7b benchmark_type=eval bash -x opencompass.sh 客户端显示运行过程，通过run.py运行。如果同时运行多个数据集，需要将不同数据集通过空格分开，加入到eval_datasets中，比如eval_datasets=ceval_gen mmlu_gen。运行命令如下所示。 cd opencompass python run.py --models vllm --datasets mmlu_gen ceval_gen -w ${output_path} output_path: 要保存的结果路径。

Step2 查看精度测试结果 默认情况下，评测结果会按照result/{model_name}/的目录结果保存到对应的测试工程。执行多少次，则会在{model_name}下生成多少次结果。benchmark_eval下生成的log中记录了客户端产生结果。数据集的打分结果在result/{model_name}/...目录下，查找到summmary目录，有txt和csv两种保存格式。总体打分结果参考txt和csv文件的最后一行，举例如下： npu： mmlu：46.6 gpu： mmlu：47 NPU打分结果（mmlu取值46.6）和GPU打分结果（mmlu取值47）进行对比，误差在1%以内（计算公式：(47-46.6)/47*100=0.85%）认为NPU精度和GPU对齐。

Step4 调用在线服务 进入在线服务详情页面，选择“预测”。 若以vllm接口启动服务，设置请求路径：“/generate”，输入预测代码“{"prompt": "你好", "temperature":0, "max_tokens":20}”，单击“预测”即可看到预测结果。 图4 预测-vllm 若以openai接口启动服务，设置请求路径：“/v1/completions”，输入预测代码“{"prompt": "你是谁","model": "${model_path}","max_tokens": 50,"temperature":0}”，单击“预测”即可看到预测结果。 图5 预测-openai 在线服务的更多内容介绍请参见文档查看服务详情。

Step1 准备模型文件和权重文件 在OBS桶中，创建文件夹，准备模型权重文件、推理启动脚本run_vllm.sh及SSL证书。此处以chatglm3-6b为例。 模型权重文件获取地址请参见表1。 若需要部署量化模型，请参考推理模型量化在Notebook中进行权重转换，并将转换后的权重上传至OBS中。 权重文件夹不要以"model"命名，若以"model"命名会导致后续创建AI应用报错。 推理启动脚本run_vllm.sh制作请参见•创建推理脚本文件run_vllm.sh。 SSL证书制作包含cert.pem和key.pem，需自行生成。生成方式请参见•通过openssl创建SSLpem证书。 图1 准备模型文件和权重文件 创建推理脚本文件run_vllm.sh run_vllm.sh脚本示例如下。 通过vLLM服务API接口启动服务 source /home/ma-user/.bashrc export ASCEND_RT_VISIBLE_DEVICES=${ASCEND_RT_VISIBLE_DEVICES} python -m vllm.entrypoints.api_server --model ${model_path} \ --ssl-keyfile="/home/mind/model/key.pem" \ --ssl-certfile="/home/mind/model/cert.pem" \ --max-num-seqs=256 \ --max-model-len=4096 \ --max-num-batched-tokens=4096 \ --dtype=float16 \ --tensor-parallel-size=1 \ --block-size=128 \ --host=0.0.0.0 \ --port=8080 \ --gpu-memory-utilization=0.9 \ --trust-remote-code 通过OpenAI服务API接口启动服务 source /home/ma-user/.bashrc export ASCEND_RT_VISIBLE_DEVICES=${ASCEND_RT_VISIBLE_DEVICES} python -m vllm.entrypoints.openai.api_server --model ${model_path} \ --ssl-keyfile="/home/mind/model/key.pem" \ --ssl-certfile="/home/mind/model/cert.pem" \ --max-num-seqs=256 \ --max-model-len=4096 \ --max-num-batched-tokens=4096 \ --dtype=float16 \ --tensor-parallel-size=1 \ --block-size=128 \ --host=0.0.0.0 \ --port=8080 \ --gpu-memory-utilization=0.9 \ --trust-remote-code 参数说明： ${ASCEND_RT_VISIBLE_DEVICES}：使用的NPU卡，单卡设为0即可，4卡可设为0,1,2,3。 ${model_path}：模型路径，填写为/home/mind/model/权重文件夹名称，如：/home/mind/model/chatglm3-6b。 /home/mind/model路径为推理平台固定路径，部署服务时会将Step1 准备模型文件和权重文件OBS路径下的文件传输至/home/mind/model路径下。 --tensor-parallel-size：并行卡数。 --hostname：服务部署的IP，使用本机IP 0.0.0.0。 --port：服务部署的端口8080。 --max-model-len：最大数据输入+输出长度，不能超过模型配置文件config.json里面定义的“max_position_embeddings”和“seq_length”；如果设置过大，会占用过多显存，影响kvcache的空间。 --gpu-memory-utilization：NPU使用的显存比例，复用原vLLM的入参名称，默认为0.9。 --trust-remote-code：是否相信远程代码。 --dtype：模型推理的数据类型。仅支持FP16和BF16数据类型推理。float16表示FP16，bfloat16表示BF16。 推理启动脚本必须名为run_vllm.sh，不可修改其他名称。 hostname和port也必须分别是0.0.0.0和8080不可更改。 高阶参数说明： --enable-prefix-caching：如果prompt的公共前缀较长或者多轮对话场景下推荐使用prefix-caching特性。在推理服务启动脚本中添加此参数表示使用，不添加表示不使用。 --quantization：推理量化参数。当使用量化功能，则在推理服务启动脚本中增加该参数，若未使用量化功能，则无需配置。根据使用的量化方式配置，可选择awq或smoothquant方式。 --speculative-model ${container_draft_model_path}：投机草稿模型地址，模型格式是HuggingFace的目录格式。即Step2 准备权重文件上传的HuggingFace权重文件存放目录。投机草稿模型为与--model入参同系列，但是权重参数远小于--model指定的模型。若未使用投机推理功能，则无需配置。 --num-speculative-tokens：投机推理小模型每次推理的token数。若未使用投机推理功能，则无需配置。参数--num-speculative-tokens需要和--speculative-model ${container_draft_model_path}同时使用。 可在run_vllm.sh增加如下环境变量开启高阶配置： export DEFER_DECODE=1 # 是否使用推理与Token解码并行；默认值为1表示开启并行，取值为0表示关闭并行。开启该功能会略微增加首Token时间，但可以提升推理吞吐量。 export DEFER_MS=10 # 延迟解码时间，默认值为10，单位为ms。将Token解码延迟进行的毫秒数，使得当次Token解码能与下一次模型推理并行计算，从而减少总推理时延。该参数需要设置环境变量DEFER_DECODE=1才能生效。 export USE_VOCAB_PARALLEL=1 # 是否使用词表并行；默认值为1表示开启并行，取值为0表示关闭并行。对于词表较小的模型（如llama2系模型），关闭并行可以减少推理时延，对于词表较大的模型（如qwen系模型），开启并行可以减少显存占用，以提升推理吞吐量。 export USE_PFA_HIGH_PRECISION_MODE=1 # PFA算子是否使用高精度模式；默认值为0表示不开启。针对Qwen2-7B模型，必须开启此配置，否则精度会异常；其他模型不建议开启，因为性能会有损失。

Step2 准备权重文件 将OBS中的模型权重上传到Notebook的工作目录/home/ma-user/work/下。上传代码参考如下。 import moxing as mox obs_dir = "obs://${bucket_name}/${folder-name}" local_dir = "/home/ma-user/work/qwen-14b" mox.file.copy_parallel(obs_dir, local_dir) 实际操作如下图所示。 图1 上传OBS文件到Notebook的代码示例

Step3 启动推理服务 配置需要使用的NPU卡编号。例如：实际使用的是第1张卡，此处填写“0”。 export ASCEND_RT_VISIBLE_DEVICES=0 如果启动服务需要使用多张卡，例如：实际使用的是第1张和第2张卡，此处填写为“0,1”，以此类推。 export ASCEND_RT_VISIBLE_DEVICES=0,1 NPU卡编号可以通过命令npu-smi info查询。 配置环境变量。 export DEFER_DECODE=1 # 是否使用推理与Token解码并行；默认值为1表示开启并行，取值为0表示关闭并行。开启该功能会略微增加首Token时间，但可以提升推理吞吐量。 export DEFER_MS=10 # 延迟解码时间，默认值为10，单位为ms。将Token解码延迟进行的毫秒数，使得当次Token解码能与下一次模型推理并行计算，从而减少总推理时延。该参数需要设置环境变量DEFER_DECODE=1才能生效。 export USE_VOCAB_PARALLEL=1 # 是否使用词表并行；默认值为1表示开启并行，取值为0表示关闭并行。对于词表较小的模型（如llama2系模型），关闭并行可以减少推理时延，对于词表较大的模型（如qwen系模型），开启并行可以减少显存占用，以提升推理吞吐量。 export USE_PFA_HIGH_PRECISION_MODE=1 # PFA算子是否使用高精度模式；默认值为0表示不开启。针对Qwen2-7B模型，必须开启此配置，否则精度会异常；其他模型不建议开启，因为性能会有损失。 如果需要增加模型量化功能，启动推理服务前，先参考推理模型量化章节对模型做量化处理。 启动服务与请求。此处提供vLLM服务API接口启动和OpenAI服务API接口启动2种方式。详细启动服务与请求方式参考：https://docs.vllm.ai/en/latest/getting_started/quickstart.html。 以下服务启动介绍的是在线推理方式，离线推理请参见https://docs.vllm.ai/en/latest/getting_started/quickstart.html#offline-batched-inference。 通过vLLM服务API接口启动服务 在ascend_vllm目录下通过vLLM服务API接口启动服务，具体操作命令如下，API Server的命令相关参数说明如下，可以根据参数说明修改配置。 python -m vllm.entrypoints.api_server --model ${model_path} \ --max-num-seqs=256 \ --max-model-len=4096 \ --max-num-batched-tokens=4096 \ --dtype=float16 \ --tensor-parallel-size=1 \ --block-size=128 \ --host=${docker_ip} \ --port=8080 \ --gpu-memory-utilization=0.9 \ --trust-remote-code 通过OpenAI服务API接口启动服务 在ascend_vllm目录下通OpenAI服务API接口启动服务，具体操作命令如下，可以根据参数说明修改配置。 python -m vllm.entrypoints.openai.api_server --model ${model_path} \ --max-num-seqs=256 \ --max-model-len=4096 \ --max-num-batched-tokens=4096 \ --dtype=float16 \ --tensor-parallel-size=1 \ --block-size=128 \ --host=${docker_ip} \ --port=8080 \ --gpu-memory-utilization=0.9 \ --trust-remote-code 具体参数说明如下： --model ${model_path}：模型地址，模型格式是HuggingFace的目录格式。即Step2 准备权重文件上传的HuggingFace权重文件存放目录。如果使用了量化功能，则使用推理模型量化章节转换后的权重。 --max-num-seqs：最大同时处理的请求数，超过后拒绝访问。 --max-model-len：推理时最大输入+最大输出tokens数量，输入超过该数量会直接返回。max-model-len的值必须小于config.json文件中的"seq_length"的值，否则推理预测会报错。config.json存在模型对应的路径下，例如：/home/ma-user/work/chatglm3-6b/config.json。 --max-num-batched-tokens：prefill阶段，最多会使用多少token，必须大于或等于--max-model-len，推荐使用4096或8192。 --dtype：模型推理的数据类型。支持FP16和BF16数据类型推理。float16表示FP16，bfloat16表示BF16。 --tensor-parallel-size：模型并行数。取值需要和启动的NPU卡数保持一致，可以参考1。此处举例为1，表示使用单卡启动服务。 --block-size：PagedAttention的block大小，推荐设置为128。 --host=${docker_ip}：服务部署的IP，${docker_ip}替换为宿主机实际的IP地址。 --port：服务部署的端口。 --gpu-memory-utilization：NPU使用的显存比例，复用原vLLM的入参名称，默认为0.9。 --trust-remote-code：是否相信远程代码。 高阶参数说明： --enable-prefix-caching：如果prompt的公共前缀较长或者多轮对话场景下推荐使用prefix-caching特性。在推理服务启动脚本中添加此参数表示使用，不添加表示不使用。 --quantization：推理量化参数。当使用量化功能，则在推理服务启动脚本中增加该参数，若未使用量化功能，则无需配置。根据使用的量化方式配置，可选择awq或smoothquant方式。 --speculative-model ${container_draft_model_path}：投机草稿模型地址，模型格式是HuggingFace的目录格式。即Step2 准备权重文件上传的HuggingFace权重文件存放目录。投机草稿模型为与--model入参同系列，但是权重参数远小于--model指定的模型。若未使用投机推理功能，则无需配置。 --num-speculative-tokens：投机推理小模型每次推理的token数。若未使用投机推理功能，则无需配置。参数--num-speculative-tokens需要和--speculative-model ${container_draft_model_path}同时使用。 服务启动后，会打印如下类似信息。 server launch time cost: 15.443044185638428 s INFO: Started server process [2878] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

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

镜像版本 本教程中用到基础镜像地址和配套版本关系如下表所示，请提前了解。 表1 基础容器镜像地址 镜像用途 镜像地址 配套版本 基础镜像 swr.cn-southwest-2.myhuaweicloud.com/atelier/pytorch_2_1_ascend:pytorch_2.1.0-cann_8.0.rc2-py_3.9-hce_2.0.2312-aarch64-snt9b-20240606190017-b881580 CANN：cann_8.0.rc2 PyTorch：2.1.0

Step9 通过openssl创建SSL pem证书 在E CS 中执行如下命令，会在当前目录生成cert.pem和key.pem，并将生成的pem证书上传至OBS。证书用于后续在推理生产环境中部署HTTPS推理服务。 openssl genrsa -out key.pem 2048 openssl req -new -x509 -key key.pem -out cert.pem -days 1095

Step2 安装Docker 检查docker是否安装。 docker -v #检查docker是否安装 如尚未安装，运行以下命令安装docker。 yum install -y docker 配置IP转发，用于容器内的网络访问。执行以下命令查看net.ipv4.ip_forward配置项的值，如果为1，可跳过此步骤。 sysctl -p | grep net.ipv4.ip_forward 如果net.ipv4.ip_forward配置项的值不为1，执行以下命令配置IP转发。 sed -i 's/net\.ipv4\.ip_forward=0/net\.ipv4\.ip_forward=1/g' /etc/sysctl.conf sysctl -p | grep net.ipv4.ip_forward