RT-DETRとは？読み方・仕組み・YOLOとの違い・ライセンスとv2〜v4の比較

RT-DETR（Real-Time DEtection TRansformer）は、Baiduの研究チームが2023年4月に論文「DETRs Beat YOLOs on Real-time Object Detection」で発表し、CVPR 2024に採択されたTransformer系のリアルタイム物体検出モデルです。YOLO系が前提にしてきた後処理のNMS（Non-Maximum Suppression）を使わずに、T4 GPUで100 FPSを超える速度とCOCOで53%台のAPを両立させました。公式実装はApache License 2.0で、2026年10月時点ではv2・v3・v4まで派生しています。物体検出の手法全体の中での位置づけは物体検出の仕組みと代表手法の比較で整理しています。本記事では、読み方と仕組み、YOLOとの比較条件、入手経路ごとのライセンス差、バージョンの選び方を一次情報で確認し、論文が扱っていないCPUでの推論速度は実際に計測した値を載せます。

まとめ：RT-DETRの要点と2026年時点の選び方

• 正体：DETR（DEtection TRansformer）をリアルタイム化した物体検出モデル。論文はarXiv 2304.08069、CVPR 2024採択。公式実装は GitHub の lyuwenyu/RT-DETR。
• 読み方：公式の指定はありません。アルファベットで「アールティー・ディーイーティーアール」と読むのが無難です。
• 仕組み：マルチスケール特徴をハイブリッドエンコーダ（AIFI＋CCFF）で計算量を抑えて処理し、デコーダに渡す初期クエリを選別してNMSなしで箱を直接出します。デコーダ層数を減らせば再学習なしで速くなります。
• YOLOとの違い：論文ではNMS込みの速度で比べ、RT-DETR-R50（53.1 AP・108 FPS）がYOLOv8-L（52.9 AP・71 FPS）を上回りました。ただし小物体のAPは同規模のYOLOに届いていません。
• ライセンス：公式実装とPaddleDetectionはApache 2.0で商用利用できます。Ultralytics経由で使う場合はライブラリがAGPL-3.0です。
• バージョン：新規採用はv2（PyTorch実装・Transformers対応）か、精度優先ならv4（T4でX 57.0 AP）。v1を選ぶのは既存環境の保守か、YOLOと同じUltralyticsのAPIで扱いたい場合です。
• CPUでの速度：8コアのIntel CPU（Core i9-9880H）とTransformers版で計測すると、R18で1枚約1.4秒、R50で約3秒でした。この環境ではデコーダが使う時間は全体の11〜13%で、層を削ってもR18は約8%の短縮、R50は実行ごとの揺れに埋もれて短縮を確認できませんでした。

RT-DETRの正式名称・読み方・開発元

RT-DETRは「Real-Time DEtection TRansformer」の略です。DETRの部分は、2020年にFacebook AI Research（現Meta）が発表した物体検出モデル「DEtection TRansformer」を指します。論文と公式リポジトリに読み方の指定はありません。日本語ではアルファベットをそのまま読む「アールティー・ディーイーティーアール」が通じやすく、「デター」のような単語読みも見かけますが、どちらも公式の呼称ではありません。表記も「RTDETR」「RT DETR」「RT-DETR」と揺れますが、指しているものは同じです。

論文の著者はWenyu Lv氏らBaiduの研究者です。実装はBaidu公式のPaddleDetectionと、著者が公開する lyuwenyu/RT-DETR の2系統で提供されています。Hugging Face Transformersには2024年6月22日に追加され、チェックポイントは PekingU/rtdetr_r50vd などの名前で公開されています。

RT-DETRの仕組み：NMSを外すための設計

NMSが推論速度のボトルネックになる理由

YOLO系の検出器は1つの物体に対して重なった候補箱を大量に出し、NMSで重複を消してから結果を確定させます。論文は、このNMSの処理時間が箱の数と2つのしきい値（信頼度とIoU）で変わるため、モデル単体のFPSでは実運用の速度を比べられないと指摘しました。そこでNMS込みの「エンドツーエンド速度」のベンチマークを作り、その条件でYOLOと比較しています。DETR系はそもそも1物体に1つの箱を出すように学習するため、NMSの代わりにスコアのしきい値で低信頼の箱を落とすだけで済みます。

