Atlas 300V推理卡部署YOLO：CANN环境搭建与性能优化指南

1. 一块"运算加速卡"引发的误会：Atlas 300V的真实身份

先说个有意思的事。这几年后台经常收到类似"Atlas 300V 24G是不是运算加速卡"这种问题，回答起来其实有点微妙。你说它不是吧，它确实能把训练好的模型以极快的速度跑起来；你说它是吧，它跟你在工作站里插着的那种动辄400W功耗的GPU又不完全是同一类东西。

搞懂这个区别，比学会部署命令本身重要得多。因为很多人栽跟头，不是栽在技术上，是栽在对这块卡的预期上。

1.1 名字里的"300V"到底意味着什么

Atlas 300V 24G，首先是一块推理卡（Inference Card）。注意"推理"这两个字，"推理卡"三个字。它跟训练卡的分工不一样：训练卡要算梯度、要反传、要支持各种动态shape的频繁变化，所以对算力精度、显存带宽、通用计算能力的要求极其苛刻；推理卡则是在模型已经训练完成之后，专门负责把这套参数跑起来，输入图片、输出结果，就是把"学到的本领"用出来。

24G这个数字指的是板载内存，很多人一看24G就兴奋，觉得"这不跟RTX 3090差不多吗"。但推理卡的24G，跟你熟悉的GPU显存在使用逻辑上有很大差异。推理卡更看重的是内存带宽和并发吞吐，而不是单纯的大显存能塞多少数据。在跑YOLO这类目标检测模型时，24G版本的优势在于可以同时加载多路视频流或者大batch推理，让每张卡的算力被榨得更干。后面实测部分我会给具体数字，这里先记住结论：Atlas 300V不适合训练，它天生是为"上线跑服务"准备的。

1.2 它和GPU、NPU的差别用一句话就能说清

CPU像是一个干杂活的管家，什么都能干但效率一般；GPU像是一群同工种的工人，适合批量化作业；而Atlas 300V里搭载的NPU（神经网络处理单元），更像是专门为神经网络计算定制的流水线车间。它把卷积、矩阵乘、激活函数这些操作用硬件电路直接固化，没有GPU那么多通用计算指令开销。

我用一个更直白的类比：GPU好比是"什么菜都能炒的万能厨师"，NPU更像是"专门做宫保鸡丁的专营店厨子"。你非要让NPU去跑图形渲染、跑物理模拟，它会很难受；但如果你塞给它卷积神经网络，它能在极低的功耗下做到很高的吞吐。

Atlas 300V 24G的典型功耗只有72W左右，而一张RTX 3090满载时功耗能到350W以上。同样跑YOLOv5s，单张Atlas 300V的吞吐能做到RTX 3090的70%-80%，但功耗连后者的四分之一都不到。这意味着什么？意味着一个4U机箱里塞8张Atlas 300V做集群推理，总功耗只相当于两张游戏卡，机房电费直接省出一大截。对于做视频结构化、智慧园区、工业质检这类对功耗和TCO敏感的场景来说，这几乎是为需求量身定做的方案。

2. 物理安装与固件检查：通电之前必须确认的三件事

很多第一次接触Atlas系列卡的朋友，都是兴致勃勃插上卡、装好驱动、跑npu-smi，结果发现设备列表里空空如也，然后开始怀疑人生。我最初也在这个阶段浪费过一整天。后来总结下来，通电之前必须确认三件事：供电是否足够、固件和驱动是否匹配、散热风道是否合理。

2.1 供电和物理插槽的注意事项

Atlas 300V的接口是标准的PCIe 3.0 x16形态，但"形态"不等于"直接插上就能用"。首先是供电，300V 24G虽然功耗低，但它不是纯靠PCIe插槽取电的，卡上有一个辅助供电接口。如果你用的是那种老旧服务器主板，电源功率捉襟见肘，插上两张卡开机直接黑屏或者反复重启的案例我见过不止一次。

所以我的习惯是：装卡前先查一下服务器电源余量。单张卡预留30W的富余量，两张卡就按至少150W额外功耗来规划。另外，PCIe插槽的物理位置也很关键，300V是双槽位厚度（长得像一张厚GPU），如果你主板上已经有其他PCIe设备，要注意散热空间。我的建议是卡与卡之间至少留一个槽位的空隙，否则连续跑满负载时，温度会一路飙到85℃以上，然后就开始降频，推理延迟直接翻倍。

