企业官网建设流程全解析

最近后台和私信里被问得最多的一件事，就是Atlas 300V Pro 24G这块卡到底怎么样，网上炒得火热，有人说是运算加速卡，有人说是智商税，还有人问能不能拿来跑YOLO。说实话，这块卡我前后折腾了小一个月，踩了不少坑才把YOLOv8完整部署上去。今天不整虚的，直接把整个流程、参数、遇到的坑全部摊开讲讲清楚。

先说结论：Atlas 300V Pro 24G确实是一块推理加速卡，设计目标就是做AI模型推理，不是拿来跑训练的。它最典型的落地场景就是YOLO系列模型在边缘服务器或私有化环境里的部署，这也是我这次折腾的核心内容。如果你手里正好有这块卡，或者正准备采购，这篇内容应该能帮你省下不少时间。

1. Atlas 300V Pro 24G到底是什么，和普通显卡差在哪

1.1 一张图看懂这块卡的定位

很多人第一次拿到Atlas 300V Pro，会下意识拿它跟NVIDIA的RTX 4090、A10这种显卡比，这是个误区。Atlas 300V Pro属于华为昇腾推理卡产品线，芯片用的是昇腾310P，整卡显存24GB，但它的定位是“推理加速卡”，不是“通用计算卡”。

它和普通显卡的核心差别在于：

• 指令集和架构不同：昇腾310P用的是达芬奇架构，里面的AI Core是专门为矩阵运算设计的，对卷积、池化、全连接这类算子做了深度定制，但通用并行计算能力比NVIDIA的CUDA生态弱很多。
• 软件栈不同：NVIDIA走CUDA/cuDNN/TensorRT这条线，昇腾走的是CANN（Compute Architecture for Neural Networks）这条线，算子库叫AscendCL，模型转换工具叫ATC。
• 精度策略不同：昇腾卡对INT8量化支持得非常激进，很多模型在INT8下的吞吐量能翻好几倍，FP16和FP32的表现反而不是它的强项。

所以你要拿它跑渲染、跑Matlab、跑CUDA写的科学计算，那基本没法用。但如果你要跑YOLOv8、YOLOv5、ResNet50这些CV模型的批量推理，尤其是在国产化环境里，它反而是个很稳的选择。

1.2 24GB显存意味着什么

Atlas 300V Pro 24G的24GB是LPDDR4X，带宽虽然比不上GDDR6或者HBM，但胜在容量大。对大模型推理来说，容量比带宽有时候更关键。

我实测下来，24GB显存大概能干这些事：

• 跑YOLOv8s模型，batch size开到16以上没有任何压力。
• 同时加载两三个不同版本的检测模型，进行多模型并行推理，每个模型单独分配一个上下文。
• 跑一些轻量化的分割模型，比如SegFormer-B0、PP-LiteSeg，也是绰绰有余。
• 甚至可以跑一些参数量在10亿以内的Transformer模型，比如BERT-base、RoBERTa-base的推理。

当然，如果你要跑Llama-7B这种百亿参数的大语言模型，24GB还是会吃紧，量化到INT8勉强能塞进去，但推理速度就不太乐观了。

1.3 什么场景真正适合选它

从我自己的项目经验看，这块卡最适合以下几个场景：

第一个是边缘AI服务器。比如园区安防、工业质检、智慧交通这类场景，一台2U边缘服务器插上两到四张Atlas 300V Pro，就可以把几十路摄像头的视频流全接进来，实时做目标检测和结构化分析。功耗低，不用改机房供电，比插8张RTX 4090省心太多。

第二个是国产化替代需求。很多政企项目明确要求核心组件必须用国产芯片，昇腾是目前生态最成熟的国产AI芯片之一，CANN工具链和MindSpore框架这几年迭代很快，已经在大量项目中落地。