一方、元のDETRはTransformerエンコーダの計算が重く、学習に500エポックを要したうえ、論文の比較表でもDETR-DC5（R50）は43.3 APにとどまるなど、リアルタイムには遠いモデルでした。RT-DETRは、このエンコーダの重さを削ることでNMS不要の利点を実用速度に持ち込んだ点が要点です。

効率的ハイブリッドエンコーダ：AIFIとCCFF（CCFM）の分担

RT-DETRは、CNNバックボーン（ResNetやHGNetv2）の最後の3段（S3・S4・S5）から特徴マップを取り出します。ここでの工夫は、スケール内の処理とスケール間の融合を分けたことです。

• AIFI（Attention-based Intra-scale Feature Interaction）：自己注意を最も解像度の低いS5だけに掛けます。意味情報が濃く、トークン数の少ない層に絞ることで、注意機構の計算量を大きく減らしています。
• CCFF（CNN-based Cross-scale Feature Fusion）：スケール間の融合は畳み込みベースのモジュールで行います。小さい物体の手がかりが残る高解像度側の特徴は、ここで取り込まれます。初期の版の論文やUltralyticsのドキュメントではCCFMと表記されています。

従来のDeformable DETR系は全スケールのトークンをまとめてエンコーダに通していました。RT-DETRはその大半を畳み込みに置き換え、エンコーダを速度の制約内に収めています。

初期クエリの選び方：IoU-awareからuncertainty-minimalへの改称

デコーダには、エンコーダ出力から選んだ上位300個の特徴が初期クエリとして渡されます。分類スコアだけで選ぶと、クラスらしさは高いが位置がずれた特徴が混ざり、精度が落ちます。RT-DETRは、分類と位置の両方の信頼度が高い特徴を選ぶように学習させました。

この手法の名称は論文の版で変わっています。arXivのv1要旨とUltralyticsのドキュメントは「IoU-aware query selection」、最新のv3本文は「uncertainty-minimal query selection」です。分類と位置のずれを「不確かさ」として明示的に最小化する定式化に書き直されたためで、同じ機構を指しています。古い解説と論文を読み比べるときは、名称の違いで別の手法と取り違えないよう注意してください。

デコーダ層数と初期クエリ数による速度調整

RT-DETR-LやR50のデコーダは既定で6層（R18は3層）あり、各層に補助予測ヘッドが付いて学習されています。そのため、推論時に途中の層で打ち切っても再学習なしで結果が出ます。Ultralyticsのドキュメントによると、T4 GPU・TensorRT 10.11でRT-DETR-Lを4層に減らすと8.0 ms・52.7 mAPが7.4 ms・52.5 mAPになります。初期クエリを300から100に減らした場合は7.4 ms・51.7 mAPです。

同じ0.6 msの短縮でも、層を削る方が精度の落ち方は小さくなっています。クエリ数は1画像あたりの最大検出数の上限にもなるため、密集した場面を扱うなら層数の方を先に削るのが安全です。逆方向の調整はできません。UltralyticsのFAQによると、配布済みの重みは300クエリで学習されているため、max_det を300より大きくしても1画像300件を超えては返りません。1枚に300個を超える物体が写るデータでは、モデルYAMLのクエリ数（nq）を増やして学習し直す必要があります。

RT-DETRとYOLOの違い：論文の比較条件と2026年の前提

論文のTable 2は、T4 GPU・TensorRT FP16で、YOLO側はNMSを含めた速度を計測しています。論文のTable 2の主要な行に、公式リポジトリが掲載するHGNetv2-L/Xの数値を加えると次のとおりです。

同じパラメータ規模で比べると、RT-DETR-R50はYOLOv8-Lより0.2ポイント高いAPで、FPSは約1.5倍です。「DETRs Beat YOLOs」という論文タイトルは、NMSを速度に含めるというこの計測条件の上での主張です。

小物体のAP：同規模のYOLOとの精度差