2.2 固件与驱动版本匹配：让无数人"脑溢血"的坎

Atlas卡的驱动、固件和CANN（华为的计算架构，类似NVIDIA的CUDA）三者的版本必须严格对应。这里有个血的教训：某次我图省事，直接下载了最新版CANN 7.0，结果发现驱动版本还是5.x的旧版。跑npu-smi能看到卡，但一跑AscendCL的初始化函数就直接报错，错误码还极其抽象，指向"device open failed"。

后来查官方文档才发现，CANN 7.0要求驱动版本至少是24.1.rc1，旧驱动根本不兼容。所以装环境前，务必先去昇腾社区查"版本配套表"，把固件、驱动、CANN三件套的版本号对齐。这里给一个建议：不要追求最新，追求稳定。选CANN的LTS版本（长期支持版本），对应的驱动固件也一起锁定，除非有明确的新特性需求，否则不要轻易升级。企业环境里，能稳定跑一年不出幺蛾子，比追新酷炫重要得多。

安装驱动和固件时，官方提供了两个脚本：A800-9000-npu-driver_x.x.x_linux-aarch64.run和对应的固件包。执行命令通常是：

chmod +x A800-9000-npu-driver_*.run ./A800-9000-npu-driver_*.run --full

跑完之后务必执行npu-smi info确认卡状态。如果显示"OK"或者正常的芯片温度、内存信息，才算物理安装成功。切忌跳过这一步直接装CANN，不然后面排查问题的时候，你根本分不清是驱动坏了还是CANN没配好。

2.3 散热与风道：数据中心里的人肉踩坑提醒

第三个容易被忽略的是散热。Atlas 300V是被动散热设计，卡上只有散热鳍片没有风扇，完全依赖服务器机箱的系统风扇形成风道。如果你把卡插进一个风道设计很差的塔式工作站，机箱前脸没进风扇，尾部出风扇也不强，那么满载跑YOLO推理时，卡温会直线冲高。

我遇到过一台戴尔的塔式工作站，跑YOLOv5s batch=1时一切正常，改成batch=8之后，跑大概20分钟，推理延迟从12ms慢慢涨到40ms以上。一看温度，核心85℃，板温87℃，卡已经热得开始降频了。解决办法也很朴素：把机箱侧盖打开，加一个外置的12cm风扇对着卡吹，温度直接压回65℃以内。虽然不优雅，但在实验室环境或者机房风道不满意的场景下，这是最有效也最便宜的方案。

3. CANN环境的搭建与AscendCL推理代码的完整落地

环境装好、卡能正常点亮之后，接下来就是搭CANN环境。CANN就是Atlas卡的软件栈，你可以把它理解成CUDA Toolkit之于NVIDIA GPU。所有调用NPU的推理代码，最终都是通过CANN内部的各种运行时库去跟驱动打交道。

3.1 CANN的安装以及几个容易翻车的环境变量

CANN的安装不复杂，就是解压一个.run包然后跑安装脚本。以CANN 7.0为例：

chmod +x Ascend-cann-toolkit_7.0.0_linux-aarch64.run ./Ascend-cann-toolkit_7.0.0_linux-aarch64.run --install

安装完成后默认路径在/usr/local/Ascend/ascend-toolkit/latest。但光装完还不够，必须设置一堆环境变量，而且每次开新终端都要重新source。官方推荐的做法是把初始化脚本加到~/.bashrc里：

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

这一步经常有人漏掉，漏掉之后最典型的症状是：import torch或者from ais_bench.infer import Session的时候，报找不到libascendcl.so或者libtorch_npu.so这类共享库错误。这里多说一句：set_env.sh不只是设置LD_LIBRARY_PATH，它同时还会设置ASCEND_HOME_PATH、ASCEND_OPP_PATH等一系列路径。这些路径决定了CANN能不能找到算子包（OPP）和自定义算子。如果只手动设置了LD_LIBRARY_PATH，还是会有奇奇怪怪的"算子加载失败"问题。

3.2 模型转换：从PyTorch权重到离线模型（OM）

Atlas卡不能直接跑PyTorch的.pt权重文件，它需要的是华为自家的离线模型格式，后缀是.om。这一步是新手最容易困惑的地方，也是"部署YOLO"整个流程里最核心的一环。

