Transformers 社群回報 RoPE 精度差異，載入後轉 bf16 可能放大長上下文角度誤差

Transformers 社群於 10 月 4 日回報，兩種常見的 bf16 模型初始化流程，可能產生不同的位置編碼數值。案例在 5.18.0 與當時主分支重現：直接使用 from_pretrained(dtype=torch.bfloat16)，RoPE 的 inv_freq 仍保留 fp32；先載入再呼叫 model.to(torch.bfloat16)，則會把頻率緩衝區一起轉為 bf16。回報也指出，Trainer 的 bf16_full_eval=True 會走到後者路徑。重現案例

這項差異與長上下文的數值穩定性有關。官方文件說明，RoPE 依位置旋轉注意力的 query 與 key 向量，讓模型取得相對位置資訊；頻率值因此直接參與旋轉角度的計算。從這個機制推論，頻率先被低精度捨入，再乘上較大的位置索引，可能放大角度偏差。RoPE 官方文件

回報者以微型 Llama、32,768 個位置及 fp32 參考值比較，直接以 bf16 載入的平均角度誤差約為 0.0006 弧度，載入後轉型則約為 0.6733 弧度。這是旋轉角度測量，尚不能換算為回答正確率或長文檢索能力下降幅度；測試也未涵蓋 GPU、分散式包裝模型與真實權重的下游任務指標。測試方法與限制

社群隨後提出在 PreTrainedModel._apply 保留相關 fp32 緩衝區的修補，讓權重依要求轉型，位置頻率維持原精度。不過，維護者於 10 月 5 日表明不接受這項做法並關閉 PR，頁面未提供詳細理由，因此目前不能視為已有上游修復。修補提案與維護者回應

對工程團隊而言，這起回報提示長上下文評估應記錄精度轉換流程。建議以相同權重與輸入，比較直接指定 dtype 載入、載入後轉型及完整評估流程，先檢查頻率緩衝區，再量測 logits 與任務表現。後續值得追蹤的是維護者是否提出替代方案，以及差異在實際模型和部署硬體上是否具有可觀察的品質影響。