論文は弱点も明記しています。小物体のAP（AP_S）では、RT-DETR-R50がLクラスで最も高いYOLOv8-Lより0.5ポイント低く、RT-DETR-R101はXクラスで最も高いYOLOv7-Xより0.9ポイント低い結果でした。全体のAPで勝っていても、遠景の人物や基板上の微小部品のように小さな物体が主役のデータでは、YOLO系の方が有利になり得ます。公式リポジトリは2024年10月にスライス推論（画像を分割して推論する方式）を追加しており、小物体が多い用途ではこれを併用するか、候補モデルを自分のデータで比べてから決めてください。

YOLO26のNMSなし推論と既定の検出ヘッド

2023年時点では「NMSが要らない」ことがRT-DETRの明確な差別化点でした。現在は状況が変わっています。UltralyticsのYOLO26は、one-to-oneの検出ヘッドを持ち、nms=Falseを指定するとNMSを通さずに1画像あたり最大300件の結果を直接出力します。ただし既定はNMSを使うone-to-manyヘッドで、精度はこちらの方がわずかに高いとされています。NMSのしきい値調整を運用から外したいという理由だけなら、YOLO系でも選択肢はあります。RT-DETR系を選ぶ根拠は、Apache 2.0で使えることと、デコーダ層数による速度調整の柔軟さに移りつつあります。YOLO系の実装とライセンスの違いはYOLOv9のGitHub実装3種とライセンスでも扱っています。

RT-DETRのバージョン一覧：v1・v2・v3・v4の違い

2026年10月時点で、公式リポジトリの更新履歴が「最新」として案内しているのはv4です。検索では「rt-detr v5」も見られますが、lyuwenyu/RT-DETR と RT-DETRs 組織の一覧はv4までで、v5の案内は出ていません。

RT-DETRv2：同じ速度のままAPを底上げ

v2（arXiv 2407.17140）はアーキテクチャを大きく変えず、学習と実装の改良（bag-of-freebies）でAPを上げた版です。変更点は、デフォーマブル注意のサンプリング点数をスケールごとに変えられるようにしたこと、デフォーマブル注意で用いるgrid_sample演算を置き換える離散サンプリング演算を任意で選べるようにしたこと、学習後半で弱めるなどの動的なデータ拡張、モデル規模に応じたハイパーパラメータの調整です。grid_sampleは変換先の推論エンジンによって対応が不完全なことがあり、離散サンプリングはこの配備上の制約を外す目的で入りました。

FPSはv1と同じで、伸びは小さいモデルほど大きくなっています。v1からの移行で得られるのは主に小型モデルの精度と、配備時の互換性です。

RT-DETRv3：密な教師信号による学習改善

v3（arXiv 2409.08475、WACV 2025採択）は、DETRのハンガリアンマッチング（1物体に1クエリを割り当てる学習）では正例が少なく、YOLOのような密な教師信号に比べて学習が不十分になる点を改善しました。学習時だけCNNの補助ブランチを付けて密な教師信号を与え、さらに自己注意に摂動を加えて複数のクエリ群に正例を割り当てます。補助ブランチは推論時には外すため、推論速度は変わりません。実装はPaddlePaddleが中心で、PaddleDetectionの configs/rtdetrv3 と著者リポジトリ clxia12/RT-DETRv3 で公開されています。PyTorchで使いたい場合は、v3を飛ばしてv2かv4を選ぶ方が手間がかかりません。

RT-DETRv4：DINOv3からの蒸留で推論コストを増やさずに精度向上

v4（arXiv 2510.25257）は、MetaのDINOv3（ViT-B/16）を教師モデルにして、軽量な検出器に視覚基盤モデルの表現を蒸留します。教師は学習時にしか使わないため、推論時の遅延は増えません。2025年11月17日にコードと重みが公開され、2026年6月18日にECCV 2026への採択が告知されました。

各公式資料の公表値では、v4-Lはv2-L（53.4 AP・108 FPS）よりAPが2.0ポイント高く、FPSも上回ります。ただし、同一環境で再計測した比較ではないため、採用時はTensorRTの版や入出力処理を揃えて確認してください。独自データで再学習する場合は、DINOv3の重みを別途ダウンロードして設定ファイルに指定する必要があります。

RT-DETRのライセンスと商用利用：入手経路別の条件

「RT-DETRはApache 2.0」とだけ覚えていると、使う経路によっては条件を読み違えます。モデルの考え方は同じでも、配布しているコードや重みごとにライセンスが別だからです。

