YOLO-Master v26.08 — Release Report

_{2026-08-21 · Ultralytics 8.4.101 / YOLO26 · CVPR 2026}

YOLO-Master v26.08 evolves from an MoE detector into a routed real-time vision framework.

It learns not just what to see, but where, how, and for which task to compute.

🔀 Routed Architecture	🎯 MultiTask	🔧 PEFT Adaptation	⚡ Edge Deployment
MoE · MoA · MoT · Latent	detect · seg · pose	LoRA · MoLoRA · Planner	5 backends

✅ 377 passed · ⚡ YOLO26 compatible · 🖥️ Live Demo

📚 Docs · 📊 Model Zoo · 💬 Discuss · 🔄 Diff

📑 Navigation

Overview · Architecture · Mixture · PEFT · MultiTask · Edge · Reliability · Capability · Benchmarks · Migration · Limitations

🌟 Overview

Important

v26.08 is a cumulative release from YOLO-Master-v26.02. It rebases on Ultralytics 8.4.101 / YOLO26, integrates five routing families (MoE, MoA, MoT, Latent Mixture, MoLoRA) under a shared protocol, adds four PEFT paths (Standard LoRA, Planner/V-PEFT, MoLoRA, FewShot-LoRA), enables preview MultiTask learning (detect/segment/pose), and hardens the full lifecycle — from training through export to deployment — with P0-P2 evidence.

YOLO-Master no longer describes itself as just "an MoE detector." v26.08 introduces routing as a first-class framework abstraction:

Architecture Routing — which expert / attention head / transformer / latent channel computes
Adaptation Routing — which parameters are trained, at what rank, through which adapter expert
Task Routing — which task branch activates for each spatial token

All three axes share a single routing protocol for auxiliary loss collection, temperature scheduling, and diagnostics. CompositeCriterion collects by family with EMA normalization, global budgeting, and NaN isolation.

v26.08 conceptual overview: unified tasks, routed architectures, parameter-efficient adaptation, cross-platform deployment.

Release at a Glance


Release range	`YOLO-Master-v26.02` → `YOLO-Master-v26.08`
Audited history	637 commits (517 non-merge + 120 merge) · 34 author identities
Upstream upgrade	Ultralytics `8.3.240` → `8.4.101`
Native model family	YOLO26 detect · segment · semantic · pose · OBB · classify · YOLOE
Release gate	377 passed · 1 xfailed (mixture/P0-P2 scope)
Model catalog	7 evaluated checkpoints · 3 pending/evaluating variants
License	AGPL-3.0

Release Provenance

Artifact	Value
Source tag	`YOLO-Master-v26.08`
Tag target	`git rev-parse YOLO-Master-v26.08^{}`
Python package	`ultralytics==8.4.101`
Published assets	`.whl` · `.tar.gz` (see Releases)
Comparison base	`YOLO-Master-v26.02`

Why Upgrade?

Reason	Detail
🔼 New foundation	YOLO26 native task / checkpoint / export contracts from Ultralytics `8.4.101`
🔀 Unified routing	Shared protocol for MoE, MoA, MoT, Latent Mixture, MoLoRA aux losses, temperature scheduling, diagnostics, export reporting
🎛️ Multiple adaptation paths	Fixed-rank LoRA · PEFT Planner · FewShot-LoRA · Routed MoLoRA adapters
📦 Cross-platform deployment	ONNX Runtime · NCNN · MNN · TensorRT · Core ML on Windows / Linux / Jetson / macOS

Canonical release notes: docs/release-notes/v26.08.md — P0-P2 hardening summary, validation evidence, migration steps, known limitations.

📄 Accompanying Paper

[!NOTE]
YOLO-PEFT: Parameter-Efficient Fine-Tuning on YOLO Family — the accompanying paper is now available on arXiv.
Code and experiments are already included in v26.08.

The YOLO-PEFT framework: a four-stage parameter-efficient fine-tuning pipeline. (1) Parse — the detector graph (YOLO11 / YOLO12 / YOLO-World / RT-DETR / YOLO-Master) is reduced to a role-aware typed graph with operator role and semantic role annotations. (2) Plan — a structure-aware planner enumerates candidates (Conv, Linear, Attention), filters structurally-blocked operators (DWConv, DFL, Router), applies constraints, performs budget-aware rank assignment under Σcᵢ(rᵢ) ≤ B, and emits a resolved placement plan π or refuses back to full fine-tuning. (3) Train — YOLO-compatible runtime treats the detector as frozen base W₀ plus trainable sidecar ΔW(π). (4) Deploy — optional adapter merge for zero-overhead inference, export to ONNX / TensorRT.

Tip

Citation. Read the accompanying paper on arXiv.

🚀 From v26.02 to v26.08

v26.02 established ES-MoE, standard LoRA, Sparse SAHI, CW-NMS, and basic MoE loss/pruning on Ultralytics 8.3.240. v26.08 transforms this foundation into a routed vision framework with explicit parser, loss, checkpoint, data, export, and validation contracts.

Concern	v26.02	v26.08
Foundation	Ultralytics `8.3.240`	Ultralytics `8.4.101` + YOLO26 native family
Conditional compute	ES-MoE + basic routing	MoE / MoA / MoT / Latent Mixture / MoLoRA — shared routing protocol, dynamic scheduling, diagnostics, shared-expert reuse, loss budgeting
Adaptation	Fixed-rank LoRA	Standard LoRA + FewShot-LoRA + Planner / V-PEFT + LOVO + Routed MoLoRA
Task coverage	Detection only	Native YOLO26 family + MultiTask preview (detect / segment / pose)
Deployment	Sparse SAHI + CW-NMS	Export preflight + capability matrix + documented ONNX / NCNN / MNN / TensorRT / Core ML paths
Operational	Per-feature tests	P0-P2 lifecycle: AMP / MPS / DDP / EMA / checkpoints / NaN recovery / catalog / audits

Development Timeline