第三个是私有化模型服务。比如企业内部的OCR识别服务、缺陷检测平台、商品识别系统，输入是固定格式的图片或者视频帧，输出是检测框和类别。这种固定场景用推理卡非常划算，因为推理卡的采购成本和功耗都比同级别的GPU低不少。

2. 部署YOLO前的环境准备，没你想的那么轻松

2.1 硬件环境和系统要求

先说硬件，Atlas 300V Pro是标准的PCIe全高全长短卡，单槽位，被动散热，所以服务器必须有风道或者机箱风扇对着吹。我一开始插在一台塔式工作站里，风道不对，卡很快就跑到85度以上，后来换到机架式服务器里才稳定在60度左右。

系统方面，官方支持Ubuntu 18.04/20.04、CentOS 7.6/8.2等，但我的建议是直接用Ubuntu 20.04 x86_64，兼容性最好。ARM版本不建议自己折腾，除非你用的是华为自己的泰山服务器，否则在第三方ARM主板上装CANN会有一堆坑。

安装前确认三件事：

• lspci能看到卡，lspci | grep -i ascend
• BIOS里打开Above 4G Decoding和Resizable BAR，否则DMA可能出问题
• 内核版本在4.18以上，推荐5.4

2.2 驱动、固件、CANN的版本匹配

这是最容易踩坑的地方。昇腾的软件栈分三部分：NPU驱动、NPU固件、CANN工具包。三者之间不是随便乱搭配的，版本必须严格对应。

我这次用的版本组合是：

• 驱动：Ascend-hdk-310p-npu-driver_23.0.rc3_linux-x86_64.run
• 固件：Ascend-hdk-310p-npu-firmware_23.0.rc3_linux-x86_64.run
• CANN：Ascend-cann-toolkit_7.0.0_linux-x86_64.run
• 推理引擎：Ascend-cann-nnrt_7.0.0_linux-x86_64.run

安装顺序不能乱，先驱动再固件最后CANN。驱动和固件的下载地址在昇腾社区，需要注册企业账号，个人开发者也能注册。CANN在昇腾社区直接下载。

安装驱动和固件：

chmod +x Ascend-hdk-310p-npu-driver_23.0.rc3_linux-x86_64.run ./Ascend-hdk-310p-npu-driver_23.0.rc3_linux-x86_64.run --full chmod +x Ascend-hdk-310p-npu-firmware_23.0.rc3_linux-x86_64.run ./Ascend-hdk-310p-npu-firmware_23.0.rc3_linux-x86_64.run --full

装完后重启，执行npu-smi info，如果能显示芯片信息，说明驱动和固件OK。

安装CANN：

chmod +x Ascend-cann-toolkit_7.0.0_linux-x86_64.run ./Ascend-cann-toolkit_7.0.0_linux-x86_64.run --install --install-for-all source /usr/local/Ascend/ascend-toolkit/set_env.sh

注意，set_env.sh每次开新终端都要source一次，或者直接写进.bashrc。

2.3 版本不匹配的症状和处理方式

版本不匹配的典型症状就是：安装时报错、npu-smi能看到卡但初始化失败、ATC转换模型时直接报CANN Internal Error。

我遇到过一次比较诡异的问题：驱动和固件都是23.0.rc3，但CANN是6.3.rc2，结果ATC转换时老是在"Graph is not ready"这个位置卡住。后来查了昇腾社区的官方兼容性表，才发现CANN 6.3.rc2只支持到22.0.rc1的驱动，跨版本太大，驱动和CANN之间的通信协议对不上。重新刷成7.0.0之后问题就消失了。

注意：昇腾的版本兼容性表是动态更新的，安装前一定要去昇腾社区查一下当前的“驱动固件与CANN版本配套表”，不要凭经验乱配。

2.4 换源和服务配置的小坑

昇腾的pip源是独立的，不在PyPI上。装Python依赖的时候需要指定昇腾源：

