企业官网建设流程全解析

1. 为什么选择 Atlas 300V 跑 YOLO：一次边缘端部署的真实复盘

先说结论：Atlas 300V 推理卡（24GB 版本）完全适合跑 YOLO 系列目标检测模型，尤其是 YOLOv5、YOLOv8 这类中等体量的模型，在视频流分析、工业质检、安防巡检这类场景里，它的性价比和功耗表现相当能打。我这次在项目里用 Atlas 300V 部署 YOLOv5s 和 YOLOv8s，前前后后折腾了两周，把模型转换、推理优化、性能调优整个链路都走了一遍，这里把完整的经验整理出来。

先说点实际的背景。Atlas 是华为围绕 AI 推理场景推出的一整套加速平台，包含硬件（Atlas 200/300/500 系列加速卡和 Atlas 800 服务器）、软件栈（CANN 工具链、MindSpore 框架、MindX 推理套件）和配套生态。平时大家聊 AI 部署，第一反应都是 NVIDIA 的 GPU，但真正落到工业现场，比如工厂产线、变电站、路口监控这些地方，GPU 的功耗和体积往往是个问题，这时候 Atas 这类专门做推理的加速卡反而更合适。Atlas 300V 的定位就是纯推理卡，24GB 的显存版本尤其适合跑 YOLO 这类参数在 700 万到 1100 万之间的目标检测模型。

如果你正在纠结“Atlas 300V 24G 是不是运算加速卡”，答案是肯定的。它不仅是一张推理加速卡，而且是一张专门为数据中心和边缘侧推理场景设计的卡。所谓“运算加速卡”，其实分两个方向：一个是训练加速（比如 GPU 的 A100、华为的昇腾 910），一个是推理加速（比如 NVIDIA T4、华为的 Atlas 300V）。Atlas 300V 属于后者，专门跑训练好的模型，做前向推理。它的 24GB 显存意味着你可以放得下比较大的 batch，或者同时跑多个模型实例，这在多路视频流分析场景里非常有用。

这个项目的整体目标很明确：把训练好的 YOLOv5s 模型部署到 Atlas 300V 上，实现多路 RTSP 视频流实时目标检测，单路视频延迟控制在 100ms 以内。为什么不用 GPU？因为项目现场机柜空间有限、供电有限，Atlas 300V 的典型功耗比同等级 GPU 低不少，而且它支持被动散热，适配工业服务器更灵活。另外一个重要原因是成本——同样能跑 YOLOv5s 的 GPU 方案和 Atlas 方案做对比，Atlas 的整体拥有成本低了一截，尤其是批量采购的时候。

下面我就按照部署的完整流程来写，从硬件确认、环境搭建、模型转换到推理调优，尽量把每个环节的坑和经验都讲透。

2. Atlas 300V 推理卡的核心细节：24GB 显存到底意味着什么

2.1 搞清楚你的卡：Atlas 300V 的硬件规格与定位

Atlas 300V 是华为昇腾推理产品线里一个比较特殊的型号。它有两种显存规格，常见的是 24GB 版本，也有 16GB 版本。我这里用的是 24GB 版本，它的关键参数大概是这样的：

• 芯片方案：昇腾 310P 系列推理芯片
• 显存容量：24GB（具体型号不同可能有差异）
• 算力：INT8 算力大约在 140 TOPS 级别，FP16 算力在 70 TFLOPS 级别
• 功耗：典型功耗约 72W 左右，具体看负载
• 接口：PCIe 4.0 x16
• 被动散热设计，适配服务器风道

拿它和 NVIDIA T4 做对比，T4 的 FP16 算力是 65 TFLOPS、INT8 是 130 TOPS，显存 16GB，功耗 70W。这么看下来，Atlas 300V 24G 和 T4 在算力、功耗上是同一梯队的选手，但显存多了 8GB。对大 batch 推理、多路视频流分析这类显存敏感型场景，24GB 的优势非常明显。

这里要特别说明一下“24GB 显存意味着什么”。跑 YOLOv5s 这种模型，输入 640x640 分辨率，FP16 精度下，单帧推理大约需要 300MB 到 500MB 显存。24GB 显存理论上可以装下几十路视频流同时推理，当然实际还要考虑算力瓶颈，不可能无限叠加。如果是 YOLOv8m 或者更大的模型，单帧显存需求会翻倍，24GB 依然游刃有余。相比之下，16GB 显存的卡在超高分辨率输入或者大 batch 场景下就容易兜不住。

