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 的使用依赖整个昇腾软件栈。最底层的是驱动和固件驱动负责操作系统与硬件的通信固件负责硬件的底层控制逻辑上面一层是 CANNCompute 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 后设置环境变量。建议把环境变量写入~/.bashrcsource /usr/local/Ascend/ascend-toolkit/set_env.sh第四步验证环境。用 Python 导入昇腾的 ACLAscend 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 --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_16 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp_yolov5.cfg \ --output_typeFP16 \ --input_formatNCHW解析一下参数--model输入模型路径--framework55 代表 ONNX 格式CANN 里框架编号5 表示 ONNX1 是 MindSpore2 是 TensorFlow3 是 Caffe--output输出 OM 文件的名称--input_shape固定输入 shape必须和你后续推理的输入一致我固定为 1x3x640x640--soc_version芯片型号Atlas 300V 对应的是 Ascend310P3一定要写对写错会直接报错--insert_op_confAIPP 配置文件用来做图像预处理缩放、减均值、除方差、通道转换等--output_typeFP16模型输出精度推理用 FP16 足够速度比 FP32 快--input_formatNCHW输入数据排列格式这里重点讲一下 AIPP 配置文件因为这是最容易被忽略但又特别重要的环节。AIPPAscend 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/2550.003921569。这样输入图像进入模型前就已经完成了归一化和通道转换推理链路精简了不少。这里的注意点是如果你在训练时用了不同的归一化参数比如 ImageNet 的 mean/stdAIPP 配置要对应修改。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_id0): 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 typemxpi_rtspsrc namertsp_source/ plugin typemxpi_videodecoder namedecoder/ plugin typemxpi_imageresize nameresize/ plugin typemxpi_tensorinfer nameinfer/ plugin typemxpi_objectpostprocess namepostprocess/ /mxpi大致的流程是RTSP 拉流 - 解码 - 缩放 - 模型推理 - 后处理。每个插件点都有对应参数可以调比如解码器输出分辨率、推理 batch、后处理置信度阈值和 NMS 阈值。这样配置完之后直接用 MindX 的 Python API 就能跑起来整体开发效率比纯 ACL 高很多。4. 性能调优与参数选择实测数据与调优经验4.1 输入分辨率和 batch 大小怎么定部署的目标检测模型输入分辨率和 batch 是影响性能和精度最直接的两个参数。YOLOv5s 官方支持 320/416/512/640 等分辨率。分辨率越低推理越快但对小目标的检测效果越差。我实测梳理了一下 Atlas 300V 24G 上的表现输入分辨率单帧延迟FP16推理吞吐假设 GPU 利用率充分适用场景320x320约 8ms约 100 FPS小目标要求低、追求速度416x416约 12ms约 80 FPS常规场景640x640约 20ms约 45-50 FPS均衡场景推荐1280x1280约 45ms约 20 FPS小目标检测或高精度场景上面这部分是估算值实际结果受模型结构、CANN 版本和服务器配置影响会有所不同但量级可以参考。我的经验是工业质检场景优先用 640x640这是一个精度和速度都很均衡的选择。batch 大小方面Atlas 300V 24GB 显存不用省。如果你要跑多路视频流把多路帧拼成一个 batch 一起推理能显著提升整体吞吐。比如 4 路 640x640 视频流单帧拼成 batch4 推理总吞吐比逐个单帧推理高不少。做法是维护一个帧缓存队列攒够 batch 就触发一次推理。我试过的 batch 配置如下batch1适合交互式场景或单路低延迟需求batch4适合 4 路视频流场景batch8适合 8 路以上视频流但对解码和预处理的内存压力也大了这里提一个容易忽略的点OM 模型在转换时如果用--input_shapeimages:1,3,640,640固定了 batch1那推理时就没法动态修改 batch。如果需要在 batch4 下推理转换时就必须指定--input_shapeimages: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_thresholdNMS 的 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 跑 YOLOv5s640x640整数处理方式为 FP16得到的大致结果视频流分辨率 1080p单路推理延迟约 30ms包括解码、预处理、推理、后处理全链路4 路并发 batch4 推理每路平均延迟约 60ms整体 GPU 利用率 70% 左右如果只跑推理不做解码batch8、分辨率 640x640模型吞吐可以达到 500 FPS 量级纯推理部分算的这些数据说明 Atlas 300V 在工业现场跑 YOLOv5s 是绰绰有余的8 路以内的视频流分析完全没有压力。如果你的场景需要更高吞吐可以考虑在单卡上跑多个模型实例例如两个 batch4 的实例或者做 INT8 量化换来更快速度。4.5 INT8 量化要不要上怎么上除了 FP16Atlas 300V 还支持 INT8 量化推理。昇腾的 INT8 量化一般通过 AMCTAscend Model Compression Toolkit来做分两步第一步是执行量化感知训练或校准第二步是转换为 INT8 OM 模型。INT8 量化在算力利用率上比 FP16 高一截推理速度大约能再提升 20%-50%但是精度会有损失。我在实际项目里跑 YOLOv5s用 COCO 验证集测试FP16 的 mAP 大概比原模型低 0.5% 以内基本无损INT8 量化后 mAP 掉 1.5% 左右。如果是简单场景比如人、车这种大目标INT8 完全可以接受如果是小目标和密集场景INT8 得谨慎测试。量化过程大致如下准备校准数据集训练集里抽 500-1000 张图用 AMCT 对 ONNX 模型做量化分析生成量化配置重新用 ATC 转成 INT8 的 OM 模型在验证集上对比 FP16 和 INT8 的精度差异我的建议是阶段一先用 FP16 跑通全部流程确认业务精度没问题再考虑 INT8 优化。别一上来就上 INT8精度问题排查起来非常头疼。5. 部署全流程踩坑记录从零到可用的关键教训5.1 环境安装与模型转换阶段的高频问题问题 1ATC 转换时报错 soc_version 不匹配这个错误非常常见。很多人会写--soc_versionAscend310P或者不写导致报错。必须使用npu-smi info查看卡实际型号后再对照 CANN 的芯片型号对照表选择准确的soc_version比如 Ascend310P3。如果你不确定可以先在目标机器上安装好驱动后查看/usr/local/Ascend/driver/version.info来确定具体的芯片型号。问题 2ATC 转换时提示算子不支持某些 PyTorch 版本导出的 ONNX 可能会包含昇腾暂不支持的算子。解决办法换支持的算子表达方式。比如把上采样、split、slice 等操作改成 ONNX 支持的更基础算子。也可以尝试--precision_modeallow_fp32_to_fp16参数让算子以 FP16 方式跑有时候能绕过某些算子的精度问题。如果还不行就去昇腾社区查算子支持列表看看是否有替代方案。问题 3ONNX 版本太新导致转换失败ONNX 导出的 opset 版本过高时ATC 可能不识别。解决办法是导出时指定较低但足够的 opset比如--opset 11或者--opset 12。我试过 opset 17 导出的模型在较旧 CANN 版本上会报“模型解析失败”换成 opset 11 就一切正常。5.2 推理阶段的问题排查问题 1推理结果全为 0 或者检测框全乱这类问题 90% 出在预处理和后处理不一致上。先确认训练时的预处理是什么是否减均值、是否除以 255、通道顺序是 RGB 还是 BGR再对照 AIPP 配置和实际送入模型的图像数据是否一致。我的排查习惯是先拿一张训练集里的图片用 PyTorch 原模型跑一遍记录输出再在 Atlas 上跑同一张图对比前后输出张量的差异。如果输出差异巨大基本就是预处理配置问题。问题 2npu-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 是否有足够多帧。batch1 和 batch4 的总吞吐差距可能高达 2-3 倍尽量利用大 batch。5.4 与 NVIDIA 方案选型的价格与体验对比最后聊一点选型感受。NVIDIA 生态成熟、文档多TensorRT 转换工具链做得很完善但显卡价格高、功耗也高昇腾这边如果你愿意花时间熟悉 CANN 和 MindX其实部署流程并不复杂而且 Atlas 300V 在推理场景的性价比要明显优于同档 GPU。代价是资料没有 NVIDIA 那么全遇到问题很多时候要自己去试社区和官方工单响应速度不如西方厂商那么快。但话说回来在国产化、低成本推理部署的大背景下把 Atlas 这套工具链跑通是很有价值的事。我在这次项目里最大的体会是别一上来就想着跑通全部而是分阶段验证——环境先通、单张图先通、视频流再通、多路再优化。每一批次只用最小的变量去测试出了问题能立刻定位。尤其是模型转换和后处理这两个环节都是“差之毫厘、谬以千里”的地方耐心对照输出结构和预处理参数要比瞎改参数高效得多。如果你是第一次接触 Atlas建议先拿 YOLOv5s COCO 官方权重完整走一遍全流程确认每个阶段的输出都正确之后再替换成你自己的模型和数据。这个路径走通之后你会发现 Atlas 生态并没有想象中那么难搞反而在边缘侧推理的稳定性上给人不少信心。