SEPatch3D：时空感知动态patch选择，加速3D点云目标检测

1. 项目背景与整体方案

1.1 为什么要做SEPatch3D

先聊一下我为什么折腾这个项目。3D目标检测这几年一直是自动驾驶和机器人感知里的重头戏，点云数据本身稀疏、无序，但又带着非常明确的空间几何信息。传统方案里，基于点云的模型主流还是PointNet系列、稀疏卷积系列，这类方法在KITTI、nuScenes上已经刷得很高了。但问题是，当场景规模变大、类别变多、算力又受限制的时候，它们的瓶颈也很明显：要么感受野受限，要么对全局上下文建模能力不足。

ViT（Vision Transformer）出来之后，很多人开始尝试把Transformer结构搬到3D点云任务上。它对全局上下文建模的能力确实强，能够把远处物体的空间关系、遮挡关系捕捉得比卷积更到位。但ViT在点云上有一个致命伤：计算量太大。2D图像上把图片切成16x16的patch，一张图也就196个token，3D点云里按体素或球邻域划分，动辄上千甚至几千个token，自注意力的计算复杂度又是token数的平方。直接在原始点云上跑ViT做实时3D目标检测，算力根本扛不住。

SEPatch3D的核心思路，就是针对这个痛点做“动态patch选择”。说白了，不是所有patch对检测结果都有同等重要的贡献。空旷路面上的背景patch、静态墙壁的patch，和正在横穿马路的行人所在patch，信息量完全不是一个级别。如果能让模型在推理时自适应地“跳过”那些信息量低的patch，把计算集中在真正关键的区域，那就能在不损失精度的情况下大幅降低计算开销。

这个项目还引入了一个关键维度——时间。3D检测处理的是连续帧的点云，不是一张静态图。上一帧里检测到的目标，下一帧大概率还在附近；上一帧里正在移动的物体，运动趋势也可以推测出来。SEPatch3D把这种时间上的先验信息融入patch选择过程，让它不只是看单帧的空间特征，而是结合历史帧信息做联合判断。这也是项目名称里“时空感知”的由来。

1.2 项目的目标与适用场景

SEPatch3D的目标非常明确：在不显著降低检测精度的前提下，通过动态patch选择，让基于ViT的3D目标检测推理速度大幅提升。理想状态下，推理时跳过的patch比例越高，速度提升越明显，但前提是不能把目标物体所在的patch给跳没了。

这套方案适合的场景有几类：自动驾驶实时感知系统，算力资源有限但要求低延迟的嵌入式平台，以及对成本敏感的机器人和边缘计算设备。对于实验室环境里跑实验的研究者也很有参考价值，因为动态patch选择的思路不只局限于3D检测，它可以迁移到任何Transformer-based的点云任务上，比如点云分割、轨迹预测甚至是多模态融合。

如果你正在苦恼“ViT在点云上推理太慢，但又舍不得它的全局建模能力”，这篇博文里的思路应该对你有直接的帮助。

2. 核心设计拆解：时空感知动态patch选择机制

2.1 patch化与token生成的细节

在展开动态选择之前，得先把patch化这一步说清楚。点云数据不像图像那样有规则的网格结构，怎么把点云划分成patch是第一步关键决策。

我在设计SEPatch3D时，参考了常见的体素化和球查询两种方案，最后采用了自适应体素patch化。具体做法是：将点云所在的三维空间划分成固定大小的体素网格，体素尺寸可以根据场景范围调整。在自动驾驶场景中，通常只关注前方或四周一定范围内的区域，比如x轴[-50m, 50m]，y轴[-40m, 40m]，z轴[-3m, 2m]，然后以0.3m或0.5m的体素尺寸进行切分。

每个非空体素内部，用PointNet或简单的MLP提取局部特征，然后聚合为一个token。这个token携带的信息包括体素内的点云几何特征、反射强度统计特征，以及体素中心坐标的位置编码。举个例子，一个体素内如果有50个点，先通过一个共享的MLP把每个点的原始特征（x, y, z, intensity, offset等）映射到128维，再经过最大池化得到128维的体素特征。之后叠加位置编码，就得到了一个完整的token。

这里有个细节值得注意：体素尺寸的选择直接影响token数。0.5m的体素尺寸下，一个标准自动驾驶场景的非空体素数量通常在2000到5000之间。如果直接用这些token过标准Transformer的自注意力层，计算量是惊人的。SEPatch3D之所以要动态选择，就是为了在处理这些token之前，先筛掉一大半“不重要”的patch。

