上个月被一个视频流人形检测项目卡了两天——客户指定要用Atlas 300V 24G跑YOLOv5。一开始我挺不以为然的不就是一块推理卡吗GPU上怎么落地搬到这块卡上复制一遍不就完了结果从驱动、固件到模型转换、推理代码每一步都和NVIDIA那套逻辑不一样。光模型转换成功但推理输出全是0这一个问题就排查了一整天才找到根因。这篇文章把我从零到一在Atlas 300V 24G上部署YOLO的完整经历整理出来也一并解答很多人反复在搜的问题——Atlas 300V 24G到底算不算运算加速卡。如果你手里正好有这块卡或者正在纠结要不要买它来做atlas部署yolo这篇应该能帮你省掉不少弯路。1. 先回答那个热搜问题Atlas 300V 24G到底算不算运算加速卡这个问题问的人太多了网上答案又含含糊糊。我的判断很明确它算加速卡但它是AI推理加速卡不是传统意义上那种通用运算加速卡。你要是拿它当GPU用会失望你要是拿来跑神经网络推理它确实能打。1.1 从芯片看它的本质Atlas 300V 24G用的是昇腾310P处理器这是一颗专门给AI推理场景设计的SoC。芯片里边最核心的计算单元是AI Core采用达芬奇架构细分为Cube单元和Vector单元。Cube专门做矩阵乘加运算神经网络的卷积和全连接基本都是矩阵运算所以这个单元的效率非常高Vector单元负责激活、Pooling这类向量运算。这和GPU的SMStreaming Multiprocessor思路类似但更聚焦。GPU要兼顾图形渲染和通用并行计算里面有很多通用逻辑而310P几乎把资源都给了神经网络相关的算子。所以纯拼推理它是为这个场景量身定做的。至于那个24GB我拿到手第一反应是这么小一张半高卡24G显存实际它是板载LPDDR4X内存作用跟显存类似用来放模型权重和中间特征图。24G这个容量在推理卡里确实算很大了T4也就16G这卡能同时装下好几个大模型这也是它最吸引人的地方。1.2 和GPU加速卡的核心差异很多人问是不是运算加速卡其实是拿NVIDIA的思维来理解它。我先放个直观对比对比项Atlas 300V 24GNVIDIA T4说明芯片类型昇腾310PNPUTU104GPU一个专用一个通用主要场景AI推理推理通用计算T4能干的更多但更贵开发接口AscendCL / CANNCUDA / TensorRT两套完全不同的工具链模型格式ONNX转OMONNX转TensorRT engine概念上很像但细节完全不同通用并行计算基本不支持支持CUDA生态这是最大的分水岭功耗约70W级别70W都适合低功耗部署从这张表能看出来如果运算加速指的是CUDA上的科学计算、并行浮点运算那Atlas 300V基本帮不上忙——它跑不了CUDA程序也不会有任何社区给你适配开源的GPGPU代码。但如果你说的运算是指AI推理那就是它的主场。YOLO、OCR、人脸识别、语音识别、NLP分类这种模型的推理它都能跑而且跑得不慢。1.3 它能做什么、不能做什么我根据自己的使用经验把这个卡的边界划一下能干的事YOLO系列目标检测推理包括YOLOv5、YOLOv8、YOLOX多路视频流分析24G内存可以同时加载多模型或多个batchOCR、分类、分割、语音等常见模型的部署在CANN的框架适配层支持下也能做小规模训练微调但这不是它的优势干不了的事直接运行CUDA代码现有GPU项目不能无脑迁移大规模训练算力规模和生态都不支持依赖GPU通用计算库如cuBLAS、cuDNN的工程需要全部重写一句话总结这块卡是偏科生专攻推理。选它之前想清楚你的场景是不是推理是就买不是就老老实实上GPU。2. 部署YOLO前必须看懂的环境三件套驱动、固件、CANN我在装环境的时候踩了不少坑最大的坑就是没搞明白这三样东西的关系和安装顺序。如果你跟我一样是长期用NVIDIA生态过来的这套东西会让你很不适应——CUDA装个驱动就能跑但Atlas这套要装三个东西少一个都不行。2.1 三件套到底是什么关系我打个比方帮助理解驱动让操作系统认到这张卡生成/dev/davinci0这样的设备节点。相当于Windows里显卡驱动让系统看到显卡。固件跑在芯片内部的底层软件管着AI Core的调度。相当于显卡自己的BIOS和微码驱动管系统侧固件管卡侧。CANN完整的开发套件包含ATC模型转换工具、AscendCL推理API、算子库、运行时等。这就好比CUDA TensorRT cuDNN打包在一起的集合。不装驱动系统认不到卡不装固件驱动起来了但卡起不来没有CANN你连模型转换和推理API都没有。2.2 我实际用的安装流程我的机器是x86架构的Ubuntu服务器插上Atlas 300V 24G后直接去昇腾社区下载对应版本的驱动、固件和CANN Toolkit。这里重点说一句版本一定要查配套表。CANN 7.0对驱动的版本有要求版本对不上轻则npu-smi看不到卡重则驱动加载失败。我当时是用CANN 7.0.RC1配昇腾HDK 23.0.rc1那套稳定跑到现在。安装命令大致是这个流程# 1. 先装驱动 ./Ascend-hdk-310P-npu-driver_23.0.rc1_linux-x86_64.run --full # 2. 再装固件 ./Ascend-hdk-310P-npu-firmware_23.0.rc1_linux-x86_64.run --full # 3. 最后装CANN Toolkit ./Ascend-cann-toolkit_7.0.RC1_linux-x86_64.run --install # 4. 配环境变量 source /usr/local/Ascend/ascend-toolkit/set_env.sh候一下那个--full参数是完整安装的意思也可以直接不带参数跑完默认流程。装完驱动和固件后需要重启服务器。2.3 装完立刻验证三件事很多人在这一步跳过去直接开搞模型结果后面全乱套。我建议装完先做三个验证# 验证1能看到卡且Health Status为OK npu-smi info # 验证2ATC工具能用 atc --version # 验证3确认SoC版本号后面ATC转换必须用 # 通过npu-smi info查看Chip Version常见是Ascend310P3第三条很多人忽略但它极重要。ATC转换时需要指定--soc_version比如Ascend310P3填错了虽然能转但跑到卡上会报错或者干脆加载不了。我当时就是用npu-smi info看到了Chip Version才确定该填什么的。另一个建议把source /usr/local/Ascend/ascend-toolkit/set_env.sh写进~/.bashrc不然新开终端就找不到atc命令很容易误以为没装好。3. YOLO模型落地的第一站PyTorch权重转ONNX环境好了接下来就是模型本身。很多人以为把.pt权重扔给工具就能转成Atlas能跑的格式其实中间必须经过ONNX这一步。这一步做不好后面ATC转换会非常痛苦。3.1 为什么绕不开ONNXCANN的ATC工具能吃的输入格式就那么几种ONNX、Caffe的prototxt/caffemodel、MindSpore的IR。PyTorch权重不能直转OM所以先用PyTorch导出ONNX是标准路径。这步的核心目标不是导出来就完事而是导出推理友好的ONNX。也就是说要去掉一切训练和调试相关的东西只保留正经前向推理需要的算子。YOLOv5和YOLOv8官方都提供了export.py脚本但我建议自定义导出而不是直接用默认参数原因后面说。3.2 导出ONNX的命令和参数以我用的YOLOv5s为例python export.py --weights yolov5s.pt \ --include onnx \ --opset 13 \ --img 640 640 \ --batch-size 1YOLOv8的话类似yolo export modelyolov8s.pt formatonnx opset13 imgsz640 batch1有几个参数我劝你一定注意第一opset版本。我用的是13。版本太低有些算子结构不好版本太高ATC可能认不了。如果你ATC转换时报算子不支持的错先把opset改到13试试这是在实践中成功率最高的组合。第二--batch-size 1还是--batch-size N。这直接影响后面的--input_shape。先固定成1把流程跑通后面调吞吐再重新导出batch4或8的ONNX转换一次拿到对应OM。动态batch在Atlas上不是不能用但性能和稳定性不如静态batch我后面调优部分会细说。第三不要带NMS。YOLOv8导出时有个--nms参数如果你把它加上ONNX里就会包含NMS算子而ATC对NMS这类后处理算子的支持很一般即使转换成功推理耗时和精度也可能出问题。我的做法是模型只负责输出原始检测结果NMS放在代码后处理里用CPU做。在视频流场景下这个取舍非常值。3.3 导出之后必须做的两个检查导出之后别急着转ATC先做两个检查。第一个用Netron打开ONNX看一眼结构确认输出节点是什么名字、什么shape。YOLOv5导出后通常是单输出节点outputshape是1×25200×85即5个框属性中心点xy、宽高、置信度加80个类别概率。YOLOv8则可能是多个头输出或一个组合输出具体节点名看Netron才知道——后面ATC命令的--out_nodes要用这些名字。第二个用ONNX Runtime在CPU上跑一遍确认ONNX结果和PyTorch原模型结果一致。这一步便宜又保命。我习惯写个几行脚本import onnxruntime as ort import numpy as np sess ort.InferenceSession(yolov5s.onnx) dummy np.random.randn(1, 3, 640, 640).astype(np.float32) outputs sess.run(None, {images: dummy}) print([o.shape for o in outputs])如果这一步输出shape跟你预期一致再进下一环节。如果不对先回头修导出参数不要带着坏模型去做ATC。4. ATC转换从ONNX到OM的完整过程ONNX是通用格式OM是昇腾专属格式。ATC工具干的事就是把ONNX翻译成Atlas能高效执行的OM。这一步是Atlas部署YOLO特有的环节也是新手最容易翻车的地方。4.1 一条ATC命令的参数拆解以YOLOv5s为例我当时执行的转换命令长这样atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_aipp \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --insert_op_confaipp.cfg \ --output_typeFP16 \ --loginfo逐条说明参数含义踩坑提醒--framework55表示输入是ONNX不要写成其他值--soc_version指定芯片型号必须和npu-smi info看到的版本一致--input_shape指定输入节点的shape格式是节点名:维度节点名要和ONNX里的input_name完全一致--insert_op_conf插入AIPP预处理配置可以把归一化、格式转换全部搬到NPU上--output_type指定输出数据类型我用的FP16后处理在CPU上做也能接受--input_shape里的节点名images要和ONNX输入节点名一致。我第一次用YOLOv8导出时没注意节点名写成了images结果ATC直接报错说找不到这个名字。用Netron看一眼就解决。4.2 AIPP配置把预处理塞进模型这个AIPP配置是Atlas平台非常独特的一个东西用途是把图像预处理放到NPU上而不是让CPU用OpenCV去缩放、归一化。先给一个我用的配置模板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_chn_0: 0.0 min_chn_1: 0.0 min_chn_2: 0.0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }这段配置的意思输入图像是RGB888格式、640×640大小不做CSC颜色空间转换不交换R和B通道三个通道的归一化系数都是1/255也就是把像素值从0-255缩放到0.0-1.0。这里有个大坑我必须要提醒AIPP并不适合直接替代YOLO的letterbox预处理。YOLO训练时会把图像等比缩放后填充到640×640四周补灰边。AIPP的静态缩放只做简单的拉伸缩放没法做等比补边这个逻辑。如果你用AIPP直接把一个1920×1080的图硬缩到640×640宽高比变了检测精度会崩得一塌糊涂。我的做法是在CPU上先做好letterbox把图像处理成640×640的RGB图AIPP只负责把U8转成FP32并除以255。这样CPU开销小精度也保住了。等后面想进一步压CPU耗时再研究AIPP的Dynamic模式支持动态输入尺寸——那个配置更复杂建议先把静态流程跑通。4.3 ATC报错的一般排查路径ATC转换失败太常见了你搜atlas部署yolo相关的报错翻来覆去就那么几类。我把排查思路按优先级排一下第一类报错SoC version is invalid。看看--soc_version填的是不是npu-smi info里显示的芯片版本很多人写成Ascend310P少了一个3过不了。第二类报错算子不支持。比如报Unsupport operator xxx。先从日志里定位是哪个层、哪个算子再去查昇腾算子支持列表。很多时候是ONNX里带了不常见算子导致的解决办法就是把opset版本调整到13再重新导出ONNX。如果还不行升级CANN版本通常能解决。第三类报错shape不匹配。一般是你--input_shape里写错了输入节点名或维度。用Netron确认一遍节点名再跑。ATC转换成功后会在当前目录生成一个.om文件。我习惯用--loginfo生成详细日志成功了把om文件大小记录下来——太小的omp十有八九有问题通常几十MB的om是正常的。5. 用AscendCL写推理代码ACL的流程骨架与避坑点模型有了接下来就是写推理程序。Atlas上推理的API接口叫AscendCL缩写ACL。写起来基本是固定流程核心概念弄懂之后代码就是套模板。5.1 ACL的五个核心概念Device物理卡编号从0开始对应CUDA里的device。Context上下文类似进程级的环境一个进程至少创建一个。Stream执行流算子按流串行或并行执行类似CUDA stream。Model加载到内存里的OM模型实例加载后得到一个modelId。Dataset输入/输出缓冲区的集合ACL用aclmdlDataset把多个数据Buffer包起来传给执行接口。如果你懂CUDA这四个概念跟CUDA的device、context、stream、engine非常像。ACL就是把NVIDIA那套模型工程化了一遍只是换了个名字。5.2 推理流程骨架代码我贴一段简化但完整的ACL推理核心流程用C写#include acl/acl.h // 实际工程中记得封装RET_CHECK我这里偷懒省略了 int main() { // 1. 初始化 aclInit(nullptr); int32_t deviceId 0; aclrtSetDevice(deviceId); aclrtContext context; aclrtCreateContext(context, deviceId); aclrtStream stream; aclrtCreateStream(stream); // 2. 加载模型 uint32_t modelId; aclmdlLoadFromFile(yolov5s_aipp.om, modelId); // 3. 获取模型输入输出信息 aclmdlDesc *desc aclmdlCreateDesc(); aclmdlGetDesc(desc, modelId); size_t inputSize aclmdlGetInputSizeByIndex(desc, 0); size_t outputSize aclmdlGetOutputSizeByIndex(desc, 0); // 4. 申请设备侧内存并拷贝输入 void *inputBuf nullptr; void *outputBuf nullptr; aclrtMalloc(inputBuf, inputSize, ACL_MEM_MALLOC_HUGE_FIRST); aclrtMalloc(outputBuf, outputSize, ACL_MEM_MALLOC_HUGE_FIRST); // host_input就是letterbox处理后的640x640x3的RGB数据 aclrtMemcpy(inputBuf, inputSize, host_input, inputSize, ACL_MEMCPY_HOST_TO_DEVICE); // 5. 组装Dataset aclmdlDataset *inputDataset aclmdlCreateDataset(); aclDataBuffer *inputData aclCreateDataBuffer(inputBuf, inputSize); aclmdlAddDatasetBuffer(inputDataset, inputData); aclmdlDataset *outputDataset aclmdlCreateDataset(); aclDataBuffer *outputData aclCreateDataBuffer(outputBuf, outputSize); aclmdlAddDatasetBuffer(outputDataset, outputData); // 6. 执行推理 aclmdlExecute(modelId, inputDataset, outputDataset); // 7. 把输出拷回主机侧 float *host_output new float[outputSize / sizeof(float)]; aclrtMemcpy(host_output, outputSize, outputBuf, outputSize, ACL_MEMCPY_DEVICE_TO_HOST); // 8. 后处理解析1x25200x85的输出置信度过滤 NMS // 这部分逻辑训练时怎么写的就怎么写注意坐标要映射回原图尺寸 // 9. 释放资源 aclmdlUnload(modelId); aclmdlDestroyDesc(desc); aclrtFree(inputBuf); aclrtFree(outputBuf); aclrtDestroyStream(stream); aclrtDestroyContext(context); aclrtResetDevice(deviceId); aclFinalize(); return 0; }这段代码把整个链路串起来了。编译的时候要链接ascendcl库头文件在/usr/local/Ascend/ascend-toolkit/latest/include。如果是Python场景用pyACL接口思路完全一样先acl.init()再acl.rt.set_device(0)然后acl.mdl.load_from_file(...)。5.3 输入内存和通道顺序的坑这part我踩过必须说第一aclrtMalloc拿到的设备内存已经是对齐的你不用自己再额外对齐。但host侧输入缓冲区最好按64字节对齐分配我用posix_memalign或直接new float数组都行实测不齐也没出过事但为了稳妥建议对齐。第二通道顺序一定要和AIPP配置一致。如果AIPP的input_format是RGB888_U8那你拷给它的数据必须是RGB排列。OpenCV读图默认是BGR很多从GPU工程迁过来的人习惯先cvtColor一下导致数据变成RGB又来一遍AIPP里配的是RGB结果颜色全乱。我的做法是统一约定AIPP里用RGB888_U8host侧OpenCV读进来后立即转成RGB再喂给inputBuf。第三执行结束后输出buff里是FP16还是FP32取决于ATC的--output_type。如果你用了--output_typeFP16后处理解析时要按半精度去读我图省事喜欢在ATC里直接输出FP32反正1×25200×85的数据量不大带宽损失可以接受。6. 实测性能与调优方向从能跑到跑得快模型能出框了只是第一步。部署上线讲的是吞吐和延迟这一节聊聊我实测的数据和调优经验。6.1 一串可参考的推理耗时我拿自己的Atlas 300V 24G实测过几个模型输入都是640×640单batchFP16推理模型输入尺寸单帧耗时实测环境说明YOLOv5s640×6406~9msx86服务器CANN 7.0YOLOv8n640×6404~6ms同上YOLOv8s640×64012~16ms同上YOLOv5s batch4640×64020~28ms折合单帧5~7ms这个数据在不同驱动版本、不同主板上会有浮动但量级可以参考。整体来说YOLOv5s这种轻量模型在单batch下能做到10ms以内对于大多数视频流场景已经够用——一路25fps的视频流单帧6-9ms完全能扛住。6.2 调优三板斧第一板斧固定shape不要动态维度。动态shape的OM在推理时会有额外调度开销而且某些算子无法做极致优化。如果你的业务输入尺寸固定是640×640就老老实实用静态shape的OM。第二板斧AIPP把预处理下沉到NPU。我用OpenCV做letterbox 归一化一张图CPU占用大概在3-5ms在24小时跑流的服务上这个开销不容小觑。把归一化和格式转换交给AIPP后CPU上的预处理只剩letterbox的resize和copy操作大概1ms以内。第三板斧多batch攒批推理。最明显的一招。视频流场景通常有多个摄像头与其逐帧推理不如攒够4帧或8帧一起推理。batch4时总耗时20-28ms折合单帧5-7ms比单帧6-9ms还低。代码上只需要把输入buffer从1×3×640×640改成4×3×640×640然后按顺序填4帧数据推理后循环处理4份输出即可。注意batch维度的内存布局如果训练时是NCHW那在host侧组batch时就要严格按NCHW顺序把4张图的通道拼接在一起不是简简单单把四张图的字节连起来。6.3 部署方式的选择模型和代码跑通后部署形态是个性价比问题。我试过两种给个参考裸机部署直接把ACL编译出来的可执行文件放到目标机上跑之前确认目标机装了驱动、固件和CANN Runtime。这种方式最直接但环境隔离差多业务混跑时依赖冲突风险高。Docker部署用昇腾官方提供的CANN镜像启动时把设备节点挂进去docker run -it \ --device/dev/davinci0 \ --device/dev/davinci_manager \ -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \ ascendai/cann:7.0.rc1-ubuntu20.04容器部署的坑主要是设备节点没挂全。如果容器内报open device failed先检查这三个东西挂没挂/dev/davinci0、/dev/davinci_manager、/usr/local/Ascend/driver目录缺哪个补哪个。7. 我在Atlas上反复踩过的三个坑完整排查链路最后这部分我想单独列一节把我遇到的最典型的三个坑以及完整的排查链路写出来。这三个坑不是网上随便能搜到的标准答案是我一步步debug debug出来的。7.1 坑一模型转换成功推理输出全是0现象OM转换成功ATC日志无报错推理执行也返回成功但输出的25200个候选框的置信度和坐标全部是0。排查过程我当时第一反应是模型转换出了问题于是重新用ONNX Runtime跑了一遍ONNX结果完全正常。这说明ONNX模型没问题。接着怀疑AIPP配置有问题。我把AIPP配置里的归一化系数删掉换成完全不预处理区分到底是不是预处理环节的问题——结果输出依然全0。此时基本确定问题出在输入数据上。后来我把输入图像dump下来发现喂进去的数据颜色不对——蓝色和红色的物体完全反了。原来我的代码里用OpenCV读图得到BGR然后又cvtColor转成RGB但AIPP配置里input_format已经是RGB888_U8等于输入数据被转了两次颜色空间。根因和解决统一一次转换就行。我的做法是AIPP输入格式设为RGB888_U8代码里OpenCV读图后cv::cvtColor(bgr, rgb, cv::COLOR_BGR2RGB)一次之后不再做任何通道处理。改完输出立刻正常目标框全出来了。这个坑的深层教训是Atlas的数据流是从host内存到设备内存再到AI Core中间每一步都会影响最终结果。排查时要从最后一步往前推先验证输入数据对不对再验证输出解析对不对最后才去怀疑模型转换。7.2 坑二ATC转换报算子不支持现象转换YOLOv8s导出的ONNX时ATC报了一个不常见算子的unsupported错误。日志里能看到类似Unsupport op type xxx的信息。排查过程第一次看到这个错我第一反应是CANN版本太旧但同事同一套CANN转YOLOv5s没问题所以更可能是YOLOv8导出的ONNX结构里带了ATC不认得的算子。我先用--loginfo重新跑了一遍把完整日志保存下来用grep -E ERROR|Unsupport atc.log定位到具体的算子名。查了昇腾社区算子支持列表发现那个算子在高版本才支持。然后我尝试两件事一是把导出的opset从17降到13重新导ONNX二是升级CANN版本。结果降opset后问题依然存在升级CANN后顺利转换成功。根因和解决模型里的算子版本和ATC工具内置算子库的版本是有匹配关系的。当你用新框架导出的ONNX遇到老版本ATC转换不了时优先想到升级CANN而不是自己手工改ONNX——手工改图又慢又容易引入新问题。这个坑的教训是YOLOv8s转不过去不代表YOLOv5s能转过去你就不用升级。每个模型的运算图不一样涉及的算子也不一样。有条件的话新项目直接上最新稳定版CANN。7.3 坑三服务器重启后npu-smi找不到卡现象排查完前两个坑后环境终于稳定了。结果某天机房断电重启服务器起来后npu-smi info报找不到设备整个推理服务直接不可用。排查过程先怀疑是驱动没加载系统重启后内核模块没自动加载。但lsmod | grep davinci显示模块已经加载说明驱动层面起来了。接着看dmesg日志搜索davinci相关输出发现有一条固件报错。这时候想起一个细节服务器升级过一次内核从Ubuntu自带的5.4升到了5.15驱动固件还是在旧内核下装的。根因和解决内核升级后旧的驱动模块和新的内核不兼容导致设备初始化失败。解决方法是重新安装一遍和当前内核匹配的驱动和固件版本。装完重启npu-smi info恢复正常。这个坑的教训很朴素Atlas这套东西对内核版本敏感。尽量不要随意升级生产服务器的内核如果非要升级升级后要重新跑一遍驱动固件安装流程并再次验证npu-smi info。7.4 坑四容器内跑ACL报open device failed这个坑是配合Docker部署遇到的。容器里编译好推理程序一运行就报aclrtSetDevice failed: open device failed但宿主机上跑完全正常。根因容器启动时没有把设备节点映射进去。昇腾的推理程序在容器里需要访问/dev/davinci0、/dev/davinci_manager这些设备节点以及宿主机的驱动目录/usr/local/Ascend/driver。缺了这些ACL连不上卡。解决方式就是我前面6.3节那段docker run命令把设备节点和driver目录全部挂载进去问题解决。排查这个坑的链路其实很短先在宿主机跑一遍确认程序没问题再对比容器和宿主机的设备节点差异基本就是挂载遗漏。但如果你是第一次用Atlas容器化部署这个坑几乎必踩。最后分享一个我沉淀下来的习惯每次安装或升级驱动、固件、CANN之后我都会把版本号、内核版本、服务器型号、om文件的转换参数记在一个Markdown文件里。用量大了之后你会发现很多突然跑不动的问题最后都落在版本匹配上。这个习惯救了我好几次也希望能帮你少走几天弯路。Atlas这套东西确实跟GPU的玩法完全不一样。但一旦接受它的规则——静态shape、AIPP、OM中间格式、ACL这套API你会发现它就是一个为了推理场景打磨得相当成熟的工具链。如果你也是从GPU生态转过来的人记得先把这个思维转换做完再动手写代码。