表は各配布元のLICENSE（lyuwenyu/RT-DETR、RT-DETRv4、Ultralytics）に基づきます。Apache 2.0はソース非公開での製品組み込みを認めています。再配布時にはライセンス文の提供に加え、変更したファイルへの変更表示、該当する権利表示の保持、元の配布物にNOTICEがある場合の帰属表示の引き継ぎなど、第4条の条件を満たす必要があります。対してUltralyticsのパッケージはAGPL-3.0で、モデル自体がRT-DETRでも、改変版に該当するプログラムをネットワーク越しに利用させる場合、第13条により、その利用者に対応するソースを無償で取得する手段を提供する必要があります。組み込み先まで義務が及ぶ範囲は、結合方法と派生物への該当性によって判断します。Ultralytics自身は、プロジェクト全体をAGPL-3.0で公開しない利用には有償のEnterpriseライセンスが必要だと案内しています。

学習済み重みの学習データにも注意が要ります。公式にはCOCOとObjects365で事前学習した重み（例：R50で55.3 AP）もありますが、派生モデルのD-FINEはREADMEで、Objects365を使った重みはデータセットの規約の対象になり得るため、商用利用が許されると決めつけないよう注記しています。同じデータで学習したRT-DETRの重みを製品に使う場合も、Objects365の利用条件を確認しておくのが安全です。v4で再学習する場合は、教師に使うDINOv3の利用条件も合わせて確認してください。

RT-DETRの公式GitHubと使い方

公式リポジトリ lyuwenyu/RT-DETR の構成

公式リポジトリは、PaddlePaddle版とPyTorch版をv1・v2それぞれで持つ4ディレクトリ構成です。

• rtdetr_paddle／rtdetr_pytorch：v1の実装と重み
• rtdetrv2_paddle／rtdetrv2_pytorch：v2の実装と重み（新規ならこちら）

2026年8月にはDDP学習のハング修正やtorchvision 0.16以降への対応がコミットされ、保守は続いています。2026年10月9日には、ハイブリッドエンコーダの位置埋め込みを非正方形の特徴マップで正しく作る修正（#692）が入りました。正方形の入力（640×640など）は結果が変わりませんが、修正前のコードで非正方形のサイズのまま学習したモデルは再学習が、非正方形の eval_spatial_size で書き出したモデルは再エクスポートが必要だと説明されています。同じ日に、v1の rtdetr_pytorch が固定する torch 2.0.1 は Python 3.8〜3.11 でしか入らないことも README に追記されました（#690）。Python 3.12以降の環境で pip install -r requirements.txt が失敗するのはこのためです。v2のPyTorch版READMEには、torch／torchvisionの対応組み合わせとして2.0／0.15、2.1／0.16、2.2／0.17、2.4／0.19が掲載されています。独自データで学習するときは、設定ファイルの num_classes を自分のクラス数に合わせ、remap_mscoco_category を False にします。これを忘れると、クラスIDがCOCOの80クラスに読み替えられて学習が崩れます。アノテーションの設計と品質管理はデータラベリングのラベル設計と一致率で解説しています。

git clone https://github.com/lyuwenyu/RT-DETR.git
cd RT-DETR/rtdetrv2_pytorch
pip install -r requirements.txt

# 4GPUで学習（configは configs/rtdetrv2/ から選ぶ）
CUDA_VISIBLE_DEVICES=0,1,2,3 torchrun --master_port=9909 --nproc_per_node=4 \
  tools/train.py -c path/to/config --use-amp --seed=0

# ONNXへ書き出し、TensorRTエンジンに変換
python tools/export_onnx.py -c path/to/config -r path/to/checkpoint --check
python tools/export_trt.py -i path/to/onnxfile

推論はPyTorch・ONNX Runtime・TensorRT・OpenVINO向けのスクリプトが references/deploy に用意されています。エッジGPUでFP16やINT8に落とす判断はモデル量子化のPTQとQATの違い、Jetsonへの配備はNVIDIA Jetsonの選定基準が参考になります。NVIDIAの学習・配備ツールであるTAO ToolkitもRT-DETRを対象モデルに含めており、TAO 6.25.09ではRT-DETRのFP8／INT8量子化に対応しました。