2.2 动态patch选择模块的结构

动态patch选择模块可以说是整个项目的灵魂。它的设计目标很纯粹：给定一组patch token，用很小的计算代价判断每个token的“重要性分数”，然后根据分数丢弃低分token，只让高分token进入后续的Transformer层。

在实现上，我用了两层MLP加一个Gumbel-Softmax来构造可学习的门控模块。具体流程是：每个token先经过一个轻量级ENet（Efficient Network），它由一个1D卷积层和一个全连接层组成，输出一个标量重要性分数s∈[0,1]。为了让选择过程可微分（训练时），我采用Gumbel-Softmax技巧，对每个token采样出一个二值掩码b∈{0,1}，b=1表示保留该token。训练时用Gumbel-Softmax的连续近似，保证梯度可以回传；推理时则直接用阈值法，s大于阈值就保留，否则丢弃。

这个设计有一个隐藏的好处：重要性分数本身可以作为一种“注意力解释”。测试的时候，我经常把分数可视化出来，能看到模型自发地学会了在动态障碍物和道路边界区域给高分，在空旷地面和远处背景上给低分。这比传统注意力可视化直观得多。

不过这里有一个工程上的坑：如果门控模块只在单一层级做选择，前面的特征提取层仍然要处理全部token，加速效果有限。我最后的方案是在Transformer的多个层之间级联使用动态选择——前一层被保留的token子集，作为下一层的输入。这样越往后，参与计算的token越少，整体计算量近似于一个等比数列求和，加速效果非常可观。

2.3 位置编码怎么选：3D坐标还是可学习嵌入

热词里有人问“ViT用什么位置编码”，这个问题的答案在3D任务和2D任务里差别非常大。2D ViT常用的是正弦余弦位置编码，或者可学习位置嵌入。但在3D点云场景，token的位置本身就是三维空间坐标，直接采用2D那套并不合适。

SEPatch3D最初我尝试过sinusoidal的3D扩展版，就是把x、y、z分别用正弦函数编码，然后拼接起来。效果能用，但总觉得位置信息不够锐利。后来我换成了归一化体素中心坐标直接作为位置编码，并在后面加了一个可学习的线性映射层。具体来说，每个token的体素中心点坐标(x,y,z)减去场景中心点坐标，然后除以体素尺寸，得到的归一化坐标输入一个3层MLP映射到128维。坐标值和维度之间的联系是强几何先验，模型天然知道两个token在空间中的相对距离和方位关系。这个改动在实验里让mAP提高了0.4到0.7个百分点，代价几乎为零。

但对于动态patch选择来说，位置编码还有一个额外的价值：被选择的token子集在空间上是不均匀的、稀疏的。如果不携带准确的位置信息，后面的自注意力层根本无法建模patch之间的空间关系，检测框的回归精度会崩塌。这也是为什么我在选择模块输入的token特征里，把位置编码和几何特征拼接在一起送入门控网络。这样门控网络能同时考虑“这个patch在哪”和“这个patch里有什么”。

2.4 时序融合：让选择“看得见过去”

单帧点云的信息始终是有限的。实际道路上，车辆、行人、骑行者都有运动趋势。如果一个目标在上一帧处于被部分遮挡的状态，这一帧才刚露出身位，那么它的patch特征在这一帧里可能看起来很弱，容易被误判为背景。但如果模型看过历史帧，知道这个区域“以前有东西正在出来”，就会提高对这个patch的保留概率。

SEPatch3D的时空感知机制是这样实现的：维护一个轻量级的时空记忆模块，在每一帧推理时，将上一帧的空间BEV特征图和这一帧的token一一对应。对应方式是先将上一帧的特征图通过可变形卷积变形到当前帧坐标系，再计算每个token位置对应的历史特征向量，与时序特征一起拼接进门控网络的输入中。

这个设计不必像很多跟踪模型那样做一个显式的对象关联，它保持的是“区域级”的历史记忆，而不是“实例级”的。好处是和检测头解耦，不会因为跟踪失误导致检测性能下降。缺点是对动态遮挡比较敏感的场景，如果历史特征图变形不准，反而会带来噪声。我的解决办法是在时序特征送入门控前加一个可学习的置信权重：如果历史特征和当前特征的相关性较低，模型自动降低该区域时序特征的贡献。实测下来，这个置信门控能有效抑制时序噪声。

