Ultralytics YOLO27 :
Get Started

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 préentraînés officiels de YOLO26 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, et tout cela peut être examiné par programmation.

Savoir ce qui a servi à créer les points de contrôle officiels — pas seulement l’architecture, mais aussi les programmes de 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 de l’ajustement fin : quelles augmentations de données conserver, quels poids de la fonction de perte ajuster et quels réglages d’optimiseur conviennent le mieux à la taille de ton jeu de données.

Lis l’article pour avoir une vue d’ensemble

Cette page présente les hyperparamètres enregistrés dans les points de contrôle publiés. Pour comprendre leur justification, notamment l’architecture, les modifications apportées à la fonction de perte et à l’attribution des étiquettes, ainsi que les études d’ablation, lis Ultralytics YOLO26 : modèles de vision unifiés, temps réel et end-to-end.

Aperçu de l’entraînement#

Tous les modèles de base YOLO26 ont été entraînés en deux étapes : préentraînement sur Objects365v1 pendant 150 époques, suivi d’un ajustement fin 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, ce qui explique la brièveté de l’étape COCO pour la plupart des tailles. Les hyperparamètres de l’étape COCO ont été déterminés par recherche évolutionnaire. Les journaux d’entraînement et les 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
  • Entraînement à double tête avec supervision one-to-many et one-to-one ; l’inférence utilise NMS par défaut, tandis que nms=False sélectionne la tête sans NMS
  • Optimiseur MuSGD combinant SGD et des mises à jour orthogonalisées de type Muon pour les matrices de poids (poids linéaires 2D et filtres convolutifs 4D, remodelés en 2D)
  • Augmentation mosaic intensive (~0.9-1.0 de probabilité), désactivée lors des dernières époques (close_mosaic=8 pendant le préentraînement, close_mosaic=10 sur COCO)
  • Augmentation d’échelle agressive (0.5-0.95) pour traiter des objets de tailles différentes
  • Rotation et cisaillement minimaux pour la plupart des tailles, afin de limiter la distorsion géométrique

É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 décrits sur la page du jeu de données Objects365. Le fichier .pt de chaque point de contrôle COCO indique les poids de départ dans sa configuration d’entraînement intégrée ; la section Inspection des paramètres d’entraînement des points de contrôle YOLO26 ci-dessous explique comment les lire :

Point de contrôle COCOPoids de départ
yolo26n.ptyolo26n-objv1-150.pt
yolo26s.ptyolo26s-objv1-150.pt
yolo26m.ptyolo26m-objv1-150.pt
yolo26l.ptyolo26l-objv1-150.pt
yolo26x.ptyolo26x-objv1-150.pt

Le préentraînement utilisait principalement les paramètres par défaut plutôt que des valeurs issues d’une recherche. 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ètreValeur
dataObjects365v1
epochs150
imgsz640
batch128
optimizerMuSGD
lr0 / lrf0.01 / 0.01
momentum0.937
weight_decay0.0005
warmup_epochs1 (2 pour X)
close_mosaic8
box / cls / dfl7.5 / 0.5 / 6.0
AugmentationNSMLX
mosaic1.01.01.01.01.0
mixup0.00.050.150.150.2
copy_paste0.10.150.40.50.6
scale0.50.90.90.90.9

Ces tableaux présentent les paramètres qui influencent le préentraînement, et non la configuration complète. Les points de contrôle enregistrent plus de 100 arguments ; affiche train_args comme indiqué ci-dessous pour obtenir la liste de référence.

Avancé : paramètres internes de préentraînement

Le préentraînement faisait également varier le même type de paramètres de branche expérimentale que ceux décrits dans Paramètres d’entraînement internes. cls_w était égal à 1.0 pour toutes les tailles :

ParamètreNSMLX
muon_w0.450.50.450.450.5
sgd_w0.550.50.550.550.6
o2m0.10.10.11.01.0
Partir des poids Objects365

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 quel autre artefact Ultralytics, tu peux donc les affiner 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 indique les valeurs d’optimiseur, de fonction de perte et d’augmentation de l’étape 2 correspondant à cette taille dans les tableaux ci-dessous. Ces tableaux omettent des arguments secondaires non définis par défaut, tels que warmup_momentum, warmup_bias_lr, perspective, flipud et cutmix ; affiche donc train_args depuis le point de contrôle pour obtenir la configuration exacte. Le package publié rejette les paramètres internes ; tu dois utiliser la branche expérimentale.

Inspecter les arguments d’entraînement du point de contrôle YOLO26#

Chaque point de contrôle Ultralytics stocke la configuration d’entraînement complète utilisée pour le produire, tu peux donc vérifier toi-même chaque valeur de cette page :

Inspecter les arguments d’entraînement du point de contrôle
from ultralytics import YOLO

model = YOLO("yolo26n.pt")
print(model.ckpt["train_args"])

La sortie répertorie la configuration complète, qui compte 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: MuSGD