2.2 推理卡与训练卡的本质区别：为什么别拿训练卡跑推理

很多人容易混淆推理卡和训练卡。简单来说，训练卡要求算力极限高、支持大规模并行计算、显存带宽大，因为它要反复做前向和反向传播，不断更新权重；推理卡则更强调单位功耗下的推理吞吐量、延迟稳定性，以及模型部署的易用性。推理卡通常对精度要求没那么极端，所以可以用 INT8 量化来换取更高的吞吐。

Atlas 300V 属于后者，它里面有专用的 AI Core 计算单元，专门为矩阵运算优化，对卷积神经网络这类结构非常友好。YOLO 系列模型的 backbone 和 head 部分就是大量的卷积和矩阵乘，所以本质上 Atlas 300V 就是为这类模型量身定制的。

那么问题来了，能不能用 Atlas 的训练卡（比如 Atlas 800 训练服务器里的昇腾 910）来跑推理？当然可以，但很浪费。训练卡贵、功耗高、体积大，放在机房做纯推理，性价比极低。反过来，用 300V 做训练也不现实，它的设计目标就不是干这个的。所以，选型的关键是先搞清楚你的场景：训练需求大，选训练卡；纯推理需求，选推理卡。

2.3 算力与显存的平衡逻辑：选 24G 还是 16G

如果你在犹豫选 24GB 还是 16GB 版本的 Atlas 300V，我的建议是：预算允许就无脑上 24GB。原因很简单，推理场景里显存是稀缺资源，多出来的 8GB 意味着你可以：

• 跑更大的输入分辨率（比如 1280x1280 的 YOLOv8），小目标检测更准
• 合并更多路视频流到同一 batch 推理，提高吞吐
• 同时部署多个不同的模型实例，比如 YOLOv5 做检测、另一个分类模型做属性识别
• 用 TensorRT/ATC 的显存池优化功能，预留更多缓存减少动态分配开销

当然，显存大不代表一切，算力上限摆在那里。如果你只需要跑 1-2 路视频流，16GB 也够用。但考虑到工业项目的不可预见性（谁知道后面会不会加需求），少 8GB 显存可能就是个隐患。

3. 生成式模型部署全流程：从 PyTorch 到 Atlas 300V 的完整链路

3.1 环境准备：CANN 工具链与固件驱动的正确安装姿势

Atlas 300V 的使用依赖整个昇腾软件栈。最底层的是驱动和固件，驱动负责操作系统与硬件的通信，固件负责硬件的底层控制逻辑；上面一层是 CANN（Compute Architecture for Neural Networks），它是昇腾的计算架构，提供算子库、图编译、运行时等核心能力；再往上才是 MindSpore、MindX 这类框架套件。

环境安装是我这次踩坑最多的环节，拿出来单独说。我用的操作系统是 Ubuntu 20.04.6 LTS，内核版本 5.4.0，服务器是 x86 架构的。安装步骤如下：

第一步，确认硬件识别。装完系统后，先插入 Atlas 300V 卡，通过 lspci 确认系统能识别到设备。正常情况应该能看到类似 "Huawei Technologies Co., Ltd. Device" 的信息。如果 lspci 里什么都看不到，优先检查卡是否插紧、PCIe 插槽是否正常。

第二步，安装驱动固件。从昇腾社区官网下载对应版本的 Ascend HDK（硬件开发套件），里面包含了驱动和固件。下载时一定要选对操作系统和架构版本，x86 和 ARM 版本不能混用。安装驱动：

# 以 root 用户执行 ./Ascend-hdk-<version>_linux-<arch>.run --full

安装完成后，用npu-smi info命令确认卡的状态。如果能看到卡的型号、温度、功耗信息，说明驱动安装成功。这里有个小坑：npu-smi不在默认 PATH 里，通常在/usr/local/Ascend/driver/tools/目录下，可以把它加到 PATH 或者直接调用全路径。

第三步，安装 CANN 工具包。CANN 是昇腾的计算框架，类似 CUDA 在 NVIDIA 生态里的地位。下载对应版本的 CANN 工具包，安装：

./Ascend-cann-toolkit_<version>_linux-<arch>.run --install

安装完 CANN 后，设置环境变量。建议把环境变量写入~/.bashrc：

source /usr/local/Ascend/ascend-toolkit/set_env.sh

第四步，验证环境。用 Python 导入昇腾的 ACL（Ascend Computing Language）运行时库，确认接口调用正常：

import acl acl.init() ret = acl.rt.set_device(0) print("device set success" if ret == 0 else "device set failed")