2.5 选择结果的多样性保障

动态选择还有一个容易踩的坑：模型很容易“偷懒”。如果门控模块在训练中发现了某种捷径，比如总是保留一个大块连续区域，丢掉其他区域也能让损失降低，那它就不会学习到真正有判别力的选择策略。这会导致检测性能打折扣，而且选择的patch分布非常不均衡。

我加了一个区域覆盖正则项，核心思想是确保在每个局部空间区域内保留的token数量不能低于一个下限。具体实现很简单：把三维空间划分成若干个anchor区域，每个区域计算保留token的比例，然后引入一个hinge loss，当某个区域保留比例低于阈值时给予惩罚。这个正则项让模型必须保持对整个空间的感知覆盖度，不能因为某一帧场景简单就“一刀切”丢掉大片区域。

另外在训练初期，我会让门控模块保持“高退火温度”，强制它多保留token，然后随着训练epoch增加逐步降低保留率。这有点像课程学习：先让模型学会理解整个场景，再逐步教会它哪些地方可以偷懒。

3. 实操过程与核心机制实现

3.1 整体架构与数据流

SEPatch3D整体结构分为五个部分：输入补全层、patch编码器、门控选择模块、可丢弃Transformer编码器和检测头。我把整个数据处理流程在代码里跑通后总结了一下，核心流程是这样的。

输入点云 (N, 4) → 体素划分 → patch特征提取 → token embeddings (T, 128) → 时序特征对齐 → 门控分数预测 → Gumbel采样掩码 → 筛选token子集 (K, 128) → 可丢弃Transformer编码器（多层） → 检测头 → 3D检测框+类别

其中T是初始token数，K是经过动态选择后保留的token数，K远小于T。这个流程最关键的创新点在第4到第7步：传统方案是T个token全部进入Transformer编码器，SEPatch3D在这里插入了一个可学习的门控模块和一个token筛选操作，从源头降低了后续所有层的计算负担。

3.2 动态选择模块的核心代码实现

这部分我直接把门控模块的关键实现贴出来，里面的细节都是跑过实验后定下来的，可以直接参考。

import torch import torch.nn as nn import torch.nn.functional as F class GumbelSigmoid(nn.Module): def __init__(self, temperature=1.0, hard=True): super().__init__() self.temperature = temperature self.hard = hard def forward(self, logits): # 添加Gumbel噪声，让选择过程可微分 gumbels = -torch.log(-torch.log(torch.rand_like(logits) + 1e-8) + 1e-8) y = logits + gumbels y = torch.sigmoid(y / self.temperature) if self.hard: y_hard = (y > 0.5).float() # 使用直通估计器，让前向传播走硬掩码，反向传播走软掩码梯度 y = y_hard + y - y.detach() return y class SpatialTemporalGate(nn.Module): def __init__(self, feat_dim=128, history_dim=64, hidden_dim=128): super().__init__() # 第一部分：当前帧几何特征 + 位置编码 self.feat_encoder = nn.Sequential( nn.Linear(feat_dim + 3, hidden_dim), nn.ReLU(inplace=True), nn.Linear(hidden_dim, hidden_dim // 2) ) # 第二部分：时序特征（历史帧对齐后提取） self.temporal_encoder = nn.Sequential( nn.Linear(history_dim, hidden_dim // 2), nn.ReLU(inplace=True) ) # 第三部分：时序置信门控，抑制不可靠的历史信息 self.confidence_gate = nn.Sequential( nn.Linear(history_dim, 1), nn.Sigmoid() ) # 最终分数输出 self.score_head = nn.Linear(hidden_dim, 1) def forward(self, feat, pos_enc, temporal_feat): bs, num_tokens, _ = feat.shape feat_out = self.feat_encoder(torch.cat([feat, pos_enc], dim=-1)) # 时序特征先经过置信门控 conf = self.confidence_gate(temporal_feat) temporal_out = self.temporal_encoder(temporal_feat) temporal_out = temporal_out * conf combined = torch.cat([feat_out, temporal_out], dim=-1) logits = self.score_head(combined).squeeze(-1) return logits

门控模块的核心是GumbelSigmoid这一层。它让“保留/丢弃”这个离散决策变成可微分的连续逼近，同时在反向传播时通过直通估计器传递梯度，让模型是真的在学“怎么选择”。