Cette méthode fonctionne avec n’importe quel point de contrôle .pt — qu’il s’agisse de versions officielles ou de tes propres modèles affinés. Pour consulter la liste complète des arguments d’entraînement configurables, reporte-toi à la référence de configuration de l’entraînement.

Afficher les courbes d’entraînement#

train_args n'est pas la seule chose stockée. Chaque point de contrôle contient aussi les données complètes de results.csv pour chaque époque de l'entraînement 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 n'importe quel fichier .pt peut être glissé-déposé dans un projet pour tracer 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 et les courbes Objects365 sur 150 époques dans yolo26s-objv1-150.pt.

Vérifier la révision du code#

ckpt["git"] indique le commit qui a produit le point de contrôle, et ces commits se trouvent sur les branches expérimentales publiques du dépôt Ultralytics ; tu peux donc extraire la version exacte du code d’entraînement :

from ultralytics import YOLO

print(YOLO("yolo26n.pt").ckpt["git"])
# {'root': ..., 'branch': 'exp-main', 'commit': 'cb13d5f9cfbd6f299da3620c625f81d721dc2849', ...}
git fetch origin cb13d5f9cfbd6f299da3620c625f81d721dc2849
git checkout cb13d5f9cfbd6f299da3620c625f81d721dc2849

Les branches expérimentales contiennent des travaux qui n’ont jamais été intégrés à main, comme les éléments o2m et cls_w configurables. L’entraînement sur main avec les hyperparamètres documentés ci-dessous ne sera pas identique bit à bit, mais les résultats seront pratiquement équivalents aux métriques publiées.

Hyperparamètres d’entraînement 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 calendrier, coefficients de perte 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’optimiseur et de calendrier ont servi à l’affinage sur COCO pour chaque taille ; note que le modèle N se distingue des autres :

ParamètreNSMLX
optimizerMuSGDMuSGDMuSGDMuSGDMuSGD
lr00.00540.000380.000380.000380.00038
lrf0.04950.8820.8820.8820.882
momentum0.9470.9480.9480.9480.948
weight_decay0.000640.000270.000270.000270.00027
warmup_epochs0.980.990.990.990.99
epochs24570806040
batch128128128128128
imgsz640640640640640
Stratégie de taux d’apprentissage

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 et un calendrier plus progressif (lrf=0.882). Cela reflète les différences de dynamique de convergence entre les petits et les grands modèles : les petits modèles ont besoin de mises à jour plus agressives pour apprendre efficacement.

Coefficients de perte#

Les coefficients de perte é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 la distance des boîtes (dfl). Note que YOLO26, qui n’utilise pas DFL, réaffecte le coefficient dfl à une perte L1 sur les distances normalisées des boîtes plutôt qu’à une perte focale de distribution :

ParamètreNSMLX
box5.639.839.839.839.83
cls0.560.650.650.650.65
dfl9.040.960.960.960.96

Le modèle N privilégie le 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 constante 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ètreNSMLX
mosaic0.9090.9920.9920.9920.992
mixup0.0120.050.4270.4270.427
copy_paste0.0750.4040.3040.4040.404
scale0.5620.90.950.950.95
fliplr0.6060.3040.3040.3040.304
degrees1.11~0~0~0~0
shear1.46~0~0~0~0
translate0.0710.2750.2750.2750.275
hsv_h0.0140.0130.0130.0130.013
hsv_s0.6450.3530.3530.3530.353
hsv_v0.5660.1940.1940.1940.194
bgr0.1060.00.00.00.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 de fait désactivée.

Les grands modèles utilisent globalement des augmentations plus agressives (mixup et échelle plus élevés), car ils ont une plus grande capacité et tirent parti d’une régularisation plus forte. Le modèle N est le seul à utiliser des augmentations significatives de rotation, de cisaillement et de BGR.

Paramètres d’entraînement internes#

Avancé : paramètres internes du pipeline

Les points de contrôle contiennent également des paramètres utilisés sur la branche d’entraînement expérimentale, mais qui ne sont pas proposés comme paramètres configurables par l’utilisateur dans default.yaml :

ParamètreDescriptionNSMLX
muon_wCoefficient de mise à jour Muon dans MuSGD0.5280.4360.4360.4360.436
sgd_wCoefficient de mise à jour SGD dans MuSGD0.6740.4790.4790.4790.479
cls_wCoefficient de classification interne2.743.483.483.483.48
o2mCoefficient de perte de la tête un-vers-plusieurs1.00.7050.7050.7050.705
topkAttribution des étiquettes top-k85555

Consulte la FAQ sur ces paramètres pour savoir ce qu’ils signifient lors de l’affinage.

Affiner YOLO26 sur ton propre jeu de données#

Lorsque tu affines YOLO26 sur ton propre jeu de données, tu n’as pas besoin de reproduire toute la recette 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 connaître les bonnes pratiques générales d’entraînement, consulte les Conseils pour l’entraînement des modèles.

