libreyolo train

Synopsis

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

Argumente sind key=value-Paare, und die POSIX-Form funktioniert ebenfalls, epochs=50 und --epochs 50 sind also dasselbe Argument. Booleans akzeptieren true und false: amp=false wird zu --no-amp, wo das Flag eine negative Form hat.

Argumente

Modell und Daten

Trainingsschleife

Distillation

Optimizer

Scheduler

Augmentierung

EMA

Validierung während des Trainings

Ausgabe

Agent-Flags

Beispiele

# coco8.yaml liegt dem Paket bei und lädt seine 8 Bilder beim ersten Mal.libreyolo train model=LibreYOLO9s.pt data=coco8.yaml epochs=10 imgsz=640 batch=8

# Gibt aus, was der Run nutzen würde, inklusive Familien-Defaults, und# beendet sich, ohne zu trainieren oder Daten zu laden.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

Hinweise

Die Defaults oben sind nicht immer die genutzten Werte

Jede Modellfamilie bringt ihre eigene Trainingskonfiguration mit, und wo diese von der Basiskonfiguration abweicht, ersetzt ihr Wert den Default des Befehls für jedes Argument, das du nicht explizit gesetzt hast. Setzt du das Argument selbst, gewinnt das immer. libreyolo cfg gibt die Basis-Defaults und die Overrides je Familie aus, und das ist der Weg, um zu sehen, was eine bestimmte Familie tatsächlich nutzt.

imgsz ist das Argument, bei dem das am meisten zählt. Der Default des Befehls ist 640, und das ist nicht bei jedem Checkpoint die native Eingabe: die veröffentlichten RF-DETR-Größen für die Erkennung sind 384, 512, 576 und 704, und die YOLOX-Checkpoints n und t liegen bei 416. RF-DETR und DEIMv2 werden so behandelt, dass imgsz nur weitergereicht wird, wenn es explizit gesetzt wurde, sonst bleibt ihre eigene Größe in Kraft. Andere Familien bekommen den Wert so, wie er angegeben wurde, und trainieren damit. FOMO ist der strenge Fall: jede Größe akzeptiert nur ihre native Eingabe (96, 192 und 224), eine FOMO-Ausführung braucht also ein passend gesetztes imgsz, sonst bricht sie mit einem Fehler ab. RF-DETR verlangt zusätzlich, dass der Wert durch seine Patch-Größe mal seine Fensteranzahl teilbar ist, und meldet die beiden nächstgelegenen zulässigen Größen, wenn er es nicht ist.

Argumente, die eine Familie ignoriert

Nicht jede Familie liest jedes Argument, und bei den Augmentierungs-Argumenten zeigt sich das am deutlichsten. RF-DETR, D-FINE, DEIM, DEIMv2, RT-DETRv4 und DINOv2 trainieren über Pass-through-Pipelines ohne Mosaic, ohne Mixup und ohne affine Verzerrung, mosaic, mixup, hsv_prob, degrees, translate, shear, mosaic_scale und mixup_scale laufen dort also ins Leere. EC teilt sich diese Pipeline, liest aber hsv_prob, degrees und translate, wenn sein Task Pose ist. Die Klassifikationsfamilien ignorieren diesen Satz bis auf mixup, das bei ihnen Batch-MixUp ist, und sie lesen flip_prob. SegFormer, LingBot-Vision und NAFNet ignorieren den ganzen Satz und flip_prob gleich mit, weil ihr Spiegeln mit einer festen statt einer konfigurierbaren Wahrscheinlichkeit läuft. YOLO-NAS ignoriert allein mosaic, da es stattdessen mit einer immer aktiven affinen Transformation pro Sample augmentiert. RF-DETR ignoriert über diese Liste hinaus drei weitere: optimizer, momentum und nesterov.

Eines davon zu setzen ist kein Fehler. Der Run schreibt eine Zeile auf stderr, die die Familie und die Argumente nennt, die sie ignorieren wird, trainiert dann und diese Zeile ist die verbindliche Liste für die installierte Version. Sie ist außerdem das einzige Signal, ein geskripteter Run mit quiet=true unterdrückt die Warnung also zusammen mit allem anderen auf stderr.

val=false ist ein verwandter Fall. Es setzt eval_interval auf 0, was die Validierung während des Trainings abschaltet, die letzte Epoche eingeschlossen, und der Run schreibt kein best.pt.

Anderes Verhalten, das du kennen solltest

lora=true wird von RF-DETR, D-FINE, DEIM, DEIMv2, RT-DETR v1, v2 und v4, EC, GTR und ConvNeXt akzeptiert. Jede andere Familie beendet sich mit config_unsupported, statt ohne LoRA zu trainieren.

clip_max_norm wird von den Familien akzeptiert, deren Trainingskonfiguration es deklariert: YOLOv9, YOLOv9-E2E und YOLOv9-P2, wo es standardmäßig 10 ist, sowie D-FINE, Dome-DETR, DEIM, DEIMv2, TinyFormer, RT-DETR, RT-DETRv2, RT-DETRv4, RF-DETR, DINOv2 und GTR, wo es standardmäßig 0.1 ist. Jede andere Familie beendet sich mit config_unsupported, und ein negativer oder nicht endlicher Wert beendet sich mit config_type_error.

device=0,1 baut das Modell auf der ersten aufgeführten GPU und übergibt die Liste an train(), das einen Prozess pro GPU startet. Siehe Multi-GPU-Training.

RF-DETR hat keinen Transfer von Detect zu Segment. task=segment mit einem RF-DETR-Segment-Checkpoint lädt diesen Checkpoint unabhängig von seinem Dateinamen, weil die Metadaten des Checkpoints über den Task entscheiden, während ein Detektions-Checkpoint mit einem Fehler abbricht, statt einen untrainierten Masken-Head zu trainieren.

pretrained=false zusammen mit resume wird bei den Familien abgelehnt, die Training von Grund auf neu unterstützen, denn die beiden verlangen Gegensätzliches.

mosaic und mixup sind die Schreibweisen der Konfigurationsfelder mosaic_prob und mixup_prob auf der Kommandozeile; bei einem Klassifikationsmodell ist mixup stattdessen Batch-MixUp. Bei Familien, deren Mixup nur auf Mosaic-Samples wirkt, greift mixup über null bei mosaic auf null nie, und der Run sagt das auch.

dry_run=true löst die Modellreferenz auf, wendet die Defaults der Familie an und gibt die Konfiguration aus, mit der trainiert würde. Der Datensatz wird dabei nicht geladen, das ist also der billige Weg, um zu bestätigen, dass ein Argument den Wert erreicht hat, den du erwartet hast.

stdout trägt das finale Ergebnisobjekt; Fortschritt und Warnungen gehen auf stderr. Der Exit-Code ist 0 bei Erfolg, 2 bei einem Bedienungs- oder Konfigurationsfehler, 3 wenn der Datensatz nicht gefunden oder gelesen werden kann, 4 wenn das Modell nicht geladen werden kann, und 1 bei sonstigen Laufzeitfehlern.

Verwandt: libreyolo doctor, um einen Datensatz zu prüfen, bevor du dich auf einen Run festlegst, libreyolo monitor, um einen Run im Browser zu verfolgen, libreyolo val, um das Ergebnis zu messen.