YOLO-PEFT plans PEFT adapter placement for YOLO object detectors

Key facts

• Under the VOC07+12 trainval-to-VOC07 protocol, planner-selected RS-LoRA reached 0.7138 mAP50-95 on YOLO11s and 0.7307 on YOLO12s, versus 0.6428 and 0.6662 for full fine-tuning (Full-SFT) on the same models.
• On RT-DETR-L, all seven evaluated LoRA-family configurations crossed a predefined catastrophic-failure threshold, so the planner issued a calibrated Refuse-to-Full-SFT decision for that architecture.
• A controlled YOLO11 audit found LoRA cuts peak training memory by 43.9 percent but makes training 1.72 times slower than the compared setup.
• YOLO-PEFT checks each candidate adapter placement against four predicate categories, operator-validity, detector-semantic, graph-interface and deployment, logging a reason code for every excluded module.
• The authors say refusal behavior on detector architectures outside the evaluated coverage remains an open, unvalidated question.

Why it matters

PEFT techniques were designed around regular Transformer stacks. Applying them to YOLO-family real-time detectors without change can fail silently, the authors say, because those detectors have heterogeneous operators and detection-specific components that impose placement constraints ordinary Transformer PEFT never has to deal with. YOLO-PEFT's proposal is to replace ad hoc, trial-and-error adapter placement with an explicit planning step that checks each candidate module against stated rules before any training runs, and that either produces a budgeted plan or refuses outright when the setup looks unsafe.

Who it affects

Anyone fine-tuning real-time object detectors from the YOLO family (evaluation covered YOLO11 and YOLO12), plus RT-DETR-L as a comparison architecture, using parameter-efficient methods instead of full fine-tuning. More broadly, it targets teams building PEFT tooling for model architectures that fall outside the standard Transformer mold the original PEFT methods were designed for.

How to use it

The framework takes three inputs: a detector's computation graph, a PEFT request and a resource budget. It assigns operator and semantic roles, runs its four predicate checks, and outputs either a budgeted target-module plan or a Refuse decision before training starts, aiming to preserve verified train-save-merge-export paths. A project page is linked at github.com/Tencent/YOLO-Master; the source text gives no pricing, license or authorship information.

How solid is it

Results are reported under the official VOC07+12 trainval-to-VOC07 test protocol on YOLO11s and YOLO12s, where planner-selected RS-LoRA beat Full-SFT (0.7138 vs 0.6428 mAP50-95, and 0.7307 vs 0.6662, respectively), plus a separate evaluation on RT-DETR-L where the planner instead refused LoRA in favor of full fine-tuning after all seven tested LoRA-family configurations crossed a catastrophic-failure threshold. A controlled YOLO11 audit adds a memory-versus-speed trade-off: 43.9 percent less peak training memory against 1.72 times longer training. The evidence spans a small set of detector families and a single benchmark protocol.

Risks and caveats

The source text does not name individual authors or institutions, only linking a project page; it does not say who authored or funded the work, and gives no publication or submission date. It also does not define how the "predefined catastrophic threshold" on RT-DETR-L was set, or state exactly what baseline the 43.9 percent memory reduction and 1.72x training-time figures were measured against beyond "a controlled YOLO11 audit." The authors themselves note that refusal behavior on detector architectures not covered by their evaluation is still an open, unvalidated question.