timm documentation

スクリプト

Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

スクリプト

GitHubのルートフォルダに含まれる、学習、検証、推論、およびチェックポイントのクリーンアップ用スクリプトです。現在、これらのスクリプトはpipリリースにはパッケージ化されていません。

学習および検証スクリプトは、PyTorch Imagenet Examplesの初期バージョンから発展してきました。時間の経過とともに、NVIDIA’s APEX Examplesに基づくCUDA固有のパフォーマンス向上機能など、大幅な機能追加を行ってきました。

トレーニングスクリプト

トレーニング引数の種類は多岐にわたり、オプションのすべての組み合わせ(あるいはオプション自体)が完全にテストされているわけではありません。トレーニングデータセットのフォルダーについては、trainフォルダーとvalidationフォルダーを含むベースのフォルダーを指定してください。

単一ノードでの実行には、GPUごとに1プロセスでtorchrunを使用します。例えば、MobileNetV4の設定をmobilenetv4.yamlとして保存した後:

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

./distributed_train.sh 2 ... は torchrun のラッパーです。 1つのGPUを使用する場合は、python train.py ... を使用し、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.

設定ファイル

すべてのトレーニング引数は、--config を介して YAML ファイルで指定できます。キーはアンダースコア付きの引数名で指定します(--weight-decay は weight_decay になります)。コマンドライン引数はファイルの内容を上書きします。各実行では、有効な引数の完全なセットが出力フォルダ内の args.yaml に書き込まれ、そのファイル自体が有効な --config として機能するため、python train.py --config output/train/my-run/args.yaml --experiment my-run-2 を実行することで、実行を再現できます。ファイルには output、experiment、resume も記録されるため、新しい実験名を指定しないとコマンドは元のフォルダに書き込み、--resume auto を使用すると、実行を繰り返すのではなく元の実行を継続します。設定のキーはスクリプトの引数に対して検証されます。不明なキーは警告が表示され、無効な選択肢や数値引数の非数値値はエラーになります。

再開とマイルストーンチェックポイント

各ランでは、last.pth.tar(常に最新のepochであり、モデル、オプティマイザー、EMA、AMPスケーラーの状態を含む)、model_best.pth.tar、および--checkpoint-histで制限されたcheckpoint-N.pth.tarファイルのランキング付き履歴が書き込まれます。

  • --resume PATH は、その状態を復元して、チェックポイントのエポックからスケジュールを再開します。既存のチェックポイントから新しい実験フォルダを開始する際の一般的な方法です。
  • --resume auto はその場で再開します。--output と --experiment が設定されている場合、その実験フォルダ内に last.pth.tar が存在すればそこから継続し、存在しなければ新しい実行を開始します。中断後に同じコマンドを再実行できます。チェックポイントの履歴、ベストメトリックの追跡、summary.csv はすべて一貫して引き継がれるため、--checkpoint-hist による破棄と model_best は再起動後も正しく保たれます。
  • --stop-epoch N は、--epochs で設定されたスケジュールを変更せずに、N エポックの完了後に停止します。最終エポックは常に評価およびチェックポイントが保存されるため、実行をセグメント単位で学習できます。
  • --save-epochs N [N ...] は、ランク付き履歴の外に、不変の milestone-N.pth.tar スナップショット(N は完了したエポック数)を保持します。ファイルシステムが許可する場合は last.pth.tar からハードリンクされるため、追加のディスク容量は消費されません。また、これらのエポックでは評価が強制実行されます。

これらを組み合わせることで、ウォームアップ・安定・減衰(WSD)の実験を手動で簡単に実行できるようになります。一度安定したトランクを学習し、その後、そのマイルストーンから完全なオプティマイザ状態を保持した独立したクールダウンを分岐させます。

# 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

減衰はスケジュールの最後の--decay-epochsに割り当てられるため、Pエポック完了時点からDエポックのクールダウンは--epochs P+D --decay-epochs Dとなります(--warmup-prefixを使用する場合は、--epochsから--warmup-epochsを差し引きます)。以下のsweep.pyではこれを自動化しています。

ハイパーパラメータスイープ