pip3 install --upgrade pip pip3 install attrs numpy decorator sympy cffi pyyaml pathlib2 psutil protobuf scipy requests absl-py pip3 install --upgrade --user astroid

另外，CANN自带的Python接口在/usr/local/Ascend/ascend-toolkit/latest/pyACL/python/site-packages/acl下，如果Python import acl失败，多半是PYTHONPATH没设置。建议把以下内容加到.bashrc：

export ASCEND_HOME=/usr/local/Ascend/ascend-toolkit/latest export LD_LIBRARY_PATH=$ASCEND_HOME/lib64:$ASCEND_HOME/lib64/plugin/opskernel:$ASCEND_HOME/lib64/plugin/nnengine:$LD_LIBRARY_PATH export PYTHONPATH=$ASCEND_HOME/pyACL/python/site-packages:$PYTHONPATH

3. YOLOv8模型转换全流程，ATC是核心

3.1 导出ONNX模型

虽然昇腾也支持直接加载MindSpore和Caffe的模型，但现阶段最顺的路径还是走PyTorch → ONNX → OM（昇腾离线模型）。我用的是YOLOv8s，预训练权重在COCO上跑过。

先从ultralytics导出ONNX：

yolo export model=yolov8s.pt format=onnx opset=12 imgsz=640

这里有两个关键点：

• opset版本必须用12或13，不要用更高的版本，ATC对高版本ONNX算子支持不全。
• imgsz建议固定成640，如果你是训练时用608或672这种非标准尺寸，导出时直接改为对应尺寸即可，但推理输入要和它一致。

导出后用onnxsim简化一下，反正不费事：

python3 -m onnxsim yolov8s.onnx yolov8s_sim.onnx

简化的作用是去掉一些冗余的Identity节点和Shape节点，ATC转换时能少报几个Unsupported Operator。

3.2 ATC转换OM模型，参数详解

ATC转换是整条链路里最需要耐心的环节。命令我贴出来，后面逐个参数说：

source /usr/local/Ascend/ascend-toolkit/set_env.sh atc --model=yolov8s_sim.onnx \ --framework=5 \ --output=yolov8s_bs1 \ --input_shape="images:1,3,640,640" \ --soc_version=Ascend310P3 \ --insert_op_conf=aipp.cfg \ --precision_mode=force_fp16 \ --output_type=FP32 \ --optypelist_for_implmode="Sigmoid" \ --op_select_implmode=high_performance

每个参数说明：

• --framework=5，5代表ONNX。
• --output，输出文件名，不写后缀，自动生成.om。
• --input_shape，ONNX模型的输入节点名是images，维度是(batch, channel, height, width)。如果你导出的ONNX输入节点叫别的名字，用netron查看。
• --soc_version，必须填Ascend310P3或者Ascend310P4，具体看你的卡是哪个芯片版本，用npu-smi info能看到。填错了会报错，提示当前的SoC版本不匹配。
• --insert_op_conf，AIPP配置文件路径，这个后面单独说。
• --precision_mode=force_fp16，强制用FP16计算。昇腾的FP16性能远好于FP32，YOLOv8的精度损失可以忽略。
• --output_type=FP32，输出层用FP32，避免输出结果精度被压缩导致框坐标偏移。
• --optypelist_for_implmode和--op_select_implmode，让Sigmoid算子走高性能实现，对YOLOv8的置信度分支速度有优化。

如果转换成功，会生成yolov8s_bs1.om文件。转换过程大概需要几分钟，期间CPU占用会比较高，注意不要同时开太多任务。

3.3 AIPP配置，图像预处理交给NPU

AIPP（AI Preprocessing）是CANN里一个非常强大的功能，能把图像缩放、归一化、通道变换这些操作统统塞进模型里。这样的话，在推理时，你直接往NPU塞原始BGR图像就行，不需要在CPU上做复杂的预处理，省掉一部分CPU开销。

我的aipp.cfg：

aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: false load_start_pos_h: 0 load_start_pos_w: 0 min_chn_0: 0 min_chn_1: 0 min_chn_2: 0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }

要点是：

• input_format必须和你的输入数据一致。YOLOv8的预处理是把图片缩放到640x640，BGR顺序，像素值归一化到0-1，所以这里写RGB888_U8其实不太对，应该用BGR888_U8。这个我踩过坑，后面问题列表里再展开。
• var_reci_chn是归一化系数，0.003921569就是1/255，YOLOv8的归一化方式就是直接除以255。
• 注意很多显卡在推理时要RESIZE，如果模型是640输入，你ffeeding时应该已经resize好再传给NPU。如果想让NPU自己完成resize，需要在AIPP里配置resize参数，但这样会多一步操作，效率上反而不如自己先在CPU上做letterbox再传进去。

3.4 动态batch和多batch的处理

我自己的场景里，经常要同时处理十几路视频流，每路视频的画面数量不一样，所以需要支持动态batch。

ATC转换时用dynamic_batch_size参数：

atc --model=yolov8s_sim.onnx \ --framework=5 \ --output=yolov8s_dynbs \ --input_shape="images:-1,3,640,640" \ --dynamic_batch_size="1,2,4,8,16" \ --soc_version=Ascend310P3 \ --insert_op_conf=aipp.cfg \ --precision_mode=force_fp16 \ --output_type=FP32

注意，动态batch的模型在推理时需要在设备端动态设置batch大小，代码里要做适配，稍微麻烦点。如果你的业务场景里batch大小基本固定，比如总是处理固定4路或8路视频，直接用固定batch的模型就好，性能和稳定性都更好。

4. 用Python实现YOLOv8推理，可以先跑起来再优化

4.1 用pyACL实现推理的完整代码

昇腾的底层推理接口是AscendCL（ACL），可以用C++调，也可以用Python调。我先用Python跑通全流程，验证精度没问题之后，再用C++做正式的服务化部署。

首先初始化环境和设备：

import acl import numpy as np import cv2 import time # 初始化ACL ret = acl.init() assert ret == 0 # 设置推理设备，0表示第一张卡 ret = acl.rt.set_device(0) assert ret == 0 # 创建上下文 context, ret = acl.rt.create_context(0) assert ret == 0 # 加载OM模型 model_path = b"./yolov8s_bs1.om" model_id, ret = acl.mdl.load_from_file(model_path) assert ret == 0

然后准备输入输出。因为模型输入已经包含了AIPP预处理，所以这里只需要把图像resize到640x640，然后转成BGR格式就行：

def preprocess(image): # image是BGR格式的numpy数组 img = cv2.resize(image, (640, 640)) img = img.astype(np.float32) # 注意这里不再做归一化，AIPP已经处理了 img = img[:, :, ::-1] # BGR转RGB，因为AIPP配置的是RGB888_U8 img = np.transpose(img, (2, 0, 1)) # HWC转CHW img = np.expand_dims(img, axis=0) # 增加batch维度 return np.ascontiguousarray(img, dtype=np.uint8)

这里有个非常重要的点：如果AIPP配了归一化，那你输入的数据类型要用uint8，不要再除以255。我一开始没注意，把uint8的图像直接除255转成float32再送进去，结果检测结果全乱了。

接着把输入数据拷贝到设备端：

# 获取模型输入输出尺寸信息 input_desc = acl.mdl.get_input_desc(model_id) output_desc = acl.mdl.get_output_desc(model_id) input_size = acl.mdl.get_input_size_by_index(model_id, 0) output_size = acl.mdl.get_output_size_by_index(model_id, 0) # 创建设备端输入输出buffer input_data = np.zeros((input_size,), dtype=np.uint8) output_data = np.zeros((output_size,), dtype=np.float32) input_buffer = acl.rt.malloc(input_size, 2) output_buffer = acl.rt.malloc(output_size, 2) # 把图像数据拷贝到设备端 input_data = preprocess(image) acl.rt.memcpy(input_buffer, input_size, input_data.tobytes(), input_data.nbytes, 1)