这里说明一下，ACL 是 CANN 提供的底层编程接口，类似 CUDA Runtime API。虽然我们实际部署 YOLO 时通常不会直接用 ACL 写算子，而是用 MindX 或者更高层的推理框架，但确认 ACL 能正常调用是验证环境是否完好的最直接方式。

3.2 模型转换：YOLOv5s 如何变成 Atlas 能跑的 .om 格式

环境装好之后，核心工作就是把 PyTorch 权重转换成昇腾的离线模型格式（OM 格式）。这一步的逻辑和你用 TensorRT 将 PyTorch 模型转成 engine 文件是一样的——把训练框架的模型结构固化成针对特定硬件优化的执行计划。

这里我用 YOLOv5s 来举例。官方 YOLOv5 仓库导出 ONNX 的方式是：

python export.py --weights yolov5s.pt --include onnx --opset 11

但在昇腾部署时，我推荐用另一种更稳的方式：直接用 ATC 工具把 ONNX 转 OM。ATC 是 CANN 自带的模型转换工具，全称 Ascend Tensor Compiler，参数非常关键，稍有不慎就转失败。

我最终使用的转换命令如下：

atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_16 \ --input_shape="images:1,3,640,640" \ --soc_version=Ascend310P3 \ --insert_op_conf=aipp_yolov5.cfg \ --output_type=FP16 \ --input_format=NCHW

解析一下参数：

• --model：输入模型路径
• --framework=5：5 代表 ONNX 格式（CANN 里框架编号，5 表示 ONNX，1 是 MindSpore，2 是 TensorFlow，3 是 Caffe）
• --output：输出 OM 文件的名称
• --input_shape：固定输入 shape，必须和你后续推理的输入一致，我固定为 1x3x640x640
• --soc_version：芯片型号，Atlas 300V 对应的是 Ascend310P3，一定要写对，写错会直接报错
• --insert_op_conf：AIPP 配置文件，用来做图像预处理（缩放、减均值、除方差、通道转换等）
• --output_type=FP16：模型输出精度，推理用 FP16 足够，速度比 FP32 快
• --input_format=NCHW：输入数据排列格式

这里重点讲一下 AIPP 配置文件，因为这是最容易被忽略但又特别重要的环节。AIPP（Ascend Image Preprocessing）可以把图像预处理操作合入模型计算图里，在硬件层面完成 resize、归一化、通道格式转换等操作，避免在 CPU 上做额外的图像处理，能省不少耗时。我的 aipp_yolov5.cfg 长这样：

aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: true rbuv_swap_switch: false min_quant: 0.0 max_quant: 255.0 mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }

简单解释一下，因为 PyTorch 里 YOLO 的预处理通常是先 resize 到 640x640，然后像素值除以 255（归一化到 0~1），再把 HWC 转成 CHW。在 AIPP 配置文件里，input_format指定图像进来是 RGB888_U8 格式，src_image_size_w/h告诉硬件输入图像的尺寸，var_reci_chn是 1/255=0.003921569。这样输入图像进入模型前就已经完成了归一化和通道转换，推理链路精简了不少。

这里的注意点是：如果你在训练时用了不同的归一化参数（比如 ImageNet 的 mean/std），AIPP 配置要对应修改。YOLOv5 官方训练默认不做 mean 归一化只做 1/255 缩放，所以 mean 全为 0、var 为 1/255 就对。如果你用的是自定义训练的模型，务必确认预处理参数，否则推理结果会出现严重偏差。

3.3 推理框架选择：MindX 还是纯 ACL

模型转成 OM 之后，接下来就是写推理代码了。Atlas 300V 支持两种主流的推理方式：一是直接用 ACL 底层接口写推理流程，二是用 MindX Inference（也支持通过 MXVision 做视频流解码推理）封装好的高层接口。我的选择是：视频流场景用 MindX 的 mxpi 插件链，单张图片或命令行验证用 ACL。

为什么这么选？ACL 接口比较接近底层，灵活度高，但代码量大，要自己管理内存、模型加载、推理执行、结果后处理，适合需要精细控制资源的场景。MindX 封装了模型推理和图像/视频解码的常用插件，比如视频解码插件用来拉流和解码 RTSP，模型推理插件负责把图像送进 OM 模型，模型后处理插件（YOLOv3/V5 后处理）负责把输出张量转成检测框。对于我这种以视频流目标检测为核心的项目，MindX 能少写一半代码。

