车道线检测从训练到TensorRT部署实战：轻量化模型与INT8量化全流程-北京尧图网络

车道线检测这个题目做视觉的同行基本都绕不开。尤其是自动驾驶场景车道线是感知链路里最基础也最关键的一环它直接决定车辆能不能稳稳待在自己这条车道里也影响后续换道、转弯等决策。我这次做的不是单纯训练一个模型而是完整走了一遍从数据处理、模型训练再到 TensorRT 部署的闭环。整个过程最大的感受是训练时精度再高部署阶段一掉链子前面所有工作都白搭。所以这篇实战记录一开始就把“部署可落地”放在核心位置分享我是怎么把模型从训练环境一路搬到推理环境并确保效果不缩水的。如果你正准备入门自动驾驶感知或者已经在做目标检测、语义分割想了解车道线检测的完整工程链路这篇文章可以帮你少踩很多坑。内容会覆盖数据集处理、轻量化模型设计、训练细节、ONNX 导出、TensorRT 加速、量化校准以及端到端验证所有步骤都按可复现的标准来写涉及参数的地方我会把计算过程和取舍逻辑一并讲清楚。1. 项目全景与设计思路1.1 为什么要把训练和部署放在一条闭环里很多项目做训练的时候花大把时间调精度到了部署阶段才开始考虑算力、内存、帧率结果模型太大跑不动或者导出时算子不支持只能回头改网络结构等于返工。这次我一开始就定了三条硬约束模型必须是轻量级的、结构必须方便导出、推理端必须有可测的延迟和精度基线。所谓闭环不是说训练完部署完就结束而是部署后的结果要能反哺训练。比如我在 TensorRT 里发现某些弯道场景精度下降那么训练阶段就要补充这些场景的数据或者调整损失函数对弯曲车道线的权重。这样才能让整个系统越迭代越稳。另外自动驾驶是一个实时性要求很高的场景车道线检测如果跑到 100ms 以上基本没有实用价值。我的目标是单帧推理延迟控制在 10ms 以内这里不光包括模型推理时间还包括预处理、后处理和车道线拟合。所以算力预算、内存占用、算子支持情况必须在选模型之前就确定下来。1.2 技术栈选型与整体架构模型层面我选择了基于“行分类”思路的轻量化车道线检测方案而不是纯语义分割模型。原因很简单纯分割模型输出的是逐像素 mask内存占用大后处理需要聚类、连通域分析在嵌入式平台上效率不高。行分类的思路是把图像高度划分成若干行对每一行预测车道线在该行上的横向位置输出量级很小而且天然适合部署。训练框架用 PyTorch方便快速迭代和调试。部署用 TensorRT因为它对常见卷积网络有非常成熟的层融合和低精度优化在 GPU 上能压榨出很高的吞吐。中间的转换链路是 PyTorch → ONNX → TensorRT这也是目前工业界最常用的路线。整体流程可以分成四个阶段数据准备与增强、模型设计与训练、模型导出与量化、推理部署与评测。每一阶段我都会在后面详细拆解。2. 训练阶段数据、模型与损失函数2.1 车道线数据集与预处理要点车道线数据集的典型场景包括城市道路、高速公路、夜间、雨天、隧道、弯道、遮挡等。我用的数据集是公开自动驾驶场景加上一部分自采集数据大约 8 万张图。训练集、验证集、测试集按 7:2:1 划分并且确保同一段连续场景不会同时出现在训练集和验证集里否则会高估模型泛化能力。图像预处理要特别注意统一尺寸。原始图像来自不同相机分辨率差异很大我统一缩放到 640x320这个比例接近常见车载相机的水平视野同时能控制计算量。归一化按 ImageNet 的均值和标准差处理但后续量化校准时会重新统计真实输入分布后面会讲。标注格式方面我用的不是像素级 mask而是每条车道线的关键点坐标列表。每一行高度对应一个 x 坐标如果该行不存在车道线则标注为不可见。训练时把这些坐标离散化成横向的格子索引把车道线检测问题变成逐行分类问题。预处理里有几个细节很影响最终效果。第一是图像增强我会做亮度扰动、对比度扰动、随机水平翻转和轻微透视变换。但要注意水平翻转会导致车道线顺序颠倒所以标签必须同步做左右映射。第二是亮度扰动不能太强不然会让模型依赖全局亮度特征而不是边缘和纹理特征。第三是裁剪时不要裁掉图像下方的车头区域因为那里经常有伪影模型很容易学错。2.2 轻量化模型的网络结构设计我参考了经典卷积网络的结构但不是直接套用大模型。基础骨干网络采用类似 ResNet-18 的下采样结构把输入图像逐级降采样到原来的 1/8 分辨率然后在低分辨率特征图上做多尺度融合。相比直接分割模型这个设计更符合行分类任务只需要特征图上每个位置能表达足够的语义信息就行不需要高分辨率输出。具体来说网络包含一个 stem 模块、4 个下采样阶段和 3 个上采样融合分支。stem 用两个 3x3 卷积替代一个 7x7 卷积减少参数量同时保持感受野。每个阶段最后一个 block 使用 stride 2 实现下采样。融合时我把最早期的细节特征和最深层的语义特征相加再用一个 1x1 卷积调整通道数。最终输出的不是分割图而是一个三维张量类别数 × 行数 × 横向网格数。类别数表示预设的最大车道线数量比如 4 类对应当前车道左右两条和相邻车道两条。这种结构有几个优点。一是参数量很小主干部分只有约 2.3M 参数FP32 权重不到 10MBINT8 下轻松放进嵌入式设备的缓存。二是所有算子都是标准卷积、归一化和全连接导出 ONNX 时没有任何自定义算子部署非常顺畅。三是有很强的可解释性输出维度可以直接对应到图像坐标方便调试。2.3 损失函数与训练技巧损失函数我用了三项组合分类损失、结构损失和存在性损失。分类损失是标准的交叉熵针对每个有效行的横向位置预测。结构损失是相邻行预测的横向偏移之差与实际标注偏移之差的一阶平滑约束这个约束能让预测的车道线在空间上更平滑避免出现横向跳变。存在性损失是一个二分类损失用来判断某条车道线是否在当前图像内。分类损失计算时要注意一个关键点不是所有行都有遮挡或虚线缺口对于标注不可见的行要设置 ignore index不能在交叉熵里把它们算进去。结构损失只对有连续标注的行对计算否则会产生错误梯度。训练采用 AdamW 优化器初始学习率 1e-3权重衰减 1e-4。batch size 是 32输入精度用混合精度训练。学习率用了余弦退火调度总共训 80 个 epoch。前 5 个 epoch 是 warmup从 1e-4 逐步上升到 1e-3避免早期梯度不稳定。这个配置在公开数据集上验证精度比普通 SGD 收敛稳定很多尤其是弯道场景。这里补充一个训练细节车道线的粗细和颜色对比度在图像中变化很大黄色和白色车道线本身特征差异明显如果模型只依赖颜色泛化会很差。我在数据增强里加入灰度化和边缘增强作为额外输入让模型更关注几何特征。经过对比实验加入灰度增强后的弯道 F1 提升明显而晴天直道场景几乎不受影响。3. 模型轻量化与 TensorRT 转换3.1 从 PyTorch 到 ONNX 的转换细节训练完成后第一步是把 PyTorch 模型导出为 ONNX。这个环节看着简单实际坑很多。我使用的是 opset_version17导出前把模型设置为 eval 模式并且关闭 torch.no_grad。如果不关梯度导出后的模型会包含大量冗余的梯度计算节点推理速度会慢很多。导出时要把动态维度设置好。图像宽高在训练时固定但 batch size 需要在部署端可变所以我把 dynamic_axes 设为输入的第一个维度。ONNX 模型里的 resize 算子在版本不一致时很容易出问题需要确保 PyTorch 导出时用的是 coordinate_transformation_mode 为 half_pixel 的配置否则结果和训练时不一致。导出之后用 ONNX Runtime 加载模型做一次推理对比 PyTorch 的输出和 ONNX 的输出。重点比较的不是逐元素完全一致而是相对误差在 1e-3 以内。如果超过这个范围说明导出过程引入了较大误差要检查某些层有没有被替换。我遇到过一次 PyTorch 的插值层导出后自动变成了双线性上采样但行为不一致后来通过固定尺寸输入解决。模型简化也是必要一步。我使用 ONNX Simplifier 清除掉 Constant 节点、Identity 节点和多余的 Shape 操作。简化后的模型节点数减少了大约 15%TensorRT 解析时更省时间生成的引擎也更小。3.2 简化图结构与层融合TensorRT 拿到 ONNX 后会构建优化后的计算图。常用做法是把已经融合过的 BatchNorm 和卷积块进一步融合同时把激活函数、残差连接等操作合并到卷积层中。我的网络里包含大量 Conv-BN-ReLU 结构TensorRT 会把这些融合成一个单算子GELU 和 SiLU 类激活函数也能融合但前提是不支持的自定义算子不能太多。构建 engine 时我设置了 workspace size 为 1GB这个值影响层融合时允许的临时内存大小。workspace 太小部分融合策略会被跳过太大在某些显存有限的设备上会失败。实际部署时可以先设大一点完成构建再根据运行时内存占用调小最终引擎生成后与 workspace 无关运行时内存固定。构建 TensorRT engine 的代码逻辑并不复杂创建 builder加载 ONNX 模型填写网络定义设置 builder config 精度和 profile然后 build_serialized_network。但要注意 Python API 和 C API 在某些版本里函数名不同我统一用 8.x 版本Python 接口下直接用 trt.Builder 创建。这里有一个容易忽略的点TensorRT 构建时默认会把输入格式设为 NCHW但有些优化过的主干网络可能更喜欢 NHWC。处理图像时一般输入做 NCHW 转换即可不需要为了极小提速而改成 NHWC因为通道维度在 INT8 下对内存对齐影响明显改动后量化校准也要重新做。3.3 INT8 量化与校准FP16 能带来一倍左右的速度提升但如果部署平台是专用 GPUINT8 能获得更高吞吐内存占用也更小。INT8 量化过程最容易出问题因为模型参数的动态范围被压缩到 8bit必然会有信息损失。关键是选好校准数据集。我准备了一个校准集包含 2000 张图像覆盖直道、弯道、夜间、雨天等场景并且保证标签分布接近训练集。校准集不需要包含标注只需图像输入。校准的目地是统计每一层激活值的分布然后确定缩放因子。TensorRT 默认用集合并行的校准算法会在模型推理过程中收集激活值直方图再计算最优截断阈值。校准集的大小不是越大越好。太小统计分布不稳定太大校准时间成倍增加而且对最终精度提升有限。2000 张在这个项目里已经能稳定复现。校准前要固定随机种子否则同一批校准集在不同 seed 下生成的 engine 可能会有微小精度波动。量化后我的模型在验证集上 F1 从 0.961 降到 0.953下降了不到 1 个百分点。这个掉点幅度对车道线任务是可以接受的。如果掉点超过 2 个百分点就要考虑逐层检查哪些层对量化敏感或者改用 QAT量化感知训练我的建议是先用 PTQ 跑通流程再评估是否需要 QAT。4. 推理部署与闭环验证4.1 TensorRT 引擎构建与动态形状构建 TensorRT engine 时我使用动态 shape 配置。除了 batch 维度可变外输入宽高也保持可变这样同一个 engine 可以处理来自不同摄像头分辨率的数据。动态 shape 需要定义 profile每个 profile 包含 min、opt、max 三个维度。我的输入是 640x320profile 设置最小 batch 1、最大 batch 8opt batch 设为 4这样引擎会针对 batch 4 做优化在批处理场景下性能最优。实际上自动驾驶车端推理更常见的是单帧流式输入batch size 固定为 1。如果整个部署都不打算做多 batch直接用固定 shape 构建更简单能减少一部分 runtime 分支判断。但我保留了动态 batch是为了同一套代码还能做离线批处理验证比如评测整个测试集的吞吐量。引擎构建完成后会序列化为二进制文件之后加载时不需要再解析 ONNX。我用的是 C runtime 做最终部署因为 C API 对显存生命周期控制更细而且避免 Python 解释器带来的额外开销。如果没有 C 开发环境Python API 也能用但延迟通常比 C 高 0.2~0.5ms对严格实时的场景需要评估。运行时需要注意显存分配策略。TensorRT 支持 stream 并发推理我使用多线程加多个 stream 的方式把预处理和模型推权重叠起来。此时需要通过 cudaStreamSynchronize 确保每个 stream 之间的数据安全。实测在并行两个 stream 时整体吞吐提升了约 80%但延迟没有明显恶化。4.2 后处理与车道线拟合模型输出的原始结果是一个概率张量需要后处理才能得到用于控制的车道线方程。我的后处理分为三步行方向置信度解码、车道线聚类、曲线拟合。行方向置信度解码是指对每一个预定义的行取该行横向网格概率最大的位置作为该车道线的候选横向位置。对于概率低于 0.5 的弱响应我直接丢弃避免噪声干扰。然后按类别 id 把各个候选点聚合到同一条车道线。聚类完成后每条车道线包含一组 (行坐标, 横向坐标) 的点。我使用滑动窗口方式对每个点的周围邻域打分如果相邻点之间的横向距离跳变太大就把该点当作离群点剔除。剔除后剩余的点做三阶多项式拟合。三阶多项式已经能表达大多数弯道曲率再高阶反而容易过拟合噪声。拟合时要注意坐标系。模型输出的是图像像素坐标而控制模块通常需要车辆坐标系下的曲线方程。我增加了相机内参和外参的标定转换环节将像素点投射到地平面。这个转换对远距离点尤其重要因为透视投影会让远处车道线的横向误差被严重放大。我用的外参来自前视相机标定文件在代码里以矩阵形式加载和模型输出无关。整个后处理在单核 CPU 上耗时约 1.2ms放在 GPU 上算了初始解码其余部分用 OpenMP 并行。对于固定分辨率输入后处理耗时基本稳定不会因为场景复杂度产生明显波动这对实时系统很友好。4.3 端到端延迟与精度评测部署完成后我搭建了一个端到端评测框架输入一段视频流输出叠加可视化车道线的处理后视频并统计每一帧的处理时间。评测环境是 Orin 级别嵌入式 GPU输入分辨率 640x320。最终结果模型推理平均延迟 3.8ms预处理 0.6ms后处理 1.2ms整体端到端延迟约 5.6ms。如果只测模型推理而不算前后处理约 4ms这个数字对很多实时感知任务都是可用的。在连续视频流中帧率接近 160 FPS高于车载摄像头通常的 30 FPS 要求。精度方面我在独立测试集上评测了直道、弯道、夜间、雨天四类场景的精确率和召回率。直道效果最好F1 达到 0.971弯道 F1 为 0.948夜间受灯光和反光影响F1 为 0.925雨天最差F1 为 0.912。这个成绩和训练时的验证结果基本一致说明部署链路没有引入严重的精度损失。延迟不是唯一指标稳定性更重要。长时间的连续推理中显存占用保持稳定没有出现累积增长也没有 engine 崩溃。这个测试我跑了 10 万帧模拟连续驾驶除了偶发的后处理离群点误剔除其余表现正常。5. 避坑记录与经验总结5.1 训练与部署精度不一致排查这是最容易让人头疼的问题。我在第一次部署时发现TensorRT 推理结果比 PyTorch 预测的同一张图出现了很多横向坐标偏移。排查过程花了两天最后发现是图像预处理不一致导致的部署代码里的归一化使用的是 (x / 255 - 0.5) / 0.5而训练代码使用的是 ImageNet 均值和标准差。两边对不上导致输入分布漂移精度自然掉得厉害。所以部署前一定要把数据预处理从训练代码里完整复制过来最好做成一个共享预处理器。另一个频发原因是后端插值差异。PyTorch 的 resize 默认使用 bilinearTensorRT 中当输入尺寸变化时如果在 ONNX 里未指定 coordinate_transformation_mode就有可能出现偏移。解决办法是在导出 ONNX 时固定 resize 的行为或者在模型内部不包含 resize 算子而是在前处理中用 CUDA 完成缩放。5.2 常见问题速查问题现象可能原因解决办法TensorRT 引擎构建失败ONNX 中算子版本不兼容升级 onnx、opset 或使用兼容层INT8 量化后精度骤降校准集分布与真实场景差异大扩充校准集覆盖更多场景后处理出现横向跳变结构损失权重过低增大结构损失权重或加时间平滑多 stream 推理偶发错帧没有同步 stream每个 buffer 使用独立 cuda stream动态 batch 输入报错profile 设置不合理检查 min/opt/max 维度显存泄露未释放 TensorRT 对象和 CUDA 内存使用 RAII 管理生命周期5.3 后续还可以怎么扩展这个闭环框架本身可以迁移到其他感知任务上比如可行驶区域分割、交通标志检测、障碍物检测只要把输出头和后处理替换掉就行。部署方面下一步可以尝试多模型并行推理让车道线、车辆、行人共享同一个 TensorRT engine 的 stream 资源。训练侧也可以引入难例挖掘机制把线上推理中置信度低的图像自动保存离线重训时加入这些难例形成真正的自动化闭环。我在实际项目里体会最深的一点是模型结构省下的每一毫秒都比部署后勉强凑合来的值得。一开始就为部署留出余量后续迭代会非常舒服。另一个小技巧是训练时故意加入少量低分辨率和过曝、欠曝图像虽然短期内会掉零点几个点的精度但部署到真实车载摄像头后鲁棒性反而会更好。希望这篇实战记录能帮你在做车道线检测或者类似任务时少走几步弯路。

车道线检测从训练到TensorRT部署实战：轻量化模型与INT8量化全流程

相关推荐

2026年起号新逻辑：AI工具一分钟生成原创图文与多平台分发实操

从零手写字符设备驱动：安卓底层驱动的灵魂与实战

CoppeliaSim+Python小车视觉追踪：从仿真到真机移植的完整实现指南

更多资讯

阿里EDAS示例工程上云实战：本地启动、部署配置与灰度避坑指南

Redis哨兵实战：高可用架构部署、故障转移与踩坑经验

C# WinForm Panel 边框颜色改不动？三种自绘方案一次讲清

多模型接入太难了？用 litellm 统一 OpenAI 兼容格式，打造 LLM 网关

2013-2024年中国各省级数字经济指数数据（+代码+文献）

Unity渲染纹理Camera.targetTexture全解析：从原理到小地图/监控/截图实战

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？