Transformersが「モデル統合契約」を導入

Transformersは750種類以上のモデルをサポートしており、そのテストスイートは膨大である：mainブランチでは88,000以上のCPUテスト、毎日の実行では200,000以上のGPUテスト。統合テストは実際のチェックポイントを読み込み、実ハードウェア上でモデルのAPIを使用する。これらをすべての変更リクエストごとに実行することは、大量のGPUを一日中占有することになり、現実的ではない。したがって、回帰はスケジュールされた実行で検出される前にmainブランチに到達する可能性がある。

大きなモデルをテストするのではなく、モデルを縮小する

このアプローチは、fixture、すなわち実際のチェックポイントの設定から構築された、レイヤー数が少なく幅は狭いが、元のモデルに存在するすべてのタイプを含む小さなモデルを作成することである。そのトークナイザーとプロセッサーのファイルは変更されない。このfixtureは一度公開され再利用され、高速テストは単純なCPU上で実行される。チームのCPU調査では、UMT5の実験用fixtureは66 MBで、ソースチェックポイントの1,227 MBと比較された。この方法は、標準GPUに収まらないがfixtureはCPUで実行できる非常に大きなモデルにも適用できる。

テストは単なる読み込みと推論パスを超える。UMT5のバグはこのパスを問題なく通過しただろう。fixtureは完全な統合テストの代わりにはならないが、エラーがmainブランチに到達する前に検出する機会を提供する。

MICは3つの要素を含む：fixture、使用パス（テキスト生成や訓練ステップなどの実行可能な例）、およびベースライン（その例を実行し人間によって検証された記録された出力）。fixture上での実行が常にこれらの参照出力を生成する場合、契約は守られている。

UMT5バグに関する振り返り

チームは、Transformersの5ヶ月分のコミットに対して固定されたMICを再実行した。UMT5のfixtureは、2026年7月30日の導入から9月28日の修正まで、回帰を報告した。ラベルの対数確率は検証済みの参照から1.22異なり、訓練損失は約0.20異なった。重要な詳細があった：契約はデフォルトの注意経路であるSDPAを使用していた。唯一の「eager」注意バリアントのみを実行してもバグは明らかにならなかった。TransformersのCIテストブランチでのデモンストレーションでは、修正が取り消された状態で、同じ差異で検証が失敗し、T5ランナーのステップはセットアップを除いてCPU上で13.4秒かかった。

エージェントによる契約の生成

コマンドラインツールtmicが契約を作成しfixtureを構築する。新しいモデルに対しては、LLMが使用コードとマニフェストを記述し、その後CPUとGPUの実行が候補となるベースラインを測定する。チームによれば、LLMは記述するが承認はしない：期待値への変更はすべて人間による検証が必要である。Llama 4 Scoutのモデル縮小レポートはこの方法を示している：1,086億パラメータが4,470万になり、視覚部分は34層から2層に、言語部分は48層から4層になった。

テストモデルについて、チームはランダムな重みと少数の例で訓練された重みを比較した。重み初期化に関する調査では、ランダムなWhisper fixtureは注入された24個の欠陥のうち18個を検出し、訓練済みfixtureは24個中24個を検出した。これらの欠陥は合成的なものであり、両方のバージョンは実際のWhisperチェックポイントによって明らかになったアシストデコードのバグを見逃した。

2026年11月1日現在、Transformers CIのMICジョブは失敗を報告するが、変更リクエストをブロックしない。実際に検出されたバグの数と誤検知に関する測定がないため、これをブロッキングにするかどうかは未解決の問題である。