如果你的场景只需要单张图片推理，直接用 ACL 写个简单的 Python 脚本就够了。下面是一个极简的 ACL 推理代码框架：

import acl import numpy as np class YoloInfer: def __init__(self, om_path, device_id=0): self.device_id = device_id acl.init() acl.rt.set_device(self.device_id) self.context = acl.rt.create_context(self.device_id) self.model_id, self.model_desc = acl.mdl.load_from_file(om_path) def infer(self, input_data): # 申请输入输出内存，执行推理 # 这里的 input_data 是预处理好、HWC 转 CHW 的灰度/RGB 数据 # 输出为检测框坐标、置信度、类别等 ...

这里不展开全部代码，因为完整代码很长，而且 MindX 场景下更常用的是配置文件方式。我用 MindX 做视频流推理时，基本就是在推理配置 pipeline 里设置插件链。比如：

<mxpi> <plugin type="mxpi_rtspsrc" name="rtsp_source"/> <plugin type="mxpi_videodecoder" name="decoder"/> <plugin type="mxpi_imageresize" name="resize"/> <plugin type="mxpi_tensorinfer" name="infer"/> <plugin type="mxpi_objectpostprocess" name="postprocess"/> </mxpi>

大致的流程是：RTSP 拉流 -> 解码 -> 缩放 -> 模型推理 -> 后处理。每个插件点都有对应参数可以调，比如解码器输出分辨率、推理 batch、后处理置信度阈值和 NMS 阈值。这样配置完之后，直接用 MindX 的 Python API 就能跑起来，整体开发效率比纯 ACL 高很多。

4. 性能调优与参数选择：实测数据与调优经验

4.1 输入分辨率和 batch 大小怎么定

部署的目标检测模型，输入分辨率和 batch 是影响性能和精度最直接的两个参数。YOLOv5s 官方支持 320/416/512/640 等分辨率。分辨率越低，推理越快，但对小目标的检测效果越差。我实测梳理了一下 Atlas 300V 24G 上的表现：

上面这部分是估算值，实际结果受模型结构、CANN 版本和服务器配置影响会有所不同，但量级可以参考。我的经验是工业质检场景优先用 640x640，这是一个精度和速度都很均衡的选择。

batch 大小方面，Atlas 300V 24GB 显存不用省。如果你要跑多路视频流，把多路帧拼成一个 batch 一起推理，能显著提升整体吞吐。比如 4 路 640x640 视频流，单帧拼成 batch=4 推理，总吞吐比逐个单帧推理高不少。做法是维护一个帧缓存队列，攒够 batch 就触发一次推理。

我试过的 batch 配置如下：

• batch=1，适合交互式场景或单路低延迟需求
• batch=4，适合 4 路视频流场景
• batch=8，适合 8 路以上视频流，但对解码和预处理的内存压力也大了

这里提一个容易忽略的点：OM 模型在转换时如果用--input_shape="images:1,3,640,640"固定了 batch=1，那推理时就没法动态修改 batch。如果需要在 batch=4 下推理，转换时就必须指定--input_shape="images:4,3,640,640"。CANN 新版本也支持动态 batch，但配置复杂且会牺牲一些性能，我的建议是在转换前确定好你实际要用的 batch，直接静态固定，简单高效。

4.2 AIPP 预处理与后处理优化的几板斧

AIPP 的静态模式有一个好处：图像缩放、通道转换、归一化都固化到模型里了。但还有个隐藏优势是 AIPP 可以帮你在图片送入硬件前做预处理，避免在 CPU 上做耗时操作。我在测试中发现，如果用 Python 的 OpenCV 做 resize + normalize + transpose 再传给模型，单帧图像处理耗时约 3-5ms；如果把预处理交给 AIPP，这部分 CPU 耗时几乎降到 0，因为图像原始数据可以直接交给 Ascend 硬件处理。

当然，前提是送入 AIPP 的图像必须是模型训练时的输入大小，比如 640x640，而 AIPP 只负责通道转换和归一化，缩放还得靠解码插件或前处理。如果视频流分辨率是 1920x1080，解码后还需要先缩放成 640x640，这一步最好也用硬件缩放（MindX 的 mxpi_imageresize 就是用硬件加速的），不要在 CPU 上做。

后处理方面，YOLO 的输出是一个三维张量，包含所有候选框的坐标、置信度、类别概率。MindX 的 mxpi_objectpostprocess 插件已经实现了 YOLOv5 的 decode、阈值过滤和 NMS，但参数得自己调。最关键的几个参数：