sweep.py(PyTorch 2.5 以降)は、train.py の任意の引数に対して、WSD 分岐をオプションで含めてスウィープを計画・実行します。各ジョブごとに完全な train.py --config ファイルを 1 つ書き出し、ジョブの依存関係グラフを含む plan.json を生成した上で、ローカル GPU のプールで実行可能なジョブを実行します。ワーカーが実行されている間、計画は固定されます。各ジョブは独自の実験フォルダを持つ通常の train.py 呼び出しであり、生成される各 run.sh は手動で実行したり、別のスケジューラに引き渡したりできます。

クイックスウィープにはスペックファイルは不要です。探索軸は--sweepから、ベース設定は--の後の末尾のtrain.py引数から取得されます:

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 は、実行対象の GPU を、CUDA_VISIBLE_DEVICES が設定されている場合(Slurm の割り当てなど)にそのインデックスとして列挙します。

WSDスイープでは、多くのクールダウンにわたって、ハイパーパラメータの組み合わせごとに1つの安定したトランクを共有します。以下の各学習率について、トランクは18、24、30エポックのマイルストーンを設けて30エポックまで実行され、各マイルストーンから6エポックのクールダウンが分岐します。これにより、12回のフルランの代わりに、トランク4本とクールダウン12本で済みます。クールダウンは、対応するマイルストーンが存在し次第、トランクが継続している間に開始されます。GPUを1つ以上必要とするジョブは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

plannerが以下のフラグを所有しているため、コマンドラインで指定したり、一括で処理したりすることはできません。

すべてのスウィープにおいて:

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

また、WSDスウィープでは:

  • --sched(wsdとしても指定できますが、いずれにせよプランナーが設定します)
  • --epochs
  • --decay-epochs
  • --lr-decay-fn

YAML 仕様では、分布を用いたランダムサーチ、ペアリング(zip された)軸、シードに対する繰り返し、およびベース設定ファイルをサポートします。スキーマについては、sweep.py の先頭にある docstring を参照してください。python sweep.py plan spec.yaml を実行すると、何も実行せずに設定ファイルとgraph.dotが書き出されます。

スウィープは、スペックファイル(コマンドラインスウィープの場合は作業ディレクトリ)を基準とした output/sweeps/<name>/ に保存され、スウィープされた値にちなんで命名された(trial-000-lr0.001)各トライアル用のフォルダが1つずつ作成されます。各フォルダにはジョブの実験フォルダが含まれます。保持されるチェックポイントはオプティマイザ状態を含む完全なコピーであるため、スウィープジョブは last.pth.tar と model_best.pth.tar のほかに、ランク付けされたチェックポイントを1つ保持します(--checkpoint-hist 1)。また、WSDスウィープではスケジュールが更新ごとにステップされます(--sched-on-updates)。ベース設定でいずれかを設定すると、それが上書きされます。実行中または実行後:

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

結果は、同じ予算での試行を比較します。WSDスイープでは、試行ごとに1行、クールダウンごとに1列(p24-d6は24エポックからの6エポックのクールダウン)が表示され、繰り返し実行の平均値である最終メトリックが示され、各列の最良値がマークされます。通常のスイープは、各エポック予算内で最終メトリックによってランキング付けされます。results.csvには、トランクセグメントを含むすべてのジョブと、それぞれの最良エポックが保存されています。検証セットがない場合、ランキングはトレーニングロスにフォールバックし、エンドポイントのチェックポイントはvalidate.pyで評価できます。

中断されたスウィープに対してsweep.py runを再度実行すると、スウィープが再開されます。完了したジョブはスキップされ、部分的に実行済みのジョブは、そのジョブ自身のlast.pth.tarから継続されます。スウィープフォルダを共有する複数のマシン上のワーカーは、それぞれで実行できます。これらはstate/locks配下のflockロックによって調整され、各ジョブのすべての学習プロセスもこのロックを保持しているため、ワーカーが死んだジョブは、最後のプロセスが終了するまで、再開始も再計画もされません。複数のマシンで共有されるスウィープには、NFSv4や-o flockでマウントされたLustreのように、すべてのマシン間でflockが機能するファイルシステムが必要です。ローカルロックのみのマウントではマシン間で調整できないため、各クライアントからロックを確認してください。ワーカーを停止すると(Ctrl-C、またはscancelからのSIGTERM)、そのジョブが停止し、ジョブのrun.shを手動で実行すると、この調整をバイパスします。

