MapTRv2: An End-to-End Framework for Online Vectorized HD Map Construction

2024年09月15日

Task: Online Vectorized HD Map Construction (with Centerline & 3D Map)
Method: Decoupled Self-Attention, One-to-Many Matching, Auxiliary Dense Supervision
Venue: IJCV
Year: 2024
Paper: https://arxiv.org/abs/2308.05736
Code: https://github.com/hustvl/MapTR

1. 摘要

MapTRv2 是 MapTR 的全面增强版本，目标是同时解决 MapTR 的收敛慢、显存高、缺少 centerline / 3D 地图能力三大短板。核心改进有四：(1) 解耦自注意力把全局自注意力的 $O((N \cdot N_v)^2)$ 复杂度降到 $O(N^2 + N_v^2)$，显存减少近 2 GB；(2) 辅助一对多匹配以 GT 重复 $K$ 倍的方式增加正样本，加速收敛 ~4×；(3) 辅助密集监督（深度 + PV 分割 + BEV 分割）共带来 +4.9 mAP 增益；(4) 框架扩展为同时支持 centerline 学习 和 3D 地图构建。MapTRv2-R50 在 nuScenes 24-epoch 即达 61.5 mAP（比 MapTR 同条件 +11.2 mAP），110-epoch 达 68.7 mAP，V2-99 backbone 进一步达 73.4 mAP，均为同期最优；同时 R18 backbone 推理速度可达 33.7 FPS。

核心论点：把”稀疏 query 收敛慢”和”地图元素表达力不足”两个并发难题，用”解耦注意力 + 一对多匹配 + 密集监督 + centerline / 3D 扩展”四把斧一起解决，而不是再发明新表示。

2. 问题与动机

MapTR 已经把矢量化建图带进了实时区间（25.1 FPS / 50.3 mAP @ 24 ep），但仍存在三类瓶颈：

问题 根因 现象
收敛慢 一对一匈牙利匹配 → 正样本极少 24 ep 50.3 → 110 ep 才能到 58.7 mAP
显存高 全局自注意力 $O((N \cdot N_v)^2)$ $N=50, N_v=20$ 时 query 长 1000，显存 10.4 GB
能力缺口 仅支持 ped/divider/boundary 三类 + 2D 缺 centerline → 无法直接给规划用；缺 3D → 上下坡场景失真

MapTRv2 的目标：不改 MapTR 的核心范式（置换等价 + 分层查询 + 分层匹配），只在工程上做四件加法。

3. 核心洞察

洞察 1：解耦自注意力——把 $N \cdot N_v$ 拆成 $N + N_v$

MapTR：所有 $N \cdot N_v$ 个 token 一起做全局 self-attention，复杂度 $O((N \cdot N_v)^2)$；

MapTRv2：把 self-attention 解耦成两步：

  1. 实例间注意力（intra-instance：同实例 $N_v$ 个点之间）；
  2. 点间注意力（inter-instance：同位置 $N$ 个实例之间）。

复杂度从 $O((N \cdot N_v)^2)$ 降到 $O(N^2 + N_v^2)$，在 $N = 50, N_v = 20$ 时显存从 10443 MB → 8458 MB，且 mAP 不降反升 +0.5。

直觉解释：实例间应当区分”哪条线 vs 哪条线”，点间应当区分”线上的哪个点 vs 同位置另一条线的对应点”，二者本来就是不同的关系图，强行混在一起反而稀释了注意力分布。

洞察 2：辅助一对多匹配——用 GT 重复给稀疏 query 喂正样本

DETR 系方法的最大痛点是一对一匹配下正样本极少（$N$ 个 query 通常只有 ~10 个对应到 GT，剩下都是背景）。MapTRv2 引入辅助分支：

  • 在主分支（一对一匹配）之外增加一组辅助实例 query；
  • 训练时把每个 GT 重复 $K$ 倍（默认 $K=6$），让辅助 query 与”$K$ 倍 GT”做匈牙利匹配；
  • 辅助分支与主分支共享同一个 decoder，仅在训练时使用，推理时丢弃。

效果：收敛速度 ~4×，24 ep 达到原来 110 ep 的水平；mAP 单项贡献 +4.4（从 57.1 → 61.5）。

洞察 3：辅助密集监督——给稀疏预测装上 dense 锚点

稀疏 query 收敛慢的另一面是 backbone / BEV 特征学得不充分。MapTRv2 在三个层级加密集监督：

  1. PV 深度预测（LiDAR 渲染 GT，仅训练时 LiDAR）：让 PV 特征显式学到几何；
  2. PV 前景分割：让 PV 特征对地图元素有显式响应；
  3. BEV 前景分割：让 BEV 特征对前景元素有显式响应。

