1. 先把 Atlas 300V 这块卡看明白1.1 它到底是不是一张“运算加速卡”直接回答热搜那个问题是的Atlas 300V 24G 就是一张标准的 AI 推理运算加速卡而且是一张定位非常明确的国产推理卡。它和玩家熟悉的游戏显卡完全不是一个路子也有人拿它和英伟达的 Tesla 系列做类比——都是“干活的卡”不是“打游戏的卡”。我最早接触 Atlas 300V 的时候第一反应也是先确认它到底能不能正经跑模型。实际用下来它的核心职责就是把训练好的神经网络模型比如 YOLO、ResNet、BERT 这类从 CPU 上解放出来用专用的 AI 计算单元做高效推理。24G 指的是板载显存容量这个容量在推理卡里属于“大杯”配置意味着它可以同时塞下较大的模型或者在 batch 比较大的场景下跑得比较从容。有一点要特别清楚Atlas 300V 不是拿来跑训练的主流选择虽然理论上它也能做一定的训练但它的设计目标是“推理加速”。如果你手头的任务是训练一个 YOLO 模型那还是老老实实用 GPU 集群或者云端完成但如果你要把训练好的 YOLO 模型部署到生产环境让摄像头画面、图片流能以几十上百 FPS 的速度完成检测那这张卡就是非常对口的选择。1.2 这张卡适合放进什么场景拿实际场景来说Atlas 300V 24G 最常见的使用方式有三种。第一种是边缘侧视频结构化服务器。比如一个园区里有几十路摄像头每路画面都要实时做人形、车辆、烟火检测CPU 根本扛不住插几张 Atlas 300V用硬件解码单元把视频流解出来再交给 AI 核心推理最后把结构化结果送到后端整条链路非常顺。第二种是中心侧的推理集群。有些公司会专门搭一个推理资源池把训练好的模型统一部署上去通过接口对外提供检测能力。这时候 Atlas 300V 的 24G 大显存就有优势了可以一次性加载多个模型或者用动态 batch 提高吞吐。第三种是信创/国产化替代项目。如果项目要求核心硬件必须国产那 Atlas 系列几乎是绕不开的选择。之前有个朋友做交通行业的项目客户明确要求 AI 加速卡不能是国外品牌最后就是用 Atlas 300V 顶上去的YOLOv5 检测车辆和车牌效果完全满足需求。我自己的判断是如果你能接受它的软件栈学习成本这张卡在“纯推理”这个细分赛道上性价比很高。24G 显存加上还算扎实的算力单卡价格比同显存的 NVIDIA 推理卡友好不少。但前提是——你得愿意花时间把 CANN 这套工具链玩明白。1.3 和 GPU 推理卡相比差异到底在哪很多人刚上手 Atlas 时最大的不习惯就是它的“脾气”和 GPU 完全不同。这里我总结几个我自己体会最深的差异点。软件栈不同GPU 生态是 CUDA cuDNN TensorRTAtlas 是 CANN ACL MindSpore两套东西从驱动到上层接口没有任何兼容性可言。代码不能直接搬模型格式也不能直接共用。模型格式不同GPU 上推理通常用的是 TensorRT 的 engine 文件或者 ONNXAtlas 上统一的离线模型格式是 .om需要用工具把训练好的模型转换过去。计算单元设计不同GPU 是 CUDA Core 做通用并行计算Atlas 300V 的 AI Core 是专门为矩阵运算设计的对卷积、全连接这类算子效率很高但碰到形状特别不规则的算子效率就会打折。生态成熟度不同这个必须承认NVIDIA 的生态文档、社区、第三方库都极其丰富Atlas 的生态虽然这几年发展很快但遇到冷门问题还是得自己去翻文档甚至猜。不过如果你把它当做一个“专门的推理工具”而不是“通用计算卡”来用这些差异其实也就还好——你不需要在它上面跑各种乱七八糟的 CUDA 代码只需要把模型转换好、把推理接口调好剩下的它干得确实漂亮。2. 为什么要在 Atlas 上部署 YOLO怎么选型2.1 部署 YOLO 的真实需求YOLO 系列模型应该是目前工业界落地最多的目标检测模型了没有之一。它最讨喜的地方就是“一个模型搞定检测”输入一张图输出每个目标的类别、置信度和边框坐标结构直观训练资料多部署案例也多。把 YOLO 部署到 Atlas 300V 上本质上解决的是**“检测算力不够”**的问题。我见过不少项目一开始用 CPU 跑 YOLOv5s一帧 1080p 图片要 200 多毫秒也就是一秒钟只能处理 4-5 帧这哪叫实时。换到 Atlas 300V 上之后同样的模型优化得当的话能做到单帧 10 毫秒以内差距是数量级的。另外一个需求是**“模型越换越大”**。早期很多项目用 YOLOv5s但现在大家发现 v8、v11 等新版本的精度确实更好模型也更大小显存的卡开始捉襟见肘。Atlas 300V 的 24G 显存在这方面就非常有优势不但能装下更大的模型还能给 AIPP 图像预处理留出足够的 buffer甚至同一个卡上跑两个模型都问题不大。2.2 方案选型ACL、MindSpore 还是 Ascend C在 Atlas 上部署 YOLO第一步要决定的是“用哪套接口”。我把自己实际比较过的几条路线列出来。纯 ACLAscendCL推理这是最底层的 C/C 接口也是我最推荐入门方案。它把模型加载、输入输出管理、推理执行这些核心步骤都封装成了 API虽然写起来代码量稍微多一点但思路清晰性能也最可控。YOLO 部署用这一层就够了。MindSpore 推理MindSpore 是华为自家深度学习框架如果你训练阶段就是用 MindSpore 做的那推理也能走这条路。但现实是大部分人的 YOLO 模型是从 PyTorch 训练出来的强行迁移到 MindSpore 反而不划算。Ascend C 自定义算子当模型里有些算子 CANN 版本不支持、或者转换后性能太差时就得用 Ascend C 手写算子。这条路技术要求高普通部署场景用不上但遇到边缘 case 时是救命稻草。第三方封装比如 rknn-toolkit 类似的 ascend 封装社区里有人做了基于 ACL 的 Python/C 封装能减少一些样板代码。但这类封装质量参差不齐我建议至少在初期还是自己把 ACL 流程搞明白再决定要不要依赖封装。我个人的建议非常明确直接学 ACL OM 模型。这条路线最通用不依赖具体训练框架而且 CANN 版本更新对它的兼容性也做得最好。2.3 部署前先做资源规划很多人拿到 Atlas 300V 就急着装驱动、跑模型结果后面各种翻车。我吃过亏之后养成的习惯是先画一张资源规划表再动手。至少要明确这几件事。服务器主板有几个 PCIe 插槽Atlas 300V 是插在 PCIe 上的需要 x16 物理插槽供电要能满足。有些服务器显卡供电接口不够还得另配供电线。CANN 版本与驱动版本CANN 和 driver 的版本必须严格匹配这是最大的坑之一。比如 CANN 8.0 对应某几个 driver 版本搞错了直接导致设备不可用。模型输入尺寸和显存预估YOLO 的输入是 640x640x3一张图约 1.2MB 浮点数据但推理过程中间张量占的显存要大得多。24G 显存跑 YOLOv8m 的 batch 8 是没问题的但跑 batch 32 就要掂量了。CPU 与内存配合推理不仅是卡的事数据要从 CPU 搬到显存预处理也在 CPU 上做。服务器 CPU 不能太弱内存至少 32G 起步。这些规划做完后面部署才会顺利。我见过太多人栽在“卡插上去驱动装不上”这种跟模型完全无关的问题上。3. 部署前的硬骨头环境准备与 CANN 工具链3.1 服务器硬件与卡安装细节Atlas 300V 的物理安装和 GPU 卡有点像但有几点不同值得留意。第一卡体上可能有独立的 6-pin 或 8-pin 供电接口。很多服务器主板或者转接卡提供的 PCIe 供电不足需要额外接电源线不然卡能识别到但一加载模型就掉驱动。我之前就遇到过这种诡异问题排查了半天最后是供电线松了。第二散热风道。Atlas 300V 有主动散热和被动散热的不同型号服务器要保证卡周围有足够的风道。被动散热的卡如果塞在硬盘笼旁边温度分分钟飙到 90 度然后降频甚至罢工。第三BIOS 里的 PCIe Resizable BAR 设置。这个不是必须但开启了之后对性能有一点帮助尤其是大显存模型加载时能减少一部分地址映射的 overhead。装好卡之后先用 lspci 确认设备是否被识别lspci | grep -i ascend正常的话能看到类似 Huawei Technologies Co., Ltd. Device 的输出。看不到就先检查物理连接和供电不要急着下一步。3.2 CANN 工具链安装的核心流程CANN 是华为 AI 计算架构的全称它包括驱动、固件、运行时和开发工具包。安装过程说简单也简单说复杂也复杂——关键是版本匹配。我用的安装路径大致是这样的安装驱动与固件。从 Ascend 社区下载对应的 Ascend HDK 包里面有 driver 和 firmware顺序一般是先 driver 后 firmware安装完重启系统。安装 CANN Toolkit。也就是 nnrt 或者 toolkit 包nnrt 是纯推理版本的运行时比完整 toolkit 小很多。如果你只需要部署推理装 nnrt 就够了如果要跑模型转换工具、算子编译这些要装 toolkit。设置环境变量。CANN 的环境变量主要是ASCEND_HOME_PATH、LD_LIBRARY_PATH、PATH等安装完后 source 一下set_env.sh就能生效。这里我强烈建议一个习惯把每次安装的版本号记录下来。我自己建了一个简单的表格记录了哪台服务器、什么系统、什么内核版本、装的什么驱动版本、什么 CANN 版本。因为 CANN 对内核版本很敏感升级内核之后驱动经常要重新编译或重装有记录的话排查会快很多。3.3 版本匹配是头号大坑如果只让我说一个 Atlas 部署最恶心的点那就是版本匹配。CANN、driver、firmware、固件、MindSpore如果用了之间有严格的版本对应关系。CANN 8.x 需要驱动版本 24.1.rc1 之类差一个次版本号就可能出现Connect to Device failed或者ACL_ERROR_INVALID_PARAM这种让人摸不着头脑的报错。我的建议是直接去 Ascend 官网下载中心找到一张版本配套表按上面的组合来装不要想当然地装最新的。装完驱动后用npu-smi info命令确认卡的状态。看到 Health Status: OK说明驱动层没问题npu-smi info然后用一个最简单的 ACL 程序做冒烟测试不要一上来就上 YOLO。比如用acllite或者官方 sample 里的 resnet50 分类程序确认全链路通了再说。这一步走稳后面能省下大把时间。我见过太多人驱动没装利索就跑去转模型最后报错了也不知道是驱动问题还是模型问题。4. YOLO 实操从 PyTorch 权重到 Atlas 上跑通4.1 模型转换PyTorch 权重转 OMAtlas 没法直接加载 PyTorch 的 .pt 文件也没有像 ONNX Runtime 那样直接吃 ONNX 的完备接口。它自己的一套离线模型格式叫OMOffline Model需要用atc工具把模型转换过去。整个转换链路一般是PyTorch .pt / .pth - 导出 ONNX - atc 转 OM - ACL 加载推理先说导出 ONNX。YOLO 系列在导出时有一个关键细节要去掉后处理或者把后处理剥离出来。原始 YOLO 模型输出的三个特征图维度是 batch x 255 x 80 x 80以 YOLOv5 为例255 3 * (5 80)这个输出里既包含每个 anchor 的坐标偏移也包含类别概率还掺杂着 NMS 需要的中间量。如果你把它原封不动导到 ONNX 再转 OM虽然也能跑但后处理全放在 CPU 上做性能大打折扣。正确的做法是导出时把检测头保留原始输出但省掉 NMS 和非必要算子。具体来说把 YOLOv5 的 Detect 层中用到的 anchor grid 这些计算尽量导出成 ONNX 支持的算子或者干脆在导出脚本里把模型简化为 backbone neck head 的原始张量输出NMS 不要放到模型结构里放在推理后处理阶段用 CPU 实现。导出 ONNX 的命令大致是python export.py --weights yolov5s.pt --include onnx --img 640 640导出后最好用 ONNX Runtime 先验证一下import onnxruntime as ort import numpy as np sess ort.InferenceSession(yolov5s.onnx) inputs sess.get_inputs() print(inputs[0].shape)输入是 1x3x640x640输出可能是三个不同尺度的特征图这就 OK。4.2 编写 AIPP 配置图像预处理的关键这是 Atlas 部署 YOLO 最需要注意的环节之一。Atlas 的 AIPPAI Preprocessing可以在硬件上完成图像缩放、减均值、除以标准差、通道变换等操作也就是说你可以让模型直接吃原始 RGB 数据而不是在 CPU 上用 OpenCV 折腾半天。这对性能提升是实打实的。一个典型 640x640 的预处理如果用 CPU 的 OpenCV 做 resize normalization要耗时好几毫秒但对于 YOLO 推理来说这已经是很大的 overhead 了。放到 AIPP 之后CPU 这边只剩读图片和拷贝数据推理链路整体延迟能低不少。AIPP 配置写在一个 .cfg 文件里核心内容大致如下aipp_op { aipp_mode: static input_format: RGB888_U8 crop: false resize: true src_image_size_w: 1280 src_image_size_h: 720 csc_switch: true rbuv_swap_switch: false 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 }注意它的逻辑是输入原始图像尺寸是 1280x720AIPP 会先把它 resize 到模型需要的 640x640然后做归一化var_reci_chn_0 1 / 255。如果你的模型训练时用了不同的归一化参数一定要对应修改否则检测精度会明显变差。这一点我真是踩过坑。有次我把一个在 COCO 上训练的检测模型转换后直接部署没仔细配 AIPP结果图像明显偏暗检测率掉了一大截。后来才意识到是均值和方差没对上。4.3 使用 atc 命令完成转换AIPP 配置好后就可以调用 atc 做模型转换了。以 YOLOv5s 为例大概是这样atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --insert_op_confaipp.cfg \ --output_typeFP32几个参数我再解释一下--framework5表示 ONNX 格式--soc_version要根据你的卡对应填写比如 Atlas 300V 对应的昇腾芯片类型可能是Ascend310P3不确定时用npu-smi info看到的芯片类型来定--input_shape里的 batch 设为 1 可以先跑通后续再考虑动态 batch--output_typeFP32表示输出是 FP32如果后续要做后处理FP32 更直接。转换完成后会生成yolov5s_bs1.om文件。这一步如果报错绝大多数情况是两种一是算子不支持需要换 CANN 版本或者看是不是模型里混入了奇怪的自定义算子二是 shape 参数不匹配仔细看报错信息里的 tensor 名字对照 ONNX 里的输入名改一下即可。4.4 写一个可用的 ACL 推理脚本OM 模型拿到手后就该写推理代码了。这里我给出一个 Python 版本的 ACL 推理伪代码用的还是官方昇腾 AI 应用开发里常见的acllite它的可读性比较好。如果追求极致性能后面可以改 C 版本。核心流程大概是这样import acl from acllite.acllite_model import AclLiteModel from acllite.acllite_image import AclLiteImage # 初始化 ACL acl.init() # 指定运行设备 ret acl.rt.set_device(0) # 加载 OM 模型 model AclLiteModel(yolov5s_bs1.om) # 读图并做预处理这一步一般会把 resize/归一化等交给 AIPP 完成 image AclLiteImage(test.jpg) result model.execute([image]) # result 就是模型的输出张量需要解析后处理 # 这个后处理包括解码 bbox、过滤低置信度框、NMS 等 boxes postprocess_yolov5(result)这里的postprocess_yolov5是我们自己写的那一部分主要完成把模型的三个特征图输出换算到原图坐标系过滤置信度低于阈值的框对同一类别的框做 NMS去掉冗余重叠。我在最开始写后处理时就是参照 YOLOv5 官方 repo 里Detections类的逻辑把里面依赖 torch 的部分改成 numpy 实现。这个过程不难但要注意 anchor 的定义必须和训练时一致不能拿 YOLOv5 的 anchor 去套 YOLOv8 的输出格式——不同版本检测头结构差异很大很多人在这一阶段“模型能跑但结果全乱”。4.5 前后处理优化让吞吐真正上去跑通只是第一步实际部署还要考虑吞吐量。这里有几个优化的方向批量推理把多张图攒成一个 batch 一次推理24G 显存完全可以支撑 batch 8 甚至 batch 16具体看模型大小。batch 越大单位时间处理的图片数越高。但要额外控制一下延迟如果对单帧延迟敏感batch 太大反而坏事。流水线并行让数据读取、预处理如果 CPU 做、推理、后处理分属不同线程用队列串起来各个阶段互不阻塞。我实测过不做流水线时单帧处理延迟中位数波动很大做了流水线之后吞吐能提升 50% 以上。模型输出精度的取舍OM 模型输出可以直接指定为 FP16减少带宽占用和数据搬运量可能带来一些精度损失但对目标检测这种任务通常影响不大可以对比实验决定。这里也顺便说一句Atlas 300V 的硬件解码单元DVPP是经常被忽略的利器。如果你的数据源是视频流用 DVPP 直接从 H.264/H.265 解码得到 YUV 数据再送进模型会省掉一大块 CPU 解帧的开销。很多人只把它当推理卡用其实它的多媒体处理能力对视频类 AI 应用帮助极大。5. 常见问题与排查技巧实录5.1 驱动层面设备掉线、无法识别这是 Atlas 部署里最玄学也最常见的问题。典型表现是npu-smi info一开始能看到卡跑了几天之后设备不见了或者加载模型时报Device offline。排查思路我按优先级排列先查物理链路把卡拔下来重新插一下清理金手指。数据中心环境的灰尘和插拔不牢都会导致接触不良再查系统日志dmesg | tail -n 50看有没有 PCIe AER 报错如果有很可能是 PCIe 链路有问题或供电不足然后看温度npu-smi info输出里能看到芯片温度长期超过 85 度就要检查散热和风道了最后检查驱动版本和系统内核是否兼容某些内核升级会导致驱动模块无法正常加载需要重编驱动。我自己的做法是在服务器上配一个 crontab 定时任务每隔 5 分钟把npu-smi info的结果打到日志里一旦设备掉线就能从日志定位掉线时间点再回溯当时系统发生了什么。这个习惯救了我好几次。5.2 模型层面转换失败、精度异常、输出全零YOLO 模型在转换和推理阶段最常遇到这几个问题。atc 转换报算子不支持这是最常见的。先确认 ONNX 模型里的算子版本是否太新有些新模型用了最新 ONNX opset 里的算子CANN 还没跟上。解决办法是导出 ONNX 时降低 opset 版本比如从 17 降到 13。推理输出全为零一般是 AIPP 配置和模型输入不匹配或者是模型的归一化操作与 AIPP 重复了。如果你的 ONNX 里本来就有 Normalize 层那 AIPP 里就不要再做归一化二者取其一。检测框位置明显不对八成是 AIPP resize 和坐标换算的逻辑没对齐。模型是在 640x640 上训练的但原图是 1920x1080坐标缩放时要按模型的 Letterbox 方式等比缩放加 padding不能简单地用两个宽高的比例直接乘。精度比训练时低不少先用原始图片在 PyTorch 上做一次推理得到一组 benchmark 结果。再在 Atlas 上跑同一张图对比两边的输出张量差异。如果差异很大重点检查 AIPP 的均值和标准差如果只是稍低可以把--output_type从 FP16 改成 FP32 试试代价是显存占用升一点。5.3 性能层面吞吐上不去CPU 跑满卡却闲着这个现象也很典型Atlas 300V 的 AI Core 利用率不到 30%CPU 却跑得满头大汗。先分析是不是预处理拖了后腿。如果你还在用 OpenCV 在 CPU 上做 resize 和归一化那瓶颈一定在这。解决办法就是把这部分移到 AIPP让卡自己处理。再看后处理。YOLO 的输出后处理尤其是遍历几千个候选框做 NMS如果用 Python 纯循环写慢到怀疑人生。务必用 numpy 向量化操作或者用一些技巧比如直接对置信度矩阵做 topk。这部分我建议单独做一次性能 profile如果它占了总延迟的 30% 以上可以考虑用 C 扩展或者改走昇腾的 DST 后处理算子。还需要注意数据搬运。如果图片每次都从内存拷到设备再拷回来出结果PCIe 带宽就成了瓶颈。建议在业务逻辑里尽量让数据“留在卡上”处理——比如整段视频解码-预处理-推理-后处理都尽量利用 DVPP 和卡内能力而不是每帧都在 CPU 和卡之间来回搬运。5.4 常见问题速查表问题现象可能原因解决方向npu-smi info看不到设备供电不足/插槽松动/驱动未加载检查物理连接、供电线重新安装驱动驱动安装失败内核版本与驱动不匹配查询配套表选择兼容版本必要时锁定内核atc 转换报错算子不支持ONNX opset 过高或存在自定义算子降低 opset 版本简化模型结构推理输出全零AIPP 与模型归一化重复二选一去重检查输入格式检测框位置偏移坐标换算未按 letterbox 处理后处理时按等比缩放 padding 方式反算CPU 占用 100% 但卡不忙预处理/后处理在 CPU 上过重迁移到 AIPP、优化后处理向量化多路视频掉帧数据读取或解码瓶颈使用 DVPP 硬解码流水线并行这表里的每一条都是我或身边同事实际踩过的坑。有些问题光看报错完全摸不着头脑但把它归到驱动/模型/性能这几类里排查思路就会清晰很多。6. 后部署阶段的一些实在建议6.1 日志与监控体系要提前搭模型跑通只是第一场胜利真正的考验在后头。上线之后你要能随时回答这三个问题卡现在温度多少显存还剩多少最近一小时有没有报错我的做法是用npu-smi info的输出写一个采集脚本每 30 秒记录一次温度、显存占用、AI Core 利用率写到 Prometheus 之类的时序库里对推理服务本身的指标每次推理耗时、QPS、输入队列深度做单独埋点设置告警温度超过 80 度、显存占用超过 90% 持续 5 分钟、连续 10 次推理失败都要能推送到企业微信/钉钉。别嫌麻烦线上环境你不可能一直盯着终端。有了监控才能在故障发生后 5 分钟内定位到是卡的问题还是代码的问题。6.2 多卡和横向扩展的预留设计一个项目后期总会面临算力不够的问题。Atlas 300V 是标准的 PCIe 卡一台服务器可以插多张算力水平可以近似线性扩展。但多卡不是简单多插几张卡就行有几个点要提前设计模型分发策略用同样的 OM 模型跑多卡就是最简单的数据并行每张卡处理不同的输入上层做个负载均衡即可卡间通信如果模型本身切分到多卡比如超大模型就要用到 HCCS 或 PCIe Peer-to-Peer配置复杂度会上一个台阶。对 YOLO 来说一般单卡就能扛住不需要走这条路故障转移如果一张卡挂了服务不能完全瘫痪。需要在上层做个简单的健康检查发现某张卡不可用时把流量切到其他卡上。我经历过一次单卡故障导致整个推理服务不可用的事故原因就是代码写死了设备 0。后来改成启动时动态探测可用设备故障影响面就小了很多。6.3 安全与权限控制不能放最后再补充一个很多人忽视的点。Atlas 300V 的推理服务如果放到生产环境对外提供 HTTP 接口务必考虑以下几点服务进程不要用 root 跑单独建一个低权限用户对外接口要做鉴权和限流这个不用我多说没鉴权的检测接口很容易被刷爆模型文件本身也是有价值的资产OM 模型不要放在任何人都能读的路径下定期更新 CANN 版本和驱动版本安全补丁虽然不常出但出了就该及时跟进。7. 我个人踩过几次坑之后的心得真要把 Atlas 300V 24G 用到顺手我觉得最核心的心态转变就是别把它当成一张兼容 GPU 的卡而是当成一台有自己脾气的小型推理机。它的硬件能力是实打实的24G 显存跑 YOLO 系列的绝大部分模型都绰绰有余推理性能也完全不虚同档位的推理卡。但它要求你接受它的规则——用它的模型格式用它的工具链用它的思维方式思考数据流动。一旦跨过这个门槛你会发现后面的路反而很顺畅因为它的定位非常纯粹就是为推理而生的。我最后再分享一个自己一直在用的小技巧每次部署完一个模型把环境信息 转换命令 测试结果整理成一个简单的 Markdown 文档放到项目目录里。别高估自己的记忆也别低估模型迭代的频率。三个月后你要部署 YOLOv8 的新版本翻一下之前的文档十分钟就能找回全部环境参数而不是重新踩一遍所有的坑。这个习惯让我省下的时间可能比我在 Atlas 上花的所有调试时间还多。
