(论文速读)GitMerge3D:3D 点云 Transformer 真的需要这么多 Token 吗?

发布时间:2026/10/27 10:18:42
(论文速读)GitMerge3D:3D 点云 Transformer 真的需要这么多 Token 吗? 论文题目How Many Tokens Do 3D Point Cloud Transformer Architectures Really Need?方法名称GitMerge3D会议NeurIPS 2025研究方向3D 点云理解、Token 合并、Transformer 高效推理摘要3D 点云 Transformer 在语义分割、重建和目标检测等任务上表现出色但密集 Token 表示带来了较高的计算和显存开销。本文发现现有模型中的 Token 存在大量冗余在合理的合并策略下即使大幅减少 Token也能保留接近原模型的性能。为此作者提出 GitMerge3D利用全局信息评估 Token 的重要性并结合空间分布进行自适应合并。论文在 3D 语义分割、重建和语言引导目标检测上验证了方法展示了显著的效率收益。一、研究动机点云 Transformer 是否“用点过量”近年来Point Transformer 系列不断提升 3D 点云理解能力。以 Point Transformer V3PTv3为例它通过空间序列化、局部注意力和层次化编码器—解码器结构改善了大规模点云处理的可扩展性。然而模型在注意力层仍需处理大量 Token训练和推理会消耗大量显存与计算资源。作者提出了一个直接的问题如果模型中的许多 Token 对最终预测贡献有限是否可以在注意力计算前合并它们而不是让所有 Token 都参与计算论文先将多种已有 Token 剪枝、合并方法迁移到 PTv3 及其变体中。实验显示即使减少相当比例的 Token语义分割性能也常常只出现较小变化。这说明点云 Transformer 可能存在明显的过度 Token 化over-tokenization。论文 Figure 1PTv3 和 Sonata 使用 GitMerge3D 前后的 mIoU、GFLOPs 与显存对比。图中 PTv3 的 GFLOPs 从 107.5 降至 19.9显存从 10.12 GB 降至 1.6 GB分别约为 5.3 倍和 6.4 倍的效率提升Sonata 也取得明显的资源节省。作者据此提出 GitMerge3D不是简单随机删点而是判断哪些特征更冗余再利用空间感知的 Token 合并来保留对任务重要的信息。二、背景Token 合并为何不能只看特征相似度PTv3 将点云通过空间序列化转为一维序列并在局部分区内执行自注意力。注意力的计算形式可以写为其中(P(i)) 表示包含点 () 的局部分区(q,k,v) 分别是 Query、Key 和 Value 特征。Token 合并的基本思路是在注意力计算前将多个相近 Token 合并成较少的表示降低注意力层的开销。可问题在于点云不仅有特征相似性还有三维空间分布和局部密度差异。若一味合并相似点可能让某些区域的代表点过于集中导致几何结构和细节丢失而通用视觉 Token 合并方法也未必能直接适配点云的密集预测任务。此外语义分割需要为原始点云中的每个点输出标签。合并后不能只保留压缩序列还必须把特征恢复到原有分辨率才能与后续 MLP 和逐点预测流程兼容。三、GitMerge3D 的核心方法GitMerge3D 的设计围绕三个环节展开用全局信息计算 Token 的能量分数估计其相对重要性根据分区级分数自适应决定采用中等合并还是更激进的合并将分区划分为空间均匀的 bins避免合并后的代表 Token 过度集中并在注意力后恢复原始 Token 结构。论文 Figure 3方法总览。作者先计算全局能量分数再将其汇总到 patch 级别用于选择不同合并强度每个 patch 内再按空间 bins 选择 destination Token完成空间感知合并。3.1 全局信息引导的能量分数作者将点 Token () 与各局部分区的中心 () 建立二部图连接。分区中心可以写为每个 Token 与所有分区中心相连并通过它与这些中心的平均余弦相似度定义能量这里的负号意味着Token 越接近整体特征结构能量越低越不符合全局结构能量越高。作者将低能量 Token 视为相对冗余、可更激进合并的对象高能量 Token 则可能携带更独特的信息应受到更多保护。为什么要使用“全局”能量论文指出在 PTv3 的高分辨率层中单个局部 patch 的感受野有限。只在局部计算相似度可能无法判断某个点在整个场景特征空间中的位置。全局分区中心为每个 Token 提供更广泛的参照从而更适合识别可合并区域。接着作者对一个分区内所有 Token 的能量取平均得到分区能量3.2 自适应合并不同区域采用不同强度设阈值为 ()基础合并比例为 (r)。GitMerge3D 根据分区能量决定合并强度直观来说高能量分区更可能包含有区分度的信息因此只进行相对温和的合并低能量分区与全局结构更一致则可以进一步压缩。论文的实验示例中高能量分支使用约 80% 的合并率而低能量分支可采用约 97% 的激进合并配置(K32)。这体现了 GitMerge3D 的关键不要求每个区域承受同样的压缩强度而是依据特征信息动态分配合并率。3.3 空间感知合并用 bins 保留代表点分布仅仅知道哪些 Token 可以合并还不够。若 destination Token 在空间中分布不均许多 source Token 可能被压到少数代表点上损失局部几何信息。因此GitMerge3D 将每个 patch 划分为 (K) 个空间 bins在每个 bin 内选择 destination Token再将对应 source Token 合并到它上面。这样能让合并后的代表 Token 在空间中保持更均匀的覆盖。论文还给出动态设置 bins 数量的方式其中 (T) 是每个 patch 的 Token 数(r) 是合并比例。合并越激进剩余 Token 越少bins 数量也随之调整。消融结果显示在较高合并率下保留更多 bins 通常更有利于维持空间信息。3.4 Unmerge为逐点预测恢复分辨率GitMerge3D 主要在注意力层前合并 Token注意力计算完成后再通过 unmerge 操作恢复到原始 Token 结构然后继续后续 MLP 与逐点预测。这一点对语义分割等 dense prediction 任务尤为重要它减少了注意力运算中的 Token 数量却不改变下游逐点输出所需的结构。四、实验设置不只测分割也测重建和检测论文覆盖三类 3D 任务语义分割PTv3 与 Sonata在 ScanNet、ScanNet200、S3DIS 和 nuScenes 上评估。3D 重建使用以 PTv3 为核心组件的 SplatFormer在 GSO、Objaverse 和 RealWorld 等数据上测试新视角合成。语言引导目标检测在 SpatialLM 上评估场景布局和物体检测。作者还将 GitMerge3D 与 ToMe、PiToMe、ALGM 等 Token 合并方法以及 Random Drop、FPS、VoxelGrid 等点云下采样方法比较。语义分割主要报告 mIoU、mAcc、allAcc、GFLOPs、显存与延迟重建使用 PSNR、SSIM 和 LPIPS目标检测则报告不同 IoU 阈值下布局与物体的 F1 分数以及推理时间和显存。五、主要实验结果5.1 语义分割大幅压缩仍可保留竞争力论文 Table 1PTv3 和 Sonata 在 ScanNet、ScanNet200 与 S3DIS 上的比较包含直接应用off-the-shelf和少量微调两种设置。下表整理 PTv3 在合并率 0.8 设置下的主要结果方法ScanNet mIoU ↑ScanNet200 mIoU ↑S3DIS mIoU ↑PTv3 基线77.635.274.7Random Drop70.131.173.4FPS71.232.470.9VoxelGrid Downsampling72.132.269.1GitMerge3D直接应用77.034.472.3GitMerge3D微调77.435.274.3从表中可以看到直接使用 GitMerge3D 时PTv3 在 ScanNet 上的 mIoU 为 77.0相比 77.6 的基线仅小幅下降而随机丢弃、FPS 和 VoxelGrid 下采样的表现下降更明显。经过微调后ScanNet200 的 mIoU 回到 35.2S3DIS 达到 74.3接近原模型的 74.7。Sonata 上也有类似趋势基线在 ScanNet、ScanNet200 和 S3DIS 上分别为 79.0、30.4 和 72.2GitMerge3D 微调后的结果分别为 78.9、30.9 和 73.5。也就是说少量微调能在压缩后恢复相当一部分性能部分数据集甚至超过基线。论文指出微调只使用原训练周期约 10% 的训练量。其价值不只是降低推理成本也在于让已有预训练模型能以较低的额外训练开销适配 Token 合并。5.2 计算与显存收益不仅体现在 Token 数量上论文 Figure 1PTv3 与 Sonata 在合并前后的 GFLOPs 和显存变化。模型原始 GFLOPsGitMerge3D GFLOPs原始显存GitMerge3D 显存PTv3107.519.910.12 GB1.6 GBSonata20650.2110.2 GB1.92 GB按论文图中的统计PTv3 的计算量约降低 5.3 倍显存约降低 6.4 倍Sonata 的计算量约降低 4.1 倍显存约降低 5.3 倍。需要注意这组数值来自论文 Figure 1 的设置不同数据集和评估流程下的绝对资源数值会不同。在 nuScenes 语义分割上Table 3 给出另一组效率对比方法mIoU ↑mAcc ↑allAcc ↑显存GFLOPs延迟PTv380.387.294.66.20 GB101.68152 msPTv3 GitMerge3D78.085.594.00.92 GB32.45106 ms在这组实验中显存从 6.20 GB 降至 0.92 GBGFLOPs 从 101.68 降至 32.45延迟从 152 ms 降至 106 ms。代价是 mIoU 从 80.3 降至 78.0。因此更准确的结论是GitMerge3D 以有限的精度损失换取明显的资源节省而不是所有指标都完全不变。5.3 3D 重建80%—90% Token 压缩后仍保持相近画质论文 Figure 5、Figure 6在 GSO、Objaverse 等数据上的新视角合成结果以及 Token 压缩后飞机、椒类物体的重建可视化。论文使用 SplatFormer 评估新视角合成并在分布外OOD测试视角上比较 PSNR、SSIM 和 LPIPS。以下是 Table 6 中 SplatFormer 与 GitMerge3D 的结果数据集方法PSNR ↑SSIM ↑LPIPS ↓GSO-OODSplatFormer24.710.8570.152GSO-OODGitMerge3D24.560.8520.157Objaverse-OODSplatFormer22.430.8080.179Objaverse-OODGitMerge3D22.340.8030.185RealWorld-OODSplatFormer24.330.9000.100RealWorld-OODGitMerge3D24.060.8990.101这几组指标都只出现小幅变化。相较之下Random Drop、FPS 和 VoxelGrid 在大幅压缩后带来的重建退化更明显。该结果支持论文的判断与直接删除点相比基于特征与空间结构进行 Token 合并更有机会保留重建所需的信息。5.4 语言引导目标检测显存降低约 80%论文 Table 4 与 Figure 7在 SpatialLM 上将合并率设置为 0.5 和 0.8 的检测表现与资源消耗。方法F1 L25 ↑F1 L50 ↑F1 O25 ↑F1 O50 ↑时间显存SpatialLM0.49060.38860.33560.18946.009 s12.36 GBGitMerge3Dr0.50.49820.38060.34900.19465.269 s3.75 GBGitMerge3Dr0.80.48090.38730.34850.20064.795 s2.53 GB当合并率为 0.8 时推理时间从 6.009 秒降至 4.795 秒显存从 12.36 GB 降至 2.53 GB。各项 F1 分数与基线接近其中物体 F1 在两个 IoU 阈值下均有所提升而布局 F1 L25 有小幅下降。总体上模型在压缩后仍保留了有竞争力的检测效果。六、消融实验哪些设计真正重要6.1 全局能量分数优于局部能量分数论文在 ScanNet 上比较全局与局部能量分数。无合并时两者 mIoU 都为 76.3合并率为 0.5 时全局能量为 76.2局部能量为 75.7合并率为 0.8 时分别为 75.8 和 74.9。差距在高合并率下更明显。这与方法动机一致局部特征可能不足以判断 Token 与全场景结构的关系而全局参照能帮助识别更适合激进合并的区域。6.2 合并依据Value 特征与独立注意力头论文 Table 5比较用 Q、K、V 特征进行匹配以及是否为不同注意力头独立合并。设置QKV不使用独立 heads76.0876.3776.55使用独立 heads76.2776.3676.98在该消融实验中使用 ValueV特征并对各注意力头独立执行合并得到最高的 76.98 mIoU。这说明合并的效果不仅取决于压缩比例也会受到用于衡量 Token 的特征类型及注意力头处理方式影响。6.3 空间 bins 数量影响高比例合并的效果论文 Table 11不同 bins 数量 (K) 在不同合并率下的 ScanNet mIoU。合并率 (r)K128K64K32K160.577.0476.6776.7876.800.876.9876.3375.0373.990.976.6175.8474.3871.84当合并率达到 0.8 或 0.9 时较大的 (K) 能更好地保留空间分布。若 bins 太少许多 Token 可能被压到较少的 destination 上空间信息更容易丢失。因此空间均匀性是 GitMerge3D 在高压缩率下仍能维持表现的重要设计之一。6.4 能量阈值决定压缩与精度的权衡作者通过阈值 () 决定哪些 patch 进入激进合并分支并选择 () 作为效果与计算量之间的折中。附录中的结果显示随着合并率提高GFLOPs 和显存继续下降但 mIoU 也会逐渐下降。是否采用分支式自适应合并会影响这一权衡在相近计算量下保留高能量区域通常更有利于维持准确率。6.5 一个额外发现注意力本身也可能被替换论文还探索了用池化和 Token Shuffle 替换部分注意力计算。附录 Table 8 中PTv3 原模型的 ScanNet mIoU 为 77.3ShufflePool 从头训练得到 76.2接近原模型单纯 MLP 从头训练只有 42.7。这说明仅移除注意力并不够模型仍需要有效的空间信息交换。Token Shuffle 与池化的组合提供了一个值得进一步研究的轻量化方向。七、局限与思考GitMerge3D 展示了点云 Transformer 中可观的 Token 冗余但仍有几个值得注意的限制合并比例仍需手动设定。论文将 (r) 和阈值 () 作为配置参数尚未实现面向给定 GFLOPs 约束的端到端自动优化。精度并非完全不变。例如 nuScenes 上 mIoU 从 80.3 降至 78.0高合并率下空间 bins 数量也会明显影响结果。合并与恢复增加了方法复杂度。该方法需要计算全局能量、组织空间 bins并在注意力后恢复 Token 结构实际速度收益会受到硬件、框架实现和数据规模影响。全局冗余仍缺少完整理论刻画。作者在讨论中指出如何正式量化 Token 表示中的冗余并进一步自动减少冗余仍是开放问题。八、总结GitMerge3D 的核心贡献不是简单地删掉更多点而是把 Token 压缩变成一个结合全局特征重要性、区域自适应合并和空间均匀分布的过程。全局能量分数决定哪些区域更适合激进压缩空间 bins 让代表 Token 保持合理覆盖unmerge 则让压缩后的特征仍能接回逐点预测流程。实验覆盖语义分割、3D 重建和语言引导目标检测结果显示在较高 Token 合并率下模型通常仍能保持接近基线的性能同时显著降低计算量、显存和部分推理延迟。与此同时精度与效率之间仍需要根据任务选择合适的合并强度。一句话总结GitMerge3D 说明高效的 3D Transformer 不一定要处理更多 Token更重要的是识别哪些 Token 真正值得保留。

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询