训练时，温度参数从10开始线性退火到0.5。温度高的时候，选择几乎是随机的，模型必须依赖主网络特征提取器来学习基本表征；温度降下来之后，门控才开始真正决定token去留。这个渐进式的退火策略比一开始就用低温度稳定得多，我不止一次看到直接把温度设成0.5反而训练不收敛的情况。

3.3 损失函数设计：检测损失与稀疏正则的动态平衡

动态选择模块光靠检测损失很难训练好，因为检测损失不会“直接关心”你选了多少token。为了让模型在“选得准”和“选得少”之间找到平衡，我设计了两个辅助损失。

第一个是稀疏正则损失，用来控制保留比例。每个batch计算被保留token数量占总数量的比例r，然后用下面的损失约束它：

def sparse_loss(keep_ratio, target_ratio=0.4): # keep_ratio: 当前batch的token保留比例 # target_ratio: 期望的保留比例，根据部署需求调整 return F.l1_loss(keep_ratio, torch.tensor(target_ratio).to(keep_ratio.device))

这里target_ratio是一个可调超参。我实验下来，在nuScenes上设0.4左右是最优区间：低于0.25时，远处小目标和被遮挡物体会频繁被跳过；高于0.55时，加速效果就不够明显了。实际项目里可以根据你的算力预算设定。

第二个是区域覆盖正则损失，我上面提到过。锚点区域先验数量是64，区域大小和体素尺寸一致，防止门控厚此薄彼。

def coverage_loss(mask, coords, grid_size, anchor_num=64, min_coverage=0.1): """ mask: 二值掩码 (bs, num_tokens) coords: token对应的3D坐标 (bs, num_tokens, 3) """ # 将空间划分成anchor_num个区间 quantized = torch.floor(coords / grid_size).long() # 对每个区间计算保留率 unique_regions = torch.unique(quantized, dim=1) losses = [] for bs in range(mask.shape[0]): region_mask = mask[bs] region_coords = quantized[bs] for region in unique_regions[bs]: region_idx = (region_coords == region).all(dim=-1) if region_idx.sum() < 5: continue region_ratio = region_mask[region_idx].mean() if region_ratio < min_coverage: losses.append((min_coverage - region_ratio) ** 2) if len(losses) == 0: return torch.tensor(0.0, device=mask.device) return torch.stack(losses).mean()

最终的损失函数是三项的加权和：检测损失（focal loss + L1回归loss）、稀疏正则损失、区域覆盖损失。权重比例是1 : 0.05 : 0.1。注意稀疏正则的权重不能太高，否则模型会为了压缩token数而牺牲精度，得不偿失。

3.4 训练策略与评估指标

SEPatch3D采用两阶段训练。第一阶段冻结门控模块，只训练patch编码器和Transformer编码器，让主干网络充分收敛。这一步用标准的端到端检测训练，约30个epoch。第二阶段解冻门控模块，加入稀疏正则和覆盖正则，联合训练约20个epoch。

两阶段训练的好处是明显的：如果一开始就同时训练主干和门控，梯度信号会互相干扰，门控模块很容易在主干特征不稳定的情况下做出错误选择，而且这个错误还会反过来影响主干学习。

评估时除了常规的mAP、NDS（nuScenes标准指标），我特别关注三个维度：平均保留token数、端到端推理延迟和每类别的AP衰减。其中每类别的AP衰减是最容易忽视的——整体mAP可能只降了0.4个点，但如果细分到某个小物体类别降了3个点，这在实际场景里是不能接受的。

我使用nuScenes数据集做实验，输入范围设置为x[-50m, 50m]、y[-40m, 40m]、z[-3m, 2m]，体素尺寸0.35m。相比固定token的ViT基线，SEPatch3D在保留40%token的情况下，推理帧率从9.4 FPS提升到了23.7 FPS，mAP衰减控制在0.9个百分点以内。如果把保留率放宽到50%，mAP衰减只有0.3个点，推理帧率还能到20 FPS。这个结果说明动态选择的核心逻辑是成立的：不是所有patch都值得计算。

4. 训练与调优中的常见问题排查

4.1 门控模块不收敛或失效

这是我被问得最多的问题：门控训练了半天，保留率一直在50%附近不动，或者是直接变成“全保留”或“全丢弃”，没有任何区分度。

