Scripts

Un script de entrenamiento, validación, inferencia y limpieza de puntos de control incluido en la carpeta raíz de github. Los scripts no están empaquetados actualmente en la publicación de pip.

Los scripts de entrenamiento y validación evolucionaron a partir de versiones tempranas de PyTorch Imagenet Examples. Con el tiempo, he añadido funcionalidad significativa, incluidas mejoras de rendimiento específicas de CUDA basadas en NVIDIA’s APEX Examples.

Script de entrenamiento

La variedad de argumentos de entrenamiento es amplia y no todas las combinaciones de opciones (o incluso las opciones) se han probado por completo. Para la carpeta del conjunto de datos de entrenamiento, especifique la carpeta base que contiene una carpeta train y una carpeta validation.

Para una ejecución en un solo nodo, use torchrun con un proceso por GPU. Por ejemplo, después de guardar la configuración de MobileNetV4 como mobilenetv4.yaml:

torchrun --standalone --nproc_per_node=2 train.py \
  --config mobilenetv4.yaml --data-dir /data/imagenet --experiment mobilenetv4-cm

./distributed_train.sh 2 ... es un envoltorio práctico para torchrun. Para una GPU, use python train.py ... y ajuste el tamaño del lote y la tasa de aprendizaje como se describe en HParams.

`--amp` uses PyTorch native mixed precision, with float16 by default. Use `--amp-dtype bfloat16` on supported hardware. The examples below use native PyTorch AMP and DDP; Apex is not required.

Archivos de configuración

Cualquier argumento de entrenamiento puede proporcionarse en un archivo YAML mediante --config, utilizando como clave el nombre del argumento con guiones bajos (--weight-decay se convierte en weight_decay). Los argumentos de línea de comandos tienen prioridad sobre los del archivo. Cada ejecución escribe el conjunto completo de argumentos efectivos en args.yaml dentro de su carpeta de salida, y ese archivo es a su vez un --config válido, por lo que una ejecución puede reproducirse con python train.py --config output/train/my-run/args.yaml --experiment my-run-2. El archivo también registra output, experiment y resume, de modo que, sin un nuevo nombre de experimento, el comando escribe en la carpeta original, y con --resume auto continúa la ejecución original en lugar de repetirla. Las claves de la configuración se validan contra los argumentos del script: las claves desconocidas emiten una advertencia, y las opciones inválidas o los valores no numéricos para argumentos numéricos generan un error.

Reanudación y puntos de control de hitos

Cada ejecución escribe last.pth.tar (siempre la última época, con el estado del modelo, el optimizador, el EMA y el escalador AMP), model_best.pth.tar y un historial clasificado de archivos checkpoint-N.pth.tar limitado por --checkpoint-hist.

• --resume PATH restaura ese estado y continúa el plan de entrenamiento desde la época del punto de control. Esta es la forma habitual de iniciar una carpeta de experimento nueva a partir de un punto de control existente.
• --resume auto reanuda en el mismo lugar: con --output y --experiment configurados, continúa desde last.pth.tar en esa carpeta de experimento si existe, y de lo contrario inicia una ejecución nueva. El mismo comando puede volver a ejecutarse tras una interrupción. El historial de puntos de control, el seguimiento de la mejor métrica y summary.csv continúan de forma coherente, por lo que la expulsión de --checkpoint-hist y model_best se mantienen correctos a lo largo del reinicio.
• --stop-epoch N detiene el proceso después de N épocas completadas sin modificar el plan establecido por --epochs. La última época siempre se evalúa y se guarda un checkpoint, por lo que una ejecución puede entrenarse en segmentos.
• --save-epochs N [N ...] conserva instantáneas inmutables milestone-N.pth.tar (N es el número de épocas completadas) fuera del historial clasificado. Se crean mediante enlaces duros desde last.pth.tar cuando el sistema de archivos lo permite, por lo que no ocupan espacio adicional, y se fuerza una evaluación en esas épocas.

Juntas, estas características facilitan la ejecución manual de experimentos de calentamiento-estable-decaimiento (WSD): se entrena un tronco estable una vez y luego se derivan enfriamientos independientes desde sus hitos, con el estado completo del optimizador.

# stable trunk through 30 completed epochs, keeping milestones at 18, 24 and 30. The 1 epoch decay is never reached.
python train.py --config configs/vit.yaml --sched wsd --sched-on-updates --epochs 31 --decay-epochs 1 \
    --stop-epoch 30 --save-epochs 18 24 30 --output output/wsd --experiment stable --resume auto