Period	Evolution	v26.08 Artifact
Feb 2026	v26.02: ES-MoE, LoRA, Sparse SAHI, CW-NMS	Original detection + sparse inference + fixed-rank adaptation
May–Jun	FewShot-LoRA, MoE routing fixes, MoA / MoT blocks, ablation tooling	Routed attention + transformer paths beyond conv experts
Early Jul	MoLoRA, LOVO, V-PEFT / Planner, model profiles, C++ edge examples	Architecture-aware PEFT planning and adapter runtime
Mid–Late Jul	AMP safety, DDP / EMA / checkpoint hardening, NaN recovery, export preflight, `8.4.101` rebase	Numerical, distributed, checkpoint, export boundaries
Early Aug	Shared Expert MoE, Latent Mixture contracts, MultiTask integration, COCO smoke profiles	Model-scoped expert reuse + detect / segment / pose MultiTask

Feature evolution roadmap and architectural milestones from v26.02 to v26.08.

🏷️ Production & Research Surface

v26.08 separates features into two clear regions to avoid "feature zoo" perception.

Project Identity: Core / Framework / Labs

YOLO-Master is no longer just one paper's codebase — it is a growing platform. v26.08 defines three layers with distinct expectations:

Layer	Scope	Evidence Standard	Examples
YOLO-Master Core	The CVPR 2026 detection paper	Published checkpoints, full COCO benchmarks, Pareto analysis	ES-MoE, Dense baseline
YOLO-Master Framework	Shared infrastructure for all routing families	Component-level contracts, CI gate, export preflight	Routing Protocol, CompositeCriterion, Mixture Registry, PEFT, MultiTask, Export
YOLO-Master Labs	Research modules exploring new routing surfaces	Functional interfaces, build/forward verification	MoA, MoT, Latent Mixture, MoLoRA, V-PEFT

This separation ensures:

Core users see a clear, validated product with published evidence.
Framework consumers see robust infrastructure they can build on.
Labs explorers know which modules are research-grade and have no accuracy/latency claims.

Three-Axis Status: API Maturity × Accuracy Evidence × Export Readiness

Previous releases used a single status label (STABLE / VALIDATED / EXPERIMENTAL / OPT-IN) that conflated API maturity, evidence level, and default-enablement. v26.08 separates these concerns:

Feature	API Maturity	Accuracy Evidence	Export
ES-MoE	Stable	✅ Published (N/S/M, full COCO)	ONNX ✅ · TRT △
Shared Expert MoE	Stable	△ Component-level only	ONNX ✅ · TRT △
MoA	Experimental	△ Build/forward verified	ONNX dense ✅ · TRT ?
MoT	Experimental	△ Build/forward verified	ONNX dense ✅ · TRT ?
Latent Mixture	Experimental	△ Build/forward verified	ONNX dense ✅ · TRT ?
MultiTask	Preview	△ Detect/seg/pose partial	ONNX △ · TRT ?
Standard LoRA	Stable	✅ Published benchmarks	Merge ✅
PEFT Planner / V-PEFT	Beta	△ Solver contracts verified	Merge ✅
MoLoRA	Beta	△ Routing-aware merge verified	Merge ✅
FewShot-LoRA / LOVO	Beta	△ Strategy comparison API	Merge ✅

Status key — API Maturity: Stable = public API, backward-compatible · Beta = opt-in, may evolve · Preview = working, not yet API-stable · Experimental = research interface, may change without notice.

Accuracy Evidence: ✅ = published end-to-end metrics · △ = component-level tests pass, no full training run published.

Export: ✅ = hardware-verified · △ = ONNX round-trip passes, no hardware validation · ? = untested.

Production Surface

Stable, validated, and documented for users who want to adopt v26.08 today.

Module	What It Delivers
🏗️ YOLO26 / Ultralytics 8.4.101	Native task flows, checkpoint compat, export integrity, additive mixture registration
⚡ ES-MoE (Backbone)	Sparse expert routing with released checkpoints (N/S/M), COCO benchmark evidence
🔁 Shared Expert MoE	Model-scoped expert-pool reuse with cross-model isolation
🎯 Standard LoRA	Fixed-rank adaptation, all model families, documented benchmarks
📦 ONNX / NCNN / MNN	C++ backends with Windows GUI, Jetson benchmark
🛡️ Export Governance	Export preflight, capability matrix, backend compatibility validation

Research Surface

Opt-in profiles with functional interfaces — no release-level accuracy or latency claim.

Module	What It Delivers
⚡ MoA (Routed Attention)	Local/regional/global attention paths, soft mixture, optional sparse eval
🔄 MoT (Routed Transformers)	Transformer experts over spatial tokens, soft Top-K gating, scene-aware routing
🌌 Latent Mixture	Dense latent routing, configurable init/noise, calibration-gated inference
🔀 MultiTask	Detect / segment / pose from shared backbone with TaskRouter
🧠 PEFT Planner / V-PEFT	Architecture-conditioned adapter placement, AO/DCO/MIP solvers
🎛️ MoLoRA	Sparse routing over low-rank adapter experts, routing-aware merge
📡 FewShot-LoRA / LOVO	Scheduled DropConnect, teacher distillation, adaptation strategy comparison

⚡ Quick Start

Install v26.08 (Recommended — Pinned to Release Tag)

git clone --branch YOLO-Master-v26.08 --depth 1 https://github.com/Tencent/YOLO-Master.git
cd YOLO-Master && pip install -e .
yolo version && yolo checks

This ensures you get the exact audited v26.08 commit (637 commits, 377 passed gate), not whatever is on main.

Install from main (Nightly / Development)

git clone https://github.com/Tencent/YOLO-Master.git
cd YOLO-Master && pip install -e .

Architecture Selection Guide

Use Case	Model YAML	Status
Native YOLO26 baseline	`ultralytics/cfg/models/26/yolo26.yaml`	Stable
YOLO26 + MoE blocks	`ultralytics/cfg/models/26/yolo26-master-n.yaml`	Experimental
Multi-task training	`ultralytics/cfg/models/26/yolo26-master-mt-n.yaml`	Preview
Shared expert parameters	`.../v0_8/det/yolo-master-moe-mot-shared-n.yaml`	Validated
MoA + MoT routing	`.../v0_10/det/yolo-master-moa-mot-n.yaml`	Experimental
Latent-space routing	`.../26/yolo26-master-latent-n.yaml`	Experimental
Routed LoRA adapters	`yolo26.yaml` + `molora_*` args	Opt-in

from ultralytics import YOLO

