企业官网建设流程全解析

有人问“Atlas 300V 24G到底是不是一张正常的运算加速卡”，这问题我一年前也问过自己。后来在昇腾环境上把YOLOv5、YOLOv8的推理部署完整跑通，才意识到大多数人对它的误解都来自用GPU的思维惯性。这篇文章就把Atlas上部署YOLO的完整流程、参数设置、调优手段和踩坑记录一次性讲清楚，不分段堆理论，通篇是实操。无论你手里是Atlas 300V、300I Pro还是300V Pro，核心链路基本一致，照着走能省下不少试错时间。

1. 先把Atlas 300V的底细聊清楚：24G显存与“加速卡”的认知差

先说结论：Atlas 300V 24G是一张运算加速卡，但它不是GPU，而是基于昇腾达芬奇架构的NPU推理卡。很多人在选型时看着“24GB显存”就拿它跟RTX 3090、A10比算力，这个对比从根上就不成立。它的定位是数据中心侧的专用推理硬件，走的是PCIe接口，但没有任何视频输出接口，你插上它之后显示器依然只能插主板的核显或者另一张GPU，它在系统里的角色是“计算设备”，不是“显示设备”。

我第一次拿到300V时也犯过迷糊，npu-smi info里能看到板卡信息，但设备管理器里找不到类似“显卡”的条目，一度怀疑卡没识别出来。后来才弄明白，昇腾卡的设备节点是/dev/davinci0这类，跟NVIDIA的/dev/nvidia0完全两套命名体系。你要用它，第一步就得接受这套生态差异，别拿CUDA的习惯硬套。

300V这个型号名字里的V，指的是它面向视频分析场景。它最大的特点不只是24G显存，而是板载了硬件视频解码能力（VDEC）和JPEG解码能力，这意味着视频流解码可以不占CPU资源，直接扔到卡上做。这个特性在多路视频流YOLO推理场景里非常值钱。如果你只是跑单张图片的检测，这个能力用不上，但一旦赛道切到“16路视频流同时检测”，CPU解码和显存带宽的差异就体现出来了。

再说算力预期。N卡上大家习惯用FP32的TFLOPS衡量性能，昇腾卡标称的TOPS通常包含INT8算力，所以拿“标称TOPS”直接跟N卡的TFLOPS比纯属自找没趣。实测下来，Atlas 300V跑YOLOv5s、640x640输入、bs=1，单帧推理时间在几毫秒到十几毫秒之间，这个量级跟中端推理卡相当。它真正的优势不是单帧速度，而是低功耗、多路并发、视频解码卸载这条路线。24G显存意味着你可以同时驻留多个模型，比如一个YOLOv8s做检测、一个轻量分类模型做二次筛选，这对业务灵活性很有帮助。

所以回到热搜词那个问题：300V 24G是运算加速卡吗？是，而且是很典型的推理加速卡。它能跑YOLO、能跑分类、能跑分割，甚至能跑一些经过裁剪的Transformer结构。但别指望它像训练卡一样把大模型从头训一遍，它的主战场是“训练好之后的部署推理”。

2. 跑YOLO前必须铺好的三条路：驱动、CANN与模型链路

很多人在Atlas上部署失败，不是模型本身的问题，而是卡一直没被正确“点亮”。这张卡要正常工作，需要三样东西配合：NPU驱动（包含固件）、CANN工具包、以及你的模型推理代码。三者缺一不可，版本还得互相匹配。

2.1 驱动与固件：先用npu-smi确认卡是活的

装完驱动后，第一件事不是急着配环境变量，而是执行：

npu-smi info

如果能看到类似下面的输出，说明卡已经被系统正确识别：

+-------------------+-----------------+------------------------------------------------------+ | NPU Name | Health | Power | Temp | Hugepages-Free | | 0 300V | OK | 45.6W | 53C | 0 | +-------------------+-----------------+------------------------------------------------------+

关键看两处：Health是不是OK，Temp是不是正常。如果这里显示ERROR或者板卡不出现，先查驱动安装日志，别急着往下走。驱动安装命令一般是：

chmod +x Ascend-hdk-*.run ./Ascend-hdk-*.run --upgrade

注意“--upgrade”这个参数，如果你机器上之前装过旧版驱动，不加这个参数可能装不进去或者直接报错。驱动装完重启机器，再执行npu-smi info，看到正常信息再继续。

