[Feature Request] Consider Upstreaming Optional MoE Routing and Detector-Aware PEFT Support

Search before asking

• I have searched the Ultralytics issues and found no similar feature requests.

Description

Search before asking

• I have searched the existing Ultralytics issues and found no equivalent feature request.

Description

Hi @glenn-jocher and the Ultralytics team,

I am Xu Lin, the first author of the YOLO-Master and YOLO-PEFT papers.

I would like to ask for maintainer guidance before preparing any pull request. We have developed two optional research features on top of the Ultralytics codebase:

1. YOLO-Master: Efficient Sparse Mixture-of-Experts for real-time detection

   YOLO-Master introduces ES-MoE blocks and lightweight dynamic routing for instance-conditional computation. The implementation includes YAML-defined MoE model configurations, top-k expert routing, auxiliary load-balancing/stability losses, and expert utilization diagnostics.

2. YOLO-PEFT: Structure-aware Parameter-Efficient Fine-Tuning for YOLO

   YOLO-PEFT treats adapter placement as an auditable planning problem. It analyzes the detector graph, validates candidate target modules, allocates adapter budgets, rejects unsafe placements before training, and supports train/save/merge/export workflows.

This issue is not requesting that the entire YOLO-Master repository be merged into Ultralytics as-is. Instead, I would like to confirm whether either of these capabilities is relevant to the Ultralytics roadmap and whether the team would be open to a focused upstream implementation.

Proposed upstream scope

Track	Suggested initial upstream scope	Not required in the first PR
Optional MoE routing	A generic MoE/router module, YAML configuration support, optional auxiliary-loss hooks, unit tests, and clear export/backend behavior	All experimental variants, MoE pruning, CW-NMS, Sparse SAHI, and backend-specific optimizations
Detector-aware PEFT	Optional adapter registration, target-module validation, LoRA/RS-LoRA support, adapter save/merge/export, and documentation	Every adapter algorithm, the full research planner, and calibration policies for unsupported architectures

The two tracks can be implemented and reviewed independently.

Why this may be useful

• MoE routing can allocate more capacity to difficult or crowded scenes while keeping the default dense YOLO path unchanged.
• PEFT can reduce the cost of adapting YOLO models to new domains, datasets, or industrial scenarios.
• Merged adapters can be exported as ordinary YOLO models without inference-time adapter overhead.
• Both features can remain opt-in and should not change existing model behavior or default configurations.

Compatibility and maintenance constraints

We would follow the following principles:

• Existing Ultralytics models and training commands remain backward compatible.
• Additional PEFT dependencies remain optional.
• MoE deployment behavior is documented explicitly for each backend; no assumption is made that every runtime provides actual sparse-computation speedups.
• New functionality is covered by unit tests, training/validation/inference tests, export checks, and baseline comparisons.
• The first contribution would be narrowly scoped and aligned with the Ultralytics API and coding style.

Questions for the maintainers

1. Would optional MoE or conditional-routing support be considered within the Ultralytics roadmap?
2. Would generic detector-aware PEFT/LoRA support be considered within the roadmap?
3. If these features are potentially acceptable, would you prefer two separate issues and pull requests?
4. What would be the minimum acceptable API, supported model families, backend coverage, and benchmark requirements?
5. If these features are not suitable for the core repository, would an official extension package or integration guide be preferable?

For reference:

• YOLO-Master: https://github.com/Tencent/YOLO-Master
• YOLO-Master paper: https://arxiv.org/abs/2512.23273
• YOLO-PEFT paper: https://arxiv.org/abs/2608.07051

The published results are research results, and we would be happy to reproduce the relevant benchmarks under the Ultralytics evaluation and deployment protocol before submitting a PR.

Use case

The main use cases are:

• real-time detection under changing scene complexity;
• deployment on compute-constrained edge devices;
• rapid domain adaptation without storing a complete fine-tuned model for every domain;
• reproducible research on efficient YOLO architectures and adaptation.

Additional

The YOLO-Master repository is released under AGPL-3.0. I am willing to follow the Ultralytics contribution guidelines, CLA requirements, testing requirements, and any maintainer-defined implementation scope.

Are you willing to submit a PR?

Yes. I am willing to prepare and maintain a focused pull request after the scope and acceptance criteria are approved by the maintainers.

Use case

No response

Additional

No response

Are you willing to submit a PR?

• Yes I'd like to help by submitting a PR!