从一次深夜调试说起
上周在部署RT-DETR到边缘设备时遇到个怪现象:同样的模型在服务器上mAP能到42.3%,到了Jetson Orin上直接掉到38.1%。
用perf工具抓了热点,发现70%的时间耗在解码头的查询交互模块。问题出在默认的300个查询全部参与计算,而实际图像中目标很少超过20个——大量计算浪费在了“空气”上。
这引出了今天要讨论的核心:如何让查询更聪明地选择与交互。
查询选择:从静态到动态
原始RT-DETR的查询初始化是固定的300个可学习向量,相当于准备了300个“提问模板”。但实际场景中,不同图像需要提问的数量和角度完全不同。
# 原始写法(别这样写)self.query_embed=nn.Embedding(300,hidden_dim)# 改进方案