执行推理：

# 执行推理 dim = acl.mdl.get_input_dim_index(model_id, 0) acl.mdl.execute_async(model_id, [input_buffer], [output_buffer], None, 0) acl.rt.synchronize(context)

推理完成后把输出拷回主机端，然后做后处理。YOLOv8的输出是一个1x84x8400的tensor，84表示4个框坐标加80个类别置信度，8400是不同特征层的anchor总数。

4.2 后处理：坐标还原和NMS

后处理这块每个模型的格式大同小异，但细节上会有差别。YOLOv8的输出格式和YOLOv5不一样，v8没有objectness分支，所以解码逻辑要调整。

def postprocess(output_data, orig_shape, conf_thres=0.5, iou_thres=0.45): predictions = output_data.reshape(1, 84, 8400) predictions = np.transpose(predictions, (0, 2, 1)) # (1, 8400, 84) boxes = predictions[0, :, :4] class_scores = predictions[0, :, 4:] class_ids = np.argmax(class_scores, axis=1) confs = np.max(class_scores, axis=1) # 置信度过滤 mask = confs > conf_thres boxes = boxes[mask] class_ids = class_ids[mask] confs = confs[mask] if len(boxes) == 0: return [] # xywh转xyxy x1 = boxes[:, 0] - boxes[:, 2] / 2 y1 = boxes[:, 1] - boxes[:, 3] / 2 x2 = boxes[:, 0] + boxes[:, 2] / 2 y2 = boxes[:, 1] + boxes[:, 3] / 2 # 坐标缩放回原图尺寸 scale_w = orig_shape[1] / 640 scale_h = orig_shape[0] / 640 x1 *= scale_w x2 *= scale_w y1 *= scale_h y2 *= scale_h boxes = np.stack([x1, y1, x2, y2], axis=1) # 按类别做NMS final_boxes = [] for cls in np.unique(class_ids): idx = class_ids == cls cls_boxes = boxes[idx] cls_confs = confs[idx] keep = nms(cls_boxes, cls_confs, iou_thres) for i in keep: final_boxes.append([*cls_boxes[i], cls_confs[i], cls]) return final_boxes

NMS可以自己写一个简单实现，也可以用opencv的cv2.dnn.NMSBoxes，但注意cv2.dnn在有些版本里API不兼容，建议直接装一个nms工具库：

pip3 install nms

或者手写一个Python实现，逻辑也不复杂，二三十行搞定。

4.3 实测性能参考

我实测下来，在单张Atlas 300V Pro 24G上，YOLOv8s模型640x640输入，FP16推理，batch=1的情况下，纯推理耗时大约12到14毫秒，加上图像解码和前后处理，整体在18到22毫秒左右。如果打开多batch，batch=4的时候，整体吞吐量能到每秒150帧左右。

这个性能是什么水平呢？做一个对比，RTX 4090跑YOLOv8s的纯推理大概是5到7毫秒，但4090的功耗是450W，Atlas 300V Pro的功耗大约75W。如果按每瓦特的推理帧数来算，Atlas 300V Pro在推理任务上的能效比反而更高。

不过要提醒的是，我这里的数据是基于CANN 7.0和特定固件版本测的，昇腾的软件迭代对性能影响很大，同一个模型在CANN 5.1和CANN 7.0下能差出30%的推理速度。所以如果你入手了这块卡，第一步先把CANN升到最新稳定版，再测性能。

5. 部署过程中的常见问题，踩坑实录

5.1 ATC转换时报错Unsupported Operator

这是出现频率最高的问题。YOLOv8导出ONNX后，里面通常会有一些昇腾算子库暂时不支持的算子，最常见的是Einsum、GridSample、Multinomial这几个。