Hugging Face Transformersによる推論手順

Transformers経由で試す場合は、PyTorch、Transformers、Pillow、requestsをインストールしたPython環境を用意します。以下は公式ドキュメントに基づく推論例です。v1は RTDetrForObjectDetection、v2は RTDetrV2ForObjectDetection を使います。v2のクラスが入ったのはTransformers v4.49.0なので、それより古い版ではv1しか読み込めません。入力は640×640を前提に学習されており、ImageProcessorが自動でリサイズします。

import requests
import torch
from PIL import Image
from transformers import RTDetrForObjectDetection, RTDetrImageProcessor

url = "http://images.cocodataset.org/val2017/000000039769.jpg"
image = Image.open(requests.get(url, stream=True).raw)

processor = RTDetrImageProcessor.from_pretrained("PekingU/rtdetr_r50vd")
model = RTDetrForObjectDetection.from_pretrained("PekingU/rtdetr_r50vd")

inputs = processor(images=image, return_tensors="pt")
with torch.no_grad():
    outputs = model(**inputs)

# NMSは不要。スコアのしきい値で低信頼の箱を落とすだけ
results = processor.post_process_object_detection(
    outputs, target_sizes=torch.tensor([(image.height, image.width)]), threshold=0.3
)
for score, label, box in zip(results[0]["scores"], results[0]["labels"], results[0]["boxes"]):
    print(model.config.id2label[label.item()], round(score.item(), 2), [round(v, 1) for v in box.tolist()])

このコードを下の実測と同じ環境で実行すると、公式ドキュメントの出力例と同じく、ソファ1件・猫2匹・リモコン2個がスコア0.92〜0.97で検出されました。v2を使う場合はクラス名を RTDetrV2ForObjectDetection、チェックポイントを PekingU/rtdetr_v2_r18vd などに差し替えます。

Ultralyticsによる学習とTensorRT書き出し

YOLOと同じAPIで扱えるのがUltralytics版の利点です。配布されている学習済み重みは rtdetr-l.pt と rtdetr-x.pt の2つだけで、ResNet版はYAMLの構成定義のみ提供されています。

from ultralytics import RTDETR

model = RTDETR("rtdetr-l.pt")
model.train(data="coco8.yaml", epochs=100, imgsz=640, deterministic=False)

# デコーダを4層に打ち切って高速化し、TensorRT（FP16）へ書き出す
head = model.model.model[-1]
head.decoder.eval_idx = 3
model.export(format="engine", device=0, quantize=16)

CUDA上でRT-DETRを学習するときは deterministic=False を指定します。デフォーマブル注意が使う F.grid_sample には決定的な逆伝播が無く、True にしても再現性は得られず学習が遅くなるだけだからです。書き出しの精度指定は、以前の half=True に代わって quantize=16 を使います。

なお、旧来の解説でよく挙がるOpenMMLabのMMDetectionには、RT-DETRの公式設定ファイルがありません。MMDetectionの最新リリースは2024年1月のv3.3.0で止まっているため、これから組むなら上の3経路かPaddleDetectionを選んでください。

RT-DETRをCPUで動かした実測：推論時間・速度調整・重複する箱

論文とUltralyticsが公表している速度は、どれもT4 GPUとTensorRTでの値です。UltralyticsのRTDETRv2とYOLOv8の比較ページでも、RTDETRv2のCPU（ONNX）速度の欄は「-」のままです。そこで、上のTransformersの推論コードをGPUを使わない次の環境で実行し、CPUだけの速度を計測しました（計測ログは編集部で保管）。

• 環境：Intel Core i9-9880H（8コア）、メモリ16GB、macOS。Python 3.11.15、PyTorch 2.2.2、Transformers 4.50.3。PyTorchの演算スレッド数は既定の8
• 入力：上のコードと同じCOCO val2017の画像（640×480）。ImageProcessorが640×640に変換し、バッチは1
• 計測：3回空回ししたあと、モデルの推論（model(**inputs)）だけを20回測った中央値。前処理と後処理は含みません

計時の部分は、上の推論コードの model と inputs をそのまま使う次のコードです。

