Transformersコミュニティ、分散評価の不一致を報告　末尾バッチの重複サンプルが検証損失に影響する可能性

Transformersコミュニティは10月26日、評価の正確性に関する問題を報告した。Trainer.evaluateで複数プロセスによる評価を実行する際、検証セットの末尾に重複サンプルを追加する必要があると、最終的なeval_lossが同じグローバルバッチを単一プロセスで処理した場合の結果からずれる可能性がある。報告者は5.20.2と4.57.6で差異を確認したとしている。確認時点で、この問題は未解決で、メンテナーによる確認や関連する修正はない。報告と再現コード

焦点は、損失の集計と重複サンプルの除去の順序にある。報告の分析によると、各プロセスがまずバッチ全体の損失スカラーを計算し、その値をバッチサイズ分複製してからgather_for_metricsに渡す。Accelerateの公式ドキュメントでは、このインターフェースは分散環境で最後のバッチに含まれる重複項目を除去できると説明されている。しかし、重複サンプルがすでにバッチ損失や正規化の分母に含まれていれば、出力項目を削除しても元の寄与は復元できない。これは報告者が提示した原因の説明であり、プロジェクトによる検証はまだ行われていない。Accelerateインターフェースのドキュメント

報告者は、ランダムに初期化した小型のQwen3モデルでテストした。3つのシーケンスには、それぞれ有効な予測対象が4個、2個、1個含まれており、2プロセスでは約1.687、単一プロセスでは約2.103となった。グローバルバッチサイズで割り切れるデータセットでもテストしたところ、結果は一致するか、浮動小数点精度の範囲内でわずかに異なるだけだった。このことから、末尾バッチと予測対象の数が調査すべき条件として示されている。ただし、このテストは独立したCPUプロセスとFileStoreプロセスグループを使っており、一般的なGlooまたはNCCLを使ったマルチGPU実行ではない。そのため、あらゆるデプロイ環境に影響すると直ちに推定することはできない。テスト条件

エンジニアリングチームにとって、この報告は、設定間で検証損失を比較する際にデータの分割方法も確認する必要があることを示している。わずかな損失差をもとにチェックポイントを選ぶ場合は、固定したモデルと同じグローバルバッチを使い、単一プロセスと複数プロセスの結果を比較するとよい。末尾バッチのサンプル数と有効トークン数も記録しておく。報告者は、サンプルごとの損失の合計と予測対象数を収集し、重複を除去してから集計する方法を提案している。今後は、この方法が既存の指標の定義を保てるか、正式なバックエンドで回帰テストが行われるかを見守る必要がある。報告者は、報告の執筆とレビューにAIを使用したことも開示している。提案と開示