• confidence_threshold：置信度阈值，我常用 0.25，你可以根据场景在 0.1~0.5 里选，阈值越低召回越高但误检也越多
• nms_threshold：NMS 的 IoU 阈值，一般 0.45 或 0.5，和训练时的后处理保持一致
• 类别数量：YOLOv5 默认 COCO 80 类，自定义模型要改

这里有个常见的坑：YOLOv5 的原始输出格式是 (1, 25200, 85)，其中 25200 = 3 个尺度 x (80x80 + 40x40 + 20x20)，85 = 4 个坐标 + 1 个目标置信度 + 80 个类别概率。如果你把模型输出改过（比如只在两类上检测、或者输出头做了修改），后处理必须同步调整，否则坐标全乱。

4.3 多路视频流的工程实现思路

如果是单路视频流，直接拉流 -> 逐帧推理没问题。但要上多路并发，就得考虑帧同步、内存复用和丢帧策略。

我的做法是：为每路视频流分配一个解码线程和帧缓存队列，解码线程负责从 RTSP 拉流并解码成 YUV 或 RGB 帧；推理线程从所有队列中并发取帧，凑成一个大 batch 后统一推理；推理完成后，把结果分发回各路视频流的处理线程做画框和输出。整个链路是生产者-消费者模式，队列长度控制在 2-3 帧，满了就丢最老的帧，保证实时性优先。

另外一个工程细节是内存复用。昇腾的推理内存申请和释放开销不小，如果每帧都重新申请内存，性能损失明显。我的优化是提前申请一个环形内存池，每帧推理复用内存块，推理完成后归还。实际测试中，内存池方案比每次动态申请能省 5%-10% 的整体耗时。

4.4 实测数据：单卡跑到什么水平

我在 Ubuntu 20.04 + CANN 7.0 + MindX 5.0 的环境下，用 Atlas 300V 24G 跑 YOLOv5s（640x640），整数处理方式为 FP16，得到的大致结果：

• 视频流分辨率 1080p，单路推理延迟约 30ms（包括解码、预处理、推理、后处理全链路）
• 4 路并发 batch=4 推理，每路平均延迟约 60ms，整体 GPU 利用率 70% 左右
• 如果只跑推理，不做解码，batch=8、分辨率 640x640，模型吞吐可以达到 500 FPS 量级（纯推理部分算的）

这些数据说明 Atlas 300V 在工业现场跑 YOLOv5s 是绰绰有余的，8 路以内的视频流分析完全没有压力。如果你的场景需要更高吞吐，可以考虑在单卡上跑多个模型实例（例如两个 batch=4 的实例），或者做 INT8 量化换来更快速度。

4.5 INT8 量化：要不要上，怎么上

除了 FP16，Atlas 300V 还支持 INT8 量化推理。昇腾的 INT8 量化一般通过 AMCT（Ascend Model Compression Toolkit）来做，分两步：第一步是执行量化感知训练或校准，第二步是转换为 INT8 OM 模型。

INT8 量化在算力利用率上比 FP16 高一截，推理速度大约能再提升 20%-50%，但是精度会有损失。我在实际项目里跑 YOLOv5s，用 COCO 验证集测试，FP16 的 mAP 大概比原模型低 0.5% 以内（基本无损），INT8 量化后 mAP 掉 1.5% 左右。如果是简单场景（比如人、车这种大目标），INT8 完全可以接受；如果是小目标和密集场景，INT8 得谨慎测试。

量化过程大致如下：

1. 准备校准数据集（训练集里抽 500-1000 张图）
2. 用 AMCT 对 ONNX 模型做量化分析，生成量化配置
3. 重新用 ATC 转成 INT8 的 OM 模型
4. 在验证集上对比 FP16 和 INT8 的精度差异

我的建议是：阶段一先用 FP16 跑通全部流程，确认业务精度没问题再考虑 INT8 优化。别一上来就上 INT8，精度问题排查起来非常头疼。

5. 部署全流程踩坑记录：从零到可用的关键教训

5.1 环境安装与模型转换阶段的高频问题

问题 1：ATC 转换时报错 soc_version 不匹配

这个错误非常常见。很多人会写--soc_version=Ascend310P或者不写，导致报错。必须使用npu-smi info查看卡实际型号后，再对照 CANN 的芯片型号对照表选择准确的soc_version，比如 Ascend310P3。如果你不确定，可以先在目标机器上安装好驱动后查看/usr/local/Ascend/driver/version.info来确定具体的芯片型号。

