libreyolo train

Sinopse

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

Os argumentos são pares key=value, e a forma POSIX também funciona, então epochs=50 e --epochs 50 são o mesmo argumento. Os booleanos aceitam true e false: amp=false vira --no-amp onde a flag tem forma negativa.

Argumentos

Modelo e dados

Loop de treinamento

Destilação

Otimizador

Scheduler

Data augmentation

EMA

Validação durante o treinamento

Saída

Flags de agente

Exemplos

# coco8.yaml vem com o pacote e baixa suas 8 imagens no primeiro uso.libreyolo train model=LibreYOLO9s.pt data=coco8.yaml epochs=10 imgsz=640 batch=8

# Imprime o que a execução usaria, incluindo os padrões da família, e sai# sem treinar nem carregar dados.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

Notas

Os padrões acima nem sempre são os valores usados

Cada família de modelos carrega sua própria config de treinamento e, onde essa config difere da base, o valor dela substitui o padrão do comando para qualquer argumento que você não tenha definido explicitamente. Definir o argumento você mesmo sempre vence. libreyolo cfg imprime os padrões base e as sobrescritas por família, que é a forma de ver o que uma dada família vai realmente usar.

imgsz é o argumento em que isso mais importa. O padrão do comando é 640, que não é a entrada nativa de todo checkpoint: os tamanhos de detecção publicados do RF-DETR são 384, 512, 576 e 704, e os checkpoints n e t do YOLOX são 416. RF-DETR e DEIMv2 são tratados repassando imgsz apenas quando ele foi definido explicitamente, então o tamanho próprio deles continua valendo caso contrário. As outras famílias recebem o valor como veio e treinam nele. FOMO é a rigorosa: cada tamanho aceita apenas sua entrada nativa (96, 192 e 224), então uma execução de FOMO precisa de imgsz definido para corresponder, ou ela para com erro. O RF-DETR ainda exige que o valor seja divisível pelo tamanho do patch vezes a contagem de janelas, e informa os dois tamanhos válidos mais próximos quando não é.

Argumentos que uma família ignora

Nem toda família lê todo argumento, e é nos de data augmentation que isso aparece. RF-DETR, D-FINE, DEIM, DEIMv2, RT-DETRv4 e DINOv2 treinam por pipelines de passagem direta, sem mosaic, sem mixup e sem warp afim, então mosaic, mixup, hsv_prob, degrees, translate, shear, mosaic_scale e mixup_scale não chegam a nada ali. A EC compartilha esse pipeline, mas lê sim hsv_prob, degrees e translate quando sua tarefa é pose. As famílias de classificação ignoram esse conjunto exceto mixup, que para elas é MixUp por batch, e leem flip_prob. SegFormer, LingBot-Vision e NAFNet ignoram esse conjunto inteiro e flip_prob junto, porque o flip delas roda com uma probabilidade fixa em vez de configurável. A YOLO-NAS ignora só mosaic, já que faz augmentation com uma transformação afim por amostra sempre ligada. O RF-DETR ignora mais três além dessa lista: optimizer, momentum e nesterov.

Definir um desses não é erro. A execução registra uma linha no stderr nomeando a família e os argumentos que ela vai ignorar, depois treina, e essa linha é a lista autoritativa para a versão instalada. Ela também é o único sinal, então uma execução em script com quiet=true suprime o aviso junto com todo o resto do stderr.

val=false é um caso relacionado. Ele define eval_interval como 0, o que desliga a validação durante o treinamento, incluindo a época final, e a execução não grava nenhum best.pt.

Outros comportamentos que vale conhecer

lora=true é aceito por RF-DETR, D-FINE, DEIM, DEIMv2, RT-DETR v1, v2 e v4, EC, GTR e ConvNeXt. Qualquer outra família sai com config_unsupported em vez de treinar sem isso.

clip_max_norm é aceito pelas famílias cuja config de treinamento o declara: YOLOv9, YOLOv9-E2E e YOLOv9-P2, onde o padrão é 10, e D-FINE, Dome-DETR, DEIM, DEIMv2, TinyFormer, RT-DETR, RT-DETRv2, RT-DETRv4, RF-DETR, DINOv2 e GTR, onde o padrão é 0.1. Qualquer outra família sai com config_unsupported, e um valor negativo ou não finito sai com config_type_error.

device=0,1 constrói o modelo na primeira GPU da lista e passa a lista para o train(), que inicia um processo por GPU. Veja treinamento multi-GPU.

O RF-DETR não tem transferência de detect para segment. task=segment com um checkpoint segment do RF-DETR carrega esse checkpoint seja qual for o nome do arquivo, porque os metadados do checkpoint decidem a tarefa, enquanto um checkpoint de detecção para com um erro em vez de treinar uma cabeça de máscara não treinada.

pretrained=false combinado com resume é recusado para as famílias que suportam treinamento do zero, já que os dois pedem coisas opostas.

mosaic e mixup são as grafias de linha de comando dos campos de config mosaic_prob e mixup_prob; em um modelo de classificação, mixup é MixUp por batch. Nas famílias cujo mixup só se aplica a amostras de mosaic, mixup acima de zero com mosaic em zero nunca dispara, e a execução diz isso.

dry_run=true resolve a referência do modelo, aplica os padrões da família e imprime a config com que treinaria. Ele não carrega o dataset, então é a forma barata de confirmar que um argumento chegou ao valor que você esperava.

O stdout carrega o objeto de resultado final; progresso e avisos vão para o stderr. O código de saída é 0 em caso de sucesso, 2 para um erro de uso ou de configuração, 3 quando o dataset não pode ser encontrado ou lido, 4 quando o modelo não pode ser carregado, e 1 para outras falhas de runtime.

Relacionados: libreyolo doctor para conferir um dataset antes de se comprometer com uma execução, libreyolo monitor para acompanhar uma execução no navegador, libreyolo val para medir o resultado.