三者互补，共带来 +4.9 mAP（基线 50.1 → 57.1，密集监督单项见 5.2 路线图）。这与 BEVDepth 的”显式深度监督让 LSS 起飞”是同一思路在矢量化建图上的复刻。

三个洞察的递进关系

  1. 形式上瘦身：解耦注意力解决显存与速度；
  2. 标签上加密：一对多匹配加速 query 收敛；
  3. 表征上加密：密集监督让 backbone / BEV 学得更扎实。

要记住的 3 个数字：

  • 61.5 mAP（24 ep, R50）vs MapTR 50.3 mAP：四把斧合计 +11.2 mAP；
  • 73.4 mAP（110 ep, V2-99）：纯视觉矢量化建图的当时新 SOTA；
  • 解耦注意力 -2 GB 显存 / +0.5 mAP：少即是多的工程典范。

4. 方法设计

4.1 整体架构

$$\text{6 cams} \xrightarrow{\text{Backbone}} \text{PV feat} \xrightarrow{\text{BEVPoolv2}} \text{BEV feat} \xrightarrow{\text{Decoupled Decoder}} {(\text{class}, \text{polyline} / \text{centerline} / \text{3D polyline})}$$

MapTRv2 架构图

ASCII 架构图（突出 v2 的四把斧）：

6 cam (1600×900)              [LiDAR @ train only]
      │                              │
      ▼                              ▼
┌──────────────┐             ┌──────────────┐
│  Backbone    │             │ Depth Render │
│  PV feat     │             │ (GT depth)   │
└──┬────────┬──┘             └──────┬───────┘
   │        │                       │
   │        ▼ ━━ Aux PV Seg ◄──── │
   │     ┌──────────────┐       (Dense
   │     │ Aux PV Depth │ ◄─────  Sup.)
   │     └──────────────┘
   ▼
┌──────────────────────────┐
│  PV → BEV (BEVPoolv2)    │
│  + Aux BEV Seg           │
└──────┬───────────────────┘
       │ BEV feat
       ▼
┌──────────────────────────┐
│ Map Decoder × 6          │
│ ┌──────────────────────┐ │
│ │ Decoupled Self-Attn  │ │  (洞察 1)
│ │  intra + inter inst  │ │
│ └──────────────────────┘ │
│ ┌──────────────────────┐ │
│ │ Cross-Attn (Deform)  │ │
│ └──────────────────────┘ │
└──────┬───────────────────┘
       │
       ├──► One-to-One Branch (推理用)
       │       50 instance × 20 pt
       │
       └──► One-to-Many Branch (训练用，洞察 2)
               300 instance × 20 pt
               GT × K=6 重复匹配


输出: (class, 2D / 3D polyline / centerline)

4.2 关键组件对比 MapTR

模块 MapTR MapTRv2
PV2BEV GKT BEVPoolv2（LSS-based，配合深度监督）
Self-Attn 全局 $O((N \cdot N_v)^2)$ 解耦 $O(N^2 + N_v^2)$
Cross-Attn BEV-only Deformable Attn BEV / PV / Hybrid 可选
匹配 一对一匈牙利 一对一 + 辅助一对多 ($K=6$)
密集监督 无 PV depth + PV seg + BEV seg
Centerline 不支持 支持（路径式建模）
3D 地图 不支持 支持（z 坐标回归）

损失函数：

$$\mathcal{L} = \beta_o \mathcal{L}_{\text{one2one}} + \beta_m \mathcal{L}_{\text{one2many}} + \beta_d \mathcal{L}_{\text{dense}}$$

其中

$$\mathcal{L}_{\text{dense}} = \alpha_d \mathcal{L}_{\text{depth}} + \alpha_b \mathcal{L}_{\text{BEVSeg}} + \alpha_p \mathcal{L}_{\text{PVSeg}}$$

主分支 $\mathcal{L}{\text{one2one}}$ 与辅助分支 $\mathcal{L}{\text{one2many}}$ 的内部结构都沿用 MapTR 的 (cls + p2p + dir) 三件套。

4.3 Centerline 与 3D 扩展

  • Centerline 学习：把车道 centerline 当作另一类矢量元素（path），与 divider / boundary / ped_xing 共享同一套分层 query 解码框架，仅类别数从 3 增至 4；
  • 3D 地图构建：每个点 query 多回归一个 $z$ 坐标，配合 BEVPoolv2 已有的深度信息；总参数量增加 < 1%，但能正确表达上下坡。

4.4 关键代码

辅助一对多匹配的核心逻辑（基于官方实现整理）：