解决办法有几种：

第一种，升级CANN版本，新版CANN会不断补齐算子。我之前在CANN 6.3上转换一直报Einsum算子不支持，升到7.0之后就自动解决了。

第二种，如果升级版本还是不支持，就得手工改ONNX图，把这些算子的计算逻辑拆成几个基础算子的组合。比如Einsum可以拆成MatMul加ReduceSum，GridSample可以拆成Resize加Concat。这个工作量有点大，但也不是不能做。

第三种，换模型结构。比如YOLOv8的多尺度检测头输出层有一堆使用split和concat的操作，如果老版本ATC处理不好，可以试试直接在导出ONNX时把后处理逻辑（比如decode部分）剔除掉，只保留backbone和head的特征输出，后处理全部放在业务代码里做。

我自己实际用下来，最省心的方式是第三种。模型只输出三个尺度的原始特征图（分别对应80x80、40x40、20x20），然后自己在Python代码里做decode和NMS。牺牲一点点推理效率，但换来了极大的灵活性，后续想调整NMS参数、置信度阈值都不用重新转模型。

5.2 推理结果全为0或者框位置不对

这个问题的原因往往不是模型没转对，而是图像预处理和模型训练时的预处理不一致。

YOLOv8训练时用的预处理是：

image = cv2.resize(image, (640, 640)) image = image[:, :, ::-1] # BGR转RGB image = image.astype(np.float32) / 255.0 # 归一化

但如果AIPP配置里已经做了归一化，你再在Python代码里除255，那就是双重归一化，模型输出几乎肯定不对。

还有一种情况是AIPP里写错了通道顺序。我前面提到过，如果输入图像是BGR顺序，但AIPP里配的input_format是RGB888_U8，那相当于把R和B通道互换了，检测出来的物体类别会概率低下，定位框也是飘的。

最简单的排查方法是用一张纯红色图片做测试。如果AIPP配的是RGB888_U8，那么喂进去的BGR图像会把红色通道读取成蓝色，输出类别很可能从red变成blue。反过来就是通道反了。

5.3 显存占用虚高，多模型加载失败

Atlas 300V Pro的24GB虽然不小，但不代表可以无限加载模型。CANN的显存管理和CUDA是两套逻辑，它默认会为每个上下文预留一部分工作内存，如果你的代码里频繁创建上下文却不释放，显存就会慢慢被吃光。

我遇到过一个情况：同一个进程里反复加载和释放模型，第三次加载时直接报ACL_ERROR_RT_MEMORY_ALLOCATION。排查半天，发现是释放模型时只调了acl.mdl.unload_from_model，但没有调用acl.rt.destroy_context释放上下文。

正确做法是每次加载模型前检查上下文数量，用完立刻释放：

acl.mdl.unload_from_model(model_id) acl.rt.destroy_context(context)

另外，CANN环境变量里也可以设置显存池的大小和复用策略：

export ASCEND_GLOBAL_EVENT_ENABLE=0 export ASCEND_GLOBAL_LOG_LEVEL=3

如果觉得自己管理显存太麻烦，可以考虑用MindX SDK的mxVision，它提供了基于pipeline的流式推理框架，显存和Buffer管理由框架自动完成，上手门槛低很多。但要注意，mxVision的灵活度不如直接用pyACL，如果你有一些非常规的预处理逻辑（比如自定义的letterbox方式），在mxVision的plugin里实现会麻烦一些。

5.4 多卡并行时CPU占用过高

插了两张Atlas 300V Pro之后，我一开始是每个进程绑定一张卡，各自做推理。结果发现CPU占用非常高，甚至出现CPU先到瓶颈的情况。

后来排查发现，问题出在图像解码和预处理上，还是放在了CPU做。CANN虽然支持AIPP在NPU上做预处理，但我之前把它关掉了。把AIPP重新打开，并把decode也放到NPU上（利用DVPP硬件解码模块），CPU占用马上从80%降到30%以内。