我踩过的一个坑是：驱动装好了，但设备节点没生成。原因是没有把当前用户加入HwHiAiUser这个用户组。昇腾默认的管理用户是HwHiAiUser，如果你用root装完驱动，又用普通用户跑推理，经常会出现“无法打开设备/dev/davinci0”的报错。解决方法是：

usermod -a -G HwHiAiUser 你的用户名

然后重新登录，让用户组生效。

2.2 CANN工具包的安装与版本匹配

CANN是昇腾的计算框架，相当于CUDA Toolkit的角色。它有多个版本，比如7.0、8.0.RC1、8.1.RC1等，还区分架构（x86_64和aarch64）。安装包的后缀可以直接看出架构，比如Ascend-cann-toolkit_8.0.RC1_linux-aarch64.run就是ARM版本，别下错。

安装步骤很简单：

chmod +x Ascend-cann-toolkit_*.run ./Ascend-cann-toolkit_*.run --install

装完后需要source环境变量脚本：

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

这个脚本一定要source，而且每次开新终端都要重新source，或者把它写进~/.bashrc。很多人上一步都完成了，卡在“python import acl报ModuleNotFoundError”，十有八九是环境变量没加载。这个错误提示很迷惑，因为报错看起来像是Python包没装，实际上就是CANN的Python模块路径没加进PYTHONPATH。

2.3 从pt到om的整体链路

对YOLO来说，部署到Atlas的完整链路是：

PyTorch权重(.pt) -> 导出ONNX(.onnx) -> ATC工具转换 -> 昇腾模型(.om) -> ACL/Pipeline推理

为什么中间要过一道ONNX？因为CANN的ATC工具目前不支持直接吃.pt文件，ONNX是它最通用的中间格式。很多新手以为跟TensorRT一样能直接加载.pt转engine，在昇腾这套生态里这是不成立的，老老实实先导出ONNX是最稳的路线。

这条链路里，最容易翻车的是模型转换阶段，但大多数人却把精力花在推理代码上，顺序完全反了。om模型如果没转好，后面代码写得再漂亮都是白搭。所以下面单独用一整章把转换讲透。

3. 模型转换不是一把梭：pt到om的每个参数都值得较真

ATC（Ascend Tensor Compiler）是昇腾的模型转换工具。它吃进来ONNX、Caffe或者TensorFlow的模型，吐出一个后缀为.om的离线模型文件。om模型是已经针对特定芯片、特定输入shape做过算子调度的二进制文件，换一个芯片型号或者换一个输入分辨率，基本都需要重新转换。

3.1 导出ONNX时的两个关键点

用YOLOv5举例子，官方仓库里有export.py脚本，但我建议自己写一小段导出代码，因为官方脚本默认会做一堆优化，有时候反而引入了CANN不支持的算子。我自己用的导出方式很朴素：

import torch model = torch.load("yolov5s.pt", map_location="cpu")["model"].float() model.eval() dummy_input = torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, "yolov5s.onnx", opset_version=11, input_names=["images"], output_names=["output0", "output1", "output2"], dynamic_axes=None )

这里有两个点特别值得讲。第一，opset_version我选的是11，CANN对ONNX算子支持的覆盖度是跟着opset版本走的，太新的opset里有些算子还没适配完，反而容易转换失败。opset 11是经过大量验证的稳妥选择，如果你的模型结构特殊、某些算子必须要高的opset才能导出，可以试试13，再高就慎重。

第二，dynamic_axes设为None，也就是固定输入shape。YOLO本身对输入分辨率不敏感，640x640是性价比很高的选择。动态shape虽然灵活，但在CANN里会显著增加算子编译时间，而且性能大概率不如静态shape。业务上如果需要不同的batch，我宁可转两个om文件，一个bs=1一个bs=4，也不去搞动态shape。

3.2 ATC转换命令逐参数拆解

转换YOLOv5的命令长这样：

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

逐个解释一下，这些参数都不是摆设：

• --framework=5：固定写法，5代表ONNX。
• --input_shape：必须跟导出ONNX时的dummy_input完全一致。这里写images:1,3,640,640，其中images是ONNX里输入节点的名字，别写错，否则ATC会报找不到输入节点。
• --soc_version：芯片型号。Atlas 300V/300I Pro这类卡一般填Ascend310P3。这个参数很容易填错，最稳妥的方式是用命令查一下：

