说实话接触华为 Atlas 系列也有一段时间了从最初的 Atlas 200 DK 到后来长期在用的 Atlas 300V 系列中间踩过的坑、推翻重来的配置、莫名其妙的报错都能单独写个合集了。最近发现还是有不少人在纠结“Atlas 300V 24G 到底算不算运算加速卡”以及“YOLO 能不能在上面跑、跑起来效果怎么样”这类问题所以干脆结合我自己的实测经历把从选卡到部署 YOLO 的完整链路一次性说清楚。这篇文章不是什么官方文档的复读而是我把 Atlas 300V 24G 从开箱、装环境、模型转换到最终调通的真实记录。内容包括这款卡的真实定位、为什么要选它、CANN 工具链怎么梳理、YOLOv5 模型怎么从 PyTorch 转到 OM 格式、推理部署时有哪些不走弯路的方式以及我在实际项目中遇到的若干问题和对应的排查思路。如果你正在评估 Atlas 300V 24G 作为推理硬件或者正准备把 YOLO 系列模型迁到昇腾平台这篇文章应该能帮你省下不少摸索时间。1. Atlas 300V 24G 的真实定位与选型解析很多人一上来就问“Atlas 300V 24G 是运算加速卡吗”这个问题的答案其实要分两层说它确实是加速卡但它是专为 AI 推理场景设计的加速卡和传统意义上用于通用计算的“计算卡”不是一回事。这个区别决定了你后续做部署时的整个技术路线。1.1 它到底算不算运算加速卡严格来说Atlas 300V 系列是华为推出的 AI 推理加速卡核心芯片是昇腾 310P 系列主打 INT8 和 FP16 推理。它不像 NVIDIA 的 A100 或者华为自己的 Atlas 300T 系列那样具备完整的训练能力它的设计目标很明确用更低的功耗、更小的体积把训练好的模型高效地跑起来完成推理任务。在实际使用中Atlas 300V 24G 的 24GB 显存官方叫法是“内存”但为了方便理解下文统一叫显存是目前这个系列里比较大的一款。这个显存大小能装下不少主流模型比如 YOLOv5 的 L 版本、YOLOv8 的 L 版本、一些中等规模的分割模型甚至小 batch 的 Transformer 结构模型也能跑。我自己的主力设备就是一张 Atlas 300V 24G在这张卡上跑过的模型包括 YOLOv5s/m/l、YOLOv8s/m、PP-HumanSeg、OpenPose 的部分变体整体体验下来是够用的。如果你非要用“运算加速卡”这个说法那么准确的表述是Atlas 300V 24G 是一张面向 AI 推理场景的运算加速卡而不是面向通用科学计算或者 AI 训练的加速卡。它最适合的场景是模型已经训练完成需要以较低的成本、较高的吞吐量进行部署上线。1.2 为什么推理场景我更愿意选它而不是 GPU我听到过很多同行抱怨 Atlas 的生态不够成熟这确实是客观现实但如果你只看推理部署这一件事Atlas 300V 24G 有一些 GPU 给不了的优势。我平时主要做视频流分析相关的项目需要同时跑多个模型对整卡的功耗和体积都比较敏感。从项目落地角度看我选 300V 24G 的理由有三个卡片本身的价格和功耗比同显存的专业显卡低一截。24G 显存的显卡如果是专业卡或游戏卡功耗通常都在 200W 以上而 Atlas 300V 的典型功耗只有 72W 左右。对于长期运行的推理服务散热压力小很多机房或边缘机柜的部署难度也低。这点在实战中非常关键尤其是那些只有普通机箱、没有专门散热设计的现场72W 的功耗几乎不用担心温度问题。推理延迟和吞吐表现稳定。尤其是当模型已经转为离线模型OM后在 Atlas 上推理的延迟波动很小这对实时视频分析这类场景非常重要。相比之下部分 GPU 在长时间运行时因为降频延迟会出现周期性的波动这在工业场景里是没法接受的。软件栈统一且可控。Atlas 全系列走 CANN 工具链从驱动到推理框架都是同一套体系虽然有时版本兼容性确实让人头疼这点后面会详细说但一旦环境调通COPY 到其他机器上基本是一路顺畅。很多做项目交付的同行应该知道统一的环境意味着可复现、可交付、可维护。当然我也不会只说好话。Atlas 300V 在当前阶段最大的问题是社区资料少很多代码在 GitHub 上只有 GPU 版本需要自己改一部分算子或推理逻辑。如果你是一个完全没接触过 CANN 的新手刚开始会有一段比较明显的学习曲线。所以我在下面的内容里会尽量把关键步骤走一遍尤其是那些文档里写得模糊、但实际部署时又绕不开的细节。2. 部署 YOLO 前的环境准备与工具链梳理把 YOLO 部署到 Atlas 300V 24G 上本质上做的事情和 GPU 上不一样GPU 直接跑 PyTorch 或者 TensorRT而 Atlas 需要先把模型转换成它自己的离线格式 OM再通过 CANN 的推理接口加载运行。这个流程本身并不复杂但步骤很多任何一个环节的版本不一致都会导致后面莫名其妙的报错。2.1 CANN 与驱动安装的版本坑我踩过的第一个坑就是版本匹配问题。CANN 的版本非常多驱动Ascend HDK和 CANN 工具包之间必须保持兼容而这两者又分别还要和操作系统内核版本兼容。刚上手的人很容易在官网看到什么新就装什么结果驱动装上了CANN 却找不到设备或者 ATC 工具直接段错误。以我使用的环境为例目前比较稳的一套搭配是组件版本建议操作系统Ubuntu 20.04.5 LTS内核 5.4 系列驱动固件Ascend HDK 24.1.rc1 或同期的 24.1 版本CANN 工具包CANN 8.0.RC1配套 ATC、ACL 等Python3.8 或 3.9不要用 3.11部分算子适配有问题我在 Ubuntu 22.04 上也试过内核太新的话驱动自带的昇腾设备内核模块编译很容易报“头文件版本不匹配”的问题不太建议新手一开始就用太新的系统折腾。安装过程基本上就是按照昇腾社区的“安装开发环境”文档走先装 HDK驱动 固件再装 CANN toolkit然后设置环境变量。这里有个细节很多人不知道装完驱动后需要重启重启后如果/usr/local/Ascend/driver/version.info存在才能证明驱动装好了。另外我不建议用 conda 去管理 CANN 的环境CANN 的 Python API也就是aclrts、mindspore这些包对 conda 里的 Python 兼容性时好时坏。我自己现在用的是系统自带的 Python然后每个项目单独建一个 venv这样最稳。2.2 从 PyTorch 到 ONNX 再到 OM一条不能跳步的路YOLOv5 或者 YOLOv8 这一类模型的落地路径目前主流是三条线PyTorch 模型先导出 ONNX再用 ATC 工具转成 OM。这条线最通用适配性最好也是我推荐大家优先尝试的。直接使用 MindSpore 版本的 YOLO 代码训练再导出。这条线在昇腾上最“原生”但问题是第三方仓库的 MindSpore 版本 YOLO 普遍更新慢功能不如 PyTorch 版本全。在 CANN 的 PyTorch 适配层上直接跑 PyTorch 推理。这样不用转模型但性能通常没有转成 OM 后好而且算子兼容问题更多。我长期使用的是第一条线也就是PyTorch → ONNX → OM。这个过程里ONNX 扮演的角色很微妙它是一个中间格式ONNX 模型能不能顺利转成 OM很大程度取决于模型里的算子有没有被昇腾的 ATC 算子库覆盖。YOLOv5 和 YOLOv8 的 backbone 都是 Conv、BN、SiLU、Concat、Upsample 这类常见算子基本都在覆盖范围内但有一些细节需要处理后面我会专门讲。所以整体流程是在有 GPU 的机器上或者任意能跑 PyTorch 的环境里准备好 YOLOv5 的权重导出带 batch 维度的 ONNX 文件把 ONNX 文件放到 Atlas 机器上用 ATC 工具转 OM写推理代码加载 OM做预处理和后处理联调验证优化性能听起来很简单但我在第二步到第三步之间反复折腾了很久。问题主要出在模型输入输出节点的名称和动态 shape 的处理上这两个点要是搞不明白转换出来的模型要么完全没法用要么推理结果全是乱的。3. YOLO 模型转换全流程实操这一部分我把实际操作的步骤逐一展开重点放在那些如果不注意就会翻车的细节上。我自己用的是 YOLOv5 官方仓库的模型结构YOLOv8 流程类似只是输出节点数量不同我会在必要的地方标注。3.1 从 YOLOv5 导出 ONNX这一步决定了后面能不能成很多教程会直接让你用python export.py --weights yolov5s.pt --include onnx去导出但这样导出的 ONNX 有两个问题在 Atlas 上特别明显动态 batch 或动态输入尺寸可能导致 ATC 转换时的越界错误。对于推理卡我建议直接固定输入分辨率比如 640x640不要用动态 H/W。动态尺寸在 GPU 上用 TensorRT 可能没什么问题但在昇腾的 ATC 上动态 shape 的支持有些限制处理不好就会多花很多时间在 shape 推导上。输出节点默认是三维的 (1, 25200, 85)其中 25200 是三个尺度特征图的预测框总数85 是 80 类 4 个坐标 1 个置信度。这个结构在模型转换时通常没问题但在后处理时不如 TensorRT 的平坦输出好处理所以在导出前我一般会先改一下模型代码把输出层直接导出为列表形式每个尺度的输出单独分开。我自己在实际部署中用的导出方式是在models/yolo.py的forward函数里修改YOLOv5 6.x 和 7.x 的路径略有不同在Detect类的forward里直接返回原始特征图而不是经过torch.cat拼接的最终输出。这样做有两个好处一是 ATC 转换时算子的结构更简单二是后续做多尺度后处理时不用从一个大矩阵里切来切去。导出命令通常是这样python export.py --weights yolov5s.pt --include onnx --img-size 640 640 --batch-size 1 --simplify --opset 11--simplify参数会调用 ONNX Simplifier 对模型进行化简这能去掉大量冗余的 Transpose 和 Reshape 节点对应到 Atlas 上就是更少的 ATC 转换算子和更快的推理速度。--opset 11是昇腾支持得最好的版本opset 13 以上虽然部分支持但偶尔会遇到某些算子不兼容的问题。这里有个需要特别注意的点YOLOv5 6.2 之后模型里默认使用了torch.chunk在导出 ONNX 时可能会多出很多 Split 算子。经我实测这些 Split 在 ATC 转换时可以处理但会增加转换时间对最终性能影响不大所以不用刻意去改代码结构。如果你用的是 YOLOv8它的 Detect 头输出的是 (box, cls) 分开的格式转换时反而更直接一些。3.2 使用 ATC 工具将 ONNX 转换为 OMONNX 文件拿到 Atlas 机器上之后就可以用 ATC 工具转了。这一步的很多选项会在后面的推理环节深刻影响你的使用体验所以不要照搬别人的参数最好按自己的情况来。基础转换命令如下atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP16 \ --enable_small_channel1这里各个参数的含义和选择逻辑我逐个说明一下--framework5表示输入是 ONNX。这个数字要记住因为在 CANN 的 ATC 工具里框架编号只有 0Caffe、1MindSpore、3TensorFlow、5ONNX等几个值拼错了直接报错。--soc_version决定了算子按哪种芯片架构来编译。Atlas 300V 系列对应的是 Ascend310P3这个不能写错写成 Ascend310 或者 Ascend910 都会在转换时报“ACL engine 初始化失败”一类的错误。你在跑npu-smi info的时候可以看到具体的型号比如 Atlas 300V Pro 通常对应 310P3。--insert_op_conf指定一个 AIPPAI Preprocessing配置文件里面可以定义图像预处理比如 crop、resize、归一化、色域转换。理论上你可以把所有预处理都丢给 AIPP让模型输入直接是处理好后的数据但我建议只把归一化和数据格式转换放在 AIPP 里resize 留到代码里做因为 AIPP 的 resize 有些与模型输入 shape 不一致时会出现奇怪的失真排查起来很麻烦。--output_typeFP16很关键。Atlas 300V 推理时对 FP16 的支持最成熟如果把模型输出设置为 FP32某些算子在硬件上的计算效率会低不少表现为推理延迟明显上升。但注意如果你的模型里有一些动态范围很大的层比如某些分割头里直接输出 logitsFP16 可能会导致上下溢这种情况下建议用--output_typeFP32只保留输出层为 FP32。--enable_small_channel1是对输入通道数较少比如 3 或 4 通道的模型做的小优化对 YOLO 这种三通道图像输入的模型比较友好实测能让首个卷积层的耗时降低不少。还有一个参数我经常用--fusion_switch_file。这需要你事先写一个 JSON 文件对特定算子禁用融合。什么时候需要用呢我发现 YOLOv5 的 Detect 头里有很多小算子ATC 在融合阶段可能把它们合并得不合理导致推理时某个算子报“unsupported op type”兜底方案是对相关算子禁用融合。AIPP 配置文件aipp.cfg的内容大概是这样的aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: false rbuv_swap_switch: false crop: false normalize_switch: true min_chn_0: 0.0 min_chn_1: 0.0 min_chn_2: 0.0 var_reci_chn_0: 0.00392156862745098 var_reci_chn_1: 0.00392156862745098 var_reci_chn_2: 0.00392156862745098 }这里面var_reci_chn是归一化系数的倒数也就是 1/255这样 AIPP 会把输入图像直接转为 0~1 的 float 数据不需要在代码里额外处理归一化。注意source_image_size指的是模型输入尺寸不是原始图像的尺寸原始图像的缩放必须在送入模型前做掉。3.3 图像预处理的关键细节如果你用了上面的 AIPP 配置那么图像从 OpenCV 读到送入模型之间还有一步是必须做的letterbox resize。YOLOv5 和 YOLOv8 官方代码里的预处理都是先将长边缩放到 640然后对短边进行灰色填充保证输入图像没有畸变。这个步骤不能省也不能简单粗暴地直接 resize 成 640x640否则检测精度会明显下降。实际操作时我写了一个小工具函数来统一处理import cv2 import numpy as np def letterbox(img, new_shape(640, 640), color(114, 114, 114), autoFalse, stride32): shape img.shape[:2] if isinstance(new_shape, int): new_shape (new_shape, new_shape) r min(new_shape[0] / shape[0], new_shape[1] / shape[1]) ratio r, r new_unpad int(round(shape[1] * r)), int(round(shape[0] * r)) dw new_shape[1] - new_unpad[0] dh new_shape[0] - new_unpad[1] if auto: dw, dh np.mod(dw, stride), np.mod(dh, stride) dw / 2 dh / 2 if shape[::-1] ! new_unpad: img cv2.resize(img, new_unpad, interpolationcv2.INTER_LINEAR) top, bottom int(round(dh - 0.1)), int(round(dh 0.1)) left, right int(round(dw - 0.1)), int(round(dw 0.1)) img cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, valuecolor) return img, ratio, (dw, dh)这个函数和官方实现几乎一致我保留了auto参数以便在需要对齐 stride 的场合使用。推理前把图像按这个方式处理成 640x640然后HWC转CHW再转成 FP16 或 INT8 传给模型即可。预处理这一块还有一个容易忽略的点AIPP 配置里的input_format要和模型输入的布局一致。如果模型导出时的输入是 NCHW那么 AIPP 里的input_format应该是 RGB888_U8对应 CHW 布局如果你导出成了 NHWC那就得改成RGB888并加model_format: NHWC之类的配置。我第一次转换时没注意这个结果推理出来的结果全是噪声折腾了很久才发现是布局匹配问题。4. 推理部署ACL 的三种落地姿势模型转换完成只是第一步真正要上线跑起来还得把你自己的业务代码和昇腾的推理接口对接起来。CANN 目前提供的主要是 ACLAscend Computing Language接口我在这上面试过三种方式各有优劣这里一一分享。4.1 基于 Python ACL 的快速验证如果只是想快速验证 OM 模型能不能正确推理最快的方式是用 Python ACL 接口。优点是代码短、写起来快适合做集成测试和指标评估缺点是运行效率上比不上 C 版本但对大多数场景来说吞吐完全够用。一个最小可用的推理脚本框架是这样的import acl import numpy as np # 初始化 ACL ret acl.init() ret acl.rt.set_device(0) # 加载模型 model_path b./yolov5s_bs1.om model_id, ret acl.mdl.load_from_file(model_path) # 获取模型输入输出描述 desc acl.mdl.create_desc() ret acl.mdl.get_desc(desc, model_id) input_size acl.mdl.get_input_size_by_index(desc, 0) output_size acl.mdl.get_output_size_by_index(desc, 0) # 分配设备内存 input_data_buffer, ret acl.rt.malloc(input_size, 2) output_data_buffer, ret acl.rt.malloc(output_size, 2) # 打包输入数据input_tensor 需要是 1,3,640,640 的 FP16 ndarray acl.rt.memcpy(input_data_buffer, input_size, input_tensor.ctypes.data, input_size, 1) # 执行推理 ret acl.mdl.execute(model_id, input_data_buffer, input_size, output_data_buffer, output_size) # 将输出拷贝回内存 output_tensor np.zeros(output_size, dtypenp.uint8) acl.rt.memcpy(output_tensor.ctypes.data, output_size, output_data_buffer, output_size, 2)用这个骨架能跑通后再往里面加自己的业务逻辑。我建议新手第一次接触时先把这一步走通再考虑进阶的流式处理或者异步推理否则容易在复杂接口里迷路。ACL 接口的 C 版本和 Python 版本在逻辑上是一一对应的就算后面的正式生产代码打算用 C 写先用 Python 验证模型也是掌握 API 调用方式的好方法。4.2 基于 MindX SDK 的简易部署如果你不想在底层接口上花太多时间MindX SDK 的 Python 插件方式其实是一条捷径。MindX SDK 把推理封装成了一个个 plugin“数据输入 → 图像解码 → 缩放 → 推理 → 后处理”整个流程可以通过配置文件直接串联起来代码量很少。我试过用 MindX SDK 部署 YOLOv5它的mxpi_tensorinfer插件就可以直接加载 OM 模型做推理。流程大致是定义.pipeline配置文件指定各个插件用 Python 代码加载 pipeline传入图像从输出插件中获取推理结果这种方式的优点在于开发效率高尤其适合做视频流接入这种有现成插件可用的场景。但缺点也很明显MindX SDK 的插件版本和 CANN 版本绑定得很死升级 CANN 后 Pipeline 配置文件经常要改且后处理模块不如自己写代码灵活。对于生产项目我的建议是如果整个链路是标准的目标检测且不需要太多定制化逻辑可以用 MindX SDK 先搭一个原型然后再决定要不要拆到 ACL 层重新实现。因为一旦你的项目开始涉及复杂的业务后处理、多模型串联、动态 batch 等SDK 的灵活性会限制你。4.3 性能调优与并发优化推理卡最怕的不是单卡跑不快而是单张卡只在低利用率下“空转”。我见过不少人在 Atlas 上推理延迟都比预期高其实不是卡不行而是并发没拉上去。在 Atlas 300V 上做并发推理有两条路batch 维度的并发一次推理喂多张图。这要求模型转换时指定的input_shape里的第一维大于 1。比如把--input_shapeimages:4,3,640,640导出一份 bs4 的 OM 模型然后一次推理处理 4 张图。实测下来bs4 的总吞吐比 bs1 高 2~3 倍是正常的。多路异步推理使用 ACL 的 stream 机制在同一个 stream 里异步提交多个任务让硬件流水线并行。这个方式需要把acl.mdl.execute_async和acl.rt.synchronize_stream配合使用。我实际项目里用的是混合方案外部接入 4~8 路视频流每一路单独一个线程在 C 层使用两个 stream 交替提交推理任务每个任务内部 batch 为 2。这样在 Atlas 300V 24G 上1024x1024 输入下的 YOLOv5s整体吞吐能做到大约 150~200 FPS。这个数字对大部分场景已经非常充裕。需要注意并发提高后显存占用会同步上升。24G 卡跑 YOLOv5sbs4 时显存占用一般在 2~3GB 左右完全无压力但如果你同时加载了多个模型比如一个检测模型加一个分割模型显存规划就要提前算好。这里我一般用npu-smi info实时查看显存占用保证峰值不超过总显存的 70%否则稳定性和性能都会受影响。5. 常见问题与排查技巧实录这部分是整篇文章里最有“实战味”的内容因为每个问题都是我自己在部署过程中碰到过、并且耗过时间的。整理成速查表的形式方便你偶尔遇到时快速定位。5.1 典型报错与解决对照表报错现象可能原因解决措施ATC 转换报错E19999: Inner Error!输入 ONNX 的算子版本或图形结构与当前 CANN 不兼容尝试将 ONNX 用 Simplifier 再简化一遍或把 opset 改成 11 重新导出运行时acl.rt.set_device返回错误码驱动未加载、CANN 与驱动版本不匹配、当前用户权限不足检查npu-smi info能否看到设备查看/var/log/npu/slog驱动日志用 root 用户测试推理结果全为 0 或全为随机噪声AIPP 的布局与模型输入不一致或数据没有正确拷贝到设备内存重点检查input_format是不是和模型导出的 NCHW/NHWC 一致确认输入数据是 FP16 而不是 FP32除非另有设置推理延迟波动很大显存不足导致频繁内存换页系统 CPU 干扰多进程无锁共享 ACL 上下文用npu-smi info查显存每线程独立上下文避免物理机上其他进程抢占 CPU模型加载时报.om文件不存在文件路径错误或工件没拷贝到位使用绝对路径检查文件权限转换后模型推理精度明显下降某些层在 FP16 下溢出或者 AIPP 的归一化参数写错尝试将--output_type改为 FP32 或--precision_modeallow_fp32_to_fp16关掉部分降精度操作这个表格里的前两条是出现概率最高的尤其是 ATC 报错那一类。如果你在某一次版本升级后突然转换报错可以先想想有没有改了 ONNX 的导出环境这比去查 ATC 参数更节能。5.2 显存占用与 BatchSize 的适配经验有人可能会以为 24G 显存是个很大的容量但实际上跑模型时要留出的裕量比你想象中要多。Atlas 300V 在推理时除了模型本身占用的显存外ACL 上下文、中间结果缓存、多路流缓存也会占用一部分显存。若设置了多 batch 的输入输出缓冲区显存占用会成倍增加。以我实测的数据为例模型输入尺寸Batch显存占用YOLOv5s OM640x6401约 1.2GBYOLOv5s OM640x6404约 2.6GBYOLOv5m OM640x6401约 1.8GBYOLOv5m OM640x6404约 4.1GBYOLOv8l OM640x6401约 3.5GB24G 卡的优势在于你完全可以同时加载两个模型分别跑检测和分割并在两个模型之间共享一张输入图。我现在的视频分析方案里同一个输入 tensor 会分别 feed 给一个 YOLOv5 检测模型和一个分割模型显存总占用在 7~8GB 左右非常从容。如果你同时加载多个模型要注意一个问题ACL 的aclm.mdl.load_from_file对同一次初始化上下文内加载的模型数量没有硬性限制但每个模型的输入输出缓冲区要手动管理。我在项目中会对每一个模型建立独立的推理实例避免不同模型间的 buffer 被覆盖。5.3 实测性能数据参考最后给出一个我当前环境下的实测性能数据方便你在评估硬件时心里有底。我的测试条件是Atlas 300V 24GUbuntu 20.04CANN 8.0.RC1模型为 YOLOv5s 官方权重转换的 OMFP16 精度输入 640x640。测试项数值单次推理延迟bs1约 4~5 ms吞吐bs1单路约 200 FPS吞吐bs4单路约 350~400 FPS吞吐bs1多路 4 thread约 500 FPS卡功耗满载约 55~70W说实话这个性能表现在推理卡里算是相当能打的尤其考虑到它的功耗只有常规 GPU 的一半不到。在同价位段如果你不需要训练而是把模型从其他平台迁过来做推理服务Atlas 300V 24G 的性价比确实很突出。如果你手头已经有了一张卡建议按照上面的路径把 YOLO 跑通后再做一次针对自己模型和场景的压测数据会有更直接的参考价值。我在实际项目中踩过几次坑之后最深的一点体会是Atlas 部署和 GPU 部署的最大区别不在于“能不能跑”而在于“有没有按它的规则来”。只要把模型转换、AIPP、并发调度这三件事理顺后续的维护成本比想象中低很多。尤其是 AIPP 的布局和精度模式这两处如果一开始就配置正确基本可以规避掉后面至少一半的玄学报错。希望这篇文章能帮你少走一点弯路让你的 YOLO 早日在这张卡上稳定跑起来。