{"notes":[{"id":"object-detection/rt-detr","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"RT-DETR","subtitle":"NMS 込みで計る","author":"Z. Yuan","paperDate":"2023-04-17","publishedOn":"2025-01-29","world":"external/rt-detr","paperTitle":"DETRs Beat YOLOs on Real-time Object Detection","paperUrl":"https://arxiv.org/abs/2304.08069","bibliography":{"title":"DETRs Beat YOLOs on Real-time Object Detection","authors":["Yian Zhao","Wenyu Lv","Shangliang Xu","Jinman Wei","Guanzhong Wang","Qingqing Dang","Yi Liu","Jie Chen"],"url":"https://arxiv.org/abs/2304.08069","pdfUrl":"https://arxiv.org/pdf/2304.08069v3","codeUrl":"https://github.com/lyuwenyu/RT-DETR","preprint":{"id":"2304.08069","submittedOn":"2023-04-17","url":"https://arxiv.org/abs/2304.08069"},"publication":{"venue":"CVPR","year":2024,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2024/html/Zhao_DETRs_Beat_YOLOs_on_Real-time_Object_Detection_CVPR_2024_paper.html"},"citation":"@misc{objectdetectionrtdetr2023,\n title = {{DETRs Beat YOLOs on Real-time Object Detection}},\n author = {Yian Zhao and Wenyu Lv and Shangliang Xu and Jinman Wei and Guanzhong Wang and Qingqing Dang and Yi Liu and Jie Chen},\n year = {2023},\n eprint = {2304.08069},\n archivePrefix = {arXiv},\n url = {https://arxiv.org/abs/2304.08069}\n}\n","citationPath":"/content/papers/citations/object-detection/rt-detr.cbe42f7a5b6c.bib"},"thumbnail":{"src":"/content/papers/assets/7e2de3c38daff439f51d86ec04a7bd391c3f708b817ae539f3c4df7c5546f4d6.png","width":1360,"height":332},"locale":"ja","path":"/content/papers/ja/object-detection/rt-detr.d3875f64569f.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"nms-にはどれだけ時間がかかるのか","text":"NMS にはどれだけ時間がかかるのか？","depth":3},{"id":"エンドツーエンドのストップウォッチ","text":"エンドツーエンドのストップウォッチ","depth":3},{"id":"detr-はどこが遅いのか","text":"DETR はどこが遅いのか？","depth":3},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"まず全体像を見る","text":"まず全体像を見る","depth":3},{"id":"encoder-の勘定","text":"Encoder の勘定","depth":3},{"id":"aifis5-だけで自己注意","text":"AIFI：S5 だけで自己注意","depth":3},{"id":"ccffスケール間の融合は畳み込みに任せる","text":"CCFF：スケール間の融合は畳み込みに任せる","depth":3},{"id":"300-個のクエリを選ぶ","text":"300 個のクエリを選ぶ","depth":3},{"id":"decoder後ろの数層を外す","text":"Decoder：後ろの数層を外す","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"yolodino-と比べる","text":"YOLO、DINO と比べる","depth":3},{"id":"閾値はどう設定するか","text":"閾値はどう設定するか？","depth":3},{"id":"マシンを替えると","text":"マシンを替えると","depth":3},{"id":"それでも重複ボックスはときどき出る","text":"それでも重複ボックスはときどき出る","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/detr","relation":"referenced","topic":""},{"id":"object-detection/deformable-detr","relation":"referenced","topic":""},{"id":"feature-fusion/panet","relation":"referenced","topic":""}]},{"id":"object-detection/detr","category":"object-detection","legacyPath":"object-detection/2005-detr","legacySlug":"2005-detr","legacyPaths":[],"title":"DETR","subtitle":"跨分野の基盤を築く者","author":"Z. Yuan","paperDate":"2020-05-26","publishedOn":"2024-06-04","paperTitle":"End-to-End Object Detection with Transformers","paperUrl":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php","bibliography":{"title":"End-to-End Object Detection with Transformers","authors":["Nicolas Carion","Francisco Massa","Gabriel Synnaeve","Nicolas Usunier","Alexander Kirillov","Sergey Zagoruyko"],"url":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php","pdfUrl":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/papers/123460205.pdf","codeUrl":"https://github.com/facebookresearch/detr","preprint":{"id":"2005.12872","submittedOn":"2020-05-26","url":"https://arxiv.org/abs/2005.12872"},"publication":{"venue":"ECCV","year":2020,"kind":"conference","url":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php"},"citation":"@misc{objectdetectiondetr2020,\n title = {{End-to-End Object Detection with Transformers}},\n author = {Nicolas Carion and Francisco Massa and Gabriel Synnaeve and Nicolas Usunier and Alexander Kirillov and Sergey Zagoruyko},\n year = {2020},\n eprint = {2005.12872},\n archivePrefix = {arXiv},\n url = {https://arxiv.org/abs/2005.12872}\n}\n","citationPath":"/content/papers/citations/object-detection/detr.5258ffe0b9a0.bib"},"thumbnail":{"src":"/content/papers/assets/dd7e8441e6460ff562cf558374789924518fafaed7ecde0e3e35ee778c316330.jpg","width":1024,"height":266},"locale":"ja","path":"/content/papers/ja/object-detection/detr.5e84d1db3678.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"解決策","text":"解決策","depth":2},{"id":"モデル構造","text":"モデル構造","depth":3},{"id":"損失設計","text":"損失設計","depth":3},{"id":"データセット","text":"データセット","depth":3},{"id":"技術的詳細","text":"技術的詳細","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"これでいいのか","text":"これでいいのか？","depth":3},{"id":"モデル構成要素の解析","text":"モデル構成要素の解析","depth":3},{"id":"モデル挙動分析","text":"モデル挙動分析","depth":3},{"id":"未知物体数に対する一般化能力","text":"未知物体数に対する一般化能力","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{"問題の解決":"解決策","画像から物体の集合へ":"モデル構造","まず対応付け次に損失を計算":"損失設計","実験結果の検討":"討論","これでいけるまず条件を確認":"これでいいのか","どの部品が効いている":"モデル構成要素の解析","query-は何を学んだ":"モデル挙動分析"},"guide":null,"relatedReading":[{"id":"object-detection/deformable-detr","relation":"next","topic":"集合予測と Attention による検出"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"Transformer 検出器の収束を速める"}]},{"id":"object-detection/deformable-detr","category":"object-detection","legacyPath":"object-detection/2010-deformable-detr","legacySlug":"2010-deformable-detr","legacyPaths":[],"title":"Deformable DETR","subtitle":"可変形な注意力メカニズム","author":"Z. Yuan","paperDate":"2020-10-08","publishedOn":"2024-09-20","paperTitle":"Deformable DETR: Deformable Transformers for End-to-End Object Detection","paperUrl":"https://arxiv.org/abs/2010.04159","bibliography":{"title":"Deformable DETR: Deformable Transformers for End-to-End Object Detection","authors":["Xizhou Zhu","Weijie Su","Lewei Lu","Bin Li","Xiaogang Wang","Jifeng Dai"],"url":"https://arxiv.org/abs/2010.04159","pdfUrl":"https://arxiv.org/pdf/2010.04159","codeUrl":null,"preprint":{"id":"2010.04159","submittedOn":"2020-10-08","url":"https://arxiv.org/abs/2010.04159"},"publication":{"venue":"ICLR","year":2021,"kind":"conference","url":"https://arxiv.org/abs/2010.04159"},"citation":"@misc{objectdetectiondeformabledetr2020,\n title = {{Deformable DETR: Deformable Transformers for End-to-End Object Detection}},\n author = {Xizhou Zhu and Weijie Su and Lewei Lu and Bin Li and Xiaogang Wang and Jifeng Dai},\n year = {2020},\n eprint = {2010.04159},\n archivePrefix = {arXiv},\n url = {https://arxiv.org/abs/2010.04159}\n}\n","citationPath":"/content/papers/citations/object-detection/deformable-detr.df721a30472e.bib"},"thumbnail":{"src":"/content/papers/assets/36edfc5595a85c73fcdc9a4bbb9e1ca512e1f100676eb7c37203d71c84905c05.jpg","width":1224,"height":752},"locale":"ja","path":"/content/papers/ja/object-detection/deformable-detr.357715629c52.md","headings":[{"id":"問題定義","text":"問題定義","depth":2},{"id":"問題解決","text":"問題解決","depth":2},{"id":"変形可能注意機構","text":"変形可能注意機構","depth":3},{"id":"マルチスケール計算","text":"マルチスケール計算","depth":3},{"id":"モデル構造","text":"モデル構造","depth":3},{"id":"コード解析","text":"コード解析","depth":3},{"id":"トレーニング戦略","text":"トレーニング戦略","depth":3},{"id":"議論","text":"議論","depth":2},{"id":"detr-との比較","text":"DETR との比較","depth":3},{"id":"アブレーション実験","text":"アブレーション実験","depth":3},{"id":"sota-との比較","text":"SOTA との比較","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/detr","relation":"background","topic":"集合予測と Attention による検出"},{"id":"object-detection/h-detr","relation":"next","topic":"集合予測と Attention による検出"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"Transformer 検出器の収束を速める"}]},{"id":"feature-fusion/panet","category":"feature-fusion","legacyPath":"feature-fusion/1803-panet","legacySlug":"1803-panet","legacyPaths":[],"title":"PANet","subtitle":"私にショートカットをくれ","author":"Z. Yuan","paperDate":"2018-03-05","publishedOn":"2024-04-06","paperTitle":"Path Aggregation Network for Instance Segmentation","paperUrl":"https://arxiv.org/abs/1803.01534","bibliography":{"title":"Path Aggregation Network for Instance Segmentation","authors":["Shu Liu","Lu Qi","Haifang Qin","Jianping Shi","Jiaya Jia"],"url":"https://arxiv.org/abs/1803.01534","pdfUrl":"https://arxiv.org/pdf/1803.01534","codeUrl":null,"preprint":{"id":"1803.01534","submittedOn":"2018-03-05","url":"https://arxiv.org/abs/1803.01534"},"publication":{"venue":"CVPR","year":2018,"kind":"conference","url":"https://arxiv.org/abs/1803.01534"},"citation":"@misc{featurefusionpanet2018,\n title = {{Path Aggregation Network for Instance Segmentation}},\n author = {Shu Liu and Lu Qi and Haifang Qin and Jianping Shi and Jiaya Jia},\n year = {2018},\n eprint = {1803.01534},\n archivePrefix = {arXiv},\n url = {https://arxiv.org/abs/1803.01534}\n}\n","citationPath":"/content/papers/citations/feature-fusion/panet.31d49af45ee9.bib"},"thumbnail":{"src":"/content/papers/assets/549012fa5498c4bbe44cfad4f4c54ed4eac5e7f0cdc71ae6308bb1ee6a4942ed.jpg","width":1024,"height":348},"locale":"ja","path":"/content/papers/ja/feature-fusion/panet.e2f12791cb54.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"解決策","text":"解決策","depth":2},{"id":"panet-モデル設計","text":"PANet モデル設計","depth":3},{"id":"パス集約ネットワークpath-aggregation-fpn","text":"パス集約ネットワーク（Path Aggregation FPN）","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"基本的な-fpn-と比べてどうか","text":"基本的な FPN と比べてどうか？","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"feature-fusion/fpn","relation":"background","topic":"検出のためのマルチスケール特徴融合"},{"id":"feature-fusion/bifpn","relation":"next","topic":"検出のためのマルチスケール特徴融合"}]}],"text":"2023年4月、Baidu と北京大学の著者らが arXiv に論文を投稿しました。タイトルには DETRs Beat YOLOs、つまりリアルタイム物体検出で DETR が YOLO に勝った、と書かれていました。\n\n提案されたモデルは RT-DETR（Real-Time DEtection TRansformer）といいます。640×640 の写真を読み込み、300 個の予測を出力します。各予測はボックス1つ、クラス1つ、スコア1つからなり、使うときはスコアの閾値で低スコアのボックスを落とすだけでよく、後ろに NMS をつなぐ必要はありません。狙っているのは YOLO の仕事で、論文の冒頭に挙げられている物体追跡、映像監視、自動運転のように、1秒に数十枚の画像を処理しなければならない場面です。この論文はのちに CVPR 2024 で発表されました。\n\n当時、このタイトルはかなり大胆でした。この論文の Table 2 で最も精度の高い DETR は DINO で、ResNet-50 版は COCO で 50.9 AP ありますが、T4 GPU では1秒に5枚しか処理できません（入力 800×1333）。YOLO の大型モデルも COCO で同じく 52、53 AP あり、速度は1秒に数十枚以上です。\n\nDETR が勝ったと言うには、まず YOLO の速度をどう測るかを決めておく必要があります。YOLO の出力は NMS を通さないと使えず、NMS の時間を含めるか、どの閾値で測るかによって、得られる速度は大きく変わります。この論文はまず NMS をストップウォッチの計測範囲に戻し、それから DETR のどこが遅いのかを分解していきます。\n\n## 問題の定義\n\n### NMS にはどれだけ時間がかかるのか？\n\nYOLO は特徴マップの各位置でボックスを予測します。640×640 の入力なら、YOLOv8 はストライド 8、16、32 の3層の特徴マップに合計 80×80＋40×40＋20×20＝8,400 個の位置を持ち、位置ごとにボックスは1つです。YOLOv5 は各位置に3つのアンカーを置くので 25,200 個になります。同じ物体の近くにある複数の位置がそれぞれボックスを出すため、NMS（non-maximum suppression、非極大値抑制）で重複したボックスを取り除く必要があります。\n\nNMS には2つの閾値があります。まず信頼度の閾値で、スコアの低すぎるボックスを削除します。次にクラスごとに、スコアが最も高いボックスを残し、それとの IoU が閾値を超えるボックスを削除して、残ったボックスに同じことを繰り返します。IoU は2つのボックスの共通部分の面積を、和集合の面積で割った値です。\n\nそのため、NMS の仕事量は、信頼度の閾値を通過するボックスの数で決まります。著者らは同じ入力を使い、信頼度の閾値ごとに YOLOv5 と YOLOv8 のボックスがいくつ残るかを数えました。横軸は信頼度の閾値、縦軸はボックス数で、青はアンカーベースの YOLOv5、オレンジはアンカーフリーの YOLOv8 です：\n\n[](/content/papers/assets/3ce51df5cdcf3f7995e63085f9c6925d29364b00decdae24bb9a6f2b628bacb1.png)\n\n*原論文 Figure 2（Zhao et al.）。[**v3 PDF の3ページ**](https://arxiv.org/pdf/2304.08069v3#page=3)から抜粋。同じ入力に対して、信頼度の閾値ごとに残ったボックスの数です。*\n\n信頼度の閾値が 0.001 のとき、YOLOv5 には9千個あまり、YOLOv8 には3千個あまりのボックスが残ります。閾値を 0.25 まで上げると、どちらも数百個しか残りません。どの閾値でも、YOLOv5 のボックスは YOLOv8 より多くなっています。\n\n続いて著者らは、COCO val2017 で YOLOv8 の AP と NMS の実行時間を測りました。NMS には TensorRT の efficientNMSPlugin を使い、T4 GPU、TensorRT FP16 で実行しています：\n\n| 信頼度の閾値 | IoU 閾値 | AP | NMS 時間（ms） |\n| ---: | ---: | ---: | ---: |\n| 0.001 | 0.5 | 52.1 | 2.24 |\n| 0.001 | 0.6 | 52.6 | 2.29 |\n| 0.001 | 0.7 | 52.9 | 2.36 |\n| 0.001 | 0.8 | 52.8 | 2.46 |\n| 0.01 | 0.7 | 52.4 | 1.73 |\n| 0.05 | 0.7 | 51.2 | 1.06 |\n\n*表：原論文 Table 1 をもとに整理。原表は信頼度の閾値を固定した半分と、IoU 閾値を固定した半分に分かれていますが、ここでは1つの表にまとめました。表には YOLOv8 のサイズが書かれていませんが、52.9 AP は Table 2 の YOLOv8-L と同じです。*\n\nまず上の4行を見ます。信頼度の閾値を 0.001 に固定し、IoU 閾値を 0.5 から 0.8 に上げると、NMS 時間は 2.24 から 2.46 ms に増えます。IoU 閾値が高いほど1ラウンドで削除されるボックスが少なくなり、回すラウンド数が増えるからです。AP は 0.7 のときが最も高くなっています。\n\n次に、IoU 閾値を 0.7 に固定した3行です。信頼度の閾値を 0.001 から 0.05 に上げると、NMS 時間は 2.36 から 1.06 ms に下がり、半分以上短くなります。一方、AP は 52.9 から 51.2 に落ちます。\n\n最高の 52.9 AP は信頼度 0.001、IoU 0.7 で得られ、この設定の NMS 時間は表の中で2番目に長いものです。YOLO がこの AP を得たいなら、この時間を払わなければなりません。時間を節約したいなら、AP を少し譲ることになります。\n\n表の時間は、まだ一部しか数えていません。efficientNMSPlugin の中には EfficientNMSFilter、RadixSort、EfficientNMS など複数の kernel があり、Table 1 に載っているのは EfficientNMS の1つだけです。\n\n付録には、いくつかの閾値の組み合わせでの YOLOv8-L の予測も描かれています。信頼度の閾値が低すぎると、画面に余分なボックスが大量に現れます。IoU 閾値を低くすると、重なり合って互いを隠している物体が重複ボックスとして削除され、高くすると、重なった重複ボックスが残ってしまいます。著者らは、信頼度の閾値はまだ調整しやすいものの、IoU 閾値を正確に設定するのは難しいと考えています。\n\nところが YOLO が速度を報告するときは、ふつうモデル本体だけを測り、NMS を含めません（§3.1）。速度の表には NMS が入っていないのに、AP は NMS をつなぎ、とても低い信頼度の閾値で計算したものです。\n\n### エンドツーエンドのストップウォッチ\n\nそこで著者らは、エンドツーエンドの計測方法を定めました（§3.2）：\n\n- データには COCO val2017 を使い、1枚ずつ測って平均を取ります。NMS の時間は入力によって変わるからです。\n- YOLO の後ろに TensorRT の NMS プラグインをつなぎ、閾値は各モデルが報告 AP を得たときの設定を使います。公式の速度計測スクリプトにおける YOLOv8 のデフォルトは、信頼度 0.001、IoU 0.7、最大出力 300 ボックスです。\n- I/O とメモリコピーは含めず、T4 GPU、TensorRT FP16 で測ります。\n\nこのストップウォッチで測った結果、精度が同程度なら、アンカーフリーの YOLO のほうがアンカーベースのものより速いことがわかりました。後者は出力するボックスが多く、NMS により多くの時間がかかるからです。測定したモデルでは、アンカーベースのボックス数はアンカーフリーの3倍で、先ほど計算した 25,200 対 8,400 と一致します。\n\n### DETR はどこが遅いのか？\n\nDETR には NMS がないので、この時間はもともとかかりません。問題はモデル本体にあります。\n\n\n> [!TIP]\n> \n> DETR を読んだことがなければ、少し背景を補っておきます。DETR は Transformer で物体検出を行い、固定数のクエリ（query）を用意して、各クエリがボックス1つとクラス1つを出力します。学習時はハンガリアン法で予測とアノテーションを一対一にマッチングするので、1つの物体を担当するクエリは1つだけになり、推論時に NMS は必要ありません。その後の Deformable DETR はマルチスケール特徴を encoder に入れ、アテンションが少数のサンプリング点だけを見るように変えたことで、収束がずっと速くなりました。2本とも本サイトのノートを参照してください：\n> \n> - **[[20.05] DETR：跨分野の基盤を築く者](/blog/papers/object-detection/detr)**\n> - **[[20.10] Deformable DETR：可変形な注意力メカニズム](/blog/papers/object-detection/deformable-detr)**\n\n\nマルチスケール特徴によって DETR の収束は速くなり、精度も上がりますが、その代わり encoder が処理する系列が一気に長くなります。可変形アテンションで計算量はすでに減っているものの、encoder は依然として計算のボトルネックです。著者らが引用する D²ETR の分析では、Deformable DETR の encoder は GFLOPs の 49% を占めるのに、AP への寄与は 11% しかありません。\n\nでは、encoder をどう削ればよいのでしょうか？丸ごと取り除いたら、精度はどれだけ落ちるのか？一部だけ残すなら、どの部分を残すべきか？\n\n## 問題の解決\n\n### まず全体像を見る\n\nRT-DETR はバックボーン、ハイブリッド encoder、decoder の3つの部分からなります。バックボーンは最後の3つの stage の特徴 $S_3$、$S_4$、$S_5$ を取り出し、ハイブリッド encoder がそれらを一続きの画像特徴に整理します。クエリ選択はその中から固定数の特徴を選んでクエリの出発点とし、decoder がそのクエリを1層ずつ修正して、クラスとボックスを出力します。\n\n640×640 の画像を1枚例にとり、各段階のサイズを図にしてみました：\n\n[](/content/papers/assets/be7c554f6906b5d986546dacca808a2c022430faa695b767c5d0e577210ff15a.png)\n\n*図：本稿で作図。ResNet-50 バックボーン、640×640 入力の場合です。decoder が4層目で止まるのは一例です。*\n\nここからはこの図に沿って、encoder から decoder まで順に見ていきます。\n\n### Encoder の勘定\n\nまず、3層の特徴にそれぞれいくつの位置があるかを計算します。平坦化すると、1つの位置が1つのトークンになります：\n\n```python\nH = W = 640\nstrides = {\"S3\": 8, \"S4\": 16, \"S5\": 32}\ntokens = {k: (H // s) * (W // s) for k, s in strides.items()}\ntotal = sum(tokens.values())\n\nfor k, n in tokens.items():\n side = H // strides[k]\n print(f\"{k}: {side}×{side} = {n} トークン、全体の {n / total:.0%}、総当たりで {n * n / 1e6:.2f}M ペア\")\nprint(\"3層の合計\", total, \"トークン\")\n\npairs_each = sum(n * n for n in tokens.values())\npairs_s5 = tokens[\"S5\"] ** 2\nprint(f\"3層それぞれで自己注意：{pairs_each / 1e6:.2f}M ペア、S5 だけ：{pairs_s5 / 1e6:.2f}M ペア、差は {pairs_each / pairs_s5:.0f} 倍\")\n```\n\n```text\nS3: 80×80 = 6400 トークン、全体の 76%、総当たりで 40.96M ペア\nS4: 40×40 = 1600 トークン、全体の 19%、総当たりで 2.56M ペア\nS5: 20×20 = 400 トークン、全体の 5%、総当たりで 0.16M ペア\n3層の合計 8400 トークン\n3層それぞれで自己注意：43.68M ペア、S5 だけ：0.16M ペア、差は 273 倍\n```\n\nS3 の1層だけでトークンの 76% を占めます。通常の自己注意では各トークンを同じ層のすべてのトークンと組み合わせるので、S3 の1層だけで4千万ペアあまりになります。S5 だけなら 16 万ペアで済みます。\n\n著者らは、encoder のバリエーションを並べてこの勘定を確かめています。図の左から右へ A から E の5種類の encoder が並び、各マスの下の3本の矢印は3層の特徴を表します。SSE は単一スケールの Transformer encoder、MSE はマルチスケールの Transformer encoder、CSF はクロススケール融合です：\n\n[](/content/papers/assets/7e2de3c38daff439f51d86ec04a7bd391c3f708b817ae539f3c4df7c5546f4d6.png)\n\n*原論文 Figure 3（Zhao et al.）。[**v3 PDF の4ページ**](https://arxiv.org/pdf/2304.08069v3#page=4)から抜粋。5種類の encoder バリエーションの構造です。*\n\nどのバリエーションも DINO-Deformable-R50 をベースに、RT-DETR の軽量なデータ読み込みと decoder に置き換え、12 エポック学習しています。表には $\\mathrm{D}_{S_5}$ という行が1つ増えています。構造は D と同じで、SSE が S5 だけを処理します：\n\n| バリエーション | encoder の構成 | AP | パラメータ（M） | 遅延（ms） |\n| --- | --- | ---: | ---: | ---: |\n| A | encoder を外し、3層をそのまま連結 | 43.0 | 31 | 7.2 |\n| B | 3層で単一スケールの Transformer を1層共有し、それぞれ層内の相互作用を行ってから連結 | 44.9 | 32 | 11.1 |\n| C | B の結果を連結し、マルチスケールの Transformer encoder に入れる | 45.6 | 32 | 13.3 |\n| D | 層内の相互作用は単一スケールの Transformer に、層間の融合は PANet 型の構造に任せる | 46.4 | 35 | 12.2 |\n| $\\mathrm{D}_{S_5}$ | D と同じだが、層内の相互作用は S5 だけ | 46.8 | 35 | 7.9 |\n| E | AIFI＋CCFF、つまり RT-DETR の構成 | 47.9 | 42 | 9.3 |\n\n*表：原論文 Table 3。「encoder の構成」の列は §4.2 をもとに整理。*\n\n1行ずつ下へ見ていきます：\n\n1. **A → B**：AP が 1.9 上がり、遅延は 54% 増えます。層内の相互作用は効果がありますが、すべての層で自己注意を行うのはとても高くつきます。\n2. **B → C**：AP がさらに 0.7 上がり、遅延もさらに 20% 増えます。スケール間の相互作用も効果がありますが、マルチスケール encoder はもっと高くつきます。\n3. **C → D**：層内の相互作用と層間の融合を分けると、AP が 0.8 上がり、遅延はむしろ 8% 減ります。\n4. **D → $\\mathrm{D}_{S_5}$**：S5 の自己注意だけを残すと、遅延は 12.2 から 7.9 ms へ 35% 減り、AP はさらに 0.4 上がります。\n5. **D → E**：AIFI と CCFF に替えると、AP が 1.5 上がり、パラメータは 20% 増え、遅延は 24% 減ります。\n\n4番目のステップでは S3、S4 の自己注意、つまり先ほど計算した4千万ペアあまりの組み合わせを外し、遅延が 4.3 ms 減りました。最後の E を encoder がまったくない A と比べると、遅延は 2.1 ms しか増えず、AP は 4.9 高くなっています。\n\nなぜ S5 だけを残すのでしょうか？著者らの考えでは、高レベルの特徴は物体の意味情報を持っていて、この層で自己注意を行うと、画面内の異なる物体や概念の間の関係をとらえ、後段のモジュールによる位置特定と認識を助けられます。低レベルの特徴は意味情報に乏しく、そこで層内の相互作用を行うのは冗長で、高レベルの相互作用と重複したり混同したりするおそれもあります。$\\mathrm{D}_{S_5}$ の行はこの説明を裏づけていて、計算をこれだけ省いても AP は 0.4 高くなりました。\n\n### AIFI：S5 だけで自己注意\n\n論文はハイブリッド encoder を3行で書いています：\n\n$$\n\\begin{aligned}\n\\mathcal{Q} = \\mathcal{K} = \\mathcal{V} &= \\mathrm{Flatten}(S_5) \\\\\nF_5 &= \\mathrm{Reshape}(\\mathrm{AIFI}(\\mathcal{Q}, \\mathcal{K}, \\mathcal{V})) \\\\\n\\mathcal{O} &= \\mathrm{CCFF}(\\{S_3, S_4, F_5\\})\n\\end{aligned}\n$$\n\nAIFI は標準的な Transformer encoder の1層そのものです。S5 を平坦化して系列にし、Q、K、V はすべてそこから取ります。自己注意とフィードフォワードネットワークを通したら、20×20 の形に戻します。同じ画像をこのまま先へ進めましょう。バックボーンの出力はひとまず乱数で代用します：\n\n```python\nimport torch\nimport torch.nn as nn\nimport torch.nn.functional as F\n\ntorch.manual_seed(0)\n# ResNet-50 の最後の3つの stage の出力。ここでは乱数で代用する\nS3 = torch.randn(1, 512, 80, 80)\nS4 = torch.randn(1, 1024, 40, 40)\nS5 = torch.randn(1, 2048, 20, 20)\n\n# まず 1×1 畳み込みで、3層とも 256 チャネルにそろえる\nproj = nn.ModuleList(nn.Conv2d(c, 256, 1) for c in (512, 1024, 2048))\nS3, S4, S5 = (p(x) for p, x in zip(proj, (S3, S4, S5)))\n\n# AIFI：S5 だけを系列に平坦化し、Transformer encoder を1層通す\naifi = nn.TransformerEncoderLayer(d_model=256, nhead=8, dim_feedforward=1024, batch_first=True)\nseq = S5.flatten(2).transpose(1, 2)\nF5 = aifi(seq).transpose(1, 2).reshape(1, 256, 20, 20)\nprint(\"AIFI の入力\", tuple(seq.shape), \"→ F5\", tuple(F5.shape))\n```\n\n```text\nAIFI の入力 (1, 400, 256) → F5 (1, 256, 20, 20)\n```\n\nここでのサイズは付録 Table A に従い、埋め込み次元 256、ヘッド数 8、フィードフォワード層 1024 で、層は1つだけです。公式コードでは Q、K に 2D の sin-cos 位置エンコーディングも加えていますが、デモでは省略しました。\n\n### CCFF：スケール間の融合は畳み込みに任せる\n\nCCFF は PANet の路線を踏襲し、まずトップダウン、次にボトムアップに進んで、各ステップで隣り合う2層の特徴を融合して新しい層を作ります。融合ブロック（Figure 5）は隣り合う2層の特徴を連結し、2系統に分けてそれぞれ 1×1 畳み込みを通します。片方の系統にはさらに N 個の RepBlock をつなぎ、最後に2系統を要素ごとに足し合わせます。RT-DETR では N＝3 です。\n\nRepBlock は RepConv でできています。RepVGG のように、学習時は多分岐で、推論時に1つの 3×3 畳み込みへまとめる設計です。以下のデモでは通常の 3×3 畳み込みで代用し、BN、SiLU、そして公式コードが拡大の前に行う 1×1 畳み込みも省略しています：\n\n```python\nclass Fusion(nn.Module):\n \"\"\"Figure 5 の融合ブロック：2系統の 1×1 畳み込み。片方にはさらに N 個の畳み込みブロックをつなぎ、最後に要素ごとに足す\"\"\"\n def __init__(self, n=3):\n super().__init__()\n self.a = nn.Conv2d(512, 256, 1)\n self.b = nn.Conv2d(512, 256, 1)\n self.blocks = nn.Sequential(*[nn.Conv2d(256, 256, 3, padding=1) for _ in range(n)])\n\n def forward(self, x, y):\n z = torch.cat([x, y], dim=1) # 隣り合う2つのスケール。チャネルは 256 + 256\n return self.a(z) + self.blocks(self.b(z))\n\nup = lambda x: F.interpolate(x, scale_factor=2, mode=\"nearest\")\ndown = nn.ModuleList(nn.Conv2d(256, 256, 3, stride=2, padding=1) for _ in range(2))\nfuse = nn.ModuleList(Fusion() for _ in range(4))\n\n# トップダウン：F5 を2倍に拡大して S4 と融合し、さらに拡大して S3 と融合\nT4 = fuse[0](up(F5), S4)\nT3 = fuse[1](up(T4), S3)\n# ボトムアップ：再び縮小し、T4、F5 と順に融合\nB4 = fuse[2](down[0](T3), T4)\nB5 = fuse[3](down[1](B4), F5)\nfor name, x in [(\"T3\", T3), (\"B4\", B4), (\"B5\", B5)]:\n print(name, tuple(x.shape))\n\nmemory = torch.cat([x.flatten(2) for x in (T3, B4, B5)], dim=2).transpose(1, 2)\nprint(\"エンコーダの出力\", tuple(memory.shape))\n```\n\n```text\nT3 (1, 256, 80, 80)\nB4 (1, 256, 40, 40)\nB5 (1, 256, 20, 20)\nエンコーダの出力 (1, 8400, 256)\n```\n\nT3、B4、B5 はデモでつけた名前で、論文は途中の結果に名前をつけていません。出力はやはり3層で、サイズは入力と同じ、チャネルはすべて 256 です。平坦化して連結すると、8,400 個の特徴の列になります。\n\nこの数は先ほどの YOLOv8 の 8,400 個のボックスと同じです。どちらもストライド 8、16、32 の3層のグリッドで予測しているからです。ここから両者は道が分かれます。YOLO は各位置のボックスをすべて NMS に渡し、RT-DETR はその中から 300 個だけを選んで decoder に渡します。\n\n\n> [!TIP]\n> \n> CCFF の2つの経路と RepBlock には、それぞれ由来があります。本サイトのノートを参照してください：\n> \n> - **[[18.03] PANet：私にショートカットをくれ](/blog/papers/feature-fusion/panet)**\n> - **[[21.01] RepVGG：VGG を再び偉大に](/blog/papers/reparameterization/repvgg)**\n\n\n### 300 個のクエリを選ぶ\n\nDETR の元のクエリは学習可能なベクトルの集まりで、入力画像とは無関係なため、最適化が困難でした。その後の手法では、encoder の出力から選ぶようになります。Deformable DETR の2段階版と DINO は、どちらも分類スコアの上位 K 個の特徴を選んでクエリを初期化します（DINO はそれを位置クエリとしてだけ使います）。RT-DETR は K＝300 とし、選んだ特徴を内容クエリに、それらが予測したボックスを位置クエリの出発点にします。\n\n上の例の続きです：\n\n```python\nscore_head = nn.Linear(256, 80) # COCO の 80 クラス\nbox_head = nn.Linear(256, 4)\n\nlogits = score_head(memory) # 各位置の 80 クラスに対するスコア\ntop_score, top_idx = logits.max(-1).values.topk(300, dim=1)\nidx = top_idx[..., None]\ncontent = memory.gather(1, idx.expand(-1, -1, 256)) # 内容クエリ\ninit_box = box_head(memory).sigmoid().gather(1, idx.expand(-1, -1, 4)) # 初期ボックス\nprint(\"スコア\", tuple(logits.shape), \"→ 選択\", tuple(content.shape), \"と\", tuple(init_box.shape))\n```\n\n```text\nスコア (1, 8400, 80) → 選択 (1, 300, 256) と (1, 300, 4)\n```\n\nデモの2つの予測ヘッドはどちらもランダムな重みです。公式コードでは予測ヘッドの前に線形変換と LayerNorm がもう1層あり、ボックスの予測には各位置のアンカーも加わります。選択そのものは、ただの topk です。\n\n問題は選択の基準にあります。分類スコアが高いことは、その位置に物体がありそうだという手がかりになりますが、予測したボックスが正確だという保証はありません。検出器はクラスを正しく分類し、ボックスを正しい位置に置く必要があります。分類スコアだけを見ると、位置特定の不正確な特徴も選ばれてしまい、decoder は悪い出発点から修正を始めなければなりません。\n\n著者らはこのずれを不確かさと呼び、位置特定と分類という2つの予測分布の差として定義したうえで、分類損失に組み込んで一緒に最小化します：\n\n$$\n\\mathcal{U}(\\hat{\\mathcal{X}}) = \\lVert \\mathcal{P}(\\hat{\\mathcal{X}}) - \\mathcal{C}(\\hat{\\mathcal{X}}) \\rVert, \\quad \\hat{\\mathcal{X}} \\in \\mathbb{R}^D\n$$\n\n$$\n\\mathcal{L}(\\hat{\\mathcal{X}}, \\hat{\\mathcal{Y}}, \\mathcal{Y}) = \\mathcal{L}_{box}(\\hat{\\mathbf{b}}, \\mathbf{b}) + \\mathcal{L}_{cls}(\\mathcal{U}(\\hat{\\mathcal{X}}), \\hat{\\mathbf{c}}, \\mathbf{c})\n$$\n\nここで $\\hat{\\mathcal{X}}$ は encoder の特徴、$\\hat{\\mathbf{c}}$、$\\hat{\\mathbf{b}}$ は予測されたクラスとボックス、$\\mathbf{c}$、$\\mathbf{b}$ はアノテーションです。\n\n式はかなり抽象的ですが、公式コードのやり方はずっと具体的です。分類スコアの学習には Varifocal loss を使います。ある予測がハンガリアンマッチングでアノテーションに割り当てられた場合、そのクラスでの学習目標を 1 から、そのボックスとアノテーションのボックスの IoU に変えます。割り当てられなかった予測の目標は 0 です。選ばれた3つの特徴を例にします：\n\n| 特徴 | マッチしたアノテーション | 予測ボックスとアノテーションの IoU | 通常の分類目標 | RT-DETR の分類目標 |\n| --- | --- | ---: | ---: | ---: |\n| 甲 | 犬 | 0.45 | 1 | 0.45 |\n| 乙 | 猫 | 0.90 | 1 | 0.90 |\n| 丙 | マッチなし | — | 0 | 0 |\n\n*表：本稿による例示。*\n\n甲のボックスは犬と 0.45 しか重なっていないので、分類スコアは 0.45 へ引き寄せられ、以前のように 1 へ押し上げられることはありません。分類スコアがボックスの品質を反映するように学習されるので、スコアで選んだ上位 300 個は、ボックスも正確な特徴に偏るようになります。この損失は、encoder が選んだ 300 個の予測と、decoder の各層の出力の両方に使われます。\n\n\n> [!TIP]\n> \n> 公式コードの中で uncertainty-minimal という名前を探しても見つかりません。2024年8月にはすでに GitHub で質問した人がいて、別のユーザーが、それは損失関数 `loss_labels_vfl` の中に書かれていると指摘しています（[RT-DETR #438](https://github.com/lyuwenyu/RT-DETR/issues/438)）。論文の v1 ではこの設計を IoU-aware query selection と呼んでいて、こちらの名前のほうがコードの書き方に近いです。\n\n\n効果はどうでしょうか？著者らは COCO val2017 で、2つの選び方で選ばれた特徴を散布図にしました。横軸はボックスとアノテーションの IoU、縦軸は分類スコアで、分類スコアが 0.5 を超える点だけを描いています。紫は新しい選び方、緑は従来の分類スコアによる選び方で、上と右の曲線は点の密度です：\n\n[](/content/papers/assets/420e753b3717e561d473e69a1066095c23584488dab765ae7acee273b91819f8.png)\n\n*原論文 Figure 6（Zhao et al.）。[**v3 PDF の6ページ**](https://arxiv.org/pdf/2304.08069v3#page=6)から抜粋。2種類のクエリ選択で選ばれた encoder 特徴の、分類スコアと IoU です。*\n\n右上に近い点ほど、クラスもボックスも正しい可能性が高くなります。紫の点は右上に大量に集まっています。緑の点は右下に集まっていて、ボックスは悪くないのに分類スコアが低めで、数もずっと少なくなっています。Table 4 はこれを割合で測っています（RT-DETR-R50、12 エポック学習）：\n\n| クエリ選択 | AP | 分類スコア > 0.5 の割合 | 両方とも > 0.5 の割合 |\n| --- | ---: | ---: | ---: |\n| 分類スコアで選択（従来） | 47.9 | 0.35% | 0.30% |\n| uncertainty-minimal | 48.7 | 0.82% | 0.67% |\n\n*表：原論文 Table 4。*\n\nどちらの割合も2倍以上になり、AP は 0.8 上がりました。\n\n### Decoder：後ろの数層を外す\n\nRT-DETR の decoder はほぼ DINO そのままで、6層、300 個のクエリ、cross-attention には可変形アテンションを使い、サンプリング点数は4です。学習時には DINO のデノイジング学習も引き継いでいて、付録 Table A に載っているデノイジングの数は 200 です。\n\n\n> [!TIP]\n> \n> デノイジング学習では、ノイズを加えたアノテーションのボックスを追加のクエリとして decoder に入れ、元のボックスに戻すようモデルに学ばせます。推論時には丸ごと外します。公式の設定ファイルには `num_denoising: 100` と書かれていますが、コードは各グループを正と負の2つずつ作るので、実際に decoder に入るデノイジングクエリは 200 個前後になり、同じバッチの中でアノテーションが最も多い画像に応じて変わります。この手法の由来は、こちらを参照してください：\n> \n> - **[[22.03] DN-DETR：今日は犬、明日は猫](/blog/papers/object-detection/dn-detr)**\n> - **[[22.03] DINO：近くても、まだ遠い](/blog/papers/object-detection/dino-detr)**\n\n\ndecoder の各層の後ろには、それぞれ専用の予測ヘッドがつながっていて、学習時には各層の出力がどれも損失の計算に使われます。そのため、どの層もそのまま使える完全な予測を1組出力します。公式コードは推論時に `eval_idx` でどの層の出力を使うかを指定し、ループはその層まで回ったところで止まって、後ろの層は実行されません。\n\n著者らは decoder を4層から7層までそれぞれ学習させ、推論時に各層で止めた結果を比べました（RT-DETR-R50、72 エポック学習）：\n\n| 推論で使う層 | Det4 | Det5 | Det6 | Det7 | 遅延（ms） |\n| ---: | ---: | ---: | ---: | ---: | ---: |\n| 7 | | | | 52.6 | 9.6 |\n| 6 | | | 53.1 | 52.6 | 9.3 |\n| 5 | | 52.9 | 53.0 | 52.5 | 8.8 |\n| 4 | 52.7 | 52.7 | 52.7 | 52.1 | 8.3 |\n| 3 | 52.4 | 52.3 | 52.4 | 51.5 | 7.9 |\n| 2 | 51.6 | 51.3 | 51.3 | 50.6 | 7.5 |\n| 1 | 49.6 | 48.8 | 49.1 | 48.3 | 7.0 |\n\n*表：原論文 Table 5。Det k は学習時に k 層の decoder を使ったことを表し、セルの値は AP です。遅延の列は、推論で何層使ったかだけで決まります。*\n\nまず Det6 の列を見ます。6層から5層に減らすと、AP は 0.1 しか下がらず、遅延は 0.5 ms 減ります。4層まで減らすと AP は 52.7、遅延は 8.3 ms です。1層増えるごとにおよそ 0.4〜0.5 ms 増え、後ろの層ほど AP への寄与は小さくなります。\n\n次に横に比べます。Det6 を4層目で止めると 52.7 で、最初から4層で学習した Det4 と同じです。5層目で止めると 53.0 で、最初から5層で学習した Det5 より 0.1 高くなります。この表の上では、6層のモデルを学習してから短くするのと、浅いモデルを別に学習するのとで、ほとんど差がありません。7層はというと、最も良くても 52.6 で、6層より劣ります。\n\n調整の幅はどれくらいでしょうか？1層目だけなら 7.0 ms、6層すべて使うと 9.3 ms です。著者は GitHub でユーザーに答える中で、今の RT-DETR は各部分が比較的バランスしていて、時間は主にバックボーンと decoder にかかると述べています（[RT-DETR #266、2024-04](https://github.com/lyuwenyu/RT-DETR/issues/266)）。decoder の層数は再学習なしで調整できるので、速度のつまみがもう1つ増えたことになります。\n\n公開されたモデルは、まさにこの使い方をしています。付録 Table B の縮小版 RT-DETR-R50 は RepBlock のチャネルを半分にしていて、同じモデルを2層目から6層目のどこで止めるかによって、50.3 AP、154 FPS から 52.2 AP、125 FPS まで調整できます。同じ表の YOLOv8-M は 50.2 AP、97 FPS です。公式リポジトリの RT-DETR-R50-m（51.3 AP、145 FPS）は、設定ファイルに `eval_idx: 2` と書かれていて、3層目の出力を使っています。\n\n## 考察\n\n### YOLO、DINO と比べる\n\nTable 2 は RT-DETR を YOLO の L、X サイズと並べて比べています。データは COCO val2017 です。RT-DETR と YOLO はどちらも 640×640 入力、そのほかの DETR は 800×1333 です。FPS は T4、TensorRT FP16、バッチ 1 で測り、YOLO は公式の重みを使って、前述のエンドツーエンドの計測方法で NMS をつないでいます：\n\n| モデル | パラメータ（M） | GFLOPs | FPS | AP | APS |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| YOLOv6-L | 59 | 150 | 99 | 52.8 | 34.4 |\n| YOLOv7-X | 71 | 189 | 45 | 52.9 | 36.9 |\n| YOLOv8-L | 43 | 165 | 71 | 52.9 | 35.3 |\n| YOLOv8-X | 68 | 257 | 50 | 53.9 | 35.7 |\n| DINO-Deformable-DETR-R50 | 47 | 279 | 5 | 50.9 | 34.6 |\n| RT-DETR-R50 | 42 | 136 | 108 | 53.1 | 34.8 |\n| RT-DETR-R101 | 76 | 259 | 74 | 54.3 | 36.0 |\n\n*表：原論文 Table 2 から抜粋。APS は小物体の AP です。*\n\nいくつかの組み合わせを見てみます：\n\n- **RT-DETR-R50 対 YOLOv8-L**：AP は 53.1 対 52.9 で、0.2 高いだけです。速度は 108 対 71 FPS で、1枚あたりの時間に直すと 9.3 対 14.1 ms です。GFLOPs も 136 対 165 と少し少なくなっています。\n- **RT-DETR-R101 対 YOLOv8-X**：AP は 0.4 高く、速度は 74 対 50 FPS です。\n- **RT-DETR-R50 対 YOLOv6-L**：AP は 0.3 高いだけで、速度は 108 対 99 FPS と、差はずっと小さくなります。\n\n小物体は RT-DETR が負けているところです。RT-DETR-R50 の APS は 34.8 で、YOLOv8-L の 35.3 より 0.5 低く、R101 の 36.0 は YOLOv7-X の 36.9 より 0.9 低くなっています。著者らはこれを限界として挙げ、DETR に共通する弱点だとしています。\n\n学習条件も異なります。RT-DETR のバックボーンはまず ImageNet で事前学習し、そのあと COCO で 72 エポック学習しています。公式コードが読み込む R50 の重みは、PaddleClas が知識蒸留で学習した ResNet50-vd（`ssld_v2`）で、[PaddleClas のモデル表](https://paddleclas-doc.readthedocs.io/zh/latest/models/ResNet_and_vd_en.html)では ImageNet top-1 が 83.0%、オリジナルの ResNet-50 は 76.5% です。一方、表の YOLOv7、YOLOv8 はスクラッチから学習していて、YOLOv10 論文の付録にも、YOLOv8、YOLOv7、YOLOv9 にならってスクラッチから学習したと明記されています。この表が比べているのはシステム全体で、バックボーンの重みと学習レシピも含まれています。\n\nさらに Objects365 で事前学習してから COCO で微調整すると、R18、R50、R101 はそれぞれ 49.2、55.3、56.2 AP に達し、COCO だけの場合より 2.7、2.2、1.9 高くなります（付録 Table C）。\n\nDINO と比べると、RT-DETR-R50 は AP が 2.2 高く、速度は 108 対 5 FPS で約 21 倍です。これもシステム全体の比較です。DINO の入力は 800×1333 で画素数は 640×640 の 2.6 倍、学習は 36 エポックで、RT-DETR は 72 エポックです。ハイブリッド encoder そのものがどれだけ節約しているかは、Table 3 の同条件の比較に戻って見る必要があります。\n\n2024年6月、あるユーザーが GitHub でこの比較に疑問を投げかけました（[RT-DETR #349](https://github.com/lyuwenyu/RT-DETR/issues/349)）。RTX 3090 で測ると、RT-DETR の FLOPs は DINO の約半分で論文と一致するのに、速度は2倍程度しか速くなかったといいます。両者のデータ拡張とバックボーンが異なることも指摘しています。著者は、DINO の速度は論文の精度に達する条件で測るべきで、V100、T4、3090 のいずれでも測って期待どおりの結果だったと回答しました。異なるモデルの間では、最終的な精度と速度を比べるのが公平だという立場です。何度かやりとりしたあとも、双方とも元の立場を変えませんでした。\n\n### 閾値はどう設定するか？\n\n2023年10月、あるユーザーが GitHub でとても実際的な質問をしました（[RT-DETR #77](https://github.com/lyuwenyu/RT-DETR/issues/77)）。エンドツーエンドの計測方法が使うのは検証時の閾値、つまり信頼度 0.001、IoU 0.7 です。ところが実際の運用では、一般に 0.1 前後の信頼度の閾値で背景のボックスの大部分を先に落とすので、NMS はずっと速くなり、RT-DETR の速度面の優位はそれほど大きくなくなる、という指摘です。\n\n著者は、0.1 の閾値を使うと YOLO の mAP は報告された数値に届かないと答えました。精度は 0.001 で測り、速度は 0.1 で測るとしても、モデルが同時にその2つの状態にあることはありえません。RT-DETR のスコア閾値は出力を選別するだけなので、デプロイ時の速度は評価時と同じです。\n\nどちらの言い分にも根拠があります。Table 1 がちょうど中間の数字を示していて、信頼度の閾値を 0.001 から 0.05 に上げると、EfficientNMS の時間は 1.3 ms 減り、AP は 1.7 下がります。一方で、RT-DETR の 53.1 も、各画像の 300 個の出力をすべて評価プログラムに渡して計算したものです。デプロイ時にスコア閾値をかければ、AP は横ばいか下がるだけで、違いは速度がそれにつれて変わらない点にあります。\n\nこの2つの表を読むときは、Table 2 の YOLO の時間が NMS プラグイン全体を含むのに対し、Table 1 はその中の kernel を1つしか載せていないことも覚えておく必要があります。2つの表の時間をそのまま引き算することはできません。\n\n\n> [!TIP]\n> \n> 1年後の YOLOv10 は遅延を測るときに RT-DETR のこのエンドツーエンドの計測方法を踏襲し、同時に YOLO 自身からも NMS を外しました：\n> \n> - **[[24.05] YOLOv10：NMS、さようなら](/blog/papers/object-detection/yolov10)**\n\n\n### マシンを替えると\n\n2024年2月、別のユーザーが trtexec を使い、3枚の GPU で RT-DETR-R18 と NMS をつないだ YOLOv8s を比べました（[RT-DETR #214](https://github.com/lyuwenyu/RT-DETR/issues/214)）。RTX 4090 では 1.065 対 1.90 ms で、比率は論文と一致しました。ところが T4 では 5.6 対 5.4 ms で YOLOv8s のほうがわずかに速く、ノート PC の RTX 3050 では RT-DETR が 2 ms 近く遅くなりました。\n\n著者は、論文の YOLO の速度は val2017 の 5,000 枚の平均だと答えました。NMS の時間は、スコア閾値を通過するボックスの数によって変わるからです。また、RT-DETR は YOLOv8 より多くの種類の演算子を使っていて、TensorRT のバージョンによってサポートの度合いが異なるとも述べています。このスレッドに結論は出ていません。エンドツーエンドの速度はハードウェア、ソフトウェアのバージョン、データのいずれにも左右されるので、自分の用途で使うなら、やはり自分のマシンで一度測る必要があります。\n\n### それでも重複ボックスはときどき出る\n\nRT-DETR は NMS を外しましたが、重複ボックスは完全には消えていません。2024年7月、あるユーザーが同じ物体にときどき複数のボックスが出ると報告し、ほかの人たちも、ほぼ完全に重なっていて、クラスが異なる、あるいはクラスまで同じボックスに遭遇していました（[RT-DETR #379](https://github.com/lyuwenyu/RT-DETR/issues/379)）。著者はスコア閾値を慎重に選ぶよう勧めました。別のユーザーによると、こうした重複ボックスはスコアが非常に近いことが多く、閾値では分けられません。自分で NMS をつなげば解決できますが、そのぶん時間がかかり、モデルがよく学習できていれば、こうした状況は少なくなるそうです。\n\n\n> [!NOTE]\n> \n> Ultralytics パッケージの `rtdetr-l`、`rtdetr-x` を使っているなら、それらは公式リポジトリに載っている HGNetv2 バックボーン版で、それぞれ 53.0 AP、114 FPS と 54.8 AP、74 FPS です。つまり論文 v1 が前面に出していた2つのモデルです。この v3 では、ResNet バックボーンの R50、R101 が中心に変わっています。\n\n\n## 結論\n\nRT-DETR の論文は2つのことをしました。1つは、YOLO の速度を NMS 込みで、しかも報告 AP を得たときの閾値で測ったこと。もう1つは、DETR を分解して、時間がどこにかかり、どこを削れるかを調べたことです。持ち帰れるのはおおよそ次の点です：\n\n1. **NMS の時間は閾値しだい**。T4 上の YOLOv8 では、信頼度の閾値を 0.001 から 0.05 に上げると、EfficientNMS の時間は 2.36 から 1.06 ms に下がり、AP は 52.9 から 51.2 に落ちます。\n2. **自己注意は S5 だけに残す**。S3、S4 の層内の相互作用を外すと遅延は 35% 減り、AP は落ちません。AIFI と CCFF に替えると、マルチスケール Transformer encoder のバリエーション C より 2.3 AP 高く、遅延は 30% 少なくなります。\n3. **分類スコアにボックスの品質を反映させる**。クエリ選択で IoU を分類目標にすると、12 エポックの設定で AP が 0.8 上がります。\n4. **decoder は短くできる**。1層あたり約 0.5 ms で、6層のモデルを4層目で止めても、最初から4層で学習したものと同じ精度です。\n\n次にリアルタイム検出器の速度表を読むときは、まず NMS が含まれているか、どの閾値を使っているかを確かめ、次にどの GPU、どの TensorRT バージョンかを見るとよいでしょう。RT-DETR の速度は閾値によって変わりませんが、小物体の AP とバックボーンの事前学習も、合わせて比較に含める必要があります。\n\nこのエンドツーエンドの計測方法はのちに YOLOv10 に受け継がれ、RT-DETR 自身もその後のリアルタイム DETR の出発点になりました。2024年末の [DEIM](/blog/papers/object-detection/deim) は、RT-DETRv2 と D-FINE の学習方法を変えて、この種のモデルがより速く学習できるようにしています。\n","imageSizes":{"/content/papers/assets/3ce51df5cdcf3f7995e63085f9c6925d29364b00decdae24bb9a6f2b628bacb1.png":{"width":664,"height":508},"/content/papers/assets/be7c554f6906b5d986546dacca808a2c022430faa695b767c5d0e577210ff15a.png":{"width":800,"height":2044},"/content/papers/assets/7e2de3c38daff439f51d86ec04a7bd391c3f708b817ae539f3c4df7c5546f4d6.png":{"width":1360,"height":332},"/content/papers/assets/420e753b3717e561d473e69a1066095c23584488dab765ae7acee273b91819f8.png":{"width":632,"height":620}}}