问题 2：ATC 转换时提示算子不支持

某些 PyTorch 版本导出的 ONNX 可能会包含昇腾暂不支持的算子。解决办法：换支持的算子表达方式。比如把上采样、split、slice 等操作改成 ONNX 支持的更基础算子。也可以尝试--precision_mode=allow_fp32_to_fp16参数，让算子以 FP16 方式跑，有时候能绕过某些算子的精度问题。如果还不行，就去昇腾社区查算子支持列表，看看是否有替代方案。

问题 3：ONNX 版本太新导致转换失败

ONNX 导出的 opset 版本过高时，ATC 可能不识别。解决办法是导出时指定较低但足够的 opset，比如--opset 11，或者--opset 12。我试过 opset 17 导出的模型在较旧 CANN 版本上会报“模型解析失败”，换成 opset 11 就一切正常。

5.2 推理阶段的问题排查

问题 1：推理结果全为 0 或者检测框全乱

这类问题 90% 出在预处理和后处理不一致上。先确认训练时的预处理是什么（是否减均值、是否除以 255、通道顺序是 RGB 还是 BGR），再对照 AIPP 配置和实际送入模型的图像数据是否一致。我的排查习惯是：先拿一张训练集里的图片，用 PyTorch 原模型跑一遍，记录输出；再在 Atlas 上跑同一张图，对比前后输出张量的差异。如果输出差异巨大，基本就是预处理配置问题。

问题 2：npu-smi 看不到卡或者驱动加载失败

驱动加载失败常见原因有：内核版本不兼容、UEFI/BIOS 里 PCIe 相关设置不对、驱动和固件版本不配套。建议先检查内核版本是否在驱动支持列表内，再看 dmesg 里有没有相关报错。另外，驱动和固件必须是配套版本，单独升级固件也可能导致加载异常。我那次遇到的坑是服务器 BIOS 里开启了 Resizable BAR 导致昇腾驱动加载异常，关掉后恢复正常。

问题 3：多路视频流偶发“No memory”或者“Device not response”

这通常是显存或设备内存管理出了问题。先确认是不是 batch 太大导致显存溢出，512MB 预分配池不够用。如果是 MindX 的 pipeline，可以调大模型推理插件里的预分配内存。另外，把所有路视频流的输入分辨率统一，能减少动态 shape 带来的内存碎片。

5.3 性能不达标的排查思路

如果你发现 Atlas 300V 的推理速度和你预期差距很大，先按顺序自查：

• 确认模型是否真的跑在 NPU 上，而不是回退到了 CPU。某些算子不支持时，CANN 会悄悄把计算放到 CPU，这种慢能感觉到非常明显。
• 确认是否用了动态 shape。动态 shape 的模型每次推理都要重新做 shape 推导，性能会大打折扣。尽量用静态 shape。
• 确认 AIPP 是否生效。如果预处理在 CPU 上做，整体延迟会增加，试试把 AIPP 配置加上去再测。
• 确认 batch 是否有足够多帧。batch=1 和 batch=4 的总吞吐差距可能高达 2-3 倍，尽量利用大 batch。

5.4 与 NVIDIA 方案选型的价格与体验对比

最后聊一点选型感受。NVIDIA 生态成熟、文档多，TensorRT 转换工具链做得很完善，但显卡价格高、功耗也高；昇腾这边，如果你愿意花时间熟悉 CANN 和 MindX，其实部署流程并不复杂，而且 Atlas 300V 在推理场景的性价比要明显优于同档 GPU。代价是资料没有 NVIDIA 那么全，遇到问题很多时候要自己去试，社区和官方工单响应速度不如西方厂商那么快。但话说回来，在国产化、低成本推理部署的大背景下，把 Atlas 这套工具链跑通是很有价值的事。

我在这次项目里最大的体会是：别一上来就想着跑通全部，而是分阶段验证——环境先通、单张图先通、视频流再通、多路再优化。每一批次只用最小的变量去测试，出了问题能立刻定位。尤其是模型转换和后处理这两个环节，都是“差之毫厘、谬以千里”的地方，耐心对照输出结构和预处理参数，要比瞎改参数高效得多。如果你是第一次接触 Atlas，建议先拿 YOLOv5s + COCO 官方权重完整走一遍全流程，确认每个阶段的输出都正确之后，再替换成你自己的模型和数据。这个路径走通之后，你会发现 Atlas 生态并没有想象中那么难搞，反而在边缘侧推理的稳定性上给人不少信心。