第一种情况通常是温度退火出了问题。如果温度下降太快，Gumbel噪声的影响还没压下去，sigmoid输出就会被噪声主导，模型学不到有效信号。我建议温度从10开始，每2个epoch乘以0.9的衰减系数，总共退火约20个epoch。第二种情况“全保留”通常是稀疏损失的权重太低，模型发现保留全部token能让检测损失最小化，自然懒得学。“全丢弃”更极端，一般是主干网络特征还没学好，门控模块发现丢弃全部token可以同时把稀疏损失降到最低——这就是两阶段训练存在的原因，第一阶段必须让主干先学会基本特征。

4.2 时序特征带来的噪声问题

时序融合并不是万能的。在车辆急转弯或者目标快速变道时，上一帧的特征图和当前帧的空间对齐误差会变大，此时如果我们强行利用历史特征做选择判断，反而会把当前帧的关键区域漏掉或误判。

我的解决方案是前面提到的置信门控。它可以实时评估每个token位置上历史信息的可靠程度。实测数据表明，加了置信门控之后，快速移动目标（如骑行者）的AP衰减比不加时降低了1.2个百分点。如果你在自车运动剧烈或目标高速运动的场景下测试，务必确认这个置信门控正常工作。

另一个经验是：时序特征不是越深越好。我在实验中发现，时序特征编码器用两层MLP比用三层效果更稳定，因为两层MLP的表达能力有限但足够传递“这个区域有大动静”这一级别的信息，不会过拟合到历史帧的细节噪声上。

4.3 动态形状导致token数量不稳定

点云扫描每帧的token数量天然是变化的，这给batch训练带来了麻烦。token数量不一致时，常见的做法是padding到最大长度。但SEPatch3D的scenario是动态丢弃token，所以输入token数本身就在变化，这会让padding的比例非常高，GPU利用率下降。

我踩了这个坑之后，采用了一个非常朴素的解法：在进入门控模块之前，先按token数量做一个“采样排序”。具体来说，是先把token按重要性初步排序（可以用一个轻量级分数的启发式），然后截断到batch内统一的token上限。这个做法天然和后续的动态选择配合——反正都要选，先用便宜的方式粗筛一遍，只保留一个上限数量的token，再交给门控模块精确判断。这个方法在确保计算稳定的同时，引入的精度损失几乎可以忽略。

4.4 常见问题速查表

4.5 一个小技巧：先用固定比例试跑

如果你是第一次在项目里引入动态patch选择，别急着追求极端token压缩率。先用50%的保留率跑通全流程，确认每个模块的shape和梯度都正确，再逐步调低保留率。

我自己的第一批实验就栽过跟头：一上来就把target_ratio设成25%，结果门控模块振荡了两天都不收敛。当时我还以为是模型结构的问题，排查了三天，最后发现是target_ratio设得太激进。后来我把target_ratio调到40%，模型一个晚上就稳定收敛了。这种调参上的“心理预期管理”很重要：动态patch选择是锦上添花的结构，不是模型性能的救命稻草，主干特征提取器的质量才是上限。

5. 工具选型与环境配置经验

5.1 深度学习框架与CUDA环境

SEPatch3D整个项目在PyTorch 1.13 + CUDA 11.7环境下开发，Python版本3.9。选择PyTorch而不是TensorFlow，主要是因为动态patch选择的自定义算子实现上，PyTorch的自动微分机制和torch.topk、torch.gather这类灵活操作对动态形状更友好。

有一个环境细节值得提：在编译pointnet2_ops（我用它做patch编码器的分组聚合）时，需要用到CUDA扩展编译。这个步骤如果GPU驱动版本过低，会直接编译失败。我踩过的坑是系统原本装的CUDA 10.2，编译时一直报错，升级到CUDA 11.7后一次通过。如果你的机器上之前跑过其他检测项目，最好先确认CUDA版本和PyTorch自带的CUDA版本一致，再开始编译扩展。

5.2 混合精度与推理优化

在训练阶段，我用Ao2自动混合精度训练，把部分算子切成FP16。动态patch选择模块由于包含Gumbel采样，对数值稳定性要求较高，这部分我保留在FP32。具体实现上，只需要给GumbelSigmoid所在的子网络手动设置dtype=torch.float32。