# Multi-task: detect + segment + pose
multitask = YOLO("ultralytics/cfg/models/26/yolo26-master-mt-n.yaml", task="multitask")

# Shared Expert MoE
shared = YOLO("ultralytics/cfg/models/master/v0_8/det/yolo-master-moe-mot-shared-n.yaml")

# MoA + MoT combined
moa_mot = YOLO("ultralytics/cfg/models/master/v0_10/det/yolo-master-moa-mot-n.yaml")

# Latent Mixture
latent = YOLO("ultralytics/cfg/models/26/yolo26-master-latent-n.yaml")

WebUI

Live WebUI: task selection, interactive inference controls, visual output, and structured detection results.
Open Live Demo · python app.py for local launch

Note

Mixture features are selected through model YAML files, not undocumented CLI flags.

1. Unified Routing Architecture

v26.08's primary architectural innovation is that routing is no longer a per-module implementation detail — it is a framework-level abstraction. Three independent routing axes share a common protocol, loss collection, and diagnostic surface.

                         YOLO-Master
                              │
                  Adaptive / Routed Vision
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
Architecture Routing    Adaptation Routing      Task Routing
       │                      │                      │
 MoE / MoA / MoT       LoRA / MoLoRA / PEFT      TaskRouter
 Latent Mixture                                  MultiTask Heads
       │                      │                      │
       └──────────────────────┼──────────────────────┘
                              │
                    Shared Routing Protocol
                              │
             Train / Diagnose / Export / Deploy

YOLO-Master v26.08 preserves the standard Ultralytics parse_model() pipeline as its construction entry point while adding a parallel mixture resolution layer. Four complementary mixture surfaces — backbone expert routing, neck attention/transformer routing, and head-fusion latent routing — operate alongside an independent PEFT adapter injection plane.

┌──────────────────────────────────────────────────────────────────┐
│                        MODEL YAML                                 │
│  parse_model() + mixture_registry → additive profile resolution  │
└──────────┬────────────────────┬──────────────────┬───────────────┘
           ▼                    ▼                  ▼
   ┌──────────────┐   ┌──────────────┐   ┌──────────────────┐
   │  BACKBONE     │   │    NECK       │   │   HEAD FUSION     │
   │  ES-MoE       │   │  MoA (routed  │   │  Latent Mixture   │
   │  Gated MoE    │   │   attention)  │   │  (dense routing   │
   │  Shared MoE   │   │  MoT (routed  │   │   + calib gate)   │
   │  (Top-K/gated)│   │   transformer)│   │                    │
   └──────┬────────┘   └──────┬───────┘   └────────┬───────────┘
          │                   │                     │
          └───────────────────┼─────────────────────┘
                              │
                    ┌─────────▼─────────┐
                    │  SHARED ROUTING    │
                    │  PROTOCOL          │
                    │  aux loss + temp   │
                    │  scheduling + diag │
                    └─────────┬─────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
     ┌────────────┐  ┌────────────┐  ┌──────────────┐
     │ PEFT CTRL   │  │Native/Multi│  │  Composite    │
     │ Planner →   │  │Task Heads  │  │  Criterion    │
     │ MoLoRA inj. │  │det/seg/pose│  │  EMA+budget+  │
     └────────────┘  └─────┬──────┘  │  NaN isolation │
                           │         └───────┬────────┘
                           │                 │
                    ┌──────▼─────────────────▼──────┐
                    │     TRAINER                     │
                    │  AMP · DDP · EMA · checkpoint  │
                    └────────────────────────────────┘

System architecture. Model YAML drives both upstream parsing and additive mixture resolution. PEFT flows through a separate Planner/V-PEFT → MoLoRA control plane. All routed modules publish losses through a single protocol facade; CompositeCriterion collects by family with EMA normalization, global budgeting, and NaN isolation.

1.1 Routing Protocol

The shared routing protocol (ultralytics/nn/modules/routing_protocol.py) is the single canonical interface for all five routing families. Each routed module calls publish_aux_loss() during forward, passing a family identifier, loss tensor, and optional diagnostics.

Three guarantees:

Deduplication. Losses collected once per covered_modules set — a module visited through multiple forward paths is not double-counted.
Stale-record rejection. Loss records from eval or non-training contexts are discarded; the protocol enforces detach-zero at publish time.
Detached diagnostics. Diagnostic tensors preserved with .detach(), separating monitoring signals from gradient computation.

1.2 Composite Criterion

CompositeCriterion consumes published auxiliary losses in three stages:

Per-family EMA normalization — configurable decay smooths loss magnitudes across steps.
Global auxiliary budget — proportional gain layer prevents any family from dominating.
Non-finite isolation — a NaN in one family is isolated and synchronized across all DDP ranks before the primary task loss is computed, preventing cross-contamination.

1.3 Mixture Surface Taxonomy

Layer	Family	Routing Object	Placement	Execution Boundary
Backbone	ES-MoE, Gated MoE, Shared MoE	Conv/FFN expert weights (Top-K / gated)	Feature stages	Sparse dispatch (eager); model-scoped sharing
Neck	MoA	Local, regional, global attention paths	FPN attention blocks	Soft mixture (dense); optional batch-level sparse skip
Neck	MoT	Transformer experts over spatial tokens	Transformer blocks	Dense training; Top-K eager eval; `TaskRouter` separate
Head fusion	Latent Mixture	Image-level latent expert probs	Multi-scale fusion	Dense training; calibration-gated sparse inference
PEFT	MoLoRA	Adapter-expert Top-K weights	Runtime around Linear / Conv2d	Standard LoRA mutually exclusive with MoLoRA

Important

Routing ≠ task selection. MoT provides shared visual representations. TaskRouter computes per-token task affinity and applies task / shared feature gates to every YAML-enabled branch — YAML plus the dataset contract decide which branches are built and supervised. Neither router chooses one final task output at inference time.

Implementation map: ultralytics/nn/tasks.py · ultralytics/nn/mixture_registry.py · ultralytics/nn/modules/routing_protocol.py · ultralytics/nn/mixture_loss.py · ultralytics/data/multitask_sampler.py · ultralytics/nn/peft/molora/ · ultralytics/utils/export_preflight.py

Full report: YOLO-Master Deep Architecture Analysis

