凌晨两点，盯着训练日志里显存占用曲线，我点了支烟。客户把部署平台从V100换成了Jetson Orin Nano，要求实时检测帧率不低于30FPS，模型还得塞进4GB内存。原版RT-DETR在COCO上跑得挺欢，一到边缘设备就现了原形——多尺度特征融合那几层Transformer吃掉了大半算力，解码器的交叉注意力在长序列上像个内存黑洞。需求拆解：边缘端的三重门精度不是唯一标尺项目墙上贴着指标：mAP@0.5不能低于70%，但下面还有行小字——“在T4 GPU上推理时间≤15ms”。这意味着传统DETR那种堆叠编码器层的路子走不通。上周试过剪枝预训练模型，砍掉三层编码器后小目标检测直接崩盘，召回率跌了12个百分点。教训很明白：轻量化不是简单删除，得重新思考信息流。内存带宽比FLOPs更致命Jetson的共享内存架构里，卷积和Transformer的访存模式差异巨大。测试发现同样的计算量，自注意力层比深度可分离卷积多耗35%的功耗。硬件同事扔过来一张功耗热力图：“你们那个query-to-key矩阵乘，每次推理都在给散热片加热。”部署友好性暗坑客户的生产环境用TensorRT 8.6，对动态形状的支持依然别扭。原版DETR的可变查询数导致引擎需要多配置，切换时产生毫秒级延迟。生产线上的传送带可不会等你——帧率波动超过2ms就可能漏检。架构草图：在卷积与注意力之间走钢丝主干网络重新选型放弃ResNet，转向G