# a 6 epoch 1-sqrt cooldown branched from epoch 24, i.e. a 30 epoch run that shares the first 24 epochs with the trunk
python train.py --config configs/vit.yaml --sched wsd --sched-on-updates --epochs 30 --decay-epochs 6 --lr-decay-fn 1-sqrt \
    --resume output/wsd/stable/milestone-24.pth.tar --output output/wsd --experiment decay-p24-d6

El decaimiento ocupa los últimos --decay-epochs del plan, por lo que un enfriamiento de D épocas a partir de P épocas completadas es --epochs P+D --decay-epochs D (resta --warmup-epochs de --epochs cuando se usa --warmup-prefix). sweep.py a continuación automatiza esto.

Barridos de hiperparámetros

sweep.py (PyTorch 2.5 o más reciente) planifica y ejecuta barridos sobre cualquier argumento de train.py, opcionalmente con ramificación WSD. Escribe un archivo completo de train.py --config por trabajo, además de un plan.json con el grafo de dependencias de los trabajos, y luego ejecuta los trabajos listos en un grupo de GPUs locales. El plan permanece fijo mientras los workers se ejecutan. Cada trabajo es una invocación ordinaria de train.py con su propia carpeta de experimento, y cada run.sh generado puede ejecutarse manualmente o pasarse a otro programador.

Un barrido rápido no requiere un archivo de especificación. Los ejes de búsqueda provienen de --sweep, y la configuración base de los argumentos finales de train.py después de --:

python sweep.py run --name lr-wd --sweep lr=1e-4,3e-4,1e-3 --sweep weight_decay=0.05,0.1 --gpus 0,1,2,3 \
    -- --model vit_small_patch16_224 --data-dir /data/imagenet --sched cosine --epochs 100 --amp

--gpus lista las GPU en las que se ejecutará, como índices en CUDA_VISIBLE_DEVICES cuando este está definido (por ejemplo, en una asignación de Slurm).

Un barrido WSD comparte un tronco estable por combinación de hiperparámetros a lo largo de muchos cooldowns. Para cada tasa de aprendizaje siguiente, el tronco se ejecuta hasta 30 épocas con hitos en 18, 24 y 30, y un cooldown de 6 épocas se ramifica desde cada hito, 4 troncos y 12 cooldowns en total en lugar de 12 ejecuciones completas. Los cooldowns comienzan en cuanto existe su hito, mientras el tronco continúa. Los trabajos que necesitan más de una GPU se lanzan con torchrun:

python sweep.py run --name vit-wsd --sweep lr=1e-3,5e-4,2e-4,1e-4 \
    --wsd-points 18 24 30 --wsd-decay-epochs 6 --wsd-decay-fn 1-sqrt --gpus-per-job 2 --gpus 0,1 \
    -- --model vit_small_patch16_224 --data-dir /data/imagenet --warmup-epochs 3 --warmup-prefix --amp

El planificador posee las siguientes banderas, por lo que no se pueden especificar en la línea de comandos ni se pueden barrer.

En cada barrido:

• --output
• --experiment
• --resume
• --stop-epoch
• --save-epochs

Además, en un barrido WSD:

• --sched (puede indicarse como wsd, que el planificador establece de todos modos)
• --epochs
• --decay-epochs
• --lr-decay-fn

Una especificación YAML añade búsqueda aleatoria con distribuciones, ejes emparejados (zipped), repeticiones sobre semillas y un archivo de configuración base; consulte la docstring al inicio de sweep.py para el esquema. python sweep.py plan spec.yaml escribe las configuraciones y graph.dot sin ejecutar nada.

El barrido se guarda en output/sweeps/<name>/, relativo al archivo de especificación (o al directorio de trabajo para un barrido de línea de comandos), con una carpeta por prueba, nombrada según los valores barridos (trial-000-lr0.001), cada una contiene las carpetas de experimentos del trabajo. Cada punto de control conservado es una copia completa con el estado del optimizador, por lo que los trabajos de barrido conservan un punto de control clasificado además de last.pth.tar y model_best.pth.tar (--checkpoint-hist 1), y los barridos WSD avanzan la programación por actualización (--sched-on-updates). Establecer cualquiera de ellos en la configuración base lo anula. Mientras se ejecuta, o después:

python sweep.py status output/sweeps/vit-wsd    # job states and progress
python sweep.py results output/sweeps/vit-wsd   # ranked endpoint metrics, written to results.csv

