征程6上GANet车道线检测的量化部署：从F1 43.2%到68%的精度跃升实录

最近在一个L2+级智驾项目里负责车道线检测模块的部署，模型选型的时候对比了好几个方案，最后选了GANet。社区里发布的参考算法数据显示GANet在J6M上的延迟只有1.09ms，F1 Score量化后能做到68%，比浮点版本的43.2%还高出一截。实际部署下来发现车道线检测的量化有一些特殊的坑，主要是细长目标对分辨率敏感、以及弯道场景下的拟合精度问题。这篇把GANet在征程6上的完整部署流程和踩坑经验记下来。

一、为什么选GANet而不是其他方案

车道线检测的方案很多：

· 传统方法：Hough变换、IPM+边缘检测，简单但鲁棒性差

· 语义分割：把车道线当成一类做分割，但后处理复杂

· 关键点检测：预测车道线上的点，再拟合曲线

· 基于锚点的检测：类似目标检测，用anchor匹配车道线

GANet属于关键点+拟合的方案，结合了检测和分割的优点。社区里HEAL v3.0发布的参考数据表明：

模型 延迟 F1 Score 特点

GANet 1.09ms 68.0% 关键点+拟合，速度快

BezierLaneNet ~2ms 65.3% Bezier曲线拟合

LaneATT ~3ms 62.1% 基于attention

GANet的延迟最低，而且F1 Score最高，对于需要同时跑检测+车道线+分割的多任务系统来说，1.09ms的延迟基本不占资源。

注意：

GANet的输入尺寸是320x800，不是常见的640x640。这是因为车道线在图像里通常是横向分布的，高度方向的信息密度不高，压缩到320行可以减少计算量，而宽度方向保持800列以覆盖足够的横向视野。

二、模型结构与输出解析

GANet的输出比较特殊，不是传统的分割mask或者检测框，而是：

1. 关键点heatmap：每个车道线上的点用一个高斯核表示

2. 偏移量（offset）：关键点的亚像素级精确位置

3. 车道线实例特征：用于区分不同的车道线实例

4. 存在性分数：每条车道线是否存在的置信度

后处理需要把heatmap上的点聚类成车道线实例，然后用最小二乘法拟合曲线。

```python

# GANet输出解析（简化版）

def parse_ganet_output(heatmap, offset, instance_feature, existence):

# 1. 从heatmap提取峰值点

peaks = extract_peaks(heatmap, threshold=0.3)

# 2. 用offset修正到亚像素位置

for peak in peaks:

peak.x += offset[peak.y, peak.x, 0]

peak.y += offset[peak.y, peak.x, 1]

# 3. 用instance feature聚类

lanes = cluster_by_instance_feature(peaks, instance_feature)

# 4. 拟合曲线（三次多项式）

for lane in lanes:

if len(lane.points) >= 4:

lane.curve = np.polyfit(

[p.y for p in lane.points],

[p.x for p in lane.points],

3 # 三次多项式

)

# 5. 过滤低置信度

lanes = [l for l in lanes if l.confidence > 0.5]

return lanes

```

三、量化部署的特殊考虑

1. 输入尺寸不是2的幂

GANet的输入是320x800，320不是2的幂。BPU对输入尺寸的要求是高度和宽度必须是2的倍数，320和800都满足，没问题。但如果你的预处理resize把尺寸改成了奇数（比如319x799），BPU会自动padding到320x800，边缘多出来的一行/列是padding出来的，对结果没有贡献，但会浪费一点计算量。

建议：

预处理resize的时候确保输出尺寸是偶数。用OpenCV的resize时，目标尺寸设为(800, 320)或(320, 800)都可以，但要和模型训练时的尺寸完全一致。

2. 细长目标的分辨率敏感

车道线在图像里通常只有几个像素宽（比如5-10像素），量化后对关键点的定位精度影响很大。

我做过一个实验：把GANet的输入从320x800降到160x400，F1 Score从68.0%掉到了51.2%。原因是车道线宽度在160x400分辨率下只有2-5像素，量化后heatmap上的高斯核被压缩，峰值定位误差变大。

结论：

车道线检测模型对输入分辨率很敏感，不建议为了省计算量而降分辨率。320x800是GANet的sweet spot，再降精度损失很大。

3. 后处理的CPU开销

GANet的后处理（峰值提取+聚类+曲线拟合）在CPU上跑，我的实测数据：

输入尺寸 BPU延迟 CPU后处理 端到端延迟

320x800 1.09ms 3.2ms 4.29ms

640x1600 3.8ms 8.5ms 12.3ms

后处理占了端到端延迟的75%。优化方向：

1. 峰值提取用GPU加速：如果板端有GPU资源，可以用CUDA加速峰值提取

2. 降采样后处理：在heatmap的1/2或1/4分辨率上做峰值提取，再映射回原分辨率

3. 简化拟合：用二次多项式代替三次多项式，拟合速度提升30%但精度掉2%

我项目里用的是方案2：在1/2分辨率（160x400）的heatmap上做峰值提取，端到端延迟从4.29ms降到2.8ms，F1 Score只掉了0.8%。

