TransformersコミュニティがDiffusionGemmaのバッチ差異を報告、同じ入力でも異なるテキストを生成する可能性

Transformersに寄せられた新たな技術報告は、DiffusionGemmaの再現性の問題がバッチサイズに関係している可能性を示している。報告者は10月22日、論理上の入力を固定し、同じ内容を1〜4行に複製する対照実験で、24回の生成のうち22回で最終テキストが、19回で停止位置が変わったと述べた。テストにはTransformers 5.15.0、BF16、H100を使用し、A100での実験も別途行った。これらのデータはいずれも現時点では報告者によるものだ。出典：GitHub issue

この現象はモデルの生成プロセスに関係している。公式ドキュメントによると、DiffusionGemmaはまずエンコーダーでプロンプトのKV cacheを作成し、その後デコーダーがtokenブロック全体を繰り返しdenoiseする。各ステップの出力logitsは、次のステップのself-conditioning信号として使われる。そのため、単一のforward passにおける数値差を調べるだけでなく、反復処理全体を経た後のテキストと停止挙動も観察する必要がある。出典：モデルドキュメント

報告者がH100で最初に確認したのは、MoEルーティング投影の差異だった。ルーティングスコアの変化はわずか0.051%だったが、その影響は2層以内にすべてのブロック位置へ広がった。ルーティング投影を行ごとに計算するよう変更すると、最初のdenoise反復は一致したものの、後続の反復ではself-conditioningの確率から埋め込みへの行列積で再び差異が生じた。両方の計算を行ごとに行うと、4行のバッチは293回のdenoiseステップにわたり、1行の場合とバイト単位で一致した。A100では最初の差異がattention層で発生しており、同じ処理方法を他のハードウェアにもそのまま適用できるとは限らないことを示している。出典：実験と修正案

デプロイチームにとって、この報告は検証が必要なリスクを示している。トラフィックに応じてバッチサイズを調整するサービスでは、同じリクエストでもバッチ化の方法によって異なる結果が出る可能性があり、回帰テストや実験結果の比較に影響する。エンジニアはまず、モデルのrevision、ソフトウェア環境、バッチ条件を固定し、単一行の場合とバッチ処理の場合の結果をそれぞれ比較できる。このissueはまだオープンで、関連する修正は掲載されていない。行ごとに計算する方法のスループットへの影響、他のバックエンドでの挙動、新しいバージョンが影響を受けるかどうかも、引き続き検証が必要だ。出典：issueの状態