Los resultados comparan ensayos con presupuestos iguales. Un barrido WSD muestra una fila por ensayo y una columna por cooldown (p24-d6 es un cooldown de 6 epochs a partir de 24 epochs) con la métrica final, promediada sobre las repeticiones, y lo mejor de cada columna marcado. Un barrido simple se clasifica por su métrica final dentro de cada presupuesto de epochs. results.csv contiene todos los trabajos, incluidos los segmentos de trunk, con el mejor epoch de cada uno. Sin un conjunto de validación, la clasificación se basa en la pérdida de entrenamiento, y los checkpoints del punto final pueden evaluarse con validate.py.

Si se vuelve a ejecutar sweep.py run en un barrido interrumpido, este se reanuda: se omiten los trabajos finalizados y un trabajo con una ejecución parcial continúa desde su propio last.pth.tar. Los workers de varias máquinas que comparten la carpeta del barrido pueden ejecutarlo cada uno. Se coordinan mediante bloqueos flock bajo state/locks, que también mantiene cada proceso de entrenamiento de un trabajo, de modo que un trabajo cuyo worker falleció no se inicia de nuevo ni se reprograma hasta que su último proceso haya terminado. Un barrido compartido por varias máquinas requiere un sistema de archivos cuyo flock funcione entre todas ellas, como NFSv4 o Lustre montado con -o flock. Las monturas con bloqueo solo local no se coordinan entre máquinas, por lo que hay que verificar el bloqueo desde cada cliente. Detener un worker (Ctrl-C, o SIGTERM desde scancel) detiene sus trabajos, y ejecutar el run.sh de un trabajo a mano omite la coordinación.

Los archivos de bloqueo bajo state/locks son permanentes: nunca los elimines ni los reemplaces para despejar un barrido ocupado. En su lugar, detén o espera a que terminen sus workers y procesos de entrenamiento. Un estado running (gone) significa que el bloqueo de entrenamiento está libre, pero el intento no se ha reconciliado; ejecuta un worker para resolverlo y reanudar el trabajo incompleto. status y results no reparan el estado del trabajo.

Un worker lee el plan una sola vez al iniciar. Para cambiar un sweep, detenga todos sus workers y procesos de entrenamiento, vuelva a planificar con --force y luego inicie todo de nuevo. Antes de que comience cualquier trabajo, cualquier aspecto del plan puede cambiar. Después, sus trabajos de entrenamiento solo pueden extenderse: más trials, cooldowns o puntos WSD después de los existentes, donde cada trunk continúa desde donde se detuvo. Los cambios en los trabajos de entrenamiento existentes requieren un nuevo sweep. Las rutas generadas se fijan cuando se escribe el plan, por lo que vuelva a planificar en una nueva ubicación en lugar de mover la carpeta del sweep.

Si la planificación se interrumpe, los workers detectan configuraciones o launchers de una escritura de plan incompleta y se niegan a iniciar. Vuelva a ejecutar el comando de planificación original con --force para finalizar o reparar el plan y, a continuación, reinicie los workers. Cada escritura de plan exitosa publica una generación correspondiente en plan.json, las configuraciones y los launchers; un plan completo e inalterado no escribe nada.

Por ejemplo, para extender el barrido de WSD de la CLI anterior a 36 épocas estables, detenga sus workers y jobs, y luego repita los argumentos de planificación originales con el punto posterior añadido:

python sweep.py plan --force --name vit-wsd --sweep lr=1e-3,5e-4,2e-4,1e-4 \
    --wsd-points 18 24 30 36 --wsd-decay-epochs 6 --wsd-decay-fn 1-sqrt --gpus-per-job 2 \
    -- --model vit_small_patch16_224 --data-dir /data/imagenet --warmup-epochs 3 --warmup-prefix --amp
python sweep.py run output/sweeps/vit-wsd --gpus 0,1

Para un barrido YAML, agregue el punto en la especificación original y ejecute python sweep.py plan spec.yaml --force antes de reiniciar. Mantenga wsd.decay_epochs explícito y sin cambios ([6] en este ejemplo): su valor predeterminado es el 20 % del punto final, por lo que extender el horizonte puede cambiar los periodos de enfriamiento existentes de otra manera. Preserve los ID de prueba existentes; reordenar o expandir los ejes de la cuadrícula puede renumerar las pruebas. Con lr_noise, la programación del tronco depende de su horizonte, por lo que agregar un punto posterior a un barrido iniciado requiere un nuevo barrido.