四、弯道场景的特殊处理

直线车道的检测相对简单，但弯道场景下车道线有曲率，拟合难度大增。

问题：

三次多项式拟合在弯道处容易出现"抖动"（拟合曲线在弯道内侧波动），原因是关键点在弯道处的分布不均匀，内侧点密集、外侧点稀疏。

解决： 用RANSAC（随机采样一致性）做鲁棒拟合，剔除离群点：

```cpp

std::vector RansacFit(const std::vector& points,

int iterations = 100,

float threshold = 5.0f) {

std::vector best_inliers;

for (int i = 0; i < iterations; i++) {

// 随机采样4个点

auto sample = RandomSample(points, 4);

// 用这4个点拟合曲线

auto curve = PolyFit(sample, 3);

// 计算所有点到曲线的距离

std::vector inliers;

for (const auto& p : points) {

float distance = PointToCurveDistance(p, curve);

if (distance < threshold) {

inliers.push_back(p);

}

}

// 保留inlier最多的模型

if (inliers.size() > best_inliers.size()) {

best_inliers = inliers;

}

}

// 用所有inliers重新拟合

return PolyFit(best_inliers, 3);

}

```

RANSAC迭代次数设成100，阈值5个像素，可以把弯道处的抖动减少60%。

五、多车道线实例的区分

GANet的instance feature用于区分不同的车道线，但量化后instance feature的精度下降，可能导致两条相近的车道线被聚类成一条。

我踩的坑： 在一个四车道的场景下，中间两条车道线的instance feature在量化后cosine similarity达到了0.85，聚类算法误把它们当成一条车道线。

解决：

在聚类之前加一层空间约束：如果两条候选车道线的横向距离小于车道宽度的0.5倍，强制分成两条。

```cpp

void SplitNearbyLanes(std::vector& lanes) {

std::vector split_lanes;

for (auto& lane : lanes) {

bool merged = false;

for (auto& existing : split_lanes) {

float avg_distance = AverageLateralDistance(lane, existing);

if (avg_distance < LANE_WIDTH * 0.5f) {

// 两条车道线太近了，可能是同一条的重复检测

// 合并到置信度更高的一条

if (lane.confidence > existing.confidence) {

existing = lane;

}

merged = true;

break;

}

}

if (!merged) {

split_lanes.push_back(lane);

}

}

lanes = split_lanes;

}

```

六、CULane数据集 vs 真实场景

GANet在CULane数据集上训练，但真实场景和CULane的分布有差异：

场景 CULane 真实场景

车道线颜色 主要是白色 白色/黄色/蓝色

路面材质 主要是沥青 沥青/水泥/砖块

光照条件 白天为主 白天/夜间/隧道

遮挡情况 较少 车辆遮挡、施工围挡常见

迁移学习策略：

1. 用CULane预训练权重初始化

2. 在真实场景数据上fine-tune 50个epoch

3. fine-tune时冻结backbone，只训练head部分（防止过拟合）

```python

# 冻结backbone

for param in model.backbone.parameters():

param.requires_grad = False

# 只训练head

optimizer = torch.optim.Adam(model.head.parameters(), lr=1e-4)

```

fine-tune后，真实场景下的F1 Score从52.3%提升到了67.1%，接近CULane上的水平。

七、性能数据汇总

GANet在J6M上的完整性能：

指标 数值

BPU推理延迟 1.09ms

FPS（双核） 90.96

端到端延迟（含后处理） 4.29ms

F1 Score（CULane） 68.0%

F1 Score（真实场景，fine-tune后） 67.1%

模型大小（hbm） 4.2MB

内存峰值 32MB

注意：

90.96fps是双核的理论值，实际产品里不会只跑车道线一个任务。在我们的多任务系统里，车道线和检测模型并行跑，车道线模块的帧率受限于检测模型的帧率（30fps），但车道线本身只占4.29ms的延迟，不会成为瓶颈。

八、注意事项总结

1. 输入尺寸必须是320x800：不要擅自改尺寸，车道线对分辨率敏感。

2. 后处理占大头：BPU只占25%的端到端时间，CPU后处理优化是关键。

3. 弯道用RANSAC拟合：三次多项式在弯道处容易抖动，RANSAC可以剔除离群点。

4. instance feature量化后精度下降：加空间约束防止相近车道线被聚类成一条。

5. 真实场景要fine-tune：CULane和真实场景分布有差异，冻结backbone fine-tune head。

6. 车道线颜色要覆盖全：训练数据里要有白色、黄色、蓝色车道线。

7. 夜间场景单独优化：夜间车道线对比度低，ISP的gamma和对比度要调高。

8. 遮挡场景加跟踪：车辆遮挡时用车道线跟踪算法（Kalman filter）补全。

9. 多任务系统里车道线不占瓶颈：1.09ms的延迟在多任务里几乎可以忽略。

10. 降采样后处理省延迟：1/2分辨率做峰值提取，端到端延迟降35%，精度只掉0.8%。