小米回顧MiMo重複呼叫，修復僅9萬美元

小米MiMo團隊9月27日發布一篇技術部落格文章，回顧了MiMo-V2.6上線後開發者不斷反映的一個毛病：在編程代理裡，模型會一遍又一遍發出相同或幾乎相同的工具呼叫，白白燒掉上下文與運算資源，任務卻毫無進展。修復後的權重已經開源，檔名帶有MOPD後綴；API平台自9月25日清晨6點（北京時間）起已全面切換到新版本，MiMo Desktop使用者當期剩餘額度也整批重置，作為補償。

先把「呼叫太多」跟「呼叫重複」分開來看

這篇部落格並沒有把所有「呼叫次數偏多」都當成問題。小米把情況分成三類：並行呼叫是正常的最佳化手法，幾個呼叫各自查詢不同資訊；呼叫氾濫是呼叫數量超出任務實際所需；呼叫重複則是環境狀態與已知資訊都沒有改變，模型卻仍重複同一個動作。團隊真正要修的，是第三種情況。

依小米內部評估，回覆層級的重複率遠超過0.05%的容忍門檻，且各環境落差不小：

OpenCode裡的Flash版數字最難看，大約每100次回覆就有1次在原地打轉。

病根出在強化學習階段

團隊回放了強化學習過程中的各個檢查點，發現單輪發出超過十次呼叫的樣本占比，從第0步的11.1%一路升到第20步的24.6%；在MiMo Code環境裡情況更誇張，從30.6%升到41.7%。訓練原本設有懲罰機制，但只有單輪超過32次呼叫才會扣分。從第15步開始，觸發這項懲罰的樣本明顯變多，說明32這個門檻太寬鬆，攔不住模型養成「多呼叫幾次總沒有壞處」的習慣。

部落格給出一組相當直觀的數字：修復前，模型在第12次呼叫的當下，選擇繼續呼叫的機率是94.56%，選擇收手的機率只有5.43%。換句話說，它幾乎不會自己停下來。

兩條修法，成本差了一個數量級

第一條路最直接：把懲罰門檻從32次降到8次，用原本的MixRL流程重新訓練。內部測試裡重複率從13.45%降到3.83%，但代價是要把訓練回退20步重來，小米估算成本約231萬美元，而且換一組資料集效果就未必穩定。

最終採用的是MOPD，也就是多教師線上蒸餾。做法是拿內部收集到的重複樣本，另外訓練一個專門學「什麼時候該停下來」的強化學習教師模型，只跑了12步、用了約7000筆樣本；接著把主模型回退5步，在教師模型的引導下繼續訓練。整套流程下來成本約9萬美元，只有前一個方案的4%左右。

成效上，第12次呼叫時的收手機率從5.43%提升到92.17%。依部落格公布的累積停止曲線，修復前要到第59次呼叫，模型停下來的機率才過半；修復後到第8次呼叫，這個機率就已經來到99.87%。小米表示各平台的重複率都大幅下降，不同上下文長度下表現一致，整體基準測試分數也沒有掉。

放回V2.6這條時間軸上看

MiMo-V2.6是9月22日發布並開源的，當時小米最強調的是後訓練規模：據媒體披露的數字，Pro和Flash各自跑了30步強化學習，合計成本約350萬美元。五天後這篇檢討，等於把那一輪訓練留下的一個副作用攤開來講，連「原本可能要多花231萬美元」都寫了進去。

國內模型團隊主動公開上線後事故檢討的並不多，把沒有採用的方案成本也一併列出的更少見。對在OpenCode、Claude Code裡串接中國模型工作的開發者來說，更實際的重點是：如果前幾天遇過MiMo反覆重讀同一個檔案、反覆執行同一條指令，現在API已經是修好的版本；自行架設服務的使用者，則需要換成帶MOPD後綴的權重。這裡引用的重複率數字，全部來自小米內部評估，第三方複測結果目前還沒有公布。

參考來源：小米MiMo團隊技術部落格、CocoLoop；各環境重複率、氾濫率與兩種修復方案的成本，皆以小米內部評估口徑為準。