npu-smi info -t board -i 0 -c 0 | grep -i "Chip Version"

• --insert_op_conf：AIPP预处理配置文件路径。AIPP是昇腾的硬件图像预处理模块，能把图像缩放、减均值、归一化这些操作下沉到NPU执行，省去CPU端的开销。这个不配置也能转，但推理代码里就得自己做归一化。
• --log=error：只输出error级别的日志。转换出错时日志会非常多，默认info级别能把人看晕，用error能快速定位关键错误。

转换成功后，当前目录会出现一个yolov5s_bs1.om文件。你可以用atc --model=...再转换一次来覆盖输出文件，但我习惯每次都换一个output名字，避免新旧文件混在一起分不清。

3.3 AIPP配置：把缩放和归一化交给NPU

AIPP的配置文件是个protobuf文本格式，下面是一个适用于YOLOv5的基础配置：

aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: false mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 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 }

这里核心是mean_chn和var_reci_chn。AIPP内部的计算逻辑是：输出 = (输入像素值 - mean) * var_reci。YOLO训练时通常只做除以255的归一化，所以mean全填0，var_reci填1/255≈0.003921569。如果你的训练管线里用的是ImageNet的mean/std（比如跑分类模型），就得把对应的三个mean值填进去，var_reci填的是std的倒数。

input_format: RGB888_U8表示输入图像是RGB、每个通道8bit无符号整型。如果你用OpenCV读图，默认是BGR，需要先用cv2.cvtColor(img, cv2.COLOR_BGR2RGB)转成RGB，这里很容易搞反，一旦搞反，出来的检测框位置对但类别全错，或者颜色特征混乱导致漏检，排查起来非常隐蔽。

还有一个坑：AIPP的src_image_size_w/h这里写的是模型输入尺寸640x640，如果你的输入图像不是这个尺寸，AIPP会强制执行一个resize拉伸。但YOLO推理的标准姿势是letterbox，也就是保持原始长宽比、四周填充灰边。AIPP本身对这个支持很麻烦，所以我的实践是：在host端用OpenCV先把图letterbox成640x640，然后再传给NPU，AIPP只负责归一化。这样做代码多一点，但行为跟训练时完全一致，精度有保障。

3.4 转换之后输出的是什么

om模型推理后拿到的是YOLO原始的head输出。以YOLOv5s为例，你会得到三个输出tensor，对应三个不同尺度的特征图（80x80、40x40、20x20）。后处理（解码bbox、置信度过滤、NMS）需要你自己在host侧完成。这意味着，om本身不包含NMS，不要指望它像TensorRT里配置了plugin一样直接输出干净的目标框。

如果你用的是YOLOv8，它的head结构不同，输出一般是[1, 84, 8400]这种形式（4个坐标 + 80个类别分数，8400是三个尺度锚点的总和）。解析时要先转置成[1, 8400, 84]再按行处理。不同版本输出布局有差异，最好的办法是先用Python把.pt的输出打印出来看一眼shape和数值范围，再决定解析逻辑。

4. 推理端到端的两种主流写法：ACL直调与Pipeline

om模型转好之后，就要写推理代码了。我身边大部分同事第一次写昇腾推理时，第一反应是找OpenCV的DNN模块有没有CANN后端，因为在GPU上他们习惯了cv2.dnn.readNetFromTensorRT这种API。OpenCV确实提供了CANN后端的常量，但公开版的opencv-python包里根本没有编译CANN模块，你自己从源码编译OpenCV再挂CANN后端，光是折腾依赖就够喝一壶的。所以实际项目里，主流路线是ACL直调，或者用MindX SDK的pipeline。

4.1 ACL Python直调：最灵活但不难写

ACL（AscendCL）是昇腾的底层计算接口，类似CUDA Runtime API。Python版本的ACL接口封装得比较薄，但核心流程很清晰：初始化 -> 加载模型 -> 准备输入输出内存 -> 执行推理 -> 取回输出。我贴一个核心骨架：