# 来源：projects/mmdet3d_plugin/maptr/dense_heads/maptrv2_head.py
# https://github.com/hustvl/MapTR

def forward_train(self, bev_feats, gt_bboxes_list, gt_labels_list, ...):
    # ----- 主分支 (one-to-one) -----
    out_main = self.decoder(bev_feats, query_main)        # 50 inst × 20 pt
    loss_o2o = self.loss_o2o(out_main, gt_bboxes_list, gt_labels_list)

    # ----- 辅助分支 (one-to-many) -----
    if self.aux_one2many:
        # 把 GT 重复 K 倍
        gt_bboxes_o2m = [gt.repeat(self.K, 1, 1)  for gt in gt_bboxes_list]
        gt_labels_o2m = [lb.repeat(self.K)       for lb in gt_labels_list]

        # 辅助 query 数量更多（如 300），共享 decoder
        out_aux = self.decoder(bev_feats, query_aux)      # 300 inst × 20 pt
        loss_o2m = self.loss_o2m(out_aux, gt_bboxes_o2m, gt_labels_o2m)
    else:
        loss_o2m = 0.0

    # ----- 密集监督 -----
    loss_dense = self.depth_head(pv_feats, gt_depth) \
               + self.bev_seg_head(bev_feats, gt_bev_seg) \
               + self.pv_seg_head(pv_feats, gt_pv_seg)

    return self.beta_o * loss_o2o + self.beta_m * loss_o2m + self.beta_d * loss_dense
📄 点击展开：解耦自注意力的伪代码 
# Decoupled Self-Attention：把 (N, Nv, D) 的 query 张量分两次做 self-attn
def decoupled_self_attn(q):
    # q: (B, N, Nv, D)
    B, N, Nv, D = q.shape

    # 1) intra-instance：每个实例内部 Nv 个点之间
    q_intra = q.view(B*N, Nv, D)
    q_intra = self.self_attn_intra(q_intra)               # O(Nv^2)
    q = q_intra.view(B, N, Nv, D)

    # 2) inter-instance：每个位置上 N 个实例之间
    q_inter = q.permute(0, 2, 1, 3).reshape(B*Nv, N, D)
    q_inter = self.self_attn_inter(q_inter)               # O(N^2)
    q = q_inter.view(B, Nv, N, D).permute(0, 2, 1, 3)

    return q                                              # O(N^2 + Nv^2)

5. 实验与分析

5.1 主要结果

nuScenes val（论文 Tab. 2）：

方法 模态 Backbone Epoch AP_ped AP_div AP_bou mAP FPS
MapTR C R50 24 46.3 51.5 53.1 50.3 15.1
MapTRv2 C R18 110 46.9 55.1 54.9 52.3 33.7
MapTRv2 C R50 24 59.8 62.4 62.4 61.5 14.1
MapTRv2 C R50 110 68.1 68.3 69.7 68.7 14.1
MapTRv2 C V2-99 110 71.4 73.7 75.0 73.4 9.9
MapTRv2 C+L R50+Sec 24 65.6 66.5 74.8 69.0 5.8

关键发现：

  1. 24 ep 即超 MapTR 110 ep（61.5 vs 58.7 mAP），收敛 ~4× 快；
  2. R18 backbone 33.7 FPS：进一步把矢量化建图的实时上限拉高；
  3. 纯视觉 R50 24-ep 接近多模态 24-ep 成绩（61.5 vs 69.0），密集监督部分弥补了 LiDAR 缺失；
  4. V2-99 110-ep 73.4 mAP，是当时 nuScenes 矢量化建图榜首。

5.2 消融实验：MapTRv2 渐进式构建路线图

配置 mAP 单项增量 验证洞察
MapTR baseline (R50, 24 ep) 50.3 – –
+ PV2BEV 换 BEVPoolv2 50.1 −0.2 基础替换（无监督时 LSS 与 GKT 相当）
+ 辅助深度监督 55.2 +5.1 洞察 3
+ 辅助 BEV 分割 56.5 +1.3 洞察 3
+ 辅助 PV 分割 57.1 +0.6 洞察 3（密集监督累计 +6.8）
+ 解耦自注意力 57.6 +0.5 / −2 GB 洞察 1
+ 一对多匹配 61.5 +3.9 洞察 2

注：4 项叠加合计 +11.2 mAP，且显存反而降低 ~2 GB。

5.3 自注意力变体对比（洞察 1）

自注意力类型 mAP GPU 显存 FPS
全局（Vanilla） 57.1 10443 MB 14.7
仅实例间 56.8 8178 MB 14.9
解耦（默认） 57.6 8458 MB 14.1

5.4 性能瓶颈分析

