GitHub Repo
Transformers 社群回報 DiffusionGemma 批次差異,相同輸入可能生成不同文字
10 月 22 日的 Transformers 社群回報指出,DiffusionGemma 在改變批次大小後,即使輸入相同,生成文字與停止位置仍可能改變。回報者將 H100 上的差異定位至專家路由與自我條件化運算,但尚無維護者確認或正式修復。

Transformers 的一份新技術回報,將 DiffusionGemma 的重現性問題指向批次大小。回報者於 10 月 22 日表示,在固定邏輯輸入、將相同內容複製為一至四列的控制實驗中,24 次生成有 22 次改變最終文字、19 次改變停止位置。測試使用 Transformers 5.15.0、BF16 與 H100,並另有 A100 實驗;這些數據目前均來自回報者。來源:GitHub 議題
這項現象與模型的生成流程有關。依官方文件,DiffusionGemma 先由編碼器建立提示的 KV 快取,再由解碼器反覆去噪整個 token 區塊;每一步的輸出 logits 又會作為下一步的自我條件化訊號。因此,檢查單次前向運算的數值差異之外,也需要觀察完整迭代後的文字與停止行為。來源:模型文件
回報者在 H100 上首先觀察到 MoE 路由投影出現差異:只有 0.051% 的路由分數改變,影響卻在兩層內擴及所有區塊位置。將路由投影改成逐列計算後,第一輪去噪可以一致,但後續仍在自我條件化的機率轉嵌入矩陣乘法分歧。兩處都逐列計算後,四列批次才在 293 次去噪步驟中與單列逐位元組相符。A100 的首次分歧出現在注意力層,顯示同一處理方式尚不能直接推廣至其他硬體。來源:實驗與修補構想
對部署團隊而言,這份回報提示了一項待驗證風險:若服務會依流量調整批次,相同請求可能因併批方式而得到不同結果,影響回歸測試與實驗比較。工程師可先固定模型修訂、軟體環境與批次條件,分別比較單列及併批結果。議題仍開啟,尚未列出關聯修補;逐列方案的吞吐成本、其他後端表現及新版是否受影響,也仍待驗證。來源:議題狀態