简介面向计算机视觉初学者的YOLO多任务道路识别项目代码包基于YOLOv5、YOLOv8、YOLOv11系列模型解决复杂道路环境下的车辆、斑马线、交通标志、路灯等7类目标的实时检测问题。资源为zip压缩包共46个文件约115KB以txt文本、jpg图像样本、yaml模型配置文件、py训练脚本及png结果展示图为主其中txt与jpg组合构成训练所需的标注数据与图片样本yaml用于配置检测类别py为数据处理与训练入口结构清晰便于对照学习。项目依托CULane道路数据集作者使用labelimg完成自定义标注并提供了数据集处理、YAML编写及模型训练的全流程说明已有105人学习。对想入门目标检测、理解从数据标注到模型部署完整链路的学习者这份代码包可直接作为实践参考省去环境搭建与数据整理的大量摸索时间。1. 夜间车道的多任务感知为什么单检测模型不够单分割模型也不行夜间场景会让检测模型的性能明显滑落正午强光下车道线几乎消失雨雾天气里车道线与积水倒影难以区分——这三类图像我在车载辅助驾驶预研项目里都实测过。单跑目标检测模型看得到障碍物却说不清哪块区域可行驶单跑车道线分割模型又看不清远处的来车。于是我当时同时挂了三个模型跑同一路视频流在边缘推理盒子上帧率从25掉到8这还没算同步与调度带来的额外损耗。多任务道路识别的做法是把目标检测、车道线检测、可行区域分割压进同一个YOLO框架共享Backbone与Neck一次前向推理同时输出检测框、车道线掩码和可行驶区域掩码。下文按我实际落地的顺序展开架构怎么选、数据怎么洗、训练参数怎么设、坑在哪里最后收一条能真实跑出实时帧率的推理链路。2. 多任务架构拆解共享Backbone与三路Head的取舍逻辑2.1 共享主干与Neck多任务省算力的根源不是什么黑盒技巧我最早做多任务改造时最关心的问题是它凭什么比三个独立模型省算力。把三个独立模型的网络结构打印出来做对比结论其实不复杂一个典型的检测模型在640×640输入下CSPDarknet风格的Backbone承担的浮点运算量占整个模型推理的一大半Neck的FPN/PAN结构继续占据第二大部分直接负责输出的Head只占很小的比例。换句话说让三个模型各自跑一遍Backbone相当于有三份重复的浮点运算在做几乎相同的事。多任务共享结构把这一段重复计算合并成了单份这是它省算力的根本来源跟所谓的黑盒技巧无关。我实际对比过三种组织方式。第一种是三个独立模型并行跑单帧总耗时按加法计算显存占用按三倍计算第二种是把三个模型塞进同一个推理进程轮流执行显存有一部分共享但计算总量没有压缩第三种才是多任务共享结构一个Backbone、一个Neck、三个Head。在同一个推理设备上单检测模型耗时约30毫秒单分割模型约25毫秒串行合计约55毫秒多任务共享结构一次前向约35毫秒加上后处理中分割头两次上采样的开销稳定在38毫秒左右。省下来的不是隐藏的魔法是重复计提的卷积开销被合并了。这个对比也让我明确了一个选型边界多任务只有在三个模型串行开销显著时才收益大如果部署平台算力低到连单独一个检测模型都跑不顺多任务多出来的两个Head照样是负担。所以动手做架构改动之前先把三个模型的前向耗时加一遍如果总和本来就低于实时要求那多任务的意义就不大。算清楚前提条件再动模型这是我在这个项目里学到的第一个判断习惯。Neck在多任务里的角色远比很多人以为的更重要。我最初的版本直接拿检测模型自带的PAN结构跑多任务训练车道线的预测在远距离处几乎失效。问题出在把车道线Head直接接在P5这一个尺度上P5的步长是32远处的车道线在特征图上可能只占不到一个像素。在这种特征上做分割再上采样结果就是一片断断续续的斑点。后来我把Neck的输出改成P3、P4、P5三路给每个任务按需取用检测任务在三个尺度上都做目标匹配车道线Head接P3和P4两层浅层特征可行区域Head接P4和P5两层高层语义。改完之后远距离车道线的连续性明显改善。这个结构调整不需要增加多少计算量但对任务效果的影响非常直观属于多任务改造中性价比最高的改动。2.2 三路Head的输出规格与损失函数选型三个Head输出各自的结果规格差异不小。下面这张表是我在项目里反复用来对齐团队认知的规格表按这个参数定义模型和损失基本能避开维度不一致这类低级问题。输出头输出张量形状激活函数损失函数默认权重目标检测头[B, num_anchors, 41C]Sigmoid 线性CIoU 置信度BCE 分类BCE1.0车道线头[B, 1, H/4, W/4]SigmoidBCE Dice0.5可行区域头[B, C_d, H/4, W/4]SigmoidFocal Dice0.5车道线和可行区域的输出分辨率放在H/4而不是原图这是显存和速度权衡的结果。我第一次试过把分割头直接输出到原图尺寸显存占用几乎翻倍训练速度肉眼可见变慢可分割边缘的精度并没有实质提升。原因是分割头在H/4特征图上做双线性插值回原图和从更高分辨率解码再放大相比车道线这类细长结构在视觉上损失并不大但显存代价却是成倍的。现在我的习惯是分割头统一输出H/4后续要全分辨率掩码时用双线性上采样一次省下来的显存可以换更大的批大小反而对分割质量帮助更大。损失函数的选择同样有讲究。车道线分割头最初只用BCE损失训练出来的掩码孔洞很多线条内部经常断开加入Dice损失之后连续区域交叠的梯度信号更强孔洞明显减少。可行区域头最初用普通交叉熵白天与夜间样本占比悬殊时收敛很慢损失曲线来回震荡换成Focal Loss后困难样本占比提高收敛开始平稳。目标检测头保留CIoU、置信度BCE和分类BCE即可多任务改造不需要改动检测头的损失。整体原则是分割头需要能压制背景噪声并强调重叠区域的损失检测头需要的是宽松但位置敏感的回归度量。2.3 检测头与分割头的梯度协作避免任务之间互相抵消这是多任务架构里讨论得最多、也最容易让新手卡壳的问题。我遇到的具体现象是三个头各自算损失训练一段时间后检测Loss和分割Loss都在下降但同一份验证集上检测mAP却低于单任务模型车道线精度也低于单分割模型。问题不在收敛能力而在共享层的梯度被两个任务互相拉扯。我做了两项针对性调整才把这层互相干扰压下来。第一项是给不同Head设置不同的梯度回传尺度。检测头的回归分支输出的梯度幅度通常比分割分支大一个量级如果把两边梯度直接相加分割任务对共享层的影响几乎可以忽略。我在训练脚本里临时打印每个Head对共享层的梯度L2范数观察前十个epoch然后取一个中位数比值把弱的一侧梯度乘以2到4的系数再回传。这么改完之后损失曲线在同一个阶段内变得更平滑最终检测mAP和车道线IoU都高于分头训练说明梯度尺度的对齐确实有效。第二项是给分割Head开一条浅层近道。车道线Head和可行区域Head不是只从Neck最后一层拿特征而是额外从P3和P4这两层较浅的特征上各拉一路拼接。P3保留的相对完整的边缘纹理和空间细节对车道线连续性和可行区域边界都有帮助。这样即使共享层里检测梯度和分割梯度存在抵消分割任务也能靠自己的近道特征完成主要学习不再完全依赖共享层的梯度方向。这两项改动的成本很低但对最终效果的影响显著是我在多任务训练里最看重的两个实用技巧。任务主导权也应该在架构层面提前定好。我选择检测任务为主导因为下游的刹车与避障逻辑最直接依赖目标框的位置和类别。车道线与可行区域是辅助任务它们不参与NMS只在后端充当区域约束。这个选择决定了Neck分叉位置检测Head从P5拿高层特征分割Head在P3和P4上独立解码。如果反过来让分割主导远距离检测框的召回率会下降因为P5的高层语义特征被更多分配给了分割分支。先想清楚主次再动结构后面调参能少走很多弯路。3. 数据准备与格式转换从JSON标注到YOLO多任务样本集3.1 标注组织规范一图四文件的目录结构多任务项目起步时最花时间的往往不是训练而是把散落的标注整理成训练器能直接读的格式。很多团队习惯把目标检测标注放一个文件夹车道线掩码放另一个可行区域掩码又放第三个训练机器上三个路径都要挂载一个挂错就要等几个小时后才发现问题。我的做法是从一开始就固定成“一图四文件”的规范每个样本目录下固定四个文件缺一不可。dataset/ train/ images/ # 每张原图, 如 00001.jpg det_labels/ # 每图一个txt, YOLO格式: class cx cy w h lane_masks/ # 每图一个8位png, 0/1 车道线掩码 drivable_masks/ # 每图一个8位png, 0/1/2 可行区域掩码 val/这个组织方式的好处是训练代码只需要一个根路径参数三个标签路径全部由根路径推导出来不会出现标签路径失联的问题。掩码用png而不是jpg来保存因为png是无损压缩车道线这种单像素级别的线条不会被有损压缩抹掉jpg格式在低码率下会出现块状伪影训练时会被当作伪标签干扰分割头的收敛。3.2 从BDD100K到多任务标签的转换脚本公开数据里BDD100K这一类的道路感知数据拥有检测、车道线、可行区域三类标注是预研阶段做多任务联合训练合适的起点。它的原始标注是一个JSON文件每帧图像对应一组labels包含box2d框、poly2d折线、多边形区域需要转换成前面说的一图四文件格式。下面这段转换脚本我做过很多次注释标出了真正需要注意的位置。import json, os import numpy as np import cv2 def draw_lane(mask, vertices, thickness5): pts np.array(vertices, dtypenp.int32).reshape(-1, 1, 2) # 折线点集可能被拆成多段, 用 polylines 连续画宽线, 避免断头 cv2.polylines(mask, [pts], isClosedFalse, color1, thicknessthickness) return mask def bdd_box_to_yolo(box, img_w, img_h): x1, y1, x2, y2 int(box[x1]), int(box[y1]), int(box[x2]), int(box[y2]) cx, cy (x1 x2) / 2.0, (y1 y2) / 2.0 w, h x2 - x1, y2 - y1 return cx / img_w, cy / img_h, w / img_w, h / img_h def convert_sample(bdd_json_path, sample_id, out_dir, img_dir): with open(bdd_json_path, r, encodingutf-8) as f: bdd json.load(f) sample bdd[sample_id] img cv2.imread(os.path.join(img_dir, sample[name])) H, W img.shape[:2] lane_mask np.zeros((H, W), dtypenp.uint8) drivable_mask np.zeros((H, W), dtypenp.uint8) det_lines [] for label in sample[labels]: cat label[category] if cat in (car, truck, bus, rider, person): cx, cy, w, h bdd_box_to_yolo(label[box2d], W, H) if w 4 / W or h 4 / H: continue # 过滤极小框, 避免噪声正样本 det_lines.append(f0 {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}\n) elif lane in cat and label.get(poly2d): vertices label[poly2d][0][vertices] if vertices: lane_mask draw_lane(lane_mask, vertices) elif cat.startswith(drivable) or cat road: vertices label[poly2d][0][vertices] pts np.array(vertices, dtypenp.int32).reshape(-1, 1, 2) cv2.fillPoly(drivable_mask, [pts], 1) with open(os.path.join(out_dir, det_labels, sample_id .txt), w) as f: f.writelines(det_lines) cv2.imwrite(os.path.join(out_dir, lane_masks, sample_id .png), lane_mask) cv2.imwrite(os.path.join(out_dir, drivable_masks, sample_id .png), drivable_mask)这里几点要重点解释。第一poly2d里的vertices坐标不统一有的是像素坐标有的被归一化到[0,1]区间转换前必须对每个label做判断统一换算成像素坐标否则车道线会集中画到图片左上角一小块区域训练曲线看着正常一推理就露馅。第二车道线用cv2.polylines配thickness5来画能把原始单像素折线变成5像素宽的车道线掩码。宽度太窄会让分割头的正样本像素占比过低训练一开始就偏向全背景宽度太大又会让车道线的边缘定位变差5个像素是一个折中值。第三drivable_mask中我没有处理车辆遮挡区域实际更严谨的做法是先把检测框转成ignore mask把检测框内部的可行驶区域标成2训练时忽略这一部分。原因是检测框内的像素属于被车辆遮挡的区域OnGround真值无法确定。加上这一步以后可行区域分割的边界精度大约能提升两三个点代价是转换脚本多一次轮廓绘制。如果只是先验证多任务训练链路可以后补但正式项目建议一步到位。3.3 掩码坐标系与标签对齐的三个边界坑转换过程中最常出错的不是转换逻辑本身而是边界情况。第一个坑是极小目标框。数据集中存在高度只有几个像素的远距离目标框转成YOLO格式后归一化高度可能小于0.001训练时会被当成极小的正样本对损失产生噪声甚至让模型在远距离上输出一堆不可靠的小框。我的处理办法是过滤长或宽小于4个像素的目标框。第二个坑来自车道线折线的自相交。个别样本中一条车道线标注被拆成多段polyline在连续段之间出现跳跃同一个mask上这一段会从画面左边直接飞到右边。分割头学到的会是一条贯穿全图的斜线而不是真实车道。解决方式是按折线坐标的两两距离判断超过图像宽高一半的跳变就拆成独立线段重新连接这个逻辑可以放在转换脚本里也可以后处理时处理。第三个坑是掩码尺寸同步问题。训练时图像会做缩放和裁剪mask也必须同步缩放。使用同步缩放时要保持相同插值方式不要用双线性插值去缩放二值掩码。双线性插值会在车道线边缘产生介于0和1之间的过渡值训练时被当成软标签让模型预测出模糊边界。这个坑特别隐蔽因为训练损失是下降的但验证时分割IoU始终偏低而且提不上去。统一的处理方案是mask缩放用最近邻插值保持硬标签图像本身用双线性插值保持视觉质量。4. 训练参数与损失权重让三个头一起收敛的启动配置4.1 多任务训练入口与基础配置训练端的第一个决定是选什么框架。常见做法是基于开源YOLO复现工程做多任务改造或者用通用深度学习框架自己搭。我的经验是预研验证阶段用前者能省很多底层的图像增强时间生产级推理集成用后者更可控。下面这段启动命令是通用训练入口的典型写法其中几个参数对多任务场景是经过验证的合理初值。# 多任务道路识别训练入口示例 python train.py \ --data configs/multitask_road.yaml \ --weights pretrained/yolov5m.pt \ --task multitask \ --img-size 640 \ --batch-size 16 \ --epochs 120 \ --loss-weight det1.0 lane0.5 drivable0.5 \ --warmup-epochs 5 \ --lr0 0.005 \ --lrf 0.01 \ --multi-scale逐项说明含义。--task multitask告诉训练器同时优化三个Head否则框架默认只跑检测头。--loss-weight是本文方案里最需要调的参数三类损失的比值在warmup阶段结束后才真正生效。--warmup-epochs 5表示前五个epoch用较低学习率预热让Backbone统计量先稳定避免三个随机初始化的Head在初始权重碰撞下发生崩坏。--multi-scale随机改变输入分辨率对车道线和目标框两种尺度都有帮助代价是训练时间上升属于标准的多任务标配。对应的多任务数据配置YAML可以参考下面这份它把数据路径和任务定义集中到了一起训练器启动时一次性加载。# multitask_road.yaml task: multitask data: train: dataset/train/images val: dataset/val/images classes: det: [0] # 这里简化为单类, 实际按场景把car/truck等映射成多类 lane: enabled: True mask_dir: dataset/train/lane_masks weight: 0.5 drivable: enabled: True mask_dir: dataset/train/drivable_masks weight: 0.5数据读取逻辑里最关键的实现细节是每个iteration需要同时加载det txt、lane mask、drivable mask三份标注。如果训练框架里三个任务用异步线程处理线程间的锁竞争会让数据加载变成性能瓶颈实际吞吐量会掉三分之一左右。我在改造时把三个任务放到同一个数据加载器里同步读取也就是每次iteration一次性读三个文件路径不要用三个独立loader并行读这样内存占用和延迟都可控。4.2 损失权重的平衡原理与实操调整顺序多任务训练最容易出现三种损失互相内耗。假设检测头损失在0.8车道线损失在0.2可行区域损失在0.4直接相加时总损失几乎由检测主导分割任务的学习被淹没。反过来分割权重设太高检测Head梯度又会被冲淡。解决这个问题的常见做法不是一次性给出一组固定权重而是先跑20个epoch观察三个损失数值本身的数量级然后把它们调成接近同一个尺度。我的实操顺序是这样的固定det权重为1.0跑十个epoch观察lane和drivable的Loss绝对值如果lane Loss在0.1到0.3drivable Loss在0.3到0.7那么初始权重都可以设到0.5。然后看总损失曲线是否平稳。如果检测Loss在epoch5左右出现一个明显回升点多半是分割任务梯度太强要降低分割权重比如从0.5降到0.3。如果检测Loss持续下降但验证集车道线掩码碎裂那是分割权重太低回传梯度不足以驱动分割头把lane权重大幅提升到0.8甚至0.9。另一个常用策略是分阶段训练。第一阶段只训检测Head冻结lane和drivable的参数让Backbone先学好通用特征第二阶段放开所有Head联合训练。我在某次对比实验里验证过分阶段收敛速度快约两成最终精度基本持平。但分阶段有个坑如果你忘记取消冻结或者不小心用了同一份包含已训练Head的权重作为从头训练的起点两个分割Head就带着不同的预训练分布参与联合训练可能会出现收敛后车道线边界偏一侧的怪问题。更稳的做法是共享Backbone加载预训练权重三个Head全部随机初始化只让共享部分继承通用视觉特征这样回避了不同Head预训练分布不一致带来的偏移风险。4.3 优化器、学习率与批大小的配合多任务训练对批大小的敏感度比单任务高很多。我试过batch_size8和batch_size32两种设置相同epoch数下分割头IoU相差约6个点原因是分割任务每个样本的正负像素比例差异很大小批次下梯度方差大分割头难以稳定收敛。显存允许时尽量往上加至少16起步如果显存只够8配合梯度累积模拟更大批次会好很多不要硬上。优化器我固定用带动量的SGD不用自适应学习率的优化器。原因是在多任务结构里自适应优化器会分别调整每个参数的步长等于隐式地修改手工设置的损失权重辛苦调好的权重比会被抵消。SGD配合lr0、lrf和warmup的使用各任务的权重语义更直接出问题时也好排查。学习率方面单任务YOLO常用0.01起步但多任务模型包含更多随机初始化的Head初始学习率建议减半到0.005否则前几个epoch的Loss曲线会拉出一个很大的尖峰即使被warmup压回去也在浪费训练时间。EMA指数移动平均对多任务同样是推荐的配置项。由于多任务模型的参数平面比单任务更复杂找到的极值点周围普遍更陡峭EMA平均后的权重往往落在更平滑的位置推理时的稳定性会更好。不过EMA对三个Head会产生不同影响检测框的抖动被压低分割mask的边缘也更规则这是我在对比推理结果时看到的实际效果。训练脚本里开EMA即可一般衰减系数用0.99到0.999。4.4 验证指标不能只看mAP三头分别报告指标用单个mAP来判断多任务模型是否合格是个误区因为mAP只反映检测头的质量车道线和可行区域的好坏它一点体现不出来。我在每次评估时同时看三个指标检测任务看mAP50与mAP50-95车道线任务看IoU与最大车道线宽度下的召回率可行区域任务看IoU与边界F1。后面两个要单独写评估函数在验证集上逐类计算便于观察每个任务的独立变化趋势。实际组合是打印一张评估表每一行是一个任务某个epoch结束时把三个指标并列输出。如果检测mAP在上涨但车道线IoU在下降说明权重配比里车道线权重偏低如果可行区域IoU上涨但检测mAP停滞那可能是分割头把共享特征的梯度带偏了。这三个指标的相对变化比绝对值更值得关注因为它们能告诉我问题发生在权重层、梯度层还是数据层。单独追求任何一个指标的提升都可能让多任务失去其意义这也是多任务项目里“整体感知”思路在评估层面的体现。5. 多任务训练避坑指南四个每次重训都会踩的问题5.1 现象检测头正常收敛车道线IoU却长期停滞训练日志里检测Loss下降得很漂亮验证集mAP也在涨只有车道线IoU贴着地面不动。我最初以为模型结构有问题反复调整Neck分叉、尝试加深分割头都没用。后来把每个任务的Loss单独打到终端上才发现车道线Loss数值非常小在0.1附近浮动回传到共享层的梯度L2范数只有检测头的十分之一不到。原因就是第2章里说的损失权重失衡分割任务的梯度在共享层被检测任务淹没了。解决方法是把lane权重从0.5提到0.9并给分割头的共享层梯度增加2倍缩放。只改这两项两个epoch后车道线IoU就明显上升。经验是遇到单任务指标滞涨先看Loss绝对量级再谈权重和结构不要一上来就动网络。5.2 现象训练中途Loss尖峰后恢复验证集精度永久下降训练到大约第80个epoch时突然出现一次Loss尖峰然后曲线慢慢恢复看起来一切正常但验证精度比之前低了一个多点继续加epoch也回不去。我最初怀疑是学习率设置问题把--lr0调低重跑尖峰消失了最终精度仍然偏低。逐帧排查后才发现是某个极端样本的像素值范围异常把BN统计量带偏了。解决方式是在数据加载的预处理阶段做异常值清洗过滤掉对比度极端、整体偏色严重的样本。如果你用的是现成训练器可以另写一个小脚本统计每个batch的输入像素均值和方差超过阈值就告警这样能更早发现数据污染问题。5.3 现象服务器端推理正常导到端侧后车道线出现规律横纹训练和服务器端验证都正常模型导出到端侧推理时才出现规律性横条纹。这类问题通常在导出阶段部分推理库对双线性上采样支持不够彻底把双线性上采样错误地退化成最近邻实现导致分割mask出现可见的块状纹理。解决方法是导出时检查计算图里的Upsample节点确认端侧算子库对该节点的实现和训练时一致或者直接在训练时把分割头输出分辨率设为原图的一半端侧只需要一次双线性放大减少对高倍数上采样的依赖。如果你在端侧工具链上看到分割mask出现规则的网格线优先怀疑这里而不是模型权重。5.4 现象夜间与雨雾样本的精度明显低于白天训练数据里白天样本多、夜间样本少Loss曲线整体下降趋势正常但夜间验证集的三个指标都比白天低不少。这不是多任务的老问题但多任务场景下处理起来要更小心因为三个任务在夜间同时变差你很难分辨是检测的问题还是分割的问题。我的处理方式是把夜间样本和雨雾样本按比例过采样同时在训练时做亮度扰动和雨线噪声增强。建议直接离线做增强把增强后的样本写入训练集而不是每次训练时实时生成否则每个batch的加载时间都会明显上升。5.5 现象三个头的损失都在下降但验证集上目标框位置系统性偏移一个比较隐蔽的问题三个任务各自收敛良好验证集上检测框却出现系统性偏移比如所有框整体偏左上角几个像素。排查发现是数据转换时检测标签的坐标归一化方向与模型Resize的坐标对齐不一致原图1280×720缩放到640×640时letterbox补边方式不同导致标签坐标整体偏移。解决方式是在数据加载器里统一先做相同fig的letterbox参数再换算标签坐标。具体做法是记录每个样本的缩放比例和补边偏移量在读取det标签时直接做逆变换或把标签预先生成到模型输入坐标系中。这类问题最容易在混用不同来源的YOLO格式数据时出现值得在数据检查阶段多留一个心眼。6. TensorRT导出与端侧后处理把多任务模型压到实时帧率6.1 导出流程PyTorch权重到TensorRT的完整链路多任务模型训练完成后真正的落地关卡才刚刚开始。我在端侧设备上拿到PyTorch权重直接跑推理发现速度比训练时还慢原因是端侧推理库对动态shape和部分算子的支持不直接需要先把模型导出成ONNX再交给TensorRT做图优化和半精度量化。下面是我常用的导出命令链。# 第一步: 导出ONNX, 固定batch与输入尺寸 python export.py --weights runs/multitask/best.pt \ --include onnx --img-size 640 --batch 1 # 第二步: 用trtexec生成FP16的TensorRT引擎 trtexec --onnxmodel.onnx --saveEnginemodel_fp16.engine \ --fp16 --minShapesinput:1x3x640x640 \ --optShapesinput:1x3x640x640 \ --maxShapesinput:1x3x640x640导出时最容易踩的两个坑。第一是ONNX里分割头的上采样动态尺寸问题TensorRT要求输入shape固定转ONNX时务必把--img-size固定成训练时尺寸否则后续动态shape会触发重新profile延迟显著上升。第二是FP16量化会让分割mask边缘噪声变大这在模型精度可接受范围内通常不用管但如果车道线细线和背景对比度太弱FP16数值截断会导致细小线段断裂此时可以退回FP32或者只对检测分支做FP16、分割分支保持FP32虽然工程上麻烦一点但能换来更好的视觉连贯性。6.2 后处理技巧把掩码变成下游可直接消费的结构化输出多任务输出的是原始张量下游决策模块一般不愿意直接读像素掩码它要么要的是车道线控制点要么要的是可行驶区域的外包络多边形。我在后处理里通常做三件事检测头直接输出框坐标和类别车道线mask经过连通域提取后按纵向降采样生成关键点再拟合成三次样条曲线因为三次样条能表达弯道和起伏比直线拟合更贴合可行驶区域mask按置信度阈值转二值再用轮廓提取导出凹包边界。这样的输出几乎不需要下游再做二次解析调试起来也更直观。这里有一个稳定的习惯分离任务处理时不要让三个任务串行等待同一把线程锁。检测框的NMS和分割mask的连通域提取分别放两个线程用队列做缓冲这样即便一次分割mask处理慢了几毫秒检测框的延迟也不会被拖累。我在某边缘盒子上通过这个改动把端到端延迟从50毫秒压到了42毫秒。整个过程里踩坑最深的还是坐标对齐和上采样一致性它们不体现在训练指标里但每次都直接影响真实场景的表现。现在每改一版数据或模型我都会先跑一遍夜间样本做视觉检查再上指标验证这个习惯帮我拦住了多次即将上线的缺陷。希望这篇笔记对你有用。本文还有配套的精品资源点击获取