Recette d’entraînement de YOLO26#
Introduction#
Ce guide documente la recette exacte d’entraînement utilisée pour produire les points de contrôle officiels YOLO26 préentraînés sur COCO. Chaque hyperparamètre présenté ici est déjà intégré aux poids .pt publiés, avec le journal d’entraînement par époque et la révision du code utilisée pour l’exécution ; tu peux inspecter l’ensemble par programmation.
Savoir ce qui a été intégré aux points de contrôle officiels — pas seulement l’architecture, mais aussi les planifications du taux d’apprentissage, les pipelines d’augmentation et les poids des fonctions de perte qui ont façonné leurs performances — t’aide à prendre de meilleures décisions lors du fine-tuning : quelles augmentations de données conserver, quels poids de la fonction de perte ajuster et quels paramètres d’optimisation conviennent le mieux à la taille de ton jeu de données.
Cette page couvre les hyperparamètres enregistrés dans les points de contrôle publiés. Pour comprendre leur raison d’être, notamment l’architecture, les changements apportés à la perte et à l’attribution des labels, ainsi que les études d’ablation, lis Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models.
Vue d’ensemble de l’entraînement#
Tous les modèles de base YOLO26 ont été entraînés en deux étapes : un préentraînement sur Objects365v1 pendant 150 époques, suivi d’un fine-tuning sur COCO. Les deux étapes ont utilisé une résolution de 640x640, l’optimiseur MuSGD et une taille de lot de 128. Aucun point de contrôle YOLO26 n’a été entraîné sur COCO à partir de poids aléatoires ; c’est pourquoi l’étape COCO est courte pour la plupart des tailles, et ses hyperparamètres ont été déterminés par une recherche évolutionnaire. Les journaux et métriques complets de chaque taille de modèle sont stockés dans les points de contrôle publiés et affichés sous forme de graphiques sur Ultralytics Platform.
Principaux choix de conception pour toutes les tailles :
- Préentraînement sur Objects365 pour chaque taille avant l’étape COCO
- L'entraînement à double tête avec une supervision de type one-to-many et one-to-one ; l'inférence utilise NMS par défaut,
nms=Falsepermettant de sélectionner la tête sans NMS - Optimiseur MuSGD combinant SGD et des mises à jour orthogonalisées de style Muon pour les matrices de poids (poids linéaires 2D et filtres de convolution 4D, remodelés en 2D)
- Augmentation mosaïque intensive (probabilité de ~0.9-1.0) désactivée lors des dernières époques (
close_mosaic=8en préentraînement,close_mosaic=10sur COCO) - Augmentation d’échelle agressive (0.5-0.95) pour gérer les objets de différentes tailles
- Rotation et cisaillement minimaux pour la plupart des tailles, afin de limiter les distorsions géométriques
Étape 1 : préentraînement sur Objects365#
Chaque point de contrôle YOLO26 sur COCO a été ajusté à partir d’un point de contrôle Objects365v1 de même taille. Ces poids préentraînés sont également publiés et documentés sur la page du jeu de données Objects365. Chaque point de contrôle COCO indique ses poids de départ dans la configuration d’entraînement intégrée au fichier .pt, comme l’explique la section Inspecting YOLO26 Checkpoint Training Args ci-dessous :
| Point de contrôle COCO | Poids de départ |
|---|---|
yolo26n.pt | yolo26n-objv1-150.pt |
yolo26s.pt | yolo26s-objv1-150.pt |
yolo26m.pt | yolo26m-objv1-150.pt |
yolo26l.pt | yolo26l-objv1-150.pt |
yolo26x.pt | yolo26x-objv1-150.pt |
Le préentraînement a principalement utilisé les paramètres par défaut plutôt que des valeurs recherchées. lr0, lrf, momentum, weight_decay, box et cls correspondent à default.yaml, tandis que warmup_epochs, close_mosaic et dfl ont été remplacés. Les paramètres sont communs à toutes les tailles, à l’exception de warmup_epochs pour X, des intensités d’augmentation et des poids internes de MuSGD et de la tête indiqués après les tableaux :
| Paramètre | Valeur |
|---|---|
data | Objects365v1 |
epochs | 150 |
imgsz | 640 |
batch | 128 |
optimizer | MuSGD |
lr0 / lrf | 0.01 / 0.01 |
momentum | 0.937 |
weight_decay | 0.0005 |
warmup_epochs | 1 (2 pour X) |
close_mosaic | 8 |
box / cls / dfl | 7.5 / 0.5 / 6.0 |
| Augmentation | N | S | M | L | X |
|---|---|---|---|---|---|
mosaic | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
mixup | 0.0 | 0.05 | 0.15 | 0.15 | 0.2 |
copy_paste | 0.1 | 0.15 | 0.4 | 0.5 | 0.6 |
scale | 0.5 | 0.9 | 0.9 | 0.9 | 0.9 |
Ces tableaux couvrent les paramètres qui façonnent le préentraînement, et non la configuration complète. Les points de contrôle enregistrent plus de 100 arguments ; affiche donc train_args comme indiqué ci-dessous pour obtenir la liste de référence.
Avancé : paramètres internes du préentraînement
Le préentraînement a également fait varier le même type de paramètres de branche expérimentale que ceux décrits dans Internal Training Parameters. cls_w valait 1.0 pour toutes les tailles :
| Paramètre | N | S | M | L | X |
|---|---|---|---|---|---|
muon_w | 0.45 | 0.5 | 0.45 | 0.45 | 0.5 |
sgd_w | 0.55 | 0.5 | 0.55 | 0.55 | 0.6 |
o2m | 0.1 | 0.1 | 0.1 | 1.0 | 1.0 |
Tu n’as pas besoin du jeu de données Objects365 pour réutiliser l’étape 1. Les points de contrôle préentraînés se téléchargent automatiquement comme n’importe quelle autre ressource Ultralytics ; tu peux donc les ajuster sur ton propre jeu de données :
from ultralytics import YOLO
model = YOLO("yolo26s-objv1-150.pt")
results = model.train(data="your-dataset.yaml", epochs=100, imgsz=640)Pour relancer l’étape COCO, pars plutôt des mêmes poids et transmets les valeurs de l’optimiseur, de la perte et des augmentations de l’étape 2 correspondant à cette taille dans les tableaux ci-dessous. Ces tableaux omettent certains arguments secondaires non définis par défaut, comme warmup_momentum, warmup_bias_lr, perspective, flipud et cutmix ; affiche donc train_args depuis le point de contrôle pour obtenir la configuration exacte. Les paramètres internes sont rejetés par le package publié et nécessitent la branche expérimentale.
Inspection des arguments d’entraînement du point de contrôle YOLO26#
Chaque point de contrôle Ultralytics stocke la configuration complète d’entraînement utilisée pour le produire ; tu peux donc vérifier toi-même chaque valeur de cette page :
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
print(model.ckpt["train_args"])La sortie répertorie la configuration complète, qui contient plus de 100 entrées, notamment chaque valeur de recette documentée sur cette page. Voici un extrait pour yolo26n.pt :
batch: 128
...
box: 5.62767
...
close_mosaic: 10
cls: 0.56099
...
dfl: 9.03871
...
epochs: 245
...
lr0: 0.0054
lrf: 0.04952
...
optimizer: MuSGDCela fonctionne avec n’importe quel point de contrôle .pt, qu’il s’agisse de publications officielles ou de tes propres modèles ajustés. Pour consulter la liste complète des arguments d’entraînement configurables, voir la référence de configuration de l’entraînement.
Afficher les courbes d’entraînement#
train_args n’est pas le seul élément stocké. Chaque point de contrôle contient également le results.csv complet, époque par époque, de l’exécution qui l’a produit, ainsi que ses métriques finales de validation. Les courbes des points de contrôle officiels YOLO26 sont publiées sur Ultralytics Platform, et tu peux faire glisser un fichier .pt vers un projet pour représenter les mêmes données, les métadonnées étant automatiquement extraites du fichier.
Chaque point de contrôle couvre l’étape qui l’a produit ; les courbes COCO se trouvent donc dans yolo26s.pt, tandis que les courbes Objects365 sur 150 époques se trouvent dans yolo26s-objv1-150.pt.
Vérification de la révision du code#
ckpt["git"] enregistre le commit qui a produit le point de contrôle, et ces commits se trouvent dans les branches expérimentales publiques du dépôt Ultralytics ; tu peux donc récupérer le code d’entraînement exact :
from ultralytics import YOLO
print(YOLO("yolo26n.pt").ckpt["git"])
# {'root': ..., 'branch': 'exp-main', 'commit': 'cb13d5f9cfbd6f299da3620c625f81d721dc2849', ...}git fetch origin cb13d5f9cfbd6f299da3620c625f81d721dc2849
git checkout cb13d5f9cfbd6f299da3620c625f81d721dc2849Les branches expérimentales contiennent des travaux qui n’ont jamais été intégrés à main, comme o2m et cls_w configurables. Un entraînement sur main avec les hyperparamètres documentés ci-dessous ne sera pas identique bit par bit, mais ses métriques resteront à une distance négligeable de celles publiées.
Hyperparamètres d’entraînement de YOLO26 par taille de modèle#
Voici les valeurs de l’étape 2, appliquées aux poids Objects365 ci-dessus. Les tableaux ci-dessous regroupent la recette par catégorie : optimiseur et planification, poids des pertes et augmentation. Chaque valeur provient directement de train_args, intégré aux points de contrôle publiés.
Optimiseur et taux d’apprentissage#
Ces paramètres d’optimisation et de planification ont piloté le fine-tuning sur COCO pour chaque taille ; remarque que le modèle N se distingue des autres :
| Paramètre | N | S | M | L | X |
|---|---|---|---|---|---|
optimizer | MuSGD | MuSGD | MuSGD | MuSGD | MuSGD |
lr0 | 0.0054 | 0.00038 | 0.00038 | 0.00038 | 0.00038 |
lrf | 0.0495 | 0.882 | 0.882 | 0.882 | 0.882 |
momentum | 0.947 | 0.948 | 0.948 | 0.948 | 0.948 |
weight_decay | 0.00064 | 0.00027 | 0.00027 | 0.00027 | 0.00027 |
warmup_epochs | 0.98 | 0.99 | 0.99 | 0.99 | 0.99 |
epochs | 245 | 70 | 80 | 60 | 40 |
batch | 128 | 128 | 128 | 128 | 128 |
imgsz | 640 | 640 | 640 | 640 | 640 |
Le modèle N utilisait un taux d’apprentissage initial plus élevé avec une forte décroissance (lrf=0.0495), tandis que les modèles S/M/L/X utilisaient un taux initial bien plus faible avec une planification plus progressive (lrf=0.882). Cela reflète les différentes dynamiques de convergence des modèles plus petits et plus grands — les modèles plus petits ont besoin de mises à jour plus agressives pour apprendre efficacement.
Poids des pertes#
Les poids des pertes équilibrent les trois composantes de la perte de détection — la régression IoU des boîtes englobantes (box), la classification (cls) et un terme de régression de distance des boîtes (dfl). Note que YOLO26 sans DFL réaffecte le gain dfl pour pondérer une perte L1 sur les distances normalisées des boîtes plutôt que la perte focale de distribution :
| Paramètre | N | S | M | L | X |
|---|---|---|---|---|---|
box | 5.63 | 9.83 | 9.83 | 9.83 | 9.83 |
cls | 0.56 | 0.65 | 0.65 | 0.65 | 0.65 |
dfl | 9.04 | 0.96 | 0.96 | 0.96 | 0.96 |
Le modèle N donne la priorité au terme de régression de distance dfl, tandis que les modèles S/M/L/X mettent davantage l’accent sur la régression des boîtes fondée sur l’IoU. La perte de classification reste relativement homogène pour toutes les tailles.
Pipeline d’augmentation#
Pour une explication détaillée de chaque technique, consulte le guide sur l’augmentation des données YOLO.
| Paramètre | N | S | M | L | X |
|---|---|---|---|---|---|
mosaic | 0.909 | 0.992 | 0.992 | 0.992 | 0.992 |
mixup | 0.012 | 0.05 | 0.427 | 0.427 | 0.427 |
copy_paste | 0.075 | 0.404 | 0.304 | 0.404 | 0.404 |
scale | 0.562 | 0.9 | 0.95 | 0.95 | 0.95 |
fliplr | 0.606 | 0.304 | 0.304 | 0.304 | 0.304 |
degrees | 1.11 | ~0 | ~0 | ~0 | ~0 |
shear | 1.46 | ~0 | ~0 | ~0 | ~0 |
translate | 0.071 | 0.275 | 0.275 | 0.275 | 0.275 |
hsv_h | 0.014 | 0.013 | 0.013 | 0.013 | 0.013 |
hsv_s | 0.645 | 0.353 | 0.353 | 0.353 | 0.353 |
hsv_v | 0.566 | 0.194 | 0.194 | 0.194 | 0.194 |
bgr | 0.106 | 0.0 | 0.0 | 0.0 | 0.0 |
Les valeurs indiquées comme ~0 sont inférieures à 0.01 dans les points de contrôle réels (par exemple, degrees=0.00012 pour le modèle S) : l’augmentation est effectivement désactivée.
Les modèles plus grands utilisent globalement des augmentations plus agressives (mixup et mise à l’échelle plus élevés), car ils disposent d’une capacité supérieure et bénéficient d’une régularisation plus forte. Le modèle N est le seul dont la rotation, le cisaillement et l’augmentation BGR sont significatifs.
Paramètres internes d’entraînement#
Avancé : paramètres internes du pipeline
Les points de contrôle contiennent également des paramètres utilisés sur la branche expérimentale d’entraînement, mais qui ne sont pas exposés comme paramètres configurables par l’utilisateur dans default.yaml :
| Paramètre | Description | N | S | M | L | X |
|---|---|---|---|---|---|---|
muon_w | Poids de mise à jour Muon dans MuSGD | 0.528 | 0.436 | 0.436 | 0.436 | 0.436 |
sgd_w | Poids de mise à jour SGD dans MuSGD | 0.674 | 0.479 | 0.479 | 0.479 | 0.479 |
cls_w | Poids interne de classification | 2.74 | 3.48 | 3.48 | 3.48 | 3.48 |
o2m | Poids de perte de la tête one-to-many | 1.0 | 0.705 | 0.705 | 0.705 | 0.705 |
topk | Attribution des labels top-k | 8 | 5 | 5 | 5 | 5 |
Consulte l’entrée de la FAQ consacrée à ces paramètres pour comprendre leur signification lors du fine-tuning.
Fine-tuning de YOLO26 sur ton propre jeu de données#
Lors du fine-tuning de YOLO26 sur ton propre jeu de données, tu n’as pas besoin de reproduire la recette complète de préentraînement. Les poids préentraînés intègrent déjà les connaissances d’augmentation et d’optimisation acquises pendant l’entraînement sur COCO. Pour découvrir d’autres bonnes pratiques générales d’entraînement, consulte Conseils pour l’entraînement des modèles.
Fine-tuning avec les paramètres par défaut#
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
results = model.train(data="your-dataset.yaml", epochs=100, imgsz=640)Le fine-tuning avec les valeurs par défaut constitue une base solide. N’ajuste les hyperparamètres que si tu as une raison précise de le faire.
Quand ajuster les hyperparamètres de YOLO26#
Petits jeux de données (< 1 000 images) :
- Réduis l’intensité des augmentations :
mosaic=0.5,mixup=0.0,copy_paste=0.0 - Utilise un taux d’apprentissage plus faible avec un optimiseur explicite :
optimizer=AdamW,lr0=0.001 - Utilise moins d’époques avec une patience définie :
epochs=50,patience=20 - Envisage de geler les couches du backbone :
freeze=10
Grands jeux de données (> 50 000 images) :
- Reproduis plus fidèlement la recette de préentraînement
- Envisage
optimizer=MuSGDpour les entraînements plus longs - Augmente les augmentations :
mosaic=1.0,mixup=0.3,scale=0.9
Images propres à un domaine (aériennes, médicales, sous-marines) :
- Augmente
flipud=0.5si l’orientation verticale varie - Augmente
degreessi les objets apparaissent selon des rotations arbitraires - Ajuste
hsv_sethsv_vsi les conditions d’éclairage diffèrent fortement de celles de COCO
Pour l’optimisation automatisée des hyperparamètres, consulte le guide d’ajustement des hyperparamètres.
Choisir une taille de modèle#
| Modèle | Idéal pour | Recommandations concernant la taille des lots |
|---|---|---|
| YOLO26n | Appareils Edge, mobile, temps réel sur CPU | Lots importants (64-128) sur des GPU grand public |
| YOLO26s | Équilibre entre vitesse et précision | Lots moyens (32-64) |
| YOLO26m | Précision supérieure avec une puissance de calcul modérée | Lots plus petits (16-32) |
| YOLO26l | Précision élevée lorsqu’un GPU est disponible | Petits lots (8-16) ou multi-GPU |
| YOLO26x | Précision maximale, déploiement sur serveur | Petits lots (4-8) ou multi-GPU |
Pour les options d’exportation et de déploiement, consulte le guide d’exportation et les options de déploiement des modèles.
Conclusion#
Les checkpoints YOLO26 intègrent leur recette d’entraînement complète, de sorte que les hyperparamètres exacts de chaque taille de modèle sont toujours accessibles en une recherche train_args. Commence le fine-tuning avec les valeurs par défaut, ajuste-les délibérément à l’aide des tableaux de cette page, puis vérifie chaque modification sur ton propre jeu de validation. Si tu as des questions en cours de route, demande de l’aide à la communauté sur le dépôt GitHub d’Ultralytics ou le serveur Discord d’Ultralytics.
FAQ#
Chaque taille a bénéficié des mêmes 150 epochs de préentraînement sur Objects365 ; les nombres indiqués pour COCO couvrent donc uniquement l’étape de fine-tuning. Les modèles plus grands convergent sur COCO en moins d’epochs, soit 40 pour X contre 245 pour N. Les nombres ne sont pas strictement monotones (S a utilisé 70, M 80), car ils sont issus de la recherche d’hyperparamètres propre à chaque taille. Lors du fine-tuning sur ton propre jeu de données, le nombre optimal d’epochs dépend de la taille et de la complexité de ton jeu de données, et non de la taille du modèle. Utilise l’arrêt anticipé (
patience) pour trouver automatiquement le bon point d’arrêt.Ils proviennent de la branche expérimentale qui a produit les checkpoints de base, et sont enregistrés dans
train_argsà des fins de reproductibilité. Il ne s’agit pas de paramètres configurables par l’utilisateur dansdefault.yaml, et leur transmission àmodel.train()génère une erreur d’argument invalide, car le package publié ne les lit pas. Tu n’as pas besoin de les définir lors du fine-tuning ; consulte Internal Training Parameters pour connaître leurs valeurs selon la taille du modèle.Non. Chaque checkpoint COCO a été ajusté à partir d’un checkpoint Objects365v1 de même taille, qui avait déjà été entraîné pendant 150 epochs, comme indiqué dans Stage 1: Objects365 Pretraining et dans l’article consacré à YOLO26. Aucun entraînement COCO à partir de zéro n’est à l’origine des chiffres publiés ; une comparaison à partir de zéro avec ces chiffres ne serait donc pas équivalente.
Ils se trouvent dans les checkpoints et sont représentés graphiquement sur Ultralytics Platform. Chaque checkpoint enregistre le
results.csvcomplet, par epoch, de son entraînement ; il suffit donc de déposer un fichier.ptdans un projet Platform pour tracer les pertes, l’évolution du mAP et les taux d’apprentissage, sans aucun code. Consulte Viewing the Training Curves. L’étape Objects365 possède son propre journal dans les checkpointsyolo26*-objv1-150.pt.Tu obtiendras des métriques proches de celles publiées, mais pas identiques. Pour reproduire exactement la configuration, récupère le commit enregistré dans le checkpoint et entraîne le modèle sur cette branche. Consulte Checking the Code Revision.
Charge le checkpoint avec
torch.load()et accède à la clétrain_args, ou utilisemodel.ckpt["train_args"]avec l’API Ultralytics. Consulte Inspecting YOLO26 Checkpoint Training Args pour des exemples complets.