Las configuraciones de entrenamiento deben incluirse en el plan: use el bloque train de la especificación, o los argumentos después de -- al crear un barrido de CLI. No hay sobrescrituras de entrenamiento en tiempo de ejecución. Las configuraciones de informes, como la métrica de clasificación, y las configuraciones de salida (checkpoint_hist, log_wandb, wandb_project, wandb_tags) pueden modificarse sin conexión con --force sin restablecer el estado del trabajo ni cambiar la identidad del entrenamiento. Las configuraciones de salida se aplican a intentos futuros; los trabajos completados no se vuelven a ejecutar.

sweep.py requiere flock de Unix: probado en Linux, se espera que funcione pero no está probado en macOS. Windows nativo no es compatible; usa WSL2. Los bloqueos no sobreviven a una partición de red que dure más que una concesión NFS: un proceso desconectado puede seguir entrenando después de perder sus bloqueos, por lo que otra máquina puede iniciar un intento superpuesto.

Scripts de validación / inferencia

Los scripts de validación y de inferencia tienen un uso similar. Uno imprime métricas sobre un conjunto de validación y el otro imprime los topk ids de clase en un csv. Especifique la carpeta que contiene las imágenes de validación, no la base como en el script de entrenamiento.

Para validar con los pesos preentrenados del modelo (si existen):

python validate.py --data-dir /imagenet/validation/ --model seresnext26_32x4d --pretrained

Para ejecutar la inferencia desde un punto de control:

python inference.py --data-dir /imagenet/validation/ --model mobilenetv3_large_100 --checkpoint ./output/train/model_best.pth.tar

Ejemplos de entrenamiento

Recetas de entrenamiento en ImageNet

Estos comandos corresponden a las recetas de HParams seleccionadas, donde puedes encontrar configuraciones YAML copiables, gists de código fuente y resultados de checkpoints publicados. Asumen datos de ImageFolder en /data/imagenet/train/ y /data/imagenet/validation/. --batch-size es por GPU. Las tasas de aprendizaje explícitas en los ejemplos de MobileNetV4 y ConvNeXt se aplican a los tamaños de lote globales indicados; no se escalan automáticamente si cambia el número de GPUs.

MobileNetV4 Conv Medium, ImageNet-1k

De mnv4_cm_r256_e500_gpu2.yaml: 2 GPUs, lote global 1024, entrenamiento de 256px y 20 épocas de calentamiento + 500 épocas coseno. Los pesos correspondientes son mobilenetv4_conv_medium.e500_r256_in1k.

torchrun --standalone --nproc_per_node=2 train.py --data-dir /data/imagenet \
  --model mobilenetv4_conv_medium.e500_r256_in1k --img-size 256 --crop-pct 0.95 --batch-size 512 \
  --opt adamw --lr 0.002 --weight-decay 0.1 --clip-grad 5.0 \
  --sched cosine --sched-on-updates --epochs 500 --warmup-epochs 20 --warmup-prefix \
  --warmup-lr 0 --min-lr 0 --cooldown-epochs 0 \
  --aa rand-m8-inc1-mstd1.0 --mixup 0.2 --mixup-prob 0.8 --smoothing 0.1 \
  --reprob 0.25 --remode pixel --drop 0.2 --drop-path 0.1 \
  --model-ema --model-ema-decay 0.9998 --model-ema-warmup --dist-bn reduce \
  --amp --amp-dtype bfloat16 --torchcompile inductor --experiment mobilenetv4-cm

Use --amp-dtype float16 si su GPU no admite bfloat16; --torchcompile inductor es opcional.

ViT Medium con registros, ImageNet-1k

De train-vit_medium_reg4-4gpu-in1k.yaml: 4 GPUs, lote global de 1024 y 600 épocas, incluyendo 10 épocas de calentamiento y 10 de enfriamiento. Los pesos correspondientes son vit_medium_patch16_reg4_gap_256.sbb_in1k.

torchrun --standalone --nproc_per_node=4 train.py --data-dir /data/imagenet \
  --model vit_medium_patch16_reg4_gap_256.sbb_in1k --model-kwargs fix_init=True --head-init-scale 0 \
  --img-size 256 --crop-pct 0.95 --batch-size 256 \
  --opt adamw --opt-eps 1e-8 --lr-base 0.0008 --lr-base-size 512 --lr-base-scale sqrt \
  --weight-decay 0.07 --clip-grad 5.0 --sched cosine --sched-on-updates \
  --epochs 600 --warmup-epochs 20 --warmup-lr 5e-7 --min-lr 5e-7 --cooldown-epochs 10 \
  --aa rand-m7-inc1-mstd1.0-n3 --aug-repeats 3 --color-jitter 0 \
  --mixup 0.8 --cutmix 1.0 --smoothing 0.1 --reprob 0.2 --remode pixel --drop-path 0.2 \
  --seed 0 --amp --amp-dtype float16 --torchcompile inductor --experiment vit-medium-sbb

