1. 先说清楚Atlas 300V 24G 到底是不是张“运算加速卡”很多朋友看到“300V 24G”第一反应是“这是不是一张显卡”或者“这玩意儿能不能拿来打游戏”——都不是。Atlas 300V 24G 是华为昇腾生态里的一款AI 推理加速卡不是图形显卡也不是训练卡专业定位是“数据中心/边缘侧推理场景的专用算力单元”。如果你把 GPU 当成一个“既能做图形渲染又能做并行计算的全能选手”那 Atlas 300V 就更像是一个“专项技能拉满的偏科生”——它不处理显示输出但针对神经网络推理里的矩阵乘法和卷积运算做了专门优化尤其擅长高吞吐、低延迟的目标检测、图像分类、语义分割这类任务。你拿它跑 YOLO 系列模型属于绝对的本职工作。另外还要区分一个容易混淆的概念昇腾产品线里310P 芯片主要用于推理910B/910C 芯片主要用于训练。Atlas 300V 用的正是基于 310P 架构的推理芯片方案。所以“是不是运算加速卡”这个问题答案是明确的是而且是专用 AI 推理加速卡它的设计目标就是在满足精度要求的前提下把单卡推理吞吐做到极致。这卡最让我满意的点在于 24GB 显存。熟悉推理部署的朋友都知道显存大小直接决定你能跑多大的模型、同时塞多少个 batch。YOLOv8m 这种参数量几千万的模型FP16 精度下单张图也就几十 MB 级别24GB 意味着你完全不需要像在 8GB 消费级显卡上那样精打细算可以在 batch 和并发上放开手脚。2. 部署 YOLO 前先搞懂 Atlas 300V 的硬件定位和驱动安装2.1 Atlas 300V 24G 的核心硬件参数解读先列一下这卡的关键规格方便后面部署时对号入座芯片方案昇腾 310P推理专用显存容量24GB算力表现FP16 推理场景下官方标称 INT8 算力可达 140 TOPS 级别不同型号和频率有差异形态标准 PCIe 加速卡被动散热为主生态依赖CANN昇腾计算架构 MindSpore/PyTorch/TensorFlow 等框架适配层这里有个实际部署中比较关键的细节Atlas 300V 的驱动和固件是分离的需要分别安装而且驱动版本、固件版本、CANN 版本三者之间有严格的配套关系。我第一次装的时候就是吃了没看兼容矩阵的亏驱动装了个新版CANN 装了个相对旧的版本结果跑模型时直接报“ACL library version mismatch”白白折腾了一个下午。所以动手之前我强烈建议你按这个顺序来拿到卡以后先记录卡本身的硬件信息包括芯片型号、固件版本如果之前刷过的话。去昇腾社区或者官方文档找“驱动固件与 CANN 版本配套表”认准一套组合不要混搭。安装顺序固定为先装驱动再装固件最后装 CANN Toolkit。2.2 环境准备与驱动安装实操我用的操作系统是 Ubuntu 20.04.6 LTS内核 5.4 系列。昇腾生态对内核版本有一定要求太新的内核偶尔会出现编译模块失败的问题。如果你用的是 Ubuntu 22.04 或更新版本也可能正常但建议还是以官方支持列表为准。安装驱动之前先确认系统已经识别到了 PCIe 设备lspci | grep -i process正常情况能看到类似Processing accelerators: Huawei Technologies Co., Ltd.的设备行。如果没有先检查 PCIe 插槽和主板的 Above 4G Decoding 设置——Atlas 300V 需要在内核中开启大内存映射否则显存资源会被限制。驱动安装我用的是.run包方式chmod x Ascend-hdk-310p-npu-driver_24.0.0_linux-aarch64.run ./Ascend-hdk-310p-npu-driver_24.0.0_linux-aarch64.run --full装完驱动后重启然后安装固件chmod x Ascend-hdk-310p-npu-firmware_24.0.0.run ./Ascend-hdk-310p-npu-firmware_24.0.0.run --full验证是否安装成功使用npu-smi infonpu-smi info如果看到类似下面的输出说明驱动和固件正常-------------------------------------------------------------------------------------------- | npu-smi 24.0.0 Version: 24.0.0 | ------------------------------------------------------------------------------------------ | NPU Name | Health | Power(W) | Temp(C) | Hugepages-Usage(page) | |------------------------------------------------------------------------------------------ | 0 | OK | 35.8 | 48 | 0 / 452013 | | 1 | OK | 36.2 | 47 | 0 / 452013 | ------------------------------------------------------------------------------------------注意这里我自己机器上是双卡环境单卡的话只会显示一张。看到 Health 状态为 OK 就说明硬件层面已经就绪。2.3 CANN Toolkit 的安装与配置要点CANN 是昇腾 AI 处理器的核心软件栈相当于 CUDA 在 NVIDIA 生态里的角色。模型转换ATC、推理运行时ACL、算子编译这些全都依赖它。我用的 CANN 版本是 8.0.RC1不同时期版本号有变化建议装当时的最新稳定版。安装方式同样是.run包默认安装到/usr/local/Ascend/ascend-toolkit/latestchmod x Ascend-cann-toolkit_8.0.RC1_linux-aarch64.run ./Ascend-cann-toolkit_8.0.RC1_linux-aarch64.run --full安装完成后环境变量是必须手动 source 的这一步非常容易被忽略source /usr/local/Ascend/ascend-toolkit/set_env.sh为了方便我习惯把这一行写进~/.bashrc避免每次新开终端都忘记。然后可以验证 CANN 是否可用which atc which msopst如果都能找到路径说明 CANN 安装成功。到这里硬件层面和软件层面的准备工作基本就完成了下一步进入真正的 YOLO 部署链路。3. 模型转换链路从 PyTorch 权重到 OM 离线模型3.1 为什么昇腾推理不用 PyTorch 直接跑很多第一次接触昇腾部署的朋友会问为什么不能像 NVIDIA GPU 那样PyTorch 训练完直接.cuda()就能推理答案在于芯片架构的根本差异。CUDA 生态里PyTorch 通过 cuDNN 和 TensorRT 等组件直接调用 GPU 算力模型训练和推理都在同一套生态内闭环。而昇腾处理器的计算核心是达芬奇架构Da Vinci它的算子执行方式、内存管理方式和 CUDA 完全不一样无法直接运行 PyTorch 的底层算子。因此昇腾推出了一套离线转换工具链PyTorch 模型先导出为 ONNX再通过ATCAscend Tensor Compiler将 ONNX 转换成昇腾专用的OM 模型Offline Model。OM 模型在转换阶段就已经完成了算子调度、内存规划、图优化等一系列动作部署时直接加载到 NPU 上执行效率和稳定性都远超在线解释执行的方式。我建议你在脑海里建立这么一条链路概念PyTorch(.pt) - ONNX(.onnx) - OM(.om) - ACL推理引擎这个流程里ONNX 只是一个“中间桥梁”真正的关键节点是 ATC 转换和 OM 模型质量。OM 的质量直接决定推理速度和你后处理要花多少精力。3.2 YOLOv5 / YOLOv8 导出 ONNX 的实操方式YOLOv5 和 YOLOv8 是目前部署频率最高的两个版本。我自己主力用的是 YOLOv8Ultralytics 官方仓库所以以下步骤以 v8 为例v5 的差别只是在导出命令上略有不同。激活你的 Python 环境确保已经安装了ultralytics包和torch。然后执行导出yolo export modelyolov8s.pt formatonnx opset12 dynamicFalse imgsz640这里几个参数说一下formatonnx导出格式必选。opset12ONNX 算子集版本。昇腾 ATC 对高版本 opset 的兼容性有一定限制实测 opset 12 最稳13 以上偶尔会遇到不支持的算子。dynamicFalse固定输入尺寸而不是动态 shape。昇腾推理优先静态 shape性能最好动态 shape 虽然在灵活性上有优势但在 ATC 转换时往往需要额外配置并且推理性能会打折。imgsz640模型输入尺寸。YOLO 系列默认就是 640x640。如果你用的是 YOLOv5 官方仓库导出命令对应为python export.py --weights yolov5s.pt --include onnx --opset 12 --imgsz 640导出完成后你会得到一个yolov8s.onnx文件。这个文件还不能直接被昇腾用需要进一步用 ATC 工具转换。3.3 ATC 转换全流程详解ATC 是昇腾部署链路里最核心的一步。我的实践经验是把 ATC 转换的过程理解成“针对昇腾硬件做定制化编译”它会对计算图做算子融合、内存复用、数据排布优化最终生成 NPU 直接执行的二进制模型。下面是针对 YOLOv8s 的 ATC 转换命令我在实际项目中反复调整过多次这个版本是稳定可用的source /usr/local/Ascend/ascend-toolkit/set_env.sh atc \ --modelyolov8s.onnx \ --framework5 \ --outputyolov8s_24g \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --output_typeFP32 \ --input_formatNCHW \ --loginfo参数逐个解释--framework5表示输入模型是 ONNX。ATC 支持多种框架5 对应 ONNX1 对应 MindSpore0 对应 TensorFlow 等。--outputyolov8s_24g输出 OM 模型的名称前缀最终会生成yolov8s_24g.om文件。--input_shape输入张量的形状YOLOv8 的输入名默认是images。这个名称可以在导出 ONNX 后通过 Netron 工具查看务必保持一致。--soc_versionAscend310P3关键参数。Atlas 300V 24G 搭载的芯片是昇腾 310P但 310P 有多个型号310P1/P2/P3 等这个参数必须跟实际硬件对应。不确定的话可以通过npu-smi info查看或者参考官方手册。填错了要么转换失败要么转换出来的 OM 在目标硬件上跑不起来。--output_typeFP32输出数据类型。这个可以根据后处理需要来调如果后处理代码需要 float 输出就用 FP32想省带宽可以用 FP16但对精度有一定影响。--loginfo输出日志级别。初次转换建议保持 info方便排查问题。转换过程一般会输出类似“ATC run success”的提示。如果报错常见原因包括算子不支持、input_shape 不匹配、算子集版本过高等。下面的章节会专门讲排查方法。4. 使用 ACL 推理写代码调用 OM 模型4.1 ACL 推理的基本概念和流程模型转换完下一步就是写推理代码。昇腾的推理运行时 API 叫做ACLAscend Computing Language基于 C 接口提供能力同时也提供了 Python 绑定。对于大多数部署场景Python 的 ACL 接口已经完全够用而且写起来效率高很多。ACL 推理的流程可以总结为五步初始化acl.init()初始化 ACL 运行时。设备管理acl.rt.set_device(0)指定使用的 NPU 设备。加载模型acl.mdl.load_from_file(yolov8s_24g.om)这一步会把 OM 模型加载到 NPU 内存中并完成计算图实例化。准备输入输出根据 OM 模型的输入输出张量描述在 NPU 上申请内存把图像数据拷贝到设备端。执行推理acl.mdl.execute()同步执行推理输出结果拷贝回主机端然后做后处理。下面我会给出一份能直接跑的代码骨架你只需要替换图像读取和模型路径就能跑通。4.2 Python 推理代码详解先安装依赖aclruntime相关的 Python 包在 CANN 安装包里自带不需要额外 pip 安装只需要确保环境变量能被找到。source /usr/local/Ascend/ascend-toolkit/set_env.sh下面是一段完整的 YOLOv8 推理代码import acl import numpy as np import cv2 # 全局变量管理 ACL 对象 acl.init() ret acl.rt.set_device(0) context, ret acl.rt.create_context(0) # 加载 OM 模型 model_path yolov8s_24g.om model_id, ret acl.mdl.load_from_file(model_path) assert ret 0, f模型加载失败: {ret} # 获取模型输入输出信息 input_desc acl.mdl.get_input_desc(model_id) output_desc acl.mdl.get_output_desc(model_id) input_data_size acl.mdl.get_input_data_size(model_id) output_data_size acl.mdl.get_output_data_size(model_id) print(f输入数据大小: {input_data_size}, 输出数据大小: {output_data_size}) # 申请设备端内存输入输出各一块 input_buffer, input_ret acl.rt.malloc(input_data_size, acl.const.ACL_MEM_MALLOC_NORMAL_ONLY) output_buffer, output_ret acl.rt.malloc(output_data_size, acl.const.ACL_MEM_MALLOC_NORMAL_ONLY) # 读取图像并做预处理 def preprocess(image_path, input_size(640, 640)): img cv2.imread(image_path) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 保持宽高比 resize其余部分填充灰色 h, w img.shape[:2] scale min(input_size[0] / w, input_size[1] / h) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(img, (new_w, new_h)) canvas np.full((input_size[1], input_size[0], 3), 114, dtypenp.uint8) x_offset (input_size[0] - new_w) // 2 y_offset (input_size[1] - new_h) // 2 canvas[y_offset:y_offset new_h, x_offset:x_offset new_w] resized # 归一化到 [0,1] 并转换成 NCHW tensor canvas.astype(np.float32) / 255.0 tensor np.transpose(tensor, (2, 0, 1)) tensor np.expand_dims(tensor, axis0) return np.ascontiguousarray(tensor) # 图像数据拷贝到设备端 img_tensor preprocess(test.jpg) acl.rt.memcpy(input_buffer, input_data_size, img_tensor, img_tensor.nbytes, acl.const.ACL_MEMCPY_DEVICE_TO_DEVICE) # 执行推理 ret acl.mdl.execute(model_id, [input_buffer], [output_buffer]) assert ret 0, f推理失败: {ret} # 输出数据拷回主机端 output_array np.zeros(output_data_size, dtypenp.uint8) acl.rt.memcpy(output_array, output_data_size, output_buffer, output_data_size, acl.const.ACL_MEMCPY_DEVICE_TO_HOST) # 注意这里得到的 output_array 是原始字节流需要根据模型输出的 Tensor 描述做 reshape # YOLOv8 的输出通常是 [1, 84, 8400] 的 float32 张量但具体要和 OM 对齐 output_np np.frombuffer(output_array, dtypenp.float32) # 这里按照实际输出 shape 处理下面的 8400 对应输入为 640x640 的 anchor 数量 try: preds output_np.reshape(1, 84, 8400) except Exception as e: print(输出 shape 解析失败:, e) print(输出总长度:, len(output_np)) # 释放资源 acl.rt.free(input_buffer) acl.rt.free(output_buffer) acl.mdl.unload(model_id) acl.rt.destroy_context(context) acl.rt.reset_device(0) acl.finalize()这段代码虽然简短但已经把 ACL 推理的整个流程都覆盖到了。有几个细节值得特别说一下acl.mdl.execute是同步阻塞接口调用后要等推理完成才返回。如果你追求吞吐后续可以换成acl.mdl.execute_async Stream 配合。输出数据的解析并不通用不同模型和不同导出方式会把输出 shape 组织成完全不同的样子。YOLOv8 原生的输出是[1, 84, 8400]其中 84 4框坐标 80COCO 类别数8400 是三个尺度特征图上的 anchor 总数。转换到 OM 后有些 ATC 版本会把输出做额外拆分变成多个输出张量此时你需要用acl.mdl.get_output_desc去逐个确认。如果你的工程里有自己的后处理NMS、置信度过滤、坐标还原等可以直接拿上面代码里的preds继续处理。注意后处理里的坐标换算要记得减掉 letterbox 的偏移量这是我调试时经常踩的坑。5. 实战优化让 YOLO 在 Atlas 300V 上跑得更快5.1 使用异步推理提升吞吐单张图的推理延迟固然重要但在很多实际部署场景里比如视频流分析、大批量离线图片处理更关键的是吞吐量——单位时间内能处理多少张图。要想把 Atlas 300V 的能力榨干就必须用异步执行。ACL 里异步推理的核心是 Stream 机制。可以把 Stream 理解成一个任务队列推理请求提交到队列后马上返回CPU 侧可以继续准备下一张图的输入数据而 NPU 侧会按顺序消费任务。这样 CPU 的数据预处理和 NPU 的推理计算就重叠起来了流水线式处理极大提升利用率。关键代码结构如下# 创建 Stream stream acl.rt.create_stream() # 准备多组输入输出内存 inputs [] outputs [] for i in range(batch_size): in_buf, _ acl.rt.malloc(input_data_size, ...) out_buf, _ acl.rt.malloc(output_data_size, ...) inputs.append(in_buf) outputs.append(out_buf) # 对每个输入执行异步推理 for i in range(batch_size): acl.rt.memcpy_async(inputs[i], ..., streamstream) acl.mdl.execute_async(model_id, [inputs[i]], [outputs[i]], stream) # 等待所有任务完成 acl.rt.synchronize_stream(stream)实践下来使用异步和多 batch 后单卡吞吐通常能比同步单张推理提升 3 到 5 倍。具体提升幅度取决于你的数据预处理耗时占比。5.2 利用 batch 推理和模型固定 shape 榨干算力上面我们导出 ONNX 时用的是固定 640x640 输入在 ATC 转换时还可以进一步指定一个 batch把模型一次性转换成一个支持多 batch 输入的 OMatc \ --modelyolov8s.onnx \ --framework5 \ --outputyolov8s_b4 \ --input_shapeimages:4,3,640,640 \ --soc_versionAscend310P3 \ --output_typeFP32使用 batch4 的模型推理时输入就是[4, 3, 640, 640]的张量一口气处理 4 张图。在推理场景中batch 模式对算力利用率提升非常明显因为 NPU 的矩阵计算单元在处理更大 batch 时更充分地被调度内存带宽的利用率也更高。不过需要注意batch 越大模型加载时占用的显存成倍增长。24GB 显存跑 YOLOv8s 的 batch4 完全没压力哪怕跑 YOLOv8m 也能撑住。但如果后续要跑更大模型建议先用npu-smi info观察显存使用率再决定 batch 大小。5.3 预处理优化用 AIPP 减少 CPU 侧负担我记得第一次部署时CPU 侧的预处理resize、归一化、维度转换几乎占满了单核NPU 反而在等数据。这时 AIPPAI Preprocessing功能就非常有用了。AIPP 是昇腾硬件内置的图像预处理引擎可以在数据从主机端拷贝到设备端时由硬件自动完成 resize、格式转换、归一化等操作。配置方式是在 ATC 转换时带上一个 AIPP 配置文件{ aipp_op: { input_format: RGB, src_image_size_h: 640, src_image_size_w: 640, crop: false, resize: { src_image_size_h: 720, src_image_size_w: 1280, size_h: 640, size_w: 640 }, mean: [0, 0, 0], min: [0, 0, 0], var: [1.0/255.0, 1.0/255.0, 1.0/255.0] } }配置好以后ATC 转换时加入atc ... --insert_op_confaipp.cfg用了 AIPP 后主机端只需要把原始图像数据连续内存拷贝到设备端即可resize 和归一化全在硬件里完成。这个优化能显著降低 CPU 占用尤其在多路视频流并发场景效果非常明显。不过要注意的是AIPP 里的 resize 是直接缩放到目标尺寸不会保持宽高比可能会导致目标轻微变形如果对精度敏感建议还是走预处理逻辑。6. 部署 YOLO 时的高频问题与排查方案说实话Atlas 300V 部署 YOLO 的坑不少很多问题不亲自踩一遍很难从文档里找出来。这一节我把自己踩过的高频问题按“现象 - 原因 - 解决方案”列出来希望能帮你少走弯路。6.1 npu-smi 命令找不到新手最容易遇到的问题。装完驱动后输入npu-smi info直接提示command not found。这个原因基本是环境变量没配。npu-smi 工具位于/usr/local/Ascend/driver/tools/目录下。解决方式把下面的内容加到~/.bashrcexport PATH/usr/local/Ascend/driver/tools:$PATHsource 完之后再试即可。6.2 ATC 转换报错“Unsupported operator”转换过程中看到[ERROR] Unsupported operator [xxx]时不要慌记住一条原则先看算子名再找替代方案。常见情况有几种模型导出时选用了过高 opset导致某些新算子 ATC 不认识。解决方式是在导出 ONNX 时使用opset12。模型里有自定义层比如某些 BoTNet 的注意力模块ATC 不支持。解决方案是拆分处理要么在导出 ONNX 前把网络改写成标准算子要么不用该模型结构。算子支持的soc_version不匹配。比如你写的--soc_versionAscend310P1但实际硬件是 310P3某些算子会报不支持。务必用npu-smi info核实芯片具体型号然后按官方手册比对对应关系。还有一个技巧ATC 支持--op_precision_mode参数可以在某些情况下强制使用特定算子实现但一般不建议一开始就调这个优先检查算子集和 soc_version。6.3 推理输出 shape 与预想不符如果你使用acl.mdl.get_output_desc发现 OM 模型的输出 shape 不是[1, 84, 8400]而是被拆分成了多个输出不要怀疑模型坏了。ATC 在转换过程中可能对输出张量做了一些合并或拆分优化。特别是 YOLOv5 的官方导出脚本它会把三个尺度的输出拆成三个张量返回。此时你的后处理代码需要针对实际输出结构去适配。最好的做法是写一个小脚本打印出所有输出的 shape 和 dtype再决定后处理逻辑for i in range(acl.mdl.get_num_outputs(model_id)): desc acl.mdl.get_output_desc(model_id) dims acl.mdl.get_desc_dims(desc) data_type acl.mdl.get_desc_data_type(desc) print(f输出 {i}: dims{dims}, dtype{data_type})6.4 自主实现 NMS不要依赖指定的后处理插件很多人刚上手时会问OM 模型能不能直接把 NMS 也包进去省得我自己写后处理答案是能但我不建议。ATC 确实支持把部分后处理算子比如 NMS编入计算图但编入后灵活性会大打折扣。实际项目中锚框数量、置信度阈值、类别过滤规则经常要调每次调整都得重新转换模型开发效率极其低下。更合理的方案是把 NMS 放在 CPU 侧用 NumPy 或 OpenCV 实现。YOLOv8 的输出也就是 8400 个候选框纯 NumPy 的 NMS 在 CPU 上处理一次耗时大约 5 到 10 毫秒而 NPU 推理本身可能也就 10 毫秒级别这点开销完全可接受。一个简单的 NMS 实现如下def nms(preds, conf_thres0.5, iou_thres0.45): boxes preds[preds[:, 4] conf_thres] if len(boxes) 0: return [] x1 boxes[:, 0] - boxes[:, 2] / 2 y1 boxes[:, 1] - boxes[:, 3] / 2 x2 boxes[:, 0] boxes[:, 2] / 2 y2 boxes[:, 1] boxes[:, 3] / 2 scores boxes[:, 4] areas (x2 - x1) * (y2 - y1) order scores.argsort()[::-1] keep [] while order.size 0: i order[0] keep.append(i) xx1 np.maximum(x1[i], x1[order[1:]]) yy1 np.maximum(y1[i], y1[order[1:]]) xx2 np.minimum(x2[i], x2[order[1:]]) yy2 np.minimum(y2[i], y2[order[1:]]) w np.maximum(0, xx2 - xx1) h np.maximum(0, yy2 - yy1) inter w * h union areas[i] areas[order[1:]] - inter iou inter / union inds np.where(iou iou_thres)[0] order order[inds 1] return boxes[keep]6.5 显存不足和内存泄漏排查长时间运行的推理服务偶尔会出现内存泄漏问题。ACL 里内存释放不及时是主要原因。我的经验是每个acl.rt.malloc一定要对应一个acl.rt.free尤其是循环内申请内存的场景最容易遗漏。另外如果在多线程场景下使用要注意 ACL 的上下文管理。每个线程最好只持有一个 context不要跨线程共享 device 上下文否则资源管理会变得极其混乱。如果你怀疑内存泄漏最简单的定位方法是定时执行npu-smi info看 NPU 显存占用是不是持续增长。如果是逐个线程排查 malloc 和 free 的对齐情况。写在最后的一些个人体会Atlas 300V 24G 这张卡我前前后后用了小半年从最初折腾驱动、转换模型、移植推理代码到现在基本能“上电就能跑”的状态最大的感受就是昇腾生态确实和 CUDA 生态不一样但也没想象中那么复杂。它的门槛主要在前期的环境配置和模型转换环节一旦把 ONNX 到 OM 这条链路跑通后续的推理开发和调优其实和 NVIDIA 平台是大同小异的。如果只让我分享一条经验给刚准备入手的同学那就是不要跳过兼容性矩阵查询这一步驱动、固件、CANN 的版本匹配是最容易被忽略、但回报率最高的一件事。另外学会用npu-smi info监控显存和温度学会看 ATC 的转换日志基本就能解决 80% 的部署问题。YOLO 部署只是这张卡的第一步后面你还可以试试跑一些更加复杂的模型比如实例分割、姿态估计、甚至某些大语言模型的推理Atlas 300V 的 24GB 显存给这些场景留了不小的想象空间。希望这篇实践笔记能让你少踩几个坑顺利把自己的模型搬到昇腾平台上跑起来。