📊 Capability Matrix

Architecture × Task × Feature support, verified against v26.08 evidence. ✓ = verified, △ = experimental/unverified, — = not supported.

Architecture	Detect	Seg	Pose	PEFT	Sparse Infer.	ONNX	TensorRT	Status
YOLO26	✓	✓	✓	✓	—	✓	✓	Stable
ES-MoE	✓	—	—	✓	✓	✓	△	Stable
Shared-MoE	✓	—	—	✓	✓	✓	△	Validated
MoA	✓	—	—	✓	opt.	✓ dense	?	Experimental
MoT	✓	—	—	✓	✓	✓ dense	?	Experimental
Latent	✓	—	—	✓	✓	✓ dense	?	Experimental
MultiTask	✓	✓	✓	△	—	△	?	Preview

△ = component-level contracts pass; no full TensorRT validation for routed profiles. Core ML blocked by coremltools/SciPy environment issue.

2. Mixture Subsystems

2.1 Ultralytics 8.4.101 + YOLO26 Modernization

v26.08 rebases on Ultralytics 8.4.101. All mixture features (MoE / MoA / MoT / MoLoRA / V-PEFT / Agent) are additive extensions — they never replace upstream task implementations.

Compatibility Boundary	v26.08 Behavior
Official YOLO26 configs	All native YAML files preserved (detect / seg / pose / OBB / sem / cls / YOLOE)
End-to-end heads	YOLO26 detection-style heads retain `reg_max=1`, `end2end=True`, one-to-many / one-to-one branches
Train / predict / val / export	Native Ultralytics flows intact for official YOLO26 models
Mixture models	Registered as additive YAML profiles (no overwrite)
PEFT targeting	Specialized heads excluded unless `lora_include_head=True`
Checkpoints	Native fields preserved; mixture metadata added separately
Integrity boundary	Config + backend hashes recorded in `upstream-v8.4.101-manifest.json`

Native baseline (8 tasks, all verified: build + finite forward):

Task	Config	Task	Config
Detect	`yolo26.yaml`	OBB	`yolo26-obb.yaml`
Instance Seg	`yolo26-seg.yaml`	Classify	`yolo26-cls.yaml`
Semantic Seg	`yolo26-sem.yaml`	YOLOE-Detect	`yoloe-26.yaml`
Pose	`yolo26-pose.yaml`	YOLOE-Seg	`yoloe-26-seg.yaml`

yolo mixtures kind=mot task=detect      # discover mixture profiles
yolo mixtures kind=latent format=json

📁 docs/en/guides/yolo26-mixture-compatibility.md · docs/governance/upstream-v8.4.101-manifest.json · reports/migration/v8.4.101-native-baseline.json

2.2 Backbone MoE

The backbone MoE subsystem is the most mature mixture surface. ES-MoE applies Top-K routing over convolutional expert weights — each expert is a lightweight Conv2d block, the router a linear projection computing per-token affinities. All experts execute densely during training (GShard-style balance loss encourages uniformity); only Top-K (K=2) dispatch during evaluation.

Configuration is entirely YAML-driven through profiles under ultralytics/cfg/models/master/v0_10/det/.

ES-MoE backbone routing: expert activation distribution, Top-K gating across backbone stages, and load-balancing auxiliary loss dynamics during training.

2.3 Shared Expert MoE

SharedExpertMoE introduces model-scoped parameter reuse through pool_id. Multiple blocks sharing a pool_id reference a single fused_experts module, reducing total expert parameters without changing forward computation.

backbone:
  - [-1, 1, SharedExpertMoE, [512, 4, 2, 0.5, 8, 1.2, 0.5, 1.0, 1.0, 0.01, 8, 2, 0.5, "p3_p4"]]
  - [-1, 1, SharedExpertMoE, [512, 4, 2, 0.5, 8, 1.2, 0.5, 1.0, 1.0, 0.01, 8, 2, 0.5, "p3_p4"]]

The temporary registry tracking pool assignments is cleared at model boundaries during parse_model(), guaranteeing cross-model isolation.

Note

Source-level estimates suggest 25–50% expert parameter reduction with sharing. Not published as end-to-end measurement in v26.08.

2.4 MoA — Mixture of Attention

MoA combines local, regional, and global attention paths behind a shared router. Unlike MoE's sparse dispatch, MoA is a dense soft mixture: all three head groups execute every forward pass, and the router produces per-group fusion weights rather than discrete selection.

Parameter	Type	Purpose
`moa_local_window_size`	int	Local self-attention window
`moa_regional_max_kv_tokens`	int	Regional KV token cap
`moa_sparse_inference`	bool	Skip low-weight head groups at eval (opt-in)
`moa_sparse_inference_threshold`	float	Weight threshold for sparse eval

2.5 MoT — Mixture of Transformers

MoT routes spatial tokens through transformer-style experts in the neck using soft Top-K gating.

Parameter	Type	Purpose
`mot_balance_loss`	float	GShard balance-loss coefficient
`mot_router_z_loss`	float	Router z-loss for training stability
`mot_sparse_train`	bool	Sparse dispatch during training
`mot_scene_aware_router`	bool	Experimental scene-aware routing branch

model = YOLO("ultralytics/cfg/models/master/v0_10/det/yolo-master-moa-mot-n.yaml")
model.train(data="coco8.yaml", epochs=100,
            moa_sparse_inference=False, mot_balance_loss=0.01,
            moa_mot_temperature_factor=0.97, moa_mot_min_temperature=0.3)

2.6 Latent Mixture

Latent Mixture projects multi-scale feature maps into a shared latent space, routes through lightweight channel experts, and publishes balance / z-loss through the routing protocol.

Design Choice	Default	What It Means
`value_fusion_mode`	`"router_only"`	Auxiliary inputs affect routing probabilities but are NOT fused as expert values.
Training execution	Dense	All channel experts execute; router produces soft weights.
Inference execution	Configurable `top_k`	Sparse dispatch; optionally calibration-gated.
Router init	Configurable `router_init_std`	Gaussian with configurable standard deviation.
Temperature schedule	Multiplicative decay	`factor × current_temp`, floored at `min_temperature`.