import acl import numpy as np # 初始化 acl.init() acl.rt.set_device(0) context, ret = acl.rt.create_context(0) # 加载模型 model_path = b"yolov5s_bs1.om" model_id, ret = acl.mdl.load_from_file(model_path) # 获取模型描述信息 model_desc = acl.mdl.create_desc() acl.mdl.get_desc(model_desc, model_id) num_inputs = acl.mdl.get_num_inputs(model_desc) num_outputs = acl.mdl.get_num_outputs(model_desc) input_sizes = [] output_sizes = [] for i in range(num_inputs): input_sizes.append(acl.mdl.get_input_size_by_index(model_desc, i)) for i in range(num_outputs): output_sizes.append(acl.mdl.get_output_size_by_index(model_desc, i)) # 申请device侧内存 input_buffs = [] for size in input_sizes: buf, ret = acl.rt.malloc(size, 2) # 第二个参数是2MB对齐 input_buffs.append(buf) output_buffs = [] for size in output_sizes: buf, ret = acl.rt.malloc(size, 2) output_buffs.append(buf)

推理时，把预处理后的numpy数组拷到device内存，然后执行：

# 输入已经是 [1,3,640,640] float32 input_data = np.ascontiguousarray(preprocessed_img, dtype=np.float32) input_ptr = acl.util.numpy_to_ptr(input_data) acl.rt.memcpy(input_buffs[0], input_sizes[0], input_ptr, input_sizes[0], 1) # 1: H2D ret = acl.mdl.execute(model_id, input_buffs, input_sizes, output_buffs, output_sizes) # 取回输出 output_np = np.zeros(output_sizes[0], dtype=np.uint8) out_ptr = acl.util.numpy_to_ptr(output_np) acl.rt.memcpy(out_ptr, output_sizes[0], output_buffs[0], output_sizes[0], 2) # 2: D2H

这里最需要注意的是acl.rt.memcpy的最后一个参数：1代表Host到Device，2代表Device到Host。方向反了不一定会报错，但数据全是乱的。然后acl.util.numpy_to_ptr这个函数要求传入的numpy数组必须连续内存，所以我特意先调np.ascontiguousarray，防止你传入一个转置或者切片之后的内存不连续数组，否则指针会指错。

acl.mdl.execute是同步推理接口，意思是执行完才返回。线程里直接顺序调用即可，不需要额外的同步操作。如果用多路视频流，可以每个路数开一个线程，分别有自己的device内存，这样最简单。

4.2 用完后记得清理内存

写完推理逻辑之后，有件事不做的话，跑几个小时必挂：释放内存。

for buf in input_buffs: acl.rt.free(buf) for buf in output_buffs: acl.rt.free(buf) acl.mdl.unload(model_id) acl.rt.destroy_context(context) acl.rt.reset_device(0) acl.finalize()

我最开始写的推理服务跑了一个通宵，第二天早上看到内存暴涨到了20多个G，就是因为在循环里反复申请device内存但没释放。昇腾的device内存分配走的是显存池，频繁malloc/free会导致碎片，所以如果你有一个低延迟的请求处理循环，最好的做法是：启动时统一申请好内存，循环里只做memcpy和execute，结束进程时再统一释放。

4.3 MindX SDK Pipeline：适合多路视频流的现成方案

如果你不想跟ACL接口较劲，或者你要做的是多路视频流同时检测，那MindX SDK（mxVision）是很省力的选择。它的核心思路是把解码、缩放、推理、后处理这些步骤写成一个个plugin，然后用yaml声明它们之间的依赖关系，形成一个pipeline。对于YOLO这类成熟模型，mxVision自带后处理插件，连解码bbox的代码都不用自己写。

我之前用MindX SDK接过16路的RTSP视频流，pipeline的配置核心是确定每个节点做什么，比如mxpi_videodecoder负责解码、mxpi_tensorinfer负责模型推理、mxpi_yolov5postprocess负责后处理。配置好之后，业务代码只需要向pipeline塞视频流地址，再从输出端口拿目标框结果。对比ACL直调，这种方式开发效率高得多，但灵活性差一些，如果你要跑的是自己魔改的YOLO结构，后处理插件可能对不上，这时候还是得回到ACL自己写。

我的个人建议是：单路、自定义模型、需要精细控制就用ACL直调；多路视频流、标准YOLO结构、项目周期短就用MindX SDK。先想清楚场景再选路线，不要一上来就追求底层接口。

5. 从能跑到跑得久：性能调优与显存控制的实测笔记