state/locks 以下のロックファイルは永続的です。ビジーなスウィープをクリアするために削除したり置き換えたりしないでください。代わりに、そのワーカーやトレーニングプロセスを停止するか、完了を待ってください。running (gone) ステータスは、トレーニングロックが解放されているが、試行が調整(reconcile)されていないことを意味します。ワーカーを実行して状態を確定し、未完了の作業を再開してください。status および results はジョブの状態を修復しません。

ワーカーは起動時に一度だけプランを読み取ります。スウィープを変更するには、そのスウィープのすべてのワーカーとトレーニングプロセスを停止し、--forceを付けて再度プランを作成してから、それらを再起動します。ジョブが開始される前であれば、プランのあらゆる内容を変更できます。開始後は、既存のトレーニングジョブを拡張するのみです。具体的には、既存のものの後に、より多くのトライアル、クールダウン、またはWSDポイントを追加します。この場合、各トランクは停止した位置から継続します。既存のトレーニングジョブを変更するには、新しいスウィープが必要です。生成されるパスはプランが書き込まれた時点で固定されるため、スウィープフォルダを移動するのではなく、新しい場所で再度プランを作成してください。

計画が中断された場合、ワーカーは不完全な計画の書き込みから設定またはランチャーを検出し、起動を拒否します。元の計画コマンドを--forceオプション付きで再実行して計画を完了または修復し、その後ワーカーを再起動してください。各計画の書き込みが成功すると、plan.json、設定、およびランチャーの対応する世代が公開されます。変更がなく完全な計画の場合は、何も書き込まれません。

例えば、上記のCLI WSDスウィープを36安定エポックに拡張するには、そのワーカーとジョブを停止し、元の計画引数に後続の点を追加して繰り返します。

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

YAML スイープの場合、元の仕様書にポイントを付加し、再起動する前にpython sweep.py plan spec.yaml --forceを実行してください。wsd.decay_epochsは明示的に指定し、変更しないでください(この例では[6]): デフォルト値は最終ポイントの20%であるため、ホライズンを延長すると、既存のクールダウンが変更されてしまう可能性があります。既存のトライアル ID を保持してください。グリッド軸の順序変更や拡張は、トライアルの番号付けを変更する可能性があります。lr_noiseを使用する場合、トランクのスケジュールはホライズンに依存するため、開始済みのスイープに後続のポイントを追加するには、新しいスイープが必要です。

トレーニング設定はプランに属します。specのtrainブロックを使用するか、CLIスウィープを作成する場合は--の後に引数を指定してください。実行時のトレーニング設定の上書きは存在しません。ランキングメトリクスなどのレポート設定、および出力設定(checkpoint_hist、log_wandb、wandb_project、wandb_tags)は、ジョブの状態をリセットしたりトレーニングのアイデンティティを変更したりせずに、--forceを付けてオフラインで変更できます。出力設定は将来の試行に適用されます。完了したジョブは再実行されません。

sweep.py は Unix の flock を必要とします。Linux での動作を確認済みで、macOS での動作も想定されていますが、未検証です。ネイティブの Windows はサポートされていません。WSL2 を使用してください。NFS のリース期間を超えてネットワーク分割が続く場合、ロックは維持されません。接続が切断されたプロセスがロックを失った後も学習を継続する可能性があるため、別のマシンで重複する試行が開始されることがあります。

検証 / 推論スクリプト

検証と推論のスクリプトは、使い方が似ています。片方は検証セット上のメトリクスを出力し、もう片方はtopkのクラスIDをcsvで出力します。トレーニングスクリプトのようにベースディレクトリではなく、検証画像を含むフォルダを指定してください。

モデルの事前学習済み重み(存在する場合)で検証するには:

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

チェックポイントから推論を実行するには:

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

学習例

ImageNetの学習レシピ

これらのコマンドは、選択した HParams レシピに対応しており、コピー可能な YAML 設定、ソース gist、公開されたチェックポイントの結果を確認できます。これらのコマンドは、/data/imagenet/train/および/data/imagenet/validation/配下に ImageFolder 形式のデータがあることを前提としています。--batch-sizeはGPU ごとの値です。 MobileNetV4 と ConvNeXt の例に明示されている学習率は、記載されたグローバルバッチサイズに対して適用されるものであり、GPU の数が変更されても自動的にスケーリングされることはありません。

MobileNetV4 Conv Medium、ImageNet-1k

mnv4_cm_r256_e500_gpu2.yaml より: 2つのGPU、グローバルバッチサイズ1024、256pxでの学習、20エポックのウォームアップと500エポックのコサイン減衰。 対応する重みは 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