MapTRv2-tiny 推理时间（RTX 3090）：

组件 耗时 (ms) 占比
Backbone 42.4 59.8%
PV2BEV (BEVPoolv2) 11.6 16.4%
Map Decoder 16.9 23.8%
总计 70.9 100%

相比 MapTR-tiny 89.3 ms，主要因解耦注意力让 Decoder 从 21.5 → 16.9 ms。

5.5 失效场景分析

  • 远距离地图元素：与 MapTR 相同，BEV 网格分辨率限制；
  • 相机外参偏差敏感性显著优于 MapTR：50.3 → 42.0 mAP（vs MapTR 50.3 → 34.0），密集监督带来鲁棒性；
  • 3D 模式在剧烈坡度场景偶有 z 跳变：未引入时序约束。

6. 工程实践

6.1 训练配置

Backbone:        R18 / R50 / V2-99
Input:           6 cams, 1600×900
Batch size:      24（8× RTX 3090）
Optimizer:       AdamW, lr = 6e-4, weight decay = 0.01, cosine
Schedule:        24 / 110 epochs
PV2BEV:          BEVPoolv2（LSS-based）
Self-Attn:       Decoupled (intra + inter)
Matching:        one-to-one + one-to-many (K=6, T=300)
Dense Sup:       depth + BEV seg + PV seg
Train memory:    ~19426 MB (bs24)

6.2 复现要点

  1. 一对多分支显存代价大：$K=6, T=300$ 时显存从 8.5 GB 涨到 19.4 GB，需 24 GB 卡起步；推理时该分支完全不参与；
  2. 深度监督需 LiDAR GT：仅训练阶段用 LiDAR 渲染深度，部署时 LiDAR 不必上车；
  3. BEVPoolv2 + 深度监督是绑定关系：单独换 BEVPoolv2 不加深度监督会跌 0.2 mAP（见路线图第 2 行）；
  4. 解耦注意力实现细节：intra 和 inter 必须用不同的 self-attn 模块，参数共享会掉 mAP；
  5. 辅助分支与主分支共享 decoder：辅助分支只增加额外 query embedding，不增加 decoder 参数。

6.3 性能优化方向

精度提升

  • 引入时序聚合（多帧 BEV 融合，参考 BEVFormer）；
  • centerline 路径建模可增加图结构约束（与 TopoNet 结合）；
  • 3D 模式可加 z 方向时序平滑。

速度优化

  • R18 backbone 已达 33.7 FPS，进一步可用 EfficientNet / 蒸馏；
  • BEVPoolv2 替换为更轻量的 PV2BEV（如 GKT）会牺牲 ~5 mAP 但提升速度；
  • Decoder 层数 6 → 3，速度可再 +30%，精度下降 ~3 mAP。

7. 研究启示

7.1 可迁移的思想

  • 解耦自注意力：当 query 张量天然有”多维”结构（实例 × 部件 / 帧 × 物体 / batch × token）时，按维度拆 self-attention 是几乎稳赚的工程改造；
  • 一对多匹配（DETR with Hybrid Matching 思想）：任何稀疏 query-based 方法都可以用”GT 复制 + 辅助分支”的方式加速收敛，几乎无副作用；
  • 辅助密集监督：稀疏头 + 密集监督是 DETR / BEV / 矢量化建图等所有”稀疏预测”任务的通用加速手段；
  • 不发明新表示，做工程加法：MapTRv2 没有改 MapTR 的核心范式，仅通过四项增量改进就拿下 +23 mAP，是”先把基线吃透再创新”的工程典范。

7.2 方法局限

  • 单帧推理，时序一致性仍未显式建模；
  • 一对多分支训练显存翻倍，对中小算力训练不友好；
  • 深度监督依赖 LiDAR GT，无 LiDAR 数据集需替换为自监督深度；
  • centerline 模式仍是离散点表示，未利用图结构（拓扑关系交给后续 TopoNet）。

7.3 技术影响

  • 把矢量化建图的精度天花板从 ~50 抬到 73.4 mAP，让端到端规划（VAD / SparseDrive）的输入质量进入实用阶段；
  • 首次将 centerline 学习集成进 DETR-like 矢量化建图框架，为 TopoNet 等拓扑推理提供基础输入；
  • 3D 地图能力打通了上下坡 / 立体路网场景；
  • 解耦注意力 + 一对多匹配的组合被多个后续 BEV / 矢量化工作直接复用（如 MapVR、MapNeXt、StreamMapNet 等）；
  • 在工业界，MapTRv2 的 R18 33.7 FPS + 73.4 mAP 上限组合，使得”上车实时矢量化建图”从可行走向标配。