Esta ejecución utiliza AdamW sin EMA. Su LR máxima es aproximadamente 0.001131 en el lote global 1024.

ConvNeXt Tiny, ajuste fino de ImageNet-12k a ImageNet-1k

De hparams_84_00-convnext_tiny.in12k-args.yaml: 8 GPUs, lote global de 4096 y 75 épocas, incluyendo warmup + 10 épocas de cooldown. Carga los pesos de ImageNet-12k y establece --num-classes 1000 para reemplazar el clasificador y realizar fine-tuning. La familia de checkpoints resultante es convnext_tiny.in12k_ft_in1k.

torchrun --standalone --nproc_per_node=8 train.py --data-dir /data/imagenet \
  --model convnext_tiny.in12k --pretrained --num-classes 1000 \
  --img-size 224 --crop-pct 1.0 --batch-size 512 --grad-checkpointing \
  --opt adamw --lr 1e-4 --weight-decay 0.05 --layer-decay 0.75 --clip-grad 3.0 \
  --sched cosine --epochs 75 --warmup-epochs 10 --warmup-lr 1e-6 --min-lr 5e-7 \
  --cooldown-epochs 10 --lr-noise 0.1 1.0 \
  --aa rand-m8-inc1-mstd101 --mixup 0.8 --cutmix 1.0 --smoothing 0.1 \
  --reprob 0.3 --remode pixel --drop-path 0.1 --model-ema --model-ema-decay 0.9998 \
  --amp --amp-dtype float16 --experiment convnext-tiny-ft

Clasificación multi-etiqueta

Use --task multilabel para imágenes con múltiples etiquetas independientes.

• --num-classes define el tamaño del vocabulario.
• --target-format indices (predeterminado) lee la columna de destino como una lista de IDs de clase positivos, basados en cero. Las etiquetas se convierten en objetivos multi-hot de tipo float antes de formar los lotes, y las listas vacías representan imágenes sin etiquetas positivas.
• --target-format multihot lee un vector multi-hot denso de longitud --num-classes (valores bool, int o float en [0, 1]). El vector se usa tal cual, por lo que los valores suaves se entrenan directamente con BCE y se binarizan en 0.5 para las métricas de evaluación. Los mapas de clases para objetivos multi-hot deben tener como clave el índice de la clase de origen.

Sin la bandera, cada lista se lee como índices de clase, ya que un vector multi-hot de enteros es indistinguible de una lista de índices.

El conjunto de datos de patología vegetal proporciona este formato: una columna image y una columna labels que contiene una secuencia de valores de ClassLabel. Sus seis clases son complex, frog_eye_leaf_spot, healthy, powdery_mildew, rust y scab. Por ejemplo, [5, 1, 0] se convierte en [1, 1, 0, 0, 0, 1].

python train.py --dataset hfds/timm/plant-pathology-2021 \
  --task multilabel --target-key labels --num-classes 6 \
  --model resnet50 --pretrained --batch-size 32 --epochs 30 \
  --opt adamw --lr 1e-4 --weight-decay 0.01 --amp

python validate.py --dataset hfds/timm/plant-pathology-2021 \
  --task multilabel --target-key labels --num-classes 6 \
  --model resnet50 --checkpoint ./output/train/<experiment>/model_best.pth.tar

hfids/timm/plant-pathology-2021 admite streaming con el mismo formato de destino. Soporte de lectores:

• Hugging Face hfds y hfids admiten objetivos de múltiples etiquetas.
• WebDataset (wds) admite listas de identificadores de clase almacenados en el archivo lateral .json de cada muestra, bajo el campo denominado por --target-key. Sin --target-key, el archivo .cls proporciona un único índice de clase.
• Los lectores de carpetas y archivos tar Folder and tar readers devuelven índices de una sola clase.

Los conjuntos de datos que almacenan un campo binario por etiqueta, como Wake Vision, usan estas configuraciones:

• --target-key person,depiction,body_part selecciona una lista de campos separados por comas. Cada campo se convierte en una clase en el orden indicado, y los valores mayores que cero se cuentan como positivos. Esto funciona con los lectores hfds, hfids y tfds, y con WebDataset cuando los campos están en el sidecar .json.
• --num-classes debe ser igual al número de campos.
• --target-format se mantiene en su valor predeterminado, ya que las claves de múltiples campos definen su propio formato.
• Las rutas de campos anidados utilizan /, por ejemplo --input-key input --target-key output/pollen_output,output/wasps_output para el bee_dataset de TFDS. Las claves de destino individuales aceptan las mismas rutas. Un nombre de campo literal que contiene / (como image/filename de TFDS) tiene prioridad sobre una ruta.