GPUがbfloat16をサポートしていない場合は--amp-dtype float16を使用してください。--torchcompile inductorは任意です。

ViT Medium(registers付き)、ImageNet-1k

train-vit_medium_reg4-4gpu-in1k.yaml より: 4 GPU、グローバルバッチサイズ 1024、ウォームアップおよびクールダウン 10 エポックを含む 600 エポック。 対応する重みは 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

この実行では、EMAなしのAdamWを使用しています。ピークLRは、グローバルバッチ1024で約0.001131です。

ConvNeXt Tiny、ImageNet-12k から ImageNet-1k へのファインチューニング

hparams_84_00-convnext_tiny.in12k-args.yaml より: 8 GPU、グローバルバッチサイズ 4096、ウォームアップおよびクールダウン 10 エポックを含む 75 エポック。 ImageNet-12k の重みをロードし、--num-classes 1000 を設定して分類器を置き換え、ファインチューニングを行います。 生成されるチェックポイントファミリーは 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

マルチラベル分類

複数の独立したラベルを持つ画像には、--task multilabel を使用します。

  • --num-classes は語彙サイズを設定します。
  • --target-format indices (デフォルト) は、ターゲット列を正のゼロベースのクラス ID のリストとして読み取ります。 ラベルはバッチング前に float 型のマルチホットターゲットに変換され、空のリストは正のラベルがない画像を表します。
  • --target-format multihot は、長さ --num-classes の dense な multi-hot ベクトル([0, 1] 内の bool、int、または float 値)を読み取ります。このベクトルはそのまま使用されるため、soft な値は BCE で直接学習され、評価指標では 0.5 で二値化されます。multi-hot ターゲットのクラスマップは、ソースのクラスインデックスをキーとすることが必要です。

このフラグを指定しないと、整数のマルチホットベクトルはインデックスリストと区別できないため、すべてのリストがクラスインデックスとして読み込まれます。