Config governance. v26.08 fixes a critical parser flaw: the configuration dict has 13 validated fields, unknown keys are rejected at parse time, and checkpoint YAML provenance enables reconstruction without non-persistent buffers.

model = YOLO("ultralytics/cfg/models/26/yolo26-master-latent-n-initperturb020-temp05.yaml")
model.train(data="coco8.yaml", epochs=100, latent_inference_top_k=2,
            moa_mot_temperature_factor=0.97, moa_mot_min_temperature=0.3)

Latent Mixture routing pipeline: multi-scale feature projection into shared latent space, channel expert dispatch with configurable top-k, and calibration-gated inference with dense fallback.

3. PEFT Adaptation

Four adaptation paths, from simple fixed-rank LoRA to architecture-conditioned placement with routed adapter experts.

PEFT adaptation landscape: Planner/V-PEFT per-layer placement pipeline (ACCEPT / ADAPT / REFUSE), MoLoRA routed adapter injection with Top-K expert dispatch, and FewShot-LoRA scheduled DropConnect mechanism.

3.1 Standard LoRA

Fully preserved from v26.02 — the recommended starting point:

model = YOLO("yolo26n.pt")
model.train(data="coco8.yaml", epochs=100, lora_r=16, lora_alpha=32)

3.2 PEFT Planner

Architecture-conditioned adapter placement via lora_planner_enabled=True. The planner evaluates model structure and returns per-layer decisions: ACCEPT (apply LoRA at requested rank), ADAPT (modified rank), or REFUSE (skip this layer). The V-PEFT backend provides three solvers: AO (Architecture-Optimized), DCO (Dimension-Constrained), and MIP (Mixed-Integer Programming).

model.train(data="coco8.yaml", epochs=100, lora_r=16,
            lora_planner_enabled=True, lora_adapter_budget=500_000,
            lora_planner_solver="ao", lora_planner_backend="vpeft")

3.3 MoLoRA — Routed Adapter Experts

MoLoRA extends standard LoRA with sparse Top-K routing over multiple low-rank adapter experts.

Parameter	Type	Description
`molora_num_experts`	int	Adapter expert count (0 = disabled)
`molora_top_k`	int	Experts activated per forward pass
`molora_r`	int	Low-rank dimension per expert
`molora_alpha`	int	Adapter output scaling
`molora_router_type`	str	Router architecture (`"linear"` / `"mlp"`)

model = YOLO("yolo26n.pt")
model.train(data="coco8.yaml", epochs=100,
            molora_num_experts=4, molora_top_k=2,
            molora_r=8, molora_alpha=16, molora_router_type="linear")

Warning

lora_r > 0 and molora_num_experts > 0 together → intentionally rejected. Standard LoRA and MoLoRA are mutually exclusive.

3.4 FewShot-LoRA and LOVO

FewShot-LoRA adds scheduled DropConnect on adapter weights (cosine schedule), optional teacher distillation, and variational rank selection.

LOVO (Leave-One-Variant-Out) is a Python validation API for comparing adaptation strategies:

from ultralytics.utils.lora import LOVODataCollector, LOVOValidator
collector = LOVODataCollector.load("reports/lovo_data.json")
result = LOVOValidator().validate(collector)
result.save("reports/lovo_validation.json")

4. MultiTask Learning

The MultiTask subsystem enables joint training for detection, instance segmentation, and human pose from a shared backbone and neck.

                     Shared Backbone + Neck
                               │
                      Optional TaskRouter
                      (per-token affinity,
                       task/shared gates)
                               │
 ┌──────────┬─────────┬──────┬──────────┬───────┬─────┐
 │ Detect   │ Segment │ Pose │ Classify │ Depth │ OBB │
 │ (active) │(active) │(active)│(criterion│(criterion│ (rejected)
 │          │         │      │ only)   │ only)  │     │
 └──────────┴─────────┴──────┴──────────┴───────┴─────┘

MultiTask head architecture. Shipped profile: detect + segment + pose.

Component Roles

Component	Role
`MultiTaskHead`	Builds task-specific branches from model + dataset task lists
`TaskRouter`	Content-based spatial-token routing to task / shared feature channels
`MultiTaskLoss`	Combines losses only for tasks with valid supervision
`MultiTaskBatchSampler`	Weighted or round-robin sampling; DDP-aware, resumable state

MultiTask training results: per-task loss convergence curves, task-wise mAP progression for detect / segment / pose, and TaskRouter token affinity distribution across spatial positions.

Training Contract

yolo multitask train \
  model=ultralytics/cfg/models/26/yolo26-master-mt-n.yaml \
  data=ultralytics/cfg/datasets/coco-multitask-unified.yaml \
  epochs=100 imgsz=640

Note

Current scope: detect + segment + pose with aligned COCO annotations. Multi-output inference beyond DetectionPredictor is not documented as a public API.

5. Edge Deployment

Five inference backends across four operating systems, built on a shared C++ runtime.

Backend	Integration	Targets	Acceleration
ONNX Runtime	C++ backend + Windows GUI	Linux, Windows	CPU, CUDA
NCNN	C++ backend + Windows GUI	x86, ARM	Vulkan
MNN	C++ backend + Windows GUI	x86, ARM	OpenCL
TensorRT	C++ backend + Jetson scripts	NVIDIA GPU, Jetson Orin	CUDA, Tensor Cores
Core ML	Export scripts + Swift app	macOS	Apple Silicon, Intel

Windows GUI

Windows Runner: ONNX Runtime CUDA backend, dense aerial vehicle detection scene.

cd examples/YOLO-Master-Cross-Platform-Edge-Deployment/gui
./build.ps1 -Run

Verified Jetson Benchmark

| Device | Backend | Precision | Dataset | Latency | FPS | mAP50-95 |
|---|---|---|---|---|---:|---:|---:|
| Jetson Orin Nano 4 GB | TensorRT | FP16 | VisDrone, 548 images | 27.8 ms | 35.7 | 0.2029 |

Important

These values apply only to the model, data, and device documented. Routed-profile TensorRT and Core ML remain outside the validated release surface.

Deployment Capability Matrix

Verified backend coverage across architecture families. ✅ = hardware-verified · △ = ONNX round-trip passes, no hardware validation · — = not tested · ⊘ = structurally unsupported (e.g., sparse dispatch on backends without dynamic shape).

