{"notes":[{"id":"object-detection/rf-detr","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"RF-DETR","subtitle":"先訓練，再挑尺寸","author":"Z. Yuan","paperDate":"2025-11-12","publishedOn":"2026-05-12","paperTitle":"RF-DETR: Neural Architecture Search for Real-Time Detection Transformers","paperUrl":"https://arxiv.org/abs/2511.09554","bibliography":{"title":"RF-DETR: Neural Architecture Search for Real-Time Detection Transformers","authors":["Isaac Robinson","Peter Robicheaux","Matvei Popov","Deva Ramanan","Neehar Peri"],"url":"https://arxiv.org/abs/2511.09554","pdfUrl":"https://arxiv.org/pdf/2511.09554v2","codeUrl":"https://github.com/roboflow/rf-detr","preprint":{"id":"2511.09554","submittedOn":"2025-11-12","url":"https://arxiv.org/abs/2511.09554"},"publication":{"venue":"ICLR","year":2026,"kind":"conference","url":"https://iclr.cc/virtual/2026/poster/10007257"},"citation":"@misc{objectdetectionrfdetr2025,\n  title = {{RF-DETR: Neural Architecture Search for Real-Time Detection Transformers}},\n  author = {Isaac Robinson and Peter Robicheaux and Matvei Popov and Deva Ramanan and Neehar Peri},\n  year = {2025},\n  eprint = {2511.09554},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2511.09554}\n}\n","citationPath":"/content/papers/citations/object-detection/rf-detr.f78ec4489185.bib"},"thumbnail":{"src":"/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png","width":1080,"height":775},"locale":"zh-hant","path":"/content/papers/zh-hant/object-detection/rf-detr.09a0bee690ad.md","headings":[{"id":"定義問題","text":"定義問題","depth":2},{"id":"在-coco-上調得太細","text":"在 COCO 上調得太細","depth":3},{"id":"一個尺寸只對一種硬體","text":"一個尺寸只對一種硬體","depth":3},{"id":"解決問題","text":"解決問題","depth":2},{"id":"底座是-lw-detr","text":"底座是 LW-DETR","depth":3},{"id":"五個旋鈕","text":"五個旋鈕","depth":3},{"id":"每個尺寸看到多少-token","text":"每個尺寸看到多少 token","depth":3},{"id":"訓練完再挑","text":"訓練完再挑","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"先校正量延遲的尺","text":"先校正量延遲的尺","depth":3},{"id":"coco","text":"COCO","depth":3},{"id":"rf100-vl","text":"RF100-VL","depth":3},{"id":"消融多出來的-2-ap-從哪裡來","text":"消融：多出來的 2 AP 從哪裡來","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":"contrastive-learning/dinov2","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":"zh-hant","path":"/content/papers/zh-hant/object-detection/detr.5ef9bf1965a5.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":{},"guide":null,"relatedReading":[{"id":"object-detection/deformable-detr","relation":"next","topic":"集合預測與注意力偵測器"},{"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":"zh-hant","path":"/content/papers/zh-hant/object-detection/deformable-detr.4eb78eef1d58.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":"集合預測與注意力偵測器"},{"id":"object-detection/h-detr","relation":"next","topic":"集合預測與注意力偵測器"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"讓 Transformer 偵測器更快收斂"}]},{"id":"contrastive-learning/dinov2","category":"contrastive-learning","legacyPath":"contrastive-learning/2304-dinov2","legacySlug":"2304-dinov2","legacyPaths":[],"title":"DINOv2","subtitle":"通用特徵鍛造法","author":"Z. Yuan","paperDate":"2023-04-14","publishedOn":"2025-07-01","paperTitle":"DINOv2: Learning Robust Visual Features without Supervision","paperUrl":"https://arxiv.org/abs/2304.07193","bibliography":{"title":"DINOv2: Learning Robust Visual Features without Supervision","authors":["Maxime Oquab","Timothée Darcet","Théo Moutakanni","Huy V. Vo","Marc Szafraniec","Vasil Khalidov","Pierre Fernandez","Daniel Haziza","Francisco Massa","Alaaeldin El-Nouby","Mahmoud Assran","Nicolas Ballas","Wojciech Galuba","Russell Howes","Po-Yao Huang","Shang-Wen Li","Ishan Misra","Michael Rabbat","Vasu Sharma","Gabriel Synnaeve","Hu Xu","Hervé Jégou","Julien Mairal","Patrick Labatut","Armand Joulin","Piotr Bojanowski"],"url":"https://arxiv.org/abs/2304.07193","pdfUrl":"https://arxiv.org/pdf/2304.07193","codeUrl":"https://github.com/facebookresearch/dinov2","preprint":{"id":"2304.07193","submittedOn":"2023-04-14","url":"https://arxiv.org/abs/2304.07193"},"publication":{"venue":"Transactions on Machine Learning Research","shortVenue":"TMLR","year":2024,"kind":"journal","url":"https://openreview.net/forum?id=a68SUt6zFt"},"citation":"@misc{contrastivelearningdinov22023,\n  title = {{DINOv2: Learning Robust Visual Features without Supervision}},\n  author = {Maxime Oquab and Timothée Darcet and Théo Moutakanni and Huy V. Vo and Marc Szafraniec and Vasil Khalidov and Pierre Fernandez and Daniel Haziza and Francisco Massa and Alaaeldin El-Nouby and Mahmoud Assran and Nicolas Ballas and Wojciech Galuba and Russell Howes and Po-Yao Huang and Shang-Wen Li and Ishan Misra and Michael Rabbat and Vasu Sharma and Gabriel Synnaeve and Hu Xu and Hervé Jégou and Julien Mairal and Patrick Labatut and Armand Joulin and Piotr Bojanowski},\n  year = {2023},\n  eprint = {2304.07193},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2304.07193}\n}\n","citationPath":"/content/papers/citations/contrastive-learning/dinov2.e904e3854892.bib"},"thumbnail":{"src":"/content/papers/assets/9c68ef105804d4462aee8950a1bfd9f0929511f494b1a29690d857bf931da892.jpg","width":1224,"height":368},"locale":"zh-hant","path":"/content/papers/zh-hant/contrastive-learning/dinov2.c9fcec43ad7a.md","headings":[{"id":"定義問題","text":"定義問題","depth":2},{"id":"資料收集","text":"資料收集","depth":2},{"id":"1-準備資料池","text":"1. 準備資料池","depth":3},{"id":"2-去除重複","text":"2. 去除重複","depth":3},{"id":"3-自監督檢索","text":"3. 自監督檢索","depth":3},{"id":"工程規模與效率","text":"工程規模與效率","depth":3},{"id":"解決方法","text":"解決方法","depth":2},{"id":"圖像層級的特徵對齊","text":"圖像層級的特徵對齊","depth":3},{"id":"區塊層級的預測任務","text":"區塊層級的預測任務","depth":3},{"id":"head-設計","text":"Head 設計","depth":3},{"id":"sinkhorn-knopp-centering","text":"Sinkhorn-Knopp Centering","depth":3},{"id":"koleo-正則化","text":"KoLeo 正則化","depth":3},{"id":"高解析度訓練階段","text":"高解析度訓練階段","depth":3},{"id":"工程實作","text":"工程實作","depth":2},{"id":"flashattention","text":"FlashAttention","depth":3},{"id":"sequence-packing","text":"Sequence Packing","depth":3},{"id":"stochastic-depth","text":"Stochastic Depth","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":3},{"id":"討論","text":"討論","depth":2},{"id":"imagenet-classification","text":"ImageNet Classification","depth":3},{"id":"video-classification","text":"Video classification","depth":3},{"id":"instance-recognition","text":"Instance Recognition","depth":3},{"id":"semantic-segmentation","text":"Semantic segmentation","depth":3},{"id":"qualitative-results","text":"Qualitative Results","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"contrastive-learning/dino","relation":"background","topic":"視覺表徵的自我蒸餾"}]}],"text":"挑即時物件偵測器時，很多人會先看 COCO 排行榜，挑一個分數漂亮的模型家族；再從 N、S、M、L 幾個尺寸裡，找一個在自己的 GPU 上跑得夠快的；最後拿自己的資料微調。\n\n這篇論文對每一步都有意見。COCO 上的名次，換到自己的資料集未必站得住；事先切好的幾個尺寸，也未必剛好對上你的硬體；至於「跑得夠快」，各篇論文量延遲的方法並不一致。\n\n如果你沒聽過 Roboflow，先補一點背景。這是一家美國公司，經營電腦視覺的標註、訓練與部署平台，使用者公開分享的資料集集中在旗下的 Roboflow Universe。2025 年 3 月，他們在部落格發表 RF-DETR，一個 DETR 系列的即時偵測器。它吃進一張影像，直接輸出每個物件的框、類別和信心分數，中間不需要 NMS，程式以 Apache 2.0 授權開源。[Roboflow，2025-03-20](https://blog.roboflow.com/rf-detr/)\n\n論文到 2025 年 11 月才放上 arXiv，作者來自 Roboflow 與卡內基美隆大學，後來發表在 ICLR 2026。它交代了那一串模型尺寸是怎麼來的，也就是標題上的神經架構搜尋（neural architecture search，NAS）。Roboflow 本身經營模型訓練平台，和發行 YOLO 系列的 Ultralytics 是直接的競爭對手。\n\n## 定義問題\n\n### 在 COCO 上調得太細\n\n作者認為，近年只認固定類別的專用偵測器，從架構、學習率排程到資料增強，都是對著 COCO 調出來的。換到每張圖的物件數、類別數、資料量都和 COCO 不同的資料集，這些選擇未必還合用。\n\n論文裡的 YOLOv8 是個例子。在作者的測法下，YOLOv8 從 N 放大到 M，COCO 的 AP 從 35.2 升到 47.3；同樣的尺寸搬到 RF100-VL，只從 55.0 升到 56.5，再放大到 XL 也還是 56.5。\n\nRF100-VL 是這組作者在 2025 年整理的基準，從 Roboflow Universe 挑出 100 個資料集，模型在每個資料集上各自微調、評測，再把分數平均。作者把它當成「搬到任意新領域」的代理指標。\n\n另一條路是開放詞彙的視覺語言模型，例如 GroundingDINO。這類模型拿目標資料微調後成績很好，在 RF100-VL 上有 62.3 AP，可是每張圖要 309.9 ms（它不支援 TensorRT，這是 PyTorch 的延遲）。作者也提到，微調會削弱它原本的開放詞彙能力。\n\n訓練配方本身也帶著假設。cosine 學習率排程要事先知道總共訓練幾步，資料增強則預設了資料長什麼樣子。作者舉的例子是自駕車的行人偵測器，如果訓練時用了上下翻轉，模型可能把水窪裡的倒影也當成行人。\n\n### 一個尺寸只對一種硬體\n\n另一個問題是尺寸。現有的偵測器家族，例如 D-FINE 的 N 到 X，每個尺寸都由人手設計、各自訓練。目標硬體一換，只能從現成的尺寸裡挑一個最接近的，或者重新設計、重新訓練。\n\nNAS 本來就是用來自動找出不同的精度與延遲取捨。早期的硬體感知 NAS，每換一種硬體就得重新搜尋、重新訓練；2019 年的 OFA（Once-for-All）把訓練和搜尋拆開，讓一個網路同時訓練數千個共享權重的子網路，訓練完再按需求挑。用在物件偵測上的 NAS，多半只把骨幹換成搜尋出來的網路，偵測器的其他部分維持原樣。\n\n所以這篇要回答兩個問題。能不能在目標資料集上只訓練一次，就得到一整條精度與延遲的曲線，再依硬體挑一個點？挑出來的點，延遲又該怎麼量，才能和別人的數字放在一起比？\n\n## 解決問題\n\n### 底座是 LW-DETR\n\nRF-DETR 的底座是百度在 2024 年提出的 LW-DETR。它由一個 ViT 編碼器、一個 projector 和一個很淺的 DETR decoder 疊成，ViT 裡交錯使用視窗注意力和全域注意力來省計算。\n\n[![RF-DETR 架構圖：左邊是影像切成 patch、加上位置編碼後送進 ViT 骨幹，骨幹有四個 block，每個 block 是兩層視窗注意力加一層全域注意力；四個 block 的輸出進入 projector，再經 Query Selection 與查詢嵌入相加，送進 decoder；decoder 每層依序是自注意力、可變形交叉注意力與前饋層，後面疊著 Decoder Group 1 到 13；右上是偵測頭與分割頭](/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png)](/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png)\n\n*原論文 Figure 2，取自 [**v2 PDF 第 4 頁**](https://arxiv.org/pdf/2511.09554v2#page=4)，CC BY 4.0。左邊是 ViT 骨幹，中間是 decoder，右邊是分割頭，上方是兩種輸出。*\n\n從左下開始看。影像切成 patch，加上位置編碼，送進 ViT 骨幹。圖上的骨幹有四個 block，每個 block 先做兩層視窗注意力，再做一層全域注意力。四個 block 的輸出一起送進 projector，整理成 decoder 要用的特徵圖。\n\n接著是 Query Selection。projector 輸出的每個位置，先各自預測一組類別分數和一個候選框，分數最高的 300 個，成為 decoder 查詢的起點。這是 Deformable DETR 提出的 two-stage 做法。\n\n在 decoder 的每一層裡，查詢之間先做自注意力；再用可變形交叉注意力，到特徵圖上每個候選框附近取幾個點；最後過一層前饋網路。每一層的輸出都接上偵測頭，各自算一次損失，後面砍 decoder 層數的旋鈕就靠這一點。\n\n圖右邊疊著 13 組 decoder，這是從 LW-DETR 沿用的 Group DETR。訓練時準備 13 組查詢，共用同一組 decoder 權重，每組各自和標註做一對一配對，等於每個物件在一次迭代裡拿到 13 個正例；推論時只留一組，仍然不需要 NMS。官方程式的預設也是 13 組。\n\n同一個架構再加一個輕量的分割頭，就是 RF-DETR-Seg，這篇筆記只看偵測。\n\nRF-DETR 對 LW-DETR 的改動主要有三項：\n\n- **骨幹換成 DINOv2**。LW-DETR 原本用 CAEv2。DINOv2 是 Meta 以自監督方式預訓練的 ViT，作者發現用它的權重初始化，小資料集上的偵測準確率明顯提升。代價是速度，DINOv2 有 12 層，CAEv2 只有 10 層，這筆延遲留給後面的 NAS 補回來。COCO 的 N 到 L 用 ViT-S，XL 和 2XL 用 ViT-B。\n- **projector 改用 LayerNorm**。這是為了讓消費級 GPU 也能靠梯度累積湊出大批次。BatchNorm 的統計量只看每次實際送進去的小批次，梯度累積時會失準。\n- **訓練配方變單純**。學習率從 LW-DETR 的 4e-4 降到 1e-4，不用學習率排程，也不做 warm-up。資料增強只留水平翻轉和隨機裁切；多尺度縮放改成整個批次一起縮，減少補邊（padding）的像素。\n\n\n> [!TIP]\n> \n> RF-DETR 的 decoder 沿用 DETR 的一對一配對與 Deformable DETR 的可變形注意力，骨幹則是 DINOv2，背景可以參考：\n> \n> - **[[20.05] DETR：跨領域的奠基者](/blog/papers/object-detection/detr)**\n> - **[[20.10] Deformable DETR：可變形的注意力機制](/blog/papers/object-detection/deformable-detr)**\n> - **[[23.04] DINOv2：通用特徵鍛造法](/blog/papers/contrastive-learning/dinov2)**\n\n\n### 五個旋鈕\n\n底座定好之後，作者在上面開了五個可以轉的旋鈕。圖上每一格都有一條箭頭，一端寫著較快，另一端寫著較準：\n\n[![NAS 搜尋空間的五個示意圖：a 是 patch 大小，8×8 的小 patch 產生較多 token、較準，32×32 的大 patch 較快；b 是 decoder 層數，層數少較快、層數多較準；c 是丟掉部分查詢；d 是輸入解析度；e 是視窗數，右邊的方格切成四塊不同顏色的窗格](/content/papers/assets/f0e8bf4f9ecad4cb2f090117a18034f54eab8bc3e901414f94864de103d3425a.png)](/content/papers/assets/f0e8bf4f9ecad4cb2f090117a18034f54eab8bc3e901414f94864de103d3425a.png)\n\n*原論文 Figure 3，取自 [**v2 PDF 第 5 頁**](https://arxiv.org/pdf/2511.09554v2#page=5)，CC BY 4.0。五個旋鈕分別是 patch 大小、decoder 層數、查詢數、解析度與視窗數。*\n\n- **Patch 大小**（a）。patch 越小，切出來的 token 越多，越準也越慢。訓練時用 FlexiViT 的方法，把同一組 patch embedding 權重縮放到不同大小。\n- **Decoder 層數**（b）。每一層都有自己的損失，推論時可以從後面砍掉任意幾層。全部砍光也行，這時只剩 Query Selection 挑出來的 300 個候選框，變成一個不需要 NMS 的單階段偵測器。\n- **查詢數**（c）。查詢照 Query Selection 給的分數排序，推論時直接丟掉分數最低的那些。查詢數也是每張圖最多能輸出的物件數。\n- **解析度**（d）。解析度越高，小物件越好認，速度也越慢。位置編碼先照「最大解析度 ÷ 最小 patch」配好一整張表，其他組合從這張表內插。\n- **視窗數**（e）。視窗注意力只讓同一個窗格裡的 token 互相看。窗格切得越多，計算越省，資訊也越難跨窗流動。\n\n訓練時，每一步都從網格裡均勻抽一組設定，用它做一次前向和梯度更新。附錄 A 的訓練網格是解析度 320 到 960、每 64 一檔，patch 為 8、10、12、16、20、24、32，視窗數為 1、2、4。decoder 層數和查詢數在訓練時固定為 6 層、300 個，只在推論時往下砍。\n\n作者拿 dropout 的集成觀點來比喻這種訓練，每一步只更新其中一個子網路，數千個子網路一起學。他們也發現，隨機換架構本身就有正則化的效果，所以叫它「架構增強」（architecture augmentation）。後面的消融會看到證據。\n\n\n> [!TIP]\n> \n> 同一組權重怎麼適應不同的 patch 大小，可以參考 FlexiViT 的筆記：\n> \n> - **[[22.12] FlexiViT：自由的 Patch Sizes](/blog/papers/vision-transformers/flexivit)**\n\n\n### 每個尺寸看到多少 token\n\n附錄的 Table 7 列出最後在 COCO 上挑出來的配置。我們算一下，每個配置實際送進 ViT 的 token 有多少。\n\nTable 7 的視窗數寫 2。官方程式把這個數字當成每邊切幾格，所以實際是 2×2 = 4 個窗格，和 Figure 3(e) 畫的四格一致。\n\n```python\n# Table 7：COCO 偵測的帕雷托配置（解析度、patch、每邊切幾個窗格）\nconfigs = {\n    \"N\": (384, 16, 2), \"S\": (512, 16, 2), \"M\": (576, 16, 2),\n    \"L\": (704, 16, 2), \"XL\": (700, 20, 1), \"2XL\": (880, 20, 2),\n}\nfor name, (res, patch, win) in configs.items():\n    side = res // patch\n    tokens = side * side\n    print(f\"{name:>3}: {res}/{patch} = {side:>2}，共 {tokens:>4} 個 token，\"\n          f\"切成 {win * win} 個窗格，每格 {tokens // (win * win):>4} 個\")\n\n# 附錄 L：解析度固定 640，只換 patch，湊出相近的每邊格數\nfor name, patch in [(\"N\", 27), (\"S\", 21), (\"M\", 18)]:\n    print(f\"640/{patch} = {640 / patch:.1f}（{name} 原本是 {configs[name][0] // configs[name][1]}）\")\n\n# 位置編碼依「最大解析度 ÷ 最小 patch」預先配置（附錄 A 的訓練網格）\nprint(\"位置編碼網格：\", 960 // 8, \"×\", 960 // 8)\n# 附錄 A：推論時窮舉的組合數\nprint(\"組合數：\", 11 * 7 * 7 * 3 * 4)\n```\n\n```text\n  N: 384/16 = 24，共  576 個 token，切成 4 個窗格，每格  144 個\n  S: 512/16 = 32，共 1024 個 token，切成 4 個窗格，每格  256 個\n  M: 576/16 = 36，共 1296 個 token，切成 4 個窗格，每格  324 個\n  L: 704/16 = 44，共 1936 個 token，切成 4 個窗格，每格  484 個\n XL: 700/20 = 35，共 1225 個 token，切成 1 個窗格，每格 1225 個\n2XL: 880/20 = 44，共 1936 個 token，切成 4 個窗格，每格  484 個\n640/27 = 23.7（N 原本是 24）\n640/21 = 30.5（S 原本是 32）\n640/18 = 35.6（M 原本是 36）\n位置編碼網格： 120 × 120\n組合數： 6468\n```\n\n先看前六行。在論文裡，N 到 L 是同一次 DINOv2-S 訓練曲線上的四個點，patch 都是 16，差別主要在解析度，每邊從 24 格長到 44 格，decoder 也從 2 層加到 4 層。所以這幾個尺寸的參數量很接近，N 是 30.5M、M 是 33.7M，延遲卻從 2.3 ms 變成 4.4 ms（Table 2）。RF-DETR 沿用 LW-DETR 的習慣，按延遲分尺寸，不按參數量。\n\nL 和 2XL 的 token 一樣多，都是 1,936 個；2XL 換成 DINOv2-B 骨幹，用 patch 20 配上 880 的解析度。XL 只切 1 個窗格，等於每一層都是全域注意力。\n\n窗格也不是切越多越好。DINOv2 預訓練時依賴 CLS token，RF-DETR 讓每個窗格各複製一份；窗格一多，複製的份數跟著變多，速度反而受影響。附錄 L 提到，挑出來的配置大多停在每邊 2 格，LW-DETR 則是 4 格。\n\n中間三行是附錄 L 的一個實驗。作者發現精度跟著「每邊幾格」走，單看解析度或 patch 都說不準。於是把解析度固定在 640，改用 patch 27、21、18 湊出接近 N、S、M 的格數，結果和原本的配置幾乎一樣；27 和 18 這兩種 patch，訓練時一次都沒出現過。\n\n位置編碼那一行是照附錄 A 的訓練網格推出來的，最大解析度 960、最小 patch 8，所以要先準備 120×120 個位置。最後一行是推論時要窮舉的組合數，11 種解析度、7 種 patch、7 種 decoder 深度（0 到 6 層）、3 種視窗數、4 種查詢數（50、100、200、300），一共 6,468 種。\n\n### 訓練完再挑\n\n在目標資料集上訓練完之後，作者在驗證集上把這 6,468 種配置全部跑一遍，量精度和延遲，留下帕雷托前緣，也就是同樣延遲下最準的那些點。要部署時給定延遲上限，挑線上最準的那一個。RF100-VL 則先定好 N 到 2XL 各自的目標延遲，在每個資料集上找延遲落在目標 10% 以內的配置。\n\nNAS 的訓練時間大約是一般單一尺寸訓練的 2 到 4 倍，依資料集而定；搜尋本身，作者估計要 10,000 個 GPU 小時左右（200 張 T4 跑 48 小時）。換來的是所有尺寸都出自同一次訓練，非 NAS 的做法每多一個尺寸就要重訓一次。\n\n挑出配置之後，可以選擇再微調一次。COCO 上幾乎沒有幫助，各尺寸最多 +0.4 AP（Table 15）；RF100-VL 上稍微多一點，例如 N 從 57.8 升到 58.6。作者的解釋是，小資料集上訓練 100 個 epoch，還不夠讓架構增強收斂。\n\n## 討論\n\n### 先校正量延遲的尺\n\n比較延遲本來就麻煩。每篇新論文都會在自己的機器上重量一次前人的模型，數字卻常常對不起來。作者在 §4 列了幾個原因：\n\n1. **YOLO 的延遲常常不含 NMS**。拿它和不需要 NMS 的端到端偵測器比，並不公平。2023 年的 RT-DETR 就指出過這件事。\n2. **YOLO 的分割模型只算到 prototype**。量到的是中間產物的時間，還沒組成每個物件可以直接用的遮罩。\n3. **GPU 會降頻**。連續推論時 GPU 過熱，時脈被拉低，量出來的延遲跟著飄。作者的做法是每次前向之間停 200 ms。\n4. **延遲用 FP16，準確率用 FP32**。不少論文拿 FP16 的模型量速度，卻拿 FP32 的模型量準確率。直接量化有時掉得很兇，D-FINE 直接轉成 FP16 只剩 0.5 AP，改用 ONNX opset 17 匯出才恢復。作者主張準確率和延遲要用同一個模型檔量。\n5. **驗證和推論的 NMS 可能不一樣**。作者在 TensorRT 上重現不出 YOLOv8 和 YOLO11 公布的 mAP，推測是因為它們驗證時用多類別 NMS，一個框可以同時保留好幾個類別，實際推論卻只用單類別。\n\n這套量法下，YOLO 一律接上 NMS，信心門檻 0.01；硬體是 T4，用 TensorRT 10.4、CUDA 12.4。Table 1 把幾個 M 尺寸的模型，用原論文公布的數字和這套量法並排：\n\n| 模型 | 公布的 AP | 公布的延遲 | FP32 AP | FP32 延遲 | FP16 AP | FP16 延遲 |\n| --- | ---: | ---: | ---: | ---: | ---: | ---: |\n| YOLOv8-M | 50.2 | 5.86 | 49.3 | 14.8 | 47.3 | 5.4 |\n| YOLO11-M | 51.5 | 4.7 | 49.7 | 18.7 | 48.3 | 5.2 |\n| RT-DETR-R18 | 49.0 | 4.61 | 49.0 | 12.2 | 49.0 | 4.4 |\n| LW-DETR-M | 52.5 | 5.6 | 52.6 | 26.8 | 52.6 | 4.4 |\n| D-FINE-M | 55.1 | 5.62 | 55.1 | 13.9 | 55.0 | 5.4 |\n| RF-DETR-M | – | – | 54.8 | 20.5 | 54.7 | 4.4 |\n\n*表：原論文 Table 1，延遲單位 ms。後四欄都是每次前向之間停 200 ms 的量法；D-FINE 的 FP16 是修正匯出之後的數字。*\n\n從 FP32 換到 FP16，兩個 YOLO 各掉了 2.0 和 1.4 AP，四個 DETR 類模型最多掉 0.1。公布的數字和作者實測的 FP32 也有落差，YOLOv8-M 差 0.9，YOLO11-M 差 1.8。FP32 那一欄的延遲在 12.2 到 26.8 ms 之間，是 FP16 的 2.6 到 6.1 倍。\n\n2025 年 9 月，論文還沒出來，就有使用者在 RF-DETR 的 GitHub 開 issue，說他們列出的 YOLO11 數字有誤。第一作者回覆，這些數字是用 TensorRT 融合的 NMS、FP16 和 pycocotools 實際量出來的；Ultralytics 驗證時用多標籤 NMS，依他們的經驗會讓 COCO mAP 高出 1 左右，回報的速度又是不含 NMS 的 FP16。[rf-detr #350](https://github.com/roboflow/rf-detr/issues/350) 論文的 §4 把同樣的論點寫成了一套量法。\n\n停那 200 ms 有多大影響？Table 20 在同一組 M 模型上比過，不停和停 200 ms 的延遲差 0 到 0.3 ms，停得更久，變化不超過 0.1 ms。作者也承認，這套量法量的是 GPU 沒過熱時的單張延遲，不是用來量持續吞吐的；如果你的服務是連續推論，表上的數字比較接近 GPU 涼快時的狀態。TensorRT 每次編譯的結果也會差到 0.1 ms，所以論文的延遲只寫到小數點後一位。\n\n量法的選擇也會影響名次。作者在 TensorRT 裡統一開啟 CUDA graphs，讓 GPU 的運算核心預先排好隊，不必由 CPU 一個個啟動。這對 RT-DETR、LW-DETR 和 RF-DETR 有幫助，對 D-FINE 沒有；作者自己寫到，開了之後，LW-DETR 和 D-FINE 落在同一條精度與延遲的曲線上。\n\nNMS 的門檻也會改變數字。在這套量法下，YOLOv8-N 含 NMS 的總延遲是 2.1 ms，AP 35.2（Table 2）。同一個 YOLOv8-N，在 YOLOv10 論文的量法裡總延遲是 6.16 ms，其中模型本身只占 1.77 ms；YOLOv10 用的是各模型驗證時的 NMS 設定，留下的候選框多得多。看到「NMS 要花幾毫秒」這類數字時，先找門檻設在哪裡。\n\n\n> [!TIP]\n> \n> 把 NMS 算進延遲的端到端量法，以及同一個 YOLOv8-N 在不同量法下的數字，可以參考：\n> \n> - **[[23.04] RT-DETR：把 NMS 算進碼錶](/blog/papers/object-detection/rt-detr)**\n> - **[[24.05] YOLOv10：NMS，再見](/blog/papers/object-detection/yolov10)**\n\n\n### COCO\n\n先看 Figure 1 的左上角：\n\n[![COCO 物件偵測的精度與延遲曲線，橫軸是 T4 上的延遲，從約 1.5 到 20 ms，縱軸是 AP50:95，從 35 到 60；紫色的 RF-DETR（DINOv2-S）和粉紅色的 RF-DETR（DINOv2-B）是連續曲線，YOLOv8、YOLO11、D-FINE、RT-DETR、LW-DETR 是以 N 到 XL 標記連起來的折線](/content/papers/assets/5d7dc32c6480e109cfe21fc73d7a8f9fbc1a7218232165cc360266eb0d5c9849.png)](/content/papers/assets/5d7dc32c6480e109cfe21fc73d7a8f9fbc1a7218232165cc360266eb0d5c9849.png)\n\n*原論文 Figure 1 左上子圖，取自 [**v2 PDF 第 3 頁**](https://arxiv.org/pdf/2511.09554v2#page=3)，CC BY 4.0。橫軸是延遲（ms），縱軸是 COCO 的 AP50:95。*\n\n其他家族都是幾個尺寸連成的折線，RF-DETR 的兩條卻是連續的曲線。紫色那條是 DINOv2-S 骨幹的一次訓練，粉紅色那條是 DINOv2-B 的一次訓練，線上每一點都是同一份權重換一組配置。\n\n低延遲這一端，紫色線壓在所有家族上面。往右到了 L 附近，棕色的 D-FINE 追上紫色線，到 XL 時高出一截；粉紅色的曲線要到 17 ms 左右，才越過 60。\n\n挑幾列數字對照：\n\n| 模型 | 參數量 | 延遲（ms） | AP |\n| --- | ---: | ---: | ---: |\n| YOLOv8-N | 3.2M | 2.1 | 35.2 |\n| LW-DETR-T | 12.1M | 1.9 | 42.9 |\n| D-FINE-N | 3.8M | 2.1 | 42.7 |\n| RF-DETR-N | 30.5M | 2.3 | 48.0 |\n| YOLOv8-M | 25.9M | 5.4 | 47.3 |\n| LW-DETR-M | 28.2M | 4.4 | 52.6 |\n| D-FINE-M | 19.2M | 5.4 | 55.0 |\n| RF-DETR-M | 33.7M | 4.4 | 54.7 |\n| D-FINE-XL | 62M | 11.5 | 59.3 |\n| RF-DETR-XL | 126.4M | 11.5 | 58.6 |\n| RF-DETR-2XL | 126.9M | 17.2 | 60.1 |\n\n*表：整理自原論文 Table 2 與 Table 12，皆為作者以同一套量法實測。*\n\n1. **N 的差距最大**。RF-DETR-N 比 D-FINE-N 高 5.3 AP，延遲多 0.2 ms；它的 48.0 也比 YOLOv8-M 的 47.3 高，延遲不到一半。\n2. **M 以上就有輸有贏**。D-FINE-M 比 RF-DETR-M 高 0.3 AP，但慢 1.0 ms；到了 XL，兩者同樣 11.5 ms，D-FINE 反而高 0.7。\n3. **2XL 超過 60**。60.1 AP、17.2 ms，比 D-FINE-XL 高 0.8，延遲多 5.7 ms。作者說，就他們所知，這是第一個在 COCO 上超過 60 AP 的即時偵測器。\n\nRF-DETR 除了 DINOv2，還在 Objects365 上預訓練過；D-FINE 的 S 到 XL 也有，D-FINE-N 則沒有，作者在附錄自己註明了這一點。RF-DETR 的參數量也大得多，N 是 30.5M，D-FINE-N 是 3.8M，差了八倍，記憶體或儲存空間吃緊的裝置要另外考慮。論文說的「即時」，指 T4 上 40 ms 以內；附錄還有一個 Max 版本，61.8 AP，但要 98 ms，已經在這個範圍之外。\n\nRoboflow 在 2025 年 3 月的發布文章裡，就說 RF-DETR 是第一個超過 60 mAP 的即時模型，當時指的是舊版 RF-DETR-large 在 728 解析度下的 60.5；論文裡撐起這句話的，換成了 2XL 的 60.1。\n\n### RF100-VL\n\n換到 RF100-VL，同樣挑幾列：\n\n| 模型 | 延遲（ms） | AP | NAS 後再微調 |\n| --- | ---: | ---: | ---: |\n| YOLOv8-N | 2.6 | 55.0 | – |\n| YOLO11-M | 5.1 | 57.0 | – |\n| D-FINE-N | 2.0 | 58.2 | – |\n| RF-DETR-N | 2.5 | 57.8 | 58.6 |\n| D-FINE-M | 5.6 | 60.6 | – |\n| RF-DETR-M | 4.6 | 61.7 | 62.0 |\n| GroundingDINO-T（微調） | 309.9 | 62.3 | – |\n| RF-DETR-2XL | 15.6 | 63.3 | 63.5 |\n\n*表：整理自原論文 Table 4，100 個資料集的平均。GroundingDINO 的延遲是 PyTorch 量的，其他是 TensorRT。*\n\nYOLO 這邊不管尺寸大小，都停在 55 到 57。最小的尺寸，D-FINE-N 的 58.2 反而高於沒有再微調的 RF-DETR-N；到了 M，RF-DETR 領先 1.1 AP，延遲也短 1.0 ms。2XL 比微調過的 GroundingDINO 高 1.0 AP（再微調後是 1.2），延遲約是它的二十分之一，只是兩邊用的推論引擎不同。\n\nYOLO 和 DETR 類模型的差距，大多集中在小物件。YOLO 各尺寸的 AP_S 只有 4.7 到 7.3，DETR 類模型都在 30 以上，論文沒有分析原因。作者另外提醒，YOLO 這裡沿用 0.01 的信心門檻，不一定適合每一個資料集，延遲數字可能因此不是 YOLO 的最佳狀態。\n\n附錄 I 還有一組實驗，把 COCO 上挑好的配置直接搬到 RF100-VL，不在新資料集上重新搜尋。N、S、M 分別是 57.7、60.2、61.2，在 RF100-VL 上重新搜尋的配置是 57.8、60.9、61.7，差 0.1 到 0.7 AP；L 的固定配置反而高 0.2，只是延遲多了 0.6 ms。固定配置已經都高於同尺寸的 LW-DETR。\n\n### 消融：多出來的 2 AP 從哪裡來\n\nTable 5 從 LW-DETR-M 出發，一步一步改成 RF-DETR-M：\n\n| 步驟 | 延遲（ms） | AP |\n| --- | ---: | ---: |\n| LW-DETR-M | 4.4 | 52.6 |\n| + 較溫和的超參數 | 4.4 | 51.6 |\n| + DINOv2 骨幹 | 4.7 | 53.6 |\n| + 更多 Objects365 預訓練 | 4.7 | 54.3 |\n| + 權重共享 NAS（配置不變） | 4.7 | 54.6 |\n| 　patch 改 16、解析度改 640 | 4.7 | 54.4 |\n| 　解析度降到 576 | 4.0 | 53.6 |\n| 　每邊窗格 4 → 2 | 4.3 | 54.3 |\n| 　decoder 3 → 4 層 | 4.4 | 54.6 |\n\n*表：整理自原論文 Table 5，COCO。*\n\n換成較溫和的超參數（較小的學習率、LayerNorm 等），AP 先掉了 1.0；作者說 LayerNorm 會傷一點準確率，但不換就沒辦法在消費級硬體上訓練。換上 DINOv2，AP 回升 2.0，延遲多了 0.3 ms。\n\n第五步的配置是 patch 14、解析度 560，而 patch 14 根本不在訓練網格裡。模型只是跟著 NAS 一起訓練，同一個配置就多了 0.3 AP，這是前面說的架構增強的證據。\n\n後四步是轉旋鈕，把延遲拉回 4.4 ms。最後 54.6 AP，和 LW-DETR-M 同樣的延遲，高了 2.0。\n\n骨幹的比較在 Table 6。同樣的設定下，DINOv2 ViT-S 是 54.3，CAEv2 是 52.3，SigLIPv2 是 50.4；SAM2 的 Hiera-S 有 53.6，但延遲是 11.2 ms，比 DINOv2 的 4.7 ms 慢了一倍多。（SigLIPv2 和 SAM2 轉成 FP16 後成績很差，這兩列放的是 FP32 的準確率，算是它們的上限。）\n\n## 結論\n\nRF-DETR 把 LW-DETR 的骨幹換成 DINOv2，再用權重共享 NAS 在目標資料集上訓練一次，之後在驗證集上窮舉六千多種配置，依延遲挑點。論文能帶走的有這幾件事：\n\n1. **尺寸可以事後再挑**。一次訓練就得到一整條精度與延遲的曲線，不同硬體挑不同的點。代價是訓練時間變成 2 到 4 倍，搜尋還要上萬個 GPU 小時。\n2. **COCO 之外要再看一個基準**。YOLO 在 COCO 上隨尺寸一路變好，到了 RF100-VL 幾乎不動；D-FINE 和 RF-DETR 的勝負也隨資料集翻轉。不過 RF100-VL 是作者自己整理的基準。\n3. **量延遲要把條件寫清楚**。NMS 算不算、門檻多少、FP16 還是 FP32、有沒有讓 GPU 冷卻，任何一項不同，表上的數字就不能直接比。\n\nNAS 的程式沒有開源，第一作者在 2025 年 12 月的 issue 裡說，GitHub 上的程式是用來微調 NAS 找出來的固定配置；在自己的資料上跑 NAS，要透過 Roboflow 的平台。[rf-detr #483](https://github.com/roboflow/rf-detr/issues/483) 照附錄 I 的數字，COCO 的固定配置用在 RF100-VL 上，和重新搜尋的配置相比，不再微調時差距在 0.7 AP 以內。授權也分兩種，N 到 L 的偵測模型是 Apache 2.0，XL 和 2XL 的偵測模型則用 Roboflow 自己的 PML 1.0，商用自架要另外付費。[rf-detr README](https://github.com/roboflow/rf-detr)\n\n查詢數只能往下砍，上限是訓練時的 300 個。一張圖有幾百個物件的場景，第一作者的建議是把大圖切成小塊再送進去。[rf-detr #350](https://github.com/roboflow/rf-detr/issues/350) 另外，官方的後處理把「查詢 × 類別」的分數攤平後取前 300 名，同一個框可能帶著兩個類別出現。有使用者回報過重疊的框，第一作者說資料夠多時模型應該要自己學會避開，Roboflow 的工程師則建議直接在輸出後面接 NMS。[rf-detr #187](https://github.com/roboflow/rf-detr/issues/187)\n\n下次看到某個偵測器說自己比 YOLO 快，可以先翻到它量延遲的那一段，看看 NMS 的門檻設多少、測速和測準的是不是同一個模型檔。想看 YOLO 那一側怎麼處理 NMS，可以接著讀 Ultralytics 的 [YOLO26](/blog/papers/object-detection/yolo26)。\n","imageSizes":{"/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png":{"width":1080,"height":775},"/content/papers/assets/f0e8bf4f9ecad4cb2f090117a18034f54eab8bc3e901414f94864de103d3425a.png":{"width":1005,"height":653},"/content/papers/assets/5d7dc32c6480e109cfe21fc73d7a8f9fbc1a7218232165cc360266eb0d5c9849.png":{"width":788,"height":555}}}