Transformers 社群追查 Mamba2／Zamba2 快取解碼差異，時間步長限制可能未套用

Transformers 的一則狀態空間模型回報，讓預填與逐 token 解碼的一致性成為檢查焦點。問題於 10 月 9 日提出，隔日另一位社群成員表示重現 Mamba2、Zamba2 的 logits 差異，並指出其他模型共用相關快取路徑。截至查閱時，議題仍開啟，頁面未列出關聯修補 PR。社群回報

回報者檢查的程式碼中，完整序列掃描會先對時間步長 dt 加上偏置、經過 softplus，再依 time_step_limit 限制範圍；快取單 token 更新則交由更新函式處理偏置與 softplus，卻缺少相同的範圍限制。因此，相同輸入採用整段處理或前綴加快取續算時，可能使用不同的狀態更新方程。原始驗證涵蓋 CPU 與 CUDA 上的獨立 PyTorch 函式，未測量預訓練模型的生成品質。重現與修正提案

官方文件將 Mamba2 的 time_step_limit 定義為時間步長裁切範圍，預設為零至無限大；這表示是否設有有效邊界，是排查時的重要條件。快取保存狀態空間與卷積狀態，供後續 token 重用。文件也提醒，不同核心、運算順序與低精度可能造成數值差異，因此測試需要區分一般誤差與此次限制缺漏。Mamba2 官方文件

對工程團隊而言，技術風險在於離線整段評估與線上快取推論可能不一致；這是由回報機制推導的風險，尚不能解讀為回答品質普遍下降。建議固定權重、輸入、精度與填補方式，比較完整掃描及快取續算的 logits 與最終狀態。提案是在單 token 核心前統一完成偏置、softplus 與裁切，並避免核心重複處理；下一步仍須驗證完整模型及加速後端。正式版本是否受影響，也需要逐一核對，不能由開發分支案例直接推定。議題驗證範圍