GitHub Repo
Transformers 社群提出 MiniMax 精度修補,bf16 遞迴衰減可能讓長序列解碼偏移
10 月 4 日的社群重現指出,Transformers 開發版的 MiniMax Lightning Attention 以 bf16 計算衰減,可能讓部分注意力頭停止遺忘舊資訊。改用 fp32 的修補已提出但尚未合併,實際模型品質與效能影響仍待驗證。

Transformers 社群於 10 月 4 日回報,MiniMax Lightning Attention 的低精度運算可能造成隨解碼長度增加的數值偏移。案例使用開發分支、PyTorch 2.11 與 CPU,問題指向逐 token 更新的衰減係數及遞迴狀態;目前已有修補提案,仍待上游審查。問題回報
這項運算對長上下文模型尤其關鍵。官方文件說明,MiniMax-Text-01 混合 Lightning Attention、Softmax Attention 與 MoE,每七層 Lightning Attention 後配置一層 Softmax Attention。遞迴狀態的衰減控制舊資訊如何保留,因此部署時除了權重精度,也需要檢查狀態更新的計算精度。架構文件
回報指出,bf16 在接近 1 的位置精度不足,約大於等於 0.998 的衰減係數可能被捨入為 1,使相應注意力頭不再衰減。作者以公開配置估算,4,480 個 Lightning Attention 頭中有 388 個符合這種情況。不過,這是係數分析,不能直接解讀成真實任務的錯誤率或品質降幅。重現與限制
修補提案將衰減相關運算與快取狀態提升至 fp32,再於輸出投影前轉回原始精度。提案作者沿用小型模型重現,回報 3,000 token 時相對於 fp32 的隱藏狀態誤差,由約 7.39% 降至 0.39%。這項結果支持修補方向,但不是完整 MiniMax 模型的長文評測。修補提案
工程上的代價是線性注意力狀態改用 fp32 後,該部分快取容量約為 bf16 的兩倍,並非整個模型記憶體翻倍。部署團隊接下來應關注正式版本影響範圍、真實權重的 GPU 驗證,以及修補後的吞吐量與記憶體成本;驗收也應分別測試提示預填與逐 token 解碼,避免短輸出測試掩蓋累積誤差。作者明確表示尚未執行完整 MiniMax checkpoint,因此目前應視為具重現程式的數值問題回報。驗證範圍