转换工具是CANN自带的atc工具（Ascend Tensor Compiler），用法如下：

atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_bs1 \ --input_shape="images:1,3,640,640" \ --soc_version=Ascend310P3 \ --insert_op_conf=aipp.cfg

拆开解释一下这几个参数：

• --framework=5表示输入模型格式是ONNX（数字5对应ONNX，1对应Caffe，2对应MindSpore）。
• --output是输出文件名的前缀，转换完成后会生成yolov5s_bs1.om。
• --input_shape必须跟你后续推理时喂进去的shape一致。YOLOv5s默认输入是640x640，这里batch设为1。如果后面你要优化吞吐，可以额外生成一个batch=4甚至batch=8的om模型，因为Atlas卡在固定shape时的优化最充分。
• --soc_version要根据你的芯片型号填写。Atlas 300V对应的soc version是Ascend310P3，这个值错了，转换直接失败。

aipp.cfg这个文件很多人容易忽略。AIPP是Ascend Image PreProcessing的缩写，它可以把图片的缩放、减均值、除以标准差、通道变换（RGB->BGR）这些操作全部下沉到NPU里做。定义方式大致是：

aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: true load_start_pos_h: 0 load_start_pos_w: 0 crop_size_w: 640 crop_size_h: 640 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 }

这里的作用是：NPU在取图后直接完成缩放和归一化，host端只需要把原始图片像素数据拷过去，省去了在CPU上做预处理的时间。如果你的模型对预处理方式有特殊要求（比如归一化不是简单的1/255），一定要按模型训练时的配置去改写这几个参数。

3.3 推理代码的骨架：AscendCL的会话管理

模型转换好之后，就可以写推理代码了。相比CUDA那一套复杂的cudaMemcpy、cudaStreamSynchronize，AscendCL的编程模型要直白一些，核心就是"创建会话->喂数据->取结果"。

这里我用ais_bench工具做示例，它相当于Atlas上的推理测试工具，把底层API包装成了Python接口。基础用法如下：

from ais_bench.infer import Session session = Session(model_path="yolov5s_bs1.om") outputs = session.run(input_data) # input_data是numpy数组或者二进制文件

如果想自己写更底层的代码，建议直接参考官方给的acl_execute示例。核心流程是：读入图片->预处理成模型需要的shape和格式->acl.mdl.execute异步执行->获取输出->后处理（NMS、画框）。

后处理这里要注意，Atlas卡上的YOLO输出跟PyTorch原版的内存排布略有差异。从模型出来的输出是一个或多个张量，分别对应不同尺度的检测头。我用YOLOv5s为例，输出一般是三个特征图，每个特征图的通道数都是(5+类别数)*3。在Atlas上用AscendCL跑出来，这些特征图是连续内存，你需要自己按stride解析成bbox、置信度和类别概率。

如果你觉得手写后处理太繁琐，可以用昇腾社区开源的ais-bench工具包里的后处理脚本，或者直接接上yolov5官方的utils.plots做NMS。但要注意，YOLOv5官方后处理代码里有些算子Atlas并不直接支持，比如某些版本的torchvision.ops.nms在NPU上没有对应实现。所以实际落到NPU上时，要么把后处理全部改成numpy实现，要么自己写一个简单的TopK+NMS。

我自己更推荐的一种做法是：NMS也下沉到NPU上。Atlas新版本的CANN提供了一个叫DETR的后处理算子集合，能够把NMS放进模型里，输出端直接给最终检测框。这样host端只需要做非常轻量的解析。代价是转换模型时的atc参数要加额外配置，而且NMS的IOU阈值、置信度阈值要在转换时固定下来。适合阈值比较稳定的业务场景，如果是做算法研究频繁调阈值，这个方案就不太灵活了。

4. 实测YOLO部署性能：24G版本到底能压榨出多少吞吐

环境全部搭好、代码能跑通之后，就到了最让人兴奋也最考验人的环节——跑性能。我在Atlas 300V 24G上反复测过YOLOv5s、YOLOv7-tiny以及YOLOv8s，选一组最有参考价值的数据分享给大家。

4.1 单卡多batch推理的实测数据

