[Question] Potential Routing Collapse observed in YOLO-Master-v0.1-N.pt via official MoE analysis script

[YuSeanLuo]

Hi YOLO-Master authors,

Thank you for sharing this amazing work! I’ve been experimenting with the pre-trained weights for my project on small object segmentation and deeply appreciate the idea of Instance-conditional adaptive computation.

However, while analyzing the expert utilization of the pre-trained weights (YOLO-Master-v0.1-N.pt) using the official script, I noticed some unusual statistics that look like a potential Routing Collapse. I am a bit confused and would like to seek your clarification.

I used the official script provided at ultralytics/nn/modules/moe/analysis.py to diagnose the YOLO-Master-v0.1-N.pt model on the MS COCO 2017 val dataset (5000 images).

The diagnosis report shows:

1. Total Tokens Processed: 15,003. Since there are 3 router layers and 5001 forward passes (5000 val images + 1 warmup), this perfectly aligns with the instance-level routing design (1 token per image).
2. Static Expert Activation: For all 5001 images, the routers exclusively selected the exact same two experts with exactly a 50/50 split, regardless of the image content or scene complexity.

For example, in model.12.routing:

• Expert 6: 50.00% (5001 Hits)
• Expert 15: 50.00% (5001 Hits)
  (Other layers like model.6.routing and model.9.routing exhibit the exact same 100% static behavior with their respective two experts).

Since the paper emphasizes that the ES-MOE block dynamically allocates computational resources according to scene complexity, I expected the expert distribution to vary across different images (e.g., crowded scenes vs. simple backgrounds).

1. Is this static routing behavior expected for the v0.1-N.pt release? Did this specific checkpoint suffer from load balancing loss collapse during early training, causing it to fall back to a static network?
2. Regarding MoEPruner: I noticed the recent addition of the MoEPruner tool to prune experts with <15% utilization. Was this tool developed specifically to address this kind of routing redundancy observed in the current weights?

Environment:

• Weights: YOLO-Master-v0.1-N.pt (from assets)
• Dataset: MS COCO 2017 val
• Ultralytics Version: 8.3.240
• Device: CPU / GPU (both yield the same logic)

Looking forward to your insights! Thank you again for the great contribution to the community.

[isLinXu]

Thanks for the detailed analysis and for sharing your use case!

Q1: Is this static routing behavior expected in v0.1-N.pt?

No, this is not expected behavior. The router should select different experts conditioned on input complexity. The static 50%/50% split you observed indicates a routing collapse during training — the load balance loss weight (moe_balance_loss) was set too low in the v0.1 release, so the router collapsed to always selecting the same 2 experts regardless of input. The model effectively degenerated into a static network for those routing layers. This is a training bug, not a design intent.

Q2: Is MoEPruner designed specifically for this kind of routing redundancy?

Yes. MoEPruner was developed to handle exactly the type of expert redundancy you observed — it identifies experts with utilization below a threshold (default 15%) and prunes them without retraining. For v0.1 weights, running MoEPruner will remove the unused experts and produce a smaller, faster model. However, it cannot recover dynamic routing — the remaining experts are still selected statically. MoEPruner is most effective when the base model has learned some input-dependent routing but has redundant experts; it's not a fix for routing collapse itself.

Recommendations for your small object segmentation task

1. Try the latest release (v26.02) which includes fixes for MoE training stability (improved balance loss, Z-Loss, gradient accumulation bug fixes):
   👉 https://github.com/Tencent/YOLO-Master/releases/tag/YOLO-Master-v26.02
2. LoRA fine-tuning (recommended for small datasets) — if you're adapting to your own small-object segmentation data, LoRA works particularly well: only ~10% of parameters are trainable, yet it recovers 95-98% of full fine-tuning performance. The routing layers respond well to LoRA adaptation. Enable via lora_r, lora_alpha in config without changing model architecture.
3. If retraining, try increasing moe_balance_loss to [0.05, 0.1] and use analysis.py to monitor expert diversity during training.

Would be great if you could share your analysis.py output after trying the new release — especially curious whether small object scenes trigger different expert combinations with the updated training recipe.

Thanks again for the rigorous analysis!

[YuSeanLuo]

Hi @isLinXu ,

Thank you so much for your prompt and detailed reply! I really appreciate you taking the time to explain the moe_balance_loss issue and providing such practical recommendations. I will certainly apply LoRA and tune the balance loss for my small object segmentation dataset as you suggested.

Just a quick clarification regarding the model version to ensure we are on the same page: The YOLO-Master-v0.1-N.pt I initially tested was indeed downloaded directly from your latest v26.02 release assets. It seems there is a similarly named weight (yolo-master-v0.1-n.pt) in the older v0.0 release, which might have caused the confusion. I am currently using the ones provided in the v26.02 release.

Out of deep interest in your architecture, I went ahead and ran the analysis.py across 5 other weights from the v26.02 release to understand how the routing behaves at different scales. The findings were quite fascinating, and I would love to hear your architectural perspective on them:

1. The EsMoE Series (EsMoE-S, EsMoE-M)
I noticed that these models switch to spatial-level DynamicRoutingLayer. However, across all layers, the utilization is perfectly split at 33.33% for 3 experts. It appears that Top_K is set equal to the total number of experts ($K=3, Total=3$).

• Question: Are the EsMoE series weights intentionally designed as Dense Ensembles (where every token passes through all experts) to maximize performance at these scales, rather than using sparse dynamic routing?

2. The v0.1 Series (v0.1-S, v0.1-M, v0.1-L)
For the instance-level models, I observed that the routing collapse isn't isolated to the Nano model. Even in the Large (L) model, the load remains heavily skewed (e.g., in model.11.routing, 2 experts handle over 60% of the traffic, while several out of the 11 experts are completely DEAD).

• Question: Does this indicate that instance-level routing in dense prediction tasks (like YOLO) is inherently prone to expert domination, even with larger model capacities? Is finding the optimal moe_balance_loss a general bottleneck for scaling this specific architecture?

I am not pointing these out as flaws, but rather as very interesting phenomena regarding the training dynamics of MoE in real-time object detection. Since I am adapting this for my own research, understanding whether to pursue the "Dense Ensemble" route (EsMoE) or try to salvage the "Sparse Routing" route (v0.1) via custom loss tuning is crucial for my next steps.

Thanks again for your tremendous contribution, your time, and your guidance!