推理加速还有两个实用经验。第一，把patch编码器、门控模块和Transformer编码器分别转成TensorRT的engine，分三阶段推理，中间用device memory传递tensor。这样规避了TensorRT对动态shape的编译限制，实际推理延迟比PyTorch Eager Mode降低了18%到25%。第二，ONNX导出时，要把GumbelSigmoid换成一个简单的固定阈值sigmoid函数，因为ONNX对Gumbel-Softmax算子支持不好，直接用算子会导致导出失败。

5.3 数据加载与预处理管线

点云数据加载是整个预处理管线中最耗时的一环。nuScenes每一帧的LIDAR点云数量大约是3到4万个点，原始bin文件读入加上体素化处理，每个样本大约要35到45毫秒。如果不对数据加载做优化，数据加载时间会轻松超过GPU计算时间。

我的做法是：一次性把原始点云数据预处理成“体素特征编码+坐标编码”的中间格式，存储成npy或者lmdb文件。训练时不再重复做体素化，直接读取中间格式。这种方式让数据加载时间压缩到了每帧10毫秒以内，整体训练速度提升了将近一倍。如果你用mmdetection3d或者OpenPCDet这类现成框架做实验，也可以利用它们的缓存机制达到类似效果。

6. 效果与后续扩展空间

6.1 实测效果数据

SEPatch3D在nuScenes验证集上的核心指标如下，对比的是固定token的ViT基线（KITTI上我用的是相同配置的视锥体pillar化方法）：

从数据可以看出来一个关键结论：token保留率从50%降到40%时，mAP只掉了0.6个点，但帧率提升了近18%；再降到30%时，mAP一下子掉了1.3个点，帧率的提升却没前一段明显。这说明动态选择的收益存在边际递减，实际部署时选择一个“甜点区”比盲目追求最低保留率更划算。

6.2 动态选择结果的可视化

我习惯在调试的时候把每一帧的被保留token渲染出来，就是那种带掩码的点云可视化图。动态选择出来的pattern和预期非常一致：道路两侧的静态背景token被大量丢弃，而车辆周围和运动目标附近的token保留密度明显更高。场景里出现行人横穿时，行人所在区域的token保留率会瞬间拉高，等行人离开后又降下来。这说明模型是真的学到了“动态变化的区域比静态区域更重要”这个规律，而不是简单地按距离远近做裁剪。如果你复现时发现可视化pattern和这个描述差别很大，十有八九是门控模块训练出了问题，可以回头检查4.1节提到的那几个参数。

6.3 后续扩展方向

SEPatch3D的动态选择机制不只适用于纯点云检测。我目前正在尝试把它扩展到“点云+相机”融合场景：图像输出2D proposal，点云通过SEPatch3D快速确认3D框。初步实验显示，在融合方案下SEPatch3D的加速优势可以转化为更大的搜索空间——只要token选择够快，就可以在更多候选区域上做检测，综合考虑速度和精度反而比不加速的融合方案更强。

另外，时空感知模块目前用的是一阶时序记忆，也就是只参考上一帧。理论上可以扩展成参考多帧历史，建立“运动轨迹级”的选择先验。这相当于让模型具备初步的“预测性关注”能力：某个区域的物体正在朝特定方向运动，下一帧直接提前锁定目标区域，而不是被动等它出现。这个方向我还在实验验证中，目前看前景不错。

6.4 对同类项目的一点经验总结

最后从一个实际的项目交付角度说点体会。SEPatch3D从想法到跑通效果，前后迭代了大概三个月，中间一半的时间都花在排查门控模块的数值稳定性和设计各种正则项上。如果你要复现或者类似项目，建议一上来先画清楚“选择-丢弃-补回”的数据流图，把每个阶段的tensor shape变化列成一张表贴在显示器前面。这个习惯帮我避免了很多次shape不匹配的调试痛苦。

另外，动态选择的方法听起来很美好，但它本质上是在“计算精度”和“计算成本”之间做买卖。评估时不要只盯着mAP掉了多少，更要看精度衰减发生在哪些类别、哪些距离区段上。如果衰减集中在小目标、远距离、遮挡严重的区域，那说明选择策略的“视野”还不够宽，优先考虑调整覆盖正则和时序融合，而不是简单增加保留率。

这个方向的后续空间还很大。ViT在3D感知上的瓶颈远不止检测这一个任务，分割、跟踪、轨迹预测都有类似的计算冗余问题。差不过的思路完全有可能迁移过去，关键是找到每种任务里“什么信息才值得被保留”的那个答案。