模型能出框了，只算完成了一半。部署场景里更关键的是稳定性和资源占用。我自己在Atlas 300V上做过一轮系统性的性能调优，把几个核心结论分享一下。

5.1 算力预期：先别急着调，先测准

很多人在调优之前连基准数据都没有，上来就改代码，等于瞎调。我建议先跑一个最简单的循环：读一张静态图，连续推理100次，统计平均时延。注意要把GPU/NPU的初次预热排除掉，前几次推理会慢得离谱，因为算子调度、内存预分配都发生在第一轮。

一个合理的参考数字：YOLOv5s、640x640、bs=1、纯推理（不含图像预处理），在Atlas 300V上跑出5-15ms的均值都是正常的，具体跟CANN版本、卡的温度、PCIe带宽有关。如果超过20ms，先看你的代码是不是把数据拷贝和推理串行化了，确认输入图像是否在host和device之间反复搬移。

5.2 batch与多stream的取舍

单帧单次推理是延迟优先的场景。如果你的业务是边缘盒子或实时车道检测，那bs=1是必须的，不能为了吞吐牺牲延迟。但如果是离线批处理，或者单路视频流里每帧都要查的情况，适当提高batch可以显著提升吞吐。

下面是我在300V上实测过的一组经验数据（不同模型会有差异，仅供参考）：

无论用哪个batch，都要注意显存占用。24G显存看着挺大，但如果你同时加载两个bs=8的模型、再加上视频解码的帧缓冲，很快就吃紧了。我在线上服务里用npu-smi info里看显存占用时，长期稳定在60%-70%，始终留着一部分余量，因为显存一旦打满，设备会直接报错而不是自动换出。

5.3 瓶颈定位：到底是卡在NPU还是卡在数据搬运

有个现象我见过不止一次：明明NPU推理很快，但整个服务的帧率就是上不去。用msprof工具跑一下profiling就会发现，时间全耗在host侧图像预处理和内存拷贝上。这时候调什么模型参数都没用，该做的是把图像缩放、归一化这些操作扔给AIPP，或者至少优化一下图像解码的路径。

msprof的基本用法是：

msprof --application="python your_infer.py" --output=profout

跑完之后分析profiling结果，重点看三个环节的耗时占比：

• CPU侧预处理（图像解码、resize、归一化）
• host和device之间的数据拷贝
• NPU上的模型推理时间

如果CPU预处理占比超过30%，就该考虑用AIPP或者多线程流水线。如果拷贝占比高，看看能不能申请固定的page-locked内存，减少寻页开销。

5.4 长时间运行的稳定性要点

线上服务最怕的不是慢，而是跑着跑着内存爆了。我自己的经验是：推理服务跑24小时以上，内存还稳定不涨，才算合格。下面这几点是必须做到的：

第一，推理循环里不要反复创建和销毁context。context创建开销很大，而且在某些CANN版本里销毁不干净会疑似泄漏。建议一个进程只创建一个context，所有线程共享。

第二，输出的numpy数组不要直接持有device内存指针。从device拷回host后，立刻转成普通的numpy数组并明确释放引用。如果每次都让numpy对象带着device的buffer引用，这个buffer永远不会被回收。

第三，开线程处理多路视频流时，不要让每个线程都加载一遍om模型。同一块卡、同一个模型，加载一次拿到model_id，所有线程共用这个model_id推理。多加载几次不只是浪费显存的问题，在一些版本里还会导致推理调度变慢。

6. 踩坑实录：我在Atlas上部署YOLO翻过的那几个车

最后这部分，我想按“现象-排查过程-根因-解决”的顺序复盘几个真实翻车现场。这些坑单看都不难，但组合在一起，可能让一个新手卡上一两周。

6.1 设备节点消失：驱动装了，npu-smi看不到卡

现象：驱动安装全程无报错，但npu-smi info输出只有主机信息，板卡列表为空。

排查过程：我先确认了PCIe设备能否被系统识别，执行lspci | grep -i process，能看到华为的设备条目，说明硬件层面通了。接着查看驱动日志，发现有一条关于firmware版本过低的告警。最后比对官网驱动说明，发现这张卡的最低固件版本要求是某个特定版本，而我装的是旧版驱动里自带的固件。

解决：单独下载对应版本的固件升级包，执行升级后重启，npu-smi info就正常了。