DVPP的用法是在CANN里创建VP和JPEGD等模块，但代码写起来比较复杂。如果要快速落地，建议直接用MindX SDK，它自带了解码、缩放、归一化等常用插件，可以直接串成一条pipeline。

5.5 一个容易被忽略的硬坑：PCIe带宽

很多人买了Atlas 300V Pro之后只看显存和算力，没注意它是PCIe 3.0 x8的接口。如果服务器主板的PCIe槽位分配不合理，插槽实际工作在x4模式下，推理数据的传输时间会明显变长。

检查办法：

lspci -vvv | grep -A 20 "Huawei"

看LnkCap和LnkSta，如果是8GT/s x8，那就正常。如果是x4或者x2，去BIOS里找PCIe槽位带宽设置，或者换一个槽位。

这个坑在实际部署中很容易被忽略，但因为它的症状非常隐蔽，只是整体耗时变高，不会直接报错。

6. 模型量化与进一步调优

6.1 要不要做INT8量化

前面提到昇腾的INT8性能很好，我建议如果你对精度没那么敏感，或者有足够的数据做校准，可以尝试量化。

CANN提供AMCT（Ascend Model Compression Toolkit）做量化，流程是：

# 准备校准数据集，通常是几百张代表真实场景的图片 amct_onnx --model=yolov8s_sim.onnx \ --input_shape="images:1,3,640,640" \ --data_dir=calibration_images/ \ --output_path=./quant_model

量化后的模型和原模型一样用ATC转换，但精度会有一点损失。我在我们自己的工业质检数据集上测试，YOLOv8s量化后mAP从0.782掉到0.751，损失约3%，推理性能提升约1.8倍，这个性价比还是很高的。

6.2 batch size的选择

如果你的业务不是必须逐帧处理（比如项目里是流式视频分析），强烈建议把batch size提到4或8。我实测batch=1的FP16推理是13毫秒/张，batch=4时平均单张降到7毫秒，batch=8时单张降到5.5毫秒。当batch超过8之后提升就不明显了，反而显存占用上涨明显，所以8左右是一个甜点值。

6.3 多线程推理优化

昇腾的310P芯片是多核架构的，如果单线程跑推理，AI Core的利用率可能只有40%到60%。用多线程并发推理，同一张卡上跑多个推理任务，能明显提高卡的整体吞吐。

CANN里可以用acl.mdl.execute_async_in_thread_async实现多线程异步推理，或者直接用MindX SDK自带的多个推理引擎实例来并发。我最后把视频流分析的服务改成了8线程并发推理，整体吞吐提升了大约1.6倍，卡的利用率从55%涨到了85%。

7. 这套部署方案能不能直接用到生产

从我个人项目经验来看，Atlas 300V Pro 24G部署YOLOv8，完全可以在生产环境里用，但前提是你得接受它的思维方式和GPU不一样。

它不是把CUDA生态里的东西直接搬过来就能跑，而是要走一套新的工具链，从ONNX导出到ATC转换再到ACL推理，每一步都有一些无法跳过的细节。这些东西官方文档都写了，但散落在不同地方，没有一个完整实例把路走通，这也正是我写这篇文章的原因。

最后再分享一个小经验：如果你在部署过程中卡在某一步，不要自己硬扛。昇腾社区的论坛和官方技术支持其实是有人回应的，搜索时不要把关键词限定在中文社区，很多问题在英文版的技术讨论帖里早就有答案。另外，CANN每个版本的Release Notes一定要看，很多时候你以为是自己的代码问题，实际上是CANN新版本改了默认行为，这类问题在Release Notes里都会注明。

我目前正在把这套部署方案扩展到YOLOv8-seg和YOLOv8-pose上，原理类似，只是输出头的解码部分要额外处理。等到跑通了再回来更新。