libreyolo train

Synopsis

libreyolo train data=<dataset.yaml> [model=<name|path>] [key=value ...]

Les arguments sont des paires key=value, et la forme POSIX fonctionne aussi : epochs=50 et --epochs 50 sont donc le même argument. Les booléens acceptent true et false : amp=false devient --no-amp là où le flag possède une forme négative.

Arguments

Modèle et données

Boucle d'entraînement

Distillation

Optimiseur

Scheduler

Augmentation

EMA

Validation pendant l'entraînement

Sortie

Flags agent

Exemples

# coco8.yaml est fourni avec le paquet et télécharge ses 8 images au premier usage.libreyolo train model=LibreYOLO9s.pt data=coco8.yaml epochs=10 imgsz=640 batch=8

# Affiche ce que le run utiliserait, valeurs par défaut de la famille# incluses, et quitte sans entraîner ni charger de données.libreyolo train model=LibreDFINEn.pt data=coco8.yaml epochs=10 dry_run=true

libreyolo train model=LibreYOLO9s.pt data=coco8.yaml \  epochs=50 batch=8 optimizer=adamw lr0=0.001 weight_decay=0.0001 \  patience=20 save_period=5 project=runs/train name=yolo9s-coco8 exist_ok=true

Notes

Les valeurs par défaut ci-dessus ne sont pas toujours celles utilisées

Chaque famille de modèles porte sa propre config d'entraînement, et là où cette config diffère de la config de base, sa valeur remplace la valeur par défaut de la commande pour tout argument que vous n'avez pas défini explicitement. Définir l'argument vous-même l'emporte toujours. libreyolo cfg affiche les valeurs par défaut de base et les surcharges par famille, ce qui est le moyen de voir ce qu'une famille donnée utilisera réellement.

imgsz est l'argument pour lequel cela compte le plus. La valeur par défaut de la commande est 640, qui n'est pas l'entrée native de tous les checkpoints : les tailles de détection publiées pour RF-DETR sont 384, 512, 576 et 704, et les checkpoints YOLOX n et t sont en 416. RF-DETR et DEIMv2 sont traités en ne transmettant imgsz que s'il a été défini explicitement, si bien que leur propre taille reste sinon en vigueur. Les autres familles reçoivent la valeur telle quelle et s'entraînent à cette taille. FOMO est la famille stricte : chaque taille n'accepte que son entrée native (96, 192 et 224), donc un run FOMO exige que imgsz soit réglé en conséquence, sinon il s'arrête sur une erreur. RF-DETR impose en plus que la valeur soit divisible par sa taille de patch multipliée par son nombre de fenêtres, et signale les deux tailles légales les plus proches lorsque ce n'est pas le cas.

Les arguments qu'une famille ignore

Toutes les familles ne lisent pas tous les arguments, et c'est sur ceux d'augmentation que cela se voit. RF-DETR, D-FINE, DEIM, DEIMv2, RT-DETRv4 et DINOv2 s'entraînent via des pipelines pass-through sans mosaic, sans mixup et sans déformation affine, si bien que mosaic, mixup, hsv_prob, degrees, translate, shear, mosaic_scale et mixup_scale n'atteignent rien chez elles. EC partage ce pipeline mais lit bien hsv_prob, degrees et translate quand sa tâche est pose. Les familles de classification ignorent cet ensemble sauf mixup, qui est pour elles un MixUp par batch, et elles lisent flip_prob. SegFormer, LingBot-Vision et NAFNet ignorent tout cet ensemble et flip_prob avec lui, parce que leur retournement s'applique à une probabilité fixe plutôt que configurable. YOLO-NAS ignore mosaic seul, puisqu'il augmente à la place avec une transformation affine par échantillon toujours active. RF-DETR en ignore trois autres au-delà de cette liste : optimizer, momentum et nesterov.

Définir l'un d'eux n'est pas une erreur. Le run écrit sur stderr une ligne qui nomme la famille et les arguments qu'elle ignorera, puis entraîne, et cette ligne est la liste faisant autorité pour la version installée. C'est aussi le seul signal, donc un run scripté avec quiet=true supprime cet avertissement en même temps que tout le reste sur stderr.

val=false est un cas voisin. Il met eval_interval à 0, ce qui désactive la validation pendant l'entraînement, dernière époque comprise, et le run n'écrit aucun best.pt.

Autres comportements à connaître

lora=true est accepté par RF-DETR, D-FINE, DEIM, DEIMv2, RT-DETR v1, v2 et v4, EC, GTR et ConvNeXt. Toute autre famille se termine avec config_unsupported plutôt que d'entraîner sans.

clip_max_norm est accepté par les familles dont la configuration d'entraînement le déclare : YOLOv9, YOLOv9-E2E et YOLOv9-P2, où il vaut 10 par défaut, et D-FINE, Dome-DETR, DEIM, DEIMv2, TinyFormer, RT-DETR, RT-DETRv2, RT-DETRv4, RF-DETR, DINOv2 et GTR, où il vaut 0.1 par défaut. Toute autre famille se termine avec config_unsupported, et une valeur négative ou non finie se termine avec config_type_error.

device=0,1 construit le modèle sur le premier GPU listé et transmet la liste à train(), qui démarre un processus par GPU. Voir l'entraînement multi-GPU.

RF-DETR n'a pas de transfert de la détection vers la segmentation. task=segment avec un checkpoint de segmentation RF-DETR charge ce checkpoint quel que soit son nom de fichier, parce que ce sont les métadonnées du checkpoint qui décident de la tâche, tandis qu'un checkpoint de détection s'arrête avec une erreur au lieu d'entraîner une tête de masques non entraînée.

pretrained=false combiné avec resume est refusé pour les familles qui prennent en charge l'entraînement à partir de zéro, puisque les deux demandent des choses opposées.

mosaic et mixup sont les orthographes en ligne de commande des champs de config mosaic_prob et mixup_prob ; sur un modèle de classification, mixup est à la place un MixUp par batch. Sur les familles dont le mixup ne s'applique qu'aux échantillons mosaic, mixup au-dessus de zéro avec mosaic à zéro ne se déclenche jamais, et le run le signale.

dry_run=true résout la référence du modèle, applique les valeurs par défaut de la famille et affiche la config avec laquelle il entraînerait. Il ne charge pas le dataset, c'est donc le moyen peu coûteux de confirmer qu'un argument a bien atteint la valeur que vous attendiez.

stdout porte l'objet de résultat final ; la progression et les avertissements vont sur stderr. Le code de sortie est 0 en cas de succès, 2 pour une erreur d'usage ou de configuration, 3 quand le dataset est introuvable ou illisible, 4 quand le modèle ne peut pas être chargé, et 1 pour les autres échecs d'exécution.

À voir aussi : libreyolo doctor pour vérifier un dataset avant de lancer un run, libreyolo monitor pour suivre un run dans le navigateur, libreyolo val pour mesurer le résultat.