GitHub Repo
TransformersコミュニティがT5の注意機構切り替え不具合を報告、設定はSDPAでもeagerで実行
10月6日の開発版での再現では、読み込み後にT5の注意機構バックエンドを切り替えると、トップレベルの設定だけが更新され、エンコーダーとデコーダーはeagerを使い続ける可能性が示された。実際の呼び出し回数も示されているが、メンテナーによる確認や修正のマージには至っていない。

Hugging Face Transformersコミュニティは10月6日、T5で実行時に注意機構バックエンドを切り替えた際、設定と実際の処理が一致しない可能性を報告した。まずeagerで読み込み、その後set_attn_implementation("sdpa")を呼び出すと、トップレベルの設定では切り替わったように表示される一方、内部のエンコーダーとデコーダーは元のバックエンドを使い続け、警告も出ないという。報告の再現環境は開発版5.19.0.dev0、PyTorch 2.11.0、macOS ARM CPU。正式版への影響は未確認だ。コミュニティの報告
報告者はgoogle-t5/t5-smallで単一のフォワードパスを実行し、注意機構レジストリ内のSDPA関数をフックして呼び出し回数を数えた。読み込み後に切り替える方法では呼び出しは0回だったのに対し、SDPAを指定して直接読み込んだ比較対象では18回だった。設定値を読むよりも直接的な実行時の証拠だが、速度、メモリ、生成品質への影響は測定されていない。再現コード
報告者は、サブモデルへ設定を渡す際の条件に原因がある可能性を指摘している。コードは設定クラスが異なるかどうかで更新対象を決めるが、T5の2つのスタックはディープコピーされた設定を持つ一方、どちらもT5Configのインスタンスであるため、更新対象から外れる可能性があるという。これはあくまで報告者による根本原因の分析であり、ほかのモデルへの影響も個別には検証されていない。仕組みの分析
公式ドキュメントでは実行時の切り替えがサポート機能として紹介され、注意機構バックエンドが異なる演算方式によってメモリトラフィックを改善すると説明されている。エンジニアリングチームにとって、このような食い違いはバックエンド比較実験の条件を誤って記録させたり、SDPAを対象とする回帰テストが想定した経路を通らなかったりするリスクにつながる可能性がある。これは報告から導かれるテスト上のリスクであり、GPUアクセラレーション全般が機能しないことを示すものではない。注意機構バックエンドのドキュメント
当面は、報告にある直接読み込む方法を参考にし、呼び出しを追跡して実際のバックエンドを確認できる。今後は、メンテナーが設定の受け渡しに関する問題を確認するか、修正が同じクラスの独立した設定オブジェクトにも対応するか、どの正式版でテストの調整が必要になるかに注目したい。確認時点で議題はオープンのままで、ページには修正ブランチやPRの記載はない。議題の状況