Affiner avec les paramètres par défaut#

Affiner 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)

L’affinage avec les paramètres par défaut constitue une excellente base. Ne modifie les hyperparamètres que si tu as une raison précise de le faire.

Quand ajuster les hyperparamètres YOLO26#

Petits jeux de données (< 1 000 images) :

  • Réduis l’intensité de l’augmentation : mosaic=0.5, mixup=0.0, copy_paste=0.0
  • Réduis le taux d’apprentissage et indique explicitement un optimiseur : 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) :

  • Reprends plus fidèlement la recette de préentraînement
  • Envisage optimizer=MuSGD pour les entraînements plus longs
  • Augmente l’augmentation : mosaic=1.0, mixup=0.3, scale=0.9

Images propres à un domaine (aériennes, médicales, sous-marines) :

  • Augmente flipud=0.5 si l’orientation verticale varie
  • Augmente degrees si les objets apparaissent avec des rotations quelconques
  • Ajuste hsv_s et hsv_v si les conditions d’éclairage diffèrent fortement de celles de COCO

Pour optimiser automatiquement les hyperparamètres, consulte le guide de réglage des hyperparamètres.

Choisir une taille de modèle#

ModèleIdéal pourConseils sur la taille de lot
YOLO26nAppareils périphériques, mobile, temps réel sur CPUGrands lots (64-128) sur des GPU grand public
YOLO26sÉquilibre entre vitesse et précisionLots moyens (32-64)
YOLO26mMeilleure précision avec des ressources de calcul modéréesLots plus petits (16-32)
YOLO26lHaute précision si un GPU est disponiblePetits lots (8-16) ou plusieurs GPU
YOLO26xPrécision maximale, déploiement sur serveurPetits lots (4-8) ou plusieurs GPU

Pour connaître les options d’exportation et de déploiement, consulte le guide d’exportation et les options de déploiement des modèles.

Conclusion#

Les points de contrôle YOLO26 incluent leur recette d’entraînement complète ; les hyperparamètres exacts de chaque taille de modèle sont donc toujours accessibles en recherchant train_args. Commence l’affinage avec les paramètres par défaut, ajuste-les de façon réfléchie à l’aide des tableaux de cette page et vérifie chaque modification sur ton propre jeu de validation. Si tu as des questions en cours de route, adresse-toi à la communauté sur le dépôt GitHub d’Ultralytics ou le serveur Discord d’Ultralytics.

FAQ#

  • Charge le point de contrôle avec torch.load() et accède à la clé train_args, ou utilise model.ckpt["train_args"] avec l’API Ultralytics. Consulte Inspecter les arguments d’entraînement du point de contrôle YOLO26 pour des exemples complets.

  • Chaque taille a bénéficié du même préentraînement Objects365 de 150 époques ; les nombres d’époques COCO ne couvrent donc que l’étape d’affinage. Les grands modèles convergent sur COCO en moins d’époques : 40 pour X contre 245 pour N. Les nombres ne sont pas strictement monotones (S en a utilisé 70, M 80), car ils proviennent de la recherche d’hyperparamètres propre à chaque taille. Lors de l’affinage sur ton propre jeu de données, le nombre optimal d’époques 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.

  • Ces paramètres proviennent de la branche expérimentale qui a produit les points de contrôle de base ; ils sont enregistrés dans train_args pour assurer la reproductibilité. Ce ne sont pas des paramètres configurables par l’utilisateur dans default.yaml, et les transmettre à model.train() déclenche une erreur d’argument invalide, car le package publié ne les lit pas. Tu n’as pas besoin de les définir lors de l’affinage ; consulte Paramètres d’entraînement internes pour connaître leurs valeurs par taille de modèle.

  • Non. Chaque point de contrôle COCO a été affiné à partir d’un point de contrôle Objects365v1 de même taille, déjà entraîné pendant 150 époques, comme indiqué dans Étape 1 : préentraînement sur Objects365 et dans l’article YOLO26. Aucun entraînement COCO à partir de zéro n’a servi à obtenir les chiffres publiés ; une comparaison avec ces chiffres n’est donc pas équitable.

  • Ils se trouvent dans les points de contrôle et sont représentés sur Ultralytics Platform. Chaque point de contrôle stocke l’historique complet results.csv par époque de son entraînement ; il suffit donc de déposer un fichier .pt dans un projet Platform pour afficher les pertes, l’évolution de mAP et les taux d’apprentissage, sans écrire de code. Consulte Afficher les courbes d’entraînement. L’étape Objects365 possède son propre journal dans les points de contrôle yolo26*-objv1-150.pt.

  • Tu obtiendras des métriques proches des résultats publiés, mais pas identiques. Pour reproduire exactement la configuration, extrais le commit indiqué dans le point de contrôle et entraîne le modèle sur cette branche. Consulte Vérifier la révision du code.

Commentaires