测试环境为：Atlas 300V 24G + 一颗x86 CPU（仅做数据搬运和后处理），CANN 7.0。测试模型是YOLOv5s，输入640x640，图片来自COCO验证集的随机样本。结果如下：

有个反直觉的地方是：batch从1增加到8，吞吐提升了约45%；但从8增加到16，吞吐反而掉头向下。我一开始以为是卡不行，后来发现是24G版本的内存带宽在batch过大时出现了瓶颈。推理卡跟游戏卡不一样，不是batch越大越好，它有一个甜点区。对于YOLOv5s在640x640输入下，batch=8是300V 24G的舒服区。如果你用的是YOLOv8s这种参数量更大的模型，甜点区会往batch=4偏移。

4.2 多路视频流的并发场景模拟

现在很多项目其实不是单张图调用，而是视频流处理。我用Atlas 300V 24G模拟了多路RTSP视频流解码+推理的场景。每路视频流的帧率设置为25fps，推理模型依然是YOLOv5s。实测下来，单卡能稳定扛住8路视频流同时推理，CPU占用率在40%左右，推理部分稳定在每路8-10ms。

但如果要做"先解码再缩放再推理"的完整业务链路，瓶颈往往不在NPU上，而在CPU做视频解码（用的是FFmpeg软解）以及H2D拷贝上。所以如果你也是做视频流分析的项目，建议把视频解码也放到专门的硬件解码单元上，比如Atlas 300V自带的DVPP硬件解码模块，这样可以彻底把CPU释放出来。DVPP的调用其实也不难，CANN里提供了对应的Python接口，它支持H.264/H.265的硬解码、缩放、抠图等功能。很多人忽略了DVPP，非要自己用OpenCV去处理视频帧，等于白白浪费了卡上一半的硬件能力。

4.3 24G版本和普通8G版本的选择逻辑

有人会问：24G是不是比8G更值得买？我的判断标准很简单：取决于你的batch和并发需求。如果你的模型单帧输入比较大（比如YOLOv8x跑1280x1280）或者需要同时叠很多路流，24G的内存容量能让你放更多中间结果，不用频繁跟host交换数据。但如果你只是跑轻量级的检测，输入小于等于640x640，batch维持在1-4之间，8G版本完全够用，24G的优势体现不出来，还会多花钱。

顺便聊一个技术人员常忽略的运维指标：卡的内存占用率。在Atlas卡上跑模型前，可以用npu-smi info查看每张卡的内存使用率。如果模型加载后内存占用已经超过80%，同时你还想提高batch，那毫无疑问要换更大内存的版本。如果你的内存使用率只有30%，多出来的内存就是闲置资产，这时候更应该考虑的是如何利用多卡并行，而不是死磕单卡内存。

再补充一个非常实用的多卡部署技巧：Atlas 300V可以一张卡跑多个模型，不需要每个模型独占一张卡。在AscendCL中可以通过context设置多个推理会话，同时加载不同模型，物理内存够的情况下互不干扰。我曾在同一张24G卡上同时跑YOLOv5s做人员检测、慢速的YOLOv7做车辆检测，两者的平均延迟都在可接受范围内。这在很多混合业务场景里能省不少硬件成本。

5. 踩坑记录：三个频繁出现的玄学问题及排查链路

部署Atlas卡跑YOLO这个过程，我前前后后踩过不少坑。这里挑三个最有代表性的记录下来，希望能帮后来的人少走弯路。

5.1 问题一：ATC转换失败，报"Op type XXX is not supported"

这是最令我崩溃的一类报错。第一次遇到时，我试图用YOLOv5官方仓库导出的ONNX直接转换，结果atc提示模型里有一个Swish算子的某个变体不支持。排查链路如下：

首先确认了ONNX里有Swish算子，这是SiLU激活函数的一种表达形式，YOLOv5的CSP结构里大量使用。Atlas的ATC对ONNX的算子支持，通常覆盖了大部分常规算子，但某些较新的onnx opset版本或者额外用了onnx-simplifier优化后的模型，遗漏的算子会更多。

这一步的常规解法是：用onnxsim先对模型做简化，把算子尽量融合成通用形式。命令是：

python -m onnxsim yolov5s.onnx yolov5s_sim.onnx

如果简化之后还是不行，那就需要手动替换不支持算子。比如把Swish直接替换成Sigmoid+Mul的组合。这个操作在onnx_graphsurgeon里做起来不难，大致思路是遍历图节点，找到Swish，拆成两个基础算子再重建图。