import statistics, time

with torch.no_grad():
    for _ in range(3):
        model(**inputs)  # 空回し
    ts = []
    for _ in range(20):
        t = time.perf_counter()
        model(**inputs)
        ts.append((time.perf_counter() - t) * 1000)
print(f"{statistics.median(ts):.0f} ms")

4モデルのCPU推論時間：R18とR50で約2倍の差

v1とv2はパラメータ数が同じで、CPUでの速度もほぼ変わりません。速度を決めているのはバックボーンの大きさで、R50はR18の2.1〜2.3倍の時間がかかりました。同じ条件でも実行ごとに1割近く揺れましたが（R50のv1は別の実行で2,876 ms）、最も軽いR18でも1枚1.3〜1.5秒かかり、この環境では毎秒1フレームにも届きません。T4 GPUのR50は108 FPS（1枚約9 ms）と公表されています。TensorRTのFP16とPyTorchのFP32では条件が違うため倍率は出せませんが、桁が2つ違うと考えてください。

デコーダ層とクエリ数を削ったときのCPUでの効果

Transformers版には Ultralytics の eval_idx に当たる引数が無いため、読み込んだモデルのデコーダ層を前から残す数だけ切り出す方法と、設定の初期クエリ数を100にする方法で、同じ調整を再現しました。既定のデコーダ層数はチェックポイントで違い、R18の設定ファイルは3層、R50は6層です。そこでR18は3層から2層へ、R50は6層から4層へ削りました。

# 条件ごとに from_pretrained で読み直してから、どちらか一方だけを適用する
model.model.decoder.layers = model.model.decoder.layers[:2]  # R18の3層を2層で打ち切る（R50なら[:4]）
model.config.num_queries = 100  # 初期クエリを300から100に減らす

デコーダの前後にフックを付け、全体の推論時間のうちデコーダが使った時間も測りました。

この環境では、デコーダが使った時間は全体の11〜13%で、残りの9割近くはデコーダより前の処理（バックボーン、エンコーダ、クエリ選択）でした。層やクエリを削るとデコーダの時間は確かに縮みます（R50の4層化で322 msから234 ms）。しかし全体に対する効果は、R18でも8〜11%にとどまりました。R50の4層化は、全体の時間ではむしろ2,876 msから2,918 msに増えています。最初の表と同じR50の既定条件が3,117 msと2,876 msで1割近く違ったとおり、実行ごとの揺れの方が大きく、短縮は確認できませんでした。T4・TensorRTでRT-DETR-Lを4層にすると8.0 msから7.4 ms（-7.5%）になるのとは対照的です。今回の環境で速くしたいなら、デコーダの調整よりバックボーンをR50からR18に替える方が効きました（処理時間は約半分）。

この1枚の画像では、どの条件でも同じ5物体を拾いました。ただしR18を2層にすると、ソファのスコアが0.81から0.76、リモコン1個が0.79から0.63に下がっています。1枚の結果なので、精度への影響は自分のデータでAPを測って判断してください。

NMSなしでも同じ物体に箱が2つ出る例

最初の表でRT-DETRv2-R18だけ検出数が6件（しきい値0.5）になったのは、1台のソファに箱が2つ出たためです。スコアは0.86と0.82、座標はほぼ画像全体で、2つの箱のIoU（重なりの割合）は0.997でした。同じ画像でv1のR18・R50とv2のR50は、ソファを1件だけ返しています。DETR系は学習時に1物体へ1クエリだけを正解として割り当てますが、推論で重複が出ないことまでは保証されません。

人数や在庫を数える用途では、この1件の差がそのまま誤差になります。対策として、同じクラスで大きく重なる箱を抑えるNMSを、高いIoUしきい値で後処理に足す方法があります。NMSは箱の重なりだけで判断し、同じ物体かどうかは見ていないため、IoUが0.9を超えるほど重なった別々の物体があれば、それも消えます。上のTransformersのコードでクラスを RTDetrV2ForObjectDetection、チェックポイントを PekingU/rtdetr_v2_r18vd に替え、threshold=0.5 で結果を作り直したうえで次のコードを足すと、ソファの重複が消えて5件になりました。batched_nmsは残す箱の番号を返すだけなので、その番号で結果を選び直す行が必要です。