Los cargadores Standard y NaFlex admiten objetivos multietiqueta, incluidos mixup y cutmix; el entrenamiento con NaFlex actualmente requiere un conjunto de datos de estilo mapa, como hfds.

La tarea se entrena con entropía cruzada binaria con logits. El suavizado predeterminado es cero para el entrenamiento multietiqueta; establecer --smoothing s desplaza cada objetivo binario a target * (1 - s) + 0.5 * s, aplicado por Mixup/CutMix cuando están activos y por la función de pérdida en caso contrario. Las opciones existentes --bce-sum y --bce-target-thresh también se aplican. La destilación y la pérdida JSD no son compatibles con esta tarea.

--loss selecciona otras pérdidas (bce es el valor predeterminado para multietiquetas):

• asl: Asymmetric Loss. Sigue el mismo comportamiento de suavizado y Mixup/CutMix que BCE y se calcula en float32, por lo que es seguro con --amp.

  • --asl-gamma-neg establece el enfoque para los objetivos negativos (valor predeterminado 4).
  • --asl-gamma-pos establece el enfoque para los objetivos positivos (valor predeterminado 1).
  • --asl-clip establece el margen de probabilidad para los negativos (valor predeterminado 0.05).
  • --asl-reduction tiene como valor predeterminado batchmean, que suma la pérdida sobre las clases y promedia sobre el lote. sum restaura la reducción original de ASL, que también suma sobre el lote, de modo que la tasa de aprendizaje efectiva escala con el tamaño del lote.

• twoway: Pérdida de multi-etiqueta bidireccional, que contrasta los logits positivos y negativos entre las clases de cada muestra y las muestras de cada clase. Sus logits son puntuaciones de clasificación, por lo que mAP es la métrica significativa; F1 en un umbral sigmoidal no está calibrado.

  • --twoway-tp establece la temperatura del logit positivo (valor predeterminado 4).
  • --twoway-tn establece la temperatura del logit negativo (valor predeterminado 1).

• zlpr: ZLPR, una extensión multi-etiqueta de la entropía cruzada de softmax sin hiperparámetros, con 0 como umbral de logit integrado.

• db: Distribution-Balanced Loss para datos multietiqueta con cola larga. BCE con pesos de reequilibrio por muestra que tienen en cuenta la coocurrencia de etiquetas, regularización tolerante a negativos de los logits y un término focal. Admite Mixup/CutMix y suavizado, con valores predeterminados de la configuración de referencia DB:

  • --db-neg-scale establece la escala de logits negativos (valor predeterminado: 2).
  • --db-init-bias establece el factor de desplazamiento del logit de la clase previa (valor predeterminado 0.05).
  • --db-focal-gamma establece el enfoque focal (valor predeterminado 2).
  • --class-stats proporciona las cantidades de etiquetas de entrenamiento requeridas como un archivo de estadísticas de clases (a continuación).

twoway y zlpr requieren objetivos binarios, por lo que no admiten Mixup/CutMix ni --smoothing.

Para distribuciones de etiquetas sesgadas, bce y asl admiten dos banderas de ponderación:

• --loss-pos-weight pondera el término positivo de cada clase, equilibrando los positivos frente a los negativos dentro de una clase. Esto también desplaza las predicciones hacia el lado positivo (mayor recuperación en un umbral fijo, probabilidades menos calibradas).
• --loss-class-weight pondera la pérdida total de cada clase, equilibrando las clases entre sí y manteniendo la calibración.

Cada flag acepta pesos explícitos (un único valor, una lista separada por comas con un valor por clase, o un archivo) o un nombre de método que deriva los pesos a partir de las cantidades de etiquetas de entrenamiento proporcionadas con --class-stats:

• --loss-pos-weight neg_pos: negativos / positivos por clase.
• --loss-class-weight inv_freq: frecuencia inversa de la clase, normalizada a una media de 1.
• --loss-class-weight effective_num: pesos class-balanced a partir del número efectivo de muestras, normalizados a una media de 1.

Opciones de pesos derivados:

• --loss-weight-power establece el exponente para neg_pos y inv_freq (valor predeterminado 1), con 0.5 para un reponderado más suave de la raíz cuadrada.
• --loss-weight-beta establece beta para los pesos de effective_num (valor predeterminado 0.999).
• --loss-weight-max limita los pesos derivados.