Architecture	ONNX	TensorRT	NCNN	MNN	Core ML
Dense (v0.1)	✅	✅	✅	✅	✅
YOLO26 native	✅	✅	✅	✅	✅
ES-MoE	✅	△	✅	✅	—
Shared-MoE	✅	△	—	—	—
MoA (dense inference)	✅	△	—	—	—
MoA (sparse inference)	⊘	⊘	⊘	⊘	⊘
MoT (dense inference)	✅	△	—	—	—
MoT (sparse inference)	⊘	⊘	⊘	⊘	⊘
Latent Mixture (dense)	✅	△	—	—	—
Latent Mixture (sparse)	⊘	⊘	⊘	⊘	⊘
MultiTask	△	—	—	—	—

Next step (P0 target): CI-automated export→load→forward→numerical comparison for every architecture×backend cell marked △ or —. Sparse dispatch backends require explicit export-time fallback to dense mode with preflight warning.

6. Reliability Engineering

Hardening Summary

Area	v26.08 Change	Verified By
NaN handling	Pre-batch checks, component guards, recovery paths	Routed training + recovery regressions
AMP safety	Dtype-aligned sparse accumulation	MoE / MoA / MoT mixed-precision tests
DDP lifecycle	Bootstrap + pre-epoch checkpoint coordination	Static-graph + lifecycle tests
EMA	Buffer + PEFT scaling synchronization	Checkpoint / EMA regressions
MPS	Native bilinear `grid_sample` + numerical fixes	Apple Silicon regressions
Export	Routed capability matrix + pruning metadata	Export + pruning contract tests
Upstream	`8.4.101` manifest, baseline, additive registry	Integrity + checkpoint + registry tests

P0-P2 Hardening

Priority	Area	Correction
🔴 P0	Routing + aux loss	Single facade collects loss once; EMA-normalized by family; globally budgeted; non-finite families isolated with rank sync
🔴 P0	Checkpoint / EMA / DDP	Bootstrap + pre-epoch coordination; PEFT + EMA scaling sync
🔴 P0	Export contracts	Preflight validates module / backend declarations; records sparse vs dense strategy
🟡 P1	MultiTask data path	`MultiTaskBatchSampler`: weighted / round-robin, DDP-aware, resumable; partial labels loss-masked
🟡 P1	AMP / MPS / sparse	Dtype-aligned accumulation; MPS native-safe bilinear; rank-synced NaN recovery
🟡 P1	Latent Mixture	Named YAML (13 validated fields), checkpoint provenance, value-fusion mode, calibration gate
🟢 P2	PEFT + observability	MoLoRA save / load round-trip; routing snapshots for integration diagnostics

Selected Critical Fixes

PR	Fix
#74	ONNX export compatibility for MoE expert loss
#116	P0 / P1 / P2 fixes across MoE, MoA, MoT, PEFT
#124	AMP dtype alignment for sparse `index_add_` paths
#127, #140	DDP static-graph + checkpoint coordination
#158	Released router checkpoint compatibility
#161	YOLOE released-checkpoint execution semantics
#177	LoRA alpha warmup across EMA lifecycle
#188	Routing dataset statistics weighted by sample count
#192, #194	Pruned expert architecture preserved for retraining
#211	PEFT scaling state synchronization to EMA

7. Model Zoo & Benchmarks

Two model families, seven evaluated checkpoints, COCO val2017 standard protocol.

YOLO-Master-EsMoE (v0.10)

Model	Params ↓	GFLOPs	mAP50-95	FPS¹	Status
EsMoE-N	2.68M	8.7	0.427	640	✅ Weights · YAML
EsMoE-S	9.69M	29.1	0.489	424	✅ Weights · YAML
EsMoE-M	34.88M	97.4	0.530	244	✅ Weights · YAML
EsMoE-L	—	—	—	—	⏳ Pending
EsMoE-X	—	—	—	—	⏳ Pending

YOLO-Master-v0.1 (Dense Baseline)

Model	Params ↓	GFLOPs ↓	mAP50-95 ↑	FPS¹ ↑	Status
v0.1-N	7.54M	10.1	0.429	529	✅ Weights · YAML
v0.1-S	29.15M	36.0	0.489	345	✅ Weights · YAML
v0.1-M	52.17M	116.7	0.528	171	✅ Weights · YAML
v0.1-L	58.41M	138.1	0.539	150	✅ Weights · YAML
v0.1-X	—	—	—	—	⏳ Pending

¹ FPS measured on NVIDIA RTX 4090. Results are recorded in model-zoo/models.json (updated 2026-07-22).

EsMoE vs Dense: Accuracy–Parameters–Latency Pareto Frontier

EsMoE delivers a clear Pareto improvement over dense baselines across all N/S/M scales — the key metric is parameter efficiency with maintained or improved accuracy at higher FPS.

Scale	Model	Params	Δ Params	mAP50-95	Δ mAP	FPS	Δ FPS
N	Dense-N	7.54M	—	0.429	—	529	—
	EsMoE-N	2.68M	−64.5%	0.427	−0.002	640	+21.0%
S	Dense-S	29.15M	—	0.489	—	345	—
	EsMoE-S	9.69M	−66.8%	0.489	0.000	424	+22.9%
M	Dense-M	52.17M	—	0.528	—	171	—
	EsMoE-M	34.88M	−33.1%	0.530	+0.002	244	+42.7%

Important

At M-scale, EsMoE-M achieves better accuracy (+0.002 mAP) while being 42.7% faster and 33.1% lighter than the dense baseline. This is not just "competitive" — it is a Pareto-dominant improvement across all three metrics.

These results support a core project thesis:

YOLO-Master explores conditional computation as an alternative scaling axis for real-time vision: scale capacity without proportionally scaling active computation.

v26.08 Unified Benchmark Matrix

The following table defines the target evidence surface for the next release cycle. Cells marked ⏳ represent active evaluation; — represents not yet benchmarked. All metrics use COCO val2017, RTX 4090.

