1. 内容整体设计与思路拆解
1.1 传统目标检测的痛点：Anchor、NMS与手工设计
我第一次认真读DETR论文，是2019年左右。当时目标检测这个领域其实已经有非常成熟的方案了，Faster R-CNN系列、YOLO系列、SSD系列，跑起来都能看到不错的指标，但这些方案有一个共性的问题：模型里塞了大量“手工设计”的组件。比如Anchor的尺寸比例怎么设？RPN的IOU阈值取多少？NMS的抑制阈值怎么调？特征金字塔每一层负责多大尺度的目标？这些问题在每一套新数据集、新场景下都要重新调一遍，工程师心里其实没什么底，反正就是试。
DETR做的第一件颠覆性的事，就是把这些组件全部拆掉。它把目标检测重新定义成一个“集合预测”问题：模型一次性输出一组预测结果，每一条预测包含目标的类别和包围框，然后直接和真值做二分图匹配来计算损失。这个思路说出来其实很朴素，但要做到“没有Anchor、没有NMS、不需要手工先验”，难点在于怎么设计一个网络结构，能让模型直接学会“哪些预测对应哪些目标”。
当时Transformer在自然语言处理领域已经把序列建模玩得风生水起，自注意力机制天然具备建模全局依赖的能力。DETR的作者就做了一个直觉上的迁移：如果把图像特征看成一组序列，让Transformer去建模特征点之间的关系，那是不是就能让模型自己学会“这个位置和那个位置属于同一个物体”？
1.2 DETR到底解决了一个什么问题
DETR全称是Detection Transformer，核心价值可以概括成一句话：用一套统一的Transformer架构，把目标检测做成真正端到端的训练与推理流程。这里的“端到端”不是营销话术，而是指从图像输入到预测结果输出，中间的“目标候选生成”“特征对齐”“去重后处理”全部被替换成了可微分的网络层。
换个角度理解：以前的检测器把任务拆成好几个子问题，比如先生成候选框、再逐框分类和回归、最后用NMS合并重复框。每一步之间的信息传递是割裂的，而且很多操作没法直接求梯度，比如NMS里“保留哪个框”这个决策是离散的。DETR把这套流水线压缩成了一个“特征编码—对象查询—集合匹配”的整体，所有参数可以一次性端到端训练，推理时也不需要做NMS（当然实际用的时候为了保险，还是有人会做一下简单的去重，但原理上已经完全不需要了）。
这篇文章适合谁读？如果你刚接触Transformer在视觉领域的应用，想弄明白DETR的完整结构，而不只是停留在“跑个demo”的层面；如果你想在自己的数据集上复现或改进DETR，但又不知道从哪下手；或者你只是对“为什么Transformer能做检测”这个问题感兴趣，那这篇内容应该能帮到你。我会从结构设计的思路一路讲到训练里踩过的坑，尽量把我实际用下来觉得值得注意的东西都说清楚。
2. DETR的核心结构：三大模块与一条主线
2.1 整体流程能分成哪几块
DETR的结构从宏观上可以切成三段。第一段是CNN骨干网络，通常用ResNet-50或ResNet-101，负责把输入图像降采样成分辨率较低的特征图，这一步和经典检测器的Backbone没有本质区别，唯一要注意的是DETR一般会去掉ResNet最后一个Stage的步长，让输出特征图分辨率保持在32倍降采样，这样能保留更多空间细节。
第二段是Transformer的编码器和解码器。编码器接收的是“展平后的图像特征序列”，自注意力模块会在整张图的特征之间做交互，相当于让每一个空间位置都“看到”全图的上下文。解码器稍微复杂一点，它不直接读取特征图，而是输入一组可学习的“对象查询”向量，通过交叉注意力机制从编码器输出的特征里“查询”出每个目标的特征，再逐步细化。
第三段是检测头。解码器输出的每个对象查询向量，会被送入一个FFN（前馈网络），预测出目标的类别分布和包围框坐标。类别分支输出的是最多一个类别（或者“空”这个背景类），框分支则输出归一化后的中心点坐标和宽高。
这里有一个很关键的设计：为什么解码器能用“固定数量”的对象查询？因为DETR假设“一张图里最多同时出现N个目标”，N是超参，论文默认设100。就算图里只有两三个目标，模型也会输出100条预测，但多余的预测都会通过“背景类”被抑制掉。这种设计在生产环境里其实挺方便，因为输出的张量形状是固定的，部署时对显存和算力的预估更简单。
2.2 “集合预测”这一层思路比结构本身更难懂
第一次看DETR结构的人通常会有一个疑惑：编码器输出的是一组特征，解码器查询的是一组可学习向量，模型怎么知道哪个查询对应哪个目标？答案就是“二分图匹配”机制。
训练阶段，我们会把模型的100条预测和真值框做一个最优匹配。这个匹配问题的代价函数包含三部分：类别预测是否和真值类别一致、预测框和真值框的L1距离、预测框和真值框的GIoU距离。用匈牙利算法找到“让整体代价最小”的匹配方案，然后只对匹配成功的预测计算损失，没有匹配上的预测全部按背景类计算损失。
这个机制有点像排队领东西：有100个人（预测），桌上摆了若干个印了名字的礼物（真值），每个人只能拿一个，但礼物和名字之间不是一一对应的，我们需要找出一种分配方式，让所有人的满意度总和最高。匈牙利算法解决的就是这个分配问题。
为什么不能简单地把第i个预测强行对应第i个真值？因为Trm解码器输出顺序没有几何先验，第1个查询不一定对应左上角的物体，模型内部又没有谁来保证输出顺序。如果不做匹配而是按位置强行对齐，训练就崩了。这算是DETR设计里最精妙、也最容易被人忽略的部分。
2.3 训练与推理时的行为差异
训练阶段，DETR的损失是“匹配后”的损失：先用匈牙利算法做一次匹配，再计算匹配上的预测与真值之间的距离损失。这个设计意味着即使模型一开始预测得很差，只要匹配关系建立了，梯度信号依然能沿着对应的路径回流到正确的位置。
推理阶段就简单多了：不需要做匹配，直接把解码器输出经过FFN得到类别和框，然后按置信度过滤掉“空”类预测，剩下的就是检测结果。如果还有少数重叠的框，常规做法是直接按置信度取TopK，或者做一个非常宽松的NMS。我在工程落地时还是会用一个低IOU阈值的NMS，省得被下游逻辑抱怨“怎么同一个目标出两个框”，但这不是算法必需，纯属工程洁癖。
3. 关键模块拆细：编码器、解码器与位置编码的配合
3.1 编码器怎么把图像特征变成序列
图像输入DETR后，会先经过CNN骨干，假设输入是800×800的图像，经过ResNet的降采样后，特征图大概是25×25×2048。接下来为了进Transformer，需要把这个特征图压扁成序列：25×25=625个token，每个token的特征维度是2048。
Transformer编码器内部首先会用卷积1×1把特征维度从2048压缩到d_model（论文用256），这样能省下不少显存和计算量。然后会加上一个空间位置编码，再被送入一个标准的Transformer编码器层：多头自注意力+FFN，中间有残差连接和LayerNorm。编码器可以叠加多层，论文默认是6层。
这里最值得说道的是位置编码。图像特征被压成序列后，如果没有任何位置信息，自注意力做全局交互时，“左上角”和“右下角”在模型看来没有任何区别。这显然不行，因为目标检测本质上是“在哪里”的任务。DETR用的位置编码是空间版的三角函数编码：分别给x轴和y轴生成一套正弦/余弦编码，然后和特征逐元素相加。注意DETR的位置编码和输入特征是加法关系，不是拼接关系，这一点和Transformer原始论文里的做法一致。
3.2 对象查询到底是什么：可学习的“先验”
很多人把对象查询理解成“anchor的替代品”，这个类比其实挺到位的。Anchor是手动定义的、固定尺寸比例的候选框；对象查询则是一组可学习的嵌入向量，它们在训练过程中会逐渐变成“某种语义信息的触发器”。
具体来说，100个对象查询里，有的查询可能慢慢学会“专门负责中等尺寸、位于画面中央的目标”，有的是“负责大尺寸且偏左下区域的目标”。模型并没有显式地给每个查询规定分工，这种专业化完全是从数据里自发涌现出来的。你可以在训练后把每个查询对应的注意力图可视化出来，会很清晰地看到“固定位置、固定尺寸”的偏好。
解码器内部做的是这样一件事：每个对象查询先通过自注意力互相通信，避免多个查询重复指向同一个目标（这是DETR不需要NMS的底层原因之一）；然后通过交叉注意力，从编码器的特征序列里提取目标相关的信息。每一层做完后都会更新查询向量，经过6层解码器层的迭代，最后的输出向量就包含了足够丰富的类别和位置信息，足以供给FFN做最终预测。
3.3 解码器自注意力如何替代NMS
“免NMS”这个特性，很大程度要归功于解码器第一层里的自注意力。在标准Transformer解码器里，自注意力让不同token之间互相“看到”彼此；放到对象查询这个场景里，就是100个查询会互相协商，知道“我已经选中那个物体了，你别跟我抢”。
这个协商机制不是强制性的，它不像NMS那样有明确的“保留置信度高的、删除重合度高的”规则，而是靠数据驱动学出来的。两个查询如果确实同时锁定了目标，经过自注意力后，它们输出的特征会有强相关性；模型在训练时通过二分匹配会让“分数更匹配”的那个查询拿正样本，另一个查询被对应到背景类，这样梯度信号就会迫使另一个查询学会“换一个目标去关注”。训练久了，这100个查询的“分工”会逐渐稳定下来。这也是为什么DETR有时候会出现“漏检”，当目标数量非常接近100时，查询之间协商不充分，互相谦让过头了，就没人输出那个框。
3.4 FFN检测头与输出格式
解码器最后一层的输出，会分别进入类别分支和框分支。类别分支是一个线性层+Softmax，输出每个查询在C+1个类别上的概率（C个目标类别加1个背景类）。框分支是一个3层MLP，输出4个数值：归一化的中心坐标（cx, cy）和归一化的宽高（w, h）。
这里有一点容易踩坑：框分支的输出范围没有做激活函数限制，也就是说模型理论上可能输出负的宽度或高度。实际训练中因为匹配了正确的真值框，大多数预测不会出现这种离谱情况，但推理时如果看到“宽高为负数”的检测框，通常是模型还没收敛好，加长训练轮次即可。如果想要更稳，也可以在输出后手动做一次绝对值操作，但这只能算工程侧保险，不解决模型本身的问题。
4. 实操过程：准备数据、训练调参与推理部署
4.1 数据标注与格式转换
在DETR上做真实验收，第一步是准备COCO格式的标注数据。我一般用在线标注标注完导出成COCO JSON格式，然后写一个脚本把标注文件转换成DETR训练需要的格式。DETR的官方代码里直接支持COCO数据集，所以你只要把标注改成COCO格式就行，包括info/licenses/images/annotations/categories这五个关键字段。
标注的时候有几个细节特别关键。一是包围框的坐标要存成[x, y, width, height]的绝对像素值，而且不允许出现负值；二是Duplicate标注一定要清理干净，如果同一张图上同一个目标存在两个框框，训练时匈牙利匹配会无所适从，目标可能会被两个查询同时对应上，导致训练信号混乱；三是类别ID从1开始编号，0留给背景类，官方代码里读categories时它会把0留给“空”，如果你从0开始编号，后面推理时会发现类别输出整体错了一位。
4.2 训练超参数：我从论文里抄的作业和改动
官方默认配置大致是：ResNet-50骨干，Batch Size 64，训练300个epoch等效于COCO train2017上跑大约110个epoch，初始学习率1e-4，在200个epoch时乘以0.1。优化器用AdamW，weight decay 1e-4。骨干网络加载ImageNet预训练权重，Transformer部分用Xavier初始化。
实际复现时，我建议根据自己的设备去降Batch Size，但学习率要按比例调整。我自己试过，Batch Size从64降到16的时候，学习率最好也降到2.5e-5左右，否则模型会训得特别浪，损失经常跳到NaN。不过还有一个更稳的做法是保留官方学习率，但用累积梯度把等效Batch Size撑回至少32，这样与原始配置偏离不大，收敛性也更可控。
DETR最大的短板就是收敛慢，300个epoch在8张V100上要跑两三天，单卡用户基本吃不消。所以如果不是做论文复现，我更推荐用官方代码里自带的“150 epoch”版本或“50 epoch”简化配置，配合更多的数据增强。我自己在业务项目上用过50 epoch那个版本，效果虽然比300 epoch的差一点，但交付周期短很多。
4.3 数据增强策略与Loss设计
DETR对数据增强是极度依赖的。官方训练时用到的增强包括随机缩放（短边480到800之间随机取）、随机裁剪、水平翻转。这些增强消融实验影响很大，特别是随机缩放，它能给模型提供丰富的尺度多样性，让Transformer学到的“对象查询分工”更稳定。如果不做增强，模型很容易在小目标上直接摆烂。
损失函数这块官方代码用的是L1损失和GIoU损失的线性组合。公式是这样的：loss = λ1 * L1(box_pred, box_gt) + λ2 * GIoU(box_pred, box_gt)，默认系数λ1=5，λ2=2。这里L1损失负责让预测框的中心点“贴近”真值框，GIoU损失则负责让预测框的“形状和覆盖范围”接近真值框。两个损失配合使用，效果比单独用任何一个都要稳。
还有一个小技巧是auxiliary loss。DETR解码器的每一层都会输出预测，训练时会给每一层都算一次损失，并把这6层的损失加在一起回传。这个设计能显著缓解深层次解码器的梯度消失问题，也加速收敛。这个技巧后来被很多DETR变体继承，比如Deformable DETR和DN-DETR都用了auxiliary loss。所以如果你用官方代码训练，默认就带上了这个机制，不用额外操心。
4.4 推理端到端流程：从模型输出到业务结果
推理时，输入图像同样会先被预处理到固定尺寸（长边不超过1333，短边不小于800），然后经过骨干、编码器、解码器，最后拿到100个输出预测。接下来按置信度阈值过滤掉背景类和低置信度的框，比如阈值设0.7；如果业务场景只关心TopK个目标，再对置信度排序后取前K个即可。
这里分享一个实际工程经验：DETR的框坐标输出头是用归一化中心坐标+宽高格式表示的，测试时需要转成像素坐标才能传给下游。转换公式很简单：x = cx * width，y = cy * height，w = w_norm * width，h = h_norm * height，其中width和height是原图宽高。如果输入图像被等比缩放填充过，还要注意做反向映射。我第一次上线DETR服务的时候，就因为在坐标还原上多算了Padding偏移，线上结果在图像边界处总差几个像素，排查了半天才找到问题。
5. 常见问题与排查技巧实录
5.1 训练不收敛或损失震荡很大怎么办
DETR的训练窗口比较长，前几个epoch损失下降慢是正常的，但如果20个epoch后损失还在原地徘徊，就要优先检查这几个点。
一是学习率是否过大。我自己的经验是，Batch Size缩小时学习率不跟着缩，是初学者最容易犯的错误，这会导致优化过程在损失曲面边缘反复横跳。二是骨干网络的预训练权重是否被冻结或错误初始化。DETR的骨干如果从头训练，收敛速度会比加载ImageNet预训练慢很多很多，至少在COCO这种数据量上最好不要尝试。三检查是否用了auxiliary loss，如果自己写了简化版DETR而没有加auxiliary loss，解码器深层的梯度信号会很弱，也有可能导致训练卡住。
5.2 大目标还行，小目标检不出来
DETR原版在小目标检测上的效果不算好，这是一个结构性的问题：CNN骨干输出特征图是32倍降采样，一个小目标在原图上可能只占20×20像素，降采样后连一个特征点都占不满，Transformer再能干也没有足够的特征信息可用。所以如果业务场景里小目标多，原版DETR基本不适用，要做改进。
最直接的办法是换用Deformable DETR，它有类似FPN的多尺度特征机制，会在不同分辨率的特征图上做可变形注意力，效果会好很多。另一个思路是提高输入分辨率，让特征图保留更多细节，但显存消耗会同步上升。实在不行，还可以在骨干部分引入FPN结构，把输出特征图分辨率从32倍降到16倍甚至8倍，再送入Transformer编码器。
5.3 显存占用高，训练跑不起来
DETR的显存开销主要来自Transformer编码器的全局自注意力，以及解码器6层堆叠的交叉注意力。800×800的输入，编码器自注意力的计算复杂度是O(N²)，N=25×25=625，这个数量级不算特别爆炸，但Batch Size一上去，显存还是会有点疼。
我的经验是先用梯度累积跑通小Batch，比如Batch Size=2、累积32步等效Batch Size=64，先看看模型能不能收敛，再逐步提高Batch Size。如果显存确实很紧张，可以考虑用混合精度训练，DETR对FP16的容忍度还不错，只要在Loss缩放上稍微注意一下。另外，把编码器层数从6层减到3层，是显存和精度之间比较划算的折中方案。
5.4 为什么会出现同一目标多次重复框
虽然DETR的设计目标是避免NMS，但训练不够充分或者查询数量设得太少时，偶尔还是会输出几个高度重叠的框。我排查下来，最常见的原因是目标数量接近查询数量上限，100个查询不够用，导致模型只能把两个查询分配到同一个目标上，输出了两个大同小异的框。
解决办法有两种。一是增加对象查询数量，比如改成300或1000，这能明显缓解重复框问题，但推理速度会变慢；二是在推理端加一个宽松的NMS，IOU阈值设0.8以上，只合并那些高度重叠的框。我实际项目里两种方法都用了，查询数量300加上非常宽松的NMS，效果最稳，既不会丢框也不会重复框。
6. 从DETR到Deformable DETR与其他变体
6.1 原版DETR的痛点推动了后续演进
原版DETR奠定了“目标检测=集合预测”这个范式，但它有两个很突出的短板，一个是收敛太慢，另一个就是上面提到的小目标效果差。这两个短板的根源都在于“全局自注意力”：每层每个query都要去看全图的特征，计算成本高，而且要学很久才知道哪些位置是有价值的。
Deformable DETR是针对性最强的改进版本。它把标准自注意力换成了可变形注意力，每个query不再是全图扫描，而是通过一个轻量网络预测出一组采样点的偏移，然后只在这几个采样点上做注意力。这样计算复杂度从O(N²)降到了O(N·K)，其中K是采样点数量，一般默认只有4到8个，同时还能通过多尺度特征来提升小目标检测能力，一举两得。我在自己的项目上尝试过把Deformable DETR的多尺度模块单独抽出来做特征增强，效果也很明显。
6.2 后续变体：“降噪训练”与“去模糊”
DETR这条线后来还有几个值得一提的演进。DN-DETR引入了一个“降噪训练”的机制，训练时给真值框加一些随机扰动，让对象查询去重建完整框，这相当于给模型提供了额外的学习信号，收敛速度比原版快很多。DINO则像是在DN-DETR基础上又加入了对比学习和更好的初始化，直接刷新了COCO上的性能记录。
另一个方向是Conditional DETR，它把对象查询拆成“内容查询”和“位置查询”两部分，让交叉注意力在“看什么”和“看哪里”上各司其职。这个改动看似不大，但标准注意力的计算结构改变了，解码器的训练效率提升明显。
6.3 从DETR到更广泛的视觉Transformer应用
DETR的影响早就超出目标检测本身了。它证明了一个思路：Transformer结构可以直接作用于视觉特征，并且替代掉大量手工设计的任务专用模块。后来的SAM（Segment Anything Model）、CLIP的Text Encoder等大模型，虽然从任务到结构都跟DETR差别很大，但底层“图像特征序列化+自注意力全局建模”的思路，其实都能从DETR里看到影子。
如果想把DETR迁移到自己的场景，我的建议是先跑通官方代码，把骨干、编码器、解码器、匹配、损失这几个部分的代码逐一读一遍，不要急着改。只有真正理解了“匈牙利匹配为什么能替代手工匹配”“位置编码为什么是加法不是拼接”这些细节，才能在后续换骨干、换Loss、换推理策略时心里有底。
按我个人的实际经验，DETR类模型在一个新场景里最怕的不是精度不够，而是“训练不上来”。它不像YOLO那样调几个训练技巧就能很快看到效果，需要更多耐心去等它收敛。但一旦训练稳定了，推理时那种“干干净净直接输出结果”的体验，确实比传统检测器舒服得多。如果你也在折腾DETR，建议先拿小数据集把整个训练流程跑通，再逐步放大，这样会少掉很多头发。
