1. 项目缘起与整体设计思路1.1 为什么选择征程6M加YOLOv8s这个组合把YOLOv8s塞进地平线征程6M这个组合在当下量产智驾项目里出现的频率越来越高。征程6M单颗芯片算力标称128TOPS实际可用BPU算力要打折扣但应付YOLOv8s这种量级的检测网络绰绰有余。YOLOv8s本身参数量约11M输入640×640时FLOPs在28.6G左右属于轻量级检测头里精度和速度平衡得比较好的选择。我选这个组合的核心逻辑有三点。第一是算力匹配度征程6M的BPU架构对卷积类算子友好YOLOv8s的骨干网络以C2f模块和标准卷积为主没有太多花哨的注意力机制量化友好度高。第二是工具链成熟度地平线的OE工具链对YOLO系列的支持经过几代迭代已经比较稳定从ONNX导出到量化编译的链路踩坑成本可控。第三是量产落地需求很多项目需要在一个中算力平台上同时跑检测、车道线、甚至部分预测任务YOLOv8s占用的算力预算不会把其他任务挤死。这里要明确一个认知不是所有YOLOv8s都能顺利上征程6M。官方Model Zoo里有参考实现但实际项目里你拿到的往往是自定义数据集训练出来的权重类别数、输入分辨率、甚至网络结构都可能和官方有差异。所以整个部署流程的核心不是“跑通”而是“跑稳且精度不掉”。1.2 整体部署链路拆解整个部署链路我习惯分成五个阶段每个阶段都有明确的输入输出和验收标准阶段核心任务输入输出验收标准模型准备PyTorch权重导出ONNX.pt文件.onnx文件ONNX Runtime推理结果与PyTorch一致模型检查算子兼容性分析.onnx文件算子支持列表无不支持算子或已确定替代方案量化校准PTQ量化校准.onnx校准数据量化模型余弦相似度0.99编译部署模型编译上板量化模型.hbm文件板端推理结果与仿真一致精度调优板端精度对齐.hbm测试集精度报告mAP下降1%这个链路里最容易出问题的是量化校准和精度调优两个环节。很多人以为模型编译过了就万事大吉结果上板一跑发现mAP掉了十几个点回头查发现是校准集分布和实际场景差太远。1.3 关键设计决策与取舍在动手之前有几个决策点需要想清楚这些决策会直接影响后续所有工作输入分辨率的选择。YOLOv8s默认640×640但征程6M的BPU对输入尺寸有对齐要求。我实测下来640×640是支持最好的如果改成608×608或者512×512虽然能省算力但需要重新调整anchor和特征图尺寸而且量化时的校准集也要对应调整。除非算力实在紧张否则建议保持640×640。是否保留后处理在CPU。YOLOv8s的输出是三个尺度的特征图后处理包括解码和NMS。地平线工具链支持把部分后处理放到BPU上加速但配置复杂且容易出bug。我的建议是第一版部署先把后处理放CPU跑通之后再考虑优化。CPU后处理在征程6M的A核上跑640×640输入下耗时大约8-12ms对于大部分项目可以接受。量化方式的选择。地平线支持PTQ和QAT两种。PTQ上手快但精度损失可能较大QAT精度好但需要改训练代码重新训练。我的经验是如果PTQ后mAP下降在2个点以内优先用PTQ如果下降超过3个点再考虑QAT。不要一上来就QAT时间成本太高。注意征程6M的BPU对某些激活函数和算子有特殊要求比如SiLU在量化时可能被替换成HardSwish的近似实现这会带来精度差异。在模型设计阶段就要考虑这些约束。2. 核心细节解析与实操要点2.1 模型导出ONNX的隐藏陷阱从PyTorch导出ONNX看起来是一行代码的事但YOLOv8s导出时有几个坑必须提前处理。第一个坑是输出节点命名。Ultralytics的YOLOv8导出ONNX时默认输出节点名字是output0形状是[1, 84, 8400]。这个84是4个bbox坐标加80个类别分数。但地平线工具链在解析时对输出节点的数量和命名有要求建议在导出时显式指定输出节点名称并且确认输出维度顺序是工具链期望的格式。第二个坑是动态维度。导出时一定要用dynamicFalse固定所有维度征程6M的BPU不支持动态shape。如果导出时带了动态batch或者动态height/width后续编译会直接报错。第三个坑是opset版本。我试过opset 11、12、13、17几个版本最稳的是opset 11。opset 17导出的模型里有些算子会被拆成更细粒度的子图反而增加编译难度。opset 11的算子集和地平线工具链的兼容性最好。导出命令参考yolo export modelyolov8s.pt formatonnx opset11 simplifyTrue dynamicFalse imgsz640导出后一定要用ONNX Runtime跑一遍验证确认输出和PyTorch一致。我习惯用一张固定图片分别用PyTorch和ONNX Runtime推理对比输出的最大绝对误差正常应该在1e-4量级。2.2 算子兼容性检查的实操方法ONNX导出后不要急着量化先做算子兼容性检查。地平线OE工具链提供了hb_model_checker工具可以扫描ONNX里的所有算子并给出支持情况。实际操作中YOLOv8s的算子兼容性通常没问题但有几个地方需要留意Resize算子YOLOv8s的上采样用的是最近邻插值这个BPU支持。但如果你的模型里用了双线性插值且align_cornersTrue可能需要改成align_cornersFalse。Concat算子C2f模块里有大量ConcatBPU支持但要求所有输入张量的通道对齐。如果通道数不是16的倍数编译时可能报错。Split算子YOLOv8的Detect头里有Split这个算子在某些工具链版本里支持不好可能需要用Slice替代。检查命令hb_model_checker --model yolov8s.onnx --output check_result.json检查结果里会列出每个算子的支持状态。如果有不支持或部分支持的算子需要回到PyTorch层面修改网络结构重新导出。实操心得我遇到过C2f模块里的Split在量化时被错误处理导致某个分支的输出全零。后来把Split改成两个Slice操作就正常了。这种问题在仿真阶段不一定暴露上板才会发现所以算子检查一定要做细。2.3 校准集制作的核心原则PTQ量化的精度高度依赖校准集的质量。校准集不是随便找几百张图就完事有几个原则必须遵守分布匹配原则。校准集的图像分布必须和实际部署场景一致。如果你的模型是跑在车载前视摄像头上的校准集就要用实际路测数据而不是COCO或者ImageNet的图。我见过一个项目用COCO校准结果上板后夜间场景漏检严重就是因为COCO里夜间图太少。数量适中原则。校准集不是越多越好。地平线工具链建议100-500张。我实测下来200张左右是个甜点再多收益递减而且校准过程耗时线性增长。关键是多样性而不是数量。预处理一致原则。校准集的预处理必须和推理时完全一致包括resize方式、归一化参数、通道顺序。如果推理时用的是letterbox resize校准集也必须用letterbox不能用直接resize。校准集目录结构calib_data/ ├── image_0001.jpg ├── image_0002.jpg ├── ... └── image_0200.jpg配合一个calib_list.txt列出所有图片路径。注意图片格式建议用jpgpng也可以但读取会慢一些。2.4 量化配置文件的参数详解地平线的量化配置文件是个yaml里面有几个关键参数直接决定量化精度model: input_type: rgb input_shape: [1, 3, 640, 640] mean: [0, 0, 0] scale: [0.003921568627, 0.003921568627, 0.003921568627] calibration: cali_type: default cali_num: 200 calibration_type: kl quantization: activation_quantization: int8 weight_quantization: int8 bias_quantization: int32mean和scale要和训练时的归一化参数一致。YOLOv8默认是0-1归一化所以scale是1/255mean是0。如果训练时用了ImageNet的mean和std这里要对应改。calibration_type选kl还是max这个有讲究。kl散度校准对激活值分布比较敏感适合分布比较集中的场景max校准简单粗暴适合分布比较分散的场景。我一般先用kl如果精度不好再试max。per_channel量化建议开启对权重的量化精度提升明显而且征程6M的BPU支持per_channel量化不会增加推理耗时。3. 实操过程与核心环节实现3.1 环境搭建与工具链安装地平线OE工具链的安装是个体力活依赖比较多。我习惯用Docker环境避免污染宿主机。官方提供了Docker镜像但版本要选对征程6M需要OE 3.0以上的版本。安装完成后先验证hb_mapper --version hb_model_checker --version hb_compiler --version三个命令都能正常输出版本号才算环境OK。如果报错找不到库大概率是LD_LIBRARY_PATH没设对。注意OE工具链对Python版本有要求建议用Python 3.8或3.103.9有时候会有奇怪的兼容性问题。CUDA版本建议11.8和工具链的GPU算子匹配最好。3.2 模型转换完整流程整个转换流程我整理成一个可复现的脚本# Step 1: 导出ONNX yolo export modelyolov8s.pt formatonnx opset11 simplifyTrue dynamicFalse imgsz640 # Step 2: 算子检查 hb_model_checker --model yolov8s.onnx --output check_result.json # Step 3: 准备校准集 python prepare_calib.py --source ./train_images --output ./calib_data --num 200 # Step 4: 量化编译 hb_mapper makertbin --config yolov8s_config.yaml --model-type onnx # Step 5: 精度仿真 hb_mapper inference --model yolov8s_quantized_model.bin --input ./test_images --output ./sim_resultStep 4的makertbin是整个流程的核心它会依次执行量化、优化、编译三个子步骤。如果中间任何一步失败日志里会有详细报错。我建议把日志级别开到DEBUG方便排查。编译成功后会在model_output目录下生成.hbm文件这个就是最终上板的模型文件。3.3 板端部署与推理验证模型编译好之后通过地平线的部署工具把.hbm文件推到板子上。板端推理的代码框架大致如下from hobot_dnn import pyeasy_dnn as dnn import numpy as np # 加载模型 models dnn.load(./yolov8s.hbm) model models[0] # 获取输入输出信息 input_shape model.inputs[0].properties.shape output_shapes [out.properties.shape for out in model.outputs] # 预处理 def preprocess(img, target_size640): # letterbox resize h, w img.shape[:2] scale min(target_size/h, target_size/w) new_h, new_w int(h*scale), int(w*scale) resized cv2.resize(img, (new_w, new_h)) canvas np.full((target_size, target_size, 3), 114, dtypenp.uint8) canvas[:new_h, :new_w] resized return canvas, scale # 推理 input_tensor preprocess(img)[0].astype(np.uint8) outputs model.forward(input_tensor) # 后处理 def postprocess(outputs, conf_thres0.25, iou_thres0.45): # 解码 NMS ...板端推理有几个性能关键点输入数据格式。征程6M的BPU输入支持NV12和RGB两种格式。如果摄像头输出是NV12直接送NV12可以省一次格式转换但需要模型训练时就用NV12数据。如果模型是RGB训练的就要在CPU上做NV12到RGB的转换这个转换在640×640下大约耗时2-3ms。内存对齐。BPU的输入输出张量要求16字节对齐如果不对齐会触发额外的内存拷贝。在分配输入buffer时要注意。多线程推理。征程6M有多个BPU核心可以通过多线程并行推理提升吞吐。但YOLOv8s单帧推理时间已经比较短多线程的收益主要体现在多路视频场景。3.4 精度对齐与调优实录板端跑通之后最重要的一步是精度对齐。我习惯用以下流程在PC上用ONNX Runtime跑测试集记录mAP作为baseline用仿真工具跑量化后的模型记录mAP板端跑同样的测试集记录mAP对比三个结果定位精度损失发生在哪个环节正常情况下仿真mAP和板端mAP应该几乎一致差异0.1%。如果差异大说明板端推理有问题比如预处理不一致或者后处理参数不同。仿真mAP和ONNX baseline的差异就是量化损失。如果量化损失超过2个点需要调优调优手段一调整校准集。增加校准集数量或者替换更有代表性的图片。我遇到过一次量化后小目标漏检严重后来在校准集里增加了大量小目标场景的图片问题解决。调优手段二混合量化。对精度敏感的层比如Detect头的最后几层保持FP16其他层用INT8。地平线工具链支持通过配置文件指定某些层不量化。调优手段三调整量化参数。把calibration_type从kl改成max或者调整per_channel的设置。调优手段四QAT。如果以上都不行只能上QAT。QAT需要在训练代码里插入伪量化节点重新训练几个epoch。虽然麻烦但精度恢复效果最好。实操心得我做过一个项目PTQ后mAP从42.1掉到38.5试了各种校准集调整都只能恢复到39.8。最后上了QAT训练了10个epochmAP恢复到41.9基本无损。所以如果项目对精度要求高QAT的时间投入是值得的。4. 常见问题与排查技巧实录4.1 编译阶段常见报错与解决编译阶段是报错最集中的地方我整理了一个速查表报错信息原因解决方法Unsupported op: SplitSplit算子不支持用Slice替代SplitShape mismatch in Concat通道数不对齐调整网络使通道数为16的倍数Input shape not aligned输入尺寸不对齐确保H和W是32的倍数Calibration failed校准集路径错误或图片损坏检查calib_list.txt和图片完整性Out of memory模型太大或校准集太多减少校准集数量或降低输入分辨率其中通道对齐问题最隐蔽。YOLOv8s的C2f模块输出通道数通常是64、128、256这种都是16的倍数一般没问题。但如果你改了网络结构比如把某个卷积的输出通道改成48就可能触发对齐问题。4.2 板端推理精度异常的排查思路板端精度异常通常表现为mAP大幅下降或者输出全零。排查思路按以下顺序第一步检查输入数据。把板端预处理后的输入张量dump出来和PC上的预处理结果对比。我遇到过一次板端图片读取时通道顺序搞反了BGR当RGB导致mAP直接掉到个位数。第二步检查输出张量。把板端输出和仿真输出对比看差异在哪个尺度上。如果某个尺度的输出全零说明那个分支的量化出了问题。第三步检查后处理。后处理的解码逻辑要和训练时完全一致。YOLOv8的解码涉及anchor点和stride如果stride搞错了框的位置会整体偏移。第四步检查量化配置。确认板端加载的.hbm文件和仿真用的是同一个。有时候编译了多个版本部署时拿错了文件。4.3 性能优化实战技巧精度对齐之后下一步是性能优化。征程6M上YOLOv8s的推理耗时我实测在15-20ms左右单核BPU优化后可以压到12ms以内。优化手段包括输入分辨率降级。如果场景允许把640×640降到512×512推理耗时可以降低约35%。但需要重新训练模型或者至少重新校准。后处理优化。CPU后处理是耗时大户可以用C重写后处理比Python快3-5倍。或者把NMS放到BPU上但配置复杂。模型剪枝。对YOLOv8s的骨干网络做通道剪枝减少计算量。剪枝后需要微调恢复精度。多核并行。征程6M有多个BPU核心可以把模型的不同层分配到不同核心上并行执行。这个需要工具链支持配置起来比较麻烦。注意性能优化不要过早进行。先把精度调好再优化性能。我见过有人为了追求低延迟把分辨率降到416结果mAP掉了8个点最后还得改回来。4.4 量产部署的注意事项从Demo到量产还有一段路要走几个关键点温度稳定性。征程6M在高温下BPU频率会降推理耗时会增加。量产前要做高低温测试确认在-40°C到85°C范围内性能满足要求。内存占用。除了模型本身还要考虑输入输出buffer、中间张量、后处理的内存占用。征程6M的内存有限如果同时跑多个模型要仔细规划内存分配。模型加密。量产模型需要加密防止被提取。地平线工具链支持模型加密但加密后的模型加载会慢一些。版本管理。模型文件、配置文件、校准集都要做版本管理。我吃过亏量产时发现板端模型和测试时的不是同一个版本排查了半天。长尾场景验证。测试集上的mAP好看不代表实际场景好用。要专门收集长尾场景夜间、逆光、雨雾、遮挡做验证这些场景的精度往往比平均mAP低很多。5. 个人实操体会与后续扩展方向5.1 踩过的坑与经验总结做征程6M加YOLOv8s部署这个事我前后做了三个项目踩过的坑总结下来有这么几条。第一条不要迷信官方Model Zoo。官方提供的YOLOv8s参考实现和你的实际模型可能有差异直接套用配置大概率出问题。一定要从自己的ONNX出发一步步走完整个流程。第二条校准集的质量决定量化上限。我试过用1000张COCO图校准效果还不如200张实际场景图。校准集要“精”不要“多”要“像”不要“全”。第三条仿真和板端不一致时先查预处理。90%的仿真板端不一致问题都出在预处理上包括resize方式、归一化参数、通道顺序。把预处理代码在PC和板端各跑一遍dump出输入张量对比问题一目了然。第四条QAT不是洪水猛兽。很多人怕QAT麻烦宁愿接受精度损失。但实际上QAT的代码改动量不大Ultralytics的框架已经支持加个配置就能跑。如果项目对精度要求高QAT是值得的。第五条性能优化要留余量。量产时的实际耗时往往比实验室高20-30%因为要考虑温度、内存竞争、多任务调度等因素。设计时按实验室耗时的1.5倍来规划算力预算。5.2 后续可以扩展的方向这个部署方案跑通之后还有几个方向可以继续深挖。多模型并行。征程6M的算力可以同时跑YOLOv8s和车道线检测、可行驶区域分割等任务。多模型并行的挑战在于算力分配和内存管理需要仔细规划。BEV感知。YOLOv8s做2D检测只是第一步后续可以扩展到BEV视角的3D检测。征程6M支持BEV相关的算子但模型设计和量化会更复杂。端到端优化。把预处理和后处理也放到BPU上实现全流程硬件加速。地平线工具链支持自定义算子可以把letterbox resize和NMS都做成BPU算子。模型小型化。YOLOv8n比YOLOv8s更轻量如果场景允许可以换成YOLOv8n进一步降低算力占用。但精度会有所下降需要评估是否可接受。量化感知训练深化。目前的QAT只是简单插入伪量化节点后续可以研究更精细的量化策略比如对不同层用不同的量化位宽进一步压缩模型同时保持精度。这个项目做下来最大的感受是部署不是终点而是起点。模型跑通只是第一步真正难的是在量产环境下保持稳定和精度。每一次精度掉点、每一次性能不达标都是对细节的考验。把每个环节做扎实把每个参数搞清楚才能做出真正能用的东西。
1. 项目缘起与整体设计思路1.1 为什么选择征程6M加YOLOv8s这个组合把YOLOv8s塞进地平线征程6M这个组合在当下量产智驾项目里出现的频率越来越高。征程6M单颗芯片算力标称128TOPS实际可用BPU算力要打折扣但应付YOLOv8s这种量级的检测网络绰绰有余。YOLOv8s本身参数量约11M输入640×640时FLOPs在28.6G左右属于轻量级检测头里精度和速度平衡得比较好的选择。我选这个组合的核心逻辑有三点。第一是算力匹配度征程6M的BPU架构对卷积类算子友好YOLOv8s的骨干网络以C2f模块和标准卷积为主没有太多花哨的注意力机制量化友好度高。第二是工具链成熟度地平线的OE工具链对YOLO系列的支持经过几代迭代已经比较稳定从ONNX导出到量化编译的链路踩坑成本可控。第三是量产落地需求很多项目需要在一个中算力平台上同时跑检测、车道线、甚至部分预测任务YOLOv8s占用的算力预算不会把其他任务挤死。这里要明确一个认知不是所有YOLOv8s都能顺利上征程6M。官方Model Zoo里有参考实现但实际项目里你拿到的往往是自定义数据集训练出来的权重类别数、输入分辨率、甚至网络结构都可能和官方有差异。所以整个部署流程的核心不是“跑通”而是“跑稳且精度不掉”。1.2 整体部署链路拆解整个部署链路我习惯分成五个阶段每个阶段都有明确的输入输出和验收标准阶段核心任务输入输出验收标准模型准备PyTorch权重导出ONNX.pt文件.onnx文件ONNX Runtime推理结果与PyTorch一致模型检查算子兼容性分析.onnx文件算子支持列表无不支持算子或已确定替代方案量化校准PTQ量化校准.onnx校准数据量化模型余弦相似度0.99编译部署模型编译上板量化模型.hbm文件板端推理结果与仿真一致精度调优板端精度对齐.hbm测试集精度报告mAP下降1%这个链路里最容易出问题的是量化校准和精度调优两个环节。很多人以为模型编译过了就万事大吉结果上板一跑发现mAP掉了十几个点回头查发现是校准集分布和实际场景差太远。1.3 关键设计决策与取舍在动手之前有几个决策点需要想清楚这些决策会直接影响后续所有工作输入分辨率的选择。YOLOv8s默认640×640但征程6M的BPU对输入尺寸有对齐要求。我实测下来640×640是支持最好的如果改成608×608或者512×512虽然能省算力但需要重新调整anchor和特征图尺寸而且量化时的校准集也要对应调整。除非算力实在紧张否则建议保持640×640。是否保留后处理在CPU。YOLOv8s的输出是三个尺度的特征图后处理包括解码和NMS。地平线工具链支持把部分后处理放到BPU上加速但配置复杂且容易出bug。我的建议是第一版部署先把后处理放CPU跑通之后再考虑优化。CPU后处理在征程6M的A核上跑640×640输入下耗时大约8-12ms对于大部分项目可以接受。量化方式的选择。地平线支持PTQ和QAT两种。PTQ上手快但精度损失可能较大QAT精度好但需要改训练代码重新训练。我的经验是如果PTQ后mAP下降在2个点以内优先用PTQ如果下降超过3个点再考虑QAT。不要一上来就QAT时间成本太高。注意征程6M的BPU对某些激活函数和算子有特殊要求比如SiLU在量化时可能被替换成HardSwish的近似实现这会带来精度差异。在模型设计阶段就要考虑这些约束。2. 核心细节解析与实操要点2.1 模型导出ONNX的隐藏陷阱从PyTorch导出ONNX看起来是一行代码的事但YOLOv8s导出时有几个坑必须提前处理。第一个坑是输出节点命名。Ultralytics的YOLOv8导出ONNX时默认输出节点名字是output0形状是[1, 84, 8400]。这个84是4个bbox坐标加80个类别分数。但地平线工具链在解析时对输出节点的数量和命名有要求建议在导出时显式指定输出节点名称并且确认输出维度顺序是工具链期望的格式。第二个坑是动态维度。导出时一定要用dynamicFalse固定所有维度征程6M的BPU不支持动态shape。如果导出时带了动态batch或者动态height/width后续编译会直接报错。第三个坑是opset版本。我试过opset 11、12、13、17几个版本最稳的是opset 11。opset 17导出的模型里有些算子会被拆成更细粒度的子图反而增加编译难度。opset 11的算子集和地平线工具链的兼容性最好。导出命令参考yolo export modelyolov8s.pt formatonnx opset11 simplifyTrue dynamicFalse imgsz640导出后一定要用ONNX Runtime跑一遍验证确认输出和PyTorch一致。我习惯用一张固定图片分别用PyTorch和ONNX Runtime推理对比输出的最大绝对误差正常应该在1e-4量级。2.2 算子兼容性检查的实操方法ONNX导出后不要急着量化先做算子兼容性检查。地平线OE工具链提供了hb_model_checker工具可以扫描ONNX里的所有算子并给出支持情况。实际操作中YOLOv8s的算子兼容性通常没问题但有几个地方需要留意Resize算子YOLOv8s的上采样用的是最近邻插值这个BPU支持。但如果你的模型里用了双线性插值且align_cornersTrue可能需要改成align_cornersFalse。Concat算子C2f模块里有大量ConcatBPU支持但要求所有输入张量的通道对齐。如果通道数不是16的倍数编译时可能报错。Split算子YOLOv8的Detect头里有Split这个算子在某些工具链版本里支持不好可能需要用Slice替代。检查命令hb_model_checker --model yolov8s.onnx --output check_result.json检查结果里会列出每个算子的支持状态。如果有不支持或部分支持的算子需要回到PyTorch层面修改网络结构重新导出。实操心得我遇到过C2f模块里的Split在量化时被错误处理导致某个分支的输出全零。后来把Split改成两个Slice操作就正常了。这种问题在仿真阶段不一定暴露上板才会发现所以算子检查一定要做细。2.3 校准集制作的核心原则PTQ量化的精度高度依赖校准集的质量。校准集不是随便找几百张图就完事有几个原则必须遵守分布匹配原则。校准集的图像分布必须和实际部署场景一致。如果你的模型是跑在车载前视摄像头上的校准集就要用实际路测数据而不是COCO或者ImageNet的图。我见过一个项目用COCO校准结果上板后夜间场景漏检严重就是因为COCO里夜间图太少。数量适中原则。校准集不是越多越好。地平线工具链建议100-500张。我实测下来200张左右是个甜点再多收益递减而且校准过程耗时线性增长。关键是多样性而不是数量。预处理一致原则。校准集的预处理必须和推理时完全一致包括resize方式、归一化参数、通道顺序。如果推理时用的是letterbox resize校准集也必须用letterbox不能用直接resize。校准集目录结构calib_data/ ├── image_0001.jpg ├── image_0002.jpg ├── ... └── image_0200.jpg配合一个calib_list.txt列出所有图片路径。注意图片格式建议用jpgpng也可以但读取会慢一些。2.4 量化配置文件的参数详解地平线的量化配置文件是个yaml里面有几个关键参数直接决定量化精度model: input_type: rgb input_shape: [1, 3, 640, 640] mean: [0, 0, 0] scale: [0.003921568627, 0.003921568627, 0.003921568627] calibration: cali_type: default cali_num: 200 calibration_type: kl quantization: activation_quantization: int8 weight_quantization: int8 bias_quantization: int32mean和scale要和训练时的归一化参数一致。YOLOv8默认是0-1归一化所以scale是1/255mean是0。如果训练时用了ImageNet的mean和std这里要对应改。calibration_type选kl还是max这个有讲究。kl散度校准对激活值分布比较敏感适合分布比较集中的场景max校准简单粗暴适合分布比较分散的场景。我一般先用kl如果精度不好再试max。per_channel量化建议开启对权重的量化精度提升明显而且征程6M的BPU支持per_channel量化不会增加推理耗时。3. 实操过程与核心环节实现3.1 环境搭建与工具链安装地平线OE工具链的安装是个体力活依赖比较多。我习惯用Docker环境避免污染宿主机。官方提供了Docker镜像但版本要选对征程6M需要OE 3.0以上的版本。安装完成后先验证hb_mapper --version hb_model_checker --version hb_compiler --version三个命令都能正常输出版本号才算环境OK。如果报错找不到库大概率是LD_LIBRARY_PATH没设对。注意OE工具链对Python版本有要求建议用Python 3.8或3.103.9有时候会有奇怪的兼容性问题。CUDA版本建议11.8和工具链的GPU算子匹配最好。3.2 模型转换完整流程整个转换流程我整理成一个可复现的脚本# Step 1: 导出ONNX yolo export modelyolov8s.pt formatonnx opset11 simplifyTrue dynamicFalse imgsz640 # Step 2: 算子检查 hb_model_checker --model yolov8s.onnx --output check_result.json # Step 3: 准备校准集 python prepare_calib.py --source ./train_images --output ./calib_data --num 200 # Step 4: 量化编译 hb_mapper makertbin --config yolov8s_config.yaml --model-type onnx # Step 5: 精度仿真 hb_mapper inference --model yolov8s_quantized_model.bin --input ./test_images --output ./sim_resultStep 4的makertbin是整个流程的核心它会依次执行量化、优化、编译三个子步骤。如果中间任何一步失败日志里会有详细报错。我建议把日志级别开到DEBUG方便排查。编译成功后会在model_output目录下生成.hbm文件这个就是最终上板的模型文件。3.3 板端部署与推理验证模型编译好之后通过地平线的部署工具把.hbm文件推到板子上。板端推理的代码框架大致如下from hobot_dnn import pyeasy_dnn as dnn import numpy as np # 加载模型 models dnn.load(./yolov8s.hbm) model models[0] # 获取输入输出信息 input_shape model.inputs[0].properties.shape output_shapes [out.properties.shape for out in model.outputs] # 预处理 def preprocess(img, target_size640): # letterbox resize h, w img.shape[:2] scale min(target_size/h, target_size/w) new_h, new_w int(h*scale), int(w*scale) resized cv2.resize(img, (new_w, new_h)) canvas np.full((target_size, target_size, 3), 114, dtypenp.uint8) canvas[:new_h, :new_w] resized return canvas, scale # 推理 input_tensor preprocess(img)[0].astype(np.uint8) outputs model.forward(input_tensor) # 后处理 def postprocess(outputs, conf_thres0.25, iou_thres0.45): # 解码 NMS ...板端推理有几个性能关键点输入数据格式。征程6M的BPU输入支持NV12和RGB两种格式。如果摄像头输出是NV12直接送NV12可以省一次格式转换但需要模型训练时就用NV12数据。如果模型是RGB训练的就要在CPU上做NV12到RGB的转换这个转换在640×640下大约耗时2-3ms。内存对齐。BPU的输入输出张量要求16字节对齐如果不对齐会触发额外的内存拷贝。在分配输入buffer时要注意。多线程推理。征程6M有多个BPU核心可以通过多线程并行推理提升吞吐。但YOLOv8s单帧推理时间已经比较短多线程的收益主要体现在多路视频场景。3.4 精度对齐与调优实录板端跑通之后最重要的一步是精度对齐。我习惯用以下流程在PC上用ONNX Runtime跑测试集记录mAP作为baseline用仿真工具跑量化后的模型记录mAP板端跑同样的测试集记录mAP对比三个结果定位精度损失发生在哪个环节正常情况下仿真mAP和板端mAP应该几乎一致差异0.1%。如果差异大说明板端推理有问题比如预处理不一致或者后处理参数不同。仿真mAP和ONNX baseline的差异就是量化损失。如果量化损失超过2个点需要调优调优手段一调整校准集。增加校准集数量或者替换更有代表性的图片。我遇到过一次量化后小目标漏检严重后来在校准集里增加了大量小目标场景的图片问题解决。调优手段二混合量化。对精度敏感的层比如Detect头的最后几层保持FP16其他层用INT8。地平线工具链支持通过配置文件指定某些层不量化。调优手段三调整量化参数。把calibration_type从kl改成max或者调整per_channel的设置。调优手段四QAT。如果以上都不行只能上QAT。QAT需要在训练代码里插入伪量化节点重新训练几个epoch。虽然麻烦但精度恢复效果最好。实操心得我做过一个项目PTQ后mAP从42.1掉到38.5试了各种校准集调整都只能恢复到39.8。最后上了QAT训练了10个epochmAP恢复到41.9基本无损。所以如果项目对精度要求高QAT的时间投入是值得的。4. 常见问题与排查技巧实录4.1 编译阶段常见报错与解决编译阶段是报错最集中的地方我整理了一个速查表报错信息原因解决方法Unsupported op: SplitSplit算子不支持用Slice替代SplitShape mismatch in Concat通道数不对齐调整网络使通道数为16的倍数Input shape not aligned输入尺寸不对齐确保H和W是32的倍数Calibration failed校准集路径错误或图片损坏检查calib_list.txt和图片完整性Out of memory模型太大或校准集太多减少校准集数量或降低输入分辨率其中通道对齐问题最隐蔽。YOLOv8s的C2f模块输出通道数通常是64、128、256这种都是16的倍数一般没问题。但如果你改了网络结构比如把某个卷积的输出通道改成48就可能触发对齐问题。4.2 板端推理精度异常的排查思路板端精度异常通常表现为mAP大幅下降或者输出全零。排查思路按以下顺序第一步检查输入数据。把板端预处理后的输入张量dump出来和PC上的预处理结果对比。我遇到过一次板端图片读取时通道顺序搞反了BGR当RGB导致mAP直接掉到个位数。第二步检查输出张量。把板端输出和仿真输出对比看差异在哪个尺度上。如果某个尺度的输出全零说明那个分支的量化出了问题。第三步检查后处理。后处理的解码逻辑要和训练时完全一致。YOLOv8的解码涉及anchor点和stride如果stride搞错了框的位置会整体偏移。第四步检查量化配置。确认板端加载的.hbm文件和仿真用的是同一个。有时候编译了多个版本部署时拿错了文件。4.3 性能优化实战技巧精度对齐之后下一步是性能优化。征程6M上YOLOv8s的推理耗时我实测在15-20ms左右单核BPU优化后可以压到12ms以内。优化手段包括输入分辨率降级。如果场景允许把640×640降到512×512推理耗时可以降低约35%。但需要重新训练模型或者至少重新校准。后处理优化。CPU后处理是耗时大户可以用C重写后处理比Python快3-5倍。或者把NMS放到BPU上但配置复杂。模型剪枝。对YOLOv8s的骨干网络做通道剪枝减少计算量。剪枝后需要微调恢复精度。多核并行。征程6M有多个BPU核心可以把模型的不同层分配到不同核心上并行执行。这个需要工具链支持配置起来比较麻烦。注意性能优化不要过早进行。先把精度调好再优化性能。我见过有人为了追求低延迟把分辨率降到416结果mAP掉了8个点最后还得改回来。4.4 量产部署的注意事项从Demo到量产还有一段路要走几个关键点温度稳定性。征程6M在高温下BPU频率会降推理耗时会增加。量产前要做高低温测试确认在-40°C到85°C范围内性能满足要求。内存占用。除了模型本身还要考虑输入输出buffer、中间张量、后处理的内存占用。征程6M的内存有限如果同时跑多个模型要仔细规划内存分配。模型加密。量产模型需要加密防止被提取。地平线工具链支持模型加密但加密后的模型加载会慢一些。版本管理。模型文件、配置文件、校准集都要做版本管理。我吃过亏量产时发现板端模型和测试时的不是同一个版本排查了半天。长尾场景验证。测试集上的mAP好看不代表实际场景好用。要专门收集长尾场景夜间、逆光、雨雾、遮挡做验证这些场景的精度往往比平均mAP低很多。5. 个人实操体会与后续扩展方向5.1 踩过的坑与经验总结做征程6M加YOLOv8s部署这个事我前后做了三个项目踩过的坑总结下来有这么几条。第一条不要迷信官方Model Zoo。官方提供的YOLOv8s参考实现和你的实际模型可能有差异直接套用配置大概率出问题。一定要从自己的ONNX出发一步步走完整个流程。第二条校准集的质量决定量化上限。我试过用1000张COCO图校准效果还不如200张实际场景图。校准集要“精”不要“多”要“像”不要“全”。第三条仿真和板端不一致时先查预处理。90%的仿真板端不一致问题都出在预处理上包括resize方式、归一化参数、通道顺序。把预处理代码在PC和板端各跑一遍dump出输入张量对比问题一目了然。第四条QAT不是洪水猛兽。很多人怕QAT麻烦宁愿接受精度损失。但实际上QAT的代码改动量不大Ultralytics的框架已经支持加个配置就能跑。如果项目对精度要求高QAT是值得的。第五条性能优化要留余量。量产时的实际耗时往往比实验室高20-30%因为要考虑温度、内存竞争、多任务调度等因素。设计时按实验室耗时的1.5倍来规划算力预算。5.2 后续可以扩展的方向这个部署方案跑通之后还有几个方向可以继续深挖。多模型并行。征程6M的算力可以同时跑YOLOv8s和车道线检测、可行驶区域分割等任务。多模型并行的挑战在于算力分配和内存管理需要仔细规划。BEV感知。YOLOv8s做2D检测只是第一步后续可以扩展到BEV视角的3D检测。征程6M支持BEV相关的算子但模型设计和量化会更复杂。端到端优化。把预处理和后处理也放到BPU上实现全流程硬件加速。地平线工具链支持自定义算子可以把letterbox resize和NMS都做成BPU算子。模型小型化。YOLOv8n比YOLOv8s更轻量如果场景允许可以换成YOLOv8n进一步降低算力占用。但精度会有所下降需要评估是否可接受。量化感知训练深化。目前的QAT只是简单插入伪量化节点后续可以研究更精细的量化策略比如对不同层用不同的量化位宽进一步压缩模型同时保持精度。这个项目做下来最大的感受是部署不是终点而是起点。模型跑通只是第一步真正难的是在量产环境下保持稳定和精度。每一次精度掉点、每一次性能不达标都是对细节的考验。把每个环节做扎实把每个参数搞清楚才能做出真正能用的东西。