from torchvision.ops import batched_nms

r = results[0]
keep = batched_nms(r["boxes"], r["scores"], r["labels"], iou_threshold=0.9)
r = {k: v[keep] for k, v in r.items()}  # 残す箱だけを選び直す

0.9はこの画像で重複だけが消えた設定例です。密集した物体を数える用途では、しきい値を変えながら自分のデータで数え漏れが出ないかを確かめてから決めてください。

RT-DETRを選ぶ場面・選ばない場面と後継モデル

RT-DETR系が向いているのは、NVIDIA GPUとTensorRTで推論する構成で、Apache 2.0のコードを製品に組み込みたい場合です。論文の速度はT4とTensorRT FP16の数値で、別のGPU、CPU、推論エンジンでの優劣は、この計測値からは判断できません。コミュニティが移植したAndroid（LiteRT GPU）版では、RT-DETRv2-SがPixel 8aで1フレーム約615 ms（静止画）と報告されています。この端末と実装の条件では、毎秒数十フレームを求める動画のリアルタイム処理には足りません。上の実測でも、8コアのIntel CPUでは最小のR18で1枚1.3〜1.5秒かかりました。CPUやモバイルが主戦場なら、軽量なYOLO系から検討する方が現実的です。候補のモデルを自社の画像で比べてから決めたい場合は、画像認識AIモデル構築の支援で、データの準備から精度・速度の比較まで相談できます。

精度をさらに求めるなら、RT-DETRを土台にした後継モデルも候補になります。ただしライセンスは揃っていません。

特にDEIMv2は、COCOでX 57.8 APと高い精度を示していますが、標準のDEIMv2 Licenseは非商用に限られ、商用利用には開発元との別契約が要ります。追加の商用ライセンス契約を避けたい場合は、RT-DETRv4、D-FINE、RF-DETRのApache 2.0版が候補です。DEIMv2も別途商用契約を取得する選択肢があり、いずれも使用する重みと第三者素材の条件を確認して選びます。

よくある質問

DETRとRT-DETRの違いは何ですか？

DETRは2020年にFacebook AI Researchが発表した、Transformerで物体検出をNMSなしに行う最初期のモデルです。論文の比較表ではDETR-DC5（R50）が43.3 APで、学習に500エポックを要するなど収束の遅さも課題でした。RT-DETRはその枠組みを引き継ぎつつ、エンコーダをハイブリッド構成にしてリアルタイム速度を実現したモデルです。

RT-DETRv5はありますか？

2026年10月14日時点で、公式の公開先にはありません。公式リポジトリが最新として案内しているのは2025年11月に公開されたRT-DETRv4で、arXivとGitHubを「RT-DETRv5」で検索しても該当する論文やリポジトリは見つかりませんでした。

RF-DETRとRT-DETRは同じモデルですか？

別のモデルです。RF-DETRはRoboflowが2025年に公開したDETR系の検出器で、DINOv2をバックボーンに使います。名前は似ていますが、開発元も実装も異なります。

RT-DETRの論文はどこで読めますか？

v1はarXiv 2304.08069「DETRs Beat YOLOs on Real-time Object Detection」、v2は2407.17140、v3は2409.08475、v4は2510.25257で公開されています。v1はCVPR 2024の採択論文です。

RT-DETRはCPUだけで動かせますか？

動きます。ただし速度は大きく落ちます。8コアのIntel CPU（Core i9-9880H）でTransformers版を計測した例では、R18で1枚約1.4秒、R50で約3秒でした。1日に処理する枚数と許される待ち時間から必要な速度を逆算し、この速度で足りなければ、NVIDIA GPUとTensorRTを組み合わせた構成を検討してください。

関連記事

• 物体検出とは？仕組み・代表手法の比較から実装判断までエンジニア向けに解説
• YOLOv9のGitHub実装3種の選び方｜MIT版・GPL版のライセンスと実行手順
• SAM 3（SAM3）とは？SAM 2との違い・使い方・ダウンロード手順とSAM 3.1【2026年9月】
• 量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】
• NVIDIA Jetsonとは？Orin・Thorの違いと選定基準・量産判断を実装視点で解説【2026年版】