為何傳統測試無法即時捕捉回歸錯誤

Transformers 函式庫支援超過 750 種模型類型，其測試套件龐大，包含主分支上超過 88,000 個 CPU 測試及每日執行超過 200,000 個 GPU 測試。

整合測試需載入真實檢查點並在硬體上執行 API，若每個合併請求（PR）都執行全部測試，將需要大量 GPU 資源全天候運作，這在實務上不可行。

因此，回歸錯誤往往在排程執行的測試發現時，已進入主分支。例如 2026 年 7 月 30 日啟用 PyTorch 縮放點積注意力（SDPA）後，UMT5 解碼器可關注未來 token，導致訓練時能「偷看」答案，此錯誤在主分支停留近兩個月未被發現。

模型整合合約（MIC）的組成與運作機制

Hugging Face 提出 transformers-mic 作為打包測試的標準提案，一個 MIC 包含三個部分：縮小版模型（fixture）、可執行的使用路徑範例、以及人工審核過的基準輸出。

合約的有效性取決於在 fixture 上執行使用路徑後，是否仍能產生與基準一致的輸出。合約涵蓋特定架構與使用路徑，而非單一檢查點；相容的檢查點可共用 fixture，但各自保留預期結果。

例如 SmolLM 合約會從「The capital of France is」等提示生成文本，並比較 token ID 與記錄的答案。此外，合約也比較訓練損失、檢查梯度是否有限，並驗證優化器步驟是否改變權重。

Hub 上的 fleet dataset 將每個 MIC 固定到凍結的修訂版本及記錄基準時使用的套件版本，確保 CI 執行可重現。在 PR 中，系統根據補丁修改的檔案選擇相關的 MIC 進行測試。

縮小版模型的建構原則與技術細節

建構 fixture 的目標是保留真實檢查點的所有層類型（包括滑動與全注意力混合、密集與 MoE 層），同時減少隱藏大小、注意力頭數與深度。預處理部分保持不變，詞彙表、特殊 token 及輸入維度均複製自原始模型。

權重建構過程嘗試使用隨機種子權重，若模型無回應則嘗試在合約的小批量範例上訓練。系統會重新載入儲存的模型，檢查輸出、損失與梯度是否有限，並拒絕失敗的建構。

為確保測試涵蓋真實用戶載入檢查點時的轉換代碼，fixture 保留原始權重檔案格式。基準輸出需在已知良好的 Transformers 版本上測量，經人工審核後發布為固定快照，CI 重複使用該快照而非每次重建。

以 Llama 4 Scout 為例，1086 億參數被縮小至 4470 萬參數，視覺堆疊從 34 層減至 2 層，語言堆疊從 48 層減至 4 層，但保留了檢查過的層類型與 MoE 路由風格。

UMT5 回歸錯誤的捕捉與驗證

研究團隊將凍結的 MIC 重現於 Transformers 五個月的提交記錄中，小型 UMT5 fixture 從 2026 年 7 月 30 日錯誤引入起標記該回歸，直到 9 月 28 日修復為止。

測試顯示標籤對數機率與審核基準差異為 1.22，訓練損失差異約 0.20。關鍵在於合約使用了預設的 SDPA 注意力路徑；若僅執行 eager attention 變體則會錯過此錯誤。

在 Transformers CI 的證明分支上還原修復後，檢查失敗並出現相同差異。選定的 T5 合約 runner 步驟在 CPU 上耗時 13.4 秒（不含設定時間）。

這表明 fixture 必須通過與真實檢查點相同的代碼路徑才能有效捕捉錯誤。傳統的前向傳播測試無法發現此類邏輯錯誤，因為模型仍能正常執行而不崩潰。

隨機權重與過擬合權重的比較

使用隨機權重的 Whisper fixture 對音訊變化反應微弱，雖能執行但無法有效測試音訊路徑。因此團隊在少量語調與單詞（如「red」、「green」）配對上進行訓練，使音訊變化在輸出中可見。

在權重初始化研究中，隨機 Whisper fixture 捕捉了 24 個注入錯誤中的 18 個，而過擬合 fixture 捕捉了全部 24 個。然而，兩者均錯過了真實 Whisper 檢查點所暴露的輔助解碼錯誤。

目前策略為：若隨機權重通過檢查則使用之；若需更高靈敏度或可讀答案則進行過擬合。訓練雖僅需數秒，但增加了收斂失敗風險與維護負擔。

此比較結果並未確立哪種方法較優，因為測試使用的是合成錯誤，且尚未發現僅由過擬合版本捕捉到的真實回歸錯誤。

自動化生成流程與未來挑戰

CLI 工具 tmic 用於建立合約與 fixture。對於新模型，LLM 透過 Inference Providers 起草使用代碼與清單，並由 CPU/GPU 執行測量候選基準。LLM 僅負責起草，變更預期結果需人工審核。

團隊利用代理跨模型家族建構 MIC，遇到邊界情況時修正通用配方而非單一 fixture。已發布的模型與剩餘缺口可在 coverage space 中查看。

截至 2026 年 11 月 1 日，Transformers CI 中的 MIC 工作僅報告失敗而不阻擋 PR。是否應阻擋取決於尚未測量的因素：在實際 PR 中捕捉真實錯誤的數量、誤報頻率、以及基準審核所需的工作量。

目前尚不清楚有多少錯誤（如 Whisper 輔助解碼錯誤）僅在使用真實權重時出現，或過擬合是否能捕捉隨機權重遺漏的真實錯誤。覆蓋範圍在模型家族與 API 使用上仍屬部分狀態。