Ambas banderas de ponderación pueden usar las mismas estadísticas. class_weights.py cuenta las etiquetas de una partición, con los mismos argumentos de conjunto de datos que train.py, y escribe el archivo de estadísticas de clases (--method muestra las ponderaciones de un método):

python class_weights.py --dataset hfds/timm/plant-pathology-2021 --split train \
  --task multilabel --target-key labels --num-classes 6 --output stats.json

python train.py --dataset hfds/timm/plant-pathology-2021 \
  --task multilabel --target-key labels --num-classes 6 \
  --class-stats stats.json --loss-pos-weight neg_pos --loss-weight-power 0.5 ...

Banderas obsoletas:

Los informes de validación muestran la pérdida BCE, map (precisión media promedio), micro_f1, macro_f1 y sample_f1. Las métricas son porcentajes y utilizan el conjunto de validación completo, incluidas las predicciones recopiladas en los rangos distribuidos. Se excluye el relleno del muestreador distribuido ordenado. El mAP exacto conserva las predicciones en la CPU hasta que termina la evaluación, por lo que su uso de memoria escala con el número de ejemplos y clases. Las clases sin positivos contribuyen con un AP cero; los valores de F1 con un denominador cero son cero.

--eval-metric map es el valor predeterminado para la selección de puntos de control y la programación. F1 utiliza un umbral de probabilidad sigmoid de 0.5, configurable con --multilabel-threshold; mAP es independiente de este umbral. Las salidas del modelo siguen siendo logits, por lo que se debe aplicar sigmoid para obtener probabilidades de clase independientes al utilizar el modelo entrenado.

Recetas de ImageNet históricas

Estas ejecuciones anteriores siguen siendo referencias útiles para el entrenamiento con RMSProp, SGD y AugMix/JSD. El hardware y las métricas reportadas describen las ejecuciones originales. Para las recetas más recientes de AdamW, comience con los ejemplos anteriores o con las colecciones de gists.

EfficientNet-B2 con RandAugment - 80,4 top-1, 95,1 top-5

La ejecución original utilizó tarjetas dual Titan RTX con NVIDIA Apex; el actual --amp utiliza AMP nativo de PyTorch:

./distributed_train.sh 2 --data-dir /imagenet/ --model efficientnet_b2 -b 128 --sched step --epochs 450 --decay-epochs 2.4 --decay-rate .97 --opt rmsproptf --opt-eps .001 -j 8 --warmup-lr 1e-6 --weight-decay 1e-5 --drop 0.3 --drop-path 0.2 --model-ema --model-ema-decay 0.9999 --aa rand-m9-mstd0.5 --remode pixel --reprob 0.2 --amp --lr .016

MixNet-XL con RandAugment - 80.5 top-1, 94.9 top-5

La ejecución original utilizó tarjetas dual Titan RTX con NVIDIA Apex; el actual --amp utiliza AMP nativo de PyTorch:

./distributed_train.sh 2 --data-dir /imagenet/ --model mixnet_xl -b 128 --sched step --epochs 450 --decay-epochs 2.4 --decay-rate .969 --opt rmsproptf --opt-eps .001 -j 8 --warmup-lr 1e-6 --weight-decay 1e-5 --drop 0.3 --drop-path 0.2 --model-ema --model-ema-decay 0.9999 --aa rand-m9-mstd0.5 --remode pixel --reprob 0.3 --amp --lr .016 --dist-bn reduce

SE-ResNeXt-26-D y SE-ResNeXt-26-T

Estos hparams (o similares) funcionan bien para una amplia gama de arquitecturas ResNet; por lo general, es una buena idea aumentar el número de epochs a medida que aumenta el tamaño del modelo… es decir, aproximadamente 180-200 para ResNe(X)t50, y 220+ para modelos más grandes. Aumenta el tamaño del batch y la LR proporcionalmente para GPUs más potentes o con AMP habilitado. Estos parámetros eran para 2 tarjetas 1080Ti:

./distributed_train.sh 2 --data-dir /imagenet/ --model seresnext26t_32x4d --lr 0.1 --warmup-epochs 5 --epochs 160 --weight-decay 1e-4 --sched cosine --reprob 0.4 --remode pixel -b 112

EfficientNet-B3 con RandAugment - 81,5 top-1, 95,7 top-5

