做检测落地的这几年选型会上一半的争论都集中在两派之间一边是 DETRs 这一系列端到端检测器一边是 YOLOs 这套单阶段方案。前者不用 NMS、后处理干净听着就让人舒服后者快、生态全、部署链路被踩过无数遍。真正卡住大家的从来不是谁精度高而是在实时目标检测这个硬约束下端到端到底能不能打。百度那篇《DETRs Beat YOLOs on Real-time Object Detection》就是正面回答这个问题的作品产物就是 RT-DETR。我前后用它的 R50 和 L 两个规格做过工业质检和园区周界两个项目也在论文复现上踩过一些坑这篇就把论文的方法论、关键模块的算力账、复现路径和部署经验一次讲透。适合正在做检测选型的算法工程师、准备复现 RT-DETR 的学生以及需要给项目选一个时延可控检测器的工程同学。1. 端到端检测器为什么一直卡在实时赛道门口1.1 从 DETR 到 DINO精度翻了速度没翻2020 年 DETR 出来的时候大家兴奋的点其实不在精度而在不用 NMS这件事本身。Transformer 编码器加解码器、匈牙利匹配做一对一标签分配、一次输出固定数量的框后处理就是取分数前几名干净得不像检测器。但它的毛病也很明显ResNet-50 版本在 COCO 上 42 AP 左右训练要 500 个 epoch 才收敛小目标尤其难看速度也上不去。后面这条线一路演进Deformable DETR 用多尺度可变形注意力把收敛轮数压到 50 epoch 以内DAB-DETR 把查询变成带锚框语义的四维表示DN-DETR 引入去噪训练加速收敛到 DINO 基本把精度打到了 DETR 系的天花板——R50 十二个 epoch 就能到 49 AP 左右36 epoch 到 51 AP 出头。精度这条路走通了速度这条却始终差一档。DINO-R50 在 T4 上开 TensorRT FP16帧率大概在 60 FPS 量级同期 YOLO 系在同样口径下普遍在 120 FPS 以上。差一倍对于要跑多路视频流的服务器或者算力紧张的边缘盒子这一倍就是能不能上线的区别。所以过去几年行业里的默认结论是要精度用 DETR 系要速度用 YOLO 系想两个都要那就只能上蒸馏或者换更小的骨干本质是在精度和速度之间做交换而不是同时拿到。1.2 NMS 这笔账很多人只算了平均时延NMS 被诟病最多的是多了一个超参但这个说法太轻了。我把它拆成三个层次看第一层是超参数耦合。NMS 的置信度阈值和 IoU 阈值需要按场景反复调。同一个模型换一批数据、换一个摄像头视角最优阈值就可能变。这就导致模型的端到端程度打了折扣——你没法把一个训练好的权重直接丢给另一条产线总得有人重新标定后处理。第二层是时延与场景耦合。NMS 的计算量取决于进入 NMS 的候选框数量而这个数量又跟图像里的目标数量、置信度阈值强相关。空场景和几百个目标的密集场景NMS 耗时可能差好几倍。做实时闭环控制比如机械臂抓取、AGV 避障时真正要命的是 P99 时延而不是平均时延而 NMS 恰好是那种均值好看、长尾难看的算子。第三层是部署链路的复杂度。NMS 在一些推理框架里是独立算子或者需要自写插件量化友好度也一般排序和大量比较操作在部分加速器上并不能很好地并行。链路里多一个非标准算子就多一个版本的坑。论文里专门做了一组实验来量化这件事固定模型、改变场景中的目标数量和置信度阈值观察后处理延迟的变化。结论是端到端检测器的推理时延基本只跟输入分辨率有关而带 NMS 的方案时延曲线会随目标数往上爬。这组实验比任何一句端到端更优雅都有说服力。1.3 RT-DETR 要回答的三个具体问题把前面的分析拧成具体的技术问题论文实际上要解决三件事编码器里的注意力太贵。原始 DETR 系在编码器阶段就用多尺度注意力而编码器的注意力实际上有两个不同的目的——同尺度内的语义增强和跨尺度的信息融合。把两件事都交给注意力做成本翻倍收益却不一定线性。解码器的查询给得不够好。两阶段 DETR 的查询选择只看分类分数选出来的候选框可能分类很自信但框得很偏解码器得花好几层把自己的起点纠正回来等于浪费了计算。一套权重没法覆盖多档速度。工程上经常需要在不同算力的设备上跑同一个项目传统做法是训大中小三个模型训练和运维成本都翻倍。RT-DETR 的三个核心设计正好一一对应混合编码器、IoU-aware 查询选择、解码器层数可截断。下面逐个拆。2. 整体架构拆解三处改动撑起实时两个字2.1 高效混合编码器注意力只花在高语义层先看数据流。输入图像过骨干网络拿到三个尺度的特征图S3下采样 8 倍、S416 倍、S532 倍。以 640×640 输入为例对应的特征图尺寸分别是 80×80、40×40、20×20展平成 token 就是 6400、1600、400。RT-DETR 的混合编码器把编码过程拆成两个明确的阶段阶段一叫 AIFI也就是基于注意力的尺度内特征交互。它只作用在 S5 上做的是标准的多头自注意力加前馈网络。之所以敢只在一层上做理由很直接高层特征虽然分辨率低但语义信息最丰富编码器需要建模的语义关系主要靠它而且它的 token 数最少注意力成本最低。阶段二叫 CCFF也就是基于卷积的跨尺度特征融合。S5 经过 AIFI 之后自顶向下依次和 S4、S3 融合每个融合单元由两个 1×1 卷积做通道对齐、相加、再过一个 RepConv 组成。跨尺度这一步为什么用卷积不用注意力因为在不同分辨率的特征图之间做对齐和搬运本质是局部邻域的信息整合卷积的感受野完全够用而且卷积在硬件上快、支持量化、不需要位置编码适配。换句话说注意力负责在同一个尺度内想清楚卷积负责把不同尺度的信息搬过来。这个拆分的顺序不能反。论文的消融实验显示先做尺度内交互、再做跨尺度融合精度优于反过来。我的理解是AIFI 先把 S5 的语义理清楚让它作为融合的骨架往下传递的就是干净的语义线索如果先融合S5 已经被低层特征混入细节噪声再去做自注意力建模的关系就不那么纯粹了。2.2 IoU-aware 查询选择让解码器从好起点出发这是我认为整篇论文里性价比最高的一处改动几乎不增加推理成本但训练收敛和最终精度都受益。原始两阶段 DETR 的查询选择是这么做的在编码器输出特征上接一个分类头对每个位置打分取分数最高的 K 个RT-DETR 里 K300把对应的特征作为内容查询、对应的预测框作为初始参考框送进解码器。问题在于分类分数衡量的只是这里有没有东西不衡量这个框画得准不准。实践中经常出现这种情况某个候选框分类置信度 0.9但框得特别大把周围几个真实目标都包进去了。解码器拿这种框当起点就得花额外的层数去收缩和纠正而解码器层数正是实时方案里最贵的资源。RT-DETR 的做法是同时预测一个 IoU 分数用分类分数和 IoU 分数的组合来排序选出既像目标、又框得准的候选。IoU 分支的监督信号来自预测框与匹配到的真实框之间的重叠度。这样选出来的 300 个查询初始框的定位质量明显更高。这里有个容易被忽略的细节这 300 个查询不是随便给的噪声向量而是承载了编码器阶段的检测结果解码器的角色从从零开始找目标变成了精细修正已有的候选。角色一变对解码器深度的需求就降低了这为后面的层数截断埋了伏笔。2.3 灵活速度调节一次训练多档推理RT-DETR 的解码器是迭代式精修的每一层都会根据上一层的预测更新参考框逐层把框往更准的方向推。这个特性被作者直接拿来当变速器用——推理时你可以只取前 N 层的输出不需要重新训练。道理不复杂。因为初始查询来自编码器的好起点第 3 层、第 4 层的输出虽然精度不如第 6 层但已经是一个合法可用的检测结果。于是你手里就多了一个旋钮同一个权重用 6 层是精度档用 3 层是速度档。论文给出的趋势大致是把解码器从 6 层减到 4 层AP 掉一个点左右帧率涨大约 8% 到 10%减到 3 层AP 掉一个多点帧率涨 15% 左右具体数值请以原论文表格为准我这里的数字是复现手感。对工程侧的意义很大以前要覆盖高算力服务器和低算力边缘盒子两种硬件得训两个模型、维护两套权重现在一套权重加一个配置项就够了验证工作量和版本管理成本都下来了。2.4 三处改动之间的关系把三处改动放到一起看逻辑其实是一条链编码器省钱AIFI 只做一层注意力 卷积做融合→ 省下来的预算给到查询质量IoU-aware 选择→ 查询起点好解码器层数就能减 → 层数能减速度就有了连续调节的余地。每一步都在给下一步创造条件而不是三个独立的小技巧堆在一起。这也是判断一篇论文有没有系统设计感的标准。3. 核心模块的实现细节与算力账3.1 AIFI 只打 S5 的量化理由注意力只放在 S5这句话如果只当成设计偏好是理解不到位的。算一笔账就清楚了。设隐藏维度 d256注意力头数 8640×640 输入作用尺度token 数 NQKV 投影注意力矩阵加权求和FFN1024合计 MACsS5 (20×20)40078.6M41M41M210M约 0.37GS3 (80×80)64001.26G10.5G10.5G3.35G约 25.6G差了将近 70 倍。更狠的是显存注意力矩阵在 S5 上是 400×400单个头 0.64MB到 S3 就是 6400×6400单个头 164MB8 个头全物化出来超过 1.3GB。这还只是一层。RT-DETR-R50 整体在 640 分辨率下的计算量大约一百多 GFLOPsAIFI 那一层占不到 1%。把注意力放到 S3 上编码器直接变成模型里最贵的一块实时性就没法谈了。提示如果你打算把输入分辨率从 640 提到 1280 来救小目标先算清这笔账。token 数变成 4 倍注意力矩阵变成 16 倍AIFI 的显存和时间开销是按平方涨的不是线性。3.2 CCFF 的结构与 RepConv 重参数化CCFF 的数据流可以写成三行伪代码S5 AIFI(S5) F4 Fusion(S4, Upsample(S5)) F3 Fusion(S3, Upsample(F4)) 输出 {F3, F4, S5} 三个尺度给解码器的多尺度可变形注意力每个 Fusion 单元内部有三个部分对两个输入各接一个 1×1 卷积做通道对齐逐元素相加然后过一个 RepConv 做邻域整合。1×1 卷积在这里的作用纯粹是降维和通道统一把两个来源的特征拉到同一个维度上才能相加。RepConv 是这部分的工程亮点。训练时它有三个分支并行一个 3×3 卷积、一个 1×1 卷积、一条恒等映射输出相加。推理时1×1 卷积分支可以通过周围补零的方式等价展开成一个 3×3 卷积恒等映射分支可以表示成中心为 1、其余为 0 的 3×3 卷积三个分支的权重直接相加就合并成一个 3×3 卷积。每个分支后面如果有 BatchNorm也可以折进卷积设卷积权重 W、BN 的缩放 γ、偏移 β、滑动均值 μ、方差 σ折完的权重是 W W · γ/σ偏置是 b β − γμ/σ。这一步做完训练时的多分支结构在推理时变成单分支 3×3没有任何额外开销。注意重参数化只在推理时做训练时必须保留多分支否则等于少了一半模型容量。导出 ONNX 前记得确认已经调用过融合逻辑很多导出后精度掉点的问题都出在这里。3.3 损失函数与监督信号的分工RT-DETR 的匹配和回归沿用 DETR 系的老路子但分类损失做了替换。分类用的是 varifocal loss它对正样本做 IoU 加权、对负样本做不对称衰减好处是让高质量正样本的梯度权重更大符合端到端检测器对定位质量的敏感度。回归用的是 L1 损失加 GIoU 损失的组合匈牙利匹配在输出层完成。引用官方配置的话损失权重大致是分类 1、L1 框回归 5、GIoU 2 这个比例训练时再加上辅助损失对中间层做监督。另外前面说的 IoU-aware 查询选择那个 IoU 分支也需要独立的监督信号用它对匹配到的真实框算出的重叠度作为回归目标。这里有个经验分类损失换成 VFL 之后模型对框的质量更敏感了代价是分数分布不像交叉熵那么平整部署时阈值不要照搬 YOLO 的经验值。我在一个工地安全帽项目里YOLO 时代的阈值是 0.35换到 RT-DETR 上用 0.45 起步才把误检压下去。3.4 训练配置、增广流水线与显存评估论文主体实验在 COCO train2017 上做R50 版本用的是 72 个 epoch 的日程也就是 DETR 系里常说的 6x。优化器是 AdamW主干网络学习率和整体学习率分开设置权重衰减量级在 1e-4训练过程用了指数滑动平均来稳定指标。另外提一句DINO 里那套对比去噪查询的训练技巧RT-DETR 的方案里没有搬过来作者把预算集中花在了编码器和查询选择上这一点从方法章节和官方配置里都能对上。增广流水线基本是 DETR 系近几年的标准配方我按官方配置整理成一份可直接对照的清单train_transforms: - RandomPhotometricDistort: {p: 0.5} - RandomZoomOut: {fill: 0} - RandomIoUCrop: {p: 0.8} - SanitizeBoundingBoxes: {min_size: 1} - RandomHorizontalFlip: {} - Resize: {size: [640, 640]} # 不保持长宽比 - ConvertPILImage: {dtype: float32, scale: true} - Normalize: {mean: [0.485,0.456,0.406], std: [0.229,0.224,0.225]} val_transforms: - Resize: {size: [640, 640]} - ConvertPILImage: {dtype: float32, scale: true} - Normalize: {mean: [0.485,0.456,0.406], std: [0.229,0.224,0.225]}显存评估给个大致手感640×640 输入、批大小 16 的 R50 版本在 8 张 16GB 卡上跑得比较从容单张 24GB 卡上批大小压到 4 到 8 能启动需要配合梯度累积。要注意梯度累积会改变 BatchNorm 的统计行为和 EMA 的更新节奏如果你从小批量起步最好把主干里的 BN 换成同步 BN 或者干脆冻结主干前几层否则前期指标会很难看。按我的经验COCO 全量 72 epoch 在 8 卡上大概要一两天普通团队强烈建议直接拿官方发布的预训练权重做微调而不是从零训。4. 复现路径从环境到推理的完整实操4.1 环境准备与代码结构官方代码开源在 lyuwenyu/RT-DETR 这个仓库里目录结构大致分三块configs 放配置文件engine 放模型与训练引擎deploy 放部署相关的转换和推理代码。这套结构比很多检测仓库清晰模型定义、数据、损失解耦得比较干净二次开发友好。环境按下面这套配基本不会出问题conda create -n rtdetr python3.10 -y conda activate rtdetr pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install -r requirements.txt # 部署侧可选 pip install onnx onnxsim onnxruntime-gpu opencv-python pycocotoolsTensorRT 走官方 DLL 包或者本地编译都行如果要用仓库自带的部署路径还需要 CUDA Toolkit 和 CMake 来编译可变形注意力插件。我的建议是先用 ONNX Runtime 把链路跑通再做 TensorRT 优化别一上来就啃插件。4.2 自定义数据集的配置改法数据组织成 COCO 格式最省事images/train、images/val放图annotations/instances_train.json、instances_val.json放标注。配置文件里几个必须改的字段我列成表配置项说明踩坑提醒num_classes类别数不含背景写错会直接表现为指标极低remap_mscoco_category是否为 COCO 80 类重映射自定义数据集必须设 Falseimg_folder/ann_file数据路径支持相对路径但容易和 include 的基准目录搞混eval_spatial_size评测输入尺寸训练和评测不一致会导致指标虚高或虚低num_queries查询数量默认 300类别少、场景简单时可下调换速度eval_idx用第几层解码器的输出做评测/导出-1 表示最后一层配合层数截断用模型部分的配置结构大致是这样可以直接对着改RTDETR: backbone: ResNet encoder: HybridEncoder decoder: RTDETRTransformer num_classes: 6 num_queries: 300 eval_spatial_size: [640, 640]4.3 训练与微调命令微调一条命令就能起python tools/train.py \ -c configs/rtdetr/rtdetr_r50vd_6x_coco.yml \ -t rtdetr_r50vd_6x_coco.pth \ --seed 0 \ --use-amp \ --output-dir ./output/my_project-t表示载入权重做微调只加载主干和编码器这类可迁移部分如果想完整恢复训练就用-r。具体参数名以你手上那个版本的脚本为准这套仓库更新比较勤参数偶尔会变。微调阶段的几个经验值学习率比预训练时降一个量级整体 1e-5 到 2e-5 起步主干更低。数据量小于 5000 张时把主干前两个 stage 冻住只训后半部分能明显减少过拟合。增广要收着来。COCO 上那套 RandomIoUCrop 在小数据集上很容易把目标裁得只剩半截建议把概率降到 0.3 以下或者直接关掉。类别数少于 10 时num_queries从 300 降到 100 到 150速度有小幅提升精度几乎不动因为一对一匹配本来也不需要那么多查询。4.4 导出 ONNX / TensorRT 与时延实测导出 ONNXpython tools/export_onnx.py \ -c configs/rtdetr/rtdetr_r50vd_6x_coco.yml \ -r output/my_project/best.pth \ --check --simplify \ --opset 16 \ --input-shape 1 3 640 640 \ --output-file rtdetr_r50.onnx这里的--check很关键它会用同一张图跑一遍 PyTorch 和 ONNX对比输出差异。建议每次导出都开能省掉大量上线才发现对不上的时间。转 TensorRTtrtexec --onnxrtdetr_r50.onnx \ --shapesimages:1x3x640x640 \ --fp16 \ --saveEnginertdetr_r50_fp16.engine多尺度可变形注意力在 PyTorch 里导出后通常表现为GridSample算子。新版 TensorRT 对它有支持但性能和兼容性不一定理想仓库的 deploy 目录里提供了自定义插件的实现追求极致速度的话建议编上。另外插件版本和 TensorRT 版本要严格对齐我在这上面浪费过整整一个下午。测时延千万别用 Python 里那种time.time()包住前向的写法CPU 和 GPU 的同步会把测量结果搅得一塌糊涂。用 CUDA 事件配合充分暖机import torch model build_model().cuda().eval().half() x torch.randn(1, 3, 640, 640, devicecuda, dtypetorch.float16) with torch.inference_mode(): for _ in range(30): # 暖机让 cudnn 完成算法选择 model(x) torch.cuda.synchronize() start, end torch.cuda.Event(True), torch.cuda.Event(True) start.record() for _ in range(200): model(x) end.record() torch.cuda.synchronize() print(latency(ms):, start.elapsed_time(end) / 200)如果只测单张记得不要开torch.backends.cudnn.benchmark True之外的额外变量也不要在循环里做任何.cpu()或.item()调用这些都会强制同步测出来的数字能差出好几倍。5. 指标怎么读公平对比与时延口径5.1 精度-速度曲线上的位置论文的核心论据就是那条精度-速度曲线。以 COCO val2017 的 AP 和 T4 上 TensorRT FP16、批大小为 1 的帧率为坐标RT-DETR 的几个规格大致落在这些位置模型骨干AP (COCO val2017)帧率量级 (T4, FP16)是否需 NMSRT-DETR-R50ResNet-50约 53.1约 108否RT-DETR-R101ResNet-101约 54.3约 74否RT-DETR-LHGNetv2-L约 53.0约 114否RT-DETR-XHGNetv2-X约 54.8约 74否YOLOv8-L自研约 52.9约 120是YOLOv8-X自研约 53.9约 70是这些数字我按论文图表和官方配置的手感整理正式引用请回原论文表格核对不同版本的推理栈测出来会有出入。看这张表要抓两点。一是同等精度下RT-DETR 的帧率跟 YOLO 已经在同一档个别规格甚至反超端到端不再必然意味着慢。二是同精度的对比里YOLO 那一侧的数字是含 NMS的口径如果算上 NMS 在密集场景下的长尾延迟实际工程体验上的差距会更大。5.2 NMS 延迟不稳定性的实验设计这部分实验设计得很扎实值得单独说。作者固定模型去扫两个变量图像中的目标数量和置信度阈值然后画后处理耗时曲线。结论有两条目标数量增加时带 NMS 的方案耗时明显上升因为候选框的排序和两两比较本身就是跟数量呈超线性关系的置信度阈值降低时同样如此因为进入 NMS 的框更多。这个结论对部署的意义是如果你的业务场景里目标密度波动很大比如有的画面空无一人有的画面几十个安全帽YOLO 方案的帧率就会跟着波动你需要按最坏情况来规划算力而端到端检测器只要分辨率定死耗时基本恒定算力规划简单得多。5.3 FPS 口径自查清单我见过太多论文说 100 FPS 我的机器只有 30的困惑绝大多数是口径问题。对照下面这张表自查口径项常见差异是否含预处理图像 resize 和归一化放 CPU 还是 GPU差很多是否含后处理含 NMS 的耗时、top-k 和坐标反算的耗时精度模式FP32 / FP16 / INT8差一到两倍批大小批 1 还是批 8吞吐和单张延迟是两个概念推理引擎PyTorch 原生 / ONNX Runtime / TensorRT / 自研加速器硬件型号T4、V100、A100 之间差距很大别混着比暖机与同步是否暖机、是否用 CUDA 事件而非墙钟输入分辨率640 和 1280 不是同一个模型把这张表对齐之后再谈复现差距效率会高很多。6. 常见问题与排查实录6.1 训练侧的高频问题最典型的症状是损失在降、mAP 却低得离谱。这种情况九成是数据层面的问题remap_mscoco_category没关导致你的类别被强行映射到 COCO 的 80 类上或者标注格式写成了cxcywh而数据加载期望xyxy再或者图像 resize 了但标注没跟着变换。我的排查惯例是先写一个可视化脚本把加载后的图和 GT 框画在一起看五秒钟就能定位问题比盯着日志猜快得多。第二个高频问题是比论文低两三个点。这时候要逐项对齐增广流水线是否一致、训练轮数是否够、有没有开 EMA、评测时是否做了同一尺寸的 resize、混合精度下有没有梯度溢出。我遇到过一次就是 AMP 起步阶段梯度爆炸把 loss 打成了 NaN 再恢复模型后半程一直在补课指标自然上不去。解决方式是给 AMP 加梯度裁剪和更长的 warmup。6.2 部署与导出侧的高频问题ONNX 和 PyTorch 输出对不上是最常见的。原因通常是四类可变形注意力对应的GridSample在不同算子集下行为有差异导出时用了动态 shape 但某些分支没适配BatchNorm 没融合导致数值有微小偏移参考点相关的运算在 FP16 下精度不足。我的处理顺序是先用固定的单尺度输入导出并开启--check验证一致性如果 PyTorch 对得上而 ONNX 对不上就逐算子输出中间张量定位确认是GridSample的问题就换算子集或者改用插件最后才考虑把参考点相关的中间量强制保持 FP32。推理结果里冒出一堆重叠框一般是分数阈值太低或者导出时 top-k 的支路被改动了。端到端检测器正常情况下不需要 NMS如果你发现必须加 NMS 才能压住重叠框说明查询选择或者解码器输出被改坏了应该回头查代码而不是加后处理。6.3 常见问题速查表症状大概率原因处理动作mAP 只有个位数类别映射错、标注坐标系错、变换没同步可视化 GT 与图像叠加比论文低 2 至 4 点增广差异、轮数不足、未开 EMA、AMP 溢出逐项对齐官方配置loss 突然 NaN学习率过大、AMP 溢出、异常标注梯度裁剪 拉长 warmup 清洗数据显存爆掉分辨率提升、批大小过大、查询数过多降分辨率优先于降批大小导出后指标掉点BN 未融合、算子集不兼容、FP16 精度开 --check 逐项验证TRT 转换报错缺自定义插件、版本不匹配编译插件并锁定版本帧率远低于论文测法含预处理、未暖机、未量化用 trtexec --benchmark 单测小目标漏检严重640 分辨率不够、低层特征只做融合提分辨率、加 P2 层或换大规格帧率随画面波动残留了 NMS 或类似后处理检查后处理链路7. 落地影响与选型建议7.1 对部署链路和工程侧的影响RT-DETR 这类工作带来的变化不止是多了个能打的模型。第一层影响是部署链路变短了。没有 NMS计算图更干净标准算子更多对各类推理框架和加速器编译器都更友好在多路视频流场景里省下的不只是时间还有排错成本。第二层影响是时延的可预测性前面说过这对闭环控制类应用是刚需。第三层影响是训练侧的心态变化——当端到端不再等于慢团队在选型时就不必默认牺牲一头这一点会慢慢改变整个行业的默认方案。我也观察到后面的一些实时检测工作在往无 NMS 的方向走这说明端到端这条路线的工程价值被验证了不是只有学术意义。7.2 场景选型与微调经验给一张我自己的选型对照表供参考场景特征建议方案边缘盒子、算力很紧RT-DETR-L 640 分辨率 FP16先确认算子支持服务器多路视频流RT-DETR-R50 TensorRT FP16批聚合提吞吐时延敏感的闭环控制优先端到端按需把解码器截断到 4 层密集小目标遥感、PCB提高分辨率或加 P2 融合层慎用极致提速配置追求最高精度R101 或 X 规格配合更大模型做蒸馏已有 YOLO 生产管线迁移重点是预处理对齐和后处理删除成本可控微调上再补两点。一是从小模型蒸馏到大模型的路线在论文里被验证过HGNetv2 的高规格骨干就是靠缩放加蒸馏得到的你在自己业务上也可以拿 X 规格训一个教师模型再蒸一个 L 规格上线精度损失往往比直接训 L 小。二是如果你的数据域跟 COCO 差得远红外、X 光、显微图像预训练权重的迁移收益会下降这时候冻结主干的意义就不大了反而应该放开整网微调但学习率要更保守。7.3 我个人踩过的一些坑最后说几个文档里不会写、但一定会遇到的细节。第一个是评测尺寸。训练用 640、评测偷懒用原图指标会虚高几百个点因为大分辨率下小目标全出来了。反过来训练 640、评测 480指标会明显偏低。定死一个评测尺寸全流程一致。第二个是阈值。RT-DETR 换了分类损失之后分数分布跟交叉熵训出来的模型不一样别照搬 YOLO 的阈值经验。我的做法是在验证集上画一条分数分布曲线把阈值定在正负样本分数分离最明显的那个谷底附近。第三个是层数截断的验证。截断到 4 层之后精度掉点不是均匀的某些类别掉得多、某些几乎不掉。如果有类别的指标是硬性要求就针对这些类别单独验证再决定档位不要只看整体 AP。第四个是插件的版本。自定义算子插件和 TensorRT 版本之间的兼容性很脆升级任何一边之前先把推理结果回归一遍别等上线才发现框全飘了。这套东西用下来我的整体判断是RT-DETR 把端到端检测器从精度优先的学术玩具变成了可以在工程选型里平视 YOLO 的候选方案而且它给出的那套方法论——尺度和任务的解耦、查询质量的显式建模、推理深度的可调——比模型本身更值得借鉴。后面我打算把它的编码器结构搬到分割和关键点任务上试试看看这套混合编码的思路在密集预测任务里是否同样成立。