如果你连图编辑都不想做，还有一个更粗暴但推荐优先尝试的方案：升级CANN版本。旧版CANN对ONNX opset的支持确实不够全，升到新版之后很多算子兼容性问题会自动消失。所以"先升CANN、再onnxsim、最后手动改图"，这是我总结的最省时间的排查顺序。

5.2 问题二：模型可以推理，但输出结果全是0或者nan

这个问题比不支持更折磨人。我一开始怀疑是模型转换丢了权重，反复检查了--output参数和输入数据，都没发现问题。后来仔细对比了原版PyTorch的推理结果和AscendCL的推理结果，发现一个关键线索：输出shape是对的，但数值全部偏差巨大。

进一步深挖后，问题出在aipp.cfg的归一化参数上。我的YOLOv5训练时归一化方式是除以255，但仔细一看，我写的var_reci_chn_0是0.0039215686，这确实等于1/255，看起来没错。问题出在后面的min_chn_0减均值参数。YOLOv5默认不做减均值，只需要除以255，所以min_chn_0应该填0。但当时我参考了一份旧文档，填了训练集的BGR均值，结果等于把像素数据先减了均值再除以255，跟训练时的预处理完全不一致，模型自然输出怪兽值。

这个案例告诉我们一个朴素的道理：AIPP的参数必须跟训练时的预处理完全对齐，差一个减均值都会让模型"说胡话"。排查时，不要看输出数值对不对，先看预处理链路是否跟训练时完全一致。

5.3 问题三：多线程推理时程序卡死或者崩溃

我把推理模块封装成多线程服务后发现，一旦并发超过4个线程，程序就开始随机崩溃，报错地址还每次不一样。用gdb看了core dump，发现崩溃位置在一个叫做aclrtSynchronizeStream的函数里。

排查过程很曲折。后来查明原因：我在每个线程里都创建了独立的aclmdlDesc和aclmdlDataset，但没有为每个线程独立设置aclrtContext。AscendCL的线程模型要求：每个线程在使用NPU之前必须显式绑定一个context，否则多个线程会竞争同一个默认context，导致内部状态错乱。

解决方法是给每个推理线程绑定独立的context，并且加一个互斥锁来控制模型的初始化和销毁过程。核心代码逻辑如下：

import acl # 每个线程初始化时 ret = acl.rt.set_device(device_id) context, ret = acl.rt.create_context(device_id) # 线程结束时 acl.rt.destroy_context(context) acl.rt.reset_device(device_id)

顺带说一句，AscendCL的context模型和CUDA的stream模型不是一一对应的，用CUDA的习惯去套AscendCL，很容易写出隐蔽的并发bug。我的建议是：一开始就严格按照官方多线程示例代码的框架来组织线程和context的关系，不要自创并发模型，等到对底层机制足够熟悉后再做优化。

5.4 排查问题的通用方法论

总结这些坑，我发现它们都有一个共同特征：报错信息并不能直接告诉你根因，甚至报错本身还与根因无关。所以我的排查习惯是：

先是信息收集。用npu-smi info查看卡状态，用dmesg看内核日志，用ascend_install.info确认安装包是否完整。然后是环境复现。写一个最小化的推理demo，不引入任何业务逻辑，单张图片去跑，确认底层链路有没有问题。如果最小化demo正常，再逐步把业务逻辑一层层叠加上去。最忌讳的就是在几十万行的业务代码里大海捞针式地调试NPU相关问题。

6. 部署选项对比：什么时候选Atlas 300V，什么时候选别的

很多新手都会问：同样的预算，我是买Atlas 300V还是买一张二手的NVIDIA游戏卡？这里从项目角度做个很实际的分析。

6.1 Atlas 300V vs 普通GPU推理卡

功耗与机架密度是Atlas最大的优势。Atlas 300V 24G的功耗72W，一个标准的2U服务器里插4张卡毫无压力，整机功耗大约400W出头。同样算力水平的4张NVIDIA GPU，整机功耗至少900W以上，散热和供电的要求也水涨船高。如果部署到边缘机房或者改造过的老旧机柜里，功耗优势直接决定了项目能不能落地。