经验：遇到卡不被识别，别反复重装同样的驱动包，先查固件版本。驱动和固件是两个独立的安装包，很多新手只装驱动不装固件，或者固件版本搭配不对，这属于高频翻车点。

6.2 推理输出全零：模型转换成功了，但结果是坏的

现象：om模型加载成功，推理执行成功，但输出的tensor全是0或者极小值。

排查过程：这个问题最难的地方在于报错为零。我先用同样的输入在PyTorch里跑了一遍，确认onnx模型输出是正常的；接着怀疑是输入数据有问题，打印了输入numpy数组的数值范围和dtype，发现dtype是float32、范围在0到1之间，看起来没问题；最后检查AIPP配置，发现问题在于我同时做了两件事：AIPP配置里设了mean和var_reci，但host侧代码又把图像归一化了一遍。

根因：AIPP执行了归一化，host侧又做了一次归一化，相当于归一化了两遍，模型接收到的输入分布跟训练时完全不一致，输出自然废了。

解决：二选一。要么在host侧只做resize和转RGB，把归一化交给AIPP；要么完全不配置AIPP，host侧一次做完resize、归一化、转NCHW。最怕的就是两边都做，两边都没想到对方。

6.3 后处理坐标对不上：框的位置整体偏移

现象：检测框能出来，类别也基本正确，但框的位置在原图上明显偏了，尤其是目标靠近图像边缘时，框跟物体错开很多。

排查过程：我一开始怀疑是模型没训练好，但同样的模型在GPU上用TensorRT推理位置就是准的。后来认真看了letterbox的代码，发现在还原坐标到原图尺寸时，只考虑了scale缩放比例，忘了把letterbox的padding偏移加回去。

根因：图像从原始分辨率缩放到640x640时做了等比缩放并填充灰边，模型输出的bbox坐标是相对640x640画布的位置，还原到原图时必须先把坐标减去padding的偏移，再除以缩放比例。漏了padding偏移，越靠近边缘误差越大。

解决：在解码bbox时，把letterbox记录的pad_x和pad_y正确减掉：

x_original = (x_640 - pad_x) / scale y_original = (y_640 - pad_y) / scale

这个逻辑虽然简单，但我在实际项目里见过至少三个人踩同一个坑，写完代码没过单测就直接扔进线上，最后框全漂移。

6.4 性能忽高忽低：同一段推理代码，时延波动明显

现象：单帧推理时延在5ms和25ms之间剧烈跳动，很不稳定。

排查过程：我用msprof抓了profiling，发现慢的帧基本都卡在CPU侧的图像解码和resize上，不是NPU的问题。进一步看，服务器上还有其他服务在抢CPU资源，导致我的预处理线程时不时被调度打断。

解决：第一，把预处理线程绑核运行，避免被频繁迁移导致cache失效；第二，图像解码和resize用单独的线程池，跟推理线程解耦，形成流水线。

经验：在真机上做推理服务，永远是端到端的Pipeline思维，不能只看NPU单点耗时。CPU侧预处理能力必须跟上NPU的推理速度，否则再快的卡也会被前处理拖累。

6.5 模型能转但精度差：同一个om，不同输入表现差异大

现象：白天场景检测正常，到了夜间或者暗光场景，漏检增多，置信度普遍下降。

排查过程：对比了正常的GPU推理结果，GPU一切都好。于是怀疑是AIPP的归一化参数固定写死导致暗光下特征被压缩。检查AIPP配置，发现mean填了0、var_reci填了1/255，这个对正常亮度图没问题，但暗光图像素值本来就低，再除以255之后特征被压得更扁。

解决：这个问题本质上不是AIPP配置错误，而是固定预处理参数无法适应宽动态范围输入。对于夜景这类场景，我们最后的方案是在host侧做了自适应亮度调整，再喂给模型，而不是依赖AIPP。

经验：AIPP适合标准化输入，如果业务场景光照变化大，预处理环节最好保留在host侧，想清楚再决定是否下沉到硬件。

最后再分享一个我自己的习惯：在Atlas上做YOLO部署，我永远会保留一套“最低可行性验证”脚本——从加载om开始，到输出几个关键tensor的shape、均值、方差为止，整个过程不超过20行代码。每次修改任何配置或参数后，先跑这个脚本确认tensor输出还在合理范围，再进完整的后处理流程。很多看不见的坑，都是被这一步提前拦住的。