El entrenamiento de este modelo comenzó con la misma línea de comandos que EfficientNet-B2 w/ RA anterior. Después de casi tres semanas de entrenamiento, el proceso se interrumpió. Los resultados no parecían impresionantes, así que reanudé el entrenamiento varias veces con ajustes a algunos parámetros (aumentar la probabilidad de RE, disminuir rand-aug, aumentar ema-decay). Nada parecía bueno. Al final, promedié los mejores checkpoints de todas las reiniciaciones. El resultado es mediocre con la resolución/recorte predeterminado, pero curiosamente rinde mucho mejor con un recorte de prueba de imagen completa de 1.0.

EfficientNet-B0 con RandAugment - 77,7 top-1, 95,3 top-5

Michael Klachko logró estos resultados con la línea de comandos para B2 adaptada para un tamaño de lote mayor, con la tasa de dropout recomendada de B0 de 0.2.

./distributed_train.sh 2 --data-dir /imagenet/ --model efficientnet_b0 -b 384 --sched step --epochs 450 --decay-epochs 2.4 --decay-rate .97 --opt rmsproptf --opt-eps .001 -j 8 --warmup-lr 1e-6 --weight-decay 1e-5 --drop 0.2 --drop-path 0.2 --model-ema --model-ema-decay 0.9999 --aa rand-m9-mstd0.5 --remode pixel --reprob 0.2 --amp --lr .048

ResNet50 con pérdida JSD y RandAugment (limpio + 2x aumentos RA) - 79.04 top-1, 94.39 top-5

Entrenado en dos tarjetas 1080Ti más antiguas, esto llevó un tiempo. El resultado de validación en ImageNet es solo ligeramente mejor, no de forma estadísticamente significativa, que mi primer buen entrenamiento con AugMix de 78.99. Sin embargo, estos pesos son más robustos en pruebas con ImageNetV2, ImageNet-Sketch, etc. A diferencia de mis primeras ejecuciones de AugMix, habilité SplitBatchNorm, deshabilité el borrado aleatorio en la división limpia y aumenté la probabilidad de borrado aleatorio en las 2 rutas aumentadas.

./distributed_train.sh 2 --data-dir /imagenet -b 64 --model resnet50 --sched cosine --epochs 200 --lr 0.05 --amp --remode pixel --reprob 0.6 --aug-splits 3 --aa rand-m9-mstd0.5-inc1 --resplit --split-bn --loss jsd --dist-bn reduce

EfficientNet-ES (EdgeTPU-Small) con RandAugment - 78.066 top-1, 93.926 top-5

Entrenado por Andrew Lavin con 8 tarjetas V100. No se utilizó EMA del modelo; el punto de control final es el promedio de los 8 mejores puntos de control durante el entrenamiento.

./distributed_train.sh 8 --data-dir /imagenet --model efficientnet_es -b 128 --sched step --epochs 450 --decay-epochs 2.4 --decay-rate .97 --opt rmsproptf --opt-eps .001 -j 8 --warmup-lr 1e-6 --weight-decay 1e-5 --drop 0.2 --drop-path 0.2  --aa rand-m9-mstd0.5 --remode pixel --reprob 0.2 --amp --lr .064

MobileNetV3-Large-100 - 75.766 top-1, 92.542 top-5

./distributed_train.sh 2 --data-dir /imagenet/ --model mobilenetv3_large_100 -b 512 --sched step --epochs 600 --decay-epochs 2.4 --decay-rate .973 --opt rmsproptf --opt-eps .001 -j 7 --warmup-lr 1e-6 --weight-decay 1e-5 --drop 0.2 --drop-path 0.2 --model-ema --model-ema-decay 0.9999 --aa rand-m9-mstd0.5 --remode pixel --reprob 0.2 --amp --lr .064 --lr-noise 0.42 0.9

ResNeXt-50 32x4d con RandAugment - 79.762 top-1, 94.60 top-5

Estos parámetros también funcionan bien para SE-ResNeXt-50 y SK-ResNeXt-50 y probablemente para 101. Los usé para el SK-ResNeXt-50 32x4d que entrené con 2 GPU usando una LR ligeramente más alta por tamaño de lote efectivo (lr=0.18, b=192 por GPU). La línea de comandos de abajo está ajustada para el entrenamiento con 8 GPU.

./distributed_train.sh 8 --data-dir /imagenet --model resnext50_32x4d --lr 0.6 --warmup-epochs 5 --epochs 240 --weight-decay 1e-4 --sched cosine --reprob 0.4 --recount 3 --remode pixel --aa rand-m7-mstd0.5-inc1 -b 192 -j 6 --amp --dist-bn reduce