Architecture	Params	Active Params	GFLOPs	Active GFLOPs	mAP50-95	FPS	VRAM (train)	Train Throughput	Status
YOLO26-N (baseline)	⏳	⏳	⏳	⏳	⏳	⏳	⏳	⏳	Target
Dense (v0.1-N)	7.54M	7.54M	10.1	10.1	0.429	529	⏳	⏳	✅
ES-MoE (v0.10-N)	2.68M	⏳	8.7	⏳	0.427	640	⏳	⏳	✅
Shared-MoE	—	—	—	—	—	—	—	—	⏳
MoA	—	—	—	—	—	—	—	—	⏳
MoT	—	—	—	—	—	—	—	—	⏳
MoA + MoT	—	—	—	—	—	—	—	—	⏳
Latent Mixture	—	—	—	—	—	—	—	—	⏳

Note on Active Params / Active FLOPs. For mixture architectures, total parameters and theoretical FLOPs are insufficient metrics. Active parameters (experts actually dispatched per input) and active FLOPs (actual compute per forward pass) are the meaningful efficiency measures. These will be reported alongside standard metrics in future releases.

PEFT Efficiency Benchmarks

Method	Trainable Params	% of Total	mAP50-95	vs Full FT	FPS (merged)	Status
Full Fine-tune	⏳	100%	⏳	baseline	⏳	Target
Standard LoRA (r=16)	⏳	⏳	⏳	⏳	⏳	⏳
PEFT Planner (AO)	⏳	⏳	⏳	⏳	⏳	⏳
MoLoRA (K=2, r=8)	⏳	⏳	⏳	⏳	⏳ (merged)	⏳
FewShot-LoRA	⏳	⏳	⏳	⏳	⏳	⏳

All PEFT rows are targets for the next release cycle. v26.08 ships the code and component-level verification; end-to-end accuracy/efficiency figures are pending.

MultiTask Efficiency

Training Scheme	Total Params	Train Time (rel.)	Detect mAP	Seg mAP	Pose mAP	Status
3 × Solo Model	⏳	3.0×	⏳	⏳	⏳	Target
MultiTask (shared)	⏳	⏳	⏳	⏳	⏳	⏳

This comparison — "does one MultiTask model outperform or match three independent models at lower total cost?" — is the central evidentiary question for the MultiTask subsystem and a P0 target for the next release.

Model Zoo benchmark comparison: parameter count vs. mAP50-95 across EsMoE (v0.10) and v0.1 dense baseline, with FPS annotated per model variant.

8. Validation Methodology

The v26.08 release gate is a targeted verification surface — covering features and compatibility claims promoted in this report.

Gate Composition (16 test files + Agent Skill suite)

pytest -q \
  tests/test_routed_module_protocol.py tests/test_routing_diagnostics.py \
  tests/test_molora_merge_semantics.py tests/test_p2_fixes.py \
  tests/test_latent_mixture.py tests/test_mixture_loss_composition.py \
  tests/test_mixture_model_registry.py tests/test_export_capability_matrix.py \
  tests/test_multitask.py tests/test_mot.py tests/test_mixture_export.py \
  tests/test_routing_aux_contract.py tests/test_mixture_aux_loss.py \
  tests/test_moe_router_boundaries.py tests/test_molora_vpeft_integration.py \
  tests/test_vpeft.py

python agent/scripts/validate_yolo_master_skill.py --suite quick --pretty --summary-only

Results

Gate	Result
MoE, MoA, MoT modules	✅ Passed
Routed auxiliary-loss contracts	✅ Passed
Shared Expert (build / forward / reuse / isolation)	✅ Passed
Master model config regression	✅ Passed
Default config integrity	✅ Passed
Mixture catalog integrity	✅ Passed
Ultralytics `8.4.101` upstream integrity	✅ Passed
Checkpoint conversion + compatibility	✅ Passed
Additive mixture model registry	✅ Passed
Mixture / P0-P2 focused gate	377 passed · 1 xfailed
Agent Skill quick suite	36/36 passed

Note

The single xfailed is a known expected failure, retained for transparency.

Verification Boundaries

Routed model profiles → experimental unless registry marks stable
MultiTask multi-output prediction beyond detect → preview only
MoA / MoT, Latent Mixture, MoLoRA, FewShot-LoRA → no release-level accuracy / latency tables
TensorRT for routed profiles → unverified (component ONNX round-trip ≠ full TensorRT)
CUDA / MPS AMP multi-epoch + NCCL 2-GPU → not recorded in this audit
Core ML → blocked by coremltools / SciPy binary loading issue
EsMoE-L, EsMoE-X, v0.1-X → pending / under evaluation

9. Migration: v26.02 → v26.08

No formally declared breaking changes for documented public APIs. The primary action is the upstream rebase.

Workflow Impact Matrix

v26.02 Workflow	v26.08 Behavior	Action
Native detection / official YOLO	Parser / trainer / heads follow `8.4.101`	Retest internal imports; keep native YAML unchanged
ES-MoE model YAML	YAML-owned topology; aux loss via shared protocol	Keep YAML + checkpoint; validate custom modules with boundary tests
Fixed-rank LoRA	`lora_r` + `lora_alpha` still supported	Keep existing calls; opt into Planner / V-PEFT only if needed
LoRA + routed adapter	MoLoRA: dedicated runtime with save / load / merge	Choose LoRA or MoLoRA (not both)
Sparse SAHI / CW-NMS	Settings remain; not silently converted	Preserve config; benchmark target backend
Exporting mixture profile	Sparse ≠ exported (backend-dependent)	Run preflight; accept dense fallback or explicit refusal
MultiTask	Detect / Seg / Pose profile with partial-label masks	Use `task="multitask"` + COCO-unified; OBB rejected
Resume / checkpoint	Native fields retained; mixture / PEFT metadata additive	Retest resume + EMA; don't replace native fields

Upstream Rebase

pip install -e .
python -c "import ultralytics; print(ultralytics.__version__, ultralytics.__file__)"
yolo version && yolo checks