软件生态是Atlas最大的短板。PyTorch模型转ONNX再转OM，中间过程虽然不复杂但多绕一层，遇到不支持的算子时的确痛苦。而NVIDIA的生态下，很多算法团队训练用的就是PyTorch+GPU，部署到NVIDIA卡上顺理成章。所以我见过很多团队在算法选型时会优先考虑NVIDIA，只有在项目有明确的功耗、成本、国产化要求时，才会选择Atlas。

算力表现上看，Atlas 300V在稀疏卷积和低精度推理上非常有竞争力。它原生支持INT8量化，配合CANN提供的AMCT（Ascend Model Compression Toolkit）做量化后，YOLOv5s的INT8版本相比FP16版本在精度几乎不掉（mAP下降通常不超过0.5%）的情况下，吞吐还能再提升80%左右。如果你的业务场景对精度不是极度敏感，量化是一个比换卡更划算的性能优化手段。

6.2 部署模式的选型：单机多卡、多机集群还是边缘盒子

项目规模不同，选型方案也不同。如果你只是一个千万级图片脱敏或者小流量接口，单张Atlas 300V就够了，不需要考虑复杂的多卡集群。如果是需要处理几十上百路视频流的园区安防项目，那就需要考虑多卡并行甚至多机分布式。

多卡并行有两种方式：一种是用AscendCL在单机内管理多张卡，自己写负载均衡；另一种是用MindSpore或者TensorFlow的分布式接口，让框架去调度。对于YOLO推理场景，我推荐前一种，因为推理服务本质上是无状态服务，自己控制"请求->卡号"的映射更简单可靠。比如可以把卡0指定为处理"人员检测"请求，卡1处理"车辆检测"请求，或者把请求按hash分片到不同卡上，这样应对策略非常简单。

对于边缘场景，我更推荐直接用Atlas 200I DK A2这类开发板。它算力虽然弱于300V，但功耗只有十几瓦，体积小、无风扇设计，适合放在路口机柜、生产车间等环境受限的场景。把YOLO模型部署到边缘盒子里，再将检测结果通过MQTT或HTTP上传到中心平台，这种"端边云"架构目前也是最主流的目标检测落地方案。

7. 个人经验：部署YOLO到Atlas最值得投入时间的地方

最后说点实际操作中我的体会。

从零开始，把一个YOLO模型部署到Atlas 300V上，顺利的话一个下午能完成，不顺利的话三天也正常。但我个人觉得，整个流程里真正值得精雕细琢的不是跑通demo，而是两件事。

第一件是模型预处理链路与训练时保持一致。绝大多数"模型部署后效果变差"的案例，问题都出在预处理不一致，而不是模型被转换坏了。你要把训练代码里的resize方式（是letterbox还是直接拉伸）、归一化方式、通道顺序（RGB还是BGR）逐一对照检查。很多人在PyTorch里用cv2.imread读图已经习惯BGR格式了，结果部署时换了PIL读图又变回RGB，模型输出立刻就乱了。建议从一开始部署就建立一个环境变量来控制预处理模式，把所有配置都沉淀在模型仓库里。

第二件是合理的batch策略和模型量化。我见过太多人部署完之后就丢在那里，每张卡只跑batch=1，利用率低得可怜。实际上稍微花半个下午做一次batch扫描和INT8量化实验，吞吐翻倍是常有的事。量化前先评估业务对mAP的变化容忍度，如果检测框位置和类别精度都还能接受，就没有理由不用INT8。

还有一个我踩过多次的细节，就是模型的动态shape问题。YOLO原版模型在训练时支持任意shape输入，但在Atlas卡的推理部署上，动态shape会有额外的性能开销。如果业务场景里图片尺寸基本固定，建议做一次分辨率对齐（比如统一resize到640x640再进模型），把模型固化到某个固定shape上，这样ATC能给出更激进的算子融合优化方案，性能提升非常明显。我之前有个项目就是图省事一直用动态shape，后来切成固定shape之后延迟直接下降了20%。

做Atlas部署的这段时间，给我最大的感受是：这个平台的资料越来越完善，社区也开始活跃起来，但相比NVIDIA生态的积累仍有差距。不过换个角度看，正因为如此，现在能提前吃透这块卡的人，在未来国产化推理设备需求密集增长时，反而是最有竞争力的那批人。花一周时间把Atlas 300V的部署链路彻底跑通，这个投入绝对不会亏。