植物病理学データセットは、image列と、ClassLabel値のシーケンスを含むlabels列という形式を提供します。その6つのクラスはcomplex、frog_eye_leaf_spot、healthy、powdery_mildew、rust、scabです。例えば、[5, 1, 0]は[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は、同じターゲット形式でのストリーミングをサポートしています。リーダーのサポート状況:

  • Hugging Face hfds および hfids は、マルチラベルのターゲットをサポートしています。
  • WebDataset (wds)は、各サンプルの.jsonサイドカーファイルに格納されているクラスIDのリストをサポートします。このリストは、--target-keyで指定されたフィールド名に保存されます。--target-keyを指定しない場合、.clsファイルが単一のクラスインデックスを提供します。
  • Folder and tar readersは単一のクラスインデックスを返します。

Wake Visionのように、ラベルごとに1つのバイナリフィールドを保存するデータセットでは、これらの設定を使用します。

  • --target-key person,depiction,body_part はカンマ区切りのフィールドのリストを選択します。各フィールドは、リストされた順序で1つのクラスとなり、0より大きい値は正としてカウントされます。これは hfds、hfids、tfds リーダーで動作し、フィールドが .json サイドカーにある場合の WebDataset でも動作します。
  • --num-classes は、フィールドの数と一致する必要があります。
  • --target-format は、マルチフィールドキーが独自の形式を定義するため、デフォルトのままです。
  • ネストされたフィールドパスには/を使用します。例えば、TFDSのbee_datasetでは--input-key input --target-key output/pollen_output,output/wasps_outputのように指定します。単一のターゲットキーも同じパスを受け付けます。/を含むリテラルなフィールド名(TFDSのimage/filenameなど)は、パスよりも優先されます。

StandardおよびNaFlexローダーは、mixupやcutmixを含むマルチラベルターゲットをサポートしています。NaFlexの学習は現在、hfdsなどのマップスタイルのデータセットが必要です。

このタスクは、logits付きバイナリクロスエントロピーで学習します。マルチラベル学習では、スムージングのデフォルト値はゼロです。--smoothing sを設定すると、各バイナリターゲットがtarget * (1 - s) + 0.5 * sに移動します。これは、Mixup/CutMixが有効な場合にそれらによって、それ以外の場合は損失関数によって適用されます。既存の--bce-sumおよび--bce-target-threshオプションも適用されます。このタスクでは、蒸留およびJSD損失はサポートされていません。

--loss は他の損失関数を選択します(bce はマルチラベルのデフォルトです):

  • asl: Asymmetric Loss。BCE と同じく、スムージングおよび Mixup/CutMix の挙動に従い、float32 で計算されるため、--amp と併用しても安全です。

    • --asl-gamma-negは、ネガティブターゲットのフォーカスを設定します(デフォルトは4)。
    • --asl-gamma-posは、正のターゲットに対するフォーカスを設定します(デフォルトは1)。
    • --asl-clipは、ネガティブの確率マージンを設定します(デフォルトは0.05)。
    • --asl-reduction のデフォルト値は batchmean で、クラス間で損失を合計し、バッチ間で平均化します。sum を指定すると、元の ASL の集約方法に戻り、バッチ間でも合計されるため、実効的な学習率がバッチサイズに比例して変化します。
  • twoway: Two-way Multi-Label Loss、 各サンプルのクラス間および各クラスのサンプル間で、正のlogitsと負のlogitsを対比させます。 そのlogitsはランキングスコアであるため、mAPが意味のある指標です。シグモイド閾値でのF1はキャリブレーションされていません。

    • --twoway-tp は、正の logit の温度を設定します(デフォルトは 4)。
    • --twoway-tnは、負のlogitの温度を設定します(デフォルトは1)。
  • zlpr: ZLPRは、0を内蔵のlogit閾値とする、ハイパーパラメータ不要なsoftmax交差エントロピーのマルチラベル拡張です。

  • db: 長尾分布を持つマルチラベルデータ向けのDistribution-Balanced Loss。ラベルの共起を考慮したサンプルごとの再バランス重み付きBCE、logitsに対する負に寛容な正則化、およびfocal項を備えています。Mixup/CutMixおよびsmoothingをサポートし、デフォルト値は参照DB設定に基づいています:

    • --db-neg-scaleは、負のロジットのスケールを設定します(デフォルトは2)。
    • --db-init-bias は、クラス事前確率のロジットシフト係数(デフォルト 0.05)を設定します。
    • --db-focal-gamma は、focal focusing を設定します(デフォルトは 2)。
    • --class-stats は、クラス統計ファイル(下記参照)として、必要なトレーニングラベルの数を指定します。

twoway と zlpr はバイナリターゲットを必要とするため、Mixup/CutMix や --smoothing はサポートされていません。

ラベル分布が偏っている場合、bceとaslは2つの重み付けフラグをサポートします:

  • --loss-pos-weight は、各クラスの正の項に重みを付与し、クラス内の正例と負例のバランスを調整します。これにより、予測は正の方向にシフトし、固定の閾値において召回率(recall)が高まり、確率の較正(calibration)が低下します。
  • --loss-class-weight は、各クラスの損失全体に重みを付与し、クラス間のバランスを調整しながらキャリブレーションを維持します。

各フラグは、明示的な重み(単一の値、クラスごとに1つの値を持つカンマ区切りのリスト、またはファイル)または、--class-statsで指定されたトレーニングラベルの件数から重みを導出するメソッド名を受け取ります:

  • --loss-pos-weight neg_pos: クラスごとのネガティブ/ポジティブの比率。
  • --loss-class-weight inv_freq: 逆クラス頻度。平均が1になるように正規化されています。
  • --loss-class-weight effective_num: 有効サンプル数から算出されるclass-balanced重み。平均値が1になるように正規化されています。

派生重みのオプション:

  • --loss-weight-power は、neg_pos および inv_freq の指数を設定します(デフォルトは 1)。0.5 を指定すると、より緩やかな平方根による重み付けが行われます。
  • --loss-weight-beta は、effective_num の重みに対する beta を設定します(デフォルトは 0.999)。
  • --loss-weight-max は、導出された重みの上限を制限します。

両方の重み付けフラグは同じ統計情報を使用できます。class_weights.py は、train.py と同じデータセット引数を使用して、スプリットのラベルをカウントし、クラス統計ファイルを書き出します(--method はメソッドの重みをプレビューします):

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 ...

非推奨フラグ:

旧フラグ置き換え
--bce-loss--loss bce
--jsd-loss--loss jsd
--bce-pos-weight--loss-pos-weight

ValidationではBCE loss、map(mean average precision)、micro_f1、macro_f1、およびsample_f1を報告します。メトリクスはパーセンテージで表され、分散ランク間で集められた予測を含む完全なValidationセットを使用します。順序付き分散サンプラーのパディングは除外されます。Exact mAPは評価が完了するまで予測をCPUに保持するため、そのメモリ使用量はサンプル数とクラス数に比例して増加します。正のサンプルがないクラスはAPにゼロを寄与し、分母がゼロであるF1値はゼロになります。

--eval-metric map は、チェックポイントの選択とスケジューリングのデフォルトです。F1 はシグモイド確率の閾値 0.5 を使用しますが、--multilabel-threshold で設定できます。mAP はこの閾値に依存しません。モデルの出力は logits のままなので、学習済みモデルを使用する際は、独立したクラス確率を得るためにシグモイドを適用してください。

過去のImageNetレシピ

これらの以前のランは、RMSProp、SGD、および AugMix/JSD 学習の有用な参照として残っています。ハードウェアと報告されたメトリクスは、元のランを説明しています。新しい AdamW レシピについては、上記の例や gist コレクション から始めることをお勧めします。

RandAugment を使用した EfficientNet-B2 - top-1 80.4、top-5 95.1

元のランではNVIDIA Apexを使用するデュアルTitan RTXカードが使用されていましたが、現在の--ampはネイティブのPyTorch AMPを使用しています:

./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

RandAugment を使用した MixNet-XL - top-1 80.5、top-5 94.9

元のランではNVIDIA Apexを使用するデュアルTitan RTXカードが使用されていましたが、現在の--ampはネイティブのPyTorch AMPを使用しています:

./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 と SE-ResNeXt-26-T

これらのハイパーパラメータ(または類似のもの)は、幅広いResNetアーキテクチャで良好に機能します。一般的に、モデルサイズが大きくなるにつれてエポック数を増やすのが良い考えです。例えば、ResNe(X)t50では約180〜200、より大きなモデルでは220以上です。より高性能なGPUを使用する場合やAMPを有効にしている場合は、バッチサイズと学習率を比例して増加させてください。これらのパラメータは、1080Tiカード2枚用のものでした:

./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

RandAugment を使用した EfficientNet-B3 - top-1 81.5、top-5 95.7

このモデルの学習は、上記のEfficientNet-B2 w/ RAと同じコマンドラインから開始しました。約3週間の学習後、プロセスがクラッシュしました。結果はあまり良く見えなかったため、いくつかのパラメータ(RE probの増加、rand-augの減少、ema-decayの増加)を調整して学習を複数回再開しました。しかし、どれも良い結果にはなりませんでした。最終的に、すべての再開から得られた最良のチェックポイントを平均化しました。結果はデフォルトの解像度/クロップでは平凡ですが、奇妙なことに、1.0のフルイメージテストクロップでははるかに良いパフォーマンスを示します。

RandAugment を使用した EfficientNet-B0 - top-1 77.7、top-5 95.3

Michael Klachko は、B2 のコマンドラインをより大きなバッチサイズに合わせて調整し、推奨される B0 の dropout rate 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

JSD損失とRandAugment(クリーン + 2倍のRA拡張)を用いたResNet50 - top-1 79.04、top-5 94.39

2世代前の1080Tiカード2枚で学習したため、時間がかかりました。ImageNetの検証結果は、私の最初の良好なAugMix学習の78.99と比べてわずかに、統計的には有意ではないほど良い結果でした。しかし、これらの重みは、ImageNetV2やImageNet-Sketchなどのテストでより頑健です。最初のAugMix実行とは異なり、SplitBatchNormを有効にし、クリーンな分割でのランダムイレーシングを無効にし、2つの拡張パスでのランダムイレーシングの確率を上げました。

./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

RandAugment を使用した EfficientNet-ES (EdgeTPU-Small) - top-1 78.066、top-5 93.926

Andrew Lavin によって、V100カード8枚で学習されました。モデルEMAは使用されず、最終チェックポイントは学習中の最良の8つのチェックポイントの平均です。

./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 w/ RandAugment - top-1 79.762、top-5 94.60

これらのパラメータは、SE-ResNeXt-50 および SK-ResNeXt-50、おそらく 101 でも良好に機能します。私は、2 GPU を使用して、実効バッチサイズあたりの学習率をわずかに高くして(lr=0.18、GPU ごとに b=192)学習した SK-ResNeXt-50 32x4d にこれらを使用しました。以下のコマンドラインは、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
Update on GitHub