Use packaged YOLO26 YAML files for native models
Keep mixture architectures additive (don't replace official yolo26*.yaml)
Preserve native checkpoint fields; mixture_checkpoint metadata added separately
Revalidate custom integrations against new 8.4.101 parser / trainer / head signatures

Quick Migration Cheatsheet

# ✅ Existing LoRA — unchanged
model = YOLO("ultralytics/cfg/models/26/yolo26.yaml")
model.train(data="coco8.yaml", epochs=100, lora_r=16, lora_alpha=32)

# ✅ PEFT Planner — explicit opt-in
model.train(data="coco8.yaml", lora_r=16,
            lora_planner_enabled=True, lora_planner_backend="vpeft",
            lora_planner_solver="ao")

# ✅ MoLoRA — positive expert count (NOT with lora_r > 0)
model.train(data="coco8.yaml",
            molora_num_experts=4, molora_top_k=2, molora_r=8)

Warning

Do not combine lora_r > 0 + molora_num_experts > 0 — the adapter extension rejects the ambiguous request.

10. Known Limitations

These are not bugs — they are areas where implementation evidence does not yet support production-ready claims.

Accuracy & Convergence

MoA, MoT, Latent Mixture, MoLoRA, and FewShot-LoRA have component-level build / forward / loss verification but no release-level accuracy tables. Multi-epoch full-COCO training runs with these profiles have not been executed in this release cycle.

Distributed Training

DDP evidence is lifecycle and contract focused. No real NCCL multi-node or multi-GPU training result with mixture profiles is recorded in this release audit.

Export Completeness

TensorRT export for routed profiles (MoA / MoT / Latent Mixture) is unverified. ONNX round-trip tests do not imply full-model TensorRT validation. Core ML blocked by coremltools / SciPy incompatibility.

MultiTask Coverage

Classify, depth, normal, and semantic branches have criterion implementations but no validation metrics. MultiTask OBB is explicitly rejected.

Model Zoo

EsMoE-L, EsMoE-X, v0.1-X evaluations pending. No PEFT efficiency figures published.

🤝 Contributors

637 commits · 120 merged PRs · 34 unique author identities across v26.02 → v26.08.

Contributor	Contributions	Primary Focus
isLinXu	364 commits · 57% of range	Project direction, ES-MoE architecture, DDP hardening, release orchestration
Hertz	102 commits · 16% of range	MoA / MoT block design, mixture optimization, routing infrastructure
gatilin	24 commits	Agent Skill system, release management, documentation
13ewat3r	15 commits	MoA test suite, vertical validation, ablation infrastructure
kimariyb	15 commits	MoT hybrid architecture, domain-specific LoRA, training recipes
Thomas	13 commits	Framework-level fixes, parser hardening, integration testing
SidKC	12 commits	LoRA / V-PEFT lifecycle, routing dataset statistics, EMA fixes
skywalker-lt	9 merged PRs	Cross-platform C++ edge deployment, Jetson benchmarking, reproducibility workflows

Community contributors — Lfan-ke · vankari · delei-kong · Cooryn · Ricky-7-Yan · Zviolin — and every tester, reviewer, and early adopter who helped harden this release.

🙏 Acknowledgments

Ultralytics team for the 8.4.101 upstream release · Research community behind MoE, LoRA, SAHI, and GShard · Every contributor, tester, and user who helped harden this release.

References

[1] YOLO-Master Team, "YOLO-PEFT: Parameter-Efficient Fine-Tuning on YOLO Family," arXiv:2608.07051, 2026.

[2] N. Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer," ICLR, 2017.

[3] D. Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding," ICLR, 2021.

[4] E. J. Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models," ICLR, 2022.

[5] F. C. Akyon et al., "Slicing Aided Hyper Inference and Fine-tuning for Small Object Detection," ICIP, 2022.

[6] G. Jocher, A. Chaurasia, and J. Qiu, "Ultralytics YOLO," 2023.

🔗 Community Links

📚 Documentation · 📖 Wiki · 📊 Model Zoo · 💬 Discussions · 🐛 Issues · 🔄 Full Diff

📞 Contact

gatilin@tencent.com · islinxu@163.com

📄 License

GNU AGPL v3.0. Commercial use may require a separate Ultralytics license.

🌟 Star History

View complete star history

Made with ❤️ by the YOLO-Master Team

⬆ Back to top

Uh oh!

YOLO-Master v26.08

YOLO-Master v26.08 — Release Report

🌟 Overview

Release at a Glance

Release Provenance

Why Upgrade?

📄 Accompanying Paper

🚀 From v26.02 to v26.08

Development Timeline

🏷️ Production & Research Surface

Project Identity: Core / Framework / Labs

Three-Axis Status: API Maturity × Accuracy Evidence × Export Readiness

Production Surface

Research Surface

⚡ Quick Start

Install v26.08 (Recommended — Pinned to Release Tag)

Install from main (Nightly / Development)

Architecture Selection Guide

WebUI

1. Unified Routing Architecture

1.1 Routing Protocol

1.2 Composite Criterion

1.3 Mixture Surface Taxonomy

📊 Capability Matrix

2. Mixture Subsystems

2.1 Ultralytics 8.4.101 + YOLO26 Modernization

2.2 Backbone MoE

2.3 Shared Expert MoE

2.4 MoA — Mixture of Attention

2.5 MoT — Mixture of Transformers

2.6 Latent Mixture

3. PEFT Adaptation

3.1 Standard LoRA

3.2 PEFT Planner

3.3 MoLoRA — Routed Adapter Experts

3.4 FewShot-LoRA and LOVO

4. MultiTask Learning

Component Roles

Training Contract

5. Edge Deployment

Windows GUI

Verified Jetson Benchmark

Deployment Capability Matrix

6. Reliability Engineering

Hardening Summary

P0-P2 Hardening

Selected Critical Fixes

7. Model Zoo & Benchmarks

YOLO-Master-EsMoE (v0.10)

YOLO-Master-v0.1 (Dense Baseline)

EsMoE vs Dense: Accuracy–Parameters–Latency Pareto Frontier

v26.08 Unified Benchmark Matrix

PEFT Efficiency Benchmarks

MultiTask Efficiency

8. Validation Methodology

Gate Composition (16 test files + Agent Skill suite)

Results

Verification Boundaries

9. Migration: v26.02 → v26.08

Workflow Impact Matrix

Upstream Rebase

Quick Migration Cheatsheet

10. Known Limitations

Accuracy & Convergence

Distributed Training

Export Completeness

MultiTask Coverage

Model Zoo

🤝 Contributors

🙏 Acknowledgments

References

🔗 Community Links

📞 Contact

📄 License

🌟 Star History

Uh oh!